I think contacting the developers is the best way for such a problem -- and especially for an actively developed application like SmartGit.

BTW, does any one know how to tell -- via the Main perspective -- which branch one is on?

I currently bring up the dialog box that appears via Branch -> Switch (Ctrl+G) to figure this out.  I'm hoping there's some obvious place I'm missing on the Main perspective I can look to get that information...

I started to feel the need for this after using the cherry-picking functionality (nice to have ).

In the the "directories" section/pane, the top directory should have the branch specified in parenthesis.**

Great!  Thanks a lot for pointing that out -- much appreciated

You're working with Git ? Is there a reason why you wanted to do an explicit rename ? Normally Git is good at automatically detecting renames.

Sorry, your post got lost in my emails for some reason... I'll look at that this WE.
Did you find any solution ?

Just found the Index Editor feature.  IIUC, this allows one to not commit all changes in a file, but rather to choose portions (like git add -p?).  Commits can be more focused, so reviewing history can be easier...I think

Seems quite nice  

---

Found the following documentation to be helpful:

 Staging, unstaging and the Index Editor

---

Possibly a (minor?) gotcha...

The documentation states:

Only the contents of the middle and the right editor can be modified. You can alter the contents of the Index either by editing the contents of the middle editor, or by moving chunks between the three editors. To do so, either click on the arrow and 'x' buttons between the editors, or click on the Take Left and Take Right buttons on the toolbar. After you're done, save your changes and close the Index Editor.

IIUC, the middle here represents the index and the right is the corresponding file in the working tree.  So I think that although it's called "Index Editor", one can also edit working tree content -- may be this can be convenient...

FWIW, it looks like there is some kind of stash support (at least in the 2.x series):

Spent some time trying to figure out how to view stash content -- perhaps the following may be helpful for someone else.

IIUC to view the content of a stash, open the log view (Control+L here), and find rows corresponding to a stash:



The left highlighted section shows two rows:

 The row beginning with text "On master" appears to represent tracked file changes in a particular stash.

 The row beginning with text "untracked files" appears to represent untracked files for the same stash.

By selecting one or the other row, other areas of the UI change correspondingly (e.g. the Files tab -- the right highlighted area in the image).  Subsequent examination of appropriate areas of the UI appear to let one determine what is in a particular stash.

For reference, this was in a 3.x series SmartGit client.

Thanks for the response

Git is fun, isn't it ?

He he -- once I figure out how to do something I'm stuck on, perhaps so.

Rebase, not as much. Maybe because I'm mostly working on my own, I don't mind having a few meaningless commits.

I take the log rewriting features to be a longer term investment -- for those days when I don't remember so well what was done before (wait...isn't that most days?).

One of the benefits I'm experiencing through the use of DVCS has to do with reviewing code -- at commit time, when viewing the log, etc.  I find it tends to uncover opportunities for improvement.  When one's log consists of commits that are easy to understand and are focused, I find the reviewing tends to be easier.  I am guessing that modifying past commits can aid in this process.

Apart from that, yes, stashing can be extremely useful. E.g. for those times where I find a bug that should be fixed before pursuing some coding : stash the current work, do the bug fixing, come back to previous coding by reapplying stash.

Definitely seems like a good time to use stashing.

What I've been using it mostly for is the following sort of situation:

• Working on feature A
• Realize I need feature B
• Stash feature A work
• Implement feature B and test
• Commit feature B and test
• Apply saved stash to continue work on A

Before learning how to use the stash, I was using the Index Editor to selectively commit -- but I've found that after one accumulates enough changes, picking out the relevant bits can become error-prone and overwhelming.  He he...I need better planning too.

Still trying to develop the habit of pausing to stash before starting work on something unexpected though.

You mentioned renaming in a previous post. I still use the command line when I want to do an explicit file rename. But I usually don't have to as Git detects those if you're careful not committing renames with a bunch of other changes.

I use the GUI but manually remove and add.  Still seems like it'd be nice if there were explicit support for renaming!

SmartGit proved to be quite user friendly, stable and helpful. Used it almost exclusively, together with TortoiseGit which has some great features implementations too (I especially like the fact that I can select and copy commits from the log view and I'll get a nice clean copy of all of them, with the comments... I use that for quickly creating reports). Also, SmartGit now supports Hg, which is a good thing for those of us who use mercurial !

It's nice to have that Hg support 

As I try hard not to use applications that modify the registry, I have not really used TortoiseGit -- a pity, as it seems so nice.  I wonder if there's a way to get it to work with 3rd party Explorer alternatives...

---

Apart from interactive rebasing via the command line, I've been using magit in Emacs a bit.  Once I got the hang of the UI idea, I've been finding it to be pretty decent.

FWIW, the following screencast was very helpful in getting started:

  Meet Magit

This may be documented somewhere, but since it caught me by surprise...

I noticed that if:

• there is a selection of files in the Files view of the main project
• the File view has focus
• a commit is initiated

The commit appears to include the selected files even if changes from them have not been registered with the index.

This seems like it can be convenient at times (as well as a good reminder to check the list of files that have changes in the commit dialog), but I think over time it's likely that it will lead to unintentional changes making it into commits.

I'm not sure yet what happens if there is a file selected (AND the Files view has focus) AND the file has some changes registered with the index, and then a commit is executed. the whole file from the working tree appears to get staged -- so all changes seem to get committed.

FWIW, my brief exploration of the preferences didn't turn up any option to disable this behavior.

---

Armando: Hope you got a chance to check out magit.

Came across the following SmartGitHg docs:

  Modifying the History

Sections for:

• Modifying the last commit
• Merging the last two commits
• Splitting the last commit into two
• Modifying older commits
• Merging and splitting older commits
• Reordering commits

A brief reading suggests the content may not have been updated for the version 4 series (e.g. no mention of "joining commits").

However, since the current release of version 4 doesn't appear to support the bold-faced sections in as convenient a fashion as the non-bold-faced ones, the docs still seems potentially useful.

Haven't tested the instructions yet so not sure if any of the bold-faced section steps are easier than using interactive rebasing from the command line.

Rather surprising:

http://blogs.msdn.com/b/bharry/archive/2013/01/30/git-init-vs.aspx

Visual Studio will have Git support – and concretely, we released a CTP of a VSIX plugin for the Visual Studio 2012 Update 2 CTP today.

...

Why are we incorporating Git?

When we made the decision that we were going to take the DVCS plunge, we looked at many options.  Should we build something?  Buy something?  Adopt OSS?  We looked at Git, Mercurial and others.  It didn’t take long to realize that Git was quickly taking over the DVCS space and, in fact, is virtually synonymous with DVCS.  We thought hard about building something.  Git hasn’t been as friendly for Windows developers as on other platforms.  By building on Git, we can take all the time we might spend just “catching up” and spend that effort on something where we can add more distinctive value.  Choosing Git just made sense.

...

Older versions of VS & TFS – At this time, we are not planning to include Git integration in older versions of VS or TFS.

Interesting to see MS adopt Git as an official first-rate citizen.

And it's going to be interesting to see what "His Screwyouness" has to say about this ;p

Who is His Screwyouness?

Linus Torvalds - he tends to flip people off and call them nasty names and such - and now Evil Inc. is taking his baby and putting it into one of their big, nasty producst? Uh oh!