From: Jakub Narebski <jnareb@gmail.com>
To: Thomas Guyot-Sionnest <dermoth@aei.ca>
Cc: git@vger.kernel.org
Subject: Re: [PATCHv2] Add options to specify snapshot file name, prefix
Date: Sat, 5 Nov 2011 09:47:14 +0100 [thread overview]
Message-ID: <201111050947.15440.jnareb@gmail.com> (raw)
In-Reply-To: <4EB488C9.2050301@aei.ca>
On Sat, 5 Nov 2011, Thomas Guyot-Sionnest wrote:
> On 11-11-04 12:10 PM, Jakub Narebski wrote:
> > Thomas Guyot-Sionnest <dermoth@aei.ca> writes:
> >
> > > commit b629275 implemented "smart" snapshot names and prefixes. I have
> > > scripts that used to rely on the old behaviour which allowed in some
> > > cases to have fixed prefix, and would require modifications to work with
> > > newer Gitweb.
[...]
> > > This patch adds two parameters for overriding the snapshot name and
> > > prefix, sn and sp respectively. For example, to get a snapshot
> > > named "myproject.[suffix]" with no prefix one can add this query string:
> > > ?sn=myproject;sp=
> >
> > Would you need support for expandable parameters in both (a la
> > 'action' feature)?
>
> I'm not sure what you mean... I never tinkered with gitweb.pl directly
> before.
I'm sorry I didn't make it clear what I meant here.
What I wanted to ask is if you would need support for snapshot names
like for example
myproject-<full sha1>.tar.gz
It means that snapshot name depends on commit / tag / tree being archived;
for that you would need e.g.
...?sn=myproject-%H.tar.gz;sp=
But even if there would be need for this, it should be anyway put into
separate commit.
In short: forget about this comment.
[...]
> > > @@ -6684,11 +6686,19 @@ sub git_snapshot {
> > > }
> > >
> > > my ($name, $prefix) = snapshot_name($project, $hash);
> > > + if (defined($input_params{'snapshot_name'})) {
> > > + $name = $input_params{'snapshot_name'};
> > > + }
> > > + if (defined($input_params{'snapshot_prefix'})) {
> > > + $prefix = $input_params{'snapshot_prefix'};
> > > + } else {
> > > + $prefix .= '/';
> > > + }
> > > my $filename = "$name$known_snapshot_formats{$format}{'suffix'}";
> > > my $cmd = quote_command(
> > > git_cmd(), 'archive',
> > > "--format=$known_snapshot_formats{$format}{'format'}",
> > > - "--prefix=$prefix/", $hash);
> > > + "--prefix=$prefix", $hash);
> > > if (exists $known_snapshot_formats{$format}{'compressor'}) {
> > > $cmd .= ' | ' . quote_command(@{$known_snapshot_formats{$format}{'compressor'}});
> > > }
> >
> > I wonder if you really want to allow prefix which do not end in '/'
>
> I kind of agree, yet considering its lack of "front-end" visibility it
> made me think of plumbing commands like git-checkout-index (which I use
> sometimes to replace the "missing" git export) where prefix is nothing
> more than an appended string to file names.
>
> And now I remember, this is also exactly how git-archive works.
Right.
I wonder if anybody is using "git archive" with prefix that DOESN'T
end with a '/'...
> > (which would be suprising, isn't it), or just allow empty prefix too.
> >
> >
> > For example
> >
> > @@ -6684,11 +6686,19 @@ sub git_snapshot {
> > }
> >
> > my ($name, $prefix) = snapshot_name($project, $hash);
> > + if (defined($input_params{'snapshot_name'})) {
> > + $name = $input_params{'snapshot_name'};
> > + }
> > + if (defined($input_params{'snapshot_prefix'})) {
> > + $prefix = $input_params{'snapshot_prefix'};
> > + }
> > my $filename = "$name$known_snapshot_formats{$format}{'suffix'}";
> > my $cmd = quote_command(
> > git_cmd(), 'archive',
> > "--format=$known_snapshot_formats{$format}{'format'}",
> > - "--prefix=$prefix/", $hash);
> > + ($prefix eq "" ? () : "--prefix=$prefix"), $hash);
> > if (exists $known_snapshot_formats{$format}{'compressor'}) {
> > $cmd .= ' | ' . quote_command(@{$known_snapshot_formats{$format}{'compressor'}});
> > }
> >
>
> You still have to add the /, i.e.:
>
> > + ($prefix eq "" ? () : "--prefix=$prefix/"), $hash);
True. Sorry about that.
> And personally, I think git-archive is the one that should add a / - it
> has much more visibility to end-users than this obscure query-string.
So should we expect a re-roll?
P.S. I'd like to point out that git is now in pre-release feature freeze,
so please don't expect for these changes to appear in 'master' soon, though
most probably they would be available in 'pu' for the time being.
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2011-11-05 8:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1320302318-28315-1-git-send-email-dermoth@aei.ca>
2011-11-04 0:53 ` [PATCHv2] Add options to specify snapshot file name, prefix Thomas Guyot-Sionnest
2011-11-04 16:10 ` Jakub Narebski
2011-11-05 0:52 ` Thomas Guyot-Sionnest
2011-11-05 8:47 ` Jakub Narebski [this message]
2011-11-05 9:18 ` Jakub Narebski
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=201111050947.15440.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=dermoth@aei.ca \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.