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)

[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 --]

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: [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: 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.

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] 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
 
 '

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.

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

[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

[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 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 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 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

[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

[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

[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

[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

[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 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

[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

[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

[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, 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

[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

[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

[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

[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]

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

[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

[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: [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

[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, 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

[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

[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

[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 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

[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: 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