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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Wed, 6 Dec 2006, Junio C Hamano wrote:

> Here is a list of topics that are cooking; the commits marked
> with '+' are in 'next', '-' are in 'pu'.  Dates are when the
> topic was last touched [*1*].

I like the combined pu/next "What's new".

> * ap/clone-origin (Wed Dec 6 12:07:23 2006 +0000)
> [...]
>  I think it is sensible to merge to 'master' after that change.

Me, too. I really would like this to go in.

> * jc/3way (Wed Nov 29 18:53:13 2006 -0800)
>  + git-merge: preserve and merge local changes when doing fast forward
> [...]
>  It has been in next for some time and unless we hear somebody scream I 
>  think it is Ok to merge to 'master'.

This is something I am looking forward to to test. Maybe in "next" for 
while before putting it into "master"?

> * jc/explain (Mon Dec 4 19:35:04 2006 -0800)
>  - git-explain

I vote for putting this into "next" for a wider audience. It also would 
help people to submit patches (it is kind of a hassle to branch "pu", so I 
rarely do it myself, whereas my git is based on "next" at all times).

> * js/merge (Wed Dec 6 16:45:42 2006 +0100)
>
>  merge-recursive that does not rely on RCS "merge".  I use this
>  exclusively these days.  Perhaps cook a little further and
>  merge to 'master'.

Yes, definitely cook it for at least a week; maybe I find the time to 
check the conflicted merges in git.git at least.

> * js/shallow (Fri Nov 24 16:00:13 2006 +0100)
> 
>  Probably with a better documentation of its limitations and caveats, 
>  this should be mergeable to 'master'.

The more I see the missing reaction, the less sure I am this is a sensible 
thing to do.

And it would need more safety valves, not just documentation. For example, 
I am not sure if a push from/to a shalow repo is safe.

Ciao,
Dscho