* 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: 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: [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: [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: [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: 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
* 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: 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
* 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: 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: 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: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: 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: 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: [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: 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:43 UTC (permalink / raw)
To: gitzilla; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <4B0DB04A.6020209@gmail.com>
A Large Angry SCM wrote:
> 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.
s/my system of choice/the user's system of choice/
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Andreas Schwab @ 2009-11-25 22:43 UTC (permalink / raw)
To: Thomas Singer; +Cc: Daniel Barkalow, git
In-Reply-To: <4B0CEFCA.5020605@syntevo.com>
Thomas Singer <thomas.singer@syntevo.com> writes:
> I've did following:
>
> toms-mac-mini:git-umlauts tom$ ls
> Überlänge.txt
> toms-mac-mini:git-umlauts tom$ git status
> # On branch master
> #
> # Initial commit
> #
> # Changes to be committed:
> # (use "git rm --cached <file>..." to unstage)
> #
> # new file: "U\314\210berla\314\210nge.txt"
> #
> toms-mac-mini:git-umlauts tom$ git stage "U\314\210berla\314\210nge.txt"
> fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
Try $'U\314\210berla\314\210nge.txt' instead.
"U\314\210berla\314\210nge.txt" is the same as
"U\\314\\210berla\\314\\210nge.txt" to the shell.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] tests: rename duplicate t1009
From: Jeff King @ 2009-11-25 22:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
We should avoid duplicate test numbers, since things like
GIT_SKIP_TESTS consider something like t1009.5 to be
unambiguous.
Signed-off-by: Jeff King <peff@peff.net>
---
This is on top of the nd/sparse topic.
As an aside, that diffstat is really unreadable. I'm not sure how to do
better without dropping the rename information, though.
...ckout.sh => t1011-read-tree-sparse-checkout.sh} | 0
1 files changed, 0 insertions(+), 0 deletions(-)
rename t/{t1009-read-tree-sparse-checkout.sh => t1011-read-tree-sparse-checkout.sh} (100%)
diff --git a/t/t1009-read-tree-sparse-checkout.sh b/t/t1011-read-tree-sparse-checkout.sh
similarity index 100%
rename from t/t1009-read-tree-sparse-checkout.sh
rename to t/t1011-read-tree-sparse-checkout.sh
--
1.6.6.rc0.249.g9b4cf.dirty
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 22:53 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, git
In-Reply-To: <4B0DB29D.5010101@gmail.com>
On Wed, Nov 25, 2009 at 05:41:33PM -0500, A Large Angry SCM wrote:
> >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.
It is tempting to have scripts simply set a GIT_VANILLA environment
variable to ignore config options. But I think it is not quite so
simple. As a script, if I am calling "git log", do I want it to respect
the user's colorization config or not? It depends on _how_ I am calling
it. Is the output to be shown to the user, or am I going to process it
myself?
Similarly, why is the script calling "git grep"? If it is because the
script is a convenience wrapper (e.g., let's say to colorize the output
in a particular way), then it probably wants to respect my configured
choice of which files to grep. But if the script is just using "git
grep" to get data to perform some other calculation, then it probably
does care deeply about which set of files to grep.
So I think you have situations where scripts do want to invoke the
porcelain version of a command versus the plumbing. But much harder, you
have ones where they want to respect some options but not others.
-Peff
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Wincent Colaiuta @ 2009-11-25 22:26 UTC (permalink / raw)
To: James Pickens; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <885649360911251412n3e566c8fu536b361b993f2ac6@mail.gmail.com>
El 25/11/2009, a las 23:12, James Pickens escribió:
> I like Junio's suggestion to make paths starting with / anchored to
> the
> top.
Oh, I wouldn't like that at all. I think it would be a very ugly UI
wart, because it would basically make Git behave differently than
every other command line tool that accepts paths. If it is to deviate
from the extremely widespread convention that paths starting with /
refer to absolute paths rooted at the root of the filesystem, then the
justification for it would need to be very strong indeed.
Cheers,
Wincent
^ permalink raw reply
* Re: cvsexportcommit dies when applying an (empty) merge commit
From: Nick Woolley @ 2009-11-25 23:00 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B0D2BC5.1000002@drmicha.warpmail.net>
Michael J Gruber wrote:
> I think the behavior is correct in the sense that you're telling git
> cvsexportcommit to make a commit to cvs, and it can't, because there is
> no change to commit. A merge can't be represented.
The main problem with this is that by default it aborts the whole process with
an error. I'd prefer a non-fatal warning rather than having to catch the error
and decide if it's ignorable or not, although for now I guess I'll have to, or
make a fork of git-cvsexportcommit.
CVS doesn't has an --allow-empty equivalent I know of, and nor does
git-cvsexportcommit.
Cheers,
N
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: A Large Angry SCM @ 2009-11-25 23:07 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091125225318.GA10127@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Nov 25, 2009 at 05:41:33PM -0500, A Large Angry SCM wrote:
>
>>> 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.
>
> It is tempting to have scripts simply set a GIT_VANILLA environment
> variable to ignore config options. But I think it is not quite so
> simple. As a script, if I am calling "git log", do I want it to respect
> the user's colorization config or not? It depends on _how_ I am calling
> it. Is the output to be shown to the user, or am I going to process it
> myself?
>
> Similarly, why is the script calling "git grep"? If it is because the
> script is a convenience wrapper (e.g., let's say to colorize the output
> in a particular way), then it probably wants to respect my configured
> choice of which files to grep. But if the script is just using "git
> grep" to get data to perform some other calculation, then it probably
> does care deeply about which set of files to grep.
>
> So I think you have situations where scripts do want to invoke the
> porcelain version of a command versus the plumbing. But much harder, you
> have ones where they want to respect some options but not others.
<semi rhetorical>
So, what's the solution?
Have every command command take a list of configuration options to
ignore/respect?
Have every command take an option to ignore/respect _all_ configuration
options?
Have inconsistency between commands, like we have now
Have commands have all kinds of hidden/undocumented default settings?
</semi rhetorical>
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Johannes Schindelin @ 2009-11-25 23:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, Nanako Shiraishi, Marc Fournier, git
In-Reply-To: <7vpr76uzju.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 25 Nov 2009, Junio C Hamano wrote:
> 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.
I took exception to the awkward way to specify the option. A strong hint
just how awkward -X<option> is: it is hard to implement using
parse-options.
There is no real reason to do it properly, i.e. with an option
--merge-option <option> or --backend-option <option> or -X <option> (even
if "-X" is not really an expressive name, to be real honest).
BTW the same goes for -S<string>, but unfortunately, we have to keep it
to maintain backwards compatibility.
Ciao,
Dscho
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Avery Pennarun @ 2009-11-25 23:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nanako Shiraishi, Marc Fournier, git
In-Reply-To: <alpine.DEB.1.00.0911260013550.4985@pacific.mpi-cbg.de>
On Wed, Nov 25, 2009 at 6:17 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Wed, 25 Nov 2009, Junio C Hamano wrote:
>> 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.
>
> I took exception to the awkward way to specify the option. A strong hint
> just how awkward -X<option> is: it is hard to implement using
> parse-options.
I read the earlier thread and I still don't quite understand this
point. What makes it difficult? X seems just like any other option
that takes a string parameter (which is easily supported by getopt at
least; I haven't played with parse_options but I certainly hope it's
as good as getopt).
The string parameter (say, $x) is translated directly into "--$x" and
passed as exactly one argument of the argv array to the subprogram.
Easy, right? Plus Junio already wrote a patch to do it (which I'm in
the process of forward-porting) and it seems pretty straightforward.
Perhaps I'm missing something.
Thanks,
Avery
^ 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