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

31–40 of 86 posts

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

#31

Post by magoon »

mibbitier wrote: post #26
aidenn0 wrote: post #22

Earlier quoted context omitted.

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?

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

This shouldn't happen; you need to rethink how you're set up.

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

You can use git commit -a

Edit: by "rethink" I mean research why this is happening, because it isn't by design. I'm sure somebody can help, I just don't have the answer for you.

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

#32

Post by dfc »

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 would be handy if there was a option to git-rebase that would print a warning if you were about to rebase a commit by someone other than $(git config user.email)

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

#33

Post by misiti3780 »

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/

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

#34

Post by smithzvk »

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 a few commits that should have been done together as they all addressed the same issue. This all seems right to me. I am left with a clean history of everything I have done on a very fine grained time scale. But the large number of commits, each with little significance to whole program hides the large scale structure of the development.

However, I could use rebase to start combining loosely related commits, trading the time resolution for clarity in the commit history. There seems to be a continuum along this scale. Where is the proper place in that continuum to say this is clean enough? Also, I don't like making changes where I am losing perfectly good information.

I know that I can group certain commits by defining a branch, developing on it, then merging (non-fast-forward) back to the original. The branch should keep the grouping in the commit history. I even suppose that this is can be done after the fact using rebase with the proper amount of git-fu. Is branching and non-fast-forward merges the preferred method of grouping related commits in the history?

If so, this seems troubling as it means that partially fixing something is difficult to do with a clean history. Until the piece of the program you wish to fix is completely working, it shouldn't be merged into master because it would ruin the grouping of the related commits. This means that there can't be any partial thought's like fixing bugs as you find them, because presumably you might want to group all bug fixes of a function together, but have a distinct commit for each.

Now I'm more confused than when I started. Seriously, any references or advice on this sort of topic are welcome.

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

#35

Post by wickedchicken »

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/

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

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

#36

Post by saraid216 »

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 have a point where my private branch diverges from master; my changes are always fresh and based off the latest and greatest.

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

#38

Post by saraid216 »

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.

You might want to look into writing hooks, perhaps? The company I work at has some simple hooks that require you to have a line stating who code reviewed your commit. Sure, it can be bypassed, but there's social pressure not to do so.

I've written my own hooks to do some automated testing on my changes, too. (I've got one that checks for trailing commas in my Javascript files, for instance.)

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

#39

Post by sanderjd »

ajross wrote: post #18
lukev wrote: post #14

Earlier quoted context omitted.

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…

I think it's a balance. There is value in having people working on a given project aligned on the same basic workflow. To achieve that for a team that is currently growing or is planning to grow, you have to document what that basic workflow should look like. That "document" can be a set of social mores that are loosely enforced through complaint and argument, or an actual document somewhere, or a tool like your parent is suggesting.

Such a tool, which makes the preferred workflow very easy and excursions outside it achievable but somewhat more difficult seems like a pretty good idea to me, and not at all as stuffy and prohibitive as you seem to fear.

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

#40

Post by saraid216 »

dfc wrote: post #32
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 would be handy if there was a option to git-rebase that would print a warning if you were about to rebase a commit by someone other than $(git config user.email)

I'd suggest writing a git hook on pre-rebase.
Post reply on HN