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

Linus on keeping a clean git history (2009)

mail-archive.com

Post reply on HN
Print view View original

71–80 of 86 posts

Re: Linus on keeping a clean git history (2009)

#71

Post by jebblue »

I have tried to get git, some people say one project per repo (which seems crazy but I did it), many projects are ok, you do need a main master repo, you don't need one, then there's the half dozen commands where with SVN it's one.

Now the most valuable thing to me in source control, history, I'm supposed to keep clean? That's like a sacred cow, you _don't_ mess with history.

>> That's fairly straightforward, no?

No _Linus_ it isn't. Git is hard to get right. If it wasn't for EGit I'd be lost. I tried Canonical's bzr and it is more understandable for ordinary humans.

All that aside I really like Linux. :)

Re: Linus on keeping a clean git history (2009)

#72

Post by smithzvk »

lmm wrote: post #66
smithzvk wrote: post #51

Earlier quoted context omitted.

Okay, that is basically keeping with my current understanding (though I'm not sure how much I live up to the "only have working history in the public repo" rule). There is the other issue I raised, however: is there a good way to group a series of commits that happen to be towards a single distinct goal. Using branches is a clear step in that direction, but it seems like a nightmare to perform a rebase like you descr…

Switching branches is cheap, I'd say the "right" way to get a tree like you want is to have two or even five branches all the time you're working. But I suspect you could make two branches and cherry-pick different sets of commits onto them to get the result you're after. To my mind it wouldn't be worth the effort though; how often do you really care whether the code worked with only 1 and 4 applied?

Right, I would say that it isn't worth the effort. Also, I probably never care about the code with only 1 and 4 applied. So perhaps branches aren't the right way to do what I am describing.

I always saw VC as a systematic way to keep a log of my development so that I could figure out where I may have broken my code. For this purpose, having some sort of meta-data where commits can be grouped would be nice. It would also work to do something like always end my commit messages with some kind of meta-data tag that I could grep the log for. I was just wondering if there was a prescribed/built-in way for Git to handle this.

Re: Linus on keeping a clean git history (2009)

#73

Post by guelo »

misiti3780 wrote: post #33
lukev wrote: post #3

This highlights the only thing I don't like about Git. It's an immensely capable tool, but it gives no guidance regarding the right way to do things. Our own teams have a set of practices which are similar but different from what Linus outlines here. And different projects on my company use different practices from those. The worst thing is that there's no way of enforcing these workflows or practices other than out-…

http://nvie.com/posts/a-successful-git-branching-model/

And the accompanying tools for it: https://github.com/nvie/gitflow

Re: Linus on keeping a clean git history (2009)

#74

Post by jrochkind1 »

oh yeah, perfectly straightforward, only took several thousand words to confusingly explain.

Nope, not simple. Yep, this is a git usability problem.

In the ruby/github world, people generally violate this and DO rewrite 'public' history in order to get 'cleanness', primarily because almost ALL history is 'public', since you tend to show people work in progress on github, or just push it there to have a reliable copy in the cloud. And yes, this sometimes leads to madness.

Re: Linus on keeping a clean git history (2009)

#75

Post by jrochkind1 »

qznc wrote: post #10
mattdeboard wrote: post #8

Earlier quoted context omitted.

Based on what I've seen from popular open-source Python projects I've used in the past (Fabric, Haystack and basically anything else by daniel lindsley) having a single human gatekeeper is the express lane to hell. If you do that make sure you have at least a few core contribs who can approve commits.

Linus is the single gatekeeper of Linux.

I've never even looked at any linux source code, but I still know there's too much of it to believe Linus reviews and signs off on every single commit personally.

Re: Linus on keeping a clean git history (2009)

#76

Post by jrochkind1 »

DigitalJack wrote: post #67
wickedchicken wrote: post #35

Earlier quoted context omitted.

This is great for people who are that organized. I'm not, so I like the 'just merge everything into master' mentality. See http://scottchacon.com/2011/08/31/github-flow.html

My main issue with the described github-flow is that they push development branches to the server, and encourage that to be done very often. And my issue with that is once you push something, it's off-limits to any kind of archaeology in the history. And that's not a "principle" thing. If you push your branch, do some rebasing and push again, you are in a world of hurt. The operation will very likely fail, and recove…

And yet if you _don't_ push it to the server, then nobody else can see it. And don't you want other people to see develop branches to give feedback and even to collaborate on writing?

In practice, what everyone does is they DO rewrite history on those pushed dev branches, and they TRY to avoid the world of hurt by some convention for keeping track of what branches are 'development branches', and knowing that their history can change, and thus not _pulling_ from these branches into anything except a branch that does nothing but track the dev branch. And then using 'rebase' in just the right way on your local copy of that dev branch, when you need to. And then winding up in that world of hurt when something goes wrong.

Contrary to all the git apologists in this thread, i think it is one of the biggest usability problems with git. I'm not familiar enough with the other dcvs to know if they manage to do this better. I do know for all that, branching/merging is still a hell of a lot better than it was with svn.

What I myself tend to do is avoid ever rewriting history, sacrificing 'cleanness' for reliability and safety. Except when I'm working on a dev branch for an open source project where they insist upon it, and then I worry, and mess up a lot, and spend lots of time recovering from my mistakes.

Re: Linus on keeping a clean git history (2009)

#77

Post by jrochkind1 »

Jacquass12321 wrote: post #28
silverlake wrote: post #17

I'm still new-ish to git and don't get why rebase is popular. If I do my work on a branch B, I can merge this branch into the master M. The merge point will have a succinct message "Bug Fix #1". You can print the history so it only shows these merge messages and not the messy history in the branches. Isn't this the same as rebase? That is, rebase removes the messy branch history. But I'd prefer to keep that history,…

There are two major things I really gain out of rebasing frequently. Firstly and most importantly, Thanks to rebase I'm constantly working against the most recent mainline, merge pains are reduced by frequently dealing with smaller rebase merges instead of trying to do one massive merge at the end when I'm finished with a longer life task that might last a week or two. The more often you merge the less painful it is.…

> merge pains are reduced by frequently dealing with smaller rebase merges instead of trying to do one massive merge at the end when I'm finished with a longer life task that might last a week or two. The more often you merge the less painful it is.

You can take care of that just by doing frequent regular merges, no need to do rebase ever, and rebase doesn't make this part any easier, does it?

I think the 'cleaning part of history', and trying to avoid those annoying merge commits in the logs, is in fact the only reason to do rebases, no? It's obviously an important one to many people.

Re: Linus on keeping a clean git history (2009)

#78

Post by qu4z-2 »

mibbitier wrote: post #59
easy_rider wrote: post #27

Earlier quoted context omitted.

svn always seemed limited to me if your dev team grows beyond the capability of utilizing simple verbal communication to mitigate problems when merging.

Personally, I've never been a fan of branching and merging. I don't think it works well at all for small groups. Maybe if you're in a big corp. though.

What do you do if you want to commit a half-finished feature? Do you only commit in very large-grained chunks?

Re: Linus on keeping a clean git history (2009)

#79

Post by chris_wot »

Unintentional contradiction two messages down the thread: Linus says "But note: none of these rules should be absolutely black-and-white. Nothing in life ever is."

Or perhaps intentional. I can never tell when I read a Linus fiat.

http://www.mail-archive.com/dri-devel@lists.sourceforge.net/...

Post reply on HN