* Re: Cannot clone redirecting stdout
From: Stefan Naewe @ 2009-09-11 6:39 UTC (permalink / raw)
To: Aloisio; +Cc: git@vger.kernel.org
In-Reply-To: <fc8ab2ad0909101533l135c8003m80091cb40ec93f16@mail.gmail.com>
On 9/11/2009 12:33 AM, Aloisio wrote:
> Hi all,
>
> I faced a problem when trying to clone git://gitorious.org/qt/qt.git
>
> this works:
> git clone -n git://gitorious.org/qt/qt.git repo
>
> this doesn't:
> git clone -n git://gitorious.org/qt/qt.git repo >log
> fatal: The remote end hung up unexpectedly
> fatal: early EOF
> fatal: index-pack failed
>
> I reproduced the error in the following versions:
> git version 1.6.0.4
> git version 1.6.4.2
> git version 1.5.4.7
>
> Any clues?
> Thanks
I'd say:
Take a look at /proc/<pid-of-git>/fd
fd 0 (stdout) is linked through a pipe to 'git index-pack'.
Redirecting this link breaks everything.
Regards,
Stefan
^ permalink raw reply
* Re: [PATCH 2/4] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Daniel Barkalow @ 2009-09-11 6:32 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Johannes Schindelin, Stephan Beyer,
Jakub Narebski, Linus Torvalds
In-Reply-To: <200909110734.13903.chriscool@tuxfamily.org>
On Fri, 11 Sep 2009, Christian Couder wrote:
> On Friday 11 September 2009, Junio C Hamano wrote:
> > Christian Couder <chriscool@tuxfamily.org> writes:
> > > From: Stephan Beyer <s-beyer@gmx.net>
> > >
> > > This patch makes "reset_index_file()" call "unpack_trees()" directly
> > > instead of forking and execing "git read-tree".
> >
> > And the reason why it is a good idea is...?
>
> ...that it should be faster.
>
> Ok, I will add that to the commit message in the next version.
There's also the benefit (IMHO, more significant) that git-read-tree's
command line parsing is complicated, and using it from git-reset makes it
hard to see exactly what each option of "git reset" does in terms of
operations on the index and the working tree.
For example, it's not obvious when reading the code to run read-tree that
all of the branches lead to the use of the "merge" flag, because some
branches use "-m" and some use "--reset".
Actually, there's a behavior difference between the old version and the
new version. The old version gives an error for "git reset --merge" with
unmerged entries (unlike any other option to "git reset", AFAICT), and the
new version does not. There's no way you'd know this without a careful
reading of cmd_read_tree() and cross-reference with reset_index_file(),
since the documentation doesn't mention it, the code in reset_index_file()
only replaces "--reset" with "-m", and it seems to be doing that for the
effect of not ignoring differences in the working tree.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 2/4] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Junio C Hamano @ 2009-09-11 5:55 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Linus Torvalds
In-Reply-To: <200909110734.13903.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> On Friday 11 September 2009, Junio C Hamano wrote:
>> Christian Couder <chriscool@tuxfamily.org> writes:
>> > From: Stephan Beyer <s-beyer@gmx.net>
>> >
>> > This patch makes "reset_index_file()" call "unpack_trees()" directly
>> > instead of forking and execing "git read-tree".
>>
>> And the reason why it is a good idea is...?
>
> ...that it should be faster.
>
> Ok, I will add that to the commit message in the next version.
Please don't add "should be". That is not a justification.
^ permalink raw reply
* Re: [PATCH 4/4] reset: add test cases for "--merge-dirty" option
From: Daniel Barkalow @ 2009-09-11 5:36 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Johannes Schindelin, Stephan Beyer,
Jakub Narebski, Linus Torvalds
In-Reply-To: <200909110705.35083.chriscool@tuxfamily.org>
On Fri, 11 Sep 2009, Christian Couder wrote:
> On Friday 11 September 2009, Daniel Barkalow wrote:
> > On Thu, 10 Sep 2009, Christian Couder wrote:
> >
> > This shows that with the "--merge-dirty" option,
> >
> > changes that are both in the work tree and the index are kept
> >
> > in the work tree after the reset (but discarded in the index). As
> > with the "--merge" option,
> >
> > changes that are in both the work tree and the index are discarded
> >
> > after the reset.
> >
> > I'm lost here.
> >
> > If you have:
> >
> > working index HEAD target
> > version B B A A
> >
> > You get:
> >
> > working index HEAD target
> > --m-d B A A A
> > --merge A A A A
> >
> > ?
>
> Yes, files that are not different between HEAD and target are changed like
> that. Thanks for explaining it better than I could!
I worked on the rules for merging way back when, so I've looked at tables
of cases like that. If there are more cases to cover, it might work
better to have a table like:
working index HEAD target working index HEAD
B B A A --m-d B A A
--merge A A A
B B A C --m-d (disallowed)
--merge C C C
Are there other differences?
> > > ---
> > > t/t7110-reset-merge.sh | 54
> > > +++++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 49
> > > insertions(+), 5 deletions(-)
> > >
> > > diff --git a/t/t7110-reset-merge.sh b/t/t7110-reset-merge.sh
> > > index 45714ae..1e6d634 100755
> > > --- a/t/t7110-reset-merge.sh
> > > +++ b/t/t7110-reset-merge.sh
> > > @@ -19,7 +19,7 @@ test_expect_success 'creating initial files' '
> > > git commit -m "Initial commit"
> > > '
> > >
> > > -test_expect_success 'ok with changes in file not changed by reset' '
> > > +test_expect_success '--merge: ok if changes in file not touched by
> > > reset' '
> >
> > Should probably have the "--merge: " from the beginning, since you're
> > adding the test in this series anyway. That would make the diff come out
> > clearer.
>
> Yeah, but I am not sure that patches 3/4 and 4/4 will get merged in the end.
> If they are not merged it will be better if there is no "--merge: ".
Maybe write those lines to mention "reset --merge" naturally? Like:
'ok with changes in file not changed by reset --merge'
'reset --merge discards changes added to index 1'
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 3/4] reset: add option "--merge-dirty" to "git reset"
From: Junio C Hamano @ 2009-09-11 5:34 UTC (permalink / raw)
To: Christian Couder
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds
In-Reply-To: <20090910202333.3722.37592.chriscool@tuxfamily.org>
I have two comments (and I share Linus's puzzlement).
> From: Stephan Beyer <s-beyer@gmx.net>
- Trying to give credit to Stephan is nice, but comparing this with bits
from the previous round, I am not sure if you need to keep calling this
Stephan's code anymore. Perhaps it would be enough to replace the last
three lines in your commit log message with "Uses some code from
Stephan's GSoC work in git://repo.or.cz/git/sbeyer.git repository".
And I would actually prefer you take the authorship, especially if
Stephan's series does not add an option to "reset". Then we know whom
to forward any bug reports to ;-)
I did not compare this with the GSoC repository, so maybe this is what
Stephan did after all, but still I thought it is worth to ask.
> This option is nearly like "--merge" except that it is a little bit
> safer as it seems that it tries to keep changes in the index. On the
> contrary "--merge", only keep changes in the work tree.
Nearly, a little bit, seems and tries?
These words do not build confidence that this new feature is robust and
behaves predictably.
Of course, you are not adding a random number generator, but a useful mode
with a bit more complex behaviour than "--merge that _always_ discards
changes in the index." So as the salesman, you would need to do a bit
better job to explain what the new behaviour is, and why it is better to
have that new behaviour than the behaviour of --merge, to sell that new
feature.
^ permalink raw reply
* Re: [PATCH 2/4] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Christian Couder @ 2009-09-11 5:34 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds
In-Reply-To: <7v1vme2h2f.fsf@alter.siamese.dyndns.org>
On Friday 11 September 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > From: Stephan Beyer <s-beyer@gmx.net>
> >
> > This patch makes "reset_index_file()" call "unpack_trees()" directly
> > instead of forking and execing "git read-tree".
>
> And the reason why it is a good idea is...?
...that it should be faster.
Ok, I will add that to the commit message in the next version.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 3/4] reset: add option "--merge-dirty" to "git reset"
From: Christian Couder @ 2009-09-11 5:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, git, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski
In-Reply-To: <alpine.LFD.2.01.0909101617280.3654@localhost.localdomain>
On Friday 11 September 2009, Linus Torvalds wrote:
> On Thu, 10 Sep 2009, Christian Couder wrote:
> > In fact with "--merge-dirty", changes that are both in
> > the work tree and the index are kept in the work tree
> > after the reset (but discarded in the index). As with
> > "--merge", changes that are in both the work tree and
> > the index are discarded after the reset.
>
> Can you explain that again?
Yeah, I tried to explain it better in my reply to Daniel.
> That paragraph makes no sense, because it
> boils down to saying two different thing for "changes that are in both
> the work tree and the index". First it says such changes are kept in the
> work tree (but discarded in the index), and then it says that the changes
> are discarded.
>
> Which seems very odd.
>
> Or are my reading comprehension skills lacking?
No, I realize it was my writing skills that were lacking again. I will
rework the commit message using some tables like in Daniel's message.
> The patch also seems to imply that it's always about HEAD. True?
Yes.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH 1/4] reset: add a few tests for "git reset --merge"
From: Christian Couder @ 2009-09-11 5:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Stephan Beyer, Daniel Barkalow
In-Reply-To: <200909102259.16469.jnareb@gmail.com>
On Thursday 10 September 2009, Jakub Narebski wrote:
> Christian Couder wrote:
> > diff --git a/t/t7110-reset-merge.sh b/t/t7110-reset-merge.sh
> > new file mode 100755
> > index 0000000..45714ae
> > --- /dev/null
> > +++ b/t/t7110-reset-merge.sh
> > @@ -0,0 +1,70 @@
> > +#!/bin/sh
> > +#
> > +# Copyright (c) 2009 Christian Couder
> > +#
> > +
> > +test_description='Tests for "git reset --merge"'
> > +
> > +exec </dev/null
>
> What does this do?
Nothing! Yeah, this is a mistake.
Thanks for spoting it,
Christian.
^ permalink raw reply
* Re: [PATCH 2/4] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Junio C Hamano @ 2009-09-11 5:20 UTC (permalink / raw)
To: Christian Couder
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds
In-Reply-To: <20090910202333.3722.58409.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> From: Stephan Beyer <s-beyer@gmx.net>
>
> This patch makes "reset_index_file()" call "unpack_trees()" directly
> instead of forking and execing "git read-tree".
And the reason why it is a good idea is...?
^ permalink raw reply
* Re: [PATCH 4/4] reset: add test cases for "--merge-dirty" option
From: Christian Couder @ 2009-09-11 5:05 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Junio C Hamano, git, Johannes Schindelin, Stephan Beyer,
Jakub Narebski, Linus Torvalds
In-Reply-To: <alpine.LNX.2.00.0909101757530.28290@iabervon.org>
On Friday 11 September 2009, Daniel Barkalow wrote:
> On Thu, 10 Sep 2009, Christian Couder wrote:
>
> This shows that with the "--merge-dirty" option,
>
> changes that are both in the work tree and the index are kept
>
> in the work tree after the reset (but discarded in the index). As
> with the "--merge" option,
>
> changes that are in both the work tree and the index are discarded
>
> after the reset.
>
> I'm lost here.
>
> If you have:
>
> working index HEAD target
> version B B A A
>
> You get:
>
> working index HEAD target
> --m-d B A A A
> --merge A A A A
>
> ?
Yes, files that are not different between HEAD and target are changed like
that. Thanks for explaining it better than I could!
And also when files are different between HEAD and target (and when the
index is the same as the working tree but different than HEAD), the result
from -m-d and --merge are different:
If you have:
working index HEAD target
version B B A C
You get:
working index HEAD target
--m-d B B A C : --m-d fails (so no change)
--merge C C C C : success but changes B discarded
In t/t7110-reset-merge.sh these differences are shown by test cases 3, 4, 5
and 6:
--merge: discard changes added to index 1
--merge: discard changes added to index 2
--merge-dirty: not ok with touched changes in index
--merge-dirty: keep untouched changes
> > ---
> > t/t7110-reset-merge.sh | 54
> > +++++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 49
> > insertions(+), 5 deletions(-)
> >
> > diff --git a/t/t7110-reset-merge.sh b/t/t7110-reset-merge.sh
> > index 45714ae..1e6d634 100755
> > --- a/t/t7110-reset-merge.sh
> > +++ b/t/t7110-reset-merge.sh
> > @@ -19,7 +19,7 @@ test_expect_success 'creating initial files' '
> > git commit -m "Initial commit"
> > '
> >
> > -test_expect_success 'ok with changes in file not changed by reset' '
> > +test_expect_success '--merge: ok if changes in file not touched by
> > reset' '
>
> Should probably have the "--merge: " from the beginning, since you're
> adding the test in this series anyway. That would make the diff come out
> clearer.
Yeah, but I am not sure that patches 3/4 and 4/4 will get merged in the end.
If they are not merged it will be better if there is no "--merge: ".
If they get merged, the option name '--merge-dirty" will probably be changed
to something else like "--merge-safe" so I will have to change some patches
anyway.
Thanks,
Christian.
^ permalink raw reply
* [RFC/PATCH v2] gitweb: check given hash before trying to create snapshot
From: Mark Rada @ 2009-09-11 5:01 UTC (permalink / raw)
To: git, Jakub Narebski, Junio C Hamano
I squashed the two commits together and I also used Jakub's idea to
create a wrapper for git_get_head_hash.
--
Mark Rada (ferrous26)
marada@uwaterloo.ca
--->8---
Make things nicer in cases when you hand craft the snapshot URL but
make a typo in defining the hash variable (e.g. netx instead of next);
you will now get an error message instead of a broken tarball.
To maintain backwards compatibility, git_get_head_hash is now a wrapper
for git_get_full_hash, as suggested by Jakub Narebski.
Tests for t9501 are included to demonstrate changed functionality.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
---
gitweb/gitweb.perl | 13 ++++++++++---
t/t9501-gitweb-standalone-http-status.sh | 29 +++++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 24b2193..a40a50d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1983,11 +1983,17 @@ sub quote_command {
# get HEAD ref of given project as hash
sub git_get_head_hash {
+ return git_get_full_hash(shift, 'HEAD');
+}
+
+# given a project and tree-ish, returns full hash
+sub git_get_full_hash {
my $project = shift;
+ my $hash = shift;
my $o_git_dir = $git_dir;
my $retval = undef;
$git_dir = "$projectroot/$project";
- if (open my $fd, "-|", git_cmd(), "rev-parse", "--verify", "HEAD") {
+ if (open my $fd, '-|', git_cmd(), 'rev-parse', '--verify', $hash) {
my $head = <$fd>;
close $fd;
if (defined $head && $head =~ /^([0-9a-fA-F]{40})$/) {
@@ -5196,8 +5202,9 @@ sub git_snapshot {
die_error(403, "Unsupported snapshot format");
}
- if (!defined $hash) {
- $hash = git_get_head_hash($project);
+ my $snapshot = git_get_full_hash($project, $hash);
+ if (!$snapshot) {
+ die_error(400, "Not a valid hash id: $hash");
}
my $name = $project;
diff --git a/t/t9501-gitweb-standalone-http-status.sh b/t/t9501-gitweb-standalone-http-status.sh
index d0ff21d..81abfae 100644
--- a/t/t9501-gitweb-standalone-http-status.sh
+++ b/t/t9501-gitweb-standalone-http-status.sh
@@ -75,4 +75,33 @@ test_expect_success \
test_debug 'cat gitweb.output'
+# ----------------------------------------------------------------------
+# snapshot hash ids
+
+test_expect_success \
+ 'snapshots: bad treeish id' \
+ 'gitweb_run "p=.git;a=snapshot;h=frizzumFrazzum;sf=tgz" &&
+ grep "400 - Not a valid hash id:" gitweb.output'
+test_debug 'cat gitweb.output'
+
+test_expect_success \
+ 'snapshots: good treeish id' \
+ 'gitweb_run "p=.git;a=snapshot;h=master;sf=tgz" &&
+ grep "Status: 200 OK" gitweb.output'
+test_debug 'cat gitweb.output'
+
+test_expect_success \
+ 'snapshots: bad object id' \
+ 'gitweb_run "p=.git;a=snapshot;h=abcdef01234;sf=tgz" &&
+ grep "400 - Not a valid hash id:" gitweb.output'
+test_debug 'cat gitweb.output'
+
+test_expect_success \
+ 'snapshots: good object id' \
+ 'ID=`git rev-parse --verify HEAD` &&
+ gitweb_run "p=.git;a=snapshot;h=$ID;sf=tgz" &&
+ grep "Status: 200 OK" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
test_done
--
1.6.4.2
^ permalink raw reply related
* Re: tracking branch for a rebase
From: Junio C Hamano @ 2009-09-11 4:54 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Björn Steinbrink, Michael J Gruber, Pete Wyckoff,
git
In-Reply-To: <alpine.DEB.1.00.0909100941330.8306@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> How about ^^branch? *ducks*
You'd better duck.
Just like %branch, it is a selfish and short-sighted "good enough for this
particular case but there is no room for extending it" hack that I have
serious problem with. It closes the door for people who come later, and
such an attitude is okay only if this is _the last great invention_ and
there is no more great feature that deserves short-and-sweet notation to
come. It might be the _latest_ great invention, but chances are that it
won't be the last.
> Seriously again, I think that ^{tracking} (with shorthand ^t, maybe) is
> not too shabby an option. The point is: if we make this unattractive
> enough by requiring a lot of typing, we will never get to the point where
> it is popular enough to make a shorthand: it just will not be used at all.
I actually think it is the other way around.
If it is so useful to be able to specify the ref your branch is based on
by applying a magic to the name of your branch, the users will use it even
if it is rather long to type, as long as the feature is easy to discover
and remember, and then they will demand a short-hand.
If on the other hand users say "Hey, I know can say 'git log X@{upstream}'
but why bother? I always build my branch X on top of origin/X anyway, so
I'd forego that feature and type 'git log origin/X'. It's not worth my
time to type that long magic," then the feature is not as useful as you
hoped. And there is no point in coming up with a short-hand syntax for
it.
I personally suspect that users love to use the feature _despite_ the
initial lack of short-hand, and we would end up adding some short-hand,
and that would be a far better proof that the feature itself is useful
than "it is used just %X happens to be shorter than origin/X".
But before that happens, I'd rather not waste short-hand notations, such
as @{t} or @{u}, that will be in short-supply in the longer term.
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Björn Steinbrink @ 2009-09-11 3:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Wincent Colaiuta, Brendan Miller, git
In-Reply-To: <7vbpliaaxo.fsf@alter.siamese.dyndns.org>
On 2009.09.10 11:53:23 -0700, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > First, it would be consistent with how ordinary archivers such as tar
> > or zip are used, where you have to specify list of files to archive
> > (in our case this list is HEAD). Second, I'd rather not accidentally
> > dump binary to terminal: "git archive [HEAD]" dumps archive to standard
> > output.
>
> So does "cat". I do not agree with your second point.
"cat $some_binary" does, not just "cat". I guess Jakub's point was that
a command without arguments shouldn't just put some binary crap onto
your screen. Of course, "git archive HEAD" still does that, but I kind
of he where he's coming from, being one of those that tends to run
"$some_command" without arguments, just to see if it shows me some sort
of short help.
Björn
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Junio C Hamano @ 2009-09-11 0:37 UTC (permalink / raw)
To: demerphq
Cc: John Tapsell, Jakub Narebski, Wincent Colaiuta, Brendan Miller,
git
In-Reply-To: <9b18b3110909101619n6904a75dm10dd0b5717fb0d76@mail.gmail.com>
demerphq <demerphq@gmail.com> writes:
> 2009/9/11 Junio C Hamano <gitster@pobox.com>:
>> John Tapsell <johnflux@gmail.com> writes:
>>
>>> 2009/9/10 Jakub Narebski <jnareb@gmail.com>:
>>>> Dnia czwartek 10. września 2009 21:46, John Tapsell napisał:
>>>>> 2009/9/10 Jakub Narebski <jnareb@gmail.com>:
>>>>
>>>>> > First, it would be consistent with how ordinary archivers such as tar
>>>>> > or zip are used, where you have to specify list of files to archive
>>>>> > (in our case this list is HEAD). Second, I'd rather not accidentally
>>>>> > dump binary to terminal: "git archive [HEAD]" dumps archive to standard
>>>>> > output.
>>>>>
>>>>> That could be fixed by outputting to a file. git format-patch outputs
>>>>> to a file, so why wouldn't git achieve?
>>>>
>>>> "git format-patch" outputs to files because it generates _multiple_
>>>> files; generating single patch is special case. Also git-format-patch
>>>> can generate file names from patch (commit) subject; it is not the case
>>>> for "git archive" (what name should it use?).
>>>
>>> What if it used the current (or topleve) directory name? Wouldn't
>>> that work in most cases?
>>
>> Following along the same line of reasoning, it would work in most cases if
>> the output is literally named "archive.tar". If it is not the name the
>> user wants, the user can "mv" afterwards, or give an explicit filename.
>
> Why not $sha1.tar?
Why not $(basename $(dirname $(pwd)))-$(date).tar instead?
See? archive.tar is as good a compromise (so is a.out from cc).
> Is it portable to assume that piping is always in binmode? From a
> portability POV i could imagine piping being a problem in this
> respect, and might be why tar provides a way to output to a file and
> not just to a handle. For example ISTR that on windows piping is by
> default in text mode. I think its not a showstopper there as you can
> change it, but still, from a portability point of view you might not
> want to depend on piping.
Windows is not a showstopper to me ;-).
But seriously, I am glad that you brought up about a potential issue with
pipe. There is one fairly important reason that it is better to say
GZIP=-9 tar zcf here.tar.gz .
than to say
tar cf - . | gzip -9 >here.tar.gz
but it has nothing to do with binmode. The reason is error detection.
For exactly the same reason, if we can say
git archive -9 --output-file=here.tar.gz HEAD
it is much better than having to say
git archive HEAD | gzip -9 >here.tar.gz
In other words, I am not opposed to supporting a "--output-file here.tar"
at all. I just do not want it to be mandatory. I think that it is an
ugly kludge to force people to work it around with "-f /dev/stdout".
Oh wait.
That is exactly what we have, so what's the point of continuing this
discussion any further? Can we just _really_ stop this time, please?
^ permalink raw reply
* [PATCH v2] add documentation for mailinfo.scissors and '--no-scissors'
From: Nicolas Sebrecht @ 2009-09-11 0:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git, Nicolas Sebrecht
In-Reply-To: <33445216edc4c4e1976cdd81521922042955e6eb.1252626034.git.nicolas.s.dev@gmx.fr>
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
I've missed the documentation of --no-scissors in git-am.txt in the previous
round (second hunks here).
Sorry for inconvenience.
Documentation/git-am.txt | 5 ++++-
Documentation/git-mailinfo.txt | 6 ++++++
builtin-mailinfo.c | 2 +-
git-am.sh | 1 +
4 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 87781f4..14ae3a5 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--3way] [--interactive] [--committer-date-is-author-date]
[--ignore-date] [--ignore-space-change | --ignore-whitespace]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
- [--reject] [-q | --quiet] [--scissors]
+ [--reject] [-q | --quiet] [--scissors | --no-scissors]
[<mbox> | <Maildir>...]
'git am' (--skip | --resolved | --abort)
@@ -44,6 +44,9 @@ OPTIONS
Remove everything in body before a scissors line (see
linkgit:git-mailinfo[1]).
+---no-scissors::
+ Do not obey to a scissors line (see linkgit:git-mailinfo[1]).
+
-q::
--quiet::
Be quiet. Only print error messages.
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 823ab82..55b8c5e 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -62,6 +62,12 @@ This is useful if you want to begin your message in a discussion thread
with comments and suggestions on the message you are responding to, and to
conclude it with a patch submission, separating the discussion and the
beginning of the proposed commit log message with a scissors line.
++
+This can enabled by default with the configuration option mailinfo.scissors.
+
+--no-scissors::
+ Do not obey to a scissors line. This is only useful if mailinfo.scissors is
+ enabled (see --scissors).
<msg>::
The commit log message extracted from e-mail, usually
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 7d22fd7..d498b1c 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -1004,7 +1004,7 @@ static int git_mailinfo_config(const char *var, const char *value, void *unused)
}
static const char mailinfo_usage[] =
- "git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors] msg patch < mail >info";
+ "git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors | --no-scissors] msg patch < mail >info";
int cmd_mailinfo(int argc, const char **argv, const char *prefix)
{
diff --git a/git-am.sh b/git-am.sh
index 26ffe70..f242d1a 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
c,scissors strip everything before a scissors line
+no-scissors don't obey to a scissors line (default)
whitespace= pass it through git-apply
ignore-space-change pass it through git-apply
ignore-whitespace pass it through git-apply
--
1.6.5.rc0.168.gdcd6e
^ permalink raw reply related
* Re: obnoxious CLI complaints
From: Junio C Hamano @ 2009-09-11 0:25 UTC (permalink / raw)
To: John Tapsell; +Cc: Jakub Narebski, Wincent Colaiuta, Brendan Miller, git
In-Reply-To: <43d8ce650909101718j2f1f77cbgc347ee755145353f@mail.gmail.com>
John Tapsell <johnflux@gmail.com> writes:
>> git archive >my.file.tar
>
> I thought you didn't like this because then you dump binary to the
> console by default ?
No. That objection came from Jakub and I said it did not make sense to me.
> Why would it be so bad to do:
>
> git archive -f - | down stream commands
Are you seriously asking "why" after I said this?
>> and people who want to pipe (which is 99% of the use pattern for me) can
>> say
If you really need it to be spelled out,...
Because I have to say "-f -" 99% of the time without no good reason.
^ permalink raw reply
* Re: obnoxious CLI complaints
From: John Tapsell @ 2009-09-11 0:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Wincent Colaiuta, Brendan Miller, git
In-Reply-To: <7v4ora76vr.fsf@alter.siamese.dyndns.org>
2009/9/11 Junio C Hamano <gitster@pobox.com>:
> John Tapsell <johnflux@gmail.com> writes:
>
>> 2009/9/10 Jakub Narebski <jnareb@gmail.com>:
>>> Dnia czwartek 10. września 2009 21:46, John Tapsell napisał:
>>>> 2009/9/10 Jakub Narebski <jnareb@gmail.com>:
>>>
>>>> > First, it would be consistent with how ordinary archivers such as tar
>>>> > or zip are used, where you have to specify list of files to archive
>>>> > (in our case this list is HEAD). Second, I'd rather not accidentally
>>>> > dump binary to terminal: "git archive [HEAD]" dumps archive to standard
>>>> > output.
>>>>
>>>> That could be fixed by outputting to a file. git format-patch outputs
>>>> to a file, so why wouldn't git achieve?
>>>
>>> "git format-patch" outputs to files because it generates _multiple_
>>> files; generating single patch is special case. Also git-format-patch
>>> can generate file names from patch (commit) subject; it is not the case
>>> for "git archive" (what name should it use?).
>>
>> What if it used the current (or topleve) directory name? Wouldn't
>> that work in most cases?
>
> Following along the same line of reasoning, it would work in most cases if
> the output is literally named "archive.tar". If it is not the name the
> user wants, the user can "mv" afterwards, or give an explicit filename.
That would also work. Like how gcc uses "a.out" as the default filename
> What it does _not_ allow is to send the output to a downstream command for
> postprocessing without introducing some magic token to say "standard
> output" (e.g. "git archive -f - | (cd ../foo && tar xf -)").
Right, so what's wrong with the magic token? There's plenty of precedence.
> If the default is to write to the standard output, we won't have all of
> these issues.
These are issues?
> People who want a file can name the file by
>
> git archive >my.file.tar
I thought you didn't like this because then you dump binary to the
console by default ?
> and people who want to pipe (which is 99% of the use pattern for me) can
> say
>
> git archive | down stream commands.
Why would it be so bad to do:
git archive -f - | down stream commands
?
This is the most logical way forward. It keeps the command simple for
simple use cases (make an archive - "git archive") but easily
scalable for more complex use cases (add a "-f -" if you want to do
magical things)
John
^ permalink raw reply
* [PATCH 2/2] add documentation for mailinfo.scissors and '--no-scissors'
From: Nicolas Sebrecht @ 2009-09-11 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git, Nicolas Sebrecht
In-Reply-To: <682ef47420f36d8c53e42981370d377b621d7b86.1252626034.git.nicolas.s.dev@gmx.fr>
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
Documentation/git-am.txt | 2 +-
Documentation/git-mailinfo.txt | 6 ++++++
builtin-mailinfo.c | 2 +-
git-am.sh | 1 +
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 87781f4..8b2897b 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--3way] [--interactive] [--committer-date-is-author-date]
[--ignore-date] [--ignore-space-change | --ignore-whitespace]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
- [--reject] [-q | --quiet] [--scissors]
+ [--reject] [-q | --quiet] [--scissors | --no-scissors]
[<mbox> | <Maildir>...]
'git am' (--skip | --resolved | --abort)
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 823ab82..55b8c5e 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -62,6 +62,12 @@ This is useful if you want to begin your message in a discussion thread
with comments and suggestions on the message you are responding to, and to
conclude it with a patch submission, separating the discussion and the
beginning of the proposed commit log message with a scissors line.
++
+This can enabled by default with the configuration option mailinfo.scissors.
+
+--no-scissors::
+ Do not obey to a scissors line. This is only useful if mailinfo.scissors is
+ enabled (see --scissors).
<msg>::
The commit log message extracted from e-mail, usually
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 7d22fd7..d498b1c 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -1004,7 +1004,7 @@ static int git_mailinfo_config(const char *var, const char *value, void *unused)
}
static const char mailinfo_usage[] =
- "git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors] msg patch < mail >info";
+ "git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors | --no-scissors] msg patch < mail >info";
int cmd_mailinfo(int argc, const char **argv, const char *prefix)
{
diff --git a/git-am.sh b/git-am.sh
index 26ffe70..f242d1a 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
c,scissors strip everything before a scissors line
+no-scissors don't obey to a scissors line (default)
whitespace= pass it through git-apply
ignore-space-change pass it through git-apply
ignore-whitespace pass it through git-apply
--
1.6.5.rc0.164.g5f6b0
^ permalink raw reply related
* [PATCH 1/2] mailinfo: add '--scissors' to usage message
From: Nicolas Sebrecht @ 2009-09-11 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git, Nicolas Sebrecht
In-Reply-To: <7vtyzexnhm.fsf@alter.siamese.dyndns.org>
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
builtin-mailinfo.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 03cbcad..7d22fd7 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -1004,7 +1004,7 @@ static int git_mailinfo_config(const char *var, const char *value, void *unused)
}
static const char mailinfo_usage[] =
- "git mailinfo [-k] [-u | --encoding=<encoding> | -n] msg patch <mail >info";
+ "git mailinfo [-k] [-u | --encoding=<encoding> | -n] [--scissors] msg patch < mail >info";
int cmd_mailinfo(int argc, const char **argv, const char *prefix)
{
--
1.6.5.rc0.164.g5f6b0
^ permalink raw reply related
* scissors definition and documentation
From: Nicolas Sebrecht @ 2009-09-11 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vtyzexnhm.fsf@alter.siamese.dyndns.org>
The 07/09/09, Junio C Hamano wrote:
>
> * jc/mailinfo-scissors (2009-08-26) 5 commits
> (merged to 'next' on 2009-08-30 at 5fc6248)
> + mailinfo.scissors: new configuration
> + am/mailinfo: Disable scissors processing by default
> + Documentation: describe the scissors mark support of "git am"
> + Teach mailinfo to ignore everything before -- >8 -- mark
> + builtin-mailinfo.c: fix confusing internal API to mailinfo()
>
> I didn't pick up the patch to simplify the definition of scissors. I do
> not have strong opinion on it either way, and nobody on the list seemed to
> care too much either.
Since --scissors is an option instead of the default behaviour, I believe that
the definition of scissors is much less critical.
The following two patches is only about documentation.
The last patch mixes documentation of both mailinfo.scissors and --no--scissors
because I think they are very tied from the user POV.
[PATCH 1/2] mailinfo: add '--scissors' to usage message
[PATCH 2/2] add documentation for mailinfo.scissors and '--no-scissors'
---
Documentation/git-am.txt | 2 +-
Documentation/git-mailinfo.txt | 6 ++++++
builtin-mailinfo.c | 2 +-
git-am.sh | 1 +
4 files changed, 9 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH 3/4] reset: add option "--merge-dirty" to "git reset"
From: Linus Torvalds @ 2009-09-10 23:24 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski
In-Reply-To: <20090910202333.3722.37592.chriscool@tuxfamily.org>
On Thu, 10 Sep 2009, Christian Couder wrote:
>
> In fact with "--merge-dirty", changes that are both in
> the work tree and the index are kept in the work tree
> after the reset (but discarded in the index). As with
> "--merge", changes that are in both the work tree and
> the index are discarded after the reset.
Can you explain that again? That paragraph makes no sense, because it
boils down to saying two different thing for "changes that are in both the
work tree and the index". First it says such changes are kept in the work
tree (but discarded in the index), and then it says that the changes are
discarded.
Which seems very odd.
Or are my reading comprehension skills lacking?
The patch also seems to imply that it's always about HEAD. True?
Linus
^ permalink raw reply
* Re: obnoxious CLI complaints
From: demerphq @ 2009-09-10 23:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: John Tapsell, Jakub Narebski, Wincent Colaiuta, Brendan Miller,
git
In-Reply-To: <7v4ora76vr.fsf@alter.siamese.dyndns.org>
2009/9/11 Junio C Hamano <gitster@pobox.com>:
> John Tapsell <johnflux@gmail.com> writes:
>
>> 2009/9/10 Jakub Narebski <jnareb@gmail.com>:
>>> Dnia czwartek 10. września 2009 21:46, John Tapsell napisał:
>>>> 2009/9/10 Jakub Narebski <jnareb@gmail.com>:
>>>
>>>> > First, it would be consistent with how ordinary archivers such as tar
>>>> > or zip are used, where you have to specify list of files to archive
>>>> > (in our case this list is HEAD). Second, I'd rather not accidentally
>>>> > dump binary to terminal: "git archive [HEAD]" dumps archive to standard
>>>> > output.
>>>>
>>>> That could be fixed by outputting to a file. git format-patch outputs
>>>> to a file, so why wouldn't git achieve?
>>>
>>> "git format-patch" outputs to files because it generates _multiple_
>>> files; generating single patch is special case. Also git-format-patch
>>> can generate file names from patch (commit) subject; it is not the case
>>> for "git archive" (what name should it use?).
>>
>> What if it used the current (or topleve) directory name? Wouldn't
>> that work in most cases?
>
> Following along the same line of reasoning, it would work in most cases if
> the output is literally named "archive.tar". If it is not the name the
> user wants, the user can "mv" afterwards, or give an explicit filename.
Why not $sha1.tar?
> What it does _not_ allow is to send the output to a downstream command for
> postprocessing without introducing some magic token to say "standard
> output" (e.g. "git archive -f - | (cd ../foo && tar xf -)").
>
> If the default is to write to the standard output, we won't have all of
> these issues. People who want a file can name the file by
>
> git archive >my.file.tar
>
> and people who want to pipe (which is 99% of the use pattern for me) can
> say
>
> git archive | down stream commands.
>
> Oh, wait.
>
> That is exactly what we have, so what's the point of continuing this
> discussion any further? Can we just stop?
Is it portable to assume that piping is always in binmode? From a
portability POV i could imagine piping being a problem in this
respect, and might be why tar provides a way to output to a file and
not just to a handle. For example ISTR that on windows piping is by
default in text mode. I think its not a showstopper there as you can
change it, but still, from a portability point of view you might not
want to depend on piping.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Junio C Hamano @ 2009-09-10 22:49 UTC (permalink / raw)
To: John Tapsell; +Cc: Jakub Narebski, Wincent Colaiuta, Brendan Miller, git
In-Reply-To: <43d8ce650909101504q32448cb9w562a43969d01b1fe@mail.gmail.com>
John Tapsell <johnflux@gmail.com> writes:
> 2009/9/10 Jakub Narebski <jnareb@gmail.com>:
>> Dnia czwartek 10. września 2009 21:46, John Tapsell napisał:
>>> 2009/9/10 Jakub Narebski <jnareb@gmail.com>:
>>
>>> > First, it would be consistent with how ordinary archivers such as tar
>>> > or zip are used, where you have to specify list of files to archive
>>> > (in our case this list is HEAD). Second, I'd rather not accidentally
>>> > dump binary to terminal: "git archive [HEAD]" dumps archive to standard
>>> > output.
>>>
>>> That could be fixed by outputting to a file. git format-patch outputs
>>> to a file, so why wouldn't git achieve?
>>
>> "git format-patch" outputs to files because it generates _multiple_
>> files; generating single patch is special case. Also git-format-patch
>> can generate file names from patch (commit) subject; it is not the case
>> for "git archive" (what name should it use?).
>
> What if it used the current (or topleve) directory name? Wouldn't
> that work in most cases?
Following along the same line of reasoning, it would work in most cases if
the output is literally named "archive.tar". If it is not the name the
user wants, the user can "mv" afterwards, or give an explicit filename.
What it does _not_ allow is to send the output to a downstream command for
postprocessing without introducing some magic token to say "standard
output" (e.g. "git archive -f - | (cd ../foo && tar xf -)").
If the default is to write to the standard output, we won't have all of
these issues. People who want a file can name the file by
git archive >my.file.tar
and people who want to pipe (which is 99% of the use pattern for me) can
say
git archive | down stream commands.
Oh, wait.
That is exactly what we have, so what's the point of continuing this
discussion any further? Can we just stop?
^ permalink raw reply
* Cannot clone redirecting stdout
From: Aloisio @ 2009-09-10 22:33 UTC (permalink / raw)
To: git
Hi all,
I faced a problem when trying to clone git://gitorious.org/qt/qt.git
this works:
git clone -n git://gitorious.org/qt/qt.git repo
this doesn't:
git clone -n git://gitorious.org/qt/qt.git repo >log
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
I reproduced the error in the following versions:
git version 1.6.0.4
git version 1.6.4.2
git version 1.5.4.7
Any clues?
Thanks
Aloisio Almeida
^ permalink raw reply
* Re: obnoxious CLI complaints
From: René Scharfe @ 2009-09-10 22:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Brendan Miller, git
In-Reply-To: <200909101116.55098.jnareb@gmail.com>
Jakub Narebski schrieb:
> [...] Second, compression is better left to separate program, but
> I guess we can follow GNU tar example and add equivalents of -Z/-z/-j
> and --use-compress-program options when using --output=<file>. [...]
Compression only makes sense for the tar format, so I think it's better
exposed by new formats and not by generic options.
For compress and bzip2 we'd need to call the external archiver, similar
to a pager. Interesting idea.
For gzip, we can use the zlib helper functions, since we're linking
against it anyway. I mention this because the following patch has been
laying around here for a while, collecting dust because it was a feature
waiting for a requester.
Using zlib directly avoids the overhead of a pipe and of buffering the
output for blocked writes; surprisingly (to me), it isn't any faster.
I didn't make any tuning efforts, yet, though. Anyway, here it is:
---
Documentation/git-archive.txt | 2 +-
archive-tar.c | 76 ++++++++++++++++++++++++++++++++++++----
archive.c | 43 ++++++++++++++++++++++-
archive.h | 1 +
t/t5000-tar-tree.sh | 30 ++++++++++++++++
5 files changed, 141 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 92444dd..2935246 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -34,7 +34,7 @@ OPTIONS
-------
--format=<fmt>::
- Format of the resulting archive: 'tar' or 'zip'. The default
+ Format of the resulting archive: 'tar', 'tar.gz' or 'zip'. The default
is 'tar'.
-l::
diff --git a/archive-tar.c b/archive-tar.c
index cee06ce..f22304d 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -58,18 +58,78 @@ static void write_blocked(const void *data, unsigned long size)
write_if_needed();
}
+static void gzwrite_or_die(gzFile *gzfile, const void *buf, size_t count)
+{
+ const int chunk = 1 << 30; /* Big arbitrary value that fits into int. */
+ const char *p = buf;
+
+ while (count > 0) {
+ unsigned int to_write = (count < chunk) ? count : chunk;
+ int written = gzwrite(gzfile, p, to_write);
+ if (written <= 0) {
+ int err;
+ const char *msg = gzerror(gzfile, &err);
+ if (err != Z_ERRNO)
+ die("zlib error: %s", msg);
+ if (errno == EAGAIN || errno == EINTR)
+ continue;
+ if (errno == EPIPE)
+ exit(0);
+ die_errno("write error");
+ }
+ count -= written;
+ p += written;
+ }
+}
+
+/*
+ * Writes directly through zlib and pads with NUL bytes to multiples of
+ * RECORDSIZE. Updates offset because the length of the trailer depends
+ * on it.
+ */
+static void write_to_tgz(struct archiver_args *args, const void *data,
+ unsigned long size)
+{
+ unsigned long tail = size % RECORDSIZE;
+ gzwrite_or_die(args->gzfile, data, size);
+ if (tail) {
+ tail = RECORDSIZE - tail;
+ if (gzseek(args->gzfile, tail, SEEK_CUR) == -1)
+ die("zlib error while seeking.");
+ }
+ offset = (offset + size + tail) % BLOCKSIZE;
+}
+
+static void write_to_archive(struct archiver_args *args, const void *data,
+ unsigned long size)
+{
+ if (args->gzfile)
+ write_to_tgz(args, data, size);
+ else
+ write_blocked(data, size);
+}
+
/*
* The end of tar archives is marked by 2*512 nul bytes and after that
* follows the rest of the block (if any).
*/
-static void write_trailer(void)
+static void write_trailer(struct archiver_args *args)
{
int tail = BLOCKSIZE - offset;
- memset(block + offset, 0, tail);
- write_or_die(1, block, BLOCKSIZE);
- if (tail < 2 * RECORDSIZE) {
- memset(block, 0, offset);
+ if (args->gzfile) {
+ if (tail < 2 * RECORDSIZE)
+ tail += BLOCKSIZE;
+ if (gzseek(args->gzfile, tail - 1, SEEK_CUR) == -1)
+ die("zlib error while seeking.");
+ if (gzputc(args->gzfile, '\0') == -1)
+ die("zlib error while writing a NUL byte.");
+ } else {
+ memset(block + offset, 0, tail);
write_or_die(1, block, BLOCKSIZE);
+ if (tail < 2 * RECORDSIZE) {
+ memset(block, 0, offset);
+ write_or_die(1, block, BLOCKSIZE);
+ }
}
}
@@ -201,9 +261,9 @@ static int write_tar_entry(struct archiver_args *args,
return err;
}
strbuf_release(&ext_header);
- write_blocked(&header, sizeof(header));
+ write_to_archive(args, &header, sizeof(header));
if (S_ISREG(mode) && buffer && size > 0)
- write_blocked(buffer, size);
+ write_to_archive(args, buffer, size);
return err;
}
@@ -245,6 +305,6 @@ int write_tar_archive(struct archiver_args *args)
if (!err)
err = write_archive_entries(args, write_tar_entry);
if (!err)
- write_trailer();
+ write_trailer(args);
return err;
}
diff --git a/archive.c b/archive.c
index 0bca9ca..8809f51 100644
--- a/archive.c
+++ b/archive.c
@@ -15,6 +15,8 @@ static char const * const archive_usage[] = {
};
#define USES_ZLIB_COMPRESSION 1
+#define USES_GZIP_COMPRESSION 2
+#define USES_COMPRESSION (USES_ZLIB_COMPRESSION | USES_GZIP_COMPRESSION)
static const struct archiver {
const char *name;
@@ -22,6 +24,7 @@ static const struct archiver {
unsigned int flags;
} archivers[] = {
{ "tar", write_tar_archive },
+ { "tar.gz", write_tar_archive, USES_GZIP_COMPRESSION },
{ "zip", write_zip_archive, USES_ZLIB_COMPRESSION },
};
@@ -336,7 +339,7 @@ static int parse_archive_args(int argc, const char **argv,
args->compression_level = Z_DEFAULT_COMPRESSION;
if (compression_level != -1) {
- if ((*ar)->flags & USES_ZLIB_COMPRESSION)
+ if ((*ar)->flags & USES_COMPRESSION)
args->compression_level = compression_level;
else {
die("Argument not supported for format '%s': -%d",
@@ -351,11 +354,38 @@ static int parse_archive_args(int argc, const char **argv,
return argc;
}
+static void archive_gzfile_open(struct archiver_args *args)
+{
+ char mode[] = "wbX";
+ if (args->compression_level == Z_DEFAULT_COMPRESSION)
+ mode[2] = '\0';
+ else
+ mode[2] = '0' + args->compression_level;
+ args->gzfile = gzdopen(xdup(1), mode);
+ if (!args->gzfile)
+ die("zlib error: out of memory.");
+}
+
+static void archive_gzfile_close(struct archiver_args *args)
+{
+ int err = gzclose(args->gzfile);
+ switch (err) {
+ case Z_OK:
+ break;
+ case Z_ERRNO:
+ die_errno("zlib error");
+ default:
+ die("zlib error %d while closing.", err);
+ }
+ args->gzfile = NULL;
+}
+
int write_archive(int argc, const char **argv, const char *prefix,
int setup_prefix)
{
const struct archiver *ar = NULL;
struct archiver_args args;
+ int err;
argc = parse_archive_args(argc, argv, &ar, &args);
if (setup_prefix && prefix == NULL)
@@ -366,5 +396,14 @@ int write_archive(int argc, const char **argv, const char *prefix,
git_config(git_default_config, NULL);
- return ar->write_archive(&args);
+ args.gzfile = NULL;
+ if (ar->flags & USES_GZIP_COMPRESSION)
+ archive_gzfile_open(&args);
+
+ err = ar->write_archive(&args);
+
+ if (!err && (ar->flags & USES_GZIP_COMPRESSION))
+ archive_gzfile_close(&args);
+
+ return err;
}
diff --git a/archive.h b/archive.h
index 038ac35..638a7ba 100644
--- a/archive.h
+++ b/archive.h
@@ -12,6 +12,7 @@ struct archiver_args {
unsigned int verbose : 1;
unsigned int worktree_attributes : 1;
int compression_level;
+ gzFile gzfile;
};
typedef int (*write_archive_fn_t)(struct archiver_args *);
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 5f84b18..4094c18 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -26,6 +26,8 @@ commit id embedding:
. ./test-lib.sh
UNZIP=${UNZIP:-unzip}
+GZIP=${GZIP:-gzip}
+GUNZIP=${GUNZIP:-$GZIP -d}
SUBSTFORMAT=%H%n
@@ -79,6 +81,15 @@ test_expect_success \
'git tar-tree HEAD >b2.tar'
test_expect_success \
+ 'git archive --format=tar.gz' \
+ 'git archive --format=tar.gz HEAD >bz.tar.gz'
+
+test_expect_success \
+ 'git archive --format=tar.gz with --output' \
+ 'git archive --format=tar.gz --output=bz1.tar.gz HEAD &&
+ test_cmp bz.tar.gz bz1.tar.gz'
+
+test_expect_success \
'git archive vs. git tar-tree' \
'test_cmp b.tar b2.tar'
@@ -146,7 +157,9 @@ test_expect_success \
'cp .git/info/attributes .git/info/attributes.before &&
echo "substfile?" export-subst >>.git/info/attributes &&
git archive HEAD >f.tar &&
+ git archive --format=tar.gz HEAD >fz.tar.gz &&
git archive --prefix=prefix/ HEAD >g.tar &&
+ git archive --format=tar.gz --prefix=prefix/ HEAD >gz.tar.gz &&
mv .git/info/attributes.before .git/info/attributes'
test_expect_success \
@@ -173,6 +186,23 @@ test_expect_success \
test_cmp a/substfile2 g/prefix/a/substfile2
'
+$GUNZIP -h >/dev/null 2>&1
+if [ $? -eq 127 ]; then
+ echo "Skipping tar.gz expansion tests, because gunzip was not found"
+else
+ test_expect_success \
+ 'expand *.tar.gz' \
+ '$GUNZIP bz.tar.gz &&
+ $GUNZIP fz.tar.gz &&
+ $GUNZIP gz.tar.gz'
+
+ test_expect_success \
+ 'compare files created by formats tar and tar.gz' \
+ 'test_cmp b.tar bz.tar &&
+ test_cmp f.tar fz.tar &&
+ test_cmp g.tar gz.tar'
+fi
+
test_expect_success \
'git archive --format=zip' \
'git archive --format=zip HEAD >d.zip'
--
1.6.5.rc0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox