git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Guyot-Sionnest <dermoth@aei.ca>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCHv2] Add options to specify snapshot file name, prefix
Date: Fri, 04 Nov 2011 20:52:25 -0400	[thread overview]
Message-ID: <4EB488C9.2050301@aei.ca> (raw)
In-Reply-To: <m3fwi350ou.fsf@localhost.localdomain>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
> 
> If scripts use 'wget' or 'curl' you can always change the name of
> saved file:
> 
>   wget -O <file> ...
>   curl -o <file> ...
> 
> If downloaded snapshot is compressed tarfile, you can use
> --strip-components=1 to strip prefix.

I actually didn't care about the filename (in my script I pipe straight
to tar, and in a python app I have that will use snapshots I have I
planned on "opening" the url as a stream directly with the tarfile lib);
it was just as easy to add both anyway.

I thought I had looked up the tar man page for an option that strips the
path, clearly I missed that one. :)

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

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

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

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.

- -- 
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk60iMAACgkQ6dZ+Kt5BchbOFwCgmDuUVd9vI+ZC8JDQPS+SC7e2
FpIAnAkf6BrmAcvY/3GA1wjQvR9s50c6
=0pb2
-----END PGP SIGNATURE-----

  reply	other threads:[~2011-11-05  0:52 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 [this message]
2011-11-05  8:47       ` Jakub Narebski
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=4EB488C9.2050301@aei.ca \
    --to=dermoth@aei.ca \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    /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).