v1.5.4 plans

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

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

Jakub Narebski <jnareb@gmail.com> writes:

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".

On Dec 3, 2007 9:04 AM, Junio C Hamano <gitster@pobox.com> wrote:

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.

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

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)

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.

Hi,

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

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

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

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

Hi,

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

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

Ciao, Dscho

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

Ok, send in updates, please.

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(-)

Hi,

On Mon, 3 Dec 2007, Johannes Schindelin wrote:

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(-)

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(-)

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

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

-Peff

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

Emperor of the Rising Sun.  ;-)

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

Nicolas Pitre <nico@cam.org> writes:

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.

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

---

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

Here it is.

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.

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

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

Nicolas Pitre <nico@cam.org> writes:

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

On Fri, 14 Dec 2007, Jakub Narebski wrote:

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

On Fri, Dec 14, 2007 at 08:38:51AM -0500, Nicolas Pitre 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?

Joel

On Fri, 14 Dec 2007, Joel Becker wrote:

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

On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:

	That would be excellent, especially the former message.
 

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

Joel

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?

Nicolas

On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre 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>

Joel

On Fri, 14 Dec 2007, Joel Becker wrote:

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

Nicolas

Hi,

On Fri, 14 Dec 2007, Nicolas Pitre wrote:

GMane does not seem to have it, either:

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

returns "No such article".

Ciao, Dscho

Nicolas Pitre <nico@cam.org> writes:

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

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

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.

On Fri, 14 Dec 2007, Joel Becker wrote:

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

On Fri, Dec 14, 2007 at 09:23:38PM -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).
	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

On Mon, 17 Dec 2007, Joel Becker wrote:

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?

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

On Mon, Dec 17, 2007 at 03:41:24PM -0500, Nicolas Pitre wrote:

	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.

	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.

	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.

	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

On Mon, Dec 17, 2007 at 01:13:18PM -0800, Joel Becker 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.

---b.

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

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

On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:

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.

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

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

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

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.

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

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

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.

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

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.

On Mon, Dec 17, 2007 at 02:55:15PM -0800, Junio C Hamano wrote:

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.

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

t5302 provides a good demonstration of that.

Nicolas

Nicolas Pitre <nico@cam.org> writes:

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.

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

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

Nicolas Pitre <nico@cam.org> writes:

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.

On Mon, Dec 17, 2007 at 04:41:19PM -0800, Junio C Hamano wrote:

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

On Mon, 17 Dec 2007, Junio C Hamano 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.

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

On Dec 18, 2007 4:23 PM, Nicolas Pitre <nico@cam.org> wrote:

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

On Tue, 18 Dec 2007, Martin Langhoff wrote:

I agree.  Might be time for 1.6.0?

Nicolas

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

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.

Junio C Hamano wrote:

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

Hi,

On Tue, 18 Dec 2007, Jakub Narebski wrote:

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

On Tue, 18 Dec 2007, Jakub Narebski wrote:

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

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

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

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

Hi,

On Tue, 18 Dec 2007, Jeff King wrote:

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

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

On Tue, Dec 18, 2007 at 12:06:23PM +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).

-Peff

Hi,

On Tue, 18 Dec 2007, Jeff King wrote:

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

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

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

On Tue, 18 Dec 2007, Jeff King wrote:

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

Johannes Schindelin wrote:

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

Jeff King <peff@peff.net> writes:

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

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.

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:

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.

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

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

On Mon, 17 Dec 2007, Mark Fasheh wrote:

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.

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

On Dec 3, 2007 7:04 AM, Junio C Hamano <gitster@pobox.com> wrote:

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