Re: [PATCH] GIT commit statistics.

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Nov 12, 2005, 12:19 UTC
Message-ID: <46a038f90511120419v70166c60t93d58b7544e03e3b@mail.gmail.com>
In-Reply-To: <7v7jbeia3v.fsf_-_@assigned-by-dhcp.cox.net>

On 11/12/05, Junio C Hamano <junkio@cox.net> wrote:

Show 9 quoted lines

> Ryan Anderson <ryan@michonline.com> writes:
>
> > Junio C Hamano wrote:
> >
> >> Just for fun, I randomly picked two heads/master commits from
> >> linux-2.6 repository ... and fed the commits
> >> between the two to a little script that looks at commits and
> >> tries to stat what they did (the script ignores renames so they
> >> appear as deletes and adds).

Related to this, I've been wondering whether it'd be possible to teach git to rebase local patches, even if that means rewriting local history. When you are dealing with team shared repo, the sequences of pull/push end up being quite messy, full of little meaningless merges. Similarly, when dealing with an upstream, my tree gets slowly out of sync and slightly messy. Eventually I get a new checkout, and rebase any pending patches with git-format-patch and git-am.

The same process would be much easier if I could just cg-update from the repo and get it to try and actually rebase my local commits -- rewriting history as if I had committed them after the update. Of course, it'd be cheating... but we cheat all the time anyway, we only sweat harder at it ;-)

cheers,

martin