Since I'm running out of time, I'll have to be brief but might be able to expand during the weekend.
It does miss some other important ones though, like “blame”, "blame" is on our todo-list. Could you please explain the use-case behind "clone --bare"? Isn't a bare repository usually located on a server without GUI?
“stash”, “clone –bare” (last one : surprising, to say the least… Unless I missed something [I did miss the "stash" command which was very obvious ] ).
Nice to know blame is on the todo list.
As for the "clone --bare" use-case... If I remember correctly, I think I was toying with the idea of using Dropbox as a Git repository/server and wanted to clone my current working directory to the Dropbox folder. I don't remember all the details at the moment. I'll see if I can find more details later.
I did encounter a few problems and solving these problems meant dropping to the command line. E.g. : how do you "correct" a rebase that’s stalled… and won't abort nor continue ? hmmmm... Do you mean, that SmartGit sometimes hangs during a rebase? This bug has been fixed in version "2.1 early-access build 5". This was caused by Git trying to open an editor and waiting for it to exit.
That must be it. I will Download the latest version. Thanks for the heads up.
I also had another problem with rebase -- not sure. I'll have to checkout my notes and maybe try to reproduce the problem later... that is, if there was a problem.
The manual is ok, but not as clear as Tortoise’s, IMHO. Very dry, almost no graphs… and so it remains slightly abstract. I’d almost rather read Git’s man pages (not bad at all btw).You are right, our manual is a weak spot.
SmartGit is pretty feature rich. It would greatly benefit from a better manual where all features are clearly documented. A few interface images would be good too...
Wow, nope, I didn't know about the search as you type feature.What shortcut did you expect? What we can do to make the "search-as-you-type" feature more noticeable?
Thanks for sharing all this!
Yes, the arrows do feel a bit odd, but I'll get use to it.
As you probably know, a lot of Windows applications (text editors, IDEs) use F3 and Shift/ctrl+F3 to move to next/previous occurrence (can't talk about Linux or Mac as I haven't really worked with those in the last couple years and I forgot...). I couldn't say for sure what the standard is, but F3 is what I'm used to... Hence the "awkward" feel.That said
, it's probably not a big deal if everything is documented properly or easily discovered (tooltips or whatever). Arrows are perfectly fine if one knows what they're supposed to do. Documentation is key here.
Other small points I can think of:
- Some other shortcuts feel a bit weird. E.g.: Ctrl+T for staging. I immediately changed it for Alt+Enter, and Ctrl+Alt+Enter for editing the index, which seems much more natural when reviewing changes using Alt+Arrows. This is personal of course... but just saying.
- After staging some content, the focus always moves to the newly staged file, which interrupts the "files modifications reviewing". There might be a way to prevent that but I haven't found it. Question: Could the focus remain at the top of the list and not move? When reviewing files before committing , it's inconvenient to always have to move back to the top of the file list or where the other file to review is located. But like I said, I'm aware that I might be missing something.And last one for today
(something super minor that occurred to me while using SmartGit this morning):
- Some tooltips seem too verbose.
E.g., in the files section/table : "if selected, unchanged files will be shown".
Why not simply : "Show unchanged files" ? It's more "to the point" IMO.
Like I said, it's minor, but... the devil is in the details!
Thanks for your attention.