GIT 0.99.6

GIT 0.99.6

[Junio C Hamano]

Highlights
==========

* Documentation is in much better shape.  Thanks everybody.

* Two grave bugs in 'git fetch' were caught and fixed.  One is "Fix
  fetching of tags", the other is "Fix pulling into the same branch.".

* We have archimport (unfortunately undocumented yet), and
  cvsimport is being improved.

* Revert, rebase and cherry-pick are done using three-way merge,
  not a straight patch application.

* 'git commit' should be a bit easier to use than before in
  initial commits and merge commits.

* 'git applymbox' is a bit more accomodating and it should be
  easier to handle MIME patches than before.

* As usual, comes with more recent gitk.

Better merge algorithms and the infrastructure are being worked
on by Daniel and Fredrik; they are not in this release yet.


What to expect after 0.99.6
===========================

This is written in a form of to-do list for me, so if I say
"accept patch", it means I do not currently plan to do that
myself.  People interested in seeing it materialize please take
a hint.  The latest copy of this document is found at 

    http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO

Tool Renames Plan
-----------------

 - All non-binary commands will lose -script suffix in
   $(bindir).  The source to git-foo will be either git-foo.sh
   or git-foo.perl in the source tree, and the documentation
   will be in Documentation/git-foo.txt.

 - The commands whose names have 'cache' to mean 'index file'
   will get 'cache' in their names replaced with 'index'. For
   git-fsck-cache and git-convert-cache, 'cache' will be
   replaced with 'objects'.

 - The commit walkers will have 'pull' in their names replaced
   with 'fetch'.  'git-ssh-push' will become 'git-ssh-upload'.

 - We continue to follow the convention to name the C source
   file that contains the main program of 'git-foo' command
   'foo.c'.  That means we will have 'fsck-objects.c', for
   example.

 - At this moment, I am not planning to rename the symbols used
   in programs, nor any library sources.  "cache.h" will stay
   "cache.h", so does "read-cache.c".  "struct cache_entry"  and
   "ce_match_stat()" will keep their names.  We _might_ want to
   rename them in later rounds but not right now.

 - In 0.99.7, all renamed commands will have symbolic links in
   $(bindir) so that old names continue to work.  These backward
   compatible symlinks will not be present in documentation,
   though.  Especially, the main documentation, git(7) will talk
   about the new names.  Old environment names defined in
   gitenv() will also be removed in this release.

   Tentatively we aim to do this on Sep 17th.

 - In 0.99.8, we do not install these backward compatible
   symbolic links in $(bindir) anymore.  The Makefile will have
   a target to remove old symlinks from $(DESTDIR)$(bindir) you
   can run manually to help you clean things up.

   The timeframe for this is around Oct 1st, but I could be
   talked into delaying the symlink removal if Porcelain people
   find this schedule too tight.


Documentation
-------------

* Accept patches from people who actually have done CVS
  migration and update the cvs-migration documentation.
  Link the documentation from the main git.txt page.

* Accept patches from people who were hit by shiny blue bat to
  update the SubmittingPatches [ONGOING].

* Talk about using rsync just once at the beginning when
  initializing a remote repository so that local packs do not
  need to be expanded.  I personally do not think we need tool
  support for this (but see below about optimized cloning).

* Maybe update tutorial with a toy project that involves two or
  three developers..

* Update tutorial to cover setting up repository hooks to do
  common tasks.

* Accept patches to finish missing docs.


Technical (heavier)
-------------------

* Tony Luck reported an unfortunate glitch in the 3-way merge.
  Encourage discussions to come up with a not-so-expensive way
  to catch the kind of ambiguities that led to his misery.
  [Daniel's patch looks quite promising, so is the one from
  Fredrik.]

* HPA has two projects, klibc and klibc-kbuild, that have large
  set of overlapping files in different paths (i.e. one has many
  renames from the other).  There currently is no way for git to
  help keep these two trees in sync, merging criss-cross between
  them.  The merge logic should be able to take advantage of
  rename/copy detection smarts git-diff-* family has.  Linus,
  me, and Daniel outlined a smarter merge strategy for this.
  Try them out.

* To make it easier to experiment with different merge
  strategies, make git-merge driver that will run merge backends
  for the best merge [Outlined the idea; just do it].

* We might want to optimize cloning with GIT native transport
  not to explode the pack, and store it in objects/pack instead.
  We would need a tool to generate an idx file out of a pack
  file for this.  Also this itself may turn out to be a bad
  idea, making the set of packs in repositories everybody has
  different from each other.

* Maybe a pack optimizer.  I am not convinced that packing all
  objects into a single pack and removing all the existing panck
  is the right way to go, since that would work against people
  who already have those packs.

* Maybe an Emacs VC backend.


Technical (milder)
------------------

* Tool renames [STARTED].

* Have Daniel's read-tree graduate from "pu" after plugging leaks.

* Implement a merge backend using Daniel's read-tree.

* Accept Fredrik merge after renaming it (I want to name the
  driver 'git merge').  Suggest where to place *.py stuff --
  probably in $(share)/git-core/ and add Makefile entry for
  installation.

* Encourage concrete proposals to commit log message templates
  we discussed some time ago.

* Bug Martin for archimport script documentation.

* More portability.  I dropped a SunOS patch on the floor by
  somebody.

* Accept patches to cause "read-tree -u" delete a directory when
  it makes it empty.

* Perhaps accept patches to introduce the concept of "patch flow
  expressed as ref mappings" Josef has been advocating about.

* Perhaps accept patches to do undo/redo.

* Maybe grok PGP signed text/plain in applymbox as well.

* Perhaps a tool to revert a single file to pre-modification
  state?  git-cat-file blob `git-ls-files | grep foo` >foo or
  git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should
  the command be called?  git-revert is taken so is
  git-checkout.

* A tool to detect, show and prune already merged topic
  branches.

* Enhance "git repack" to not always use --all; this would be
  handy if the repository contains wagging heads like "pu" in
  git.git repository.

* Internally split the project into non-doc and doc parts; add
  an extra root for the doc part and merge from it; move the
  internal doc source to a separate repository, like the +Meta
  repository; experiment if this results in a reasonable
  workflow, and document it in howto form if it does.

* Option to limit rename detection for more than N paths.


Technical (trivial)
-------------------

* Perhaps "git branch -d" to delete a branch.

* We would want test scripts for the relative directory path
  stuff Linus has been working on.  So far, the following
  commands should be usable with relative directory paths:

    update-cache
    ls-files
    diff-files
    diff-cache
    diff-tree
    rev-list
    rev-parse

* In a freashly created empty repository, `git fetch foo:bar`
  works OK, but `git checkout bar` afterwards does not (missing
  `.git/HEAD`).

Tool renames and 'ls-files -t' output

[Junio C Hamano]

The "master" branch post 0.99.6 already has the renamed tools
with backward compatibility symlinks.  I'll be sending a
patch to address an issue raised by some people separately to
see what the list thinks, and also will attempt to send out a
patch for the Pasky and Catalin heads later this week.  Also
I'll remove the ancient backward compatible environment variable
names from gitenv.c.

There were discussion on the tag 'git-ls-files -t' output uses.
I got a feeling that we might want to change them to match what
other tools give.  Here is the proposed changes:
	
    Meaning	Current		Updated

    cached	H		.
    unmerged	M		U
    removed	R		D
    other	?		?
    killed	K		K
    modified	info unav.	M

I may also be tempted to rename 'tag_removed' variable there to
'tag_deleted' for consistency.

Comments?

Post 0.99.7 preperation patches

[Junio C Hamano]

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

> The "master" branch post 0.99.6 already has the renamed tools
> with backward compatibility symlinks.  I'll be sending a
> patch to address an issue raised by some people separately to
> see what the list thinks, and also will attempt to send out a
> patch for the Pasky and Catalin heads later this week.

I've prepared these and will be sending them out separately to
you two, hoping they would help you prepare for post 0.99.7
changes.  Note that 0.99.6 does not know about these new names,
the current "master" branch knows about both new and old names,
so will 0.99.7, and in 0.99.8 the old names will be removed, if
things go as planned.

Here is a small script that I used before auditing what it did
to your trees by running 'git diff' on its result.

------------
#!/bin/sh
git-ls-files |
xargs perl -i -p -e '
	s/git-merge-one-file-script/git-merge-one-file/g;
	s/git-count-objects-script/git-count-objects/g;
	s/git-format-patch-script/git-format-patch/g;
	s/git-parse-remote-script/git-parse-remote/g;
	s/git-request-pull-script/git-request-pull/g;
	s/git-cherry-pick-script/git-cherry-pick/g;
	s/git-archimport-script/git-archimport/g;
	s/git-send-email-script/git-send-email/g;
	s/git-verify-tag-script/git-verify-tag/g;
	s/git-cvsimport-script/git-cvsimport/g;
	s/git-ls-remote-script/git-ls-remote/g;
	s/git-checkout-script/git-checkout/g;
	s/git-sh-setup-script/git-sh-setup/g;
	s/git-octopus-script/git-octopus/g;
	s/git-resolve-script/git-resolve/g;
	s/git-checkout-cache/git-checkout-index/g;
	s/git-bisect-script/git-bisect/g;
	s/git-branch-script/git-branch/g;
	s/git-commit-script/git-commit/g;
	s/git-rebase-script/git-rebase/g;
	s/git-relink-script/git-relink/g;
	s/git-rename-script/git-rename/g;
	s/git-repack-script/git-repack/g;
	s/git-revert-script/git-revert/g;
	s/git-status-script/git-status/g;
	s/git-convert-cache/git-convert-objects/g;
	s/git-clone-script/git-clone/g;
	s/git-fetch-script/git-fetch/g;
	s/git-prune-script/git-prune/g;
	s/git-reset-script/git-reset/g;
	s/git-update-cache/git-update-index/g;
	s/git-diff-script/git-diff/g;
	s/git-pull-script/git-pull/g;
	s/git-push-script/git-push/g;
	s/git-merge-cache/git-merge-index/g;
	s/git-add-script/git-add/g;
	s/git-log-script/git-log/g;
	s/git-tag-script/git-tag/g;
	s/git-local-pull/git-local-fetch/g;
	s/git-diff-cache/git-diff-index/g;
	s/git-fsck-cache/git-fsck-objects/g;
	s/git-http-pull/git-http-fetch/g;
	s/git-ssh-pull/git-ssh-fetch/g;
	s/git-ssh-push/git-ssh-upload/g;
'
git-update-cache --refresh

Re: Post 0.99.7 preperation patches

[Petr Baudis]

Dear diary, on Fri, Sep 09, 2005 at 11:20:53AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Junio C Hamano <junkio@cox.net> writes:
> 
> > The "master" branch post 0.99.6 already has the renamed tools
> > with backward compatibility symlinks.  I'll be sending a
> > patch to address an issue raised by some people separately to
> > see what the list thinks, and also will attempt to send out a
> > patch for the Pasky and Catalin heads later this week.
> 
> I've prepared these and will be sending them out separately to
> you two, hoping they would help you prepare for post 0.99.7
> changes.  Note that 0.99.6 does not know about these new names,
> the current "master" branch knows about both new and old names,
> so will 0.99.7, and in 0.99.8 the old names will be removed, if
> things go as planned.
> 
> Here is a small script that I used before auditing what it did
> to your trees by running 'git diff' on its result.

Thanks for the notification. I will do an auxiliary release right
after 0.99.7 is released.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

RFC: s/git-merge-base/git-find-common-ancestor/g

[Yasushi SHOJI]

At Thu, 08 Sep 2005 15:14:52 -0700,
Junio C Hamano wrote:
> 
> The "master" branch post 0.99.6 already has the renamed tools
> with backward compatibility symlinks.  I'll be sending a
> patch to address an issue raised by some people separately to
> see what the list thinks, and also will attempt to send out a
> patch for the Pasky and Catalin heads later this week.  Also
> I'll remove the ancient backward compatible environment variable
> names from gitenv.c.

everything seems very consistent indeed, except one command:

   git-merge-base

I've already got used to it. but, at first, the name gave me the
impression that it merge the current branch with given base point.

the current documentation says:

   Finds as good a common ancestor as possible for a merge

so would it be better to rename it to:

   git-find-common-ancestor

That's what the command does after all.
--
         yashi

Re: RFC: s/git-merge-base/git-find-common-ancestor/g

[Junio C Hamano]

Yasushi SHOJI <yashi@atmark-techno.com> writes:

> I've already got used to it. but, at first, the name gave me the
> impression that it merge the current branch with given base point.
>
> the current documentation says:
>
>    Finds as good a common ancestor as possible for a merge
>
> so would it be better to rename it to:
>
>    git-find-common-ancestor
>
> That's what the command does after all.

It does not find just any common ancestor, but tries to find a
set of common ancestors that are good to be used as merge bases.
So git-find-merge-base _might_ be an acceptable rename, but
git-find-common-ancestor certainly isn't.

[PATCH] Rename git-merge-base to git-find-merge-base

[Yasushi SHOJI]

Junio C Hamano wrote:
> 
> Yasushi SHOJI <yashi@atmark-techno.com> writes:
> 
> > I've already got used to it. but, at first, the name gave me the
> > impression that it merge the current branch with given base point.
> >
> > the current documentation says:
> >
> >    Finds as good a common ancestor as possible for a merge
> >
> > so would it be better to rename it to:
> >
> >    git-find-common-ancestor
> >
> > That's what the command does after all.
> 
> It does not find just any common ancestor, but tries to find a
> set of common ancestors that are good to be used as merge bases.
> So git-find-merge-base _might_ be an acceptable rename, but
> git-find-common-ancestor certainly isn't.

ok.  it certainly does't find all common ancestors for given sha1s.

how about renaming the command to git-find-merge-base as you suggested
and document what the merge base is?

attached patch does the rename only.  haven't added "merge base" entry
to Documentation/git-find-merge-base.txt.
--
       yashi

Rename git-merge-base to git-find-merge-base

The command is to _find_ merge base, not merge something with base.
Reflect what it does to its name.

Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>


---

 .gitignore                            |    2 
 Documentation/git-find-merge-base.txt |   34 +++++++
 Documentation/git-merge-base.txt      |   34 -------
 Documentation/git-read-tree.txt       |    2 
 Documentation/git-show-branch.txt     |    2 
 Documentation/git.txt                 |    2 
 Makefile                              |    2 
 README                                |    2 
 find-merge-base.c                     |  171 +++++++++++++++++++++++++++++++++
 git-archimport.perl                   |    4 -
 git-fetch.sh                          |    2 
 git-merge-octopus.sh                  |    2 
 git-merge.sh                          |    2 
 git-octopus.sh                        |    2 
 git-resolve.sh                        |    4 -
 gitk                                  |    2 
 merge-base.c                          |  171 ---------------------------------
 t/t4100/t-apply-1.patch               |    2 
 t/t4100/t-apply-5.patch               |    2 
 templates/hooks--update               |    2 
 20 files changed, 223 insertions(+), 223 deletions(-)
 create mode 100644 Documentation/git-find-merge-base.txt
 delete mode 100644 Documentation/git-merge-base.txt
 create mode 100644 find-merge-base.c
 delete mode 100644 merge-base.c

2652b63c0dcd376f47e3985be26a3cef67c397c8
diff --git a/.gitignore b/.gitignore
--- a/.gitignore
+++ b/.gitignore
@@ -42,7 +42,7 @@ git-ls-tree
 git-mailinfo
 git-mailsplit
 git-merge
-git-merge-base
+git-find-merge-base
 git-merge-fredrik
 git-merge-index
 git-merge-octopus
diff --git a/Documentation/git-find-merge-base.txt b/Documentation/git-find-merge-base.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-find-merge-base.txt
@@ -0,0 +1,34 @@
+git-find-merge-base(1)
+======================
+v0.1, May 2005
+
+NAME
+----
+git-find-merge-base - Finds as good a common ancestor as possible for a merge
+
+
+SYNOPSIS
+--------
+'git-find-merge-base' <commit> <commit>
+
+DESCRIPTION
+-----------
+"git-find-merge-base" finds as good a common ancestor as possible. Given a
+selection of equally good common ancestors it should not be relied on
+to decide in any particular way.
+
+The "git-find-merge-base" algorithm is still in flux - use the source...
+
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the link:git.html[git] suite
+
diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt
deleted file mode 100644
--- a/Documentation/git-merge-base.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-git-merge-base(1)
-=================
-v0.1, May 2005
-
-NAME
-----
-git-merge-base - Finds as good a common ancestor as possible for a merge
-
-
-SYNOPSIS
---------
-'git-merge-base' <commit> <commit>
-
-DESCRIPTION
------------
-"git-merge-base" finds as good a common ancestor as possible. Given a
-selection of equally good common ancestors it should not be relied on
-to decide in any particular way.
-
-The "git-merge-base" algorithm is still in flux - use the source...
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-
-Documentation
---------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the link:git.html[git] suite
-
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -239,7 +239,7 @@ some edits since.  Three-way merge makes
 added or modified cache entries since $JC, and if you haven't,
 then does the right thing.  So with the following sequence:
 
-    $ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
+    $ git-read-tree -m -u `git-find-merge-base $JC $LT` $JC $LT
     $ git-merge-index git-merge-one-file -a
     $ echo "Merge with Linus" | \
       git-commit-tree `git-write-tree` -p $JC -p $LT
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -38,7 +38,7 @@ OPTIONS
 
 --merge-base::
 	Instead of showing the commit list, just act like the
-	'git-merge-base -a' command, except that it can accept
+	'git-find-merge-base -a' command, except that it can accept
 	more than two heads.
 
 --independent::
diff --git a/Documentation/git.txt b/Documentation/git.txt
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -131,7 +131,7 @@ link:git-ls-files.html[git-ls-files]::
 link:git-ls-tree.html[git-ls-tree]::
 	Displays a tree object in human readable form
 
-link:git-merge-base.html[git-merge-base]::
+link:git-find-merge-base.html[git-find-merge-base]::
 	Finds as good a common ancestor as possible for a merge
 
 link:git-rev-list.html[git-rev-list]::
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -98,7 +98,7 @@ PROGRAMS = \
 	git-diff-helper git-diff-index git-diff-stages \
 	git-diff-tree git-export git-fetch-pack git-fsck-objects \
 	git-hash-object git-init-db \
-	git-local-fetch git-ls-files git-ls-tree git-merge-base \
+	git-local-fetch git-ls-files git-ls-tree git-find-merge-base \
 	git-merge-index git-mktag git-pack-objects git-patch-id \
 	git-peek-remote git-prune-packed git-read-tree \
 	git-receive-pack git-rev-list git-rev-parse \
diff --git a/README b/README
--- a/README
+++ b/README
@@ -445,7 +445,7 @@ state of the directory ("tree" object) a
 To get the "base" for the merge, you first look up the common parent
 of two commits with
 
-		git-merge-base <commit1> <commit2>
+		git-find-merge-base <commit1> <commit2>
 
 which will return you the commit they are both based on.  You should
 now look up the "tree" objects of those commits, which you can easily
diff --git a/find-merge-base.c b/find-merge-base.c
new file mode 100644
--- /dev/null
+++ b/find-merge-base.c
@@ -0,0 +1,171 @@
+#include <stdlib.h>
+#include "cache.h"
+#include "commit.h"
+
+#define PARENT1 1
+#define PARENT2 2
+#define UNINTERESTING 4
+
+static struct commit *interesting(struct commit_list *list)
+{
+	while (list) {
+		struct commit *commit = list->item;
+		list = list->next;
+		if (commit->object.flags & UNINTERESTING)
+			continue;
+		return commit;
+	}
+	return NULL;
+}
+
+/*
+ * A pathological example of how this thing works.
+ *
+ * Suppose we had this commit graph, where chronologically
+ * the timestamp on the commit are A <= B <= C <= D <= E <= F
+ * and we are trying to figure out the merge base for E and F
+ * commits.
+ *
+ *                  F
+ *                 / \
+ *            E   A   D
+ *             \ /   /  
+ *              B   /
+ *               \ /
+ *                C
+ *
+ * First we push E and F to list to be processed.  E gets bit 1
+ * and F gets bit 2.  The list becomes:
+ *
+ *     list=F(2) E(1), result=empty
+ *
+ * Then we pop F, the newest commit, from the list.  Its flag is 2.
+ * We scan its parents, mark them reachable from the side that F is
+ * reachable from, and push them to the list:
+ *
+ *     list=E(1) D(2) A(2), result=empty
+ *
+ * Next pop E and do the same.
+ *
+ *     list=D(2) B(1) A(2), result=empty
+ *
+ * Next pop D and do the same.
+ *
+ *     list=C(2) B(1) A(2), result=empty
+ *
+ * Next pop C and do the same.
+ *
+ *     list=B(1) A(2), result=empty
+ *
+ * Now it is B's turn.  We mark its parent, C, reachable from B's side,
+ * and push it to the list:
+ *
+ *     list=C(3) A(2), result=empty
+ *
+ * Now pop C and notice it has flags==3.  It is placed on the result list,
+ * and the list now contains:
+ *
+ *     list=A(2), result=C(3)
+ *
+ * We pop A and do the same.
+ * 
+ *     list=B(3), result=C(3)
+ *
+ * Next, we pop B and something very interesting happens.  It has flags==3
+ * so it is also placed on the result list, and its parents are marked
+ * uninteresting, retroactively, and placed back on the list:
+ *
+ *    list=C(7), result=C(7) B(3)
+ * 
+ * Now, list does not have any interesting commit.  So we find the newest
+ * commit from the result list that is not marked uninteresting.  Which is
+ * commit B.
+ */
+
+static int show_all = 0;
+
+static int find_merge_base(struct commit *rev1, struct commit *rev2)
+{
+	struct commit_list *list = NULL;
+	struct commit_list *result = NULL;
+
+	if (rev1 == rev2) {
+		printf("%s\n", sha1_to_hex(rev1->object.sha1));
+		return 0;
+	}
+
+	parse_commit(rev1);
+	parse_commit(rev2);
+
+	rev1->object.flags |= 1;
+	rev2->object.flags |= 2;
+	insert_by_date(rev1, &list);
+	insert_by_date(rev2, &list);
+
+	while (interesting(list)) {
+		struct commit *commit = list->item;
+		struct commit_list *tmp = list, *parents;
+		int flags = commit->object.flags & 7;
+
+		list = list->next;
+		free(tmp);
+		if (flags == 3) {
+			insert_by_date(commit, &result);
+
+			/* Mark parents of a found merge uninteresting */
+			flags |= UNINTERESTING;
+		}
+		parents = commit->parents;
+		while (parents) {
+			struct commit *p = parents->item;
+			parents = parents->next;
+			if ((p->object.flags & flags) == flags)
+				continue;
+			parse_commit(p);
+			p->object.flags |= flags;
+			insert_by_date(p, &list);
+		}
+	}
+
+	if (!result)
+		return 1;
+
+	while (result) {
+		struct commit *commit = result->item;
+		result = result->next;
+		if (commit->object.flags & UNINTERESTING)
+			continue;
+		printf("%s\n", sha1_to_hex(commit->object.sha1));
+		if (!show_all)
+			return 0;
+		commit->object.flags |= UNINTERESTING;
+	}
+	return 0;
+}
+
+static const char find_merge_base_usage[] =
+"git-find-merge-base [--all] <commit-id> <commit-id>";
+
+int main(int argc, char **argv)
+{
+	struct commit *rev1, *rev2;
+	unsigned char rev1key[20], rev2key[20];
+
+	while (1 < argc && argv[1][0] == '-') {
+		char *arg = argv[1];
+		if (!strcmp(arg, "-a") || !strcmp(arg, "--all"))
+			show_all = 1;
+		else
+			usage(find_merge_base_usage);
+		argc--; argv++;
+	}
+	if (argc != 3 ||
+	    get_sha1(argv[1], rev1key) ||
+	    get_sha1(argv[2], rev2key))
+		usage(find_merge_base_usage);
+	rev1 = lookup_commit_reference(rev1key);
+	rev2 = lookup_commit_reference(rev2key);
+	if (!rev1 || !rev2)
+		return 1;
+	return find_merge_base(rev1, rev2);
+}
diff --git a/git-archimport.perl b/git-archimport.perl
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -640,7 +640,7 @@ sub find_parents {
     #
     # Identify what branches are merging into me
     # and whether we are fully merged
-    # git-merge-base <headsha> <headsha> should tell
+    # git-find-merge-base <headsha> <headsha> should tell
     # me what the base of the merge should be 
     #
     my $ps = shift;
@@ -674,7 +674,7 @@ sub find_parents {
     # that branch.
     #
     foreach my $branch (keys %branches) {
-	my $mergebase = `git-merge-base $branch $ps->{branch}`;
+	my $mergebase = `git-find-merge-base $branch $ps->{branch}`;
 	die "Cannot find merge base for $branch and $ps->{branch}" if $?;
 	chomp $mergebase;
 
diff --git a/git-fetch.sh b/git-fetch.sh
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -113,7 +113,7 @@ fast_forward_local () {
 	if test -f "$GIT_DIR/$1"
 	then
 	    local=$(git-rev-parse --verify "$1^0") &&
-	    mb=$(git-merge-base "$local" "$2") &&
+	    mb=$(git-find-merge-base "$local" "$2") &&
 	    case "$2,$mb" in
 	    $local,*)
 		echo >&2 "* $1: same as $3"
diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh
--- a/git-merge-octopus.sh
+++ b/git-merge-octopus.sh
@@ -42,7 +42,7 @@ CNT=1 ;# counting our head
 NON_FF_MERGE=0
 for SHA1 in $remotes
 do
-	common=$(git-merge-base $MRC $SHA1) ||
+	common=$(git-find-merge-base $MRC $SHA1) ||
 		die "Unable to find common commit with $SHA1"
 
 	if test "$common" = $SHA1
diff --git a/git-merge.sh b/git-merge.sh
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -114,7 +114,7 @@ case "$#,$common" in
 	up_to_date=t
 	for remote
 	do
-		common_one=$(git-merge-base $head $remote)
+		common_one=$(git-find-merge-base $head $remote)
 		if test "$common_one" != "$remote"
 		then
 			up_to_date=f
diff --git a/git-octopus.sh b/git-octopus.sh
--- a/git-octopus.sh
+++ b/git-octopus.sh
@@ -33,7 +33,7 @@ CNT=1 ;# counting our head
 NON_FF_MERGE=0
 while read SHA1 REPO
 do
-	common=$(git-merge-base $MRC $SHA1) ||
+	common=$(git-find-merge-base $MRC $SHA1) ||
 		die "Unable to find common commit with $SHA1 from $REPO"
 
 	if test "$common" = $SHA1
diff --git a/git-resolve.sh b/git-resolve.sh
--- a/git-resolve.sh
+++ b/git-resolve.sh
@@ -31,7 +31,7 @@ dropheads
 echo $head > "$GIT_DIR"/ORIG_HEAD
 echo $merge > "$GIT_DIR"/LAST_MERGE
 
-common=$(git-merge-base $head $merge)
+common=$(git-find-merge-base $head $merge)
 if [ -z "$common" ]; then
 	die "Unable to find common commit between" $merge $head
 fi
@@ -55,7 +55,7 @@ esac
 # Find an optimum merge base if there are more than one candidates.
 LF='
 '
-common=$(git-merge-base -a $head $merge)
+common=$(git-find-merge-base -a $head $merge)
 case "$common" in
 ?*"$LF"?*)
 	echo "Trying to find the optimum merge base."
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -2266,7 +2266,7 @@ proc findgca {ids} {
 	    set gca $id
 	} else {
 	    if {[catch {
-		set gca [exec git-merge-base $gca $id]
+		set gca [exec git-find-merge-base $gca $id]
 	    } err]} {
 		return {}
 	    }
diff --git a/merge-base.c b/merge-base.c
deleted file mode 100644
--- a/merge-base.c
+++ /dev/null
@@ -1,171 +0,0 @@
-#include <stdlib.h>
-#include "cache.h"
-#include "commit.h"
-
-#define PARENT1 1
-#define PARENT2 2
-#define UNINTERESTING 4
-
-static struct commit *interesting(struct commit_list *list)
-{
-	while (list) {
-		struct commit *commit = list->item;
-		list = list->next;
-		if (commit->object.flags & UNINTERESTING)
-			continue;
-		return commit;
-	}
-	return NULL;
-}
-
-/*
- * A pathological example of how this thing works.
- *
- * Suppose we had this commit graph, where chronologically
- * the timestamp on the commit are A <= B <= C <= D <= E <= F
- * and we are trying to figure out the merge base for E and F
- * commits.
- *
- *                  F
- *                 / \
- *            E   A   D
- *             \ /   /  
- *              B   /
- *               \ /
- *                C
- *
- * First we push E and F to list to be processed.  E gets bit 1
- * and F gets bit 2.  The list becomes:
- *
- *     list=F(2) E(1), result=empty
- *
- * Then we pop F, the newest commit, from the list.  Its flag is 2.
- * We scan its parents, mark them reachable from the side that F is
- * reachable from, and push them to the list:
- *
- *     list=E(1) D(2) A(2), result=empty
- *
- * Next pop E and do the same.
- *
- *     list=D(2) B(1) A(2), result=empty
- *
- * Next pop D and do the same.
- *
- *     list=C(2) B(1) A(2), result=empty
- *
- * Next pop C and do the same.
- *
- *     list=B(1) A(2), result=empty
- *
- * Now it is B's turn.  We mark its parent, C, reachable from B's side,
- * and push it to the list:
- *
- *     list=C(3) A(2), result=empty
- *
- * Now pop C and notice it has flags==3.  It is placed on the result list,
- * and the list now contains:
- *
- *     list=A(2), result=C(3)
- *
- * We pop A and do the same.
- * 
- *     list=B(3), result=C(3)
- *
- * Next, we pop B and something very interesting happens.  It has flags==3
- * so it is also placed on the result list, and its parents are marked
- * uninteresting, retroactively, and placed back on the list:
- *
- *    list=C(7), result=C(7) B(3)
- * 
- * Now, list does not have any interesting commit.  So we find the newest
- * commit from the result list that is not marked uninteresting.  Which is
- * commit B.
- */
-
-static int show_all = 0;
-
-static int merge_base(struct commit *rev1, struct commit *rev2)
-{
-	struct commit_list *list = NULL;
-	struct commit_list *result = NULL;
-
-	if (rev1 == rev2) {
-		printf("%s\n", sha1_to_hex(rev1->object.sha1));
-		return 0;
-	}
-
-	parse_commit(rev1);
-	parse_commit(rev2);
-
-	rev1->object.flags |= 1;
-	rev2->object.flags |= 2;
-	insert_by_date(rev1, &list);
-	insert_by_date(rev2, &list);
-
-	while (interesting(list)) {
-		struct commit *commit = list->item;
-		struct commit_list *tmp = list, *parents;
-		int flags = commit->object.flags & 7;
-
-		list = list->next;
-		free(tmp);
-		if (flags == 3) {
-			insert_by_date(commit, &result);
-
-			/* Mark parents of a found merge uninteresting */
-			flags |= UNINTERESTING;
-		}
-		parents = commit->parents;
-		while (parents) {
-			struct commit *p = parents->item;
-			parents = parents->next;
-			if ((p->object.flags & flags) == flags)
-				continue;
-			parse_commit(p);
-			p->object.flags |= flags;
-			insert_by_date(p, &list);
-		}
-	}
-
-	if (!result)
-		return 1;
-
-	while (result) {
-		struct commit *commit = result->item;
-		result = result->next;
-		if (commit->object.flags & UNINTERESTING)
-			continue;
-		printf("%s\n", sha1_to_hex(commit->object.sha1));
-		if (!show_all)
-			return 0;
-		commit->object.flags |= UNINTERESTING;
-	}
-	return 0;
-}
-
-static const char merge_base_usage[] =
-"git-merge-base [--all] <commit-id> <commit-id>";
-
-int main(int argc, char **argv)
-{
-	struct commit *rev1, *rev2;
-	unsigned char rev1key[20], rev2key[20];
-
-	while (1 < argc && argv[1][0] == '-') {
-		char *arg = argv[1];
-		if (!strcmp(arg, "-a") || !strcmp(arg, "--all"))
-			show_all = 1;
-		else
-			usage(merge_base_usage);
-		argc--; argv++;
-	}
-	if (argc != 3 ||
-	    get_sha1(argv[1], rev1key) ||
-	    get_sha1(argv[2], rev2key))
-		usage(merge_base_usage);
-	rev1 = lookup_commit_reference(rev1key);
-	rev2 = lookup_commit_reference(rev2key);
-	if (!rev1 || !rev2)
-		return 1;
-	return merge_base(rev1, rev2);
-}
diff --git a/t/t4100/t-apply-1.patch b/t/t4100/t-apply-1.patch
--- a/t/t4100/t-apply-1.patch
+++ b/t/t4100/t-apply-1.patch
@@ -92,7 +92,7 @@ diff --git a/Makefile b/Makefile
 +++ b/Makefile
 @@ -30,7 +30,7 @@ PROG=   git-update-cache git-diff-files 
  	git-checkout-cache git-diff-tree git-rev-tree git-ls-files \
- 	git-check-files git-ls-tree git-merge-base git-merge-cache \
+ 	git-check-files git-ls-tree git-find-merge-base git-merge-cache \
  	git-unpack-file git-export git-diff-cache git-convert-cache \
 -	git-http-pull git-rpush git-rpull git-rev-list git-mktag \
 +	git-http-pull git-ssh-push git-ssh-pull git-rev-list git-mktag \
diff --git a/t/t4100/t-apply-5.patch b/t/t4100/t-apply-5.patch
--- a/t/t4100/t-apply-5.patch
+++ b/t/t4100/t-apply-5.patch
@@ -202,7 +202,7 @@ diff a/Makefile b/Makefile
 +++ b/Makefile
 @@ -30,7 +30,7 @@ PROG=   git-update-cache git-diff-files 
  	git-checkout-cache git-diff-tree git-rev-tree git-ls-files \
- 	git-check-files git-ls-tree git-merge-base git-merge-cache \
+ 	git-check-files git-ls-tree git-find-merge-base git-merge-cache \
  	git-unpack-file git-export git-diff-cache git-convert-cache \
 -	git-http-pull git-rpush git-rpull git-rev-list git-mktag \
 +	git-http-pull git-ssh-push git-ssh-pull git-rev-list git-mktag \
diff --git a/templates/hooks--update b/templates/hooks--update
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -15,7 +15,7 @@ then
 	echo "Created a new ref, with the following commits:"
 	git-rev-list --pretty "$3"
 else
-	$base=$(git-merge-base "$2" "$3")
+	$base=$(git-find-merge-base "$2" "$3")
 	case "$base" in
 	"$2")
 		echo "New commits:"

[RFC/Patch] Tool rename fallout fix

[Junio C Hamano]

Immediately after I updated the "master" branch with the tool
renames, I got a complaint from somebody telling me that the
things do not work anymore without 'make install'.

Strictly speaking, git has never worked fully without
installation because 'git' wrapper looked for things in the same
directory as it was in, which meant that 'git applymbox' would
not have worked anyway (it was coming from tools/applymbox until
recently), but on the other hand it certainly is nice if we can
run most of the things immediately after building but before
installing.

This patch attempts to remedy it.  What is helped the most is
that test scripts do not have to special case the scripts
anymore; obviously we do want to be able to run tests before
installing.  A downside is that your working tree after a build
has a lot more files than before.

As a side effect, you can specify non-standard path your Perl is
installed, and you can explicitly say "#!/usr/local/bin/bash".

Comments?


---
cd /opt/packrat/playpen/public/in-place/git/git.junio/
git diff HEAD
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -142,6 +142,13 @@ ifeq ($(shell uname -s),SunOS)
 	PLATFORM_DEFINES += -DNO_GETDOMAINNAME=1
 endif
 
+ifndef SHELL_PATH
+	SHELL_PATH = /bin/sh
+endif
+ifndef PERL_PATH
+	PERL_PATH = /usr/bin/perl
+endif
+
 ifndef NO_OPENSSL
 	LIB_OBJS += epoch.o
 	OPENSSL_LIBSSL = -lssl
@@ -179,21 +186,32 @@ endif
 
 DEFINES += '-DSHA1_HEADER=$(SHA1_HEADER)'
 
-SCRIPTS = $(SCRIPT_SH) $(SCRIPT_PERL) gitk
+SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
+	  $(patsubst %.perl,%,$(SCRIPT_PERL)) gitk
 
 ### Build rules
 
-all: $(PROGRAMS) git.sh
+all: $(PROGRAMS) $(SCRIPTS)
 
 all:
 	$(MAKE) -C templates
 
-git.sh: git.sh.in Makefile
+git: git.sh Makefile
 	rm -f $@+ $@
-	sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' <$@.in >$@+
+	sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' <$@.sh >$@+
 	chmod +x $@+
 	mv $@+ $@
 
+$(filter-out git,$(patsubst %.sh,%,$(SCRIPT_SH))) : % : %.sh
+	rm -f $@
+	sed -e '1s|#!.*/sh|#!$(SHELL_PATH)|' $@.sh >$@
+	chmod +x $@
+
+$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
+	rm -f $@
+	sed -e '1s|#!.*perl|#!$(PERL_PATH)|' $@.perl >$@
+	chmod +x $@
+
 %.o: %.c
 	$(CC) -o $*.o -c $(ALL_CFLAGS) $<
 %.o: %.S
@@ -250,19 +268,8 @@ check:
 
 install: $(PROGRAMS) $(SCRIPTS)
 	$(INSTALL) -m755 -d $(DESTDIR)$(bindir)
-	$(INSTALL) $(PROGRAMS) $(DESTDIR)$(bindir)
-	@for s in $(SCRIPTS); \
-	do \
-		case "$$s" in \
-		*.*) \
-			e=`expr "$$s" : '\(.*\)\.[^.]*$$'` ;; \
-		*) \
-			e="$$s" ;; \
-		esac && \
-		echo ": install $$s $(DESTDIR)$(bindir)/$$e" && \
-		$(INSTALL) $$s $(DESTDIR)$(bindir)/$$e || exit; \
-	done
-	$(INSTALL) git-revert.sh $(DESTDIR)$(bindir)/git-cherry-pick
+	$(INSTALL) $(PROGRAMS) $(SCRIPTS) $(DESTDIR)$(bindir)
+	$(INSTALL) git-revert $(DESTDIR)$(bindir)/git-cherry-pick
 	sh ./cmd-rename.sh $(DESTDIR)$(bindir)
 	$(MAKE) -C templates install
 
@@ -299,7 +306,8 @@ deb: dist
 
 clean:
 	rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROGRAMS) $(LIB_FILE)
-	rm -f git-core.spec git.sh
+	rm -f $(filter-out gitk,$(SCRIPTS))
+	rm -f git-core.spec
 	rm -rf $(GIT_TARNAME)
 	rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
 	rm -f git-core_$(GIT_VERSION)-*.deb git-core_$(GIT_VERSION)-*.dsc
diff --git a/git.sh.in b/git.sh
similarity index 100%
rename from git.sh.in
rename to git.sh
diff --git a/t/t1005-read-tree-m-2way-emu23.sh b/t/t1005-read-tree-m-2way-emu23.sh
--- a/t/t1005-read-tree-m-2way-emu23.sh
+++ b/t/t1005-read-tree-m-2way-emu23.sh
@@ -25,7 +25,7 @@ In the test, these paths are used:
 read_tree_twoway () {
     git-read-tree --emu23 "$1" "$2" &&
     git-ls-files --stage &&
-    git-merge-index ../../git-merge-one-file.sh -a &&
+    git-merge-index git-merge-one-file -a &&
     git-ls-files --stage
 }
 
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -13,12 +13,12 @@ handled.  Specifically, that a bogus bra
 test_expect_success \
     'prepare an trivial repository' \
     'echo Hello > A &&
-     ../../git-update-index --add A &&
-     ../../git-commit.sh -m "Initial commit."'
+     git-update-index --add A &&
+     git-commit -m "Initial commit."'
 
 test_expect_failure \
     'git branch --help should return error code' \
-    '../../git-branch.sh --help'
+    'git-branch --help'
 
 test_expect_failure \
     'git branch --help should not have created a bogus branch' \
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -21,9 +21,9 @@ test_expect_success setup '
 	    parent=$commit || return 1
 	done &&
 	echo "$commit" >.git/HEAD &&
-	git-clone.sh -l ./. victim &&
+	git-clone -l ./. victim &&
 	cd victim &&
-	git-log.sh &&
+	git-log &&
 	cd .. &&
 	echo $zero >.git/HEAD &&
 	parent=$zero &&
@@ -35,7 +35,7 @@ test_expect_success setup '
 	done &&
 	echo "$commit" >.git/HEAD &&
 	echo Rebase &&
-	git-log.sh'
+	git-log'
 
 test_expect_success \
         'pushing rewound head should not barf but require --force' ' 

No GIT 0.99.7 today

[Junio C Hamano]

I was planning to do 0.99.7 today but I need to delay it for a
couple of days.  I am expected to be offline for most of today.

[ANNOUNCE] GIT 0.99.7

[Junio C Hamano]

I am hoping that sending this out to the kernel list is not
considered too much of useless spamming, but I promise I
wouldn't do thit next time for 0.99.8, if I hear from somebody
not to.

Here comes GIT 0.99.7

--

Done in 0.99.7
==============

Organization
~~~~~~~~~~~~

Some commands and most scripts are renamed for consistency.

  - We have an official standard terminology list [*1*].  To
    match this, commands that operate on index files now have
    'index' instead of 'cache' in their names, and ones that
    download are called 'fetch' instead of 'pull'.

  - We used to install most of the commands that happen to be
    implemented as scripts as 'git-*-script', which was
    cumbersome to remember and type unless you always used 'git'
    wrapper.  They lost '-script' suffix from their names.

For now, we install synonyms as symbolic links so that old
names continue to work, but they are planned to be removed in
0.99.8 (or later if there are enough objections on the list --
so far I have heard none).

Also ancient environment variables [*2*] are not supported
anymore.


New Features and Commands
~~~~~~~~~~~~~~~~~~~~~~~~~

Downloaders that are not fully git aware have been taught about
the mechanism to borrow objects from other repositories via
objects/info/alternates the server side may be using.  'git
fetch' and 'git pull' commands over rsync and http transport
should be able to handle such repositories [*3*].

People found interesting cases where the 'stupid' three-way
merge mechanism does the wrong thing without noticing.  We have
two new merge algorithms by Daniel and Fredrik that attempt to
do better in such cases.  A new 'git merge' command has been
introduced to make it easier to experiment with and choose among
different merge strategies.  Note that 'git pull' still uses the
traditional three-way merge after downloading, but it is
expected to be switched to use 'git merge' sometime in the
future.

Importing from tla archives has been improved and documentated.

'git branch' command acquired '-d' flag to delete a branch that
has already been merged into the current branch.

'git bisect' command is easier to use by logging the earlier
good/bad choices and make it replayable.

'git repack' has -a' flag to pack the whole repository into a
single pack.

'git grep' is a new command to run grep on files 'git' knows
about.


Fixes
~~~~~

* 'git-diff-*' commands used to mark copy/rename incorrectly
  when an (A,B) => (B,C) rename was made.  We said the new B is
  a copy of old A, not a rename of old A.

* When the user exported CDPATH into environment, 'cd' took
  scripts to unexpected places.  Unset it upfront to guard us.

* 'git format-patch' knows about 'git cherry' and skips patches
  already merged upstream.

* hopefully plugged memory leak in diffcore-rename properly.

* commit walkers incorrectly assumed having a commit means we
  have the whole history leading up to it -- which is not true
  if the previous download was interrupted.  As a safety
  measure, we now only trust the commits that are pointed by the
  existing refs.

* 'git rev-list' uses a lot less memory.

* The build should be a bit friendlier to Solaris and Darwin now.

* 'git ssh-{push,pull}' are friendlier to tcsh.

* http transport is nicer to caching proxies.

* 'git daemon' port is registered with IANA.

* Many documentation updates.


[Footnotes]
*1* http://www.kernel.org/pub/software/scm/git/docs/glossary.html

*2* Ancient environment variable names: SHA1_FILE_DIRECTORIES
AUTHOR_DATE AUTHOR_EMAIL AUTHOR_NAME COMMIT_AUTHOR_EMAIL
COMMIT_AUTHOR_NAME SHA1_FILE_DIRECTORY

*3* But not grafts.

What to expect after GIT 0.99.7

[Junio C Hamano]

The GIT To-Do File
==================

  The latest copy of this document is found at 

    http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO


Tool Renames Plan
=================

 - All non-binary commands will lose -script suffix in
   $(bindir).  The source to git-foo will be either git-foo.sh
   or git-foo.perl in the source tree, and the documentation
   will be in Documentation/git-foo.txt.

 - The commands whose names have 'cache' to mean 'index file'
   will get 'cache' in their names replaced with 'index'. For
   git-fsck-cache and git-convert-cache, 'cache' will be
   replaced with 'objects'.

 - The commit walkers will have 'pull' in their names replaced
   with 'fetch'.  'git-ssh-push' will become 'git-ssh-upload'.

 - We continue to follow the convention to name the C source
   file that contains the main program of 'git-foo' command
   'foo.c'.  That means we will have 'fsck-objects.c', for
   example.

 - At this moment, I am not planning to rename the symbols used
   in programs, nor any library sources.  "cache.h" will stay
   "cache.h", so does "read-cache.c".  "struct cache_entry"  and
   "ce_match_stat()" will keep their names.  We _might_ want to
   rename them in later rounds but not right now.

 - In 0.99.7, all renamed commands will have symbolic links in
   $(bindir) so that old names continue to work.  These backward
   compatible names will not appear in documentation.  The main
   documentation, git(7) will talk about the new names but would
   mention their old names as historical notes.  Old environment
   names defined in gitenv() will also be removed in this release.

 - In 0.99.8, we do not install these backward compatible
   symbolic links in $(bindir) anymore.  The Makefile will have
   a target to remove old symlinks from $(DESTDIR)$(bindir) you
   can run manually to help you clean things up.

   The timeframe for this is around Oct 1st, but I could be
   talked into delaying the symlink removal if Porcelain people
   find this schedule too tight.


What to expect after 0.99.7
===========================

This is written in a form of to-do list for me, so if I say
"accept patch", it means I do not currently plan to do that
myself.  People interested in seeing it materialize please take
a hint.


Documentation
-------------

* Accept patches from people who actually have done CVS
  migration and update the cvs-migration documentation.
  Link the documentation from the main git.txt page.

* Accept patches from people who were hit by shiny blue bat to
  update the SubmittingPatches.

* Talk about using rsync just once at the beginning when
  initializing a remote repository so that local packs do not
  need to be expanded.  I personally do not think we need tool
  support for this (but see below about optimized cloning).

* Maybe update tutorial with a toy project that involves two or
  three developers..

* Update tutorial to cover setting up repository hooks to do
  common tasks.

* Accept patches to finish missing docs.


Technical (heavier)
-------------------

* Tony Luck reported an unfortunate glitch in the 3-way merge.
  Encourage discussions to come up with a not-so-expensive way
  to catch the kind of ambiguities that led to his misery.
  [Deathmatch between Daniel's and Fredrik's ongoing.]

* HPA has two projects, klibc and klibc-kbuild, that have large
  set of overlapping files in different paths (i.e. one has many
  renames from the other).  There currently is no way for git to
  help keep these two trees in sync, merging criss-cross between
  them.  The merge logic should be able to take advantage of
  rename/copy detection smarts git-diff-* family has.  Linus,
  me, and Daniel outlined a smarter merge strategy for this.
  Try them out.

* We might want to optimize cloning with GIT native transport
  not to explode the pack, and store it in objects/pack instead.
  We would need a tool to generate an idx file out of a pack
  file for this.  Also this itself may turn out to be a bad
  idea, making the set of packs in repositories everybody has
  different from each other.

* Libification.  There are many places "run once" mentality is
  ingrained in the management of basic data structures, which
  need to be fixed.

* Maybe a pack optimizer.

* Maybe an Emacs VC backend.


Technical (milder)
------------------

* The recent commit walker safety patch may be too cautious and
  appears to take forever when cloning.  This may even be
  infinitely looping in the code lifted from the old rev-list --
  needs to be taken a look at [DONE INITIAL CUT].

* Encourage concrete proposals to commit log message templates
  we discussed some time ago.

* Accept patches for more portability.

  * strcasestr() in mailinfo.  We may need compat/strcasestr.c;
    this is bugging OpenBSD folks.

* Accept patches to cause "read-tree -u" delete a directory when
  it makes it empty.

* Perhaps accept patches to introduce the concept of "patch flow
  expressed as ref mappings" Josef has been advocating about.

* Perhaps accept patches to do undo/redo.

* Perhaps accept patch to optionally allow '--fuzz' in
  'git-apply'.

* Allow 'git apply' to accept GNU diff 2.7 output that forgets
  to say '\No newline' if both input ends with incomplete
  lines.

* Maybe grok PGP signed text/plain in applymbox as well.

* Perhaps a tool to revert a single file to pre-modification
  state?  git-cat-file blob `git-ls-files | grep foo` >foo or
  git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should
  the command be called?  git-revert is taken so is
  git-checkout.

* Enhance "git repack" to not always use --all; this would be
  handy if the repository contains wagging heads like "pu" in
  git.git repository.

* Internally split the project into non-doc and doc parts; add
  an extra root for the doc part and merge from it; move the
  internal doc source to a separate repository, like the +Meta
  repository; experiment if this results in a reasonable
  workflow, and document it in howto form if it does.

* Make rebase restartable; instead of skipping what cannot be
  automatically forward ported, leave the conflicts in the work
  tree, have the user resolve it, and then restart from where it
  left off.

* Output full path in the "git-rev-list --objects" output, not
  just the basename, and see the improved clustering results in
  better packing [Tried, but did not work out well].

* Remove obsolete commands [READY].

* Option to limit rename detection for more than N paths [READY].

* Option to show only status and name from diff [READY].


Technical (trivial)
-------------------

* 'git add --recursive'?

* 'git merge-projects'?

* 'git lost-and-found'?  Link dangling commits found by
  fsck-objects under $GIT_DIR/refs/lost-found/.  Then
  show-branch or gitk can be used to find any lost commit. [A
  feeler patch sent out. Very underwhelming response X-<.]

  Do not name it /lost+found/; that would probably confuse
  things that mistake it a mount point (not our code but
  somebody else's).

* Add simple globbing rules to git-show-branch so that I can
  say 'git show-branch --heads "ko-*"' (ko-master, ko-pu, and
  ko-rc are in refs/tags/).

* We would want test scripts for the relative directory path
  stuff Linus has been working on.  So far, the following
  commands should be usable with relative directory paths:

    git-update-index
    git-ls-files
    git-diff-files
    git-diff-index
    git-diff-tree
    git-rev-list
    git-rev-parse

* In a freashly created empty repository, `git fetch foo:bar`
  works OK, but `git checkout bar` afterwards does not (missing
  `.git/HEAD`).

Re: What to expect after GIT 0.99.7

[Linus Torvalds]

On Sun, 18 Sep 2005, Junio C Hamano wrote:
> 
> * Accept patches for more portability.
> 
>   * strcasestr() in mailinfo.  We may need compat/strcasestr.c;
>     this is bugging OpenBSD folks.

Maybe something stupid like this?

Totally untested, of course.

		Linus
---
diff-tree 9b2d397a5d03514bdf3f545e459817c48579830f (from 727132834e6be48a93c1bd6458a29d474ce7d5d5)
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date:   Sun Sep 18 18:29:07 2005 -0700

Add stupid 'strcasestr()' compat routine

Signed-off-by: Linus Torvalds <torvalds@osdl.org>

---
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -9,6 +9,8 @@
 # Define NO_CURL if you do not have curl installed.  git-http-pull is not
 # built, and you cannot use http:// and https:// transports.
 #
+# Define NO_STRCASESTR if you don't have strcasestr.
+#
 # Define PPC_SHA1 environment variable when running make to make use of
 # a bundled SHA1 routine optimized for PowerPC.
 #
@@ -203,6 +205,10 @@ ifdef NEEDS_NSL
 	LIBS += -lnsl
 	SIMPLE_LIB += -lnsl
 endif
+ifdef NO_STRCASESTR
+	DEFINES += -Dstrcasestr=gitstrcasestr
+	LIB_OBJS += compat/strcasestr.o
+endif
 
 DEFINES += '-DSHA1_HEADER=$(SHA1_HEADER)'
 
diff --git a/compat/strcasestr.c b/compat/strcasestr.c
new file mode 100644
--- /dev/null
+++ b/compat/strcasestr.c
@@ -0,0 +1,22 @@
+#include <string.h>
+
+char *gitstrcasestr(const char *haystack, const char *needle)
+{
+	int nlen = strlen(needle);
+	int hlen = strlen(haystack) - nlen;
+	int i;
+
+	for (i = 0; i < hlen; i++) {
+		int j;
+		for (j = 0; j < nlen; j++) {
+			unsigned char c1 = haystack[i+j];
+			unsigned char c2 = needle[j];
+			if (toupper(c1) != toupper(c2))
+				goto next;
+		}
+		return (char *) haystack + i;
+	next:
+		;
+	}
+	return NULL;
+}

Re: What to expect after GIT 0.99.7

[Linus Torvalds]

On Sun, 18 Sep 2005, Linus Torvalds wrote:
> +++ b/compat/strcasestr.c
> @@ -0,0 +1,22 @@
> +#include <string.h>

That should be <ctype.h> of course.

		Linus

Re: What to expect after GIT 0.99.7

[Johannes Schindelin]

Hi,

On Sun, 18 Sep 2005, Linus Torvalds wrote:

> On Sun, 18 Sep 2005, Junio C Hamano wrote:
> > 
> > * Accept patches for more portability.
> > 
> >   * strcasestr() in mailinfo.  We may need compat/strcasestr.c;
> >     this is bugging OpenBSD folks.
> 
> Maybe something stupid like this?
>
> [...]

I like it. Git does not need a complicated Boyer-Moore algorithm, because 
that code path is not time critical.

However, I would like it a bit more, if it returned (const char*). After 
all, we do not need to comply with wrong interface definitions.

Ciao,
Dscho

Re: What to expect after GIT 0.99.7

[Joachim B Haga]

Linus Torvalds <torvalds@osdl.org> writes:

> >   * strcasestr() in mailinfo.  We may need compat/strcasestr.c;
> 
> Totally untested, of course.
>
> +	int hlen = strlen(haystack) - nlen;

int hlen = strlen(haystack) - nlen + 1;

(otherwise you'll miss match at the end)

-j.

Re: What to expect after GIT 0.99.7

[Linus Torvalds]

On Mon, 19 Sep 2005, Joachim B Haga wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
> 
> > >   * strcasestr() in mailinfo.  We may need compat/strcasestr.c;
> > 
> > Totally untested, of course.
> >
> > +	int hlen = strlen(haystack) - nlen;
> 
> int hlen = strlen(haystack) - nlen + 1;

Yeah. Duh.

		Linus

Re: What to expect after GIT 0.99.7

[Anton Altaparmakov]

On Sun, 18 Sep 2005, Junio C Hamano wrote:
[snip]
> * Perhaps a tool to revert a single file to pre-modification
>   state?  git-cat-file blob `git-ls-files | grep foo` >foo or
>   git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should
>   the command be called?  git-revert is taken so is
>   git-checkout.

How about git-clean?  (It cleans a "dirty" file..."  IIRC that is what bk 
used to call it so at least some people should be familliar with its name 
that way.)

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: What to expect after GIT 0.99.7

[Matthias Urlichs]

Hi, Junio C Hamano wrote:

> * Perhaps a tool to revert a single file to pre-modification
>   state?  git-cat-file blob `git-ls-files | grep foo` >foo or
>   git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should
>   the command be called?  git-revert is taken so is
>   git-checkout.

git-checkout can be extended to accept filenames, which would have the
additional benefit of enabling me to get any revision, not just HEAD.

So can git-reset.

I agree with Anton's "git clean"; with an optional -r <commit>
argument, that would be a better solution.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
BOFH excuse #396:

Mail server hit by UniSpammer.

Re: What to expect after GIT 0.99.7

[Junio C Hamano]

Matthias Urlichs <smurf@smurf.noris.de> writes:

> Hi, Junio C Hamano wrote:
>
>> * Perhaps a tool to revert a single file to pre-modification
>>   state?  git-cat-file blob `git-ls-files | grep foo` >foo or
>>   git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should
>>   the command be called?  git-revert is taken so is
>>   git-checkout.
>
> git-checkout can be extended to accept filenames, which would have the
> additional benefit of enabling me to get any revision, not just HEAD.
>
> So can git-reset.
>
> I agree with Anton's "git clean"; with an optional -r <commit>
> argument, that would be a better solution.

It probably is because I am BK untainted, but 'git clean' sounds
as if it would do 'git-ls-files --others | xargs rm -f'.

I used to do 'cvs update -p foo.c >foo.c', and extending
git-checkout may be familiar to cvs migrants.  The most
roundabout way (albeit with perhaps least typing) is:

    git-tar-tree HEAD | tar xf - foo.c

I originally talked about reverting file(s) in the working tree,
but I wonder if reverting a cache (eh, index) entry to the state
in a committed tree is useful.  read-tree with a pathspec to
overwrite index entries for specified paths while leaving others
intact.  We could think of it as undoing git-update-index.

Re: What to expect after GIT 0.99.7

[Petr Baudis]

Dear diary, on Mon, Sep 19, 2005 at 10:25:21AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Matthias Urlichs <smurf@smurf.noris.de> writes:
> 
> > Hi, Junio C Hamano wrote:
> >
> >> * Perhaps a tool to revert a single file to pre-modification
> >>   state?  git-cat-file blob `git-ls-files | grep foo` >foo or
> >>   git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should
> >>   the command be called?  git-revert is taken so is
> >>   git-checkout.
> >
> > git-checkout can be extended to accept filenames, which would have the
> > additional benefit of enabling me to get any revision, not just HEAD.
> >
> > So can git-reset.
> >
> > I agree with Anton's "git clean"; with an optional -r <commit>
> > argument, that would be a better solution.
> 
> It probably is because I am BK untainted, but 'git clean' sounds
> as if it would do 'git-ls-files --others | xargs rm -f'.

FWIW, that's also what cg-clean does. It uses cg-restore -f filename to
restore files to the state of the last commit, but it's not like I'd be
terribly happy about that.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: What to expect after GIT 0.99.7

[Linus Torvalds]

On Mon, 19 Sep 2005, Junio C Hamano wrote:
> 
> I used to do 'cvs update -p foo.c >foo.c', and extending
> git-checkout may be familiar to cvs migrants.  The most
> roundabout way (albeit with perhaps least typing) is:
> 
>     git-tar-tree HEAD | tar xf - foo.c

Uhh.

I use

	git-checkout-index -f -u foo.c

which works fine. Of course, that doesn't help if you've updated the
index, but then I actually think it's fine to expose the index.

Now, admittedly, we should probably make that easier to do.

If you want to reset to the HEAD state _and_ your index is stale, I'd just
precede it with a

	git reset

and be done. Yes, it will reset your whole index, not just that file, but 
hey, big deal. In practice it works fine.

> I originally talked about reverting file(s) in the working tree,
> but I wonder if reverting a cache (eh, index) entry to the state
> in a committed tree is useful.  read-tree with a pathspec to
> overwrite index entries for specified paths while leaving others
> intact.  We could think of it as undoing git-update-index.

Yes, I think it would be useful to be able to read in just part of the
tree.

		Linus

[ANNOUNCE] Cogito-0.15

[Petr Baudis]

  Hello,

  this is the release of Cogito-0.15. It fixes several minor bugs, and
adds a feature or two. The most important thing though is that this
depends on Git-core-0.99.7 and uses the new command names. Everyone is
encouraged to upgrade at least to this Cogito version in the next few
days, since the older Cogito versions likely won't work with the future
Git-core releases.

  To stay in sync with the Git terminology, Cogito also renames its
cg-pull to cg-fetch. Since this is a major naming change (I'm not too
happy about it, personally), cg-pull will stay aliased to cg-fetch for
at least one (likely two) next major Cogito releases (it also produces a
warning when invoked as cg-pull). In the more distant future, cg-pull
will slowly become the new name of cg-update, to make it confusing.

  While at it, we also renamed the *-id scriptlets to cg-*-id. Other
notable stuff is cg-init respecting the ignore rules, and better UI for
cg-add wrt. directories (including cg-add -r support).

  Now let's see what the usual bug-right-after-release (major release,
so a major bug?) will be this time.

  Happy hacking,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

Re: [ANNOUNCE] Cogito-0.15

[Pavel Machek]

Hi!

>   this is the release of Cogito-0.15. It fixes several minor bugs, and
> adds a feature or two. The most important thing though is that this
> depends on Git-core-0.99.7 and uses the new command names. Everyone is
> encouraged to upgrade at least to this Cogito version in the next few
> days, since the older Cogito versions likely won't work with the future
> Git-core releases.
> 
>   To stay in sync with the Git terminology, Cogito also renames its
> cg-pull to cg-fetch. Since this is a major naming change (I'm not too
> happy about it, personally), cg-pull will stay aliased to cg-fetch for
> at least one (likely two) next major Cogito releases (it also produces a
> warning when invoked as cg-pull). In the more distant future, cg-pull
> will slowly become the new name of cg-update, to make it confusing.

Could we keep at least the cg-update name? It is certainly not a
*pull* because it does update local repository (and tree, too).

								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: [ANNOUNCE] Cogito-0.15

[Petr Baudis]

Dear diary, on Tue, Sep 20, 2005 at 01:15:38AM CEST, I got a letter
where Pavel Machek <pavel@suse.cz> told me that...
> Hi!

Hi,

> >   this is the release of Cogito-0.15. It fixes several minor bugs, and
> > adds a feature or two. The most important thing though is that this
> > depends on Git-core-0.99.7 and uses the new command names. Everyone is
> > encouraged to upgrade at least to this Cogito version in the next few
> > days, since the older Cogito versions likely won't work with the future
> > Git-core releases.
> > 
> >   To stay in sync with the Git terminology, Cogito also renames its
> > cg-pull to cg-fetch. Since this is a major naming change (I'm not too
> > happy about it, personally), cg-pull will stay aliased to cg-fetch for
> > at least one (likely two) next major Cogito releases (it also produces a
> > warning when invoked as cg-pull). In the more distant future, cg-pull
> > will slowly become the new name of cg-update, to make it confusing.
> 
> Could we keep at least the cg-update name?

yes, I want to retain it. I'm not 100% decided yet whether to actually
use the pull term for anything in Cogito. Previous usage reportedly
confused some, the new usage actually confuses me and apparently some
other people. So I might just avoid the 'pull' term in the future
altogether. Not decided yet, though, and opinions obviously welcomed.

> It is certainly not a *pull* because it does update local repository
> (and tree, too).

AIUI, that's what makes it a pull for *cough* some people. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [ANNOUNCE] Cogito-0.15

[Linus Torvalds]

On Tue, 20 Sep 2005, Pavel Machek wrote:
> 
> Could we keep at least the cg-update name? It is certainly not a
> *pull* because it does update local repository (and tree, too).

That _is_ what "pull" means.

"fetch" is the one that only updates the history. A "pull" also does a
merge and updates the current branch _and_ the currently checked out tree.

		Linus

Re: [ANNOUNCE] GIT 0.99.7

[Nigel Cunningham]

Hi.

On Mon, 2005-09-19 at 09:37, Junio C Hamano wrote:
> I am hoping that sending this out to the kernel list is not
> considered too much of useless spamming, but I promise I
> wouldn't do thit next time for 0.99.8, if I hear from somebody
> not to.
> 
> Here comes GIT 0.99.7

Could you please include a url for anyone who might not know the
canonical address from which to download?

Regards,

Nigel

Re: [ANNOUNCE] GIT 0.99.7

[Chris White]

[-- Attachment #1: Type: text/plain, Size: 250 bytes --]

On Monday 19 September 2005 11:24, Nigel Cunningham wrote:

> Could you please include a url for anyone who might not know the
> canonical address from which to download?

http://www.kernel.org/pub/software/scm/git/

> Regards,

> Nigel

Chris White

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ANNOUNCE] GIT 0.99.7

[Alan Chandler]

On Monday 19 Sep 2005 13:01, Chris White wrote:
> On Monday 19 September 2005 11:24, Nigel Cunningham wrote:
> > Could you please include a url for anyone who might not know the
> > canonical address from which to download?
>
> http://www.kernel.org/pub/software/scm/git/
>
> > Regards,
> >
> > Nigel
>
> Chris White

Right now there is no tar files, only an rpm
-- 
Alan Chandler
http://www.chandlerfamily.org.uk