Junio C Hamano wrote:
quoted text > 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*].
>
> ----------------------------------------------------------------
quoted text > * 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).
quoted text > * 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.
quoted text > * 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).
quoted text > * 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.
quoted text > * 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.
quoted text > * 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.
quoted text > [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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
