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

[Jakub Narebski <jnareb@gmail.com>]

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*].
> 
> ----------------------------------------------------------------

> * jc/3way (Wed Nov 29 18:53:13 2006 -0800)
>  + git-merge: preserve and merge local changes when doing fast forward
> 
>  This allows you to run a 'git merge' (or 'git pull') that
>  results in a fast-forward merge that updates a path your
>  working tree has modified locally; it merges your local changes
>  into the updated version, in the same way the branch switching
>  'git checkout -m' works.  It has been in next for some time and
>  unless we hear somebody scream I think it is Ok to merge to
>  'master'.

Very nice. Less suprises for CVS users (with "update then commit"
mentality/habits).
  
> * jc/explain (Mon Dec 4 19:35:04 2006 -0800)
>  - git-explain
> 
>  This was just a discussion starter.  I tried to reuse existing
>  status markers various existing command leaves, but it might be
>  a good idea to invent a unified status marker to help 'git
>  explain' (or 'git wtf') command, so that everybody can write
>  into the same file and 'explain' has to know only about that
>  file.  I dunno.

I think it would be nice to have... but as it is very fresh
it probably should cook for a while in next.
 
> * jc/leftright (Sun Oct 22 17:32:47 2006 -0700)
>  - rev-list --left-right.
> 
>  When reviewing "git log --merge" I often wish which side each
>  of the commits comes from, and this is to achieve that.  I
>  haven't met with an enthusiastic support for it, though.
>  Perhaps people do not find need for that, or do not do
>  complicated merges, or have other tools that I do not regularly
>  use that is better than this approach; in which case I should
>  probably drop this.

Looks nice, as an alternative to git-cherry-pick (which sometimes
doesn't do - because it cannot - it's work).
 
> * jc/web (Wed Nov 8 14:54:09 2006 -0800)
>  - gitweb: steal loadavg throttle from kernel.org

Is having loadavg in gitweb, and not configured in server good idea?
What next, log generation in gitweb? Just kidding.
 
> * js/merge (Wed Dec 6 16:45:42 2006 +0100)
>  + merge-file: support -p and -q; fix compile warnings
>  + Add builtin merge-file, a minimal replacement for RCS merge
>  + xdl_merge(): fix and simplify conflict handling
>  + xdl_merge(): fix thinko
>  + xdl_merge(): fix an off-by-one bug
>  + merge-recursive: use xdl_merge().
>  + xmerge: make return value from xdl_merge() more usable.
>  + xdiff: add xdl_merge()
> 
>  merge-recursive that does not rely on RCS "merge".  I use this
>  exclusively these days.  Perhaps cook a little further and
>  merge to 'master'.

Very nice, especially with zealous (tight) merge conflicts.

> * lh/branch-rename (Thu Nov 30 03:16:56 2006 +0100)
>  + git-branch: let caller specify logmsg
>  + rename_ref: use lstat(2) when testing for symlink
>  + git-branch: add options and tests for branch renaming
> 
>  I do not rename branches myself and do not see a need for this
>  nor I have tested it in real-world setting.  The code seemed
>  clean and may be 'master' material.

I'd like to have this, but it MUST work well with reflogs for me.
 
> [Footnote]
> 
> *1* I am trying out an alternative to short-log.  I think the
> above format is easier to see what is going on than separate
> short-log for 'next' and 'pu'.  It is based on the "TO" script
> found in 'todo' branch but hand edited.

It looks and reads better. I usually read only description,
as shortlog is not that useful unless you are interested in
given topic. At least for me.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git