* Re: git-1.6.2-rc2 problems on t4034-diff-words.sh
From: Johannes Schindelin @ 2009-02-27 19:43 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Git List
In-Reply-To: <alpine.LNX.2.00.0902271216090.19082@suse104.zenez.com>
Hi,
On Fri, 27 Feb 2009, Boyd Lynn Gerber wrote:
> On Fri, 27 Feb 2009, Johannes Schindelin wrote:
>
> > But as I did not forget your kind words, I'll try to help.
> >
> > > * FAIL 6: use regex supplied by driver
> > >
> > >
> > > word_diff --color-words
>
> Does the test suite use bash as it's shell? I seem to have to use bash
> now to run the test. I do not remember having to use bash on earlier
> 1.6.0
No, bash should not be required.
> > It might be a regex related issue. Could you
> >
> > - run the test with -i -v (and if that does not help, "sh -x t...")?
>
> I have to use bash to run the test or I get
>
> $ ./t4034-diff-words.sh
> ./t4034-diff-words.sh: syntax error at line 52: `(' unexpected
Could you tell me what your version of t4034 has at line 52? Mine does
not have a single parenthesis on that line.
> But if I run
>
> $ bash ./t4034-diff-words.sh
> * ok 1: setup
> * ok 2: word diff with runs of whitespace
> * ok 3: word diff with a regular expression
> * ok 4: set a diff driver
> * ok 5: option overrides .gitattributes
> * FAIL 6: use regex supplied by driver
>
>
> word_diff --color-words
Could you run it again after appending "-i -v" to the command line?
Ciao,
Dscho
^ permalink raw reply
* Re: [WARNING] Proposed future changes that are backward incompatible
From: Johannes Schindelin @ 2009-02-27 19:48 UTC (permalink / raw)
To: George Spelvin; +Cc: git, gitster
In-Reply-To: <20090227192708.6266.qmail@science.horizon.com>
Hi,
On Fri, 27 Feb 2009, George Spelvin wrote:
> There's one more change that was suggested that I'd like to propose:
> - Make "git grep" search the whole repository by default; include an
> explicit "." path limiter to search only the current directory.
I use "git grep" in subdirectories extensively, and I like that it does
_not_ search the whole repository.
Could you suggest a nice way for me to retain that behavior with an
option?
After all, since you propose a change in behavior, it is _your_ duty to
provide ways for those who want the old behavior to get at it easily!
In the alternative, I could suggest "git grep -e <expression> HEAD".
Ciao,
Dscho
^ permalink raw reply
* Re: [WARNING] Proposed future changes that are backward incompatible
From: Sverre Rabbelier @ 2009-02-27 19:51 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: George Spelvin, git, gitster
In-Reply-To: <alpine.LFD.2.00.0902271439310.5511@xanadu.home>
On Fri, Feb 27, 2009 at 20:42, Nicolas Pitre <nico@cam.org> wrote:
> [nico@xanadu git]$ git grep Alice
Now try again from within a subdir ;).
I actually prefer the current behavior, and am a very extensive user
of it. Config option? ;)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [WARNING] Proposed future changes that are backward incompatible
From: Junio C Hamano @ 2009-02-27 19:59 UTC (permalink / raw)
To: George Spelvin; +Cc: git
In-Reply-To: <20090227192708.6266.qmail@science.horizon.com>
"George Spelvin" <linux@horizon.com> writes:
> There's one more change that was suggested that I'd like to propose:
> - Make "git grep" search the whole repository by default; include an
> explicit "." path limiter to search only the current directory.
>
> In addition to being more consistent with other commands like "git log",
> this saves a lot of typing working in drivers/net/usb/ if the identifier
> you're looking for is in include/. Typing the additional space-dot
> is pretty trivial if you want the current directory only.
I do not remember it was ever suggested, let alone coming to anything near
consensus.
The only way you could justify such a default change is to say:
Almost all the time, everybody wants to use this new behaviour; the
old behaviour is almost never useful in any situation other than a
narrow corner case; and if somebody wants to do such a useless thing
in a corner case, he can always add " ." at the end, so nothing is
lost.
I do not think that is true for the change you are proposing here. 'He
can always add " ." at the end' alone is not a good enough justification.
I however think your use case deserves to be supported, and I would not
mind at all accepting a new "--full-tree" (or some shorter synonym) option
if the patch is cleanly done (hint, hint).
I'd rather not add this to "future changes that are backward incompatible"
list. It may be a useful new feature, but that is not what the topic of
this thread is about.
^ permalink raw reply
* Re: git-1.6.2-rc2 problems on t4034-diff-words.sh
From: Junio C Hamano @ 2009-02-27 20:05 UTC (permalink / raw)
To: Boyd Lynn Gerber; +Cc: Johannes Schindelin, Git List
In-Reply-To: <alpine.LNX.2.00.0902271216090.19082@suse104.zenez.com>
Boyd Lynn Gerber <gerberb@zenez.com> writes:
> Does the test suite use bash as it's shell? I seem to have to use
> bash now to run the test. I do not remember having to use bash on
> earlier 1.6.0
If your /bin/sh is not POSIX enough, you may be using a different shell
when building the scripted commands in the main Makefile by setting
SHELL_PATH. The tests are supposed to use the same one as that.
> I have to use bash to run the test or I get
>
> $ ./t4034-diff-words.sh
> ./t4034-diff-words.sh: syntax error at line 52: `(' unexpected
The open parenthesis on line 52 is the one between h and 4 here:
cat > expect <<\EOF
<WHITE>diff --git a/pre b/post<RESET>
<WHITE>index 330b04f..5ed8eff 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
<BROWN>@@ -1,3 +1,7 @@<RESET>
<RED>h(4)<RESET><GREEN>h(4),hh[44]<RESET>
<RESET>
a = b + c<RESET>
<GREEN>aa = a<RESET>
<GREEN>aeff = aeff * ( aaa )<RESET>
EOF
Perhaps your shell has a broken here-text?
^ permalink raw reply
* Re: [WARNING] Proposed future changes that are backward incompatible
From: George Spelvin @ 2009-02-27 20:31 UTC (permalink / raw)
To: linux, gitster; +Cc: git
In-Reply-To: <7v3adzk5wb.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "George Spelvin" <linux@horizon.com> writes:
>
> > There's one more change that was suggested that I'd like to propose:
> > - Make "git grep" search the whole repository by default; include an
> > explicit "." path limiter to search only the current directory.
> >
> > In addition to being more consistent with other commands like "git log",
> > this saves a lot of typing working in drivers/net/usb/ if the identifier
> > you're looking for is in include/. Typing the additional space-dot
> > is pretty trivial if you want the current directory only.
>
> I do not remember it was ever suggested, let alone coming to anything near
> consensus.
The suggestion was in <83vdsefz9j.fsf@kalahari.s2.org>, available as
http://marc.info/?l=git&m=123216049508531
but I agree that there was no consensus. I just thought this thread was
a good place to elicit discussion, since it would be an incompatible change.
> The only way you could justify such a default change is to say:
>
> Almost all the time, everybody wants to use this new behaviour; the
> old behaviour is almost never useful in any situation other than a
> narrow corner case; and if somebody wants to do such a useless thing
> in a corner case, he can always add " ." at the end, so nothing is
> lost.
>
> I do not think that is true for the change you are proposing here. 'He
> can always add " ." at the end' alone is not a good enough justification.
Please forgive me, I thought the above *might* be true, and wanted
to provoke discussion to see how people felt. The "consistent with
git-log and all that stuff" argument is quite persuasive to me, but it's
a convenience feature, so it depends on how people feel.
> I however think your use case deserves to be supported, and I would not
> mind at all accepting a new "--full-tree" (or some shorter synonym) option
> if the patch is cleanly done (hint, hint).
Hint taken. Half of the patch is available at
http://marc.info/?l=git&m=123207990016944
Is -t/--full-tree okay? I'd rather use -a/--all, but that's taken. -t
isn't used by grep(1) either.
> I'd rather not add this to "future changes that are backward incompatible"
> list. It may be a useful new feature, but that is not what the topic of
> this thread is about.
Sorry for veering off on an inappropriate tangent.
^ permalink raw reply
* git-svn woes
From: Nicolas Pitre @ 2009-02-27 20:37 UTC (permalink / raw)
To: git; +Cc: Eric Wong
OK... I cannot pretend to be a newbie with git. However it's the first
time I try git-svn and it looks like a couple basic things aren't right.
I initially cloned svn://svn.berlios.de/openocd using "git svn clone -s".
So far so good. Now I'm attempting to update using "git svn fetch" but
the operation always fails with the following error:
|branch_from: /openocd/branches => /openocd/branches/xscale
|Found possible branch point:
|svn://svn.berlios.de/openocd/openocd/branches/xscale =>
|svn://svn.berlios.de/openocd/branches/xscale, 1231
|Initializing parent: xscale@1231
|Found branch parent: (xscale) 657522f3f2d1ab8b679fd5b45ce4e9ca1974af18
|Following parent with do_switch
|Scanning for empty symlinks, this may take a while if you have many empty files
|You may disable this with `git config svn.brokenSymlinkWorkaround false'.
|This may be done in a different terminal without restarting git svn
|Malformed network data: Malformed network data at /home/nico/libexec/git-core/git-svn line 3333
Thing is... the repository never gets updated and by far. According to
"git svn info", the fetched revision is 1232, while a separate
repository using native svn claims to be at revision 1383.
Furthermore, the "git svn info" command produces yet more errors, such
as:
|Use of uninitialized value $lc_author in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 964.
|Use of uninitialized value $lc_rev in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 965.
|Use of uninitialized value $t in gmtime at /home/nico/libexec/git-core/git-svn line 4743.
|Use of uninitialized value $t in numeric comparison (<=>) at /home/nico/libexec/git-core/git-svn line 4744.
|Use of uninitialized value $t in subtraction (-) at /home/nico/libexec/git-core/git-svn line 4745.
|Use of uninitialized value $t in localtime at /home/nico/libexec/git-core/git-svn line 4746.
This is with git from current "next". I cannot spend time to try fixing
the issue myself (especially as I'm not familiar at all with the inner
workings of svn), so my only option at the moment is to give up on
git-svn altogether. :-(
Nicolas
^ permalink raw reply
* Re: git-1.6.2-rc2 problems on t4034-diff-words.sh
From: Boyd Lynn Gerber @ 2009-02-27 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git List
In-Reply-To: <7vwsbbir1j.fsf@gitster.siamese.dyndns.org>
On Fri, 27 Feb 2009, Junio C Hamano wrote:
> Boyd Lynn Gerber <gerberb@zenez.com> writes:
>> Does the test suite use bash as it's shell? I seem to have to use
>> bash now to run the test. I do not remember having to use bash on
>> earlier 1.6.0
>
> If your /bin/sh is not POSIX enough, you may be using a different shell
> when building the scripted commands in the main Makefile by setting
> SHELL_PATH. The tests are supposed to use the same one as that.
>
>> I have to use bash to run the test or I get
>>
>> $ ./t4034-diff-words.sh
>> ./t4034-diff-words.sh: syntax error at line 52: `(' unexpected
>
> The open parenthesis on line 52 is the one between h and 4 here:
>
> cat > expect <<\EOF
> <WHITE>diff --git a/pre b/post<RESET>
> <WHITE>index 330b04f..5ed8eff 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> <BROWN>@@ -1,3 +1,7 @@<RESET>
> <RED>h(4)<RESET><GREEN>h(4),hh[44]<RESET>
> <RESET>
> a = b + c<RESET>
>
> <GREEN>aa = a<RESET>
>
> <GREEN>aeff = aeff * ( aaa )<RESET>
> EOF
>
> Perhaps your shell has a broken here-text?
On OpenServer 6.0.6 /u95/bin/sh /u95/bin/ksh /u95/bin/bash are POSIX
compliant shells. The /bin/ shells are the stand SCO has had finx XENIX.
They use system 5v3. POSIX is System 5v4.
Thanks,
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: [RFC] add test cases for the --repo option to git push
From: Jay Soffian @ 2009-02-27 20:48 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <49A7C3A7.6060202@drmicha.warpmail.net>
On Fri, Feb 27, 2009 at 5:42 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> bcc785f (git push: add verbose flag and allow overriding of default
> target repository, 2006-10-30) Linus introduces --repo.
So I still don't get why Linus introduced the option. I'm looking at
bcc785f:builtin-push.c and AFAICT, the following are exactly
equivalent:
$ git push [options]... <repo>
$ git push [options]... --repo=<repo>
Which is why I sent the original message that has spawned this saga. :-)
Here's the abbreviated code in question:
const char *repo = "origin"; /* default repository */
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
if (arg[0] != '-') {
repo = arg;
i++;
break;
}
if (!strncmp(arg, "--repo=", 7)) {
repo = arg+7;
continue;
}
}
set_refspecs(argv + i, argc - i);
return do_push(repo);
--repo can be placed anywhere on the command line, but other than
that, it's identical in effect to specifying the repo as the first
non-dashed argument.
Or am I completely blind?
j.
^ permalink raw reply
* Re: git-1.6.2-rc2 problems on t4034-diff-words.sh
From: Boyd Lynn Gerber @ 2009-02-27 20:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git List
In-Reply-To: <alpine.LNX.2.00.0902271341440.19082@suse104.zenez.com>
On Fri, 27 Feb 2009, Boyd Lynn Gerber wrote:
> On Fri, 27 Feb 2009, Junio C Hamano wrote:
>> Boyd Lynn Gerber <gerberb@zenez.com> writes:
>>> Does the test suite use bash as it's shell? I seem to have to use
>>> bash now to run the test. I do not remember having to use bash on
>>> earlier 1.6.0
>>
>> If your /bin/sh is not POSIX enough, you may be using a different shell
>> when building the scripted commands in the main Makefile by setting
>> SHELL_PATH. The tests are supposed to use the same one as that.
>>
>>> I have to use bash to run the test or I get
>>>
>>> $ ./t4034-diff-words.sh
>>> ./t4034-diff-words.sh: syntax error at line 52: `(' unexpected
>>
>> The open parenthesis on line 52 is the one between h and 4 here:
>>
>> cat > expect <<\EOF
>> <WHITE>diff --git a/pre b/post<RESET>
>> <WHITE>index 330b04f..5ed8eff 100644<RESET>
>> <WHITE>--- a/pre<RESET>
>> <WHITE>+++ b/post<RESET>
>> <BROWN>@@ -1,3 +1,7 @@<RESET>
>> <RED>h(4)<RESET><GREEN>h(4),hh[44]<RESET>
>> <RESET>
>> a = b + c<RESET>
>>
>> <GREEN>aa = a<RESET>
>>
>> <GREEN>aeff = aeff * ( aaa )<RESET>
>> EOF
>>
>> Perhaps your shell has a broken here-text?
>
> On OpenServer 6.0.6 /u95/bin/sh /u95/bin/ksh /u95/bin/bash are POSIX
> compliant shells. The /bin/ shells are the stand SCO has had finx XENIX.
> They use system 5v3. POSIX is System 5v4.
That should have been OpenServer 6.0 MP4.
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: [PATCH] git-p4: remove tabs from usermap file
From: Simon Hausmann @ 2009-02-27 20:50 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20090227185359.GA18102@padd.com>
On Friday 27 February 2009 19:53:59 Pete Wyckoff wrote:
> Some users have tabs in their names, oddly enough. This
> causes problems when loading the usercache from disk,
> as split separates the fields on the wrong tabs. When
> fast-import's parse_ident() tries to parse the committer
> field, it is unhappy about the unbalanced <..> angle brackets.
>
> It is easy enough to convert the tabs to single spaces.
>
> Signed-off-by: Pete Wyckoff <pw@padd.com>
> ---
> Here's another random little fix. We have a user
> Firstname\tLastname who checked something in recently and
> broke my git-p4 conversion.
>
> I need to send the other acked patch to Junio; will wait
> and give him two if you ack this one.
Looks good to me :-)
Acked-by: Simon Hausmann <simon@lst.de>
Thanks,
Simon
> contrib/fast-import/git-p4 | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 3832f60..342529d 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -1142,7 +1142,7 @@ class P4Sync(Command):
>
> s = ''
> for (key, val) in self.users.items():
> - s += "%s\t%s\n" % (key, val)
> + s += "%s\t%s\n" % (key.expandtabs(1), val.expandtabs(1))
>
> open(self.getUserCacheFilename(), "wb").write(s)
> self.userMapFromPerforceServer = True
^ permalink raw reply
* Re: git-svn woes
From: Deskin Miller @ 2009-02-27 20:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Eric Wong
In-Reply-To: <alpine.LFD.2.00.0902271442270.5511@xanadu.home>
On Fri, Feb 27, 2009 at 15:37, Nicolas Pitre <nico@cam.org> wrote:
>
> OK... I cannot pretend to be a newbie with git. However it's the first
> time I try git-svn and it looks like a couple basic things aren't right.
>
> I initially cloned svn://svn.berlios.de/openocd using "git svn clone -s".
> So far so good. Now I'm attempting to update using "git svn fetch" but
> the operation always fails with the following error:
>
> |branch_from: /openocd/branches => /openocd/branches/xscale
> |Found possible branch point:
> |svn://svn.berlios.de/openocd/openocd/branches/xscale =>
> |svn://svn.berlios.de/openocd/branches/xscale, 1231
> |Initializing parent: xscale@1231
> |Found branch parent: (xscale) 657522f3f2d1ab8b679fd5b45ce4e9ca1974af18
> |Following parent with do_switch
> |Scanning for empty symlinks, this may take a while if you have many empty files
> |You may disable this with `git config svn.brokenSymlinkWorkaround false'.
> |This may be done in a different terminal without restarting git svn
> |Malformed network data: Malformed network data at /home/nico/libexec/git-core/git-svn line 3333
I experience the same error as you do with 1.6.2-rc2. This error is
occurring in the new broken-symlink-workaround code. I'm not sure
what is going on and don't have time to examine it closely, but the
function where the error occurs doesn't run if the config
svn.brokenSymlinkWorkaround option is set false; doing so makes the
fetch continue for me.
Any ideas, Eric?
> Thing is... the repository never gets updated and by far. According to
> "git svn info", the fetched revision is 1232, while a separate
> repository using native svn claims to be at revision 1383.
>
> Furthermore, the "git svn info" command produces yet more errors, such
> as:
>
> |Use of uninitialized value $lc_author in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 964.
> |Use of uninitialized value $lc_rev in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 965.
> |Use of uninitialized value $t in gmtime at /home/nico/libexec/git-core/git-svn line 4743.
> |Use of uninitialized value $t in numeric comparison (<=>) at /home/nico/libexec/git-core/git-svn line 4744.
> |Use of uninitialized value $t in subtraction (-) at /home/nico/libexec/git-core/git-svn line 4745.
> |Use of uninitialized value $t in localtime at /home/nico/libexec/git-core/git-svn line 4746.
>
> This is with git from current "next". I cannot spend time to try fixing
> the issue myself (especially as I'm not familiar at all with the inner
> workings of svn), so my only option at the moment is to give up on
> git-svn altogether. :-(
Oh, don't give up quite yet :)
Deskin Miler
^ permalink raw reply
* Re: [RFC] add test cases for the --repo option to git push
From: Linus Torvalds @ 2009-02-27 21:00 UTC (permalink / raw)
To: Jay Soffian; +Cc: Michael J Gruber, Junio C Hamano, git
In-Reply-To: <76718490902271248p2de44082ka66645203c9683d4@mail.gmail.com>
On Fri, 27 Feb 2009, Jay Soffian wrote:
>
> So I still don't get why Linus introduced the option. I'm looking at
> bcc785f:builtin-push.c and AFAICT, the following are exactly
> equivalent:
>
> $ git push [options]... <repo>
> $ git push [options]... --repo=<repo>
Yes.
But now do
[alias]
push-all=push all
and then try to add those options AFTERWARDS!
> --repo can be placed anywhere on the command line, but other than
> that, it's identical in effect to specifying the repo as the first
> non-dashed argument.
>
> Or am I completely blind?
It's the "placed anywhere on the command line" that is the important part.
Try
git push-all --tags
and it didn't use to work without "--repo=all".
Of course, I think it works now, because I think "git push" uses
"parse_options" these days, so now "--tags" actually works even after the
repository definition. So _these_ days, you can just do
git push all --tags
but that was not true historically. Back then, if you wanted to use an
alias (which mean that the repo was named _before_ the arguments), you
needed to do
git push --repo=all --tags
because putting "--tags" after the repository name wouldn't work.
So _today_, we could remove the use of "--repo". But today, we have
another reason to do "--repo" - compatibility.
Linus
^ permalink raw reply
* Re: git-svn woes
From: Ben Walton @ 2009-02-27 21:02 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git@vger.kernel.org, normalperson
In-Reply-To: <alpine.LFD.2.00.0902271442270.5511@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]
Excerpts from Nicolas Pitre's message of Fri Feb 27 15:37:16 -0500 2009:
> |Use of uninitialized value $lc_author in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 964.
> |Use of uninitialized value $lc_rev in concatenation (.) or string at /home/nico/libexec/git-core/git-svn line 965.
> |Use of uninitialized value $t in gmtime at /home/nico/libexec/git-core/git-svn line 4743.
> |Use of uninitialized value $t in numeric comparison (<=>) at /home/nico/libexec/git-core/git-svn line 4744.
> |Use of uninitialized value $t in subtraction (-) at /home/nico/libexec/git-core/git-svn line 4745.
> |Use of uninitialized value $t in localtime at /home/nico/libexec/git-core/git-svn line 4746.
All of the $t references are due to the patch I kicked in a few days
back. $t is set to the first function argument, which in this case
was passed as a null reference. Should $t default to time() in this
circumstance? That would match the previous behaviour when
localtime(shift) was used, although it may mask errors like this...?
If so, I'll submit a small patch for that asap.
As for why it's getting a null reference if it shouldn't be, I'll
leave that for the people that know the svn part of this.
HTH.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [WARNING] Proposed future changes that are backward incompatible
From: Junio C Hamano @ 2009-02-27 21:02 UTC (permalink / raw)
To: George Spelvin; +Cc: gitster, git
In-Reply-To: <20090227203108.10186.qmail@science.horizon.com>
"George Spelvin" <linux@horizon.com> writes:
> The suggestion was in <83vdsefz9j.fsf@kalahari.s2.org>, available as
> http://marc.info/?l=git&m=123216049508531
> but I agree that there was no consensus. I just thought this thread was
> a good place to elicit discussion, since it would be an incompatible change.
>
>> The only way you could justify such a default change is to say:
>>
>> Almost all the time, everybody wants to use this new behaviour; the
>> old behaviour is almost never useful in any situation other than a
>> narrow corner case; and if somebody wants to do such a useless thing
>> in a corner case, he can always add " ." at the end, so nothing is
>> lost.
>>
>> I do not think that is true for the change you are proposing here. 'He
>> can always add " ." at the end' alone is not a good enough justification.
>
> Please forgive me, ...
There is nothing that needs forgiveness. Discussion is a good thing, as
long as it is not about useless bikeshedding (and I should just learn to
ignore discussions that are useless, instead of getting upset. Lucikly we
haven't had many).
> ... I thought the above *might* be true, and wanted to provoke
> discussion to see how people felt.
If you suspected that the above may be true, that the new behaviour should
be the default, and that many people may support that view, and wanted to
confirm it, then your justification should have really spelled it out.
> The "consistent with
> git-log and all that stuff" argument is quite persuasive to me, but it's
> a convenience feature, so it depends on how people feel.
Consistency among tools with a similar objective is a good thing to aim
for.
"log" especially "log -p" is about inspecting _changes_ and to understand
the change you would more often than not want to view the change in the
entire context (that is the point of having an atomic while-tree commit).
On the other hand, "grep" is about narrowing down the _state_ you would
want to inspect, and unlike the case when you _inspect changes_ where you
would more often want to have the entire context, you would more often
want to omit unrelated parts of the tree while you are _narrowing down
state_ to inspect. This is especially true when you run it from a
subdirectory, and by definition when you are already in a subdirectory,
your attention is already narrowed down to the part of the whole tree you
are currently in.
So in that sense, I do not see a "similar objective" between what log and
grep are used for. They may superficially look similar, but the useful
mode of operation between them can be different because they are used for
different purposes.
^ permalink raw reply
* Re: [PATCH] bisect: fix quoting TRIED revs when "bad" commit is also "skip"ped
From: Christian Couder @ 2009-02-27 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3ae0mfob.fsf@gitster.siamese.dyndns.org>
Le vendredi 27 février 2009, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> >> This makes me suspect that we are forgetting
> >> to check return status after we eval the output from filter_skipped
> >> function. Shouldn't the function should string its commands together
> >> with "&&" to protect it from a breakage like this?
> >
> > Right, that would be an improvement. I put it in another patch though,
> > because it is not really needed to fix a breakage.
Here I wanted to say that I think it fixes a separate breakage or another
kind of breakage rather than not a breakage. Sorry.
> Sorry, but I have to disagree.
>
> Look at the caller of filter_skipped in bisect_next():
>
> eval="git rev-list --bisect-vars $BISECT_OPT $good $bad --" &&
> eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
> eval=$(filter_skipped "$eval" "$skip") &&
> eval "$eval" || exit
>
> if [ -z "$bisect_rev" ]; then
> echo "$bad was both good and bad"
> exit 1
> fi
>
> The eval "$eval" in the middle, if failed properly upon seeing the quote
> bug, would have exited there, because "|| exit" there is all about
> catching a broken eval string. It was not effective.
Yes, but before I introduced filter_skipped there was:
eval="git rev-list --bisect-vars $good $bad --" &&
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
eval=$(eval "$eval") &&
eval "$eval" || exit
so the output of "git rev-list --bisect-vars ..." was evaled, and this
output is something like that:
$ git rev-list --bisect-vars HEAD ^HEAD~3
bisect_rev=c24505030fad7cc2872e0a0fd0f44e05571a0ad8
bisect_nr=1
bisect_good=0
bisect_bad=1
bisect_all=3
where there is no "&&" at the end of the commands to string them together.
So this breakage already existed before I introduced "filter_skipped".
> You were lucky in this case that bisect_rev happens to be empty because
> the bug happened to be at the place where bisect_rev was assigned to.
> But with a random other breakage in the filter_skipped, you would not
> have been so lucky.
Yeah, I should have improved on the existing design instead of blindly
following it. I hope I won't get sued for that ;-)
> I think it is an integral part of the bugfix to string the commands
> filter_skipped outputs with &&, so that an error while executing an
> earlier command in the output sequence is not masked by execution of
> other commands in the output.
So you should perhaps squash the following hunk to the patch:
diff --git a/git-bisect.sh b/git-bisect.sh
index 08e31d6..980d73c 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -284,7 +284,13 @@ filter_skipped() {
_skip="$2"
if [ -z "$_skip" ]; then
- eval "$_eval"
+ eval "$_eval" | {
+ while read line
+ do
+ echo "$line &&"
+ done
+ echo ':'
+ }
return
fi
as this will string the commands together when there are no skipped commits
too.
> Here is what I am thinking about queueing for 1.6.2; it may be necessary
> to apply it to 1.6.1.X (or 1.6.0.X) and merge the fix upwards.
It looks good to me. But frankly I feel always strange when a patch like
this one, where you did most of the code change, get attributed to me. I
would have prefered that you added a patch attributed to you on top of mine
if possible.
Best regards,
Christian.
^ permalink raw reply related
* Re: [RFC] add test cases for the --repo option to git push
From: Jay Soffian @ 2009-02-27 21:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michael J Gruber, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0902271255530.3111@localhost.localdomain>
On Fri, Feb 27, 2009 at 4:00 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> So _today_, we could remove the use of "--repo". But today, we have
> another reason to do "--repo" - compatibility.
I was not suggesting removing --repo. I just didn't understand why it existed.
Thanks for the clarification.
j.
^ permalink raw reply
* Re: [WARNING] Proposed future changes that are backward incompatible
From: Pascal Obry @ 2009-02-27 20:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: George Spelvin, git, gitster
In-Reply-To: <alpine.DEB.1.00.0902272046040.6600@intel-tinevez-2-302>
Johannes Schindelin a écrit :
> I use "git grep" in subdirectories extensively, and I like that it does
> _not_ search the whole repository.
Count me too! I find this feature very important.
> After all, since you propose a change in behavior, it is _your_ duty to
> provide ways for those who want the old behavior to get at it easily!
Agreed.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Josef Wolf @ 2009-02-27 22:05 UTC (permalink / raw)
To: git
In-Reply-To: <49A826C8.1060300@drmicha.warpmail.net>
Thanks for your patience, Michael!
On Fri, Feb 27, 2009 at 06:45:44PM +0100, Michael J Gruber wrote:
> Josef Wolf venit, vidit, dixit 27.02.2009 18:12:
> > On Wed, Feb 25, 2009 at 10:26:10AM +0100, Michael J Gruber wrote:
> >> Josef Wolf venit, vidit, dixit 24.02.2009 23:34:
[ ... ]
> > (cd git-svn-repos; git pull ../clone1)
>
> Gives you 1-2-3-4
>
> > (cd git-svn-repos; git svn rebase)
>
> Does nothing here (but is good practice)
>
> > (cd git-svn-repos; git svn dcommit)
>
> Creates 2-3-4 on the svn side. *Then rebases* your master, which creates
> 1-2'-3'-4' on master. Note that 2 is different from 2' (git-svn id).
So the sha1 is not preserved when it goes through svn?
> > (cd git-svn-repos; git pull ../clone1) # if this line is executed,
>
> That's the problem. This creates a merge after which you 1-2-3-4 and
> 1-2'-3'-4' plus the merge of 4 and 4'.
--verbosity=on please ;-)
> Instead, use git pull --rebase here. You don't want merges in the branch
> from which you dcommit.
Yeah, "pull --rebase" seems to help a lot. So I've come up with the next
version of my workflow-test-script:
(
set -ex
# create test directory
#
TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX`
rm -rf $TESTDIR
mkdir -p $TESTDIR
cd $TESTDIR
SUBVERSION_REPOS=file://`pwd`/subversion-repos
# create subversion repos with some history
#
svnadmin create subversion-repos
svn -m "create standard layout" mkdir \
$SUBVERSION_REPOS/trunk \
$SUBVERSION_REPOS/branches \
$SUBVERSION_REPOS/tags
svn co $SUBVERSION_REPOS/trunk subversion-wc
echo change1 >>subversion-wc/test
svn add subversion-wc/test
svn ci -m "commit 0" subversion-wc
# create git-svn-repos
#
git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos
(cd git-svn-repos; git svn fetch)
# create clones
#
git clone git-svn-repos clone1
git clone git-svn-repos clone2
git clone git-svn-repos clone3
# now go several times to every clone, do some work on it, and sync
# the results
#
for cycle in 1 2 3; do
for clone in 1 2 3; do
for commit in 1 2 3; do
(
cd clone$clone
git pull --rebase
echo change $clone $commit >>test
git commit -a -m "commit $clone $commit"
)
done
(cd git-svn-repos; git pull --rebase ../clone$clone)
(cd git-svn-repos; git svn rebase)
(cd git-svn-repos; git svn dcommit)
done
done
)
At least, this seems to not creating collisions any more. But I'm still
not sure I fully understand what's going on here. Guess, I'll have to
get into the learning-by-doing mode :)
> Borrowing from some other vcs:
>
> Repeat the soothing mantra: a merge is no merge is no merge - it it's in
> svn ;)
Huh?
> > Obviously, I'm doing something wrong. But I can't figure what. Any hints?
>
> I guess when we said integrated we should have said rebase. Haven't we?
You like to talk in riddles? Aren't you?
Thanks a lot.
^ permalink raw reply
* proper way to merge?
From: John Dlugosz @ 2009-02-27 22:11 UTC (permalink / raw)
To: git
I'm merging two branches: let's say "dev" is for development of future
releases, and "rel" is changes made to the current release for immediate
application. Now I want to bring the changes made in rel back to dev.
Rather than trying to merge it all at once, I'm applying the changes a
few at a time and making sure it still compiles as I go. Then,
git-reset and I have dev as my HEAD and the desired merge result in the
working tree.
Now, I want to introduce the proper commit node to show that this is the
graft. But, I don't want to be presented with all the differences that
I already resolved; I know what it should look like already. How do I
commit the current state of things and have it show up with both dev and
rel as parents? (then make that the new dev)
I'm also interesting in learning how to do it better next time. But I'm
doing the incremental merging now and need to know how to conclude it.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [PATCH] bisect: fix quoting TRIED revs when "bad" commit is also "skip"ped
From: Junio C Hamano @ 2009-02-27 22:34 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <200902272205.10501.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> So you should perhaps squash the following hunk to the patch:
> ...
> as this will string the commands together when there are no skipped commits
> too.
Ok, good eyes.
Even though this part is directly from rev-list --bisect-vars and is much
less likely to be malformed than the list of commands filter_skipped
function produces, I agree it is a good discipline to protect it from the
breakage the same way.
Thanks.
^ permalink raw reply
* Issue 125 in msysgit: gitk crashes when quit while reading (fwd)
From: Johannes Schindelin @ 2009-02-27 23:45 UTC (permalink / raw)
To: paulus; +Cc: patthoyts, git, msysgit
Hi Paul,
this came in through msysGit's issue tracker, from a guy who is involved
in the Tk project.
---------- Forwarded message ----------
Date: Fri, 27 Feb 2009 23:12:11 +0000
From: codesite-noreply@google.com
To: msysgit@googlegroups.com
Subject: [msysGit] Issue 125 in msysgit: gitk crashes when quit while reading
Comment #4 on issue 125 by patthoyts: gitk crashes when quit while reading
http://code.google.com/p/msysgit/issues/detail?id=125
The simplest fix for all current versions of Tk is to apply the following patch
to
gitk which will flush all the geometry events before it begins reading the
commit
ids. This avoids the crash. A fix has now been applied to Tk 8.5 and HEAD
branches to
avoid this in the future.
diff --git a/gitk b/gitk
index dc2a439..197bc67 100755
--- a/gitk
+++ b/gitk
@@ -10884,6 +10884,7 @@ makewindow
# wait for the window to become visible
tkwait visibility .
wm title . "[file tail $argv0]: [file tail [pwd]]"
+update
readrefs
if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne {}} {
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
^ permalink raw reply related
* Re: [PATCH 1/4] diffcore-pickaxe: refactor diffcore_pickaxe()
From: René Scharfe @ 2009-02-27 23:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <4b1358cc6558ec05a134431b603e4781b42deabd.1235629933.git.gitster@pobox.com>
Junio C Hamano schrieb:
> void diffcore_pickaxe(const char *needle, int opts)
> {
> struct diff_queue_struct *q = &diff_queued_diff;
> @@ -75,29 +107,14 @@ void diffcore_pickaxe(const char *needle, int opts)
> /* Showing the whole changeset if needle exists */
> for (i = has_changes = 0; !has_changes && i < q->nr; i++) {
> struct diff_filepair *p = q->queue[i];
> - if (!DIFF_FILE_VALID(p->one)) {
> - if (!DIFF_FILE_VALID(p->two))
> - continue; /* ignore unmerged */
> - /* created */
> - if (contains(p->two, needle, len, regexp))
> - has_changes++;
> - }
> - else if (!DIFF_FILE_VALID(p->two)) {
> - if (contains(p->one, needle, len, regexp))
> - has_changes++;
> - }
> - else if (!diff_unmodified_pair(p) &&
> - contains(p->one, needle, len, regexp) !=
> - contains(p->two, needle, len, regexp))
> - has_changes++;
> + if (pickaxe_match_one(p, needle, len, regexp))
> + return; /* not munge the queue */
> }
> - if (has_changes)
> - return; /* not munge the queue */
>
> - /* otherwise we will clear the whole queue
> - * by copying the empty outq at the end of this
> - * function, but first clear the current entries
> - * in the queue.
> + /*
> + * otherwise we will clear the whole queue by copying
> + * the empty outq at the end of this function, but
> + * first clear the current entries in the queue.
> */
> for (i = 0; i < q->nr; i++)
> diff_free_filepair(q->queue[i]);
> @@ -106,24 +123,8 @@ void diffcore_pickaxe(const char *needle, int opts)
> /* Showing only the filepairs that has the needle */
> for (i = 0; i < q->nr; i++) {
> struct diff_filepair *p = q->queue[i];
> - has_changes = 0;
> - if (!DIFF_FILE_VALID(p->one)) {
> - if (!DIFF_FILE_VALID(p->two))
> - ; /* ignore unmerged */
> - /* created */
> - else if (contains(p->two, needle, len, regexp))
> - has_changes = 1;
> - }
> - else if (!DIFF_FILE_VALID(p->two)) {
> - if (contains(p->one, needle, len, regexp))
> - has_changes = 1;
> - }
> - else if (!diff_unmodified_pair(p) &&
> - contains(p->one, needle, len, regexp) !=
> - contains(p->two, needle, len, regexp))
> - has_changes = 1;
>
> - if (has_changes)
> + if (pickaxe_match_one(p, needle, len, regexp))
> diff_q(&outq, p);
> else
> diff_free_filepair(p);
You might want to squash this in, because has_changes is now constantly set
to zero:
diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
index d27e725..d294d29 100644
--- a/diffcore-pickaxe.c
+++ b/diffcore-pickaxe.c
@@ -84,7 +84,7 @@ void diffcore_pickaxe(const char *needle, int opts)
{
struct diff_queue_struct *q = &diff_queued_diff;
unsigned long len = strlen(needle);
- int i, has_changes;
+ int i;
regex_t regex, *regexp = NULL;
struct diff_queue_struct outq;
outq.queue = NULL;
@@ -105,7 +105,7 @@ void diffcore_pickaxe(const char *needle, int opts)
if (opts & DIFF_PICKAXE_ALL) {
/* Showing the whole changeset if needle exists */
- for (i = has_changes = 0; !has_changes && i < q->nr; i++) {
+ for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
if (pickaxe_match_one(p, needle, len, regexp))
return; /* not munge the queue */
^ permalink raw reply related
* Re: git-svn and repository hierarchy?
From: Josef Wolf @ 2009-02-27 23:58 UTC (permalink / raw)
To: git
In-Reply-To: <eaa105840902271011u19375ba4j4a765ed2707ebb3b@mail.gmail.com>
On Fri, Feb 27, 2009 at 01:11:36PM -0500, Peter Harris wrote:
> On Fri, Feb 27, 2009 at 11:58 AM, Josef Wolf wrote:
> > On Wed, Feb 25, 2009 at 08:02:45PM -0500, Peter Harris wrote:
> >
> >> No need to coordinate clones, aside from each clone
> >> needing to know how to work in a "commits will be rebased by upstream"
> >> type of environment (which isn't unique to git-svn).
> >
> > Hmm, what does that exactly mean? Chances are that the reason for my
> > problem is that _I_ am the one who don't know that...
>
> See, for example,
> http://kerneltrap.org/mailarchive/git/2008/8/23/3056824 and
> surrounding thread.
>
> The consensus is "Pester upstream until they stop rebasing".
> Unfortunately, Subversion is an application, not a human, so your
> pleas will go unheard. :-) The rest of that thread contains hints for
> working with a rebasing upstream.
Thanks for the pointer, Peter! That's a long thread with a lot of
dense information. I'm going to read (and try to understand :),
but I guess it will take a couple of days...
> git-svn will actually never rebase anything once it is in Subversion.
> So, for example, when they say 'linux-next' in that thread, you could
> read "any branch that isn't in Subversion yet", since you know that
> branch will be rebased at least once.
At the time I read the tutorials/howtos/whatever, I thought I understand
what "rebase" actually means. But now I get pretty much confused, since
there are "git rebase", "git pull --rebase" and "git svn rebase" involved,
and they all seem to do very different things.
> > jw@raven:/home/jw> git --version
> > git version 1.6.0.2
> > jw@raven:/home/jw>
>
> 2beec8973 is the commit in question. Unless I'm mistaken, it first
> appeared in 1.6.1.0, so you may want to upgrade each cloneN to at
> least 1.6.1.
OK.
^ permalink raw reply
* [PATCH] autoconf: Add support for --infodir
From: Jakub Narebski @ 2009-02-28 0:33 UTC (permalink / raw)
To: git; +Cc: Jeff King, Tim Visher, Jakub Narebski
In-Reply-To: <Tim Visher <tim.visher@gmail.com>
On Thu, 26 Feb 2009, Jeff King wrote:
> On Thu, Feb 26, 2009 at 09:48:29AM -0500, Tim Visher wrote:
>
>> I'm working on getting git 1.6.2-rc2 built. I have a bin, man, info,
>> and html directory in my home folder that I'd like to use as the
>> defaults for git. I attempted to do this through
>>
>> make configure
>> ./configure --XXdir=/full/path/to/dir
>> make all man info html
>> make install install-man install-info install-html
>>
>> But other than the binaries (and I'm not even totally convinced they
>> got in correctly) and the man pages, everything else seems to be
>> attempting to go to the typical places in /usr/local.
>>
>> What am I doing wrong?
Why don't you use simply --prefix=DIR?
>
> The configure support is notoriously incomplete (AFAIK, very few of the
> active developers use it regularly). Probably you need something like
> this (but I didn't test it):
>
> diff --git a/config.mak.in b/config.mak.in
> index 7cce0c1..505d5c7 100644
> --- a/config.mak.in
> +++ b/config.mak.in
> @@ -18,6 +18,8 @@ datarootdir = @datarootdir@
> template_dir = @datadir@/git-core/templates
>
> mandir=@mandir@
> +htmldir=@htmldir@
> +infodir=@infodir@
>
> srcdir = @srcdir@
> VPATH = @srcdir@
Well, the infodir part works trivially, because autoconf (and
therefore ./configure script) has support for --infodir=DIR.
Below there is patch that adds that, with the commit message.
But it is more difficult with respect to --htmldir. I am not autoconf
hacker, so I don't know how to add support for having --htmldir=DIR in
./configure (in configure.ac). What can be done is to derive htmldir
in config.mak.in from other sources, for example:
htmldir=@datadir@/doc/git
or something like that.
-- >8 --
Now that we actually (can) install some info files, and that $infodir
is set and used in Makefile(s), let add support for --infodir=DIR
[PREFIX/info] ./configure option in config.mak.in.
Half of patch by Jeff King <peff@peff.net>m adding --XXdir support
(the easy part: autoconf has --infodir, but not --htmldir).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
config.mak.in | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index 7cce0c1..acff9ed 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -18,6 +18,7 @@ datarootdir = @datarootdir@
template_dir = @datadir@/git-core/templates
mandir=@mandir@
+infodir=@infodir@
srcdir = @srcdir@
VPATH = @srcdir@
^ 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