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

11–20 of 86 posts

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

#11

Post by exDM69 »

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.

It makes a lot of sense to require that a commit must go through at least 1-2 human reviewers before getting merged to master. In addition to going through automated builds and tests, if applicable.

You need more than one person who can commit to master and is responsible for the merges, but you most certainly don't need every contributor to have commit access.

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

#12

Post by qznc »

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

Just read the two followup posts. It is not that clear within Linux as well.

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

#13

Post by ajross »

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

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 your own team's workflow? If you want one that supports both, how is that providing clarity about the "right" way to do things?

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

#14

Post by lukev »

ajross wrote: post #13
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-…

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.

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

#16

Post by EternalLight »

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.

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.

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

#17

Post by silverlake »

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 rarely use or display it. bisect can also ignore those branches and only use the merge points. Saving the branch history shouldn't be problem. What am I missing?

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

#18

Post by ajross »

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.

Isn't that what all large projects are doing internally? Hell, big chunks of the git chrome (things like "git am", "git request-pull", "git send-email") is precisely an attempt to write scripts to automate core parts of the kernel workflow. Github added bits of its own, like "watching" a public repository and providing a core spot for pull requests to land, with discussion and review tools. I don't understand why you're so interested in "enforcement" when projects using these tools seem to be doing just fine.

What you're saying sounds to me a lot like the stuff we heard from Java nerds in the 90's (who certainly didn't invent it, Pascal and PL/1 nuts said much of the same stuff) -- the programming environment should be designed to force the user into a particular style. Our community has, for the most part, rejected that view in favor of dynamic systems with more flexibility. Why should SCM branch management be any different?

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

#19

Post by adestefan »

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

Linus doesn't want all of your personal history. So he's okay with you rebasing your 15 commits that fixed bug X into one "fix for bug X," but never should anyone rebase someone else's history.
Post reply on HN