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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html