* Re: git-send-pack SIGSEGV..
From: Linus Torvalds @ 2007-06-15 17:26 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706150949300.5848@iabervon.org>
On Fri, 15 Jun 2007, Daniel Barkalow wrote:
>
> Your analysis of the failure was right, though. I reproduced it, and this
> fixes it for me:
>
> --- cut here ---
> Author: Daniel Barkalow <barkalow@iabervon.org>
> Date: Fri Jun 15 10:22:37 2007 -0400
>
> Fix pushing to a pattern with no dst
>
> Refspecs with no colons are left with no dst value, because they are
> interepreted differently for fetch and push. For push, they mean to
> reuse the src side. Fix this for patterns.
>
> Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
And in case anybody cares, I've also verified it, so here's an
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
in case Junio didn't already apply it.
Linus
^ permalink raw reply
* Re: pull into dirty working tree
From: Robin Rosenberg @ 2007-06-15 18:26 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Bill Lear, git
In-Reply-To: <46a038f90706142033p1b7f5b49uc5b4af72b0419c8e@mail.gmail.com>
fredag 15 juni 2007 skrev Martin Langhoff:
> On 6/15/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > But yeah, if you can check in stage 1 (_without_ changing the working
> > tree) whether the merge will work, then everything is fine.
>
> Aha- so at phase 1 we know
> - what paths are dirty in the checkout
> - what paths of the merge need an actuall diff3 merge
>
> perhaps we can do those diff3 merges elsewhere (tempfiles). If they
> are trivial diff3 merges, then we can complete the merge operation
> without touching the checkout. After this is complete, we can then
> update the checkout...
Can't you treat this like git-am or git-rabase. Save the diff to .dottest. Then
peform the pull just like you do normally involving the user if necessary. After
that either automatically or after a --continue/--abort you apply the diff with it's own
conflicts.
-- robin
^ permalink raw reply
* Re: StGIT vs. guilt: What's the difference?
From: Yann Dirson @ 2007-06-15 20:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, Steven Grimm, 'git'
In-Reply-To: <tnx1wgds1pv.fsf@arm.com>
On Fri, Jun 15, 2007 at 03:59:24PM +0100, Catalin Marinas wrote:
> I haven't tried quilt either but, if it uses plain text patches, the
> disadvantage might be the losing of the three-way merge when pushing a
> patch onto the stack. The solution is to remember which commit the
> patch applies to, switch the tree, apply the patch and merge with
> HEAD.
Note that I haven't tried guilt either.
However, storing diffs is certainly a great way to interact with
legacy SCMs, and there are situations where guilt is certainly more
suited than stgit. Eg, on a project where you have to use CVS, and
you have to maintain changes to a Linux kernel, and you want to store
the history of a series of patches, guilt will be much easier to use
than stgit.
We may even want to implement something in stgit to ease such
integration with legacy SCMs - eg. an option to auto-export the stack
on push/refresh should not be too hard to implement.
> StGIT might have some more features as it is older but I see a lot of
> development is going on with guilt. Another difference is that StGIT
> is written in Python and guilt uses shell scripts (some people don't
> like the dependency on Python).
Well, people may not like python, but IMHO it is a lot easier to learn
it if you don't know it (that's what I did, although I did not start
from zero), than writing a robust and maintainable software of even
moderate complexity in shell script. Shell script may be good for
prototyping or gluing tools in a simple way, but for advanced sofware
on which to rely to store my own data, it is just not really suited.
Best regards,
--
Yann
^ permalink raw reply
* Re: [StGIT PATCH 2/4] Abstract a PatchSet object out of Series.
From: Yann Dirson @ 2007-06-15 20:14 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0706141556w1fb280dbu12e55dc91f6d5941@mail.gmail.com>
On Thu, Jun 14, 2007 at 11:56:47PM +0100, Catalin Marinas wrote:
> On 13/06/07, Yann Dirson <ydirson@altern.org> wrote:
> >I have started to work on a Hydra class (available at [1], but be
> >aware it doesn't do much more than creating an octopus, and breaking
> >many current StGIT assumptions), with a testcase to demonstrate its
> >use), which binds together a set of stacks with an octopus, to allow
> >keeping related patches together, and allow people to pull from one
> >topic stack without getting unrelated work.
>
> If it works, it would be really useful. Do the stacks need to be
> independent? I can group my patches easily (and I was thinking about
> "collapse/expand" commands for better viewing) but one stack might
> still depend on patches from a different one. It would be nice if one
> could also set the base of a series in this kind of hydra structure
> (unless it makes it difficult to understand).
Indeed one of the things that naturally come to mind after hydra, is
to abstract a parent class above PatchSet and Patch, and allow those
to be mostly used everywhere one of them is allowed.
That way we can have a (sub-)stack anywhere between 2 patches in a
stack, and that should I think address the need you describe. But
that would also allow to have an hydra built of single patches instead
of stacks, which would be quite similar to how darcs organizes
patches. Combinations are endless, and I don't even count the
possibility of adding new structures besides stacks and hydras :)
> >As described in that mail, there are problems both with the
> >original approach (Karl's test failing), and with that new one (that
> >exisiting test failing).
> >
> >Do you have any idea on how we could overcome the problem ? In the
> >meantime, we could possibly just comment that testcase out (or add
> >support for continuing the testsuite even with a failure) - the
> >problem it exhibits is probably less common than the one that was
> >fixed.
>
> I am happy with only 2 modes - one using ORIG_HEAD for people using
> StGIT in combination with plain GIT and the other overriding the base
> without checks. The second mode is for people not mixing StGIT with
> plain GIT. For the first mode, they have to deal with conflicts as
> with the standard GIT.
Well, I have to think about that in details - but right now I'm a bit
busy with the hydra thing.
> >BTW, a02ba4077f12578fe31c99d903488804a656e1c4 has a slight problem: it
> >is a patch by Karl, which I re-sent in the same group since it was
> >exhibiting the problem (and with the intent of adding a signed-off-by
> >line, but my way of adding them trough a buggy template showed its
> >limits and the commit now have 2 signed-off-by lines with Karl's
> >name). However, it was applied with myself as author, which is quite
> >wrong: could that be a but in "stg import" ignoring the Author field ?
>
> It's not a bug. The import command just uses the e-mail sender or a
> "From:" line before the patch description (see the default mail
> template). It doesn't check the sign lines (it is following the kernel
> patch submission guidelines).
We could surely improve things (and I'm not suggesting we should look
at sign lines). Eg, by having stg-mail add an Author pseudo-header
when the patch author is different from the sender, and having
stg-import use that when available.
> I would drop both the above commits for release 0.13. Are you OK with this?
Seems reasonable: the previous situation only seems to hurt when using
a workflow not involving stgit alone, whereas with this patch we also
break stgit-only workflows.
Best regards,
--
Yann.
^ permalink raw reply
* git-svn crashes with svn 1.4.4
From: Dave Hanson @ 2007-06-15 20:15 UTC (permalink / raw)
To: git
I just installed Subversion 1.4.4 on my Intel Mac Pro from
http://downloads.open.collab.net/binaries.html. After doing so,
git-svn dies with a bus error, in a perl library, I believe.
I rebuild git v1.5.2.1 and reinstalled. Same behavior. I suspect I
have a mismatch between git-svn and the perl swig bindings, but I have
yet been able to pinpoint the offender. Clues would be appreciated.
thanks,
dave h
^ permalink raw reply
* Re: git-svn crashes with svn 1.4.4
From: Dave Hanson @ 2007-06-15 21:49 UTC (permalink / raw)
To: git
In-Reply-To: <9fb1551c0706151315u221feed1se61cc7689ba1f7d@mail.gmail.com>
On 6/15/07, Dave Hanson <drh@drhanson.net> wrote:
> I just installed Subversion 1.4.4 on my Intel Mac Pro from
> http://downloads.open.collab.net/binaries.html. After doing so,
> git-svn dies with a bus error, in a perl library, I believe.
Fixed. Turns out I had older--and now incompatible--svn Perl bindings in
/Library/Perl/5.8.6/darwin-thread-multi-2level/{SVN,auto}
The newest bindings are in
/usr/local/lib/svn-perl/{SVN,auto}/
Even running perl -e "use SVN::Core" crashed with a bus error. Adding
/usr/local/lib/svn-perl to the environment variable PERL5LIB fixes
these problems.
I removed /Library/.../{SVN,auto}. Interestingly, perl -e "use
SVN::Core" then fails with a reasonable diagnostic. Next, I did
sudo cp -rp /usr/local/lib/svn-perl/* \
/Library/Perl/5.8.6/darwin-thread-multi-2level
which obviates the need to set PERL5LIB. I'm sure there's a way to
configure perl to add /usr/local/lib/svn-perl to PERL5LIB. Even so,
the old, incompatible bindings must be removed.
Pardon the false alarm,
dave h
^ permalink raw reply
* Re: Newbie questions about moving around repositories
From: Alex Riesen @ 2007-06-15 21:58 UTC (permalink / raw)
To: Ed Schofield; +Cc: git
In-Reply-To: <1b5a37350706151019u2bf81e81me05d13ea9bf40591@mail.gmail.com>
Ed Schofield, Fri, Jun 15, 2007 19:19:58 +0200:
> On 6/15/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> >On 6/15/07, Ed Schofield <edschofield@gmail.com> wrote:
> >> 1. I would like to move my repository (including all branches) from
> >> directory A to a directory B on a different filesystem.
> >> [snip]
> >
> >Just copy it.
> >[snip]
> >... but fix that .git/objects/info/alternates files in the repos left to
> >point to the new location of the moved directory.
>
>
> Thanks, Alex! Changing this and .git/branches/origin worked a treat.
>
.git/branches is obsoleted. Branch configuration is in .git/config now
^ permalink raw reply
* Re: [PATCH guilt] make guilt use standard POSIX shell
From: Benjamin Sergeant @ 2007-06-15 22:31 UTC (permalink / raw)
To: Derek Fawcus; +Cc: Pierre Habouzit, Josef Jeff Sipek, git
In-Reply-To: <20070615090104.B20266@mrwint.cisco.com>
On 6/15/07, Derek Fawcus <dfawcus@cisco.com> wrote:
> On Thu, Jun 14, 2007 at 02:50:55PM +0200, Pierre Habouzit wrote:
> > This patch series makes guilt be able to work with a standard posix shell.
> >
> > This has been tested with bash, zsh, dash and posh acting as /bin/sh.
>
> Well if you want to try with a 'real' bourne shell, there is always the
> heirloom sh or the v7 shell...
>
> http://heirloom.sourceforge.net/sh.html
>From the main page
'''
interactive use. The Bourne shell provides job control if it is
invoked as jsh and runs on a terminal. Of course, it lacks fancy
features such as a command history, command line completion, etc. But
working with these features tends to distract the user's attention.
After a familiarization phase, use of the Bourne shell can lead to a
more even-tempered, concentrated working style. Give it a try.
Seriously.
'''
I love it. I acknowledge that you have to be fairly well concentrated
if you want to type
/usr/lib/python2.5/site-packages/spambayes/resources/ (as an example)
without missing one char.
:)
Benjamin.
> http://www.collyer.net/who/geoff/v7sh.tar
> http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/
>
> DF
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [RFT] Format our Documentation/ with both AsciiDoc 7 & 8
From: Junio C Hamano @ 2007-06-15 22:52 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Stefan Richter
In-Reply-To: <20070615080935.GB28554@artemis.intersec.eu>
Pierre Habouzit <madcoder@debian.org> writes:
> sadly, it does not fixes the issue I reported with git-pull.1 (e.g.)
> that reads:
>
> <refspec>
> The canonical format of a <refspec> parameter is ?<src>:<dst>; that
>
> whereas it should be:
>
> <refspec>
> The canonical format of a <refspec> parameter is +?<src>:<dst>; that
That is very unexpected, especially as your e-mail address is in
debian.org.
* My local test and build usually is done with AsciiDoc 7.1.2
that is shipped with Debian, without any local modifications.
The part you quoted is formatted like this (I indented for
e-mail inclusion and line-wrapped below):
.PP
<refspec>
.RS 3n
The canonical format of a <refspec> parameter is +?<src>:<dst>;
that is, an optional plus +, followed by the source ref,
followed by a colon :, followed by the destination ref.
This is the same with or without the patch we are
discussing.
* I updated my notebook that runs Debian with AsciiDoc 8.2.1
and tested with the patch. The formatted result matches the
above.
* I tried the above with a hand-installed AsciiDoc 8.2.1 from
the tarball distribution. Again, the formatted result of the
quoted part matches.
* The preformatted manual pages on man branch in git.git are
generated on a k.org machine that runs AsciiDoc 7.0.2 on
FC5. The version before the patch is formatted like this:
.TP
<refspec>
The canonical format of a <refspec> parameter is +?<src>:<dst>;
that is, an optional plus +, followed by the source ref,
followed by a colon :, followed by the destination ref.
I haven't had a chance to test how it comes out with the
patch, but because the only difference under AsciiDoc 7 is
the definition of {caret} macro, I do not expect any change
in the quoted area.
In other words, there is no breakage like you are observing in
the original (nor updated) version with any of the platforms and
AsciiDoc versions I had handy to test. There is something
different with the version of AsciiDoc you are using, but I
cannot tell what that is.
^ permalink raw reply
* Re: [PATCH] git-svn: avoid string eval for defining functions
From: Eric Wong @ 2007-06-16 0:22 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <11818790393274-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> You don't need to use string eval to define new functions; assigning a
> code reference to the target symbol table is enough.
Cool.
Acked-by: Eric Wong <normalperson@yhbt.net>
> ---
> git-svn.perl | 64 +++++++++++++++++++++++++++++----------------------------
> 1 files changed, 33 insertions(+), 31 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 4d35895..4ba0813 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -38,14 +38,16 @@ use IPC::Open3;
> use Git;
>
> BEGIN {
> - my $s;
> + # import functions from Git into our packages, en masse
> + no strict 'refs';
> foreach (qw/command command_oneline command_noisy command_output_pipe
> command_input_pipe command_close_pipe/) {
> - $s .= "*SVN::Git::Editor::$_ = *SVN::Git::Fetcher::$_ = ".
> - "*Git::SVN::Migration::$_ = ".
> - "*Git::SVN::Log::$_ = *Git::SVN::$_ = *$_ = *Git::$_; ";
> + for my $package ( qw(SVN::Git::Editor SVN::Git::Fetcher
> + Git::SVN::Migration Git::SVN::Log Git::SVN),
> + __PACKAGE__) {
> + *{"${package}::$_"} = \&{"Git::$_"};
> + }
> }
> - eval $s;
> }
>
> my ($SVN);
> @@ -898,26 +900,26 @@ BEGIN {
> # some options are read globally, but can be overridden locally
> # per [svn-remote "..."] section. Command-line options will *NOT*
> # override options set in an [svn-remote "..."] section
> - my $e;
> - foreach (qw/follow_parent no_metadata use_svm_props
> - use_svnsync_props/) {
> - my $key = $_;
> + no strict 'refs';
> + for my $option (qw/follow_parent no_metadata use_svm_props
> + use_svnsync_props/) {
> + my $key = $option;
> $key =~ tr/_//d;
> - $e .= "sub $_ {
> - my (\$self) = \@_;
> - return \$self->{-$_} if exists \$self->{-$_};
> - my \$k = \"svn-remote.\$self->{repo_id}\.$key\";
> - eval { command_oneline(qw/config --get/, \$k) };
> - if (\$@) {
> - \$self->{-$_} = \$Git::SVN::_$_;
> + my $prop = "-$option";
> + *$option = sub {
> + my ($self) = @_;
> + return $self->{$prop} if exists $self->{$prop};
> + my $k = "svn-remote.$self->{repo_id}.$key";
> + eval { command_oneline(qw/config --get/, $k) };
> + if ($@) {
> + $self->{$prop} = ${"Git::SVN::_$option"};
> } else {
> - my \$v = command_oneline(qw/config --bool/,\$k);
> - \$self->{-$_} = \$v eq 'false' ? 0 : 1;
> + my $v = command_oneline(qw/config --bool/,$k);
> + $self->{$prop} = $v eq 'false' ? 0 : 1;
> }
> - return \$self->{-$_} }\n";
> + return $self->{$prop};
> + }
> }
> - $e .= "1;\n";
> - eval $e or die $@;
> }
>
> my %LOCKFILES;
> @@ -2956,17 +2958,17 @@ my ($can_do_switch, %ignored_err, $RA);
>
> BEGIN {
> # enforce temporary pool usage for some simple functions
> - my $e;
> - foreach (qw/rev_proplist get_latest_revnum get_uuid get_repos_root/) {
> - $e .= "sub $_ {
> - my \$self = shift;
> - my \$pool = SVN::Pool->new;
> - my \@ret = \$self->SUPER::$_(\@_,\$pool);
> - \$pool->clear;
> - wantarray ? \@ret : \$ret[0]; }\n";
> + no strict 'refs';
> + for my $f (qw/rev_proplist get_latest_revnum get_uuid get_repos_root/) {
> + my $SUPER = "SUPER::$f";
> + *$f = sub {
> + my $self = shift;
> + my $pool = SVN::Pool->new;
> + my @ret = $self->$SUPER(@_,$pool);
> + $pool->clear;
> + wantarray ? @ret : $ret[0];
> + };
> }
> -
> - eval "$e; 1;" or die $@;
> }
>
> sub new {
> --
> 1.5.2.0.45.gfea6d-dirty
>
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Documentation/gitmodules: fix asciidoc
From: Sam Vilain @ 2007-06-16 1:53 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Git Mailing List
In-Reply-To: <8c5c35580706150011g2189e45dvb1dc1567f12c7f8c@mail.gmail.com>
Lars Hjemli wrote:
>> Yea, I got doc build errors today too from `next`
> This is my bad, sorry about that.
> Have you tested the patch in
> <11817720703159-git-send-email-hjemli@gmail.com> /
> http://article.gmane.org/gmane.comp.version-control.git/50135 ?
Yep, that works, cheers.
Sam.
^ permalink raw reply
* Re: git-send-pack SIGSEGV..
From: Junio C Hamano @ 2007-06-16 2:00 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706150949300.5848@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
>> I suspect this has an side effect of allowing
>>
>> fetch = refs/heads/*
>>
>> to mean the same thing as
>>
>> fetch = refs/heads/*:refs/heads/*
>>
>> which is suitable for a bare mirroring repository, but I do not
>> think of any downside, so it might be Ok.
>>
>> But that is something from a person who was under anesthesia a
>> few hours ago, so you should take it with a big grain of salt ;-)
>
> Yeah, that's not right; "push = refs/heads/*" works like that, but
> "fetch = refs/heads/*" puts them in MERGE_HEAD without storing them
> anywhere, unlike "fetch = refs/heads/*:refs/heads/*".
While I appreciate the proper fix, I have to say "Wait a minute".
First of all, do you really mean MERGE_HEAD in the above? My
fix would obviously change the way how "git fetch" would STORE
what was fetched when you have "fetch = refs/heads/*" line in
the configuration file, which is what I already said in my
message. However, using or not using tracking branches to store
the result should never affect if the fetched object is used in
MERGE_HEAD, so the fix you are responding to should not affect
what goes there at all. If it does, then there is something
wrong in the current code.
I did not even realize that "push/fetch = $prefix/*" was
allowed. IIRC, it has always been "$prefix1/*:$prefix2/*" form,
and "$prefix/*" was illegal. Somehow a change in sematics
sneaked in without me knowing that makes it legal, and the
updated semantics is that for push "$prefix/*" is the same as
listing every ref under the prefix (without any colon, so it
pushes to the same name), and for fetch "$prefix/*" is the same
as $prefix/$x: (i.e. with colon and empty RHS) for all refs
under $prefix.
Now, I am not opposed to _having_ enhanced semantics. Earlier,
"$prefix/*" was illegal, so it is not like you have introduced
any incompatibility. On the push side, I do not think of any
sane interpretation for it other than treating it exactly as
"$prefix/*:$prefix/*". On the fetch side, however, I am not
sure not to use any tracking _and_ grabbing everything is a sane
semantics. You fetch everything under $prefix/ and list them in
FETCH_HEAD --- now what? On the other handl, treating it as if
the user wrote "$prefix/*:$prefix/*" makes some sense. It is a
natural operation to keep a bare mirroring repository up to
date.
But I am somewhat upset about us having the enhanced semantics
without me knowing. I see two possible reasons for it: (1) I
was not being extra careful when I accepted your patches, and
(2) the change in the semantics were not documented, either in
the log nor Documentation/.
We obviously cannot fix (1) overnight, but could you please at
least fix (2)? git-push.txt and pull-fetch-param.txt would be
the two places that talk about "$prefix1/*:$prefix2/*", and they
should talk about the new "$prefix/*" syntax as well.
I think "fetch = refs/heads/*" syntax, if it just fetches
without storing, does not make much sense. In a separate-remote
repository, "[remote "foo"] fetch = refs/heads/*" would probably
be useful if we treated it as "refs/heads/*:refs/remotes/foo/*".
In a bare repository used for mirrors, it would be useful if it
stood for "refs/heads/*:refs/heads/*".
^ permalink raw reply
* Re: git-send-pack SIGSEGV..
From: Daniel Barkalow @ 2007-06-16 4:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7v7iq47j5z.fsf@assigned-by-dhcp.pobox.com>
On Fri, 15 Jun 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> >> I suspect this has an side effect of allowing
> >>
> >> fetch = refs/heads/*
> >>
> >> to mean the same thing as
> >>
> >> fetch = refs/heads/*:refs/heads/*
> >>
> >> which is suitable for a bare mirroring repository, but I do not
> >> think of any downside, so it might be Ok.
> >>
> >> But that is something from a person who was under anesthesia a
> >> few hours ago, so you should take it with a big grain of salt ;-)
> >
> > Yeah, that's not right; "push = refs/heads/*" works like that, but
> > "fetch = refs/heads/*" puts them in MERGE_HEAD without storing them
> > anywhere, unlike "fetch = refs/heads/*:refs/heads/*".
>
> While I appreciate the proper fix, I have to say "Wait a minute".
>
> First of all, do you really mean MERGE_HEAD in the above?
Sorry, FETCH_HEAD. MERGE_HEAD would be seriously wrong. I was trying to
say that it didn't store them in any tracking location, and messed up the
irrelevant bit of was it does do with them.
> I did not even realize that "push/fetch = $prefix/*" was
> allowed. IIRC, it has always been "$prefix1/*:$prefix2/*" form,
> and "$prefix/*" was illegal.
I thought when I was first writing the remotes.{c,h} code, I found that at
least "push = foo/*" was supported already, due to nothing actually
excluding it, and the code for copying the lhs to a blank rhs was being
applied to patterns just like non-patterns.
That is, since "push = refs/heads/master" was already the same as "push =
refs/heads/master:refs/heads/master", the pattern fell into that code. I
was at least confidant enough of this to translate --tags into
"refs/tags/*" instead of "refs/tags/*:refs/tags/*" when I got to that
point.
I'm not sure if "fetch = foo/*" was permitted (or is, since fetch is still
using other parsing in general), but, whatever it does, if it's allowed,
it should certainly match "fetch = refs/head/master", which is pretty well
agreed on at this point.
> Somehow a change in sematics sneaked in without me knowing that makes it
> legal, and the updated semantics is that for push "$prefix/*" is the
> same as listing every ref under the prefix (without any colon, so it
> pushes to the same name), and for fetch "$prefix/*" is the same
> as $prefix/$x: (i.e. with colon and empty RHS) for all refs
> under $prefix.
>
> Now, I am not opposed to _having_ enhanced semantics. Earlier,
> "$prefix/*" was illegal, so it is not like you have introduced
> any incompatibility. On the push side, I do not think of any
> sane interpretation for it other than treating it exactly as
> "$prefix/*:$prefix/*". On the fetch side, however, I am not
> sure not to use any tracking _and_ grabbing everything is a sane
> semantics. You fetch everything under $prefix/ and list them in
> FETCH_HEAD --- now what? On the other handl, treating it as if
> the user wrote "$prefix/*:$prefix/*" makes some sense. It is a
> natural operation to keep a bare mirroring repository up to
> date.
I think it could make sense to prepare an octopus merge of a bunch of
heads in a subdirectory. And it should either be prohibited or match the
behavior of a non-pattern, or it would be really confusing.
> But I am somewhat upset about us having the enhanced semantics
> without me knowing. I see two possible reasons for it: (1) I
> was not being extra careful when I accepted your patches, and
> (2) the change in the semantics were not documented, either in
> the log nor Documentation/.
Actually, I thought I was just overlooking the part of the documentation
that explained patterns for push, but it isn't actually there.
builtin-push.c put a lot of effort into supporting them when I got to it,
but none of the documentation even suggests that you can put wildcards in
two-sided refspecs for push, let alone one (and the code I was looking at
was yours, added without documentation but with a hefty commit message in
d46ae3f0). Based on the meaning of wildcards in push refspecs, however,
the documentation for one-sided refspecs in git-push:
A parameter <ref> without a colon pushes the <ref> from the source
repository to the destination repository under the same name.
clearly implies that anything that, whatever refs/heads/* matches, it
pushes to the destination under the same name.
On the fetch side, the code isn't using my parser yet, anyway. But my
parser should be able to distinguish the one-sided refspec case, so that
the fetch logic can do whatever is determined to be right with the
combination of features.
> I think "fetch = refs/heads/*" syntax, if it just fetches
> without storing, does not make much sense. In a separate-remote
> repository, "[remote "foo"] fetch = refs/heads/*" would probably
> be useful if we treated it as "refs/heads/*:refs/remotes/foo/*".
> In a bare repository used for mirrors, it would be useful if it
> stood for "refs/heads/*:refs/heads/*".
I'm kind of uncomfortable with this level of complexity for a fully
specified lhs pattern. Maybe "fetch = refs/heads/*" should be prohibited,
while something DWIM-y like "fetch = heads/*" or even "fetch = head *"
could come up with clever and useful patterns. In any case, the parser
should report "refs/heads/*" as pattern,refs/heads/,NULL and let the fetch
code decide what to do with it, rather than having the special case in the
parser.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Add test-script for git-tag
From: Junio C Hamano @ 2007-06-16 5:14 UTC (permalink / raw)
To: Carlos Rica; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0706141851160.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> forwarded:
> +# creating and listing lightweight tags:
> +
> +tag_exists () {
> + git show-ref --quiet --verify refs/tags/$1
> +}
It would be better if you _always_ quoted "$1" for my eyes, as
it would let my brain coast over it without thinking. This does
not matter in practice as we do not allow metacharacters nor
whitespaces in tagnames, but that comes _after_ having to think
about it.
> +test_expect_success 'listing all tags in an empty tree now should succeed' \
> + 'git tag -l'
A recent patch made it not to exit with non-zero, but I think
that is probably a bug we might want to fix.
> +test_expect_success \
> + 'listing a tag using a matching pattern should output that tag' \
> + 'test `git-tag -l mytag` = mytag'
> +
> +test_expect_success \
> + 'listing tags using a non-matching pattern now should suceed' \
> + 'git-tag -l xxx'
> +
> +test_expect_success \
> + 'listing tags using a non-matching pattern should output nothing' \
> + 'test `git-tag -l xxx | wc -l` -eq 0'
> +
Additional test would be to see git-tag -l "my*" should succeed,
and git-tag -l "my.*" should fail, as the pattern should match
with fnmatch() not regexp().
> +# special cases for creating tags:
> +
> +test_expect_failure \
> + 'trying to create a tag with the name of one existing should fail' \
> + 'git tag mytag'
> +
> +test_expect_failure 'trying to create a tag with a non-valid name should fail' '
> + test `git-tag -l | wc -l` -ne 1 ||
> + git tag .othertag ||
> + git tag "other tag" ||
> + git tag "othertag^" ||
> + git tag "other~tag" ||
> + test `git-tag -l | wc -l` -ne 1
> +'
While it is logically correct to string error conditions with ||
and test inside expect-failure (you are saying "it is a failure
if any of these succeeds"), it needs a bit of brain-twisting to
get what is going on. But I think this is a valid way to use
expect-failure.
> +test_expect_success \
> + 'listing tags with substring as pattern now must print those matching' '
> ...
> +test_expect_success \
> + 'listing tags with substring as pattern now must print those matching' '
> ...
> +test_expect_success \
> + 'listing tags with substring as pattern now must print those matching' '
> ...
> +test_expect_success \
> + 'listing tags using a name as pattern now must print those matching' '
> ...
> +test_expect_success \
> + 'listing tags using a name as pattern now must print those matching' '
> ...
Somehow, "now" gets quite irritating.
> +
> +cat >expect <<EOF
> +v1.1.3
> +EOF
> +test_expect_success \
> + 'listing tags with ? in the pattern should print those matching' '
> + git-tag -l 1.1? > actual &&
> + git-diff expect actual
> +'
I know that there is no such file as 1.1X in the working tree,
but I would feel better if the test protected the ? from the
shell, as in "git tag -l 1.1\? >actual".
> +# creating and verifying lightweight tags:
> +
> +test_expect_success \
> + 'a non-annotated tag created without parameters should point to HEAD' '
> + git-tag non-annotated-tag &&
> + ! git cat-file tag non-annotated-tag &&
> + test "$(git rev-parse non-annotated-tag^{commit})" = \
> + "$(git rev-parse HEAD)"
> +'
I think testing the type directly is more to the point, as in
test $(git-cat-file -t non-annotated-tag) = commit &&
test $(git-rev-parse non-annotated-tag) = $(git-rev-parse HEAD)
> +
> +test_expect_failure 'trying to verify an unknown tag should fail' \
> + 'git-tag -v unknown-tag'
> +
> +test_expect_failure \
> + 'trying to verify a non-annotated and non-signed tag should fail' \
> + 'git-tag -v non-annotated-tag'
> +
> +# creating annotated tags:
> +
> +get_tag_msg () {
> + git cat-file tag "$1" | sed -n -e "1,/BEGIN PGP/p"
> +}
> +
I would write that as "sed -e '/BEGIN PGP/q'", shorter and more
to the point.
> +get_tag_header () {
> +cat >expect <<EOF
> +object $2
> +type commit
> +tag $1
> +tagger C O Mitter <committer@example.com> $3 -0700
> +
> +EOF
> +}
Maybe -0700 deserves a comment --- test_tick always gives time
in that timezone.
You probably would want to also test annotated tags on non
commits (i.e. trees, blobs and tags).
> +
> +commit=$(git rev-parse HEAD)
> +time=$test_tick
> +
> +get_tag_header annotated-tag $commit $time >expect
Huh? get_tag_header stores into "expect" file without saying
anything itself, and you redirect that nothingless to the same
file?
> +touch emptyfile
Maybe it's just me being old-fashioned, but I prefer creation of
an empty file be done with:
: >emptyfile
or just
>emptyfile
and avoid using "touch". Some broken systems did not create a
new file with "touch non-existing-file" (I think it was old AIX).
> +# creating and verifying signed tags:
> +
> +gpg --version >/dev/null
> +if [ $? -eq 127 ]; then
> + echo "Skipping signed tags tests, because gpg was not found"
> + test_done
> + exit
> +fi
> +
> +# key generation info: gpg --homedir t/t7003 --gen-key
> +# Type DSA and Elgamal, size 2048 bits, no expiration date.
> +# Name and email: C O Mitter <committer@example.com>
> +# No password given, to enable non-interactive operation.
> +
> +cp -R ../t7003 ./gpghome
> +chmod 0700 gpghome
> +export GNUPGHOME="$(pwd)/gpghome"
> +
> +get_tag_header signed-tag $commit $time >expect
> +echo 'A signed tag message' >>expect
> +echo '-----BEGIN PGP SIGNATURE-----' >>expect
> +test_expect_success 'creating a signed tag with -m message should succeed' '
> + git-tag -s -m "A signed tag message" signed-tag &&
> + get_tag_msg signed-tag >actual &&
> + git-diff expect actual
> +'
> +
This is just me being curious, but I wonder if this test is safe
to run on an otherwise idle server without moving parts and
keyboard (i.e. lack of sufficient entropy). I think you made a
prudent choice of not generating a test key in the test script,
by the way.
> +test_expect_success 'verifying a signed tag should succeed' \
> + 'git-tag -v signed-tag'
> +
Forging the tag at this point and make sure it does not verify
would also be interesting, as in:
forged=$(git cat-file tag signed-tag |
sed -e "s/signed-tag/forged-tag/" |
git mktag) &&
git tag forged-tag $forged &&
if git-tag -v forged-tag
then
echo Oops
false
else
: happy
fi
> diff --git a/t/t7003/random_seed b/t/t7003/random_seed
> new file mode 100644
> index 0000000000000000000000000000000000000000..8fed1339ed0a744e5663f4a5e6b6ac9bae3d8524
> GIT binary patch
> literal 600
> zcmV-e0;m1=h9nBV>1C6QsKJEiEJaD@Q3F8s5u<$E+<2(By)JAZSxviTsXg(wKC+O%
> zzvV{Z>W3*k?r7~pgmmkbw8-x{Am!eeN)z?cwIHcT2jqgiA(SXo<iO=E?cY80`p#w8
Is it necessary to ship random_seed, or is it created as needed
during the test?
^ permalink raw reply
* Re: [PATCH/RFH] pp_header(): work around possible memory corruption
From: Junio C Hamano @ 2007-06-16 5:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706151318210.4059@racer.site>
At least the older humongous pretty_print_commit() got separated
into manageable chunks, and I was happy. I was just too lazy
when refactoring the code and stopped there.
The right fix is to propagate the "realloc as needed" callchain
into add_user_info(), instead of having "this should be enough"
there. These two you touched are the only two callsite of that
static function.
^ permalink raw reply
* Re: [RFT] Format our Documentation/ with both AsciiDoc 7 & 8
From: Pierre Habouzit @ 2007-06-16 8:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7ik7rvq.fsf@assigned-by-dhcp.pobox.com>
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
On Fri, Jun 15, 2007 at 03:52:09PM -0700, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > sadly, it does not fixes the issue I reported with git-pull.1 (e.g.)
> > that reads:
> >
> > <refspec>
> > The canonical format of a <refspec> parameter is ?<src>:<dst>; that
> >
> > whereas it should be:
> >
> > <refspec>
> > The canonical format of a <refspec> parameter is +?<src>:<dst>; that
>
> That is very unexpected, especially as your e-mail address is in
> debian.org.
Well I'm running unstable, with asciidoc 8.2.1.
> * I updated my notebook that runs Debian with AsciiDoc 8.2.1
> and tested with the patch. The formatted result matches the
> above.
AAAAND I'M AN IDIOT. I tested it in the wrong branch, without the
patch. do'h.
I confirm that it works perfectly. Now, does someone knows a hole
where I can hide into ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Add --skip-from-cc option to git-send-email to prevent mailing to From: and Cc: addresses in patch headers
From: Alex Unleashed, Alex Unleashed @ 2007-06-16 14:00 UTC (permalink / raw)
To: git
This applies only to From: and Cc: lines in headers, not the body, so
that --no-signed-off-by-cc still applies for those.
Signed-off-by: Alex Unleashed <unledev@gmail.com>
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 946bd76..7c9fded 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -67,6 +67,10 @@ The --cc option must be repeated for each user you want on the cc list.
Make git-send-email less verbose. One line per email should be
all that is output.
+--skip-from-cc::
+ Do not add emails found in From: or Cc: headers in patches.
+ Note that this does not apply to addresses in patch bodies.
+
--smtp-server::
If set, specifies the outgoing SMTP server to use (e.g.
`smtp.example.com` or a raw IP address). Alternatively it can
diff --git a/git-send-email.perl b/git-send-email.perl
index 7c0c90b..35a0e6c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -68,6 +68,9 @@ Options:
that appear in Signed-off-by: or Cc: lines to the cc:
list. Note: Using this option is not recommended.
+ --skip-from-cc Do not send email to From: and Cc: addresses from headers
+ in patches.
+
--smtp-server If set, specifies the outgoing SMTP server to use.
Defaults to localhost.
@@ -139,7 +142,7 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,
# Behavior modification variables
my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
- $dry_run) = (1, 0, 0, 0, 0);
+ $skip_from_cc, $dry_run) = (1, 0, 0, 0, 0, 0);
my $smtp_server;
my $envelope_sender;
@@ -179,6 +182,7 @@ my $rc = GetOptions("from=s" => \$from,
"quiet" => \$quiet,
"suppress-from" => \$suppress_from,
"no-signed-off-cc|no-signed-off-by-cc" => \$no_signed_off_cc,
+ "skip-from-cc" => \$skip_from_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
);
@@ -560,7 +564,7 @@ foreach my $t (@files) {
if (/^Subject:\s+(.*)$/) {
$subject = $1;
- } elsif (/^(Cc|From):\s+(.*)$/) {
+ } elsif (!$skip_from_cc && /^(Cc|From):\s+(.*)$/) {
if (unquote_rfc2047($2) eq $from) {
$from = $2;
next if ($suppress_from);
@@ -583,7 +587,7 @@ foreach my $t (@files) {
# line 2 = subject
# So let's support that, too.
$input_format = 'lots';
- if (@cc == 0) {
+ if (!$skip_from_cc && @cc == 0) {
printf("(non-mbox) Adding cc: %s from line '%s'\n",
$_, $_) unless $quiet;
--
1.5.2.1
^ permalink raw reply related
* Re: [PATCH] Add a local implementation of hstrerror for the system which do not have it
From: Randal L. Schwartz @ 2007-06-16 15:21 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Johannes Sixt, Junio C Hamano
In-Reply-To: <20070613185432.GA3412@steel.home>
>>>>> "Alex" == Alex Riesen <raa.lkml@gmail.com> writes:
Alex> The function converts the value of h_errno (last error of name
Alex> resolver library, see netdb.h).
Alex> One of systems which supposedly do not have the function is SunOS.
Alex> POSIX does not mandate its presence.
Thanks... 952c8c5 compiles and installs fine on sunos now.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Fix up ugly open-coded "alloc_nr()" user in object.c
From: Linus Torvalds @ 2007-06-16 17:30 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
When adding objects to the object/mode array, we used to have our own
alloc_nr() implementation, rather than use the normal one.
And since the normal one is arguably a bit nicer (still grows the
allocation exponentially, just not by more-than-doubling it every time),
why not just use it?
That array of objects ends up being really quite big when you force a
while repack of a big project, and while we might end up doing a few more
xreallocs in the process, we also hopefully don't end up with a final
allocation that is quite as wastefully big.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
That was an overkill of a situation for a trivial patch that I don't
think is in the least interesting or even important. I really don't care
if you take this, Junio, but it seemed the obvious one-liner to do, so
I'm sending it in anyway.
object.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/object.c b/object.c
index 16793d9..fdd6ceb 100644
--- a/object.c
+++ b/object.c
@@ -245,7 +245,7 @@ void add_object_array_with_mode(struct object *obj, const char *name, struct obj
struct object_array_entry *objects = array->objects;
if (nr >= alloc) {
- alloc = (alloc + 32) * 2;
+ alloc = alloc_nr(alloc);
objects = xrealloc(objects, alloc * sizeof(*objects));
array->alloc = alloc;
array->objects = objects;
^ permalink raw reply related
* Re: Fix up ugly open-coded "alloc_nr()" user in object.c
From: Jeff King @ 2007-06-16 18:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706161024220.14121@woody.linux-foundation.org>
On Sat, Jun 16, 2007 at 10:30:22AM -0700, Linus Torvalds wrote:
> When adding objects to the object/mode array, we used to have our own
> alloc_nr() implementation, rather than use the normal one.
>
> And since the normal one is arguably a bit nicer (still grows the
> allocation exponentially, just not by more-than-doubling it every time),
> why not just use it?
How about using the new ALLOC_GROW macro to make it even shorter? I also
got rid of the aliased variables, which IMO just make it harder to see
what's going on.
---
object.c | 19 +++++--------------
1 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/object.c b/object.c
index 16793d9..064e423 100644
--- a/object.c
+++ b/object.c
@@ -240,18 +240,9 @@ void add_object_array(struct object *obj, const char *name, struct object_array
void add_object_array_with_mode(struct object *obj, const char *name, struct object_array *array, unsigned mode)
{
- unsigned nr = array->nr;
- unsigned alloc = array->alloc;
- struct object_array_entry *objects = array->objects;
-
- if (nr >= alloc) {
- alloc = (alloc + 32) * 2;
- objects = xrealloc(objects, alloc * sizeof(*objects));
- array->alloc = alloc;
- array->objects = objects;
- }
- objects[nr].item = obj;
- objects[nr].name = name;
- objects[nr].mode = mode;
- array->nr = ++nr;
+ ALLOC_GROW(array->objects, array->nr, array->alloc);
+ array->objects[array->nr].item = obj;
+ array->objects[array->nr].name = name;
+ array->objects[array->nr].mode = mode;
+ array->nr++;
}
^ permalink raw reply related
* [PATCH 00/11] Document missing options
From: Jakub Narebski @ 2007-06-16 19:03 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
This series of patches documents [some] options which were missing
from the documentation.
Table of contents:
==================
[PATCH 01/11] Use tabs for indenting definition list for options in git-log.txt
[PATCH 02/11] Document git log --full-diff
[PATCH 03/11] Document git log --abbrev-commit, as a kind of pretty option
[PATCH 04/11] Document that '--message=<msg>' is long version of '-m <msg>'
[PATCH 05/11] Document that '--no-checkout' is long version of '-n' option of git-clone
[PATCH 06/11] Document git rev-list --timestamp
[PATCH 07/11] Document git rev-list --full-history
[PATCH 08/11] Document git rev-parse --is-inside-git-dir
[PATCH 09/11] Document git read-tree --trivial
[PATCH 10/11] Document git reflog --stale-fix
[PATCH 11/11] Document git commit --untracked-files and --verbose
What is still undocumented are:
* git clone --no-separate-remote, which is deprecated and perhaps
should be left undocumented.
* git commit -o|--only, which is now default when providing files
to be committed, and -i|--include is not present. Description
of this option was removed in commit 6c96753d:
"Documentation/git-commit: rewrite to make it more end-user friendly."
Should we re-add this description?
* git commit --reedit-message (--reedit) and --reuse-message
(--reuse). I'm not sure what are the meaning of those options, and
how they differ from -c (or -C --edit) and -C. I think, but I'm not
sure, that --reedit-message is long form of -c, and --reuse-message
is long form of -C.
* git reflog --dry-run. The --dry-run option in other command describe
what would be done. I think that this option does not work for this
command.
I have checked only ling options in builtins and shell scripts; I have
not checked Perl scripts not short options, and I might have missed
some options for which the same named option but for different command
exists in the documentation.
I might have missed modifying usage strings in command source, and
in command documentation.
But I think this series of patches is a good start...
---
Documentation/git-clone.txt | 1 +
Documentation/git-commit.txt | 12 ++++++++++--
Documentation/git-log.txt | 9 ++++++++-
Documentation/git-read-tree.txt | 8 +++++++-
Documentation/git-reflog.txt | 13 +++++++++++++
Documentation/git-rev-list.txt | 13 +++++++++++++
Documentation/git-rev-parse.txt | 4 ++++
Documentation/pretty-options.txt | 9 +++++++++
builtin-read-tree.c | 2 +-
9 files changed, 66 insertions(+), 5 deletions(-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 01/11] Use tabs for indenting definition list for options in git-log.txt
From: Jakub Narebski @ 2007-06-16 19:03 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11820206272990-git-send-email-jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/git-log.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 6157edb..c072441 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -52,7 +52,7 @@ include::pretty-options.txt[]
See also gitlink:git-reflog[1].
--decorate::
- Print out the ref names of any commits that are shown.
+ Print out the ref names of any commits that are shown.
<paths>...::
Show only commits that affect the specified paths.
--
1.5.2
^ permalink raw reply related
* [PATCH 03/11] Document git log --abbrev-commit, as a kind of pretty option
From: Jakub Narebski @ 2007-06-16 19:03 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11820206272990-git-send-email-jnareb@gmail.com>
Documentation taken from paraphrased description of "--abbrev[=<n>]"
diff option, and from description of commit 5c51c985 introducing
this option.
Note that to change number of digits one must use "--abbrev=<n>",
which affects [also] diff output.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/pretty-options.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
index 6338def..746bc5b 100644
--- a/Documentation/pretty-options.txt
+++ b/Documentation/pretty-options.txt
@@ -5,6 +5,15 @@
'full', 'fuller', 'email', 'raw' and 'format:<string>'.
When left out the format default to 'medium'.
+--abbrev-commit::
+ Instead of showing the full 40-byte hexadecimal commit object
+ name, show only handful hexdigits prefix. Non default number of
+ digits can be specified with "--abbrev=<n>" (which also modifies
+ diff output, if it is displayed).
++
+This should make "--pretty=oneline" a whole lot more readable for
+people using 80-column terminals.
+
--encoding[=<encoding>]::
The commit objects record the encoding used for the log message
in their encoding header; this option can be used to tell the
--
1.5.2
^ permalink raw reply related
* [PATCH 04/11] Document that '--message=<msg>' is long version of '-m <msg>'
From: Jakub Narebski @ 2007-06-16 19:03 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11820206272990-git-send-email-jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/git-commit.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 53a7bb0..352a494 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -71,7 +71,7 @@ OPTIONS
Override the author name used in the commit. Use
`A U Thor <author@example.com>` format.
--m <msg>::
+-m <msg>|--message=<msg>::
Use the given <msg> as the commit message.
-s|--signoff::
--
1.5.2
^ permalink raw reply related
* [PATCH 02/11] Document git log --full-diff
From: Jakub Narebski @ 2007-06-16 19:03 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11820206272990-git-send-email-jnareb@gmail.com>
Based on description of commit 477f2b41310c4b1040a9e7f72720b9c39d82caf9
"git log --full-diff" adding this option.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/git-log.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index c072441..7adcdef 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -54,6 +54,13 @@ include::pretty-options.txt[]
--decorate::
Print out the ref names of any commits that are shown.
+--full-diff::
+ Without this flag, "git log -p <paths>..." shows commits that
+ touch the specified paths, and diffs about the same specified
+ paths. With this, the full diff is shown for commits that touch
+ the specified paths; this means that "<paths>..." limits only
+ commits, and doesn't limit diff for those commits.
+
<paths>...::
Show only commits that affect the specified paths.
--
1.5.2
^ 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