* Re: current git kernel has strange problems during bisect
From: Kyle Moffett @ 2009-01-15 23:13 UTC (permalink / raw)
To: Kyle Moffett, Christian Borntraeger, Linus Torvalds, Sam Ravnborg,
"Johanne
In-Reply-To: <20090115165425.GA7517@bombe-desk.opditex>
On Thu, Jan 15, 2009 at 11:54 AM, Andreas Bombe <andreas.bombe@mytum.de> wrote:
> On Tue, Jan 13, 2009 at 03:26:09PM -0500, Kyle Moffett wrote:
>> On Sun, Jan 11, 2009 at 4:39 PM, Christian Borntraeger
>> <borntraeger@de.ibm.com> wrote:
>> > In my opinion we should really avoid subtree merges in the future as a curtesy
>> > to people who do the uncool work of testing, problem tracking and bisecting.
>> > </rant>
>>
>> As an alternative, you can relatively easily rewrite the following
>> independent histories:
>>
>> A -- B -- C
>> X -- Y -- Z
>>
>> To look like this:
>>
>> A -- B -- C -- X' -- Y' -- Z'
>>
>> Where X' is (C + sub/dir/X), Y' is (C + sub/dir/Y), etc...
>
> Given that the subtree may have been in development for a long time, it
> is almost a certainty that the older commits may compile on A but not
> on C. By basing it all on C you create a lot of uncompilable commits
> which hurt bisection just as bad. At least with missing kernel sources
> it is obvious that an attempt at compilation is futile and a waste of
> time.
No, the older commits will compile just fine as they don't actually
reference the new code from any of the parent makefiles. It would
effectively be "dead code" until the "merge" in the commit *after* Z'
in which you add lines to "sub/Kconfig" and "sub/Kbuild" which
reference "sub/dir/*".
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Santi Béjar @ 2009-01-16 0:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Teemu Likonen, Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0901151940170.3586@pacific.mpi-cbg.de>
2009/1/15 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Thu, 15 Jan 2009, Junio C Hamano wrote:
>> I didn't see the semantics of color-words documented in the original
>> either,
>
[...]
>> E.g. when these two are compared:
>>
>> bbb aaa bb aa b
>> ccc aaa cc
>>
>> what should happen? We would want to say "aa" was removed by showing it
>> in red, but on what background should it be displayed? cc <red>aa</red>
>> b?
>
> If we are only ever interested in the 'a's, I'd say that the output should
> only reflect that. In other words, what the current code does (ccc
> aaa<red>aa</red> cc) is okay IMHO. After all, we said we're interested in
> the 'a's, so we should not complain that it did not show us the removal of
> 'b's.
It may be ok and logical, but for me it is not what I want. Mmaybe I
don't really undestand what I want or is a crazy idea but here it is
anyway:
Take a simple case with this two lines :
matrix[a,b,c]
matrix{d,b,c}
there is no space so the standard color-words does not help to
visualize that matrix, the b and c are not changed.
What I currently do is to add some spaces:
matrix[ a, b, c ]
matrix{ d, b, c }
then the color-words at least says that "b, c" is unchanged.
What I would like is that --color-words would act as adding this
spaces automatically (and even one after "matrix").
Or another way to think it could be:
a) primary words are those with alphanumerics (or a regex)
b) secondary "words" are the other non-whitespaces characters (in this
case "[]{} and ,"
c) whitespaces are cruft.
(having two regexp to specify what is a words but they cannot mix).
If everything works as I think (it's late night :-) with the above two lines:
matrix[a,b,c]
matrix{d,b,c}
the word diff would be
matrix<RED>[<GREEN>{<RED>a<GREEN>d<RESET>,b,c<RED>]<GREEN>}<RED>
Santi
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Björn Steinbrink @ 2009-01-16 0:11 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Sverre Rabbelier, Junio C Hamano, Anders Melchiorsen, git,
Johannes.Schindelin
In-Reply-To: <20090115225912.GL9794@neumann>
On 2009.01.15 23:59:12 +0100, SZEDER Gábor wrote:
> On Thu, Jan 15, 2009 at 11:20:08PM +0100, Sverre Rabbelier wrote:
> > On Thu, Jan 15, 2009 at 23:09, Junio C Hamano <gitster@pobox.com> wrote:
> > > I agree that is a true disadvantage that shows "reset --soft HEAD^" is a
> > > bad idea (you could still say commit -c @{1}, though).
> >
> > But it's not:
> > "It also makes sure that a pre-filled editor is fired up when doing
> > "git rebase --continue", in case the user just wanted to fix the
> > commit message."
>
> Indeed, but in this case the rebase process will continue after
> finishing the commit message. OTOH, with the current behaviour, you
> must do a 'git commit --amend && git rebase --continue', which might
> seem more complicated at first sight, but...
No, you don't have to do that. As long as you only want to "edit" the
commit you marked as "edit", you only need to use "git add" and "git
rebase --continue". rebase -i checks whether HEAD still resolves to the
same commit and if so, it automatically does the soft reset for you.
Maybe we should just advertise that in the message provided by rebase
after it stops? I'm afraid I can't come up with a sane wording though,
as there are still cases when you need to commit yourself, eg. when you
use reset. And getting that into one simple sentence seems a bit hard
(for me).
A bit off-topic: The "auto-amend" code path passes --no-verify to git
commit. What's the reason for doing that? I actually always expected
that to use my pre-commit hook to stop me from committing crap. :-/
Björn
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Junio C Hamano @ 2009-01-16 1:09 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Sverre Rabbelier, Anders Melchiorsen, git, Johannes.Schindelin
In-Reply-To: <20090115225912.GL9794@neumann>
SZEDER Gábor <szeder@ira.uka.de> writes:
> But the current behaviour of the 'edit' rebase command gives you the
> possibility of adding further commits on top of the selected one
> (after you have edited that or left intact, doesn't matter). To do
> that with this automatic 'reset --soft HEAD^' modification you would
> first need to 'git commit -c @{1}' to keep the selected commit before
> going on with adding further commits, which is not quite nice.
Yeah, I agree.
I think my confusion mostly came from perception, and the way the "edit"
action is (not) explained.
What "edit" means is "pick this commit and then stop to give control back
to the user. The user is free to muck with the history starting from the
state after picking the named commit in any way, and --continue will carry
on the rest of the insns from the state" [*1*]. Once I realize that,
it becomes clear what it means to do any of the following when "edit"
gives the control back to me:
(1) commit --amend (with or without changing the tree and message); this
is the originally intended usage. Edit the commit the machinery just
picked and let it continue. The end result is as if you edited one
commit in the sequence.
(2) making completely unrelated commits on top of the state "edit" gave
you; this inserts a new commit in the sequence.
(3) first "reset HEAD^", commit selected parts of the difference in one
commit, commit the reaminder in another commit; this splits the
commit the machinery just picked into two.
By the way, "rebase --continue" codepath has extra code that does
something magical when the index does not match the HEAD commit. I
suspect what it does makes sense only in the originally intended usage
sequence (i.e. "edit" stops, you want to do "commit --amend" and then
"rebase --continue" but somehow you forgot to commit everything).
How well does that logic work when the user wanted to do (2) or (3) above,
and happened to have the index unclean when s/he said "rebase --continue"?
Does it do something nonsensical?
[Footnote]
*1* Explained the same way, "pick" is "cherry-pick the named commit to
replay its effect and then continue".
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johannes Schindelin @ 2009-01-16 1:34 UTC (permalink / raw)
To: Björn Steinbrink
Cc: SZEDER Gábor, Sverre Rabbelier, Junio C Hamano,
Anders Melchiorsen, git
In-Reply-To: <20090116001139.GA26357@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 358 bytes --]
Hi,
On Fri, 16 Jan 2009, Björn Steinbrink wrote:
> A bit off-topic: The "auto-amend" code path passes --no-verify to git
> commit. What's the reason for doing that? I actually always expected
> that to use my pre-commit hook to stop me from committing crap. :-/
IIRC people requested that rebase commits their crap without complaining
:-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Junio C Hamano @ 2009-01-16 1:37 UTC (permalink / raw)
To: Santi Béjar; +Cc: Johannes Schindelin, Teemu Likonen, Thomas Rast, git
In-Reply-To: <adf1fd3d0901151610p41930ee2gfc7259aee7e15d73@mail.gmail.com>
Santi Béjar <santi@agolina.net> writes:
> It may be ok and logical, but for me it is not what I want. Mmaybe I
> don't really undestand what I want or is a crazy idea but here it is
> anyway:
>
> Take a simple case with this two lines :
>
> matrix[a,b,c]
> matrix{d,b,c}
>
> there is no space so the standard color-words does not help to
> visualize that matrix, the b and c are not changed.
>
> What I currently do is to add some spaces:
>
> matrix[ a, b, c ]
> matrix{ d, b, c }
>
> then the color-words at least says that "b, c" is unchanged.
>
> What I would like is that --color-words would act as adding this
> spaces automatically (and even one after "matrix").
>
> Or another way to think it could be:
>
> a) primary words are those with alphanumerics (or a regex)
> b) secondary "words" are the other non-whitespaces characters (in this
> case "[]{} and ,"
> c) whitespaces are cruft.
Dscho and Thomas discussed and designed a way to mark "words look like
this" (and anything that are not words are crufts), and Dscho further
argues that it is Ok to discard crufts (which I think is fine).
What you seem to want in this example is "there is no cruft other than
whitespace, but there are different kinds of words". I do not think it is
incompatible with the way crufts are discarded, but it may be incompatible
with the way how words are identified.
I would expect something like:
[a-zA-Z0-9]+|[^ a-zA-Z0-9]+
should define your "two kinds of words". That is, a run of alnums is a
word, and a run of non-alnums is a word, but "matrix[a" is not a word (it
is a sequence of three words "matrix", "[" and "a").
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Boyd Stephen Smith Jr. @ 2009-01-16 1:42 UTC (permalink / raw)
To: Santi Béjar
Cc: Johannes Schindelin, Junio C Hamano, Teemu Likonen, Thomas Rast,
git
In-Reply-To: <adf1fd3d0901151610p41930ee2gfc7259aee7e15d73@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]
On Thursday 15 January 2009, Santi Béjar <santi@agolina.net> wrote
about 'Re: [PATCH take 3 0/4] color-words improvements':
>It may be ok and logical, but for me it is not what I want. Mmaybe I
>don't really undestand what I want or is a crazy idea but here it is
>anyway:
The discussion above is mildly theoretical. I don't imagine someone is
going to intentionally mark 98% of a file as non-words, which is basically
what you are doing with a regex of "a+".
>a) primary words are those with alphanumerics (or a regex)
regex: [[:alnum:]]+
example words: matrix ball I a
example non-words: don't haven't
>b) secondary "words" are the other non-whitespaces characters (in this
>case "[]{} and ,"
regex: []{}[,]
example words: [ , }
example non-words: [] ball 147
>c) whitespaces are cruft.
>
>(having two regexp to specify what is a words but they cannot mix).
Combine regex with '|' to get:
[[:alnum:]]+|[]{}[,]
>If everything works as I think (it's late night :-) with the above two
> lines:
>
>matrix[a,b,c]
>matrix{d,b,c}
>
>the word diff would be
>
>matrix<RED>[<GREEN>{<RED>a<GREEN>d<RESET>,b,c<RED>]<GREEN>}<RED>
For this specific case, the regex "[^[:space:]]" by itself should work,
although it would end up being a character-by-character diff.
The regex you built from your description "[[:alnum:]]+|[]}{[,]" would also
give the same diff. However:
-dont
+don't
gives a word diff of:
don't
not:
don<RED>'<RESET>t
because "'" is not recognized as part of any word it is considered
ignorable.
There was a patch that included documentation that most users should add
"|[^[:space:]]" to the end of their regex, to capture all non-whitespace
characters that are not otherwise part of a word as individual,
single-character "words".
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: cygwin git diff crash
From: Johannes Schindelin @ 2009-01-16 1:47 UTC (permalink / raw)
To: Jeremy Ramer; +Cc: Git Mailing List
In-Reply-To: <b9fd99020901151308u3e901602ya66f170da2b37045@mail.gmail.com>
Hi,
On Thu, 15 Jan 2009, Jeremy Ramer wrote:
> Well, after compiling from source the error seems to have disappeared.
> Strange. I have seen it disappear before and come back later so I will
> watch out for it, but for now it's not an issue.
Well, at least it is gone for now.
> Just a note, the cygwin names for the packages necessary to compile are
> curl-devel
> gcc
> libiconv
> make
> openssl-devel
Thanks,
Dscho
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: Junio C Hamano @ 2009-01-16 1:52 UTC (permalink / raw)
To: George Spelvin; +Cc: git
In-Reply-To: <20090115222905.8157.qmail@science.horizon.com>
"George Spelvin" <linux@horizon.com> writes:
> Could someone fix this some day?
As far as I know you are the first to ask for this, so perhaps people never
considered this was something to "fix"....
> "git grep <pattern> ../include"
> is something I find myself wanting quite frequently, and it's a fresh
> annoyance every time I type it to discover that it still doesn't work.
>
> While you're at it, an option to search the entire git tree rather than
> the current subdirectory would also be useful. I was thinking about
> a flag like -r (for "root"),...
... but
$ grep -r foo ..
will look for foo anywhere below one level up from your current directory,
and I think it may be a reasonable enhancement to teach:
$ git grep foo ..
to do the same. Patches welcome ;-).
By the way, congratulations for getting a name. Can we fix one entry in
our .mailmap file?
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Johannes Schindelin @ 2009-01-16 1:55 UTC (permalink / raw)
To: Santi Béjar; +Cc: Junio C Hamano, Teemu Likonen, Thomas Rast, git
In-Reply-To: <adf1fd3d0901151610p41930ee2gfc7259aee7e15d73@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 445 bytes --]
Hi,
On Fri, 16 Jan 2009, Santi Béjar wrote:
> If everything works as I think (it's late night :-) with the above two lines:
>
> matrix[a,b,c]
> matrix{d,b,c}
>
> the word diff would be
>
> matrix<RED>[<GREEN>{<RED>a<GREEN>d<RESET>,b,c<RED>]<GREEN>}<RED>
So I guess that you want something like
[A-Za-z0-9]+|[^A-Za-z0-9 \t]+
Note: I only want to help you finding what you actually want, I am not
trying to find it for you.
Ciao,
Dscho
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Petr Baudis @ 2009-01-16 1:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901151651460.3586@pacific.mpi-cbg.de>
Hi,
On Thu, Jan 15, 2009 at 04:53:48PM +0100, Johannes Schindelin wrote:
> sorry to bother you between two games of Go; Could you have a look at the
> 'mail' link with the commit "Update 1.6.2 draft release notes"? It is not
> working for me...
>
> That is, it links to marc (not gmane?) but finds no matches...
what mailing list post should it point to?
Petr "Pasky" Baudis
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Junio C Hamano @ 2009-01-16 1:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
In-Reply-To: <20090116015439.GF12275@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> That is, it links to marc (not gmane?) but finds no matches...
>
> what mailing list post should it point to?
I think Dscho's point is that you shouldn't be generating these links that
lead to nowhere ;-).
It would really be nice if we can maintain an exterenal database that
links mailing list discussion threads and individual commits, and have
gitweb and other visualization tools to make use of that information.
I do not care what storage mechanism that external database uses. It
could use notes or it could just be a BDB that can be indexed with commit
object names.
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: Johannes Schindelin @ 2009-01-16 2:07 UTC (permalink / raw)
To: George Spelvin; +Cc: git
In-Reply-To: <20090115222905.8157.qmail@science.horizon.com>
Hi,
On Thu, 15 Jan 2009, George Spelvin wrote:
> Could someone fix this some day?
Yes, someone could.
Ciao,
Dscho
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: Junio C Hamano @ 2009-01-16 2:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: George Spelvin, git
In-Reply-To: <alpine.DEB.1.00.0901160307290.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 15 Jan 2009, George Spelvin wrote:
>
>> Could someone fix this some day?
>
> Yes, someone could.
Or perhaps someone did more than two years ago with --full-name?
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Johannes Schindelin @ 2009-01-16 2:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vmydsovs5.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 15 Jan 2009, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> >> That is, it links to marc (not gmane?) but finds no matches...
> >
> > what mailing list post should it point to?
I found gmane to be much nicer to click through than marc.
> I think Dscho's point is that you shouldn't be generating these links
> that lead to nowhere ;-).
Almost.
I wondered what the point was, and I would _welcome_ links that pointed to
the mails containing the patches (identified either by patch ids or by
manual editing; best would be to have both methods at the same time).
Ciao,
Dscho
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Petr Baudis @ 2009-01-16 2:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901160315170.3586@pacific.mpi-cbg.de>
On Fri, Jan 16, 2009 at 03:17:14AM +0100, Johannes Schindelin wrote:
> On Thu, 15 Jan 2009, Junio C Hamano wrote:
>
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > >> That is, it links to marc (not gmane?) but finds no matches...
> > >
> > > what mailing list post should it point to?
>
> I found gmane to be much nicer to click through than marc.
IIRC I found no way to actually make a gmane link since it requires POST
query for the searches or something.
> > I think Dscho's point is that you shouldn't be generating these links
> > that lead to nowhere ;-).
>
> Almost.
>
> I wondered what the point was, and I would _welcome_ links that pointed to
> the mails containing the patches (identified either by patch ids or by
> manual editing; best would be to have both methods at the same time).
Well, but you already have that, or at least an approximation. Do you
think the approximation is inadequate? I would expect linking to a
commit showing the inadequacy - I don't see how a false positive is
inadequate at all, actually; even if we had a separate database with the
mapping, for no records I think falling back to linking to a mailing
list search still makes more sense than showing no link.
I was not actually planning to carry the patch over the next gitweb
update since I got no feedback on it (IIRC) since I implemented it.
--
Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Jacob Helwig @ 2009-01-16 2:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20090116022408.GG12275@machine.or.cz>
On Thu, Jan 15, 2009 at 18:24, Petr Baudis <pasky@suse.cz> wrote:
>
> IIRC I found no way to actually make a gmane link since it requires POST
> query for the searches or something.
>
$ cat bin/gmane-links.pl
#!/usr/bin/perl
use strict;
use warnings;
use Mail::Summary::Tools::ArchiveLink::Gmane;
unless ($ARGV[0]) {
print STDERR "Must provide a message-id.\n";
exit 1;
}
my $link = Mail::Summary::Tools::ArchiveLink::Gmane->new(message_id =>
$ARGV[0]);
print "Thread: " . $link->thread_uri() . "\n";
print "Message: " . $link->message_uri() . "\n";
^ permalink raw reply
* How to exclude some files when using git-archive?
From: Ping Yin @ 2009-01-16 2:40 UTC (permalink / raw)
To: Git Mailing List
I want to exclude .gitignore from the archive, but hasn't find a easy way
Ping Yin
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Junio C Hamano @ 2009-01-16 2:41 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Petr Baudis, Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <8c9a060901151832l71464185qf9f88afede6f550d@mail.gmail.com>
"Jacob Helwig" <jacob.helwig@gmail.com> writes:
> On Thu, Jan 15, 2009 at 18:24, Petr Baudis <pasky@suse.cz> wrote:
>>
>> IIRC I found no way to actually make a gmane link since it requires POST
>> query for the searches or something.
>>
>
> $ cat bin/gmane-links.pl
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use Mail::Summary::Tools::ArchiveLink::Gmane;
>
> unless ($ARGV[0]) {
> print STDERR "Must provide a message-id.\n";
> exit 1;
> }
>
> my $link = Mail::Summary::Tools::ArchiveLink::Gmane->new(message_id =>
> $ARGV[0]);
>
> print "Thread: " . $link->thread_uri() . "\n";
> print "Message: " . $link->message_uri() . "\n";
Not quite, if message_id means what I think it means.
Pasky searches for the title of the message, and he does not have the
Message-ID header of the original message.
^ permalink raw reply
* Re: 'mail' link on http://repo.or.cz/w/git.git no workee?
From: Junio C Hamano @ 2009-01-16 2:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
In-Reply-To: <20090116022408.GG12275@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I was not actually planning to carry the patch over the next gitweb
> update since I got no feedback on it (IIRC) since I implemented it.
Heh, now you got it.
And I do not think you advertised it since you implemented it, so no
feedback does not necessarily mean no interest. FWIW, I think looking for
a message that has similar words in the mail archive is a nifty feature to
have.
^ permalink raw reply
* Re: How to exclude some files when using git-archive?
From: Junio C Hamano @ 2009-01-16 2:44 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320901151840l18257501x62a3fa1fe9701dc@mail.gmail.com>
Ping Yin <pkufranky@gmail.com> writes:
> I want to exclude .gitignore from the archive, but hasn't find a easy way
>
> Ping Yin
"man gitattributes", then look for export-ignore?
^ permalink raw reply
* Re: [PATCH 3/3] implement pattern matching in ce_path_match
From: Junio C Hamano @ 2009-01-16 2:51 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, johannes
In-Reply-To: <7vljtd20m6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Clemens Buchacher <drizzd@aon.at> writes:
>
>> With this patch ce_path_match uses match_pathspec in order to perform
>> pattern matching.
>
> We have two conflicting definitions of pattern matching in our system.
> I'd make it more explicit which kind of pattern matching you are talking
> about here.
>
> The family of operations based on the diff-tree machinery (e.g. path
> limited revision walking "git log A..B -- dir1/dir2") define the pattern
> matching as "leading path match (exact match is just a special case of
> this)". Other operations that work on paths in the work tree and the
> index (e.g. grep, ls-files) uses "leading path match, but fall back to
> globbing".
>
> In the longer term we really should unify them by teaching the former to
> fall back to globbing without getting undue performance hit, and this
> patch may be a step in the right direction. There are optimizations that
> assume the "leading path" semantics to trim the input early and avoid
> opening and descending into a tree object if pathspec patterns cannot
> possibly match (see tree-diff.c::tree_entry_interesting() for an example),
> and we need to teach them to notice a glob wildcard in an earlier part of
> a pathspec and to descend into some trees that they would have skipped
> with the old definition of pathspec.
Actually there was an earlier attempt that resulted in the pathspec
matching tree traverser builtin-grep uses. Even though it has to work
with trees (when grepping inside a tree-ish) and has optimizations not to
open unnecessary subtrees similar to the one the diff-tree machinery has,
it also knows how to handle globs. If we were to pick one of existing
implementations for the longer term unification, I think that is probably
the one we should build on top of.
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: George Spelvin @ 2009-01-16 3:27 UTC (permalink / raw)
To: Johannes.Schindelin, gitster; +Cc: linux, git
In-Reply-To: <7vhc40ov78.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Or perhaps someone did more than two years ago with --full-name?
Thank you for pointing that out! It's a bit of a handful to type,
but at least it makes what I want to do possible without having to
write a wrapper script. And I can reduce the typing with an alias.
I'm still trying to figure out why the basic form doesn't work,
though. Is there something more subtle than that fact that the
filename simplification in grep_sha1 and grep_file might do the
wrong thing? If I comment out the check in cmd_grep(), it seems
to work, although it prints out some funky filenames.
That seems like a straightforward thing to fix. Basically, strip
off the common part of the prefix and name, and for every remaining
component in the prefix, prepend a ../ to the name.
I don't mind doing the coding, but can someone who groks the
code more fully tell me if I'm missing something major?
^ permalink raw reply
* how to edit commit message in history
From: bill lam @ 2009-01-16 3:57 UTC (permalink / raw)
To: git
I made some typos in commit messages, how to edit them without
affecting everything else?
Thanks in advance.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩311 無名氏 雜詩
盡寒食雨草萋萋 著麥苗風柳映堤 等是有家歸未得 杜鵑休向耳邊啼
^ permalink raw reply
* Re: how to edit commit message in history
From: Jike Song @ 2009-01-16 4:09 UTC (permalink / raw)
To: git
In-Reply-To: <20090116035714.GA6984@b2j>
On Fri, Jan 16, 2009 at 11:57 AM, bill lam <cbill.lam@gmail.com> wrote:
> I made some typos in commit messages, how to edit them without
> affecting everything else?
>
> Thanks in advance.
say, it's commit HEAD~2 to be revised.
git rebase -i HEAD~3
In your editor, you all see something like this:
pick db79377 2nd
pick fa9ced8 3rd
pick b842e49 4nd
# Rebase 1423d77..b842e49 onto 1423d77
#
# Commands:
# p, pick = use commit
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
Now change "pick" to "edit" with your typo commit, save it and exit.
You will see something like this:
$ git-rebase -i HEAD~3
Stopped at db79377... 2nd
You can amend the commit now, with
git commit --amend
Once you are satisfied with your changes, run
git rebase --continue
Just follow the instructions.
--
Thanks,
Jike
^ permalink raw reply
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