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

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

#51

Post by smithzvk » Thu, Oct 04, 2012, 5:31 PM UTC

wickedchicken wrote: post #44

smithzvk wrote: post #34

So I'm relatively new to version control entirely, but in the last few years my group has been making a big push to institute Git. I have been wondering lately, however: how much history cleaning is expected/desirable? When I develop, I split my commits into as many small changes as I can so that the commit messages are single topic. I thought that was basically the idea. Every once in a while I use rebase to combine…

> However, I could use rebase to start combining loosely related commits, trading the time resolution for clarity in the commit history. In general, your commits should be the smallest atomic operation that makes sense. When people talk about 'clean history,' they're talking about working in the awesome workflow git provides: 1. Write half-written broken code. 2. Fix that code up. 3. Add some more onto that. 4. Fix a…

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 described if the commits are mixed and I would like the end result to involve grouping via branches. That is confusing, hopefully this will clear it up:

1. Bugfix in function1. 2. Bugfix in function2. 3. New feature in function2. 4. Bugfix in function1. 5. Bugfix in function2

...and we want in the end:

      /-- 1 ---- 4 ---\
  -----HEAD
      \- 2 -- 3 -- 5 -/

Can rebase do this easily? Is this a good idea (it seems like it is to me)? The programmer would have to confirm that the code works at every state.

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

#52

Post by stephen » Thu, Oct 04, 2012, 5:35 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-…

You can enforce workflow via post-commit hooks if you get a bit creative, e.g.:

https://github.com/stephenh/git-central/blob/master/server/u...

Unfortunately I haven't done a lot with this project in a few years since github doesn't allow bash post commit hooks; you'd have to run your own git server.

(Edit to add...)

So, I understand your impression that it's impossible to enforce workflow in git, given GitHub doesn't support it, and most users probably don't want to write complex post-commit scripts.

But it is actually possible.

It'd be nice if communities like git-flow/etc. codified their rules into post-commit hooks that you could install, and maybe GitHub could even vet (e.g. that the bash scripts won't nuke their servers), and provide as out-of-the-box/opt-in options in the admin section of their repos. E.g. "Enforce git-flow in my repo".

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

#53

Post by mibbitier » Thu, Oct 04, 2012, 5:36 PM UTC

pm215 wrote: post #30

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…

Don't most people actually end up using git in a centralised manner though? eg the rise of github.

I can totally see git is ridiculously powerful, and general purpose. I just wish it'd default to what most people want a bit more.

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

#54

Post by mcgwiz » Thu, Oct 04, 2012, 6: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-…

> The worst thing is that there's no way of enforcing these workflows or practices other than out-of-band social conventions.

False. It's called the Dictator and Lieutenants workflow. It's costly, but if you're in a position where you don't trust your own developers or your conventions are severe, then it's a price you have to pay.

If you can't afford it, hire trustworthy developers or dial back your conventions.

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

#55

Post by mcgwiz » Thu, Oct 04, 2012, 6:08 PM UTC

LnxPrgr3 wrote: post #6

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

On a repo I've been maintaining, I'm horribly tempted to revoke almost everyone's commit access, for two reasons: to add a code review step to the process, and to be able to keep the commit history reasonably clean. It's low-tech, but a human gatekeeper's really your only hope for enforcing whatever conventions your project has.

No it's not your only hope. Your other hopes are:

- hiring developers that appreciate and obey the conventions, or

- reducing the weight of the conventions.

Simply put, if you have conventions that the developers aren't following, you're organization is dysfunctional in some way. Management should include the team when crafting the conventions, and management should take efforts to give the team time/resources to obey them.

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

#56

Post by krzyk » Thu, Oct 04, 2012, 6:11 PM UTC

aidenn0 wrote: post #21

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

Does using rebase or squash leave the history in my local repo and "squash" the commits to a single one in the master?

Sorry for basic questions but I'm new to git.

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

#57

Post by JonnieCache » Thu, Oct 04, 2012, 6:52 PM UTC

lukev wrote: post #14

ajross wrote: post #13

Earlier quoted context omitted.

I'm not sure exactly what you think a better tool would look like. By your own admission, there are multiple "right" ways to do branch management, and all of them are supported meaningfully by git. But, more or less by definition, a tool that enforced a "right" way to do things would disallow some of these. So... I don't understand. Do you want a tool that makes the kernel branching style illegal, or one that breaks…

It isn't hard to imagine a SCM tool (using GIT internally) that enforces a specific set of curated operations for a particular workflow, that teams could agree to use for a given project. You could have different such tools for different workflows on different projects. You could even write a meta-tool that allows administrators to define and reify a workflow which would then be enforced for developers on a project.

http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flo...

https://github.com/nvie/gitflow

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

#58

Post by dkarl » Thu, Oct 04, 2012, 7:06 PM UTC

exDM69 wrote: post #5

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. Maybe there isn't a "right way". A workflow that suits a simple desktop application is different from what is used by a kernel or another product that has dozens of targets to worry about. Similarly a web app that gets deployed in a controlled environment will most likely need a different way of working than an end-user a…

> 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 culture around your product is probably very different from the kernel devs' culture so it makes sense for you to have a different model.
> The worst thing is that there's no way of enforcing these workflows or practices other than out-of-band social conventions. And so minor mistakes happen, all the time. Our Git projects are never as pretty as they should be.

Enforcing certain kinds of work flow would mean not allowing something that is currently possible. Crippling one workflow to standardize on another, while there is no clear evidence that one workflow would be the best for everyone.

I agree 100%. Tools that attempt to defined culture are an enormous pain and often unusable outside the context understood by their creators. Tools that help you reinforce the culture you decide on for your project are wonderful, but they are rarely as un-opinionated as they need to be.

One thing that strikes me about source control culture is that in centralized environments people are very aggressive about installing pre-commit hooks to enforce rules, but I rarely see people using hooks for git, or even including hooks in their project as a suggestion for other developers to use. I wonder why not?

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

#59

Post by mibbitier » Thu, Oct 04, 2012, 7:15 PM UTC

easy_rider wrote: post #27

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.

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.

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

#60

Post by Karunamon » Thu, Oct 04, 2012, 7:35 PM UTC

saraid216 wrote: post #36

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

> But I'd prefer to keep that history, but rarely use or display it. So why have it? > I'm still new-ish to git and don't get why rebase is popular. My most common use case for rebase is actually to keep my private branches up to date with master. `git rebase master` or `git fetch origin && git rebase origin/master` are common tools for me when I'm doing private work for an extended period of time. This way, I don't…

Because rarely != never?