Re: What's cooking in git.git (topics)

[Jakub Narebski <jnareb@gmail.com>]

Junio C Hamano wrote:

> Things that I feel should be done need to be done to complete
> v1.5.0 are:
[...]
>  - now reflog is enabled by default for user repositories, I
>    have two worries about its effect, fortunately can be killed
>    with a single stone.
> 
>    * the reflog grows unbounded;
> 
>    * revisions recorded in the reflog can be pruned out,
>      rendering some entries in reflog useless.
> 
>    I am thinking about teaching fsck-objects and prune to keep
>    revisions recorded in the reflog; we would need an end-user
>    way to prune older reflog entries and I would appreciate
>    somebody codes it up, but even without it, people can always
>    use "vi" or "ed" on reflog files ;-).

I'd rather not have prune keep revisions recorded in reflog. Reflog
keeps also amended commits, and blobs from incrementally staged
commits. Or perhaps make it an configuration option, default to
true for new users (or have an option to git-prune to ignore reflog).

As of "reflog grows unbounded"... perhaps we should encourage to use
logrotate for that (well, perhaps git-prune and porcelains which deal
with reflog should be able to uncompress reflog if needed).

>  - 'git-svn' users should speak out about two issues:
> 
>    * use of svn command line client as the backend is being
>      removed;
> 
>    * 'git-svn commit' command is being renamed to avoid
>      confusion, and potentially 'dcommit' will be renamed to 
>      'commit'.
> 
>    Please discuss these with Eric.

What about remote.<repo>.url = svn://ser.ver/repo/ idea?
 
> ** jc/reflog (Thu Dec 14 15:58:56 2006 -0800) 1 commit
>  - Teach show-branch how to show ref-log data.
> 
> A strawman to make reflog data a bit more browsable; it would be
> useful while recovering from a mistake you made recently.  Not
> essential and can wait or be dropped if people do not find it
> useful.

Looks useful.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git