git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: fuz@fuz.su
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: git archive should use vendor extension in pax header
Date: Thu, 28 Jan 2016 10:14:18 +0100	[thread overview]
Message-ID: <20160128091418.GA6875@fuz.su> (raw)
In-Reply-To: <alpine.DEB.2.20.1601280906340.2964@virtualbox>

Hello,

> > > Users can always go back to the original format.  At least I don't
> > > expect this new format becoming the default too quickly.
>
> This is the most crucial issue here, as far as I am concerned: there are
> already tons of .zip files out there that were created by git archive, and
> there will inevitably be loads of tons more *having the current pax header
> format*.
> 
> So tools wanting to deal with Git archives will have to handle those as
> well, i.e. do *precisely* as René suggested and use get-tar-commit-id. As
> such, the value of changing the format *now* is a bit like closing the
> barn's door after pretty much all of the horses left (except the old one
> that has a few troubles getting up in the morning but that is too nice to
> the kids to shoot).

That's not really an argument.  The situation you describes applies to
all file formats and it always ends in the same way:  A new file format
is designed and then slowly adopted by the rest of the users, in case of
git I imagine this to be a quick process taking maybe a year or two.
Newly created files use the new file format and old files still hang
around but their importance is dwindling until you can safely support
only the new format.  But to get there, a new file format has to be
adopted in the first place.

> > Sure thing.  If this is going to be implemented, I would add options
> > to choose what / what style of metadata to include.
> 
> Why not put your money where your mouth is? I.e. get your head down into
> the code and come up with a patch (because otherwise it is unlikely that
> your idea will go anywhere)?

I'd love to but I prefer to ask if there is interest in such a change in
the first place.  I'm not going to waste my time implementing this and
then being told that the git project is not interested in this kind of
functionality.  So can someone give me a clear signal?

> Ciao,
> Johannes

Yours sincerely,
Robert Clausecker

-- 
()  ascii ribbon campaign - for an 8-bit clean world 
/\  - against html email  - against proprietary attachments

  reply	other threads:[~2016-01-28  9:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-24 15:59 git archive should use vendor extension in pax header fuz
2016-01-26 22:06 ` René Scharfe
2016-01-27 23:25   ` fuz
     [not found]   ` <20160127114634.GA1976@fuz.su>
     [not found]     ` <56A92913.3030909@web.de>
2016-01-27 23:45       ` fuz
2016-01-28  8:13         ` Johannes Schindelin
2016-01-28  9:14           ` fuz [this message]
2016-02-06 13:23         ` René Scharfe
2016-02-06 14:57           ` fuz
2016-02-15 20:25             ` René Scharfe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160128091418.GA6875@fuz.su \
    --to=fuz@fuz.su \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).