v1.5.4 plans

v1.5.4 plans

[Junio C Hamano]

Please do not take this as the final decision made by the Emperor, whose
subjects now must follow.  This is a sanity-check to see if everybody is
on the same page.

I am not the Emperor anyway ;-)

Deprecation and Removal
-----------------------

 * We have already removed svnimport without giving a deprecation notice
   in the release notes of the previous feature release, which was bad.
   Maybe the users will forgive us.  Maybe not.

 * As discussed on the list, v1.5.4 will ship with the dashed form of
   commands (e.g. "git-commit") on users' PATH by default.  However we
   will move them outside the normal PATH (exact location needs to be
   decided by checking FHS first, something like /usr/libexec/git-core)
   in v1.5.5 so the release notes to v1.5.4 will declare deprecation
   (see the top of Documentation/RelNotes-1.5.4.txt).  We might want to
   keep copies of dashed form Porcelains in /usr/bin but that discussion
   is towards v1.5.5 (post v1.5.4, not now).

 * We also will give deprecation warning for the following features and
   commands in the release notes to v1.5.4, and remove them in v1.5.5:

   - lost-found (use fsck --lost-found);
   - post-update hook (use post-receive hook);
   - peek-remote (use ls-remote)


Topics not in 'master' yet but should be in v1.5.4
--------------------------------------------------

I think the following should go in, along with what we already have in
'master':

 * git-commit in C (Kristian and others)
 * git-add --patch (Wincent)
 * git-prune --expire (Dscho)
 * git-add --interactive coloring (Dan Zwell)
 * whitespace error classes in diff and patch, using gitattributes (Bruce and me)
 * cvsserver runs post-receive (Michael Witten)
 * git-rebase -i gives chance to rerere (Dscho)
 * git-rebase gives more appropriate help text (Wincent)
 * make refspec matching logic in git-push and git-fetch saner (Steffen Prohaska)
 * work-tree related minor fixes (Nguyen and Dscho)
 * allow update hook to munge commit (Steven Grimm)

I'd like to explicitly exclude topics about the following, although I
think there might be worthwhile ones among them to think about in the
longer term:

 * removing dashed form from the filesystem
 * teaching diff family about fileglob pathspecs
 * making it possible to omit leading paths from diff family output when
   run from a subdirectory

Re: v1.5.4 plans

[Jakub Narebski]

Does this mean we should be entering feature freeze?
Or at least feature freeze for 'master'?

-- 
Jakub Narebski

Re: v1.5.4 plans

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> Does this mean we should be entering feature freeze?
> Or at least feature freeze for 'master'?

I said "these are not in master but should be before v1.5.4", so master
is not frozen yet in that sense, but on the other hand, I want to stop
taking anything other than I explicitly listed to 'master' from now on.

So please take it as a "rfc feature freeze notice".

Re: v1.5.4 plans

[David Symonds]

On Dec 3, 2007 9:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Please do not take this as the final decision made by the Emperor, whose
> subjects now must follow.  This is a sanity-check to see if everybody is
> on the same page.
>
> I am not the Emperor anyway ;-)
>

> Topics not in 'master' yet but should be in v1.5.4
> --------------------------------------------------
>
> I think the following should go in, along with what we already have in
> 'master':

Can we add the git-status/git-checkout relative path stuff that's
currently been sitting in 'next'? It would be a good step forward for
usability.


Dave.

Re: v1.5.4 plans

[Junio C Hamano]

"David Symonds" <dsymonds@gmail.com> writes:

> On Dec 3, 2007 9:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Please do not take this as the final decision made by the Emperor, whose
>> subjects now must follow.  This is a sanity-check to see if everybody is
>> on the same page.
>>
>> I am not the Emperor anyway ;-)
>>
>
>> Topics not in 'master' yet but should be in v1.5.4
>> --------------------------------------------------
>>
>> I think the following should go in, along with what we already have in
>> 'master':
>
> Can we add the git-status/git-checkout relative path stuff that's
> currently been sitting in 'next'? It would be a good step forward for
> usability.

I think checkout from subdirectory with relative was merged on November
18th to master, with d577bc58.  Relative path output for git-status is
part of the "git-commit in C" series, which is planned to go in.

But now you mention it, I realize that I ran "git-topic.perl" (found in
my 'todo' branch) without "--all" option when I made that list, and I
missed stuff fully merged to 'next'.  Sorry.

Here is a corrected list.

Topics not in 'master' yet but should be in v1.5.4
--------------------------------------------------

I think the following should go in, along with what we already have in
'master':

 * git-commit in C (Kristian and others)
 * git-add --patch (Wincent)
 * git-prune --expire (Dscho)
 * git-add --interactive coloring (Dan Zwell)
 * whitespace error classes in diff and patch, using gitattributes (Bruce and me)
 * cvsserver runs post-receive (Michael Witten)
 * git-rebase -i gives chance to rerere (Dscho)
 * git-rebase gives more appropriate help text (Wincent)
 * make refspec matching logic in git-push and git-fetch saner (Steffen Prohaska)
 * work-tree related minor fixes (Nguyen and Dscho)
 * allow update hook to munge commit (Steven Grimm)
 * git-fast-export (Dscho)
 * Add commitdiff to gitweb grep page (Denis Cheng)
 * "git pull --rebase" (Dscho)
 * "git config --get-color" (me)
 * "color.diff = true" means "auto" (me)
 * Rewrite "export VAR=VAL" to "VAR=VAL; export VAR" (Dscho)
 * run correct perl in Documentation (me, waiting for Merlyn)

Many things pushed out to 'master'

[Junio C Hamano]

I've merged a handful topics that have been cooking in 'next' to
'master'.  Except for a few big topics still in 'next', this brings the
tip of 'master' much closer to what will become 1.5.4.

As always has been promised, the tip of 'master' is designed to be more
stable than any released version without introducing regression, and we
need to test how true that is from time to time ;-).

Please keep the fixes flowing.  The next batch will be "commit in C" and
"add --patch" series.

Re: Many things pushed out to 'master'

[Johannes Schindelin]

Hi,

On Mon, 3 Dec 2007, Junio C Hamano wrote:

> I've merged a handful topics that have been cooking in 'next' to 
> 'master'.  Except for a few big topics still in 'next', this brings the 
> tip of 'master' much closer to what will become 1.5.4.

I usually run off next + patches, so I do not know if fast-export already 
made it to "master".

But I remembered that you requested a mode for signed tags where they 
would just be copied.  I just realised while implementing "verbatim" that 
"ignore" does just that.  Maybe we should rename this mode to "verbatim"?

And maybe you want to make it the default (even if I think that this will 
result in more surprise moments than the current mode which aborts).

Ciao,
Dscho

Re: Many things pushed out to 'master'

[Junio C Hamano]

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

> But I remembered that you requested a mode for signed tags where they 
> would just be copied.  I just realised while implementing "verbatim" that 
> "ignore" does just that.  Maybe we should rename this mode to "verbatim"?
>
> And maybe you want to make it the default (even if I think that this will 
> result in more surprise moments than the current mode which aborts).

I did not hear others agreeing with me, so let's respect the original
author's thinking.

Re: Many things pushed out to 'master'

[Johannes Schindelin]

Hi,

On Mon, 3 Dec 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > But I remembered that you requested a mode for signed tags where they 
> > would just be copied.  I just realised while implementing "verbatim" 
> > that "ignore" does just that.  Maybe we should rename this mode to 
> > "verbatim"?
> >
> > And maybe you want to make it the default (even if I think that this 
> > will result in more surprise moments than the current mode which 
> > aborts).
> 
> I did not hear others agreeing with me, so let's respect the original 
> author's thinking.

But the original author already admitted that the original naming was 
stupid...

Ciao,
Dscho

Re: Many things pushed out to 'master'

[Junio C Hamano]

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

> Hi,
>
> On Mon, 3 Dec 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> > But I remembered that you requested a mode for signed tags where they 
>> > would just be copied.  I just realised while implementing "verbatim" 
>> > that "ignore" does just that.  Maybe we should rename this mode to 
>> > "verbatim"?
>> >
>> > And maybe you want to make it the default (even if I think that this 
>> > will result in more surprise moments than the current mode which 
>> > aborts).
>> 
>> I did not hear others agreeing with me, so let's respect the original 
>> author's thinking.
>
> But the original author already admitted that the original naming was 
> stupid...

Ok, send in updates, please.

[PATCH] fast-export: rename the signed tag mode 'ignore' to 'verbatim'

[Johannes Schindelin]

The name 'verbatim' describes much better what this mode does with
signed tags.  While at it, fix the documentation what it actually
does.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Mon, 3 Dec 2007, Junio C Hamano wrote:

	> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
	> 
	> > But the original author already admitted that the original 
	> > naming was stupid...
	> 
	> Ok, send in updates, please.

	Alright...

 Documentation/git-fast-export.txt |    4 ++--
 builtin-fast-export.c             |    8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
index 073ff7f..fd3d571 100644
--- a/Documentation/git-fast-export.txt
+++ b/Documentation/git-fast-export.txt
@@ -26,14 +26,14 @@ OPTIONS
 	Insert 'progress' statements every <n> objects, to be shown by
 	gitlink:git-fast-import[1] during import.
 
---signed-tags=(ignore|warn|strip|abort)::
+--signed-tags=(verbatim|warn|strip|abort)::
 	Specify how to handle signed tags.  Since any transformation
 	after the export can change the tag names (which can also happen
 	when excluding revisions) the signatures will not match.
 +
 When asking to 'abort' (which is the default), this program will die
 when encountering a signed tag.  With 'strip', the tags will be made
-unsigned, with 'ignore', they will be silently ignored (i.e. not exported)
+unsigned, with 'verbatim', they will be silently exported
 and with 'warn', they will be exported, but you will see a warning.
 
 
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index 72be45d..2136aad 100755
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -23,15 +23,15 @@ static const char *fast_export_usage[] = {
 };
 
 static int progress;
-static enum { IGNORE, WARN, STRIP, ABORT } signed_tag_mode = ABORT;
+static enum { VERBATIM, WARN, STRIP, ABORT } signed_tag_mode = ABORT;
 
 static int parse_opt_signed_tag_mode(const struct option *opt,
 				     const char *arg, int unset)
 {
 	if (unset || !strcmp(arg, "abort"))
 		signed_tag_mode = ABORT;
-	else if (!strcmp(arg, "ignore"))
-		signed_tag_mode = IGNORE;
+	else if (!strcmp(arg, "verbatim") || !strcmp(arg, "ignore"))
+		signed_tag_mode = VERBATIM;
 	else if (!strcmp(arg, "warn"))
 		signed_tag_mode = WARN;
 	else if (!strcmp(arg, "strip"))
@@ -270,7 +270,7 @@ static void handle_tag(const char *name, struct tag *tag)
 				warning ("Exporting signed tag %s",
 					 sha1_to_hex(tag->object.sha1));
 				/* fallthru */
-			case IGNORE:
+			case VERBATIM:
 				break;
 			case STRIP:
 				message_size = signature + 1 - message;
-- 
1.5.3.7.2120.g1a32

Re: [PATCH] fast-export: rename the signed tag mode 'ignore' to 'verbatim'

[Johannes Schindelin]

Hi,

On Mon, 3 Dec 2007, Johannes Schindelin wrote:

> The name 'verbatim' describes much better what this mode does with
> signed tags.  While at it, fix the documentation what it actually
> does.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---

Maybe you want to squash this, too (sorry, I sent the patch too soon, 
although the mode "ignore" is still accepted, and thus, the test 
succeeded):

-- snipsnap --
[PATCH] fast-export: test "verbatim", not "ignore"

The signed-tag-mode "ignore" was renamed to "verbatim", and although we 
still accept "ignore" as a synonym, it is better to test "verbatim".

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

---

 t/t9301-fast-export.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index e9c9fe6..f09bfb1 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -106,9 +106,9 @@ test_expect_success 'signed-tags=abort' '
 
 '
 
-test_expect_success 'signed-tags=ignore' '
+test_expect_success 'signed-tags=verbatim' '
 
-	git fast-export --signed-tags=ignore sign-your-name > output &&
+	git fast-export --signed-tags=verbatim sign-your-name > output &&
 	grep PGP output
 
 '

[PATCH] Fix quote_path when called with negative length.

[Pierre Habouzit]

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

When the len passed was -1, relative paths shortening was broken, resulting
in too long paths.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---

    On Sun, Dec 02, 2007 at 11:39:59PM +0000, David Symonds wrote:
    > On Dec 3, 2007 9:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
    > > Please do not take this as the final decision made by the Emperor, whose
    > > subjects now must follow.  This is a sanity-check to see if everybody is
    > > on the same page.
    > >
    > > I am not the Emperor anyway ;-)
    > >
    > 
    > > Topics not in 'master' yet but should be in v1.5.4
    > > --------------------------------------------------
    > >
    > > I think the following should go in, along with what we already have in
    > > 'master':
    > 
    > Can we add the git-status/git-checkout relative path stuff that's
    > currently been sitting in 'next'? It would be a good step forward for
    > usability.

    Speaking of which, there is this irritating bug in git status that
    let it show too long paths in the first chunk (the "tracked files"
    one).

    The previous version of the function was avoiding very hard to
    compute "in" length, and had quite convoluted code because of that.
    I now compute it at the beginning. The real issue was the:

 		while (prefix[off] && off < len && prefix[off] == in[off])

    line, when len is negative, the shortening never happens. I could
    have fixed it using ((len < 0 && in[off]) || off < len), but I
    disliked the resulting code, so I went for this.

    -- 
    ·O·  Pierre Habouzit
    ··O                                                madcoder@debian.org
    OOO                                                http://www.madism.org

 wt-status.c |   31 +++++++++++++------------------
 1 files changed, 13 insertions(+), 18 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index 0e0439f..eb2cbea 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -84,30 +84,25 @@ static void wt_status_print_trailer(struct wt_status *s)
 static char *quote_path(const char *in, int len,
 		struct strbuf *out, const char *prefix)
 {
-	if (len > 0)
-		strbuf_grow(out, len);
+	int pos = 0;
+
+	if (len < 0)
+		len = strlen(in);
+	strbuf_grow(out, len);
 	strbuf_setlen(out, 0);
 
 	if (prefix) {
 		int off = 0;
 		while (prefix[off] && off < len && prefix[off] == in[off])
-			if (prefix[off] == '/') {
-				prefix += off + 1;
-				in += off + 1;
-				len -= off + 1;
-				off = 0;
-			} else
-				off++;
-
-		for (; *prefix; prefix++)
-			if (*prefix == '/')
+			if (prefix[off++] == '/')
+				pos = off;
+		while (prefix[off])
+			if (prefix[off++] == '/')
 				strbuf_addstr(out, "../");
 	}
 
-	for (; (len < 0 && *in) || len > 0; in++, len--) {
-		int ch = *in;
-
-		switch (ch) {
+	for (; pos < len; pos++) {
+		switch (in[pos]) {
 		case '\n':
 			strbuf_addstr(out, "\\n");
 			break;
@@ -115,8 +110,8 @@ static char *quote_path(const char *in, int len,
 			strbuf_addstr(out, "\\r");
 			break;
 		default:
-			strbuf_addch(out, ch);
-			continue;
+			strbuf_addch(out, in[pos]);
+			break;
 		}
 	}
 
-- 
1.5.3.7.2065.g3d18-dirty


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

Re: [PATCH] Fix quote_path when called with negative length.

[Jeff King]

On Mon, Dec 03, 2007 at 10:06:52AM +0100, Pierre Habouzit wrote:

>     Speaking of which, there is this irritating bug in git status that
>     let it show too long paths in the first chunk (the "tracked files"
>     one).

It was annoying me, too. See the thread 'quote_path: fix collapsing of
relative paths'.

-Peff

Re: v1.5.4 plans

[Nicolas Pitre]

On Sun, 2 Dec 2007, Junio C Hamano wrote:

> Please do not take this as the final decision made by the Emperor, whose
> subjects now must follow.  This is a sanity-check to see if everybody is
> on the same page.
> 
> I am not the Emperor anyway ;-)

Emperor of the Rising Sun.  ;-)

> Deprecation and Removal
> -----------------------
> 
>  * We also will give deprecation warning for the following features and
>    commands in the release notes to v1.5.4, and remove them in v1.5.5:
> 
>    - lost-found (use fsck --lost-found);
>    - post-update hook (use post-receive hook);
>    - peek-remote (use ls-remote)

Two things I would like to see in the next version (1.5.5) as well, for 
which we could provide early warnings now:

 - repack.usedeltabaseoffset defaulting to true

 - pack.indexversion defaulting to 2


Nicolas

Re: v1.5.4 plans

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> Two things I would like to see in the next version (1.5.5) as well, for 
> which we could provide early warnings now:
>
>  - repack.usedeltabaseoffset defaulting to true
>
>  - pack.indexversion defaulting to 2

I think the former would be sensible, the latter I fear might be a bit
too new but I do not recall the exact version dependency.

Could you draft a patch to ReleaseNotes to explain the consequences of
these changes using ordinary user's vocabulary, like:

	Starting v1.5.5, repack.usedeltabaseoffset will default to true,
	which will give denser packfile (i.e. more efficient storage).
	The downside is that git older than version X will not be able
	to use a repository packed using this setting.

[PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

Signed-off-by: Nicolas Pitre <nico@cam.org>

---

On Mon, 3 Dec 2007, Junio C Hamano wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > Two things I would like to see in the next version (1.5.5) as well, for 
> > which we could provide early warnings now:
> >
> >  - repack.usedeltabaseoffset defaulting to true
> >
> >  - pack.indexversion defaulting to 2
> 
> I think the former would be sensible, the latter I fear might be a bit
> too new but I do not recall the exact version dependency.
> 
> Could you draft a patch to ReleaseNotes to explain the consequences of
> these changes using ordinary user's vocabulary, like:
> 
> 	Starting v1.5.5, repack.usedeltabaseoffset will default to true,
> 	which will give denser packfile (i.e. more efficient storage).
> 	The downside is that git older than version X will not be able
> 	to use a repository packed using this setting.

Here it is.

diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt
index 6645565..d6fd3dd 100644
--- a/Documentation/RelNotes-1.5.4.txt
+++ b/Documentation/RelNotes-1.5.4.txt
@@ -43,6 +43,17 @@ Deprecation notices
  * "git peek-remote" is deprecated, as "git ls-remote" was written in C
    and works for all transports, and will be removed in the future.
 
+ * From v1.5.5, the repack.usedeltabaseoffset config option will default
+   to true, which will give denser packfile (i.e. more efficient storage).
+   The downside is that git older than version 1.4.4 will not be able
+   to directly use a repository packed using this setting.
+
+ * From v1.5.5, the pack.indexversion config option will default to 2,
+   which is slightly more efficient, and makes repacking more immune to
+   data corruptions.  Git older than version 1.5.2 may revert to version 1
+   of the pack index with a manual "git index-pack" to be able to directly
+   access corresponding pack files.
+
 
 Updates since v1.5.3
 --------------------

Re: [PATCH] provide advance warning of some future pack default changes

[Junio C Hamano]

Thanks.

Deprecating versions before 1.5.2 (May 20 2007) feels a bit too quick,
but seven month is almost an eternity in git timescale, and by now
anything older than 1.5.2 can safely be called prehistoric.  Will apply.

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Thu, 13 Dec 2007, Junio C Hamano wrote:

> Thanks.
> 
> Deprecating versions before 1.5.2 (May 20 2007) feels a bit too quick,
> but seven month is almost an eternity in git timescale, and by now
> anything older than 1.5.2 can safely be called prehistoric.  Will apply.

Well, index version 1 is not gone.  It's only the version used by 
default that will change, which can be overriden with a config variable.

And even if that wasn't done, then any old Git version can just blow 
away the new index and recreate it.  So it is not like if you actually 
needed a recent version of Git to convert the repo back to the old 
format.

And all this will be effective in 1.5.5 which is still a few months 
ahead.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Jakub Narebski]

Nicolas Pitre <nico@cam.org> writes:

> + * From v1.5.5, the repack.usedeltabaseoffset config option will default
> +   to true, which will give denser packfile (i.e. more efficient storage).
> +   The downside is that git older than version 1.4.4 will not be able
> +   to directly use a repository packed using this setting.
> +
> + * From v1.5.5, the pack.indexversion config option will default to 2,
> +   which is slightly more efficient, and makes repacking more immune to
> +   data corruptions.  Git older than version 1.5.2 may revert to version 1
> +   of the pack index with a manual "git index-pack" to be able to directly
> +   access corresponding pack files.

Which means what? Local clone with shortcut (hardlinking and remotes)?
Dumb protocols (http, ftp, rsync)?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Fri, 14 Dec 2007, Jakub Narebski wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > + * From v1.5.5, the repack.usedeltabaseoffset config option will default
> > +   to true, which will give denser packfile (i.e. more efficient storage).
> > +   The downside is that git older than version 1.4.4 will not be able
> > +   to directly use a repository packed using this setting.
> > +
> > + * From v1.5.5, the pack.indexversion config option will default to 2,
> > +   which is slightly more efficient, and makes repacking more immune to
> > +   data corruptions.  Git older than version 1.5.2 may revert to version 1
> > +   of the pack index with a manual "git index-pack" to be able to directly
> > +   access corresponding pack files.
> 
> Which means what? Local clone with shortcut (hardlinking and remotes)?
> Dumb protocols (http, ftp, rsync)?

Right, or simply shared repo over NFS or the like.

The 1.5.5 release notes will contain a note reminding people to set the 
corresponding config variables if they wish to retain the legacy 
behaviors.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Joel Becker]

On Fri, Dec 14, 2007 at 08:38:51AM -0500, Nicolas Pitre wrote:
> On Fri, 14 Dec 2007, Jakub Narebski wrote:
> > Which means what? Local clone with shortcut (hardlinking and remotes)?
> > Dumb protocols (http, ftp, rsync)?
> 
> Right, or simply shared repo over NFS or the like.
> 
> The 1.5.5 release notes will contain a note reminding people to set the 
> corresponding config variables if they wish to retain the legacy 
> behaviors.

	We've seen that release notes are a poor way to communicate
this.  What will happen to a 1.4.4 user when they try to access the
repository?  Corruption, cryptic error message, or clean "this repo is
not compatible" message?

Joel

-- 

"Depend on the rabbit's foot if you will, but remember, it didn't
 help the rabbit."
	- R. E. Shay

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Fri, 14 Dec 2007, Joel Becker wrote:

> On Fri, Dec 14, 2007 at 08:38:51AM -0500, Nicolas Pitre wrote:
> > On Fri, 14 Dec 2007, Jakub Narebski wrote:
> > > Which means what? Local clone with shortcut (hardlinking and remotes)?
> > > Dumb protocols (http, ftp, rsync)?
> > 
> > Right, or simply shared repo over NFS or the like.
> > 
> > The 1.5.5 release notes will contain a note reminding people to set the 
> > corresponding config variables if they wish to retain the legacy 
> > behaviors.
> 
> 	We've seen that release notes are a poor way to communicate
> this.  What will happen to a 1.4.4 user when they try to access the
> repository?  Corruption, cryptic error message, or clean "this repo is
> not compatible" message?

There won't be any corruption.

In the best case there will be a message along "x is not supported by 
this version of Git -- please consider upgrading".  In the worst case 
it'll say "x is bad".

But you know what? repositories with the change affecting 1.4.4 users 
are _already_ out there and no one complained recently.  Anyone pushing 
changes over the native Git protocol is already using deltabaseoffset as 
the native protocol negociate that capability in its handshake, and 
these days we keep packs as is on the receiving side when they're large 
enough.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Joel Becker]

On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:
> On Fri, 14 Dec 2007, Joel Becker wrote:
> > 	We've seen that release notes are a poor way to communicate
> > this.  What will happen to a 1.4.4 user when they try to access the
> > repository?  Corruption, cryptic error message, or clean "this repo is
> > not compatible" message?
> 
> There won't be any corruption.
> 
> In the best case there will be a message along "x is not supported by 
> this version of Git -- please consider upgrading".  In the worst case 
> it'll say "x is bad".

	That would be excellent, especially the former message.
 
> But you know what? repositories with the change affecting 1.4.4 users 
> are _already_ out there and no one complained recently.  Anyone pushing 

	I did, as did people I work with.  It's on git-list, even.  I'm
pretty sure it corrupted too.

Joel

-- 

"Practice random acts of kindness and senseless acts of beauty."

 Oh, and don't forget where your towel is.

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Fri, 14 Dec 2007, Joel Becker wrote:

> On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:
> > But you know what? repositories with the change affecting 1.4.4 users 
> > are _already_ out there and no one complained recently.  Anyone pushing 
> 
> 	I did, as did people I work with.  It's on git-list, even.  I'm
> pretty sure it corrupted too.

Could you please give me a reference to such message, so to verify that 
we're actually talking about the same thing?


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Joel Becker]

On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre wrote:
> On Fri, 14 Dec 2007, Joel Becker wrote:
> 
> > On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:
> > > But you know what? repositories with the change affecting 1.4.4 users 
> > > are _already_ out there and no one complained recently.  Anyone pushing 
> > 
> > 	I did, as did people I work with.  It's on git-list, even.  I'm
> > pretty sure it corrupted too.
> 
> Could you please give me a reference to such message, so to verify that 
> we're actually talking about the same thing?

	The relevant message is:

Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>

See the paragraphs at the bottom.  The thread, started by me, begins
with:

Message-ID: <20070910205429.GE27837@tasint.org>

Joel

-- 

"You must remember this:
 A kiss is just a kiss,
 A sigh is just a sigh.
 The fundamental rules apply
 As time goes by."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Fri, 14 Dec 2007, Joel Becker wrote:

> On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre wrote:
> > On Fri, 14 Dec 2007, Joel Becker wrote:
> > 
> > > On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:
> > > > But you know what? repositories with the change affecting 1.4.4 users 
> > > > are _already_ out there and no one complained recently.  Anyone pushing 
> > > 
> > > 	I did, as did people I work with.  It's on git-list, even.  I'm
> > > pretty sure it corrupted too.
> > 
> > Could you please give me a reference to such message, so to verify that 
> > we're actually talking about the same thing?
> 
> 	The relevant message is:
> 
> Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
> 
> See the paragraphs at the bottom.  The thread, started by me, begins
> with:
> 
> Message-ID: <20070910205429.GE27837@tasint.org>

I don't have such emails in my mail folders anymore.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Johannes Schindelin]

Hi,

On Fri, 14 Dec 2007, Nicolas Pitre wrote:

> On Fri, 14 Dec 2007, Joel Becker wrote:
> 
> > On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre wrote:
> > > On Fri, 14 Dec 2007, Joel Becker wrote:
> > > 
> > > > On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:
> > > > > But you know what? repositories with the change affecting 1.4.4 users 
> > > > > are _already_ out there and no one complained recently.  Anyone pushing 
> > > > 
> > > > 	I did, as did people I work with.  It's on git-list, even.  I'm
> > > > pretty sure it corrupted too.
> > > 
> > > Could you please give me a reference to such message, so to verify that 
> > > we're actually talking about the same thing?
> > 
> > 	The relevant message is:
> > 
> > Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
> > 
> > See the paragraphs at the bottom.  The thread, started by me, begins
> > with:
> > 
> > Message-ID: <20070910205429.GE27837@tasint.org>
> 
> I don't have such emails in my mail folders anymore.

GMane does not seem to have it, either:

	http://mid.gmane.org/20070910205429.GE27837@tasint.org

returns "No such article".

Ciao,
Dscho

Re: [PATCH] provide advance warning of some future pack default changes

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Fri, 14 Dec 2007, Joel Becker wrote:
>
>> > Could you please give me a reference to such message, so to verify that 
>> > we're actually talking about the same thing?
>> 
>> 	The relevant message is:
>> 
>> Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
>> 
>> See the paragraphs at the bottom.  The thread, started by me, begins
>> with:
>> 
>> Message-ID: <20070910205429.GE27837@tasint.org>
>
> I don't have such emails in my mail folders anymore.

-- >8 --

Date:	Mon, 10 Sep 2007 13:54:29 -0700
From:	Joel Becker <Joel.Becker@oracle.com>
To:	git@vger.kernel.org
Subject: Remote branches and better documentation
Message-ID: <20070910205429.GE27837@tasint.org>
Sender:	git-owner@vger.kernel.org

Junio et al,
	Git is a fast moving target, so some of this obviously needs a
grain of salt.  However, I'd like to make a couple of humble suggestions
and ask one simple question.
	First, the question:  Is there a syntax to git clone that
creates the old-style branches?  That is, you get all the branches
locally, for people that either haven't learned "git branch -r" or have
existing scripts that expect the branch to exist?  I can't find anything
in the git clone manpage.
	The suggestions are pretty simple.  First, when behavior is
changed invisibly (as the remote branch stuff was), can we note it in
the documentation?  I don't mean the ChangeLog, I mean the manpage.  I
personally already knew about "branch -r" because I read this list.  A
coworker of mine, who just uses git, spent an hour trying to find his
branches after a clone with git 1.5.  He thought his clone had failed.
He read the manpage, and there was no big "Hey, those of you used to
the old behavior, it changed!".  The single sentence about "remote
tracking branches" clearly isn't enough for folks that don't follow the
development side.  If we're going to take the liberty of changing
expected behavior silently, we should be giving it its own section in
the manpage.
	The second suggestion is related.  When an invisible change has
made the repository incompatible with older versions, we should make
sure that things behave.  We had some repositories cloned via 1.4.2.  Do
some work with 1.5.0.6 (on a different machine), then go back to the
machine with 1.4.2, and 1.4.2 doesn't work.  In fact, it can mess things
up.  He was doing simple things: pull from Linus, switch branches, etc.
If this is going to be incompatible, then the newer stuff should at
least warn about it, if not outright prevent 1.4 from running.
	These sorts of things make fast-moving changes workable.

Joel

-- >8 --

Date:	Mon, 10 Sep 2007 19:27:34 -0700
Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
Sender:	git-owner@vger.kernel.org

Joel Becker <Joel.Becker@oracle.com> writes:

> On Tue, Sep 11, 2007 at 02:05:34AM +0200, Wincent Colaiuta wrote:
>> But that's precisely the group release notes are for; existing users who 
>> need to be informed of any changes to the way things work.
>
> 	No one reads the changelogs of 100 packages updated via "yum
> update".  Heck, they don't even see the list of packages.  They just
> switch to a different desktop while it runs.

Distros are not something under my control, so I cannot help you
much there.

> 	Then there's the user that doesn't administer the system.  They
> don't even know the version changed.  It Just Breaks, and they don't
> know why.

That's a valid concern, but I am not sure how you would want to
address that issue.  Design constraints are:

 - you cannot change the old software that is not updated on the
   user's box;

 - you cannot afford to write something to the repository to
   mark the latest version that mucked with the repository every
   time any operation happens;

We _could_ check presence of $HOME/.knows-git-version-X.Y.Z file
every time we run (that's just a single stat(2) call that cannot
be too expensive) and if there isn't one, ask the user if he has
read the release notes and understood the backward compatibility
issues if there is any, and refuse to run until getting a
satisfactory answer.

But I personally do not think that would be an improvement.

After reviewing Release Notes for v1.5.0, I do not think we
could have done much better, unfortunately.

    As of git v1.5.0 there are some optional features that changes
    the repository to allow data to be stored and transferred more
    efficiently.  These features are not enabled by default, as they
    will make the repository unusable with older versions of git.
    Specifically, the available options are:

     - There is a configuration variable core.legacyheaders that
       changes the format of loose objects so that they are more
       efficient to pack and to send out of the repository over git
       native protocol, since v1.4.2.  However, loose objects
       written in the new format cannot be read by git older than
       that version; people fetching from your repository using
       older clients over dumb transports (e.g. http) using older
       versions of git will also be affected.

       To let git use the new loose object format, you have to
       set core.legacyheaders to false.

     - Since v1.4.3, configuration repack.usedeltabaseoffset allows
       packfile to be created in more space efficient format, which
       cannot be read by git older than that version.

       To let git use the new format for packfiles, you have to
       set repack.usedeltabaseoffset to true.

    The above two new features are not enabled by default and you
    have to explicitly ask for them, because they make repositories
    unreadable by older versions of git, and in v1.5.0 we still do
    not enable them by default for the same reason.  We will change
    this default probably 1 year after 1.4.2's release, when it is
    reasonable to expect everybody to have new enough version of
    git.

     - 'git pack-refs' appeared in v1.4.4; this command allows tags
       to be accessed much more efficiently than the traditional
       'one-file-per-tag' format.  Older git-native clients can
       still fetch from a repository that packed and pruned refs
       (the server side needs to run the up-to-date version of git),
       but older dumb transports cannot.  Packing of refs is done by
       an explicit user action, either by use of "git pack-refs
       --prune" command or by use of "git gc" command.

So everything was opt in and clearly marked as such.  You may
not have read it, distros may not have shown it, but then that
is something we cannot do much about, unfortunately.

I think there was _one_ honest slippage though.  Fetching from
1.5.0 peer by 1.5.0 client could (after doing content
negotiation between both ends as a protection measure) create a
packfile that cannot be read by older 1.4 clients.  Obviously
you cannot expect that kind of "protection" to work across set
of machines with mixed versions sharing a repository over NFS,
and that probably is a mistake we can learn from.

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Fri, 14 Dec 2007, Joel Becker wrote:

> On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre wrote:
> > On Fri, 14 Dec 2007, Joel Becker wrote:
> > 
> > > On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:
> > > > But you know what? repositories with the change affecting 1.4.4 users 
> > > > are _already_ out there and no one complained recently.  Anyone pushing 
> > > 
> > > 	I did, as did people I work with.  It's on git-list, even.  I'm
> > > pretty sure it corrupted too.
> > 
> > Could you please give me a reference to such message, so to verify that 
> > we're actually talking about the same thing?
> 
> 	The relevant message is:
> 
> Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
> 
> See the paragraphs at the bottom.  The thread, started by me, begins
> with:
> 
> Message-ID: <20070910205429.GE27837@tasint.org>

OK.  From those emails Junio forwarded to me, I don't see any case for 
actual _corruptions_.  Git does indeed refuse to work with unknown pack 
index or unknown objects in a pack.  Really old versions were not overly 
clueful as to why they refused to work, but they should never corrupt a 
pack which, for all purposes, is always read-only anyway.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Joel Becker]

On Fri, Dec 14, 2007 at 09:23:38PM -0500, Nicolas Pitre wrote:
> On Fri, 14 Dec 2007, Joel Becker wrote:
> > 	The relevant message is:
> > 
> > Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
> > 
> > See the paragraphs at the bottom.  The thread, started by me, begins
> > with:
> > 
> > Message-ID: <20070910205429.GE27837@tasint.org>
> 
> OK.  From those emails Junio forwarded to me, I don't see any case for 
> actual _corruptions_.  Git does indeed refuse to work with unknown pack 
> index or unknown objects in a pack.  Really old versions were not overly 
> clueful as to why they refused to work, but they should never corrupt a 
> pack which, for all purposes, is always read-only anyway.

	You may not see a case for actual corruptions, but my coworker
updated his tree on a box with 1.5.x, then tried to work on a box with
1.4.x (I think 1.4.2 back then), and ended up with a tree that was
unusable.  He had to re-clone, and I think he got lucky recovering
pending changes (probably using 1.5.x on the branches with the changes,
as master was what got broken).
	My point is not that change is always bad, but that we should
really look forward to what we're doing, and that "it's in the release
notes" is not sufficient if an older git gives an incomprehensible error
or a silent problem.  I was responding to the cavalier statement "well,
it's in the release notes, so don't worry about older versions".

Joel

-- 

"Vote early and vote often." 
        - Al Capone

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Mon, 17 Dec 2007, Joel Becker wrote:

> On Fri, Dec 14, 2007 at 09:23:38PM -0500, Nicolas Pitre wrote:
> > On Fri, 14 Dec 2007, Joel Becker wrote:
> > > 	The relevant message is:
> > > 
> > > Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
> > > 
> > > See the paragraphs at the bottom.  The thread, started by me, begins
> > > with:
> > > 
> > > Message-ID: <20070910205429.GE27837@tasint.org>
> > 
> > OK.  From those emails Junio forwarded to me, I don't see any case for 
> > actual _corruptions_.  Git does indeed refuse to work with unknown pack 
> > index or unknown objects in a pack.  Really old versions were not overly 
> > clueful as to why they refused to work, but they should never corrupt a 
> > pack which, for all purposes, is always read-only anyway.
> 
> 	You may not see a case for actual corruptions, but my coworker
> updated his tree on a box with 1.5.x, then tried to work on a box with
> 1.4.x (I think 1.4.2 back then), and ended up with a tree that was
> unusable.  He had to re-clone, and I think he got lucky recovering
> pending changes (probably using 1.5.x on the branches with the changes,
> as master was what got broken).

I still claim that there wasn't any corruptions.

Just for fun, just edit some document with Microsoft Office 95, then 
open the same document with Office 2007 and save it with default 
settings.  Now try to open it back with Office 95.  It won't work.  
Does that mean that the document got corrupted?

> 	My point is not that change is always bad, but that we should
> really look forward to what we're doing, and that "it's in the release
> notes" is not sufficient if an older git gives an incomprehensible error
> or a silent problem.  I was responding to the cavalier statement "well,
> it's in the release notes, so don't worry about older versions".

Your allegation of corruptions is cavalier just as well.

I'm telling you that there won't be any such corruption.  Just like in 
the M$ Office case, it is expected that newer versions make data 
unusable by older versions at some point -- that's the inevitable side 
effect of progress.

And we cannot always anticipate what kind of incompatibility will be 
worth making in the future, so it is hard to come with proper error 
messages in all cases today.

Recent enough Git versions do suggest upgrading when they refuse to 
access repositories though, and later Git versions can be configured to 
remain compatible with old Git versions.  And we also document it.

And when you still cannot figure it out on your own, then there is that 
free support available on a public mailing list, and even an IRC 
channel.

So I don't see how we could do better in that regard.  Carving the 
repository format in stone to keep ancient versions working forever is 
_not_ a solution.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Joel Becker]

On Mon, Dec 17, 2007 at 03:41:24PM -0500, Nicolas Pitre wrote:
> On Mon, 17 Dec 2007, Joel Becker wrote:
> > 	You may not see a case for actual corruptions, but my coworker
> > updated his tree on a box with 1.5.x, then tried to work on a box with
> > 1.4.x (I think 1.4.2 back then), and ended up with a tree that was
> > unusable.  He had to re-clone, and I think he got lucky recovering
> > pending changes (probably using 1.5.x on the branches with the changes,
> > as master was what got broken).
> 
> I still claim that there wasn't any corruptions.
> 
> Just for fun, just edit some document with Microsoft Office 95, then 
> open the same document with Office 2007 and save it with default 
> settings.  Now try to open it back with Office 95.  It won't work.  
> Does that mean that the document got corrupted?

	No, but when you try to re-open it with Office 2007, you expect
it to work, don't you?  His master was messed up even for 1.5.x.  It was
now months ago, so I don't quite remember all the details, but I think
you'd agree that "1.5.x no longer works" is not correct.

> I'm telling you that there won't be any such corruption.  Just like in 
> the M$ Office case, it is expected that newer versions make data 
> unusable by older versions at some point -- that's the inevitable side 
> effect of progress.

	Sure, we're not complaining about that.  We complain some about
the fast pace (at the time he had his problem, 1.4 installs were not
unusual, and Junio's response suggested that "I use NFS" wasn't strongly
considered as a use case), but more we complain about the obscurity of
the reason.  If it's obvious what happened (not the specifics, just
"please upgrade" or "repository format changed" or something), the user
moves along.

> And we cannot always anticipate what kind of incompatibility will be 
> worth making in the future, so it is hard to come with proper error 
> messages in all cases today.

	How hard is it?  We have core.repositoryformatversion.  We
undoubtably have headers on our files.  As an example, an older version
should be able to ascertain 1) this is a pack file 2) I don't know how
to read it.  Thus, it should always be able to tell the user as such.
This is different from reporting "invalid pack file" or "corrupt pack
file", or "garbage in tree".  Filesystems, as an example, set
compatibility bits or version levels.  When an old kernel tries to mount
it, it does not say "corrupt filesystem", it says "this filesystem has a
feature I don't understand, I'm going to be nice and not do anything,
please upgrade".  This is clear, even though the older kernel doesn't
have any specifics about what the new feature is.

> So I don't see how we could do better in that regard.  Carving the 
> repository format in stone to keep ancient versions working forever is 
> _not_ a solution.

	Once again, we're not asking for that.  We're asking that you
think ahead to what can change, and plan for it, so you can tell the
user.  If the user has a clear idea where to go next, the can solve the
rest themselves.
	Look, not everyone reads this mailing list.  No one outside of
this list reads the Release Notes.  They get their upgrade via yum or
apt-get, along with 100 other packages.  You can't assume that 3 months
of feature discussion here is going to be known to your average user.

Joel

-- 

"Vote early and vote often." 
        - Al Capone

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: [PATCH] provide advance warning of some future pack default changes

[J. Bruce Fields]

On Mon, Dec 17, 2007 at 01:13:18PM -0800, Joel Becker wrote:
> 	Sure, we're not complaining about that.  We complain some about
> the fast pace (at the time he had his problem, 1.4 installs were not
> unusual, and Junio's response suggested that "I use NFS" wasn't strongly
> considered as a use case), but more we complain about the obscurity of
> the reason.  If it's obvious what happened (not the specifics, just
> "please upgrade" or "repository format changed" or something), the user
> moves along.

By the way, just as a data point: I do keep some git repositories on
NFS, and access them from multiple machines with different git versions
(not on purpose--it's just that the machines don't all run the same
distro, so it'd be extra work to give them all the same version).  I
don't use anything older than 1.5.0.  If the repository became unusable
on one of those machines without warning it'd be annoying.

---b.

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Mon, 17 Dec 2007, J. Bruce Fields wrote:

> By the way, just as a data point: I do keep some git repositories on
> NFS, and access them from multiple machines with different git versions
> (not on purpose--it's just that the machines don't all run the same
> distro, so it'd be extra work to give them all the same version).  I
> don't use anything older than 1.5.0.  If the repository became unusable
> on one of those machines without warning it'd be annoying.

What the v1.5.5 release notes will say is that you'll have to set 
pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.  

And even if you forget about it then there'll be a simple way to regain 
compatibility after the facts.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[J. Bruce Fields]

On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
> On Mon, 17 Dec 2007, J. Bruce Fields wrote:
> 
> > By the way, just as a data point: I do keep some git repositories on
> > NFS, and access them from multiple machines with different git versions
> > (not on purpose--it's just that the machines don't all run the same
> > distro, so it'd be extra work to give them all the same version).  I
> > don't use anything older than 1.5.0.  If the repository became unusable
> > on one of those machines without warning it'd be annoying.
> 
> What the v1.5.5 release notes will say is that you'll have to set 
> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.  

Is there any reason not to make pack.indexversion=1 the default (for
preexisting repositories at the very least) and suggest in the release
notes that people set something else if they want the features the new
version provides?

--b.

> And even if you forget about it then there'll be a simple way to regain 
> compatibility after the facts.

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Mon, 17 Dec 2007, J. Bruce Fields wrote:

> On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
> > On Mon, 17 Dec 2007, J. Bruce Fields wrote:
> > 
> > > By the way, just as a data point: I do keep some git repositories on
> > > NFS, and access them from multiple machines with different git versions
> > > (not on purpose--it's just that the machines don't all run the same
> > > distro, so it'd be extra work to give them all the same version).  I
> > > don't use anything older than 1.5.0.  If the repository became unusable
> > > on one of those machines without warning it'd be annoying.
> > 
> > What the v1.5.5 release notes will say is that you'll have to set 
> > pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.  
> 
> Is there any reason not to make pack.indexversion=1 the default (for
> preexisting repositories at the very least) and suggest in the release
> notes that people set something else if they want the features the new
> version provides?

That's already the case now.

But the thing is that index version 2 is better and actually plug a flaw 
in the repacking process where unnoticed corruption could be repacked 
otherwise.  So for better repo integrity sake, it has to become the 
default at some point.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Junio C Hamano]

"J. Bruce Fields" <bfields@fieldses.org> writes:

> On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
>> On Mon, 17 Dec 2007, J. Bruce Fields wrote:
>> 
>> > By the way, just as a data point: I do keep some git repositories on
>> > NFS, and access them from multiple machines with different git versions
>> > (not on purpose--it's just that the machines don't all run the same
>> > distro, so it'd be extra work to give them all the same version).  I
>> > don't use anything older than 1.5.0.  If the repository became unusable
>> > on one of those machines without warning it'd be annoying.
>> 
>> What the v1.5.5 release notes will say is that you'll have to set 
>> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.  
>
> Is there any reason not to make pack.indexversion=1 the default (for
> preexisting repositories at the very least) and suggest in the release
> notes that people set something else if they want the features the new
> version provides?

That's a judgement call.

Pack-idx format v2 is by design much safer in the face of bitflip (do we
have a test case to make sure this is indeed true?).  But from the end
user's point of view, all the usual "I do not want to be forced to
update that old box I do not want to touch" applies.

And the people who needs to suffer from the dilemma are only the ones
who access a single repository across NFS with git from different
vintage.  If that is a minority and/or tends to be more clueful people,
the inconvenience factor may be outweighed by the advantage v2 offers,
and pushing adoption of v2 harder the way Nico is driving at would
generally be a good thing.

Re: [PATCH] provide advance warning of some future pack default changes

[J. Bruce Fields]

On Mon, Dec 17, 2007 at 02:17:01PM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
> > On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
> >> On Mon, 17 Dec 2007, J. Bruce Fields wrote:
> >> 
> >> > By the way, just as a data point: I do keep some git repositories on
> >> > NFS, and access them from multiple machines with different git versions
> >> > (not on purpose--it's just that the machines don't all run the same
> >> > distro, so it'd be extra work to give them all the same version).  I
> >> > don't use anything older than 1.5.0.  If the repository became unusable
> >> > on one of those machines without warning it'd be annoying.
> >> 
> >> What the v1.5.5 release notes will say is that you'll have to set 
> >> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.  
> >
> > Is there any reason not to make pack.indexversion=1 the default (for
> > preexisting repositories at the very least) and suggest in the release
> > notes that people set something else if they want the features the new
> > version provides?
> 
> That's a judgement call.

Sure.  And I'm totally unfamiliar with the details here, so don't my let
my judgement weigh too heavily.

> Pack-idx format v2 is by design much safer in the face of bitflip (do we
> have a test case to make sure this is indeed true?).  But from the end
> user's point of view, all the usual "I do not want to be forced to
> update that old box I do not want to touch" applies.
> 
> And the people who needs to suffer from the dilemma are only the ones
> who access a single repository across NFS with git from different
> vintage.

Hm.  We tell people to set up public repo's by doing something like:

	git clone --bare ~/proj proj.git
	touch proj.git/git-daemon-export-ok
	scp -r proj.git example.com:

Is that going to hit the same problem if the public server has an older
git version?  (Servers do tend to be on longer upgrade cycles; the
public server I use was on something 1.4ish till about a month ago.)

--b.

Re: [PATCH] provide advance warning of some future pack default changes

[Junio C Hamano]

"J. Bruce Fields" <bfields@fieldses.org> writes:

> Hm.  We tell people to set up public repo's by doing something like:
>
> 	git clone --bare ~/proj proj.git
> 	touch proj.git/git-daemon-export-ok
> 	scp -r proj.git example.com:
>
> Is that going to hit the same problem if the public server has an older
> git version?

It will, but I think you should teach people --mirror pushing these
days, which was specifically invented for priming the public
repository.

That way, the administrator at example.com, as long as he initializes an
empty repository with suitable daemon-export-ok and necessary hooks
(which can be automated via templates), does not even have to allow you
a full ssh access.

Re: [PATCH] provide advance warning of some future pack default changes

[J. Bruce Fields]

On Mon, Dec 17, 2007 at 02:55:15PM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
> > Hm.  We tell people to set up public repo's by doing something like:
> >
> > 	git clone --bare ~/proj proj.git
> > 	touch proj.git/git-daemon-export-ok
> > 	scp -r proj.git example.com:
> >
> > Is that going to hit the same problem if the public server has an older
> > git version?
> 
> It will, but I think you should teach people --mirror pushing these
> days, which was specifically invented for priming the public
> repository.
>
> That way, the administrator at example.com, as long as he initializes an
> empty repository with suitable daemon-export-ok and necessary hooks
> (which can be automated via templates), does not even have to allow you
> a full ssh access.

So the basic instructions would be something like this?:

	ssh example.com "git init --bare myproj.git"
	# (or ask your admin to do the previous step)
	git add remote example example.com:myproj.git
	git push --mirror example

OK, that's neat, thanks.

On the backwards-compatibility issue, though: this won't help the large
number of people who learned to just clone a bare repo and copy it
around, since they aren't of their own initiative going to seek out new
ways of doing things that they think they already know how to do.

--b.

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Mon, 17 Dec 2007, Junio C Hamano wrote:

> Pack-idx format v2 is by design much safer in the face of bitflip (do we
> have a test case to make sure this is indeed true?).

t5302 provides a good demonstration of that.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Mon, 17 Dec 2007, Joel Becker wrote:
>
>> 	You may not see a case for actual corruptions, but my coworker
>> updated his tree on a box with 1.5.x, then tried to work on a box with
>> 1.4.x (I think 1.4.2 back then), and ended up with a tree that was
>> unusable.  He had to re-clone, and I think he got lucky recovering
>> pending changes (probably using 1.5.x on the branches with the changes,
>> as master was what got broken).
>
> I still claim that there wasn't any corruptions.
> ...
> Your allegation of corruptions is cavalier just as well.
>
> I'm telling you that there won't be any such corruption.  Just like in 
> the M$ Office case, it is expected that newer versions make data 
> unusable by older versions at some point -- that's the inevitable side 
> effect of progress.

This is mostly spilt milk under the bridge now, but I have to mildly
disagree.

If we had core.usedeltabaseoffset instead of repack.usedeltabaseoffset,
and made the format negotiation in fetch-pack protocol pay attention to
that variable, Joel's coworker did not have to suffer if the repository
explicitly asked OFS_DELTA not to be used.

Instead we unconditionally said "if you are downloading with the new
client, we assume you would never be using older client to access that
repository locally, if you did so, you are screwed."

IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT
native protocol use offsets to delta base when possible) could have been
a bit more careful in this respect.

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Mon, 17 Dec 2007, Junio C Hamano wrote:

> This is mostly spilt milk under the bridge now, but I have to mildly
> disagree.
> 
> If we had core.usedeltabaseoffset instead of repack.usedeltabaseoffset,
> and made the format negotiation in fetch-pack protocol pay attention to
> that variable, Joel's coworker did not have to suffer if the repository
> explicitly asked OFS_DELTA not to be used.
> 
> Instead we unconditionally said "if you are downloading with the new
> client, we assume you would never be using older client to access that
> repository locally, if you did so, you are screwed."
> 
> IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT
> native protocol use offsets to delta base when possible) could have been
> a bit more careful in this respect.

Probably.  But this can hardly be called a "corruption" since nothing 
was actually lost, rather an incompatibility problem.

If, on the other hand, the latest Git version wasn't able to read it 
either then this is a different matter entirely.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Mon, 17 Dec 2007, Junio C Hamano wrote:
> ...
>> Instead we unconditionally said "if you are downloading with the new
>> client, we assume you would never be using older client to access that
>> repository locally, if you did so, you are screwed."
>> 
>> IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT
>> native protocol use offsets to delta base when possible) could have been
>> a bit more careful in this respect.
>
> Probably.  But this can hardly be called a "corruption" since nothing 
> was actually lost, rather an incompatibility problem.

It is not a corruption, but the distinction doesn't matter much to the
end user who wants to get the job done with the data right now.  The
data that was made inaccessible is inaccessible.  The only difference is
that it is recoverable once the user upgrades, but that may be painful,
even though it may be rewarding afterwards and worth doing so, and the
user may not be able to afford doing so right at that moment.

Re: [PATCH] provide advance warning of some future pack default changes

[Mark Fasheh]

On Mon, Dec 17, 2007 at 04:41:19PM -0800, Junio C Hamano wrote:
> It is not a corruption, but the distinction doesn't matter much to the
> end user who wants to get the job done with the data right now.  The
> data that was made inaccessible is inaccessible.  The only difference is
> that it is recoverable once the user upgrades, but that may be painful,
> even though it may be rewarding afterwards and worth doing so, and the
> user may not be able to afford doing so right at that moment.

Junio, I agree 100% with your description here. This is all about user
experience and data which is silently made inaccessible makes them feel
pretty bad.
	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@oracle.com

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Mon, 17 Dec 2007, Junio C Hamano wrote:

> Nicolas Pitre <nico@cam.org> writes:
> 
> > On Mon, 17 Dec 2007, Junio C Hamano wrote:
> > ...
> >> Instead we unconditionally said "if you are downloading with the new
> >> client, we assume you would never be using older client to access that
> >> repository locally, if you did so, you are screwed."
> >> 
> >> IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT
> >> native protocol use offsets to delta base when possible) could have been
> >> a bit more careful in this respect.
> >
> > Probably.  But this can hardly be called a "corruption" since nothing 
> > was actually lost, rather an incompatibility problem.
> 
> It is not a corruption, but the distinction doesn't matter much to the
> end user who wants to get the job done with the data right now.  The
> data that was made inaccessible is inaccessible.  The only difference is
> that it is recoverable once the user upgrades, but that may be painful,
> even though it may be rewarding afterwards and worth doing so, and the
> user may not be able to afford doing so right at that moment.

Sure, but at some point that's something users mixing versions should be 
ready to cope with.  We try to make it as painless as possible of 
course.

Data corruption is usually something you just cannot recover from 
(unless you have backups).  And if mixing different tool versions 
actually cause data corruption then this is a much much more serious 
issue and that must be avoided.

So at some point the distinction must be made, and if using an old 
version of Git on a repo created by a new version actually produces data 
corruption as Joel seemed to imply, then we must really take it 
seriously.  OTOH, compatibility issues are usually much less of a pain 
to fix.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Martin Langhoff]

On Dec 18, 2007 4:23 PM, Nicolas Pitre <nico@cam.org> wrote:
> Sure, but at some point that's something users mixing versions should be
> ready to cope with.  We try to make it as painless as possible of
> course.

I have to say I agree with the "apparently minor updates should not
break cross-version compat". And I think it's a communication issue
around the version numbering. The fact that this will be introduced
with a v1.5.5 is, IMHO, a good part of the problem.

If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor
revisions should interoperate with end users not even thinking about
it. But 1.5.5 has in its changelog lots of deprecations and interop
changes.

It's not good communication to label it 1.5.5.

Other than that, it's an _amazing_ thing, and I'm in love with git.
But the version number is a bit of a lie -- and is bound to confuse
and anger end users.

cheers,


martin

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Tue, 18 Dec 2007, Martin Langhoff wrote:

> On Dec 18, 2007 4:23 PM, Nicolas Pitre <nico@cam.org> wrote:
> > Sure, but at some point that's something users mixing versions should be
> > ready to cope with.  We try to make it as painless as possible of
> > course.
> 
> I have to say I agree with the "apparently minor updates should not
> break cross-version compat". And I think it's a communication issue
> around the version numbering. The fact that this will be introduced
> with a v1.5.5 is, IMHO, a good part of the problem.
> 
> If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor
> revisions should interoperate with end users not even thinking about
> it. But 1.5.5 has in its changelog lots of deprecations and interop
> changes.
> 
> It's not good communication to label it 1.5.5.

I agree.  Might be time for 1.6.0?


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Junio C Hamano]

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

> If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor
> revisions should interoperate with end users not even thinking about
> it. But 1.5.5 has in its changelog lots of deprecations and interop
> changes.
>
> It's not good communication to label it 1.5.5.

There indeed are handful scheduled removals.  I do not mind declaring
that 1.6.0 comes after 1.5.4, or just relabel the removal schedule for
1.6.0 and keep the scheduled change on hold a bit longer.

By the way, I'd appreciate an Ack or comment on the recent pserver
authentication enhancements in c934dca22ee07cb3ca146a249bdb73ab0f30b2b1
(Authentication support for pserver); I do not mind merging this in
1.5.4 as the change is fairly isolated and should not affect people who
do not use the feature.

Re: [PATCH] provide advance warning of some future pack default changes

[Jakub Narebski]

Junio C Hamano wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
> 
>> If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor
>> revisions should interoperate with end users not even thinking about
>> it. But 1.5.5 has in its changelog lots of deprecations and interop
>> changes.
>>
>> It's not good communication to label it 1.5.5.
> 
> There indeed are handful scheduled removals.  I do not mind declaring
> that 1.6.0 comes after 1.5.4, or just relabel the removal schedule for
> 1.6.0 and keep the scheduled change on hold a bit longer.

By the way, I wonder if there would be packv4 in time for 1.6.0;
perhaps not enabled by default.

-- 
Jakub Narebski
Poland

Re: [PATCH] provide advance warning of some future pack default changes

[Johannes Schindelin]

Hi,

On Tue, 18 Dec 2007, Jakub Narebski wrote:

> By the way, I wonder if there would be packv4 in time for 1.6.0; perhaps 
> not enabled by default.

Sure!  If someone undertakes the massive amount of work it takes to bring 
packv4 off!

But if that is done, I do not see why it should be off by default.

Ciao,
Dscho

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Tue, 18 Dec 2007, Jakub Narebski wrote:

> Junio C Hamano wrote:
> > "Martin Langhoff" <martin.langhoff@gmail.com> writes:
> > 
> >> If cvs 1.11 doesn't talk with 1.12 I'll say there are nuts - minor
> >> revisions should interoperate with end users not even thinking about
> >> it. But 1.5.5 has in its changelog lots of deprecations and interop
> >> changes.
> >>
> >> It's not good communication to label it 1.5.5.
> > 
> > There indeed are handful scheduled removals.  I do not mind declaring
> > that 1.6.0 comes after 1.5.4, or just relabel the removal schedule for
> > 1.6.0 and keep the scheduled change on hold a bit longer.

I think Git development is dynamic enough to justify 1.6.0 right after 
1.5.4.

> By the way, I wonder if there would be packv4 in time for 1.6.0;
> perhaps not enabled by default.

I don't think so.  First, if packv4 actually happens, it might justify 
v2.0.0 and not v1.6.0.

But so far there were steady improvement made to the system even with 
the current pack format, so the return on the investment for packv4 is 
diminishing.  The largest road block for packv4 at the moment is a 
complete refactoring of the tree walking code.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Jeff King]

On Mon, Dec 17, 2007 at 09:01:49PM -0800, Junio C Hamano wrote:

> There indeed are handful scheduled removals.  I do not mind declaring
> that 1.6.0 comes after 1.5.4, or just relabel the removal schedule for
> 1.6.0 and keep the scheduled change on hold a bit longer.

I can think of two other user-visible changes which have been discussed
that might warrant such a version bump:
  - option parsing tweaks (hopefully these should be minor, but it is
    clear that we cannot be 100% consistent while retaining the
    identical previous behavior)
  - moving dashed forms out of paths

-Peff

Re: [PATCH] provide advance warning of some future pack default changes

[Johannes Schindelin]

Hi,

On Tue, 18 Dec 2007, Jeff King wrote:

> On Mon, Dec 17, 2007 at 09:01:49PM -0800, Junio C Hamano wrote:
> 
> > There indeed are handful scheduled removals.  I do not mind declaring 
> > that 1.6.0 comes after 1.5.4, or just relabel the removal schedule for 
> > 1.6.0 and keep the scheduled change on hold a bit longer.
> 
> I can think of two other user-visible changes which have been discussed 
> that might warrant such a version bump:
>
>   - option parsing tweaks (hopefully these should be minor, but it is
>     clear that we cannot be 100% consistent while retaining the
>     identical previous behavior)

IMHO this does not warrant a version bump.  It should be mostly 
behind-the-scenes, after all.

>   - moving dashed forms out of paths

Playing it safe, and waiting with this after announcing it more obviously, 
is something that I appreciate.  Too many scripts can break, and I am sure 
quite a few of mine will; I simply do not have the time right now to audit 
them.

Ciao,
Dscho

Re: [PATCH] provide advance warning of some future pack default changes

[Jeff King]

On Tue, Dec 18, 2007 at 12:06:23PM +0000, Johannes Schindelin wrote:

> >   - option parsing tweaks (hopefully these should be minor, but it is
> >     clear that we cannot be 100% consistent while retaining the
> >     identical previous behavior)
> 
> IMHO this does not warrant a version bump.  It should be mostly 
> behind-the-scenes, after all.

Yes, it should be, but I think there will be a few user-visible fallouts
(like "--abbrev $foo" in scripts should now be "--abbrev-default $foo"
for safety).

-Peff

Re: [PATCH] provide advance warning of some future pack default changes

[Johannes Schindelin]

Hi,

On Tue, 18 Dec 2007, Jeff King wrote:

> On Tue, Dec 18, 2007 at 12:06:23PM +0000, Johannes Schindelin wrote:
> 
> > >   - option parsing tweaks (hopefully these should be minor, but it is
> > >     clear that we cannot be 100% consistent while retaining the
> > >     identical previous behavior)
> > 
> > IMHO this does not warrant a version bump.  It should be mostly 
> > behind-the-scenes, after all.
> 
> Yes, it should be, but I think there will be a few user-visible fallouts
> (like "--abbrev $foo" in scripts should now be "--abbrev-default $foo"
> for safety).

But we are on our way to fix this, no?  IOW this warrants not a version 
bump, but an extended feature freeze/bug fix period (like Junio suggested, 
until January).

Ciao,
Dscho

Re: [PATCH] provide advance warning of some future pack default changes

[Jeff King]

On Tue, Dec 18, 2007 at 01:30:49PM +0000, Johannes Schindelin wrote:

> > Yes, it should be, but I think there will be a few user-visible fallouts
> > (like "--abbrev $foo" in scripts should now be "--abbrev-default $foo"
> > for safety).
> 
> But we are on our way to fix this, no?  IOW this warrants not a version 
> bump, but an extended feature freeze/bug fix period (like Junio suggested, 
> until January).

I think the resolution seems to be that we will now support "--abbrev
foo", though we didn't in the past. Because the "foo" here is optional,
the old "git log --abbrev HEAD" is ambiguous. In this case we'll see
that "HEAD" isn't a number and DWIM. But that means a script trying to
be unambiguous should use "git log --abbrev-default $foo" to make sure
that "$foo" doesn't accidentally match as a number.

So there will be user-visible changes (though I don't expect them to be
huge...there simply aren't that many variables with optional arguments).

-Peff

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Tue, 18 Dec 2007, Jeff King wrote:

> So there will be user-visible changes (though I don't expect them to be
> huge...there simply aren't that many variables with optional arguments).

OTOH, there are quite a bunch of changes affecting the user experience.  
Many of the feedback messages printed by Git were completely revamped, 
starting with the progress display to the fetch summary.


Nicolas

Re: [PATCH] provide advance warning of some future pack default changes

[Jakub Narebski]

Johannes Schindelin wrote:
> On Tue, 18 Dec 2007, Jeff King wrote:
> 
>>   - moving dashed forms out of paths
> 
> Playing it safe, and waiting with this after announcing it more obviously, 
> is something that I appreciate.  Too many scripts can break, and I am sure 
> quite a few of mine will; I simply do not have the time right now to audit 
> them.

We could do it IMVHO in two (or two an a half :-)) steps:

1. Decide where separate exec-path area should be, following FHS. Create
   it during install. Install helper scripts there, moving it out of PATH.
   Test those tools which use helper scripts (helper commands), which
   should be _much_ easier than testing whole git for "moving dashed forms
   out of path" breakage.

2. Move dashed forms out of PATH, perhaps leaving (or with option of
   leaving) dashed forms of porcelain in PATH. Test all scripts and tests
   ;-)
   
I think that the first step can be done before 1.6.0, perhaps even
before 1.5.4
-- 
Jakub Narebski
Poland

Re: [PATCH] provide advance warning of some future pack default changes

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I can think of two other user-visible changes which have been discussed
> that might warrant such a version bump:
>
>   - option parsing tweaks (hopefully these should be minor, but it is
>     clear that we cannot be 100% consistent while retaining the
>     identical previous behavior)

This could have a fallout, like *-default disambiguation which scripts
did not have to implement.

>   - moving dashed forms out of paths

This is already planned for 1.5.5 and it is not among "other
user-visible changes".  Technically the use of git-foo form without
preparing the environment has not been supported for quite some time,
but people have come to rely on it and I'd agree this warrants a 1.6.0.

Re: [PATCH] provide advance warning of some future pack default changes

[Mark Fasheh]

Hi,

	Just to "out" myself, I'm the "co-worker" whose name Joel has been
(politely) keeping anonymous.

On Mon, Dec 17, 2007 at 03:41:24PM -0500, Nicolas Pitre wrote:
> > 	You may not see a case for actual corruptions, but my coworker
> > updated his tree on a box with 1.5.x, then tried to work on a box with
> > 1.4.x (I think 1.4.2 back then), and ended up with a tree that was
> > unusable.  He had to re-clone, and I think he got lucky recovering
> > pending changes (probably using 1.5.x on the branches with the changes,
> > as master was what got broken).
> 
> I still claim that there wasn't any corruptions.

The following description is really vague because this was a while ago:

Something made my ocfs2.git tree unusable in that I could no longer do
common tasks, such as git-log, etc without getting messages about corrupted
refs.

I wish I had saved off some of the messages. Sorry.

I had to re-create my git tree several times before I learned by deduction
that it was the older versions of git on some of the machines that were
writing some sort of incompatible format.


> Just for fun, just edit some document with Microsoft Office 95, then 
> open the same document with Office 2007 and save it with default 
> settings.  Now try to open it back with Office 95.  It won't work.  
> Does that mean that the document got corrupted?

Boy, I hope Microsoft Office isn't our bar for compatiblity here...
	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@oracle.com

Re: [PATCH] provide advance warning of some future pack default changes

[Nicolas Pitre]

On Mon, 17 Dec 2007, Mark Fasheh wrote:

> Hi,
> 
> 	Just to "out" myself, I'm the "co-worker" whose name Joel has been
> (politely) keeping anonymous.
> 
> On Mon, Dec 17, 2007 at 03:41:24PM -0500, Nicolas Pitre wrote:
> > > 	You may not see a case for actual corruptions, but my coworker
> > > updated his tree on a box with 1.5.x, then tried to work on a box with
> > > 1.4.x (I think 1.4.2 back then), and ended up with a tree that was
> > > unusable.  He had to re-clone, and I think he got lucky recovering
> > > pending changes (probably using 1.5.x on the branches with the changes,
> > > as master was what got broken).
> > 
> > I still claim that there wasn't any corruptions.
> 
> The following description is really vague because this was a while ago:
> 
> Something made my ocfs2.git tree unusable in that I could no longer do
> common tasks, such as git-log, etc without getting messages about corrupted
> refs.
> 
> I wish I had saved off some of the messages. Sorry.
> 
> I had to re-create my git tree several times before I learned by deduction
> that it was the older versions of git on some of the machines that were
> writing some sort of incompatible format.

Next time please don't hesitate to post your issue on this list.  The 
fix could have been so obvious to many people on the list, saving you 
time and frustration.  In your case I think the "fix" would have 
consisted of simply running "git repack -a -d" on the machine with the 
most recent Git version.

And if it was a case of real corruption then we certainly would have 
liked to know about it ASAP.

> > Just for fun, just edit some document with Microsoft Office 95, then 
> > open the same document with Office 2007 and save it with default 
> > settings.  Now try to open it back with Office 95.  It won't work.  
> > Does that mean that the document got corrupted?
> 
> Boy, I hope Microsoft Office isn't our bar for compatiblity here...

We can do better of course, like allowing you to still produce the old 
format with a new version of Git.  But sometimes format changes are 
unavoidable for many good reasons.


Nicolas

Re: v1.5.4 plans

[Russell]

On Dec 3, 2007 7:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
>  * We have already removed svnimport without giving a deprecation notice
>    in the release notes of the previous feature release, which was bad.
>    Maybe the users will forgive us.  Maybe not.

Ah, that explains that.  I was in the middle of importing the open2x
project into a git repo.  It's a large tree which looks like it
includes several copies of linux 2.4, and importing is taking several
days.  Occasionally the svn connection times out or something, and I
just restart it and it continues.  In the middle of that I built and
installed git 1.5.3.7 and was surprised when git-svnimport wasn't
there the next time I tried to restart it.  Back to 1.5.3.6 for now.

I see there's a thread about using a git-svnimport tree with git-svn,
so I'll do that.

Oh, and you're forgiven.  :)



-- 
Virus found in this message.

What's in git/spearce.git (stable)

[Shawn O. Pearce]

For those who may be new to the git/spearce.git concept I'm filling
in for Junio and have published a tree on repo.or.cz:

  git://repo.or.cz/git/spearce.git
  http://repo.or.cz/r/git/spearce.git

------

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

Alex Bennee (1):
  Ensure we add directories in the correct order

Andrew Clausen (1):
  helpful error message when send-pack finds no refs in common.

Brian Gernhardt (1):
  cvsserver: Use exit 1 instead of die when req_Root fails.

Gerrit Pape (1):
  git-config: print error message if the config file cannot be read

Jeff King (1):
  send-pack: respect '+' on wildcard refspecs

Joakim Tjernlund (1):
  Improve receive-pack error message about funny ref creation

Johannes Schindelin (3):
  Fix setup_git_directory_gently() with relative GIT_DIR &
      GIT_WORK_TREE
  fix filter-branch documentation
  filter-branch: update current branch when rewritten

Julian Phillips (1):
  fast-import: Fix argument order to die in file_change_m

Linus Torvalds (4):
  git-blame shouldn't crash if run in an unmerged tree
  Avoid scary errors about tagged trees/blobs during git-fetch
  Fix directory scanner to correctly ignore files without d_type
  Fix diffcore-break total breakage

Patrick Welche (1):
  Define NI_MAXSERV if not defined by operating system

Ralf Wildenhues (1):
  gitk.txt: Fix markup.

Robert Schiele (1):
  fixing output of non-fast-forward output of post-receive-email

Shawn O. Pearce (16):
  git-gui: Display message box when we cannot find git in $PATH
  git-gui: Handle starting on mapped shares under Cygwin
  git-gui: Ensure .git/info/exclude is honored in Cygwin workdirs
  git-gui: Allow gitk to be started on Cygwin with native Tcl/Tk
  git-gui: Don't crash when starting gitk from a browser session
  Correct typos in release notes for 1.5.3.5
  Avoid 'expr index' on Mac OS X as it isn't supported
  Document additional 1.5.3.5 fixes in release notes
  Yet more 1.5.3.5 fixes mentioned in release notes
  Avoid invoking diff drivers during git-stash
  Further 1.5.3.5 fixes described in release notes
  Paper bag fix diff invocation in 'git stash show'
  git-gui: Correctly report failures from git-write-tree
  git-gui: Handle progress bars from newer gits
  git-gui: Don't display CR within console windows
  Describe more 1.5.3.5 fixes in release notes

Simon Sasburg (1):
  git-gui: Avoid using bold text in entire gui for some fonts

Steffen Prohaska (2):
  git-gui: accept versions containing text annotations, like
      1.5.3.mingw.1
  attr: fix segfault in gitattributes parsing code


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

Benoit Sigoure (5):
  git-svn: add a generic tree traversal to fetch SVN properties
  git-svn: implement git svn create-ignore
  git-svn: add git svn propget
  git-svn: add git svn proplist
  git-svn: simplify the handling of fatal errors

Chris Pettitt (1):
  git-p4 support for perforce renames.

Eygene Ryabinkin (1):
  git-svn: use "no warnings 'once'" to disable false-positives

Jeff King (3):
  git-gc: improve wording of --auto notification
  Documentation/git-gc: explain --auto in description
  Documentation/git-gc: improve description of --auto

Johannes Schindelin (1):
  Deduce exec_path also from calls to git with a relative path

Johannes Sixt (1):
  gitk: Do not pick up file names of "copy from" lines

Jonathan del Strother (1):
  gitk: Add support for OS X mouse wheel

Junio C Hamano (2):
  git-am: make the output quieter.
  git-am: fix typo in the previous one.

Linus Torvalds (1):
  optimize diffcore-delta by sorting hash entries.

Luke Lu (1):
  gitweb: speed up project listing on large work trees by limiting
      find depth

Marius Storm-Olsen (1):
  Teach core.autocrlf to 'git blame'

Michael Witten (1):
  git-cvsexportcommit.perl: git-apply no longer needs --binary

Paul Mackerras (3):
  gitk: Check that we are running on at least Tcl/Tk 8.4
  gitk: Avoid an error when cherry-picking if HEAD has moved on
  gitk: Fix "can't unset prevlines(...)" Tcl error

Ralf Wildenhues (1):
  git-cherry-pick: improve description of -x.

René Scharfe (1):
  Correct some sizeof(size_t) != sizeof(unsigned long) typing errors

Sam Vilain (1):
  gitk: disable colours when calling git log

Shawn O. Pearce (2):
  Improved const correctness for strings
  Use PRIuMAX instead of 'unsigned long long' in show-index

Simon Hausmann (1):
  git-p4: When skipping a patch as part of "git-p4 submit" make sure
      we correctly revert to the previous state of the files using
      "p4 revert".

koreth@midwinter.com (1):
  Add a message explaining that automatic GC is about to start

What's in git.git (stable)

[Junio C Hamano]

* The 'maint' branch has just produced the 1.5.3.5 release.

* The 'master' branch has these since the last announcement
  in addition to what's in 1.5.3.5.

  - git-bisect enhancements to support "git bisect skip".
  - git-fetch rewritten in C for performance and portability.
  - git-svnimport is no more --- use git-svn.
  - git-send-pack does not update the tracking ref on the local
    side for failed push (needs cherry-picking to 'maint').
  - git-rebase does not choke when $GIT_DIR has whitespace in it
    (needs cherry-picking to 'maint').
  - optimize rename detection.
  - comes with updated gitk.

  The above list makes me realize that it probably is a good
  time to start freezing things for 1.5.4.  Tonight's "What's
  cooking" will talk about what other topics should graduate to
  'master' before that happens.

Alex Riesen (1):
  Fix a crash in ls-remote when refspec expands into nothing

Alexandre Julliard (4):
  git.el: Fix typo in "Reverted file" message.
  git.el: Fix typo in git-update-saved-file error handling.
  git.el: Refresh only the changed file marks when marking/unmarking
      all.
  git.el: Run git-gc --auto after commits.

Benoit Sigoure (1):
  core-tutorial: Catch up with current Git

Christian Couder (12):
  Test suite: reset TERM to its previous value after testing.
  rev-list: implement --bisect-all
  rev-list documentation: add "--bisect-all".
  Bisect: fix some white spaces and empty lines breakages.
  Bisect: implement "bisect skip" to mark untestable revisions.
  Bisect: refactor "bisect_write_*" functions.
  Bisect: refactor some logging into "bisect_write".
  Bisect: refactor "bisect_{bad,good,skip}" into "bisect_state".
  Bisect: add "bisect skip" to the documentation.
  Bisect: add a "bisect replay" test case.
  Bisect run: "skip" current commit if script exit code is 125.
  Bisect: add "skip" to the short usage string.

Dan McGee (1):
  Remove outdated references to cogito in documentation

Daniel Barkalow (15):
  Refactor http.h USE_CURL_MULTI fill_active_slots().
  Make function to refill http queue a callback
  Remove obsolete commit-walkers
  Modularize commit-walker
  Add uploadpack configuration info to remote.
  Report information on branches from remote.h
  Make fetch-pack a builtin with an internal API
  Push code for transport library
  Add matching and parsing for fetch-side refspec rules
  Add fetch methods to transport library.
  Make fetch a builtin
  Allow abbreviations in the first refspec to be merged
  Restore default verbosity for http fetches.
  Remove duplicate ref matches in fetch
  Correct handling of upload-pack in builtin-fetch-pack

David Symonds (3):
  gitweb: Provide title attributes for abbreviated author names.
  gitweb: Refactor abbreviation-with-title-attribute code.
  gitweb: Use chop_and_escape_str in more places.

Gerrit Pape (1):
  No longer install git-svnimport, move to contrib/examples

Jakub Narebski (1):
  gitweb: Fix and simplify "split patch" detection

Jari Aalto (1):
  On error, do not list all commands, but point to --help option

Jeff King (2):
  send-pack: don't update tracking refs on error
  t5516: test update of local refs on push

Jim Meyering (1):
  hooks-pre-commit: use \t, rather than a literal TAB in regexp

Johannes Schindelin (6):
  Move bundle specific stuff into bundle.[ch]
  Add bundle transport
  Introduce remove_dir_recursively()
  fetch/push: readd rsync support
  Fix compilation when NO_CURL is defined
  fetch: if not fetching from default remote, ignore default merge

Jonathan del Strother (1):
  Fixing path quoting in git-rebase

Junio C Hamano (5):
  bundle transport: fix an alloc_ref() call
  k.org git toppage: Add link to 1.5.3 release notes.
  help: remove extra blank line after "See 'git --help'" message
  git-fetch: do not fail when remote branch disappears
  RelNotes-1.5.4: describe recent updates

Lars Hjemli (1):
  Teach git-pull about --[no-]ff, --no-squash and --commit

Lars Knoll (1):
  Speedup scanning for excluded files.

Linus Torvalds (8):
  Add 'diffcore.h' to LIB_H
  Split out "exact content match" phase of rename detection
  Ref-count the filespecs used by diffcore
  copy vs rename detection: avoid unnecessary O(n*m) loops
  Do linear-time/space rename logic for exact renames
  Do exact rename detection regardless of rename limits
  Fix ugly magic special case in exact rename detection
  Do the fuzzy rename detection limits with the exact renames removed

Miklos Vajna (1):
  git-send-email: add a new sendemail.to configuration variable

Nguyễn Thái Ngọc Duy (1):
  git-sh-setup.sh: use "git rev-parse --show-cdup" to check for
      SUBDIRECTORY_OK

Paul Mackerras (34):
  gitk: Establish and use global left-to-right ordering for commits
  gitk: Improve the drawing of links to parent lines
  gitk: Eliminate diagonal arrows
  gitk: Get rid of idrowranges and rowrangelist
  gitk: Get rid of idinlist array
  gitk: Fix some problems with the display of ids as links
  gitk: Get rid of the rowchk array
  gitk: Do only the parts of the layout that are needed
  gitk: Fix bug causing incorrect ref list contents when switching
      view
  gitk: Fix bug causing undefined variable error when cherry-picking
  gitk: Add a cache for the topology info
  gitk: Make it possible to lay out all the rows we have received so
      far
  gitk: Fix bugs in setting rowfinal
  gitk: Get rid of lookingforhead, use commitinterest instead
  gitk: Fix bug in generating patches
  gitk: Simplify highlighting interface and combine with Find
      function
  gitk: Fix a couple of bugs
  gitk: Add progress bars for reading in stuff and for finding
  gitk: Fix the tab setting in the diff display window
  gitk: Fix bug causing Tcl error when changing find match type
  gitk: Use named fonts instead of the font specification
  gitk: Keep track of font attributes ourselves instead of using font
      actual
  gitk: Add a font chooser
  gitk: Fix bug where the last few commits would sometimes not be
      visible
  gitk: Get rid of the diffopts variable
  gitk: Fix Tcl error: can't unset findcurline
  gitk: Limit diff display to listed paths by default
  gitk: Ensure tabstop setting gets restored by Cancel button
  gitk: Integrate the reset progress bar in the main frame
  gitk: Use the status window for other functions
  gitk: Fix some bugs with path limiting in the diff display
  gitk: Fix a couple more bugs in the path limiting
  gitk: Simplify the code for finding commits
  gitk: Use the UI font for the diff/old version/new version radio
      buttons

Pierre Habouzit (3):
  Add some fancy colors in the test library when terminal supports
      it.
  Support a --quiet option in the test-suite.
  fast-import.c: fix regression due to strbuf conversion

Shawn O. Pearce (37):
  Correct builtin-fetch to handle + in refspecs
  Fix off by one bug in reflog messages written by builtin-fetch
  Remove unnecessary debugging from builtin-fetch
  Remove unused unpacklimit variable from builtin-fetch
  Replace custom memory growth allocator with ALLOC_GROW
  Simplify fetch transport API to just one function
  Refactor index-pack "keep $sha1" handling for reuse
  Remove pack.keep after ref updates in git-fetch
  Always ensure the pack.keep file is removed by git-fetch
  Fix builtin-fetch memory corruption by not overstepping array
  Backup the array passed to fetch_pack so we can free items
  Properly cleanup in http_cleanup so builtin-fetch does not segfault
  Don't bother passing ref log details to walker in builtin-fetch
  Cleanup duplicate initialization code in transport_get
  Add transport.h to LIB_H as transport.o is in LIB_OBJS
  Remove unnecessary 'fetch' argument from transport_get API
  Allow builtin-fetch to work on a detached HEAD
  Don't configure remote "." to fetch everything to itself
  Remove more debugging from builtin-fetch
  builtin-fetch: Don't segfault on "fetch +foo"
  Don't attempt to merge non-existant remotes in t5515
  Correct handling of branch.$name.merge in builtin-fetch
  Avoid printing unnecessary warnings during fetch and push
  Use 'unsigned:1' when we mean boolean options
  Rename remote.uri to remote.url within remote handling internals
  Refactor struct transport_ops inlined into struct transport
  Always obtain fetch-pack arguments from struct fetch_pack_args
  Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
  Fix memory leaks when disconnecting transport instances
  Cleanup style nit of 'x == NULL' in remote.c
  Cleanup unnecessary break in remote.c
  Prevent send-pack from segfaulting when a branch doesn't match
  Fix 'push --all branch...' error handling
  Support 'push --dry-run' for rsync transport
  Support 'push --dry-run' for http transport
  Avoid scary errors about tagged trees/blobs during git-fetch
  Define compat version of mkdtemp for systems lacking it

Väinö Järvelä (1):
  Added a test for fetching remote tags when there is not tags.

What's in git.git (stable)

[Junio C Hamano]

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

Brad King (1):
  cvsexportcommit: fix for commits that do not have parents

Jakub Narebski (1):
  gitweb: Update config file example for snapshot feature in
      gitweb/INSTALL

Jonas Fonseca (1):
  Remove escaping of '|' in manpage option sections

Jonathan del Strother (1):
  Fixing path quoting in git-rebase

Kristian Høgsberg (1):
  Remove unecessary hard-coding of EDITOR=':' VISUAL=':' in some test
      suites.

Ralf Wildenhues (1):
  git-clone.txt: Improve --depth description.

Sergei Organov (3):
  git-filter-branch.txt: fix a typo.
  git-format-patch.txt: fix explanation of an example.
  Documentation: quote commit messages consistently.

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

* The 'master' branch has these since the last announcement
  in addition to the above.  Notable topics are:

  - fork-exec removal from MinGW work.
  - the first batch of parse-options.
  - terse progress display.

Short log follows.

Alex Riesen (2):
  Rework make_usage to print the usage message immediately
  Do no colorify test output if stdout is not a terminal

Blake Ramsdell (1):
  transport.c: squelch a gcc 4.0.1 complaint about an uninitialized
      variable

Emil Medve (1):
  Fixed a command line option type for builtin-fsck.c

Gerrit Pape (1):
  git-diff.txt: add section "output format" describing the diff
      formats

James Bowes (1):
  gc: use parse_options

Johannes Schindelin (2):
  Add tests for parse-options.c
  parse-options: Allow abbreviated options when unambiguous

Johannes Sixt (14):
  Change git_connect() to return a struct child_process instead of a
      pid_t.
  Use start_command() in git_connect() instead of explicit fork/exec.
  Use start_command() to run content filters instead of explicit
      fork/exec.
  Use run_command() to spawn external diff programs instead of
      fork/exec.
  Use start_comand() in builtin-fetch-pack.c instead of explicit
      fork/exec.
  Have start_command() create a pipe to read the stderr of the child.
  upload-pack: Use start_command() to run pack-objects in
      create_pack_file().
  Add infrastructure to run a function asynchronously.
  Use the asyncronous function infrastructure in
      builtin-fetch-pack.c.
  upload-pack: Move the revision walker into a separate function.
  upload-pack: Run rev-list in an asynchronous function.
  t0021-conversion.sh: Test that the clean filter really cleans
      content.
  Avoid a dup2(2) in apply_filter() - start_command() can do it for
      us.
  Use the asyncronous function infrastructure to run the content
      filter.

Jonas Fonseca (1):
  Update manpages to reflect new short and long option aliases

Kristian Høgsberg (5):
  Enable wt-status output to a given FILE pointer.
  Enable wt-status to run against non-standard index file.
  Introduce entry point add_interactive and add_files_to_cache
  Export rerere() and launch_editor().
  Port builtin-add.c to use the new option parser.

Nicolas Pitre (16):
  more compact progress display
  cope with multiple line breaks within sideband progress messages
  pack-objects: no delta possible with only one object in the list
  pack-objects.c: fix some global variable abuse and memory leaks
  fix const issues with some functions
  fix for more minor memory leaks
  prune-packed: don't call display_progress() for every file
  make struct progress an opaque type
  relax usage of the progress API
  add throughput to progress display
  add throughput display to index-pack
  add some copyright notice to the progress display code
  add throughput display to git-push
  return the prune-packed progress display to the inner loop
  make sure throughput display gets updated even if progress doesn't
      move
  Show total transferred as part of throughput progress

Pierre Habouzit (17):
  Add a simple option parser.
  parse-options: be able to generate usages automatically
  parse-options: make some arguments optional, add callbacks.
  Add shortcuts for very often used options.
  parse-options: allow callbacks to take no arguments at all.
  Make builtin-rm.c use parse_options.
  Make builtin-mv.c use parse-options
  Make builtin-branch.c use parse_options.
  Make builtin-describe.c use parse_options
  Make builtin-revert.c use parse_options.
  Make builtin-update-ref.c use parse_options
  Make builtin-symbolic-ref.c use parse_options.
  Make builtin-for-each-ref.c use parse-opts.
  Make builtin-fsck.c use parse_options.
  Make builtin-count-objects.c use parse_options.
  Make builtin-name-rev.c use parse_options.
  Make builtin-pack-refs.c use parse_options.

Scott R Parish (7):
  "git" returns 1; "git help" and "git help -a" return 0
  remove unused/unneeded "pattern" argument of list_commands
  "current_exec_path" is a misleading name, use "argv_exec_path"
  list_commands(): simplify code by using chdir()
  use only the $PATH for exec'ing git commands
  include $PATH in generating list of commands for "help -a"
  shell should call the new setup_path() to setup $PATH

Shawn O. Pearce (3):
  Change 'Deltifying objects' to 'Compressing objects'
  Teach prune-packed to use the standard progress meter
  Stop displaying "Pack pack-$ID created." during git-gc

Steffen Prohaska (3):
  mergetool: use path to mergetool in config var
      mergetool.<tool>.path
  mergetool: add support for ECMerge
  mergetool: avoid misleading message "Resetting to default..."

What's in git.git (stable)

[Junio C Hamano]

On 'master' front:

 - git-p4 in contrib/ has updates.  As I cannot test it myself
   and did not hear any success/failure stories from the list,
   the only way to make sure is to push it out and see if
   anybody screams.

 - "git lost-found" is going to be deprecated (not removed) in
   the next feature release.

 - Unspecified clean.requireForce defaults to true; this would
   make "git clean" require "-f" by default.

 - "git send-email --suppress-from" does not CC yourself even
   when your name is on S-o-b: or Cc: lines in the body of the
   message.

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

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

Ask Bjørn Hansen (1):
  When exec() fails include the failing command in the error message

David D Kilzer (2):
  RelNotes-1.5.3.5: fix typo
  RelNotes-1.5.3.5: fix another typo

Eric Wong (2):
  git-svn: fix dcommit clobbering when committing a series of diffs
  git-svn: t9114: verify merge commit message in test

Gerrit Pape (3):
  git-diff.txt: add section "output format" describing the diff
      formats
  git-cvsimport: really convert underscores in branch names to dots
      with -u
  git-daemon: fix remote port number in log entry

Johannes Schindelin (1):
  Add Documentation/CodingGuidelines

Junio C Hamano (1):
  grep with unmerged index

Marco Costalba (1):
  Remove a couple of duplicated include

Mike Hommey (1):
  Delay pager setup in git blame


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

Benoit Sigoure (1):
  git-svn: sort the options in the --help message.

Brian Gernhardt (1):
  t3502: Disambiguate between file and rev by adding --

Chris Pettitt (2):
  git-p4: Add a helper function to parse the full git diff-tree
      output.
  git-p4: Detect changes to executable bit and include them in p4
      submit.

Daniel Barkalow (1):
  Use parseopts in builtin-push

David Symonds (1):
  Improve accuracy of check for presence of deflateBound.

Gerrit Pape (4):
  git-reset: add -q option to operate quietly
  contrib/hooks/post-receive-email: fix typo
  contrib/hooks/post-receive-email: reformat to wrap comments at 76
      chars
  contrib/hooks/post-receive-email: make subject prefix configurable

Heikki Orsila (1):
  git-clone: honor "--" to end argument parsing

J. Bruce Fields (1):
  errors: "strict subset" -> "ancestor"

Jakub Narebski (9):
  gitweb: Always set 'from_file' and 'to_file' in
      parse_difftree_raw_line
  gitweb: Add 'status_str' to parse_difftree_raw_line output
  gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb
      test
  gitweb: Easier adding/changing parameters to current URL
  gitweb: Use href(-replay=>1, page=>...) to generate pagination
      links
  gitweb: Use href(-replay=>1, action=>...) to generate alternate
      views
  gitweb: Add tests for overriding gitweb config with repo config
  gitweb: Read repo config using 'git config -z -l'
  gitweb: Use config file for repository description and URLs

Johannes Schindelin (3):
  git-reset: do not be confused if there is nothing to reset
  Split off the pretty print stuff into its own file
  Deprecate git-lost-found

Johannes Sixt (1):
  Fix an infinite loop in sq_quote_buf().

Junio C Hamano (6):
  revert/cherry-pick: work on merge commits as well
  format-patch -s: add MIME encoding header if signer's name requires
      so
  cherry-pick/revert -m: add tests
  test format-patch -s: make sure MIME content type is shown as
      needed
  clean: require -f to do damage by default
  gc: --prune prunes unreferenced objects.

Mike Hommey (5):
  Refactor working tree setup
  Use setup_work_tree() in builtin-ls-files.c
  Don't always require working tree for git-rm
  Make git-blame fail when working tree is needed and we're not in
      one
  Small code readability improvement in show_reference() in
      builtin-tag.c

Nicolas Pitre (4):
  make the pack index version configurable
  pack-objects: get rid of an ugly cast
  git-fetch: more terse fetch output
  restore fetching with thin-pack capability

Pierre Habouzit (1):
  Some better parse-options documentation.

Ralf Wildenhues (1):
  Fix minor nits in configure.ac

Shawn Bohrer (1):
  Add more tests for git-clean

Simon Sasburg (1):
  Make mailsplit and mailinfo strip whitespace from the start of the
      input

Steffen Prohaska (1):
  Fix comment in strbuf.h to use correct name strbuf_avail()

Steven Grimm (1):
  builtin-fetch: Add "-q" as a synonym for "--quiet"

Uwe Kleine-König (1):
  send-email: apply --suppress-from to S-o-b and cc-cmd

What's in git.git (stable)

[Junio C Hamano]

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

Alex Riesen (1):
  stop t1400 hiding errors in tests

Benoit Sigoure (1):
  git-send-email: Change the prompt for the subject of the initial
      message.

Gerrit Pape (1):
  git-mailsplit: with maildirs not only process cur/, but also new/

Jonas Fonseca (1):
  instaweb: Minor cleanups and fixes for potential problems

Junio C Hamano (3):
  refresh_index_quietly(): express "optional" nature of index writing
      better
  Makefile: add missing dependency on wt-status.h
  Start preparing for 1.5.3.6

Nicolas Pitre (3):
  print warning/error/fatal messages in one shot
  git-hash-object should honor config variables
  fix index-pack with packs >4GB containing deltas on 32-bit machines

Ralf Wildenhues (2):
  Avoid a few unportable, needlessly nested "...`...".
  Fix sed string regex escaping in module_name.

Sergei Organov (1):
  SubmittingPatches: improve the 'Patch:' section of the checklist

Vincent Zanotti (1):
  gitweb: correct month in date display for atom feeds


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

Gerrit Pape (3):
  hooks--update: fix test for properly set up project description
      file
  hooks--update: decline deleting tags or branches by default, add
      config options
  contrib/hooks/post-receive-email: remove cruft, $committer is not
      used

Johannes Schindelin (4):
  parse-options: abbreviation engine fix.
  builtin-reset: do not call "ls-files --unmerged"
  builtin-reset: avoid forking "update-index --refresh"
  builtin-blame: set up the work_tree before the first file access

Johannes Sixt (1):
  upload-pack: Use finish_{command,async}() instead of waitpid().

Junio C Hamano (6):
  Style: place opening brace of a function definition at column 1
  Update draft release notes for 1.5.4
  Documentation: lost-found is now deprecated.
  Make check-docs target detect removed commands
  Documentation: remove documentation for removed tools.
  git-commit: a bit more tests

Lars Hjemli (1):
  for-each-ref: fix setup of option-parsing for --sort

Michele Ballabio (1):
  test-lib.sh: move error line after error() declaration

Nicolas Pitre (1):
  add a howto document about corrupted blob recovery

Ralf Wildenhues (1):
  git-bisect.sh: Fix sed script to work with AIX and BSD sed.

Sergei Organov (1):
  core-tutorial.txt: Fix git-show-branch example and its description

Steffen Prohaska (2):
  push: mention --verbose option in documentation
  push: teach push to pass --verbose option to transport layer

What's in git.git (stable)

[Junio C Hamano]

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

Benoit Sigoure (1):
  git-svn: prevent dcommitting if the index is dirty.

Christian Couder (1):
  for-each-ref: fix off by one read.

Jeff King (1):
  git-branch: remove mention of non-existent '-b' option

Jing Xue (1):
  replace reference to git-rm with git-reset in git-commit doc

Jonas Fonseca (1):
  Documentation: Fix man page breakage with DocBook XSL v1.72

Junio C Hamano (3):
  t/t3404: fix test for a bogus todo file.
  revert/cherry-pick: allow starting from dirty work tree.
  git-clean: honor core.excludesfile

Sergei Organov (2):
  core-tutorial.txt: Fix argument mistake in an example.
  git-remote.txt: fix typo

Shawn O. Pearce (2):
  Fix memory leak in traverse_commit_list
  Don't allow fast-import tree delta chains to exceed maximum depth

Wincent Colaiuta (1):
  Grammar fixes for gitattributes documentation


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

Alex Riesen (1):
  Fix dependencies of parse-options test program

Andreas Ericsson (1):
  Simplify strchrnul() compat code

Björn Steinbrink (3):
  git-commit.sh: Fix usage checks regarding paths given when they do
      not make sense
  t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
  git-commit: Add tests for invalid usage of -a/--interactive with
      paths

Brian Gernhardt (2):
  format-patch: Add configuration and off switch for --numbered
  format-patch: Test --[no-]numbered and format.numbered

David Symonds (1):
  Rearrange git-format-patch synopsis to improve clarity.

Emil Medve (1):
  git-stash: Fix listing stashes

Eric Wong (1):
  git-svn: support for funky branch and project names over HTTP(S)

Gordon Hopper (1):
  git-cvsimport: fix handling of user name when it is not set in
      CVSROOT

Johannes Schindelin (2):
  rebase: operate on a detached HEAD
  rebase: fix "rebase --continue" breakage

Johannes Sixt (2):
  git-clean: Fix error message if clean.requireForce is not set.
  Fix preprocessor logic that determines the availablity of
      strchrnul().

Jonas Fonseca (1):
  Documentation: Fix references to deprecated commands

Junio C Hamano (9):
  stash: implement "stash create"
  rebase: allow starting from a dirty tree.
  Revert "rebase: allow starting from a dirty tree."
  git-merge: no reason to use cpio anymore
  ce_match_stat, run_diff_files: use symbolic constants for
      readability
  git-add: make the entry stat-clean after re-adding the same
      contents
  t2200: test more cases of "add -u"
  Resurrect git-revert.sh example and add comment to builtin-revert.c
  core.excludesfile clean-up

Mike Hommey (2):
  Reuse previous annotation when overwriting a tag
  Add tests for git tag

Nicolas Pitre (6):
  fix display overlap between remote and local progress
  sideband.c: ESC is spelled '\033' not '\e' for portability.
  make display of total transferred more accurate
  remove dead code from the csum-file interface
  make display of total transferred fully accurate
  nicer display of thin pack completion

Pierre Habouzit (1):
  git-fetch: be even quieter.

René Scharfe (5):
  Add strchrnul()
  --pretty=format: on-demand format expansion
  --pretty=format: parse commit message only once
  add strbuf_adddup()
  --format=pretty: avoid calculating expensive expansions twice

Robin Rosenberg (1):
  cvsexportcommit: Add switch to specify CVS workdir

Rémi Vanicat (1):
  Make GIT_INDEX_FILE apply to git-commit

Sergei Organov (2):
  user-manual.txt: fix a few mistakes
  user-manual: minor rewording for clarity.

Shawn O. Pearce (5):
  git-fetch: Always fetch tags if the object they reference exists
  run-command: Support sending stderr to /dev/null
  rev-list: Introduce --quiet to avoid /dev/null redirects
  git-fetch: avoid local fetching from alternate (again)
  Handle broken vsnprintf implementations in strbuf

What's in git.git (stable)

[Junio C Hamano]

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

There are a few candidate fixes for back-porting from the
development series (see "What's cooking" message).  I will
include them in 1.5.3.6, probably on or around 20th of this
month.

David Symonds (1):
  Improve accuracy of check for presence of deflateBound.

Jeff King (1):
  git-send-email: add charset header if we add encoded 'From'

Junio C Hamano (3):
  core.excludesfile clean-up
  Fix per-directory exclude handing for "git add"
  Update draft release notes for 1.5.3.6

Wincent Colaiuta (1):
  Fix t9101 test failure caused by Subversion "auto-props"


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

Guido Ostkamp (1):
  Remove unreachable statements

Jeff King (1):
  git-ls-files: add --exclude-standard

Johannes Sixt (1):
  refs.c: Remove unused get_ref_sha1()

Junio C Hamano (2):
  Fix per-directory exclude handing for "git add"
  Update draft release notes for 1.5.4

Mike Hommey (1):
  Fix and improve t7004 (git-tag tests)

Sergei Organov (3):
  Documentation: customize diff-options depending on particular
      command
  user-manual.txt: minor clarification.
  Documentation: fix git-clone manpage not to refer to itself

What's in git.git (stable)

[Junio C Hamano]

There are quite a few backported fixes on 'maint' and it might make
sense to cut 1.5.3.7 soon.

On 'master' front, many topics that have been cooking in 'next' have
graduated.  Notably:

 - git-bisect learns "skip";

 - git-rebase --skip does not need "reset --hard" beforehand;

 - git-clean is now in C;

 - git-push is much more careful reporting errors and updateing tracking
   refs.

 - git-push learns --mirror option.

Also contains the 0.9.0 series of git-gui with i18n.

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

Björn Steinbrink (3):
  git-commit.sh: Fix usage checks regarding paths given when they do
      not make sense
  t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
  git-commit: Add tests for invalid usage of -a/--interactive with paths

Brian Downing (2):
  config: correct core.loosecompression documentation
  config: clarify compression defaults

J. Bruce Fields (3):
  git-remote.txt: fix example url
  user-manual: mention "..." in "Generating diffs", etc.
  Documentation: Fix references to deprecated commands

Jeff King (1):
  send-email: add transfer encoding header with content-type

Johannes Schindelin (1):
  bundle create: keep symbolic refs' names instead of resolving them

Junio C Hamano (10):
  format-patch -s: add MIME encoding header if signer's name requires so
  test format-patch -s: make sure MIME content type is shown as needed
  ce_match_stat, run_diff_files: use symbolic constants for readability
  git-add: make the entry stat-clean after re-adding the same contents
  t2200: test more cases of "add -u"
  grep -An -Bm: fix invocation of external grep command
  GIT 1.5.3.6
  Make test scripts executable.
  Fix sample pre-commit hook
  git-checkout: describe detached head correctly

Linus Torvalds (1):
  Fix rev-list when showing objects involving submodules

Matthieu Moy (1):
  Doc fix for git-reflog: mention @{...} syntax, and <ref> in synopsys.

Rémi Vanicat (1):
  Make GIT_INDEX_FILE apply to git-commit

Steffen Prohaska (1):
  user-manual: Add section "Why bisecting merge commits can be harder ..."


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

Alex Riesen (4):
  More updates and corrections to the russian translation of git-gui
  Updated russian translation of git-gui
  Add a test checking if send-pack updated local tracking branches
      correctly
  Update the tracking references only if they were succesfully
      updated on remote

Andy Whitcroft (5):
  Teach send-pack a mirror mode
  git-push: plumb in --mirror mode
  Add tests for git push'es mirror mode
  git-push: add documentation for the newly added --mirror mode
  git-quiltimport.sh fix --patches handling

Anton Gyllenberg (1):
  gitview: import only one of gtksourceview and gtksourceview2

Ask Bjørn Hansen (1):
  send-email: Don't add To: recipients to the Cc: header

Christian Couder (4):
  Bisect reset: remove bisect refs that may have been packed.
  Bisect visualize: use "for-each-ref" to list all good refs.
  Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.
  Bisect reset: do nothing when not bisecting.

Christian Stimming (12):
  Mark strings for translation.
  Makefile rules for translation catalog generation and installation.
  Add glossary that can be converted into a po file for each
      language.
  Add glossary translation template into git.
  German translation for git-gui
  German glossary for translation
  git-gui: Add more words to translation glossary
  git-gui: Update German glossary according to mailing list
      discussion
  git-gui: Incorporate glossary changes into existing German
      translation
  git-gui: Update German translation, including latest glossary
      changes
  git-gui: Add more terms to glossary.
  git-gui: Update German translation

Daniel Barkalow (5):
  Miscellaneous const changes and utilities
  Build-in peek-remote, using transport infrastructure.
  Use built-in send-pack.
  Build-in send-pack, with an API for other programs to call.
  Build in ls-remote

David D Kilzer (3):
  git-svn log: fix ascending revision ranges
  git-svn log: include commit log for the smallest revision in a
      range
  git-svn log: handle unreachable revisions like "svn log"

David D. Kilzer (4):
  git-send-email: show all headers when sending mail
  git-svn: extract reusable code into utility functions
  git-svn info: implement info command
  git-svn: info --url [path]

David Reiss (1):
  git-svn: Fix a typo and add a comma in an error message in git-svn

David Symonds (2):
  git-checkout: Support relative paths containing "..".
  git-checkout: Test for relative path use.

Eric Wong (3):
  git-svn: add tests for command-line usage of init and clone
      commands
  t9106: fix a race condition that caused svn to miss modifications
  git-svn: allow `info' command to work offline

Guido Ostkamp (1):
  Use compat mkdtemp() on Solaris boxes

Harri Ilari Tapio Liusvaara (1):
  git-gui: Disambiguate "commit"

Irina Riesen (1):
  git-gui: initial version of russian translation

Jakub Narebski (3):
  gitweb: Style all tables using CSS
  gitweb: Put project README in div.readme, fix its padding
  autoconf: Add tests for memmem, strtoumax and mkdtemp functions

Jeff King (11):
  more terse push output
  receive-pack: don't mention successful updates
  send-pack: require --verbose to show update of tracking refs
  send-pack: track errors for each ref
  send-pack: check ref->status before updating tracking refs
  send-pack: assign remote errors to each ref
  make "find_ref_by_name" a public function
  send-pack: tighten remote error reporting
  send-pack: fix "everything up-to-date" message
  avoid "defined but not used" warning for fetch_objs_via_walker
  send-pack: cluster ref status reporting

Johannes Schindelin (9):
  Add po/git-gui.pot
  Ignore po/*.msg
  git-gui: Deiconify startup wizard so it raises to the top
  git-gui: add a simple msgfmt replacement
  po2msg: ignore entries marked with "fuzzy"
  po2msg: ignore untranslated messages
  po2msg: actually output statistics
  Close files opened by lock_file() before unlinking.
  rebase -i: move help to end of todo file

Johannes Sixt (14):
  git-gui: Change main window layout to support wider screens
  Give git-am back the ability to add Signed-off-by lines.
  t5300-pack-object.sh: Split the big verify-pack test into smaller
      parts.
  t7501-commit.sh: Not all seds understand option -i
  t5302-pack-index: Skip tests of 64-bit offsets if necessary.
  Skip t3902-quoted.sh if the file system does not support funny
      names.
  Use is_absolute_path() in sha1_file.c.
  Move #include <sys/select.h> and <sys/ioctl.h> to
      git-compat-util.h.
  builtin run_command: do not exit with -1.
  Allow a relative builtin template directory.
  Introduce git_etc_gitconfig() that encapsulates access of
      ETC_GITCONFIG.
  Allow ETC_GITCONFIG to be a relative path.
  fetch-pack: Prepare for a side-band demultiplexer in a thread.
  Flush progress message buffer in display().

Junio C Hamano (20):
  git-gui po/README: Guide to translators
  git-gui: Update Japanese strings (part 2)
  scripts: Add placeholders for OPTIONS_SPEC
  git-rev-parse --parseopt
  git-sh-setup: fix parseopt `eval` string underquoting
  send-pack: segfault fix on forced push
  git-am: -i does not take a string parameter.
  git-bisect: war on "sed"
  git-bisect: use update-ref to mark good/bad commits
  git-bisect: modernize branch shuffling hack
  Draft release notes: fix clean.requireForce description
  Update draft release notes for 1.5.4
  git-clean: Fix error message if clean.requireForce is not set.
  git-compat-util.h: auto-adjust to compiler support of FLEX_ARRAY a
      bit better
  Fix "quote" misconversion for rewrite diff output.
  Make test scripts executable.
  Addendum to "MaintNotes"
  t4119: correct overeager war-on-whitespace
  Deprecate peek-remote
  Update draft release notes for 1.5.4

Kirill (1):
  Updated Russian translation.

Konstantin V. Arkhipov (1):
  git-svn's dcommit must use subversion's config

Linus Torvalds (6):
  Simplify topo-sort logic
  Add "--early-output" log flag for interactive GUI use
  Enhance --early-output format
  revision walker: mini clean-up
  Fix rev-list when showing objects involving submodules
  Fix parent rewriting in --early-output

Michele Ballabio (4):
  git-gui: remove dots in some UI strings
  git-gui: add some strings to translation
  git-gui: fix typo in lib/blame.tcl
  git-gui: update Italian translation

Mike Hommey (1):
  Do git reset --hard HEAD when using git rebase --skip

Miklos Vajna (1):
  Hungarian translation of git-gui

Nanako Shiraishi (2):
  Japanese translation of git-gui
  git-gui: Update Japanese strings

Nicolas Pitre (1):
  rehabilitate some t5302 tests on 32-bit off_t machines

Paolo Ciarrocchi (1):
  Italian translation of git-gui

Pierre Habouzit (17):
  Add a parseopt mode to git-rev-parse to bring parse-options to
      shell scripts.
  Update git-sh-setup(1) to allow transparent use of git-rev-parse
      --parseopt
  Migrate git-clean.sh to use git-rev-parse --parseopt.
  Migrate git-clone to use git-rev-parse --parseopt
  Migrate git-am.sh to use git-rev-parse --parseopt
  Migrate git-merge.sh to use git-rev-parse --parseopt
  Migrate git-instaweb.sh to use git-rev-parse --parseopt
  Migrate git-checkout.sh to use git-rev-parse --parseopt
      --keep-dashdash
  Migrate git-quiltimport.sh to use git-rev-parse --parseopt
  Migrate git-repack.sh to use git-rev-parse --parseopt
  sh-setup: don't let eval output to be shell-expanded.
  parse-options new features.
  Use OPT_SET_INT and OPT_BIT in builtin-branch
  Use OPT_BIT in builtin-for-each-ref
  Use OPT_BIT in builtin-pack-refs
  Make the diff_options bitfields be an unsigned with explicit masks.
  Reorder diff_opt_parse options more logically per topics.

Shawn Bohrer (2):
  Make git-clean a builtin
  Teach git clean to use setup_standard_excludes()

Shawn O. Pearce (57):
  git-gui: Locate the library directory early during startup
  git-gui: Initialize Tcl's msgcat library for internationalization
  git-gui: Update po/README as symlink process is not necessary
  git-gui: Correct stock message for 'Invalid font specified in %s'
  git-gui: Quiet the msgfmt part of the make process
  git-gui: Ensure msgfmt failure stops GNU make
  git-gui: Mark revision chooser tooltip for translation
  git-gui: Localize commit/author dates when displaying them
  git-gui: Support context-sensitive i18n
  git-gui: Document the new i18n context support
  git-gui: Make the tree browser also use lightgray selection
  git-gui: Paper bag fix missing translated strings
  git-gui: Fix missing i18n markup in push/fetch windows
  git-gui: Support native Win32 Tcl/Tk under Cygwin
  git-gui: Refactor some UI init to occur earlier
  git-gui: Allow users to choose/create/clone a repository
  git-gui: Avoid console scrollbars unless they are necessary
  git-gui: Don't bother showing OS error message about hardlinks
  git-gui: Keep the UI responsive while counting objects in clone
  git-gui: Copy objects/info/alternates during standard clone
  git-gui: Don't delete console window namespaces too early
  git-gui: Don't delete scrollbars in console windows
  git-gui: Switch the git-gui logo to Henrik Nyh's logo
  git-gui: Make the status bar easier to read in the setup wizard
  git-gui: Use Henrik Nyh's git logo icon on Windows systems
  git-gui: Support a native Mac OS X application bundle
  git-gui: Refer to ourselves as "Git Gui" and not "git-gui"
  git-gui: Allow forced push into remote repository
  git-gui: Refactor Henrik Nyh's logo into its own procedure
  git-gui: Refactor about dialog code into its own module
  git-gui: Include our Git logo in the about dialog
  git-gui: Use progress meter in the status bar during index updates
  git-gui: Consolidate the Fetch and Push menus into a Remote menu
  git-gui: Bind Cmd-, to Preferences on Mac OS X
  git-gui: Shorten the staged/unstaged changes title bar text
  git-gui: Updated po strings based on current sources
  git-gui: Move load_config procedure below git-version selection
  git-gui: Refactor git-config --list parsing
  git-gui: Support LFs embedded in config file values
  git-gui: Change repository browser radio buttons to hyperlinks
  git-gui: Offer repository management features in menu bar
  git-gui: Fix bind errors when switching repository chooser panels
  git-gui: Disable the text widget in the repository chooser
  git-gui: Bind n/c/o accelerators in repository chooser
  git-gui: Ensure copyright message is correctly read as UTF-8
  git-gui: Use proper Windows shortcuts instead of bat files
  git-gui: Support cloning Cygwin based work-dirs
  git-gui: Collapse $env(HOME) to ~/ in recent repositories on
      Windows
  git-gui: Honor a config.mak in git-gui's top level
  git-gui: Paper bag fix the global config parsing
  git-gui: Make sure we get errors from git-update-index
  git-gui: Protect against bad translation strings
  git-gui: Allow users to set font weights to bold
  Reteach builtin-ls-remote to understand remotes
  git-gui: Bind Meta-T for "Stage To Commit" menu action
  Fix warning about bitfield in struct ref
  git-gui 0.9.0

Shun Kei Leung (1):
  git-p4: Fix typo in --detect-labels

Simon Hausmann (1):
  git-p4: Fix direct import from perforce after fetching changes
      through git from origin

Steffen Prohaska (4):
  git-gui: add directory git-gui is located in to PATH (on Windows)
  git-gui: set NO_MSGFMT to force using pure tcl replacement in
      msysgit
  git-gui: add mingw specific startup wrapper
  git-gui: offer a list of recent repositories on startup

Thomas Harning (1):
  git-merge-ours: make it a builtin.

Wincent Colaiuta (3):
  Further clarify clean.requireForce changes
  Authenticate only once in git-send-email
  Refactor patch_update_cmd

Xudong Guan (2):
  Initial Chinese translation for git-gui
  git-gui: Added initial version of po/glossary/zh_cn.po

What's in git.git (stable)

[Junio C Hamano]

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

J. Bruce Fields (4):
  user-manual: define "branch" and "working tree" at start
  user-manual: failed push to public repository
  user-manual: clarify language about "modifying" old commits
  user-manual: recovering from corruption

Jan Hudec (1):
  Improve description of git-branch -d and -D in man page.

Jeff King (4):
  Add basic cvsimport tests
  cvsimport: use rev-parse to support packed refs
  cvsimport: miscellaneous packed-ref fixes
  cvsimport: fix usage of cvsimport.module

Johannes Schindelin (1):
  Replace the word 'update-cache' by 'update-index' everywhere

Johannes Sixt (1):
  t7003-filter-branch: Fix test of a failing --msg-filter.

Junio C Hamano (1):
  scripts: do not get confused with HEAD in work tree


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

André Goddard Rosa (2):
  Print the real filename that we failed to open.
  Error out when user doesn't have access permission to the repository

Jakub Narebski (1):
  Add config_int() method to the Git perl module

Jeff King (1):
  Revert "t5516: test update of local refs on push"

Johannes Schindelin (4):
  filter-branch: fix dirty way to provide the helpers to commit filters
  git checkout's reflog: even when detaching the HEAD, say from where
  bash completion: add diff options
  receive-pack: allow deletion of corrupt refs

Junio C Hamano (3):
  revert/cherry-pick: do not mention the original ref
  dir.c: minor clean-up
  per-directory-exclude: lazily read .gitignore files

Linus Torvalds (2):
  Fix a pathological case in git detecting proper renames
  Fix a pathological case in git detecting proper renames

Pascal Obry (1):
  git-stash: do not get fooled with "color.diff = true"

Steffen Prohaska (2):
  Use is_absolute_path() in diff-lib.c, lockfile.c, setup.c, trace.c
  sha1_file.c: Fix size_t related printf format warnings

Wincent Colaiuta (1):
  Fix typo in draft 1.5.4 release notes

What's in git.git (stable)

[Junio C Hamano]

Nothing exciting on 'maint' since 1.5.3.7.

On the 'master' front, we will soon be in feature freeze for 1.5.4.
Many topics that have been cooking in 'next' has been pushed out.  This
round it is a rather large batch but hopefully it will not destabilize
it too much.  Knock wood.

 * "git pull --rebase" is a different way to integrate what you fetched
   into your current branch.

 * "git fast-export" produces datastream that can be fed to fast-import
   to reproduce the history recorded in a git repository.

 * gitk is now merged as a subdirectory of git.git project, in
   preparation for its i18n.

 * Value "true" for color.diff and color.status configuration used to
   mean "always" (even when the output is not going to a terminal).
   This has been corrected to mean the same thing as "auto".

 * "git commit --allow-empty" allows you to create a single-parent
   commit that records the same tree as its parent, overriding the usual
   safety valve.

 * "git stash random-text" does not create a new stash anymore.  It was
   a UI mistake.  Use "git stash save random-text", or "git stash"
   (without extra args) for that.

 * HTTP proxy can be specified per remote repository using
   remote.*.proxy configuration, or global http.proxy configuration
   variable.

 * "git rebase -i" also triggers rerere to help you repeated merges.

 * "git prune --expire <time>" can exempt young loose objects from
   getting pruned.

 * "git branch --contains <commit>" can list branches that are
   descendants of a given commit.

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

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

Jeff King (1):
  t9600: test cvsimport from CVS working tree

Junio C Hamano (2):
  Fix typo in t4008 test title
  GIT 1.5.3.7


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

Andy Whitcroft (1):
  git-svn: add support for pulling author from From: and Signed-off-by:

Carlos Rica (1):
  Make builtin-tag.c use parse_options.

Christian Couder (2):
  Documentation: add a new man page for "git-help"
  Trace and quote with argv: get rid of unneeded count argument.

David D. Kilzer (1):
  git-svn: Remove unnecessary Git::SVN::Util package

David Symonds (1):
  Mention that git-rm can be an appropriate resolution as well as git-add.

Denis Cheng (1):
  gitweb: the commitdiff is very commonly used, it's needed on search page,
    too

Gustaf Hendeby (1):
  git-svn now reads settings even if called in subdirectory

Jakub Narebski (1):
  gitweb: Update and improve gitweb/README file

Jeff King (2):
  git-tag: test that -s implies an annotated tag
  Enable rewrite as well as rename detection in git-status

Johannes Schindelin (7):
  Replace instances of export VAR=VAL with VAR=VAL; export VAR
  Teach 'git pull' about --rebase
  rebase -i: give rerere a chance
  Add "--expire <time>" option to 'git prune'
  Add 'git fast-export', the sister of 'git fast-import'
  fast-export: rename the signed tag mode 'ignore' to 'verbatim'
  Allow ':/<oneline-prefix>' syntax to work with save_commit_buffer == 0

Johannes Sixt (1):
  git-commit: Allow to amend a merge commit that does not change the tree

Junio C Hamano (17):
  Move gitk to its own subdirectory
  git-branch --contains=commit
  git-branch --contains: doc and test
  builtin-tag: accept and process multiple -m just like git-commit
  "git-tag -s" should create a signed annotated tag
  "color.diff = true" is not "always" anymore.
  git-config --get-color: get configured color
  Update draft release notes for 1.5.4
  Resurrect peek-remote
  Consolidate command list to one.
  Update draft release notes for 1.5.4
  rename: Break filepairs with different types.
  git-am: catch missing author date early.
  git-commit --allow-empty
  git-commit documentation: fix unfinished sentence.
  Add git-fast-export to list of commands.
  Update draft release notes for 1.5.4

Kevin Leung (1):
  git-stash: Display help message if git-stash is run with wrong
    sub-commands

Pierre Habouzit (1):
  parse-options: Allow to hide options from the default usage.

Robert Schiele (1):
  install-sh from automake does not like -m without delimiting space

Sam Vilain (2):
  Allow HTTP proxy to be overridden in config
  Add remote.<name>.proxy

Steven Grimm (1):
  git-svn: Don't create a "master" branch every time rebase is run

Theodore Ts'o (2):
  Make the list of common commands more exclusive
  Remove hint to use "git help -a"

Vineet Kumar (1):
  git-svn: add a show-externals command.

Wincent Colaiuta (1):
  revert/cherry-pick: Allow overriding the help text by the calling
    Porcelain

What's in git.git (stable)

[Junio C Hamano]

I haven't tagged the tip of 'master' as -rc0 yet, this has more than 80%
of it.  Graduated to 'master' tonight are:

 * Wincent's "git add -p"
 * "git commit in C" by Kristian and others
 * Steffen Prohaska's clean-up of push/fetch refspec handling.

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

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

Alex Riesen (2):
  Do not generate full commit log message if it is not going to be used
  Simplify crud() in ident.c

H.Merijn Brand (1):
  Do not rely on the exit status of "unset" for unset variables

Jakub Narebski (1):
  contrib: Make remotes2config.sh script more robust

Jeff King (3):
  git-commit: clean up die messages
  quote_path: fix collapsing of relative paths
  t9600: require cvsps 2.1 to perform tests

Johannes Schindelin (8):
  launch_editor(): read the file, even when EDITOR=:
  builtin-commit: fix reflog message generation
  git status: show relative paths when run in a subdirectory
  builtin-commit: fix --signoff
  builtin-commit --s: add a newline if the last line was not a S-o-b
  builtin-commit: resurrect behavior for multiple -m options
  builtin-commit: Add newline when showing which commit was created
  Replace "runstatus" with "status" in the tests

Junio C Hamano (15):
  file_exists(): dangling symlinks do exist
  builtin-commit: do not color status output shown in the message template
  builtin-commit: run commit-msg hook with correct message file
  Export three helper functions from ls-files
  Fix add_files_to_cache() to take pathspec, not user specified list of
    files
  builtin-commit: fix partial-commit support
  git-add -i: allow multiple selection in patch subcommand
  Add a few more tests for git-commit
  builtin-add: fix command line building to call interactive
  add -i: Fix running from a subdirectory
  Fix --signoff in builtin-commit differently.
  git-commit: Allow to amend a merge commit that does not change the tree
  git-commit --allow-empty
  Documentation/git.txt: typofix
  t5510: add a bit more tests for fetch

Kristian Høgsberg (10):
  Add testcase for amending and fixing author in git commit.
  Export launch_editor() and make it accept ':' as a no-op editor.
  Port git commit to C.
  builtin-commit: Refresh cache after adding files.
  Call refresh_cache() when updating the user index for --only commits.
  builtin-commit: Clean up an unused variable and a debug fprintf().
  t7501-commit: Add test for git commit <file> with dirty index.
  builtin-commit: Include the diff in the commit message when verbose.
  Fix off-by-one error when truncating the diff out of the commit message.
  Use a strbuf for copying the command line for the reflog.

Pascal Obry (1):
  Set OLD_ICONV on Cygwin.

Pierre Habouzit (1):
  builtin-commit.c: export GIT_INDEX_FILE for launch_editor as well.

Ralf Wildenhues (1):
  Document all help keys in "git add -i" patch mode.

Shawn Bohrer (1):
  Make git status usage say git status instead of git commit

Shawn O. Pearce (1):
  Remove git-status from list of scripts as it is builtin

Steffen Prohaska (4):
  push: support pushing HEAD to real branch name
  add refname_match()
  push: use same rules as git-rev-parse to resolve refspecs
  refactor fetch's ref matching to use refname_match()

Wincent Colaiuta (6):
  Teach builtin-add to pass multiple paths to git-add--interactive
  Add path-limiting to git-add--interactive
  Add "--patch" option to git-add--interactive
  Highlight keyboard shortcuts in git-add--interactive
  add -i: allow prefix highlighting for "Add untracked" as well.
  git-add -i: add help text for list-and-choose UI

İsmail Dönmez (1):
  gitweb: use Perl built-in utf8 function for UTF-8 decoding.

What's in git.git (stable)

[Junio C Hamano]

Heavy merges to 'master' continues.  We are almost there for -rc0.
Merged to 'master' are:

 * Colorized "add -i" (Dan Zwell)
 * Talk more about diff options in "git log" documentation (Miklos)
 * git-gui 0.9.1 preview
 * Make cvsserver act more like receive-pack (Michael Witten)
 * "git-clean <paths>" limits the damage to named paths
 * Use right Perl in Documentation/Makefile

Also people's favorite topic "squelching compilation warnings for iconv"
is included.

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

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

David Symonds (1):
  Change from using email.com to example.com as example domain, as per RFC
    2606.

Junio C Hamano (2):
  git grep shows the same hit repeatedly for unmerged paths
  git-am -i: report rewritten title

Nguyễn Thái Ngọc Duy (3):
  Add missing inside_work_tree setting in setup_git_directory_gently
  Do check_repository_format() early
  Do check_repository_format() early (re-fix)

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

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

Björn Steinbrink (1):
  git config: Don't rely on regexec() returning 1 on non-match

Brian M. Carlson (1):
  git-gui: Reorder msgfmt command-line arguments

Christian Stimming (2):
  Update git-gui.pot with latest (few) string additions and changes.
  Update German translation. 100% completed.

Jakub Narebski (1):
  autoconf: Add test for OLD_ICONV (squelching compiler warning)

Jeff King (1):
  t7300: add test for clean with wildcard pathspec

Johannes Sixt (2):
  git-gui: Improve the application icon on Windows.
  for-each-ref: Fix quoting style constants.

Junio C Hamano (12):
  Run the specified perl in Documentation/
  git-cvsserver runs hooks/post-update
  Revert "git-am: catch missing author date early."
  Documentation: color.* = true means "auto"
  git config --get-colorbool
  Color support for "git-add -i"
  git-clean: Honor pathspec.
  config --get-colorbool: diff.color is a deprecated synonym to color.diff
  hg-to-git: handle an empty dir in hg.
  do not discard status in fetch_refs_via_pack()
  git-status documentation: mention subdirectory behaviour
  Update draft release notes to 1.5.4

Kristian Høgsberg (1):
  Rewrite builtin-fetch option parsing to use parse_options().

Matthias Kestenholz (1):
  Documentation: add --patch option to synopsis of git-add

Michael Witten (1):
  git-cvsserver runs hooks/post-receive

Michele Ballabio (2):
  git-gui: fix a typo in lib/commit.tcl
  git-gui: update it.po and glossary/it.po

Miklos Vajna (2):
  Include diff options in the git-log manpage
  Update Hungarian translation. 100% completed.

Nanako Shiraishi (1):
  Update ja.po for git-gui

Robert Schiele (1):
  git-gui: install-sh from automake does not like -m755

Wincent Colaiuta (1):
  Silence iconv warnings on Leopard

What's in git.git (stable)

[Junio C Hamano]

One more topic remains in 'next' before 1.5.4-rc0 where "bugfix only"
freeze period begins.  We have a handful regression fixes on 'master'
from the fallout from massive C-rewrite during this cycle.

People still following 'next' are requested to switch to 'master', and
spare a bit more time on finding and fixing regressions there instead of
coming up with new topics from now on.

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

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

Jim Meyering (1):
  config.c:store_write_pair(): don't read the byte before a malloc'd
    buffer.

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

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

Jeff King (3):
  wt-status.c:quote_path(): convert empty path to "./"
  add status.relativePaths config variable
  git-status: documentation improvements

Junio C Hamano (13):
  War on whitespace: first, a bit of retreat.
  git-diff: complain about >=8 consecutive spaces in initial indent
  core.whitespace: add test for diff whitespace error highlighting
  builtin-apply: rename "whitespace" variables and fix styles
  builtin-apply: teach whitespace_rules
  core.whitespace: documentation updates.
  Use gitattributes to define per-path whitespace rule
  git-bisect visualize: work in non-windowed environments better
  mailmap: fix bogus for() loop that happened to be safe by accident
  shortlog: code restructuring and clean-up
  ls-remote: resurrect pattern limit support
  Fix commit-msg hook to allow editing
  Re-fix "builtin-commit: fix --signoff"

Nicolas Pitre (3):
  pack-objects: fix delta cache size accounting
  pack-objects: reverse the delta search sort list
  pack-objects: fix threaded load balancing

Pini Reznik (1):
  Open external merge tool with original file extensions for all three
    files

Sergei Organov (1):
  Let git-help prefer man-pages installed with this version of git

Wincent Colaiuta (4):
  Teach "git add -i" to colorize whitespace errors
  Allow --no-verify to bypass commit-msg hook
  Documentation: fix --no-verify documentation for "git commit"
  Add tests for pre-commit and commit-msg hooks

v1.5.4 plans

[Junio C Hamano]

People might have noticed that I've been ignoring most of the new
topics/enhancements for the past few days.  Here is what I want to see
happen until we declare v1.5.4.

First, stabilize 'master' enough and tag v1.5.4-rc0 soon.

 * Among what's already in 'next', Christian's "git help -w" enhancement
   is the only candidate to be in v1.5.4.  Johannes's "git remote" could
   also be, but I've seen it fail tests when run in my k.org private
   repository and haven't had chance to find time to diagnose it, so I'd
   rather leave it after v1.5.4.

 * Eric's sanely-compact mapping from SVN rev-ids to git commits saw a
   positive feedback.  I haven't carefully read that patch but it seemed
   sane and I'd like to have it in v1.5.4.

 * Please, everybody, no more new features until v1.5.4 final ships, and
   please spend a bit more time on finding and fixing regressions than
   you would spend time cooking your favorite new features.  I do not
   have infinite amount of time to comment on new feature patches while
   concentrating on fixes at the same time.

There are outstanding issues that need to be resolved:

 * I'd like to see the pack-object's memory performance issue resolved
   before the release; two very capable people are looking into it and I
   am fairly optimistic.

 * We need to do something about "gc --aggressive".  The documentation
   removal patch from Linus, if it ever materializes, would be better
   than nothing, but I have this nagging suspicion that the explosion is
   merely a bad interation between -A and -f option to the repack, which
   are not meant to be used together.

 * We have a handful deprecation notices in the draft release notes, but
   if I recall correctly, Nico wanted to add a few more.  We need to
   come up with a wording that is easy to understand for the end users
   to decide which ancient versions will be affected.

  "git help -w" will want to have the HTML pages installed, which means
   we would need to add a new package to hold it in git.spec.in.  I am
   willing to work on the initial draft, but help in testing is very
   much appreciated --- I do not work on RPM systems myself.  The same
   goes for "git help -i" which will want the INFO pages installed.

 * I've seen t9119-git-svn-info.sh fail in my k.org private repository
   and have been skipping the test, but this needs to be diagnosed and
   fixed [*1*].  It could be just that the code is fine and the test is
   not rejecting SVN that is too-old. I dunno.

 * There have been quite a few HTTP paches from Mike Hommey.  I'd like
   to limit the changes only to fixes and trivially-correct clean-ups,
   which means these will need to be looked at:

    [PATCH 1/4] Cleanup variables in http.[ch]
    [PATCH 2/4] Use strbuf in http code
    [PATCH 1/5] Remove the default_headers variable from http-push.c
    [PATCH 2/5] Remove a CURLOPT_HTTPHEADER (un)setting
    [PATCH 3/5] Avoid redundant declaration of missing_target()
    [PATCH 4/5] Correctly initialize buffer in start_put() in http-push.c
    [PATCH 5/5] Fix various memory leaks in http-push.c and http-walker.c

   Help in reviewing these from people who were involved in the http
   part of the current codebase is very much appreciated.

If we can freeze by the end of the year, we may be able to release mid
January 2008.


[Footnote]
----------------------------------------------------------------

*1* t9119 first fails at the 6th test.  Perhaps the test needs to check
svn version first and stop testing this feature.  This test does not
fail on my personal box that has svn 1.4.2.

* expecting success:
        (cd svnwc; svn info file) > expected.info-file &&
        (cd gitwc; git-svn info file) > actual.info-file &&
        git-diff expected.info-file actual.info-file

diff --git a/expected.info-file b/actual.info-file
index b1d57f4..997c927 100644
--- a/expected.info-file
+++ b/actual.info-file
@@ -10,6 +10,5 @@ Last Changed Author: junio
 Last Changed Rev: 1
 Last Changed Date: 2007-12-10 22:18:12 +0000 (Mon, 10 Dec 2007)
 Text Last Updated: 2007-12-10 22:18:13 +0000 (Mon, 10 Dec 2007)
-Properties Last Updated: 2007-12-10 22:18:13 +0000 (Mon, 10 Dec 2007)
 Checksum: 5bbf5a52328e7439ae6e719dfe712200

* FAIL 6: info file

                (cd svnwc; svn info file) > expected.info-file &&
                (cd gitwc; git-svn info file) > actual.info-file &&
                git-diff expected.info-file actual.info-file

: hera t/master; svn --version
svn, version 1.3.2 (r19776)
   compiled Jun  1 2006, 10:05:51

Copyright (C) 2000-2006 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_dav : Module for accessing a repository via WebDAV (DeltaV) protocol.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

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

Re: v1.5.4 plans

[Jeff King]

On Mon, Dec 10, 2007 at 02:37:09PM -0800, Junio C Hamano wrote:

>  * Please, everybody, no more new features until v1.5.4 final ships, and
>    please spend a bit more time on finding and fixing regressions than
>    you would spend time cooking your favorite new features.  I do not
>    have infinite amount of time to comment on new feature patches while
>    concentrating on fixes at the same time.
> 
> There are outstanding issues that need to be resolved:

A few regressions that you did not mention, but I think should be
addressed before 1.5.4:

 - extra newline in builtin-commit output. You found a case that
   needs it, but fixing it is non-trivial, and I wanted to get your
   input before preparing a patch. See

     http://mid.gmane.org/20071203075357.GB3614@sigill.intra.peff.net

 - git-clean's handling of directory wildcards. I didn't get a response
   to

     http://mid.gmane.org/20071206043247.GC5499@coredump.intra.peff.net

   I suspect there are still some bugs lurking in there, but it's hard
   to say because I don't know what the behavior _should_ be (there are
   some test cases in that email).

And perhaps not a regression, but I think we should bring git-svn's
handling of color.* in line with the changes to the rest of the code
before 1.5.4. I posted a "last resort" patch, but I think with your
changes to "git config --colorbool" it might be possible to use that.
I'll try to work up a new patch.

-Peff

Re: v1.5.4 plans

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> A few regressions that you did not mention, but I think should be
> addressed before 1.5.4:
>
>  - extra newline in builtin-commit output. You found a case that
>    needs it, but fixing it is non-trivial, and I wanted to get your
>    input before preparing a patch. See
>
>      http://mid.gmane.org/20071203075357.GB3614@sigill.intra.peff.net

I am actually becoming somewhat fond of the newline that makes the end
of a session that led to a commit stand out ;-). IOW, I was wondering if
we can have another for a merge commit case.

But I suspect that it amounts to the change in the same area and of
similar complexity.

>  - git-clean's handling of directory wildcards. I didn't get a response
>    to
>
>      http://mid.gmane.org/20071206043247.GC5499@coredump.intra.peff.net
>
>    I suspect there are still some bugs lurking in there, but it's hard
>    to say because I don't know what the behavior _should_ be (there are
>    some test cases in that email).

The last time I looked at the "directory" side of builtin-clean.c, I had
to quickly reach for my barf bag.  I never use "git clean" without "-n"
and I never ever use "git clean" with "-d"; I do not have any idea what
behaviour when given "-d" would be useful.  AFAIU, the scripted version
did not have clear semantics either.

Another thing that irritates me is it talks about not removing a
directory when run "git clean -n" (without -d).  I did not ask it to
remove directories, so I did not expect it to talk about it not doing
what I did not ask it to.

> And perhaps not a regression, but I think we should bring git-svn's
> handling of color.* in line with the changes to the rest of the code
> before 1.5.4. I posted a "last resort" patch, but I think with your
> changes to "git config --colorbool" it might be possible to use that.
> I'll try to work up a new patch.

Thanks for a reminder.  Anything else?

Re: v1.5.4 plans

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Jeff King <peff@peff.net> writes:
>
>> A few regressions that you did not mention, but I think should be
>> addressed before 1.5.4:
>>
>>  - extra newline in builtin-commit output. You found a case that
>>    needs it, but fixing it is non-trivial, and I wanted to get your
>>    input before preparing a patch. See
>>
>>      http://mid.gmane.org/20071203075357.GB3614@sigill.intra.peff.net
>
> I am actually becoming somewhat fond of the newline that makes the end
> of a session that led to a commit stand out ;-). IOW, I was wondering if
> we can have another for a merge commit case.
>
> But I suspect that it amounts to the change in the same area and of
> similar complexity.

-- >8 --
[PATCH] commit: do not add extra LF at the end of the summary.

The scripted version relied on the nice "auto-strip the terminating LF"
behaviour shell gives to "var=$(cmd)" construct, but we have to roll
that ourselves.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-commit.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/builtin-commit.c b/builtin-commit.c
index b6b81d5..e5a972c 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -660,12 +660,17 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
 	rev.verbose_header = 1;
 	rev.show_root_diff = 1;
 	rev.commit_format = get_commit_format("format:%h: %s");
-	rev.always_show_header = 1;
+	rev.always_show_header = 0;
 
 	printf("Created %scommit ", initial_commit ? "initial " : "");
 
-	log_tree_commit(&rev, commit);
-	printf("\n");
+	if (!log_tree_commit(&rev, commit)) {
+		struct strbuf buf = STRBUF_INIT;
+		pretty_print_commit(rev.commit_format, commit, &buf,
+				    0, NULL, NULL, 0, 0);
+		printf("%s\n", buf.buf);
+		strbuf_release(&buf);
+	}
 }
 
 int git_commit_config(const char *k, const char *v)
-- 
1.5.3.7-1149-g591a

Re: v1.5.4 plans

[Jeff King]

On Mon, Dec 10, 2007 at 09:02:26PM -0800, Junio C Hamano wrote:

> [PATCH] commit: do not add extra LF at the end of the summary.
> 
> The scripted version relied on the nice "auto-strip the terminating LF"
> behaviour shell gives to "var=$(cmd)" construct, but we have to roll
> that ourselves.

This looks reasonable and generates the correct output as far as I can
tell, but...

> -	log_tree_commit(&rev, commit);
> -	printf("\n");
> +	if (!log_tree_commit(&rev, commit)) {
> +		struct strbuf buf = STRBUF_INIT;
> +		pretty_print_commit(rev.commit_format, commit, &buf,
> +				    0, NULL, NULL, 0, 0);
> +		printf("%s\n", buf.buf);
> +		strbuf_release(&buf);
> +	}

We are duplicating the "!shown && ..." conditional branch from
log_tree_commit, which calls show_log. Why are we not calling show_log
instead of pretty_print_commit (I understand that show_log should end up
calling pretty_print_commit, but it is not immediately obvious that all
of the extra code in show_log is going to be ignored).

-Peff

Re: v1.5.4 plans

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> We are duplicating the "!shown && ..." conditional branch from
> log_tree_commit, which calls show_log. Why are we not calling show_log
> instead of pretty_print_commit (I understand that show_log should end up
> calling pretty_print_commit, but it is not immediately obvious that all
> of the extra code in show_log is going to be ignored).

Exactly.  I think show_log() has become too complex, and when we want a
oneline userformat, pretty-print-commit is more appropriate to use.
Actually, when I re-review the code, I think the part should use
format_commit_message() which is more to the point without any of the
other "more generic" parameter pretty-print-commit takes.

Re: v1.5.4 plans

[Jeff King]

On Mon, Dec 10, 2007 at 10:47:18PM -0800, Junio C Hamano wrote:

> > We are duplicating the "!shown && ..." conditional branch from
> > log_tree_commit, which calls show_log. Why are we not calling show_log
> > instead of pretty_print_commit (I understand that show_log should end up
> > calling pretty_print_commit, but it is not immediately obvious that all
> > of the extra code in show_log is going to be ignored).
> 
> Exactly.  I think show_log() has become too complex, and when we want a
> oneline userformat, pretty-print-commit is more appropriate to use.
> Actually, when I re-review the code, I think the part should use
> format_commit_message() which is more to the point without any of the
> other "more generic" parameter pretty-print-commit takes.

Perhaps it would be even more readable to simply split the printing of
the commit message and the diff. Tracking this bug was a bit confusing.
Ideally, print_summary would just say:

  print_commit_message(commit);
  print_diff(commit, "^commit");

where obviously each of those takes a few lines to say properly. But the
use of a combination "show the log and maybe the diff" function seems
like a shell holdover, trying to avoid spawning too many processes.

-Peff

Re: v1.5.4 plans

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Perhaps it would be even more readable to simply split the printing of
> the commit message and the diff. Tracking this bug was a bit confusing.
> Ideally, print_summary would just say:
>
>   print_commit_message(commit);
>   print_diff(commit, "^commit");
>
> where obviously each of those takes a few lines to say properly. But the
> use of a combination "show the log and maybe the diff" function seems
> like a shell holdover, trying to avoid spawning too many processes.

Perhaps, but that's post 1.5.4.  There is no short-hand to call the
single commit diff-tree and not give any commit header afair.

Anyway, format-commit-message() makes it much more readable ;-)

diff --git a/builtin-commit.c b/builtin-commit.c
index b6b81d5..9cb7589 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -660,12 +660,16 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
 	rev.verbose_header = 1;
 	rev.show_root_diff = 1;
 	rev.commit_format = get_commit_format("format:%h: %s");
-	rev.always_show_header = 1;
+	rev.always_show_header = 0;
 
 	printf("Created %scommit ", initial_commit ? "initial " : "");
 
-	log_tree_commit(&rev, commit);
-	printf("\n");
+	if (!log_tree_commit(&rev, commit)) {
+		struct strbuf buf = STRBUF_INIT;
+		format_commit_message(commit, "%h: %s", &buf);
+		printf("%s\n", buf.buf);
+		strbuf_release(&buf);
+	}
 }
 
 int git_commit_config(const char *k, const char *v)

Re: v1.5.4 plans

[Jeff King]

On Mon, Dec 10, 2007 at 11:00:55PM -0800, Junio C Hamano wrote:

> Perhaps, but that's post 1.5.4.  There is no short-hand to call the
> single commit diff-tree and not give any commit header afair.

OK. I was going to add a "something like this..." patch to my last
email, but realized I had no idea how one would invoke the diff
machinery in such a way.

> Anyway, format-commit-message() makes it much more readable ;-)

The repetition of the format string is a little ugly. But otherwise,

Acked-by: Jeff King <peff@peff.net>

-Peff

Re: v1.5.4 plans

[Jeff King]

On Mon, Dec 10, 2007 at 05:27:17PM -0800, Junio C Hamano wrote:

> > And perhaps not a regression, but I think we should bring git-svn's
> > handling of color.* in line with the changes to the rest of the code
> > before 1.5.4. I posted a "last resort" patch, but I think with your
> > changes to "git config --colorbool" it might be possible to use that.
> > I'll try to work up a new patch.
> 
> Thanks for a reminder.  Anything else?

2-patch series will follow momentarily. 1/2 gives --get-colorbool the
necessary information for implementing color.pager, and 2/2 fixes
git-svn.

Very light testing by me, since I'm not actually a git-svn user, but it
does pass the test scripts. Acks from svn-using people would be nice.

-Peff

Re: v1.5.4 plans

[Jeff King]

Subject: [PATCH 1/2] Support GIT_PAGER_IN_USE environment variable

When deciding whether or not to turn on automatic color
support, git_config_colorbool checks whether stdout is a
tty. However, because we run a pager, if stdout is not a
tty, we must check whether it is because we started the
pager. This used to be done by checking the pager_in_use
variable.

This variable was set only when the git program being run
started the pager; there was no way for an external program
running git indicate that it had already started a pager.
This patch allows a program to set GIT_PAGER_IN_USE to a
true value to indicate that even though stdout is not a tty,
it is because a pager is being used.

Signed-off-by: Jeff King <peff@peff.net>
---

A few notes:

We could also just put the color.pager logic in git-svn, or in Git.pm,
and have it impact the stdout_is_tty argument; but the whole point of
--get-colorbool is to consolidate that logic.

We convert pager_in_use to a function; we could also just set the
variable early on, but I think this lazy evaluation is more robust.

This might have uses besides --get-colorbool (e.g., wrapper scripts
which start their own pager can still have git sub-commands understand
whether to turn on color).

 cache.h       |    2 +-
 color.c       |    2 +-
 environment.c |    1 -
 pager.c       |   15 ++++++++++++++-
 4 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/cache.h b/cache.h
index 1bcb3df..27d90fe 100644
--- a/cache.h
+++ b/cache.h
@@ -608,7 +608,7 @@ extern int write_or_whine_pipe(int fd, const void *buf, size_t count, const char
 /* pager.c */
 extern void setup_pager(void);
 extern char *pager_program;
-extern int pager_in_use;
+extern int pager_in_use(void);
 extern int pager_use_color;
 
 extern char *editor_program;
diff --git a/color.c b/color.c
index 7bd424a..7f66c29 100644
--- a/color.c
+++ b/color.c
@@ -135,7 +135,7 @@ int git_config_colorbool(const char *var, const char *value, int stdout_is_tty)
  auto_color:
 	if (stdout_is_tty < 0)
 		stdout_is_tty = isatty(1);
-	if (stdout_is_tty || (pager_in_use && pager_use_color)) {
+	if (stdout_is_tty || (pager_in_use() && pager_use_color)) {
 		char *term = getenv("TERM");
 		if (term && strcmp(term, "dumb"))
 			return 1;
diff --git a/environment.c b/environment.c
index f3e3d41..18a1c4e 100644
--- a/environment.c
+++ b/environment.c
@@ -31,7 +31,6 @@ size_t packed_git_window_size = DEFAULT_PACKED_GIT_WINDOW_SIZE;
 size_t packed_git_limit = DEFAULT_PACKED_GIT_LIMIT;
 size_t delta_base_cache_limit = 16 * 1024 * 1024;
 char *pager_program;
-int pager_in_use;
 int pager_use_color = 1;
 char *editor_program;
 char *excludes_file;
diff --git a/pager.c b/pager.c
index fb7a1a6..0376953 100644
--- a/pager.c
+++ b/pager.c
@@ -5,6 +5,8 @@
  * something different on Windows, for example.
  */
 
+static int spawned_pager;
+
 static void run_pager(const char *pager)
 {
 	/*
@@ -41,7 +43,7 @@ void setup_pager(void)
 	else if (!*pager || !strcmp(pager, "cat"))
 		return;
 
-	pager_in_use = 1; /* means we are emitting to terminal */
+	spawned_pager = 1; /* means we are emitting to terminal */
 
 	if (pipe(fd) < 0)
 		return;
@@ -70,3 +72,14 @@ void setup_pager(void)
 	die("unable to execute pager '%s'", pager);
 	exit(255);
 }
+
+int pager_in_use(void)
+{
+	const char *env;
+
+	if (spawned_pager)
+		return 1;
+
+	env = getenv("GIT_PAGER_IN_USE");
+	return env ? git_config_bool("GIT_PAGER_IN_USE", env) : 0;
+}
-- 
1.5.3.7.2230.g796d07-dirty

Re: v1.5.4 plans

[Jeff King]

On Mon, Dec 10, 2007 at 05:27:17PM -0800, Junio C Hamano wrote:

> >    I suspect there are still some bugs lurking in there, but it's hard
> >    to say because I don't know what the behavior _should_ be (there are
> >    some test cases in that email).
> 
> The last time I looked at the "directory" side of builtin-clean.c, I had
> to quickly reach for my barf bag.  I never use "git clean" without "-n"
> and I never ever use "git clean" with "-d"; I do not have any idea what
> behaviour when given "-d" would be useful.  AFAIU, the scripted version
> did not have clear semantics either.

I had the same feeling. I am tempted to leave it, then. The
non-intuitive behavior I managed to trigger was:

  - _only_ when using git pathspec matching like "git clean -n '*.ext'"
  - confusing in a safe way (trying to remove 'dir.ext' with '*.ext'
    will accidentally not happen, rather than accidentally happening)

So unless somebody complains, it is probably not a big problem,
and I think fixing it will require mucking with pathspec and dir
matching internals, which would be nice not to do right before v1.5.4.

OTOH, leaving something that is broken and just hoping nobody will
complain feels kind of wrong. :)

-Peff

Re: v1.5.4 plans

[Andreas Ericsson]

Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
>>  - git-clean's handling of directory wildcards. I didn't get a response
>>    to
>>
>>      http://mid.gmane.org/20071206043247.GC5499@coredump.intra.peff.net
>>
>>    I suspect there are still some bugs lurking in there, but it's hard
>>    to say because I don't know what the behavior _should_ be (there are
>>    some test cases in that email).
> 
> The last time I looked at the "directory" side of builtin-clean.c, I had
> to quickly reach for my barf bag.  I never use "git clean" without "-n"
> and I never ever use "git clean" with "-d"; I do not have any idea what
> behaviour when given "-d" would be useful.


When you have a trash directory without any tracked files, clean will not
by default descend into that directory and thus won't remove neither files
nor directory. I frequently use one for automated testing, much like git's
trash repository, but the only time I do "git clean -d" is when building
things on a release-server with the repository checked out. It's faster
than "make distclean", and not all of our projects have a Makefile to begin
with. Tacking "git clean -d" at the end of test-scripts makes it simple to
remove all excess cruft in one go.

So in short, git clean -d can be useful. I have no idea when "git clean dir"
would be though.

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

Re: v1.5.4 plans

[Jeff King]

On Mon, Dec 10, 2007 at 05:27:17PM -0800, Junio C Hamano wrote:

> Thanks for a reminder.  Anything else?

This bugfix has been sitting in my repo for a few weeks.  When it last
appeared, you asked if the other code paths needed a similar fix, and I
verified that they did not, so I think it is complete as-is.

-- >8 --
git-clone: print an error message when trying to clone empty repo

Previously, cloning an empty repository looked like this:

$ (mkdir parent && cd parent && git --bare init)
$ git-clone parent child
Initialized empty Git repository in /home/peff/clone/child/.git/
$ cd child
-bash: cd: child: No such file or directory
$ echo 'wtf?' | mail git@vger.kernel.org

Now we at least report that the clone was not successful.

Signed-off-by: Jeff King <peff@peff.net>
---
 git-clone.sh |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/git-clone.sh b/git-clone.sh
index ecf9d89..96a356d 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -297,7 +297,8 @@ yes)
 				      find objects -type f -print | sed -e 1q)
 			# objects directory should not be empty because
 			# we are cloning!
-			test -f "$repo/$sample_file" || exit
+			test -f "$repo/$sample_file" ||
+				die "fatal: cannot clone empty repository"
 			if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
 			then
 				rm -f "$GIT_DIR/objects/sample"
-- 
1.5.3.7.2224.ge4a5

Re: v1.5.4 plans

[Nicolas Pitre]

On Mon, 10 Dec 2007, Junio C Hamano wrote:

> There are outstanding issues that need to be resolved:
> 
>  * We need to do something about "gc --aggressive".  The documentation
>    removal patch from Linus, if it ever materializes, would be better
>    than nothing, but I have this nagging suspicion that the explosion is
>    merely a bad interation between -A and -f option to the repack, which
>    are not meant to be used together.

Well, with the gcc repo, simply using 'git repack -a -f' with current 
default window size does produce a 2.1GB pack, while changing the window 
size to 100 (keeping default delta depth) produces a 400MB pack for me.

So this is really a matter of not having a sufficiently large window for 
some data sets.

>  * We have a handful deprecation notices in the draft release notes, but
>    if I recall correctly, Nico wanted to add a few more.  We need to
>    come up with a wording that is easy to understand for the end users
>    to decide which ancient versions will be affected.

This is still on my todo list.


Nicolas

Re: v1.5.4 plans

[Johannes Schindelin]

Hi,

On Mon, 10 Dec 2007, Nicolas Pitre wrote:

> On Mon, 10 Dec 2007, Junio C Hamano wrote:
> 
> > There are outstanding issues that need to be resolved:
> > 
> >  * We need to do something about "gc --aggressive".  The documentation
> >    removal patch from Linus, if it ever materializes, would be better
> >    than nothing, but I have this nagging suspicion that the explosion is
> >    merely a bad interation between -A and -f option to the repack, which
> >    are not meant to be used together.
> 
> Well, with the gcc repo, simply using 'git repack -a -f' with current 
> default window size does produce a 2.1GB pack, while changing the window 
> size to 100 (keeping default delta depth) produces a 400MB pack for me.
> 
> So this is really a matter of not having a sufficiently large window for 
> some data sets.

So my dumb patch to simply default to window and depth 250 with 
aggressive was not _that_ dumb after all?

Ciao,
Dscho

Re: v1.5.4 plans

[Nicolas Pitre]

On Fri, 30 Mar 2029, Johannes Schindelin wrote:

> Hi,
> 
> On Mon, 10 Dec 2007, Nicolas Pitre wrote:
> 
> > On Mon, 10 Dec 2007, Junio C Hamano wrote:
> > 
> > > There are outstanding issues that need to be resolved:
> > > 
> > >  * We need to do something about "gc --aggressive".  The documentation
> > >    removal patch from Linus, if it ever materializes, would be better
> > >    than nothing, but I have this nagging suspicion that the explosion is
> > >    merely a bad interation between -A and -f option to the repack, which
> > >    are not meant to be used together.
> > 
> > Well, with the gcc repo, simply using 'git repack -a -f' with current 
> > default window size does produce a 2.1GB pack, while changing the window 
> > size to 100 (keeping default delta depth) produces a 400MB pack for me.
> > 
> > So this is really a matter of not having a sufficiently large window for 
> > some data sets.
> 
> So my dumb patch to simply default to window and depth 250 with 
> aggressive was not _that_ dumb after all?

Probably not, although this might be rather wasteful on some 
repositories.  But that's what expectations are for --aggressive.

I wish we could find a way to set some good window default dynamically 
though.  Or perhaps the filename hashing needs improvements.


Nicolas

Re: v1.5.4 plans

[Kristian Høgsberg]

On Mon, 2007-12-10 at 14:37 -0800, Junio C Hamano wrote:
>  * We have a handful deprecation notices in the draft release notes, but
>    if I recall correctly, Nico wanted to add a few more.  We need to
>    come up with a wording that is easy to understand for the end users
>    to decide which ancient versions will be affected.

Can we deprecate .git/branches?

Kristian

Re: v1.5.4 plans

[Junio C Hamano]

Kristian Høgsberg <krh@redhat.com> writes:

> On Mon, 2007-12-10 at 14:37 -0800, Junio C Hamano wrote:
>>  * We have a handful deprecation notices in the draft release notes, but
>>    if I recall correctly, Nico wanted to add a few more.  We need to
>>    come up with a wording that is easy to understand for the end users
>>    to decide which ancient versions will be affected.
>
> Can we deprecate .git/branches?

We deprecated it from the very beginning, in the sense that we never
wrote into it ourselves, but merely tried to pay attention to what
others wrote there.  So I am open to a bullet point that officially
declares the deprecation.

But we need to come up with a removal schedule.  Say, the first feature
release after June 2008?

Re: v1.5.4 plans

[Eric Wong]

Junio C Hamano <gitster@pobox.com> wrote:
> People might have noticed that I've been ignoring most of the new
> topics/enhancements for the past few days.  Here is what I want to see
> happen until we declare v1.5.4.
> 
> First, stabilize 'master' enough and tag v1.5.4-rc0 soon.

>  * Eric's sanely-compact mapping from SVN rev-ids to git commits saw a
>    positive feedback.  I haven't carefully read that patch but it seemed
>    sane and I'd like to have it in v1.5.4.

It's looking good for most users, I think it's safe enough for 1.5.4

>  * I've seen t9119-git-svn-info.sh fail in my k.org private repository
>    and have been skipping the test, but this needs to be diagnosed and
>    fixed [*1*].  It could be just that the code is fine and the test is
>    not rejecting SVN that is too-old. I dunno.

I wouldn't mind dropping this test for now.

100% output compatibility with SVN is too difficult to achieve
and IMHO not worth it for commands like `info' and `log'.

David:

I also noticed some race-conditions on this test when running this on my
Centrino laptop (my fastest box, but I rarely use it for git
development) and having git on my USB thumb drive.  I'm pretty sure
these were caused by inconsistencies in handling timestamps on symlinks
vs timestamps on the files they link to.

> *1* t9119 first fails at the 6th test.  Perhaps the test needs to check
> svn version first and stop testing this feature.  This test does not
> fail on my personal box that has svn 1.4.2.
> 
> * expecting success:
>         (cd svnwc; svn info file) > expected.info-file &&
>         (cd gitwc; git-svn info file) > actual.info-file &&
>         git-diff expected.info-file actual.info-file
> 
> diff --git a/expected.info-file b/actual.info-file
> index b1d57f4..997c927 100644
> --- a/expected.info-file
> +++ b/actual.info-file
> @@ -10,6 +10,5 @@ Last Changed Author: junio
>  Last Changed Rev: 1
>  Last Changed Date: 2007-12-10 22:18:12 +0000 (Mon, 10 Dec 2007)
>  Text Last Updated: 2007-12-10 22:18:13 +0000 (Mon, 10 Dec 2007)
> -Properties Last Updated: 2007-12-10 22:18:13 +0000 (Mon, 10 Dec 2007)
>  Checksum: 5bbf5a52328e7439ae6e719dfe712200
> 
> * FAIL 6: info file
> 
>                 (cd svnwc; svn info file) > expected.info-file &&
>                 (cd gitwc; git-svn info file) > actual.info-file &&
>                 git-diff expected.info-file actual.info-file
> 
> : hera t/master; svn --version
> svn, version 1.3.2 (r19776)

-- 
Eric Wong

Re: v1.5.4 plans

[Junio C Hamano]

Eric Wong <normalperson@yhbt.net> writes:

> David:
>
> I also noticed some race-conditions on this test when running this on my
> Centrino laptop (my fastest box, but I rarely use it for git
> development) and having git on my USB thumb drive.  I'm pretty sure
> these were caused by inconsistencies in handling timestamps on symlinks
> vs timestamps on the files they link to.

I actually saw that for the first time on my primary box during the
nightly rebuild last night.  I'll disable the test for now --- if we can
spot and fix the race by the release, that's good, otherwise, shipping
the test disabled is also fine, too.

Re: v1.5.4 plans

[David D. Kilzer]

Junio C Hamano <gitster@pobox.com> wrote:

> Eric Wong <normalperson@yhbt.net> writes:
> 
> > I also noticed some race-conditions on this test when running this on my
> > Centrino laptop (my fastest box, but I rarely use it for git
> > development) and having git on my USB thumb drive.  I'm pretty sure
> > these were caused by inconsistencies in handling timestamps on symlinks
> > vs timestamps on the files they link to.
> 
> I actually saw that for the first time on my primary box during the
> nightly rebuild last night.  I'll disable the test for now --- if we can
> spot and fix the race by the release, that's good, otherwise, shipping
> the test disabled is also fine, too.

I'll see if I can reproduce it and figure out where the race is happening.

Dave

Re: v1.5.4 plans

[David D. Kilzer]

Eric Wong <normalperson@yhbt.net> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> >  * I've seen t9119-git-svn-info.sh fail in my k.org private repository
> >    and have been skipping the test, but this needs to be diagnosed and
> >    fixed [*1*].  It could be just that the code is fine and the test is
> >    not rejecting SVN that is too-old. I dunno.
> 
> I wouldn't mind dropping this test for now.
> 
> 100% output compatibility with SVN is too difficult to achieve
> and IMHO not worth it for commands like `info' and `log'.
> 
> David:
> 
> I also noticed some race-conditions on this test when running this on my
> Centrino laptop (my fastest box, but I rarely use it for git
> development) and having git on my USB thumb drive.  I'm pretty sure
> these were caused by inconsistencies in handling timestamps on symlinks
> vs timestamps on the files they link to.

The problem is that 'svn info' is reading the mtime from its hidden backup file
(in the .svn directory) instead of the file in the working directory, so
setting the mtime (and atime) of the git working copy file using the svn
working copy doesn't always work.

I'm working on a solution now.

Dave