Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.

You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.

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

Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."Glenn Gould

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 ).

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

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

E.g. MyCode (master)

----

Yup, cherry-picking is useful... if you're careful ! :-)

** that said, it could be made more visible. The window title bar would be a good place.

Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."Glenn Gould

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.

Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."Glenn Gould

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

Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."Glenn Gould

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

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...

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.

I've been using the index editor and stashing capabilities quite a bit in the last 1.5 year. Rebase, not as much. Maybe because I'm mostly working on my own, I don't mind having a few meaningless commits. I haven't looked for rebase interactive in the new SmartGit ; but, as you say, it doesn't seem to be implemented yet. Should be soon as the developer mentioned an available preview in October.

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.

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.

--

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 !

Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."Glenn Gould

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

Quote

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.

Quote

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.

Quote

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!

Quote

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.

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."Glenn Gould

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.

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

This is quite true. I made a few mistakes in the past. I don't find it that annoying though as I forces me to be more vigilant when I commit -- i.e. review each changes made to the code before indexing & committing.

Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."Glenn Gould

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.

Logged

"A problem, properly stated, is a problem on it's way to being solved" -Buckminster Fuller"Multithreading is just one damn thing after, before, or simultaneous with another" -Andrei Alexandrescu

Pretty surprising, yes! It somewhat corroborates the perception/idea that Git is 1- great at what it does 2- and a/the "major player" in the DVCS (or maybe even the whole VS) ecosystem...

Logged

"I suppose it can be said that I'm an absent-minded driver. It's true that I've driven through a number of red lights on occasion, but on the other hand, I've stopped at a lot of green ones but never gotten credit for it."Glenn Gould