Re: multi-project repos (was Re: Cleaning up git user-interface warts)

[Shawn Pearce <spearce@spearce.org>]

Carl Worth <cworth@cworth.org> wrote:
> Yes, this was my exact thought when reading what Linus
> wrote. ORIG_HEAD might be fine and all, but it pales in functionality
> compared to what reflog provides.
> 
> I would very much like to see reflog getting first-class citizen
> support in git:
> 
> 1. Be on by default

I have:

	git repo-config --global core.logAllRefUpdates true

especially since Junio fixed it to only create logs for heads and
not tags.  That way its on by default for me.  But I think it should
be on by default in the next version of Git.
 
> 2. Get documented in all the right places, (much better than adding
>    documentation for ORIG_HEAD in my opinion)

Agreed.  I'm not likely to do it anytime soon however, so I'm hoping
someone else will do it...  :-)
 
> 3. Tighter integration with branch manipulations. Do we already delete
>    reflog when deleting a branch? We don't have a branch rename
>    operation, but if we get one, renaming the reflog should go
>    hand-in-hand, etc.

Yes, we delete the log when we delete the branch, and we prune
back the empty directories too just like we do on the branch side,
so that new branches can be correctly created.

There was a recent discussion about that from Junio if I recall.
Several people that I work with have asked that branch rename
support be added to Git, and that if you rename the branch the
reflog follows.  Because in their mind they are simply changing
the name of the branch, any old history of that branch should
stick around.

I tried to think of an option to "git branch" to do the rename but
kept thinking that:

	git rename-branch old new

is the better syntax...  even though that's command number 133
or something like that...

We should stick a "null" event into the reflog during a branch
rename.  Make both the old and new SHA1 the current SHA1 but drop
a message in saying "renamed branch old -> new" (for example).

--