* Git submodules with usernames in the URL
From: Tillmann.Crueger @ 2012-02-14 13:26 UTC (permalink / raw)
To: git
Hi,
I already had a look at the mailinglist archive, but I could not find any mention of this problem. There is a posting on Stackoverflow.com about this (http://stackoverflow.com/questions/7714326/git-submodule-url-not-including-username) with a workaround, but it would nice to have an official position.
Here is the problem:
When I am using git-submodule over an authorized https it is convenient to be able to specify the username directly in the url in the form https://user@domain.com/path/to/repo. So I am able to do a
> git submodule add https://user@domain.com/path/to/repo
Howver if I do this, the username becomes baked into the URL of the submodule, so other people working with the repository will not be able to use the submodule and have to change the URL first.
Is there an actual rationale for including the username in the URL in this case, or is this just because it is simpler than removing it?
One thing I noticed, is that automatically removing it would basically eliminate the convinience for the person who has been using that URL in the first place. If the username was removed every update would have to query the username again. Also having a username in the repo could be correct, in case this isn't a real user, but a role for using that repository.
Still I feel that having a username within a repository is hardly ever what someone wants and most often a mistake. For now I will try to educate everybody about this and fix all repositories where this goes wrong, but a better solution would be nice to have.
Thanks for your time,
Till
^ permalink raw reply
* Re: Git submodules with usernames in the URL
From: Michael Schubert @ 2012-02-14 14:55 UTC (permalink / raw)
To: Tillmann.Crueger; +Cc: git
In-Reply-To: <E76DF6102FDBC04BA291EAE9A3BAECB50137C2AC6530@HE111540.emea1.cds.t-internal.com>
On 02/14/2012 02:26 PM, Tillmann.Crueger@telekom.de wrote:
> I already had a look at the mailinglist archive, but I could not find
> any mention of this problem. There is a posting on Stackoverflow.com
> about this
> (http://stackoverflow.com/questions/7714326/git-submodule-url-not-including-username)
> with a workaround, but it would nice to have an official position.
>
> Here is the problem:
>
> When I am using git-submodule over an authorized https it is
> convenient to be able to specify the username directly in the url in
> the form https://user@domain.com/path/to/repo. So I am able to do a
>
>> git submodule add https://user@domain.com/path/to/repo
>
> Howver if I do this, the username becomes baked into the URL of the
> submodule, so other people working with the repository will not be
> able to use the submodule and have to change the URL first.
>
> Is there an actual rationale for including the username in the URL in
> this case, or is this just because it is simpler than removing it?
>
> One thing I noticed, is that automatically removing it would
> basically eliminate the convinience for the person who has been using
> that URL in the first place. If the username was removed every update
> would have to query the username again. Also having a username in the
> repo could be correct, in case this isn't a real user, but a role for
> using that repository.
* If the submodule repository is accessible without authentication, no
user specific URL should go into the repository.
* If the submodule repository is not accessible without authentication,
the user specific URL should not go into the repository either,
because of the problem you just described. (Sure, you could add a
"git submodule user", but..)
> Still I feel that having a username within a repository is hardly
> ever what someone wants and most often a mistake. For now I will try
> to educate everybody about this and fix all repositories where this
> goes wrong, but a better solution would be nice to have.
Git >= v1.7.9 comes with a credentials API and some helpers; see
commit abca927dbef2c310056b8a1a8be5561212b3243a
and following or the available documentation for credentials, e.g.:
https://raw.github.com/gitster/git/master/Documentation/git-credential-store.txt
In contrib, there's a helper for the OS X keychain:
https://github.com/gitster/git/tree/master/contrib/credential
If that's no option, you would have to go with netrc / url config
approach.
HTH.
^ permalink raw reply
* [PATCH 0/2] t: add blame -e tests for mailmap
From: Felipe Contreras @ 2012-02-14 16:11 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
I sent both the fix and the tests. Another fix was applied, but we are still
missing the tests.
These are good before, and after the fix.
Felipe Contreras (2):
t: mailmap: add 'git blame -e' tests
t: mailmap: add simple name translation test
t/t4203-mailmap.sh | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
--
1.7.9.1.g97f7d
^ permalink raw reply
* [PATCH 1/2] t: mailmap: add 'git blame -e' tests
From: Felipe Contreras @ 2012-02-14 16:11 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, Jonathan Nieder, Marius Storm-Olsen
In-Reply-To: <1329235894-20581-1-git-send-email-felipe.contreras@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
t/t4203-mailmap.sh | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index 1f182f6..db12265 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -255,4 +255,22 @@ test_expect_success 'Blame output (complex mapping)' '
test_cmp expect actual.fuzz
'
+# git blame -e
+cat >expect <<\EOF
+^OBJI (<author@example.com> DATE 1) one
+OBJID (<some@dude.xx> DATE 2) two
+OBJID (<other@author.xx> DATE 3) three
+OBJID (<other@author.xx> DATE 4) four
+OBJID (<santa.claus@northpole.xx> DATE 5) five
+OBJID (<santa.claus@northpole.xx> DATE 6) six
+OBJID (<cto@company.xx> DATE 7) seven
+EOF
+test_expect_success 'Blame output (complex mapping)' '
+ git blame -e one >actual &&
+ cp actual /tmp &&
+ cp internal_mailmap/.mailmap /tmp &&
+ fuzz_blame actual >actual.fuzz &&
+ test_cmp expect actual.fuzz
+'
+
test_done
--
1.7.9.1.g97f7d
^ permalink raw reply related
* [PATCH 2/2] t: mailmap: add simple name translation test
From: Felipe Contreras @ 2012-02-14 16:11 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, Marius Storm-Olsen, Jim Meyering,
Jonathan Nieder
In-Reply-To: <1329235894-20581-1-git-send-email-felipe.contreras@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
t/t4203-mailmap.sh | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index db12265..fc3855a 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -157,6 +157,9 @@ A U Thor <author@example.com> (1):
CTO <cto@company.xx> (1):
seventh
+Mr. Right <right@company.xx> (1):
+ eight
+
Other Author <other@author.xx> (2):
third
fourth
@@ -196,6 +199,11 @@ test_expect_success 'Shortlog output (complex mapping)' '
test_tick &&
git commit --author "CTO <cto@coompany.xx>" -m seventh &&
+ echo eight >>one &&
+ git add one &&
+ test_tick &&
+ git commit --author "Wrong <right@company.xx>" -m eight &&
+
mkdir -p internal_mailmap &&
echo "Committed <committer@example.com>" > internal_mailmap/.mailmap &&
echo "<cto@company.xx> <cto@coompany.xx>" >> internal_mailmap/.mailmap &&
@@ -204,6 +212,7 @@ test_expect_success 'Shortlog output (complex mapping)' '
echo "Other Author <other@author.xx> <nick2@company.xx>" >> internal_mailmap/.mailmap &&
echo "Santa Claus <santa.claus@northpole.xx> <me@company.xx>" >> internal_mailmap/.mailmap &&
echo "Santa Claus <santa.claus@northpole.xx> <me@company.xx>" >> internal_mailmap/.mailmap &&
+ echo "Mr. Right <right@company.xx>" >> internal_mailmap/.mailmap &&
git shortlog -e HEAD >actual &&
test_cmp expect actual
@@ -212,6 +221,9 @@ test_expect_success 'Shortlog output (complex mapping)' '
# git log with --pretty format which uses the name and email mailmap placemarkers
cat >expect <<\EOF
+Author Wrong <right@company.xx> maps to Mr. Right <right@company.xx>
+Committer C O Mitter <committer@example.com> maps to Committed <committer@example.com>
+
Author CTO <cto@coompany.xx> maps to CTO <cto@company.xx>
Committer C O Mitter <committer@example.com> maps to Committed <committer@example.com>
@@ -248,6 +260,7 @@ OBJID (Other Author DATE 4) four
OBJID (Santa Claus DATE 5) five
OBJID (Santa Claus DATE 6) six
OBJID (CTO DATE 7) seven
+OBJID (Mr. Right DATE 8) eight
EOF
test_expect_success 'Blame output (complex mapping)' '
git blame one >actual &&
@@ -264,6 +277,7 @@ OBJID (<other@author.xx> DATE 4) four
OBJID (<santa.claus@northpole.xx> DATE 5) five
OBJID (<santa.claus@northpole.xx> DATE 6) six
OBJID (<cto@company.xx> DATE 7) seven
+OBJID (<right@company.xx> DATE 8) eight
EOF
test_expect_success 'Blame output (complex mapping)' '
git blame -e one >actual &&
--
1.7.9.1.g97f7d
^ permalink raw reply related
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Jakub Narebski @ 2012-02-14 17:31 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: git
In-Reply-To: <20120213220917.4cf14eb1@gmail.com>
A few issues I have just noticed about this series.
First, about naming. "Highlighting interesting parts of diff" is
acceptable name, but "syntax highlighting for diff" is not: gitweb
already use syntax highlighting in diff views. Call it "diff refinement
highlighting", "highlighting changes / changed sections", "intraline
highlighting".
Second, I think (but I am not sure) that there is a bug in code that
finds common suffix and prefix.
If I understand correctly the idea is to highlight changed part if
there is at least one of common non-whitespace suffix or prefix.
So syntax highlighting should look like this:
1. Both prefix and suffix are non empty and non whitespace only
-foo -{bar} baz
+foo +{quux} baz
2. Non empty and non whitespace only prefix
-foo -{bar}
+foo +{quux}
2. Non empty and non whitespace only suffix
--{bar} baz
++{quux} baz
But in your code $prefix is not the length of common prefix, but
the position of end of prefix in the original line of diff. So
you start with $prefix = 1... even though the prefix is empty.
How is that supposed to work?
On Mon, 13 Feb 2012, Michał Kiedrowicz wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
> > On Mon, 13 Feb 2012, Michal Kiedrowicz wrote:
> > > I haven't found *examples* on GitHub and Trac sites, but what about
> > > these ones:
> > >
> > > https://github.com/gitster/git/commit/8cad4744ee37ebec1d9491a1381ec1771a1ba795
> > > http://trac.edgewall.org/changeset/10973
[...]
> > BTW GitHub is closed source, but we can check what algorithm does Trac
> > use for diff refinement highlighting (highlighting changed portions of
> > diff).
> >
>
> I think it's
> http://trac.edgewall.org/browser/trunk/trac/versioncontrol/diff.py
> (see markup intraline_changes()).
It is get_change_extent() that finds extent of changes, as a pair
containing the offset at which the changes start, and the negative offset
at which the changes end. So it is the same solution you use, only
without ignoring whitespace-only prefixes and suffixes... This code can
be easily ported to Perl, BTW.
The markup_intraline_changes() function compares lines from preimage and
from postimage pairwise, requiring that number of lines matches, the same
like in your algorithm.
[...]
> > I wonder if we can use --diff-words for diff refinement highlighting,
> > i.e. LCS on words.
>
> I think we can try it, but I worry about performance of running `git
> diff` on every diff chunk.
I was thinking about one single additional run of git-diff-tree with
`--diff-words`, not one per chunk.
Or perhaps even put it together in one git-diff-tree invocation, just like
'commitdiff' action / git_commitdiff() subroutine uses single git-diff-tree
invocation, with the option "--patch-with-raw", to generate both raw diff
for difftree and patchset.
> > Anyway Jeff's approach is a bit limited, in that it would work only for
> > change that does not involve adding newlines, for example splitting
> > overly long line when changing something.
> >
> > See for example line 1786 (in pre-image) in http://trac.edgewall.org/changeset/10973
>
> Yes, I'm aware of that. I was thinking about improving it later ("Let's
> start with a simple refinment highlightning and maybe later add more
> sophisticated algorithms").
Right.
[...]
> > BTW. is it "at least one of prefix or suffix are non-empty" or "both prefix
> > and suffix are non-empty"?
> >
>
> At least one. See:
>
> -a = 42;
> +b = 42;
>
> Here prefix is empty but suffix is not.
Nb. prefix is empty but $prefix == 1, and is boolean true.
> > > I would also consider ignoring prefixes/suffixes with punctuation, like:
> > >
> > > - * I like you.
> > > + * Alice had a little lamb.
> >
> > But this patch doesn't implement this feature yet, isn't it?
>
> No, but is a matter of adding
>
> -$prefix_is_space = 0 if ($r[$prefix] !~ /\s/);
> +$prefix_is_space = 0 if ($r[$prefix] !~ /\s|[[:punct:]]/);
>
> (and the same for suffix)
All right. But it is better added as separate patch. Perhaps even
requiring that not only there is at least one of common prefix or common
suffix, but at least one of them is not whitespace only could be put
in a separate commit...
> > > > > +sub format_rem_add_line {
> > > > > + my ($rem, $add) = @_;
> > > > > + my @r = split(//, $rem);
> > > > > + my @a = split(//, $add);
> >
> > BTW the name of variable can be just @add and @rem.
> >
>
> I know they are different scopes but I don't like it. It makes the code
> more confusing IMO. But I won't insist.
In my opinion if the variable refers to the same entity in different
forms, using @foo and %foo (used in gitweb), or $foo and @foo (could be
used here) is all right, and even better than trying to come up with
different name for the same thing because of sigil.
> > > > Shouldn't
> > > > $prefix / $prefix_len start from 0, not from 1?
> > >
> > > It starts from 1 because it skips first +/-. It should become obvious
> > > after reading the comment from last patch :).
This means that $prefix is true even if prefix is empty ($prefix == 1).
Wouldn't it be better for $prefix_len to count length of true prefix,
without diff adornment? Or make @r / @rem skip initial characters...
> > > + # In combined diff we must ignore two +/- characters.
> > > + $prefix = 2 if ($is_combined);
> >
> > Anyway comment about that fact would be nice.
>
> Will do.
BTW. it is not "2" but "scalar @{$co{'parents'}}".
> > > The splitting and comparing by characters is taken from diff-highlight.
> > > I don't think it's worth changing here.
> >
> > You are right.
> >
> > I'll try to come with hacky algorithm using string bitwise xor and regexp,
> > and benchmark it comparing to your C-like solution, but it can be left for
> > later (simple is better than clever, usually).
>
> If you have time :).
Anyway it would be separate commit. Better to just copy tested code
from contrib/diff-highlight
BTW. would "git blame -C -C -C -w" detect this correctly as code
movement^W copying?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH/RFC v4] grep: Add the option '--exclude'
From: Junio C Hamano @ 2012-02-14 17:35 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Albert Yale, git
In-Reply-To: <CACsJy8DhtjG6AhPkb0SEm4g6zhtmuRb5x+4+P3A6eS0+_7OQNw@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> It makes me wonder, why not add match_pathspec_with_exclusion(const
> struct pathspec *include_ps, const struct pathspec *exclude_ps,...),
> use the new function in grep.c and revert struct pathspec back to
> original? The same can be applied to tree_entry_interesting() (i.e.
> add a new one that takes two pathspec sets, which supports exclusion)
Sorry, but I am the one to blame for this in:
http://thread.gmane.org/gmane.comp.version-control.git/189455/focus=189486
> I think you may make less changes that way.
The arrangement to use two pathspecs certainly is simpler in the short
term, but I think it is a short-sighted hack that is wrong for two
reasons.
- Doing it that way will not give you a solution where you only have to
update the command line parsing of an existing command to stuff
negative patterns to the pathspec structure you have been passing down
to the existing codepath, and the command starts to understand negative
patterns without any other change. You introduce a new pathspec that
holds negative patterns, and pass that along with the positive one you
have been passing down in the existing codepath for all commands that
need to understand pathspec (otherwise we will be back to a similar
situation we were in before you started looking at pathspec where we
had three different implementations giving different semantics---some
command knows how to handle this kind of pathspec but some others do
not).
- Look at the fields in 'struct pathspec' and think about what those
outside "items" list mean. The recursive and max_depth fields are about
how the namespace is traversed [*1*], so if a codepath that used to
know only about positive patterns learns to also care about negative
ones, using different settings for these two fields in two separate
'struct pathspec' does not make sense. It is conceptually much cleaner
to make 'struct pathspec' the data structure used by the updated logic
to match paths to pathspec that can have positive and negative patterns.
[Footnote]
*1* The has_wildcard field is about optimizing the matching during the
traversal so it is a bit different. Also it is our longer term goal to
get rid of the "raw" field (which does not work well to substring match
against the path when pathspec "magic" is involved), so we won't worry
about it in this discussion.
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Michał Kiedrowicz @ 2012-02-14 18:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202141831.59699.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> A few issues I have just noticed about this series.
>
>
> First, about naming. "Highlighting interesting parts of diff" is
> acceptable name, but "syntax highlighting for diff" is not: gitweb
> already use syntax highlighting in diff views. Call it "diff refinement
> highlighting", "highlighting changes / changed sections", "intraline
> highlighting".
OK, I'll make sure the naming is correct and consistent.
>
>
> Second, I think (but I am not sure) that there is a bug in code that
> finds common suffix and prefix.
>
> If I understand correctly the idea is to highlight changed part if
> there is at least one of common non-whitespace suffix or prefix.
> So syntax highlighting should look like this:
>
> 1. Both prefix and suffix are non empty and non whitespace only
>
> -foo -{bar} baz
> +foo +{quux} baz
>
> 2. Non empty and non whitespace only prefix
>
> -foo -{bar}
> +foo +{quux}
>
> 2. Non empty and non whitespace only suffix
>
> --{bar} baz
> ++{quux} baz
>
> But in your code $prefix is not the length of common prefix, but
> the position of end of prefix in the original line of diff. So
> you start with $prefix = 1... even though the prefix is empty.
>
> How is that supposed to work?
But see the check:
+ # Mark lines that are different from each other, but have some common
+ # part that isn't whitespace. If lines are completely different, don't
+ # mark them because that would make output unreadable, especially if
+ # diff consists of multiple lines.
+ if (($prefix == 1 && $suffix_rem == $#r && $suffix_add == $#a)
^
|
This part.
+ || ($prefix_is_space && $suffix_is_space)) {
+ $esc_rem = esc_html($rem);
+ $esc_add = esc_html($add);
+ } else {
+ $esc_rem = esc_html_mark_range(\@r, $prefix, $suffix_rem);
+ $esc_add = esc_html_mark_range(\@a, $prefix, $suffix_add);
+ }
I guess it's still not correct because it should be equal to number of
parents or $prefix_length should start from 0 like you wrote later.
>
>
> On Mon, 13 Feb 2012, Michał Kiedrowicz wrote:
> > Jakub Narebski <jnareb@gmail.com> wrote:
> > > On Mon, 13 Feb 2012, Michal Kiedrowicz wrote:
>
> > > > I haven't found *examples* on GitHub and Trac sites, but what about
> > > > these ones:
> > > >
> > > > https://github.com/gitster/git/commit/8cad4744ee37ebec1d9491a1381ec1771a1ba795
> > > > http://trac.edgewall.org/changeset/10973
> [...]
> > > BTW GitHub is closed source, but we can check what algorithm does Trac
> > > use for diff refinement highlighting (highlighting changed portions of
> > > diff).
> > >
> >
> > I think it's
> > http://trac.edgewall.org/browser/trunk/trac/versioncontrol/diff.py
> > (see markup intraline_changes()).
>
> It is get_change_extent() that finds extent of changes, as a pair
> containing the offset at which the changes start, and the negative offset
> at which the changes end. So it is the same solution you use, only
> without ignoring whitespace-only prefixes and suffixes... This code can
> be easily ported to Perl, BTW.
>
> The markup_intraline_changes() function compares lines from preimage and
> from postimage pairwise, requiring that number of lines matches, the same
> like in your algorithm.
>
So using Jeff's diff-highlight we remain quite consistent with Trac
output. There's nothing we can "steal" from it.
> > > > I would also consider ignoring prefixes/suffixes with punctuation, like:
> > > >
> > > > - * I like you.
> > > > + * Alice had a little lamb.
> > >
> > > But this patch doesn't implement this feature yet, isn't it?
> >
> > No, but is a matter of adding
> >
> > -$prefix_is_space = 0 if ($r[$prefix] !~ /\s/);
> > +$prefix_is_space = 0 if ($r[$prefix] !~ /\s|[[:punct:]]/);
> >
> > (and the same for suffix)
>
> All right. But it is better added as separate patch.
Sure
> Perhaps even
> requiring that not only there is at least one of common prefix or common
> suffix, but at least one of them is not whitespace only could be put
> in a separate commit...
>
> > > > > > +sub format_rem_add_line {
> > > > > > + my ($rem, $add) = @_;
> > > > > > + my @r = split(//, $rem);
> > > > > > + my @a = split(//, $add);
> > >
> > > BTW the name of variable can be just @add and @rem.
> > >
> >
> > I know they are different scopes but I don't like it. It makes the code
> > more confusing IMO. But I won't insist.
>
> In my opinion if the variable refers to the same entity in different
> forms, using @foo and %foo (used in gitweb), or $foo and @foo (could be
> used here) is all right, and even better than trying to come up with
> different name for the same thing because of sigil.
OK. I'll follow that convention then.
>
> > > > > Shouldn't
> > > > > $prefix / $prefix_len start from 0, not from 1?
> > > >
> > > > It starts from 1 because it skips first +/-. It should become obvious
> > > > after reading the comment from last patch :).
>
> This means that $prefix is true even if prefix is empty ($prefix == 1).
> Wouldn't it be better for $prefix_len to count length of true prefix,
> without diff adornment? Or make @r / @rem skip initial characters...
>
> > > > + # In combined diff we must ignore two +/- characters.
> > > > + $prefix = 2 if ($is_combined);
> > >
> > > Anyway comment about that fact would be nice.
> >
> > Will do.
>
> BTW. it is not "2" but "scalar @{$co{'parents'}}".
>
OK.
>
> > > > The splitting and comparing by characters is taken from diff-highlight.
> > > > I don't think it's worth changing here.
> > >
> > > You are right.
> > >
> > > I'll try to come with hacky algorithm using string bitwise xor and regexp,
> > > and benchmark it comparing to your C-like solution, but it can be left for
> > > later (simple is better than clever, usually).
> >
> > If you have time :).
>
> Anyway it would be separate commit. Better to just copy tested code
> from contrib/diff-highlight
>
> BTW. would "git blame -C -C -C -w" detect this correctly as code
> movement^W copying?
>
Cannot say. Have you considered what I wrote in a separate e-mail,
about using diff-highlight output directly / as a library?
^ permalink raw reply
* Re: [PATCH] column: Fix an incorrect parse of the 'nodense' option token
From: Ramsay Jones @ 2012-02-14 18:28 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <CACsJy8B7=6OYBV-HVK3Cq4_cTdPvm_1MvVv=U2R=4yQw9t5X9Q@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> It's about overriding config. If you set "dense" by default in
> column.ui but do not want it in this particular run, you can say
> --column=nodense.
Ah, OK, I missed that (obvious in retrospect!). Thanks.
> The [no]color is for plumbing only. If a command produces colored
> output, "color" is required to calculate text length correctly.
> Overriding it with "nocolor" would break the layout badly so it's no
> use there. It does not make sense (to me) for users to put "color" in
> column.ui. Which is why it's not mentioned in document.
Er... but 'color' is documented with column.ui in config.txt.
I'm obviously (still) being dense! :-D
ATB,
Ramsay Jones
^ permalink raw reply
* Re: cvs2git migration
From: supadhyay @ 2012-02-14 18:33 UTC (permalink / raw)
To: git
In-Reply-To: <1329220866066-7283631.post@n2.nabble.com>
Hi All,
Can any one please update me what would be the method/steps to migrate
existing CVS users to GIT in CVS2GIT migration? User migration is possible
or not?
Thanks in advance...
--
View this message in context: http://git.661346.n2.nabble.com/cvs2git-migration-tp7283631p7285021.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC PATCH 0/3] git-p4: move to toplevel
From: Junio C Hamano @ 2012-02-14 18:40 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Pete Wyckoff, git, Luke Diamand, Vitor Antunes
In-Reply-To: <20120214092048.GC1762@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> On Mon, Feb 13, 2012 at 01:20:25PM -0800, Junio C Hamano wrote:
>> Clemens Buchacher <drizzd@aon.at> writes:
>>
>> >> Erm,... do you really need the alias if you add git-p4 in a directory on
>> >> your $PATH?
>> >
>> > With recent git versions, this has stopped working.
>>
>> Erm, I am confused.
>
> Looks like in my case it did not work because I had a PATH entry with a
> '~' in it. It probably stopped working for me because I moved some
> executables around.
>
> It's not a regression (I just tried with 1.6.0 and I get the same
> result). And dash does not apply tilde expansion to PATH either.
I do not think tilde in $PATH is expanded by exec*p family to begin with,
so it is not "dash" but POSIX, I would think. It is bash that is harming
other programs, by trying to be more helpful, encouraging this user
mistake to add ~ literally on the PATH.
You can see it in action below.
$ cd /var/tmp
$ cat >execlptest.c <<\EOF
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <stdio.h>
int main(int ac, const char **av)
{
int status = execlp("xyzzy", "xyzzy", NULL);
printf("execlp returned %d (errno = %d, %s)\n",
status, errno, strerror(errno));
return 0;
}
EOF
$ gcc -o execlptest execlptest.c
$ cat >/home/junio/junk/xyzzy <<\EOF
#!/bin/sh
exec lp test
EOF
$ chmod +x /home/junio/junk/xyzzy
$ PATH=/usr/bin:/bin
$ export PATH
$ /var/tmp/execlptest
execlp returned -1 (errno = 2, No such file or directory)
: notice the sq pair around the value on the next line
$ PATH='/usr/bin:/bin:~/junk'; export PATH; echo "$PATH"
/usr/bin:/bin:~/junk
$ /var/tmp/execlptest
execlp returned -1 (errno = 2, No such file or directory)
$ xyzzy
exec lp test
$ echo $BASH_VERSION
4.1.5(1)-release
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Jeff King @ 2012-02-14 18:52 UTC (permalink / raw)
To: Michał Kiedrowicz; +Cc: Jakub Narebski, git
In-Reply-To: <20120214192340.2d473866@gmail.com>
On Tue, Feb 14, 2012 at 07:23:40PM +0100, Michał Kiedrowicz wrote:
> > > > BTW GitHub is closed source, but we can check what algorithm does Trac
> > > > use for diff refinement highlighting (highlighting changed portions of
> > > > diff).
> > > >
> > > I think it's
> > > http://trac.edgewall.org/browser/trunk/trac/versioncontrol/diff.py
> > > (see markup intraline_changes()).
> [...]
> [...]
> > The markup_intraline_changes() function compares lines from preimage and
> > from postimage pairwise, requiring that number of lines matches, the same
> > like in your algorithm.
>
> So using Jeff's diff-highlight we remain quite consistent with Trac
> output. There's nothing we can "steal" from it.
Neat. When I originally wrote diff-highlight, I was inspired by seeing
what Trac and GitHub did, but came up with the algorithm on my own.
Learning that Trac does the multiline thing (as we started doing with
recent patches) makes me feel even better that it's a good strategy.
As an aside, I looked at what GitHub does. It turns on highlighting only
for the single-line case, and does the same prefix/suffix thing.
It's really not very complex code; most of the hassle in diff-highlight
is ignoring (but preserving) embedded colors, so that we build on top of
existing colorization. A web tool will be doing the line coloring itself
anyway, so it can be much simpler. Elsewhere, I suggested lib-ifying
diff-highlight for gitweb to use. But once you remove the embedded color
handling, there really is not that much code, and it's probably simpler
to just rewrite it.
-Peff
^ permalink raw reply
* Re: [RFC PATCH 0/3] git-p4: move to toplevel
From: Jeff King @ 2012-02-14 19:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Clemens Buchacher, Pete Wyckoff, git, Luke Diamand, Vitor Antunes
In-Reply-To: <7vaa4l8diz.fsf@alter.siamese.dyndns.org>
On Tue, Feb 14, 2012 at 10:40:04AM -0800, Junio C Hamano wrote:
> I do not think tilde in $PATH is expanded by exec*p family to begin with,
> so it is not "dash" but POSIX, I would think. It is bash that is harming
> other programs, by trying to be more helpful, encouraging this user
> mistake to add ~ literally on the PATH.
Hmm. There is an interesting ramification for run-command's "use_shell"
optimization. Typically, git runs all of the user-provided commands
given to it via the shell. But if the command contains no
meta-characters, we skip the shell invocation as an optimization, since
the shell should simply be word-splitting and calling exec, and the
behavior will be identical.
But if your shell handles PATH entries differently, then there is a
difference. I.e., doing this:
mkdir junk
ln -s /usr/bin/vi junk/my-editor
export PATH=~/junk:$PATH
export GIT_EDITOR=my-editor
git commit
might work without the optimization, but not with.
We could check PATH and disable the optimization in that case, but I
suspect it is not worth it, as:
1. People who put a literal "~" in their PATH get what they deserve
anyway. :)
2. We explicitly run "sh" in such situations, not SHELL_PATH. Even if
"sh" is bash, I believe it should look at its own argv[0] and put
itself into a more POSIX-y mode (but I didn't test).
-Peff
^ permalink raw reply
* Re: [PATCH 2/5] do not override receive-pack errors
From: Junio C Hamano @ 2012-02-14 19:06 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <20120214083324.GA1762@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> Yes, it really is. For example, in t5504 rev-list --verify-objects (it
> was turned on for me if called from there) detects the corrupt object.
> But the error string is later overwritten with the return value of
> update, which is NULL in this case.
> ...
> Actually, check_alias_update searches for aliases of cmd in ref_list,
> which is a list of refs from all commands, irrespective of their error
> status. So this change is correct.
Ok, thanks for clarificatin on both counts.
^ permalink raw reply
* Re: [PATCH 12/10] support pager.* for external commands
From: Jeff King @ 2012-02-14 19:13 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Steffen Daode Nurpmeso, Ingo Brückl
In-Reply-To: <CACBZZX596wnk2KE9QzUPMc=A6Mt8HbUs7F4rnAZbw1_RrcKHnw@mail.gmail.com>
On Sun, Feb 12, 2012 at 01:46:34AM +0100, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Aug 19, 2011 at 00:01, Jeff King <peff@peff.net> wrote:
>
> > +test_expect_success TTY 'command-specific pager works for external commands' '
> > + sane_unset PAGER GIT_PAGER &&
> > + echo "foo:initial" >expect &&
> > + >actual &&
> > + test_config pager.external "sed s/^/foo:/ >actual" &&
> > + test_terminal git --exec-path="`pwd`" external log --format=%s -1 &&
> > + test_cmp expect actual
>
> For reasons that I haven't looked into using sed like that breaks
> under /usr/bin/ksh on Solaris. Just using:
>
> sed -e \"s/^/foo:/\"
>
> Instead fixes it, it's not broken with /usr/xpg4/bin/sh, so it's some
> ksh peculiarity.
>
> The error it gives is:
>
> sed s/^/foo:/ >actual: Not found
>
> Indicating that for some reason it's considering that whole "sed
> s/^/foo:/ >actual" string to be a single command.
Hrm. Is the problem on the git-executing side, or is it on the setting
up the config side?
Sadly (or perhaps not) I no longer have any Solaris machines to test on.
Can you confirm that "git config pager.external" looks OK inside that
test? Can you confirm via GIT_TRACE=1 what is being sent to the shell?
Also, it looks like we actually run commands internally from git using
"sh -c". So if it is the executing side that is wrong, I don't see how
/usr/bin/ksh would be involved at all (it would either be /bin/sh, or
/usr/xpg4/bin/sh if you have your PATH set).
-Peff
^ permalink raw reply
* Re: [RFC PATCH 0/3] git-p4: move to toplevel
From: Junio C Hamano @ 2012-02-14 19:25 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Clemens Buchacher, Pete Wyckoff, git,
Luke Diamand, Vitor Antunes
In-Reply-To: <20120214190515.GB12072@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Feb 14, 2012 at 10:40:04AM -0800, Junio C Hamano wrote:
>
>> I do not think tilde in $PATH is expanded by exec*p family to begin with,
>> so it is not "dash" but POSIX, I would think. It is bash that is harming
>> other programs, by trying to be more helpful, encouraging this user
>> mistake to add ~ literally on the PATH.
>
> Hmm. There is an interesting ramification for run-command's "use_shell"
> optimization....
> But if your shell handles PATH entries differently, then there is a
> difference.
Yeah, I agree; that is exactly what I meant by bash harming users by
trying to be more helpful.
^ permalink raw reply
* [ANNOUNCE] Git 1.7.9.1
From: Junio C Hamano @ 2012-02-14 19:28 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git 1.7.9.1 is now available at the usual
places. This is primarily to fix various user experience kinks in the new
feature added in 1.7.9 release, so that there no longer is an excuse for
users to hold on to older releases.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
bd85327627f96c4e98071a4d1d32c30f210aa54a git-1.7.9.1.tar.gz
de5ad73499cfdb08e261bc481c84a75f11b7ff0f git-htmldocs-1.7.9.1.tar.gz
8c6ee031b39da5c5e53f927952838796e0959ce9 git-manpages-1.7.9.1.tar.gz
Also the following public repositories all have a copy of the v1.7.9.1
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Have fun.
----------------------------------------------------------------
Git v1.7.9.1 Release Notes
==========================
Fixes since v1.7.9
------------------
* The makefile allowed environment variable X seep into it result in
command names suffixed with unnecessary strings.
* The set of included header files in compat/inet-{ntop,pton}
wrappers was updated for Windows some time ago, but in a way that
broke Solaris build.
* rpmbuild noticed an unpackaged but installed *.mo file and failed.
* Subprocesses spawned from various git programs were often left running
to completion even when the top-level process was killed.
* "git add -e" learned not to show a diff for an otherwise unmodified
submodule that only has uncommitted local changes in the patch
prepared by for the user to edit.
* Typo in "git branch --edit-description my-tpoic" was not diagnosed.
* Using "git grep -l/-L" together with options -W or --break may not
make much sense as the output is to only count the number of hits
and there is no place for file breaks, but the latter options made
"-l/-L" to miscount the hits.
* "git log --first-parent $pathspec" did not stay on the first parent
chain and veered into side branch from which the whole change to the
specified paths came.
* "git merge --no-edit $tag" failed to honor the --no-edit option.
* "git merge --ff-only $tag" failed because it cannot record the
required mergetag without creating a merge, but this is so common
operation for branch that is used _only_ to follow the upstream, so
it was changed to allow fast-forwarding without recording the mergetag.
* "git mergetool" now gives an empty file as the common base version
to the backend when dealing with the "both sides added, differently"
case.
* "git push -q" was not sufficiently quiet.
* When "git push" fails to update any refs, the client side did not
report an error correctly to the end user.
* "rebase" and "commit --amend" failed to work on commits with ancient
timestamps near year 1970.
* When asking for a tag to be pulled, "request-pull" did not show the
name of the tag prefixed with "tags/", which would have helped older
clients.
* "git submodule add $path" forgot to recompute the name to be stored
in .gitmodules when the submodule at $path was once added to the
superproject and already initialized.
* Many small corner case bugs on "git tag -n" was corrected.
Also contains minor fixes and documentation updates.
----------------------------------------------------------------
Changes since v1.7.9 are as follows:
Adrian Weimann (1):
completion: --edit and --no-edit for git-merge
Albert Yale (1):
grep: fix -l/-L interaction with decoration lines
Ben Walton (1):
Drop system includes from inet_pton/inet_ntop compatibility wrappers
Clemens Buchacher (2):
fix push --quiet: add 'quiet' capability to receive-pack
dashed externals: kill children on exit
David Aguilar (1):
mergetool: Provide an empty file when needed
Jakub Narebski (1):
git.spec: Workaround localized messages not put in any RPM
Jeff King (4):
run-command: optionally kill children on exit
imap-send: remove dead code
tag: fix output of "tag -n" when errors occur
tag: die when listing missing or corrupt objects
Jens Lehmann (1):
submodule add: fix breakage when re-adding a deep submodule
Johannes Schindelin (1):
add -e: do not show difference in a submodule that is merely dirty
Junio C Hamano (15):
server_supports(): parse feature list more carefully
Making pathspec limited log play nicer with --first-parent
request-pull: explicitly ask tags/$name to be pulled
tests: add write_script helper function
parse_date(): allow ancient git-timestamp
parse_date(): '@' prefix forces git-timestamp
merge: do not create a signed tag merge under --ff-only option
branch --edit-description: protect against mistyped branch name
Git 1.7.6.6
Prepare for 1.7.9.1
tag: do not show non-tag contents with "-n"
merge: do not launch an editor on "--no-edit $tag"
Update draft release notes to 1.7.9.1
Update draft release notes to 1.7.9.1
Git 1.7.9.1
Michael J Gruber (1):
t5541: avoid TAP test miscounting
Michael Palimaka (1):
Explicitly set X to avoid potential build breakage
Shawn O. Pearce (1):
remote-curl: Fix push status report when all branches fail
Ævar Arnfjörð Bjarmason (3):
Makefile: Change the default compiler from "gcc" to "cc"
Remove Git's support for smoke testing
t: use sane_unset instead of unset
^ permalink raw reply
* Re: cvs2git migration
From: Kevin @ 2012-02-14 19:45 UTC (permalink / raw)
To: supadhyay; +Cc: git
In-Reply-To: <1329244386868-7285021.post@n2.nabble.com>
Hi,
Because git is distributed, it has no user management (which is
impossible to do). Every user adds his name and e-mail address to his
global .gitconfig file.
For access control, you can check gitolite [1].
[1]: http://github.com/sitaramc/gitolite
On Tue, Feb 14, 2012 at 7:33 PM, supadhyay <supadhyay@imany.com> wrote:
> Hi All,
>
> Can any one please update me what would be the method/steps to migrate
> existing CVS users to GIT in CVS2GIT migration? User migration is possible
> or not?
>
> Thanks in advance...
>
> --
> View this message in context: http://git.661346.n2.nabble.com/cvs2git-migration-tp7283631p7285021.html
> Sent from the git mailing list archive at Nabble.com.
> --
> 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: cvs2git migration
From: Kevin @ 2012-02-14 19:50 UTC (permalink / raw)
To: supadhyay; +Cc: git
In-Reply-To: <1329244386868-7285021.post@n2.nabble.com>
I see that you have already asked this question before on the mailing list
See http://git.661346.n2.nabble.com/User-authentication-in-GIT-td7261349.html
On Tue, Feb 14, 2012 at 7:33 PM, supadhyay <supadhyay@imany.com> wrote:
> Hi All,
>
> Can any one please update me what would be the method/steps to migrate
> existing CVS users to GIT in CVS2GIT migration? User migration is possible
> or not?
>
> Thanks in advance...
>
> --
> View this message in context: http://git.661346.n2.nabble.com/cvs2git-migration-tp7283631p7285021.html
> Sent from the git mailing list archive at Nabble.com.
> --
> 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: diff --stat
From: Jeff King @ 2012-02-14 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4nuub7el.fsf@alter.siamese.dyndns.org>
On Mon, Feb 13, 2012 at 04:11:46PM -0800, Junio C Hamano wrote:
> Hrm, what is wrong with this picture?
>
> $ git -c diff.color.old=red show --format='%s' --stat
> Merge branch 'jk/diff-highlight' into pu
>
> contrib/diff-highlight/README | 109 ++++++++++++++++++++++++++++++--
> contrib/diff-highlight/diff-highlight | 109 ++++++++++++++++++++++++---------
> 2 files changed, 181 insertions(+), 37 deletions(-)
>
> They both have 109 lines changed but the end of the graph lines do not
> coincide...
I think it is rounding error. The first one is +102/-7, and the second
one is +79/-30. When we get to scale_linear, we try to scale 109 change
markers into a 33-character width. So the right scaling factor is ~.303.
So our "true" scaled widths should be:
README, added: 30.9
README, deleted: 2.1
highlight, added: 23.9
highlight, deleted: 9.1
However, we're dealing with integer numbers of characters, so we need to
round. In this case, it seems that our rounding produces (30, 2) in the
first instance and (24, 9) in the second. Which is odd. You'd think
we'd either always round to the nearest integer, or always round down.
But we end up rounding 30.9 down and 23.9 up. So it may be a subtle
loss-of-precision error in scale_linear.
Hmm. Looking at scale_linear, the formula is:
return ((it - 1) * (width - 1) + max_change - 1) / (max_change - 1);
I don't see how that can be accurate, since the magnitude of the "-1"
tweak will vary based on the value of "it". This code is due to
3ed74e6, but I don't quite follow the logic in the commit message.
-Peff
^ permalink raw reply
* Re: [RFC PATCH 0/3] git-p4: move to toplevel
From: Clemens Buchacher @ 2012-02-14 19:49 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Pete Wyckoff, git, Luke Diamand, Vitor Antunes
In-Reply-To: <20120214190515.GB12072@sigill.intra.peff.net>
On Tue, Feb 14, 2012 at 02:05:15PM -0500, Jeff King wrote:
>
> 2. We explicitly run "sh" in such situations, not SHELL_PATH. Even if
> "sh" is bash, I believe it should look at its own argv[0] and put
> itself into a more POSIX-y mode (but I didn't test).
Indeed it does.
^ permalink raw reply
* Re: [PATCH 6/8] gitweb: Highlight interesting parts of diff
From: Michał Kiedrowicz @ 2012-02-14 20:04 UTC (permalink / raw)
To: Jeff King; +Cc: Jakub Narebski, git
In-Reply-To: <20120214185233.GA12072@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Tue, Feb 14, 2012 at 07:23:40PM +0100, Michał Kiedrowicz wrote:
>
> > > > > BTW GitHub is closed source, but we can check what algorithm does Trac
> > > > > use for diff refinement highlighting (highlighting changed portions of
> > > > > diff).
> > > > >
> > > > I think it's
> > > > http://trac.edgewall.org/browser/trunk/trac/versioncontrol/diff.py
> > > > (see markup intraline_changes()).
> > [...]
> > [...]
> > > The markup_intraline_changes() function compares lines from preimage and
> > > from postimage pairwise, requiring that number of lines matches, the same
> > > like in your algorithm.
> >
> > So using Jeff's diff-highlight we remain quite consistent with Trac
> > output. There's nothing we can "steal" from it.
>
> Neat. When I originally wrote diff-highlight, I was inspired by seeing
> what Trac and GitHub did, but came up with the algorithm on my own.
> Learning that Trac does the multiline thing (as we started doing with
> recent patches) makes me feel even better that it's a good strategy.
>
> As an aside, I looked at what GitHub does. It turns on highlighting only
> for the single-line case, and does the same prefix/suffix thing.
>
> It's really not very complex code; most of the hassle in diff-highlight
> is ignoring (but preserving) embedded colors, so that we build on top of
> existing colorization. A web tool will be doing the line coloring itself
> anyway, so it can be much simpler. Elsewhere, I suggested lib-ifying
> diff-highlight for gitweb to use. But once you remove the embedded color
> handling, there really is not that much code, and it's probably simpler
> to just rewrite it.
>
> -Peff
Sure, now it's a simple algorithm, but if we add more code, we will
have problems with making it consistent in both gitweb and
diff-highlight (which is nice-to-have IMO). Note that my patches to
gitweb already support combined diffs (in obvious cases) while
diff-highlight will fail on them badly (see for example 09bb4eb4f14c).
I haven't done it in diff-highlight because I noticed that problem
while working on patches for gitweb.
Anyway, thanks for looking at Trac/GitHub code and sharing your opinion.
^ permalink raw reply
* Re: diff --stat
From: Junio C Hamano @ 2012-02-14 20:07 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20120214195036.GD12072@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Hmm. Looking at scale_linear, the formula is:
>
> return ((it - 1) * (width - 1) + max_change - 1) / (max_change - 1);
>
> I don't see how that can be accurate, since the magnitude of the "-1"
> tweak will vary based on the value of "it". This code is due to
> 3ed74e6, but I don't quite follow the logic in the commit message.
Doesn't it need +1 at the end, I wonder? We want to map:
- zero to zero
- any number to at least 1
so scaling a non-zero "it" so that maximum maps to (width-1) and then
adding 1 would be the right way for the latter case.
Of course, an easy way out without worrying about the correct math is to
scale the total and the smaller one and then declare that the scaled
larger one is the difference between the two. That way, both of these two
files have 109 in total so the length of the entire graph would be the
same ;-).
^ permalink raw reply
* Re: [PATCH 2/2] t: mailmap: add simple name translation test
From: Junio C Hamano @ 2012-02-14 20:10 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Marius Storm-Olsen, Jim Meyering, Jonathan Nieder
In-Reply-To: <1329235894-20581-3-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
It was clear that we didn't have any test for "blame -e" hence it was no
brainer to judge that the patch 1/2 is good without any description.
But I am scratching my head, deciphering what this patch adds.
It appears to me that the existing tests that map author@example.com from
the original "A U Thor" to "Repo Guy" and inspect names and mails in
various output already cover this "Wrong with <right@company.xx> can be
corrected to Mr. Right" case this patch adds.
What am I missing? Instead of explaining it to me, can it be explained in
the log message?
Thanks.
> t/t4203-mailmap.sh | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
> index db12265..fc3855a 100755
> --- a/t/t4203-mailmap.sh
> +++ b/t/t4203-mailmap.sh
> @@ -157,6 +157,9 @@ A U Thor <author@example.com> (1):
> CTO <cto@company.xx> (1):
> seventh
>
> +Mr. Right <right@company.xx> (1):
> + eight
> +
> Other Author <other@author.xx> (2):
> third
> fourth
> @@ -196,6 +199,11 @@ test_expect_success 'Shortlog output (complex mapping)' '
> test_tick &&
> git commit --author "CTO <cto@coompany.xx>" -m seventh &&
>
> + echo eight >>one &&
> + git add one &&
> + test_tick &&
> + git commit --author "Wrong <right@company.xx>" -m eight &&
> +
> mkdir -p internal_mailmap &&
> echo "Committed <committer@example.com>" > internal_mailmap/.mailmap &&
> echo "<cto@company.xx> <cto@coompany.xx>" >> internal_mailmap/.mailmap &&
> @@ -204,6 +212,7 @@ test_expect_success 'Shortlog output (complex mapping)' '
> echo "Other Author <other@author.xx> <nick2@company.xx>" >> internal_mailmap/.mailmap &&
> echo "Santa Claus <santa.claus@northpole.xx> <me@company.xx>" >> internal_mailmap/.mailmap &&
> echo "Santa Claus <santa.claus@northpole.xx> <me@company.xx>" >> internal_mailmap/.mailmap &&
> + echo "Mr. Right <right@company.xx>" >> internal_mailmap/.mailmap &&
>
> git shortlog -e HEAD >actual &&
> test_cmp expect actual
> @@ -212,6 +221,9 @@ test_expect_success 'Shortlog output (complex mapping)' '
>
> # git log with --pretty format which uses the name and email mailmap placemarkers
> cat >expect <<\EOF
> +Author Wrong <right@company.xx> maps to Mr. Right <right@company.xx>
> +Committer C O Mitter <committer@example.com> maps to Committed <committer@example.com>
> +
> Author CTO <cto@coompany.xx> maps to CTO <cto@company.xx>
> Committer C O Mitter <committer@example.com> maps to Committed <committer@example.com>
>
> @@ -248,6 +260,7 @@ OBJID (Other Author DATE 4) four
> OBJID (Santa Claus DATE 5) five
> OBJID (Santa Claus DATE 6) six
> OBJID (CTO DATE 7) seven
> +OBJID (Mr. Right DATE 8) eight
> EOF
> test_expect_success 'Blame output (complex mapping)' '
> git blame one >actual &&
> @@ -264,6 +277,7 @@ OBJID (<other@author.xx> DATE 4) four
> OBJID (<santa.claus@northpole.xx> DATE 5) five
> OBJID (<santa.claus@northpole.xx> DATE 6) six
> OBJID (<cto@company.xx> DATE 7) seven
> +OBJID (<right@company.xx> DATE 8) eight
> EOF
> test_expect_success 'Blame output (complex mapping)' '
> git blame -e one >actual &&
^ permalink raw reply
* Re: [PATCH v2 2/2] submodules: always use a relative path from gitdir to work tree
From: Jens Lehmann @ 2012-02-14 17:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Antony Male, Phil Hord
In-Reply-To: <7vlio6ec7q.fsf@alter.siamese.dyndns.org>
Am 13.02.2012 20:59, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> + a=$(cd "$gitdir" && pwd)
>> + b=$(cd "$path" && pwd)
>> + while [ "$b" ] && [ "${a%%/*}" = "${b%%/*}" ]
>> + do
>> + a=${a#*/} b=${b#*/};
>> + done
>> + rel=$(echo $a | sed -e 's|[^/]*|..|g')
>> + (clear_local_git_env; cd "$path" && git config core.worktree "$rel/$b")
>> }
>
>
> The style ([ "$b" ] vs "test -n "$b") aside, it strikes me odd that you
> only check $b; it is unclear what guarantees that "$a" is always longer.
> Maybe there is a reason but then a one-line comment here would not hurt?
I just copied that while loop from a few lines up, but you are right
about the style and logic issues (Will send a cleanup patch for the
other loop too when we agree on how to write this one).
After adding a comment, using test instead of [], testing both $a and
$b and assigning each variable on it's own line I get the following
interdiff. Does that make more sense?
diff --git a/git-submodule.sh b/git-submodule.sh
index 3463d6d..ed76ce2 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -172,9 +172,11 @@ module_clone()
a=$(cd "$gitdir" && pwd)
b=$(cd "$path" && pwd)
- while [ "$b" ] && [ "${a%%/*}" = "${b%%/*}" ]
+ # Remove all common leading directories
+ while test -n "$a" && test -n "$b" && test "${a%%/*}" = "${b%%/*}"
do
- a=${a#*/} b=${b#*/};
+ a=${a#*/}
+ b=${b#*/}
done
rel=$(echo $a | sed -e 's|[^/]*|..|g')
(clear_local_git_env; cd "$path" && git config core.worktree "$rel/$b")
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox