* Re: [PATCH] grep: --full-tree
From: A Large Angry SCM @ 2009-11-25 22:41 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091125222625.GB2861@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Nov 25, 2009 at 02:19:35PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>>> ... That is, I don't want to have to remember "git grep
>>> --full-tree" or "git grep /" every time
>> But that cuts both ways. If you change the default to full-tree,
>> people will forget to put "." every time when asking to limit to the
>> current directory.
>
> I know. Which is why I am arguing for a configuration option.
>
> Though as a side note, I think if you are going to err, it is probably
> better to err in showing _too much_ data. It is easier for the user to
> notice the situation and re-issue the command with more limits than it
> is for them to notice that some results are missing and re-issue the
> command with fewer limits.
>
>>> If I am the one who sets the configuration variable to something more
>>> sensible for my workflow, who am I hurting?
>> Somebody more clueful in git than you who is called to help you in your
>> repository when you have trouble. Obviously "you" in this sentence is not
>> Jeff King, but I think you get the point.
>
> Clearly, because there _isn't_ anybody more clueful than me in git. ;)
>
> But that is what my meta-rant elsewhere in the thread was about. Sure,
> it hurts when more clueful people are called in (and that includes
> asking for help on the list). But that evil to me is much less than a
> user who is frustrated because they have to specify the same thing to
> git over and over again.
>
>> And re-read what I wrote in its entirety and notice I am not disagreeing
>> with you that the long term goal should be to have the default changed
>> consistently for all command to do the full tree. The important first
>> step is to make sure we are capable of doing both full tree and limit to
>> current directory and "grep" is one example that cannot do both, and be it
>> the --full-tree option or new /rooted-pathspec, we need some change _now_
>> that is backward compatible to pave the way for later changes. We give
>> people convenient way to choose between the two, and _train_ them to
>> express which way they want _without_ having to think. After that is
>> achieved, the default does not matter much and we can safely change the
>> default.
>>
>> Think of it as a way to force existing users _unlearn_ the command
>> specific default we currently have. Because any change of default will
>> hurt them until that is done, we should start training them as early as
>> possible.
>
> I agree with all of this as far as changing the default goes. But the
> point of my earlier messages was that I don't think there _is_ one sane
> default. I really do want it different per-project. And that means a
> configuration option.
Since grep is so useful, both interactively and scripted, outside of
git, this is a pretty convincing argument that git-grep, and all other
git commands with configurable behavior or defaults that change over
time, need a both a scripting form and an interactive form.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: A Large Angry SCM @ 2009-11-25 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vljhuqm84.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>> To make the reconciliation even more difficult, some git commands
>> will also work on out-of-tree paths.
>
> I think people know my feeling towards "diff --no-index". It makes many
> nice features invented in git to people who do not use "git" (e.g, to
> compare files outside of control of git using --color-words). If it
> happened in an ideal world, it wouldn't have been done as a patch to "git"
> but to something like "GNU diff" to benefit people who do not even want to
> install "git". But unfortunately that wasn't the way it was done.
>
> It has turned out to be an unnecessary maintenance burden ever since it
> was applied and every time we needed to change small things to "git diff".
> I would not be very unhappy if we need to ejected it from "git diff" if it
> turns out to hinder the necessary UI changes too much.
>
git-diff aside, I would be much happier with git's interface, and I
think new/occasional users would be also, if it was consistent across
all of git commands. And even more so if git's conventions matched most
other commands on my system of choice.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtywiqmbs.fsf@alter.siamese.dyndns.org>
On Wed, Nov 25, 2009 at 02:19:35PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > ... That is, I don't want to have to remember "git grep
> > --full-tree" or "git grep /" every time
>
> But that cuts both ways. If you change the default to full-tree,
> people will forget to put "." every time when asking to limit to the
> current directory.
I know. Which is why I am arguing for a configuration option.
Though as a side note, I think if you are going to err, it is probably
better to err in showing _too much_ data. It is easier for the user to
notice the situation and re-issue the command with more limits than it
is for them to notice that some results are missing and re-issue the
command with fewer limits.
> > If I am the one who sets the configuration variable to something more
> > sensible for my workflow, who am I hurting?
>
> Somebody more clueful in git than you who is called to help you in your
> repository when you have trouble. Obviously "you" in this sentence is not
> Jeff King, but I think you get the point.
Clearly, because there _isn't_ anybody more clueful than me in git. ;)
But that is what my meta-rant elsewhere in the thread was about. Sure,
it hurts when more clueful people are called in (and that includes
asking for help on the list). But that evil to me is much less than a
user who is frustrated because they have to specify the same thing to
git over and over again.
> And re-read what I wrote in its entirety and notice I am not disagreeing
> with you that the long term goal should be to have the default changed
> consistently for all command to do the full tree. The important first
> step is to make sure we are capable of doing both full tree and limit to
> current directory and "grep" is one example that cannot do both, and be it
> the --full-tree option or new /rooted-pathspec, we need some change _now_
> that is backward compatible to pave the way for later changes. We give
> people convenient way to choose between the two, and _train_ them to
> express which way they want _without_ having to think. After that is
> achieved, the default does not matter much and we can safely change the
> default.
>
> Think of it as a way to force existing users _unlearn_ the command
> specific default we currently have. Because any change of default will
> hurt them until that is done, we should start training them as early as
> possible.
I agree with all of this as far as changing the default goes. But the
point of my earlier messages was that I don't think there _is_ one sane
default. I really do want it different per-project. And that means a
configuration option.
-Peff
^ permalink raw reply
* Re: Please help with GIT install problem.
From: Junio C Hamano @ 2009-11-25 22:23 UTC (permalink / raw)
To: Stephan T.; +Cc: git
In-Reply-To: <377205.65475.qm@web30806.mail.mud.yahoo.com>
"Stephan T." <stman937-lingit@yahoo.com> writes:
> My system is a:
> % uname -a
> Linux naboo 2.4.21-50.ELsmp #1 SMP Tue May 8 17:18:29 EDT 2007 i686 i686 i386 GNU/Linux
> ...
> What is missing on my system?
Perhaps reading INSTALL will tell you a bit better?
On a typical Linux desktop, configure is unnecessary.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-25 22:21 UTC (permalink / raw)
To: gitzilla; +Cc: Jeff King, git
In-Reply-To: <4B0DAC9F.2010205@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> To make the reconciliation even more difficult, some git commands
> will also work on out-of-tree paths.
I think people know my feeling towards "diff --no-index". It makes many
nice features invented in git to people who do not use "git" (e.g, to
compare files outside of control of git using --color-words). If it
happened in an ideal world, it wouldn't have been done as a patch to "git"
but to something like "GNU diff" to benefit people who do not even want to
install "git". But unfortunately that wasn't the way it was done.
It has turned out to be an unnecessary maintenance burden ever since it
was applied and every time we needed to change small things to "git diff".
I would not be very unhappy if we need to ejected it from "git diff" if it
turns out to hinder the necessary UI changes too much.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 22:20 UTC (permalink / raw)
To: James Pickens; +Cc: Junio C Hamano, git
In-Reply-To: <885649360911251412n3e566c8fu536b361b993f2ac6@mail.gmail.com>
On Wed, Nov 25, 2009 at 03:12:26PM -0700, James Pickens wrote:
> Config options are not free - they add code bloat, increase the maintenance
> and testing burden, make it harder to explain how Git works if you have to
> say things like "if config X is true, then Git does ..., otherwise Git does
> ..., unless config Y is false, in which case Git does ...", make it harder
> to debug when Git doesn't do what you expected if you have to check a bunch
> of configs to figure out what the behavior should be, and make it harder to
> develop new features since you have to consider how they might interact with
> lots of config options. So I think the bar for adding config options,
> especially ones that fundamentally change user visible behavior, should be
> set pretty high, and this one doesn't even come close to getting over the
> bar.
Sure, there are all those downsides. But what is the other option?
Making me use the command line option (or pathspec magic) every single
time I invoke git grep? That is a huge downside to me.
I started to try to write an argument against this, but I really don't
know how to. You don't think this particular option gets over the bar.
Probably because it is not something that has been annoying you
personally. But is _is_ something that has been annoying me. Now we are
both making claims from our gut. How do we proceed with a rational
analysis?
-Peff
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-25 22:19 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091125214949.GA31473@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... That is, I don't want to have to remember "git grep
> --full-tree" or "git grep /" every time
But that cuts both ways. If you change the default to full-tree,
people will forget to put "." every time when asking to limit to the
current directory.
> If I am the one who sets the configuration variable to something more
> sensible for my workflow, who am I hurting?
Somebody more clueful in git than you who is called to help you in your
repository when you have trouble. Obviously "you" in this sentence is not
Jeff King, but I think you get the point.
And re-read what I wrote in its entirety and notice I am not disagreeing
with you that the long term goal should be to have the default changed
consistently for all command to do the full tree. The important first
step is to make sure we are capable of doing both full tree and limit to
current directory and "grep" is one example that cannot do both, and be it
the --full-tree option or new /rooted-pathspec, we need some change _now_
that is backward compatible to pave the way for later changes. We give
people convenient way to choose between the two, and _train_ them to
express which way they want _without_ having to think. After that is
achieved, the default does not matter much and we can safely change the
default.
Think of it as a way to force existing users _unlearn_ the command
specific default we currently have. Because any change of default will
hurt them until that is done, we should start training them as early as
possible.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: A Large Angry SCM @ 2009-11-25 22:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vmy2as319.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:
>>
>>> So I think the posted patch alone without changing anything else
would be
>>> the approach to give the most benefit with the least impact to existing
>>> users, at least for now.
>> Yes, I meant to say in my original message but forgot to: I think
>> --full-tree is an important first step, no matter what happens next. It
>> gives people a way to do what they want without typing the right number
>> of ".."s, and it opens up --no-full-tree if the default changes later.
>>
>> But I do worry about it being a command-line option. You are asking the
>> user to remember to type --full-tree every time.
>
> We could redefine get_pathspec() to treat a pathspec that begins with a
> slash to be anchored at the top, i.e.
>
> $ git grep -e frotz /
>
> would be a nicer way to spell
>
> $ git grep --full-tree -e frotz
>
> and allows you more than what you can do with --full-tree, e.g.
>
> $ cd linux/subtree/some/very/deep/subdir/you/do/not/remember/exactly
> $ git grep -e frotz /linux/subtree
>
> If we do that, it will not be limited to "grep" but would bring
uniformity
> to the command set [*1*]. Of course, you can keep doing
>
> $ cd t
> $ git grep -e frotz .
>
> to look inside only the current directory, and once this new
convention is
> accepted and widely used, it would become possible to flip the default
> without causing too much pain (yes, I am agreeing with you that this
is an
> important first step).
>
> Once there is a convenient and uniform way to ask for either
behaviour, no
> matter what the default is, the scripts that want specific behaviour can
> be updated to choose whichever they want, given enough time (say, 2.0.0).
>
Speaking as a `grep' user: having git-grep behave radically different
than normal grep would be/is very annoying [*1*].
Speaking as a `git' user: having the different git commands use
radically different path conventions, relative to other git commands,
would be/is very annoying [*1*].
To make the reconciliation even more difficult, some git commands will
also work on out-of-tree paths.
Footnotes:
[*1*] And surprising to new/occasional git users.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: James Pickens @ 2009-11-25 22:12 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091125214949.GA31473@coredump.intra.peff.net>
On Wed, Nov 25, 2009 at 2:49 PM, Jeff King <peff@peff.net> wrote:
> I'm not sure I really understand. "git grep" is routinely producing
> wrong results for me _now_. I'd like to configure it so that it produces
> results more sensible to me. If I am the one who sets the configuration
> variable to something more sensible for my workflow, who am I hurting?
Config options are not free - they add code bloat, increase the maintenance
and testing burden, make it harder to explain how Git works if you have to
say things like "if config X is true, then Git does ..., otherwise Git does
..., unless config Y is false, in which case Git does ...", make it harder
to debug when Git doesn't do what you expected if you have to check a bunch
of configs to figure out what the behavior should be, and make it harder to
develop new features since you have to consider how they might interact with
lots of config options. So I think the bar for adding config options,
especially ones that fundamentally change user visible behavior, should be
set pretty high, and this one doesn't even come close to getting over the
bar.
I like Junio's suggestion to make paths starting with / anchored to the
top. If that were added then it would be easy for users to tell Git what
they want; they just have to use the right pathspec, which I think is a
very reasonable requirement.
That's my 2 cents....
James
^ permalink raw reply
* Please help with GIT install problem.
From: Stephan T. @ 2009-11-25 22:07 UTC (permalink / raw)
To: git
Hello there,
My system is a:
% uname -a
Linux naboo 2.4.21-50.ELsmp #1 SMP Tue May 8 17:18:29 EDT 2007 i686 i686 i386 GNU/Linux
Trying to install "git-1.6.5.3". Configure goes happily to the end but make gives me the following error:
> make
CC fast-import.o
In file included from /usr/include/openssl/ssl.h:179,
from git-compat-util.h:138,
from builtin.h:4,
from fast-import.c:143:
/usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory
In file included from /usr/include/openssl/ssl.h:179,
from git-compat-util.h:138,
from builtin.h:4,
from fast-import.c:143:
/usr/include/openssl/kssl.h:134: syntax error before "krb5_enctype"
What is missing on my system?
Thanks for your help,
Stephan.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmy2as319.fsf@alter.siamese.dyndns.org>
On Wed, Nov 25, 2009 at 01:33:22PM -0800, Junio C Hamano wrote:
> We could redefine get_pathspec() to treat a pathspec that begins with a
> slash to be anchored at the top, i.e.
>
> $ git grep -e frotz /
>
> would be a nicer way to spell
>
> $ git grep --full-tree -e frotz
I do like that idea (and I cannot see any obvious flaw in it, though I
have only been think for a few minutes). I am not sure how useful it
will be for other commands. Conceptually I might use it for "diff" and
"status" (the new version that uses pathspecs sanely :) ), but those
commands generally aren't a big deal. I haven't touched anything in the
uninteresting subtree, so there is nothing to report.
Hmm. Actually, after having considered that, don't we actually allow
absolute paths in diff to do out-of-tree diffs? I haven't looked at how
that code interacts with get_pathspec.
> > Certainly I think that would be an improvement. But again, it suffers
> > from the "you must remember to do this" as above. I really want "git
> > grep" to Do What I Mean.
>
> And /this-is-absolute is one way to tell "grep" What You Mean. I do not
> claim it would be the _best_ way (I just concocted it up a few minutes ago
> without giving it deep thought). Do you have a better alternative in
> mind?
Well, what I meant is that I shouldn't have to tell it each time what I
mean. I should be able to set up configuration so that it does what I
want (well, ideally, it would just read my mind, but I am willing to
concede that point). That is, I don't want to have to remember "git grep
--full-tree" or "git grep /" every time, because I am not likely to
notice when I forget. I want to set up "when I am in this directory,
this is probably what I want".
> My earlier "push is excusable" was primarily because "push" tends to be
> the _final_ action in the chain of events, as opposed to "ls-files" and
> "grep" output that are meant to be used by the user to _decide_ what to
> do next depending on what they find, and as such, the latter has more
> problem if they changed behaviour based on the configuration.
I'm not sure I really understand. "git grep" is routinely producing
wrong results for me _now_. I'd like to configure it so that it produces
results more sensible to me. If I am the one who sets the configuration
variable to something more sensible for my workflow, who am I hurting?
-Peff
^ permalink raw reply
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Junio C Hamano @ 2009-11-25 21:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Stephen Boyd, git
In-Reply-To: <200911252155.59318.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> It was 'Unspecified error.' shown in xhr watch. Accessing xhr.status
> causes an error.
As to the topic, it does not seem to break _existing_ features; if that is
not the case, please let me know.
Otherwise I'm inclined to merge the entire series to 'master' by 1.6.6-rc1.
6821dee gitweb.js: fix padLeftStr() and its usage
6aa2de5 gitweb.js: Harden setting blamed commit info in incremental blame
e42a05f gitweb.js: fix null object exception in initials calculation
63267de gitweb: Minify gitweb.js if JSMIN is defined
c4ccf61 gitweb: Create links leading to 'blame_incremental' using JavaScript
e206d62 gitweb: Colorize 'blame_incremental' view during processing
4af819d gitweb: Incremental blame (using JavaScript)
aa7dd05 gitweb: Add optional "time to generate page" info in footer
-aef3768 gitweb: Use light/dark for class names also in 'blame' view
and treat it as a new feature with known breakages, to give it wider
audience. That way you will hopefully get more people who are willing to
help debug/fix things for you.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-25 21:33 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091125210034.GC18487@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:
>
>> So I think the posted patch alone without changing anything else would be
>> the approach to give the most benefit with the least impact to existing
>> users, at least for now.
>
> Yes, I meant to say in my original message but forgot to: I think
> --full-tree is an important first step, no matter what happens next. It
> gives people a way to do what they want without typing the right number
> of ".."s, and it opens up --no-full-tree if the default changes later.
>
> But I do worry about it being a command-line option. You are asking the
> user to remember to type --full-tree every time.
We could redefine get_pathspec() to treat a pathspec that begins with a
slash to be anchored at the top, i.e.
$ git grep -e frotz /
would be a nicer way to spell
$ git grep --full-tree -e frotz
and allows you more than what you can do with --full-tree, e.g.
$ cd linux/subtree/some/very/deep/subdir/you/do/not/remember/exactly
$ git grep -e frotz /linux/subtree
If we do that, it will not be limited to "grep" but would bring uniformity
to the command set [*1*]. Of course, you can keep doing
$ cd t
$ git grep -e frotz .
to look inside only the current directory, and once this new convention is
accepted and widely used, it would become possible to flip the default
without causing too much pain (yes, I am agreeing with you that this is an
important first step).
Once there is a convenient and uniform way to ask for either behaviour, no
matter what the default is, the scripts that want specific behaviour can
be updated to choose whichever they want, given enough time (say, 2.0.0).
> Certainly I think that would be an improvement. But again, it suffers
> from the "you must remember to do this" as above. I really want "git
> grep" to Do What I Mean.
And /this-is-absolute is one way to tell "grep" What You Mean. I do not
claim it would be the _best_ way (I just concocted it up a few minutes ago
without giving it deep thought). Do you have a better alternative in
mind?
> I have to wonder: is "git grep" really plumbing or porcelain? It is
> really just a wrapper for
>
> git ls-files | xargs grep
>
> Do people actually use it in their scripts? Should they be?
The issue is not necessarily "scripts", but "what people use the output
for".
My earlier "push is excusable" was primarily because "push" tends to be
the _final_ action in the chain of events, as opposed to "ls-files" and
"grep" output that are meant to be used by the user to _decide_ what to
do next depending on what they find, and as such, the latter has more
problem if they changed behaviour based on the configuration.
[Footnote]
*1* It won't be only get_pathspec(), but we would also need to teach
verify_filename() and verify_non_filename() about the new convention.
^ permalink raw reply
* Re: [egit] Git repository with multiple eclipse projects ?
From: Robin Rosenberg @ 2009-11-25 21:27 UTC (permalink / raw)
To: Yann Dirson; +Cc: git, egit-dev
In-Reply-To: <20091125164734.GF21347@linagora.com>
onsdag 25 november 2009 17:47:34 skrev Yann Dirson:
> I am investigating whether it is possible at all to have several
> eclipse projects in a single git repo, and have those projects
> correctly seen as managed by git.
>
> When importing a git repo into eclipse, we get a list of projects to
> import, but that list is empty. What is expected by egit to get this
> list filled ?
Both Egit and Jgit themselves have multiple projects in the same repo.
All projects must be located in the same directory structure.
repo/.git
|`--project1/.git
|`--project2
etc
Other variations are possible.
>
> It also does not look like it would be possible to use the "share"
> functionnality to setup such a repository from multiple projects (or
> from a project set), right ?
Share only tells Eclipse to attach EGit as the team provider, provided
it is located in a git repo, or lets you create a repo if none exists.
-- robin
^ permalink raw reply
* Re: jgit problems for file paths with non-ASCII characters
From: Robin Rosenberg @ 2009-11-25 21:11 UTC (permalink / raw)
To: Marc Strapetz; +Cc: git, egit-dev
In-Reply-To: <4B0D356D.1080709@syntevo.com>
onsdag 25 november 2009 14:47:25 skrev Marc Strapetz:
> I have noticed that jgit converts file paths to UTF-8 when querying the
> repository. Especially,
> org.eclipse.jgit.treewalk.filter.PathFilter#PathFilter performs this
> conversion:
>
> private PathFilter(final String s) {
> pathStr = s;
> pathRaw = Constants.encode(pathStr);
> }
>
> Because of this conversion, a TreeWalk fails to identify a file with
> German umlauts. When using platform encoding to convert the file path to
> bytes:
>
> private PathFilter(final String s) {
> pathStr = s;
> pathRaw = s.getBytes();e pr
> }
>
> the TreeWalk works as expected. Actually, the file path seems to be
> stored with platform encoding in the repository.
>
> Is this a bug or a misconfiguration of my repository? I'm using jgit
> (commit e16af839e8a0cc01c52d3648d2d28e4cb915f80f) on Windows.
A bug.
The problem here is that we need to allow multiple encodings since there
is no reliable encoding specified anywhere. The approach I advocate is
the one we use for handling encoding in general. I.e. if it looks like UTF-8,
treat it like that else fallback. This is expensive however and then we have
all the other issues with case insensitive name and the funny property that
unicode has when it allows characters to be encoding using multiple sequences
of code points as empoloyed by Apple.
-- robin
-- robin
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 21:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqcytjic.fsf@alter.siamese.dyndns.org>
On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:
> So I think the posted patch alone without changing anything else would be
> the approach to give the most benefit with the least impact to existing
> users, at least for now.
Yes, I meant to say in my original message but forgot to: I think
--full-tree is an important first step, no matter what happens next. It
gives people a way to do what they want without typing the right number
of ".."s, and it opens up --no-full-tree if the default changes later.
But I do worry about it being a command-line option. You are asking the
user to remember to type --full-tree every time. I can't count the
number of times I have been in a subdirectory and done "git grep foo",
spent some time analyzing and doing something with the results, only for
my palm to hit my forehead when I realize that I was missing half of the
results I wanted. In other words, I not only have to remember to use the
option, but when I forget, I may get punished very annoyingly by results
which are subtly different from what I want.
So I am in favor of taking it further, but even if we do, the
command-line option is the right thing to be doing _now_.
> "git grep -e frotz .." will work in your "from linux/subproject/t look for
> everywhere in linux/subproject", but if "/t" part were much longer and
> variable (iow you need to chdir around inside linux/subproject to scratch
> your itch) compared to "linux/subproject" part that is much shorter and
> static (to your work), it may make sense to give us a mode to specify
> pathspec from the top of the tree.
>
> $ cd linux/subproject
> $ cd foo
> $ cd bar
> $ cd baz
> $ git grep --absolute-pathspec -e frotz -- linux/subproject
>
> As "git grep" never takes absolute paths, we _might_ be able to also do
>
> $ git grep -e frotz -- /linux/subproject
>
> to achieve the same.
Certainly I think that would be an improvement. But again, it suffers
from the "you must remember to do this" as above. I really want "git
grep" to Do What I Mean.
I have to wonder: is "git grep" really plumbing or porcelain? It is
really just a wrapper for
git ls-files | xargs grep
Do people actually use it in their scripts? Should they be?
-Peff
^ permalink raw reply
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Jakub Narebski @ 2009-11-25 20:55 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <200911251536.08993.jnareb@gmail.com>
On Wed, 25 Nov 2009, Jakub Narebski wrote:
> On Wed, 25 Nov 2009 05:01, Stephen Boyd wrote:
> > Jakub Narebski wrote:
> > >
> > > Debugging this is serious PITA. After fix below it appears that this bug
> > > is some intermittent bug, depending on XMLHttpRequest timing. It more
> > > often than not (at least when I tried to debug it using build-in IE8
> > > debugger) works correctly for the folowing files: README, GIT-VERSION-GEN,
> > > revision.c (once even it did fail when first running for given file, and
> > > then running correctly when reloading from debugger; fun it is not).
> > >
> > > It does consistently fail for gitweb/gitweb.perl... but when I tried
> > > to debug it IE8 would hang up when trying to use debugger (with around
> > > 600MB available RAM). Perhaps somebody else would have more luck...
> >
> > Interesting. I don't have time to look into this until early December,
> > but if it's still around then I'll take a look. I wonder if IE6 or IE7
> > works (I don't think everyone is on version 8 yet).
>
> Well, the one time I was able to run debugger (F12, select 'Script', select
> 'gitweb.js') with error occurring
The error was "Unspecified error", char:2 in the mentioned line
> and without IE hanging (for README file) it did show an error for the
> following line:
>
> if (xhr.readyState === 3 && xhr.status !== 200) {
>
> When I checked 'xhr' object, it has "Unknown error" as contents of
> xhr.statusText field and as contents of xhr.status (sic!), which should
> be a number: HTTP status code.
It was 'Unspecified error.' shown in xhr watch. Accessing xhr.status
causes an error.
This might be cause by the fact that xhr (XMLHttpRequest object, or as IE8
shows it in JScript debugger DispHTMLXMLHttpRequest object) is not fully
initialized, or something; gitweb.js calls handleResponse() also from
a timer, to work around the fact that some web browsers onreadystatechange
handler is called only once for each state, and not as soon as new data
is available from server.
Longer term solution would be to use onprogress handler if it is available;
if it is available we don't need trick with calling handleResponse from
timer, as XMLHttpRequest 2.0 proposed specification ensures calling callback
as soon as new data is available.
Short term solution would be to wrap access to xhr.status in try ... catch
block for IE8... although I am a bit reluctant to implement this workaround
bugs in IE8.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, git
In-Reply-To: <7vr5rmwgbn.fsf@alter.siamese.dyndns.org>
On Wed, Nov 25, 2009 at 11:32:44AM -0800, Junio C Hamano wrote:
> But if a command like "grep" that "does one small thing and do it well"
> changes its behaviour drastically depending on a config variable or an
> environment variable, it won't be a command that you can rely upon any
> more in your scripts and hooks. It's the same insanity as GREP_OPTIONS
> environment variable.
I know this is the attitude we have taken in the past, and I am worried
it is part of what hurts the usability of git. Just consider for a
moment: git grows some feature with a default behavior X. Time passes.
Some people like behavior Y instead. How can we help the people who like
Y?
1. Declare Y better than X, and default to it. This hurts people who
like X. It also hurts scripts built around X.
2. Add a config option to switch the behavior to Y. This hurts people
or scripts unexpectedly using somebody's configuration with Y.
3. Add a --Y command line option. Now the Y people have to remember to
use that option. Every single time they invoke the command.
4. Tell them to alias "git foo-y" to "git foo --Y". IMHO, this is
completely unscalable. They can't just call it "foo", so they have
to remember to invoke "foo-y" each time. And when they forget,
instead of getting an error, they get the X behavior. Furthermore,
as time goes on, they basically develop a vocabulary of git
commands that is totally unlike anybody else's, making their
scripts and git knowledge unportable to other people's setups (sort
of like in (2) above).
So as a Y user, what is the impression of git that I am left with? It
doesn't do what I want unless I remember an option every time, or create
an arcane pseudo-porcelain interface through my set of aliases. Patches
to fix the situation are blocked by compatibility issues. Y users remain
frustrated indefinitely.
I know that (1) and (2) have their problems. But I think by not giving a
little on those compatibility issues, we end up with an equally bad or
worse outcome. In other words, I think in this case that (2) may be the
lesser of many evils.
-Peff
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-25 20:52 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091125203922.GA18487@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Nov 24, 2009 at 12:56:32AM -0800, Junio C Hamano wrote:
>
>> * In http://article.gmane.org/gmane.comp.version-control.git/111717, I
>> once argued in the opposite way, but I think it is Ok to aim for making
>> the default --full-tree in the longer run (cf. $gmane/127885). This is
>> the first step in that direction.
>
> Ironically, I argued for --full-tree behavior in the same thread, but
> have since softened my view. What I have come to realize is that (for
> me, anyway) it is very dependent on the organization of the project you
> are working on.
I was against --full-tree but wished for it when I dipped my toe into
somebody else's project and my itch lived in a directory a few levels
deep, while the infrastructure the files in the directory uses were spread
across global include directory and platform implementations [*1*].
And I agree that the preferred behaviour depends largely on both the
project and what kind of change you are currently scratching.
So I think the posted patch alone without changing anything else would be
the approach to give the most benefit with the least impact to existing
users, at least for now.
> 2. It would be useful to have a "partial-tree" middle ground. In other
> words, if I am in "linux/subproject/t", I would find it most
> useful if "git grep" searched all of "linux/subproject".
"git grep -e frotz .." will work in your "from linux/subproject/t look for
everywhere in linux/subproject", but if "/t" part were much longer and
variable (iow you need to chdir around inside linux/subproject to scratch
your itch) compared to "linux/subproject" part that is much shorter and
static (to your work), it may make sense to give us a mode to specify
pathspec from the top of the tree.
$ cd linux/subproject
$ cd foo
$ cd bar
$ cd baz
$ git grep --absolute-pathspec -e frotz -- linux/subproject
As "git grep" never takes absolute paths, we _might_ be able to also do
$ git grep -e frotz -- /linux/subproject
to achieve the same.
[Footnote]
*1* It's rockbox, if you need to know.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Sverre Rabbelier @ 2009-11-25 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd436uzet.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Nov 25, 2009 at 21:23, Junio C Hamano <gitster@pobox.com> wrote:
> But then you can alias "gr 'grep --full-tree'" with the same ease and
> there is no reason to change the default.
I agree, but then again I'm somewhat biased, as I want the current behavior :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk4xggv27.fsf@alter.siamese.dyndns.org>
On Tue, Nov 24, 2009 at 12:56:32AM -0800, Junio C Hamano wrote:
> * In http://article.gmane.org/gmane.comp.version-control.git/111717, I
> once argued in the opposite way, but I think it is Ok to aim for making
> the default --full-tree in the longer run (cf. $gmane/127885). This is
> the first step in that direction.
Ironically, I argued for --full-tree behavior in the same thread, but
have since softened my view. What I have come to realize is that (for
me, anyway) it is very dependent on the organization of the project you
are working on.
For git.git, and most of my small-ish other projects, I want "git grep"
to search the full tree. But recently, I have been working on a
large-ish project imported from svn where the parts of interest to me
are rooted two directories deep (i.e., I am working in
"linux/subproject/", and I don't care at all what's happening in
"windows/otherproject"). I don't want grep hits from the other area to
clutter my output, and I especially don't want to waste time hitting the
disk for those pages, which are an order of magnitude larger than the
working set of files that are actually of interest to me.
On top of that, I think there are two ways within a logical subproject
to use subdirectories. In git.git, I tend to actually chdir into
Documentation/ or t/, because they have their own Makefiles. But for a
project that organizes its code into a bunch of module subdirectories
all driven by a top-level non-recursive Makefile, I tend to stay at the
root and actually do "vi module/foo.c; make".
So what that tells me is:
1. It is not necessarily the _developer_, but a combination of
developer and project that decides which behavior (of --full-tree
and the current behavior) is more useful. Which to me really points
to the utility of a config option.
2. It would be useful to have a "partial-tree" middle ground. In other
words, if I am in "linux/subproject/t", I would find it most
useful if "git grep" searched all of "linux/subproject".
Implementing that would become much more complex, though. Probably
the user would specify a list of rooted subprojects, and we would
prefix-match our path to find which one we were in, and then
do a full-tree grep on that subtree.
And yes, this is somewhat an argument in favor of splitting the
project into submodules. But I'd really rather not do that. They
introduce significant complexity, and the rest of git is so _good_
at ignoring uninteresting parts.
-Peff
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-25 20:23 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911251219t3ad0dacen67d8615ef6eefa02@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Wed, Nov 25, 2009 at 20:32, Junio C Hamano <gitster@pobox.com> wrote:
>> The standard answer given by others has been "you can always say '.' at
>> the end; having to remember/count number of ../ necessary is much much
>> more inconvenient".
>
> A commandline flag to keep the old behavior then perhaps? "git config
> alias.gr 'grep --no-full-tree'" is not that hard to write either.
But then you can alias "gr 'grep --full-tree'" with the same ease and
there is no reason to change the default.
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Junio C Hamano @ 2009-11-25 20:20 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Nanako Shiraishi, Marc Fournier, git
In-Reply-To: <32541b130911251148v70a5dc77k9936881d0b382ec2@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
>> Look at http://github.com/gitster/git/commits/jc/merge-theirs/
>
> I also tried simply searching for things like 'git "-xsubtree"' in
> google, with no luck. But thanks for the link.
I didn't _find_ the link ;-) I just pushed it out a few minutes ago,
after looking for strings that appear in messages of these commits. The
series was done over a few weeks, and would have been very painful to find
from the gmane archive.
> - What was the reason this never got merged? What changes are needed
> to rectify that?
I do not remember there was any real reason. I do remember some people
didn't like -X<option> syntax but I don't think there was any solid
counterproposal to achieve a similar goal to satisfy the need to pass
arbitrary parameters to the merge strategy backends.
> - Considering the earlier discussion, do we want to leave out the
> actual -Xtheirs feature and just have -Xours and -Xsubtree?
Both -Xtheirs and -Xours have the same degree of badness in the context of
"source code management", but there was a real-world use case that would
have benefitted from -Xours recently.
cf. http://thread.gmane.org/gmane.comp.version-control.git/131902/focus=132920
If -Xours goes in, so should -Xtheirs, I think, because Peter's "web tree"
example could merge in both ways (i.e. he could be pulling from web tree
into his private area and then cleaning things up before pushing the
result back).
> - If I rebase them and the changes turn out to be minimal, do they
> still need a signed-off-by Junio?
"minimal" by definition means that you ased your work on mine and I still
have the copyright to the change as a co-author together with you. We
both need to certify that the change is made under DCO.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Sverre Rabbelier @ 2009-11-25 20:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5rmwgbn.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Nov 25, 2009 at 20:32, Junio C Hamano <gitster@pobox.com> wrote:
> The standard answer given by others has been "you can always say '.' at
> the end; having to remember/count number of ../ necessary is much much
> more inconvenient".
A commandline flag to keep the old behavior then perhaps? "git config
alias.gr 'grep --no-full-tree'" is not that hard to write either.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [egit] Git repository with multiple eclipse projects ?
From: Yann Simon @ 2009-11-25 19:53 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20091125164734.GF21347@linagora.com>
Le mercredi 25 novembre 2009 à 17:47 +0100, Yann Dirson a écrit :
> It also does not look like it would be possible to use the "share"
> functionnality to setup such a repository from multiple projects (or
> from a project set), right ?
The last time I worked with egit, it was not yet implemented.
Yann
^ 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