What's in git.git

What's in git.git

[Junio C Hamano]

Now 1.1.4 is out, here is a summary of what are not there but
already merged to the "master" branch (i.e. 1.2.0 material).

Build and Environment issues:

      Makefile: add 'strip' target
      Fix the installation location.
      Allow building of RPM from interim snapshot.
      Exec git programs without using PATH (Michal Ostrowski).
      Disable USE_SYMLINK_HEAD by default (Pavel Roskin)

CVS:

      git-cvsimport: Add -A <author-conv-file> option (Andreas).
      cvsimport: ease migration from CVSROOT/users format


Pushes and Pulls:

      git-push: avoid falling back on pushing "matching" refs.
      git-push: fix --tags and document it.
      clone: --naked option.
      Add --keep option to keep downloaded packs to git-fetch (Tom Prince).
      Fix generation of "humanish" part of source repo (Uwe Zeisberger)


Usability Enhancements:

      git-describe: default to HEAD

      Documentation: show-branch.
      show-branch: make the current branch and merge commits stand out.
      show-branch: --current includes the current branch.
      show-branch: take default arguments from configuration file.

      octopus: allow criss-cross and clarify the message when it rejects
      octopus: allow manual resolve on the last round.

      checkout: automerge local changes while switching branches.
      checkout: merge local modifications while switching branches.
      checkout: show dirty state upon switching branches.

      format-patch: always --mbox and show sane Date:

----------------------------------------------------------------

These are still cooking in "pu" branch.

Build and Environment:

      Makefile: do not assume lack of IPV6 means no sockaddr_storage.
      fsck-objects: support platforms without d_ino in struct dirent.
      DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN

      * These are for the latest Cygwin builds.

Documentation:

      New Tutorial (J. Bruce Fields)

      * Waiting for updates after the last round of comments.

Subproject:

      read-tree: --prefix=<path>/ option.
      write-tree: --prefix=<path>/ and --exclude=<prefix>/.
      commit-tree: --bind <sha1> <path>/ option.

      * Basic design has been outlined, and read-tree/write-tree
        are probably safe to push out, but commit objects that
        contain "bind" lines are unsafe until fsck-objects and
        rev-list are updated.

Annotate:

      rev-list: stop when the file disappears (Linus)

      * I've only taken a cursory look at this patch.

What's in git.git

[Junio C Hamano]

I've pushed out the following changes to "master" branch:

 * git-clone

   . --naked option is still accepted but is deprecated.  Please
     say --bare.

   . a repository cloned with --bare does not get "origin"
     branch, nor remotes/origin file.

   . Earlier we accepted more than one -o options, without
     complaining.  We now complain.

 * fetch and peek/ls-remote (Michal Ostrowski)

   . --upload-pack option to the underlying git-peek-remote and
     friends can be passed from the barebone Porcelain.

 * local push/pull environment fix (Matt Draisey)

   . We now clean "GIT_DIR" and friends from the environment
     when spawning a program on the other end to drive git
     native protocols on a local machine.  This uses unsetenv(),
     which is not strictly portable, but I was too lazy to fix
     it myself.  I am hoping that Jason Riedy will scream and
     give us a patch to make it work again on his Solaris box
     ;-).

 * sample update-hook rewrite (Andreas Ericsson)

 * asciidoc --unsafe workaround (Pavel Roskin)

In the "pu" branch, there are some interesting changes.  The
most immediately visible usability enhancement is the "combined
diff" option to git-diff-tree command.  Interested people can
try something like this:

	$ git checkout pu
	$ make clean strip all install
	$ git checkout master

Do not forget to come back to your "master" branch once you are
done, or your next pull would be screwed.

        $ git whatchanged --cc --abbrev pu

This would show an improved version of "git whatchanged -m -p".
The difference is that it uses the "dense combined diff"
suggested by Linus yesterday.  Commits near the tip of "pu" tend
to be Octopus, and you would see quite interesting combined
diffs for them.  I am not proud of the implementation itself,
and I am sure there are more bugs to be discovered, but overall
I am reasonably happy with what it shows.  Once it stabilizes,
it would be a good addition to gitweb UI.  In addition to the
"commitdiff" next to each parent, there would be an extra link
in a merge commit to get a combined diff.

The "annotate helper" change by Linus and "bound commit"
subproject support experiments are there as before.

There are other minor fixes and enhancements.  Not all of them
may make it to "master":

 * "diff-tree --abbrev --pretty" was still showing full 40
   characters of commit object names on "Merge:" line.

 * "rev-parse --abbrev[=<n>] $rev" is similar to
   "rev-parse --verify $rev", except that it shows an
   abbreviated object name.

 * The flag argument was handled confusingly by "rev-parse
   [--flags|--no-flags]".  The command now treats anything that
   come after --flags/--no-flags things to be parsed, not an
   option to control what the command does.  This was primarily
   needed to allow parsing out "--abbrev" option and giving it
   to "diff-tree" inside whatchanged.  All existing users have
   been adjusted to this change.  I do not think any of Cogito,
   gitk, nor stgit is affected.

Re: What's in git.git

[Junio C Hamano]

Santi Bejar <sbejar@gmail.com> writes:

> I think we should be consistent with respect the leading dots. Now the
> diff-tree line has the dots, but the merge line do not.

This is deliberate.  Merge lines do not have to align with
anything else for readability.

Re: What's in git.git

[Jason Riedy]

And Junio C Hamano writes:
 -      This uses unsetenv(), which is not strictly portable, but 
 - 	I was too lazy to fix it myself.

And you manage to catch me on the one day in the last month
I've played with git code...  Patch to add compat/unsetenv.c
coming shortly.  Passes unit tests and make test as well as 
before (I have some wierd, local-only cpio problems), but I 
haven't used this extensively.

People _with_ unsetenv can still add compat functions, you 
know.  ;)

Jason

Re: What's in git.git

[Junio C Hamano]

Santi Bejar <sbejar@gmail.com> writes:

> Junio C Hamano <junkio@cox.net> writes:
>...
>>         $ git whatchanged --cc --abbrev pu
>...
>       Then some comments :)
>
>       * There is an extra space between the +- and the content.

Thanks for noticing.  Fixed.

>       * I think the "diff command" could be just "diff --git".  And
>         "diff --git --cc" for the "dense combined diff".

I chose not say "--git" because I wanted to make sure people
would not run "git apply" by mistake.  I replaced them
with "--combined" and "--cc" to make the differences clearer.

>       * I miss the index lines

That would probably be easy to add in the later rounds if you
really want them, but I consider it lower priority for now.
This is designed to be human readable and not necessarily
machine applicable, so I do not see much point in showing them.

Mode changes, creation, deletion, rename, and copy may need to
be there, though.  The code currently punts on them.  Patches
welcome.

>       * In the case of 3 and more parents I find uninteresting the hunk
>         where the merge is equal to one (or more) of its children and
>         the rest are equal. For example the first hunk in 22573dd, where
>         all the children are equal expect the picked one:
>
> diff-tree 22573dd... (from parents)
> Merge: 92643a2 0359fe8 a428965 4aa079f
> Author: Junio C Hamano <junkio@cox.net>
> Date:   Wed Jan 25 03:51:37 2006 -0800
>
>     Merge lt/revlist,jc/diff,jc/bind
>
> diff --combined rev-list.c
> @@@@@ +37,7 @@@@@
>      static int dense = 1;
>      static int unpacked = 0;
>      static int bisect_list = 0;
> ---  static int tag_objects = 0;
> ---  static int tree_objects = 0;
> ---  static int blob_objects = 0;
> +++  static int list_objects = 0;
>      static int verbose_header = 0;
>      static int show_parents = 0;
>      static int hdr_termination = 0;

I noticed it and found it somewhat less interesting than others,
but left it the way.  It is "changed the same way from all of
these parents except this one", which is different from what I
culled in the version you are commenting on, i.e. "changed only
from one parent".

I've since updated the logic to drop these hunks as well.
Please take a look at the tip of "pu".

>       * Like you said in another thread, the line numbers of all the
>         files.

This is left as an exercise for the reader ;-)

> So, at the end, I suggest this output for the diff:
>...
> and this for the diff-raw:
>
> :100644 100644 56505b4... 538d21d... M  Makefile
> :100644 100644 30479b4... 538d21d... M  Makefile

I do not find this to be so interesting.  diff-raw is primarily
for quick sanity check and machine processing, so I'd rather not
play games when generating diff-raw in order to keep the latter
form of users sane.

Re: What's in git.git

[Junio C Hamano]

Santi Bejar <sbejar@gmail.com> writes:

> 2006/1/26, Junio C Hamano <junkio@cox.net>:
>> No comment on your message yet, but please fix your MUA so that
>> your messages do not get rejected by the mailing list software.
>>
>> I suspect it is base64 CTE that causes it.
>>
>>         Content-Type: text/plain; charset=UTF-8
>>         Content-Transfer-Encoding: base64
>
> Sorry, about that. But I didn't get any notification.

You do not need to feel sorry.  It's just your voice is not
heard as widely as it should have been, and you did not know
about it.

The spam filter just drops things on the floor without bothering
to notify potential spammers.

I think this patch would address your two issues (applies on top
of "pu"), but I have not had time to test it seriously enough.

-- >8 --
[PATCH] combine-diff: better hunk splitting.

It considered an otherwise unchanged line that had line removals
in front of it an interesting line, which caused hunks to have
one extra the trailing context line.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 combine-diff.c |  142 ++++++++++++++++++++++++++++++++++++++++++++++----------
 1 files changed, 116 insertions(+), 26 deletions(-)

0aa20bc0c276c3fcb7215ba9f591960178792261
diff --git a/combine-diff.c b/combine-diff.c
index 3b219a0..d94a93d 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -323,52 +323,142 @@ static unsigned long line_all_diff(struc
 	return different;
 }
 
-static int make_hunks(struct sline *sline, unsigned long cnt,
-		       int num_parent, int dense)
+static unsigned long adjust_hunk_tail(struct sline *sline,
+				      unsigned long all_mask,
+				      unsigned long hunk_begin,
+				      unsigned long i)
+{
+	/* i points at the first uninteresting line.
+	 * If the last line of the hunk was interesting
+	 * only because it has some deletion, then
+	 * it is not all that interesting for the
+	 * purpose of giving trailing context lines.
+	 */
+	if ((hunk_begin + 1 <= i) &&
+	    ((sline[i-1].flag & all_mask) == all_mask))
+		i--;
+	return i;
+}
+
+static unsigned long next_interesting(struct sline *sline,
+				      unsigned long mark,
+				      unsigned long i,
+				      unsigned long cnt,
+				      int uninteresting)
+{
+	while (i < cnt)
+		if (uninteresting ?
+		    !(sline[i].flag & mark) :
+		    (sline[i].flag & mark))
+			return i;
+		else
+			i++;
+	return cnt;
+}
+
+static int give_context(struct sline *sline, unsigned long cnt, int num_parent)
 {
 	unsigned long all_mask = (1UL<<num_parent) - 1;
 	unsigned long mark = (1UL<<num_parent);
 	unsigned long i;
 	int has_interesting = 0;
 
-	i = 0;
+	i = next_interesting(sline, mark, 0, cnt, 0);
+	if (cnt <= i)
+		return 0;
+
 	while (i < cnt) {
-		if (interesting(&sline[i], all_mask)) {
-			unsigned long j = (context < i) ? i - context : 0;
-			while (j <= i)
+		unsigned long j = (context < i) ? (i - context) : 0;
+		unsigned long k;
+		while (j < i)
+			sline[j++].flag |= mark;
+
+	again:
+		j = next_interesting(sline, mark, i, cnt, 1);
+		if (cnt <= j)
+			break; /* the rest are all interesting */
+
+		/* lookahead context lines */
+		k = next_interesting(sline, mark, j, cnt, 0);
+		j = adjust_hunk_tail(sline, all_mask, i, j);
+
+		if (k < j + context) {
+			/* k is interesting and [j,k) are not, but
+			 * paint them interesting because the gap is small.
+			 */
+			while (j < k)
 				sline[j++].flag |= mark;
-			while (++i < cnt) {
-				if (!interesting(&sline[i], all_mask))
-					break;
-				sline[i].flag |= mark;
-			}
-			j = (i + context < cnt) ? i + context : cnt;
-			while (i < j)
-				sline[i++].flag |= mark;
-			has_interesting = 1;
-			continue;
+			i = k;
+			goto again;
 		}
-		i++;
+
+		/* j is the first uninteresting line and there is
+		 * no overlap beyond it within context lines.
+		 */
+		i = k;
+		k = (j + context < cnt) ? j + context : cnt;
+		while (j < k)
+			sline[j++].flag |= mark;
+	}
+	return 1;
+}
+
+static int make_hunks(struct sline *sline, unsigned long cnt,
+		       int num_parent, int dense)
+{
+	unsigned long all_mask = (1UL<<num_parent) - 1;
+	unsigned long mark = (1UL<<num_parent);
+	unsigned long i;
+	int has_interesting = 0;
+
+	for (i = 0; i < cnt; i++) {
+		if (interesting(&sline[i], all_mask))
+			sline[i].flag |= mark;
+		else
+			sline[i].flag &= ~mark;
 	}
 	if (!dense)
-		return has_interesting;
+		return give_context(sline, cnt, num_parent);
 
 	/* Look at each hunk, and if we have changes from only one
 	 * parent, or the changes are the same from all but one
 	 * parent, mark that uninteresting.
 	 */
-	has_interesting = 0;
 	i = 0;
 	while (i < cnt) {
-		int j, hunk_end, same, diff;
+		unsigned long j, hunk_begin, hunk_end;
+		int same, diff;
 		unsigned long same_diff, all_diff;
 		while (i < cnt && !(sline[i].flag & mark))
 			i++;
 		if (cnt <= i)
 			break; /* No more interesting hunks */
-		for (hunk_end = i + 1; hunk_end < cnt; hunk_end++)
-			if (!(sline[hunk_end].flag & mark))
-				break;
+		hunk_begin = i;
+		for (j = i + 1; j < cnt; j++) {
+			if (!(sline[j].flag & mark)) {
+				/* Look beyond the end to see if there
+				 * is an interesting line after this
+				 * hunk within context span.
+				 */
+				unsigned long la; /* lookahead */
+				int contin = 0;
+				la = adjust_hunk_tail(sline, all_mask,
+						     hunk_begin, j);
+				la = (la + context < cnt) ?
+					(la + context) : cnt;
+				while (j <= --la) {
+					if (sline[la].flag & mark) {
+						contin = 1;
+						break;
+					}
+				}
+				if (!contin)
+					break;
+				j = la;
+			}
+		}
+		hunk_end = j;
+
 		/* [i..hunk_end) are interesting.  Now does it have
 		 * the same change with all but one parent?
 		 */
@@ -387,13 +477,13 @@ static int make_hunks(struct sline *slin
 		}
 		if ((num_parent - 1 <= same) || (diff == 1)) {
 			/* This hunk is not that interesting after all */
-			for (j = i; j < hunk_end; j++)
+			for (j = hunk_begin; j < hunk_end; j++)
 				sline[j].flag &= ~mark;
 		}
-		else
-			has_interesting = 1;
 		i = hunk_end;
 	}
+
+	has_interesting = give_context(sline, cnt, num_parent);
 	return has_interesting;
 }
 
-- 
1.1.4.g2cff

Re: What's in git.git

[Santi Bejar]

> I think this patch would address your two issues (applies on top
> of "pu"), but I have not had time to test it seriously enough.

It works here, thanks.

Just a little issue. With grafted commits the combined diff works but
the "Merge:" line is not shown.

Santi

What's in git.git

[Junio C Hamano]

Now the Kiwi thing is over, I have merged up most of the topic
branches I've been holding back to the master branch.

Here are the highlights:

 * "rev-list --remove-empty" by Linus, a step to help "annotate".

 * "diff -c/--cc" combined diff format.  When used with diff-tree,
   they make a merge commit a bit more readable.  They can also be
   used with diff-files with an unmerged index to see the difference
   to the working tree files from ours and theirs.

 * Fix "diff-tree" to honour info/grafts file while showing parents.
   When "rev-list --parents" output is piped to "diff-tree --stdin", I
   think it also should show a fake header, but that is not currently
   fixed.

 * "rev-parse v2.6.14..v2.6.16" fix by Linus, with a follow up fix to
   make "git whatchanged -- git-fetch-script" work again.

 * Various 'abbreviation' fixes.

I'd like to do a 1.2 release with these sometime next week, but I
would like to encourage people to upgrade to 1.1.5 (or tonight's
"master") sooner rather than waiting for 1.2, since previous versions
have a little problem that can lead to a core dump or worse.

The "bind commit" thing is still in "pu"; since the discussion somehow
stalled, it may stay there for a while.  I have not been exercising it
more than just using it in my regular workflow (meaning, I have not
seen any regression but no tests on the additional features) and have
not started playing with Porcelainish layer, primarily because I am
not in urgent need for subprojects myself.

What's in git.git

[Junio C Hamano]

I haven't heard major breakage around the new features scheduled
for 1.2.0 so far, except for the two-tree "diff-tree --cc" Linus
has already fixed, so the previous "What's new" is pretty much
unchanged.

One *major* change I am thinking about doing is to change my
workflow a bit.  So far, the proposed updates branch "pu" was
almost impossible to follow unless you are really a devoted git
developer, because it is always rebased to the latest master and
then topic branches are merged onto it.  While that keeps the
number of unnecessary merge nodes between master and pu to the
minimum, it actively discouraged for the branch to be followed
by developers.

I would like to rectify that.

So I have created another branch, "next".  This is managed quite
differently from "pu".  I'd promise these things:

 * It is to contain planned updates and merge from topic
   branches, just like "pu" currently does.  However, the topics
   merged there will not contain majorly whacky / unproven ones
   like bind commits and shallow clones, until the basic part
   proves sound during the list discussion.

 * I will not rewind or rebase the "next" branch.  Also I will
   not rebase the topic branches that are merged into it.

 * It would occasionally merge from "master" if only to prevent
   conflicts.

 * If there are patches sent to improve a topic branch in it,
   they will be applied to the topic branch, and then the topic
   branch is merged into "next", without any funny rewinding or
   rebasing of "next".  This will make the "next" branch
   cluttered with repeated merges from the same topic branch,
   but that is OK.  "next" will not be merged into "master",
   ever.

 * Once a topic is fully cooked, the topic branch will be merged
   into "master".

What this means is that "next" should be as easy to follow as
"master", but still is slightly ahead of "master" with not so
wildly experimental features.

Although there theoretically is no reason not to follow the
above principles I set for "next" to manage "pu", it will stay
wild for now until I get more comfortable with this workflow.

Now, what's in "next"?  Currently I have two topic branches
merged to it.

    * jc/nostat:
      ls-files: debugging aid for CE_VALID changes.
      "Assume unchanged" git: do not set CE_VALID with --refresh
      "Assume unchanged" git

    * jc/empty-commit:
      t6000: fix a careless test library add-on.
      Do not allow empty name or email.

Re: What's in git.git

[sean]

On Wed, 08 Feb 2006 22:47:54 -0800
Junio C Hamano <junkio@cox.net> wrote:


> One *major* change I am thinking about doing is to change my
> workflow a bit.  So far, the proposed updates branch "pu" was
> almost impossible to follow unless you are really a devoted git
> developer, because it is always rebased to the latest master and
> then topic branches are merged onto it.  While that keeps the
> number of unnecessary merge nodes between master and pu to the
> minimum, it actively discouraged for the branch to be followed
> by developers.

I've always followed it okay by just using "git branch -d pu" each time 
before pulling from you.   Your "next" branch does sound like an 
improvement though.

Sean

Re: What's in git.git

[Andreas Ericsson]

sean wrote:
> On Wed, 08 Feb 2006 22:47:54 -0800
> Junio C Hamano <junkio@cox.net> wrote:
> 
> 
> 
>>One *major* change I am thinking about doing is to change my
>>workflow a bit.  So far, the proposed updates branch "pu" was
>>almost impossible to follow unless you are really a devoted git
>>developer, because it is always rebased to the latest master and
>>then topic branches are merged onto it.  While that keeps the
>>number of unnecessary merge nodes between master and pu to the
>>minimum, it actively discouraged for the branch to be followed
>>by developers.
> 
> 
> I've always followed it okay by just using "git branch -d pu" each time 
> before pulling from you.   Your "next" branch does sound like an 
> improvement though.
> 

I thought

	Pull: +pu:pu

was supposed to handle such things automatically. It has always pulled 
properly for me anyways.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: What's in git.git

[sean]

On Thu, 09 Feb 2006 10:04:53 +0100
Andreas Ericsson <ae@op5.se> wrote:

> I thought
> 
> 	Pull: +pu:pu
> 
> was supposed to handle such things automatically. It has always pulled 
> properly for me anyways.
> 

The only problem with that is that Junio rebases and discards commits
periodically that will still be in your local pu branch.   The fetch/merge 
logic doesn't notice that commits have disappeared from Junio's pu branch.
So you'll end up with a union of all the pu branches in your local repo 
with commits that were dropped and never merged into mainline by Junio.

Unless you add changes to the pu branch locally you should never need
anything but a fast forward when pulling from Junio.  Except it breaks
when he rebases things.   The easy hackish "fix" is just to delete and repull
the branch which is always small anyway.

Sean

Re: What's in git.git

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> sean wrote:
>> I've always followed it okay by just using "git branch -d pu" each
>> time before pulling from you.   Your "next" branch does sound like
>> an improvement though.
>
> I thought
>
> 	Pull: +pu:pu
>
> was supposed to handle such things automatically. It has always pulled
> properly for me anyways.

Yes, fetching to look at is no problem, but what I wanted to
solve is that you cannot easily _touch_ it.  The point of this
is to make improving on top of what is still _not_ in master
easier for the contributors.

If you want to improve upon what is in the current "pu", the
natural thing for you to do would be:

	$ git fetch git://git.kernel.org/pub/scm/git/git +pu:pu
	$ git checkout -b my-pu pu ;# initial
        $ hack on it and git commit many times
        $ git format-patch --stdout pu..my-pu |
          git send-email --to junkio@cox.net --cc git@vger.kernel.org

(Side note: I do not know git-send-email would work like the
above, but if it did that might be handy.  Ryan?)

But sometimes you may take more time than how my "pu"
progresses, and you would want to sync your work to my updated
"pu".  A natural thing you would want to do is this:

        $ git pull git://git.kernel.org/pub/scm/git/git +pu:pu

Unfortunately, this would _not_ work very well, because by the
time you pull from my "pu" again, it would have rewound and
rebased.  You would end up seeing unnecessary merge conflicts.

Another possibility would be:

        $ git fetch git://git.kernel.org/pub/scm/git/git +pu:pu
        $ git rebase pu

This helps somewhat because "git rebase" uses "git cherry" to
detect the same patch with different commit ID in "pu" that you
already have in "my-pu".  But my topic branches have been
sometimes rewound and even rewritten to fix minor points (using
"reset --soft HEAD^" followed by "commit -a -c ORIG_HEAD"), and
when that happens "git rebase" would not be of much help.

The updated workflow on my part is trying to reduce these
problems by (1) not rewinding nor rebasing "next" and (2) not
rewinding nor rebasing the topic branches merged into "next".

Strictly speaking, the latter is not necessary (I would need to
resolve conflicts when merging the rewound/rebased topic
branches into "next", but after that is done, contributors who
pulled "next" do not have to deal with that, as long as "next"
itself is not rewound/rebased), but that way you could disect
component topic branches more easily out of "next".

For example, as of this writhing, my "master" and "next" look
like this:

    $ git show-branch --topo-order master next
    * [master] .gitignore git-rerere and config.mak
     ! [next] Merge branch 'jc/nostat'
    --
     - [next] Merge branch 'jc/nostat'
     + [next^2] "Assume unchanged" git: --really-refresh fix.
     - [next^] Merge branch 'jc/ls-files-o'
     + [next^^2] ls-files: honour per-directory ignore file ...
     - [next~2] Merge branches 'jc/nostat' and 'jc/empty-commit'
     + [next~2^3] t6000: fix a careless test library add-on.
     + [next~2^3^] Do not allow empty name or email.
     + [next^2^] ls-files: debugging aid for CE_VALID changes.
     + [next^2~2] "Assume unchanged" git: do not set CE_VALID...
     + [next^2~3] "Assume unchanged" git
    *+ [master] .gitignore git-rerere and config.mak

If you want to help fixing my thinko in jc/nostat branch, you
could:

	$ git checkout -b jc/nostat next^2
        $ fix fix fix; git commit

By convention, merge records what was the tip of the branch as
the first parent, and the second parent (and subsequent ones if
it is an Octopus) is the tip of the branch that was merged in,
so you can tell "next^2" is what was merged into the branch to
advance "next"; in other words, that is the tip of the jc/nostat
branch.  Similarly, you can tell the tip of jc/empty-commit was
merged to next~2 in an Octopus as the second merged-in branch,
so you can tell that its tip is next~2^3.

You could even publish your jc/nostat branch after you built on
it and tell me to pull from it to fix my stupidity.

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Wed, 8 Feb 2006, Junio C Hamano wrote:

> So I have created another branch, "next".

I never quite understood why you not just publish your topic branches. 
IMHO what you intend to put into "next" should be put into "master" 
anyway: everyone interested in git development should try the new features 
as early as possible. If there is a "whacky" feature, you can put it into 
"whacky/archexport" or something along the lines.

Ciao,
Dscho

Re: What's in git.git

[Andreas Ericsson]

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> 
>>sean wrote:
>>
>>>I've always followed it okay by just using "git branch -d pu" each
>>>time before pulling from you.   Your "next" branch does sound like
>>>an improvement though.
>>
>>I thought
>>
>>	Pull: +pu:pu
>>
>>was supposed to handle such things automatically. It has always pulled
>>properly for me anyways.
> 
> 
> Yes, fetching to look at is no problem, but what I wanted to
> solve is that you cannot easily _touch_ it.  The point of this
> is to make improving on top of what is still _not_ in master
> easier for the contributors.
> 
> If you want to improve upon what is in the current "pu", the
> natural thing for you to do would be:
> 
> 	$ git fetch git://git.kernel.org/pub/scm/git/git +pu:pu
> 	$ git checkout -b my-pu pu ;# initial
>         $ hack on it and git commit many times
>         $ git format-patch --stdout pu..my-pu |
>           git send-email --to junkio@cox.net --cc git@vger.kernel.org
> 

This is exactly what I do when I improve upon things in master, and 
according to numerous emails this is the recommended workflow.

> (Side note: I do not know git-send-email would work like the
> above, but if it did that might be handy.  Ryan?)
> 

With my (still un-published) git-send-patch you could do

	$ work, work, work
	$ git send-patch -s "Some subject for a prelude message" pu

and it would do the right thing.

I guess I'll have to get around to sending that thing in sooner or later.

> But sometimes you may take more time than how my "pu"
> progresses, and you would want to sync your work to my updated
> "pu".  A natural thing you would want to do is this:
> 
>         $ git pull git://git.kernel.org/pub/scm/git/git +pu:pu
> 

Do you mean
	$ git pull git://git.kernel.org/pub/scm/git/git +pu:my-pu

? Otherwise, I don't see how I can end up with merge-conflicts.

> Unfortunately, this would _not_ work very well, because by the
> time you pull from my "pu" again, it would have rewound and
> rebased.  You would end up seeing unnecessary merge conflicts.
> 
> Another possibility would be:
> 
>         $ git fetch git://git.kernel.org/pub/scm/git/git +pu:pu
>         $ git rebase pu
> 

Using my own topic-branch, this is what I always do. Conflicts that 
occur that way are always in my patches, so they would have to be 
reworked anyway. The new rerere tool should help if I dally too long.

Perhaps I'm just weird, but I never touch published branches.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: What's in git.git

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> IMHO what you intend to put into "next" should be put into "master" 
> anyway: everyone interested in git development should try the new features 
> as early as possible.

Yes, but I've been trying to be _very_ conservative to keep
"master" clean and stable, as I said in my inauguration speech.

Since git is still young and we are building features that are
needed in the field every day, it is very beneficial for users
to keep up-to-date with "master", and I would really like to
encourage that.  It saddens me to see git patches posted to the
kernel list marked with 0.99.9.GIT by prominent kernel people.

However, I do not want to see their time wasted on getting
bitten by stupid bugs I carelessly place on the "master" branch.
So I'd like to keep "master" conservative, stable and boring, at
least for now.

Instead of introducing "next", I could treat "pu" the way I said
I would do "next".  But even if I rid of its constant rewinding
nature, "pu" tends to have intrusive stuff near its tip and is
very hard to build on top of it.  Patches against the tip of
"pu" to fix things unrelated to the whacky ones often would be
inapplicable to "master".  This is especially true with what are
currently pending near the tip of "pu" (bind commits and shallow
clones).  I do not forsee them to graduate to "master" any time
soon.  Not in their current shape.

The promised "next" should be much easier to build on top of,
without disecting it into component topic branches, and it would
be the branch to track for people interested in git development
if you want to stay closer to the edge without touching bleeding
or even broken edge.  Making it easier to participate in git
development by people interested is what I am aiming at here.

I've considered publishing the topic branches individually.
Branches are cheap from the storage point of view (not really,
one inode and a filesystem block wasted to store only 41-bytes
;-)), but it needs management time and care (I will need to
remember to go to the repository and remove stale ones once they
are merged up).  Since branches in "next" are meant to be
short-lived, I am hoping it is easier for me to bundle them up
like I am planning.

On the other hand, long-lived whacky intrusive ones might be
better published as individual branches.  

Re: What's in git.git

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> This is exactly what I do when I improve upon things in master, and
> according to numerous emails this is the recommended workflow.

Yes.

> Do you mean
> 	$ git pull git://git.kernel.org/pub/scm/git/git +pu:my-pu

I do mean "+pu:pu".  In my illustration, "pu" is used in your
repository to track "pu" retrieved from me, and "my-pu" is a
fork you created from it and you build your changes upon.

	$ git pull $URL +pu:my-pu

is a shorthand for:

	$ git fetch $URL +pu:my-pu
        $ git merge "auto merge message" HEAD my-pu

and you definitely do not want to _fetch_ into my-pu when you
are on my-pu.

> ? Otherwise, I don't see how I can end up with merge-conflicts.

The problem is exactly why you need the plus sign when you fetch,
i.e. "+pu:pu".  My "pu" rebases.

Suppose I had this:

             o--o--o
            /      "pu"
	o--o
           "master"     

You do fetch +pu:pu, branch my-pu, and build on top of it:

                     o--o--o--o--o--o--o
                    /                  "my-pu"
             o--o--o
            /      "pu"
	o--o
           "master"

I add some to my "master" and rebuild "pu", maybe while adding
another commit on "pu".  You fetch +pu:pu again:

                     o--o--o--o--o--o--o
                    /                  "my-pu"
             o--o--o        o--o--o--o
            /              /         "pu" 
	o--o--o--o--o--o--o
                          "master"

Now, what happens when you merge "pu" into "my-pu"?  The three
commits I had on my previous "pu" are not part of the history of
the updated "pu" anymore, but is considered to be part of your
development trail.  If these had an addition of a file, and if
your development on top of the previous "pu" modified it, the
merge would result in:

 * originally the file did not exist.
 * "pu" adds it one way.
 * "my-pu" adds it in another way.

This requires a hand merge.  What should be done is for me to
instead of rebasing "pu", merge the updated master to "pu".

                     o--o--o--o--o--o--o
                    /                  "my-pu"
             o--o--o--------*--o
            /              /   "pu" 
	o--o--o--o--o--o--o
                          "master"

Then merge between "my-pu" and "pu" become easier.  You do not
have to worry about the earlier three commits, because the point
you forked from the previous "pu" becomes the merge base.

The reason I have not done it that way so far is primarily I am
lazy and also I do not like to see too many merges in the log.
Also "pu" tends to have really wacky stuff, so separating out
only usable bits, excluding wacky ones is slightly easier if I
rebuild it from scratch.

The new "next" aka "not too close to bleeding or broken edge"
branch will be managed like the last picture above, in order to
make working with it easier to manage.  This is only usable if I
do not include too bleeding-edge topic branch in it.

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Thu, 9 Feb 2006, Junio C Hamano wrote:

> Branches are cheap from the storage point of view (not really,
> one inode and a filesystem block wasted to store only 41-bytes
> ;-)), [...]

Not really. I use reiserfs which is quite efficient on these small files.

Hth,
Dscho

Re: What's in git.git

[Andreas Ericsson]

Junio C Hamano wrote:
> 
> The problem is exactly why you need the plus sign when you fetch,
> i.e. "+pu:pu".  My "pu" rebases.
> 
> Suppose I had this:
> 
>              o--o--o
>             /      "pu"
> 	o--o
>            "master"     
> 
> You do fetch +pu:pu, branch my-pu, and build on top of it:
> 
>                      o--o--o--o--o--o--o
>                     /                  "my-pu"
>              o--o--o
>             /      "pu"
> 	o--o
>            "master"
> 
> I add some to my "master" and rebuild "pu", maybe while adding
> another commit on "pu".  You fetch +pu:pu again:
> 
>                      o--o--o--o--o--o--o
>                     /                  "my-pu"
>              o--o--o        o--o--o--o
>             /              /         "pu" 
> 	o--o--o--o--o--o--o
>                           "master"
> 

But wouldn't rebase detect the commits as being the same, unless you've 
made changes to them? If it doesn't, can we teach it to discard parent 
info and re-hash the commits if they conflict? That should solve most 
such merge-conflicts, really.


> Now, what happens when you merge "pu" into "my-pu"?  The three
> commits I had on my previous "pu" are not part of the history of
> the updated "pu" anymore, but is considered to be part of your
> development trail.  If these had an addition of a file, and if
> your development on top of the previous "pu" modified it, the
> merge would result in:
> 
>  * originally the file did not exist.
>  * "pu" adds it one way.
>  * "my-pu" adds it in another way.
> 
> This requires a hand merge.  What should be done is for me to
> instead of rebasing "pu", merge the updated master to "pu".
> 
>                      o--o--o--o--o--o--o
>                     /                  "my-pu"
>              o--o--o--------*--o
>             /              /   "pu" 
> 	o--o--o--o--o--o--o
>                           "master"
> 
> Then merge between "my-pu" and "pu" become easier.  You do not
> have to worry about the earlier three commits, because the point
> you forked from the previous "pu" becomes the merge base.
> 
> The reason I have not done it that way so far is primarily I am
> lazy and also I do not like to see too many merges in the log.
> Also "pu" tends to have really wacky stuff, so separating out
> only usable bits, excluding wacky ones is slightly easier if I
> rebuild it from scratch.
> 
> The new "next" aka "not too close to bleeding or broken edge"
> branch will be managed like the last picture above, in order to
> make working with it easier to manage.  This is only usable if I
> do not include too bleeding-edge topic branch in it.
> 
> 

Good thinking. You're a marvel at explaining things.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: What's in git.git

[Tony Luck]

On 2/8/06, Junio C Hamano <junkio@cox.net> wrote:
>  * If there are patches sent to improve a topic branch in it,
>    they will be applied to the topic branch, and then the topic
>    branch is merged into "next", without any funny rewinding or
>    rebasing of "next".  This will make the "next" branch
>    cluttered with repeated merges from the same topic branch,
>    but that is OK.  "next" will not be merged into "master",
>    ever.
>
>  * Once a topic is fully cooked, the topic branch will be merged
>    into "master".

This is pretty much the workflow in my test/release branches (mostly
documented in Documentation/howto/using-topic-branches.txt).

I've sometimes wondered about re-creating the topic branches in
the case where there have been a series of follow-on commits
before pulling them into the release branch.  The goal would be
to present history not as it was, but as it should have been if we
didn't have all the dumb mistakes and typos.

So is there an easy way in git to take the series of commits
from a topic branch, make a new branch with all those commits
as just one commit ... with an open editor on the concatenated
commit comments (If there were just typo fixes the comment
from the first commit would apply, but sometimes the follow-on
commits would have substantive changes).

-Tony

Re: What's in git.git

[Ryan Anderson]

On Thu, Feb 09, 2006 at 03:14:59PM -0800, Tony Luck wrote:
> On 2/8/06, Junio C Hamano <junkio@cox.net> wrote:
> >  * If there are patches sent to improve a topic branch in it,
> >    they will be applied to the topic branch, and then the topic
> >    branch is merged into "next", without any funny rewinding or
> >    rebasing of "next".  This will make the "next" branch
> >    cluttered with repeated merges from the same topic branch,
> >    but that is OK.  "next" will not be merged into "master",
> >    ever.
> >
> >  * Once a topic is fully cooked, the topic branch will be merged
> >    into "master".
> 
> This is pretty much the workflow in my test/release branches (mostly
> documented in Documentation/howto/using-topic-branches.txt).
> 
> I've sometimes wondered about re-creating the topic branches in
> the case where there have been a series of follow-on commits
> before pulling them into the release branch.  The goal would be
> to present history not as it was, but as it should have been if we
> didn't have all the dumb mistakes and typos.
> 
> So is there an easy way in git to take the series of commits
> from a topic branch, make a new branch with all those commits
> as just one commit ... with an open editor on the concatenated
> commit comments (If there were just typo fixes the comment
> from the first commit would apply, but sometimes the follow-on
> commits would have substantive changes).

git checkout topic
git format-patch --stdout origin > topic-diff
$VISUAL topic-diff
# Fix comments
git checkout master
git checkout -b new-topic master
git-am topic-diff

.. done?

(I typically do something akin to this before sending patches to Junio,
by looking at the output of format-patch in a directory, editing,
combining a few changes if necessary, then re-committing, re-running
format-patch, and sending the output upstream.)

-- 

Ryan Anderson
  sometimes Pug Majere

Re: What's in git.git

[Junio C Hamano]

Tony Luck <tony.luck@intel.com> writes:

> So is there an easy way in git to take the series of commits
> from a topic branch, make a new branch with all those commits
> as just one commit ... with an open editor on the concatenated
> commit comments (If there were just typo fixes the comment
> from the first commit would apply, but sometimes the follow-on
> commits would have substantive changes).

I do not have a script to do so but my guess is that would be a
20-30 line shell script.  Use cherry to find which ones to pick,
run diff-tree on them to extract patches, run apply --index on
each of them in turn, and dump "git log master..topic" to your
editor and you are done.  The editor would have the commit log
to be edited while working tree and the index would have a
ready-to-commit tree with all the changes applied.

RE: What's in git.git

[Luck, Tony]

Looks very close to what I want.

> git checkout topic
> git format-patch --stdout origin > topic-diff

 topic-diff contains each commit as a separate message

> $VISUAL topic-diff
> # Fix comments

 so this needs some skill & care to rearrange the pieces
 and end up with legal input to git-am

Perhaps I'd like to have:

 git diff SHA-where-I-branched..HEAD

but I don't see the way to compute the SHA-where-I-branched

-Tony

Re: What's in git.git

[Junio C Hamano]

"Luck, Tony" <tony.luck@intel.com> writes:

> Looks very close to what I want.
>
>> git checkout topic
>> git format-patch --stdout origin > topic-diff
>
>  topic-diff contains each commit as a separate message
>
>> $VISUAL topic-diff
>> # Fix comments
>
>  so this needs some skill & care to rearrange the pieces
>  and end up with legal input to git-am
>
> Perhaps I'd like to have:
>
>  git diff SHA-where-I-branched..HEAD
>
> but I don't see the way to compute the SHA-where-I-branched
>
> -Tony

If what you want to end up with is a single commit, that is
easy.

If your topic branch is only "fork from master and never
re-merge with master but just pile new commits on top of the
tip, single strand of pearls" kind,

        git-merge-base master topic

would find the 'x' commit, where you forked from:

                           "master"
        ---x---o---o---o---o
            \
             o---o---o---o
                          "topic"

If you have "my topic will conflict with a change recently done
in master so let's merge up from master to resolve conflict
before going further" kind of merge commit on your topic branch,
then you cannot have a single two-tree diff easily anyway, but
in such a case, the following steps would work.

                           "master"
        ---o---o---o---o---o
            \       \
             o---o---*---o
                          "topic"

  (1) First merge "master" into "topic":

        $ git checkout topic
        $ git pull . master

                           "master"
        ---o---o---o---o---o
            \       \       \ 
             o---o---*---o---*
                             "topic"

      which would give you the rightmost '*' merge.

  (2) Extract diff from "master" to '*':

        $ git diff HEAD^2 HEAD >P.diff

      HEAD^1 is previous "topic" head and HEAD^2 is what you
      merged ("master").

  (3) Pick commits only on "topic" branch but not on "master"

        $ git rev-list --pretty --no-merges master..topic >P.log

      This will pick up the three 'o' commits on the lower
      development track and show their commit log message.


  (4) Reset the "topic" branch to "master", and do the squashed
      commit:

	$ git reset --hard master
        $ git apply --index P.diff
        $ git commit -F P.log -e

This obviously would work equally well for single strand of
pearls case.  Maybe you can package the above up, and send in a
patch to add "git-squash" command?

Re: What's in git.git

[Junio C Hamano]

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

> "Luck, Tony" <tony.luck@intel.com> writes:
>
>> Looks very close to what I want.
>>
>>> git checkout topic
>>> git format-patch --stdout origin > topic-diff
>>
>>  topic-diff contains each commit as a separate message
>>
>>> $VISUAL topic-diff
>>> # Fix comments
>>
>>  so this needs some skill & care to rearrange the pieces
>>  and end up with legal input to git-am
>>
>> Perhaps I'd like to have:
>>
>>  git diff SHA-where-I-branched..HEAD
>>
>> but I don't see the way to compute the SHA-where-I-branched
>>
>> -Tony
>
> If what you want to end up with is a single commit, that is
> easy.
>
> If your topic branch is only "fork from master and never
> re-merge with master but just pile new commits on top of the
> tip, single strand of pearls" kind,
>
>         git-merge-base master topic
>
> would find the 'x' commit, where you forked from:
>
>                            "master"
>         ---x---o---o---o---o
>             \
>              o---o---o---o
>                           "topic"
>
> If you have "my topic will conflict with a change recently done
> in master so let's merge up from master to resolve conflict
> before going further" kind of merge commit on your topic branch,
> then you cannot have a single two-tree diff easily anyway, but
> in such a case, the following steps would work.
>
>                            "master"
>         ---o---o---o---o---o
>             \       \
>              o---o---*---o
>                           "topic"
>
>   (1) First merge "master" into "topic":
>
>         $ git checkout topic
>         $ git pull . master
>
>                            "master"
>         ---o---o---o---o---o
>             \       \       \ 
>              o---o---*---o---*
>                              "topic"
>
>       which would give you the rightmost '*' merge.
>
>   (2) Extract diff from "master" to '*':
>
>         $ git diff HEAD^2 HEAD >P.diff
>
>       HEAD^1 is previous "topic" head and HEAD^2 is what you
>       merged ("master").
>
>   (3) Pick commits only on "topic" branch but not on "master"
>
>         $ git rev-list --pretty --no-merges master..topic >P.log
>
>       This will pick up the three 'o' commits on the lower
>       development track and show their commit log message.
>
>
>   (4) Reset the "topic" branch to "master", and do the squashed
>       commit:
>
> 	$ git reset --hard master
>         $ git apply --index P.diff
>         $ git commit -F P.log -e
>
> This obviously would work equally well for single strand of
> pearls case.  Maybe you can package the above up, and send in a
> patch to add "git-squash" command?

I am stupid.  (4) can be done a lot more easily.  Do not do step
(2) -- you do not need a diff at all.  But do do step (3) to get
the logs.  Then:

	$ git reset --soft master
        $ git commit -F P.log -e

What --soft reset does is to keep the index and the working tree
as is, but just change the current branch head to point at the
named commit.  So, immediately after the above soft reset, your
commit ancestry graph looks like this:

                            "master"
         ---o---o---o---o---o
                            "topic"

and the last commit finally would give you:


                            "master"
         ---o---o---o---o---o
                             \
                              o
                              "topic"

Re: What's in git.git

[Ryan Anderson]

On Thu, Feb 09, 2006 at 03:49:16PM -0800, Luck, Tony wrote:
> Looks very close to what I want.
> 
> > git checkout topic
> > git format-patch --stdout origin > topic-diff
> 
>  topic-diff contains each commit as a separate message
> 
> > $VISUAL topic-diff
> > # Fix comments
> 
>  so this needs some skill & care to rearrange the pieces
>  and end up with legal input to git-am

Doh, right, I was thinking "git apply" actually.  (Apply the whole thing
as  single diff - the comments from each commit in the middle should get
ignored.)

Note that I don't believe there is any need to combine the hunks, just
stick them there in order and it *should* do the right thing.

> Perhaps I'd like to have:
> 
>  git diff SHA-where-I-branched..HEAD
> 
> but I don't see the way to compute the SHA-where-I-branched

git-merge-base topic master ?

-- 

Ryan Anderson
  sometimes Pug Majere

Re: What's in git.git

[Junio C Hamano]

Ryan Anderson <ryan@michonline.com> writes:

> Note that I don't believe there is any need to combine the hunks, just
> stick them there in order and it *should* do the right thing.

Probably not.  I suspect it would not like two pieces of diffs
touching the same path in a batch.

Feeding one at a time is OK, though.

Re: What's in git.git

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> But wouldn't rebase detect the commits as being the same, unless
> you've made changes to them? If it doesn't, can we teach it to discard
> parent info and re-hash the commits if they conflict? That should
> solve most such merge-conflicts, really.

Yes, rebase would help somewhat (I said that didn't I?).  But
the thing is, with the "pu" workflow of mine so far, I _did_
rewrite/replace commits on my topic branches, especially when
they are young and not in a good shape.

For example, the topic branch jc/nostat ("Assume unchanged" git)
has four commits since it forked from the mainline:

 + [jc/nostat] "Assume unchanged" git: --really-refresh fix.
 + [jc/nostat^] ls-files: debugging aid for CE_VALID changes.
 + [jc/nostat~2] "Assume unchanged" git: do not set CE_VALID with --refresh
 + [jc/nostat~3] "Assume unchanged" git

With the "pu" workflow, I would have merged the "do not set
CE_VALID" commit and "--really-refresh fix" commit into the
first "Assume unchanged" commit after I found out about these
two small mistakes.  So one day "pu" would have contained what
is there right now as "jc/nostat~3", but the next day it would
have a commit, perhaps with slightly modified log message from
what is there as "jc/nostat~3" to contain fixes jc/nostat~2 and
jc/nostat have right now (the ls-files one is a debugging aid so
I would have left it separate even with the rewriting-history
workflow).

That kind of rewriting history is not being honest, but the end
result is that people do not have to see intermediate states and
earlier mistakes when things are fully cooked and ready to be
merged into the mainline.  By promising not to rewind "next" and
topic branches that go to "next", I am closing the door for me
to do this kind of history rewrite freely.  I can still rewrite
things I have not pushed out yet, though.

BTW, it is always a judgement call if it is a good thing to
squash commits into one like this.  Being too honest hurts the
usability of the history.  Especially if you have a trivial "Oh,
what I checked in does not even compile" kind of mistakes left
in the development trail, that would inconvenience bisection.
Being too sanitized OTOH tends to drop a single big ball of wax
into the history, and makes correcting things harder if it is
found later that only parts of that change are desired and the
other parts are not.

Re: What's in git.git

[Junio C Hamano]

Tony Luck <tony.luck@intel.com> writes:

> On 2/8/06, Junio C Hamano <junkio@cox.net> wrote:
> [ ... about the "next" branch ... ]
>
> This is pretty much the workflow in my test/release branches (mostly
> documented in Documentation/howto/using-topic-branches.txt).

Yup.  Sorry I did not make that clear.  You deserve the credit.

I am beginning to feel this workflow might benefit from some
tool support, but I haven't had enough experience to talk about
exactly what they are yet.

For example, listing topics that have ever been merged into a
particular branch, listing topics that have not been fully
merged into a particular branch, etc. are things I find myself
doing frequently.  I vaguely recall seeing your post that has
these things.

RE: What's in git.git

[Luck, Tony]

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

> Yup.  Sorry I did not make that clear.  You deserve the credit.
Thanks (and that wasn't a grumble, just a point of information)

> I am beginning to feel this workflow might benefit from some
> tool support, but I haven't had enough experience to talk about
> exactly what they are yet.
I feel that I have settled into a rut.  My topic workflow works
fairly well, so I'm not really working on cleaning any remaining
rough edges.  It will be good to have some other eyes (especially
some eyes that have been keeping a close eye on all the new features
that have been added to the rest of git) looking at this.

> For example, listing topics that have ever been merged into a
> particular branch, listing topics that have not been fully
> merged into a particular branch, etc. are things I find myself
> doing frequently.  I vaguely recall seeing your post that has
> these things.

At the end of the using-topic-branches file there is an example
"status" script.  My real script has had some updates (see attached)
that reports on extra bits (like whether Linus as made new packfiles
that I should pull down). And ignoring some special (to me) branch
names when reporting.  But it has lots of hard-coded paths for my
workflow. Branches "linus", "release" and "test" are very special.
I have no "master" or "origin" branches at all.  But the net output
seems to be what you want ... for each topic branch it reports
whether that branch has already been merged to the test/release/linus
branches, and whether I have commits in my release branch that are
not in test.

-Tony

[-- Attachment #2: tl-status --]
[-- Type: application/octet-stream, Size: 2073 bytes --]

#!/bin/bash

# report on status of my ia64 GIT tree

gb=$(tput setab 2)
rb=$(tput setab 1)
restore=$(tput setab 9)

# Get status of trees @ kernel.org
eval $(socksify ssh master.kernel.org '\
echo release=$(cat scm/linux-2.6.git/refs/heads/release) ; \
echo test=$(cat scm/linux-2.6.git/refs/heads/test) ; \
echo linus=$(cat torvalds/linux-2.6.git/refs/heads/master) ; \
echo packfiles=\"$(ls torvalds/linux-2.6.git/objects/pack)\" ')

cd /home/aegl/GIT/work

echo $gb ======= linus ====== $restore
local=`cat .git/refs/heads/linus`
if [ "$linus" = "$local" ]
then
	echo -e "\tUp to date"
else
	echo -e "\tNeed to pull from kernel.org"
fi

eval $(echo mypackfiles=\"$(ls .git/objects/pack)\")
if [ "$packfiles" != "$mypackfiles" ]
then
	echo $rb New packfiles in Linus tree $restore
	echo He has "<$packfiles>"
	echo I have "<$mypackfiles>"
fi

for branch in release test
do
	echo $gb ======= $branch ====== $restore
	local=`cat .git/refs/heads/$branch`
	if [ "${!branch}" = "$local" ]
	then
		echo -e "\tUp to date"
	else
		echo -e "\tNeed to push to kernel.org"
	fi
	if [ `git-rev-list linus ^$branch | wc -l` -gt 0 ]
	then
		echo -e "\tNeeds merge from linus"
	fi
done

if [ `git-rev-list release --no-merges ^test | wc -c` -gt 0 ]
then
	echo $rb Warning: commits in release that are not in test $restore
	git-whatchanged release ^test | git-shortlog
fi

for branch in `ls -rt .git/refs/heads | awk '{print $NF}'`
do
	case "$branch" in
	linus | release | test | base-* | bad-* | EXP-* )
		continue
		;;
	esac

	age=$(git-cat-file commit $branch | grep '^author' | awk '{print $(NF-1)}')
	echo -n $gb ======= $branch "(`showtime $age`)" ====== $restore " "
	status=
	for ref in test release linus
	do
		if [ `git-rev-list $branch ^$ref | wc -c` -gt 0 ]
		then
			status=$status${ref:0:1}
		fi
	done
	case $status in
	trl)
		echo $rb Need to pull into test $restore
		;;
	rl)
		echo "In test"
		;;
	l)
		echo "Waiting for linus"
		;;
	"")
		echo $rb All done $restore
		;;
	*)
		echo $rb "<$status>" $restore
		;;
	esac
	git-whatchanged $branch ^linus | git-shortlog
done

Re: What's in git.git

[Luck, Tony]

> >   (1) First merge "master" into "topic":
> >
> >         $ git checkout topic
> >         $ git pull . master
> >
> >   (3) Pick commits only on "topic" branch but not on "master"
> >
> >         $ git rev-list --pretty --no-merges master..topic >P.log
> >
> >       This will pick up the three 'o' commits on the lower
> >       development track and show their commit log message.
> >
> >
> > This obviously would work equally well for single strand of
> > pearls case.  Maybe you can package the above up, and send in a
> > patch to add "git-squash" command?
> 
> I am stupid.  (4) can be done a lot more easily.  Do not do step
> (2) -- you do not need a diff at all.  But do do step (3) to get
> the logs.  Then:
> 
> 	$ git reset --soft master
>         $ git commit -F P.log -e

Yes, that all seems to work as advertised.  One extra wrinkle was to
preserve the author information by grepping out the last Author: line
from the log.  Here's the work-in-progress version of git-squash (I
don't have a "master" branch, so I stuck in the "mbranch" shell variable
so there is only one place for me to change ... to mbranch=linus).

Any style (or other) comments?  If not I'll package into patch format
with a manual page in a few days.

-Tony

#!/bin/sh

. git-sh-setup

branch="$1"
mbranch=master

if [ ! -f .git/refs/heads/"$branch" ]
then
	die "Can't see branch '$branch'"
fi

if [ -f .git/refs/heads/"$branch"-unsquashed ]
then
	die "Branch '$branch' has been squashed before"
fi

cp .git/refs/heads/"$branch" .git/refs/heads/"$branch"-unsquashed

git checkout "$branch" || die "Couldn't checkout '$branch'"

git pull . $mbranch || die "Can't merge $mbranch into $branch"

git-rev-list --pretty --no-merges $mbranch..$branch > /tmp/git-squash-$$

git reset --soft $mbranch

author=$(sed -n -e  '/^Author: /s///p' /tmp/git-squash-$$ | tail -1)

git commit --author "$author" -F /tmp/git-squash-$$ -e

rm -f /tmp/git-squash-$$

What's in git.git

[Junio C Hamano]

* Master branch has these since 1.2.1 maintenance release.

  - documentation fixes:
    git-commit: Now --only semantics is the default.

  - usability:
    - rebase aquired a hook to refuse rebasing.
    - commit and add detects misspelled pathspec while making a partial commit.
    - git-svnimport: -r adds svn revision number to commit messages
    - properly git-bisect reset after bisecting from non-master head
    - send-email: Add some options for controlling how addresses
      are automatically added to the cc: list.
    - send-email: Add --cc

* Next branch has these, that are not in master.  If you feel
  you would benefit from these, testing and feedback is greatly
  appreciated.

 - "Assume unchanged git" series (7 commits):

   This was done in response to people on filesystems with slow
   lstat(2).  I do not have such an environment, so I cannot say
   I tested it that much.

 - "Rebase to different branch" (1 commit):

   This was previously discussed on the list.  With this command
   line:

    	$ git rebase --onto master~1 master topic
    
   would rebase this ancestry graph to:
    
              A---B---C topic
             /
        D---E---F---G master
    
    
   another graph that looks like this:
    
                  A'--B'--C' topic
                 /
        D---E---F---G master

   Earlier, you couldn't rebase to anywhere other than on top of
   "the other branch".


* Proposed updates "pu" branch has these, not in "next".  Some
  of them are of iffy nature, and without further work will not
  go anywhere.

 - "merge-tree" series by Linus (2 commits).

   I haven't spent enough time looking at and thinking about
   this yet.

 - "reuse pack data" (1 commit).

   I still haven't seen data corruption with this one, which is
   a good sign, but would like to keep beating it privately for
   a while.  Perhaps will graduate to "next" by next week.

 - "bind commit" series (6 commits).

   I think the core-side is more or less done with this one.
   Anybody interested in doing Porcelain side?

 - "shallow clone" series (1 commit).

   I should drop this one for now and perhaps when enough people
   are interested reopen the issue.

Re: What's in git.git

[linux]

 - "Rebase to different branch" (1 commit):

   This was previously discussed on the list.  With this command
   line:

    	$ git rebase --onto master~1 master topic
    
   would rebase this ancestry graph to:
    
              A---B---C topic
             /
        D---E---F---G master
    
    
   another graph that looks like this:
    
                  A'--B'--C' topic
                 /
        D---E---F---G master

   Earlier, you couldn't rebase to anywhere other than on top of
   "the other branch".


Er... what does this do, again?  I couldn't find the list discussion, and
I can get this exact effect in vanilla 1.2.1 with "git rebase master~1 topic".
AFAIK, $ARGV[1] of git-rebase only has to be a commit-ish, not a branch.

OTOH, I can imagine wanting
	$ git-rebase master~1 topic topic~2

to produce

              A   B---C topic
             /   /
        D---E---F---G master

H'm... I wonder if the same syntax could be used to resolve the ambiguous
case where there are multiple possible common ancestors, e.g.

              A---B---C topic
             /   /
        D---E---F---G master

as discussed in the "git rebase behaviour changed?" thread...

Re: What's in git.git

[Junio C Hamano]

linux@horizon.com writes:

> Er... what does this do, again?  I couldn't find the list
> discussion, and I can get this exact effect in vanilla 1.2.1
> with "git rebase master~1 topic".
>...
> OTOH, I can imagine wanting
>...
>               A   B---C topic
>              /   /
>         D---E---F---G master

Yup.  The example was a bad one, but the above, and in general

         X---A'--B'--C' topic

         D---E---F---G master

on an arbitrary X was what I wanted to do.

What's in git.git

[Junio C Hamano]

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

Alexandre Julliard:
      Add an Emacs interface in contrib.

Aneesh Kumar:
      Add contrib/gitview from Aneesh.

Aneesh Kumar K.V:
      Add a README for gitview
      gitview: typofix

Carl Worth:
      Trap exit to clean up created directory if clone fails.
      Abstract test_create_repo out for use in tests.
      Prevent git-upload-pack segfault if object cannot be found

Eric Wong:
      Introducing contrib/git-svn.
      git-svn: fix revision order when XML::Simple is not loaded
      git-svn: ensure fetch always works chronologically.
      git-svn: remove files from the index before adding/updating
      archimport: remove files from the index before adding/updating

Fernando J. Pereda:
      Allow building Git in systems without iconv

Jonas Fonseca:
      git-rev-parse: Fix --short= option parsing
      Document --short and --git-dir in git-rev-parse(1)

Junio C Hamano:
      rebase: allow rebasing onto different base.
      Detect misspelled pathspec to git-add
      topo-order: make --date-order optional.
      git-tag: -l to list tags (usability).
      Add contrib/README.
      SubmittingPatches: note on whitespaces

Martin Mares:
      Fix retries in git-cvsimport

Shawn Pearce:
      Make git-reset delete empty directories


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

Johannes Schindelin:
      Fix cpio call
      Optionally support old diffs
      Support Irix
      Optionally work without python

Junio C Hamano:
      pack-objects: reuse data from existing packs.
      pack-objects: finishing touches.
      git-repack: allow passing a couple of flags to pack-objects.
      pack-objects: avoid delta chains that are too long.
      Make "empty ident" error message a bit more helpful.
      Delay "empty ident" errors until they really matter.
      Keep Porcelainish from failing by broken ident after making changes.
      fmt-merge-msg: say which branch things were merged into unless 'master'
      Allow git-mv to accept ./ in paths.

Linus Torvalds:
      Handling large files with GIT
      Handling large files with GIT
      git-merge-tree: generalize the "traverse <n> trees in sync" functionality


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

Johannes Schindelin:
      Fixes for ancient versions of GNU make

Junio C Hamano:
      read-tree: --prefix=<path>/ option.
      write-tree: --prefix=<path>/ and --exclude=<prefix>/.
      commit-tree: --bind <sha1> <path>/ option.
      rev-list: simplify --object list generation.
      rev-list: understand bound commits.
      fsck-objects, convert-objects: understand bound commits.

What's in git.git

[Junio C Hamano]

The updated pack-object series is now in "next" branch, and
seems to be cooking nicely.  The "reuse from existing pack"
change seems to be a huge win and I haven't found problems in
there.

There now is further performance improvements for git-send-pack
to avoid sending a huge blob or tree object in its full
representation when we know the other end has a suitable object
to use as the base; instead we can just send it out deltified.
The other end would expand it to a loose object and this would
not make abit of difference in the resulting repository -- only
the bandwidth requirement reduction is visible [*1*].

In principle, this is also applicable for fetch-pack, but it
involves a bit of pack protocol change.  The protocol extension
mechanism was done nicely by Johannes a while ago, and we can
use it to implement this with full backward compatibility.

After a bit more testing, we might want to make --thin transfer
the default (even without an option to turn it off -- I just do
not see a point not to use it if it is bug-free).

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

Junio C Hamano:
      fmt-merge-msg: say which branch things were merged into unless 'master'
      Allow git-mv to accept ./ in paths.
      Documentation: fix typo in rev-parse --short option description.
      fmt-merge-msg: do not add excess newline at the end.
      Merge branch 'jc/mv'
      Merge branch 'jc/merge-msg'


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

Johannes Schindelin:
      Fixes for ancient versions of GNU make
      avoid makefile override warning
      Really honour NO_PYTHON

Junio C Hamano:
      Merge branch 'jc/merge-msg' into next
      Merge branch 'js/portable' into next
      rev-list --objects-edge
      Merge branch 'jc/rev-list' into next
      Thin pack - create packfile with missing delta base.
      send-pack --thin: use "thin pack" delta transfer.
      Merge branch 'jc/pack-thin' into next


[Footnote]

*1* The version of the patch I earlier sent to the list had a
grave performance bug; please do not use it.  The one in "next"
branch has the bug fixed already.

Re: What's in git.git

[Andreas Ericsson]

Junio C Hamano wrote:
> The updated pack-object series is now in "next" branch, and
> seems to be cooking nicely.  The "reuse from existing pack"
> change seems to be a huge win and I haven't found problems in
> there.
> 

Wonderful news. I'll cherry-pick them and do some further testing.

> There now is further performance improvements for git-send-pack
> to avoid sending a huge blob or tree object in its full
> representation when we know the other end has a suitable object
> to use as the base; instead we can just send it out deltified.
> The other end would expand it to a loose object and this would
> not make abit of difference in the resulting repository -- only
> the bandwidth requirement reduction is visible [*1*].
> 

How likely is this to increase the CPU-power needed on the server-side? 
If there is a blob on the server-side, but far from the deltified object 
I suppose we have to look at each commit, perhaps only to discover that 
the client doesn't have them and we need to construct the blob anyways.

> 
> After a bit more testing, we might want to make --thin transfer
> the default (even without an option to turn it off -- I just do
> not see a point not to use it if it is bug-free).
> 

If the answer to my question above is "minimal to none", I agree most 
vehemently. ;)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: What's in git.git

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> Junio C Hamano wrote:
>
>> There now is further performance improvements for git-send-pack
>> to avoid sending a huge blob or tree object in its full
>> representation when we know the other end has a suitable object
>> to use as the base; instead we can just send it out deltified.
>> The other end would expand it to a loose object and this would
>> not make abit of difference in the resulting repository -- only
>> the bandwidth requirement reduction is visible [*1*].
>
> How likely is this to increase the CPU-power needed on the
> server-side? If there is a blob on the server-side, but far from the
> deltified object I suppose we have to look at each commit, perhaps
> only to discover that the client doesn't have them and we need to
> construct the blob anyways.

Not much.  It deliberately keeps the set of blobs and trees to
consider for remote base to minimum -- just the trees contained
in the boundary commits.  That way we may miss the best base
candidate that are further back in history, but it does not
matter because even using the less optimum one as a base saves
us from sending the base object at all.

Re: What's in git.git

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> Junio C Hamano wrote:
>>
>> The updated pack-object series is now in "next" branch, and
>> seems to be cooking nicely.  The "reuse from existing pack"
>> change seems to be a huge win and I haven't found problems in
>> there.
>
> Wonderful news. I'll cherry-pick them and do some further testing.

BTW, the point of "next" is that you do not have to necessarily
cherry pick.  The topic branches in there are supposed to be in
testable shape.

Having said that, you could disect them out if you wanted to:

$ git log --pretty=oneline next | grep jc/pack- | head -n 8
5be4eabf90a4f6d14d3ae16772e6b2e063d71587 Merge branch 'jc/pack-thin' into next
bb837eccf42e5e8bbd4fe0927e7fa2afcfd2b564 Merge branch 'jc/pack-thin' into next
416b3cb4303e1a13ed05413bef7a0c1b9f7fc09e Merge branch 'jc/pack-reuse'
07e8ab9be913bd50595707f21a896ac15c4f5a89 Merge branch 'jc/pack-reuse'

The tip of jc/pack-reuse (that is the "reuse data from existing
packs" topic branch) jc/pack-thin ("thin packs") are at 416b3c^2
and 5be4ea^2 respectively.

So to check out the "reuse", you would:

$ git branch -f jc/pack-reuse 416b3c^2
$ git pull . jc/pack-reuse

If you want to try out "thin packs", you would need both
pack-objects change and rev-list change (the tip of jc/rev-list
is at 8c0db2^2).

$ git branch -f jc/rev-list 8c0db2^2
$ git branch -f jc/pack-thin 5be4ea^2
$ git pull . jc/pack-thin
$ git pull . jc/rev-list

What's in git.git

[Junio C Hamano]

Tonight's installment is a fairly huge update.  I am getting a
feeling that we should declare 1.3 real soon, once what's
cooking in the 'next' branch stabilizes.

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

 - Updates to gitview by Aneesh Kumar (contrib/)

   This is not shellquote safe, so please be careful if your
   GIT_DIR has shell metacharacters in it.

 - Various fixes and cleanups from Carl Worth, Jason Riedy and me.

 - Solaris 9+ portability bits by Paul Jakma.

 - Portability bits by Johannes Schindelin.

   "make -j" breakage was fixed.  Thanks.

 - gitk "fix find" update.  I failed to pull this one for some
   time.

 - "Assume unchanged git".

 - Reusing data from existing packs.

 - Perl 5.6 backward compatibility.

   Alex Riesen volunteered to further work on porting the
   "allegedly 5.6 compatible" constructs these patches use to
   work on ActiveState (whose 5.8 does not grok them).  We'll
   see what happens.


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

 - send-pack workaround for insanely large number of refs.

 - git-cvsserver by Martyn and Martin (and The Open University UK folks).

 - Delta updates by Nicolas Pitre.

   One part out of this four patch series seems to break diff
   tests so that one sits in 'pu' for now.

 - Other bits I mentioned in the previous message:

   - "Thin pack" bandwidth reduction for "git push" and "git
     fetch".

   - git-blame by Fredrik.

   - git-annotate by Ryan, with some enhancements from Johannes
     to make it usable with git-cvsserver.

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

 - git-rm by Carl Worth and Krzysiek Pawlik.

   This is not shellquote safe, so please be careful if you
   have files with shell metacharacters in their names.

 - Delta updates by Nicolas Pitre.

 - "Bound commit" lowlevel machinery for subprojects support.

Re: What's in git.git

[Alex Riesen]

On 2/22/06, Junio C Hamano <junkio@cox.net> wrote:
>  - Perl 5.6 backward compatibility.
>
>    Alex Riesen volunteered to further work on porting the
>    "allegedly 5.6 compatible" constructs these patches use to
>    work on ActiveState (whose 5.8 does not grok them).  We'll
>    see what happens.

Well, I'll have to.
The alternative is Perforce which is too much pain to explain...

What's in git.git

[Junio C Hamano]

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

Junio C Hamano:
      gitview: ls-remote invocation shellquote safety.
      detect broken alternates.
      git-fetch: follow tag only when tracking remote branch.
      Merge fixes up to GIT 1.2.3

Nicolas Pitre:
      nicer eye candies for pack-objects
      also adds progress when actually writing a pack


* The 'next' branch, in addition, has these (not much changed).

 - git-rm from Carl Worth.  I think this is ready.

 - git-cvsserver from Martin.  I think this is ready.

 - git-annotate and git-blame from Ryan and Friedrik.

 - "thin pack" pack transfer optimization.

 - delta optimization from Nicolas Pitre.


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

 - "bind commit"

 - delta optimization bits from Nicolas.

What's in git.git

[Junio C Hamano]

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

  - Cygwin related fixes (Alex Riesen) [*]
  - git-rm fixes and docs (Carl Worth)
  - gitview updates (Aneesh Kumar, Pavel Roskin)
  - git-svn updates (Eric Wong)
  - git-cvsserver (Martin Langhoff, Johannes Schindelin)
  - git-annotate (Ryan Anderson)
  - format-patch fix (Alexandre Julliard)
  - fix send-pack to a remote with insanely large number of refs [*]
  - "thin" pack git-push/git-fetch.
  - eye candies to checkout [*].
  - error() formatting fixes [*].
  - git-am empty commit prevention [*].
  - git-mailinfo now is built and installed again.
  - fix two sample hooks [*].
  - diffcore-rename and diffcore-break microfix [*].
  - svnimport enhancements (Karl Hasselström)
  - git-fetch output tweak (Lukas Sandström)
  - start to do more things in git wrapper (Linus)
  - combine-diff fixes (Mark Wooding) [*]
  - ls-files -i -o fix (Shawn Pearce)
  - Darwin related fix (Shawn Pearce)
  - compilation warning fixes (Timo Hirvonen, Tony Luck, Andreas Ericsson)

  The changes marked with [*] will appear in the next
  maintenance release; they are either first applied to 1.2.X
  maintenance branch and pulled into master, or first applied to
  master and then cherry picked to 1.2.X maintenance branch.

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

  I wanted to have this out to "master", but ran out of time.
  The same set of changes are already cherry-picked and waiting
  for inclusion in the next maintenance release.

  - git-apply trailing whitespace warning (Linus and me)

  These are waiting for further progress by authors:

  - git-blame (Fredrik Kuivinen)
  - delta packer updates for tighter packs (Nicolas Pitre)

  These are here only because they are new, not because I have
  any qualms about them:

  - for_each_ref warning (Johannes Schindelin)
  - prepare to make rename/break detection independent from delta packing.
  - checkout-index --stdin (Shawn Pearce)

  These are here because they are rather important and I am
  playing it safe.

  - beginning of rev-list libification (Linus)
  - git-log without shell script (Linus and me) 

  I am almost happy about this.  Now the author mapping format
  is the same between cvs/svn importers, would it make sense to
  unify them so that other foreign scm interface can also follow
  suit?  Usually you would not have upstreams with two different
  foreign scm to a single repository anyway, so this may not be an
  issue, though...

  - git-svnimport save author name mapping to a file (Karl Hasselström)

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

  This is in preparation for Nico's delta work already in "next".

  - make rename/break detection independent from delta packing.

  These muddy the water for what is in "next", improving of
  which is more important.

  - diff-delta: cull collided hash bucket more aggressively.
  - diff-delta: allow reusing of the reference buffer index (Nicolas Pitre)

  I am not sure about the command line interface of this.  Would
  it make more sense to checkout three stages in one pass?

  - checkout-index --suffix (Shawn Pearce)

Re: What's in git.git

[Nicolas Pitre]

On Wed, 1 Mar 2006, Junio C Hamano wrote:

>   These are waiting for further progress by authors:
> 
>   - delta packer updates for tighter packs (Nicolas Pitre)

Please don't wait to merge the first two patches to diff-delta.c.  They 
are purely cleanups with no functional differences.


Nicolas

Re: What's in git.git

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Wed, 1 Mar 2006, Junio C Hamano wrote:
>
>>   These are waiting for further progress by authors:
>> 
>>   - delta packer updates for tighter packs (Nicolas Pitre)
>
> Please don't wait to merge the first two patches to diff-delta.c.  They 
> are purely cleanups with no functional differences.

I presume you mean these three?

    commit 8e1454b5ad285ec5dd25758e799c589045aff9d4
    Author: Nicolas Pitre <nico@cam.org>

        diff-delta: big code simplification

    commit fe474b588b3cb1c23c987a3d0f9e869a160d82d2
    Author: Nicolas Pitre <nico@cam.org>

        diff-delta: fold two special tests into one plus cleanups

    commit cac251d0bc4c68b7ab36026990aff3c783913ae6
    Author: Nicolas Pitre <nico@cam.org>

        relax delta selection filtering in pack-objects

Re: What's in git.git

[Luck, Tony]

On Wed, Mar 01, 2006 at 04:24:14AM -0800, Junio C Hamano wrote:
> * The 'master' branch has these since the last announcement.
>   - compilation warning fixes (Timo Hirvonen, Tony Luck, Andreas Ericsson)

In commit 8fcf1ad9c68e15d881194c8544e7c11d33529c2b you put in a
combination of my double cast and Andreas' switch to using
unsigned long ... just the latter is sufficient (and a lot less
ugly than using the double cast).

Signed-off-by: Tony Luck <tony.luck@intel.com>

--

diff --git a/pack-objects.c b/pack-objects.c
index 21ee572..136a7f5 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -99,7 +99,7 @@ static int reused_delta = 0;
 
 static int pack_revindex_ix(struct packed_git *p)
 {
-	unsigned long ui = (unsigned long)(long)p;
+	unsigned long ui = (unsigned long)p;
 	int i;
 
 	ui = ui ^ (ui >> 16); /* defeat structure alignment */

What's in git.git

[Junio C Hamano]

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)

Re: What's in git.git

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> 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".

Re: What's in git.git

[Linus Torvalds]

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--;
 	}

Re: What's in git.git

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> 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")...

Re: What's in git.git

[Martin Langhoff]

On 3/5/06, Junio C Hamano <junkio@cox.net> 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

Re: What's in git.git

[Alexandre Julliard]

"Martin Langhoff" <martin.langhoff@gmail.com> 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

Re: What's in git.git

[Junio C Hamano]

"Martin Langhoff" <martin.langhoff@gmail.com> 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".

Re: What's in git.git

[Martin Langhoff]

On 3/5/06, Alexandre Julliard <julliard@winehq.org> 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

Re: What's in git.git

[Alexandre Julliard]

"Martin Langhoff" <martin.langhoff@gmail.com> 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

Re: What's in git.git

[Linus Torvalds]

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;
 }

Re: What's in git.git

[Linus Torvalds]

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

Re: What's in git.git

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> 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.

Re: What's in git.git

[Junio C Hamano]

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>

Re: What's in git.git

[Linus Torvalds]

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

What's in git.git

[Junio C Hamano]

The "deathmatch" between Ryan's annotate and Fredrik's blame is
officially on.  Currently the last test in all three branches
fail.  Please do not get alarmed.

I'd like asciidoc tweaks in "next" by Francis Daly tested by
people who have access to different vintages of docbook-xsl by
trying to build manpages.  Look for displayed examples, such as
the one in git-branch documentation.  I've tried it with v1.68
and getting far better results than before, and Francis says
v1.69 works fine with or without the change. IOW this is a
workaround for a problem in v1.68.

I've been tweaking on-and-off the similarity estimator in the
"next" branch.  It has become independent from the xdelta code
used for pack generation.  It may detect more renames that it
missed before, and it may miss some other renames and copies.
In general, it seems that the algorithm tends to detect slightly
more breaks than before.  I'd appreciate feedback from people
interested in this area.

Another thing I have started in "pu" branch is to stop placing
an object we decided to delta that is already max-depth deep
back in the delta-base window, because such a thing only wastes
the delta base slot.  The changed pack-objects does pick up more
delta, but the resulting pack seems bigger and I am puzzled why.

This may suggest that our criteria to delta should be tightened
a bit (the value of max_size in try_delta should be decreased).
We are better off storing a plain deflated representation instad
of generating a bad, bigger delta.  Insights?

-- -- --

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

- Documentation fixes (Dmitry V. Levin, Mark Wooding, Martin
  Langhoff, Jeff Muizelaar)

  git/Documentation: fix SYNOPSIS style bugs
  Documentation/Makefile: Some `git-*.txt' files aren't manpages.
  cvsserver: updated documentation
  cosmetics: change from 'See-Also' to 'See Also'
  documentation: add 'see also' sections to git-rm and git-add

- The deathmatch between annotate/blame (Ryan Anderson, Fredrik
  Kuivinen, me cheerleading)

  annotate: Support annotation of files on other revisions.
  git-blame: Make the output human readable
  git-blame: Use the same tests for git-blame as for git-annotate
  blame: avoid -lm by not using log().
  blame and annotate: show localtime with timezone.
  blame: avoid "diff -u0".
  annotate/blame tests updates.
  annotate-blame test: don't "source", but say "."
  annotate-blame test: add evil merge.

- Tweak rev-list (Linus Torvalds)

  get_revision(): do not dig deeper when we know we are at the end.

- Fix git-commit --amend (me)

  git-commit --amend: allow empty commit.

- Misc fixes and cleanups (Mark Wooding and me)

  gitignore: Ignore some more boring things.
  contrib/emacs/Makefile: Provide tool for byte-compiling files.
  Const tightening.

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

- Fix manpage formatting (Francis Daly)

  Tweak asciidoc output to work with broken docbook-xsl

- Tweak break/rename/copy similarity estimator tweaks (me)

  diffcore-rename: similarity estimator fix.
  count-delta: no need for this anymore.
  diffcore-break: similarity estimator fix.
  diffcore-delta: make change counter to byte oriented again.

- Help pack generation tweaks (me)

  verify-pack -v: show delta-chain histogram.

- checkout-index --temp (Shawn Pearce)

  Add --temp and --stage=all options to checkout-index.

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

- WIP: pack generation tweak (me)

  [WIP] do not waste delta window with objects with already at max-depth.

Re: What's in git.git

[Martin Langhoff]

On 3/6/06, Junio C Hamano <junkio@cox.net> wrote:
> - The deathmatch between annotate/blame (Ryan Anderson, Fredrik
>   Kuivinen, me cheerleading)

Add fuel to the fire  ;-) Can git-blame take cached git-rev-list
output like annotate does with -S?


m

Re: What's in git.git

[Johannes Schindelin]

Hi,

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

> Another thing I have started in "pu" branch is to stop placing
> an object we decided to delta that is already max-depth deep
> back in the delta-base window, because such a thing only wastes
> the delta base slot.  The changed pack-objects does pick up more
> delta, but the resulting pack seems bigger and I am puzzled why.

Not that I know much about the pack format, but is it possible that the 
deltas are deflated? In that case, a possible explanation is that a better 
delta is less compressible (and taken together, this could amount to more 
bytes).

Ciao,
Dscho

Re: What's in git.git

[Lukas Sandström]

Junio C Hamano wrote:
 
> I'd like asciidoc tweaks in "next" by Francis Daly tested by
> people who have access to different vintages of docbook-xsl by
> trying to build manpages.  Look for displayed examples, such as
> the one in git-branch documentation.  I've tried it with v1.68
> and getting far better results than before, and Francis says
> v1.69 works fine with or without the change. IOW this is a
> workaround for a problem in v1.68.
> 

I tested it with asciidoc 7.0.1 and the examples in the git-branch 
man page look better with the fix.

/Lukas

Before:
 Examples
       Start development off of a know tag


              $  git  clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 $
              cd my2.6 $ git branch my2.6.14 v2.6.14 $ git checkout my2.6.14

               These two steps are the same as "checkout -b my2.6.14 v2.6.14".

       Delete unneeded branch


              $  git clone git://git.kernel.org/.../git.git my.git $ cd my.git
              $ git branch -D todo

               delete todo branch even if the "master" branch  does  not  have
              all commits from todo branch.

After:
   Examples
       Start development off of a know tag

              $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
              $ cd my2.6
              $ git branch my2.6.14 v2.6.14
              $ git checkout my2.6.14

               These two steps are the same as "checkout -b my2.6.14 v2.6.14".


       Delete unneeded branch

              $ git clone git://git.kernel.org/.../git.git my.git
              $ cd my.git
              $ git branch -D todo

               delete todo branch even if the "master" branch does not have all
              commits from todo branch.

Re: What's in git.git

[Francis Daly]

> I'd like asciidoc tweaks in "next" by Francis Daly tested by
> people who have access to different vintages of docbook-xsl by
> trying to build manpages.  Look for displayed examples, such as
> the one in git-branch documentation.  I've tried it with v1.68
> and getting far better results than before, and Francis says
> v1.69 works fine with or without the change. IOW this is a
> workaround for a problem in v1.68.

For completeness / comparison:

I have docbook-xsl v1.68 (strictly, 1.68.1-0.1 as packaged in debian
stable) and docbook-xsl v1.69 (1.69.1 freshly downloaded with the
manpages/ChangeLog listing the last change on 2005-08-11).

I have asciidoc 7.1.1 (local install) and xmlto version 0.0.18 as packaged
in debian stable.

Also:

$ xsltproc -V
Using libxml 20616, libxslt 10112 and libexslt 810
xsltproc was compiled against libxml 20616, libxslt 10112 and libexslt 810
libxslt 10112 was compiled against libxml 20616
libexslt 810 was compiled against libxml 20616

Of that lot, I believe only the docbook-xsl version actually matters
for this test, but I'm happy to learn otherwise.

I run

asciidoc -b docbook -d manpage -f asciidoc.conf git-branch.txt 
xmlto man git-branch.xml 
asciidoc -b xhtml11 -d manpage -f asciidoc.conf git-branch.txt 

I vary the docbook-xsl version being used and I vary the asciidoc.conf
file to include or exclude the "literallayout" change.

The four html files produced differ only in the "Last updated" time.

The two man pages produced with v1.69 are identical.

The two man pages produced with v1.68 differ in the expected and intended
ways, replacing ".IP" with a ".nf/.fi" pair in two places.

And the differences between 1.68 and 1.69 with the old configuration, and
1.68 and 1.69 with the new configuration, are also confined to that area.

Repeating the tests on git-clone.txt (which also has a multiline example)
gets the same result.

And doing the test on git-mv.txt (with no multiline example) shows
that the asciidoc.conf change has no effect on pages like that. No real
surprise there.

So I'm happy that the (fixed) change improves something and breaks
nothing, at least for those versions of the tools.

	f
-- 
Francis Daly        francis@daoine.org

Re: What's in git.git

[Fredrik Kuivinen]

On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote:
> On 3/6/06, Junio C Hamano <junkio@cox.net> wrote:
> > - The deathmatch between annotate/blame (Ryan Anderson, Fredrik
> >   Kuivinen, me cheerleading)
> 
> Add fuel to the fire  ;-) Can git-blame take cached git-rev-list
> output like annotate does with -S?
> 

Currently it cannot do that. How is that option used? If you want to
make annotate/blame faster for certain files you might as well cache
the output of annotate/blame instead of the git-rev-list output, no?

What am I missing?

- Fredrik

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Fri, 10 Mar 2006, Fredrik Kuivinen wrote:

> On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote:
> > On 3/6/06, Junio C Hamano <junkio@cox.net> wrote:
> > > - The deathmatch between annotate/blame (Ryan Anderson, Fredrik
> > >   Kuivinen, me cheerleading)
> > 
> > Add fuel to the fire  ;-) Can git-blame take cached git-rev-list
> > output like annotate does with -S?
> > 
> 
> Currently it cannot do that. How is that option used?

The history is linearized, and the commits are ordered accordingly, then 
to be passed to git-annotate/-blame.

> If you want to make annotate/blame faster for certain files you might as 
> well cache the output of annotate/blame instead of the git-rev-list 
> output, no?
> 
> What am I missing?

Two things:

- the history is growing, and
- it would be inefficient/error-prone to save the annotates for files 

Hth,
Dscho
  

Re: What's in git.git

[Martin Langhoff]

On 3/11/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> The history is linearized, and the commits are ordered accordingly, then
> to be passed to git-annotate/-blame.

Exactly.

If a process has already done the costly git-rev-list for other
purposes (say, grab logentries of the relevant commits), and wants to
also run annotate/blame, it should be able to reuse it cheaply, by
passing -S filename. Possibly an IDE (or gitk/qgit) would want to do
this.

Now, what I use it for in git-cvsserver is to "flatten" merges. CVS
clients don't really understand that we know about parallel history,
so every time we have a merge the view that the CVS client gets is of
a "merge commit" with a merge summary. And I sweep the merged commits
under the carpet.

(there's some arbitrary nondeterministic magic in how I pick what side
to track and what side to merge. let's not think about that too much.
but I just want git-blame to see a somewhat simplified git-rev-list).

does that help?

cheers,


m

Re: What's in git.git

[Junio C Hamano]

Fredrik Kuivinen <freku045@student.liu.se> writes:

> On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote:
>> 
>> Add fuel to the fire  ;-) Can git-blame take cached git-rev-list
>> output like annotate does with -S?
>
> Currently it cannot do that. How is that option used? If you want to
> make annotate/blame faster for certain files you might as well cache
> the output of annotate/blame instead of the git-rev-list output, no?

There are two reasons Martin's git-cvsserver uses -S to feed you
the revision list.  One is that he already has that ancestry
chain information, and there is no point for him to have the
git-annotate command to recompute it.

But there is another, more important reason.  He is giving his
clients a modified world view where the branch he is exposing to
have _no_ merges -- just a single strand of pearls.  So what is
fed to git-annotate using -S from git-cvsserver has either one
object name (single root commit) or two (the commit and its sole
parent).  IOW, he does not want you to look at other parents
when dealing with a merge commit.

What this means is that in cases where your algorithm looked at
second and subsequent parents to pass remaining blame on after
looking at the first parent for a merge, the algorithm now needs
to assign the blame to the merge commit itself.  Your
process_commit() currently reads the commit object and loops
over its true parents, but the -S flag wants to supply its own
notion of who are the parents of whom (and in the case of
git-cvsserver, it always supplies at most one parent) so you
would need to honor that instead of looking at the real
ancestry.

What's in git.git

[Junio C Hamano]

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

 - git-svn updates (Eric Wong)
 - git-blame knows about renames (Fredrik Kuivinen)
 - imap-send (Mike McCormack with fixes from Johannes Schindelin
   and Marco Roeland)
 - cvsimport only updates tracking branch (Matthias Urlichs)
 - repo-config fix (Jonas Fonseca)
 - fmt-merge-msg cleanup (Linus Torvalds)
 - format-patch attachments enhancements (Mike McCormack)
 - delitifier cleanup and performance fix (Nicolas Pitre)
 - remove end-of-line period from git-pull message (Olaf Hering)
 - http-push and fetch updates (Nick Hengeveld)
 - rev-list and revision walker performance fix (Matthias Urlichs)
 - annotate RPM packaging workaround (sean)
 - assorted doc fixes (Francis Daly, Fredrik Kuivinen)
 - assorted test fixes (Mark Wooding, me)
 - improve git wrapper --help output (Fredrik Kuivinen)
 - checkout-index --temp (Shawn Pearce)
 - no more --standalone to fsck-objects
 - rev-list path limiter fix at boundary
 - git-diff: -p disables rename detection

As you can see from the above, the core part does not have
drastic changes these days anymore.  Just some boring fixes with
a handful new and interesting developments.

In the "next" branch is the "insanely fast rename detection".
I've done some minor fixups to its hash function to be usable on
both 32-bit and 64-bit machines but otherwise it is what was
posted by Linus to the list.  It completes the rename detection
between v2.6.12 and v2.6.14 kernel source under 5 seconds on my
Duron 750 with slow disks, where the current "master" branch
version takes about 60 seconds.

Also I've been keeping ls-{tree,files} --abbrev patches and
refs/remotes patch from Eric Wong in 'next' and 'pu'.  I haven't
seen anybody jumps up and down to have them merged to "master",
nor have been asked to push them out sooner so that a widely
used Porcelain or two can take advantage of them, and that's the
only reason why they are not in "master".  In other words, while
I do not have much against them, it would be nicer to have a
convincing argument why they are must-have's or even
better-have's before they graduate.

What's in git.git

[Junio C Hamano]

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

 - git.el updates (Alexandre Julliard)
 - git-svn updates (Eric Wong)
 - git-blame updates (Fredrik Kuivinen)
 - documentation updates (Francis Daly, Jon Loeliger)
 - Makefile: Add TAGS and tags targets (Fredrik Kuivinen)
 - http-push support for deleting remote branches (Nick Hengeveld)

 - assorted minor fixes and tweaks (Alexandre Julliard, Mark
   Hollomon, Shawn Pearce, Yasushi SHOJI, Nicolas Pitre, Randal
   L. Schwartz and me)

* The 'next' branch, in addition, has two important fixes and
  enhancements, and it probably is a good time to do a 1.3
  release when they graduate to "master" and prove stable.

 - quicker and dirtier rename detection by Linus and me.

   I've been using this myself and haven't seen major
   misdetection so far, but I do not use much renames.  Maybe
   it's time to push this out and see what happens.  This is
   _not_ the "important" part.

 - cvsimport post-import checkout fix.

   Earlier we had a workaround to deal with people who import
   into the current branch by not checking out.  After
   incrementally importing from the same CVS repository again,
   however, the code did update the branch head.  This made the
   working tree and the index stale and was causing more
   confusion than it avoided.

   This fix is to make re-importing act more like git-pull, not
   git-fetch.  So if you run an incremental import into the
   current branch, it tries to fast-forward the working tree and
   index (your current branch head, index and working tree had
   better be pristine with respect to the CVS repository for
   this, but that is already an requirement for a tracking
   branch anyway) when your current branch is the tracking
   branch, or merge the imported result into your current branch
   if you are using a separate tracking branch.

   I've done some testing on this myself, but am waiting for
   independent confirmations from cvsimport users.  Merlyn?

 - refs/remotes support.

   This has been the recent hot topic, on git-clone.

   First, not so controversial one.  A new option --reference
   can be used to help cloning a project similar to what you
   already have over thin wire:

	$ git clone --reference /git/linux-2.6.git \
          git://git.kernel.org/pub/.../jgarzik/libata-dev.git/ \
          libata-dev

   What happens here is that the new repository (libata-dev you
   are creating by cloning from Jeff) is set up to borrow from
   vanilla Linus repository you already keep track of, and the
   initial clone downloads and expands objects that are only
   present in Jeff's tree.

   Another new option, --use-separate-remote, changes the way
   $GIT_DIR/remotes/origin file and your tracking branches are
   set up after the initial cloning.  Without it, all the remote
   heads are copied to your $GIT_DIR/refs/heads/ and a copy of
   the remote HEAD is made as $GIT_DIR/refs/heads/origin, and
   remotes/origin file is set up to keep this structure up to
   date.  This is the traditional behaviour.

   When --use-separate-remote is in effect, the tracking
   branches are created in $GIT_DIR/refs/remotes/origin/ and you
   will not get the extra "origin" head.  Your local branch
   namespace under $GIT_DIR/refs/heads/ will only have "master".
   In addition, a symref $GIT_DIR/refs/remotes/origin/HEAD
   points at the primary branch of the remote repository.
   Similar to a filename in $GIT_DIR/refs/{heads,tags} that can
   be used to name a ref (e.g. when you say "git diff frotz",
   you are telling git to read from $GIT_DIR/refs/heads/frotz
   and use that commit ID to diff your working tree against), a
   directory that has such a symref under $GIT_DIR/refs/remotes
   can be used to name the ref.  IOW, "git diff origin" in a
   repository a cloned this way means you want a diff against
   $GIT_DIR/refs/remotes/origin/HEAD.

   I've done reasonable amount of testing over git:// transport,
   and some with http:// as well, but I do not know if rsync://
   works at all (I never use rsync:// transport myself).  If
   anybody cares about rsync:// transport, please test it while
   it still is in "next" to keep things working for you.

   A new configuration option, 'core.warnambiguousrefs', can be
   set to warn you if you use "frotz" to name a ref when you
   have more than one "frotz" under $GIT_DIR/refs (e.g. you have
   both branch "frotz" and tag "frotz", and/or you have
   refs/remotes/frotz/HEAD).

   It also has changes by Eric Wong to teach git-fetch about
   $GIT_DIR/refs/remotes hierarchy.

Re: What's in git.git

[Randal L. Schwartz]

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

Junio>  - cvsimport post-import checkout fix.

Junio>    Earlier we had a workaround to deal with people who import
Junio>    into the current branch by not checking out.  After
Junio>    incrementally importing from the same CVS repository again,
Junio>    however, the code did update the branch head.  This made the
Junio>    working tree and the index stale and was causing more
Junio>    confusion than it avoided.

Junio>    This fix is to make re-importing act more like git-pull, not
Junio>    git-fetch.  So if you run an incremental import into the
Junio>    current branch, it tries to fast-forward the working tree and
Junio>    index (your current branch head, index and working tree had
Junio>    better be pristine with respect to the CVS repository for
Junio>    this, but that is already an requirement for a tracking
Junio>    branch anyway) when your current branch is the tracking
Junio>    branch, or merge the imported result into your current branch
Junio>    if you are using a separate tracking branch.

Junio>    I've done some testing on this myself, but am waiting for
Junio>    independent confirmations from cvsimport users.  Merlyn?

I'm waiting for that CVS tree to change again.  It changes every
4-5 days.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: What's in git.git

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

Randal> I'm waiting for that CVS tree to change again.  It changes every
Randal> 4-5 days.

Speaking of which, I *know* you sent me a patch to apply to incorporate the
one difference, but is there a more automatic way of cherry-picking
git-cvsimport.perl from "next" into a new topic branch of mine?

For example, I can do this:

$ git-checkout next
$ cp git-cvsimport.perl DUMMY
$ git-checkout -b my-playground
$ mv DUMMY git-cvsimport.perl
$ git-commit -a -m 'trying that other version'

But this wastes a commit.  Is there any way to get an index that simply
includes the file from that other branch?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: What's in git.git

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> For example, I can do this:
>
> $ git-checkout next
> $ cp git-cvsimport.perl DUMMY
> $ git-checkout -b my-playground
> $ mv DUMMY git-cvsimport.perl
> $ git-commit -a -m 'trying that other version'
>
> But this wastes a commit.  Is there any way to get an index that simply
> includes the file from that other branch?

        $ git checkout master
        $ git checkout next git-cvsimport.perl

Re: What's in git.git

[Randal L. Schwartz]

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

>> But this wastes a commit.  Is there any way to get an index that simply
>> includes the file from that other branch?

Junio>         $ git checkout master
Junio>         $ git checkout next git-cvsimport.perl

Yow.  How simple is *that*?  Thanks.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: What's in git.git

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
>>> But this wastes a commit.  Is there any way to get an index that simply
>>> includes the file from that other branch?
>
> Junio>         $ git checkout master
> Junio>         $ git checkout next git-cvsimport.perl
>
> Yow.  How simple is *that*?  Thanks.

There is one thing you would want to be careful about.
This updates the index.

Re: What's in git.git

[Bertrand Jacquin]

On 3/22/06, Junio C Hamano <junkio@cox.net> wrote:
>
>    A new configuration option, 'core.warnambiguousrefs', can be
>    set to warn you if you use "frotz" to name a ref when you
>    have more than one "frotz" under $GIT_DIR/refs (e.g. you have
>    both branch "frotz" and tag "frotz", and/or you have
>    refs/remotes/frotz/HEAD).

Ah cool :) I had the problem recently.
Also, Would could I know all configuration option ?

--
Beber
#e.fr@freenode

Re: What's in git.git

[Petr Baudis]

Dear diary, on Wed, Mar 22, 2006 at 02:58:28AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
>    When --use-separate-remote is in effect, the tracking
>    branches are created in $GIT_DIR/refs/remotes/origin/ and you
>    will not get the extra "origin" head.  Your local branch
>    namespace under $GIT_DIR/refs/heads/ will only have "master".
>    In addition, a symref $GIT_DIR/refs/remotes/origin/HEAD
>    points at the primary branch of the remote repository.
>    Similar to a filename in $GIT_DIR/refs/{heads,tags} that can
>    be used to name a ref (e.g. when you say "git diff frotz",
>    you are telling git to read from $GIT_DIR/refs/heads/frotz
>    and use that commit ID to diff your working tree against), a
>    directory that has such a symref under $GIT_DIR/refs/remotes
>    can be used to name the ref.  IOW, "git diff origin" in a
>    repository a cloned this way means you want a diff against
>    $GIT_DIR/refs/remotes/origin/HEAD.

Sounds very good.

>    A new configuration option, 'core.warnambiguousrefs', can be
>    set to warn you if you use "frotz" to name a ref when you
>    have more than one "frotz" under $GIT_DIR/refs (e.g. you have
>    both branch "frotz" and tag "frotz", and/or you have
>    refs/remotes/frotz/HEAD).

Is there any reason why this isn't enabled by default?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.

Re: What's in git.git

[Linus Torvalds]

On Tue, 21 Mar 2006, Junio C Hamano wrote:

> merlyn@stonehenge.com (Randal L. Schwartz) writes:
> 
> >>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> >
> >>> But this wastes a commit.  Is there any way to get an index that simply
> >>> includes the file from that other branch?
> >
> > Junio>         $ git checkout master
> > Junio>         $ git checkout next git-cvsimport.perl
> >
> > Yow.  How simple is *that*?  Thanks.
> 
> There is one thing you would want to be careful about.
> This updates the index.

Yes. Btw, I've been bitten by that. I think it might be better to _not_ 
update the index when we check out a file from another branch than the one 
we're on (or rather, we should perhaps update the index with the value 
from the current branch every time, even though the _working_tree_ is 
updated from another branch)

		Linus

Re: What's in git.git

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>>    A new configuration option, 'core.warnambiguousrefs', can be
>>    set to warn you if you use "frotz" to name a ref when you
>>    have more than one "frotz" under $GIT_DIR/refs (e.g. you have
>>    both branch "frotz" and tag "frotz", and/or you have
>>    refs/remotes/frotz/HEAD).
>
> Is there any reason why this isn't enabled by default?

Not in particular, other than Inertia and trying one baby step
at a time.

What's in git.git

[Junio C Hamano]

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

 - git-svn memory usage reduction (Eric Wong)
 - documentation updates (Francis Daly, Jon Loeliger)
 - fix updating working tree after cvsimport reads from CVS
 - fetch exits non-zero when fast-forward check fails.
 - improve git-pull's failur case when pulling into the tracking branch.
 - commit-tree checks return value from write_sha1_file().
 - git-apply understands "@@ -l, +m @@" correctly.

----------------------------------------------------------------

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

These are harmless and useful to be pushed into "master"; I just
have not gotten around to.

 - updates around git-clone:
   . --use-separate-remote
   . --reference <repo>
   . fetch,parse-remote,fmt-merge-msg: refs/remotes/* support (Eric Wong)
   . sha1_name() understands refs/remotes/$foo/HEAD

 - sha1_name safety and core.warnambiguousrefs
 - git-merge knows some strategies want to skip trivial merges

------------

I really should do some more stats on this and push it out.
Just haven't got around to do so.

 - insanely fast rename detection (Linus and me)

------------

These look very good, but people depend on them, so I'd like to
simmer them in "next" for a couple of days to hear success
stories, or "ah crap I got burned" story ;-).

 - tar-tree updates (Rene Scharfe)
 - send-email updates (Eric Wong)

------------

Hot off the press.  I smell the beginning of a good stuff here.

 - truly built-in diff (Linus with Davide)

------------

This is harmless to be pushed into "master" but is staying here
only because nobody expressed urgency.

 - ls-{files,tree} --abbrev (Eric Wong)

----------------------------------------------------------------

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

Since I do not have a good guinea pig case to use this, I
haven't read and understood the code being patched enough to
comment on the change this one introduces; it looks obviously
correct, though.

I'd like an ACK or two from people who works with SVN gateway
before I apply this to "master".

 - git-svnimport: if a limit is specified, respect it (Anand Kumria)

------------

This script does what it claims to do, but I do not think of a
useful use case for this.  When I have packs with garbage
objects in them (because I rewind my "pu" branch I usually end
up having a handful in my packs), I just run "repack -a -d" and
that is good enough.  So I need a bit of convincing to keep
this.

 - Add git-explode-packs (Martin Atukunda)

What's in git.git

[Junio C Hamano]

GIT 1.3.0-rc1 is pushed out and will be mirrored out soon.

All of the things that were not in the "master" branch were
either cooked long enough in "next" without causing problems
(e.g. insanely fast rename detector or true built-in diff) or
isolated in a specific subsystem (e.g. tar-tree and svnimport).

So I am clearing the deck to prepare for a 1.3.0.  Remaining
wrinkles, if any, will be ironed out in the "master" branch.

------------
Changes since the last announcement:

 - updates around git-clone:
   . --use-separate-remote
   . --reference <repo>
   . fetch,parse-remote,fmt-merge-msg: refs/remotes/* support (Eric Wong)
   . sha1_name() understands refs/remotes/$foo/HEAD

 - sha1_name safety and core.warnambiguousrefs

 - git-merge knows some strategies want to skip trivial merges

 - insanely fast rename detection (Linus and me)

 - tar-tree updates (Rene Scharfe)

 - send-email updates (Eric Wong)

 - truly built-in diff (Linus with Davide)

 - ls-{files,tree} --abbrev (Eric Wong)

 - git-svnimport: if a limit is specified, respect it (Anand Kumria)

 - documentation (J. Bruce Fields)

 - build fix (Johannes Schindelin)

 - git-ls-files --others --directory --no-empty-directory (Petr Baudis)

 - gitk updates (Martin Mares, Paul Mackerras)

 - GIT 1.3.0 rc1 (me)

Currently "next" and "pu" are empty.

What's in git.git

[Junio C Hamano]

I've tagged the tip of "master" as 1.3.0-rc2.  It has the
following changes since the last announcement.

 - enhancement and a minor fix to built-in xdiff
   (Davide Libenzi and Mark Wooding)

 - contrib/git-svn updates (Eric Wong)

 - documentation updates (J. Bruce Fields)

 - build and other assorted fixes and cleanups (Jason Riedy,
   Peter Eriksen, Rene Scharfe, Yasushi SHOJI, and Jim Radford)

 - Solaris "clone" fix (Linus and Jason Riedy with initial
   reproduction help from Peter Eriksen)

 - revision traversal latency improvements with paths and
   max-age limiting (Linus and me)

 - http-fetch updates (Nick Hengeveld)

 - updated gitk (Paul Mackerras)


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

 - fix cloning of upsteram whose HEAD does not point at master
   (me); this is an attempt to fix a real bug, but I haven't had
   a chance to test it sufficiently enough to convince myself it
   is ready.

 - pickaxe enhancements that looks for needles matching regexp
   (Petr Baudis)

 - combine-diff that uses built-in xdiff (me)

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

 - assorted gitk updates from the list (Johannes Schindelin,
   Keith Packard and Mark Wooding); I am waiting for some of
   them to trickle back from Paul's canonical gitk tree.

 - beginning of new pickaxe (me); I've got busy before getting this
   one to do anything interesting.  Currently it is just a bit
   faster way to do 'rev-list | diff-tree --stdin path' for a
   single path.

What's in git.git

[Junio C Hamano]

No real 1.3.0 yet...

* The 'master' branch has these since the last announcement.
  All of them are fixes and clean-ups (except --parents stuff
  from Linus which seems safe enough).

Junio C Hamano:
      git-log: match rev-list --abbrev and --abbrev-commit
      diff: fix output of total-rewrite diff.
      diffcore-rename: fix merging back a broken pair.
      Retire diffcore-pathspec.
      Retire git-log.sh
      Retire git-log.sh (take#2)

Linus Torvalds:
      Make "--parents" logs also be incremental

Marco Roeland:
      xdiff/xdiffi.c: fix warnings about possibly uninitialized variables

Petr Baudis:
      Improve the git-diff-tree -c/-cc documentation


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

  - diff-* --patch-with-raw
  - Implement limited context matching in git-apply (Eric W. Biederman)

  - log-tree: separate major part of diff-tree.
  - git log [diff-tree options]...

I should not be moving anything new from "next" to "master"
before 1.3.0, but I am inclined to include the --patch-with-raw
change, which Cogito wants.  Also apply -Cn by Eric seems safe
enough; as long as you do not ask for it, it keeps the existing
behaviour.  The initial part of "git log with diff-tree options"
seems safe enough so it is also in 'next'.

I have the rest of "git log with diff-tree options", along with
its fallouts, which turned out to be more than what I wanted to
see, in "pu".

Re: What's in git.git

[Linus Torvalds]

On Mon, 10 Apr 2006, Junio C Hamano wrote:
>
>       Retire git-log.sh
>       Retire git-log.sh (take#2)

I think you need a (take#3).

This creates "git-log" as a link to "git", but does so at _build_ time, 
not install time.

Which means that when it actually gets installed, it gets installed as a 
copy of that link, and you get two different executables instead of one 
single executable that is just linked to two names:

  [torvalds@g5 git]$ ls -li /home/torvalds/bin/git ~/bin/git-log
  67272830 -rwxr-xr-x 1 torvalds torvalds 333613 Apr 11 06:45 /home/torvalds/bin/git
  67272781 -rwxr-xr-x 1 torvalds torvalds 333613 Apr 11 06:45 /home/torvalds/bin/git-log

so it _works_, but it wastes 300kB+ for each "builtin". Which was kind of 
against the whole point.

I think the builtins should be a install-time only issue. 

		Linus

Re: What's in git.git

[Petr Baudis]

Dear diary, on Tue, Apr 11, 2006 at 03:50:14PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
> I think the builtins should be a install-time only issue. 

I don't care about git-log in particular since I don't use it, but I use
development Git versions without actually installing them and if it's
not a huge hurdle, it would be nice to keep this possible.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.

Re: What's in git.git

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>> I think the builtins should be a install-time only issue. 
>
> I don't care about git-log in particular since I don't use it, but I use
> development Git versions without actually installing them and if it's
> not a huge hurdle, it would be nice to keep this possible.

Also not making the link would probably break test suite (I do
not know if we have git-log test right now, though).

But installing *copies* is obviously not right as you pointed out.

What's in git.git

[Junio C Hamano]

Getting closer with bunch of fixes, perhaps a real 1.3.0 early
next week.

I'd appreciate people beating what's in the "master" branch to
shake down the last minute brown paper bag problems.  

BTW, I shifted my git day from usual Wednesday to Thursday this
week.  I may do the same the next week.

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

 - More Solaris 9 portability (Dennis Stosberg)
 - kill index() and replace it with strchr() (Dennis Stosberg)
 - git-apply -C to apply patch with fuzz (Eric W. Biederman)
 - git-log [diff options]
 - Retire git-log.sh
 - Combine-diff fix
 - Retire t5501 test
 - Fix "echo -n foo | git commit -F -"
 - diff --patch-with-raw (Pasky and me)
 - Documentation updates (Pasky and me)
 - Fix running t3600 test as root.
 - "expr match : foobar" fix (Mark Wooding and me)
 - commit message formatting fix for incomplete line (Linus)
 - git-log memory footprint fix (Linus)

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

 - xdiff: post-process hunks to make them consistent (Davide Libenzi)
 - diff --stat (Johannes Schindelin and me)
 - t5500 test fix

What's in git.git

[Junio C Hamano]

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

 - Update xdiff (Davide Libenzi)
 - Add diff --stat and --patch-with-stat (Johannes Schindelin)
 - Miscellaneous fixes (A Large Angry SCM, Linus, Serge
   E. Hallyn, Yann Dirson, me)
 - Fix rev-list --boundary (me)
 - Update gitk (Paul Mackerras)

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

 - Common option parsing for "git log --diff" and friends (Linus)
 - Log message printout cleanups (Linus)
 - Log/show/whatchanged commands are now built-in (Linus and me)
 - Similarity fingerprint (Geert Bosch)
 - Define "log --stat" to be "stat with first parent" (Linus and me)

The commits on the lt/logopt branch (part of "next" branch) are
proving to be more stable and safe enough to use.  It cleans up
the code quote a lot,

I'm really resisting the temptation to merge these before 1.3.0.
There is a slight output format change from diff-tree --pretty;
while I would not expect no Porcelains is affected in practice,
technically this is a backward incompatible change, so...

Anyway, they will be merged immediately after the big release.

What's in git.git

[Junio C Hamano]

* The 'maint' branch has these fixes since the last announcement.
  They will be part of 1.3.1 early next week.

  - Fix diff --stat filename output when binary files with long
    names are involved (Jonas Fonseca)

  - git-merge gives a bit more readable user guidance upon conflicts.

  - The example pre-commit hook complains about conflict markers.

  - Two fixes to git-commit --amend.

  - Fix pack-objects.  This was discussed in this thread:

    http://thread.gmane.org/gmane.comp.version-control.git/19021

  - mailinfo: decode underscore used in "Q" encoding properly.

    The versions before this fix broke some peoples names;
    apologies to Santi and Lukas.

  - Fix spawning of PAGER (Linus Torvalds).  This was discussed
    in this thread:

    http://thread.gmane.org/gmane.comp.version-control.git/18969

  - Fix pack-object buffer size (Nicolas Pitre)

  - Reintroduce svn pools to solve the memory leak (Santi Béjar)

  - Document git-clone --reference (Shawn Pearce)


* The 'master' branch has these since the last announcement.
  All the 'maint' fixes are included.

  - Big 'revision.c/log-tree.c' option parsing unification (Linus).
  - Big log formatting unification (Linus).
  - Built-in git-whatchanged.
  - Do not fork PAGER=cat
  - combine-diff --stat: show diffstat with the first parent.
  - get_sha1() shorthands for blob/tree objects (Linus)
  - Allow "git repack" users to specify repacking window/depth (Linus)
  - Split up builtin commands into separate files from git.c (Linus)

    Most of the above happened immediately after 1.3.0, and will
    not be part of 1.3.X series, which is maintenance fixes only.

    The general direction is that many commands we used to
    implement as one liner pipe from git-rev-list to
    git-diff-tree are converted into built-in C implementation.

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

  - daemon::socksetup: don't return on set_reuse_addr() error (Serge E. Hallyn)

    Comments?

  - Tentative built-in format-patch

    This is meant to be the next in the "internalize rev-list
    piped to diff-tree" series.  Currently it does only --stdout
    form and does not take any options.  It needs more work in
    the core area to spit things out into separate files with
    munged filenames.

  - git-update-index --unresolve.  This was discussed in this
    thread:

    http://thread.gmane.org/gmane.comp.version-control.git/18936

    This thread was fruitful; three patches came out of it.

  - diff --stat: do not drop rename information.

    I think this is ready to graduate to "master"; I just
    haven't got around to it.

    Johannes suggested "file => /dev/null" to show a deleted
    file as if a rename was done.  While I think it makes some
    sense, I am afraid it diverges too much from the traditional
    diffstat output.  I am undecided, somewhat negative, about
    the suggestion.

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

  - gitk: Fix geometry on rootless X (Johannes Schindelin)

  - "bind commit" resurrected.

    Somebody off-list volunteered to look into adding
    subprojects support, so I merged the old codebase and placed
    it here.  The merge conflict was not too bad, to my
    surprise.  Subpro.txt file in the "todo" branch describes
    one suggested plan, but who he codes gets to decide the
    details of the implementation and semantics, so we will see
    what emerges.  One big piece still missing from the core
    side to implement Subpro.txt plan is an enhancement to the
    index file format to do "update-index --bind/--unbind".  I
    may have to fill that gap over the weekend, but no firm
    promises.

  - contrib/colordiff.

    This is an external colorizer you can use by saying:
    
	PAGER="colordiff | less -RS" git log --cc

  - colored diff with diff.usecolor configuration option.

    I'll not be using colorization myself, so there is no strong
    incentive on my part to carry this forward, but this is here
    just in case if people are interested.  Currently it does
    not do color for combined diffs.

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Fri, 21 Apr 2006, Junio C Hamano wrote:

>   - diff --stat: do not drop rename information.
> 
>     Johannes suggested "file => /dev/null" to show a deleted
>     file as if a rename was done.  While I think it makes some
>     sense, I am afraid it diverges too much from the traditional
>     diffstat output.  I am undecided, somewhat negative, about
>     the suggestion.

It was not so much a suggestion, but a misinterpretation of your patch. I 
am also undecided and slightly negative about it.

> * The 'pu' branch, in addition, has these.
> 
>   - gitk: Fix geometry on rootless X (Johannes Schindelin)

I talked to Paul about this, and was not only slightly negative about it. 
The suggestion was to either use native versions of Tk (which might or 
might not fix it), or fix Tk.

Having spent already some time with this workaround, I am not willing to 
invest more of it, though.

So, if people want to do something about this patch, go wild.

Ciao,
Dscho

What's in git.git

[Junio C Hamano]

* The 'maint' branch has fixes mentioned in the 1.3.1 
  announcement.

  As I outlined in the 1.3.1 maintenance release announcement,
  people with that release will soon be missing many
  improvements.  The following is a list of what to expect.


* In addition to the above. the 'master' branch has these since
  the last announcement,

  - git-update-index --chmod=+x now affects all the subsequent
    files (Alex Riesen).

  - git-update-index --unresolve paths...; this needs
    documentation (hint).

  - minor "diff --stat" and "show --stat" fixes.

  - Makefile dependency fixes.  This fixes the infamous
    "libgit.a still contains stale diff.o" problem.

  - contrib has colordiff that understands --cc output.

  - beginning of libified "git diff" family.

  - git-commit-tree <ent> -p <parent> now takes extended SHA1
    expression, not limited to 40-byte SHA1, for <ent> (it
    already did so for <parent>).

  - updated gitk to handle repositories with large number of
    tags and heads (Paul).


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

  - internal log/show/whatchanged family (Linus and me).

  - beginning of internal format-patch.

  - Geert's similarity code in contrib/

  - cache-tree optimization to speed up git-apply + write-tree
    cycles.

    Initially I was getting close to 50% improvement, but
    re-benching suggests it is more like 16%.  An earlier
    version in 'next' used a separate .git/index.aux to record
    the cache-tree information but now it is stored as part of
    the index.  If you used previous 'next' (ha, ha) version and
    see tmp-indexXXXX.aux or next-indexXXXX.aux files left in
    your $GIT_DIR, they can safely be removed.

  - more "diff --stat" fixes.

  - git-cvsserver: typofixes.

  - diff-delta interface reorganization (Nico)

  - git-repo-config --list (Pasky)


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

  - resurrect "bind commit"; this has been done only partially.

    I have not updated the rev-list/fsck-objects yet.  Probably
    need to drop the specific "bind " line and replace it with
    "link object bind" in the commit objects before going
    forward.

  - get_sha1(): :path and :[0-3]:path to extract from index.

  - Loosening path argument check a little bit in revision.c.

    I've been meaning to do the opposite of this, the tightening
    of ambiguous case mentione by Linus, but haven't got around
    to yet (I haven't got around to too many things, hint hint).

  - reverse the pack-objects delta window logic (Nico)

    This is in theory the right thing to do, but things are not
    quite there yet.  But Nico is on top of it so we will see
    quite an improvement in the pack generation hopefully very
    soon.

What's in git.git

[Junio C Hamano]

* The 'maint' branch has these fixes since the last announcement.

 - Documentation cleanups (Sean Estabrooks)
 - git-format-patch uses rfc2822 compliant date (Huw Davies).
 - git-am usability fixes (Robert Shearman and me)
 - Fix filename verification when in a subdirectory (Linus)
 - git-send-email debuggability improvements (Martin Langhoff)
 - annotate fixes (Matthias Kestenholz)
 - rebase: typofix.
 - commit-tree.c: check_valid() microoptimization.
 - verify-pack: check integrity in a saner order.


* The 'master' branch has these since the last announcement, in
  addition to the above fixes.

 - gitk views and highlights enhancements (Paul Mackerras).
 - repo-config -l (Petr Baudis and Johannes Schindelin)
 - repo-config white-space fix (Johannes Schindelin)
 - diff --stat fix.
 - revision parsing more strictly checks "rev -- paths"
 - t0000-basic: more commit-tree tests.
 - Extended SHA1 -- "rev^@" syntax to mean "all parents"
 - Fix "git help -a" terminal autosizing (Linus)
 - git-fetch: resolve remote symrefs for HTTP transport (Nick Hengeveld)
 - daemon: socksetup: don't return on set_reuse_addr() error (Serge E. Hallyn)


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

 - built-in git-count-objects
 - built-in git-diff.
 - built-in git-push (Linus with fix by Johannes Schindelin).
 - built-in git-log.
 - built-in git-grep.

   These not only implement them built-in, but remove the
   corresponding shell script versions.  I think all of them are
   ready to be pushed out, so expect them soon in your "master"
   branch ;-).

 - repo-config: support --get-regexp (Johannes Schindelin)
 - core.prefersymlinkrefs: use symlinks for .git/HEAD
 - get_sha1(): :path and :[0-3]:path to extract from index.
 
  Needs a bit more testing.

 - further diff-delta improvements (Nicolas Pitre)

   Benchmark impressions are welcome on this.  

 - cache-tree optimization

   This yields a nice speedup to (apply then write-tree)+
   sequence, but is rather intrusive and risky (if somebody
   forgets to invalidate a cached information the next write
   tree can write out corrupt data).  I am hoping we can redo
   this inside the index.

 - built-in git-fmt-patch

   This is not ready as format-patch replacement yet; it only
   does --stdout.

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

 - read-tree: --prefix=<path> option.
 - write-tree: --exclude=<prefix>
 - write-tree: --prefix=<path>
      
   These were originally done as part of "bind commit" series,
   but are useful outside the context of subproject support.
   read-tree --prefix=<path> allows you to graft a tree object
   at a subdirectory in an already populated index, and
   write-tree --prefix=<path> allows you to write out only a
   subdirectory out of an index as a tree object.  I am not in
   an urgent need for these features, but if some Porcelain
   finds them useful, they can be merged to "next".

What's in git.git

[Junio C Hamano]

* Latest maintenance release 1.3.2 is out from the 'maint' branch.

* The 'master' branch has these since the last announcement, not
  counting what is in v1.3.2.

 - blame path-pruning fix (Fredrik Kuivinen)

 - built-in push (Linus, Johannes Schindelin)

 - beginning of "put remotes/ info in config file" (Johannes Schindelin)

 - repo-config updates and fixes (Johannes Schindelin)

 - built-in count-objects and diff

 - core.prefersymlinkrefs can be given to use symlink HEAD;
   this may be needed to bisect kernel history before January
   2006 whose setlocalversion script depended on HEAD being a
   symlink.

 - "git-log --parents" fix (Linus)

 - use rev-list instead of log in git-cvsserver (Martin Langhoff)

 - sha1_to_hex() usage cleanup (Linus)

 - Document update-index --unresolve (Matthias Kestenholz)


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

 - "put remotes/ info in config file" for fetch side (Johannes Schindelin)

 - built-in grep

   It now knows all the common grep options I personally use,
   including -l, -w, -E, -i, -[ABC]<n>, -v; I am planning to
   push this out perhaps mid next week.

 - built-in format-patch WIP

   I really should resume working on this again...

 - cache-tree

   Fixed a rather nasty bug; should be safe again to use it now.

 - get_sha1(): :path and :[0-3]:path to extract from index.

 - diff-delta enhancements (Nicolas Pitre)


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

 - partial tree reading/writing with --prefix option.

 - Transitively read alternatives (Martin Waitz)

Re: What's in git.git

[Petr Baudis]

Dear diary, on Thu, May 04, 2006 at 10:14:54AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
>  - core.prefersymlinkrefs can be given to use symlink HEAD;
>    this may be needed to bisect kernel history before January
>    2006 whose setlocalversion script depended on HEAD being a
>    symlink.

Oh, I expected this to end up in 1.3.2, actually. :-)

Shouldn't this belong to the maint branch? It is "physically" a new
feature but I would consider "cannot bisect kernel before January" a bug
certainly worth fixing and the feature is pretty tiny. (It seems to be
backwards-incompatible but that only means you should provide some
transition path, I think. ;)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.

What's in git.git

[Junio C Hamano]

This week's "What's in" is a day early, since I do not expect to
be able to do much gitting for the rest of the week.

* The 'maint' branch has these fixes since the last announcement.

Dmitry V. Levin:
      Separate object name errors from usage errors

Eric Wong:
      apply: fix infinite loop with multiple patches with --index

Johannes Schindelin:
      repo-config: trim white-space before comment

Junio C Hamano:
      core.prefersymlinkrefs: use symlinks for .git/HEAD
      repo-config: document what value_regexp does a bit more clearly.
      Fix repo-config set-multivar error return path.
      Documentation: {caret} fixes (git-rev-list.txt)

Linus Torvalds:
      Fix "git diff --stat" with long filenames
      revert/cherry-pick: use aggressive merge.

Martin Waitz:
      clone: keep --reference even with -l -s
      repack: honor -d even when no new pack was created

Matthias Lederhofer:
      core-tutorial.txt: escape asterisk

Pavel Roskin:
      Release config lock if the regex is invalid

Sean Estabrooks:
      Fix for config file section parsing.

Yakov Lerner:
      read-cache.c: use xcalloc() not calloc()


* The 'master' branch has these since the last announcement, in
  addition to the above.  I've flushed topics that have been
  cooked in "next" long enough and hadn't given me problems.

Eric Wong:
      git-svn: documentation updates
      git-svn 1.0.0

Johannes Schindelin:
      builtin-push: --all and --tags _are_ explicit refspecs
      Fix users of prefix_path() to free() only when necessary
      Fix users of prefix_path() to free() only when necessary

Junio C Hamano:
      get_sha1(): :path and :[0-3]:path to extract from index.
      Makefile: do not link rev-list any specially.
      delta: stricter constness
      pack-object: squelch eye-candy on non-tty
      binary patch.
      binary diff: further updates.
      update-index --unresolve: work from a subdirectory.
      checkout-index: plug memory leak from prefix_path()
      update-index: plug memory leak from prefix_path()
      update-index --again
      update-index --again: take optional pathspecs
      binary diff and apply: testsuite.
      repo-config: document what value_regexp does a bit more clearly.
      get_sha1() - fix infinite loop on nonexistent stage.
      Teach git-clean optional <paths>... parameters.
      checkout: use --aggressive when running a 3-way merge (-m).

Martin Waitz:
      Transitively read alternatives
      test case for transitive info/alternates
      clone: don't clone the info/alternates file

Nicolas Pitre:
      split the diff-delta interface
      use delta index data when finding best delta matches
      replace adler32 with Rabin's polynomial in diff-delta
      tiny optimization to diff-delta
      improve diff-delta with sparse and/or repetitive data
      improve base85 generated assembly code

Peter Hagervall:
      Sparse fix for builtin-diff

Sean Estabrooks:
      Several trivial documentation touch ups.
      Fix up docs where "--" isn't displayed correctly.
      Update git-unpack-objects documentation.
      Clarify git-cherry documentation.
      Another config file parsing fix.
      t1300-repo-config: two new config parsing tests.


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

  - cvsserver and cvsexportcommit updates (Martin Langhoff and Martyn Smith)

    This is a new merge but not very new code.  Martin may want
    to comment on how ready they are.

  - built-in fmt-patch (Johannes Schindelin)

    I think this is ready, even though it does not have some
    things we have in format-patch (i.e. --attach, --signoff,
    --check).  If anybody deeply cares please stop me soon or
    better yet enhance with your patches; otherwise I would like
    to push this out to "master" sometime next week to supersede
    the git-format-patch script.

  - built-in grep (me)

    I think this is also ready, even though it robs users from
    having funky "grep" on their $PATH and invoke it.  Compared
    to GNU grep, it lacks -P (pcre), -Z (NUL-terminated output),
    -q (totally quiet), -z (NUL-terminated input), but all the
    commonly used ones including -f (from file), -F (fixed), -w
    (word regexp), -l/-L (files with/without match) and -n (line
    number) are implemented.  The same "stop me or else" comment
    applies.

  - use config "remote.$name.url" and friends for fetch/pull
    (Johannes Schindelin)

    I think this itself is ready; the only reason I do not plan
    to do so this week is to wait until the new config format
    discussion settles, at which time we would need to adjust
    this to the new format.

  - cache-tree (me)

    This has been stalled; I would want to redo it without using
    out-of-index data structure, but that would need the
    following steps, and lately I have too many distractions to
    concentrate on them.

    - review existing index/working-tree/tree walkers.

    - prepare a merge-tree style path walker that walks index,
      working tree, and zero or more trees in parallel.  This
      would probably have an interator interface to return list
      of either tree or blob <mode,sha1> to the caller.  Because
      index does not currently have tree entries, a "not
      up-to-date" tree entry would be returned from the index
      part of the walker if I base this change on "master".  I
      might base this on "next" and use information from
      cache-tree. 

    - using the parallel path walker, revamp diff-cache (both
      cached and non cached) to work out kinks to the walker API
      and see how well it performs.  If I base the work on
      "next", the code should be able to skip unchanged
      subtrees.

    - revamp diff-files (walks index and working tree), although
      this will not get any benefit from having tree entries in
      the index.

    - revamp read-tree (all forms).

    - if I based the work on "next", rip out the cache-tree
      dependency and make the walker return "not up-to-date"
      tree entries for index.

    - revamp update-index, apply, and write-tree to have tree
      entries in the index.  This probably involves revamping
      read-cache interface to update the index file contents.

    - review read-tree to make sure it correctly maintains the
      tree entries in the cache.

* The 'pu' branch, in addition, has the proposed configuration
  file syntax updates from Linus with a patch from Sean.  I
  haven't had time to really look at it, and it seems to fail a
  test right now, but I left it as is.  This is merged from a
  throw-away topic branch for now, but when I resume to gitting
  sometime next week I am hoping we have something ready to be
  tested (iow, "next" material) based on the list concensus.  At
  that time we might probably do backport to cope with the
  syntax updates for 1.3.X release and perhaps 1.2.X series just
  for fun.

Re: What's in git.git

[Linus Torvalds]

On Tue, 9 May 2006, Junio C Hamano wrote:
> 
> * The 'pu' branch, in addition, has the proposed configuration
>   file syntax updates from Linus with a patch from Sean.  I
>   haven't had time to really look at it, and it seems to fail a
>   test right now, but I left it as is.

The reason for the failure is the new syntax for multi-section variables.

This patch makes the test succed, by changing

	[1.2.3]

into

	[1 "2.3"]

which is how subsections now end up being shown (you can still _parse_ 
them the old way, but they get created the new way, which is why the test 
fails)

That's a very strange test-case, and on the face of it the new syntax 
looks "worse", but if you were to be realistic about this kind of section 
name, it would more likely explain _what_ that number sequence means, so 
you would more realistically name your sections something like

	[version "1.2.3"]

which I think everybody agrees looks nicer than

	[version.1.2.3]

or similar.

Of course, I don't think we currently actually have any _users_ of any 
multi-level section names at all, so this is all entirely theoretical 
until we start actually using them.

		Linus
---
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 7090ea9..54b3394 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -241,7 +241,7 @@ # empty line
 	NoNewLine = wow2 for me
 [123456]
 	a123 = 987
-[1.2.3]
+[1 "2.3"]
 	alpha = beta
 EOF
 

Re: What's in git.git

[Linus Torvalds]

On Tue, 9 May 2006, Junio C Hamano wrote:
> 
> Junio C Hamano:
>       binary patch.
>       binary diff: further updates.

Btw, am I just smoking stuff, or is this going to be fundamentally 
problematic for "git-apply -R" if we ever want to support that?

I think the new binary diff is non-reversible. That's ok right now, since 
we don't actually support patching in reverse (if you want to get the 
reverse patch, you need to _diff_ it in reverse and then patch it that 
way).

But at least in theory we might well want to do "-R" eventually.

Hmm? Or did I just mis-understand the format?

		Linus

Re: What's in git.git

[Linus Torvalds]

On Tue, 9 May 2006, Linus Torvalds wrote:
> 
> I think the new binary diff is non-reversible. That's ok right now, since 
> we don't actually support patching in reverse (if you want to get the 
> reverse patch, you need to _diff_ it in reverse and then patch it that 
> way).

Btw, I don't actually know why we don't support "-R". The way git-apply is 
written, it should be totally trivial (just switch old/new around for data 
and line numbers - since it doesn't actually apply the patch directly line 
by line or anything like that) for a normal patch.

So if I read the binary patch right, the lack of "-R" went from "silly 
oversight" to "uhhuh, I don't think the patch format supports it".

Maybe it's not a big deal.

			Linus

Re: What's in git.git

[Randal L. Schwartz]

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

Junio> This week's "What's in" is a day early, since I do not expect to
Junio> be able to do much gitting for the rest of the week.

I just got this with the latest, on the git archive, using git-repack -a:

Generating pack...
Done counting 19151 objects.
Deltifying 19151 objects.
Segmentation fault (core dumped)

This is on OpenBSD.  Is there a secret sabotage afoot?  This is repeatable.
Is there anything I can try differently?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: What's in git.git

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Tue, 9 May 2006, Junio C Hamano wrote:
>> 
>> Junio C Hamano:
>>       binary patch.
>>       binary diff: further updates.
>
> Btw, am I just smoking stuff, or is this going to be fundamentally 
> problematic for "git-apply -R" if we ever want to support that?

It is problematic but not more than the current index + "Binary
files differ" output.  If you have both pre and postimage then
you do not need the binary data.

The forward application is done assuming you have the preimage
(but not necessarily postimage), and when you do not have
postimage the binary data is used.  When going reverse we should
assume you have the postimage (but not necessarily preimage),
but the pack-object format xdelta is not reversible so if you do
not have preimage that matches the index, with the current
output format you lose.

If we care enough, we could add a reverse delta from postimage
to preimage to the output, but I am not sure if it is worth it.

> But at least in theory we might well want to do "-R" eventually.

Yes, but even without binary, -R has a funny implication when
copy-edit patch is involved.  What if a patch copy-edits to
create a new file B based on old A, and also modifies A
in-place, and somehow the postimages of A and B you already have
are not consistent with what that patch does?  Application with
-R would produce two versions of A and you would get a conflict.
I guess showing a combined diff would be a helpful way to
resolve that ;-).

Re: What's in git.git

[Linus Torvalds]

On Tue, 9 May 2006, Randal L. Schwartz wrote:

> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> 
> Junio> This week's "What's in" is a day early, since I do not expect to
> Junio> be able to do much gitting for the rest of the week.
> 
> I just got this with the latest, on the git archive, using git-repack -a:
> 
> Generating pack...
> Done counting 19151 objects.
> Deltifying 19151 objects.
> Segmentation fault (core dumped)
> 
> This is on OpenBSD.  Is there a secret sabotage afoot?  This is repeatable.
> Is there anything I can try differently?

Can you see what the traceback is with gdb?

I'd suspect the deltifier changes, the rabin hash in particular. The core 
file traceback would probably point right at the culprit if so.

I don't see the problem myself, but if it's an access just past the end of 
an array or something, it would depend on exactly what the delta pattern 
is (which, without the "-f" flag, in turn depends on what your previous 
packs looked like) and also on the allocation strategy (which migth 
explain why it shows on OpenBSD but Linux people hadn't seen it).

			Linus

Re: What's in git.git

[Linus Torvalds]

On Tue, 9 May 2006, Junio C Hamano wrote:
> 
> It is problematic but not more than the current index + "Binary
> files differ" output.  If you have both pre and postimage then
> you do not need the binary data.

Fair enough.

> > But at least in theory we might well want to do "-R" eventually.
> 
> Yes, but even without binary, -R has a funny implication when
> copy-edit patch is involved.  What if a patch copy-edits to
> create a new file B based on old A, and also modifies A
> in-place, and somehow the postimages of A and B you already have
> are not consistent with what that patch does?

Yeah, that could get exciting ;)

		Linus

Re: What's in git.git

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> This week's "What's in" is a day early, since I do not expect to
> Junio> be able to do much gitting for the rest of the week.
>
> I just got this with the latest, on the git archive, using git-repack -a:
>
> Generating pack...
> Done counting 19151 objects.
> Deltifying 19151 objects.
> Segmentation fault (core dumped)
>
> This is on OpenBSD.  Is there a secret sabotage afoot?  This is repeatable.
> Is there anything I can try differently?

Tonight's latest (f7a3276) merged Nico's delta patches that was
in "next" branch for some time, so that is what I would suspect
first.

    commit 06a9f9203570d21f9ef5fe219cdde527dcdf0990
    Author: Nicolas Pitre <nico@cam.org>

        improve diff-delta with sparse and/or repetitive data

    commit 2d08e5dd730680f7f8645a6326ec653435e032df
    Author: Nicolas Pitre <nico@cam.org>

        tiny optimization to diff-delta

    commit 3dc5a9e4cdcc7124c665a050547d1285d86a421f
    Author: Nicolas Pitre <nico@cam.org>

        replace adler32 with Rabin's polynomial in diff-delta

    commit f6c7081aa97aa67baa06390a1ef36088c33bf010
    Author: Nicolas Pitre <nico@cam.org>

        use delta index data when finding best delta matches

    commit 08abe669c05521499149dbf84fedefb04a8fa34d
    Author: Nicolas Pitre <nico@cam.org>

        split the diff-delta interface

Could you revert them (i.e. run "git revert 06a9f9", "git revert
2d08e5", ...) to see where it starts behaving again?

Alternatively, you could bisect between 2fc240a (before merging
np/delta branch) and master (f7a3276).

(1) Reverting recipe.

	$ git checkout -b testfix master
        $ make
        $ GIT_EXEC_PATH=. PATH=.:$PATH \
          ./git-repack -a ;# you already know this fails.
        $ EDITOR=: git revert 06a9f92
        $ make
        $ GIT_EXEC_PATH=. PATH=.:$PATH ./git-repack -a ;# does it?
        $ EDITOR=: git revert 2d08e5d
        $ make
        $ GIT_EXEC_PATH=. PATH=.:$PATH ./git-repack -a ;# does it?
        $ EDITOR=: git revert 3dc5a9e
        $ make
        $ GIT_EXEC_PATH=. PATH=.:$PATH ./git-repack -a ;# does it?
        ...

(2) Bisecting recipe.

	$ git checkout -b testfix master
	$ make
        $ GIT_EXEC_PATH=. PATH=.:$PATH \
          ./git-repack -a ;# you already know this fails.
        $ git reset --hard 2fc240a
	$ make
        $ GIT_EXEC_PATH=. PATH=.:$PATH \
          ./git-repack -a ;# before merging np/delta,
                           # should hopefully work
        $ git bisect start
        $ git bisect good 2fc240a
        $ git bisect bad master
        Bisecting: 10 revisions left to test after this
        [143f4d94c6e2188a6bedfdfa268e66b579e3fbf9] Merge branch 'jc/again'
	$ make
        $ GIT_EXEC_PATH=. PATH=.:$PATH ./git-repack -a ;# does this work?

        $ git bisect good ;# if it works, or
        $ git bisect bad  ;# otherwise
	Bisecting: 7 revisions left to test after this
	...

	

Re: What's in git.git

[Martin Langhoff]

On 5/10/06, Junio C Hamano <junkio@cox.net> wrote:
> * The 'next' branch, in addition, has these.
>
>   - cvsserver and cvsexportcommit updates (Martin Langhoff and Martyn Smith)
>
>     This is a new merge but not very new code.  Martin may want
>     to comment on how ready they are.

They have seen some limited use in-house -- we don't use Eclipse
in-house that much, but that has been the test target. I am currently
looking for a machine with good bandwidth to a backbone and cycles to
spare where we can run anon cvs access to Linus's kernel.git repo.

cheers,


martin

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

>   - built-in grep (me)
> 
>     I think this is also ready, even though it robs users from
>     having funky "grep" on their $PATH and invoke it.  Compared
>     to GNU grep, it lacks -P (pcre), -Z (NUL-terminated output),
>     -q (totally quiet), -z (NUL-terminated input), but all the
>     commonly used ones including -f (from file), -F (fixed), -w
>     (word regexp), -l/-L (files with/without match) and -n (line
>     number) are implemented.  The same "stop me or else" comment
>     applies.

If there would be possible to use external grep (like one can use external
diff), then lack of some options wouldn't matter.

-- 
Jakub Narebski
Warsaw, Poland

Re: What's in git.git

[Nicolas Pitre]

On Tue, 9 May 2006, Linus Torvalds wrote:

> 
> 
> On Tue, 9 May 2006, Randal L. Schwartz wrote:
> 
> > >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> > 
> > Junio> This week's "What's in" is a day early, since I do not expect to
> > Junio> be able to do much gitting for the rest of the week.
> > 
> > I just got this with the latest, on the git archive, using git-repack -a:
> > 
> > Generating pack...
> > Done counting 19151 objects.
> > Deltifying 19151 objects.
> > Segmentation fault (core dumped)
> > 
> > This is on OpenBSD.  Is there a secret sabotage afoot?  This is repeatable.
> > Is there anything I can try differently?
> 
> Can you see what the traceback is with gdb?
> 
> I'd suspect the deltifier changes, the rabin hash in particular. The core 
> file traceback would probably point right at the culprit if so.
> 
> I don't see the problem myself, but if it's an access just past the end of 
> an array or something, it would depend on exactly what the delta pattern 
> is (which, without the "-f" flag, in turn depends on what your previous 
> packs looked like) and also on the allocation strategy (which migth 
> explain why it shows on OpenBSD but Linux people hadn't seen it).

When linking with Electric Fence I can reproduce the segfault on Linux 
as well.

Looking into it now.


Nicolas

Re: What's in git.git

[Alex Riesen]

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

On 5/10/06, Nicolas Pitre <nico@cam.org> wrote:
> > >
> > > Junio> This week's "What's in" is a day early, since I do not expect to
> > > Junio> be able to do much gitting for the rest of the week.
> > >
> > > I just got this with the latest, on the git archive, using git-repack -a:
> > >
> > > Generating pack...
> > > Done counting 19151 objects.
> > > Deltifying 19151 objects.
> > > Segmentation fault (core dumped)
> > >

Probably unrelated but I get something similar in cygwin:
$ git pull //pc1/share/dir +ref1:ref2
Generating pack...
Done counting 93 objects.
Result has 62 objects.
Deltifying 62 objects.
git-unpack-objects: fatal: early EOF
git-fetch-pack: fatal: git-unpack-objects died with error code 128

(The program names come from a patch attached to the message)

After I remerged (from git's master) everything but np/delta
(I saw that report about crash on openbsd) it worked again.
This time I cannot make the repository public but will try to
help with testing.

[-- Attachment #2: proc-self-cmdline.patch --]
[-- Type: application/xxxxx, Size: 638 bytes --]

Re: What's in git.git

[Linus Torvalds]

On Wed, 10 May 2006, Nicolas Pitre wrote:
> 
> When linking with Electric Fence I can reproduce the segfault on Linux 
> as well.
> 
> Looking into it now.

Yeah, I get 

	#0  0x1000bfe4 in create_delta (index=0xf7d758a0, trg_buf=0xf7d72eb8, trg_size=327, delta_size=0xffb422b4, 
	    max_size=143) at diff-delta.c:308
	#1  0x10005734 in try_delta (trg=0xf7fdbfa0, src=0xf7fdbf94, src_index=0xf7d758a0, max_depth=10)
	    at pack-objects.c:1049
	#2  0x10005b04 in find_deltas (list=0xf7e32f54, window=11, depth=10) at pack-objects.c:1128
	#3  0x10005ca0 in prepare_pack (window=10, depth=10) at pack-objects.c:1161
	#4  0x1000677c in main (argc=3, argv=0xffb436e4) at pack-objects.c:1359

ie the "entry" chain seems to be corrupt in create_delta.

Actually, it's not even the chain: it's the very first entry:

	(gdb) p index->hash[i]
	$2 = (struct index_entry *) 0xf7d7385c
	(gdb) p entry
	$3 = (struct index_entry *) 0xf7d7385c

and it's not a random value - it looks perfectly valid. As do all the 
other index hash entries. It's just that the index hash entries seem to 
all have been freed, so accessing them causes a SIGSEV!

			Linus

What's in git.git

[Junio C Hamano]

* The 'maint' branch produced the v1.3.3 release I announced
  just a minute ago.

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

 - 64-bit (especially BE) fix for pack-objects (Dennis Stosberg)

 - Porting issues (Dennis Stosberg, Ben Clifford)
 
 - send-email updates (Eric Wong)

 - built-in "grep" (Linus and me)

 - "reset --hard" simplification (Linus and me)

 - configuration file syntax updates (Linus)

 - cvsserver updates (Martin Langhoff, Martyn Smith)

 - delta generation fix (Nicolas Pitre)

 - "git commit" novice usability fix (Sean Estabrooks)


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

 - "diff revA:path1 revB:path2" fix

   When two blobs are given, it produced diff in reverse by
   mistake ("setup_revisions()" left the parsed objects in
   reverse order, and the caller forgot to reverse it).

   This is trivial and ready -- I just haven't got around to
   merging it up.

 - "rebase" help text updates (Sean Estabrooks)

   Ready.

 - "diff --summary" (Sean Estabrooks)

   I haven't really read the code yet, but it is low impact and
   should be ready.

 - strip leading tags/ from "git tag -l" output (Sean Estabrooks) 

   "git tag -l" as I wrote it originally stupidly left leading tags/
   in its output for all tags.  This removes it, and I think it
   is a sensible thing to do.

 - move remotes/ to config (Johannes)

   Now configuration syntax discussion is settled, thanks to
   Linus, we can start discussing per-branch attribute
   semantics.  This series is about the other half of the story.

   I think it is ready as it is, if we are not going to change
   the semantics of "remote"; except some people seem to want to
   reorganize the way per-branch property and remotes interact
   with each other.

 - Further optimiation of pack-object (Nicolas Pitre)

   Testing.

 - "apply --cached"

   This allows "git apply" to apply a patch to the index without
   touching the working tree.  It is handy to prepare a tree to
   use in 3-way fallback, and updated "git am" takes advantage
   of it.  I am planning to use it for stash/unstash.

 - built-in format-patch (Johannes) 

   I think this is almost ready to supersede the script version,
   except that this does not do attachments.

   We need to do RFC2047 for headers as well.  I'd rather do it
   in this version than fix the script version.

 - cache-tree with read-tree/write-tree --prefix

   I haven't made any progress on this one, but haven't been
   bitten by it either, so it is a good sign.

What's in git.git

[Junio C Hamano]

[ This is sent to the kernel list as well, because I suspect
  Eric's quiltimport matches the audience there and it deserves
  a bit more exposure.  "What's in git.git" is sometimes more
  important and significant than [ANNOUNCE] messages, and this
  is such a time. ]

* The 'maint' branch has these fixes since the last announcement.

Elrond:
      git-cvsimport: Handle "Removed" from pserver

Fredrik Kuivinen:
      Update the documentation for git-merge-base

Junio C Hamano:
      merge-base: Clarify the comments on post processing.


* The 'master' branch has these since the last announcement, in
  addition to the above.

  - git-quiltimport (Eric W. Biederman)

    This will probably see more enhancements over time taking
    inputs from real quilt users.

  - use config file to store remotes information (Johannes Schindelin)

  - pack-objects further 15% improvements (Nicolas Pitre)

  - "diff --check" (Johannes Schindelin)

  - "git apply --cached"

  - read-tree -m -u: do not overwrite or remove untracked working tree files.

  - more built-in commands (Linus, Lukas, Timo and me)
  - commit: allow --pretty= args to be abbreviated (Eric Wong)
  - Other minor fixes to "git apply", "git diff". 

  - many cleanups from Sean Estabrooks, Shawn Pearce, 
      Remove unnecessary local in get_ref_sha1.
      Reference git-check-ref-format in git-branch.
      Elaborate on why ':' is a bad idea in a ref name.

  Also Tilman Sauerbeck twisted my arm sufficiently enough that
  I incorporated some of what I use to generate html/man pages
  automatically every time I update "master" in the main
  Makefile; so if I do not forget to update my release script,
  there will be html/man documentation tarballs next to the
  usual source tarball release when 1.4.0 release is done.


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

 - built-in "git add/rm" (Linus)

   Will merge to "master" shortly, unless somebody finds
   breakage soon enough.

 - built-in "git format-patch" (Johannes Schindelin) 

   Will merge to "master" shortly, unless somebody finds
   breakage soon enough.

 - "git tar-tree --remote"

   This change itself is low-impact and while it is not a
   substitute for true shallow/lazy clone people may find it
   useful in other scenarios.  I dunno.

 - cache-tree with read-tree/write-tree --prefix

   I haven't made any progress on this one, but haven't been
   bitten by it either, so it is a good sign.


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

Eric Wong:
      git-svn: ignore expansion of svn:keywords [test patch]

Sean Estabrooks:
      Remove possible segfault in http-fetch.

Shawn Pearce:
      Improve abstraction of ref lock/write.
      Convert update-ref to use ref_lock API.
      Log ref updates to logs/refs/<ref>
      Support 'master@2 hours ago' syntax
      Fix ref log parsing so it works properly.
      General ref log reading improvements.
      Added logs/ directory to repository layout.
      Force writing ref if it doesn't exist.
      Log ref updates made by fetch.
      Change 'master@noon' syntax to 'master@{noon}'.
      Correct force_write bug in refs.c
      Change order of -m option to update-ref.
      Include ref log detail in commit, reset, etc.
      Create/delete branch ref logs.
      Enable ref log creation in git checkout -b.

What's in git.git

[Junio C Hamano]

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

 - lift length limits from mktag (Björn Engelmann)

 - misc fixes and cleanups (Alex Riesen, Björn Engelmann,
   Linus, Martin Waitz, Peter Eriksen, Sean Estabrooks)

 - git-svn updates, ignores svn:keywords (Eric Wong)

 - documentation updates (J. Bruce Fields)

 - cvsimport updates (Jeff King, Martin Langhoff)

 - built-in format-patch (Johannes Schindelin)

 - built-in many commands (Linus, Peter Eriksen, Timo Hirvonen, me)

 - remote tar-tree

 - "git status -u" (Matthias Lederhofer)

 - more cygwin portability bits (Yakov Lerner)

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

 - handle patches at the beginning and the end of file properly
   (Catalin Marinas, Linus)

 - mailinfo updates (Eric W. Biederman).

 - cache-tree to speed up "apply & write-tree" cycle.

 - http-fetch possible segfault fix (Sean Estabrooks)

 - ref-log (Shawn Pearce)

What's in git.git

[Junio C Hamano]

* The 'master' branch has these since the last announcement.
  This is a fairly big update.

 - git-apply takes notice of beginning and end of file as
   context (Catalin Marinas, Linus and me)
      apply: treat EOF as proper context.
      apply: force matching at the beginning.

 - gitview updates (Aneesh Kumar K.V)

 - git-mailinfo updates (Eric W. Biederman and me)
      Make read_one_header_line return a flag not a length.
      Move B and Q decoding into check header.
      Refactor commit messge handling.
      In handle_body only read a line if we don't already have one.
      More accurately detect header lines in read_one_header_line
      Allow in body headers beyond the in body header prefix.
      mailinfo: skip bogus UNIX From line inside body
      mailinfo: More carefully parse header lines in read_one_header_line()

 - format-patch --start-number (Johannes Schindelin and me)
      cache-tree: replace a sscanf() by two strtol() calls
      Fix crash when reading the empty tree
      git-format-patch --start-number <n>
      built-in format-patch: various fixups.
      format-patch: -n and -k are mutually exclusive.

 - ls-remote rsync:// fix (me)
      ls-remote: fix rsync:// to report HEAD

   * This should fix clone over rsync:// (which is deprecated
     but anyway).

 - cache-tree optimization for apply & write-tree sequence (me,
      Johannes, Dennis Stosberg)
      read-cache/write-cache: optionally return cache checksum SHA1.
      Add cache-tree.
      Update write-tree to use cache-tree.
      Invalidate cache-tree entries for touched paths in git-apply.
      Use cache-tree in update-index.
      Add test-dump-cache-tree
      cache-tree: protect against "git prune".
      index: make the index file format extensible.
      Teach fsck-objects about cache-tree.
      cache-tree: sort the subtree entries.
      test-dump-cache-tree: report number of subtrees.
      update-index: when --unresolve, smudge the relevant cache-tree entries.
      read-tree: teach 1 and 2 way merges about cache-tree.
      read-tree: teach 1-way merege and plain read to prime cache-tree.
      cache_tree_update: give an option to update cache-tree only.
      test-dump-cache-tree: validate the cached data as well.
      cache-tree.c: typefix
      fsck-objects: mark objects reachable from cache-tree
      Fix test-dump-cache-tree in one-tree disappeared case.
      read-tree: invalidate cache-tree entry when a new index entry is added.
      cache-tree: a bit more debugging support.
      fsck-objects: do not segfault on missing tree in cache-tree
      fix git-write-tree with cache-tree on BE64

    * I've held onto this too long but haven't seen breakage.
      This should make cycles of "apply & write-tree" faster by
      15-20%.

 - documentation (Jeff King)
      cat-file: document -p option

 - cvsimport Perl backward compatibility (Jeff King)
      cvsimport: avoid "use" with :tag

 - build fixes (Jim Meyering, Martin Waitz)
      Don't write directly to a make target ($@).
      Documentation/Makefile: remove extra /
      Add instructions to commit template.

 - "git-clone --template" (me)
      Let git-clone to pass --template=dir option to git-init-db.

 - various fixes and cleanups (Linus, Martin Waitz, Petr Baudis,
   Shawn Pearce, me)
      builtin-rm: squelch compiler warnings.
      fetch.c: remove an unused variable and dead code.
      git-fetch: avoid using "case ... in (arm)"
      bogus "fatal: Not a git repository"
      t1002: use -U0 instead of --unified=0
      Fix "--abbrev=xyz" for revision listing
      Don't use "sscanf()" for tree mode scanning
      Call builtin ls-tree in git-cat-file -p
      Built git-upload-tar should be ignored.

 - rev-list --objects memory leak fix (Linus)
      Fix memory leak in "git rev-list --objects"

 - cvsexportcommit fixups (Yann Dirson)
      Do not call 'cmp' with non-existant -q flag.
      Document current cvsexportcommit limitations.
      Make cvsexportcommit create parent directories as needed.


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

 - portability of tests across different bourne flavors (Eric Wong)
      t3300-funny-names: shell portability fixes
      tests: Remove heredoc usage inside quotes
      t5500-fetch-pack: remove local (bashism) usage.
      t6000lib: workaround a possible dash bug

   * I think these are OK to push out to "master".

 - read-tree/write-tree --prefix from bind commit series (me)
      read-tree: --prefix=<path>/ option.
      write-tree: --prefix=<path>
      read-tree: reorganize bind_merge code.

   * I think these are OK to push out to "master".

 - avoid wasted work in fetch-pack when receiving side has more
   roots than the sender (me).
      fetch-pack: give up after getting too many "ack continue"

   * While this would not hurt, it is a client-side hack.  To
     fix the problem properly, the server side needs to become a
     bit smarter.

 - tree parser reorganization (Linus)
      Add raw tree buffer info to "struct tree"
      Make "tree_entry" have a SHA1 instead of a union of object pointers
      Switch "read_tree_recursive()" over to tree-walk functionality
      Remove "tree->entries" tree-entry list from tree parser

   * This looks good; I would like to cook this for a while in
     "next", and mark its graduation with 1.4.0 release.

 - test fix for http-fetch segfault (Sean Estabrooks)

   * Status?

 - ref-log (Shawn Pearce)
      Improve abstraction of ref lock/write.
      Convert update-ref to use ref_lock API.
      Log ref updates to logs/refs/<ref>
      Support 'master@2 hours ago' syntax
      Fix ref log parsing so it works properly.
      General ref log reading improvements.
      Added logs/ directory to repository layout.
      Force writing ref if it doesn't exist.
      Log ref updates made by fetch.
      Change 'master@noon' syntax to 'master@{noon}'.
      Correct force_write bug in refs.c
      Change order of -m option to update-ref.
      Include ref log detail in commit, reset, etc.
      Create/delete branch ref logs.
      Enable ref log creation in git checkout -b.
      Verify git-commit provides a reflog message.
      Test that git-branch -l works.

   * I think these are OK to push out to "master" in that it
     does not seem to cause regression, but I haven't used this
     change for real work.  Impressions?


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

 - $HOME/.gitrc (Petr Baudis)
      Read configuration also from ~/.gitrc

   * I like this but it breaks the tests big time.  Not "next"
     material yet, unfortunately.

What's in git.git

[Junio C Hamano]

It's been a while since I've done v1.4.0, and I haven't fully
caught up with the list traffic yet, but here is the current
status.

I'm planning to manage the v1.4.X series a bit differently
during this round.  So far, they were supposed to be fix-only on
top of v1.4.0, but people who follow the maintenance series
(including the binary packages) missed out on too many good
stuff that happen on the "master" branch.  Also presses like
lwn.net tended to cover the maint series which gets stale pretty
quickly.

So I'll first merge only post-1.4.0 fixes and additions to the
"master" branch until we are comfortable with its shape, tag it
as 1.4.1, and continue.  Essentially, "next" and "pu" will
become the playpens (the first being "not proven but fixable"
changes, the latter being "under consideration, but will not be
missed if dropped" changes) their names originally implied, and
"master" will be what "maint" was supposed to be -- fixes and
good changes.  The old fixes-only maintenance on "maint" branch
will be halted for now -- except maybe when some urgent fixes
are needed, I might do 1.4.X.Y like the kernel folks do.

* The 'master' branch has these since v1.4.0

   Dennis Stosberg:
      Make t4101-apply-nonl bring along its patches

   Eric W. Biederman:
      Don't parse any headers in the real body of an email message.

   Eric Wong:
      git-svn: t0000: add -f flag to checkout
      git-svn: fix handling of filenames with embedded '@'
      git-svn: eol_cp corner-case fixes
      git-svn: restore original LC_ALL setting (or unset) for commit
      git-svn: don't allow commit if svn tree is not current
      git-svn: support -C<num> passing to git-diff-tree
      git-svn: --branch-all-refs / -B support
      git-svn: optimize --branch and --branch-all-ref
      git-svn: support manually placed initial trees from fetch
      git-svn: Move all git-svn-related paths into $GIT_DIR/svn
      git-svn: minor cleanups, extra error-checking
      git-svn: add --repack and --repack-flags= options
      git-svn: add --shared and --template= options to pass to init-db
      git-svn: add some functionality to better support branches in svn
      git-svn: add UTF-8 message test
      git-svn: add 'log' command, a facsimile of basic `svn log'
      git-svn: add support for Perl SVN::* libraries
      git-svn: make the $GIT_DIR/svn/*/revs directory obsolete
      git-svn: avoid creating some small files
      git-svn: fix several small bugs, enable branch optimization
      git-svn: Eliminate temp file usage in libsvn_get_file()
      git-svn: bugfix and optimize the 'log' command
      git-svn: tests no longer fail if LC_ALL is not a UTF-8 locale
      git-svn: svn (command-line) 1.0.x compatibility
      git-svn: rebuild convenience and bugfixes

   Florian Forster:
      gitweb: Adding a `blame' interface.
      gitweb: Make the `blame' interface in gitweb optional.

   Fredrik Kuivinen:
      blame: Add --time to produce raw timestamps

   Jakub Narebski:
      Update gitweb README: gitweb is now included with git

   Junio C Hamano:
      gitk: rereadrefs needs listrefs
      fix git alias
      t5100: mailinfo and mailsplit tests.
      mailinfo: ignore blanks after in-body headers.

   Linus Torvalds:
      gitweb.cgi history not shown

   Martin Langhoff:
      cvsimport: ignore CVSPS_NO_BRANCH and impossible branches
      cvsimport: complete the cvsps run before starting the import
      cvsimport: keep one index per branch during import

   Peter Eriksen:
      Implement safe_strncpy() as strlcpy() and use it more.

   Sean Estabrooks:
      Add a "--notags" option for git-p4import.

   Sven Verdoolaege:
      git-cvsexportcommit.perl: fix typo


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

   Johannes Schindelin:
      diff options: add --color

   I would say this would be fine as is -- diff being quite
   important part of the system, I just wanted to cook it for a
   while.

   Junio C Hamano:
      read-tree: --prefix=<path>/ option.
      write-tree: --prefix=<path>
      read-tree: reorganize bind_merge code.

   I'll have them graduate to "master" soon, as they do not seem
   to hurt anybody.

      fetch-pack: give up after getting too many "ack continue"

   Maybe merge to "master" and see what it breaks.

      shared repository: optionally allow reading to "others".

   This should be ready.  I just want to do another round of
   check.

   Paul Eggert:
      date.c: improve guess between timezone offset and year.

   This is more for the entertainment value than for practical
   value ;-).

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

   Johannes Schindelin:
      Read configuration also from ~/.gitconfig
      repo-config: learn the flag "--no-local"

   I see Pasky has proposed another config change (this time,
   not "also from" but "alternatively from") -- I am not sure
   which one is more appropriate.  Waiting for Johannes's
   response to Pasky's message and hoping the list can agree on
   a single patch series to apply to "next".

      Teach diff about -b and -w flags

   Yakov Lerner:
      auto-detect changed prefix and/or changed build flags

   I think this is fine, except that test-prefix-change target
   is probably unneeded as Martin noticed.

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Sat, 17 Jun 2006, Junio C Hamano wrote:

>       Read configuration also from ~/.gitconfig
>       repo-config: learn the flag "--no-local"
> 
>    I see Pasky has proposed another config change (this time,
>    not "also from" but "alternatively from") -- I am not sure
>    which one is more appropriate.  Waiting for Johannes's
>    response to Pasky's message and hoping the list can agree on
>    a single patch series to apply to "next".

There is one thing I don't like about Pasky's approach: You can change the 
config file name to whatever you like, even if no program will read it. 
That is why I decided to have a flag instead of an option: to prevent 
pilot-errors.

But hey, that is just me.

I cobbled together a patch, which turned out to be rather messy, 
introducing "--config-file <file>" to git-repo-config. If people are 
interested, I'll clean it up and post it. But then, if you already know 
you want to use another config file, you are probably better of just 
exporting GIT_CONFIG_FILE and be done with it.

Note that this issue is orthogonal to the need for a user-specific config 
file. I still think that this one should go in.

Ciao,
Dscho

Re: What's in git.git

[Petr Baudis]

Dear diary, on Sun, Jun 18, 2006 at 02:26:14PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> There is one thing I don't like about Pasky's approach: You can change the 
> config file name to whatever you like, even if no program will read it. 
> That is why I decided to have a flag instead of an option: to prevent 
> pilot-errors.

I'm lost here, admittelly not getting your argument. :-(

> I cobbled together a patch, which turned out to be rather messy, 
> introducing "--config-file <file>" to git-repo-config. If people are 
> interested, I'll clean it up and post it. But then, if you already know 
> you want to use another config file, you are probably better of just 
> exporting GIT_CONFIG_FILE and be done with it.

$GIT_CONFIG_FILE feels nicer since any other git tool can use it as
well, it's not git-repo-config-specific. But the current intent indeed
is to simply override the location for git-repo-config, thus for the
current purposes if we will have --config-file instead of
GIT_CONFIG_FILE, I will not weep; whatever does the job.

> Note that this issue is orthogonal to the need for a user-specific config 
> file. I still think that this one should go in.

I agree as well.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Sun, 18 Jun 2006, Petr Baudis wrote:

> Dear diary, on Sun, Jun 18, 2006 at 02:26:14PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > There is one thing I don't like about Pasky's approach: You can change the 
> > config file name to whatever you like, even if no program will read it. 
> > That is why I decided to have a flag instead of an option: to prevent 
> > pilot-errors.
> 
> I'm lost here, admittelly not getting your argument. :-(

Okay, the point I was driving at:

GIT_CONFIG_FILE=~/.gitrc git repo-config blabla.blibli bloblo

_will_ succeed, but to the user it will be non-obvious that the git 
commands do not pick up on it (because ~/.gitconfig is read instead of 
~/.gitrc), whereas

git repo-config --user blabla.blibli bloblo

is pretty obvious, and _has_ the intended effect.

> > I cobbled together a patch, which turned out to be rather messy, 
> > introducing "--config-file <file>" to git-repo-config. If people are 
> > interested, I'll clean it up and post it. But then, if you already know 
> > you want to use another config file, you are probably better of just 
> > exporting GIT_CONFIG_FILE and be done with it.
> 
> $GIT_CONFIG_FILE feels nicer since any other git tool can use it as
> well, it's not git-repo-config-specific. But the current intent indeed
> is to simply override the location for git-repo-config, thus for the
> current purposes if we will have --config-file instead of
> GIT_CONFIG_FILE, I will not weep; whatever does the job.

Yes, that is true. Forget about my --config-file patch, please.

> > Note that this issue is orthogonal to the need for a user-specific config 
> > file. I still think that this one should go in.
> 
> I agree as well.

Ciao,
Dscho

Re: What's in git.git

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Dear diary, on Sun, Jun 18, 2006 at 02:26:14PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
>
>> Note that this issue is orthogonal to the need for a user-specific config 
>> file. I still think that this one should go in.
>
> I agree as well.

OK, let's have it then.

Johannes, this makes your earlier ~/.gitconfig and --no-local
patches no longer applicable, so I'd drop them from "pu" for
now.  But I suspect we do want to have per user configuration
that is used as a fallback for per repo configuration, right?

I think we should mark what we have in "next" tonight, plus a
few others, as v1.4.1 sometime this coming week and continue
from there.

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Mon, 19 Jun 2006, Junio C Hamano wrote:

> Petr Baudis <pasky@suse.cz> writes:
> 
> > Dear diary, on Sun, Jun 18, 2006 at 02:26:14PM CEST, I got a letter
> > where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> >
> >> Note that this issue is orthogonal to the need for a user-specific config 
> >> file. I still think that this one should go in.
> >
> > I agree as well.
> 
> OK, let's have it then.
> 
> Johannes, this makes your earlier ~/.gitconfig and --no-local
> patches no longer applicable, so I'd drop them from "pu" for
> now.  But I suspect we do want to have per user configuration
> that is used as a fallback for per repo configuration, right?

I'll redo the patches, then.

Ciao,
Dscho

What's in git.git

[Junio C Hamano]

No v1.4.1-rc2 this weekend, as I am expecting a visitor today
and will mostly be offline.  But we got a dozen or so good fixes
and cleanups in "master" so far.

In "next", we have the following being cooked.  I expect most of
them to be in v1.4.1-rc2 sometime next week.  Please report
breakage on any of these if you see one.

 - "git rebase --merge" updates by Eric Wong.
 - "git diff -b -w" by Johannes.
 - "git cvsimport" multi-branch fixes by Martin and Johannes.
 - "git diff --color" can be controlled from $GIT_DIR/config.
 - "git merge --squash"; this may not be strictly needed as it
   can be emulated with repeated use of "cherry-pick -n" but it
   might be handy in some workflows.

In "pu", I have queued other bigger changes.  I do not think
most of them are v1.4.1 material yet.

 - "git format-patch --ignore-already-merged" fixes by
   Johannes; I am hoping to have this in v1.4.1.

 - Perl scripts clean-up and Git.xs by Pasky with a few fixes by
   me; in my mailbox there are several other patches in this
   series not in "pu" that primarily makes more scripts to use
   the new Perl infrastructure.  My feeling is that the series
   needs to be proven to have a sound infrastructure (building,
   testing and installation) on a bit wider platforms before
   starting to consider them for inclusion in "next".  We may be
   able to have the basics from this series in v1.4.1, but am
   still uneasy to convert any important scripts to use this,
   even in "next", at this moment.  Not just yet.

 - built-in "git am" by Lukas; it fails some tests which is not
   a good sign, and as I said in a separate message a few days
   ago, I think it is not worth going this route for something
   high-level as "am", so probably the next round I'd drop the
   last patch from the topic.  The patch to clean up cmd_apply()
   might be worth keeping and merging in "next", depending on
   how the Git.xs effort goes, though.

 - "git diff" option clean-ups by Timo Hirvonen; this is moving
   things in a good direction but as with any intrusive cleanups
   still has some rough edges.  I am hoping we can round them
   off soon to merge it in "next".

 - A new PPC SHA-1 implementation by linux@horizon.com; Linus
   showed that this does not make much difference in real life
   from performance point of view.  If it has other benefits
   (such as code size -- which I do not know how it fares), I am
   willing to merge it as it seems to be correct and does not
   seem to introduce regressions.  But I am not a PPC user so
   somebody needs to push my back on this one.

----------------------------------------------------------------

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

   Jeff King:
      git-commit: allow -e option anywhere on command line

   Johannes Schindelin:
      patch-id: take "commit" prefix as well as "diff-tree" prefix
      apply: replace NO_ACCURATE_DIFF with --inaccurate-eof runtime flag.

   Junio C Hamano:
      Makefile: do not recompile main programs when libraries have changed.
      usage: minimum type fix.
      git-pull: abort when fmt-merge-msg fails.
      diff --color: use reset sequence when we mean reset.
      repo-config: fix printing of bool

   Linus Torvalds:
      Tweak diff colors

   Martin Langhoff:
      git-repack -- respect -q and be quiet

   Matthias Kestenholz:
      add GIT-CFLAGS to .gitignore

   Peter Eriksen:
      Rename safe_strncpy() to strlcpy().

   Petr Baudis:
      Customizable error handlers

   Timo Hirvonen:
      git-merge: Don't use -p when outputting summary
      Clean up diff.c

   Yann Dirson:
      git-commit: filter out log message lines only when editor was run.


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

   Eric Wong:
      rebase: allow --merge option to handle patches merged upstream
      rebase: cleanup rebasing with --merge
      rebase: allow --skip to work with --merge

   Johannes Schindelin:
      Teach diff about -b and -w flags
      cvsimport: always set $ENV{GIT_INDEX_FILE} to $index{$branch}

   Junio C Hamano:
      Makefile: add framework to verify and bench sha1 implementations.
      git-merge --squash
      test-sha1: test hashing large buffer
      diff --color: use $GIT_DIR/config

   Martin Langhoff:
      cvsimport: setup indexes correctly for ancestors and incremental imports


* The 'pu' branch, in addition, has these (this fails the tests).

   Johannes Schindelin:
      add diff_flush_patch_id() to calculate the patch id
      format-patch: introduce "--ignore-if-in-upstream"

   Junio C Hamano:
      Perl interface: add build-time configuration to allow building with -fPIC
      Perl interface: make testsuite work again.
      perl: fix make clean
      Git.pm: tentative fix to test the freshly built Git.pm

   Lukas Sandström:
      Make it possible to call cmd_apply multiple times
      Make git-am a builtin

   Petr Baudis:
      Introduce Git.pm (v4)
      Git.pm: Implement Git::exec_path()
      Git.pm: Call external commands using execv_git_cmd()
      Git.pm: Implement Git::version()
      Add Error.pm to the distribution
      Git.pm: Better error handling
      Git.pm: Handle failed commands' output
      Git.pm: Enhance the command_pipe() mechanism
      Git.pm: Implement options for the command interface
      Git.pm: Add support for subdirectories inside of working copies
      Convert git-mv to use Git.pm
      Git.pm: assorted build related fixes.

   Timo Hirvonen:
      Merge with_raw, with_stat and summary variables to output_format
      Make --raw option available for all diff commands
      Set default diff output format after parsing command line
      DIFF_FORMAT_RAW is not default anymore
      --name-only, --name-status, --check and -s are mutually exclusive
      Remove awkward compatibility warts

   Unknown (linux@horizon.com):
      A better-scheduled PPC SHA-1 implementation.

Re: What's in git.git

[Linus Torvalds]

On Sun, 25 Jun 2006, Junio C Hamano wrote:
> 
>    Timo Hirvonen:
>       Clean up diff.c

THIS IS CRAP!

Dammit, anybody who claims that casting a constant string to "(char *)" is 
a _cleanup_ is doing something seriously wrong.

That's crap, crap, crap, CRAP!

If the "cleanup" was about hiding compiler warnings, then dammit, those 
warnings should be fixed by fixing the code, not by casting the warning 
away but leaving the broken code.

If the ptr really is never accessed, and doesn't matter, then don't use a 
constant empty string, use NULL.

And if it _is_ accessed, then casting a constant string to "char *" is 
_wrong_. 

The whole and only point about the "const" warnings is not to hide them, 
but to fix the code. If you're not going to fix the code, then you 
shouldn't ask the compiler to warn about it, it's that simple. Adding 
bogus casts is not the answer.

I really hate how many _bogus_ casts we're growing. Casts are one of the 
most important features of C (it's what allows you to break the type 
system if you need to, and turns C into the truly extensible language it 
is), but they should be used with reverence and care, not to shut up a 
compiler.

I'm _especially_ disgusted by how this was claimed to be a "cleanup". 
Adding a cast is _never_ a cleanup.

Dammit, don't do crap like this!

THIS is a cleanup:

-               char *prefix = "";
+               const char *prefix = "";

but THESE are total and utter CRAP:

-               mf->ptr = ""; /* does not matter */
+               mf->ptr = (char *)""; /* does not matter */
-                               s->data = "";
+                               s->data = (char *)"";

and we're better off with the warning than with the new code.

I suspect that both could have been made to use NULL instead to indicate 
that no pointer exists.

			Linus

Re: What's in git.git

[Timo Hirvonen]

Linus Torvalds <torvalds@osdl.org> wrote:

> On Sun, 25 Jun 2006, Junio C Hamano wrote:
> > 
> >    Timo Hirvonen:
> >       Clean up diff.c
> 
> THIS IS CRAP!
> 
> Dammit, anybody who claims that casting a constant string to "(char *)" is 
> a _cleanup_ is doing something seriously wrong.
> 
> That's crap, crap, crap, CRAP!

Sorry.  It got really annoying to skip over the same compiler warnings
in vim's quickfix window many times.  At that time I just wanted to
focus on the code I was writing.

> but THESE are total and utter CRAP:
> 
> -               mf->ptr = ""; /* does not matter */
> +               mf->ptr = (char *)""; /* does not matter */
> -                               s->data = "";
> +                               s->data = (char *)"";
> 
> and we're better off with the warning than with the new code.
> 
> I suspect that both could have been made to use NULL instead to indicate 
> that no pointer exists.

I'll look into this.

-- 
http://onion.dynserv.net/~timo/

Re: What's in git.git

[Linus Torvalds]

On Sun, 25 Jun 2006, Timo Hirvonen wrote:
> > 
> > I suspect that both could have been made to use NULL instead to indicate 
> > that no pointer exists.
> 
> I'll look into this.

An alternative is to really mark the char pointer structure members const. 
That is often the preferred thing to do, if usage allows it.

The biggest problem I've traditionally had with structure members that are 
"const char *" has ironically been that the standard C definition of 
"free()" is misdesigned. 

"free()" should take a "const volatile void *", not just a "void *". As it 
is, you often have to cast things to free() just to avoid the warning 
about discarding qualifiers. Which is really sad.

It's perfectly valid to do something like

	struct xyzzy {
		const char *member;
		..
	};

	s->member = strdup(string);
	..
	free(s->member);
	free(s)

but sadly, that member free generates a (bogus) warning.

Of course, we should probably do a "xfree()" anyway, to match our 
"x[c|re]alloc()".

			Linus

Re: What's in git.git

[Martin Langhoff]

On 6/25/06, Junio C Hamano <junkio@cox.net> wrote:
>  - "git cvsimport" multi-branch fixes by Martin and Johannes.

Note: I have the nagging suspicion that there's a thinko in the
opening of new branches, but can't get into fixing that till later
today.

cheers,



martin

Re: What's in git.git

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> I suspect that both could have been made to use NULL instead to indicate 
> that no pointer exists.

As long as none of the following does not dereference the NULL
pointer that should work fine:

	- memchr(NULL, ch, 0);

        - memcmp(NULL, ptr, 0);

        - stream.next_in = NULL;
          stream.avail_in = 0;
          deflate(&stream, Z_FINISH);

Re: What's in git.git

[Linus Torvalds]

On Mon, 26 Jun 2006, Junio C Hamano wrote:
> 
> As long as none of the following does not dereference the NULL
> pointer that should work fine:
> 
> 	- memchr(NULL, ch, 0);
> 
>         - memcmp(NULL, ptr, 0);
> 
>         - stream.next_in = NULL;
>           stream.avail_in = 0;
>           deflate(&stream, Z_FINISH);

Well, they clearly _shouldn't_, but bugs happen in libraries too.

(The reason they shouldn't is simple: replace the NULL pointer with a 
perfectly normal pointer at the end of a page, and if you access past the 
length of the memory area, you'd get the same SIGSEGV that a NULL pointer 
should give you).

So the question is how much to trust the libraries for a special case that 
has a clearly "Right Answer", but is probably unusual in practice.

(That said, "malloc(0)" can validly return NULL, so the NULL+<zero length> 
thing can really happen in real code even if it's not explicit).

If people want to be anally defensive, we should give it a valid pointer. 
If there are known buggy libraries, I wouldn't object to something 
explicit like

	#define DUMMYPTR ((void *)"")

and hide it that way - the code may be the exact same thing that I 
objected to, but now you're showing that you know that the cast is crud, 
and you're just wanting to pass in some non-NULL valid pointer that can be 
dereferenced but never written to.

Personally, I think NULL is much better, until somebody shows an actual 
buggy library.

			Linus

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Mon, 26 Jun 2006, Linus Torvalds wrote:

> 	#define DUMMYPTR ((void *)"")

NULL_STRING describes better what you want.

Ciao,
Dscho

What's in git.git

[Junio C Hamano]

Hopefully 'master' which I tagged and pushed out as v1.4.1-rc2
is very close to the final.  I would like to merge format-patch
fixes by Johannes, see nobody yells at me for a few days, and
call it 1.4.1 this weekend.

Thanks to Pavel Roskin and Marco Roeland, the Perly Git series
by Pasky should be in much better shape now.  Timo's diff output
format options updates is looking better and I am gaining
confidence in it, especially after I've done small testsuite and
fixed things here and there.  I would want a bit more tests to
cover wider combinations to avoid regression but basically it
looks ready.  These two series are still in "pu" and I'd like to
pull them into "next" after 1.4.1.

A late comer is Linus's merge-tree/merge-files work.  I'm
parking it on "pu" but haven't read it through yet.

----------------------------------------------------------------

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

   Andreas Ericsson:
      git wrapper: fix command name in an error message.

   Dennis Stosberg:
      Solaris needs inclusion of signal.h for signal()
      Fix pkt-line.h to compile with a non-GCC compiler
      Fix expr usage for FreeBSD

   Eric Wong:
      rebase: allow --merge option to handle patches merged upstream
      rebase: cleanup rebasing with --merge
      rebase: allow --skip to work with --merge
      git-svn: SVN 1.1.x library compatibility
      git-svn: several graft-branches improvements
      git-svn: add the commit-diff command
      git-svn: add --follow-parent and --no-metadata options to fetch
      git-svn: be verbose by default on fetch/commit, add -q/--quiet option
      rebase: get rid of outdated MRESOLVEMSG
      rebase: check for errors from git-commit

   Jeff King:
      quote.c: silence compiler warnings from EMIT macro

   Johannes Schindelin:
      Teach diff about -b and -w flags
      cvsimport: always set $ENV{GIT_INDEX_FILE} to $index{$branch}
      Save errno in handle_alias()

   Junio C Hamano:
      git-merge --squash
      diff --color: use $GIT_DIR/config
      combine-diff.c: type sanity
      connect.c: remove unused parameters from tcp_connect and proxy_connect
      connect.c: check the commit buffer boundary while parsing.
      t/README: start testing porcelainish
      checkout -m: fix read-tree invocation

   Martin Langhoff:
      cvsimport: setup indexes correctly for ancestors and incremental imports
      cvsimport - cleanup of the multi-indexes handling

   Matthias Lederhofer:
      correct documentation for git grep

   Timo Hirvonen:
      Make some strings const


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

   Johannes Schindelin:
      add diff_flush_patch_id() to calculate the patch id
      format-patch: introduce "--ignore-if-in-upstream"
      t4014: fix for whitespace from "wc -l"
      format-patch: use clear_commit_marks() instead of some ad-hockery

   Junio C Hamano:
      Makefile: add framework to verify and bench sha1 implementations.
      test-sha1: test hashing large buffer
      git-repack: Be careful when updating the same pack as an existing one.
      t4013: add tests for diff/log family output options.
      t4014: add format-patch --ignore-if-in-upstream test
      t4013: add more tests around -c and --cc
      t4014: fix test commit labels.
      diff.c: fix get_patch_id()

   Linus Torvalds:
      xdiff: generate "anti-diffs" aka what is common to two files


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

   Dennis Stosberg:
      "test" in Solaris' /bin/sh does not support -e
      Makefile fix for Solaris
      Add possibility to pass CFLAGS and LDFLAGS specific to the perl subdir

   Junio C Hamano:
      Fix some more diff options changes.
      t4013 test updates for new output code.
      combine-diff.c: type sanity.
      Perl interface: add build-time configuration to allow building with -fPIC
      Perl interface: make testsuite work again.
      perl: fix make clean
      Git.pm: tentative fix to test the freshly built Git.pm
      Perly Git: arrange include path settings properly.
      Makefile: Set USE_PIC on x86-64

   Linus Torvalds:
      Prepare "git-merge-tree" for future work
      Improved three-way blob merging code

   Matthias Lederhofer:
      GIT_TRACE: show which built-in/external commands are executed

   Petr Baudis:
      Introduce Git.pm (v4)
      Git.pm: Implement Git::exec_path()
      Git.pm: Call external commands using execv_git_cmd()
      Git.pm: Implement Git::version()
      Add Error.pm to the distribution
      Git.pm: Better error handling
      Git.pm: Handle failed commands' output
      Git.pm: Enhance the command_pipe() mechanism
      Git.pm: Implement options for the command interface
      Git.pm: Add support for subdirectories inside of working copies
      Convert git-mv to use Git.pm
      Git.pm: assorted build related fixes.
      Git.pm: Try to support ActiveState output pipe
      Git.pm: Swap hash_object() parameters
      Git.pm: Fix Git->repository("/somewhere/totally/elsewhere")
      Git.pm: Support for perl/ being built by a different compiler

   Timo Hirvonen:
      Merge with_raw, with_stat and summary variables to output_format
      Make --raw option available for all diff commands
      Set default diff output format after parsing command line
      DIFF_FORMAT_RAW is not default anymore
      Add msg_sep to diff_options
      Don't xcalloc() struct diffstat_t
      whatchanged: Default to DIFF_FORMAT_RAW
      Print empty line between raw, stat, summary and patch
      diff-tree: Use ---\n as a message separator
      log --raw: Don't descend into subdirectories by default
      Fix diff-tree -s
      --name-only, --name-status, --check and -s are mutually exclusive
      Remove awkward compatibility warts
      Fix a mixed declarations and code warning

   Unknown:
      A better-scheduled PPC SHA-1 implementation.

What's in git.git

[Junio C Hamano]

The 'master' branch has been pushed out as GIT 1.4.1 tonight to
celebrate the birthday of lady gitster.

In "next", there are the following series:

 - rationalize diff output options by Timo Hirvonen.

   This makes "diff --patch --stat" operate sensibly.  I have
   added about 100 tests to make sure that this does not regress
   diff/log commands, and made small fixups to Timo's version
   here and there.

   There are still slight differences in output between the
   current "master" version and Timo's version, but I believe
   they are all improvements.  Curious people may want to take a
   look at the following two commits that updates the tests to
   match Timo's output:

	commit 026625e78eaf8ea2ae960525c367b5e8f1629fd4
	commit 9e76bab14e50c46c624ae35f13c527a7a1b1185d

   I think this is ready to be merged into "master", but further
   testing is appreciated.

 - A few Makefile clean-ups by Jakub Narebski.

   This is part of Jakub's "optionally manage config.mk with
   autoconf generated configure script" series.  I have not been
   queueing the rest of the series but judging from the list
   traffic and the size and quality of the later pieces, the
   patch series might have stabilized enough to be resubmitted
   for consideration.  Honestly, I am still somewhat reluctant,
   but my impression was it was still strictly "opt-in" so it
   might be OK.

 - git_merge_bases() by Johannes.

   Calling commit ancestry walkers more than once correctly is
   hard, and that is why I have accepted the libifying part with
   the change to use the lib by one caller that calls the
   function only once, without merging anything that calls the
   function more than once.

   I think this library part, with the clean-up by Rene Scharfe
   in "pu", is in good shape to be tested further.  The '...'
   operator work would be a good demonstration to prove the
   libification is sound, before proceeding to bigger and more
   interesting users, like merge-recursive in C by Alex Riesen.

   Alex/Johannes team's effort seems to be progressing nicely
   and I am looking forward to seeing a version that is stable
   enough for testing.

 - gitweb updates by Dennis Stosberg and Luben Tuikov.

   I am personally running this on my private machine to see the
   progress made by Jakub so far with these updates, and am
   generally happy.  I'd like to see the code further refactored
   before picking up any more new features, though.  I see Jakub
   is talking with xmms2 team and am hoping to see we can see
   more cleanups they made in our tree soon (thanks Jakub).

 - instaweb by Eric Wong.

   I made a mismerge when accepting this series and "next" ended
   up with two copies of three "gitweb" related patches.  Sorry
   for cluttering the history.

 - "A better scheduled PPC SHA-1 implementation" by linux@horizon.com

 - git-merge-tree WIP by Linus.

   I should take a look at this and follow it through but
   haven't spent as much time as I should have nor I would have
   liked yet.


In "pu", there are more interesting pieces:

 - updates to git-merge-bases with '...' operator by Rene Scharfe.

   This should come in "next" but I think Johannes has a point
   that library interface should be the easier-to-use version.

   Maybe we should have get_merge_bases_unclean() as an oddball
   function that does not clean up for performance, and make
   git-merge-base call that, and keep the name of the function
   for generic callers that does clean up short and sweet
   get_merge_bases().

 - updates to diff options rationalization by Timo Hirvonen.

   This makes --name-only, --name-status, --check and -s
   mutually exclusive, and makes 'git diff-files -s' behave like
   other diff commands (i.e. -s means "silent" -- so no output
   is seen).  These are both optional.

 - "Perly Git" series by Pasky and Pavel Roskin.

   I've heard success stories from some but negatives from
   others.  Feedback from people other than who are on Linux
   i386/x86-64 with Perl 5.8 are appreciated.

   In order to get a bit wider exposure without disrupting
   people, we might want to revert the fmt-merge-msg conversion
   with a workaround option in Makefile to allow skipping the
   build of perl/ subdirectory, and merge the result to "next".

 - GIT_TRACE by Matthias Lederhofer.
 - "git grep boolean expression" by me.

   I am not personally interested in these two very much, but I
   do not think they break anything.  I may push them to "next"
   or keep them lingering on in "pu".  I do not care too much
   either way myself -- people who are interested need to push
   my back.

What's in git.git

[Junio C Hamano]

Many fixes came in since 1.4.1 was done.  Please see the
short-log for what's new in "master".

In the "next" branch, these are cooking:

 - Early parts of Perly Git by Petr Baudis with help from others
   are merged to "next".  Please report breakages before other
   Perl scripts are converted to use this.

 - "diff --text" by Stephan Feder.  I think this one is correct
   and should be very safe, but bugs happen to "obvious" code
   too, so I have not merged it to "master" yet.
 
 - Move git-svn by Eric Wong out of contrib to make it a
   first-class citizen.

 - "git-merge-tree" improvements by Linus.  I may want to update
   this to use our diff routines, but probably after OLS.

In "pu", there are a few more:

 - An updated result minimization code in merge-base.  I think
   this is correct and is not too expensive.  I'd like to run a
   few more test on this and merge it to "next".

 - Updated upload-pack to avoid letting the downloader to
   traverse commits from a branch all the way down to root in
   vain, when that root is knot known to upload-pack.  This
   needs another round of test with something like Linus's 2.6
   repository and MIPS repository, which costs me quite a lot of
   time so I am postponing it right now.

 - Built-in git-prune by Linus.  I have read the code and did
   not spot problems, and it indeed is a lot faster.  But this
   is git-prune, so I am playing it a bit more cautiously than I
   usually do.

 - GIT_TRACE by Matthias Lederhofer.  What it lets you do is
   interesting (although I personally do not foresee myself
   using it), and I am in favor of its inclusion.  The issue
   that the mechanism does not let you trace some commands
   (scripts) raised on the list has stalled this topic branch.
   I'd either want people to agree that it is not a problem, or
   if they feel it is a problem, have a fix for that, before
   merging this to "next".

 - Auto configuration by Pasky and Jakub.  This deserves a fresh
   paragraph.

The first patch to use autoconf to build ./configure by Jakub
Narebski is in "pu".  I am not against an autoconfiguration
mechanism to maintain config.mak.gen mechanically as an _option_,
and if we are going to have a ./configure script, it would be
better to avoid reinventing the tests autoconf people worked for
a long time to make robust and portable.  

I hope further patches to this series will be added soon to
autodetect the following in our Makefile (from "pu"):

        NO_D_INO_IN_DIRENT
        NO_D_TYPE_IN_DIRENT
        NO_STRCASESTR
        NO_STRLCPY
        NO_SETENV
        USE_PIC
        NEEDS_SSL_WITH_CRYPTO
        NEEDS_LIBICONV
        NEEDS_SOCKET
        WITH_OWN_SUBPROCESS_PY
        NO_IPV6
        NO_SOCKADDR_STORAGE
        NO_ICONV

These are not something you can change without replacing libc
(or installed Python) wholesale, so autodetection would be
always correct.

Also the following would be nice if autodetection worked for
most of the users with ./configure command line override:

	CC
        AR
	TAR
        INSTALL
	SHELL_PATH
        PERL_PATH
        PYTHON_PATH
	BASIC_CFLAGS 	mostly for -I include paths
        BASIC_LDFLAGS	mostly for -L library paths
	ALL_LDFLAGS
	NO_OPENSSL
        MOZILLA_SHA1
        PPC_SHA1
        ARM_SHA1
        NO_CURL
        NO_EXPAT
        CURLDIR
        OPENSSLDIR
        ICONVDIR
        EXPATDIR (we do not have one, but I think it should be there
		  to allow -lexpat installed elsewhere just like
                  we have CURLDIR and OPENSSLDIR)

Note that I listed NO_OPENSSL, NO_CURL, and NO_EXPAT here not
with the first category, because you may not want to build git
with them even when you do have these libraries.

The directories our stuff will go is builder's policy, so I do
not think automating it is particularly useful, but I am not
opposed if ./configure allowed people to say --prefix=blah.

Because the autodetection of non-policy part is what I primarily
want from ./configure, people who run ./configure without giving
particular --prefix and friends to it should not be burned by
the choice ./configure makes by default.  I presume they can
have their own customized prefix and friends in config.mak which
will be included after config.mak.gen so hopefully that is a
non-issue.

----------------------------------------------------------------

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

   Dennis Stosberg:
      gitweb: Declare global variables with "our"

   Eric Wong:
      Add git-instaweb, instantly browse the working repo with gitweb
      instaweb: fix unportable ';' usage in sed
      t8001-annotate: fix a bash-ism in this test
      git-svn: avoid fetching files outside of the URL we're tracking
      builtin-log: respect diff configuration options

   Jakub Narebski:
      send-email: format 2822 datestring ourselves.

   Joachim B Haga:
      Make zlib compression level configurable, and change default.
      core.compression documentation formatting fix.

   Johannes Schindelin:
      refactor merge_bases() as preparation to libify merge-base
      move get_merge_bases() to core lib.
      Makefile: replace ugly and unportable sed invocation
      Make git-fmt-merge-msg a builtin

   Junio C Hamano:
      Makefile: add framework to verify and bench sha1 implementations.
      test-sha1: test hashing large buffer
      t4013: add tests for diff/log family output options.
      t4013: add more tests around -c and --cc
      Fix some more diff options changes.
      t4013 test updates for new output code.
      combine-diff.c: type sanity.
      format-patch: fix diff format option implementation
      t4013: add format-patch tests.
      t4013: note improvements brought by the new output code.
      gitweb: optimize per-file history generation
      t4013: add "diff" UI program tests.
      builtin-diff: turn recursive on when defaulting to --patch format.
      commit.c: do not redefine UNINTERESTING bit.
      Makefile: tighten git-http-{fetch,push} dependencies
      get_merge_bases: clean up even when there is no common commit.
      revert clear-commit-marks for now.
      boolean: accept yes and no as well
      send-email: do not barf when Term::ReadLine does not like your terminal
      t6200: fmt-merge-msg test.
      git-grep: fix parsing of pathspec separator '--'
      git-grep: fix exit code when we use external grep.
      git-grep: use a bit more specific error messages.
      Re-fix clear_commit_marks().
      git-reset: complain and exit upon seeing an unknown parameter.
      builtin-rev-parse.c: constness tightening
      show-branch: match documentation and usage
      rev-parse documentation: talk about range notation.

   Linus Torvalds:
      revision.c: fix "dense" under --remove-empty
      Improve git-peek-remote

   Luben Tuikov:
      gitweb: Enable tree (directory) history display

   Rene Scharfe:
      Add get_merge_bases_clean()
      Add '...' operator for revisions
      Make clear_commit_marks() clean harder
      Fold get_merge_bases_clean() into get_merge_bases()
      rev-list: free commit_list in ... handler

   Robin Rosenberg:
      Empty author may be presented by svn as an empty string or a null value.

   Ryan Anderson:
      annotate: Support annotation of files on other revisions.
      annotate: Correct most merge following to annotate correctly.

   Santi Béjar:
      Teach rev-parse the ... syntax.

   Stephan Feder:
      Do not drop data from '\0' until eol in patch output

   Timo Hirvonen:
      Merge with_raw, with_stat and summary variables to output_format
      Make --raw option available for all diff commands
      Set default diff output format after parsing command line
      DIFF_FORMAT_RAW is not default anymore
      Add msg_sep to diff_options
      Don't xcalloc() struct diffstat_t
      whatchanged: Default to DIFF_FORMAT_RAW
      Print empty line between raw, stat, summary and patch
      diff-tree: Use ---\n as a message separator
      log --raw: Don't descend into subdirectories by default
      Fix diff-tree -s

   Unknown:
      A better-scheduled PPC SHA-1 implementation.

   Ville Skyttä:
      Fix print-log and diff compatibility with recent vc versions


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

   Dennis Stosberg:
      "test" in Solaris' /bin/sh does not support -e
      Makefile fix for Solaris
      Add possibility to pass CFLAGS and LDFLAGS specific to the perl subdir

   Eric Wong:
      git-svn: migrate out of contrib
      git-svn: migrate out of contrib (follow-up)
      diff.c: respect diff.renames config option

   Jakub Narebski:
      Allow INSTALL, bindir, mandir to be set in main Makefile
      Rename man1 and man7 variables to man1dir and man7dir

   Johannes Schindelin:
      Git.xs: older perl do not know const char *
      Makefile: export NO_SVN_TESTS

   Junio C Hamano:
      Perl interface: add build-time configuration to allow building with -fPIC
      Perl interface: make testsuite work again.
      perl: fix make clean
      Git.pm: tentative fix to test the freshly built Git.pm
      Perly Git: arrange include path settings properly.
      Makefile: Set USE_PIC on x86-64
      Perly git: work around buggy make implementations.
      Git.pm: clean generated files.
      Perly Git: make sure we do test the freshly built one.
      INSTALL: a tip for running after building but without installing.
      git-grep: boolean expression on pattern matching.
      mailinfo: assume input is latin-1 on the header as we do for the body
      diffcore-rename: try matching up renames without populating filespec first.
      diff.c: --no-color to defeat diff.color configuration.
      Update diff-options and config documentation.
      git log -p --merge [[--] paths...]

   Linus Torvalds:
      xdiff: generate "anti-diffs" aka what is common to two files
      Prepare "git-merge-tree" for future work
      Improved three-way blob merging code

   Pavel Roskin:
      Fix probing for already installed Error.pm
      Delete manuals if compiling without docs
      Make perl interface a separate package

   Petr Baudis:
      Introduce Git.pm (v4)
      Git.pm: Implement Git::exec_path()
      Git.pm: Call external commands using execv_git_cmd()
      Git.pm: Implement Git::version()
      Add Error.pm to the distribution
      Git.pm: Better error handling
      Git.pm: Handle failed commands' output
      Git.pm: Enhance the command_pipe() mechanism
      Git.pm: Implement options for the command interface
      Git.pm: Add support for subdirectories inside of working copies
      Convert git-mv to use Git.pm
      Git.pm: assorted build related fixes.
      Git.pm: Try to support ActiveState output pipe
      Git.pm: Swap hash_object() parameters
      Git.pm: Fix Git->repository("/somewhere/totally/elsewhere")
      Git.pm: Support for perl/ being built by a different compiler
      Git.pm: Remove PerlIO usage from Git.xs
      Git.pm: Avoid ppport.h
      Git.pm: Don't #define around die
      Use $GITPERLLIB instead of $RUNNING_GIT_TESTS and centralize @INC munging
      Git.pm: Add config() method
      Convert git-send-email to use Git.pm
      Git.pm: Introduce ident() and ident_person() methods

   Stephan Feder:
      Teach --text option to diff
      Teach diff -a as shorthand for --text
      Add -a and --text to common diff options help
      diff-options: Explain --text and -a

   Timo Hirvonen:
      --name-only, --name-status, --check and -s are mutually exclusive


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

   A Large Angry SCM:
      Additional merge-base tests (revised)

   Jakub Narebski:
      autoconf: Use autoconf to write installation directories to config.mak.autogen

   Junio C Hamano:
      merge-base: update the clean-up postprocessing
      upload-pack: use object pointer not copy of sha1 to keep track of has/needs.
      upload-pack: lift MAX_NEEDS and MAX_HAS limitation
      upload-pack: minor clean-up in multi-ack logic
      upload-pack: stop the other side when they have more roots than we do.
      Work around sed and make interactions on the backslash at the end of line.

   Linus Torvalds:
      builtin "git prune"

   Matthias Lederhofer:
      GIT_TRACE: show which built-in/external commands are executed

   Peter Baumann:
      git-cvsexportcommit can't handle merge commits correctly

   Petr Baudis:
      Make it possible to set up libgit directly (instead of from the environment)
      Git.pm: Introduce fast get_object() method
      Convert git-annotate to use Git.pm

   Timo Hirvonen:
      Remove awkward compatibility warts
      GIT_TRACE: fix a mixed declarations and code warning

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Fri, 7 Jul 2006, Junio C Hamano wrote:

>  - Early parts of Perly Git by Petr Baudis with help from others
>    are merged to "next".  Please report breakages before other
>    Perl scripts are converted to use this.

I saw many problems on my machines with this, just as I expected. Please 
play it _really_ safe. I hated to be forced to rewrite git-fmt-merge-msg 
in C, but I just could not use 'next' without that. I would hate it even 
more to rewrite git-mv in C just to make the tests happy (they are not on 
my iBook right now).

>  - GIT_TRACE by Matthias Lederhofer.  What it lets you do is
>    interesting (although I personally do not foresee myself
>    using it), and I am in favor of its inclusion.  The issue
>    that the mechanism does not let you trace some commands
>    (scripts) raised on the list has stalled this topic branch.
>    I'd either want people to agree that it is not a problem, or
>    if they feel it is a problem, have a fix for that, before
>    merging this to "next".

You probably allude to my comments, which were meant more as a hint to go 
towards C, instead of scripts. There is a lot to be said about C, but the 
fact is: if you have most of the core of git in C (if not all of it), you 
have less problems (especially when integrating over _all_ platforms and 
setups).

As it is, I am all for inclusion of GIT_TRACE support. If need be, 
everybody can add GIT_TRACE support to the script she is debugging. And if 
she's nice, she can send a patch to the list, too.

>  - Auto configuration by Pasky and Jakub.  This deserves a fresh
>    paragraph.

I can see why some may want autoconf (or a clone of MPlayer's configure) 
in git. But the fact is: on many platforms, the Makefile works out of the 
box. Especially on cygwin, where _any_ shell script -- and autoconf 
generated scripts in particular -- are slower than a dog's poo, it is 
_soooo_ much better to be able to just say "make".

Please, please, _please_ keep autoconfiguration _strictly_ opt-in.

>    Linus Torvalds:
>       builtin "git prune"

FWIW, I read the code, too, and I agree it is ready for 'next'. After my 
first read, I was curious why the parameter "object_array *p" was needed 
for all the process_* functions. It turned out that add_object() needs 
this. Just in case anybody else wonders.

Ciao,
Dscho

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

> I hope further patches to this series will be added soon to
> autodetect the following in our Makefile (from "pu"):

I have just (re)sent series of patches adding autodetection
of building options via autoconf generated configure.
 
>         NO_D_INO_IN_DIRENT
>         NO_D_TYPE_IN_DIRENT
>         NO_STRCASESTR
>         NO_STRLCPY
>         NO_SETENV
>         NO_SOCKADDR_STORAGE
Done.

>         USE_PIC
To be written by somebody better versed in autoconf.

>         NEEDS_SSL_WITH_CRYPTO
>         NEEDS_LIBICONV
>         NEEDS_SOCKET
Needs checking.

>         WITH_OWN_SUBPROCESS_PY
>         NO_IPV6
>         NO_ICONV
Needs explanation, and probably custom test.

> These are not something you can change without replacing libc
> (or installed Python) wholesale, so autodetection would be
> always correct.
> 
> Also the following would be nice if autodetection worked for
> most of the users with ./configure command line override:
> 
>       CC
>       AR
>       TAR
Done, I think

>       INSTALL
Needs lightweight install-sh script. If I remember correctly someone 
provided such script because of lack of install on some exotic 
architecture. Easily provided.

>       SHELL_PATH
>       PERL_PATH
>       PYTHON_PATH
To be done using --with-shell=PATH, --with-perl=PATH, 
--with-python=PATH, easily.

>       BASIC_CFLAGS    mostly for -I include paths
>       BASIC_LDFLAGS   mostly for -L library paths
>       ALL_LDFLAGS
I don't know how to do this (for now), probably quite easy.

>       NO_OPENSSL
>       MOZILLA_SHA1
>       PPC_SHA1
>       ARM_SHA1
>       NO_CURL
>       NO_EXPAT
>       CURLDIR
>       OPENSSLDIR
>       ICONVDIR
>       EXPATDIR (we do not have one, but I think it should be there
>                 to allow -lexpat installed elsewhere just like
>                 we have CURLDIR and OPENSSLDIR)
Should be done in next series of patches... provided I'd have enough 
free time for this... 

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

What's in git.git

[Junio C Hamano]

Quite a bit of stuff has been merged, and I have tagged the tip
of the master as v1.4.2-rc1, before heading for Ottawa.

Notable changes in the "master" branch includes:

  - Merge-base has been improved thanks to a test script by
    ALASCM.

  - A handful gitweb enhancements and fixes by Alp Toker and
    Luben Tuikov.

  - git-svn is now out of "contrib/" status.

  - Many documentation updates.

  - Fixed a performance bug in git-show-branch, which affected
    git-merge.

  - Fixed a nonsense output from git-fmt-merge-msg when pulling
    HEAD from a remote repository, spotted by Linus.

  - "git-log --merge" helps the archeology during a conflicted
    merge, per request by Linus.

  - git-grep boolean expression to allow --and, --or, and --not
    is now in "master".

  - A few updates to git-daemon by Matthias Lederhofer.

  - A handful portability fixes by Pavel Roskin and Shawn Pearce.

  - Ref-log updates by Shawn Pearce.


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

  - "checkout -f" and "reset --hard" fixes, when the new tree
    should have file "foo" and the old tree and/or working tree
    has directory there.  Earlier we failed to instantiate file
    "foo", and did not report an error.  Testing is appreciated.

  - git-apply fixes that was started by a test script by Eric
    Wong.  Testing is appreciated on this stuff.

  - Perly git by Pasky with help from others.

  - Optional autoconf by Jakub Narebski.

  - A WIP of merge-recursive by Johannes and Alex Riesen.

  - A usability enhancement of format-patch for imap-send users by
    Josh Triplett

  - A new loose object format support by Linus.

  - An update to diff to make --name-only, --name-status,
    --check and -s mutually exclusive by Timo Hirvonen.

* The 'pu' branch has an experimental "read-tree --rename" to
  teach renames to git-merge-resolve, but currently it fails a
  few of its own tests.


I noticed that "git diff" from subdirectories does not seem to
pick up the configuration from $GIT_DIR/config properly.  I
suspect that fixing this breakage properly would help us later,
as more and more commands learn to use the configuration
mechanism to store user preferences, and the same fix would be
applicable to them.  If somebody can fix this while we are away
this week, that would be wonderful ;-).

What's in git.git

[Junio C Hamano]

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

  I've merged too many stuff since 1.4.2-rc2, so there will be
  1.4.2-rc3 tonight and hopefully things can be stabilized to
  tag 1.4.2 over the weekend.

  - autoconf stuff by Jakub Narebski
  - portability to GNU/kFreeBSD by Gerrit Pape
  - various cleanups and fixes by Johannes
  - built-in git-mv by Johannes
  - git-apply -R by Johannes
  - setup_git_directory cleanups by Linus
  - gitweb clean-ups and blame improvements by Luben Tuikov
  - commit walker updates by Pasky
  - rebase tweaks by Robert Shearman
  - more tests and documentation updates

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

  - Git.pm by Pasky with help from Pavel Roskin and others.

    I'd like to merge this immediately after 1.4.2, unless there
    still are concerns about its portability (in which case
    please help fixing them up before this hits the "master"
    branch).

  - many gitweb cleanups by Jakub Narebski, Martin Waitz and
    Matthias Lederhofer.

    I think these are low-impact and generally good changes.

  - "merge-recur" by Johannes and Alex with help from others.

    I still see a few TODO here and there in the code, but it
    appears that this operates correctly (I've been using this
    for real work for some time).  Do we have benchmarks?

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

   Johannes Schindelin:
      Add the --color-words option to the diff options family

   Junio C Hamano:
      upload-pack: minor clean-up in multi-ack logic
      upload-pack: stop the other side when they have more roots than we do.
      read-tree --rename and merge-rename

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Tue, 1 Aug 2006, Junio C Hamano wrote:

>   - Git.pm by Pasky with help from Pavel Roskin and others.
> 
>     I'd like to merge this immediately after 1.4.2, unless there
>     still are concerns about its portability (in which case
>     please help fixing them up before this hits the "master"
>     branch).

Although I am admittedly not a big fan of this dependency (it is one thing 
to depend on perl, but another to depend on compiling C modules for perl), 
I have to say that on all machines I tested, it works fine now. The only 
platform I did not test is IRIX, and I'll do that on Friday.

>   - "merge-recur" by Johannes and Alex with help from others.
> 
>     I still see a few TODO here and there in the code, but it
>     appears that this operates correctly (I've been using this
>     for real work for some time).  Do we have benchmarks?

As for the TODOs: they are strictly non-functional. But I think we can 
squash the remaining three until Monday.

As for benchmarks, Alex has a very nasty test-case, where the Python 
script takes ages: 10 minutes as compared to just over 2 minutes with our 
recursive merge.

Unfortunately, resolve beats that easily with less than 3 seconds ;-)

>    Johannes Schindelin:
>       Add the --color-words option to the diff options family

BTW I realized it is not really colouring words, since I erroneously 
selected word boundaries at whitespace. But if the only reaction to this 
is your "soooooooo strange", I guess you'll drop it...

>       read-tree --rename and merge-rename

Do you have any numbers on that? I could imagine that merge-recursive 
could be rewritten as a shell script using this and git-merge-base...

Ciao,
Dscho

Re: What's in git.git

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Although I am admittedly not a big fan of this dependency (it is one thing 
> to depend on perl, but another to depend on compiling C modules for perl), 
> I have to say that on all machines I tested, it works fine now. The only 
> platform I did not test is IRIX, and I'll do that on Friday.

Thanks.

>>    Johannes Schindelin:
>>       Add the --color-words option to the diff options family
>
> BTW I realized it is not really colouring words, since I erroneously 
> selected word boundaries at whitespace. But if the only reaction to this 
> is your "soooooooo strange", I guess you'll drop it...

Perhaps, I dunno.

>>       read-tree --rename and merge-rename
>
> Do you have any numbers on that? I could imagine that merge-recursive 
> could be rewritten as a shell script using this and git-merge-base...

I think "read-tree --rename" is now becoming into a debuggable
shape.

One bad thing about it is that merge-rename uses the usual
merge-one-file, and it loses a rename merge conflict because of
that.  When our branch renames A to B while their branch renames
A to C, "read-tree --rename" notices it and leaves A, B, and C
in stage #1, #2, and #3, but merge-one-file resolves these paths
following the usual 3-way merge rules, resulting A to be removed
and both B and C created.

Re: What's in git.git

[Alex Riesen]

On 8/2/06, Junio C Hamano <junkio@cox.net> wrote:
>   - Git.pm by Pasky with help from Pavel Roskin and others.
>
>     I'd like to merge this immediately after 1.4.2, unless there
>     still are concerns about its portability (in which case
>     please help fixing them up before this hits the "master"
>     branch).

Completely broken on ActiveState Perl and cygwin. Generated Makefile
contains pathnames with backslashes and the whole file has
CRLF line endings.

Re: What's in git.git

[carbonated beverage]

Any plans on a fix for:
http://marc.theaimsgroup.com/?l=git&m=115089393505286&w=2

I use gitk a lot, but having to nuke ~/.gitk every time I launch it is a bit
annoying. :-)

Commenting out the line mentioned in the reply lets me resize the window and
see the bottom panel properly -- but I do have to resize it every time so it
doesn't extend past the bottom of the screen.

FYI, if it's not easy to reproduct, I'm running it on Debian/stable systems,
i386 and x86_64, both with backports.org X servers, using tcl/tk 8.4

-- DN
Daniel Nobuto

Re: What's in git.git

[Junio C Hamano]

carbonated beverage <ramune@net-ronin.org> writes:

> Any plans on a fix for:
> http://marc.theaimsgroup.com/?l=git&m=115089393505286&w=2

Unfortunately, plan needs to be drawn by somebody who sees
breakage.

> Commenting out the line mentioned in the reply lets me resize the window and
> see the bottom panel properly -- but I do have to resize it every time so it
> doesn't extend past the bottom of the screen.
>
> FYI, if it's not easy to reproduct, I'm running it on Debian/stable systems,
> i386 and x86_64, both with backports.org X servers, using tcl/tk 8.4

I am running Debian/testing+unstable on i386 and x86_64 with
tcl8.4 (8.4.12-1.1) and tk8.4 (8.4.12-1), displaying on
xserver-xorg (1:7.0.22).  I cannot get gitk to misbehave the way
the quoted post describes.  Even after resizing it to so short
that the bottom search input and commitdiff area becomes
invisible, moving the middle separator around gives the lower
panes back, and both of the scrollbars on the lower panes seem
to be behaving during that exercise.

The "workaround" to disable ".ctop conf" feels actively wrong;
this makes the command forget the dimension from the last
session, which is not so different from removing ~/.gitk every
time.

Could this be some funny interaction between window manager and
gitk perhaps?  I think my machines run metacity and the
environment is minimally Gnome.

Re: What's in git.git

[Junio C Hamano]

"Alex Riesen" <raa.lkml@gmail.com> writes:

> On 8/2/06, Junio C Hamano <junkio@cox.net> wrote:
>>   - Git.pm by Pasky with help from Pavel Roskin and others.
>>
>>     I'd like to merge this immediately after 1.4.2, unless there
>>     still are concerns about its portability (in which case
>>     please help fixing them up before this hits the "master"
>>     branch).
>
> Completely broken on ActiveState Perl and cygwin. Generated Makefile
> contains pathnames with backslashes and the whole file has
> CRLF line endings.

Anything constructive other than "doctor it hurts when I use
activestate", so you can help improve things to be more
ActiveState friendly?

What's the standard workflow/procedure ActiveState users would
use to build and install .xs extensions?  Maybe they have their
own $(MAKE) equivalent that groks such a Makefile with
backslashed pathnames and CRLF endings?

Re: What's in git.git

[A Large Angry SCM]

Broken for me also:
	Suse 9.3
	Ubuntu Hoary
	Ubuntu Breezy

No Gnome(s) here.


Junio C Hamano wrote:
> carbonated beverage <ramune@net-ronin.org> writes:
> 
>> Any plans on a fix for:
>> http://marc.theaimsgroup.com/?l=git&m=115089393505286&w=2
> 
> Unfortunately, plan needs to be drawn by somebody who sees
> breakage.
> 
>> Commenting out the line mentioned in the reply lets me resize the window and
>> see the bottom panel properly -- but I do have to resize it every time so it
>> doesn't extend past the bottom of the screen.
>>
>> FYI, if it's not easy to reproduct, I'm running it on Debian/stable systems,
>> i386 and x86_64, both with backports.org X servers, using tcl/tk 8.4
> 
> I am running Debian/testing+unstable on i386 and x86_64 with
> tcl8.4 (8.4.12-1.1) and tk8.4 (8.4.12-1), displaying on
> xserver-xorg (1:7.0.22).  I cannot get gitk to misbehave the way
> the quoted post describes.  Even after resizing it to so short
> that the bottom search input and commitdiff area becomes
> invisible, moving the middle separator around gives the lower
> panes back, and both of the scrollbars on the lower panes seem
> to be behaving during that exercise.
> 
> The "workaround" to disable ".ctop conf" feels actively wrong;
> this makes the command forget the dimension from the last
> session, which is not so different from removing ~/.gitk every
> time.
> 
> Could this be some funny interaction between window manager and
> gitk perhaps?  I think my machines run metacity and the
> environment is minimally Gnome.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: What's in git.git

[carbonated beverage]

On Wed, Aug 02, 2006 at 09:52:10PM -0700, Junio C Hamano wrote:
> Unfortunately, plan needs to be drawn by somebody who sees
> breakage.

I'm willing to help out with anything needed, but I haven't touched TCL in a
very long time -- and never used Tk.

> Could this be some funny interaction between window manager and
> gitk perhaps?  I think my machines run metacity and the
> environment is minimally Gnome.

I'm using Enlightenment from the Debian repo:
barbeque/zarathustra:barbeque: eesh -ewait 'version'
Enlightenment Version : enlightenment-0.16.7.2
code is current to    : $Date: 2004/12/14 22:00:25 $

barbeque/zarathustra:barbeque: dpkg -l xserver-xorg|tail -1
ii  xserver-xorg   6.9.0.dfsg.1-3 the X.Org X server

I'll start experimenting with other window managers and see what I turn up.

-- DN
Daniel Nobuto

Re: What's in git.git

[carbonated beverage]

Looks like it's not window-manager specific.

rm'd ~/.gitk, then launched it twice -- it showed up on:

Enlightenment 0.16.7.2-1
flwm 1.00-7
wm2 4-8
fluxbox 0.9.11-1sarge0
metacity 2.8.8-1
vtwm 5.4.6b-1
ctwm 3.6-2
twm 6.9.0.dfsg.1-3
ion3 20050502-2

If anyone has ideas or requests for more info, let me know.

*starts to read up on Tk*

-- DN
Daniel

Re: What's in git.git

[carbonated beverage]

Wheee...

Found it.

Not sure what the "right" way to do this is... generated it with
"git format-patch FETCH_HEAD.." on the master branch, and dropped it
inline to the mail.

Um.... patch included because it's so trivial anyone could have fixed it,
but what's the "proper" way to submit patches?

-- DN
Daniel

>From 1483a6207ffe8bf216ea3258db7b453857c3e1d6 Mon Sep 17 00:00:00 2001
From: Daniel Nobuto <ramune@net-ronin.org>
Date: Thu, 3 Aug 2006 00:32:01 -0700
Subject: [PATCH] Save geometry(ctexth) in ~/.gitk

Not doing so causes subsequent launches of gitk to "lose" the bottom bits
of the window.

Signed-off-by: Daniel Nobuto <ramune@net-ronin.org>
---
 gitk |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/gitk b/gitk
index ba4644f..5ae28ef 100755
--- a/gitk
+++ b/gitk
@@ -770,6 +770,9 @@ proc savestuff {w} {
 	set wid [expr {([winfo width $ctext] - 8) \
 			   / [font measure $textfont "0"]}]
 	puts $f "set geometry(ctextw) $wid"
+	set geometry(ctexth) [expr {($texth - 8) /
+			   / [font metrics $textfont -linespace]}]
+	puts $f "set geometry(ctexth) $wid"
 	set wid [expr {([winfo width $cflist] - 11) \
 			   / [font measure [$cflist cget -font] "0"]}]
 	puts $f "set geometry(cflistw) $wid"
-- 
1.4.1.1

Re: What's in git.git

[carbonated beverage]

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

Of course, and the patch gets munched.  Re-trying as an attachment. :(

-- DN
Daniel

[-- Attachment #2: 0001-Save-geometry-ctexth-in-.gitk.txt --]
[-- Type: text/plain, Size: 940 bytes --]

>From 1483a6207ffe8bf216ea3258db7b453857c3e1d6 Mon Sep 17 00:00:00 2001
From: Daniel Nobuto <ramune@net-ronin.org>
Date: Thu, 3 Aug 2006 00:32:01 -0700
Subject: [PATCH] Save geometry(ctexth) in ~/.gitk

Not doing so causes subsequent launches of gitk to "lose" the bottom bits
of the window.

Signed-off-by: Daniel Nobuto <ramune@net-ronin.org>
---
 gitk |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/gitk b/gitk
index ba4644f..5ae28ef 100755
--- a/gitk
+++ b/gitk
@@ -770,6 +770,9 @@ proc savestuff {w} {
 	set wid [expr {([winfo width $ctext] - 8) \
 			   / [font measure $textfont "0"]}]
 	puts $f "set geometry(ctextw) $wid"
+	set geometry(ctexth) [expr {($texth - 8) /
+			   / [font metrics $textfont -linespace]}]
+	puts $f "set geometry(ctexth) $wid"
 	set wid [expr {([winfo width $cflist] - 11) \
 			   / [font measure [$cflist cget -font] "0"]}]
 	puts $f "set geometry(cflistw) $wid"
-- 
1.4.1.1

Re: What's in git.git

[Alex Riesen]

On 8/3/06, Junio C Hamano <junkio@cox.net> wrote:
> >>   - Git.pm by Pasky with help from Pavel Roskin and others.
> >>
> >>     I'd like to merge this immediately after 1.4.2, unless there
> >>     still are concerns about its portability (in which case
> >>     please help fixing them up before this hits the "master"
> >>     branch).
> >
> > Completely broken on ActiveState Perl and cygwin. Generated Makefile
> > contains pathnames with backslashes and the whole file has
> > CRLF line endings.
>
> Anything constructive other than "doctor it hurts when I use
> activestate", so you can help improve things to be more
> ActiveState friendly?

Nothing. If I had something, I'd post it.

> What's the standard workflow/procedure ActiveState users would
> use to build and install .xs extensions?  Maybe they have their
> own $(MAKE) equivalent that groks such a Makefile with
> backslashed pathnames and CRLF endings?

I don't know. It's a bit more than backslashes and CRLF. The pathnames
must be _completely_ converted from windows to cygwin. Cygwin even
provides an utility for that (cygpath). Besides, there still is that stupid
case-sensitivity problem.

Re: What's in git.git

[Junio C Hamano]

carbonated beverage <ramune@net-ronin.org> writes:

> Wheee...
>
> Found it.
>
> diff --git a/gitk b/gitk
> index ba4644f..5ae28ef 100755
> --- a/gitk
> +++ b/gitk
> @@ -770,6 +770,9 @@ proc savestuff {w} {
>  	set wid [expr {([winfo width $ctext] - 8) \
>  			   / [font measure $textfont "0"]}]
>  	puts $f "set geometry(ctextw) $wid"
> +	set geometry(ctexth) [expr {($texth - 8) /
> +			   / [font metrics $textfont -linespace]}]
> +	puts $f "set geometry(ctexth) $wid"

Are you sure about this?

	* $texth is not global, and set geometry(ctexth)
          expression has a syntax error (the slash at the end of
          the line should be backslash for continuation) -- I do
          not see how this could have worked.

	* you are setting geometry(ctexth) but trying to write
          out $wid (which is geometry(ctextw) for the next
          round).

	* but because of the first problem, I suspect the entire
          catch {} clause would have silently failed, perhaps
          leaving the old ~/.gitk around, or more likely not
          creating ~/.gitk at all, which essentially is
          "removing ~/.gitk every time you run it" ;-).

Did your ~/.gitk change after exiting your gitk session?  I
somehow doubt it.

The following _might_ have a better chance of success...

---
diff --git a/gitk b/gitk
index ba4644f..b06e022 100755
--- a/gitk
+++ b/gitk
@@ -761,17 +761,25 @@ proc savestuff {w} {
 	puts $f [list set cmitmode $cmitmode]
 	puts $f [list set wrapcomment $wrapcomment]
 	puts $f [list set showneartags $showneartags]
+
+	set g_height [winfo height .ctop]
+	set g_canvh [expr {[winfo height $canv]-2}]
+
 	puts $f "set geometry(width) [winfo width .ctop]"
-	puts $f "set geometry(height) [winfo height .ctop]"
+	puts $f "set geometry(height) $g_height"
 	puts $f "set geometry(canv1) [expr {[winfo width $canv]-2}]"
 	puts $f "set geometry(canv2) [expr {[winfo width $canv2]-2}]"
 	puts $f "set geometry(canv3) [expr {[winfo width $canv3]-2}]"
-	puts $f "set geometry(canvh) [expr {[winfo height $canv]-2}]"
+	puts $f "set geometry(canvh) $g_canvh"
 	set wid [expr {([winfo width $ctext] - 8) \
 			   / [font measure $textfont "0"]}]
 	puts $f "set geometry(ctextw) $wid"
 	set wid [expr {([winfo width $cflist] - 11) \
 			   / [font measure [$cflist cget -font] "0"]}]
+	set texth [expr {$g_height - $g_canvh - 56}]
+	set g_ctexth [expr {($texth - 8) \
+			   / [font metrics $textfont -linespace]}]
+	puts $f "set geometry(ctexth) $g_ctexth"
 	puts $f "set geometry(cflistw) $wid"
 	puts -nonewline $f "set permviews {"
 	for {set v 0} {$v < $nextviewnum} {incr v} {

Re: What's in git.git

[carbonated beverage]

On Thu, Aug 03, 2006 at 01:39:57AM -0700, Junio C Hamano wrote:
> Did your ~/.gitk change after exiting your gitk session?  I
> somehow doubt it.
> 
> The following _might_ have a better chance of success...

Whups -- you're right.  It wasn't creating ~/.gitk at all, so it was in
as you said -- just like rm'ing it every time.

I tried your patch, and I still get the same result, though it creates a
~/.gitk.  "set geometry(ctexth)" appears in the ~/.gitk file properly now,
though.

I'll keep digging, and sorry for the noise.

-- DN
Daniel

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

> The following _might_ have a better chance of success...

Doesn't clobber ~/.gitk, but doesn't correct error either (i.e. I still
cannot see bottommost part of gitk window in subsequent invocations).

* Aurox Linux 11.1 (Zeus), based on Fedora Core 4
* Linux 2.6.14-11.1.aur.2
* tcl-8.4.9-3
* xorg-x11-6.8.2-37.FC4.49.2
* windowmaker-0.91.0-1.1.fc3.rf
* git v1.4.2-rc2-geb10b37 + your patch

# grep geometry ~/.gitk 
set geometry(width) 890
set geometry(height) 868
set geometry(canv1) 405
set geometry(canv2) 270
set geometry(canv3) 174
set geometry(canvh) 354
set geometry(ctextw) 80
set geometry(ctexth) 34
set geometry(cflistw) 35

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Junio C Hamano]

"Alex Riesen" <raa.lkml@gmail.com> writes:

>> What's the standard workflow/procedure ActiveState users would
>> use to build and install .xs extensions?  Maybe they have their
>> own $(MAKE) equivalent that groks such a Makefile with
>> backslashed pathnames and CRLF endings?
>
> I don't know. It's a bit more than backslashes and CRLF. The pathnames
> must be _completely_ converted from windows to cygwin. Cygwin even
> provides an utility for that (cygpath). Besides, there still is that stupid
> case-sensitivity problem.

What I meant to say was that the real mistake might be for us to
try using the Cygwin toolchain (GNU make, gcc and GNU C library)
while working with ActiveState.

Now, I admit I know very little about ActiveState and know
nothing about Windows build environment, but I would not be
surprised if in ActiveState land there were a MakeMaker
equivalent that spits out Makefile equivalent that is suitable
for MS development environment, and the users are expected to
work in that environment, perhaps using MS C compiler toolchain,
to produce object files if they want to link with ActiveState
stuff.  If that were the case, maybe what is needed is to port
the build infrastructure to MS development environment, and
making Makefile generated from perl/Makefile.PL usable might not
be of much use.

Re: What's in git.git

[carbonated beverage]

Okay, dug around a bit more, and I admit, I'm not very familiar with Tk
(just started reading about it when poking at the gitk weirdness).

After applying your patch, rm'ing ~/.gitk, *and* doing:

--- gitk        2006-08-03 02:27:20.000000000 -0700
+++ /home/barbeque/bin/gitk     2006-08-03 02:24:52.000000000 -0700
@@ -429,7 +429,7 @@
     panedwindow .ctop -orient vertical
     if {[info exists geometry(width)]} {
        .ctop conf -width $geometry(width) -height $geometry(height)
-       set texth [expr {$geometry(height) - $geometry(canvh) - 56}]
+       set texth [expr {$geometry(height) - $geometry(canvh) - 136}]
        set geometry(ctexth) [expr {($texth - 8) /
                                    [font metrics $textfont -linespace]}]
     }

Then subsequent launches of gitk appear to be correct.  However, if the stale
~/.gitk is still around, the bug stays around.

Since my eyes are getting fuzzy, can someone that knows TCL/Tk eyeball that
and see if it's the actual cause, or just papering over a bug?

Thanks!

-- DN
Daniel

Re: What's in git.git

[Alex Riesen]

On 8/3/06, Junio C Hamano <junkio@cox.net> wrote:
> >> What's the standard workflow/procedure ActiveState users would
> >> use to build and install .xs extensions?  Maybe they have their
> >> own $(MAKE) equivalent that groks such a Makefile with
> >> backslashed pathnames and CRLF endings?
> >
> > I don't know. It's a bit more than backslashes and CRLF. The pathnames
> > must be _completely_ converted from windows to cygwin. Cygwin even
> > provides an utility for that (cygpath). Besides, there still is that stupid
> > case-sensitivity problem.
>
> What I meant to say was that the real mistake might be for us to
> try using the Cygwin toolchain (GNU make, gcc and GNU C library)
> while working with ActiveState.

Luckily, only ActiveState Perl users are hit. Which, I suppose,
is not all that much (it's really crappy environment to work in,
an only real stupid corporate users can keep doing that),
and they're used to pain.

> Now, I admit I know very little about ActiveState and know
> nothing about Windows build environment, but I would not be
> surprised if in ActiveState land there were a MakeMaker
> equivalent that spits out Makefile equivalent that is suitable
> for MS development environment, and the users are expected to
> work in that environment, perhaps using MS C compiler toolchain,

AFAICS, it is not suitable for anything: generated Makefile is not
parsable by nmake(what MS thinks is a make) and is more like a
broken gmake Makefile. Also -fno-strict-aliasing points at gcc.

> to produce object files if they want to link with ActiveState
> stuff.  If that were the case, maybe what is needed is to port
> the build infrastructure to MS development environment, and
> making Makefile generated from perl/Makefile.PL usable might not
> be of much use.

I'd suggest to add NO_PERL_XS option to the top-level Makefile.
Really core tools do not need Git.pm.

Re: What's in git.git

[Alex Riesen]

On 8/3/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> > Now, I admit I know very little about ActiveState and know
> > nothing about Windows build environment, but I would not be
> > surprised if in ActiveState land there were a MakeMaker
> > equivalent that spits out Makefile equivalent that is suitable
> > for MS development environment, and the users are expected to
> > work in that environment, perhaps using MS C compiler toolchain,
>
> AFAICS, it is not suitable for anything: generated Makefile is not
> parsable by nmake(what MS thinks is a make) and is more like a
> broken gmake Makefile. Also -fno-strict-aliasing points at gcc.

I think I better post what I have got from MakeMaker. Just keep
in mind: it's CRLF delimited.

# This Makefile is for the Git extension to perl.
#
# It was generated automatically by MakeMaker version
# 6.17 (Revision: 1.133) from the contents of
# Makefile.PL. Don't edit this file, edit Makefile.PL instead.
#
#       ANY CHANGES MADE HERE WILL BE LOST!
#
#   MakeMaker ARGV: (q[PREFIX=/d/scripts/git], q[DEFINE=
-DNO_D_TYPE_IN_DIRENT -DNO_D_INO_IN_DIRENT -DNO_SYMLINK_HEAD -DNO_IPV6
-DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR -DNO_STRLCPY -DNO_MMAP
-DGIT_VERSION='"1.4.2.rc2.gb80eb"'], q[LIBS= -lz  -liconv  -lcrypto])
#
#   MakeMaker Parameters:

#     INC => q[-I. -I..]
#     MYEXTLIB => q[../libgit.a]
#     NAME => q[Git]
#     PM => { private-Error.pm=>q[$(INST_LIBDIR)/Error.pm],
Git.pm=>q[$(INST_LIBDIR)/Git.pm] }
#     VERSION_FROM => q[Git.pm]

# --- MakeMaker post_initialize section:


# --- MakeMaker const_config section:

# These definitions are from config.sh (via c:/perl/lib/Config.pm)

# They may have been overridden via Makefile.PL or on the command line
AR = ar
CC = gcc
CCCDLFLAGS =
CCDLFLAGS =
DLEXT = dll
DLSRC = dl_win32.xs
LD = gcc
LDDLFLAGS = -mdll
LDFLAGS = -nologo -nodefaultlib -debug -opt:ref,icf
-libpath:"C:\Perl\lib\CORE"  -machine:x86
LIBC = msvcrt.lib
LIB_EXT = .lib
OBJ_EXT = .o
OSNAME = MSWin32
OSVERS = 5.0
RANLIB = rem
SITELIBEXP = C:\Perl\site\lib
SITEARCHEXP = C:\Perl\site\lib
SO = dll
EXE_EXT = .exe
FULL_AR =
VENDORARCHEXP = $(VENDORPREFIX)\lib\5.8.7\MSWin32-x86-multi-thread
VENDORLIBEXP = $(VENDORPREFIX)\lib


# --- MakeMaker constants section:
AR_STATIC_ARGS = cr
DIRFILESEP = ^\
NAME = Git
NAME_SYM = Git
VERSION = 0.01
VERSION_MACRO = VERSION
VERSION_SYM = 0_01
DEFINE_VERSION = -D$(VERSION_MACRO)=\"$(VERSION)\"
XS_VERSION = 0.01
XS_VERSION_MACRO = XS_VERSION
XS_DEFINE_VERSION = -D$(XS_VERSION_MACRO)=\"$(XS_VERSION)\"
INST_ARCHLIB = blib\arch
INST_SCRIPT = blib\script
INST_BIN = blib\bin
INST_LIB = blib\lib
INST_MAN1DIR = blib\man1
INST_MAN3DIR = blib\man3
INST_HTMLDIR = blib\html
MAN1EXT = 1
MAN3EXT = 3
INSTALLDIRS = site
DESTDIR =
PREFIX = /d/scripts/git
PERLPREFIX = $(PREFIX)
SITEPREFIX = $(PREFIX)
VENDORPREFIX = $(PREFIX)
INSTALLPRIVLIB = $(PERLPREFIX)\lib
DESTINSTALLPRIVLIB = $(DESTDIR)$(INSTALLPRIVLIB)
INSTALLSITELIB = $(SITEPREFIX)\lib
DESTINSTALLSITELIB = $(DESTDIR)$(INSTALLSITELIB)
INSTALLVENDORLIB = $(VENDORPREFIX)\lib
DESTINSTALLVENDORLIB = $(DESTDIR)$(INSTALLVENDORLIB)
INSTALLARCHLIB = $(PERLPREFIX)\lib
DESTINSTALLARCHLIB = $(DESTDIR)$(INSTALLARCHLIB)
INSTALLSITEARCH = $(SITEPREFIX)/lib
DESTINSTALLSITEARCH = $(DESTDIR)$(INSTALLSITEARCH)
INSTALLVENDORARCH = $(VENDORPREFIX)\lib\5.8.7\MSWin32-x86-multi-thread
DESTINSTALLVENDORARCH = $(DESTDIR)$(INSTALLVENDORARCH)
INSTALLBIN = $(PERLPREFIX)\bin
DESTINSTALLBIN = $(DESTDIR)$(INSTALLBIN)
INSTALLSITEBIN = $(SITEPREFIX)\bin
DESTINSTALLSITEBIN = $(DESTDIR)$(INSTALLSITEBIN)
INSTALLVENDORBIN = $(VENDORPREFIX)\bin
DESTINSTALLVENDORBIN = $(DESTDIR)$(INSTALLVENDORBIN)
INSTALLSCRIPT = $(PERLPREFIX)\bin
DESTINSTALLSCRIPT = $(DESTDIR)$(INSTALLSCRIPT)
INSTALLMAN1DIR = $(PERLPREFIX)\man\man1
DESTINSTALLMAN1DIR = $(DESTDIR)$(INSTALLMAN1DIR)
INSTALLSITEMAN1DIR = $(SITEPREFIX)\man\man1
DESTINSTALLSITEMAN1DIR = $(DESTDIR)$(INSTALLSITEMAN1DIR)
INSTALLVENDORMAN1DIR = $(VENDORPREFIX)\man\man1
DESTINSTALLVENDORMAN1DIR = $(DESTDIR)$(INSTALLVENDORMAN1DIR)
INSTALLMAN3DIR = $(PERLPREFIX)\man\man3
DESTINSTALLMAN3DIR = $(DESTDIR)$(INSTALLMAN3DIR)
INSTALLSITEMAN3DIR = $(SITEPREFIX)\man\man3
DESTINSTALLSITEMAN3DIR = $(DESTDIR)$(INSTALLSITEMAN3DIR)
INSTALLVENDORMAN3DIR = $(VENDORPREFIX)\man\man3
DESTINSTALLVENDORMAN3DIR = $(DESTDIR)$(INSTALLVENDORMAN3DIR)
INSTALLHTMLDIR = $(PERLPREFIX)\html
DESTINSTALLHTMLDIR = $(DESTDIR)$(INSTALLHTMLDIR)
INSTALLSITEHTMLDIR = $(SITEPREFIX)\html
DESTINSTALLSITEHTMLDIR = $(DESTDIR)$(INSTALLSITEHTMLDIR)
INSTALLVENDORHTMLDIR = $(VENDORPREFIX)C:\Perl\html
DESTINSTALLVENDORHTMLDIR = $(DESTDIR)$(INSTALLVENDORHTMLDIR)
PERL_LIB = C:\Perl\lib
PERL_ARCHLIB = C:\Perl\lib
LIBPERL_A = libperl.lib
MYEXTLIB = ../libgit.a
FIRST_MAKEFILE = Makefile
MAKEFILE_OLD = $(FIRST_MAKEFILE).old
MAKE_APERL_FILE = $(FIRST_MAKEFILE).aperl
PERLMAINCC = $(CC)
PERL_INC = C:\Perl\lib\CORE
PERL = C:\perl\bin\perl.exe
FULLPERL = C:\perl\bin\perl.exe
ABSPERL = $(PERL)
PERLRUN = $(PERL)
FULLPERLRUN = $(FULLPERL)
ABSPERLRUN = $(ABSPERL)
PERLRUNINST = $(PERLRUN) "-I$(INST_ARCHLIB)" "-I$(INST_LIB)"
FULLPERLRUNINST = $(FULLPERLRUN) "-I$(INST_ARCHLIB)" "-I$(INST_LIB)"
ABSPERLRUNINST = $(ABSPERLRUN) "-I$(INST_ARCHLIB)" "-I$(INST_LIB)"
PERL_CORE = 0
PERM_RW = 644
PERM_RWX = 755

MAKEMAKER   = c:/perl/lib/ExtUtils/MakeMaker.pm
MM_VERSION  = 6.17
MM_REVISION = 1.133

# FULLEXT = Pathname for extension directory (eg Foo/Bar/Oracle).
# BASEEXT = Basename part of FULLEXT. May be just equal FULLEXT. (eg Oracle)
# PARENT_NAME = NAME without BASEEXT and no trailing :: (eg Foo::Bar)
# DLBASE  = Basename part of dynamic library. May be just equal BASEEXT.
FULLEXT = Git
BASEEXT = Git
PARENT_NAME =
DLBASE = $(BASEEXT)
VERSION_FROM = Git.pm
INC = -I. -I..
DEFINE =  -DNO_D_TYPE_IN_DIRENT -DNO_D_INO_IN_DIRENT -DNO_SYMLINK_HEAD
-DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR -DNO_STRLCPY
-DNO_MMAP -DGIT_VERSION='"1.4.2.rc2.gb80eb"'
OBJECT = $(BASEEXT)$(OBJ_EXT)
LDFROM = $(OBJECT)
LINKTYPE = dynamic

# Handy lists of source code files:
XS_FILES = Git.xs
C_FILES  = Git.c
O_FILES  = Git.o
H_FILES  =
MAN1PODS =
MAN3PODS = Git.pm \
	private-Error.pm

# Where is the Config information that we are using/depend on
CONFIGDEP = $(PERL_ARCHLIB)$(DIRFILESEP)Config.pm
$(PERL_INC)$(DIRFILESEP)config.h

# Where to build things
INST_LIBDIR      = $(INST_LIB)
INST_ARCHLIBDIR  = $(INST_ARCHLIB)

INST_AUTODIR     = $(INST_LIB)\auto\$(FULLEXT)
INST_ARCHAUTODIR = $(INST_ARCHLIB)\auto\$(FULLEXT)

INST_STATIC      = $(INST_ARCHAUTODIR)\$(BASEEXT)$(LIB_EXT)
INST_DYNAMIC     = $(INST_ARCHAUTODIR)\$(DLBASE).$(DLEXT)
INST_BOOT        = $(INST_ARCHAUTODIR)\$(BASEEXT).bs

# Extra linker info
EXPORT_LIST        = $(BASEEXT).def
PERL_ARCHIVE       = $(PERL_INC)\perl58.lib
PERL_ARCHIVE_AFTER =


TO_INST_PM = Git.pm \
	private-Error.pm

PM_TO_BLIB = private-Error.pm \
	$(INST_LIBDIR)/Error.pm \
	Git.pm \
	$(INST_LIBDIR)/Git.pm


# --- MakeMaker platform_constants section:
MM_Win32_VERSION = 1.09


# --- MakeMaker tool_autosplit section:
# Usage: $(AUTOSPLITFILE) FileToSplit AutoDirToSplitInto
AUTOSPLITFILE = $(PERLRUN)  -e "use AutoSplit;  autosplit($$ARGV[0],
$$ARGV[1], 0, 1, 1)"



# --- MakeMaker tool_xsubpp section:

XSUBPPDIR = C:\perl\lib\ExtUtils
XSUBPP = $(XSUBPPDIR)/xsubpp
XSPROTOARG =
XSUBPPDEPS = C:\Perl\lib\ExtUtils\typemap $(XSUBPP)
XSUBPPARGS = -typemap C:\Perl\lib\ExtUtils\typemap
XSUBPP_EXTRA_ARGS =


# --- MakeMaker tools_other section:
CHMOD = $(PERLRUN) -MExtUtils::Command -e chmod
CP = $(PERLRUN) -MExtUtils::Command -e cp
MV = $(PERLRUN) -MExtUtils::Command -e mv
NOOP = rem
NOECHO = @
RM_F = $(PERLRUN) -MExtUtils::Command -e rm_f
RM_RF = $(PERLRUN) -MExtUtils::Command -e rm_rf
TEST_F = $(PERLRUN) -MExtUtils::Command -e test_f
TOUCH = $(PERLRUN) -MExtUtils::Command -e touch
UMASK_NULL = umask 0
DEV_NULL = > NUL
MKPATH = $(PERLRUN) "-MExtUtils::Command" -e mkpath
EQUALIZE_TIMESTAMP = $(PERLRUN) "-MExtUtils::Command" -e eqtime
ECHO = $(PERLRUN) -l -e "print qq{@ARGV}"
ECHO_N = $(PERLRUN)  -e "print qq{@ARGV}"
UNINST = 0
VERBINST = 0
MOD_INSTALL = $(PERLRUN) -MExtUtils::Install -e "install({@ARGV},
'$(VERBINST)', 0, '$(UNINST)');"
DOC_INSTALL = $(PERLRUN) "-MExtUtils::Command::MM" -e perllocal_install
UNINSTALL = $(PERLRUN) "-MExtUtils::Command::MM" -e uninstall
WARN_IF_OLD_PACKLIST = $(PERLRUN) "-MExtUtils::Command::MM" -e
warn_if_old_packlist


# --- MakeMaker makemakerdflt section:
makemakerdflt: all
	$(NOECHO) $(NOOP)


# --- MakeMaker dist section:
TAR = tar
TARFLAGS = cvf
ZIP = zip
ZIPFLAGS = -r
COMPRESS = gzip --best
SUFFIX = .gz
SHAR = shar
PREOP = $(NOECHO) $(NOOP)
POSTOP = $(NOECHO) $(NOOP)
TO_UNIX = $(NOECHO) $(NOOP)
CI = ci -u
RCS_LABEL = rcs -Nv$(VERSION_SYM): -q
DIST_CP = best
DIST_DEFAULT = tardist
DISTNAME = Git
DISTVNAME = Git-0.01


# --- MakeMaker macro section:


# --- MakeMaker depend section:


# --- MakeMaker cflags section:

CCFLAGS = -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT
-DNO_HASH_SEED -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT
-DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -DHASATTRIBUTE
-fno-strict-aliasing
OPTIMIZE = -O2
PERLTYPE =
MPOLLUTE =


# --- MakeMaker const_loadlibs section:

# Git might depend on some other libraries:
# See ExtUtils::Liblist for details
#
LDLOADLIBS = -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32
-lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lmsvcrt
LD_RUN_PATH =


# --- MakeMaker const_cccmd section:
CCCMD = $(CC) -c $(PASTHRU_INC) $(INC) \
	$(CCFLAGS) $(OPTIMIZE) \
	$(PERLTYPE) $(MPOLLUTE) $(DEFINE_VERSION) \
	$(XS_DEFINE_VERSION)

# --- MakeMaker post_constants section:


# --- MakeMaker pasthru section:
PASTHRU = -nologo

# --- MakeMaker special_targets section:
.SUFFIXES: .xs .c .C .cpp .i .s .cxx .cc $(OBJ_EXT)

.PHONY: all config static dynamic test linkext manifest



# --- MakeMaker c_o section:

.c.i:
	gcc -E -c $(PASTHRU_INC) $(INC) \
	$(CCFLAGS) $(OPTIMIZE) \
	$(PERLTYPE) $(MPOLLUTE) $(DEFINE_VERSION) \
	$(XS_DEFINE_VERSION) $(CCCDLFLAGS) "-I$(PERL_INC)" $(PASTHRU_DEFINE)
$(DEFINE) $*.c > $*.i

.c.s:
	$(CCCMD) -S $(CCCDLFLAGS) "-I$(PERL_INC)" $(PASTHRU_DEFINE) $(DEFINE) $*.c

.c$(OBJ_EXT):
	$(CCCMD) $(CCCDLFLAGS) "-I$(PERL_INC)" $(PASTHRU_DEFINE) $(DEFINE) $*.c

.cpp$(OBJ_EXT):
	$(CCCMD) $(CCCDLFLAGS) "-I$(PERL_INC)" $(PASTHRU_DEFINE) $(DEFINE) $*.cpp

.cxx$(OBJ_EXT):
	$(CCCMD) $(CCCDLFLAGS) "-I$(PERL_INC)" $(PASTHRU_DEFINE) $(DEFINE) $*.cxx

.cc$(OBJ_EXT):
	$(CCCMD) $(CCCDLFLAGS) "-I$(PERL_INC)" $(PASTHRU_DEFINE) $(DEFINE) $*.cc


# --- MakeMaker xs_c section:

.xs.c:
	$(PERLRUN) $(XSUBPP) $(XSPROTOARG) $(XSUBPPARGS) $(XSUBPP_EXTRA_ARGS)
$*.xs > $*.xsc && $(MV) $*.xsc $*.c


# --- MakeMaker xs_o section:


# --- MakeMaker top_targets section:
all :: pure_all htmlifypods
	$(NOECHO) $(NOOP)


pure_all :: config pm_to_blib subdirs linkext
	$(NOECHO) $(NOOP)

subdirs :: $(MYEXTLIB)
	$(NOECHO) $(NOOP)

config :: $(FIRST_MAKEFILE) $(INST_LIBDIR)$(DIRFILESEP).exists
	$(NOECHO) $(NOOP)

config :: $(INST_ARCHAUTODIR)$(DIRFILESEP).exists
	$(NOECHO) $(NOOP)

config :: $(INST_AUTODIR)$(DIRFILESEP).exists
	$(NOECHO) $(NOOP)

$(INST_AUTODIR)\.exists :: C:\Perl\lib\CORE\perl.h
	$(NOECHO) $(MKPATH) $(INST_AUTODIR)
	$(NOECHO) $(EQUALIZE_TIMESTAMP) C:\Perl\lib\CORE\perl.h $(INST_AUTODIR)\.exists

	-$(NOECHO) $(CHMOD) $(PERM_RWX) $(INST_AUTODIR)

$(INST_LIBDIR)\.exists :: C:\Perl\lib\CORE\perl.h
	$(NOECHO) $(MKPATH) $(INST_LIBDIR)
	$(NOECHO) $(EQUALIZE_TIMESTAMP) C:\Perl\lib\CORE\perl.h $(INST_LIBDIR)\.exists

	-$(NOECHO) $(CHMOD) $(PERM_RWX) $(INST_LIBDIR)

$(INST_ARCHAUTODIR)\.exists :: C:\Perl\lib\CORE\perl.h
	$(NOECHO) $(MKPATH) $(INST_ARCHAUTODIR)
	$(NOECHO) $(EQUALIZE_TIMESTAMP) C:\Perl\lib\CORE\perl.h
$(INST_ARCHAUTODIR)\.exists

	-$(NOECHO) $(CHMOD) $(PERM_RWX) $(INST_ARCHAUTODIR)

config :: $(INST_MAN3DIR)$(DIRFILESEP).exists
	$(NOECHO) $(NOOP)


$(INST_MAN3DIR)\.exists :: C:\Perl\lib\CORE\perl.h
	$(NOECHO) $(MKPATH) $(INST_MAN3DIR)
	$(NOECHO) $(EQUALIZE_TIMESTAMP) C:\Perl\lib\CORE\perl.h $(INST_MAN3DIR)\.exists

	-$(NOECHO) $(CHMOD) $(PERM_RWX) $(INST_MAN3DIR)

help:
	perldoc ExtUtils::MakeMaker


# --- MakeMaker linkext section:

linkext :: $(LINKTYPE)
	$(NOECHO) $(NOOP)


# --- MakeMaker dlsyms section:

Git.def: Makefile.PL
	$(PERLRUN) -MExtUtils::Mksymlists \
     -e "Mksymlists('NAME'=>\"Git\", 'DLBASE' => '$(BASEEXT)',
'DL_FUNCS' => {  }, 'FUNCLIST' => [], 'IMPORTS' => {  }, 'DL_VARS' =>
[]);"


# --- MakeMaker dynamic section:

dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
	$(NOECHO) $(NOOP)


# --- MakeMaker dynamic_bs section:
BOOTSTRAP = $(BASEEXT).bs

# As Mkbootstrap might not write a file (if none is required)
# we use touch to prevent make continually trying to remake it.
# The DynaLoader only reads a non-empty file.
$(BOOTSTRAP): $(FIRST_MAKEFILE) $(BOOTDEP)
$(INST_ARCHAUTODIR)$(DIRFILESEP).exists
	$(NOECHO) $(ECHO) "Running Mkbootstrap for $(NAME) ($(BSLOADLIBS))"
	$(NOECHO) $(PERLRUN) \
		"-MExtUtils::Mkbootstrap" \
		-e "Mkbootstrap('$(BASEEXT)','$(BSLOADLIBS)');"
	$(NOECHO) $(TOUCH) $(BOOTSTRAP)
	$(CHMOD) $(PERM_RW) $@

$(INST_BOOT): $(BOOTSTRAP) $(INST_ARCHAUTODIR)$(DIRFILESEP).exists
	$(NOECHO) $(RM_RF) $(INST_BOOT)
	-$(CP) $(BOOTSTRAP) $(INST_BOOT)
	$(CHMOD) $(PERM_RW) $@


# --- MakeMaker dynamic_lib section:

# This section creates the dynamically loadable $(INST_DYNAMIC)
# from $(OBJECT) and possibly $(MYEXTLIB).
OTHERLDFLAGS = -Wl,--image-base,0x23050000
INST_DYNAMIC_DEP =

$(INST_DYNAMIC): $(OBJECT) $(MYEXTLIB) $(BOOTSTRAP)
$(INST_ARCHAUTODIR)$(DIRFILESEP).exists $(EXPORT_LIST) $(PERL_ARCHIVE)
$(INST_DYNAMIC_DEP)
	dlltool --def $(EXPORT_LIST) --output-exp dll.exp
	$(LD) -o $@ -Wl,--base-file -Wl,dll.base $(LDDLFLAGS) $(LDFROM)
$(OTHERLDFLAGS) $(MYEXTLIB) $(PERL_ARCHIVE) $(LDLOADLIBS) dll.exp
	dlltool --def $(EXPORT_LIST) --base-file dll.base --output-exp dll.exp
	$(LD) -o $@ $(LDDLFLAGS) $(LDFROM) $(OTHERLDFLAGS) $(MYEXTLIB)
$(PERL_ARCHIVE) $(LDLOADLIBS) dll.exp
	$(CHMOD) $(PERM_RWX) $@


# --- MakeMaker static section:

## $(INST_PM) has been moved to the all: target.
## It remains here for awhile to allow for old usage: "make static"
static :: $(FIRST_MAKEFILE) $(INST_STATIC)
	$(NOECHO) $(NOOP)


# --- MakeMaker static_lib section:
$(INST_STATIC): $(OBJECT) $(MYEXTLIB) $(INST_ARCHAUTODIR)$(DIRFILESEP).exists
	$(RM_RF) $@
	$(CP) $(MYEXTLIB) $@
	$(AR) -ru $@ $(OBJECT)
	$(CHMOD) $(PERM_RWX) $@
	$(NOECHO) $(ECHO) "$(EXTRALIBS)" > $(INST_ARCHAUTODIR)\extralibs.ld



# --- MakeMaker manifypods section:

POD2MAN_EXE = $(PERLRUN) "-MExtUtils::Command::MM" -e pod2man "--"
POD2MAN = $(POD2MAN_EXE)


manifypods : pure_all  \
	private-Error.pm \
	Git.pm \
	private-Error.pm \
	Git.pm
	$(NOECHO) $(POD2MAN) --section=3 --perm_rw=$(PERM_RW)\
	  private-Error.pm $(INST_MAN3DIR)\private-Error.$(MAN3EXT) \
	  Git.pm $(INST_MAN3DIR)\Git.$(MAN3EXT)




# --- MakeMaker htmlifypods section:

POD2HTML_EXE = $(PERLRUN) "-MActivePerl::DocTools" -e
"Pod2HTML(installdirs => "$(INSTALLDIRS)")"
POD2HTML = $(POD2HTML_EXE)


htmlifypods :  \
	private-Error.pm \
	Git.pm
	$(NOECHO) $(POD2HTML)



# --- MakeMaker processPL section:


# --- MakeMaker installbin section:


# --- MakeMaker subdirs section:

# none

# --- MakeMaker clean_subdirs section:
clean_subdirs :
	$(NOECHO) $(NOOP)


# --- MakeMaker clean section:

# Delete temporary files but do not touch installed files. We don't delete
# the Makefile here so a later make realclean still has a makefile to use.

clean :: clean_subdirs
	-$(RM_RF) Git.c ./blib $(MAKE_APERL_FILE)
$(INST_ARCHAUTODIR)/extralibs.all $(INST_ARCHAUTODIR)/extralibs.ld
perlmain.c tmon.out mon.out so_locations pm_to_blib *$(OBJ_EXT)
*$(LIB_EXT) perl.exe perl perl$(EXE_EXT) $(BOOTSTRAP) $(BASEEXT).bso
$(BASEEXT).def lib$(BASEEXT).def $(BASEEXT).exp $(BASEEXT).x core
core.*perl.*.? *perl.core core.[0-9] core.[0-9][0-9]
core.[0-9][0-9][0-9] core.[0-9][0-9][0-9][0-9]
core.[0-9][0-9][0-9][0-9][0-9]
	-$(MV) $(FIRST_MAKEFILE) $(MAKEFILE_OLD) $(DEV_NULL)
clean ::
	-$(RM_F) dll.base dll.exp



# --- MakeMaker realclean_subdirs section:
realclean_subdirs :
	$(NOECHO) $(NOOP)


# --- MakeMaker realclean section:

# Delete temporary files (via clean) and also delete installed files
realclean purge ::  clean realclean_subdirs
	$(RM_RF) $(INST_AUTODIR) $(INST_ARCHAUTODIR)
	$(RM_RF) $(DISTVNAME)
	$(RM_F) $(INST_DYNAMIC) $(INST_BOOT)
	$(RM_F) $(INST_STATIC)
	$(RM_F)  $(INST_LIBDIR)/Git.pm $(INST_LIBDIR)/Error.pm
$(MAKEFILE_OLD) $(FIRST_MAKEFILE)


# --- MakeMaker metafile section:
metafile :
	$(NOECHO) $(ECHO) "#
http://module-build.sourceforge.net/META-spec.html" > META.yml
	$(NOECHO) $(ECHO) "#XXXXXXX This is a prototype!!!  It will change in
the future!!! XXXXX#" >> META.yml
	$(NOECHO) $(ECHO) "name:         Git" >> META.yml
	$(NOECHO) $(ECHO) "version:      0.01" >> META.yml
	$(NOECHO) $(ECHO) "version_from: Git.pm" >> META.yml
	$(NOECHO) $(ECHO) "installdirs:  site" >> META.yml
	$(NOECHO) $(ECHO) "requires:" >> META.yml
	$(NOECHO) $(ECHO) "" >> META.yml
	$(NOECHO) $(ECHO) "distribution_type: module" >> META.yml
	$(NOECHO) $(ECHO) "generated_by: ExtUtils::MakeMaker version 6.17" >> META.yml


# --- MakeMaker metafile_addtomanifest section:
metafile_addtomanifest:
	$(NOECHO) $(PERLRUN) -MExtUtils::Manifest=maniadd -e "eval {
maniadd({q{META.yml} => q{Module meta-data (added by MakeMaker)}}) } \
    or print \"Could not add META.yml to MANIFEST: $${'@'}\n\""


# --- MakeMaker dist_basics section:
distclean :: realclean distcheck
	$(NOECHO) $(NOOP)

distcheck :
	$(PERLRUN) "-MExtUtils::Manifest=fullcheck" -e fullcheck

skipcheck :
	$(PERLRUN) "-MExtUtils::Manifest=skipcheck" -e skipcheck

manifest :
	$(PERLRUN) "-MExtUtils::Manifest=mkmanifest" -e mkmanifest

veryclean : realclean
	$(RM_F) *~ *.orig */*~ */*.orig



# --- MakeMaker dist_core section:

dist : $(DIST_DEFAULT) $(FIRST_MAKEFILE)
	$(NOECHO) $(PERLRUN) -l -e "print 'Warning: Makefile possibly out of
date with $(VERSION_FROM)'\
    if -e '$(VERSION_FROM)' and -M '$(VERSION_FROM)' < -M '$(FIRST_MAKEFILE)';"

tardist : $(DISTVNAME).tar$(SUFFIX)
	$(NOECHO) $(NOOP)

uutardist : $(DISTVNAME).tar$(SUFFIX)
	uuencode $(DISTVNAME).tar$(SUFFIX) $(DISTVNAME).tar$(SUFFIX) >
$(DISTVNAME).tar$(SUFFIX)_uu

$(DISTVNAME).tar$(SUFFIX) : distdir
	$(PREOP)
	$(TO_UNIX)
	$(TAR) $(TARFLAGS) $(DISTVNAME).tar $(DISTVNAME)
	$(RM_RF) $(DISTVNAME)
	$(COMPRESS) $(DISTVNAME).tar
	$(POSTOP)

zipdist : $(DISTVNAME).zip
	$(NOECHO) $(NOOP)

$(DISTVNAME).zip : distdir
	$(PREOP)
	$(ZIP) $(ZIPFLAGS) $(DISTVNAME).zip $(DISTVNAME)
	$(RM_RF) $(DISTVNAME)
	$(POSTOP)

shdist : distdir
	$(PREOP)
	$(SHAR) $(DISTVNAME) > $(DISTVNAME).shar
	$(RM_RF) $(DISTVNAME)
	$(POSTOP)


# --- MakeMaker distdir section:
distdir : metafile metafile_addtomanifest
	$(RM_RF) $(DISTVNAME)
	$(PERLRUN) "-MExtUtils::Manifest=manicopy,maniread" \
		-e "manicopy(maniread(),'$(DISTVNAME)', '$(DIST_CP)');"



# --- MakeMaker dist_test section:

disttest : distdir
	cd $(DISTVNAME) && $(ABSPERLRUN) Makefile.PL
	cd $(DISTVNAME) && $(MAKE) $(PASTHRU)
	cd $(DISTVNAME) && $(MAKE) test $(PASTHRU)


# --- MakeMaker dist_ci section:

ci :
	$(PERLRUN) "-MExtUtils::Manifest=maniread" \
	  -e "@all = keys %{ maniread() };" \
	  -e "print(qq{Executing $(CI) @all\n}); system(qq{$(CI) @all});" \
	  -e "print(qq{Executing $(RCS_LABEL) ...\n}); system(qq{$(RCS_LABEL) @all});"


# --- MakeMaker install section:

install :: all pure_install doc_install doc_update

install_perl :: all pure_perl_install doc_perl_install

install_site :: all pure_site_install doc_site_install

install_vendor :: all pure_vendor_install doc_vendor_install

pure_install :: pure_$(INSTALLDIRS)_install

doc_install :: doc_$(INSTALLDIRS)_install

doc_update ::
	$(NOECHO) $(PERLRUN) "-MActivePerl::DocTools" -e ActivePerl::DocTools::WriteTOC

pure__install : pure_site_install
	$(NOECHO) $(ECHO) INSTALLDIRS not defined, defaulting to INSTALLDIRS=site

doc__install : doc_site_install
	$(NOECHO) $(ECHO) INSTALLDIRS not defined, defaulting to INSTALLDIRS=site

pure_perl_install ::
	$(NOECHO) $(MOD_INSTALL) \
		read $(PERL_ARCHLIB)\auto\$(FULLEXT)\.packlist \
		write $(DESTINSTALLARCHLIB)\auto\$(FULLEXT)\.packlist \
		$(INST_LIB) $(DESTINSTALLPRIVLIB) \
		$(INST_ARCHLIB) $(DESTINSTALLARCHLIB) \
		$(INST_BIN) $(DESTINSTALLBIN) \
		$(INST_SCRIPT) $(DESTINSTALLSCRIPT) \
		$(INST_MAN1DIR) $(DESTINSTALLMAN1DIR) \
		$(INST_MAN3DIR) $(DESTINSTALLMAN3DIR) \
		$(INST_HTMLDIR) $(DESTINSTALLHTMLDIR)
	$(NOECHO) $(WARN_IF_OLD_PACKLIST) \
		$(SITEARCHEXP)\auto\$(FULLEXT)


pure_site_install ::
	$(NOECHO) $(MOD_INSTALL) \
		read $(SITEARCHEXP)\auto\$(FULLEXT)\.packlist \
		write $(DESTINSTALLSITEARCH)\auto\$(FULLEXT)\.packlist \
		$(INST_LIB) $(DESTINSTALLSITELIB) \
		$(INST_ARCHLIB) $(DESTINSTALLSITEARCH) \
		$(INST_BIN) $(DESTINSTALLSITEBIN) \
		$(INST_SCRIPT) $(DESTINSTALLSCRIPT) \
		$(INST_MAN1DIR) $(DESTINSTALLSITEMAN1DIR) \
		$(INST_MAN3DIR) $(DESTINSTALLSITEMAN3DIR) \
		$(INST_HTMLDIR) $(DESTINSTALLSITEHTMLDIR)
	$(NOECHO) $(WARN_IF_OLD_PACKLIST) \
		$(PERL_ARCHLIB)\auto\$(FULLEXT)

pure_vendor_install ::
	$(NOECHO) $(MOD_INSTALL) \
		read $(VENDORARCHEXP)\auto\$(FULLEXT)\.packlist \
		write $(DESTINSTALLVENDORARCH)\auto\$(FULLEXT)\.packlist \
		$(INST_LIB) $(DESTINSTALLVENDORLIB) \
		$(INST_ARCHLIB) $(DESTINSTALLVENDORARCH) \
		$(INST_BIN) $(DESTINSTALLVENDORBIN) \
		$(INST_SCRIPT) $(DESTINSTALLSCRIPT) \
		$(INST_MAN1DIR) $(DESTINSTALLVENDORMAN1DIR) \
		$(INST_MAN3DIR) $(DESTINSTALLVENDORMAN3DIR) \
		$(INST_HTMLDIR) $(DESTINSTALLVENDORHTMLDIR)

doc_perl_install ::
	$(NOECHO) $(ECHO) Appending installation info to
$(DESTINSTALLARCHLIB)/perllocal.pod
	-$(NOECHO) $(MKPATH) $(DESTINSTALLARCHLIB)
	-$(NOECHO) $(DOC_INSTALL) \
		"Module" "$(NAME)" \
		"installed into" "$(INSTALLPRIVLIB)" \
		LINKTYPE "$(LINKTYPE)" \
		VERSION "$(VERSION)" \
		EXE_FILES "$(EXE_FILES)" \
		>> $(DESTINSTALLARCHLIB)\perllocal.pod

doc_site_install ::
	$(NOECHO) $(ECHO) Appending installation info to
$(DESTINSTALLARCHLIB)/perllocal.pod
	-$(NOECHO) $(MKPATH) $(DESTINSTALLARCHLIB)
	-$(NOECHO) $(DOC_INSTALL) \
		"Module" "$(NAME)" \
		"installed into" "$(INSTALLSITELIB)" \
		LINKTYPE "$(LINKTYPE)" \
		VERSION "$(VERSION)" \
		EXE_FILES "$(EXE_FILES)" \
		>> $(DESTINSTALLARCHLIB)\perllocal.pod

doc_vendor_install ::
	$(NOECHO) $(ECHO) Appending installation info to
$(DESTINSTALLARCHLIB)/perllocal.pod
	-$(NOECHO) $(MKPATH) $(DESTINSTALLARCHLIB)
	-$(NOECHO) $(DOC_INSTALL) \
		"Module" "$(NAME)" \
		"installed into" "$(INSTALLVENDORLIB)" \
		LINKTYPE "$(LINKTYPE)" \
		VERSION "$(VERSION)" \
		EXE_FILES "$(EXE_FILES)" \
		>> $(DESTINSTALLARCHLIB)\perllocal.pod


uninstall :: uninstall_from_$(INSTALLDIRS)dirs doc_update

uninstall_from_perldirs ::
	$(NOECHO) $(UNINSTALL) $(PERL_ARCHLIB)\auto\$(FULLEXT)\.packlist

uninstall_from_sitedirs ::
	$(NOECHO) $(UNINSTALL) $(SITEARCHEXP)\auto\$(FULLEXT)\.packlist

uninstall_from_vendordirs ::
	$(NOECHO) $(UNINSTALL) $(VENDORARCHEXP)\auto\$(FULLEXT)\.packlist


# --- MakeMaker force section:
# Phony target to force checking subdirectories.
FORCE:
	$(NOECHO) $(NOOP)


# --- MakeMaker perldepend section:

PERL_HDRS = \
	$(PERL_INC)/EXTERN.h		\
	$(PERL_INC)/INTERN.h		\
	$(PERL_INC)/XSUB.h		\
	$(PERL_INC)/av.h		\
	$(PERL_INC)/cc_runtime.h	\
	$(PERL_INC)/config.h		\
	$(PERL_INC)/cop.h		\
	$(PERL_INC)/cv.h		\
	$(PERL_INC)/dosish.h		\
	$(PERL_INC)/embed.h		\
	$(PERL_INC)/embedvar.h		\
	$(PERL_INC)/fakethr.h		\
	$(PERL_INC)/form.h		\
	$(PERL_INC)/gv.h		\
	$(PERL_INC)/handy.h		\
	$(PERL_INC)/hv.h		\
	$(PERL_INC)/intrpvar.h		\
	$(PERL_INC)/iperlsys.h		\
	$(PERL_INC)/keywords.h		\
	$(PERL_INC)/mg.h		\
	$(PERL_INC)/nostdio.h		\
	$(PERL_INC)/op.h		\
	$(PERL_INC)/opcode.h		\
	$(PERL_INC)/patchlevel.h	\
	$(PERL_INC)/perl.h		\
	$(PERL_INC)/perlio.h		\
	$(PERL_INC)/perlsdio.h		\
	$(PERL_INC)/perlsfio.h		\
	$(PERL_INC)/perlvars.h		\
	$(PERL_INC)/perly.h		\
	$(PERL_INC)/pp.h		\
	$(PERL_INC)/pp_proto.h		\
	$(PERL_INC)/proto.h		\
	$(PERL_INC)/regcomp.h		\
	$(PERL_INC)/regexp.h		\
	$(PERL_INC)/regnodes.h		\
	$(PERL_INC)/scope.h		\
	$(PERL_INC)/sv.h		\
	$(PERL_INC)/thrdvar.h		\
	$(PERL_INC)/thread.h		\
	$(PERL_INC)/unixish.h		\
	$(PERL_INC)/util.h

$(OBJECT) : $(PERL_HDRS)

Git.c : $(XSUBPPDEPS)


# --- MakeMaker makefile section:

$(OBJECT) : $(FIRST_MAKEFILE)

# We take a very conservative approach here, but it's worth it.
# We move Makefile to Makefile.old here to avoid gnu make looping.
$(FIRST_MAKEFILE) : Makefile.PL $(CONFIGDEP)
	$(NOECHO) $(ECHO) "Makefile out-of-date with respect to $?"
	$(NOECHO) $(ECHO) "Cleaning current config before rebuilding Makefile..."
	$(NOECHO) $(RM_F) $(MAKEFILE_OLD)
	$(NOECHO) $(MV)   $(FIRST_MAKEFILE) $(MAKEFILE_OLD)
	-$(MAKE) -f $(MAKEFILE_OLD) clean $(DEV_NULL) || $(NOOP)
	$(PERLRUN) Makefile.PL "PREFIX=/d/scripts/git" "DEFINE=
-DNO_D_TYPE_IN_DIRENT -DNO_D_INO_IN_DIRENT -DNO_SYMLINK_HEAD -DNO_IPV6
-DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR -DNO_STRLCPY -DNO_MMAP
-DGIT_VERSION='"1.4.2.rc2.gb80eb"'" "LIBS= -lz  -liconv  -lcrypto"
	$(NOECHO) $(ECHO) "==> Your Makefile has been rebuilt. <=="
	$(NOECHO) $(ECHO) "==> Please rerun the make command.  <=="
	false



# --- MakeMaker staticmake section:

# --- MakeMaker makeaperl section ---
MAP_TARGET    = perl
FULLPERL      = C:\perl\bin\perl.exe

$(MAP_TARGET) :: static $(MAKE_APERL_FILE)
	$(MAKE) -f $(MAKE_APERL_FILE) $@

$(MAKE_APERL_FILE) : $(FIRST_MAKEFILE)
	$(NOECHO) $(ECHO) Writing \"$(MAKE_APERL_FILE)\" for this $(MAP_TARGET)
	$(NOECHO) $(PERLRUNINST) \
		Makefile.PL DIR= \
		MAKEFILE=$(MAKE_APERL_FILE) LINKTYPE=static \
		MAKEAPERL=1 NORECURS=1 CCCDLFLAGS= \
		PREFIX=/d/scripts/git \
		DEFINE=' -DNO_D_TYPE_IN_DIRENT -DNO_D_INO_IN_DIRENT
-DNO_SYMLINK_HEAD -DNO_IPV6 -DSHA1_HEADER='<openssl/sha.h>'
-DNO_STRCASESTR -DNO_STRLCPY -DNO_MMAP
-DGIT_VERSION='"1.4.2.rc2.gb80eb"'' \
		LIBS=' -lz  -liconv  -lcrypto'


# --- MakeMaker test section:

TEST_VERBOSE=0
TEST_TYPE=test_$(LINKTYPE)
TEST_FILE = test.pl
TEST_FILES =
TESTDB_SW = -d

testdb :: testdb_$(LINKTYPE)

test :: $(TEST_TYPE)
	$(NOECHO) $(ECHO) 'No tests defined for $(NAME) extension.'

test_dynamic :: pure_all

testdb_dynamic :: pure_all
	$(FULLPERLRUN) $(TESTDB_SW) "-I$(INST_LIB)" "-I$(INST_ARCHLIB)" $(TEST_FILE)

test_ : test_dynamic

test_static :: pure_all $(MAP_TARGET)

testdb_static :: pure_all $(MAP_TARGET)
	./$(MAP_TARGET) $(TESTDB_SW) "-I$(INST_LIB)" "-I$(INST_ARCHLIB)" $(TEST_FILE)



# --- MakeMaker ppd section:
# Creates a PPD (Perl Package Description) for a binary distribution.
ppd:
	$(NOECHO) $(ECHO) "<SOFTPKG NAME=\"$(DISTNAME)\"
VERSION=\"0,01,0,0\">" > $(DISTNAME).ppd
	$(NOECHO) $(ECHO) "    <TITLE>$(DISTNAME)</TITLE>" >> $(DISTNAME).ppd
	$(NOECHO) $(ECHO) "    <ABSTRACT></ABSTRACT>" >> $(DISTNAME).ppd
	$(NOECHO) $(ECHO) "    <AUTHOR></AUTHOR>" >> $(DISTNAME).ppd
	$(NOECHO) $(ECHO) "    <IMPLEMENTATION>" >> $(DISTNAME).ppd
	$(NOECHO) $(ECHO) "        <OS NAME=\"$(OSNAME)\" />" >> $(DISTNAME).ppd
	$(NOECHO) $(ECHO) "        <ARCHITECTURE
NAME=\"MSWin32-x86-multi-thread-5.8\" />" >> $(DISTNAME).ppd
	$(NOECHO) $(ECHO) "        <CODEBASE HREF=\"\" />" >> $(DISTNAME).ppd
	$(NOECHO) $(ECHO) "    </IMPLEMENTATION>" >> $(DISTNAME).ppd
	$(NOECHO) $(ECHO) "</SOFTPKG>" >> $(DISTNAME).ppd


# --- MakeMaker pm_to_blib section:

pm_to_blib: $(TO_INST_PM)
	$(NOECHO) $(PERLRUN) -MExtUtils::Install -e "pm_to_blib({@ARGV},
'$(INST_LIB)\auto', '$(PM_FILTER)')"\
	  private-Error.pm $(INST_LIBDIR)/Error.pm \
	  Git.pm $(INST_LIBDIR)/Git.pm
	$(NOECHO) $(TOUCH) $@

# --- MakeMaker selfdocument section:


# --- MakeMaker postamble section:
instlibdir:
	@echo '$(INSTALLSITEARCH)'

check:
	perl -MDevel::PPPort -le 'Devel::PPPort::WriteFile(".ppport.h")' && \
	perl .ppport.h --compat-version=5.6.0 Git.xs && \
	rm .ppport.h



# End.

What's in git.git

[Junio C Hamano]

* The 'master' branch has these since the last announcement.
  Since it was tagged as 1.4.2-rc3, it has acquired a couple of
  further fixes.  Hopefully there won't be anything but fixes on
  this branch until the real 1.4.2 happens.

  - Documentation, usage string fixes and general clean-ups
    everywhere by Jeff King, Ramsay Allan Jones, Uwe Zeisberger,
    and Matthias Lederhofer.

  - A few more commands are made built-ins by Matthias
    Kestenholz.

  - A minor memory leak in git-tar-tree was plugged by Rene
    Scharfe.

  - Ramsay Allan Jones has introduced "NO_C99_FORMAT" Makefile
    variable to help running things with a C library that does
    not support %zu and %td format.  This would be a good target
    for autoconf work by Jakub (hint hint).

  - To make it easy to tell which side of the connection the
    errors happened while fetching/pulling, messages from the
    remote side are prefixed with "remote: ".

  - "git diff blob1 blob2" were showing the patch in reverse,
    and did not identify blob names of both sides.  Fixed.

  - "git commit -o path" from subdirectories were broken when
    git-read-tree became a built-in.  Fixed.

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

  - A big gitweb clean-up series by Jakub Narebski, with help
    from Jeff King, Matthias Lederhofer and Martin Waitz to make
    run-time and build-time configuration easier.

  - Jakub Narebski made config.mak.autogen to tell where Perl
    and Python are to the build system.

  - Not-universally-liked Git.pm by Pasky with help from Dennis
    Stosberg, Johannes Schindelin, Pavel Roskin and others.
    One drawback is this pretty much makes Perl scripts that use
    Git.pm unusable with ActiveState right now.

  - A new merge strategy, merge-recur, which is a rewrite of
    merge-recursive in C, by Johannes and Alex.

  - More commands are made built-in by Matthias Kestenholz, and
    I cleaned up the build procedure for built-ins a bit.

  - New style loose objects, which use the same header format as
    in-pack objects, can be copied straight into packs when not
    deltified.  Note that new-style loose objects are not
    enabled by default yet.

  - Matthias Lederhofer introduced $GIT_PAGER environment
    variable that can specify a different pager from $PAGER.

  - I suspect Cygwin needs NO_C99_FORMAT.  Confirmation is
    appreciated.

  - Ramsay Allan Jones has one header fix to add _GNU_SOURCE,
    which helps things to compile in his environment; this needs
    to be checked to make sure it does not break others.

  - Timo Hirvonen made the parameter parsing of diff family
    saner some time ago.  Two minor changes are waiting to
    graduate to "master" after 1.4.2:

    * --name-only, --name-status, --check and -s are mutually exclusive

    * Remove awkward compatibility warts "-s".  Now -s means "do
      not output diff" everywhere, including git-diff-files.

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

  - Johannes Schindelin has a new diff option --color-words to
    use color to squash word differences into single line
    output.

  - An update to upload-pack to prevent it from going all the
    way back when the downloader has more roots than it.  Needs
    testing and comments.

  - A new merge strategy, merge-rename, which is still a
    work-in-progress to handle renames in read-tree 3-way
    merge.

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

>   - Not-universally-liked Git.pm by Pasky with help from Dennis
>     Stosberg, Johannes Schindelin, Pavel Roskin and others.
>     One drawback is this pretty much makes Perl scripts that use
>     Git.pm unusable with ActiveState right now.

It would be nice if when compiling with NO_GIT_XS (or equivalent) defined,
Git.pm used pure Perl implementation. It would be even better if we could
avoid unnecessary code repetition.

I think it would solve (read: paper on the problem) ActiveState problem...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Fri, 4 Aug 2006, Junio C Hamano wrote:

>   - I suspect Cygwin needs NO_C99_FORMAT.  Confirmation is
>     appreciated.

I can confirm that a just update cygwin setup needs it.

Ciao,
Dscho

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

>   - Ramsay Allan Jones has introduced "NO_C99_FORMAT" Makefile
>     variable to help running things with a C library that does
>     not support %zu and %td format.  This would be a good target
>     for autoconf work by Jakub (hint hint).

See [PATCH 2/4] in this thread (introductory message somehow got lost).
Testing on system which doesn't have C99 format specifiers would be
appreciated.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>
>>   - Ramsay Allan Jones has introduced "NO_C99_FORMAT" Makefile
>>     variable to help running things with a C library that does
>>     not support %zu and %td format.  This would be a good target
>>     for autoconf work by Jakub (hint hint).
>
> See [PATCH 2/4] in this thread (introductory message somehow got lost).
> Testing on system which doesn't have C99 format specifiers would be
> appreciated.

Running generated configure script on Cygwin just updated
reports NO_C99_FORMAT is needed.  This is consistent with what
Johannes confirmed.

Thanks, both.

Re: What's in git.git

[Junio C Hamano]

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

> Running generated configure script on Cygwin just updated
> reports NO_C99_FORMAT is needed.  This is consistent with what
> Johannes confirmed.

BTW, my copy of config.mak.autogen generated on Cygwin says:

	NO_D_INO_IN_DIRENT
        NO_D_TYPE_IN_DIRENT
        NO_C99_FORMAT
        NO_STRCASESTR
	NO_OPENSSL		???

The defaults in our Makefile are:

        NO_D_INO_IN_DIRENT
	NO_D_TYPE_IN_DIRENT
        NO_STRCASESTR
        NO_STRLCPY		???
        NEEDS_LIBICONV		???
        NO_C99_FORMAT
        NO_IPV6			???

(1) configure misdetects NO_OPENSSL.  The relevant parts are:

        checking for SHA1_Init in -lssl... no
        checking for SHA1_INIT in -lcrypto... no

    but I've been building git on Cygwin without NO_OPENSSL (eh,
    that's double negation -- what I mean is I've been building
    git with -lssl just fine).  I think the function to check in
    -lcrypto should be SHA1_Init, not SHA1_INIT (trivial patch
    attached at the end).

(2) NO_STRLCPY is detected to be available by configure.  I
    think we should update the default in Makefile.

(3) NEEDS_LIBICONV is found to be unnecessary by configure, but
    the link fails like this without it:

        builtin-mailinfo.o: In function `convert_to_utf8':
        /git/builtin-mailinfo.c:539: undefined reference to `_libiconv_open'
        /git/builtin-mailinfo.c:560: undefined reference to `_libiconv'
        /git/builtin-mailinfo.c:561: undefined reference to `_libiconv_close'
        collect2: ld returned 1 exit status

(4) NO_IPV6 is not detected yet -- you should be able to detect
    this by checking for "struct addrinfo".  The compilation
    fails like this on Cygwin:

        connect.c: In function `git_tcp_connect_sock':
        connect.c:361: error: storage size of 'hints' isn't known

(Z) When configure detects some NO_XXX is unneeded, currently
    there is no way for generated config.mak.autogen to override
    the default set in Makefile.  For example, NO_STRLCPY is set
    by Makefile, and the included config.mak.autogen does not
    say anything about it even though it knows strlcpy is
    usable.  It might be better to explicitly undef unneeded
    NO_XXX in config.mak.autogen?

-- >8 --
autoconf: typofix to detect SHA1_Init in -lcrypto

---
diff --git a/configure.ac b/configure.ac
index 9ce00e9..c6d76af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -155,7 +155,7 @@ #
 # Define NO_OPENSSL environment variable if you do not have OpenSSL.
 # Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
 AC_CHECK_LIB([ssl], [SHA1_Init],[],
-[AC_CHECK_LIB([crypto], [SHA1_INIT],
+[AC_CHECK_LIB([crypto], [SHA1_Init],
  [GIT_CONF_APPEND_LINE(NEEDS_SSL_WITH_CRYPTO=YesPlease)],
  [GIT_CONF_APPEND_LINE(NO_OPENSSL=YesPlease)])])
 #

Re: What's in git.git

[Junio C Hamano]

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

> (1) configure misdetects NO_OPENSSL.  The relevant parts are:
>
>         checking for SHA1_Init in -lssl... no
>         checking for SHA1_INIT in -lcrypto... no
>
>     but I've been building git on Cygwin without NO_OPENSSL (eh,
>     that's double negation -- what I mean is I've been building
>     git with -lssl just fine).  I think the function to check in
>     -lcrypto should be SHA1_Init, not SHA1_INIT (trivial patch
>     attached at the end).

I just noticed that this is not enough.  It does fix the
NO_OPENSSL problem, but I think the logic and test for ssl and
crypto in the original are the other way around.

NEEDS_SSL_WITH_CRYPTO means you cannot just say "-lcrypto" to
use SHA1 stuff, but need to say "-lcrypto -lssl", so the test
should say "if we can get away with -lcrypto, we are happy,
otherwise if we need -lssl, then say NEEDS_SSL_WITH_CRYPTO,
otherwise we cannot use OpenSSL so say NO_OPENSSL", or something
like that.

-- >8 --

diff --git a/configure.ac b/configure.ac
index 9ce00e9..fea18b6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -154,8 +154,8 @@ AC_MSG_NOTICE([CHECKS for libraries])
 #
 # Define NO_OPENSSL environment variable if you do not have OpenSSL.
 # Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
-AC_CHECK_LIB([ssl], [SHA1_Init],[],
-[AC_CHECK_LIB([crypto], [SHA1_INIT],
+AC_CHECK_LIB([crypto], [SHA1_Init],[],
+[AC_CHECK_LIB([ssl], [SHA1_Init],
  [GIT_CONF_APPEND_LINE(NEEDS_SSL_WITH_CRYPTO=YesPlease)],
  [GIT_CONF_APPEND_LINE(NO_OPENSSL=YesPlease)])])
 #

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

> (3) NEEDS_LIBICONV is found to be unnecessary by configure, but
>     the link fails like this without it:
> 
>         builtin-mailinfo.o: In function `convert_to_utf8':
>         /git/builtin-mailinfo.c:539: undefined reference to `_libiconv_open'
>         /git/builtin-mailinfo.c:560: undefined reference to `_libiconv'
>         /git/builtin-mailinfo.c:561: undefined reference to `_libiconv_close'
>         collect2: ld returned 1 exit status

Does the following patch help?

+++
autoconf: Set NEEDS_LIBICONV unconditionally if there is no iconv in libc

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
 configure.ac |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5926f3c..61c9fa3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -172,8 +172,7 @@ AC_CHECK_LIB([expat], [XML_ParserCreate]
 #
 # Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
 AC_CHECK_LIB([c], [iconv],[],
-[AC_CHECK_LIB([iconv],[iconv],
- [GIT_CONF_APPEND_LINE(NEEDS_LIBICONV=YesPlease)],[])])
+[GIT_CONF_APPEND_LINE(NEEDS_LIBICONV=YesPlease)])
 #
 # Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
 # Patrick Mauritz).
-- 
1.4.1.1

What's in git.git

[Junio C Hamano]

* The 'maint' branch now is at 1.4.2 plus a few fixes to be
  released as part of 1.4.2.1

   Luben Tuikov:
      Fix regex pattern in commit-msg
      sample commit-msg hook: no silent exit on duplicate Signed-off-by lines


* The 'master' branch has these since the last announcement.
  Most are what have been cooking in "next" for quite a while.

   Eric Wong:
      git-svn: correctly kill keyword expansion without munging EOLs
      git-svn: bugfix: allow SVN:: lib users to track the root of the repository
      git-svn: split the path from the url correctly with limited perms

   Jakub Narebski:
      gitweb: whitespace cleanup
      gitweb: Use list for of open for running git commands, thorougly.
      gitweb: simplify git_get_hash_by_path
      gitweb: More explicit error messages for open "-|"
      gitweb: Cleanup - chomp $line in consistent style
      gitweb: Cleanup - chomp @lines in consistent style
      gitweb: Add git_page_nav for later use
      gitweb: Navbar refactoring - use git_page_nav to generate navigation bar
      gitweb: Replace form-feed character by ^L
      gitweb: Show project descriptions with utf-8 characters in project list correctly
      gitweb: Add "\n" after <br/> in git_page_nav
      gitweb: Pager refactoring - use git_get_paging_nav for pagination
      gitweb: Remove $project from git_get_paging_nav arguments
      gitweb: Headers refactoring - use git_header_div for header divs
      gitweb: Remove characters entities entirely when shortening string
      gitweb: Ref refactoring - use git_get_referencing for marking tagged/head commits
      gitweb: Refactor generation of shortlog, tags and heads body
      gitweb: do not quote path for list version of open "-|"
      gitweb: Remove characters entities entirely when shortening string -- correction
      gitweb: Reordering code and dividing it into categories
      gitweb: Refactoring git_project_list
      autoconf: Add support for setting SHELL_PATH and PERL_PATH
      autoconf: Move site configuration section earlier in configure.ac
      autoconf: Add support for setting PYTHON_PATH or NO_PYTHON
      autoconf: Check for ll hh j z t size specifiers introduced by C99
      autoconf: Typo cleanup, reordering etc.
      Copy description of new build configuration variables to configure.ac
      autoconf: Set NEEDS_LIBICONV unconditionally if there is no iconv in libc
      gitweb: Separate input validation and dispatch, add comment about opml action
      gitweb: die_error first (optional) parameter is HTTP status
      gitweb: Use undef for die_error to use default first (status) parameter value
      gitweb: Don't undefine query parameter related variables before die_error
      gitweb: Cleanup and uniquify error messages
      gitweb: No periods for error messages
      gitweb: No error messages with unescaped/unprotected user input
      gitweb: PATH_INFO=/ means no project
      gitweb: Inline $rss_link
      gitweb: Refactor untabifying - converting tabs to spaces
      gitweb: fix commitdiff for root commits
      gitweb: Skip nonmatching lines in difftree output, consistently
      autoconf: Unset NO_STH and NEED_STH when it is detected not needed
      gitweb: Remove unused variables in git_shortlog_body and git_heads
      autoconf: Add configure target to main Makefile
      autoconf: Error out on --without-shell and --without-perl
      autoconf: Improvements in NO_PYTHON/PYTHON_PATH handling
      autoconf: Move variables which we always set to config.mak.in
      autoconf: It is --without-python, not --no-python
      autoconf: Add support for setting CURLDIR, OPENSSLDIR, EXPATDIR
      gitweb: Whitespace cleanup - tabs are for indent, spaces are for align

   Jeff King:
      gitweb: optionally read config from GITWEB_CONFIG

   Johannes Schindelin:
      read-trees: refactor the unpack_trees() part
      read-tree: move merge functions to the library
      http-push: avoid fork() by calling merge_bases() directly
      Add the --color-words option to the diff options family

   Junio C Hamano:
      upload-pack: use object pointer not copy of sha1 to keep track of has/needs.
      upload-pack: lift MAX_NEEDS and MAX_HAS limitation
      sha1_file.c: expose map_sha1_file() interface.
      pack-objects: reuse deflated data from new-style loose objects.
      unpack-objects: read configuration data upon startup.
      gitweb: There can be more than two levels of subdirectories
      gitweb: an obvious cut and paste error.
      gitweb: fix use of uninitialized value.
      gitweb: when showing history of a tree, show tree link not blob
      gitweb: avoid undefined value warning in print_page_path
      gitweb/README: do not bug Kay with gitweb questions anymore
      Makefile: gitweb/gitweb.cgi is now generated.
      gitweb: do not use @@FOO@@ for replaced tokens
      Make git-checkout-index a builtin
      builtins: Makefile clean-up
      git.c: Rename NEEDS_PREFIX to RUN_SETUP
      autoconf: fix NEEDS_SSL_WITH_CRYPTO
      autoconf: NO_IPV6
      Racy git: avoid having to be always too careful
      read-cache: tweak racy-git delay logic
      autoconf: clean temporary file mak.append
      git-apply: applying a patch to make a symlink shorter.
      combine-diff: use color
      Fix git-diff A...B
      builtin-apply: remove unused increment
      git-sh-setup: do not use repo-config to test the git directory
      git-grep: show pathnames relative to the current directory
      git-am: give better diagnostics when the patch does not apply during --3way
      Better error message when we are unable to lock the index file
      t/t4013: fix futzing with the version string.

   Luben Tuikov:
      gitweb: git_tree displays blame based on repository config
      gitweb: bugfix: git_commit and git_commitdiff parents
      gitweb: blame table row no highlight fix

   Martin Waitz:
      gitweb: fill in gitweb configuration by Makefile
      gitweb: use out-of-line GIT logo.

   Matthias Kestenholz:
      Make git-name-rev a builtin
      Make git-pack-objects a builtin
      Make git-unpack-objects a builtin
      Make git-symbolic-ref a builtin
      Add gitweb.cgi to .gitignore

   Matthias Lederhofer:
      upload-pack: fix timeout in create_pack_file
      pager: environment variable GIT_PAGER to override PAGER
      gitweb: use a hash to lookup the sub for an action
      gitweb: require $ENV{'GITWEB_CONFIG'}
      gitweb: check if HTTP_ACCEPT is really set
      gitweb: fix commitdiff_plain for root commits
      gitweb: fix $project usage

   Paul Mackerras:
      gitk: Allow the user to set some colors
      gitk: Show the currently checked-out head in bold font

   Ramsay Jones:
      Fix header breakage with _XOPEN_SOURCE.

   Rene Scharfe:
      Add has_extension()
      git-verify-pack: show usage when no pack was specified
      git-verify-pack: more careful path handling
      git-verify-pack: insist on .idx extension
      git-verify-pack: get rid of while loop
      git-verify-pack: free pack after use and a cleanup
      git-verify-pack: buffer overrun paranoia
      git-verify-pack: no need to count errors
      git-verify-pack: make builtin
      drop length argument of has_extension

   Rutger Nijlunsing:
      http-push: Make WebDAV work with (broken?) default apache2 WebDAV module
      Add Documentation/howto/setup-git-server-over-http.txt

   Timo Hirvonen:
      --name-only, --name-status, --check and -s are mutually exclusive
      Remove awkward compatibility warts


* The 'next' branch, in addition, has these.  Essentially, they
  are "Git.pm/Git.xs" series and "merge-recur" series.

   Dennis Stosberg:
      "test" in Solaris' /bin/sh does not support -e
      Makefile fix for Solaris
      Add possibility to pass CFLAGS and LDFLAGS specific to the perl subdir

   Johannes Schindelin:
      Git.xs: older perl do not know const char *
      Status update on merge-recursive in C
      Cumulative update of merge-recursive in C
      merge-recur: Convert variable names to lower_case
      merge-recur: Get rid of debug code
      merge-recur: Remove dead code
      merge-recur: Fix compiler warning with -pedantic
      merge-recur: Cleanup last mixedCase variables...
      merge-recur: Explain why sha_eq() and struct stage_data cannot go
      merge-recur: fix thinko in unique_path()
      merge-recur: use the unpack_trees() interface instead of exec()ing read-tree
      merge-recur: virtual commits shall never be parsed
      merge-recursive: fix rename handling
      merge-recur: do not call git-write-tree
      merge-recur: do not setenv("GIT_INDEX_FILE")
      merge-recur: if there is no common ancestor, fake empty one
      merge-recur: try to merge older merge bases first
      merge-recur: do not die unnecessarily
      discard_cache(): discard index, even if no file was mmap()ed

   Junio C Hamano:
      Perl interface: add build-time configuration to allow building with -fPIC
      Perl interface: make testsuite work again.
      perl: fix make clean
      Git.pm: tentative fix to test the freshly built Git.pm
      Perly Git: arrange include path settings properly.
      Makefile: Set USE_PIC on x86-64
      Perly git: work around buggy make implementations.
      Git.pm: clean generated files.
      Perly Git: make sure we do test the freshly built one.
      INSTALL: a tip for running after building but without installing.
      Work around sed and make interactions on the backslash at the end of line.
      recur vs recursive: help testing without touching too many stuff.
      Makefile: git-merge-recur depends on xdiff libraries.
      .gitignore: git-merge-recur is a built file.
      upload-pack: minor clean-up in multi-ack logic
      upload-pack: stop the other side when they have more roots than we do.

   Pavel Roskin:
      Fix probing for already installed Error.pm
      Delete manuals if compiling without docs
      Make perl interface a separate package

   Petr Baudis:
      Introduce Git.pm (v4)
      Git.pm: Implement Git::exec_path()
      Git.pm: Call external commands using execv_git_cmd()
      Git.pm: Implement Git::version()
      Add Error.pm to the distribution
      Git.pm: Better error handling
      Git.pm: Handle failed commands' output
      Git.pm: Enhance the command_pipe() mechanism
      Git.pm: Implement options for the command interface
      Git.pm: Add support for subdirectories inside of working copies
      Convert git-mv to use Git.pm
      Git.pm: assorted build related fixes.
      Git.pm: Try to support ActiveState output pipe
      Git.pm: Swap hash_object() parameters
      Git.pm: Fix Git->repository("/somewhere/totally/elsewhere")
      Git.pm: Support for perl/ being built by a different compiler
      Git.pm: Remove PerlIO usage from Git.xs
      Git.pm: Avoid ppport.h
      Git.pm: Don't #define around die
      Use $GITPERLLIB instead of $RUNNING_GIT_TESTS and centralize @INC munging
      Git.pm: Add config() method
      Convert git-send-email to use Git.pm
      Git.pm: Introduce ident() and ident_person() methods
      Make it possible to set up libgit directly (instead of from the environment)
      Git.pm: Introduce fast get_object() method
      Convert git-annotate to use Git.pm
      Eliminate Scalar::Util usage from private-Error.pm


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

   Junio C Hamano:
      git-status WIP

Re: What's in git.git

[Alex Riesen]

On 8/14/06, Junio C Hamano <junkio@cox.net> wrote:
>       sha1_file.c: expose map_sha1_file() interface.

Could we have corresponding unmap_sha1_file too?
So that I can implement more effective mmap/munmap
for windows (or any other mmap challenged platform,
like QNX).

What's in git.git

[Junio C Hamano]

* The 'maint' branch has these fixes since the last announcement.
  I am planning to cut a 1.4.2.1 with them soon.

   Dennis Stosberg:
      Solaris does not support C99 format strings before version 10

   Johannes Schindelin:
      git-mv: succeed even if source is a prefix of destination
      git-mv: add more path normalization

   Junio C Hamano:
      finish_connect(): thinkofix


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

  - Many many clean-ups by David Rientjes.

  - Portability fixes by Dennis Stosberg for Solaris.

  - Franck Bui-Huu's "format-patch --signoff" updates.

  - Gitweb clean-up continues, headed by Jakub Narebski with
    help from Martin Waitz and Yasushi Shoji.

  - There was a code to sleep before writing out the index, in
    order to avoid paying runtime costs in the racy-git
    avoidance code later.  After some experimenting and a bit of
    thinking, removed this sleep.  While at it, documented what
    the racy-git problem is and how the avoidance works.

  - Ville Skyttä updated Emacs VC support.

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

  - Git.pm/Git.xs series as before (no change)

  - git-merge-recur as before (no change)

  - upload-pack tweaks for the case where downloader has more
    root than the server (no change -- need testing)

  - git-apply --reverse --binary (new)

    Earlier "git apply --reverse" rejected binary patch because
    our binary patch format was irreversible.  So I made it
    reversible, and wrote some tests.  This affects both diff
    and apply.

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

  - git-status WIP

    I am hoping I can drop this; the implementation Peff
    outlined sounded far simpler and cleaner.

  - git-apply --reject (WIP)

    I started working on an option to let 'git apply' apply a
    patch whose some hunks do and some hunks do not apply, while
    leaving rejects in a separate file (or files).  Haven't
    started testing this yet, though.

What's in git.git

[Junio C Hamano]

This is CC'ed to the kernel list as well because the "master"
update is rather large.

On the "maint" front, I've been wanting to cut 1.4.2.1 for some
time, but various time constraints prevented me doing so so far.
I have a vague suspicion that 1.4.3 might happen before that.

Also I have been sort-of waiting for the x86-32 machine at
kernel.org to become available again so that I can do an RPM for
end users, which unfortunately hasn't happened yet.

* The 'maint' branch has these fixes since the last announcement.

   Johannes Schindelin:
      git-mv: special case destination "."
      git-mv: fix off-by-one error
      builtin-mv: readability patch

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

  - Johannes's reimplementation of merge-recursive in C is in
    'master' for early adopter testing.  Currently it is called
    'merge-recur', so you either (1) invoke it explicitly with
    the -s option to 'git pull' and/or 'git merge', or (2) have
    an environment variable GIT_USE_RECUR_FOR_RECURSIVE set to
    non-empty string, in which case places that call
    'git-merge-recursive' would use 'git-merge-recur' instead.

    This has been tested in 'next' for some time, and Johannes
    ran tests to reproduce all merges in post 2.6.12-rc2 kernel
    history to validate it produces the same result as the
    current merge-recursive.  The only difference is that it is
    about 6x-10x faster and you do not have to have Python
    installed.

    I intend to retire the current merge-recursive.py and
    replace it with merge-recur before 1.4.3 happens.

  - Various calls to memcmp/memcpy/memset with length '20' to
    compare, copy and clear object names have been abstracted
    out to hashcmp/hashcpy/hashclr wrappers, spearheaded by
    David Rientjes.  This would make it easier to migrate the
    code to hashes of other lengths if it is ever needed.

    Obviously migrating the existing data is another story.

  - Updates to git-svn by Eric Wong.

  - git-apply can be given --reject to produce *.rej files,
    instead of failing the whole patch atomically.  It also can
    be given --verbose to report what it is doing.

  - Rene Scharfe helped git-tar-tree find its soulmate
    git-zip-tree.

  - Tilman Sauerbeck taught git-daemon to setuid/setgid before
    serving the clients.

  - Various small fixes and clean-ups by Haavard Skinnemoen, Jakub
    Narebski, Jonas Fonseca, Pierre Habouzit, Rene Scharfe,
    Shawn Pearce, and Tilman Sauerbeck.

  - Various documentation clean-ups by Jonas Fonseca, and Rene
    Scharfe.

  - The internal is readied to be able to say "32 hours ago" in
    "git log" and friends by Linus; we do not have an UI to
    enable it yet.


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

  - Various gitweb updates by Jakub Narebski with help from
    Aneesh Kumar, Luben Tuikov, and Martin Waitz.  The most
    attractive thing these updates have is that we finally got
    rid of having to use temporary files to show diffs.

    I'd like to push this out to "master" soonish.  You can get
    a taste of how it works at the site Jakub maintains

	http://front.fuw.edu.pl/cgi-bin/jnareb/gitweb.cgi

  - Git.pm by Pasky with help from Dennis Stosberg, Eric Wong,
    Johannes, and Pavel Roskin.  During the next round I'd like
    to push this out to "master" to see who screams ;-).

  - upload-pack has a bit of updates still held back.

  - git-daemon is taught to optionally serve git-tar-tree
    output.


* In the 'pu' branch, I have my WIP of a library to walk the
  index, the working tree, and zero or more tree objects in
  parallel.  Its test program does something that vaguely looks
  like diff-index with and without --cached in parallel, but it
  is not polished enough for public testing/consumption yet.

What's in git.git

[Junio C Hamano]

It's been two weeks since the last "What's in" update, so here
is the current status.

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

 - Andy Whitcroft spotted a long-standing bug that prevented 
   send-pack to deal correctly with a ref whose name is longer
   than 45 bytes, where we did not have to have any such limit.

 - Jakub Narebski keeps working on gitweb, with help from Aneesh
   Kumar, Dennis Stosberg, Luben Tuikov, and Martin Waitz.
   There are a lot of clean-ups, including these notables:

   - mechanism to selectively enable or disable features by site
     administrators and repository owners.
   - snapshot and blame are now elective features using the above.
   - gitweb no longer uses temporary files to generate diffs.

 - Jakub also updated a few autoconf stuff.

 - Christian Couder's GIT_TRACE updates.

 - Franck Bui-Huu's clean-up to the code for "format-patch -s".

 - git-daemon acquired a mechanism to selectively enable or
   disable features by site administrators and repository
   owners.

 - pack-objects validates the data it copies from existing pack
   or new-style loose objects.

 - Other small clean-ups, fixes and updates from Johannes Schindelin,
   Jonas Fonseca, Linus Torvalds, Martin Langhoff, Matthias Kestenholz,
   Sergey Vlasov and Shawn Pearce.

 - gitk updates from Paul Mackerras.


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

 - Andy Whitcroft taught send-pack to use git-rev-list --stdin
   so that we do not have to be limited by the number of refs
   exec() command-line can hold.

 - Pasky's Git.pm is on hold; it was discussed and agreed that
   Git.xs layer was a bit premature and is hurting the adoption
   of the entire series.

 - Franck Bui-Huu and Rene Scharfe with a bit help from me added
   git-archive command to unify git-tar-tree/git-zip-tree and
   make them accessible over network.

 - Jeff King rewrote run_status() shell function in git-commit
   and git-status in C.

 - Per requests from the list, "git apply" automatically applies
   binary patches without having to be given --binary flag.

 - Likewise, "git diff --binary" does not give full index line for
   non-binary part of the patch anymore.

 - Pack-objects learned to run rev-list logic internally when
   given --revs parameter; the refs arguments you would normally
   give the upstream rev-list can be fed from its standard
   input, instead of usual list of objects.

 - Pack-objects also knows how to pretend objects that are in
   named packs are unpacked.  This would make easy to update
   repack to incrementally pack loose objects and recent
   "active" pack(s).

 - I have a few patches to upload-pack that would help
   upload-pack when downloader has more roots than the uploader
   has, but this is frozen until I hear real-world feedback.

 - unpack-objects learned a trick not to stop when fed a corrupt
   pack; instead it can make the best effort to recover from
   such an error that was detected.


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

 - I have a wip to implement index, working tree and zero or
   more trees in parallel but I haven't looked at it for some
   time.

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

>  - Andy Whitcroft taught send-pack to use git-rev-list --stdin
>    so that we do not have to be limited by the number of refs
>    exec() command-line can hold.
[...]
>  - Pack-objects learned to run rev-list logic internally when
>    given --revs parameter; the refs arguments you would normally
>    give the upstream rev-list can be fed from its standard
>    input, instead of usual list of objects.
BTW. could you please document the above?

Perhaps those two options, --stdin to feed arguments from standard input,
and -revs to run rev-list logic internally should be used whenever possible
in all the git commands? This would allow to avoid forks and/or command
line length limit.
 
In 'next' currently the following commands have --stdin implemented:
 * git-update-index: --stdin to feed list of paths, one per line
 * git-diff-tree: --stdin to loop over <tree-ish>, or pairs of
   <tree-ish>[*1*]
 * git-hash-object: --stdin is equivalent of '-' special file
 * git-http-fetch and git-local-fetch have some strange --stdin
 * git-name-rev with --stdin functions as filter
 * git-rev-list: --stdin to feed list of <commits>; it is not clear from 
   the manpage if one can use ^<commit>, and commit related options
   and shortcuts like --not, <commit>..<commit>, <commit>...<commit>
And the following have --revs implemented
 * git-pack-objects: --revs to provide arguments to rev-list from stdin,
   instead of list of objects. UNDOCUMENTED.

It would be nice if the following commands had --stdin or had it's --stdin
usage extended:
 * git-diff-tree: --stdin to allow to provide path limits, separated 
   by ' -- ' from <tree-ish> or pair of <tree-ish> (does git-diff-tree allow
   for diff3-like behavior? then perhaps also three <tree-ish>)
 * git-ls-tree: --stdin to loop over <tree-ish>, one tree per line.
 * git-cat-object: --stdin to loop over objects, plus -z to change separator
   between records to NULL (or have it turned on by default).
For all "loop" --stdin, the output should begin with the line which was
arguments, like git-diff-tree outputs first <tree-ish> used for diff.

I think it is quite often to use git-rev-list ...| git-diff-tree ...
pipeline, so it might be worth to add --revs option to git-diff-tree.
Or it might not.

P.S. does git-merge take -F <file> option?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Perhaps those two options, --stdin to feed arguments from standard input,
> and -revs to run rev-list logic internally should be used whenever possible
> in all the git commands? This would allow to avoid forks and/or command
> line length limit.

Some make more sense than others, from usability point of view.
It all depends on how much sense it makes to be able to run them
on sequence of commits.

>  * git-rev-list: --stdin to feed list of <commits>; it is not clear from 
>    the manpage if one can use ^<commit>, and commit related options
>    and shortcuts like --not, <commit>..<commit>, <commit>...<commit>
>  * git-pack-objects: --revs to provide arguments to rev-list from stdin,
>    instead of list of objects. UNDOCUMENTED.

Time spent whining about it is better spent finding it out
yourself (UTSL) and writing it I suspect.  You'll learn how
things actually work while doing so ;-).

> It would be nice if the following commands had --stdin or had it's --stdin
> usage extended:
>  * git-diff-tree: --stdin to allow to provide path limits, separated 
>    by ' -- ' from <tree-ish> or pair of <tree-ish>

Something like this could be used to follow renames and do more
interesting stuff.  The caller would create a pair of pipes,
throw first tree-pair at it, receive and examine the output, and
decide what pathspec to use for the next one and continue.  If
you do not limit yourself to pathspec but e.g. allow -S to be
also specified per invocation, then you can make it to follow
line movements, not just renames.  So in the bigger picture, I
like what something like this can offer to the Porcelain writers.

It is a separate story if it is worth building that _into_
diff-tree itself.  A sane way to see if it is is to start by
writing a rough equivalent that is:

	#!/bin/sh
	while read stuff;
        do
		# Note: this really needs to do shell quote
        	git-diff-tree $stuff
		echo I am done with one record.
        done

Then, write such a driver program to drive it and see if
per-line invocation of diff-tree is really the bottleneck.  For
any useful and interesting application of this pattern, I
suspect the process that drives this diff-tree loop will have
enough computation in it, and the only thing you are saving is
the start-up cost of diff-tree (i.e. fork+exec).  I am not sure
how much of the bottleneck it would be in the while thing.

>  * git-ls-tree: --stdin to loop over <tree-ish>, one tree per line.

Likewise.  Also you would need to decide the record delimiter.

>  * git-cat-object: --stdin to loop over objects, plus -z to change separator
>    between records to NULL (or have it turned on by default).

I would suggest TYPE SP BYTE-COUNT LF followed by payload
instead.  You cannot otherwise handle binary files with NUL
(lesson of the day: NULL is a pointer, the character's name is
NUL) in it.  If you do not mind redundancy to help the consumer
of this output, TYPE SP SHA-1 SP BYTE-COUNT LF followed by
payload might even be a better choice.

> For all "loop" --stdin, the output should begin with the line which was
> arguments, like git-diff-tree outputs first <tree-ish> used for diff.

That's something you cannot decide on a whim without knowing how
they are used and what convention is the most useful.  I suspect
that single record delimiter without frill might turn out to be
more useful.  Parrotting the arguments means you would need to
make sure the output format can easily parsable -- the issues
include that you need deal with embedded newlines in them.  To
quote them in the output routine is easy but the consumer now
needs to know they need to be dequoted.

> I think it is quite often to use git-rev-list ...| git-diff-tree ...
> pipeline, so it might be worth to add --revs option to git-diff-tree.

Are you talking about "git rev-list | git diff-tree --stdin"???

> P.S. does git-merge take -F <file> option?

No; it is not a Porcelain so ease of typing is not its goal.
You can say longhand: git-merge "`cat $file`" ...
Merge messages are supposed to be mostly automated and short,
so command line length limit is not much of an issue here.

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

>>  * git-rev-list: --stdin to feed list of <commits>; it is not clear from 
>>    the manpage if one can use ^<commit>, and commit related options
>>    and shortcuts like --not, <commit>..<commit>, <commit>...<commit>
>>  * git-pack-objects: --revs to provide arguments to rev-list from stdin,
>>    instead of list of objects. UNDOCUMENTED.
> 
> Time spent whining about it is better spent finding it out
> yourself (UTSL) and writing it I suspect.  You'll learn how
> things actually work while doing so ;-).

I still think it is better, easier and faster for someone who makes a new
feature to document it too.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Petr Baudis]

Dear diary, on Mon, Sep 11, 2006 at 11:06:03PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Junio C Hamano wrote:
> 
> >>  * git-rev-list: --stdin to feed list of <commits>; it is not clear from 
> >>    the manpage if one can use ^<commit>, and commit related options
> >>    and shortcuts like --not, <commit>..<commit>, <commit>...<commit>
> >>  * git-pack-objects: --revs to provide arguments to rev-list from stdin,
> >>    instead of list of objects. UNDOCUMENTED.
> > 
> > Time spent whining about it is better spent finding it out
> > yourself (UTSL) and writing it I suspect.  You'll learn how
> > things actually work while doing so ;-).
> 
> I still think it is better, easier and faster for someone who makes a new
> feature to document it too.

Especially since we _DON'T_ have good track record in other people
quickly documenting newly introduced undocumented features.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam

Re: What's in git.git

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Dear diary, on Mon, Sep 11, 2006 at 11:06:03PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>
>> I still think it is better, easier and faster for someone who makes a new
>> feature to document it too.
>
> Especially since we _DON'T_ have good track record in other people
> quickly documenting newly introduced undocumented features.

Well,...

I miss the days the lead of this project had _me_ as a
contributor ;-).

What's in git.git

[Junio C Hamano]

* The 'maint' branch has this since the last announcement (v1.4.2.1).

   - Liu Yubao fixed duplicate xmalloc in builtin-add.

   - "git-am --skip" incorrectly insisted that its standard
     input to be connected to a tty.  Fixed.


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

  - http-fetch from a repository that uses alternates to borrow
    from neighbouring repositories were quite broken for some
    time now.  This has been fixed (this fix is also in
    v1.4.2.1).

  - Andy Whitcroft taught send-pack to use git-rev-list --stdin
    so that we can deal with repositories with massive number
    of refs more efficiently.

  - A handful clean-ups, fixes and documentation updates by
    Christian Couder, Dmitry V. Levin, Jonas Fonseca and Linus.

  - Franck Bui-Huu and Rene Scharfe added 'git-archive' command,
    that will eventually supersede 'git-tar-tree' and
    'git-zip-tree'.

    I think zip-tree can be deprecated without hurting too many
    users, judging from its short existence, but I suspect that
    deprecating tar-tree needs to be done very carefully.
    Perhaps we should drop "tar-tree --remote" and "upload-tar",
    but keep tar-tree but make it internally a synonym for
    "archive --format=tar".  We should also update our toplevel
    Makefile to use git-archive.

  - Jakub Narebski continues improving gitweb with help from 
    Martin Waitz, and Matthias Lederhofer.

    We really need some test suites for gitweb.

  - Jeff King rewrote run_status() shell function used in
    git-commit and git-status in C, and made it colorful while
    he was at it.  Johannes Schindelin taught it --untracked.

  - unpack-objects with "-r" now makes the best effort to
    recover objects from a corrupt packfile.

  - apply does not need --binary anymore to take a binary patch.

  - diff --binary does not produce full 40-byte index lines
    unless necessary.

  - pack-objects learned --revs option, which lets it not to
    rely on rev-list.  Instead of taking the list of objects to
    pack from the standard input, it can read the list of rev
    parameters and run rev-list logic internally.

  - rev-list learned --unpacked=<existing pack> option.

  - Linus taught git-grep "-h" option to suppress filename
    output.

  - "git-am --skip" incorrectly insisted that its standard
    input to be connected to a tty.  Fixed.

  - "git-apply" learned to handle --unified=0 patches more
    gracefully by allowing some sanity checks that cannot be
    done with such patches to be disabled.

  - Sasha Khapyorsky noticed that http-fetch commit walker can
    almost deal with ftp:// transport already, and added
    minimum updates to support it.


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

  - Git.pm is on hold, waiting for stripping out Git.xs part before
    going forward.

  - Linus introduced packed refs and taught the core about
    them.  Christian Couder taught git-branch about them and
    Jeff King taught wt-status about it.

    There are still some things that are broken which need to
    be addressed before this series is pushed out to "master".
    I offhand know of these two but there probably are others:

    - "git branch -d" does not work.
    - "git ls-remote rsync://" does not work.

  - An experimental git-for-each-ref command to help language
    bindings to get information on many refs at once.  Hopefully
    Jakub can teach gitweb to use it to speed things up.


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

  - Jon Loeliger's git-daemon virtual hosting patch; this will be
    dropped and replaced with his updated version.

  - "git log --author=foo", "git log --grep=pattern" support.

  - I haven't started cleaning up the para-walk changes yet; they
    are still in the form of a messy 10-series patchset.  When I
    find time I'd like to rewrite diff-index with it and see how
    well it performs.

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

>   - An experimental git-for-each-ref command to help language
>     bindings to get information on many refs at once.  Hopefully
>     Jakub can teach gitweb to use it to speed things up.

I use 'origin' (or 'next') version of gitweb, while using _released_
version of git (git-core-1.4.2.1-1.i386.rpm). So at least for now 
I wouldn't be able to _test_ the git-for-each-ref.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

>     We really need some test suites for gitweb.

Could we use the git.git repository itself for testing gitweb?
At least checking if there are any errors or warnings?

The problem with test suite is that you really need _two_ tests;
first if there are any errors or warnings, then if page looks like
it should. The first can be done by simply running gitweb with
at least the following enviromental variables set:
  export GATEWAY_INTERFACE="CGI/1.1"
  export HTTP_ACCEPT="*/*"
  export REQUEST_METHOD="GET"
  export QUERY_STRING=""$1""
The second should be done by looking at gitweb output.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>
>>   - An experimental git-for-each-ref command to help language
>>     bindings to get information on many refs at once.  Hopefully
>>     Jakub can teach gitweb to use it to speed things up.
>
> I use 'origin' (or 'next') version of gitweb, while using _released_
> version of git (git-core-1.4.2.1-1.i386.rpm). So at least for now 
> I wouldn't be able to _test_ the git-for-each-ref.

That's not a good excuse, though.  It means you cannot propose
new core-side support that only gitweb would benefit from
initially, since we will not add new stuff to the core that does
not have real users, and new stuff in the core must be cooked in
"next" before it is proven to be useful and correct.

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> Junio C Hamano wrote:
>>
>>>   - An experimental git-for-each-ref command to help language
>>>     bindings to get information on many refs at once.  Hopefully
>>>     Jakub can teach gitweb to use it to speed things up.
>>
>> I use 'origin' (or 'next') version of gitweb, while using _released_
>> version of git (git-core-1.4.2.1-1.i386.rpm). So at least for now 
>> I wouldn't be able to _test_ the git-for-each-ref.
> 
> That's not a good excuse, though.  It means you cannot propose
> new core-side support that only gitweb would benefit from
> initially, since we will not add new stuff to the core that does
> not have real users, and new stuff in the core must be cooked in
> "next" before it is proven to be useful and correct.
 
But this also means that if I were for example to use git-for-each-ref
in gitweb, I couldn't _test_ if it works. Ah, well, if you can live with
PATCH/RFC... But I'd rather wait for git-for-each-ref in _released_ version
of git. 

On the other side as you said the true test for new core stuff is to use
it. Perhaps someone who runs 'master' or 'next' version of git...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1250 bytes --]

Hi,

On Mon, 18 Sep 2006, Jakub Narebski wrote:

> Junio C Hamano wrote:
> 
> > Jakub Narebski <jnareb@gmail.com> writes:
> > 
> >> Junio C Hamano wrote:
> >>
> >>>   - An experimental git-for-each-ref command to help language
> >>>     bindings to get information on many refs at once.  Hopefully
> >>>     Jakub can teach gitweb to use it to speed things up.
> >>
> >> I use 'origin' (or 'next') version of gitweb, while using _released_
> >> version of git (git-core-1.4.2.1-1.i386.rpm). So at least for now 
> >> I wouldn't be able to _test_ the git-for-each-ref.
> > 
> > That's not a good excuse, though.  It means you cannot propose
> > new core-side support that only gitweb would benefit from
> > initially, since we will not add new stuff to the core that does
> > not have real users, and new stuff in the core must be cooked in
> > "next" before it is proven to be useful and correct.
>  
> But this also means that if I were for example to use git-for-each-ref
> in gitweb, I couldn't _test_ if it works. Ah, well, if you can live with
> PATCH/RFC... But I'd rather wait for git-for-each-ref in _released_ version
> of git. 

Why not set up a testing directory, where you use both gitweb _and_ git 
from next? It is easy...

Ciao,
Dscho

Re: What's in git.git

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> > That's not a good excuse, though.  It means you cannot propose
>> > new core-side support that only gitweb would benefit from
>> > initially, since we will not add new stuff to the core that does
>> > not have real users, and new stuff in the core must be cooked in
>> > "next" before it is proven to be useful and correct.
>>  
>> But this also means that if I were for example to use git-for-each-ref
>> in gitweb, I couldn't _test_ if it works. Ah, well, if you can live with
>> PATCH/RFC... But I'd rather wait for git-for-each-ref in _released_ version
>> of git. 
>
> Why not set up a testing directory, where you use both gitweb _and_ git 
> from next? It is easy...

That's Ok; it means that he just cannot work on certain things.
It's not like we take gitweb patch only from Jakub, so it is not
the end of the world either ;-).

Also it is handy to have somebody who sticks to things that are
available in master to catch breakage we might accidentally
cause by Porcelainish commands jumping the gun before core-side
change hits the master branch.

Re: What's in git.git

[Franck Bui-Huu]

Junio C Hamano wrote:
> 
>   - Franck Bui-Huu and Rene Scharfe added 'git-archive' command,
>     that will eventually supersede 'git-tar-tree' and
>     'git-zip-tree'.
> 

I still have one issue, but haven't found out the solution yet.
Actually I even don't know if its related to 'archive/upload-archive'
commands. Could someone give it a try to tell me if he can at least
reproduce it ?

Here is the scenario (git-daemon and git-archive are executed on the
same machine):

git-daemon is started with the following command:

$  git daemon --verbose --syslog --export-all  \
   --enable=upload-archive --base-path=/home/fbuihuu/tmp/ --reuseaddr

git-archive is run to archive a small repo located in ~/tmp/test-git.
This is done in an endless loop:

$ while true; do
> git archive --format=tar --remote=git://localhost/test-git HEAD | tar tf -
> done
a
b
a
b
a
b
a
b
a
b
a
b
a
b # stuck !!!

So after a couple of loops, git-archive is stuck waiting for git-daemon but
daemon seems to be stuck somewhere.

Syslog shows something interesting here:

[...]
Sep 18 16:11:42 25-fbuihuu git-daemon: [16549] Connection from 127.0.0.1:30373
Sep 18 16:11:42 25-fbuihuu git-daemon: [16549] Extended attributes (16 bytes) exist <host=localhost>
Sep 18 16:11:42 25-fbuihuu git-daemon: [16549] Request upload-archive for '/test-git2'
Sep 18 16:11:42 25-fbuihuu git-upload-archive: finished
Sep 18 16:11:42 25-fbuihuu git-daemon: [16549] Disconnected
Sep 18 16:11:42 25-fbuihuu git-daemon: [16553] Connection from 127.0.0.1:30629
Sep 18 16:11:42 25-fbuihuu git-daemon: [16553] Extended attributes (16 bytes) exist <host=localhost>
Sep 18 16:11:42 25-fbuihuu git-daemon: [16553] Request upload-archive for '/test-git2'
Sep 18 16:11:42 25-fbuihuu git-upload-archive: finished
[END]

It looks like git-daemon never receives the SIGCHLD signal that is
normally sent by upload-archive once it has finished its job.

		Franck

What's in git.git

[Junio C Hamano]

* The 'maint' branch has these fixes since the last announcement.

   t3403-rebase-skip failed when run while its standard input is
   connected to /dev/null.  It turns out that an earlier safety
   check to prevent git-am to be fed a new patch while there is
   a leftover .dotest/ directory was incorrect.  Fixed.

   There was an unnecessary xmalloc() in builtin-add.  Removed.

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

   Recent change to http-fetch.c did not play well with older
   curl releases.  Fixed.

   Clean-up of gitweb continues.  Notably, generation the
   summary page makes fewer call to git executable.

   Receive-pack has an added safety check that lets the
   repository owner to forbid non-fast-forward push into a
   shared repository by setting receive.denyNonFastforwards
   configuration variable.

   Output from git-describe can now be used as an abbreviated
   object name.

   git-resolve is now officially deprecated.  The next "master"
   release (1.4.3) will ship with a version that gives an
   annoying "deprecation warning" message, and the command will
   be removed from the release after that.

   There was a build problem in upload-archive on OpenBSD.  Fixed.

   git-zip-tree is now superseded by "git-archive --format=zip".

   Miscellaneous clean-ups and documentation updates.

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

   A new command git-show-ref was added to list and verify local
   references.

   A new command git-for-each-ref was added to help Porcelains
   to make smaller number of calls to git binary to obtain
   summary information for refs.

   cvsimport was updated to use git-for-each-ref.

   Git.pm topic lost Git.xs for now.

   The resolve_ref() internal API was straightened out to work
   solely on refname (i.e. string that begins with "refs/"),
   instead of pathnames.  To deal with many refs efficiently,
   there is now a "packed-ref" format where many refs are stored
   in a single flat file instead of the traditional
   one-ref-per-file format.

   git-diff --color highlights trailing whitespaces and SP
   followed by TAB in indentation as common whitespace errors.

   git-daemon now has a virtual host support.

   upload-pack stops the fetch-pack on the other side when
   downloader has more roots than uploader; otherwise the
   downloader would send "have" from a development line that
   the uploader does not know about til its root.

   git-log learned --author=, --committer= and --grep= options
   to filter commits.

   pack-objects now creates version 3 packs; this allows a copy
   of larger block of data to be expressed.

   Per branch configuration items branch."branchname".remote can
   specify what remotes/ file instead of usual "origin" should
   be used when no option is given to "git fetch" while on the
   named branch.  Similarly, branch."branchname".merge can
   specify which remote branches to be merged while on the named
   branch.

   git-svnimport learned a new trick to parse log message for
   Signed-off-by: lines and pick authorship information from
   there.  I haven't heard Ack nor Nack from any subversion
   users, but we will hopefully hear somebody scream if it
   breaks things after pushing it out to "master".

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

   git-apply --whitespace learned to notice SP before TAB in
   indent as a common whitespace error, in addition to the
   trailing whitespaces it already knew about.

   git-diff output is unfriendly to GNU patch when the filename
   contained a SP.  Appending a TAB after filename in this case
   works the problem around.  However, git-apply needs to learn
   about it as well, so it did.

   There is one new data type in the pack format that records
   delta base object by offset in the stream instead of 20-byte
   object name.  This reduces the resulting packsize by 3 to 5%.

   One additional test for git-branch is in, but the current
   implementation of git-branch fails it.

What's in git.git

[Junio C Hamano]

* The 'master' branch has these since the last announcement.
  There are some small bits I'd like to merge still brewing in
  'next' before the -rc1, but please expect a real 1.4.3-rc1
  soon.

  - git-daemon virtual hosting.

  - With git-branch, deleting branch a/b and then creating
    branch a did not work.  Fixed.

  - Updated git-archive documentation.

  - git-repack can be run from project subdirectory.

  - git-log and friends can limit output with --author,
    --committer and --grep options.

  - Minor git-runstatus by Johannes Schindelin.

  - git-diff --color highlights whitespace errors.

  - git-apply --whitespace={warn,error,strip} notices whitespace
    errors in indentation.

  - git-tar is now a thin wrapper to "git-archive --format=tar";
    "git-tar --remote" talks with "git-upload-archive" on the
    other end.

  - Python-based merge-recursive is deprecated.  It is still
    available as "recursive-old" strategy, but "recursive"
    strategy now uses the C implementation.  The earlier synonym
    "recur" still available.

  - "git-grep --fixed-strings" with boolean expression did not
    work; fixed.

  - git-pack-objects generates packfile version 3 that can
    express copying of larger block from delta base.

  - Many internal routines that deal with using packfiles have
    been cleaned up.

  - Many updates to gitweb by the usual suspects.

  - Default repository to fetch from, and the remote branches to
    merge, can be specified by per-branch configuration items.

  - git-svnimport gets the full author name from Signed-off-by:
    line when available.

  - git-svn got a few updates.

  - git-checkout while not on a branch (e.g. git-init-db
    followed by git-fetch to create branches from remotes) did
    not work; fixed.

  - Even when core.filemode is set to false (i.e. the filesystem
    does not have reliable mode bits), git-update-index still
    registered new paths with random mode bits obtained from the
    filesystem.  Fixed.


* The 'next' branch, in addition, has these.  I think the ones
  marked with + could be 1.4.3-rc1 material:

  - Triggered by the packed-ref series from Linus, we have
    accumulated a few topics, but I decided to consolidate them
    into one topic branch.  It contains:

    - resolve_ref() API cleanup;

    - for_each_ref() API cleanup;

    - git-show-ref helper;

    - git-for-each-ref helper;

    - ref locking fix-up to tighten races for ref creation and
      deletion cases;

    - packed refs and pruning of refs;

    - git-receive-pack now uses lock_ref_sha1() API and updates
      ref-log like other programs;

    The series still has a few problems I listed in my earlier
    message:

	Subject: What will happen to git.git in the near future
	Message-ID: <7v7iztbldm.fsf@assigned-by-dhcp.cox.net>

    I do not plan to include this in the next release; hopefully
    soon after the next release we can have it in 'master'.  

  - cvsimport was updated to use for-each ref.  This obviously
    depends on the above.

  + Git.pm lost Git.xs; its remnant still remains, though.
    Notably, we still compile x86_64 with -fPIC, and the top
    level Makefile has {BASIC,ALL}_{CFLAGS,LDFLAGS} distinction
    and INSTALL talks about perl/blib/arch/auto.  I am torn
    between removing these and keeping them; on one hand, they
    are not needed and makes new developers wonder what the
    distinction between BASIC and ALL are.  On the other hand,
    we may eventually would want to reintroduce Git.xs in the
    future and keeping them might help us.  But on the third
    hand ;-), we can always resurrect it from the repository and
    that is the point of using git to keep track of the project,
    so removing them might not be such a big deal.  I'd like to
    decide between this two and push it out to 'master' before
    doing the -rc1.

  + More gitweb updates from usual suspects.

  + "git-diff --stat" can now be told to use custom output width
    with --stat-width=N option instead of the default 80.

  + "git-diff --stat --color" shows the graph in colors.

  - "git-grep --all-match" limits output to files that have all
    the top-level ORed expressions.  I suck at documentation and
    the description I added to the manual needs rewriting.
    Help?

  - git-log and friends learned the same --all-match flag.  With
    it:

    	git log --all-match --author=Linus --committer=Junio --grep=list

    would show only changes written by Linus and committed by me
    and talks about "list".

  - updates to packfile format that allows delta base objects to
    be expressed by offset in the stream, not by 20-byte object
    name.  Just completed and started cooking in 'next'.

  - upload-pack: stop the other side when they have more roots than we do.


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

  - change "git-diff" output for paths with embedded SP a bit
    friendlier to "GNU patch".  This is done by appending an
    extra TAB after "--- a/file name" and "+++ b/file name"
    lines.  This needs to be done in two steps:

    - prepare git-apply to take the new output format.

    - update git-diff to produce such, after people's git-apply
      has been updated.

    Do people have objection to the output format change?
    Otherwise I'd like to merge the first stage to 'next', and
    perhaps soon after 1.4.3 to 'master'.

  - two git-cvsexportcommit improvements, which unfortunately
    fails with certain combination of patch/perl/cvs; breakage
    under investigation by the author.

Re: What's in git.git

[Petr Baudis]

Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
>   -

BTW, what's the difference between '-' and '+'?

>   + Git.pm lost Git.xs; its remnant still remains, though.
>     Notably, we still compile x86_64 with -fPIC, and the top
>     level Makefile has {BASIC,ALL}_{CFLAGS,LDFLAGS} distinction
>     and INSTALL talks about perl/blib/arch/auto.  I am torn
>     between removing these and keeping them; on one hand, they
>     are not needed and makes new developers wonder what the
>     distinction between BASIC and ALL are.  On the other hand,
>     we may eventually would want to reintroduce Git.xs in the
>     future and keeping them might help us.  But on the third
>     hand ;-), we can always resurrect it from the repository and
>     that is the point of using git to keep track of the project,
>     so removing them might not be such a big deal.  I'd like to
>     decide between this two and push it out to 'master' before
>     doing the -rc1.

FWIW, I'd say kill it all (perhaps except BASIC_*, I don't know about
that one) - we indeed can easily resurrect this, and that was the
presumption with which I've killed the rest of Git.xs. There's no point
in keeping legacy cruft around when we can take it back from the
history.

Perhaps we could throw a note to perl/Makefile saying

	# If you are thinking about adding Git.xs support, please note
	# that we have already been there before - see the #next branch
	# history for more-or-less working one already added, and also
	# the reason why it was removed for now.

so that noone wastes their time.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Thu, 28 Sep 2006, Petr Baudis wrote:

> Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
> 
> >   + Git.pm lost Git.xs; its remnant still remains, though.
> >     Notably, we still compile x86_64 with -fPIC, and the top
> >     level Makefile has {BASIC,ALL}_{CFLAGS,LDFLAGS} distinction
> >     and INSTALL talks about perl/blib/arch/auto.  I am torn
> >     between removing these and keeping them; on one hand, they
> >     are not needed and makes new developers wonder what the
> >     distinction between BASIC and ALL are.  On the other hand,
> >     we may eventually would want to reintroduce Git.xs in the
> >     future and keeping them might help us.  But on the third
> >     hand ;-), we can always resurrect it from the repository and
> >     that is the point of using git to keep track of the project,
> >     so removing them might not be such a big deal.  I'd like to
> >     decide between this two and push it out to 'master' before
> >     doing the -rc1.
> 
> FWIW, I'd say kill it all (perhaps except BASIC_*, I don't know about
> that one) - we indeed can easily resurrect this, and that was the
> presumption with which I've killed the rest of Git.xs. There's no point
> in keeping legacy cruft around when we can take it back from the
> history.
> 
> Perhaps we could throw a note to perl/Makefile saying
> 
> 	# If you are thinking about adding Git.xs support, please note
> 	# that we have already been there before - see the #next branch
> 	# history for more-or-less working one already added, and also
> 	# the reason why it was removed for now.
> 
> so that noone wastes their time.

Having ranted so often about Git.xs, I feel like I have to apologize. It 
would be a better idea (IMHO) to put an effort into having the _option_ to 
use Git.xs, since it is so much more efficient. If it is a strict opt-in, 
I think it could remain in "next", and it would be much more likely that 
people took up the ball and worked towards libifying git.

Ciao,
Dscho

Re: What's in git.git

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> FWIW, I'd say kill it all (perhaps except BASIC_*, I don't know about
> that one) - we indeed can easily resurrect this, and that was the
> presumption with which I've killed the rest of Git.xs. There's no point
> in keeping legacy cruft around when we can take it back from the
> history.

I came up with this to apply on top of "next".  Extra sets of
eyeballs very much appreciated.

-- >8 --
Remove -fPIC which was only needed for Git.xs

The distinction between BASIC_ vs ALL_ is still kept, since it
is not Git.xs specific -- we could face the same issue when we
do other language bindings (e.g. Python). 

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 INSTALL       |   13 -------------
 Makefile      |   13 -------------
 config.mak.in |    1 -
 configure.ac  |    7 -------
 4 files changed, 0 insertions(+), 34 deletions(-)

diff --git a/INSTALL b/INSTALL
index 0d432d7..fa9bf74 100644
--- a/INSTALL
+++ b/INSTALL
@@ -38,19 +38,6 @@ Issues of note:
    has been actively developed since 1997, and people have moved over to
    graphical file managers.
 
- - You can use git after building but without installing if you
-   wanted to.  Various git commands need to find other git
-   commands and scripts to do their work, so you would need to
-   arrange a few environment variables to tell them that their
-   friends will be found in your built source area instead of at
-   their standard installation area.  Something like this works
-   for me:
-
-	GIT_EXEC_PATH=`pwd`
-	PATH=`pwd`:$PATH
-	GITPERLLIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git
-	export GIT_EXEC_PATH PATH GITPERLLIB
-
  - Git is reasonably self-sufficient, but does depend on a few external
    programs and libraries:
 
diff --git a/Makefile b/Makefile
index 8a7f29b..1875965 100644
--- a/Makefile
+++ b/Makefile
@@ -60,9 +60,6 @@ # a bundled SHA1 routine coming from Moz
 # on non-x86 architectures (e.g. PowerPC), while the OpenSSL version (default
 # choice) has very fast version optimized for i586.
 #
-# Define USE_PIC if you need the main git objects to be built with -fPIC
-# in order to build and link perl/Git.so.  x86-64 seems to need this.
-#
 # Define NEEDS_SSL_WITH_CRYPTO if you need -lcrypto with -lssl (Darwin).
 #
 # Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
@@ -112,7 +109,6 @@ uname_P := $(shell sh -c 'uname -p 2>/de
 # CFLAGS and LDFLAGS are for the users to override from the command line.
 
 CFLAGS = -g -O2 -Wall
-PIC_FLAG = -fPIC
 LDFLAGS =
 ALL_CFLAGS = $(CFLAGS)
 ALL_LDFLAGS = $(LDFLAGS)
@@ -402,12 +398,6 @@ endif
 ifneq (,$(findstring arm,$(uname_M)))
 	ARM_SHA1 = YesPlease
 endif
-ifeq ($(uname_M),sun4u)
-	USE_PIC = YesPlease
-endif
-ifeq ($(uname_M),x86_64)
-	USE_PIC = YesPlease
-endif
 
 -include config.mak.autogen
 -include config.mak
@@ -546,9 +536,6 @@ else
 endif
 endif
 endif
-ifdef USE_PIC
-	ALL_CFLAGS += $(PIC_FLAG)
-endif
 ifdef NO_ACCURATE_DIFF
 	BASIC_CFLAGS += -DNO_ACCURATE_DIFF
 endif
diff --git a/config.mak.in b/config.mak.in
index addda4f..fecae80 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -3,7 +3,6 @@ # @configure_input@
 
 CC = @CC@
 CFLAGS = @CFLAGS@
-PIC_FLAG = @PIC_FLAG@
 AR = @AR@
 TAR = @TAR@
 #INSTALL = @INSTALL@		# needs install-sh or install.sh in sources
diff --git a/configure.ac b/configure.ac
index 0f93f6f..8192826 100644
--- a/configure.ac
+++ b/configure.ac
@@ -96,13 +96,6 @@ ## Checks for programs.
 AC_MSG_NOTICE([CHECKS for programs])
 #
 AC_PROG_CC([cc gcc])
-if test -n "$GCC"; then
-	PIC_FLAG="-fPIC"
-else
-	AC_CHECK_DECL(__SUNPRO_C, [CFLAGS="$CFLAGS -xO3"; PIC_FLAG="-KPIC"])
-fi
-AC_SUBST(PIC_FLAG)
-
 #AC_PROG_INSTALL		# needs install-sh or install.sh in sources
 AC_CHECK_TOOL(AR, ar, :)
 AC_CHECK_PROGS(TAR, [gtar tar])

Re: What's in git.git

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>>   -
>
> BTW, what's the difference between '-' and '+'?

quoting myself...

|| * The 'next' branch, in addition, has these.  I think the ones
||   marked with + could be 1.4.3-rc1 material:

Re: What's in git.git

[Petr Baudis]

Dear diary, on Fri, Sep 29, 2006 at 09:34:51AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> diff --git a/INSTALL b/INSTALL
> index 0d432d7..fa9bf74 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -38,19 +38,6 @@ Issues of note:
>     has been actively developed since 1997, and people have moved over to
>     graphical file managers.
>  
> - - You can use git after building but without installing if you
> -   wanted to.  Various git commands need to find other git
> -   commands and scripts to do their work, so you would need to
> -   arrange a few environment variables to tell them that their
> -   friends will be found in your built source area instead of at
> -   their standard installation area.  Something like this works
> -   for me:
> -
> -	GIT_EXEC_PATH=`pwd`
> -	PATH=`pwd`:$PATH
> -	GITPERLLIB=`pwd`/perl/blib/lib:`pwd`/perl/blib/arch/auto/Git
> -	export GIT_EXEC_PATH PATH GITPERLLIB
> -
>   - Git is reasonably self-sufficient, but does depend on a few external
>     programs and libraries:
>  

The passage should be kept and even GITPERLLIB - just drop the second
path after the colon.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: What's in git.git

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

>> - - You can use git after building but without installing if you
>>...
>> -	export GIT_EXEC_PATH PATH GITPERLLIB
>> -
>>   - Git is reasonably self-sufficient, but does depend on a few external
>>     programs and libraries:
>
> The passage should be kept and even GITPERLLIB - just drop the second
> path after the colon.

Thanks.

What's in git.git

[Junio C Hamano]

* The 'maint' branch has produced the third maintenance release
  1.4.2.3 a few days ago.

* The 'master' branch is at 1.4.3-rc1; we are in stabilization
  cycle.  I do not think I have made any formal announcement on
  the merge policy during -rc; I am planning to play by the
  following rules:

  * no new features nor interface change should hit "master"
    after -rc1, but I am a human and smaller things could seep
    through ;-).

  * fixes for "master" are encouraged and very much appreciated;

  * fixes for "next" are also encouraged and appreciated, but
    perfecting a topic that was still in "next" after -rc1 will
    not make the topic for a candidate in the upcoming "master"
    release.  It will make the topic merged as part of the first
    wave of merges after the release.

  * For totally new topics, I reserve the right to drop them on
    the floor during the stabilization period, but they might
    get lucky and land on "next" or "pu" depending on my mood.
    Please re-send them after the next release if you care
    deeply enough.

  contrib/ is exempt from the above rules for obvious reasons.

Here are what was added since 1.4.3-rc1 and will be in 1.4.3.
By the above definition, they should mostly be fixes:

Alan Chandler:
      Update the gitweb/README file to include setting the GITWEB_CONFIG environment
      git.c: Fix usage string to match that given in the man page

Alexandre Julliard:
      git.el: Fixed inverted "renamed from/to" message.
      vc-git.el: Switch to using git-blame instead of git-annotate.

Dennis Stosberg:
      lock_ref_sha1_basic does not remove empty directories on BSD

Franck Bui-Huu:
      Add git-upload-archive to the main git man page

Junio C Hamano:
      Makefile: install and clean merge-recur, still.
      git-mv: invalidate the removed path properly in cache-tree
      git-push: .git/remotes/ file does not require SP after colon
      escape tilde in Documentation/git-rev-parse.txt
      tar-tree deprecation: we eat our own dog food.
      gitweb: Make the Git logo link target to point to the homepage
      git-send-email: avoid uninitialized variable warning.
      cherry-pick: make -r the default

Luben Tuikov:
      gitweb: Escape ESCAPE (\e) character
      gitweb: Do not print "log" and "shortlog" redundantly in commit view
      gitweb: blame: Minimize vertical table row padding

Martin Waitz:
      gitweb: document webserver configuration for common gitweb/repo URLs.
      git-commit: cleanup unused function.

Robin Rosenberg:
      Error in test description of t1200-tutorial


* The 'next' branch, in addition, has these.  They will not be
  in 1.4.3 (except one):

  - git-pack-refs, git-for-each-ref, git-show-ref by Linus and
    me, with help in updating the documentation, test scripts,
    and updates to the tools to use them from Andy Whitcroft,
    Christian Couder, Dennis Stosberg, Jeff King, Johannes,
    Jonas, Pasky,

    I think this is in testable shape and I started to use
    packed refs in one of my test repositories to see what are
    still broken.  Hopefully be in "master" soon after 1.4.3.

  - git-receive-pack uses the common ref-locking code, and as a
    side effect git-push will add ref-log entries on the remote
    end if enabled.

    This depends on the first item and should be considered a
    part of it.

  - git log --summary without any other options now look into
    subdirectories, thanks to Johannes.

    This is a small backward-incompatible change, but I think it
    falls into "fix a broken behaviour" category (same as making
    "cherry-pick -r" the default).  If nobody objects I'll merge
    it to "master" before 1.4.3-rc2.

  - "git log --all-match --author=Foo --committer=Bar".

  - "git apply" is prepared for planned output format change for
    "git diff" when a file with SP in its name is involved.  We
    will add a trailing TAB on "+++/---" lines.

    Merge to "master" immediately after 1.4.3

  - Santi Béjar tidied up output from fetch and merge.

    Merge to "master" immediately after 1.4.3

  - Robert Shearman taught git-rebase (sans --merge) to use
    --ignore-if-in-upstream to reduce obvious conflicts, and
    taught it to show upstream changes with -v option.

    Merge to "master" immediately after 1.4.3

  - Assorted gitweb updates by Alan Chandler, me, Luben Tuikov,
    Martin Waitz

    Notable enhancements are:

    - blame page output got a facelift.
    - the URL gitweb generates can use PATH_INFO.

    Merge to "master" sometime after 1.4.3

  - Nico's pack format optimization.

    I've been using this for my pulls and haven't seen a
    problem.  I'll enable it for repository packing in one of my
    test repository soon to see if I get burned ;-) but I do not
    expect breakage from Nico's code.  Soon after dust settles
    from other ones graduating to "master" post 1.4.3.

  - "git blame --show-name" tells it to always output filename.

    After dust settles from other ones graduating to "master"
    post 1.4.3.

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

  - "git diff"'s output format change for a file with SP in its
    name, as described above.  This will be merged after the
    matching change to "git apply" graduates to "master" and
    matures.

  - "git blame --porcelain" gives richer information on revs
    that are involved for scripted use.

  - "gitweb" is updated to use the above "git blame --porcelain"

  - My WIP of parallel tree walker hasn't made any progress.
 

What's in git.git

[Junio C Hamano]

* The 'maint' branch has this fix and produced 1.4.2.4 release.

   Linus Torvalds (1):
      Fix hash function in xdiff library


* The 'master' branch has these since the last announcement.
  The fix in 'maint' is also included.  Hopefully we can cut the
  real 1.4.3 with this sometime this week.

   Junio C Hamano (1):
      Revert "move pack creation to version 3"

   Petr Baudis (1):
      svnimport: Fix broken tags being generated

   Rene Scharfe (2):
      Make write_sha1_file_prepare() void
      Replace open-coded version of hash_sha1_file()


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

   Alan Chandler (1):
      Gitweb - provide site headers and footers

   Andy Whitcroft (2):
      cvsimport: move over to using git-for-each-ref to read refs.
      git-for-each-ref: improve the documentation on scripting modes

   Christian Couder (12):
      Add [-s|--hash] option to Linus' show-ref.
      Use Linus' show ref in "git-branch.sh".
      Document git-show-ref [-s|--hash] option.
      Fix show-ref usage for --dereference.
      Add pack-refs and show-ref test cases.
      When creating branch c/d check that branch c does not already exists.
      Uncomment test case: git branch c/d should barf if branch c exists.
      Fix a remove_empty_dir_recursive problem.
      Clean up "git-branch.sh" and add remove recursive dir test cases.
      Use git-update-ref to delete a tag instead of rm()ing the ref file.
      Check that a tag exists using show-ref instead of looking for the ref file.
      Do not create tag leading directories since git update-ref does it.

   Dennis Stosberg (2):
      lock_ref_sha1_basic does not remove empty directories on BSD
      Remove bashism from t3210-pack-refs.sh

   Jeff King (3):
      wt-status: use simplified resolve_ref to find current branch
      gitignore: git-pack-refs is a generated file.
      gitignore: git-show-ref is a generated file.

   Johannes Schindelin (3):
      Fix git-update-index --again
      show-branch: mark active branch with a '*' again
      Turn on recursive with --summary

   Jonas Fonseca (1):
      Add man page for git-show-ref

   Junio C Hamano (55):
      upload-pack: stop the other side when they have more roots than we do.
      Add git-for-each-ref: helper for language bindings
      Fix t1400-update-ref test minimally
      fsck-objects: adjust to resolve_ref() clean-up.
      symbolit-ref: fix resolve_ref conversion.
      Add callback data to for_each_ref() family.
      Tell between packed, unpacked and symbolic refs.
      pack-refs: do not pack symbolic refs.
      git-pack-refs --prune
      pack-refs: fix git_path() usage.
      lock_ref_sha1_basic: remove unused parameter "plen".
      Clean-up lock-ref implementation
      update-ref: -d flag and ref creation safety.
      update a few Porcelain-ish for ref lock safety.
      Teach receive-pack about ref-log
      receive-pack: call setup_ident before git_config
      grep --all-match
      teach revision walker about --all-match.
      git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 1)
      ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
      refs: minor restructuring of cached refs data.
      lock_ref_sha1(): do not sometimes error() and sometimes die().
      lock_ref_sha1(): check D/F conflict with packed ref when creating.
      delete_ref(): delete packed ref
      git-branch: remove D/F check done by hand.
      show-ref --hash=len, --abbrev=len, and --abbrev
      git-fetch: adjust to packed-refs.
      Fix refs.c;:repack_without_ref() clean-up path
      gitweb: make leftmost column of blame less cluttered.
      git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
      pack-refs: use lockfile as everybody else does.
      gitweb: prepare for repositories with packed refs.
      Revert 954a6183756a073723a7c9fd8d2feb13132876b0
      pack-refs: call fflush before fsync.
      blame.c: whitespace and formatting clean-up.
      git-blame: --show-number (and -n)
      git-blame: --show-name (and -f)
      blame.c: move code to output metainfo into a separate function.
      git-send-email: do not drop custom headers the user prepared
      ref-log: allow ref@{count} syntax.
      git-send-email: real name with period need to be dq-quoted on From: line
      git-blame --porcelain
      gitweb: use blame --porcelain
      Make git-send-email detect mbox-style patches more readily
      core.logallrefupdates create new log file only for branch heads.
      git-pack-refs --all
      core.logallrefupdates thinko-fix
      pack-objects: document --delta-base-offset option
      blame: Document and add help text for -f, -n, and -p
      gitweb: spell "blame --porcelain" with -p
      git-repack: repo.usedeltabaseoffset
      diff --numstat
      pack-objects: use of version 3 delta is now optional.
      gitweb: use for-each-ref to show the latest activity across branches
      Revert "pack-objects: use of version 3 delta is now optional."

   Linus Torvalds (6):
      Add "git show-ref" builtin command
      Teach "git checkout" to use git-show-ref
      Start handling references internally as a sorted in-memory list
      Add support for negative refs
      Make ref resolution saner
      Enable the packed refs file format

   Luben Tuikov (4):
      gitweb: blame: print commit-8 on the leading row of a commit-block
      gitweb: blame: Mouse-over commit-8 shows author and date
      gitweb: blame porcelain: lineno and orig lineno swapped
      git-revert with conflicts to behave as git-merge with conflicts

   Martin Waitz (2):
      gitweb: start to generate PATH_INFO URLs.
      gitweb: warn if feature cannot be overridden.

   Matthew Wilcox (1):
      Add --dry-run option to git-send-email

   Nicolas Pitre (8):
      introduce delta objects with offset to base
      teach git-unpack-objects about deltas with offset to base
      teach git-index-pack about deltas with offset to base
      make git-pack-objects able to create deltas with offset to base
      make pack data reuse compatible with both delta types
      let the GIT native protocol use offsets to delta base when possible
      zap a debug remnant
      allow delta data reuse even if base object is a preferred base

   Petr Baudis (5):
      Fix broken sha1 locking
      Fix buggy ref recording
      gitweb: Document features better
      gitweb: Fix search form when PATH_INFO is enabled
      bisect reset: Leave the tree in usable state if git-checkout failed

   Rene Scharfe (2):
      git-archive --format=zip: use default version ID
      git-archive --format=zip: add symlink support

   Robert Shearman (2):
      git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
      git-rebase: Add a -v option to show a diffstat of the changes upstream at the start of a rebase.

   Ryan Anderson (1):
      Remove git-annotate.perl and create a builtin-alias for git-blame

   Santi Béjar (2):
      fetch: Misc output cleanup
      merge and resolve: Output short hashes and .. in "Updating ..."

   Sasha Khapyorsky (1):
      git-svnimport.perl: copying directory from original SVN place


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

   Junio C Hamano (17):
      git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
      para-walk: walk n trees, index and working tree in parallel
      para walk wip
      merge: loosen overcautious "working file will be lost" check.
      git-pickaxe: blame rewritten.
      git-pickaxe: minimally use revision machinery.
      git-pickaxe: fix output for more than one paths from the same commit.
      git-pickaxe: fix "bottom" commit handling.
      git-pickaxe: allow using non -u0 diff internally.
      git-pickaxe: use linked list of blame entries.
      git-pickaxe: collapse trivial blame entry.
      git-pickaxe: blame line movements within a file.
      git-pickaxe: blame cut-and-pasted lines.
      git-pickaxe: -M, -C, and -C -C
      git-pickaxe: optimize nth_line()
      git-pickaxe: make -C (copy from other file) take immediate blame.
      git-pickaxe: document -M, -C, and -C -C

   Petr Baudis (1):
      gitweb: Show project README if available

Re: What's in git.git

[Linus Torvalds]

On Tue, 17 Oct 2006, Junio C Hamano wrote:
>
> * The 'maint' branch has this fix and produced 1.4.2.4 release.
> 
>    Linus Torvalds (1):
>       Fix hash function in xdiff library

There's two things to note about this:

 - the libxdiff dependencies are broken, so it's likely that you need to 
   do a "make clean; make" to actually see the result of this.

   We really should fix this. I was bitten by this _again_ when I wanted 
   to do some performance testing, and was scratching my head about why it 
   didn't seem to matter.

   I haven't looked into which part of the Makefile is broken yet, so I 
   really don't know what's broken, but maybe somebody who likes makefiles 
   could take a look? Basically, doing a

	touch xdiff/xmacros.h

   should cause a recompile of a lot more than it causes.

 - while the hash function problem _can_ cause really huge slowdowns in 
   some unlucky situations, it actually causes noticeable performance 
   issues even for normal situations.

   For example, for me on a 2GHz merom machine in the current git 
   directory:

   Before:

	[torvalds@merom git]$ time ./git log -p | wc -l
	746211
	
	real    0m27.223s
	user    0m26.894s
	sys     0m0.424s

   After:

	[torvalds@merom git]$ time ./git log -p | wc -l
	746211
	
	real    0m9.638s
	user    0m9.329s
	sys     0m0.468s

   so there's a factor-of-three difference here even on a "normal" load 
   like git itself. You don't need a huge file with tons of changes to see 
   the effect of this.

So we should fix the makefile to add whatever proper header file 
dependencies, but we should also make sure that whoever builds binaries 
has done a "make clean", otherwise the fix is potentially hidden.

		Linus

Re: What's in git.git

[Davide Libenzi]

On Tue, 17 Oct 2006, Linus Torvalds wrote:

>  - while the hash function problem _can_ cause really huge slowdowns in 
>    some unlucky situations, it actually causes noticeable performance 
>    issues even for normal situations.

Yes, using a 32 bits multiplier on a 64 bits machine transform the almost 
O(1) hash performance to a crappy O(N) list performance. you notice that 
in every diff operation, independently from the content.



- Davide

Re: What's in git.git

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> There's two things to note about this:
>
>  - the libxdiff dependencies are broken, so it's likely that you need to 
>    do a "make clean; make" to actually see the result of this.

Eh, stupid-and-obvious like this perhaps.

---

diff --git a/Makefile b/Makefile
index 2c7c338..3fed480 100644
--- a/Makefile
+++ b/Makefile
@@ -237,6 +237,7 @@ PYMODULES = \
 
 LIB_FILE=libgit.a
 XDIFF_LIB=xdiff/lib.a
+$(XDIFF_LIB): $(wildcard xdiff/*.[ch])
 
 LIB_H = \
 	archive.h blob.h cache.h commit.h csum-file.h delta.h grep.h \

Re: What's in git.git

[Linus Torvalds]

On Tue, 17 Oct 2006, Junio C Hamano wrote:
> 
> Eh, stupid-and-obvious like this perhaps.

I'm not convinced that is enough. You need to make the individual 
xdiff/*.c files depend on the xdiff/*.h files, because otherwise it will 
think that the *.o files are up-to-date and just re-link the archive.

The kernel does automatic dependency generation for all the *.c files, and 
it's _really_ nice. Having to do dependencies by hand is just always going 
to suck. But the kernel can depend on more things (in particular, the 
kernel can depend on gcc, and use things like "-MD,$(depfile)" to generate 
lists of dependencies while building, so that any object file _always_ has 
the things it depended upn explicitly listed).

But in the absense of those kinds of really clever and powerful tricks, it 
might be worthwhile to even just have a "mkdepend" scrupt thing and 
include the end result into the Makefile (we do already depend on GNU 
make).

That would allow us to get the real dependencies (and minimal! right now 
we sometimes compile too _much_ just because some of our dependencies are 
so screwed up and lazy).

			Linus

Re: What's in git.git

[Andy Whitcroft]

Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> 
>> There's two things to note about this:
>>
>>  - the libxdiff dependencies are broken, so it's likely that you need to 
>>    do a "make clean; make" to actually see the result of this.
> 
> Eh, stupid-and-obvious like this perhaps.
> 
> ---
> 
> diff --git a/Makefile b/Makefile
> index 2c7c338..3fed480 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -237,6 +237,7 @@ PYMODULES = \
>  
>  LIB_FILE=libgit.a
>  XDIFF_LIB=xdiff/lib.a
> +$(XDIFF_LIB): $(wildcard xdiff/*.[ch])

To combine your more succinct style with my previous patch, its the link
between the .o's and the .h's thats missing.

$(XDIFF_OBJS): $(wildcard xdiff/*.h)

-apw

What's in git.git

[Junio C Hamano]

* The 'maint' branch is now for post 1.4.3 fixes.  It currently
  contains these:

   Nguyễn Thái Ngọc Duy (2):
      Reject hexstring longer than 40-bytes in get_short_sha1()
      Add revspec documentation for ':path', ':[0-3]:path' and git-describe

   Nicolas Pitre (1):
      reduce delta head inflated size


* The 'master' branch has produced 1.4.3 release today.  I've
  merged the 'maint' fixes and the first wave of what have been
  cooking in "next".

   Andy Whitcroft (1):
      add proper dependancies on the xdiff source

   Johannes Schindelin (1):
      Turn on recursive with --summary

   Junio C Hamano (7):
      grep --all-match
      teach revision walker about --all-match.
      git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 1)
      git-send-email: do not drop custom headers the user prepared
      git-send-email: real name with period need to be dq-quoted on From: line
      Make git-send-email detect mbox-style patches more readily
      diff --numstat

   Markus Amsler (1):
      git-imap-send: Strip smtp From_ header from imap message.

   Martin Waitz (2):
      gitweb: start to generate PATH_INFO URLs.
      gitweb: warn if feature cannot be overridden.

   Matthew Wilcox (1):
      Add --dry-run option to git-send-email

   Nguyễn Thái Ngọc Duy (2):
      Reject hexstring longer than 40-bytes in get_short_sha1()
      Add revspec documentation for ':path', ':[0-3]:path' and git-describe

   Nicolas Pitre (1):
      reduce delta head inflated size

   Petr Baudis (3):
      gitweb: Document features better
      gitweb: Fix search form when PATH_INFO is enabled
      bisect reset: Leave the tree in usable state if git-checkout failed

   Rene Scharfe (2):
      git-archive --format=zip: use default version ID
      git-archive --format=zip: add symlink support

   Robert Shearman (2):
      git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
      git-rebase: Add a -v option to show a diffstat of the changes upstream at the start of a rebase.

   Santi Béjar (2):
      merge and resolve: Output short hashes and .. in "Updating ..."
      fetch: Misc output cleanup

   Sasha Khapyorsky (1):
      git-svnimport.perl: copying directory from original SVN place


* The 'next' branch, in addition, has these.  Roughly speaking,
  there are two and half big topics:

  (1) Nico's delta-base-offset encoding;

  (2) Linus's packed-refs and related changes;

  (3) my blame --porcelain and its use in gitweb;

  When the dust settles after the first wave I pushed out
  tonight, I'd merge delta-base-offset stuff as the second wave,
  and then hopefully packed-refs stuff after that.  I suspect
  there still remains breakage around ref-log I need to fix in
  the latter topic.

   Alan Chandler (1):
      Gitweb - provide site headers and footers

   Andy Whitcroft (2):
      cvsimport: move over to using git-for-each-ref to read refs.
      git-for-each-ref: improve the documentation on scripting modes

   Christian Couder (12):
      Add [-s|--hash] option to Linus' show-ref.
      Use Linus' show ref in "git-branch.sh".
      Document git-show-ref [-s|--hash] option.
      Fix show-ref usage for --dereference.
      Add pack-refs and show-ref test cases.
      When creating branch c/d check that branch c does not already exists.
      Uncomment test case: git branch c/d should barf if branch c exists.
      Fix a remove_empty_dir_recursive problem.
      Clean up "git-branch.sh" and add remove recursive dir test cases.
      Use git-update-ref to delete a tag instead of rm()ing the ref file.
      Check that a tag exists using show-ref instead of looking for the ref file.
      Do not create tag leading directories since git update-ref does it.

   Dennis Stosberg (2):
      lock_ref_sha1_basic does not remove empty directories on BSD
      Remove bashism from t3210-pack-refs.sh

   Jeff King (3):
      wt-status: use simplified resolve_ref to find current branch
      gitignore: git-pack-refs is a generated file.
      gitignore: git-show-ref is a generated file.

   Johannes Schindelin (2):
      Fix git-update-index --again
      show-branch: mark active branch with a '*' again

   Jonas Fonseca (1):
      Add man page for git-show-ref

   Junio C Hamano (48):
      upload-pack: stop the other side when they have more roots than we do.
      Add git-for-each-ref: helper for language bindings
      Fix t1400-update-ref test minimally
      fsck-objects: adjust to resolve_ref() clean-up.
      symbolit-ref: fix resolve_ref conversion.
      Add callback data to for_each_ref() family.
      Tell between packed, unpacked and symbolic refs.
      pack-refs: do not pack symbolic refs.
      git-pack-refs --prune
      pack-refs: fix git_path() usage.
      lock_ref_sha1_basic: remove unused parameter "plen".
      Clean-up lock-ref implementation
      update-ref: -d flag and ref creation safety.
      update a few Porcelain-ish for ref lock safety.
      Teach receive-pack about ref-log
      receive-pack: call setup_ident before git_config
      ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
      refs: minor restructuring of cached refs data.
      lock_ref_sha1(): do not sometimes error() and sometimes die().
      lock_ref_sha1(): check D/F conflict with packed ref when creating.
      delete_ref(): delete packed ref
      git-branch: remove D/F check done by hand.
      show-ref --hash=len, --abbrev=len, and --abbrev
      git-fetch: adjust to packed-refs.
      Fix refs.c;:repack_without_ref() clean-up path
      gitweb: make leftmost column of blame less cluttered.
      git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
      pack-refs: use lockfile as everybody else does.
      gitweb: prepare for repositories with packed refs.
      Revert 954a6183756a073723a7c9fd8d2feb13132876b0
      pack-refs: call fflush before fsync.
      blame.c: whitespace and formatting clean-up.
      git-blame: --show-number (and -n)
      git-blame: --show-name (and -f)
      blame.c: move code to output metainfo into a separate function.
      ref-log: allow ref@{count} syntax.
      git-blame --porcelain
      gitweb: use blame --porcelain
      core.logallrefupdates create new log file only for branch heads.
      git-pack-refs --all
      core.logallrefupdates thinko-fix
      pack-objects: document --delta-base-offset option
      blame: Document and add help text for -f, -n, and -p
      gitweb: spell "blame --porcelain" with -p
      git-repack: repo.usedeltabaseoffset
      pack-objects: use of version 3 delta is now optional.
      gitweb: use for-each-ref to show the latest activity across branches
      Revert "pack-objects: use of version 3 delta is now optional."

   Linus Torvalds (6):
      Add "git show-ref" builtin command
      Teach "git checkout" to use git-show-ref
      Start handling references internally as a sorted in-memory list
      Add support for negative refs
      Make ref resolution saner
      Enable the packed refs file format

   Luben Tuikov (4):
      gitweb: blame: print commit-8 on the leading row of a commit-block
      gitweb: blame: Mouse-over commit-8 shows author and date
      gitweb: blame porcelain: lineno and orig lineno swapped
      git-revert with conflicts to behave as git-merge with conflicts

   Nicolas Pitre (9):
      introduce delta objects with offset to base
      teach git-unpack-objects about deltas with offset to base
      teach git-index-pack about deltas with offset to base
      make git-pack-objects able to create deltas with offset to base
      make pack data reuse compatible with both delta types
      let the GIT native protocol use offsets to delta base when possible
      zap a debug remnant
      allow delta data reuse even if base object is a preferred base
      index-pack: compare only the first 20-bytes of the key.

   Petr Baudis (2):
      Fix broken sha1 locking
      Fix buggy ref recording

   Ryan Anderson (1):
      Remove git-annotate.perl and create a builtin-alias for git-blame


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

   Junio C Hamano (18):
      git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
      para-walk: walk n trees, index and working tree in parallel
      para walk wip
      merge: loosen overcautious "working file will be lost" check.
      git-pickaxe: blame rewritten.
      git-pickaxe: minimally use revision machinery.
      git-pickaxe: fix output for more than one paths from the same commit.
      git-pickaxe: fix "bottom" commit handling.
      git-pickaxe: allow using non -u0 diff internally.
      git-pickaxe: use linked list of blame entries.
      git-pickaxe: collapse trivial blame entry.
      git-pickaxe: blame line movements within a file.
      git-pickaxe: blame cut-and-pasted lines.
      git-pickaxe: -M, -C, and -C -C
      git-pickaxe: optimize nth_line()
      git-pickaxe: make -C (copy from other file) take immediate blame.
      git-pickaxe: document -M, -C, and -C -C
      git-pickaxe: "--not A B -- path" is the same as "HEAD --not A B -- path"

   Petr Baudis (1):
      gitweb: Show project README if available

What's in git.git

[Junio C Hamano]

* The 'maint' branch has spawned 1.4.3.2 tonight.

* The 'master' branch has these since the last announcement.  In
  addition to all fixes in 1.4.3.2, a major change is that it
  contains Nico's delta-base-offset series that has been cooking
  in "next" for quite some time.

   Alexandre Julliard (1):
      prune-packed: Fix uninitialized variable.

   Dmitry V. Levin (1):
      git-clone: define die() and use it.

   Eric Wong (1):
      git-send-email: do not pass custom Date: header

   J. Bruce Fields (1):
      Make prune also run prune-packed

   Jakub Narebski (4):
      gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
      gitweb: Do not esc_html $basedir argument to git_print_tree_entry
      gitweb: Improve git_print_page_path
      gitweb: Add '..' (up directory) to tree view if applicable

   Jim Meyering (3):
      Don't use $author_name undefined when $from contains no /\s</.
      git-clone: honor --quiet
      xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header.

   Junio C Hamano (5):
      pack-objects: document --delta-base-offset option
      git-repack: repo.usedeltabaseoffset
      pager: default to LESS=FRS
      pager: default to LESS=FRSX not LESS=FRS
      daemon: do not die on older clients.

   Karl Hasselström (2):
      git-vc: better installation instructions
      ignore-errors requires cl

   Lars Hjemli (2):
      Fix typo in show-index.c
      Fix usagestring for git-branch

   Linus Torvalds (1):
      git-apply: prepare for upcoming GNU diff -u format change.

   Nicolas Pitre (10):
      introduce delta objects with offset to base
      teach git-unpack-objects about deltas with offset to base
      teach git-index-pack about deltas with offset to base
      make git-pack-objects able to create deltas with offset to base
      make pack data reuse compatible with both delta types
      let the GIT native protocol use offsets to delta base when possible
      zap a debug remnant
      allow delta data reuse even if base object is a preferred base
      index-pack: compare only the first 20-bytes of the key.
      add the capability for index-pack to read from a stream

   Petr Baudis (1):
      gitweb: Fix setting $/ in parse_commit()

   Rene Scharfe (1):
      git-merge: show usage if run without arguments

   Santi Béjar (1):
      Documentation for the [remote] config

   Shawn Pearce (1):
      Use column indexes in git-cvsserver where necessary.


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

  - Linus's packed-refs and related changes are supposed to
    graduate to "master" when the dust settles from the
    tonight's update.  I think it is pretty much ready.

  - git-blame --porcelain should be ready to get pushed out, but
    it's not that urgent.

  - Superseding git-annotate by git-blame could be merged
    anytime.

  - We have accumulated some gitweb changes in "next".  Some
    depend on the packed-refs and related work, and some other
    depend on blame --porcelain.

  - An early part of my git-pickaxe is in "next", but more
    interesting bits are still cooking in "pu".

   Alan Chandler (1):
      Gitweb - provide site headers and footers

   Andy Whitcroft (2):
      cvsimport: move over to using git-for-each-ref to read refs.
      git-for-each-ref: improve the documentation on scripting modes

   Christian Couder (12):
      Add [-s|--hash] option to Linus' show-ref.
      Use Linus' show ref in "git-branch.sh".
      Document git-show-ref [-s|--hash] option.
      Fix show-ref usage for --dereference.
      Add pack-refs and show-ref test cases.
      When creating branch c/d check that branch c does not already exists.
      Uncomment test case: git branch c/d should barf if branch c exists.
      Fix a remove_empty_dir_recursive problem.
      Clean up "git-branch.sh" and add remove recursive dir test cases.
      Use git-update-ref to delete a tag instead of rm()ing the ref file.
      Check that a tag exists using show-ref instead of looking for the ref file.
      Do not create tag leading directories since git update-ref does it.

   Dennis Stosberg (2):
      lock_ref_sha1_basic does not remove empty directories on BSD
      Remove bashism from t3210-pack-refs.sh

   Jeff King (3):
      wt-status: use simplified resolve_ref to find current branch
      gitignore: git-pack-refs is a generated file.
      gitignore: git-show-ref is a generated file.

   Johannes Schindelin (2):
      Fix git-update-index --again
      show-branch: mark active branch with a '*' again

   Jonas Fonseca (1):
      Add man page for git-show-ref

   Junio C Hamano (55):
      upload-pack: stop the other side when they have more roots than we do.
      Add git-for-each-ref: helper for language bindings
      Fix t1400-update-ref test minimally
      fsck-objects: adjust to resolve_ref() clean-up.
      symbolit-ref: fix resolve_ref conversion.
      Add callback data to for_each_ref() family.
      Tell between packed, unpacked and symbolic refs.
      pack-refs: do not pack symbolic refs.
      git-pack-refs --prune
      pack-refs: fix git_path() usage.
      lock_ref_sha1_basic: remove unused parameter "plen".
      Clean-up lock-ref implementation
      update-ref: -d flag and ref creation safety.
      update a few Porcelain-ish for ref lock safety.
      Teach receive-pack about ref-log
      receive-pack: call setup_ident before git_config
      ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
      refs: minor restructuring of cached refs data.
      lock_ref_sha1(): do not sometimes error() and sometimes die().
      lock_ref_sha1(): check D/F conflict with packed ref when creating.
      delete_ref(): delete packed ref
      git-branch: remove D/F check done by hand.
      show-ref --hash=len, --abbrev=len, and --abbrev
      git-fetch: adjust to packed-refs.
      Fix refs.c;:repack_without_ref() clean-up path
      gitweb: make leftmost column of blame less cluttered.
      git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
      pack-refs: use lockfile as everybody else does.
      gitweb: prepare for repositories with packed refs.
      Revert 954a6183756a073723a7c9fd8d2feb13132876b0
      pack-refs: call fflush before fsync.
      blame.c: whitespace and formatting clean-up.
      git-blame: --show-number (and -n)
      git-blame: --show-name (and -f)
      blame.c: move code to output metainfo into a separate function.
      ref-log: allow ref@{count} syntax.
      git-blame --porcelain
      gitweb: use blame --porcelain
      core.logallrefupdates create new log file only for branch heads.
      git-pack-refs --all
      core.logallrefupdates thinko-fix
      blame: Document and add help text for -f, -n, and -p
      gitweb: spell "blame --porcelain" with -p
      pack-objects: use of version 3 delta is now optional.
      gitweb: use for-each-ref to show the latest activity across branches
      Revert "pack-objects: use of version 3 delta is now optional."
      ref-log: fix D/F conflict coming from deleted refs.
      git-pickaxe: blame rewritten.
      git-pickaxe -M: blame line movements within a file.
      git-pickaxe -C: blame cut-and-pasted lines.
      git-pickaxe: pagenate output by default.
      git-pickaxe: fix nth_line()
      git-pickaxe: improve "best match" heuristics
      git-pickaxe: introduce heuristics to avoid "trivial" chunks
      sha1_name.c: avoid compilation warnings.

   Linus Torvalds (6):
      Add "git show-ref" builtin command
      Teach "git checkout" to use git-show-ref
      Start handling references internally as a sorted in-memory list
      Add support for negative refs
      Make ref resolution saner
      Enable the packed refs file format

   Luben Tuikov (4):
      gitweb: blame: print commit-8 on the leading row of a commit-block
      gitweb: blame: Mouse-over commit-8 shows author and date
      gitweb: blame porcelain: lineno and orig lineno swapped
      git-revert with conflicts to behave as git-merge with conflicts

   Petr Baudis (6):
      Fix broken sha1 locking
      Fix buggy ref recording
      gitweb: Restore object-named links in item lists
      gitweb: Make search type a popup menu
      gitweb: Do not automatically append " git" to custom site name
      gitweb: Show project's README.html if available

   Rene Scharfe (1):
      Built-in cherry

   Ryan Anderson (1):
      Remove git-annotate.perl and create a builtin-alias for git-blame


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

   Junio C Hamano (11):
      git-pickaxe: do not keep commit buffer.
      git-pickaxe: do not confuse two origins that are the same.
      git-pickaxe: get rid of wasteful find_origin().
      git-pickaxe: swap comparison loop used for -C
      merge: loosen overcautious "working file will be lost" check.
      rev-list --left-right
      para-walk: walk n trees, index and working tree in parallel
      merge-recursive: use abbreviated commit object name.
      merge-recursive: make a few functions static.
      git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
      t3200: git-branch testsuite update

   Lars Hjemli (1):
      Make git-branch a builtin

   Petr Baudis (1):
      gitweb: Support for 'forks'

What's in git.git

[Junio C Hamano]

* The 'maint' branch has produced 1.4.3.3 and has these fixes
  since the last announcement (some of them are post 1.4.3.3).

   Christian Couder (1):
      Remove --syslog in git-daemon inetd documentation examples.

   Eric Wong (1):
      git-svn: fix symlink-to-file changes when using command-line svn 1.4.0

   Gerrit Pape (1):
      Set $HOME for selftests

   J. Bruce Fields (1):
      Documentation: updates to "Everyday GIT"

   Jakub Narebski (1):
      diff-format.txt: Combined diff format documentation supplement

   Junio C Hamano (6):
      Documentation: note about contrib/.
      RPM package re-classification.
      Refer to git-rev-parse:Specifying Revisions from git.txt
      Update cherry documentation.
      Documentation/SubmittingPatches: 3+1 != 6
      Documentation: clarify refname disambiguation rules.

   Petr Baudis (1):
      xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines

   Tuncer Ayaz (1):
      git-fetch.sh printed protocol fix


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

  I've flushed all the 'gitweb/' changes from "next" and core
  support that some of them needed; notably "for-each-ref" and
  "blame --porcelain" is now in "master".  Oh, and "annotate"
  is now a mere synonym for "blame -c".

   Alan Chandler (1):
      Gitweb - provide site headers and footers

   Andy Whitcroft (2):
      cvsimport: move over to using git-for-each-ref to read refs.
      git-for-each-ref: improve the documentation on scripting modes

   Christian Couder (1):
      Remove --syslog in git-daemon inetd documentation examples.

   Eric Wong (1):
      git-svn: fix symlink-to-file changes when using command-line svn 1.4.0

   Gerrit Pape (1):
      Set $HOME for selftests

   J. Bruce Fields (1):
      Documentation: updates to "Everyday GIT"

   Jakub Narebski (4):
      gitweb: Get rid of git_print_simplified_log
      gitweb: Filter out commit ID from @difftree in git_commit and git_commitdiff
      gitweb: Print commit message without title in commitdiff only if there is any
      diff-format.txt: Combined diff format documentation supplement

   Junio C Hamano (20):
      Add git-for-each-ref: helper for language bindings
      gitweb: make leftmost column of blame less cluttered.
      gitweb: prepare for repositories with packed refs.
      Revert 954a6183756a073723a7c9fd8d2feb13132876b0
      blame.c: whitespace and formatting clean-up.
      git-blame: --show-name (and -f)
      git-blame: --show-number (and -n)
      blame.c: move code to output metainfo into a separate function.
      git-blame --porcelain
      gitweb: use blame --porcelain
      blame: Document and add help text for -f, -n, and -p
      gitweb: spell "blame --porcelain" with -p
      gitweb: use for-each-ref to show the latest activity across branches
      Documentation: note about contrib/.
      RPM package re-classification.
      Refer to git-rev-parse:Specifying Revisions from git.txt
      Update cherry documentation.
      Documentation/SubmittingPatches: 3+1 != 6
      Documentation: clarify refname disambiguation rules.
      combine-diff: a few more finishing touches.

   Luben Tuikov (3):
      gitweb: blame: print commit-8 on the leading row of a commit-block
      gitweb: blame: Mouse-over commit-8 shows author and date
      gitweb: blame porcelain: lineno and orig lineno swapped

   Petr Baudis (5):
      gitweb: Restore object-named links in item lists
      gitweb: Make search type a popup menu
      gitweb: Do not automatically append " git" to custom site name
      gitweb: Show project's README.html if available
      xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines

   Ryan Anderson (1):
      Remove git-annotate.perl and create a builtin-alias for git-blame

   Tuncer Ayaz (1):
      git-fetch.sh printed protocol fix


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

  The next series to graduate is Linus's "packed-ref" and
  associated changes, including rewrite of "branch" in C,
  perhaps early next week.

   Christian Couder (12):
      Add [-s|--hash] option to Linus' show-ref.
      Use Linus' show ref in "git-branch.sh".
      Document git-show-ref [-s|--hash] option.
      Fix show-ref usage for --dereference.
      Add pack-refs and show-ref test cases.
      When creating branch c/d check that branch c does not already exists.
      Uncomment test case: git branch c/d should barf if branch c exists.
      Fix a remove_empty_dir_recursive problem.
      Clean up "git-branch.sh" and add remove recursive dir test cases.
      Use git-update-ref to delete a tag instead of rm()ing the ref file.
      Check that a tag exists using show-ref instead of looking for the ref file.
      Do not create tag leading directories since git update-ref does it.

   Dennis Stosberg (2):
      lock_ref_sha1_basic does not remove empty directories on BSD
      Remove bashism from t3210-pack-refs.sh

   Jeff King (3):
      wt-status: use simplified resolve_ref to find current branch
      gitignore: git-pack-refs is a generated file.
      gitignore: git-show-ref is a generated file.

   Johannes Schindelin (2):
      Fix git-update-index --again
      show-branch: mark active branch with a '*' again

   Jonas Fonseca (1):
      Add man page for git-show-ref

   Junio C Hamano (47):
      upload-pack: stop the other side when they have more roots than we do.
      Fix t1400-update-ref test minimally
      fsck-objects: adjust to resolve_ref() clean-up.
      symbolit-ref: fix resolve_ref conversion.
      Add callback data to for_each_ref() family.
      Tell between packed, unpacked and symbolic refs.
      pack-refs: do not pack symbolic refs.
      git-pack-refs --prune
      pack-refs: fix git_path() usage.
      lock_ref_sha1_basic: remove unused parameter "plen".
      Clean-up lock-ref implementation
      update-ref: -d flag and ref creation safety.
      update a few Porcelain-ish for ref lock safety.
      Teach receive-pack about ref-log
      receive-pack: call setup_ident before git_config
      ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
      refs: minor restructuring of cached refs data.
      lock_ref_sha1(): do not sometimes error() and sometimes die().
      lock_ref_sha1(): check D/F conflict with packed ref when creating.
      delete_ref(): delete packed ref
      git-branch: remove D/F check done by hand.
      show-ref --hash=len, --abbrev=len, and --abbrev
      git-fetch: adjust to packed-refs.
      Fix refs.c;:repack_without_ref() clean-up path
      git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
      pack-refs: use lockfile as everybody else does.
      pack-refs: call fflush before fsync.
      ref-log: allow ref@{count} syntax.
      core.logallrefupdates create new log file only for branch heads.
      git-pack-refs --all
      core.logallrefupdates thinko-fix
      pack-objects: use of version 3 delta is now optional.
      Revert "pack-objects: use of version 3 delta is now optional."
      ref-log: fix D/F conflict coming from deleted refs.
      git-pickaxe: blame rewritten.
      git-pickaxe -M: blame line movements within a file.
      git-pickaxe -C: blame cut-and-pasted lines.
      git-pickaxe: pagenate output by default.
      git-pickaxe: fix nth_line()
      git-pickaxe: improve "best match" heuristics
      git-pickaxe: introduce heuristics to avoid "trivial" chunks
      git-pickaxe: do not keep commit buffer.
      git-pickaxe: do not confuse two origins that are the same.
      git-pickaxe: get rid of wasteful find_origin().
      git-pickaxe: swap comparison loop used for -C
      sha1_name.c: avoid compilation warnings.
      t3200: git-branch testsuite update

   Lars Hjemli (1):
      Make git-branch a builtin

   Linus Torvalds (6):
      Add "git show-ref" builtin command
      Teach "git checkout" to use git-show-ref
      Start handling references internally as a sorted in-memory list
      Add support for negative refs
      Make ref resolution saner
      Enable the packed refs file format

   Luben Tuikov (1):
      git-revert with conflicts to behave as git-merge with conflicts

   Nicolas Pitre (1):
      enable index-pack streaming capability

   Petr Baudis (2):
      Fix broken sha1 locking
      Fix buggy ref recording

   Rene Scharfe (1):
      Built-in cherry


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

  We'd still need more work on merge-recursive to fix the
  overcautious "working file will be overwritten by merge" --
  this is really needed for usability.

  The diff/apply change I am holding back is the one that
  appends an extra tab after "---/+++" filename to the diff
  output, when the filename has an embedded SP in it, to make it
  compatible with GNU diff.  Updates to git-apply to understand
  the new output is already in "master" but not in 1.4.3 series,
  and until it propagates to majority of users, this change
  cannot be unleashed, in order to keep people with older git
  who use such a pathname happy.

  I did not hear any comments on the left-right stuff; perhaps
  it is not needed, or it is not useful as its current shape (it
  could be enhanced to say which starting commits each of the
  commit is reachable from, by borrowing much of show-branch
  code).

  I looked at Pasky's "project forks" gitweb code, and while I
  liked it a lot (having a demonstration site repo.or.cz really
  helps), I read on #git log that Pasky himself was having
  doubt, so it is parked in "pu", not in "next".

  Nico's 3-patch index-pack rework is quite nice; unfortunately
  the last one in the series seems to make the test fail so it
  is not included here, and I did not find enough time to see if
  the other two are "next" material.  They are parked in "pu" in
  the meantime.

   Junio C Hamano (7):
      merge: loosen overcautious "working file will be lost" check.
      merge-recursive: use abbreviated commit object name.
      merge-recursive: make a few functions static.
      git-commit: show --summary after successful commit.
      para-walk: walk n trees, index and working tree in parallel
      git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
      rev-list --left-right

   Nicolas Pitre (2):
      make index-pack able to complete thin packs.
      add progress status to index-pack

   Petr Baudis (1):
      gitweb: Support for 'forks'

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

> * The 'master' branch has these since the last announcement.
> 
>   I've flushed all the 'gitweb/' changes from "next" and core
>   support that some of them needed; notably "for-each-ref" and
>   "blame --porcelain" is now in "master".  Oh, and "annotate"
>   is now a mere synonym for "blame -c".
[...]
>    Junio C Hamano (20):
[...]
>       gitweb: prepare for repositories with packed refs.
[...]
>       gitweb: use for-each-ref to show the latest activity across branches

This unfortunately means that I cannot test gitweb based on 'master'
branch using _released_ git core, git version 1.4.3.3, as it doesn't have
git-for-each-ref nor git-show-ref.

BTW. do people often use latest gitweb with older git binaries? Should
we try to wait for core feature to mature to released version before using
it in gitweb? Or perhaps we should add some kind of version checking, and
provide workrounds, e.g. using $ENV{GIT_DIR} if git core doesn't support
--git-dir option, pathlimit filtering using git-rev-list piped to 
git-diff-tree --stdin in git_history if there is no --full-history
option, show always HEAD activity if there is no git-for-each-ref
etc.; well the latest we can do without checking for git core version, just

        if -x qx($GIT --exec-path)/git-for-each-ref

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

>   I did not hear any comments on the left-right stuff; perhaps
>   it is not needed, or it is not useful as its current shape (it
>   could be enhanced to say which starting commits each of the
>   commit is reachable from, by borrowing much of show-branch
>   code).

It looks reasonable, and useful.

>   I looked at Pasky's "project forks" gitweb code, and while I
>   liked it a lot (having a demonstration site repo.or.cz really
>   helps), I read on #git log that Pasky himself was having
>   doubt, so it is parked in "pu", not in "next".

Perhaps that's for the best.

By the way, Pasky, where one can find your changes to gitweb?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>
>>   I've flushed all the 'gitweb/' changes from "next" and core
>>   support that some of them needed; notably "for-each-ref" and
>>   "blame --porcelain" is now in "master".  Oh, and "annotate"
>>   is now a mere synonym for "blame -c".
>>       gitweb: prepare for repositories with packed refs.
>>       gitweb: use for-each-ref to show the latest activity across branches
>
> This unfortunately means that I cannot test gitweb based on 'master'
> branch using _released_ git core, git version 1.4.3.3, as it doesn't have
> git-for-each-ref nor git-show-ref.

As long as "master" version of gitweb goes with "master" version
of the core, I do not see it as a problem.  Otherwise how would
you make any progress?

> ... Should
> we try to wait for core feature to mature to released version before using
> it in gitweb?

That's both insulting and inconsistent.

Insulting in that somehow you seem to feel "master" is lessor
quality than "maint", and inconsistent in that you seem to find
"gitweb" is somehow more special than other scripts we ship as
part of the git.git project sources.

Anyhow, I have done my fair share of git hacking for the week,
so I'll stop venting and go to bed.

Re: What's in git.git

[Petr Baudis]

Dear diary, on Thu, Oct 26, 2006 at 11:12:36AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> This unfortunately means that I cannot test gitweb based on 'master'
> branch using _released_ git core, git version 1.4.3.3, as it doesn't have
> git-for-each-ref nor git-show-ref.
> 
> BTW. do people often use latest gitweb with older git binaries? Should
> we try to wait for core feature to mature to released version before using
> it in gitweb? Or perhaps we should add some kind of version checking, and
> provide workrounds, e.g. using $ENV{GIT_DIR} if git core doesn't support
> --git-dir option, pathlimit filtering using git-rev-list piped to 
> git-diff-tree --stdin in git_history if there is no --full-history
> option, show always HEAD activity if there is no git-for-each-ref
> etc.; well the latest we can do without checking for git core version, just
> 
>         if -x qx($GIT --exec-path)/git-for-each-ref

I can't imagine a situation where you would _want_ to use latest gitweb
but refuse to use older git binaries - can you explain why do you want
to do that?

If you don't want to install the latest master systemwide, that's
reasonable, but you can just keep the latest master for the gitweb
script and/or your personal use.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

Re: What's in git.git

[Jakub Narebski]

Dnia czwartek 26. października 2006 14:08, Petr Baudis napisał:
> Dear diary, on Thu, Oct 26, 2006 at 11:12:36AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> This unfortunately means that I cannot test gitweb based on 'master'
>> branch using _released_ git core, git version 1.4.3.3, as it doesn't have
>> git-for-each-ref nor git-show-ref.
>> 
>> BTW. do people often use latest gitweb with older git binaries? Should
>> we try to wait for core feature to mature to released version before using
>> it in gitweb? Or perhaps we should add some kind of version checking, and
>> provide workrounds, e.g. using $ENV{GIT_DIR} if git core doesn't support
>> --git-dir option, pathlimit filtering using git-rev-list piped to 
>> git-diff-tree --stdin in git_history if there is no --full-history
>> option, show always HEAD activity if there is no git-for-each-ref
>> etc.; well the latest we can do without checking for git core version, just
>> 
>>         if -x qx($GIT --exec-path)/git-for-each-ref
> 
> I can't imagine a situation where you would _want_ to use latest gitweb
> but refuse to use older git binaries - can you explain why do you want
> to do that?

Theoretically? I could have Perl installed, have installed tools Git
requires to use but not have installed tools Git require to compile.
Hence forced to use pre-compiled binaries.
 
But that is not my situation.

> If you don't want to install the latest master systemwide, that's
> reasonable, but you can just keep the latest master for the gitweb
> script and/or your personal use.

Well, I'd use compiled 'master' version of git for gitweb, then...
-- 
Jakub Narebski

Re: What's in git.git

[Petr Baudis]

Dear diary, on Thu, Oct 26, 2006 at 10:47:12AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
>       gitweb: use for-each-ref to show the latest activity across branches

It's a pity that for-each-ref is used only for that, I'd appreciate a
lot if git_get_refs_list() could use it too, for the sake of
repo.or.cz:glibc-cvs.git summary view, which is massive. :-)

>   I looked at Pasky's "project forks" gitweb code, and while I
>   liked it a lot (having a demonstration site repo.or.cz really
>   helps), I read on #git log that Pasky himself was having
>   doubt, so it is parked in "pu", not in "next".

I had doubts in the middle of implementing it, but now I don't - for
summary of why, please see

	http://news.gmane.org/find-root.php?message_id=<20061024173943.GF20017@pasky.or.cz>

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

Re: What's in git.git

[Andy Whitcroft]

Junio C Hamano wrote:

>   I did not hear any comments on the left-right stuff; perhaps
>   it is not needed, or it is not useful as its current shape (it
>   could be enhanced to say which starting commits each of the
>   commit is reachable from, by borrowing much of show-branch
>   code).

That was the stuff which kinda did cherry in rev-list.  It seemed to
produce interesting output, but nothing I couldn't do with cherry.
Still interesting tho.  The sort of thing that if it was in there
someone would find a use for, think lazers.

Re: What's in git.git

[Petr Baudis]

Dear diary, on Thu, Oct 26, 2006 at 11:19:49AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> By the way, Pasky, where one can find your changes to gitweb?

http://repo.or.cz/w/git/repo.git

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

What's in git.git

[Junio C Hamano]

* The 'maint' branch has these fixes since the last announcement.

  We have one semantic fix in "maint".  To the revision traversal
  machinery, --unpacked used to mean that any commit that is in a
  pack is uninteresting and tainted its ancestors also
  uninteresting.  Updated semantics of --unpacked is just an
  output filter -- it traverses ancestry chain as usual, but does
  not show unpacked commits.  This made what "git repack" does
  actually make sense when the repository is partly packed in the
  half-way (the earlier logic worked fine only if all ancestors of
  a packed commit were all packed).

  A few minor "diff --cc" output fixes are also in "maint".  It
  now honours --no-commit-id option and shows function names on
  the @@@ ... @@@ line just like normal diffs do.


   Christian Couder (2):
      Documentation: add upload-archive service to git-daemon.
      Documentation: add git in /etc/services.

   Edgar Toernig (1):
      Use memmove instead of memcpy for overlapping areas

   Jakub Narebski (2):
      diff-format.txt: Correct information about pathnames quoting in
	patch format
      gitweb: Check git base URLs before generating URL from it

   Jan Harkes (1):
      Continue traversal when rev-list --unpacked finds a packed commit.

   Junio C Hamano (7):
      combine-diff: a few more finishing touches.
      combine-diff: fix hunk_comment_line logic.
      combine-diff: honour --no-commit-id
      Surround "#define DEBUG 0" with "#ifndef DEBUG..#endif"
      quote.c: ensure the same quoting across platforms.
      revision traversal: --unpacked does not limit commit list anymore.
      link_temp_to_file: don't leave the path truncated on
	adjust_shared_perm failure

   Nicolas Pitre (1):
      pack-objects doesn't create random pack names

   Rene Scharfe (1):
      git-cherry: document limit and add diagram


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

  Linus's packed-refs work with associated refs handling
  clean-ups are out on "master", but there is one disclaimer.
  Commit walkers cannot fetch from a repository whose refs are
  packed and then pruned yet, so people with public repositories
  that are expected to be fetched via http should not run
  git-pack-refs just yet.  I think it is probably just the
  matter of updating git-fetch.sh to run ls-remote against the
  repository upfront, and use the SHA-1 of wanted branch tip
  instead of the branch tip name when running the low-level
  git-http-fetch.

  git-branch and git-cherry are now built-in.

   Andy Parkins (1):
      Make filenames line up in git-status output

   Christian Couder (14):
      Add [-s|--hash] option to Linus' show-ref.
      Use Linus' show ref in "git-branch.sh".
      Document git-show-ref [-s|--hash] option.
      Fix show-ref usage for --dereference.
      Add pack-refs and show-ref test cases.
      When creating branch c/d check that branch c does not already exists.
      Uncomment test case: git branch c/d should barf if branch c exists.
      Fix a remove_empty_dir_recursive problem.
      Clean up "git-branch.sh" and add remove recursive dir test cases.
      Use git-update-ref to delete a tag instead of rm()ing the ref file.
      Check that a tag exists using show-ref instead of looking for the
	ref file.
      Do not create tag leading directories since git update-ref does it.
      Documentation: add upload-archive service to git-daemon.
      Documentation: add git in /etc/services.

   Dennis Stosberg (3):
      lock_ref_sha1_basic does not remove empty directories on BSD
      Remove bashism from t3210-pack-refs.sh
      Bash completion support for aliases

   Edgar Toernig (2):
      Use memmove instead of memcpy for overlapping areas
      Use memmove instead of memcpy for overlapping areas

   Jakub Narebski (8):
      gitweb: Use --no-commit-id in git_commit and git_commitdiff
      diff-format.txt: Correct information about pathnames quoting in
	patch format
      gitweb: Check git base URLs before generating URL from it
      Documentation: Update information about <format> in git-for-each-ref
      gitweb: Move git_get_last_activity subroutine earlier
      gitweb: Add "next" link to commitdiff view
      gitweb: Secure against commit-ish/tree-ish with the same name as path
      gitweb: Use 's' regexp modifier to secure against filenames with LF

   Jan Harkes (1):
      Continue traversal when rev-list --unpacked finds a packed commit.

   Jeff King (3):
      wt-status: use simplified resolve_ref to find current branch
      gitignore: git-pack-refs is a generated file.
      gitignore: git-show-ref is a generated file.

   Johannes Schindelin (2):
      Fix git-update-index --again
      show-branch: mark active branch with a '*' again

   Jonas Fonseca (1):
      Add man page for git-show-ref

   Junio C Hamano (42):
      Fix t1400-update-ref test minimally
      fsck-objects: adjust to resolve_ref() clean-up.
      symbolit-ref: fix resolve_ref conversion.
      Add callback data to for_each_ref() family.
      Tell between packed, unpacked and symbolic refs.
      pack-refs: do not pack symbolic refs.
      git-pack-refs --prune
      pack-refs: fix git_path() usage.
      lock_ref_sha1_basic: remove unused parameter "plen".
      Clean-up lock-ref implementation
      update-ref: -d flag and ref creation safety.
      update a few Porcelain-ish for ref lock safety.
      Teach receive-pack about ref-log
      receive-pack: call setup_ident before git_config
      ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
      refs: minor restructuring of cached refs data.
      lock_ref_sha1(): do not sometimes error() and sometimes die().
      lock_ref_sha1(): check D/F conflict with packed ref when creating.
      delete_ref(): delete packed ref
      git-branch: remove D/F check done by hand.
      show-ref --hash=len, --abbrev=len, and --abbrev
      git-fetch: adjust to packed-refs.
      Fix refs.c;:repack_without_ref() clean-up path
      git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
      pack-refs: use lockfile as everybody else does.
      pack-refs: call fflush before fsync.
      ref-log: allow ref@{count} syntax.
      core.logallrefupdates create new log file only for branch heads.
      git-pack-refs --all
      core.logallrefupdates thinko-fix
      ref-log: fix D/F conflict coming from deleted refs.
      sha1_name.c: avoid compilation warnings.
      t3200: git-branch testsuite update
      combine-diff: fix hunk_comment_line logic.
      combine-diff: honour --no-commit-id
      tests: merge-recursive is usable without Python
      Documentation: fix git-format-patch mark-up and link it from git.txt
      Surround "#define DEBUG 0" with "#ifndef DEBUG..#endif"
      quote.c: ensure the same quoting across platforms.
      revision traversal: --unpacked does not limit commit list anymore.
      link_temp_to_file: don't leave the path truncated on
	adjust_shared_perm failure
      branch: work in subdirectories.

   Lars Hjemli (2):
      Make git-branch a builtin
      Fix show-ref usagestring

   Linus Torvalds (6):
      Add "git show-ref" builtin command
      Teach "git checkout" to use git-show-ref
      Start handling references internally as a sorted in-memory list
      Add support for negative refs
      Make ref resolution saner
      Enable the packed refs file format

   Luben Tuikov (2):
      git-revert with conflicts to behave as git-merge with conflicts
      gitweb: esc_html() author in blame

   Nicolas Pitre (1):
      pack-objects doesn't create random pack names

   Petr Baudis (3):
      Fix broken sha1 locking
      Fix buggy ref recording
      gitweb: Fix up bogus $stylesheet declarations

   Rene Scharfe (3):
      Built-in cherry
      Make git-cherry handle root trees
      git-cherry: document limit and add diagram

   Robin Rosenberg (2):
      Mention that pull can work locally in the synopsis
      Swap the porcelain and plumbing commands in the git man page

   Sasha Khapyorsky (1):
      git-svnimport: support for partial imports

   Sergey Vlasov (2):
      git-send-email: Document support for local sendmail instead of
	SMTP server
      git-send-email: Read the default SMTP server from the GIT config file

   Shawn Pearce (1):
      Move deny_non_fast_forwards handling completely into receive-pack.


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

  The largest one is "pickaxe"; I think it is ready for wider
  testing if not for production use, and it is a new command so
  it should be relatively safe to push it out anytime on "master".

  Nico did a lot of work on index-pack and with help from Shawn
  pushing many objects without exploding them into loose objects
  at the other end is becoming reality.  The latest part of
  their series is not in "next" nor "pu" yet, though.

  Linus pointed out that when merging a branch based on an older
  codebase that used to have a path into your branch that does
  not have that path tracked anymore triggers a bogus safety
  valve; I've done both merge-resolve and merge-recursive to
  handle this situation but the result needs to be sanity
  checked.  We are _loosening_ safety valve and need to be extra
  cautious not to overloosen it.

   Junio C Hamano (28):
      upload-pack: stop the other side when they have more roots than we do.
      git-pickaxe: blame rewritten.
      git-pickaxe -M: blame line movements within a file.
      git-pickaxe -C: blame cut-and-pasted lines.
      git-pickaxe: pagenate output by default.
      git-pickaxe: fix nth_line()
      git-pickaxe: improve "best match" heuristics
      git-pickaxe: introduce heuristics to avoid "trivial" chunks
      git-pickaxe: do not keep commit buffer.
      git-pickaxe: do not confuse two origins that are the same.
      git-pickaxe: get rid of wasteful find_origin().
      git-pickaxe: swap comparison loop used for -C
      merge: loosen overcautious "working file will be lost" check.
      merge-recursive: use abbreviated commit object name.
      merge-recursive: make a few functions static.
      merge-recursive: adjust to loosened "working file clobbered" check
      t6022: ignoring untracked files by merge-recursive when they do not
	matter
      send-pack --keep: do not explode into loose objects on the receiving end.
      git-pickaxe: WIP to refcount origin structure.
      git-pickaxe: allow -Ln,m as well as -L n,m
      git-pickaxe: refcount origin correctly in find_copy_in_parent()
      git-pickaxe: tighten sanity checks.
      Revert "send-pack --keep: do not explode into loose objects on the
	receiving end."
      git-pickaxe: split find_origin() into find_rename() and find_origin().
      git-pickaxe: cache one already found path per commit.
      Introduce a new revision set operator <rev>^!

   Linus Torvalds (2):
      Allow '-' in config variable names
      git push: add verbose flag and allow overriding of default target
	repository

   Nicolas Pitre (8):
      enable index-pack streaming capability
      make index-pack able to complete thin packs.
      add progress status to index-pack
      mimic unpack-objects when --stdin is used with index-pack
      enhance clone and fetch -k experience
      index-pack: minor fixes to comment and function name
      missing small substitution
      make git-push a bit more verbose

   Petr Baudis (1):
      gitweb: Support for 'forks'

   Shawn Pearce (4):
      Allow short pack names to git-pack-objects --unpacked=.
      Only repack active packs by skipping over kept packs.
      Teach git-index-pack how to keep a pack file.
      Remove unused variable in receive-pack.


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

  Johannes's "shallow" was marked as "pu" material so I've based
  the series on the tip of "next" (which means we cannot
  directly merge that into "next" or "master" without rebasing
  it to "master" first) and parked it in "pu".  I have given
  only a cursory look to it but it looks promising.

  Nico's latest 6-series builds on top of what Shawn has here
  (the first two from Nico are the same), but I haven't gotten
  around to them yet.

   Johannes Schindelin (6):
      upload-pack: no longer call rev-list
      support fetching into a shallow repository
      allow cloning a repository "shallowly"
      allow deepening of a shallow repository
      add tests for shallow stuff
      Build in shortlog

   Junio C Hamano (4):
      rev-list --left-right
      git-diff/git-apply: make diff output a bit friendlier to GNU
	patch (part 2)
      para-walk: walk n trees, index and working tree in parallel
      git-commit: show --summary after successful commit.

   Shawn Pearce (2):
      Allow pack header preprocessing before unpack-objects/index-pack.
      Teach receive-pack how to keep pack files based on object count.

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Wed, 1 Nov 2006, Junio C Hamano wrote:

> * The 'pu' branch, in addition, has these.
> 
>   Johannes's "shallow" was marked as "pu" material so I've based
>   the series on the tip of "next" (which means we cannot
>   directly merge that into "next" or "master" without rebasing
>   it to "master" first) and parked it in "pu".  I have given
>   only a cursory look to it but it looks promising.

Note that I have no use for shallow clones myself, since I really like to 
have the complete history around. It also makes for a nice distributed 
backup solution.

The reasons I did it:

- 'cause I could
- I think it is important for other people (this means you, Jon)
- I suggested lazy clones as an easy way out, but I am now convinced that 
they introduce more problems than they solve. Therefore I wanted to make 
good for the confusion I helped develop.

Since I do not have any use for shallow clones myself, I am waiting for 
people to jump on it, test it, and shout "Hooray" or "Nacknacknack".

Ciao,
Dscho

Re: What's in git.git

[Rene Scharfe]

Junio C Hamano schrieb:
>   git-branch and git-cherry are now built-in.

Yes, but git-cherry.sh still exists in master (but not in next).
Intentionally?

Re: What's in git.git

[Junio C Hamano]

Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

> Junio C Hamano schrieb:
>>   git-branch and git-cherry are now built-in.
>
> Yes, but git-cherry.sh still exists in master (but not in next).
> Intentionally?

Thanks for catching this; it was a mismerge in commit 56532fa1.

What's in git.git

[Junio C Hamano]

Executive Summary.

[maint]

  I might do a 1.4.3.5 with the accumulated stuff, but the
  stablization cycle for v1.4.4 has started tonight, so it may
  not be worth the effort, unless something more pressing comes
  along.

[master]

  Three topics that have been cooking in 'next' have been
  merged, I've tagged the tip as v1.4.4-rc1.

   - Nico and Shawn's keep-pack work;

   - Loosening of bogusly overstrict 'a working tree file will
     be overwritten by the merge' check;

   - git-pickaxe.

[next]

  This now is almost empty, and I'd like to keep it that way
  until v1.4.5 final.  IOW, I'd be happier if people sent in
  only obviously correct fixes to 'master' than seeing the next
  greatest feature ;-).

  By the way, do people mind if I start to rewind and rebase
  'next' after every feature release (i.e. tagged release is
  made after 'master')?  I do not feel a strong need for it, and
  'git log --no-merges master..next' will show emptiness
  eventually, but being able to restart from clean slate after a
  release would be somewhat nice.

[pu]

  Johannes's shallow clone work now should rebase cleanly on top
  of 'master' although I haven't done so yet.  As he said
  himself the series is waiting for people who have needs for
  such a feature to raise hands.

  The part #2 of git-diff/git-apply change has a slight backward
  compatibility issue, and until everybody who is affected is
  upgraded to v1.4.3 (which has already prepared us for this
  change) we cannot push it out to 'master'.  It adjusts the
  diff output header for files with SP in their names to what
  GNU patch accepts.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

   Alex Riesen (1):
      merge-recursive implicitely depends on trust_executable_bit

   Andy Parkins (2):
      Minor grammar fixes for git-diff-index.txt
      git-clone documentation didn't mention --origin as equivalent of -o

   Jakub Narebski (1):
      Documentation: Transplanting branch with git-rebase --onto

   Jeff King (1):
      Fix git-runstatus for repositories containing a file named HEAD

   Johannes Schindelin (1):
      link_temp_to_file: call adjust_shared_perm() only when we created the directory

   Junio C Hamano (2):
      apply: handle "traditional" creation/deletion diff correctly.
      adjust_shared_perm: chmod() only when needed.

   Shawn O. Pearce (3):
      Use ULONG_MAX rather than implicit cast of -1.
      Remove SIMPLE_PROGRAMS and make git-daemon a normal program.
      Remove unsupported C99 style struct initializers in git-archive.

   Tero Roponen (1):
      remove an unneeded test

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

   Alex Riesen (1):
      merge-recursive implicitely depends on trust_executable_bit

   Alexandre Julliard (5):
      pack-refs: Store the full name of the ref even when packing only tags.
      git.el: Added functions for moving to the next/prev unmerged file.
      git.el: Added a function to open the current file in another window.
      git.el: Move point after the log message header when entering log-edit mode.
      git.el: Include MERGE_MSG in the log-edit buffer even when not committing a merge.

   Andy Parkins (3):
      Remove uneccessarily similar printf() from print_ref_list() in builtin-branch
      Minor grammar fixes for git-diff-index.txt
      git-clone documentation didn't mention --origin as equivalent of -o

   Aneesh Kumar K.V (1):
      gitweb: Remove extra "/" in path names for git_get_project_list

   Eric Wong (2):
      git-svn: avoid printing filenames of files we're not tracking
      git-svn: don't die on rebuild when --upgrade is specified

   Jakub Narebski (4):
      gitweb: Use git-for-each-ref to generate list of heads and/or tags
      gitweb: Output also empty patches in "commitdiff" view
      gitweb: Better support for non-CSS aware web browsers
      Documentation: Transplanting branch with git-rebase --onto

   Jeff King (2):
      git-pickaxe: work properly in a subdirectory.
      Fix git-runstatus for repositories containing a file named HEAD

   Johannes Schindelin (1):
      link_temp_to_file: call adjust_shared_perm() only when we created the directory

   Junio C Hamano (40):
      git-pickaxe: blame rewritten.
      git-pickaxe -M: blame line movements within a file.
      git-pickaxe -C: blame cut-and-pasted lines.
      git-pickaxe: pagenate output by default.
      git-pickaxe: fix nth_line()
      git-pickaxe: improve "best match" heuristics
      git-pickaxe: introduce heuristics to avoid "trivial" chunks
      git-pickaxe: do not keep commit buffer.
      git-pickaxe: do not confuse two origins that are the same.
      git-pickaxe: get rid of wasteful find_origin().
      git-pickaxe: swap comparison loop used for -C
      merge: loosen overcautious "working file will be lost" check.
      merge-recursive: use abbreviated commit object name.
      merge-recursive: make a few functions static.
      merge-recursive: adjust to loosened "working file clobbered" check
      t6022: ignoring untracked files by merge-recursive when they do not matter
      send-pack --keep: do not explode into loose objects on the receiving end.
      git-pickaxe: WIP to refcount origin structure.
      git-pickaxe: allow -Ln,m as well as -L n,m
      git-pickaxe: refcount origin correctly in find_copy_in_parent()
      git-pickaxe: tighten sanity checks.
      Revert "send-pack --keep: do not explode into loose objects on the receiving end."
      git-pickaxe: split find_origin() into find_rename() and find_origin().
      git-pickaxe: cache one already found path per commit.
      Introduce a new revision set operator <rev>^!
      for-each-ref: "creator" and "creatordate" fields
      apply: handle "traditional" creation/deletion diff correctly.
      git-pickaxe: rename detection optimization
      git-pickaxe: simplify Octopus merges further
      git-pickaxe: re-scan the blob after making progress with -M
      git-pickaxe: re-scan the blob after making progress with -C
      git-pickaxe: fix origin refcounting
      cherry is built-in, do not ship git-cherry.sh
      git-blame: add internal statistics to count read blobs.
      git-pickaxe: optimize by avoiding repeated read_sha1_file().
      adjust_shared_perm: chmod() only when needed.
      Document git-pack-refs and link it to git(7).
      git-pickaxe: -L /regexp/,/regexp/
      git-pickaxe: allow "-L <something>,+N"
      GIT 1.4.3-rc1

   Linus Torvalds (2):
      Allow '-' in config variable names
      git push: add verbose flag and allow overriding of default target repository

   Nicolas Pitre (14):
      enable index-pack streaming capability
      make index-pack able to complete thin packs.
      add progress status to index-pack
      mimic unpack-objects when --stdin is used with index-pack
      enhance clone and fetch -k experience
      index-pack: minor fixes to comment and function name
      missing small substitution
      make git-push a bit more verbose
      Allow pack header preprocessing before unpack-objects/index-pack.
      git-fetch can use both --thin and --keep with fetch-pack now
      improve fetch-pack's handling of kept packs
      have index-pack create .keep file more carefully
      remove .keep pack lock files when done with refs update
      git-pack-objects progress flag documentation and cleanup

   Petr Baudis (1):
      gitweb: Support for 'forks'

   Sean Estabrooks (1):
      Add --global option to git-repo-config.

   Shawn O. Pearce (11):
      Added completion support for git-branch.exe.
      Added bash completion support for git-reset.
      Use ULONG_MAX rather than implicit cast of -1.
      Remove SIMPLE_PROGRAMS and make git-daemon a normal program.
      Remove unsupported C99 style struct initializers in git-archive.
      Added missing completions for show-branch and merge-base.
      Only load .exe suffix'd completions on Cygwin.
      Bash completion support for remotes in .git/config.
      Take --git-dir into consideration during bash completion.
      Support bash completion on symmetric difference operator.
      Remove more sed invocations from within bash completion.

   Shawn Pearce (5):
      Allow short pack names to git-pack-objects --unpacked=.
      Only repack active packs by skipping over kept packs.
      Teach git-index-pack how to keep a pack file.
      Remove unused variable in receive-pack.
      Teach receive-pack how to keep pack files based on object count.

   Tero Roponen (1):
      remove an unneeded test


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

   Junio C Hamano:
      upload-pack: stop the other side when they have more roots than we do.


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

   Johannes Schindelin (6):
      Build in shortlog
      upload-pack: no longer call rev-list
      support fetching into a shallow repository
      allow cloning a repository "shallowly"
      allow deepening of a shallow repository
      add tests for shallow stuff

   Junio C Hamano (6):
      git-branch -a: show both local and remote tracking branches.
      git-commit: show --summary after successful commit.
      para-walk: walk n trees, index and working tree in parallel
      git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
      rev-list --left-right
      blame and pickaxe: --show-stats for easier optimization work.

Re: What's in git.git

[David Lang]

On Tue, 7 Nov 2006, Junio C Hamano wrote:

> [pu]
>
>  Johannes's shallow clone work now should rebase cleanly on top
>  of 'master' although I haven't done so yet.  As he said
>  himself the series is waiting for people who have needs for
>  such a feature to raise hands.

I haven't been watching this recently, but if this is what I understand it to be 
(the ability to get a partial repository from upstream and work normally from 
there with the result of data-mineing tools sometimes reporting 'that's part of 
the truncated history' if they hit the cutoff) consider my hand raised.

there are a number of cases where I would be interested in following a project 
as it moves forwards, but do not have the need to have the full history (even 
with the good compression that a git pack provides, it's still a significant 
amount of disk space and download time for large projects)

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

>    Jakub Narebski (4):
[...]
>       gitweb: Output also empty patches in "commitdiff" view

I think that this patch is a bit premature. Without "new improved patchset
view" the empty patches are just that: totally empty. It is new header and
especially outputting extended header information which makes outputting
"empty" patches (with no diff) in "commitdiff" view usefull. By "empty"
patches I mean pure type change, pure rename, pure copy and type change and
rename.

The "new improved patchset view" is prepared to send in two stages: updated
filename quoting/unquoting series (two patches: unescape + minimal
esc_path; esc_path with span.cntrl and backslash sequence quoting), and
"new improved patchset view" (three patches originally, two remains: using
"git diff" header and extended git diff headers; output and link also to
patches with empty diff; improved formatting of chunk header).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Jakub Narebski]

Junio C Hamano wrote:

> [master]
> 
>   Three topics that have been cooking in 'next' have been
>   merged, I've tagged the tip as v1.4.4-rc1.

By the way, tag v1.4.4-rc1 has "GIT 1.4.4-rc1" as title, while the commit it
points to, v1.4.4-rc1^{} has "GIT 1.4.3-rc1" as a title.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>
>>    Jakub Narebski (4):
> [...]
>>       gitweb: Output also empty patches in "commitdiff" view
>
> I think that this patch is a bit premature. Without "new improved patchset
> view" the empty patches are just that: totally empty. It is new header and
> especially outputting extended header information which makes outputting
> "empty" patches (with no diff) in "commitdiff" view usefull. By "empty"
> patches I mean pure type change, pure rename, pure copy and type change and
> rename.
>
> The "new improved patchset view" is prepared to send in two stages...

At least this does not break the page even without these two
follow-ups.  If the follow-ups come in time and do not break the
page, they are very welcome post -rc1 fixes to have before the
final release.  On the other hand, even if they don't, it's not
the end of the world ;-).

Re: What's in git.git

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Junio C Hamano wrote:
>
>> [master]
>> 
>>   Three topics that have been cooking in 'next' have been
>>   merged, I've tagged the tip as v1.4.4-rc1.
>
> By the way, tag v1.4.4-rc1 has "GIT 1.4.4-rc1" as title, while the commit it
> points to, v1.4.4-rc1^{} has "GIT 1.4.3-rc1" as a title.

Yeah, sometimes I make typoes.  Not a news X-<.

Re: What's in git.git

[Petr Baudis]

>   By the way, do people mind if I start to rewind and rebase
>   'next' after every feature release (i.e. tagged release is
>   made after 'master')?  I do not feel a strong need for it, and
>   'git log --no-merges master..next' will show emptiness
>   eventually, but being able to restart from clean slate after a
>   release would be somewhat nice.

  It would be annoying for me since I can't mantain a long-term private
branch tracking next then (and I prefer next to master). I don't do that
right now but I've done that shortly in the past and it would be nice to
have that possibility in the future as well.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

Re: What's in git.git

[Junio C Hamano]

Sorry, I made a mistake of pushing out git-pickaxe before making
it take over git-blame.  So I will fix it up by renaming it to
git-blame.

That is, unless there are too many people whose fingers have
already been trained to type "git-pickaxe" from 'next'
experience (you can obviously count me as one of these people).
In which case I will keep git-pickaxe as a backward compatible
synonym just like we still have git-annotate.

It might also make sense to eventually remove the other synonym
git-annotate but that would be a longer term issue and should be
handled separately.

Re: What's in git.git

[Horst H. von Brand]

David Lang <dlang@digitalinsight.com> wrote:
> On Tue, 7 Nov 2006, Junio C Hamano wrote:
> 
> > [pu]
> >
> >  Johannes's shallow clone work now should rebase cleanly on top
> >  of 'master' although I haven't done so yet.  As he said
> >  himself the series is waiting for people who have needs for
> >  such a feature to raise hands.
> 
> I haven't been watching this recently, but if this is what I
> understand it to be (the ability to get a partial repository from
> upstream and work normally from there with the result of data-mineing
> tools sometimes reporting 'that's part of the truncated history' if
> they hit the cutoff) consider my hand raised.

+1
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

Re: What's in git.git

[Junio C Hamano]

"Horst H. von Brand" <vonbrand@laptop13.inf.utfsm.cl> writes:

> David Lang <dlang@digitalinsight.com> wrote:
>> On Tue, 7 Nov 2006, Junio C Hamano wrote:
>> 
>> > [pu]
>> >
>> >  Johannes's shallow clone work now should rebase cleanly on top
>> >  of 'master' although I haven't done so yet.  As he said
>> >  himself the series is waiting for people who have needs for
>> >  such a feature to raise hands.
>> 
>> I haven't been watching this recently, but if this is what I
>> understand it to be (the ability to get a partial repository from
>> upstream and work normally from there with the result of data-mineing
>> tools sometimes reporting 'that's part of the truncated history' if
>> they hit the cutoff) consider my hand raised.
>
> +1

What does that plus one mean?  I do not know where people picked
up this annoying plus or minus one business, but could you all
stop that?

If you are volunteering to help debugging and feeding bugfixes
that is very much welcome and appreciated.

Thanks.

Re: What's in git.git

[Junio C Hamano]

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

> "Horst H. von Brand" <vonbrand@laptop13.inf.utfsm.cl> writes:
>
>>> On Tue, 7 Nov 2006, Junio C Hamano wrote:
>>> 
>>> > [pu]
>>> >
>>> >  Johannes's shallow clone work now should rebase cleanly on top
>>> >  of 'master' although I haven't done so yet.  As he said
>>> >  himself the series is waiting for people who have needs for
>>> >  such a feature to raise hands.
>>
>> +1
>
> What does that plus one mean?  I do not know where people picked
> up this annoying plus or minus one business, but could you all
> stop that?
>
> If you are volunteering to help debugging and feeding bugfixes
> that is very much welcome and appreciated.

Sorry, I sent the message without finishing.  What should have
followed is...

  On the other hand, if you are saying "yes, shallow would fit
  my workflow and would be useful to have, but I do not have
  time nor inclination to help hacking on it", that is also
  fine.

  But "+1" does not help me tell which one you really mean.

> Thanks.

Re: What's in git.git

[Dave Dillow]

On Wed, 2006-11-08 at 18:54 -0800, Junio C Hamano wrote:
> "Horst H. von Brand" <vonbrand@laptop13.inf.utfsm.cl> writes:
> 
> > David Lang <dlang@digitalinsight.com> wrote:
> >> On Tue, 7 Nov 2006, Junio C Hamano wrote:
> >> 
> >> > [pu]
> >> >
> >> >  Johannes's shallow clone work now should rebase cleanly on top
> >> >  of 'master' although I haven't done so yet.  As he said
> >> >  himself the series is waiting for people who have needs for
> >> >  such a feature to raise hands.
> >> 
> >> I haven't been watching this recently, but if this is what I
> >> understand it to be (the ability to get a partial repository from
> >> upstream and work normally from there with the result of data-mineing
> >> tools sometimes reporting 'that's part of the truncated history' if
> >> they hit the cutoff) consider my hand raised.
> >
> > +1
> 
> What does that plus one mean?  I do not know where people picked
> up this annoying plus or minus one business, but could you all
> stop that?

Horst can speak for himself, but I'd wager he's using the Apache voting
conventions:

What's in git.git

[Junio C Hamano]

Execuive summary.

I've tagged the tip of 'master' as v1.4.4-rc2 tonight.  In the
meantime, GIT 1.4.3.5 was cut from the 'maint' branch.

We hopefully can declare the real 1.4.4 soon enough, before the
turkey time.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

   Eric Wong (3):
      git-svn: avoid printing filenames of files we're not tracking
      git-svn: don't die on rebuild when --upgrade is specified
      git-svn: fix dcommit losing changes when out-of-date from svn

   Junio C Hamano (2):
      path-list: fix path-list-insert return value
      git-cvsserver: read from git with -z to get non-ASCII pathnames.

   Petr Baudis (1):
      Nicer error messages in case saving an object to db goes wrong

   Robert Shearman (1):
      git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.


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

   Eric Wong (3):
      git-svn: avoid printing filenames of files we're not tracking
      git-svn: don't die on rebuild when --upgrade is specified
      git-svn: fix dcommit losing changes when out-of-date from svn

   Jakub Narebski (3):
      gitweb: Better git-unquoting and gitweb-quoting of pathnames
      gitweb: Use character or octal escape codes (and add span.cntrl) in esc_path
      gitweb: New improved patchset view

   Junio C Hamano (14):
      gitweb: fix disabling of "forks"
      gitweb: minimally fix "fork" support.
      gitweb: do not give blame link unconditionally in diff-tree view
      git-status: quote LF in its output
      git-pickaxe: retire pickaxe
      gitweb: protect blob and diff output lines from controls.
      gitweb: protect commit messages from controls.
      gitweb: fix unmatched div in commitdiff
      Documentation: move blame examples
      git-annotate: no need to exec blame; it is built-in now.
      git-annotate: fix -S on graft file with comments.
      path-list: fix path-list-insert return value
      git-cvsserver: read from git with -z to get non-ASCII pathnames.
      GIT 1.4.4-rc2

   OGAWA Hirofumi (1):
      gitk: Fix nextfile() and add prevfile()

   Petr Baudis (1):
      Nicer error messages in case saving an object to db goes wrong

   Robert Shearman (1):
      git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.


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

   Junio C Hamano (4):
      upload-pack: stop the other side when they have more roots than we do.
      pack-objects: use of version 3 delta is now optional.
      Revert "pack-objects: use of version 3 delta is now optional."
      adjust_shared_perm: chmod() only when needed.


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

   Alexandre Julliard (1):
      Shallow clone: do not ignore shallowness when following tags

   Jakub Narebski (1):
      gitweb: New improved formatting of chunk header in diff

   Johannes Schindelin (6):
      upload-pack: no longer call rev-list
      support fetching into a shallow repository
      allow cloning a repository "shallowly"
      Build in shortlog
      allow deepening of a shallow repository
      add tests for shallow stuff

   Junio C Hamano (6):
      git-branch -a: show both local and remote tracking branches.
      git-commit: show --summary after successful commit.
      git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
      rev-list --left-right
      blame: --show-stats for easier optimization work.
      gitweb: steal loadavg throttle from kernel.org

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Tue, 7 Nov 2006, David Lang wrote:

> On Tue, 7 Nov 2006, Junio C Hamano wrote:
> 
> > [pu]
> > 
> >  Johannes's shallow clone work now should rebase cleanly on top
> >  of 'master' although I haven't done so yet.  As he said
> >  himself the series is waiting for people who have needs for
> >  such a feature to raise hands.
> 
> I haven't been watching this recently, but if this is what I understand it to
> be (the ability to get a partial repository from upstream and work normally
> from there with the result of data-mineing tools sometimes reporting 'that's
> part of the truncated history' if they hit the cutoff) consider my hand
> raised.

For now, it does not say "part of the truncated history". But yes, shallow 
clones are partial copies of remote repositories, by making some commits 
"shallow", i.e. grafting an empty set of parents onto them (thereby 
pretending that these commits are root commits).

Telling the user that a commit is shallow should not be too hard.

Ciao,
Dscho

What's in git.git

[Junio C Hamano]

Executive Summary

 - 'maint' and 'master' are the same, since we are still in
   "v1.4.4 fix" mood right now.  A maintenance release v1.4.4.1
   should follow soonish.

 - 'next' has a few 'these are obviously the right things to me
   but I want a bit of cheering-up before pushing them out, and
   they can wait until the dust settles after early fixes to
   v1.4.4 anyway' changes.

 - 'pu' has the shallow clone WIP and a half-finished rewrite of
   git branch in C, both by Johannes.  Both needs a bit more
   polishing and confidence building before going into 'next',
   and given the recent discussion of enhancing branch
   management for pulls/pushes, it might be easier to drop the
   latter for now.

   I should also bring Shawn's piecemeal-mmap into 'pu'; I've
   looked at his code and it mostly looked sane.

----------------------------------------------------------------

* The 'maint' branch has these fixes since v1.4.4 release.  The
  'master' is the same as 'maint' right now.

  Alexandre Julliard:
    gitweb: Put back shortlog instead of graphiclog in the project list.

  Jim Meyering:
    Run "git repack -a -d" once more at end, if there's 1MB or more of
    not-packed data.

  Johannes Schindelin:
    Seek back to current filepos when mmap()ing with NO_MMAP

  Junio C Hamano:
    git-checkout: do not allow -f and -m at the same time.
    git-checkout: allow pathspec to recover lost working tree directory
    convert-objects: set _XOPEN_SOURCE to 600

  Linus Torvalds:
    git-pull: allow pulling into an empty repository
    "git fmt-merge-msg" SIGSEGV

  Petr Baudis:
    Fix git-for-each-refs broken for tags
    git-apply: Documentation typo fix
    Documentation: Define symref and update HEAD description

  Rene Scharfe:
    sparse fix: non-ANSI function declaration
    sparse fix: Using plain integer as NULL pointer
    git-apply: slightly clean up bitfield usage
    Document git-runstatus

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

  Junio C Hamano
     upload-pack: stop the other side when they have more roots than we do.
     apply --numstat: mark binary diffstat with - -, not 0 0
     pack-objects: tweak "do not even attempt delta" heuristics


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

   Alexandre Julliard (1):
      Shallow clone: do not ignore shallowness when following tags

   Jakub Narebski (1):
      gitweb: New improved formatting of chunk header in diff

   Johannes Schindelin (6):
      upload-pack: no longer call rev-list
      support fetching into a shallow repository
      allow cloning a repository "shallowly"
      allow deepening of a shallow repository
      add tests for shallow stuff
      Build in shortlog

   Junio C Hamano (11):
      git-branch -a: show both local and remote tracking branches.
      git-commit: show --summary after successful commit.
      para-walk: walk n trees, index and working tree in parallel
      git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
      rev-list --left-right
      blame: --show-stats for easier optimization work.
      gitweb: steal loadavg throttle from kernel.org
      We should make sure that the protocol is still extensible.
      Why does it mean we do not have to register shallow if we have one?
      Why didn't we mark want_obj as ~UNINTERESTING in the old code?
      shallow clone: unparse and reparse an unshallowed commit

Re: What's in git.git

[Junio C Hamano]

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

>  - 'pu' has the shallow clone WIP and a half-finished rewrite of
>    git branch in C, both by Johannes.  Both needs a bit more
>    polishing and confidence building before going into 'next',
>    and given the recent discussion of enhancing branch
>    management for pulls/pushes, it might be easier to drop the
>    latter for now.

OOPS; sorry but the latter half is entirely untrue.  What's
there is half-done git-shortlog.  Scratch everything about
branch management please.

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Sat, 18 Nov 2006, Junio C Hamano wrote:

> Junio C Hamano <junkio@cox.net> writes:
> 
> >  - 'pu' has the shallow clone WIP and a half-finished rewrite of
> >    git branch in C, both by Johannes.  Both needs a bit more
> >    polishing and confidence building before going into 'next',
> >    and given the recent discussion of enhancing branch
> >    management for pulls/pushes, it might be easier to drop the
> >    latter for now.
> 
> OOPS; sorry but the latter half is entirely untrue.  What's
> there is half-done git-shortlog.  Scratch everything about
> branch management please.

IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out 
the built-in mailmap which is totally specific to the Linux kernel 
development.

As for shallow clone support: I am a bit underwhelmed by the enthusiasm 
to test this thing by the people I thought would be most interested. It 
really could be the case that it is not needed at all.

Just for the record, though: AFAICT the shallow stuff is lacking support 
for at least pushing from/into shallow repos and it should avoid making a 
commit shallow unnecessarily. And quite likely there are a few thinkos in 
it, so it would not hurt having more test cases (notably of things I did 
not think of), and some bad-ass testing with huge amounts of commits and 
files which were added/modified identically in different commits.

Ciao,
Dscho

Re: What's in git.git

[Jakub Narebski]

Johannes Schindelin wrote:

> On Sat, 18 Nov 2006, Junio C Hamano wrote:
> 
>> OOPS; sorry but the latter half is entirely untrue.  What's
>> there is half-done git-shortlog.  Scratch everything about
>> branch management please.
> 
> IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out 
> the built-in mailmap which is totally specific to the Linux kernel 
> development.

If I remember correctly besides having built-in mailmap (at least in Perl
version quite easy modificable, and updateable via Inline::Files), it also
have built-in path shortening. And that part IIRC was not solved (although
there was some proposal).

The shallow clone work looks promising...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Sun, 19 Nov 2006, Jakub Narebski wrote:

> Johannes Schindelin wrote:
> 
> > On Sat, 18 Nov 2006, Junio C Hamano wrote:
> > 
> > IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out 
> > the built-in mailmap which is totally specific to the Linux kernel 
> > development.

See the 3 patches I just sent.

> If I remember correctly besides having built-in mailmap (at least in Perl
> version quite easy modificable, and updateable via Inline::Files), it also
> have built-in path shortening. And that part IIRC was not solved (although
> there was some proposal).

I do not understand. What paths are handled by git-shortlog?

Ciao,
Dscho

Re: What's in git.git

[Petr Baudis]

On Sun, Nov 19, 2006 at 04:17:17PM CET, Johannes Schindelin wrote:
> As for shallow clone support: I am a bit underwhelmed by the enthusiasm 
> to test this thing by the people I thought would be most interested. It 
> really could be the case that it is not needed at all.

I was underwhelmed all the same by response to my multifetch work.
Perhaps we need some better mechanism to get feedback from the
downstream users which were main requesters of the $feature (I think
that in both cases people can see how it could be useful generically but
there's not too much immediate enthusiasm for playing with it inside the
community). I think the main user of multifetch was xorg while the
primary user of shallow clones would be Mozilla, right?

It would be great if, when wishing for some large feature, they could
say something like "if this ever gets done, please prod $mailinglist and
we'll give it a stab and get you some feedback" (apparently there's
noone from there monitoring the mailing list consistently, which is
understandable though since it's not a too much low-traffic one).

Alp? (xorg) Jon? (mozilla)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."

Re: What's in git.git

[Jakub Narebski]

Johannes Schindelin wrote:

> I do not understand. What paths are handled by git-shortlog?

I was under (perhaps false) impression that somewhere in git-shortlog 
there is shortening of
  Merge branch 'master' of git://git.kernel.org/pub/scm/git/git
messages, shortening the URL part.

Perhaps this was only other example of hard-coded git-for-Linux-ness.
-- 
Jakub Narebski

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Sun, 19 Nov 2006, Jakub Narebski wrote:

> Johannes Schindelin wrote:
> 
> > I do not understand. What paths are handled by git-shortlog?
> 
> I was under (perhaps false) impression that somewhere in git-shortlog 
> there is shortening of
>   Merge branch 'master' of git://git.kernel.org/pub/scm/git/git
> messages, shortening the URL part.
> 
> Perhaps this was only other example of hard-coded git-for-Linux-ness.

I found it: git-shortlog.perl:28 says

        $desc =~ s#/pub/scm/linux/kernel/git/#/.../#g;

And in builtin-shortlog.c:90 you can read

        const char *dot3 = "/pub/scm/linux/kernel/git/";

and in lines 133--136:

        while ((p = strstr(buffer, dot3)) != NULL) {
                memcpy(p, "...", 3);
                strcpy(p + 2, p + sizeof(dot3) - 1);
        }

So, not only did I forget that git-shortlog has the path shortening, but I 
also forgot that I implemented it in the builtin shortlog, too.

Ciao,
Dscho

What's in git.git

[Junio C Hamano]

The 'maint' and 'master' are at the same commit; a maintenance
release v1.4.4.1 has been cut.

A handful enhancements that have been cooking in 'next' will
start graduating to 'master' shortly; as usual, they won't be
in the future v1.4.4.x maintenance series.

 * gitweb updates.

 * shortlog is now built-in.

 * enhance packed-refs file to optimize "show-ref -d".

 * retire merge-recursive-old.

 * shallow clone.

----------------------------------------------------------------

* The 'next' branch, in addition to what are in 'master', has these.

   Andy Parkins (2):
      Improve git-prune -n output
      Add support to git-branch to show local and remote branches

   Jakub Narebski (7):
      gitweb: Protect against possible warning in git_commitdiff
      gitweb: Buffer diff header to deal with split patches + git_patchset_body refactoring
      gitweb: Default to $hash_base or HEAD for $hash in "commit" and "commitdiff"
      gitweb: New improved formatting of chunk header in diff
      gitweb: Add an option to href() to return full URL
      gitweb: Refactor feed generation, make output prettier, add Atom feed
      gitweb: Finish restoring "blob" links in git_difftree_body

   Johannes Schindelin (5):
      Build in shortlog
      shortlog: do not crash on parsing "[PATCH"
      shortlog: read mailmap from ./.mailmap again
      shortlog: handle email addresses case-insensitively
      shortlog: fix "-n"

   Junio C Hamano (9):
      upload-pack: stop the other side when they have more roots than we do.
      adjust_shared_perm: chmod() only when needed.
      apply --numstat: mark binary diffstat with - -, not 0 0
      pack-objects: tweak "do not even attempt delta" heuristics
      Store peeled refs in packed-refs file.
      remove merge-recursive-old
      git-merge: make it usable as the first class UI
      git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
      Store peeled refs in packed-refs (take 2).

   Nicolas Pitre (1):
      builtin git-shortlog is broken


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

   Alexandre Julliard (1):
      Shallow clone: do not ignore shallowness when following tags

   Johannes Schindelin (5):
      upload-pack: no longer call rev-list
      support fetching into a shallow repository
      allow cloning a repository "shallowly"
      allow deepening of a shallow repository
      add tests for shallow stuff

   Junio C Hamano (10):
      git-commit: show --summary after successful commit.
      para-walk: walk n trees, index and working tree in parallel
      rev-list --left-right
      merge: allow merging into a yet-to-be-born branch.
      blame: --show-stats for easier optimization work.
      gitweb: steal loadavg throttle from kernel.org
      We should make sure that the protocol is still extensible.
      Why does it mean we do not have to register shallow if we have one?
      Why didn't we mark want_obj as ~UNINTERESTING in the old code?
      shallow clone: unparse and reparse an unshallowed commit

What's in git.git

[Junio C Hamano]

Executive Summary
=================

The 'maint' branch still has a handful more post v1.4.4.1
fixes.

Aside from the usual gitweb and git-svn updates, the 'master'
branch has one notable change that everybody should hopefully
welcome.  separate-remote layout is now the default for newly
cloned repositories.  We would be needing documentation updates
and probably some more minor fixes for fallout from this, but I
do not expect anything majorly broken.

Cooking in 'next' are handful topics:

 * "git shortlog bottom..top" can be used instead of a pipeline
   "git log bottom..top | git shortlog".

 * "git merge -m message <commit>" is another natural way to
   perform a local merge, in addition to the traditional
   "git pull . <localbranch>".  The former is more powerful in
   that it can take arbitrary <committish>, not just a ref.

 * The new "--depth $n" parameter to git clone/fetch tries to
   limit the commit ancestry depth to $n.  This still has known
   issues (for example, shallowly cloning the git.git repository
   and then deepening the result with large --depth parameter
   later does not seem to make the resulting repository fully
   connected, and fsck-objects reports corruption), so please
   handle it with care.

 * "git show-ref", especially the "-d" variant, is much more
   efficient when used in a repository with pack-pruned refs.

 * "git fetch" can fetch from a repository with pack-pruned refs
   over dumb protocol transports.

 * "git push $URL '':$ref" can be used to delete an existing ref
   from the remote side.

 * A glob pattern "Pull: refs/heads/*:refs/remotes/origin/*" is
   allowed in the remotes file.  The fetch can be forced by
   prefixing the specification with a '+'.

Currently 'pu' does not have much to speak of.

This update has rather large impact so the kernel list is CC'ed.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

   Andy Parkins (1):
      Increase length of function name buffer

   Eric Wong (3):
      git-svn: error out from dcommit on a parent-less commit
      git-svn: correctly handle revision 0 in SVN repositories
      git-svn: preserve uncommitted changes after dcommit

   René Scharfe (1):
      archive-zip: don't use sizeof(struct ...)


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

   Andy Parkins (3):
      Improve git-prune -n output
      Add support to git-branch to show local and remote branches
      Increase length of function name buffer

   Eric Wong (6):
      git-svn: error out from dcommit on a parent-less commit
      git-svn: correctly handle revision 0 in SVN repositories
      git-svn: preserve uncommitted changes after dcommit
      git-svn: handle authentication without relying on cached tokens on disk
      git-svn: correctly access repos when only given partial read permissions
      git-svn: exit with status 1 for test failures

   Iñaki Arenaza (1):
      git-cvsimport: add support for CVS pserver method HTTP/1.x proxying

   Jakub Narebski (8):
      gitweb: Protect against possible warning in git_commitdiff
      gitweb: Buffer diff header to deal with split patches + git_patchset_body refactoring
      gitweb: Default to $hash_base or HEAD for $hash in "commit" and "commitdiff"
      gitweb: New improved formatting of chunk header in diff
      gitweb: Add an option to href() to return full URL
      gitweb: Refactor feed generation, make output prettier, add Atom feed
      gitweb: Finish restoring "blob" links in git_difftree_body
      gitweb: Replace SPC with &nbsp; also in tag comment

   Junio C Hamano (9):
      upload-pack: stop the other side when they have more roots than we do.
      apply --numstat: mark binary diffstat with - -, not 0 0
      pack-objects: tweak "do not even attempt delta" heuristics
      refs outside refs/{heads,tags} match less strongly.
      Typefix builtin-prune.c::prune_object()
      gitweb: (style) use chomp without parentheses consistently.
      git-clone: stop dumb protocol from copying refs outside heads/ and tags/.
      git-branch -D: make it work even when on a yet-to-be-born branch
      git-fetch: exit with non-zero status when fast-forward check fails

   Lars Hjemli (1):
      Add -v and --abbrev options to git-branch

   Peter Baumann (1):
      config option log.showroot to show the diff of root commits

   Petr Baudis (1):
      Make git-clone --use-separate-remote the default

   René Scharfe (1):
      archive-zip: don't use sizeof(struct ...)


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

   Alexandre Julliard (6):
      Shallow clone: do not ignore shallowness when following tags
      fetch-pack: Properly remove the shallow file when it becomes empty.
      upload-pack: Check for NOT_SHALLOW flag before sending a shallow to the client.
      git-fetch: Reset shallow_depth before auto-following tags.
      get_shallow_commits: Avoid memory leak if a commit has been reached already.
      fetch-pack: Do not fetch tags for shallow clones.

   Jakub Narebski (1):
      gitweb: Do not use esc_html in esc_path

   Johannes Schindelin (10):
      Build in shortlog
      shortlog: do not crash on parsing "[PATCH"
      shortlog: read mailmap from ./.mailmap again
      shortlog: handle email addresses case-insensitively
      shortlog: fix "-n"
      upload-pack: no longer call rev-list
      support fetching into a shallow repository
      allow cloning a repository "shallowly"
      allow deepening of a shallow repository
      add tests for shallow stuff

   Junio C Hamano (19):
      Store peeled refs in packed-refs file.
      remove merge-recursive-old
      git-merge: make it usable as the first class UI
      merge: allow merging into a yet-to-be-born branch.
      git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
      Store peeled refs in packed-refs (take 2).
      git-fetch: reuse ls-remote result.
      git-fetch: fix dumb protocol transport to fetch from pack-pruned ref
      git-fetch: allow glob pattern in refspec
      Allow git push to delete remote ref.
      We should make sure that the protocol is still extensible.
      Why does it mean we do not have to register shallow if we have one?
      Why didn't we mark want_obj as ~UNINTERESTING in the old code?
      shallow clone: unparse and reparse an unshallowed commit
      git-shortlog: fix common repository prefix abbreviation.
      git-shortlog: make common repository prefix configurable with .mailmap
      git-commit: show --summary after successful commit.
      git-fetch: allow forcing glob pattern in refspec
      fetch-pack: do not barf when duplicate re patterns are given

   Nicolas Pitre (1):
      builtin git-shortlog is broken


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

   Junio C Hamano (4):
      para-walk: walk n trees, index and working tree in parallel
      rev-list --left-right
      blame: --show-stats for easier optimization work.
      gitweb: steal loadavg throttle from kernel.org

Re: What's in git.git

[Carl Worth]

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

On Sat, 25 Nov 2006 02:12:38 -0800, Junio C Hamano wrote:
>  * The new "--depth $n" parameter to git clone/fetch tries to
>    limit the commit ancestry depth to $n.

I'm very excited to see the shallow clone stuff coming online. Thanks
to everybody that is working on that!

Has though been given to make the depth selection consistent with
other limiting options for rev-parse and rev-list? For example, I'd
like to be able to use --since to get a shallow clone, (so should
--depth instead be --max-count?, and can we re-use some existing
machinery here?).

>    Petr Baudis (1):
>       Make git-clone --use-separate-remote the default
...
>    Junio C Hamano (19):
>       git-merge: make it usable as the first class UI

Also very exciting. Please do keep up the user-interface improvements,
everybody.

-Carl

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

Re: What's in git.git

[Johannes Schindelin]

Hi,

On Tue, 28 Nov 2006, Carl Worth wrote:

> On Sat, 25 Nov 2006 02:12:38 -0800, Junio C Hamano wrote:
> >  * The new "--depth $n" parameter to git clone/fetch tries to
> >    limit the commit ancestry depth to $n.
> [...]
> Has though been given to make the depth selection consistent with
> other limiting options for rev-parse and rev-list? For example, I'd
> like to be able to use --since to get a shallow clone, (so should
> --depth instead be --max-count?, and can we re-use some existing
> machinery here?).

I briefly considered that, but decided against it, for two reasons: 1) it 
puts the burden of calculation on the server, and 2) I was not at all sure 
if the whole shallow stuff would be useful to begin with (and therefore 
avoided complicated stuff as much as possible).

> >    Petr Baudis (1):
> >       Make git-clone --use-separate-remote the default
> ...
> >    Junio C Hamano (19):
> >       git-merge: make it usable as the first class UI
> 
> Also very exciting. Please do keep up the user-interface improvements, 
> everybody.

I concur.

Ciao,
Dscho

What's in git.git

[Junio C Hamano]

Executive summary:

 * (maint) hopefully the last maintenance release for v1.5.2
   codebase, v1.5.2.4, is out.

 * (master) v1.5.3 is nicely progressing and we have v1.5.3-rc1
   out, but it has a serious last minute glitch in pack-objects,
   so please do not use "git-gc", or "git-repack" from vanilla
   v1.5.3-rc1.

   v1.5.3-rc1-1-g7d7baa5 or later should be Ok.

 * (next/pu) No topics are cooking in 'next' right now, although
   I might apply a few series I did not pick up from the list in
   the past few days, just to keep them from getting lost.

As usual, v1.5.3-rc1 means:

 * I personally will be using 'master' version for my work until
   v1.5.3 final (I usually run 'next', and switch to 'master'
   after -rc0); I ask contributors to do the same to shake out
   the last minute bugs from 'master'.

 * No more features and large code churning on 'master' until
   v1.5.3 final.

 * Bugfixes and documenation updates are always welcomed, but
   even more so than usual until v1.5.3 final.

I'll send out a draft release notes for v1.5.3 in a separate
message.

----------------------------------------------------------------

* The 'maint' branch spawned 1.5.2.4 with accumulated fixes.
  Most notably, we are in sync with git-gui 0.7.5.

* The 'master' branch has these since the last announcement; 
  we are at v1.5.3-rc1 plus a few fixes.

Adam Roben (1):
  format-patch: Add format.subjectprefix config option

Alecs King (1):
  fix remote.origin.url in tutorial.txt

Alex Riesen (4):
  Handle missing prefix for "Subject:" as if no prefix given
  Handle format.subjectprefix for every command which accepts
      --pretty
  Fix t5516 to create test repo without hooks
  Add -v|--verbose to git remote to show remote url

Andrew Ruder (2):
  Remove USE_PAGER from git-pickaxe and git-annotate
  Add urls.txt to git-clone man page

Brian Downing (10):
  pack-objects: Prefer shallower deltas if the size is equal
  gitk: Fix for tree view ending in nested directories
  Pack information tool
  Correct shebang line for contrib/stats/packinfo.pl
  Don't try to delta if target is much smaller than source
  Support fetching the memory usage of a delta index
  Add functions for parsing integers with size suffixes
  Add pack-objects window memory usage limit
  Add --window-memory option to git-repack
  Add documentation for --window-memory, pack.windowMemory

Brian Gernhardt (1):
  Add core.pager config variable.

CJ van den Berg (1):
  git-submodule: Fix two instances of the same typo

Carlos Rica (5):
  t7004: Skip tests for signed tags in an old version of gpg.
  t0030: Remove repeated instructions and add missing &&
  t0030: Add tests with consecutive text lines and others with spaces
      added.
  t7004: Add tests for the git tag -n option.
  Function stripspace now gets a buffer instead file descriptors.

Daniel Barkalow (2):
  Add allocation and freeing functions for struct refs
  Some cosmetic changes to remote library

David Kastrup (1):
  Add missing functions to contrib/emacs/vc-git.el

Emil Medve (1):
  git-submodule: Instead of using only annotated tags, use any tags.

Eric Wong (2):
  git-svn: allow dcommit to retain local merge information
  git-svn: fix blocking with svn:// servers after do_switch

Frank Lichtenheld (1):
  cvsserver: always initialize state in argsplit()

Gerrit Pape (1):
  git-commit: don't add multiple Signed-off-by: from the same
      identity

Jakub Narebski (3):
  Update git-merge documentation.
  Document long options '--message=<msg>' and '--no-commit'
  Document git commit --untracked-files and --verbose

James Bowes (1):
  stash: allow running from a subdirectory

Jeff King (6):
  git-stash: fix "no arguments" case in documentation
  git-stash: fix "can't shift that many" with no arguments
  git-stash: don't complain when listing in a repo with no stash
  Documentation: quote {non-attributes} for asciidoc
  Documentation: quote {non-attributes} for asciidoc
  Documentation: minor cleanups to branch/checkout wording

Jeffrey C. Ollie (2):
  Add an option to quiet git-init.
  Quiet the output from git-init when cloning, if requested.

Johannes Schindelin (28):
  Move the pick_author code to git-sh-setup
  Teach rebase an interactive mode
  rebase -i: several cleanups
  rebase -i: provide reasonable reflog for the rebased branch
  Teach rebase -i about --preserve-merges
  Make '!' aliases more useful
  git-fsck: add --lost-found option
  Document git-filter-branch
  Add diff-option --ext-diff
  filter-branch: add a test for the commit removal example
  filter-branch: make output nicer
  filter-branch: a few more touch ups to the man page
  filter-branch documentation: clarify which filters are eval'ed
  filter-branch: fail gracefully when a filter fails
  Future-proof source for changes in xdemitconf_t
  Teach git-stash to "apply --index"
  Enable "git rerere" by the config variable rerere.enabled
  git-branch: default to --track
  branch.autosetupmerge: allow boolean values, or "all"
  rebase -i: handle --continue more like non-interactive rebase
  rebase -i: actually show the diffstat when being verbose
  rebase -i: remember the settings of -v, -s and -p when interrupted
  rebase -i: put a nice warning into the todo list
  rerere: record resolution even if file is not in merge base
  Fix core.sharedRepository = 2
  Fix --cherry-pick with given paths
  Add for_each_remote() function, and extend remote_find_tracking()
  branch --track: code cleanup and saner handling of local branches

Johannes Sixt (4):
  Test 'git add' for unmerged entries when core.symlinks=false.
  filter-branch: Avoid an error message in the map function.
  filter-branch documentation: some more touch-ups.
  Allow rebase to run if upstream is completely merged

Jonas Fonseca (1):
  fsck --lost-found writes to subdirectories in .git/lost-found/

Junio C Hamano (30):
  diffcore_count_changes: pass diffcore_filespec
  diffcore_filespec: add is_binary
  diffcore-delta.c: update the comment on the algorithm.
  diffcore-delta.c: Ignore CR in CRLF for text files
  git-stash: require "save" to be explicit and update documentation
  Update public documentation links for 1.5.2.3
  "git-push $URL" without refspecs pushes only matching branches
  Rewrite "git-frotz" to "git frotz"
  git-stash: make "save" the default action again.
  Mark disused commit walkers officially deprecated.
  Update draft Release Notes for 1.5.3
  Update reflog message created for stashes
  Do not check if getcwd() result begins with a slash.
  Fix git-stash(1) markup.
  git-stash: allow more descriptive reminder message when saving
  Introduce diff_filespec_is_binary()
  Per-path attribute based hunk header selection.
  Fix configuration syntax to specify customized hunk header
      patterns.
  diff: honor binariness specified in attributes
  gitweb: make repeated calls to git_get_project_owner() bearable
  diff.c: make built-in hunk header pattern a separate table
  git-gui: use "blame -w -C -C" for "where did it come from,
      originally?"
  git-stash: try reusing cached stat info as much as possible
  Fix merge-one-file for our-side-added/our-side-removed cases
  Document custom hunk header selection
  revision.c: remove duplicated parents after history simplification
  Revert 88494423 (removal of duplicate parents in the output
      codepath)
  Re-code builtin-branch.c in UTF-8
  Update list of older git docs
  GIT v1.5.3-rc1

Lars Hjemli (1):
  git-submodule(1): update description and key names

Linus Torvalds (1):
  Start deprecating "git-command" in favor of "git command"

Marcus Fritzsch (1):
  Fixed a formulation mistake in Documentation/user-manual.txt

Matt Kraai (3):
  Prefer EMAIL to username@hostname.
  Change "added.moved or removed" to "added, moved or removed" in
  Add [verse] to the SYNOPSIS section of git-submodule.txt.

Matt McCutchen (3):
  gitweb: make search form generate pathinfo-style URLs
  gitweb: make "No commits" in project list gray, not bold green
  Makefile: rebuild git.o on version change, clean up git$X flags

Matthias Lederhofer (5):
  ignore git-rebase--interactive
  getenv/setenv: use constants if available
  git-init: set core.worktree if GIT_WORK_TREE is specified
  git-clone: split up long &&-command-chain and use a function for
      cleanup
  make git-clone GIT_WORK_TREE aware

Michael Hendricks (2):
  git-send-email: allow an email alias for --from
  gitweb: configurable width for the projects list Description column

Miklos Vajna (2):
  gitweb: prefer git_get_project_owner() over get_file_owner()
  gitweb: new cgi parameter: opt

Nanako Shiraishi (2):
  Add git-stash script
  Document git-stash

Nicolas Pitre (4):
  apply delta depth bias to already deltified objects
  script to display a distribution of longest common hash prefixes
  reduce git-pack-objects memory usage a little more
  Pack-objects: properly initialize the depth value

Paul Mackerras (6):
  gitk: Fix the find and highlight functions
  gitk: Fix bug in the anc_or_desc routine
  gitk: Remove the unused stopfindproc function
  gitk: Fix bug causing "can't read commitrow(0,n)" error
  gitk: Use git log and add support for --left-right
  gitk: Improve handling of -- and ambiguous arguments

René Scharfe (1):
  diff-lib.c: don't strdup twice

Sean Estabrooks (1):
  Alter git-checkout reflog message to include "from" branch

Shawn O. Pearce (36):
  git-gui: Start blame windows as tall as possible
  git-gui: Correct resizing of remote branch delete dialog
  git-gui: Honor rerere.enabled configuration option
  git-gui: New Git version check support routine
  git-gui: Teach class system to support [$this cmd] syntax
  git-gui: Abstract the revision picker into a mega widget
  git-gui: Refactor the delete branch dialog to use class system
  git-gui: Optimize for newstyle refs/remotes layout
  git-gui: Maintain remote and source ref for tracking branches
  git-gui: Allow users to match remote branch names locally
  git-gui: Fast-forward existing branch in branch create dialog
  git-gui: Enhance choose_rev to handle hundreds of branches
  git-gui: Sort tags descending by tagger date
  git-gui: Option to default new branches to match tracking branches
  git-gui: Automatically refresh tracking branches when needed
  git-gui: Better handling of detached HEAD
  git-gui: Refactor our ui_status_value update technique
  git-gui: Refactor branch switch to support detached head
  git-gui: Unabbreviate commit SHA-1s prior to display
  git-gui: Default selection to first matching ref
  git-gui: Allow double-click in checkout dialog to start checkout
  git-gui: Extract blame viewer status bar into mega-widget
  git-gui: Change the main window progress bar to use status_bar
  git-gui: Show a progress meter for checking out files
  git-gui: Always use absolute path to all git executables
  git-gui: Correct gitk installation location
  git-gui: Assume unfound commands are known by git wrapper
  git-gui: Treat `git version` as `git --version`
  git-gui: Perform our own magic shbang detection on Windows
  git-gui: Teach console widget to use git_read
  git-gui: Improve the Windows and Mac OS X shortcut creators
  git-gui: Paper bag fix for Cygwin shortcut creation
  git-gui: Use sh.exe in Cygwin shortcuts
  git-gui: Include a space in Cygwin shortcut command lines
  Support wholesale directory renames in fast-import
  git-gui: Change prior tree SHA-1 verification to use git_read

Steffen Prohaska (1):
  filter-branch: added missing warn function

Steven Walter (1):
  Documentation for git-log --follow

Sven Verdoolaege (2):
  git-submodule: provide easy way of adding new submodules
  git-clone: fetch possibly detached HEAD over dumb http

Uwe Kleine-König (2):
  stash: end commit log with a newline
  repack: don't report "Nothing new to pack." if -q is given

What's in git.git (stable frozen)

[Junio C Hamano]

There shouldn't be anything eye-popping.  Hopefully we can do
the final soonish, perhaps this weekend.

I may have made small touch-ups to a few commits, so please
check them over.

Thanks.

* The 'master' branch has these since v1.5.4-rc5

Brandon Casey (1):
  git-relink: avoid hard linking in objects/info directory

Bruno Ribas (1):
  gitweb: Make use of the $git_dir variable at sub
    git_get_project_description

Christian Couder (3):
  Documentation: config: add "browser.<tool>.path".
  Documentation: help: specify supported html browsers.
  instaweb: use 'browser.<tool>.path' config option if it's set.

Jakub Narebski (1):
  gitweb: Add info about $projectroot and $projects_list to gitweb/README

Jeff King (1):
  t9001: add missing && operators

Jim Meyering (1):
  fix doc typos

Johannes Schindelin (1):
  Add test for rebase -i with commits that do not pass pre-commit

Junio C Hamano (1):
  reflog-expire: Avoid creating new files in a directory inside readdir(3)
    loop

Yasushi SHOJI (1):
  gitweb: Convert generated contents to utf8 in commitdiff_plain

What's in git.git

[Junio C Hamano]

Config parser fixes are in 'maint', along with many other
minor fixes.

As promised, a handful topics that have been cooking in 'next'
have graduated to 'master'.

----------------------------------------------------------------

* The 'maint' branch has these fixes since v1.5.4.1

David Steven Tweed (1):
  Make git prune remove temporary packs that look like write failures

Frank Lichtenheld (1):
  config: Fix --unset for continuation lines

Gerrit Pape (1):
  builtin-commit: remove .git/SQUASH_MSG upon successful commit

James Bowes (1):
  Add a BuildRequires for gettext in the spec file.

Johannes Schindelin (2):
  bisect: allow starting with a detached HEAD
  Document that the default of branch.autosetupmerge is true

Jonas Fonseca (1):
  man pages are littered with .ft C and others

Junio C Hamano (24):
  git-pull documentation: fix markup
  archive-tar.c: guard config parser from value=NULL
  Add config_error_nonbool() helper function
  builtin-apply.c: guard config parser from value=NULL
  builtin-branch.c: guard config parser from value=NULL
  builtin-commit.c: guard config parser from value=NULL
  builtin-config.c: guard config parser from value=NULL
  builtin-log.c: guard config parser from value=NULL
  builtin-reflog.c: guard config parser from value=NULL
  builtin-show-branch.c: guard config parser from value=NULL
  builtin-tag.c: guard config parser from value=NULL
  connect.c: guard config parser from value=NULL
  convert.c: guard config parser from value=NULL
  diff.c: guard config parser from value=NULL
  git.c: guard config parser from value=NULL
  help.c: guard config parser from value=NULL
  http.c: guard config parser from value=NULL
  merge-recursive.c: guard config parser from value=NULL
  remote.c: guard config parser from value=NULL
  setup.c: guard config parser from value=NULL
  wt-status.c: guard config parser from value=NULL
  imap-send.c: guard config parser from value=NULL
  builtin-log.c: guard config parser from value=NULL
  config.c: guard config parser from value=NULL

Martin Koegler (1):
  pack-objects: only throw away data during memory pressure

Mike Hommey (1):
  Work around curl-gnutls not liking to be reinitialized

Miklos Vajna (1):
  builtin-gc.c: guard config parser from value=NULL

Uwe Kleine-König (1):
  rebase -i: accept -m as advertised in the man page


* The 'master' branch has these since v1.5.4 in addition to the
  above.

Alexandre Julliard (4):
  git.el: Support for showing unknown/ignored directories.
  git.el: Added a command to amend a commit.
  git.el: Check for existing buffers on revert.
  git.el: Better handling of subprocess errors.

Bruno Ribas (1):
  gitweb: Make use of the $git_dir variable at sub git_get_project_url_list

Christian Couder (1):
  config: add test cases for empty value and no value config variables.

Daniel Barkalow (2):
  Test :/string form for checkout
  Reduce the number of connects when fetching

David Brown (1):
  git-send-email: Generalize auto-cc recipient mechanism.

Eric Wong (1):
  git-svn: improve repository URL matching when following parents

Florian La Roche (1):
  gitweb: Make feed entries point to commitdiff view

James Bowes (1):
  Add a BuildRequires for gettext in the spec file.

Jason McMullan (1):
  Remove $Id: ..$ $Header: ..$ etc from +ko and +k files during import

Johannes Schindelin (3):
  Also use unpack_trees() in do_diff_cache()
  Fix "git clone" for git:// protocol
  Introduce the config variable pack.packSizeLimit

Johannes Sixt (1):
  Fix misuse of prefix_path()

Jonas Fonseca (1):
  man pages are littered with .ft C and others

Junichi Uekawa (1):
  git-blame.el: show the when, who and what in the minibuffer.

Junio C Hamano (12):
  index: be careful when handling long names
  Avoid running lstat(2) on the same cache entry.
  read-cache.c: fix a couple more CE_REMOVE conversion
  read-cache.c: introduce is_racy_timestamp() helper
  lazy index hashing
  Sane use of test_expect_failure
  test: reword the final message of tests with known breakages
  known breakage: revision range computation with clock skew
  fix misuse of prefix_path()
  Make error messages from cherry-pick/revert more sensible
  Define the project whitespace policy
  Update the main documentation (stale notes section)

Karl Hasselström (2):
  git-svn: Don't call git-repack anymore
  Let "git svn" run "git gc --auto" occasionally

Linus Torvalds (3):
  Make on-disk index representation separate from in-core one
  Make run_diff_index() use unpack_trees(), not read_tree()
  Create pathname-based hash-table lookup into index

Martin Koegler (2):
  git-fsck: report missing author/commit line in a commit as an error
  parse_object_buffer: don't ignore errors from the object specific parsing
    functions

Michael Witten (3):
  git-send-email: ssh/login style password requests
  git-send-email: SIG{TERM,INT} handlers
  git-send-email: Better handling of EOF

Mike Hommey (1):
  Work around curl-gnutls not liking to be reinitialized

Pierre Habouzit (2):
  git-describe: Add a --match option to limit considered tags.
  git-name-rev: add a --(no-)undefined option.

Rafael Garcia-Suarez (1):
  Make git-remote.perl "use strict" compliant

Robin Rosenberg (1):
  Improve bash prompt to detect various states like an unfinished merge

Simon Hausmann (2):
  git-p4: Fix submit user-interface.
  git-p4: Ensure the working directory and the index are clean before
    "git-p4 rebase"

Tim Stoakes (1):
  Add `git svn blame' command

Toby Allsopp (1):
  git-p4: Fix indentation from tab to spaces

Tommy Thorn (1):
  git-p4: Fix an obvious typo

Re: What's in git.git

[Daniel Stenberg]

On Mon, 11 Feb 2008, Junio C Hamano wrote:

> Mike Hommey (1):
>  Work around curl-gnutls not liking to be reinitialized

But why reinitialize libcurl at all in the first place? This "work-around"
should rather be the standard behavior since there should be no logical reason 
to re-initialize libcurl's global state during a git's execution.

Even though Mike correctly identified a libcurl bug, it also indirectly 
identified a git flaw: re-initialization with the curl_global_* functions is 
pointless and only wastes time.

Re: What's in git.git

[Mike Hommey]

On Tue, Feb 12, 2008 at 10:15:28AM +0100, Daniel Stenberg <daniel@haxx.se> wrote:
> On Mon, 11 Feb 2008, Junio C Hamano wrote:
> 
> >Mike Hommey (1):
> > Work around curl-gnutls not liking to be reinitialized
> 
> But why reinitialize libcurl at all in the first place? This "work-around"
> should rather be the standard behavior since there should be no logical 
> reason to re-initialize libcurl's global state during a git's execution.
> 
> Even though Mike correctly identified a libcurl bug, it also indirectly 
> identified a git flaw: re-initialization with the curl_global_* functions 
> is pointless and only wastes time.

The important bit in the commit message reads:
> We work around this by removing the http_init and http_cleanup calls
> from get_refs_via_curl, replacing them with a transport->data
> initialization with the http_walker (which does http_init).

Which means there remains only one initialization. I agree it's not a
workaround anymore, but the word remained from the 3 previous attempts,
which were workarounds.

Mike

Re: What's in git.git

[Daniel Stenberg]

On Tue, 12 Feb 2008, Mike Hommey wrote:

> The important bit in the commit message reads:
>> We work around this by removing the http_init and http_cleanup calls
>> from get_refs_via_curl, replacing them with a transport->data
>> initialization with the http_walker (which does http_init).
>
> Which means there remains only one initialization. I agree it's not a 
> workaround anymore, but the word remained from the 3 previous attempts, 
> which were workarounds.

Ah, ok. Then I'll retract my comments! :-) Sorry for not checking out the 
actual code change, I only read the description!

What's in git.git (stable)

[Junio C Hamano]

I'll hopefully soon apply the RPM spec patch from Kristian
Høgsberg to 'maint' and cut 1.5.4.2.  It will have bunch of
config parser related fixes among others.

On the 'master' front, a handful topics have graduated:

 - Brian Downing's compat/qsort;
 - Crhstian Couder's browser wrapper;
 - Paolo Bonzini's prepare-commit-msg hook;
 - Steffen Prohaska's safe-crlf;
 - "foo/" in .gitignore matches directory "foo".

Also, updated versions of gitk and git-gui are included.

Have fun.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Christian Couder (8):
  config: add test cases for empty value and no value config variables.
  diff.c: replace a 'strdup' with 'xstrdup'.
  diff.c: remove useless check for value != NULL
  config: add 'git_config_string' to refactor string config variables.
  Add "const" qualifier to "char *pager_program".
  Add "const" qualifier to "char *editor_program".
  Add "const" qualifier to "char *excludes_file".
  diff.c: add "const" qualifier to "char *cmd" member of "struct
    ll_diff_driver"

Daniel Barkalow (1):
  Validate nicknames of remote branches to prohibit confusing ones

Gerrit Pape (1):
  cvsimport: have default merge regex also match beginning of commit
    message

Jay Soffian (1):
  mailinfo: feed only one line to handle_filter() for QP input

Jeff King (2):
  status: suggest "git rm --cached" to unstage for initial commit
  commit: discard index after setting up partial commit

Johannes Schindelin (1):
  bisect: use verbatim commit subject in the bisect log

Johannes Sixt (1):
  upload-pack: Initialize the exec-path.

Junio C Hamano (6):
  Revert "pack-objects: only throw away data during memory pressure"
  Protect get_author_ident_from_commit() from filenames in work tree
  diff.c: fixup garding of config parser from value=NULL
  diff: Fix miscounting of --check output
  filter-branch: handle filenames that need quoting
  Documentation/git-reset:

Miklos Vajna (1):
  git clone -s documentation: force a new paragraph for the NOTE

Pieter de Bie (2):
  Documentation/git-reset: don't mention --mixed for selected-paths reset
  Documentation/git-reset: Add an example of resetting selected paths

Sergei Organov (1):
  git-cvsimport.txt: fix '-M' description.

Shawn O. Pearce (1):
  fast-import: check return value from unpack_entry()

Stelian Pop (1):
  hg-to-git: fix parent analysis

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Brian Downing (1):
  compat: Add simplified merge sort implementation from glibc

Christian Couder (7):
  help: make 'git-help--browse' usable outside 'git-help'.
  help--browse: add '--config' option to check a config option for a
    browser.
  Rename 'git-help--browse.sh' to 'git-web--browse.sh'.
  instaweb: use 'git-web--browse' to launch browser.
  Documentation: instaweb: add 'git-web--browse' information.
  web--browse: Add a few quotes in 'init_browser_path'.
  Documentation: add 'git-web--browse.txt' and simplify other docs.

Christian Stimming (2):
  git-gui: (i18n) Fix a bunch of still untranslated strings.
  git-gui: Update German translation.

Dmitry Potapov (1):
  git-web--browse: do not start the browser with nohup

Gerrit Pape (1):
  gitk: properly deal with tag names containing / (slash)

Jay Soffian (3):
  git-gui: support Git Gui.app under OS X 10.5
  git-help--browse: improve browser support under OS X
  git-web--browse: fix misplaced quote in init_browser_path()

Jeff King (2):
  allow suppressing of global and system config
  fix config reading in tests

Johan Herland (2):
  Add testcase for 'git cvsexportcommit -w $cvsdir ...' with relative
    $GIT_DIR
  Fix 'git cvsexportcommit -w $cvsdir ...' when used with relative $GIT_DIR

Johannes Schindelin (1):
  Adjust .gitignore for 5884f1(Rename 'git-help--browse.sh'...)

Johannes Sixt (1):
  gitk: Heed the lines of context in merge commits

Junio C Hamano (7):
  Documentation/SubmittingPatches: Instruct how to use [PATCH] Subject
    header
  Documentation/SubmittingPatches: discuss first then submit
  Documentation/SubmittingPatches: What's Acked-by and Tested-by?
  gitignore(5): Allow "foo/" in ignore list to match directory "foo"
  gitignore: lazily find dtype
  .mailmap: adjust to a recent patch application glitch.
  Documentation/SubmittingPatches - a suggested patch flow

Linus Torvalds (1):
  gitk: learn --show-all output

Michele Ballabio (1):
  gitk: Fix "Key bindings" message

Paolo Bonzini (4):
  git-commit: support variable number of hook arguments
  git-commit: set GIT_EDITOR=: if editor will not be launched
  git-commit: Refactor creation of log message.
  git-commit: add a prepare-commit-msg hook

Shawn O. Pearce (7):
  git-gui: Automatically spell check commit messages as the user types
  git-gui: Paper bag fix bad string length call in spellchecker
  git-gui: Correct size of dictionary name widget in options dialog
  Include annotated tags in fast-import crash reports
  Include the fast-import marks table in crash reports
  Finish current packfile during fast-import crash handler
  Update fast-import documentation to discuss crash reports

Steffen Prohaska (2):
  safecrlf: Add mechanism to warn about irreversible crlf conversions
  gitk: Add checkbutton to ignore space changes

Re: What's in git.git (stable)

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:

> On the 'master' front, a handful topics have graduated:
> 
>  - Brian Downing's compat/qsort;
>  - Crhstian Couder's browser wrapper;
>  - Paolo Bonzini's prepare-commit-msg hook;
>  - Steffen Prohaska's safe-crlf;
>  - "foo/" in .gitignore matches directory "foo".

Nice.

> Daniel Barkalow (1):
>   Validate nicknames of remote branches to prohibit confusing ones

Good one.

> Jeff King (2):
>   status: suggest "git rm --cached" to unstage for initial commit

Corner case, but good one.

>   commit: discard index after setting up partial commit

IIRC there was also request for proper solution; this was more a hack.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: What's in git.git (stable)

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

>>   commit: discard index after setting up partial commit
>
> IIRC there was also request for proper solution; this was more a hack.

It is not a hack at all.

The more fundamental improvement was along the lines of what I
suggested soon after Kristian's initial round was posted, but
what the current code does is not wrong nor hack.  It is about a
partial commit after all and is not performance critical either.

Re: What's in git.git (stable)

[Johannes Schindelin]

Hi,

On Sun, 17 Feb 2008, Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> >>   commit: discard index after setting up partial commit
> >
> > IIRC there was also request for proper solution; this was more a hack.
> 
> It is not a hack at all.
> 
> The more fundamental improvement was along the lines of what I suggested 
> soon after Kristian's initial round was posted, but what the current 
> code does is not wrong nor hack.  It is about a partial commit after all 
> and is not performance critical either.

You mean: at this point, it is not necessary to be careful about the 
index, as the index that will be reloaded will already have the most 
recent timestamps, right?

Ciao,
Dscho

Re: What's in git.git (stable)

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Sun, 17 Feb 2008, Junio C Hamano wrote:
>
>> The more fundamental improvement was along the lines of what I suggested 
>> soon after Kristian's initial round was posted, but what the current 
>> code does is not wrong nor hack.  It is about a partial commit after all 
>> and is not performance critical either.
>
> You mean: at this point, it is not necessary to be careful about the 
> index, as the index that will be reloaded will already have the most 
> recent timestamps, right?

I do not understand the question, but if you are referring to my
"not performance critical", I meant: "A partial commit is
never performance critical".

A partial commit is by its nature "oops, I earlier told you to
git add this and git add that but I did not mean that, eh, I do
mean it but not for this commit yet, sorry, I want to commit
changes to these paths first please and then I'll deal with the
earlier added paths in later commit perhaps.", i.e. very
interactive.  Its performance requirement is unlike an automated
script slurping hundreds of changes per minute applying exactly
the change it wants in each commit to the index and making
commits in rapid succession.

Re: What's in git.git (stable)

[Johannes Schindelin]

Hi,

On Sun, 17 Feb 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Sun, 17 Feb 2008, Junio C Hamano wrote:
> >
> >> The more fundamental improvement was along the lines of what I suggested 
> >> soon after Kristian's initial round was posted, but what the current 
> >> code does is not wrong nor hack.  It is about a partial commit after all 
> >> and is not performance critical either.
> >
> > You mean: at this point, it is not necessary to be careful about the 
> > index, as the index that will be reloaded will already have the most 
> > recent timestamps, right?
> 
> I do not understand the question, but if you are referring to my "not 
> performance critical", I meant: "A partial commit is never performance 
> critical".
> 
> A partial commit is by its nature "oops, I earlier told you to git add 
> this and git add that but I did not mean that, eh, I do mean it but not 
> for this commit yet, sorry, I want to commit changes to these paths 
> first please and then I'll deal with the earlier added paths in later 
> commit perhaps.", i.e. very interactive.  Its performance requirement is 
> unlike an automated script slurping hundreds of changes per minute 
> applying exactly the change it wants in each commit to the index and 
> making commits in rapid succession.

Well, my workflow has lots of these moments.  I do not even feel "oops" 
about it.  More like "by the way, this needs committing _now_".

So I guess I'll be the guinea pig for this patch, and if it is too 
painful, I'll just go and fix it.

Ciao,
Dscho

Re: What's in git.git (stable)

[Jeff King]

On Mon, Feb 18, 2008 at 01:34:50AM +0000, Johannes Schindelin wrote:

> Well, my workflow has lots of these moments.  I do not even feel "oops" 
> about it.  More like "by the way, this needs committing _now_".
> 
> So I guess I'll be the guinea pig for this patch, and if it is too 
> painful, I'll just go and fix it.

Just to be clear, this patch discards the cache after preparing the
partial index but before doing the status. This is in contrast to the
current 'master' and v1.5.4, which discard the cache _three_ times
during the status process.

So no, the performance will probably not be a big deal. It is better
than it has been in any released version of git.

-Peff

Re: What's in git.git (stable)

[Johannes Schindelin]

Hi,

On Sun, 17 Feb 2008, Jeff King wrote:

> On Mon, Feb 18, 2008 at 01:34:50AM +0000, Johannes Schindelin wrote:
> 
> > Well, my workflow has lots of these moments.  I do not even feel "oops" 
> > about it.  More like "by the way, this needs committing _now_".
> > 
> > So I guess I'll be the guinea pig for this patch, and if it is too 
> > painful, I'll just go and fix it.
> 
> Just to be clear, this patch discards the cache after preparing the
> partial index but before doing the status. This is in contrast to the
> current 'master' and v1.5.4, which discard the cache _three_ times
> during the status process.

... but then goes through big pains to reconstruct an index that needs as 
little updating as possible.

> So no, the performance will probably not be a big deal. It is better 
> than it has been in any released version of git.

I'll see, and report back.

IOW I think that your patch is necessary.  There might be some followup 
work to do for me, but at the moment, your patch fixes an existing bug.

Ciao,
Dscho

Re: What's in git.git (stable)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> .... This is in contrast to the
> current 'master' and v1.5.4, which discard the cache _three_ times
> during the status process.

The current 'master' meaning before 959ba67 (commit: discard
index after setting up partial commit), right?

I've been hoping that when this turns out to be Ok it would be
worth cherry-picking to 'maint' before 1.5.4.3.

Re: What's in git.git (stable)

[Jeff King]

On Sun, Feb 17, 2008 at 07:12:53PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > .... This is in contrast to the
> > current 'master' and v1.5.4, which discard the cache _three_ times
> > during the status process.
> 
> The current 'master' meaning before 959ba67 (commit: discard
> index after setting up partial commit), right?

Heh. Yes. The current 'master' meaning 'the current master when I wrote
that patch.' :)

-Peff

What's in git.git (stable)

[Junio C Hamano]

With a handful of fixes and RPM specfile updates, we would
probably want to do 1.5.4.3 in a week or so from 'maint'.

A handful of new topics are now on 'master', and the ones still
on 'next' are maturing with necessary fixes.  I think we have
enough material for 1.5.5 when they graduate, and I am hoping to
do an rc1 sometime early to mid next month.  We'll see.

* The 'maint' branch has these fixes since the last announcement.

Gerrit Pape (1):
  git-clone.sh: properly configure remote even if remote's head is dangling

Jay Soffian (1):
  send-email: squelch warning due to comparing undefined $_ to ""

Jeff King (3):
  push: indicate partialness of error message
  Documentation/push: clarify matching refspec behavior
  push: document the status output

Junio C Hamano (1):
  GIT 1.5.4.2

Kristian Høgsberg (1):
  Rename git-core rpm to just git and rename the meta-pacakge to git-all.

Miklos Vajna (1):
  Documentation/git-stash: document options for git stash list

Pekka Kaitaniemi (1):
  Clarified the meaning of git-add -u in the documentation


* The 'master' branch has these since the last announcement
  in addition to the above.

Brandon Casey (1):
  Add compat/fopen.c which returns NULL on attempt to open directory

Bruno Ribas (1):
  gitweb: Use the config file to set repository owner's name.

Christian Couder (1):
  help.c: use 'git_config_string' to get 'help_default_format'.

Daniel Barkalow (1):
  API documentation for remote.h

David Kågedal (1):
  git.el: Set process-environment instead of invoking env

Jakub Narebski (3):
  gitweb: Fix displaying unchopped argument in chop_and_escape_str
  gitweb: Add new option -nohtml to quot_xxx subroutines
  gitweb: Fix bug in href(..., -replay=>1) when using 'pathinfo' form

Jay Soffian (1):
  Correct git-pull documentation

Jeff King (2):
  hard-code the empty tree object
  add--interactive: handle initial commit better

Johannes Schindelin (5):
  http-push: avoid invalid memory accesses
  http-push: do not get confused by submodules
  http-push: avoid a needless goto
  bisect view: check for MinGW32 and MacOSX in addition to X11
  cvsexportcommit: be graceful when "cvs status" reorders the arguments

Johannes Sixt (1):
  Technical documentation of the run-command API.

Junio C Hamano (5):
  setup: sanitize absolute and funny paths in get_pathspec()
  git-add: adjust to the get_pathspec() changes.
  builtin-mv: minimum fix to avoid losing files
  Sync with 1.5.4.2 and start 1.5.5 Release Notes
  sending errors to stdout under $PAGER

Lars Hjemli (1):
  Simplify setup of $GIT_DIR in git-sh-setup.sh

Linus Torvalds (1):
  Add "--show-all" revision walker flag for debugging

Marco Costalba (1):
  Avoid a useless prefix lookup in strbuf_expand()

Martin Koegler (15):
  deref_tag: handle return value NULL
  deref_tag: handle tag->tagged = NULL
  check return code of prepare_revision_walk
  read_object_with_reference: don't read beyond the buffer
  get_sha1_oneline: check return value of parse_object
  mark_blob/tree_uninteresting: check for NULL
  reachable.c::add_one_tree: handle NULL from lookup_tree
  list-objects.c::process_tree/blob: check for NULL
  check results of parse_commit in merge_bases
  process_tag: handle tag->tagged == NULL
  reachable.c::process_tree/blob: check for NULL
  revision.c: handle tag->tagged == NULL
  parse_commit: don't fail, if object is NULL
  check return value from parse_commit() in various functions
  peel_onion: handle NULL

Matthias Kestenholz (1):
  Add color.ui variable which globally enables colorization if set

Robin Rosenberg (1):
  Make blame accept absolute paths

What's in git.git (stable)

[Junio C Hamano]

By the end of this week, we will hopefully pretty much know what
will be (and what won't be) in 1.5.5.  Tonight's 'master'
contains Linus's "diff --dirstat" and my "apply ---whitespace"
enhancements, among other things.  The next 'master' update is
expected to be fairly big (see "What's cooking").

----------------------------------------------------------------

* The 'maint' branch has these fixes since v1.5.4.3

Shawn O. Pearce (3):
  Ensure 'make dist' compiles git-archive.exe on Cygwin
  Protect peel_ref fallback case from NULL parse_object result
  Correct fast-export file mode strings to match fast-import standard

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Gerrit Pape (2):
  git-merge-index documentation: clarify synopsis
  builtin-tag.c: remove cruft

Jakub Narebski (1):
  gitweb: Fix bugs in git_search_grep_body: it's length(), not len()

Jay Soffian (2):
  send-email: fix In-Reply-To regression
  pull: pass --strategy along to to rebase

Jeff King (5):
  git_config_*: don't assume we are parsing a config file
  t3404: use configured shell instead of /bin/sh
  diff: fix java funcname pattern for solaris
  t9001: enhance fake sendmail test harness
  send-email: test compose functionality

Johannes Sixt (1):
  prefix_path: use is_absolute_path() instead of *orig == '/'

Junio C Hamano (18):
  builtin-apply.c: refactor small part that matches context
  builtin-apply.c: restructure "offset" matching
  builtin-apply.c: push match-beginning/end logic down
  builtin-apply.c: make it more line oriented
  builtin-apply.c: optimize match_beginning/end processing a bit.
  builtin-apply.c: mark common context lines in lineinfo structure.
  builtin-apply.c: clean-up apply_one_fragment()
  builtin-apply.c: simplify calling site to apply_line()
  builtin-apply.c: do not feed copy_wsfix() leading '+'
  builtin-apply.c: move copy_wsfix() function a bit higher.
  builtin-apply.c: pass ws_rule down to match_fragment()
  git-apply --whitespace=fix: fix whitespace fuzz introduced by previous
    run
  core.whitespace: cr-at-eol
  apply: do not barf on patch with too large an offset
  git-reset --hard and git-read-tree --reset: fix read_cache_unmerged()
  gitweb: Better chopping in commit search results
  ws_fix_copy(): move the whitespace fixing function to ws.c
  diff --dirstat: saner handling of binary and unmerged files

Linus Torvalds (5):
  Add "--dirstat" for some directory statistics
  Fix name re-hashing semantics
  Name hash fixups: export (and rename) remove_hash_entry
  Use helper function for copying index entry information
  Be more verbose when checkout takes a long time

Michele Ballabio (1):
  builtin-for-each-ref.c: fix typo in error message

Miklos Vajna (1):
  git-clean: handle errors if removing files fails

Santi Béjar (1):
  git-bundle.txt: Add different strategies to create the bundle

Shawn O. Pearce (1):
  Teach git-grep --name-only as synonym for -l

What's in git.git (stable)

[Junio C Hamano]

For the next maintenance release v1.5.4.4, I made a few
cherry-picks from 'master' and also a merge down of a topic
branch that has been cooking there, to 'maint'.

On the 'master' front, many topics have been merged.  With a few
more topics that are still in 'next', we are pretty much done
feature-wise for the next feature release v1.5.5.

----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.

Brandon Casey (1):
  builtin-reflog.c: don't install new reflog on write failure

Bryan Donlan (1):
  Documentation/git-am.txt: Pass -r in the example invocation of rm -f
    .dotest

Caio Marcelo de Oliveira Filho (1):
  filter-branch documentation: non-zero exit status in command abort the
    filter

Carl Worth (1):
  Eliminate confusing "won't bisect on seeked tree" failure

Daniel Barkalow (2):
  Use a single implementation and API for copy_file()
  Don't use GIT_CONFIG in t5505-remote

Jay Soffian (2):
  rev-parse: fix potential bus error with --parseopt option spec handling
  send-email: fix In-Reply-To regression

Johan Herland (2):
  Add testcase for 'git cvsexportcommit -w $cvsdir ...' with relative
    $GIT_DIR
  Fix 'git cvsexportcommit -w $cvsdir ...' when used with relative $GIT_DIR

Johannes Schindelin (3):
  http-push: avoid invalid memory accesses
  http-push: do not get confused by submodules
  http-push: avoid a needless goto

Jonathan del Strother (1):
  Prompt to continue when editing during rebase --interactive

Miklos Vajna (2):
  Documentation/git-filter-branch: add a new msg-filter example
  Documentation/git svn log: add a note about timezones.

Steven Drake (1):
  timezone_names[]: fixed the tz offset for New Zealand.


----------------------------------------------------------------
* The 'master' branch has these since the last announcement
  in addition to the above.

Alexandre Julliard (1):
  git.el: Do not display empty directories.

Andreas Ericsson (1):
  pack-objects: Add runtime detection of online CPU's

Brandon Casey (2):
  builtin-reflog.c: don't install new reflog on write failure
  pack-objects: Print a message describing the number of threads for packing

Carl Worth (1):
  Eliminate confusing "won't bisect on seeked tree" failure

Daniel Barkalow (26):
  Allow callers of unpack_trees() to handle failure
  Add flag to make unpack_trees() not print errors.
  Send unpack-trees debugging output to stderr
  Discard "deleted" cache entries after using them to update the working tree
  Add "skip_unmerged" option to unpack_trees.
  Build-in merge-recursive
  Move create_branch into a library file
  Use diff -u instead of diff in t7201
  Library function to check for unmerged index entries
  Move code to clean up after a branch change to branch.c
  Build in checkout
  Clean up reporting differences on branch switch
  Add more tests for format-patch
  Improve message-id generation flow control for format-patch
  Export some email and pretty-printing functions
  Use ALLOC_GROW in remote.{c,h}
  Add a --cover-letter option to format-patch
  Add tests for extra headers in format-patch
  Fix format.headers not ending with a newline
  Combine To: and Cc: headers
  Support a --cc=<email> option in format-patch
  Resolve value supplied for no-colon push refspecs
  builtin-checkout.c: Remove unused prefix arguments in switch_branches path
  Add support for url aliases in config files
  Add API access to shortlog
  Improve collection of information for format-patch --cover-letter

Gerrit Pape (1):
  hash-object: cleanup handling of command line options

Jakub Narebski (2):
  gitweb: Better cutting matched string and its context
  Add '--fixed-strings' option to "git log --grep" and friends

Jay Soffian (3):
  builtin-checkout.c: fix possible usage segfault
  branch: optionally setup branch.*.merge from upstream local branches
  doc: documentation update for the branch track changes

Jeff King (3):
  help: use parseopt
  make alias lookup a public, procedural function
  help: respect aliases

Jim Meyering (1):
  Avoid unnecessary "if-before-free" tests.

Johannes Schindelin (2):
  xdl_merge(): make XDL_MERGE_ZEALOUS output simpler
  xdl_merge(): introduce XDL_MERGE_ZEALOUS_ALNUM

Johannes Sixt (2):
  start_command(), .in/.out/.err = -1: Callers must close the file descriptor
  start_command(), if .in/.out > 0, closes file descriptors, not the callers

Junio C Hamano (12):
  diff --relative: output paths as relative to the current subdirectory
  diff --relative: help working in a bare repository
  checkout: notice when the switched branch is behind or forked
  checkout: tone down the "forked status" diagnostic messages
  checkout: work from a subdirectory
  checkout: updates to tracking report
  Add merge-subtree back
  checkout: show progress when checkout takes long time while switching
    branches
  checkout: error out when index is unmerged even with -m
  url rewriting: take longest and first match
  git-apply --whitespace=fix: fix off by one thinko
  Revert "pack-objects: Print a message describing the number of threads
    for packing"

Sebastian Noack (1):
  git-svn: Don't prompt for client cert password everytime.

Shawn O. Pearce (5):
  Optimize peel_ref for the current ref of a for_each_ref callback
  Teach git-describe to use peeled ref information when scanning tags
  Avoid accessing non-tag refs in git-describe unless --all is requested
  Teach git-describe --exact-match to avoid expensive tag searches
  Use git-describe --exact-match in bash prompt on detached HEAD

Simon Hausmann (4):
  git-p4: Remove --log-substitutions feature.
  git-p4: Clean up git-p4 submit's log message handling.
  git-p4: Removed git-p4 submit --direct.
  git-p4: git-p4 submit cleanups.

Steffen Prohaska (2):
  t4014: Replace sed's non-standard 'Q' by standard 'q'
  Add tests for filesystem challenges (case and unicode normalization)

Tommy Thorn (1):
  git-p4: support exclude paths

Tor Arvid Lund (1):
  git-p4: Support usage of perforce client spec

What's in git.git (stable)

[Junio C Hamano]

The 'master' has, aside from trivial fixes and enhancements, the following
topics that have been cooking:

 * "verify-pack" improvements;

 * "describe" that warns about a tag whose name and path contradict;

 * "describe --long" to show an tagged commit as $tag-0-$sha1;

 * "cvsimport -M" can be given more than once;

 * "gitweb" grep-search improvements;

A handful of the topics are meant also for 'maint'; after seeing no
complaints for a while they will be merged to 'maint' as part of the next
maintenance release v1.5.4.4.

----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.

Daniel Barkalow (1):
  Correct name of diff_flush() in API documentation

Gerrit Pape (1):
  templates/Makefile: don't depend on local umask setting

Junio C Hamano (1):
  Start preparing for 1.5.4.4

Mike Ralphson (1):
  Documentation cherry-pick: Fix cut-and-paste error

Rémi Vanicat (1):
  git.el: find the git-status buffer whatever its name is

Shawn O. Pearce (1):
  git-gui: Paper bag fix info dialog when no files are staged at commit

----------------------------------------------------------------
* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  Fix builtin checkout crashing when given an invalid path

Christian Stimming (2):
  git-gui: (i18n) Add newly added translation strings to template.
  git-gui: Update German translation.

Clemens Buchacher (2):
  http-push: push <remote> :<branch> deletes remote branch
  http-push: add regression tests

Daniel Barkalow (3):
  Always use the current connection's remote ref list in git protocol
  Use diff_tree() directly in making cover letter
  Write index file on any checkout of files

Denis Cheng (1):
  cleanup: remove unused git_checkout_config

Frank Lichtenheld (1):
  gc: Add --quiet option

Jakub Narebski (4):
  gitweb: Change parse_commits signature to allow for multiple options
  gitweb: Simplify fixed string search
  Documentation: Remove --{min,max}-age option from git-log(1)
  gitweb: Mark first match when searching commit messages

Jean-Luc Herren (1):
  fast-import: exit with proper message if not a git dir

Jeff King (3):
  use build-time SHELL_PATH in test scripts
  rename: warn user when we have turned off rename detection
  allow git-am to run in a subdirectory

Johannes Schindelin (4):
  completion: support format-patch's --cover-letter option
  Fix make_absolute_path() for parameters without a slash
  format-patch: use the diff options for the cover letter, too
  format-patch: wrap cover-letter's shortlog sensibly

Johannes Sixt (2):
  daemon: send more error messages to the syslog
  daemon: ensure that base-path is an existing directory

Junio C Hamano (11):
  git-remote: do not complain on multiple URLs for a remote
  Fix "git log --merge --left-right"
  format-patch: remove a leftover debugging message
  tests: introduce test_must_fail
  Update draft release notes for 1.5.5
  t6024: move "git reset" to prepare for a test inside the test itself
  CodingGuidelines: spell out how we use grep in our scripts
  find_unique_abbrev(): redefine semantics
  Clean up find_unique_abbrev() callers
  diff-lib.c: constness strengthening
  diff: make sure work tree side is shown as 0{40} when different

Martin Koegler (10):
  add generic, type aware object chain walker
  builtin-fsck: move away from object-refs to fsck_walk
  Remove unused object-ref code
  builtin-fsck: reports missing parent commits
  builtin-fsck: move common object checking code to fsck.c
  add common fsck error printing function
  unpack-object: cache for non written objects
  unpack-objects: prevent writing of inconsistent objects
  index-pack: introduce checking mode
  receive-pack: use strict mode for unpacking objects

Michele Ballabio (1):
  git-gui: fix typo in lib/spellcheck.tcl

Mike Hommey (4):
  Set proxy override with http_init()
  Add test for git rebase --abort
  Documentation/git-rebase.txt: Add --strategy to synopsys
  git rebase --abort: always restore the right commit

Miklos Vajna (1):
  Improve t6029 to check the real "subtree" case

Nicolas Pitre (4):
  factorize revindex code out of builtin-pack-objects.c
  make verify_one_pack() a bit less wrong wrt packed_git structure
  fix unimplemented packed_object_info_detail() features
  add storage size output to 'git verify-pack -v'

Petr Baudis (1):
  gitweb: Clearly distinguish regexp / exact match searches

Philippe Bruhat (BooK (3):
  cvsimport: have default merge regex allow for dashes in the branch name
  cvsimport: allow for multiple -M options
  cvsimport: document that -M can be used multiple times

Ralf Wildenhues (1):
  Fix doc typos.

Santi Béjar (2):
  git-describe: --long shows the object name even for a tagged commit
  clone: support cloning full bundles

Sebastian Noack (1):
  git-svn: Don't prompt for client cert password everytime.

Shawn O. Pearce (7):
  git-gui: Ensure all spellchecker 'class' variables are initialized
  git-gui: Remove explicit references to 'aspell' in message strings
  git-gui: Only bind the spellcheck popup suggestion hook once
  git-gui: Catch and display aspell startup failures to the user
  git-gui: Gracefully display non-aspell version errors to users
  git-gui: Shorten Aspell version strings to just Aspell version number
  Teach git-describe to verify annotated tag names before output

Uwe Kleine-König (1):
  rev-list: add --branches, --tags and --remotes

What's in git.git (stable)

[Junio C Hamano]

I should probably do a 1.5.4.4 shortly from 'maint' to flush accumulated
fixes.  There is nothing major, but send-email regression fix deserves to
be delibered sooner to the end users.

On the 'master', we briefly had a faulty receive-pack to cause a small
pushes to fail, but that glitch has been reverted.  Also fixed was a
git-describe not quite working when your tags are packed (e.g. after
git-gc).

----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.

Björn Steinbrink (1):
  receive-pack: Initialize PATH to include exec-dir.

Gerrit Pape (1):
  git-merge.sh: better handling of combined --squash,--no-ff,--no-commit
    options

Jeff King (1):
  revert: actually check for a dirty index

Junio C Hamano (2):
  tests: introduce test_must_fail
  Update draft release notes for 1.5.4.4

Matthieu Moy (1):
  Fix incorrect wording in git-merge.txt.

Mike Hommey (1):
  Fix random crashes in http_cleanup()

Ping Yin (1):
  git-submodule: Fix typo 'url' which should be '$url'

Shawn O. Pearce (1):
  Fix 'git remote show' regression on empty repository in 1.5.4

----------------------------------------------------------------
* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  Fix test for cleanup failure in t7300 on Windows

Junio C Hamano (8):
  Update draft release notes for 1.5.5
  git-describe: use tags found in packed-refs correctly
  describe: fix --long output
  describe: re-fix display_name()
  t6120 (describe): check --long properly
  Revert "receive-pack: use strict mode for unpacking objects"
  Revert "unpack-objects: prevent writing of inconsistent objects"
  fsck.c: fix bogus "empty tree" check

Martin Koegler (1):
  fetch-pack: check parse_commit/object results

Mike Hommey (1):
  t3407-rebase-abort.sh: Enhance existing tests, and add test for rebase
    --merge

SZEDER Gábor (2):
  bash: add git-branch options
  bash: git-branch -d and -m lists only local branches

Shawn O. Pearce (3):
  Don't allow git-describe failures to go unnoticed in t6120
  Test for packed tags in git-describe output
  Add git-describe test for "verify annotated tag names on output"

Simon Hausmann (1):
  git-p4: Fix import of changesets with file deletions

What's in git.git (stable)

[Junio C Hamano]

There are about half a dozen topics that need to be merged to 'maint'
before 1.5.4.4 can happen, which hopefully will be mid next week.  They
are already in 'master' and we haven't heard about breakages with them.

It would be really nice to also have msgfmt issue on OSX resolved (e.g.
http://article.gmane.org/gmane.comp.version-control.git/76355) before
that.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Junio C Hamano (1):
  test-lib: fix TERM to dumb for test repeatability

Pierre Habouzit (1):
  unquote_c_style: fix off-by-one.

Shawn O. Pearce (1):
  git-gui: Gracefully fall back to po2msg.sh if msgfmt --tcl fails

Uwe Kleine-König (1):
  config.txt: refer to --upload-pack and --receive-pack instead of --exec


* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  Do not use GUID on dir in git init --shared=all on FreeBSD

Brandon Casey (10):
  builtin-reflog.c: fix typo that accesses an unset variable
  reflog-delete: parse standard reflog options
  git-reflog: add option --rewrite to update reflog entries while expiring
  refs.c: make close_ref() and commit_ref() non-static
  git-reflog: add option --updateref to write the last reflog sha1 into the
    ref
  git-stash: add new 'drop' subcommand
  git-stash: add new 'pop' subcommand
  t3903-stash.sh: Add missing '&&' to body of testcase
  git-reflog.txt: Document new commands --updateref and --rewrite
  t3903-stash.sh: Add tests for new stash commands drop and pop

Charles Bailey (4):
  Tidy up git mergetool's backup file behaviour
  Changed an internal variable of mergetool to support custom commands
  Teach git mergetool to use custom commands defined at config time
  Add a very basic test script for git mergetool

Christian Couder (1):
  run-command: Redirect stderr to a pipe before redirecting stdout to
    stderr

Denis Cheng (3):
  whatchanged documentation: share description of --pretty with others
  specify explicit "--pretty=medium" with `git log/show/whatchanged`
  log/show/whatchanged: introduce format.pretty configuration

Johannes Schindelin (1):
  Teach "git reflog" a subcommand to delete single entries

Junio C Hamano (1):
  send-email: --no-signed-off-cc should suppress 'sob' cc

What's in git.git (stable)

[Junio C Hamano]

Maintenance release 1.5.4.4 is out with accumulated fixes.

Except for a few remaining topics ("remote rewritten in C", and "saner
unpack_trees"), 'master' is almost feature complete for 1.5.5 and we will
hopefully soon enter -rc freeze.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Adeodato Simó (1):
  Really make the LF after reset in fast-import optional

Johannes Schindelin (1):
  cvsexportcommit: be graceful when "cvs status" reorders the arguments

Johannes Sixt (2):
  daemon: send more error messages to the syslog
  daemon: ensure that base-path is an existing directory

John Goerzen (1):
  Fix dcommit, rebase when rewriteRoot is in use

Junio C Hamano (2):
  Fix "git log --merge --left-right"
  GIT 1.5.4.4

Mike Hommey (1):
  Set proxy override with http_init()

Santi Béjar (1):
  ident.c: reword error message when the user name cannot be determined

Sebastian Noack (1):
  git-svn: Don't prompt for client cert password everytime.

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Andy Whitcroft (1):
  shortlog: take the first populated line of the description

Carlos Rica (1):
  Make builtin-reset.c use parse_options.

Charles Bailey (2):
  git-mergetool documentaiton: show toolnames in typewriter font
  merge-tool documentation: describe custom command usage

Dmitry Potapov (2):
  Make private quote_path() in wt-status.c available as
    quote_path_relative()
  git-clean: correct printing relative path

Jakub Narebski (1):
  gitweb: Fix and simplify pickaxe search

Jeff King (1):
  Add a test for read-tree -u --reset with a D/F conflict

Junio C Hamano (10):
  describe --always: fall back to showing an abbreviated object name
  am: read from the right mailbox when started from a subdirectory
  am: remove support for -d .dotest
  am: --rebasing
  get_pathspec(): die when an out-of-tree path is given
  Revert part of 744dacd (builtin-mv: minimum fix to avoid losing files)
  Revert part of 1abf095 (git-add: adjust to the get_pathspec() changes)
  Revert part of d089eba (setup: sanitize absolute and funny paths in
    get_pathspec())
  git-clean: add tests for relative path
  filter-branch: handle "disappearing tree" case correctly in subdir filter

Mark Levedahl (1):
  git-submodule - Allow adding a submodule in-place

Michal Rokos (1):
  Add compat/snprintf.c for systems that return bogus

Pierre Habouzit (2):
  parse-opt: bring PARSE_OPT_HIDDEN and NONEG to git-rev-parse --parseopt
  parse-options: new option type to treat an option-like parameter as an
    argument.

Shawn O. Pearce (11):
  Remove unused variable in builtin-fetch find_non_local_tags
  Remove unnecessary delaying of free_refs(ref_map) in builtin-fetch
  Ensure tail pointer gets setup correctly when we fetch HEAD only
  Allow builtin-fetch's find_non_local_tags to append onto a list
  Free the path_lists used to find non-local tags in git-fetch
  Teach upload-pack to log the received need lines to an fd
  Make git-fetch follow tags we already have objects for sooner
  Teach git-fetch to grab a tag at the same time as a commit
  git-pack-objects: Automatically pack annotated tags if object was packed
  Teach fetch-pack/upload-pack about --include-tag
  Teach git-fetch to exploit server side automatic tag following

What's in git.git (stable)

[Junio C Hamano]

We still have remaining fixes and a handful backports (cherry-picks) from
'master' to 'maint', and we would probably need v1.5.4.5 shortly.

On the 'master' front, we have git-gui updates, more bash completion, and
a few recent graduates (rewrite of unpack_trees(), reimplementation of
git-remote).

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Andy Whitcroft (1):
  shortlog: take the first populated line of the description

Clemens Buchacher (1):
  merge-recursive: handle file mode changes

Jakub Narebski (1):
  gitweb: Fix bug in href(..., -replay=>1) when using 'pathinfo' form

Jeff King (1):
  t0021: tr portability fix for Solaris

Johannes Schindelin (3):
  launch_editor(): allow spaces in the filename
  git fetch: Take '-n' to mean '--no-tags'
  merge-file: handle empty files gracefully

Junio C Hamano (3):
  filter-branch: handle "disappearing tree" case correctly in subdir filter
  git-pull documentation: warn about the option order
  quiltimport: fix misquoting of parsed -p<num> parameter

Marc-Andre Lureau (2):
  git-svn: fix find-rev error message when missing arg
  git-cvsimport: fix merging with remote parent branch

Mike Hommey (1):
  git rebase --abort: always restore the right commit

Pierre Habouzit (1):
  git-quiltimport: better parser to grok "enhanced" series files.

Vineet Kumar (1):
  Minor wording changes in the keyboard descriptions in git-add
    --interactive.

----------------------------------------------------------------

* The 'master' branch has these since the last announcement
  in addition to the above.

Adam Piątyszek (1):
  git-gui: Add option for changing the width of the commit message text box

Christian Couder (2):
  web--browse: use custom commands defined at config time
  Documention: web--browse: add info about "browser.<tool>.cmd" config var

Johannes Schindelin (9):
  path-list: add functions to work with unsorted lists
  parseopt: add flag to stop on first non option
  Test "git remote show" and "git remote prune"
  Make git-remote a builtin
  builtin-remote: prune remotes correctly that were added with --mirror
  remote show: Clean up connection correctly if object fetch wasn't done
  remote: fix "update [group...]"
  builtin remote rm: remove symbolic refs, too
  gc: call "prune --expire 2.weeks.ago" by default

Junio C Hamano (6):
  merge-recursive: split low-level merge functions out.
  expose a helper function peel_to_type().
  traverse_trees_recursive(): propagate merge errors up
  git-gui: Simplify MSGFMT setting in Makefile
  Documentation/config: typofix
  read-tree() and unpack_trees(): use consistent limit

Kevin Ballard (1):
  bash: Properly quote the GIT_DIR at all times to fix subdirectory paths
    with spaces

Linus Torvalds (11):
  Add 'df_name_compare()' helper function
  Make 'traverse_tree()' use linked structure rather than 'const char
    *base'
  Add return value to 'traverse_tree()' callback
  Make 'traverse_trees()' traverse conflicting DF entries in parallel
  Move 'unpack_trees()' over to 'traverse_trees()' interface
  Fix tree-walking compare_entry() in the presense of --prefix
  Add 'const' where appropriate to index handling functions
  Make 'unpack_trees()' take the index to work on as an argument
  Make 'unpack_trees()' have a separate source and destination index
  unpack_trees(): minor memory leak fix in unused destination index
  unpack_trees(): fix diff-index regression.

Michal Rokos (1):
  autoconf: Test FREAD_READS_DIRECTORIES

Nicolas Pitre (1):
  pack-objects: proper pack time stamping with --max-pack-size

Philipp A. Hartmann (1):
  git-gui: if a background colour is set, set foreground colour as well

SZEDER Gábor (7):
  bash: remove unnecessary conditions when checking for subcommands
  bash: refactor searching for subcommands on the command line
  bash: add new 'git stash' subcommands
  bash: add 'git svn' subcommands and options
  bash: use __gitdir when completing 'git rebase' options
  bash: fix long option with argument double completion
  update 'git rebase' documentation

Samuel Tardieu (1):
  "remote update": print remote name being fetched from

Shawn O. Pearce (1):
  bash: Remove completion of core.legacyheaders option

Teemu Likonen (1):
  bash: Add more long options to be completed with "git --<TAB>"

eric miao (1):
  git-gui: translate the remaining messages in zh_cn.po to chinese

What's in git.git (stable)

[Junio C Hamano]

With a few late topics came quite a few regression fixes to make us ready
for -rc1.

 * gitk, git-gui and git-p4 have been updated.

 * "git gc --auto" annoyance is hopefully reduced away.

 * Breakage in automated tag following by git-fetch rewritten in C has
   hopefully been fixed.

 * Quite a few portability improvements from Solaris porting efforts.

 * "git remote show" does not talk about symrefs anymore.

 * "git help" updates to plug in more backends.

 * "git submodule summary" to show symmetric differences between commits
   in submodules.

---

* The 'maint' branch has these fixes since the last announcement.

Bernt Hansen (1):
  git-new-workdir: Share SVN meta data between work dirs and the repository

Eric Wong (1):
  git-svn: don't blindly append '*' to branch/tags config

Jonas Fonseca (1):
  Make man page building quiet when DOCBOOK_XSL_172 is defined

Junio C Hamano (3):
  format-patch: generate MIME header as needed even when there is
    format.header
  rebase -m: do not trigger pre-commit verification
  Start draft ReleaseNotes for 1.5.4.5

Linus Torvalds (1):
  rev-parse: fix meaning of rev~ vs rev~0.


* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  git-gui: update russian translation

Brandon Casey (2):
  builtin-gc.c: allow disabling all auto-gc'ing by assigning 0 to gc.auto
  t/t7003-filter-branch.sh: use test_must_fail rather than '!'

Christian Couder (5):
  help: add "man.viewer" config var to use "woman" or "konqueror"
  Documentation: help: describe 'man.viewer' config variable
  help: implement multi-valued "man.viewer" config option
  Documentation: help: explain 'man.viewer' multiple values
  help: warn if specified 'man.viewer' is unsupported, instead of erroring
    out

Daniel Barkalow (4):
  Write diff output to a file in struct diff_options
  Tighten refspec processing
  Fix t3200 config
  Fix tag following

David Aguilar (1):
  gitk: Don't show local changes when we there is no work tree

Eyvind Bernhardsen (2):
  fast-import: Allow "reset" to delete a new branch without error
  fast-import: Document the effect of "merge" with no "from" in a commit

Jeff King (15):
  gitk: make autoselect optional
  tr portability fixes
  t0050: perl portability fix
  more tr portability test script fixes
  grep portability fix: don't use "-e" or "-q"
  remove use of "tail -n 1" and "tail -1"
  add test_cmp function for test scripts
  t4020: don't use grep -a
  t6000lib: tr portability fix
  add NO_EXTERNAL_GREP build option
  filter-branch: don't use xargs -0
  filter-branch: use $SHELL_PATH instead of 'sh'
  t9112: add missing #!/bin/sh header
  t7505: use SHELL_PATH in hook
  t6000lib: re-fix tr portability

Johannes Schindelin (1):
  remote show: do not show symbolic refs

Johannes Sixt (1):
  git-submodule summary: fix that some "wc" flavors produce leading spaces

Jonas Fonseca (1):
  shortlog: do not require to run from inside a git repository

Junio C Hamano (15):
  Makefile: DIFF_OBJS is not special at all these days
  Makefile: flatten enumeration of headers, objects and programs
  Documentation/git-help: typofix
  Redo "add test_cmp function for test scripts"
  git-gui: Improve directions regarding POT update in po/README
  Resurrect git-rerere to contrib/examples
  Update draft release notes for 1.5.5
  t1000: use "test_must_fail git frotz", not "! git frotz"
  git-merge-one-file: fix longstanding stupid thinko
  Test: catch if trash cannot be removed
  Add tests to catch problems with un-unlinkable symlinks
  Fix read-tree not to discard errors
  remote.c: Fix overtight refspec validation
  gc --auto: raise default auto pack limit from 20 to 50
  GIT 1.5.5-rc1

Kevin Ballard (4):
  Add --reverse to the git-rev-list usage string
  Document the sendemail.smtpserverport config variable
  Don't try and percent-escape existing percent escapes in git-svn URIs
  Make git-svn tests behave better on OS X

Kristian Høgsberg (1):
  wt-status.c: no need for dup() dance anymore

Linus Torvalds (4):
  Fix recent 'unpack_trees()'-related changes breaking 'git stash'
  Don't update unchanged merge entries
  Fix possible Solaris problem in 'checkout_entry()'
  Make revision limiting more robust against occasional bad commit dates

Marius Storm-Olsen (1):
  git-p4: Optimize the fetching of data from perforce.

Michele Ballabio (4):
  gitk: Mark another string for translation
  git-gui: update Italian translation
  gitk: initial Italian translation
  git-gui: remove spurious "fuzzy" attributes in po/it.po

Miklos Vajna (3):
  Update Hungarian translation. 100% completed.
  git-gui: Updated Hungarian translation (e5fba18)
  Documentation/git-merge: document subtree strategy.

Nanako Shiraishi (2):
  git-gui: Update Japanese translation
  git-gui: Update Japanese translation

Nicolas Pitre (1):
  make it easier for people who just want to get rid of 'git gc --auto'

Paul Mackerras (3):
  gitk: Only restore window size from ~/.gitk, not position
  gitk: Avoid Tcl error when switching views
  gitk: Default to using po2msg.sh if msgfmt doesn't grok --tcl, -l and -d

Pekka Kaitaniemi (1):
  gitk: Add horizontal scrollbar to the diff view

Peter Karlsson (2):
  git-gui: Regenerated po template and merged translations with it
  git-gui: updated Swedish translation

Ping Yin (5):
  git-submodule summary: code framework
  git-submodule summary: show commit summary
  git-submodule summary: limit summary size
  git-submodule summary: documentation
  git-submodule summary: test

Ralf Wildenhues (1):
  Improve description of git filter-branch.

Shawn Bohrer (2):
  git-p4: Unset P4DIFF environment variable when using 'p4 -du diff'
  git-p4: Use P4EDITOR environment variable when set

Shawn O. Pearce (2):
  git-gui: Don't translate the special Apple menu
  git-gui: Adjusted Japanese translation to updated POT

Yann Dirson (1):
  Add an --argscmd flag to get the list of refs to show

What's in git.git (stable)

[Junio C Hamano]

Again with a handful fixes, the most important of which is for regression
introduced in 1.5.4 to "git fetch" (if you are using .git/branches/it to
name your remote repositories, "git fetch it" should update your local
"it" branch but it doesn't since the breakage), maybe we would need
another maintenance branch soon from 'maint'.

With fixes to a handful regressions in the changes that happened during
the 1.5.5 cycle, 'master' is nearling -rc2, which hopefully will happen
soon.  There still are one or two topics we may want to merge from 'next',
but at this point both testers and developers are encouraged to switch to
'master' if you have been using 'next' for your real work to catch the
last minute glitches.

----------------------------------------------------------------

* The 'maint' branch has these fixes since the last announcement.

Brandon Casey (1):
  t/t3800-mktag.sh: use test_must_fail rather than '!'

Daniel Barkalow (2):
  Tighten refspec processing
  Fix branches file configuration

Guanqun Lu (1):
  Fix the wrong output of `git-show v1.3.0~155^2~4` in documentation.

Jeff King (1):
  Documentation: clarify use of .git{ignore,attributes} versus .git/info/*

Junio C Hamano (2):
  git-fetch test: test tracking fetch results, not just FETCH_HEAD
  Update draft release notes for 1.5.4.5


* The 'master' branch has these since the last announcement
  in addition to the above.

Dirk Süsserott (1):
  Documentation: git-tag '-m'/'-F' implies '-a'

Frank Lichtenheld (1):
  t9600-cvsimport.sh: set HOME before checking for cvsps availability

Gerrit Pape (1):
  imap-send: properly error out if imap.host is not set in config

Guanqun Lu (1):
  Fix the wrong output of `git-show v1.3.0~155^2~4` in documentation.

Johannes Schindelin (2):
  RelNotes: mention checkout/branch's --track option, too
  init: show "Reinit" message even in an (existing) empty repository

Johannes Sixt (1):
  builtin-remote: Fix missing newline at end of listing of pushed branches

Julian Phillips (1):
  Documentation/git-checkout: Update summary to reflect current abilities

Junio C Hamano (3):
  refspec: allow colon-less wildcard "refs/category/*"
  test_must_fail: 129 is a valid error code from usage()
  Update draft release notes for 1.5.5

SZEDER Gábor (1):
  Always set *nongit_ok in setup_git_directory_gently()

What's in git.git (stable)

[Junio C Hamano]

A handful fixes are in 'master', and a few topics are still in 'next' as I
ran out of time this weekend.

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

Bryan Donlan (1):
  Silence cpio's "N blocks" output when cloning locally

Eric Wong (1):
  git-svn: remove redundant slashes from show-ignore

Junio C Hamano (4):
  builtin-prune: protect objects listed on the command line
  Add corner case tests for diff-index and diff-files
  diff-index: careful when inspecting work tree items
  diff-files: careful when inspecting work tree items

Marius Storm-Olsen (1):
  git-p4: Handle Windows EOLs properly after removal of p4 submit template
    handling.

Michele Ballabio (3):
  parse-options.c: introduce OPT_DATE
  Add tests for git-prune
  builtin-prune.c: use parse_options()

What's in git.git (stable)

[Junio C Hamano]

* The 'master' branch has these since the last announcement and we are now
  at 1.5.5-rc3.  The real 1.5.5 hopefully this weekend.

Brandon Casey (2):
  mktag.c: improve verification of tagger field and tests
  mktag.c: tweak validation of tagger field and adjust test script

Christian Couder (1):
  help: Add a missing OPT_END().

Damien Diederen (7):
  cvsserver: Respond to the 'editors' and 'watchers' commands
  cvsserver: Only print the file part of the filename in status header
  cvsserver: Do not include status output for subdirectories if -l is
    passed
  cvsserver: Add a few tests for 'status' command
  cvsserver: Implement update -p (print to stdout)
  cvsserver: Add test for update -p
  cvsserver: Use the user part of the email in log and annotate results

Johannes Sixt (3):
  filter-branch: Test renaming directories in a tree-filter
  verify-tag: Clean up the temporary file if gpg cannot be started.
  t7004-tag: Skip more tests if gpg is not available.

Jonathan del Strother (1):
  git-gui: Add shortcut keys for Show More/Less Context

Josh Elsasser (1):
  Allow git-cvsserver database table name prefix to be specified.

Junio C Hamano (2):
  Accept git aliases outside a git repository
  GIT 1.5.5-rc3

Paolo Bonzini (1):
  git-cvsserver: handle change type T

Shawn O. Pearce (1):
  git-gui 0.10

Teemu Likonen (1):
  Describe the bug in handling filenames with funny characters in 'git add
    -i'

veillette@yahoo.ca (1):
  filter-branch: Fix renaming a directory in the tree-filter

Re: What's in git.git (stable)

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> * The 'master' branch has these since the last announcement and we are now
>   at 1.5.5-rc3.  The real 1.5.5 hopefully this weekend.
...
> Shawn O. Pearce (1):
>   git-gui 0.10

0.10 is a dud on Linux.  My master branch has a bug fix, but I'm
considering bringing in Michele's patch before tagging 0.10.1.

So 0.10.1, most likely tagged in a few hours, should be in 1.5.5.
Otherwise Linux users of git-gui will be sort of pissed.

Damn.

-- 
Shawn.