# What's in git.git 14 messages from 2006-03-05 to 2006-03-05. Participants: Junio C Hamano, Linus Torvalds, Martin Langhoff, Alexandre Julliard. Thread: https://gitlist.dev/t/3561 ## Junio C Hamano, 2006-03-05 04:22 Subject: What's in git.git Message-ID: <7vacc5jza6.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vacc5jza6.fsf%40assigned-by-dhcp.cox.net ``` 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 ..." work again. rev-list split: minimum fixup. git-log (internal): add approxidate. git-log (internal): more options. setup_revisions(): handle -n and - 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 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 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, 2006-03-05 04:51 Subject: Re: What's in git.git Message-ID: <7v4q2djxy9.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v4q2djxy9.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vacc5jza6.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > Fredrik's git-blame still has -Wdeclaration-after-statement > issues,... 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". ``` ## Linus Torvalds, 2006-03-05 04:58 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0603042058250.13139%40g5.osdl.org In-Reply-To: <7vacc5jza6.fsf@assigned-by-dhcp.cox.net> ``` On Sat, 4 Mar 2006, Junio C Hamano wrote: > > 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. 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 ---- diff --git a/revision.c b/revision.c index a3df810..33a5f20 100644 --- a/revision.c +++ b/revision.c @@ -696,6 +696,18 @@ struct commit *get_revision(struct rev_i break; case 0: return NULL; + + /* Special case to avoid unnecessary parent checking */ + case 1: + if (!revs->limited && + !revs->no_merges && + !revs->paths && + revs->min_age == -1 && + revs->max_age == -1) { + revs->max_count = 0; + commit->object.flags |= SHOWN; + return commit; + } default: revs->max_count--; } ``` ## Junio C Hamano, 2006-03-05 05:44 Subject: Re: What's in git.git Message-ID: <7vfylxigxc.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vfylxigxc.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds writes: > 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. 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... > diff --git a/revision.c b/revision.c > index a3df810..33a5f20 100644 > --- a/revision.c > +++ b/revision.c > @@ -696,6 +696,18 @@ struct commit *get_revision(struct rev_i > break; > case 0: > return NULL; > + > + /* Special case to avoid unnecessary parent checking */ > + case 1: > + if (!revs->limited && > + !revs->no_merges && > + !revs->paths && > + revs->min_age == -1 && > + revs->max_age == -1) { > + revs->max_count = 0; > + commit->object.flags |= SHOWN; > + return commit; > + } 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")... ``` ## Martin Langhoff, 2006-03-05 09:21 Subject: Re: What's in git.git Message-ID: <46a038f90603050121u6bccbb71ve78de69ae45b96ad@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90603050121u6bccbb71ve78de69ae45b96ad%40mail.gmail.com In-Reply-To: <7vacc5jza6.fsf@assigned-by-dhcp.cox.net> ``` On 3/5/06, Junio C Hamano wrote: > - 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. 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.) > - git-cvsserver updates (Martin Langhoff) 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 ``` ## Alexandre Julliard, 2006-03-05 09:58 Subject: Re: What's in git.git Message-ID: <87irqtjjr1.fsf@wine.dyndns.org> URL: https://gitlist.dev/e/87irqtjjr1.fsf%40wine.dyndns.org In-Reply-To: <46a038f90603050121u6bccbb71ve78de69ae45b96ad@mail.gmail.com> ``` "Martin Langhoff" writes: > 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. 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. > 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. 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? -- Alexandre Julliard julliard@winehq.org ``` ## Junio C Hamano, 2006-03-05 10:10 Subject: Re: What's in git.git Message-ID: <7vy7zpgq1i.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vy7zpgq1i.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <46a038f90603050121u6bccbb71ve78de69ae45b96ad@mail.gmail.com> ``` "Martin Langhoff" writes: > 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. 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.. > (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.) I had pleasant experiences with "xxdiff -U". ``` ## Martin Langhoff, 2006-03-05 10:15 Subject: Re: What's in git.git Message-ID: <46a038f90603050215v7afcbd4crc145e85a4da416a7@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90603050215v7afcbd4crc145e85a4da416a7%40mail.gmail.com In-Reply-To: <87irqtjjr1.fsf@wine.dyndns.org> ``` On 3/5/06, Alexandre Julliard wrote: > 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. 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)... > > 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. > > 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? 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 ``` ## Alexandre Julliard, 2006-03-05 10:47 Subject: Re: What's in git.git Message-ID: <87bqwljhgn.fsf@wine.dyndns.org> URL: https://gitlist.dev/e/87bqwljhgn.fsf%40wine.dyndns.org In-Reply-To: <46a038f90603050215v7afcbd4crc145e85a4da416a7@mail.gmail.com> ``` "Martin Langhoff" writes: > 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)... 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 ;-) > 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 ;-) 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. -- Alexandre Julliard julliard@winehq.org ``` ## Linus Torvalds, 2006-03-05 17:53 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0603050946280.13139%40g5.osdl.org In-Reply-To: <7vfylxigxc.fsf@assigned-by-dhcp.cox.net> ``` On Sat, 4 Mar 2006, Junio C Hamano wrote: > > 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")... 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 --- diff --git a/revision.c b/revision.c index a3df810..2a33637 100644 --- a/revision.c +++ b/revision.c @@ -684,13 +684,11 @@ static void rewrite_parents(struct commi struct commit *get_revision(struct rev_info *revs) { struct commit_list *list = revs->commits; - struct commit *commit; if (!list) return NULL; /* Check the max_count ... */ - commit = list->item; switch (revs->max_count) { case -1: break; @@ -701,22 +699,28 @@ struct commit *get_revision(struct rev_i } do { - commit = pop_most_recent_commit(&revs->commits, SEEN); + struct commit *commit = revs->commits->item; + if (commit->object.flags & (UNINTERESTING|SHOWN)) - continue; + goto next; if (revs->min_age != -1 && (commit->date > revs->min_age)) - continue; + goto next; if (revs->max_age != -1 && (commit->date < revs->max_age)) return NULL; if (revs->no_merges && commit->parents && commit->parents->next) - continue; + goto next; if (revs->paths && revs->dense) { if (!(commit->object.flags & TREECHANGE)) - continue; + goto next; rewrite_parents(commit); } + /* More to go? */ + if (revs->max_count) + pop_most_recent_commit(&revs->commits, SEEN); commit->object.flags |= SHOWN; return commit; +next: + pop_most_recent_commit(&revs->commits, SEEN); } while (revs->commits); return NULL; } ``` ## Linus Torvalds, 2006-03-05 18:29 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0603051027400.13139%40g5.osdl.org In-Reply-To: ``` On Sun, 5 Mar 2006, Linus Torvalds 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? 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 ``` ## Junio C Hamano, 2006-03-05 19:36 Subject: Re: What's in git.git Message-ID: <7vwtf8fzvb.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vwtf8fzvb.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds writes: > 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. 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. ``` ## Junio C Hamano, 2006-03-05 19:53 Subject: Re: What's in git.git Message-ID: <7vk6b8fz1x.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vk6b8fz1x.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` 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 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 Signed-off-by: Linus Torvalds ``` ## Linus Torvalds, 2006-03-05 20:04 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0603051203060.13139%40g5.osdl.org In-Reply-To: <7vwtf8fzvb.fsf@assigned-by-dhcp.cox.net> ``` On Sun, 5 Mar 2006, Junio C Hamano wrote: > > 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. 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 ```