* mistake in Release Notes for 1.6.2
From: Markus Heidelberg @ 2009-01-15 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hello Junio,
Documentation/RelNotes-1.6.2.txt:
> * git-cherry defaults to HEAD when the <upstream> argument is not given.
This is not correct, see commit f2968022 (2008-12-29):
git-cherry: make <upstream> parameter optional
The upstream branch <upstream> now defaults to the first tracked
remote branch, which is set by the configuration variables
branch.<name>.remote and branch.<name>.merge of the current branch.
Without such a remote branch, the command "git cherry [-v]" fails with
usage output as before and an additional message.
I guess it's a mistake in hurry, not every default value is HEAD :)
Markus
^ permalink raw reply
* Re: [BUG] assertion failure in builtin-mv.c with "git mv -k"
From: Junio C Hamano @ 2009-01-15 22:19 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Johannes Schindelin, Matthieu Moy, git
In-Reply-To: <496F15B4.2040104@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> I'm happy to follow any variant ("1+2+3", "1 2+3", "1 2 3", in
> increasing order of preference) so there's no need to discuss or explain
> this further, just tell me "do x" ;)
Do nothing ;-) Your 1=3772923 and 2+3=be17262d are already in and we can
include the fix in the next 1.6.1.X maintenance release.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Sverre Rabbelier @ 2009-01-15 22:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: SZEDER Gábor, Anders Melchiorsen, git, Johannes.Schindelin
In-Reply-To: <7vvdsgql17.fsf@gitster.siamese.dyndns.org>
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."
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [StGit PATCH] Check for local changes with "goto"
From: Catalin Marinas @ 2009-01-15 22:24 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20090115083700.GB24890@diana.vm.bytemark.co.uk>
2009/1/15 Karl Hasselström <kha@treskal.com>:
> I'm not opposed to the change as such (even if I personally think it's
> very convenient to allow operations like goto if the local changes
> don't touch the same files), but ...
That would work if "refresh" only commits files previously added to
the patch (the same way as quilt). I found myself many times moving to
another patch and refreshing more than I wanted to add to that patch
because I forgot to run "status" before "goto".
Maybe we can make this configurable to accommodate both variants
(would be even easier if I move the check to transaction.py).
> On 2009-01-14 22:59:45 +0000, Catalin Marinas wrote:
>
>> stgit/commands/common.py | 7 +++++++
>> stgit/commands/goto.py | 8 +++++++-
>
> ... are you sure it wouldn't be better to build the check into
> transaction.py, so that all new-infrastructure command would share it?
OK, I'll do this and repost.
--
Catalin
^ permalink raw reply
* Re: git-difftool
From: Markus Heidelberg @ 2009-01-15 22:26 UTC (permalink / raw)
To: David Aguilar; +Cc: Matthieu Moy, git
In-Reply-To: <402731c90901020939k1a8ae795oc4cbfd0ced992aab@mail.gmail.com>
David Aguilar, 02.01.2009:
> I now have a git-difftool wrapper script that basically just sets up
> the environment for git-difftool-helper. git-difftool-helper does all
> of the merge tool configuration stuff ala
> http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html (it
> uses the same git config variables and thus works with existing custom
> commands). If you drop them both into the same directory it should
> work as-is (it munges $PATH).
>
> It's not a two-liner (they do all that git config stuff and handle
> more than just vimdiff) but it does use GIT_EXTERNAL_DIFF now, which
> makes the script infinitely more useful. This is much nicer now since
> you can pass any 'git diff' options to git-difftool and it'll handle
> it correctly.
>
> The usage is simpler now too:
>
> usage: git difftool [--no-prompt] [--tool=tool] ["git diff" options]
Now isn't this something for contrib, David?
Markus
^ permalink raw reply
* fatal: git grep: cannot generate relative filenames containing '..'
From: George Spelvin @ 2009-01-15 22:29 UTC (permalink / raw)
To: git
Could someone fix this some day? "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 a second idea dawned on me: interpret
absolute pathnames as relative to the root of the repository. So I could
"git grep <pattern> /" or "git grep <pattern> /include" from any subdirectory.
As it is currently, absolute pathnames don't work very well either...
[1]$ git grep xyzzy $PWD
fatal: '/home/linux/project/src' is outside repository
[2]$ cd /usr/src/linux
[3]$ git grep xyzzy $PWD
CREDITS:E: rjd@xyzzy.clara.co.uk
drivers/hwmon/hwmon-vid.c: * With assistance from Trent Piepho <xyzzy@speakeasy.
drivers/infiniband/hw/ipath/ipath_debug.h: * if(infinipath_debug & _IPATH_xyzzy)
drivers/media/dvb/frontends/or51132.c: * Copyright (C) 2007 Trent Piepho <xyz
drivers/media/video/cx88/cx88-alsa.c: * (c) 2007 Trent Piepho <xyzzy@speakeas
drivers/video/intelfb/intelfbhw.c: /* do some funky magic - xyzzy */
include/linux/byteorder/swab.h: * Trent Piepho <xyzzy@speakeasy.org> 2007114
include/linux/hwmon-vid.h: With assistance from Trent Piepho <xyzzy@speakeasy
[4]$ cd include
[5]$ git grep xyzzy $PWD
fatal: git grep: cannot generate relative filenames containing '..'
I don't quite understand that last error message.
Thank you.
^ permalink raw reply
* Re: [PATCH 3/3] Adds a #!bash to the top of bash completions so that editors can recognize, it as a bash script. Also adds a few simple comments above commands that, take arguments. The comments are meant to remind editors of potential, problems that can occur when the script is sourced on systems with "set, -u."
From: Markus Heidelberg @ 2009-01-15 22:56 UTC (permalink / raw)
To: Adeodato Simó
Cc: Boyd Stephen Smith Jr., Shawn O. Pearce, Ted Pavlic, git,
Junio C Hamano
In-Reply-To: <20090113201024.GA20129@chistera.yi.org>
Adeodato Simó, 13.01.2009:
> * Boyd Stephen Smith Jr. [Tue, 13 Jan 2009 14:03:11 -0600]:
>
> > On Tuesday 2009 January 13 10:45:18 Shawn O. Pearce wrote:
> > >See [...] how the subject is a niceshort, one
> > >line summary of the module impacted and the change?
>
> > My rule for this is absolutely no more than 80 characters.
>
> My rule for *all* of the commit message is "absolutely no more than 76
> characters". With more than 76, `git log` wraps in a 80-column terminal.
What about the 50 character limit proposed in the documentation
(git-commit, gittutorial, user-manual)?
At the beginning I tried to fulfil this limit, but often it's not easy.
So should it be adjusted to a slightly higher value in the documentation
or even split into a recommended limit (e.g. 50) and a recommended
absolute maximum (e.g. 76)? Hmm, the split wouldn't make sense, I think.
Markus
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: SZEDER Gábor @ 2009-01-15 22:59 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, SZEDER Gábor, Anders Melchiorsen, git,
Johannes.Schindelin
In-Reply-To: <bd6139dc0901151420j4ae62433uc0cc70d86dc45cfa@mail.gmail.com>
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...
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.
Regards,
Gábor
^ permalink raw reply
* Re: [PATCH 1/2] Move run_hook() from builtin-commit.c into run-command.c (libgit)
From: Junio C Hamano @ 2009-01-15 22:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Stephan Beyer, git, Paolo Bonzini, Miklos Vajna, Shawn O. Pearce,
Daniel Barkalow, Christian Couder, gitster
In-Reply-To: <alpine.DEB.1.00.0901151637590.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 15 Jan 2009, Stephan Beyer wrote:
>
>> Stripping out a libified version seemed better to me than
>> copy and paste.
>
> Oh, definitely.
>
>> - ret = start_command(&hook);
>> - if (ret) {
>> - warning("Could not spawn %s", argv[0]);
>> - return ret;
>> - }
>> - ret = finish_command(&hook);
>> - if (ret == -ERR_RUN_COMMAND_WAITPID_SIGNAL)
>> - warning("%s exited due to uncaught signal", argv[0]);
>
> What are the side effects of replacing this with "ret =
> run_command(&hook);"? This has to be discussed and defended in the commit
> message.
I think the answer is "Lost warnings here and there".
^ permalink raw reply
* Re: fatal: git grep: cannot generate relative filenames containing '..'
From: Markus Heidelberg @ 2009-01-15 23:04 UTC (permalink / raw)
To: George Spelvin; +Cc: git
In-Reply-To: <20090115222905.8157.qmail@science.horizon.com>
George Spelvin, 15.01.2009:
> 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 a second idea dawned on me: interpret
> absolute pathnames as relative to the root of the repository. So I could
> "git grep <pattern> /" or "git grep <pattern> /include" from any subdirectory.
I have never used submodules execpt for trying out, but I think it would
ambigous when calling this command from inside a submodule. It's not
clear, whether the main repo or the submodule should be used.
Markus
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Markus Heidelberg @ 2009-01-15 23:09 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901141033p47b4d8dah46f5bac27307d306@mail.gmail.com>
skillzero@gmail.com, 14.01.2009:
> On Wed, Jan 14, 2009 at 12:34 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>
> > After you created the fixup, you have this situation:
> >
> > o--o--o <- A (feature branch)
> > /
> > --o--x <- X (the fix-up branch)
> > \
> > o--o--o <- Z (probably your master)
> >
> > You merge the fix-up into the feature branch and continue developing the
> > feature:
> >
> > o--o--o--M--o--o <- A
> > / /
> > --o--x-----' <- X
> > \
> > o--o--o <- Z
> >
> > Other people need the fix in Z right now, so you merge it into Z as well:
> >
> > o--o--o--M--o--o <- A
> > / /
> > --o--x-----< <- X
> > \ \
> > o--o--o--N <- Z
> >
> > You complete your feature and merge it into Z:
> >
> > o--o--o--M--o--o <- A
> > / / \
> > --o--x-----< \ <- X
> > \ \ \
> > o--o--o--N---------O <- Z
> >
> > The fix-up commit is only once in your history.
>
> Thanks for the info. That's what I was hoping, but I was thinking that
> I'd get duplicate commits if I did that. I'll have to try it out when
> I run into this situation again.
Note, that you'd get 2 merge commits for this fix-up commit into branch Z.
The first from merging X into Z, the second is created from merging X
into A and occures in Z when merging A into it.
Markus
^ permalink raw reply
* 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
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