* Re: First round of UGFWIINI results
From: Sverre Rabbelier @ 2009-03-03 16:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Reece Dunn, git
In-Reply-To: <7vljrmd24n.fsf@gitster.siamese.dyndns.org>
Heya,
On Tue, Mar 3, 2009 at 17:04, Junio C Hamano <gitster@pobox.com> wrote:
> Are you also in the contest, with your blog as one of the contenders?
I remember Dscho saying anything mentioned in the announcement does
not count, but upon later inspection of the original post I cannot
find it...?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC] Refspec patterns with * in the middle
From: David Kastrup @ 2009-03-03 16:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vsklvlcyy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> The issue, in my case, is importing from a system where branches contain
>> projects instead of projects containing branches (and everything is a
>> single namespace). So I want to match an insane (for us) LHS with a sane
>> RHS to get stuff into reasonable shape. I don't really care about any
>> patterns where the branch identifier is multiple components, but I
>> wouldn't be surprised if somebody did.
>
> Isn't this just getting more and more insane? Is this really worth
> supporting, I have to wonder...
>
>> Oh, and it looks like "?" is reserved and currently unused, so we could
>> have * match one or more full path components, and ? match partial path
>> components.
>
> Well, "?" is not allowed exactly because it often is used to match a
> single character by things like for-each-ref.
Let me present a use case where the current matching rules have changed
working well at some point of time.
We have a product called dsp which sits in Subversion under the top
server repository as
dsp/{trunk,branches,tags}
Then we have projects that have a structure including
projekte/some-project/{trunk,branches,tags}/dsp
which usually is an external link to dsp/trunk. However, sometimes a
project needs its own local variations of dsp, in which case
projekte/some-project/trunk/dsp becomes a properly populated copy of
dsp/trunk.
Now in git, I want to track those non-externals as branches of the dsp
checkout: that way I get cherry-picking and merging and stuff like that.
To have this work out, I need to have the dsp git project pulling stuff
from any projekte/some-project/trunk/dsp as a branch called
some-project.
I had a git-svn configuration at one point of time that did that, but
the matching rules have changed since then.
So in this case, the existing Subversion structure (which makes quite
good sense) makes wildcards in non-terminal positions desirable.
--
David Kastrup
^ permalink raw reply
* Re: git log -Sfoo ignores indentation (whitespace?) changes...
From: Jeff King @ 2009-03-03 16:25 UTC (permalink / raw)
To: Michael J Gruber; +Cc: "Peter Valdemar Mørch (Lists)", git
In-Reply-To: <49AD547E.7030703@drmicha.warpmail.net>
On Tue, Mar 03, 2009 at 05:02:06PM +0100, Michael J Gruber wrote:
> > but what it actually does is find changes where the string was introduced
> > or removed. So it literally counts the number of occurences before and
> > after the commit, and the commit is interesting if they are not equal.
>
> Hmm. The diffcore doc sounds more like if the filepair is picked if
> #before > 0 and #after = 0, but not if #after > 0.
Nope, the code is #before != #after. There are some special cases around
deleted and unmerged files, but the obvious one is:
$ sed -n 89,92p diffcore-pickaxe.c
else if (!diff_unmodified_pair(p) &&
contains(p->one, needle, len, regexp) !=
contains(p->two, needle, len, regexp))
has_changes++;
So maybe the diffcore documentation needs to be clarified.
> In any case, the pickaxe can't detect moving around of strings, right?
No, it won't (and see my other mail elsewhere in the thread for why that is
actually hard to define).
-Peff
^ permalink raw reply
* Re: [PATCH v3] send-email: add --confirm option and configuration setting
From: Jay Soffian @ 2009-03-03 16:22 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git, Nanako Shiraishi, Junio C Hamano, Paul Gortmaker
In-Reply-To: <36ca99e90903030354j33de0313n41d8a95ff898798b@mail.gmail.com>
On Tue, Mar 3, 2009 at 6:54 AM, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> On Tue, Mar 3, 2009 at 05:52, Jay Soffian <jaysoffian@gmail.com> wrote:
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index adf7ecb..57127aa 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -837,6 +837,37 @@ X-Mailer: git-send-email $gitversion
>> unshift (@sendmail_parameters,
>> '-f', $raw_from) if(defined $envelope_sender);
>>
>> + if ($needs_confirm && !$dry_run) {
> So, the output is now differnt with and without --dry-run?
There doesn't seem to be any point in having the user confirm before
sending the message if the message is not actually going to be sent.
Am I missing something?
j.
^ permalink raw reply
* Re: [PATCH] doc: clarify how -S works
From: John Tapsell @ 2009-03-03 16:22 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Peter Valdemar Mørch (Lists), git
In-Reply-To: <20090303161934.GD32079@coredump.intra.peff.net>
2009/3/3 Jeff King <peff@peff.net>:
> On Tue, Mar 03, 2009 at 04:12:30PM +0000, John Tapsell wrote:
>
>> > To fix it we:
>> >
>> > 1. use "introduce or remove an instance of" instead of
>> > "contain"
>>
>> I would read this to mean that it doesn't include modifying a line
>> containing that string. But I also know that underneath the hood, a
>> change is a remove then an addition, so I would be confused :)
>>
>> What about saying "modifies" rather than "contain" ?
>
> I'm confused. It _doesn't_ include modifying a line containing the
> string. In which case it has done its job. But your "but" after that
> is what leaves me confused. You thought it would mean that, but you
> don't due to some other knowledge, which is leading you down the wrong
> path?
Yes, it would seem that I was also confused as to what -S means. It
doesn't mean what I thought it meant :-)
> I was trying to get away with a short and sweet description. But the
> behavior is basically (with a few optimizations):
>
> if count(a, string) != count(b, string) then
> it is interesting
>
> which is unambiguous, but it takes a second to realize the implications.
>
> -Peff
>
^ permalink raw reply
* Re: git log -Sfoo ignores indentation (whitespace?) changes...
From: Junio C Hamano @ 2009-03-03 16:21 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <49AD5164.8090507@sneakemail.com>
"Peter Valdemar Mørch (Lists)" <4ux6as402@sneakemail.com> writes:
> How sad... From "git log -Sfoo" looking like a really cool feature,
It is a cool feature, but its coolness lies in the other parts of a
Porcelain that is still to be written. See my other message.
^ permalink raw reply
* Re: [PATCH] doc: clarify how -S works
From: Jeff King @ 2009-03-03 16:19 UTC (permalink / raw)
To: John Tapsell; +Cc: Junio C Hamano, Peter Valdemar Mørch (Lists), git
In-Reply-To: <43d8ce650903030812n6fe857atb773f5068b6f0a17@mail.gmail.com>
On Tue, Mar 03, 2009 at 04:12:30PM +0000, John Tapsell wrote:
> > To fix it we:
> >
> > 1. use "introduce or remove an instance of" instead of
> > "contain"
>
> I would read this to mean that it doesn't include modifying a line
> containing that string. But I also know that underneath the hood, a
> change is a remove then an addition, so I would be confused :)
>
> What about saying "modifies" rather than "contain" ?
I'm confused. It _doesn't_ include modifying a line containing the
string. In which case it has done its job. But your "but" after that
is what leaves me confused. You thought it would mean that, but you
don't due to some other knowledge, which is leading you down the wrong
path?
I was trying to get away with a short and sweet description. But the
behavior is basically (with a few optimizations):
if count(a, string) != count(b, string) then
it is interesting
which is unambiguous, but it takes a second to realize the implications.
-Peff
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Jeff King @ 2009-03-03 16:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Reece Dunn, git
In-Reply-To: <alpine.DEB.1.00.0903031658180.6399@intel-tinevez-2-302>
On Tue, Mar 03, 2009 at 04:59:27PM +0100, Johannes Schindelin wrote:
> > Does using Git to track edits when proofreading a html/text document
> > (short story, novel, ...) count?
>
> I'll count it, but I want (read-only) access to the repository as a proof
> that you actually use Git that way ;-)
Is it really that unusual? I've been keeping academic papers in git for
years (and CVS before that -- blech), and I'm sure I'm not alone. Of
course I'm writing in LaTeX, which is arguably a programming language. ;)
BTW, --color-words is indispensable when dealing with things that aren't
line-oriented.
-Peff
^ permalink raw reply
* Re: proper way to merge?
From: Johannes Sixt @ 2009-03-03 16:15 UTC (permalink / raw)
To: John Dlugosz; +Cc: Bryan Donlan, git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E709F075F9@EXCHANGE.trad.tradestation.com>
John Dlugosz schrieb:
> " * Some commands are not yet supported on Windows and excluded from
> the installation; namely: git archimport, git cvsexportcommit, git
> cvsimport, git cvsserver, git filter-branch, git instaweb, git
> send-email, git shell, git svn."
A-ha. If there ever was a reason to exclude filter-branch, then I think
this reason is no more.
> So I wonder why you think it *is* in msysgit? This is the latest
> version from their site.
Because I don't use the msysgit installer, but compile git myself. I have
a working filter-branch.
-- Hannes
^ permalink raw reply
* Re: [PATCH] doc: clarify how -S works
From: John Tapsell @ 2009-03-03 16:12 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Peter Valdemar Mørch (Lists), git
In-Reply-To: <20090303154041.GA31265@coredump.intra.peff.net>
2009/3/3 Jeff King <peff@peff.net>:
> The existing text was very vague about what exactly it means
> for difference to "contain" a change. This seems to cause
> confusion on the mailing list every month or two.
>
> To fix it we:
>
> 1. use "introduce or remove an instance of" instead of
> "contain"
I would read this to mean that it doesn't include modifying a line
containing that string. But I also know that underneath the hood, a
change is a remove then an addition, so I would be confused :)
What about saying "modifies" rather than "contain" ?
>
> 2. point the user to gitdiffcore(7), which contains a more
> complete explanation
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I wonder if "gitdiffcore" is a little scary for new people who just want
> to use "-S", but hopefully point (1) above will get rid of most of the
> confusion, and those who follow the link want to learn all about diff.
>
> Documentation/diff-options.txt | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 813a7b1..9276fae 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -176,7 +176,10 @@ override configuration settings.
> number.
>
> -S<string>::
> - Look for differences that contain the change in <string>.
> + Look for differences that introduce or remove an instance of
> + <string>. Note that this is different than the string simply
> + appearing in diff output; see the 'pickaxe' entry in
> + linkgit:gitdiffcore[7] for more details.
>
> --pickaxe-all::
> When -S finds a change, show all the changes in that
> --
> 1.6.2.rc2.330.gba39e
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: remote branches, and branch names in general
From: Jeff King @ 2009-03-03 16:11 UTC (permalink / raw)
To: John Dlugosz; +Cc: Jakub Narebski, git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E709F075DF@EXCHANGE.trad.tradestation.com>
On Tue, Mar 03, 2009 at 10:52:21AM -0500, John Dlugosz wrote:
> But I wonder if some commands work differently or specifically don't
> look in remotes. I "learned" to qualify everything when I accidently
> created a local branch named pub/xxx instead of using remotes/pub/xxx
> like I intended. I don't remember what that was, but I'm guessing
> that maybe refs that are a destination are different, as you are only
> supposed to change your local stuff. I think that was a "pull"
> command, before I had the automatic argument in the config file.
Yes, the "branch" command deals only with creating things in refs/heads,
which are your local branches (similarly, "git tag" will only deal with
stuff in refs/tags). So "git branch origin/foo" will make a ref
"refs/heads/origin/foo", and "git branch -d origin/foo" will delete
"refs/heads/origin/foo", not "refs/remotes/origin/foo".
But when looking up a ref, the rules are used. So you can say:
git branch master origin/master
which will make "refs/heads/master" from "refs/remotes/origin/master".
-Peff
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Junio C Hamano @ 2009-03-03 16:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Reece Dunn, git
In-Reply-To: <alpine.DEB.1.00.0903031658180.6399@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 3 Mar 2009, Reece Dunn wrote:
>
>> 2009/2/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> > Dear fans of Git,
>> >
>> > a while ago I announced the UGFWIINI contest, a glorious battle of ideas
>> > how to
>> >
>> > Use Git For What It Is Not Indended
>>
>> Does using Git to track edits when proofreading a html/text document
>> (short story, novel, ...) count?
>
> I'll count it, but I want (read-only) access to the repository as a proof
> that you actually use Git that way ;-)
Are you also in the contest, with your blog as one of the contenders?
^ permalink raw reply
* RE: proper way to merge?
From: John Dlugosz @ 2009-03-03 16:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Bryan Donlan, git
In-Reply-To: <49ACDD17.2060601@viscovery.net>
===Re:===
Huh? filter-branch *is* in msysgit. Why do you think it is not?
===end===
Because when I tried it I got " git: 'filter-branch' is not a
git-command. See 'git --help'."
Then I looked in the Git installation directory and did not find any
file with that name. Then I looked at the ReleaseNotes.rtf file in the
top of the Git installation tree and saw,
" * Some commands are not yet supported on Windows and excluded from
the installation; namely: git archimport, git cvsexportcommit, git
cvsimport, git cvsserver, git filter-branch, git instaweb, git
send-email, git shell, git svn."
So I wonder why you think it *is* in msysgit? This is the latest
version from their site.
--John
(please excuse the footer; it's not my idea)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: git log -Sfoo ignores indentation (whitespace?) changes...
From: Jeff King @ 2009-03-03 16:03 UTC (permalink / raw)
To: "Peter Valdemar Mørch (Lists)"; +Cc: git
In-Reply-To: <49AD5164.8090507@sneakemail.com>
On Tue, Mar 03, 2009 at 04:48:52PM +0100, "Peter Valdemar Mørch (Lists)" wrote:
> If a commit removes mention of foo one place and just accidentally
> happens to add foo somewhere completely unrelated then it wouldn't show
> up in the output.
Right. But think for a minute about what it means to "move". If I have:
foo
bar
and then change it to:
bar
foo
Did "foo" move, or did "bar"?
So I'm not sure that what you're asking for is necessarily well-defined.
> Would be neat with a feature that does what I thought -S did tho...
You can do:
git log -z -p | perl -0ne 'print if /^[-+].*string/m' | tr '\0' '\n'
which I think is what you want (show any commit that has changed lines
that contain the string). But of course you will lose colorizing and
automatic paging, and it's a lot slower. And note that whether it finds
the example above will depend on how the diff is generated: did "foo"
move or did "bar"? But in practice it will generally find what you are
looking for.
> Thanks, Jeff, for both the answer and the documentation patch.
You're welcome.
-Peff
^ permalink raw reply
* Re: git log -Sfoo ignores indentation (whitespace?) changes...
From: Michael J Gruber @ 2009-03-03 16:02 UTC (permalink / raw)
To: Jeff King; +Cc: "Peter Valdemar Mørch (Lists)", git
In-Reply-To: <20090303152333.GB24593@coredump.intra.peff.net>
Jeff King venit, vidit, dixit 03.03.2009 16:23:
> On Tue, Mar 03, 2009 at 03:28:08PM +0100, "Peter Valdemar Mørch (Lists)" wrote:
>
>> Commits where only the indentation of 'foo' is changed are not shown with
>> "git log -Sfoo". Is there any way to force showing them along with other
>> changes involving foo? (E.g. for python, indentation matters!)
>>
>> Why doesn't the second commit show up in the following?
>
> Because you misunderstand how "-S" works (but don't worry, it's not your
> fault -- the documentation is somewhat misleading). The documentation says:
>
> -S<string>
> Look for differences that contain the change in <string>.
>
> but what it actually does is find changes where the string was introduced
> or removed. So it literally counts the number of occurences before and
> after the commit, and the commit is interesting if they are not equal.
Hmm. The diffcore doc sounds more like if the filepair is picked if
#before > 0 and #after = 0, but not if #after > 0.
In any case, the pickaxe can't detect moving around of strings, right?
>> # Create text containing 'line' without whitespace
>> $ echo 'line' > text
>> $ git add text
>> $ git commit -m "first" text
>>
>> # Here, I add one space of indentation in front of 'line'
>> $ echo ' line' > text
>> $ git commit -m "second" text
>
> So "line" wasn't actually changed. It just happens to be on a line which
> _did_ change.
>
>> I would like to see both "first" and "second" somehow - can I do that?
>
> I don't think there's an easy way to do this right now; you would need
> to do "git log -p" and search through the output to get what you want (I
> often do this just using the pager's search function).
If you know what your are looking for you can do variations on
git log -S'line| line' --pickaxe-regex
which seems to be different from
git log -S'line' -S' line'
which was my first attempt...
Michael
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Johannes Schindelin @ 2009-03-03 15:59 UTC (permalink / raw)
To: Reece Dunn; +Cc: git
In-Reply-To: <3f4fd2640903030709r6e585d9j57ad3ae08cf38df1@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 507 bytes --]
Hi,
On Tue, 3 Mar 2009, Reece Dunn wrote:
> 2009/2/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > Dear fans of Git,
> >
> > a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> > how to
> >
> > Use Git For What It Is Not Indended
>
> Does using Git to track edits when proofreading a html/text document
> (short story, novel, ...) count?
I'll count it, but I want (read-only) access to the repository as a proof
that you actually use Git that way ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: git log -Sfoo ignores indentation (whitespace?) changes...
From: Junio C Hamano @ 2009-03-03 15:58 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <49AD3E78.1050706@sneakemail.com>
"Peter Valdemar Mørch (Lists)" <4ux6as402@sneakemail.com> writes:
> Commits where only the indentation of 'foo' is changed are not shown
> with "git log -Sfoo". Is there any way to force showing them along
> with other changes involving foo? (E.g. for python, indentation
> matters!)
No. You should be running "git log -p" which spawns "less" and then type
/foo to jump to the occurrences of "foo".
The pickaxe -Sfoo looks for a filepair that contains different number
of substring "foo". It was designed as a basic building block for a very
different kind of Porcelain, whose final shape would look like the tool
described in http://article.gmane.org/gmane.comp.version-control.git/217,
but not yet written by anybody yet.
And I think it might be the good topic for a SoC project. From some GUI,
you let the user grab a block of text, feed it to "log -S<that multi-line
string> -1" to find where that block of text last changed, and inspect the
commit you have found very carefully using things like "git grep" to find
other places in the commit that could be related to the change of the
block of text, present all of them to the user. From there you let the
user dig deeper in the history by choosing what to look for next, most
likely giving the default selection to the block of text that roughly
corresponds to the original selection.
To make the iteration fast for this use case, the pickaxe cannot afford to
actually run diff and then grep inside the diff output (which is what you
would be doing with "log -p | less" and looking for your string in it).
^ permalink raw reply
* RE: remote branches, and branch names in general
From: John Dlugosz @ 2009-03-03 15:52 UTC (permalink / raw)
To: Jeff King, Jakub Narebski; +Cc: git
In-Reply-To: <20090303041631.GB18136@coredump.intra.peff.net>
===Re:===
... is need for disambiguation.
Yes. I don't know if they are documented anywhere, but the complete
lookup order is:
$ git grep -h -A8 ref_rev_parse_rules refs.c
const char *ref_rev_parse_rules[] = {
"%.*s",
"refs/%.*s",
"refs/tags/%.*s",
"refs/heads/%.*s",
"refs/remotes/%.*s",
"refs/remotes/%.*s/HEAD",
NULL
};
===end===
Thanks. Indeed, it works as expected when I play around with the log command.
But I wonder if some commands work differently or specifically don't look in remotes. I "learned" to qualify everything when I accidently created a local branch named pub/xxx instead of using remotes/pub/xxx like I intended. I don't remember what that was, but I'm guessing that maybe refs that are a destination are different, as you are only supposed to change your local stuff. I think that was a "pull" command, before I had the automatic argument in the config file.
--John
(excuse the footer; it's not my idea)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: git log -Sfoo ignores indentation (whitespace?) changes...
From: "Peter Valdemar Mørch (Lists)" @ 2009-03-03 15:48 UTC (permalink / raw)
To: git
In-Reply-To: <20090303152333.GB24593@coredump.intra.peff.net>
How sad... From "git log -Sfoo" looking like a really cool feature, it
now for me goes into the "must be plumbing because I have no use for it"
bin, as I can't rely on it:
If a commit removes mention of foo one place and just accidentally
happens to add foo somewhere completely unrelated then it wouldn't show
up in the output.
Would be neat with a feature that does what I thought -S did tho...
Thanks, Jeff, for both the answer and the documentation patch.
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* Re: [PATCHv3 2/2] git submodule: Fix adding of submodules at paths with ./, .. and //
From: Michael J Gruber @ 2009-03-03 15:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, Andrei Thorp
In-Reply-To: <7v3aduehz2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 03.03.2009 16:36:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Michael J Gruber schrieb:
>>> + # normalize path:
>>> + # multiple //; leading ./; /./; /../; trailing /
>>> + path=$(printf '%s/\n' "$path" |
>>> + sed -e '
>>> + s|//*|/|g
>>> + s|^\(\./\)*||
>>> + s|/\./|/|g
>>> + :start
>>> + s|\([^/]*\)/\.\./||g
>> Sorry to say: not yet. This turns "a/b/c/d/../../../d" into "a/b/c/d"
>> instead of "a/d". Drop the 'g'.
>>
>> Once this is fixed, I have to ask what should happen with path names like
>> "../a/b", "../../a/b"? Should there be a warning or error?
>>
>> Other than that, this expression works on AIX 4.3.3! Note in particular
>> that '\n' in the printf format string is essential!
>>
>>> + tstart
>>> + s|/*$||
>>> + ')
>
> At some point you should wonder if all of this complication is worth it,
> or it makes sense to reject when you see // or /\.\./ in the input.
I surely do wonder now! This started off treating merely leading ./ as
reported problematic by AT. Then the "do it really right" competition
started, and I think J6t and I came out as clear winners. There were no
other contenders.
Seriously, "git submodule init" does that normalization (by using
ls-files), so I think it does make sense to have it for add as well. git
submodule itself may have semi-porc/semi-plumb character, but if someone
wants to add submodules programmatically there is no simple way around
using "git submodule add", and paths may very well be constructed
relatively.
Michael
^ permalink raw reply
* Re: [RFC] Add an option for git-archive to output commit ID in alternative ways
From: Junio C Hamano @ 2009-03-03 15:44 UTC (permalink / raw)
To: roylee17; +Cc: git
In-Reply-To: <1236078904678-2414580.post@n2.nabble.com>
roylee17 <roylee17@gmail.com> writes:
> Consider the following use case:
> Regularly building projects which are untar'ed on-the-fly with git-archive
> without intermediate tar balls.
>
> How can I track back which commit IDs were those source code git-archive
> from?
Run "man gitattributes" and look for export-subst?
^ permalink raw reply
* [PATCH] doc: clarify how -S works
From: Jeff King @ 2009-03-03 15:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Valdemar Mørch (Lists), git
In-Reply-To: <20090303152333.GB24593@coredump.intra.peff.net>
The existing text was very vague about what exactly it means
for difference to "contain" a change. This seems to cause
confusion on the mailing list every month or two.
To fix it we:
1. use "introduce or remove an instance of" instead of
"contain"
2. point the user to gitdiffcore(7), which contains a more
complete explanation
Signed-off-by: Jeff King <peff@peff.net>
---
I wonder if "gitdiffcore" is a little scary for new people who just want
to use "-S", but hopefully point (1) above will get rid of most of the
confusion, and those who follow the link want to learn all about diff.
Documentation/diff-options.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 813a7b1..9276fae 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -176,7 +176,10 @@ override configuration settings.
number.
-S<string>::
- Look for differences that contain the change in <string>.
+ Look for differences that introduce or remove an instance of
+ <string>. Note that this is different than the string simply
+ appearing in diff output; see the 'pickaxe' entry in
+ linkgit:gitdiffcore[7] for more details.
--pickaxe-all::
When -S finds a change, show all the changes in that
--
1.6.2.rc2.330.gba39e
^ permalink raw reply related
* Re: [PATCHv4 2/2] git submodule: Fix adding of submodules at paths with ./, .. and //
From: Michael J Gruber @ 2009-03-03 15:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Andrei Thorp, Junio C Hamano
In-Reply-To: <49AD4C97.6010806@viscovery.net>
Johannes Sixt venit, vidit, dixit 03.03.2009 16:28:
> Michael J Gruber schrieb:
>> Make 'git submodule add' normalize the submodule path in the
>> same way as 'git ls-files' does, so that 'git submodule init' looks up
>> the information in .gitmodules with the same key under which 'git
>> submodule add' stores it.
>>
>> This fixes 4 known breakages.
>> ---
>
> OK!
>
> Tested-by: Johannes Sixt <j6t@kdbg.org> (AIX)
>
> but really, I ran only: cd t && make *submodule*
>
> You certainly will sign off this patch?
>
> -- Hannes
Grrmmml. Yes, 2/2 is sob me just as 1/2 is. This comes from switching
from "git f-p -s" to "git ci -s" recently and forgetting during
rewrite... So please consider all of PATCHv4 to be
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
and
Sanity-added-by: Johannes Sixt <j.sixt@viscovery.net>
<goes and does git config alias.ci 'commit -s'>
Michael
^ permalink raw reply
* Re: [PATCHv3 2/2] git submodule: Fix adding of submodules at paths with ./, .. and //
From: Junio C Hamano @ 2009-03-03 15:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Michael J Gruber, git, Andrei Thorp
In-Reply-To: <49AD2BE6.1000105@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Michael J Gruber schrieb:
>> + # normalize path:
>> + # multiple //; leading ./; /./; /../; trailing /
>> + path=$(printf '%s/\n' "$path" |
>> + sed -e '
>> + s|//*|/|g
>> + s|^\(\./\)*||
>> + s|/\./|/|g
>> + :start
>> + s|\([^/]*\)/\.\./||g
>
> Sorry to say: not yet. This turns "a/b/c/d/../../../d" into "a/b/c/d"
> instead of "a/d". Drop the 'g'.
>
> Once this is fixed, I have to ask what should happen with path names like
> "../a/b", "../../a/b"? Should there be a warning or error?
>
> Other than that, this expression works on AIX 4.3.3! Note in particular
> that '\n' in the printf format string is essential!
>
>> + tstart
>> + s|/*$||
>> + ')
At some point you should wonder if all of this complication is worth it,
or it makes sense to reject when you see // or /\.\./ in the input.
^ permalink raw reply
* Re: [PATCH] grep: add --blame so grep can show blame result at the same time
From: Junio C Hamano @ 2009-03-03 15:33 UTC (permalink / raw)
To: pi.songs; +Cc: git
In-Reply-To: <1b29507a0903030427y15ad89d7y9f55a945612f0e20@mail.gmail.com>
pi song <pi.songs@gmail.com> writes:
> My god, this is too big. I cannot attach or paste in email. What should I
> do?
For a starter, try removing hunks that record only unwarranted changes,
such as the following. They are all style regressions.
@@ -517,6 +563,8 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
show_name(opt, name);
return 1;
}
+
+
/* Hit at this line. If we haven't shown the
* pre-context lines, we would need to show them.
* When asked to do "count", this still show
@@ -524,7 +572,9 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
* deserves to get that ;-).
*/
if (opt->pre_context) {
+
unsigned from;
+
if (opt->pre_context < lno)
from = lno - opt->pre_context;
else
@@ -590,8 +664,10 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
* make it another option? For now suppress them.
*/
if (opt->count && count)
+ {
printf("%s%c%u\n", name,
opt->null_following_name ? '\0' : ':', count);
+ }
return !!last_hit;
}
^ 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