1 Feb 01:15
1 Feb 01:27
Re: logging disjoint sets of commits in a single command
Bryan O'Sullivan <bryano <at> fb.com>
2012-02-01 00:27:06 GMT
2012-02-01 00:27:06 GMT
On 2012-01-31 16:15 , "Bryan O'Sullivan" <bryano <at> fb.com> wrote: >I'm trying to use "git log" to display only a handful of commits, where >the commits are not necessarily linearly related to each other. And I beautifully fat-fingered the "send" key. Oops. What I was *going* to say was that it looks like revision.c:limit_list is (whether intentionally or not) getting in the way of this. Here's a sample command line against a kernel tree: git log 373af0c^..373af0c 590dfe2^..590dfe2 I want git to log those two specific commits, but in fact it looks like limit_list is marking 590dfe2 as UNINTERESTING while processing 373af0c, and so it gets pruned. Is there some way around this, or would a patch to fix it be acceptable?
1 Feb 01:31
Re: [PATCH/RFC v3] grep: Add the option '--exclude'
Junio C Hamano <gitster <at> pobox.com>
2012-02-01 00:31:42 GMT
2012-02-01 00:31:42 GMT
Albert Yale <surfingalbert <at> gmail.com> writes: > @@ -124,6 +125,12 @@ OPTIONS > Use fixed strings for patterns (don't interpret pattern > as a regex). > > +-x <pattern>:: > +--exclude <pattern>:: > + In addition to those found in .gitignore (per directory) and > + $GIT_DIR/info/exclude, also consider these patterns to be in the > + set of the ignore rules in effect. That makes it sound as if "git grep" will not produce hits for a path that was forcibly added despite it matches a pattern in .gitignore file, which is not true at all. > -n:: > --line-number:: > Prefix the line number to matching lines. > diff --git a/builtin/grep.c b/builtin/grep.c > index 9ce064a..e9e1ac1 100644 > --- a/builtin/grep.c > +++ b/builtin/grep.c > @@ -528,7 +528,8 @@ static int grep_cache(struct grep_opt *opt, const struct pathspec *pathspec, int > struct cache_entry *ce = active_cache[nr]; > if (!S_ISREG(ce->ce_mode)) > continue; > - if (!match_pathspec_depth(pathspec, ce->name, ce_namelen(ce), 0, NULL)) > + if (!match_pathspec_depth(pathspec, ce->name, ce_namelen(ce), > + 0, NULL, 1))(Continue reading)
1 Feb 01:39
Re: logging disjoint sets of commits in a single command
Carlos Martín Nieto <carlos <at> cmartin.tk>
2012-02-01 00:39:29 GMT
2012-02-01 00:39:29 GMT
On Wed, 2012-02-01 at 00:27 +0000, Bryan O'Sullivan wrote:
> On 2012-01-31 16:15 , "Bryan O'Sullivan" <bryano <at> fb.com> wrote:
>
> >I'm trying to use "git log" to display only a handful of commits, where
> >the commits are not necessarily linearly related to each other.
>
> And I beautifully fat-fingered the "send" key. Oops.
>
> What I was *going* to say was that it looks like revision.c:limit_list is
> (whether intentionally or not) getting in the way of this.
>
> Here's a sample command line against a kernel tree:
>
> git log 373af0c^..373af0c 590dfe2^..590dfe2
>
> I want git to log those two specific commits, but in fact it looks like
> limit_list is marking 590dfe2 as UNINTERESTING while processing 373af0c,
> and so it gets pruned.
>
> Is there some way around this, or would a patch to fix it be acceptable?
From my reading of the manpage (and the way most git commands work) log
accepts one range of commits. They all get bunched up together.
You might find cat-file's --batch mode interesting.
git rev-list 373af0c^..373af0c | git cat-file --batch
git rev-list 590dfe2^..590dfe2 | git cat-file --batch
looks a lot like what you're looking for.
(Continue reading)
1 Feb 01:48
Re: logging disjoint sets of commits in a single command
Junio C Hamano <gitster <at> pobox.com>
2012-02-01 00:48:58 GMT
2012-02-01 00:48:58 GMT
"Bryan O'Sullivan" <bryano <at> fb.com> writes:
> Here's a sample command line against a kernel tree:
>
> git log 373af0c^..373af0c 590dfe2^..590dfe2
This command line is _defined_ to be the same as this.
git log ^373af0c^ 373af0c ^590dfe2^ 590dfe2
Hence,
> Is there some way around this, or would a patch to fix it be acceptable?
the answer to the second question is "no, that is not a fix but is a
breakage for the *current* Git users".
The answer to the first question is that you may be able to do something
like this:
(
git rev-list 373af0c^..373af0c
git rev-list 590dfe2^..590dfe2
) |
sort -u |
xargs git show
Having said all that, for users of Git 2.0, giving richer meaning to the
explicit range notation to make your original command line work just like
the above scripted way would be more intuitive. While an unconditional
(Continue reading)
1 Feb 01:53
Re: logging disjoint sets of commits in a single command
Jeff King <peff <at> peff.net>
2012-02-01 00:53:33 GMT
2012-02-01 00:53:33 GMT
On Wed, Feb 01, 2012 at 01:39:29AM +0100, Carlos Martín Nieto wrote:
> > Here's a sample command line against a kernel tree:
> >
> > git log 373af0c^..373af0c 590dfe2^..590dfe2
> >
> > I want git to log those two specific commits, but in fact it looks like
> > limit_list is marking 590dfe2 as UNINTERESTING while processing 373af0c,
> > and so it gets pruned.
> >
> > Is there some way around this, or would a patch to fix it be acceptable?
>
> From my reading of the manpage (and the way most git commands work) log
> accepts one range of commits. They all get bunched up together.
Right. That command is equivalent to:
373af0c 590dfe2 --not 373af0c^ 590dfe2^
So the limiting for one range you're interested in ends up marking part
of the other as uninteresting, and that's by design. This topic came up
recently, and I think the general consensus is that it would be cool to
be able to do totally independent ranges, but that would be backwards
incompatible with the current behavior.
In the general case, you can emulate this with:
{ git log 373af0c^..373af0c
git log 590dfe2^..590dfe2
} | $PAGER
(Continue reading)
1 Feb 02:02
Re: logging disjoint sets of commits in a single command
Bryan O'Sullivan <bryano <at> fb.com>
2012-02-01 01:02:57 GMT
2012-02-01 01:02:57 GMT
On 2012-01-31, "Jeff King" <peff <at> peff.net> wrote: >This topic came up >recently, and I think the general consensus is that it would be cool to >be able to do totally independent ranges, but that would be backwards >incompatible with the current behavior. That's totally sensible. I hadn't been able to tell from inspection whether the behaviour was deliberate or not. >which is of course slightly more annoying to type. If you're just >interested in _single_ commits, though, you can just give the commits >and turn off walking: > > git log --no-walk 373af0c 590dfe2 Oh, nice! I hadn't seen that option. By the way, the reason I'm even interested in this in the first place is that the performance of commands like "git blame" and "git log" on files and subtrees has become a problem for us (> 10 seconds per invocation, forecast to get much worse), and I wanted to see whether I could feed "git log" a specific list of revisions, and if so, whether that could yield good performance. I have it in mind to build a secondary index (maintained externally) so that I can supply these git commands with precise lists of revisions for much faster response times. Thanks, guys!(Continue reading)
1 Feb 02:32
Re: [PATCH] Correct singular form in diff summary line for human interaction
Nguyen Thai Ngoc Duy <pclouds <at> gmail.com>
2012-02-01 01:32:43 GMT
2012-02-01 01:32:43 GMT
On Wed, Feb 1, 2012 at 12:50 AM, Junio C Hamano <gitster <at> pobox.com> wrote: >> If there is an environment variable to say "I don't want to see >> variations on strings intended for humans", can it be spelled as >> LC_ALL=C? > > ... > > If we were to touch this, I would prefer to do so unconditionally without > "hrm, can we reliably guess this is meant for humans?" and release it > unceremoniously, perhaps as part of the next release that will have a much > bigger user-visible UI correction to 'merge'. Unconditionally change is fine to me. There's another implication that's not mentioned in the commit message, this change also allows non-English translations. Any objections on i18n or we just keep this line English only? Personally if scripts do not matter any more, I see no reasons this line cannot be translated. -- -- Duy
1 Feb 02:45
Re: [PATCH] Correct singular form in diff summary line for human interaction
Thomas Dickey <dickey <at> his.com>
2012-02-01 01:45:15 GMT
2012-02-01 01:45:15 GMT
On Wed, Feb 01, 2012 at 08:32:43AM +0700, Nguyen Thai Ngoc Duy wrote: > On Wed, Feb 1, 2012 at 12:50 AM, Junio C Hamano <gitster <at> pobox.com> wrote: > >> If there is an environment variable to say "I don't want to see > >> variations on strings intended for humans", can it be spelled as > >> LC_ALL=C? I assume from Neider on the list that this is related to mawk, but I don't have the email preceding this... -- -- Thomas E. Dickey <dickey <at> invisible-island.net> http://invisible-island.net ftp://invisible-island.net
1 Feb 02:56
Re: [PATCH] Correct singular form in diff summary line for human interaction
Thomas Dickey <dickey <at> his.com>
2012-02-01 01:56:06 GMT
2012-02-01 01:56:06 GMT
On Wed, Feb 01, 2012 at 08:32:43AM +0700, Nguyen Thai Ngoc Duy wrote: > On Wed, Feb 1, 2012 at 12:50 AM, Junio C Hamano <gitster <at> pobox.com> wrote: > >> If there is an environment variable to say "I don't want to see > >> variations on strings intended for humans", can it be spelled as > >> LC_ALL=C? > > > > ... ... diffstat (google helped find context) > > If we were to touch this, I would prefer to do so unconditionally without > > "hrm, can we reliably guess this is meant for humans?" and release it > > unceremoniously, perhaps as part of the next release that will have a much > > bigger user-visible UI correction to 'merge'. > > Unconditionally change is fine to me. There's another implication > that's not mentioned in the commit message, this change also allows > non-English translations. Any objections on i18n or we just keep this > line English only? Personally if scripts do not matter any more, I see > no reasons this line cannot be translated. I seem to recall that gettext does support plurals... However, going that route means that even innocuous things like the parentheses "(+)" can be mangled by translators (guaranteed to break scripts(Continue reading)-- -- Thomas E. Dickey <dickey <at> invisible-island.net> http://invisible-island.net
RSS Feed