Re: [PATCH] GIT commit statistics.

Martin Langhoff <martin.langhoff@gmail.com> writes:

The key is not to let your tree go "slowly" out of sync, from my experience. When Linus was the maintainer, I used to do the equivalent of the following all the time to keep up with his tree while keeping my history clean [*1*].

Frequently [*2*], I tried to see if Linus made something new and interesting. My "origin" branch was always copy of Linus head.

	$ git fetch origin

The command would say "Fast forward".  So what did he do?

	$ git show-branch master origin
        ! [origin] Separate LDFLAGS and CFLAGS.
         * [master] Rename lost+found to lost-found.
        --
         + [master] Rename lost+found to lost-found.
         + [master^] Fix compilation warnings in pack-redundant.c
         + [master~2] Debian: build-depend on libexpat-dev.
        +  [origin] Separate LDFLAGS and CFLAGS.
        ++ [master~3] Split gitk into seperate RPM package

Ah, the commit master~3 was what he had the last time I pulled from him, and since then he made a commit while I did three. I could do "git pull . origin" at this point, but that would result in a useless mini-merge. My tree is not public so I can freely rebase to clean things up.

	$ git rebase origin
	$ git show-branch
        ! [origin] Separate LDFLAGS and CFLAGS.
         * [master] Rename lost+found to lost-found.
        --
         + [master] Rename lost+found to lost-found.
         + [master^] Fix compilation warnings in pack-redundant.c
         + [master~2] Debian: build-depend on libexpat-dev.
        ++ [origin] Separate LDFLAGS and CFLAGS.

Now I am fast-forward, so I could ask him to pull from me [*3*].

I think each of your developers can do the same, treating the "project shared repository" as "Linus repository" and pull that into the "origin" branch, and when the "master" is ready, push it back into the shared repository (which is equivalent of Linus pulling everything from me while doing nothing else in his repository).

For a sizable change that deserves a topic branch with a long sequence of commits, rebasing is not always the optimum solution; and you may want to keep the full merge history of such a branch pushed into the public repository as is. But for simpler cases that 'git rebase' can handle easily without conflicts, the above procedure would help you keeping the history of your shared repository less cluttered.

[Footnotes]

*1* Back then we did not have multi-head fetch, show-branch nor rebase, so I did these using a homebrew Porcelain.

*2* Unlike CVS which always mucks with the working tree, 'git fetch' into a branch that is not current one is an operation and can be done even when I am in the middle of a heavy hackery. Being able to peek into what others are up even when your tree is in a messy state (the fetch is often followed by log and diff) helps you to avoid doing duplicated work or going in a wrong direction, which was great.

*3* Even back then almost all changes were fed via e-mail to the maintainer.