I'm the instigator of using Git at my current workplace; we were using
Subversion before, and TortoiseSVN as our client app. We're on Win7 so we
installed MSysGit and I'm using Git Bash; personally, I'm using the
command-line and it's perfectly filling my need.
But my colleagues wanted to have a GUI interface. I suggested them to
try out TortoiseGit (I thought it was a natural replacement from
TortoiseSVN) and they've been using it for about 6 months. We've been
through all sorts of problems. My impression is that TortoiseGit is not
fully adhering to Git's philosophy but some bugs might also be hidden in it.
We tried SmartGit for about 2 months now (I even gave it a try in order
to be able to offer support to the team) and it's quite intuitive and works
nicely. Free for personal use and cheap for professionnal (you pay a
reasonable fee for a pack of licences).
So beware, if you're having problems, maybe your GUI client is to be
blamed, not just a learning curve issue.
If you're running on a Mac, like a colleague of mine, consider using
SourceTree from Atlassian (who makes Bitbucket). It's an awesome tool and I
wished it was ported to Linux and Windows systems. And it's free.
Enjoy working with Git!
On Thursday, December 27, 2012 11:19:18 AM UTC-5, Francesco Rugiano wrote:
> First of all i'd like to thank you for your suggestions. I think that i'll
> follow Philip Oakley's suggestions, so i'll keep the repository clean but
> complete. I'm using TortoiseGit to manage my local repos, so i just have to
> - "Show log"
> - Select two or more commits, then right click and "Combine to one
> commit" (i don't know what commands this procedure equals to)
> - "Git Sync", then push after having ticked the box "Force" (otherwise
> it will ask for a pull before)
> Then, from the other local repos on other PCs, i do a pull with force
> enabled and.. i get everything.
> If, in the future, i will get bigger local repos, i think i'll use the
> depth parameter as suggested by Manlio Perillo.
> Konstantin Khomoutov's solution seems a bit too complicated to me, and the
> remarks on the fact that this can be an unneccesary operation made me
> reconsider this option.
> Anyway, thank you all for these replies.
> Il giorno lunedì 24 dicembre 2012 01:31:37 UTC+1, Philip Oakley ha scritto:
>> Why do you need 'small'? and how small? There are a few different
>> reasons that may affect what you choose.
>> 1. You have big different binary files in each commit - it is good to get
>> rid of these - perhaps set a better gitignore file.
>> 2. You have lots of small partial fixes, such as work in progress (WIP)
>> commits - You should 'squash' the WIP commits using 'rebase -i', once you
>> are satisfied with your branch. This will mean the new commit sequence
>> moves steadily form one working code base to the next in small well
>> explained steps - this is good.
>> 3. You have a lot of steps in you development on big source files and are
>> worried about storage - Don't. Git is very good at it's repository
>> compression, so the 'many steps' will fit in a small space, and you will
>> still have a better history.
> Il giorno lunedì 24 dicembre 2012 15:52:01 UTC+1, Konstantin Khomoutov ha
>> I'm not sure it would work for you, but look at `git replace` .
>> Basically, using this feature, you might pretend that A->B->C
>> line exists in the PC1 and PC2 repos, but is in fact absent.
>> To do this, you first record an empty commit object and then
>> create a "replacement record" for it as described in the `git replace`
>> manual. Such a record has to replace the SHA-1 name of the D's parent
>> with the SHA-1 name of your empty bogus commit.
> Il giorno lunedì 24 dicembre 2012 16:05:35 UTC+1, Manlio Perillo ha
>> You can also try with git clone --depth=1 <remote-repository>, but read
>> the manual page carefully.
>> If you want full history again, you can just
>> git clone <remote-repository>.