Linus on keeping a clean git history (2009) • Hacker News Board

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

#21

Post by aidenn0 » Thu, Oct 04, 2012, 3:56 PM UTC

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,…

Let's compare git to SVN.

With SVN your only real option is to commit something that is working, right? If you commit something broken to SVN then you will likely get yelled at.

With git, you can make a few changes, then think "hmm that might not be the best way to fix it" do a commit and then rip out everything you just did and do it a different way.

Or maybe you Added some instrumentation for debugging the problem, committed, then fixed the problem, committed, then removed the instrumentation.

In both cases git has let you save off information that you might need during the bugfix process, but ultimately isn't needed in the final history. With SVN, you likely wouldn't check in those intermediate steps so the final history in SVN would be a single commit of "Fix bug foo"

Is there any need for everyone to have these intermediate commits in their history? I guess that's a matter of taste. I think the main thought is that rebases improve the signal-to-noise ratio of the changelog.

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

#22

Post by aidenn0 » Thu, Oct 04, 2012, 3:57 PM UTC

mibbitier wrote: post #20

git is so overly complex (Coming from svn).

In my experience, git is more complex than svn, but not needlessly so. In any sufficiently long-running project, I've wanted features that git has and svn doesn't.

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

#23

Post by giulianob » Thu, Oct 04, 2012, 4:04 PM UTC

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

That's why I like Mercurial a bit more. It takes a bit more work to shoot yourself in the foot from what I've noticed. They recently added the concept of "phases" so something is in draft state until you push to an external repo. At that point, the phase will change to public and it wont let you rebase it w/o doing a force command. You can also mark a branch as private and it wont accidentally get pushed out which is useful if you are doing some local prototyping.

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

#24

Post by easy_rider » Thu, Oct 04, 2012, 4:16 PM UTC

Funny. I was just finishing a chat with a colleague about a git strategy for a coming new release of a production product, then saw this post on top. I've been working on it without collaboration for about half a year now, so thats easy.. I've had mixed experience with both rebasing and pull strategies before that. I've found rebasing being a lot better when working with tightly coupled code. And pull being a lot cleaner in being able to cherry-pick and revert to previous states more easily. rebase is indeed a destroyer.

We've now decided to use this model, while only deleting feature branches after RC acceptance.

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

My colleague just suggested to rebase regularly from the develop branch while developing features "I'm working on a branch. someone - e.g. you - updates the develop branch. I will have no info if that is related to my stuff or not so, I should rebase regularly to the latest version of the develop branch"

I'm kinda clueless now. Git is really powerful and flexible in strageties, and that adds to complexity.

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

#25

Post by fghh45sdfhr3 » Thu, Oct 04, 2012, 4:28 PM UTC

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

It's an immensely capable tool, but it gives no guidance regarding the right way to do things.

There is no right way. Think about styling. Is there a right style? No. It is silly to argue over your code's appearance. HOWEVER! As soon as you start collaborating with people and reviewing code, a uniform style is a very nice thing to have.

Teamwork creates the need for shared conventions. And that's where your ability to convince your team members of the value of some standardizations comes into play.

different projects on my company use different practices...

It sounds like your problem is not Git, but lack of organization. I am not sure a more restrictive scm would fix that. You need to find a good way to use Git, and then sell everyone on the benefits of process uniformity.

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

#26

Post by mibbitier » Thu, Oct 04, 2012, 4:31 PM UTC

aidenn0 wrote: post #22

mibbitier wrote: post #20

git is so overly complex (Coming from svn).

In my experience, git is more complex than svn, but not needlessly so. In any sufficiently long-running project, I've wanted features that git has and svn doesn't.

As a relative newbie to git,

Why do I get prompted to enter a commit message when I'm just doing a git pull?

Why do I have to explicitly add every file I want to commit each time? Why can't it just default to "everything under the current dir" like svn does?

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

#27

Post by easy_rider » Thu, Oct 04, 2012, 4:33 PM UTC

mibbitier wrote: post #20

git is so overly complex (Coming from svn).

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

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

#28

Post by Jacquass12321 » Thu, Oct 04, 2012, 4:34 PM UTC

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.

Secondly there's the cleaning part of history involving squashing. I believe the issue with your viewing the merge history of the main line will miss out on changes that were able to be introduced fastforward without a merge. And frankly no one else on the team cares that I committed 6 times in the process of one task, they want to see all the code relevant to that task, and ideally it's all in one change set.

There's a pretty reasonable summary over here http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/

For certain teams rebase just makes a lot of sense.

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

#29

Post by dfc » Thu, Oct 04, 2012, 4:35 PM UTC

EternalLight wrote: post #16

qznc wrote: post #10

Earlier quoted context omitted.

Linus is the single gatekeeper of Linux.

No, he isn't. He's the final gatekeeper but there are several of lower level gatekeepers/maintainers for different parts. At least according to rumors, I've never invested the time to get involved myself.

There are an awful lot of maintainers for smaller individual pieces/subsytems of the kernel. Take a look at the MAINTAINERS file to see who is responsible for the smaller chunks:

  grep -B1 ^M: /usr/src/linux-kernel/MAINTAINERS

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

#30

Post by pm215 » Thu, Oct 04, 2012, 4:36 PM UTC

mibbitier wrote: post #20

git is so overly complex (Coming from svn).

I think that for people with an svn background there are three different issues that all hit at once:

* distributed rather than centralised version control brings a new set of concepts to understand

* git is flexible enough to support many different workflows. This means you have to actually choose one, and choice is difficult especially when you're just trying to get to grips with a new tool. svn has much more of a "one standard way to do it" approach

* git's UI is in places confusing, inconsistent and occasionally just randomly and unnecessarily different from most other version control systems

The first two are 'essential complexity'; the third is more 'accidental complexity'. In any case I feel it's having to deal with all three sources of confusion that makes the svn->git transition tricky for many people.