Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advanced Git tips (slides)

git-tips.heroku.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Advanced Git tips (slides)

#31

Post by tednaleid »

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.

? you can "just branch and code" in mercurial too. I do it all the time.

I'm not sure where you're getting your info. Sounds like you might be still thinking that the FUD from 2008 that the only way to branch in mercurial is to clone a repo is actually true.

Check out the links in the post you replied to for more info.

Re: Advanced Git tips (slides)

#32

Post by kree10 »

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…

The genius thing about git-svn is not that it only "talks" to svn: using git-svn (you could say subversively) converts your repo to git. One day, when somebody suggests dumping svn for git, you can skip the "but how do we preserve all that history if we switch" conversation, because it's already done.

Re: Advanced Git tips (slides)

#33

Post by tednaleid »

ciupicri wrote: post #25
masklinn wrote: post #24

Earlier quoted context omitted.

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

Yet you're complaining about that option and saying that it doesn't support the branching model as git. It does support it, but you rejected it.

Re: Advanced Git tips (slides)

#34

Post by Groxx »

tednaleid wrote: post #31
Groxx wrote: post #26

Earlier quoted context omitted.

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.

? you can "just branch and code" in mercurial too. I do it all the time. I'm not sure where you're getting your info. Sounds like you might be still thinking that the FUD from 2008 that the only way to branch in mercurial is to clone a repo is actually true. Check out the links in the post you replied to for more info.

With clones: article seems confused as to whether these are local clones or multiple remote repos[1]. If multiple remote repos: != branching, and horrendously wasteful. If local: almost exactly what I described, though they're making a repo for every existing branch; many other suggestions online suggest maintaining a "pristine", and it then becomes what I mentioned. And read the disadvantages section, it's pretty large. And this is one of the most-described means of branching; duplicating the repository because named branches are such a PITA.

Bookmarks: local only, no info ever reaches the server - ie, no label on a separate branch, it's just yet another anonymous branch.

Named branches: new head even when merged and closed, default push pushes all branches, so very difficult to use locally only if you have more than one remote branch (say, prod, qa, testing, dev. You now have to "hg push -b prod qa testing dev" just to prevent pushing your local branches. Or is it a separate push for each branch? I forget. And what if there were 20? 2000?). If you allow new remote heads, suddenly everyone will get tons of branches as you add more developers, name collisions / too many useful ones used up long ago (mybranch12a7c9?) - this is desirable how?

Anonymous: an artifact of any concurrent version control software, not a feature.

[1]: 2nd paragraph of: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

edit: summary: Git = friendly to multiple developers. Such as effectively every business environment. Mercurial = friendly to a single developer (in that case, yes, it's admittedly much easier), as long as you always push all branches.

Re: Advanced Git tips (slides)

#35

Post by boskone »

It is / can be surprising who on your team will have the most problems on a Git from SVN migration. Sometimes ol' CVS/SVN warhorses have too much to unlearn, sometimes simple devs who never bothered to progress beyond the minimal clicks with SVN/IDE to get code up and down discover the true Qi of source control management as they discover git's capabilities.

One nice thing about git vs. svn is when you reach enough mastery you can make that repo dance to your tune. At some point you and git are one and working together. SVN was always some kind of imposing, opposing force; one that I had to fool into doing my desire.

One clueless contractor could put your SVN repo into hell-and-gone. With git I told the team, "don't worry, go for it; unless you do something really strange, there's nothing you can do that I can't recover from."

Re: Advanced Git tips (slides)

#36

Post by JustAGeek »

bcl wrote: post #9

These slides are worthless without the talk. Instead go download his excellent book (or buy it) from http://progit.org

I agree that most of the slides would require further explanation but I still found a bunch of commands I've never heard of and actually could make use of, eg git bundle and git rerere.

So it's not totally worthless.

Re: Advanced Git tips (slides)

#38

Post by Groxx »

cdavid wrote: post #28
Groxx wrote: post #26

Earlier quoted context omitted.

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…

I sort of like that revision naming, actually. As long as nobody does that, it does simplify things at times. Though no more than bookmarks do, and they can be descriptive instead of iterative.

Re: Advanced Git tips (slides)

#39

Post by ciupicri »

tednaleid wrote: post #33
ciupicri wrote: post #25

Earlier quoted context omitted.

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

Yet you're complaining about that option and saying that it doesn't support the branching model as git. It does support it, but you rejected it.

Here's my current setup: I have 2 clones/repositories of Satchmo. [1] is for bug fixing and [2] for translations. I've asked for a better solution on the #mercurial channel and no one has offered it to me.

If you have a better idea that's similar to git[3] (1 repo), I'm waiting for it. Until then I'll complain about what Mercurial is offering me, just like Groxx and cdavid (see above).

[1] http://bitbucket.org/ciupicri/satchmo

[2] http://bitbucket.org/ciupicri/satchmo-l10n-ro

[3] http://github.com/ciupicri/cobbler/tree/master-pagination-bu...

Re: Advanced Git tips (slides)

#40

Post by e40 »

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…

What issues are you having? I converted my company over a year ago to Git from CVS. The main problem we still have are people that either refuse to spend the time to learn Git properly or quasi-technical people who just aren't capable of it. For the former group, some people are just lazy and try and take the easy way out. Or, they're stubborn and think they can get by with a little knowledge.

I've found, to a person, that once they put in the work and know how to use it, it's a rewarding and fun experience to use Git. It's not easy, though.

Post reply on HN