Advanced Git tips (slides) • Hacker News Board

Re: Advanced Git tips (slides)

#21

Post by pyre » Sat, Oct 09, 2010, 3:59 PM UTC

amix wrote: post #6

We recently switched from SVN to Git and the transition has been painful - last week there has been at least one issue pr. day that has stopped work and that needed to be addressed. Personally, I have used Git before via github and it has worked well (tho' my usage was mostly doing small updates, no branches, no merges etc.) My current impression of Git is that it's very powerful, but too low level and not that user…

  > We recently switched from SVN to Git

Part of the problem is that git is not similar to SVN in the way that SVN was similar to CVS. People have to give up their old paradigm of thinking, and it certainly helps if at least one person in your group is a git guru (or at least someone that is willing to investigate/fix problems without feeling like it is a chore) otherwise you will end up in the situation where everyone feels like the whole conversion process/idea was just a chore. If there is someone that makes themselves the 'go to guy/girl' for git issues it alleviates the rest of the group from thinking about git issues all of the time.

Re: Advanced Git tips (slides)

#22

Post by rue » Sat, Oct 09, 2010, 4:04 PM UTC

empika wrote: post #2

am i being an idiot? I can't see a way to change slides :s

There should be at least a noscript version with manual navigation if one does not want to include it in the regular.

Re: Advanced Git tips (slides)

#23

Post by prog » Sat, Oct 09, 2010, 4:39 PM UTC

amix wrote: post #6

We recently switched from SVN to Git and the transition has been painful - last week there has been at least one issue pr. day that has stopped work and that needed to be addressed. Personally, I have used Git before via github and it has worked well (tho' my usage was mostly doing small updates, no branches, no merges etc.) My current impression of Git is that it's very powerful, but too low level and not that user…

I have been using bzr with a team of 4 for some time now. Moved from ClearCase UCM and haven't looked back. :-) As most people had experience with cvs and svn the command set was easy to pick up. We just needed to put together a policy with integration branch and user specific product branches. It was a unix only install so standard unix groups/perms were used for these directory hierarchies.

Re: Advanced Git tips (slides)

#24

Post by masklinn » Sat, Oct 09, 2010, 5:14 PM UTC

ciupicri wrote: post #15

amix wrote: post #6

We recently switched from SVN to Git and the transition has been painful - last week there has been at least one issue pr. day that has stopped work and that needed to be addressed. Personally, I have used Git before via github and it has worked well (tho' my usage was mostly doing small updates, no branches, no merges etc.) My current impression of Git is that it's very powerful, but too low level and not that user…

Git and Mercurial are pretty similar, but I must say that I don't like the Mercurial branching model. It forces me to have a repository for every topic branch when I'm contributing to an open source project. You can read more about this here: [1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... [2] http://hgbook.red-bean.com/read/managing-releases-and-branch...

> It forces me to have a repository for every topic branch when I'm contributing to an open source project.

You might want to read the first link you gave, I think.

Re: Advanced Git tips (slides)

#25

Post by ciupicri » Sat, Oct 09, 2010, 5:23 PM UTC

masklinn wrote: post #24

ciupicri wrote: post #15

Earlier quoted context omitted.

Git and Mercurial are pretty similar, but I must say that I don't like the Mercurial branching model. It forces me to have a repository for every topic branch when I'm contributing to an open source project. You can read more about this here: [1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... [2] http://hgbook.red-bean.com/read/managing-releases-and-branch...

> It forces me to have a repository for every topic branch when I'm contributing to an open source project. You might want to read the first link you gave, I think.

What do you mean? I read that guide almost an year ago and decided that branching with clones is the best option for me.

Re: Advanced Git tips (slides)

#26

Post by Groxx » Sat, Oct 09, 2010, 5:40 PM UTC

ciupicri wrote: post #15

amix wrote: post #6

We recently switched from SVN to Git and the transition has been painful - last week there has been at least one issue pr. day that has stopped work and that needed to be addressed. Personally, I have used Git before via github and it has worked well (tho' my usage was mostly doing small updates, no branches, no merges etc.) My current impression of Git is that it's very powerful, but too low level and not that user…

Git and Mercurial are pretty similar, but I must say that I don't like the Mercurial branching model. It forces me to have a repository for every topic branch when I'm contributing to an open source project. You can read more about this here: [1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... [2] http://hgbook.red-bean.com/read/managing-releases-and-branch...

I can't stand Mercurial branches. They make no sense once you've tasted Git's.

Heck, Mercurial users / developers / websites as much as admit it sucks. The most-recommended way to branch that I've seen is to clone the remote, never develop on that copy (a "pristine" clone), and clone that repo to make your branches, pushing back into your pristine when you're ready to upload.

Git? Just branch and code.

Re: Advanced Git tips (slides)

#27

Post by yummyfajitas » Sat, Oct 09, 2010, 5:57 PM UTC

amix wrote: post #6

We recently switched from SVN to Git and the transition has been painful - last week there has been at least one issue pr. day that has stopped work and that needed to be addressed. Personally, I have used Git before via github and it has worked well (tho' my usage was mostly doing small updates, no branches, no merges etc.) My current impression of Git is that it's very powerful, but too low level and not that user…

There is little technical reason to choose Git over Mercurial or vice versa. Their usage is extremely similar. Git exposes a few more internals, and lets you fix mistakes more easily. For sharing branches which are incomplete, git's `rebase -i` is also somewhat superior to mercurial queues.

Overall, I've found git to be marginally better than hg.

The real killer feature that git has is that git talks to github and svn. Mercurial only talks to bitbucket (sorry guys, network effects are important and github won).

Re: Advanced Git tips (slides)

#28

Post by cdavid » Sat, Oct 09, 2010, 6:25 PM UTC

Groxx wrote: post #26

ciupicri wrote: post #15

Earlier quoted context omitted.

Git and Mercurial are pretty similar, but I must say that I don't like the Mercurial branching model. It forces me to have a repository for every topic branch when I'm contributing to an open source project. You can read more about this here: [1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... [2] http://hgbook.red-bean.com/read/managing-releases-and-branch...

I can't stand Mercurial branches. They make no sense once you've tasted Git's. Heck, Mercurial users / developers / websites as much as admit it sucks. The most-recommended way to branch that I've seen is to clone the remote, never develop on that copy (a "pristine" clone), and clone that repo to make your branches, pushing back into your pristine when you're ready to upload. Git? Just branch and code.

I concur to that. I find Hg branching model messy: there are clones, named branches, bookmarks and anonymous branches. They all have different features in term of how you can share them, etc... Also, I find comparing branches (through log, diff, etc...) a bit painful, especially because of inconsistencies between naming in hg - git naming is less user friendly, but much more consistent.

IOW, Git complexity comes from a f*cked-up UI, but hg simplicity is only superficial. Any semi-advanced usage in hg requires queues, a lot of plugins, etc... whereas git supports all that out of the box. Some simplicity in hg is also seriously broken - the "simple" version naming is a very bad idea in DVCS. Inevitably, different people will refer to the same revision (r1234) which is in fact a different revision because they are relative to different repositories.

Merging is also not that great in hg: I really miss git index when I need to resolve conflict. But I have a strong dislike for kdiff3 and that sort of tools.

Re: Advanced Git tips (slides)

#29

Post by sandGorgon » Sat, Oct 09, 2010, 6:55 PM UTC

JustAGeek wrote: post #13

amix wrote: post #6

We recently switched from SVN to Git and the transition has been painful - last week there has been at least one issue pr. day that has stopped work and that needed to be addressed. Personally, I have used Git before via github and it has worked well (tho' my usage was mostly doing small updates, no branches, no merges etc.) My current impression of Git is that it's very powerful, but too low level and not that user…

Which issues did you have exactly? I'm asking because my team members want to switch to Git after having to suffer through my praising git for long enough and I'd like to know which traps to avoid. My personal switch from SVN to Git was rather painless but that's probably because I "only" used git-svn and at first used Git pretty much like I used SVN and then step by step explored the possibilities offered by Git lik…

For me the biggest problem was ending up with a lot of heads. I guess this happens when you go back to a previous commit and in-advertently starting checking in stuff - In SVN, this is prevented.

I dont exactly remember how I handled this the last time around, but I think some rebase-fu was needed

Re: Advanced Git tips (slides)

#30

Post by tednaleid » Sat, Oct 09, 2010, 7:18 PM UTC

yummyfajitas wrote: post #27

amix wrote: post #6

We recently switched from SVN to Git and the transition has been painful - last week there has been at least one issue pr. day that has stopped work and that needed to be addressed. Personally, I have used Git before via github and it has worked well (tho' my usage was mostly doing small updates, no branches, no merges etc.) My current impression of Git is that it's very powerful, but too low level and not that user…

There is little technical reason to choose Git over Mercurial or vice versa. Their usage is extremely similar. Git exposes a few more internals, and lets you fix mistakes more easily. For sharing branches which are incomplete, git's `rebase -i` is also somewhat superior to mercurial queues. Overall, I've found git to be marginally better than hg. The real killer feature that git has is that git talks to github and sv…

Mercurial also talks with git (http://hg-git.github.com/) so you can use it with github if you want. This was actually created by Scott Chacon, the guy who wrote the subject of the OP.

I think it's worth giving both git and hg a try to see which fits your head better. Mercurial feels better to me and there are quite a few people in many communities (including most of the python community).