What's in git.git

I've merged up a lot for people to have fun over the weekend ;-).

The most notable core-ish change is that rev-list split and new git-log implementation by Linus. I've been using this myself for a while without problems, but there might still be some corner cases that I (and Linus perhaps) do not exercise where git-log command behaves slightly differently. rev-list is not supposed to have *any* regression other than removal of --merge-order. Please report regressions.

A new killer application is git-cvsserver. It now talks pserver protocol for anonymous CVS access. Helping Martin to audit the code for any issues, security or otherwise, is greatly appreciated.

Fredrik's git-blame still has -Wdeclaration-after-statement issues, but deserves to be beaten harder alongside Ryan's git-annotate for two reasons. It should be a good example program to use the new revision traversal infrastructure, and it is always good to have competing two implementations ;-).

* The 'master' branch has these since the last announcement.

 - Cygwin portability for test (Alex Riesen)
   workaround fat/ntfs deficiencies for t3600-rm.sh (git-rm)

 - Emacs interface (Alexandre Julliard)
   contrib/emacs: Add an Emacs VC backend.
   git.el: Added customize support for all parameters.
   git.el: Added support for Signed-off-by.
   git.el: Automatically update .gitignore status.
   git.el: Portability fixes for XEmacs and Emacs CVS.
   git.el: Set default directory before running the status mode setup hooks.

 - gitview updates (Aneesh Kumar K.V)
   gitview: Use horizontal scroll bar in the tree view
   gitview: pass the missing argument _show_clicked_cb.

 - git-svn updates (Eric Wong)
   contrib/git-svn: add --id/-i=$GIT_SVN_ID command-line switch
   contrib/git-svn: add -b/--branch switch for branch detection
   contrib/git-svn: allow --authors-file to be specified
   contrib/git-svn: avoid re-reading the repository uuid, it never changes
   contrib/git-svn: better documenting of CLI switches
   contrib/git-svn: cleanup option parsing
   contrib/git-svn: create a more recent master if one does not exist
   contrib/git-svn: fix a copied-tree bug in an overzealous assertion
   contrib/git-svn: several small bug fixes and changes
   contrib/git-svn: strip 'git-svn-id:' when commiting to SVN
   contrib/git-svn: use refs/remotes/git-svn instead of git-svn-HEAD
   git-branch: add -r switch to list refs/remotes/*

 - send-email fix (Eric Wong)
   send-email: accept --no-signed-off-by-cc as the documentation states

 - checkout-index --stdin (Shawn Pearce)
   Teach git-checkout-index to read filenames from stdin.

 - git-blame (Fredrik Kuivinen)
   Add git-blame, a tool for assigning blame.
   git-blame, take 2

 - git-mv updates (Josef Weidendorfer)
   git-mv: Allow -h without repo & fix error message
   git-mv: fixes for path handling
   git-mv: fix moves into a subdir from outside

 - split rev-list implementation and git-log (Linus and me)
   First cut at libifying revlist generation
   Splitting rev-list into revisions lib, end of beginning.
   git-rev-list libification: rev-list walking
   Introduce trivial new pager.c helper infrastructure
   Tie it all together: "git log"
   Rip out merge-order and make "git log <paths>..." work again.
   rev-list split: minimum fixup.
   git-log (internal): add approxidate.
   git-log (internal): more options.
   setup_revisions(): handle -n<n> and -<n> internally.

 - git-verify-tag update (me)
   Pretty-print tagger dates.

 - git-commit --amend (me) 

 - show-branch --topics (me)

 - git-svnimport update (Karl  Hasselström)
   Save username -> Full Name <email@addr.es> map file

 - git tool survey documentation (Marco Costalba)
   Add a Documentation/git-tools.txt

 - git-cvsserver updates (Martin Langhoff)
   cvsserver: Checkout correctly on Eclipse
   annotate: fix -S parameter to take a string
   cvsserver: Eclipse compat -- now "compare with latest from HEAD" works
   cvsserver: checkout faster by sending files in a sensible order
   cvsserver: fix checkouts with -d <somedir>
   cvsserver: nested directory creation fixups for Eclipse clients
   cvsserver: better error messages
   cvsserver: anonymous cvs via pserver support

 - delta cleanup (Nicolas Pitre)
   relax delta selection filtering in pack-objects
   diff-delta: fold two special tests into one plus cleanups
   diff-delta: big code simplification

 - git-annotate updates (Ryan Anderson)
   annotate: handle \No newline at end of file.
   annotate: Add a basic set of test cases.

 - misc fixes and docs (Francis Daly, Johannes Schindelin, Jonas Fonseca,
   Mark Wooding, Shawn Pearce, Tony Luck, Martin Langhoff, me)
   AsciiDoc fix for tutorial
   Documentation: read-tree --aggressive
   Documentation: rev-list --objects-edge
   Fix test case for some sed
   GIT-VERSION-GEN: squelch unneeded error from "cat version"
   Prevent --index-info from ignoring -z.
   Pull GIT 1.2.4 fixes from master
   Re-fix compilation warnings.
   Warn about invalid refs
   annotate should number lines starting with 1
   annotate: fix -S parameter to take a string
   annotate: resurrect raw timestamps.
   combine-diff: Honour --full-index.
   combine-diff: Honour -z option correctly.
   git-commit: make sure we protect against races.
   manpages: insert two missing [verse] markers for multi-line SYNOPSIS
   read-tree --aggressive: remove deleted entry from the working tree.
   tar-tree: file/dirmode fix.
   war on whitespaces: documentation.

* The 'next' branch, in addition, has these.

 - diffcore-rename/break and similarity estimator tweaks (me)
   count-delta: no need for this anymore.
   diffcore-break: similarity estimator fix.
   diffcore-delta: make change counter to byte oriented again.
   diffcore-rename: similarity estimator fix.

* The 'pu' branch, in addition, has these.

 - checkout-index --temp --stage=all (Shawn Pearce)

Junio C Hamano <junkio@cox.net> writes:

Quick correction before anybody says anything.

Sorry Fredrik, there is none anymore --- you have already done clean-up and I merged it. Just "print_map defined but not used".

On Sat, 4 Mar 2006, Junio C Hamano wrote:

Here's a potential fix for a special case that we used to have to make

	git-rev-list --max-count=1

be faster and not unnecessarily parse any parent objects.

Now, we had that special case because gitweb was apparently doing a lot of it, and quite frankly, I don't know if it still does. But basically it avoids doing the "pop_most_recent_commit()" which will look up and parse the parents, if it is obvious that it can.

I'm not sure this is worth it, but it looks obvious enough. Somebody with gitweb somewhere should probably check if it still even wants this.

		Linus

----

Linus Torvalds <torvalds@osdl.org> writes:

I just pulled and it's still v264 (Jan 17 2006). It does it in one sub (git_read_commit) to read a single commit and the sub is called from almost everywhere, so it would help.

Having said that...

At this point commit is revs->commits->item. It cannot be UNINTERESTING because you make it sure with !revs->limited and friends, but I wonder if it can be SHOWN already for some reason, in which case returning it is wrong.

Unlike the earlier special case in rev-list, this special case kicks in for the last iteration of repeated calls to get_revision() (e.g. third iteration of "rev-list -3")...

On Sat, 4 Mar 2006, Junio C Hamano wrote:

Good point. Yes, it needs to check that it's not SHOWN. Might as well check against interesting too. Maybe something like this instead?

		Linus

---

On Sun, 5 Mar 2006, Linus Torvalds wrote:

Actually, thinking more about it, I think we could get rid of SHOWN.

We only ever insert a commit _once_ onto the list, using the SEEN logic, so we can never pull the same commit off the list more than once. I think SHOWN was for merge-order.

But I might be wrong. I was thinking about SHOWN a bit when I did the re-organization, but didn't dare to actually touch it, so I left it alone.

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

I abused SHOWN when I did --objects-edge with mark_edge_parents_uninteresting modification in eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4, but probably it can be modified to use SEEN.

On Sun, 5 Mar 2006, Junio C Hamano wrote:

Ahh, no. SEEN is different from SHOWN. SHOWN means that we've actually shown that commit, while SEEN just means that we've added it to the list (but it might be uninteresting, for example). I think you did exactly the right thing wrt SHOWN.

That said, the revision list walker should never see a SHOWN commit on the list, because it is the thing that sets SHOWN as it removes the entry from the list (and it should never get re-added, due to SEEN).

		Linus

I was going through 'whatchanged rev-list.c' but was half-way when I sent the previous message. -S'UNINTERESTING|SHOWN' found this one.

51b1e1713b1ed8e962e994cd0850ea439ad8c3de
Author: Jon Seymour <jon.seymour@gmail.com>
Date:   Mon Jun 20 12:29:38 2005 +1000

    [PATCH] Prevent git-rev-list without --merge-order producing
    dupicates in output

    If b is reachable from a, then:

         git-rev-list a b

    argument would print one of the commits twice.

    This patch fixes that problem. A previous problem fixed it
    for the --merge-order switch.

    Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

On 3/5/06, Junio C Hamano <junkio@cox.net> wrote:

I'm somewhat confused by the fact that there are two emacs modes, both by Alexandre. Which one should I use? Also -- the killer app for emacs+git would be to leverage the great patch-editing mode in emacs.

Can we get a new merge conflict mode that generates .rej files? Emacs is superb at dealing with conflicts formatted that way. OTOH, it may be able to deal smartly with diff3-style conflicts if it knows how to talk with the VC backend -- I think the cvs mode can do that.

Linus has mentioned several times that it is more important to have well oiled tools to deal with conflicts when they happen -- easy visualization of what the different versions were, commit msgs, highlight characters that don't match in a line that looks the same at first glance, etc -- than to try and magically resolve conflicts. I'm in violent agreement, and keen on seeing the emacs vc stuff fill that gap.

(of course, if xxdiff and others can help, that'd be cool too, but currently they seem strangely unable to deal with files with diff3 conflict markers.)

Wohoo! This needs testers -- give it a whirl, please! BTW, the workarounds for Eclipse mentioned in the doco are no longer needed. Still, you do want to give Documentation/git-cvsserver.txt a quick read.

cheers,

martin

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

You can use both. The VC backend is a per-file mode, that's handy when you are editing a file and want a quick diff/revert/commit of just that file; the commands are executed directly from the buffer containing the file. When making bigger changes, you should use the git-status mode (the one in git.el), which is a tree browser that gives you a view of the whole project.

What emacs mode do you use to resolve conflicts? From the git-status buffer, if you edit a file with 'f' it will automatically turn on smerge mode if there are conflicts, or you can edit it in ediff merge mode with 'd E' like under pcl-cvs. Is that what you mean?

On 3/5/06, Alexandre Julliard <julliard@winehq.org> wrote:

So I should use a combination of both? Hmmm. Worth exploring, can you give us a quick guide on getting started with it? (Or where should I read? I'm not that good with emacs)...

Oh. Ah. Ok! I'll have to try this! So far, I've had good luck following this guide:

    http://wiki.gnuarch.org/Process_20_2a_2erej_20files

which is targetted pretty much at dumb emacs users. Like me ;-)

martin

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

To get started with the VC backend, make sure vc-git.el is somewhere on your emacs load-path, and add GIT to the vc-handled-backends variable; the easiest is with customize, something like `M-x customize-variable [RET] vc-handled-backends'.

Once you have done that, when you open a file that's under git control, the vc-git mode should automatically be turned on, and you should see a "GIT" indicator in the modeline. Then you can use the standard VC backend commands (the ones that start with the C-x v prefix). The Emacs VC mode is documented at:

  http://www.gnu.org/software/emacs/manual/html_node/Version-Control.html

For the git-status mode, simply do a `M-x load-file [RET] git.el', and then `M-x git-status'. This will prompt you for the directory to view, and display a list of modified files. From there you can mark files and perform actions on group of files, like diff, commit, revert, etc. There isn't a lot of documentation at this point, but a `C-h m' will show you the list of key bindings, so you can try them all and see what happens ;-)

smerge mode is a very simple mode to edit files that contain conflict markers, in my experience it works pretty well. The nice thing is that it works directly from the file buffer, so you don't need to jump back and forth between file and diff.

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

They are different styles. I've been in VC camp but my understanding is pcl-cvs style integration is closer to whole-tree than VC which is more per-file. I still haven't adjusted to pcl-cvs style yet..

I had pleasant experiences with "xxdiff -U".