Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[brian m. carlson]

On Sat, Dec 23, 2017 at 05:44:00PM +, Ævar Arnfjörð Bjarmason wrote:
> The reason to do this is to be able to use features released with perl
> in the last decade, 5.10 was a major feature release including things
> like new regex features, state variables, the defined-or operator
> etc.[3]
> 
> I expect this to be more controversial as since the 5.8 release stayed
> along for longer in various distributions, e.g. it's the version
> shipped with RHEL 5, replaced by 5.10 in RHEL 6 released in late 2010,
> similarly the first Debian release to include 5.10 was 5.0 (Lenny)
> released in early 2009. The release history for other distributions
> can be seen on CPAN's "Perl Binaries" page[3].

This is fine by me.  As far as I know, 5.10.1 is the oldest version of
Perl still security-supported by a major Linux vendor.

Feature-wise, the release I'd much rather see is 5.14, since it provides
the r modifier to s/// and tr/// and undef-transparent length, but that
simply won't be possible until RHEL 6 and CentOS 6 go EOL.  Upgrading to
5.10 is better than nothing, and it does get us defined-or, which is one
of the only 5.10 features I ever see used.

I'm curious, though, is there some reason you went with the "v5.10.0"
syntax other than "5.010"?  I believe the latter provides a better error
message on older Perls, although I agree the former is more readable.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Re: Bring together merge and rebase

[Johannes Schindelin]

Hi Carl,

On Sat, 23 Dec 2017, Carl Baldwin wrote:

> I imagine that a "git commit --amend" would also insert a "replaces"
> reference to the original commit but I failed to mention that in my
> original post.

And cherry-pick, too, of course.

Both of these examples hint at a rather huge urge of some users to turn
this feature off because the referenced commits may very well be
throw-away commits in their case, making the newly-recorded information
completely undesired.

Example: I am working on a topic branch. In the middle, I see a typo. I
commit a fix, continue to work on the topic branch. Later, I cherry-pick
that commit to a separate topic branch because I really don't think that
those two topics are related. Now I definitely do not want a reference of
the cherry-picked commit to the original one: the latter will never be
pushed to a public repository, and gc'ed in a few weeks.

Of course, that is only my wish, other users in similar situations may
want that information. Demonstrating that you would be better served with
an opt-in feature that uses notes rather than a baked-in commit header.

Ciao,
Johannes

Re: [PATCH] setup.c: move statement under condition

[Johannes Schindelin]

Hi Vadim,

thank you for your contribution!

On Sun, 24 Dec 2017, Vadim Petrov wrote:

> I suppose that if the condition is fulfilled then the previously
> obtained value will not be necessary.

I have to be honest: this commit message (including the subject) left me
quite puzzled as to the intent of this patch.

Maybe something like this would have spared me that puzzlement:

Avoid unnecessary offset_1st_component() when prefixing filenames

In the abspath_part_inside_repo() function that is called
somewhere deep in the call-chain when prefixing paths, we
calculate the offset of the first component, but under certain
circumstances, the result is not even used.

This patch changes the code to avoid that.

If you also have a background story that motivated you to work on this
patch (for example, if you hit a huge performance bottleneck with some
tool that fed thousands of absolute paths to Git that needed to be turned
into paths relative to the worktree's top-level directory), I would
definitely put that into the commit message, too, if I were you.

> diff --git a/setup.c b/setup.c
> index 8cc34186c..1ce0189fa 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -35,7 +35,6 @@ static int abspath_part_inside_repo(char *path)
>   return -1;
>   wtlen = strlen(work_tree);
>   len = strlen(path);
> - off = offset_1st_component(path);
>  
>   /* check if work tree is already the prefix */
>   if (wtlen <= len && !strncmp(path, work_tree, wtlen)) {
> @@ -49,6 +48,8 @@ static int abspath_part_inside_repo(char *path)
>   }
>   /* work tree might match beginning of a symlink to work tree */
>   off = wtlen;
> + } else {
> + off = offset_1st_component(path);
>   }

Up until recently, we encouraged dropping the curly brackets from
single-line statements, but apparently that changed. It is now no longer
clear, and often left to the taste of the contributor. But not always.
Sometimes we start a beautiful thread discussion the pros and cons of
curly brackets in the middle of patch review, and drop altogether
reviewing the actual patch.

However, we still encourage to put shorter alternative code paths
(i.e. the blocks after `if` and `else`) first, in your case:

@@ -35,18 +35,19 @@ static int abspath_part_inside_repo(char *path)
return -1;
wtlen = strlen(work_tree);
len = strlen(path);
-   off = offset_1st_component(path);
 
/* check if work tree is already the prefix */
-   if (wtlen <= len && !strncmp(path, work_tree, wtlen)) {
+   if (wtlen > len || strncmp(path, work_tree, wtlen))
+   off = offset_1st_component(path);
+   else {
if (path[wtlen] == '/') {
memmove(path, path + wtlen + 1, len - wtlen);
return 0;
} else if (path[wtlen - 1] == '/' || path[wtlen] == '\0') {
/* work tree is the root, or the whole path */
memmove(path, path + wtlen, len - wtlen + 1);
return 0;
}
/* work tree might match beginning of a symlink to work * tree 
*/
off = wtlen;
}

I would also encourage to generate the patch so that it includes the `off
= wtlen` line (by passing -U11 or some such to `git format-patch`), to
make the review super easy.

In short: I think your patch does the right thing, and I hope that you
find my suggestions to improve the patch useful.

Ciao,
Johannes

Re: Bring together merge and rebase

[Johannes Schindelin]

Hi Ævar,

On Sat, 23 Dec 2017, Ævar Arnfjörð Bjarmason wrote:

> On Sat, Dec 23 2017, Carl Baldwin jotted:
> 
> > The big contention among git users is whether to rebase or to merge
> > changes [2][3] while iterating. I used to firmly believe that merging
> > was the way to go and rebase was harmful. More recently, I have worked
> > in some environments where I saw rebase used very effectively while
> > iterating on changes and I relaxed my stance a lot. Now, I'm on the
> > fence. I appreciate the strengths and weaknesses of both approaches. I
> > waffle between the two depending on the situation, the tools being
> > used, and I guess, to some extent, my mood.
> >
> > I think what git needs is something brand new that brings the two
> > together and has all of the advantages of both approaches. Let me
> > explain what I've got in mind...
> >
> > I've been calling this proposal `git replay` or `git replace` but I'd
> > like to hear other suggestions for what to name it. It works like
> > rebase except with one very important difference. Instead of orphaning
> > the original commit, it keeps a pointer to it in the commit just like
> > a `parent` entry but calls it `replaces` instead to distinguish it
> > from regular history. In the resulting commit history, following
> > `parent` pointers shows exactly the same history as if the commit had
> > been rebased. Meanwhile, the history of iterating on the change itself
> > is available by following `replaces` pointers. The new commit replaces
> > the old one but keeps it around to record how the change evolved.
> >
> > The git history now has two dimensions. The first shows a cleaned up
> > history where fix ups and code review feedback have been rolled into
> > the original changes and changes can possibly be ordered in a nice
> > linear progression that is much easier to understand. The second
> > drills into the history of a change. There is no loss and you don't
> > change history in a way that will cause problems for others who have
> > the older commits.
> >
> > Replay handles collaboration between multiple authors on a single
> > change. This is difficult and prone to accidental loss when using
> > rebase and it results in a complex history when done with merge. With
> > replay, collaborators could merge while collaborating on a single
> > change and a record of each one's contributions can be preserved.
> > Attempting this level of collaboration caused me many headaches when I
> > worked with the gerrit workflow (which in many ways, I like a lot).
> >
> > I blogged about this proposal earlier this year when I first thought
> > of it [1]. I got busy and didn't think about it for a while. Now with
> > a little time off of work, I've come back to revisit it. The blog
> > entry has a few examples showing how it works and how the history will
> > look in a few examples. Take a look.
> >
> > Various git commands will have to learn how to handle this kind of
> > history. For example, things like fetch, push, gc, and others that
> > move history around and clean out orphaned history should treat
> > anything reachable through `replaces` pointers as precious. Log and
> > related history commands may need new switches to traverse the history
> > differently in different situations. Bisect is a interesting one. I
> > tend to think that bisect should prefer the regular commit history but
> > have the ability to drill into the change history if necessary.
> >
> > In my opinion, this proposal would bring together rebase and merge in
> > a powerful way and could end the contention. Thanks for your
> > consideration.
> >
> > Carl Baldwin
> >
> > [1] http://blog.episodicgenius.com/post/merge-or-rebase--neither/ [2]
> > https://git-scm.com/book/en/v2/Git-Branching-Rebasing [3]
> > http://changelog.complete.org/archives/586-rebase-considered-harmful
> 
> I think this is a worthwhile thing to implement, there are certainly
> use-cases where you'd like to have your cake & eat it too as it were,
> i.e. have a nice rebased history in "git log", but also have the "raw"
> history for all the reasons the fossil people like to talk about, or for
> some compliance reasons.
> 
> But I don't see why you think this needs a new "replaces" parent pointer
> orthagonal to parent pointers, i.e. something that would need to be a
> new field in the commit object (I may have misread the proposal, it's
> not heavy on technical details).
> 
> Consider a merge use case like this:
> 
>   A---B---C topic
>  / \
> D---E---F---G---H master
> 
> Here we worked on a topic with commits A,B & C, maybe we regret not
> squashing B into A, but it gives us the "raw" history. Instead we might
> rebase it like this:
> 
>   A+B---C topic
>  /
> G---H master
> 
> Now we can push "topic" to master, but as you've noted this loses the
> raw history, but now consider doing this instead:
> 
>   A---B---C   A2+B2---C2 topic
>  / \ /
> 

RE: Bring together merge and rebase

[Randall S. Becker]

On December 23, 2017 4:02 PM, Carl Baldwin wrote:
> On Sat, Dec 23, 2017 at 07:59:35PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > I think this is a worthwhile thing to implement, there are certainly
> > use-cases where you'd like to have your cake & eat it too as it were,
> > i.e. have a nice rebased history in "git log", but also have the "raw"
> > history for all the reasons the fossil people like to talk about, or
> > for some compliance reasons.
> 
> Thank you kindly for your reply. I do think we can have the cake and eat it
> too in this case. At a high level, what you describe above is what I'm after.
> I'm sorry if I left something out or was unclear. I hoped to keep my original
> post brief. Maybe it was too brief to be useful.
> However, I'd like to follow up and be understood.
> 
> > But I don't see why you think this needs a new "replaces" parent
> > pointer orthagonal to parent pointers, i.e. something that would need
> > to be a new field in the commit object (I may have misread the
> > proposal, it's not heavy on technical details).
> 
> Just to clarify, I am proposing a new "replaces" pointer in the commit object.
> Imagine starting with rebase exactly as it works today. This new field would
> be inserted into any new commit created by a rebase command to reference
> the original commit on which it was based. Though, I'm not sure if it would
> be better to change the behavior of the existing rebase command, provide a
> switch or config option to turn it on, or provide a new command entirely (e.g.
> git replay or git replace) to avoid compatibility issues with the existing 
> rebase.
> 
> I imagine that a "git commit --amend" would also insert a "replaces"
> reference to the original commit but I failed to mention that in my original
> post. The amend use case is similar to adding a fixup commit and then doing
> a squash in interactive mode.
> 
> > Consider a merge use case like this:
> >
> >   A---B---C topic
> >  / \
> > D---E---F---G---H master
> 
> This is a bit different than the use cases that I've had in mind. You show 
> that
> the topic has already merged to master. I have imagined this proposal being
> useful before the topic becomes a part of the master branch. I'm thinking in
> the context of something like a github pull request under active development
> and review or a gerrit review. So, at this point, we still look like this:
> 
>   A---B---C topic
>  /
> D---E---F---G
> 
> > Here we worked on a topic with commits A,B & C, maybe we regret not
> > squashing B into A, but it gives us the "raw" history. Instead we
> > might rebase it like this:
> >
> >   A+B---C topic
> >  /
> > G---H master
> 
> Since H already merged the topic. I'm not sure what the A+B and C commits
> are doing.
> 
> At the point where I have C and G above, let's say I regret not having
> squashed A and B as you suggested. My proposal would end up as I draw
> below where the primes are the new versions of the commits (A' is A+B).
> Bare with me, I'm not sure the best way to draw this in ascii. It has that
> orthogoal dimension that makes the ascii drawings a little more
> complex: (I left out the parent of A' which is still E)
> 
>A--B---C
> \ |\<- "replaces" rather than "parent"
>  -A'C' topic
>  /
> D---E---F---G master
> 
> We can continue by actually changing the base. All of these commits are
> kept, I just drop them from the drawings to avoid getting too complex.
> 
> A'--C'
>  \   \  <- "replaces" rather than "parent"
>   A"--C" topic
>  /
> D---E---F---G master
> 
> Normal git log operations would ignore them by default. When finally
> merging to master, it ends up very simple (by default) but the history is 
> still
> there to support archealogic operations.
> 
> D---E---F---G---A"--C" master
> 
> > Now we can push "topic" to master, but as you've noted this loses the
> > raw history, but now consider doing this instead:
> >
> >   A---B---C   A2+B2---C2 topic
> >  / \ /
> > D---E---F---G---G master
> 
> There are two Gs in this drawing. Should the second be H? Sorry, I'm just
> trying to understanding the use case you're describing and I don't
> understand it yet which makes it difficult to comment on the rest of your
> reply.
> 
> > I.e. you could have started working on commit A/B/C, now you "git
> > replace" them (which would be some fancy rebase alias), and what it'll
> > do is create a merge commit that entirely resolves the conflict so
> > that hte tree is equivalent to what "master" was already at. Then you
> > rewrite them and re-apply them on top.
> >
> > If you run "git log" it will already ignore A,B,C unless you specify
> > --full-history, so git already knows to ignore these sort of side
> > histories that result in no changes on the branch they got 

Re: Bring together merge and rebase

[Ævar Arnfjörð Bjarmason]

On Sat, Dec 23 2017, Carl Baldwin jotted:

> On Sat, Dec 23, 2017 at 07:59:35PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> I think this is a worthwhile thing to implement, there are certainly
>> use-cases where you'd like to have your cake & eat it too as it were,
>> i.e. have a nice rebased history in "git log", but also have the "raw"
>> history for all the reasons the fossil people like to talk about, or for
>> some compliance reasons.
>
> Thank you kindly for your reply. I do think we can have the cake and eat
> it too in this case. At a high level, what you describe above is what
> I'm after. I'm sorry if I left something out or was unclear. I hoped to
> keep my original post brief. Maybe it was too brief to be useful.
> However, I'd like to follow up and be understood.
>
>> But I don't see why you think this needs a new "replaces" parent pointer
>> orthagonal to parent pointers, i.e. something that would need to be a
>> new field in the commit object (I may have misread the proposal, it's
>> not heavy on technical details).
>
> Just to clarify, I am proposing a new "replaces" pointer in the commit
> object. Imagine starting with rebase exactly as it works today. This new
> field would be inserted into any new commit created by a rebase command
> to reference the original commit on which it was based. Though, I'm not
> sure if it would be better to change the behavior of the existing rebase
> command, provide a switch or config option to turn it on, or provide a
> new command entirely (e.g. git replay or git replace) to avoid
> compatibility issues with the existing rebase.

Yeah that sounds fine, I thought you meant that this "replaces" field
would replace the "parent" field, which would require some rather deep
incompatible changes to all git clients.

But then I don't get why you think fetch/pull/gc would need to be
altered, if it's because you thought that adding arbitrary *new* fields
to the commit object would require changes to those that's not the case.

> I imagine that a "git commit --amend" would also insert a "replaces"
> reference to the original commit but I failed to mention that in my
> original post. The amend use case is similar to adding a fixup commit
> and then doing a squash in interactive mode.
>
>> Consider a merge use case like this:
>>
>>   A---B---C topic
>>  / \
>> D---E---F---G---H master
>
> This is a bit different than the use cases that I've had in mind. You
> show that the topic has already merged to master. I have imagined this
> proposal being useful before the topic becomes a part of the master
> branch. I'm thinking in the context of something like a github pull
> request under active development and review or a gerrit review. So, at
> this point, we still look like this:
>
>   A---B---C topic
>  /
> D---E---F---G

Right, I'm just mentioning this for context, i.e. "if you only used
git-merge".

>> Here we worked on a topic with commits A,B & C, maybe we regret not
>> squashing B into A, but it gives us the "raw" history. Instead we might
>> rebase it like this:
>>
>>   A+B---C topic
>>  /
>> G---H master
>
> Since H already merged the topic. I'm not sure what the A+B and C
> commits are doing.

This means that master is at commit H, but your newly rebased topic is
at C, i.e. master has no new commits so you could `git push origin
C:master` without -f.

> At the point where I have C and G above, let's say I regret not having
> squashed A and B as you suggested. My proposal would end up as I draw
> below where the primes are the new versions of the commits (A' is A+B).
> Bare with me, I'm not sure the best way to draw this in ascii. It has
> that orthogoal dimension that makes the ascii drawings a little more
> complex: (I left out the parent of A' which is still E)
>
>A--B---C
> \ |\<- "replaces" rather than "parent"
>  -A'C' topic
>  /
> D---E---F---G master
>
> We can continue by actually changing the base. All of these commits are
> kept, I just drop them from the drawings to avoid getting too complex.
>
> A'--C'
>  \   \  <- "replaces" rather than "parent"
>   A"--C" topic
>  /
> D---E---F---G master
>
> Normal git log operations would ignore them by default. When finally
> merging to master, it ends up very simple (by default) but the history
> is still there to support archealogic operations.
>
> D---E---F---G---A"--C" master
>
>> Now we can push "topic" to master, but as you've noted this loses the
>> raw history, but now consider doing this instead:
>>
>>   A---B---C   A2+B2---C2 topic
>>  / \ /
>> D---E---F---G---G master
>
> There are two Gs in this drawing. Should the second be H? Sorry, I'm
> just trying to understanding the use case you're describing and I don't
> understand it yet which makes it difficult to 

[PATCH 4/6] wildmatch test: remove dead fnmatch() test code

[Ævar Arnfjörð Bjarmason]

Remove the unused fnmatch() test parameter from the wildmatch
test. The code that used to test this was removed in 70a8fc999d ("stop
using fnmatch (either native or compat)", 2014-02-15).

As a --word-diff shows the only change to the body of the tests is the
removal of the second out of four parameters passed to match().

Signed-off-by: Ævar Arnfjörð Bjarmason 
---
 t/t3070-wildmatch.sh | 356 +--
 1 file changed, 178 insertions(+), 178 deletions(-)

diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 71d6ea0f56..1624200a1e 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -7,13 +7,13 @@ test_description='wildmatch tests'
 match() {
if test "$1" = 1
then
-   test_expect_success "wildmatch: match '$3' '$4'" "
-   test-wildmatch wildmatch '$3' '$4'
+   test_expect_success "wildmatch: match '$2' '$3'" "
+   test-wildmatch wildmatch '$2' '$3'
"
elif test "$1" = 0
then
-   test_expect_success "wildmatch:  no match '$3' '$4'" "
-   ! test-wildmatch wildmatch '$3' '$4'
+   test_expect_success "wildmatch:  no match '$2' '$3'" "
+   ! test-wildmatch wildmatch '$2' '$3'
"
else
test_expect_success "PANIC: Test framework error. Unknown 
matches value $1" 'false'
@@ -53,176 +53,176 @@ pathmatch() {
 }
 
 # Basic wildmat features
-match 1 1 foo foo
-match 0 0 foo bar
-match 1 1 '' ""
-match 1 1 foo '???'
-match 0 0 foo '??'
-match 1 1 foo '*'
-match 1 1 foo 'f*'
-match 0 0 foo '*f'
-match 1 1 foo '*foo*'
-match 1 1 foobar '*ob*a*r*'
-match 1 1 aaabababab '*ab'
-match 1 1 'foo*' 'foo\*'
-match 0 0 foobar 'foo\*bar'
-match 1 1 'f\oo' 'f\\oo'
-match 1 1 ball '*[al]?'
-match 0 0 ten '[ten]'
-match 0 1 ten '**[!te]'
-match 0 0 ten '**[!ten]'
-match 1 1 ten 't[a-g]n'
-match 0 0 ten 't[!a-g]n'
-match 1 1 ton 't[!a-g]n'
-match 1 1 ton 't[^a-g]n'
-match 1 x 'a]b' 'a[]]b'
-match 1 x a-b 'a[]-]b'
-match 1 x 'a]b' 'a[]-]b'
-match 0 x aab 'a[]-]b'
-match 1 x aab 'a[]a-]b'
-match 1 1 ']' ']'
+match 1 foo foo
+match 0 foo bar
+match 1 '' ""
+match 1 foo '???'
+match 0 foo '??'
+match 1 foo '*'
+match 1 foo 'f*'
+match 0 foo '*f'
+match 1 foo '*foo*'
+match 1 foobar '*ob*a*r*'
+match 1 aaabababab '*ab'
+match 1 'foo*' 'foo\*'
+match 0 foobar 'foo\*bar'
+match 1 'f\oo' 'f\\oo'
+match 1 ball '*[al]?'
+match 0 ten '[ten]'
+match 0 ten '**[!te]'
+match 0 ten '**[!ten]'
+match 1 ten 't[a-g]n'
+match 0 ten 't[!a-g]n'
+match 1 ton 't[!a-g]n'
+match 1 ton 't[^a-g]n'
+match 1 'a]b' 'a[]]b'
+match 1 a-b 'a[]-]b'
+match 1 'a]b' 'a[]-]b'
+match 0 aab 'a[]-]b'
+match 1 aab 'a[]a-]b'
+match 1 ']' ']'
 
 # Extended slash-matching features
-match 0 0 'foo/baz/bar' 'foo*bar'
-match 0 0 'foo/baz/bar' 'foo**bar'
-match 0 1 'foobazbar' 'foo**bar'
-match 1 1 'foo/baz/bar' 'foo/**/bar'
-match 1 0 'foo/baz/bar' 'foo/**/**/bar'
-match 1 0 'foo/b/a/z/bar' 'foo/**/bar'
-match 1 0 'foo/b/a/z/bar' 'foo/**/**/bar'
-match 1 0 'foo/bar' 'foo/**/bar'
-match 1 0 'foo/bar' 'foo/**/**/bar'
-match 0 0 'foo/bar' 'foo?bar'
-match 0 0 'foo/bar' 'foo[/]bar'
-match 0 0 'foo/bar' 'foo[^a-z]bar'
-match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
-match 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
-match 1 0 'foo' '**/foo'
-match 1 x 'XXX/foo' '**/foo'
-match 1 0 'bar/baz/foo' '**/foo'
-match 0 0 'bar/baz/foo' '*/foo'
-match 0 0 'foo/bar/baz' '**/bar*'
-match 1 0 'deep/foo/bar/baz' '**/bar/*'
-match 0 0 'deep/foo/bar/baz/' '**/bar/*'
-match 1 0 'deep/foo/bar/baz/' '**/bar/**'
-match 0 0 'deep/foo/bar' '**/bar/*'
-match 1 0 'deep/foo/bar/' '**/bar/**'
-match 0 0 'foo/bar/baz' '**/bar**'
-match 1 0 'foo/bar/baz/x' '*/bar/**'
-match 0 0 'deep/foo/bar/baz/x' '*/bar/**'
-match 1 0 'deep/foo/bar/baz/x' '**/bar/*/*'
+match 0 'foo/baz/bar' 'foo*bar'
+match 0 'foo/baz/bar' 'foo**bar'
+match 0 'foobazbar' 'foo**bar'
+match 1 'foo/baz/bar' 'foo/**/bar'
+match 1 'foo/baz/bar' 'foo/**/**/bar'
+match 1 'foo/b/a/z/bar' 'foo/**/bar'
+match 1 'foo/b/a/z/bar' 'foo/**/**/bar'
+match 1 'foo/bar' 'foo/**/bar'
+match 1 'foo/bar' 'foo/**/**/bar'
+match 0 'foo/bar' 'foo?bar'
+match 0 'foo/bar' 'foo[/]bar'
+match 0 'foo/bar' 'foo[^a-z]bar'
+match 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
+match 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
+match 1 'foo' '**/foo'
+match 1 'XXX/foo' '**/foo'
+match 1 'bar/baz/foo' '**/foo'
+match 0 'bar/baz/foo' '*/foo'
+match 0 'foo/bar/baz' '**/bar*'
+match 1 'deep/foo/bar/baz' '**/bar/*'
+match 0 'deep/foo/bar/baz/' '**/bar/*'
+match 1 'deep/foo/bar/baz/' '**/bar/**'
+match 0 'deep/foo/bar' '**/bar/*'
+match 1 'deep/foo/bar/' '**/bar/**'
+match 0 'foo/bar/baz' '**/bar**'
+match 1 'foo/bar/baz/x' '*/bar/**'
+match 0 'deep/foo/bar/baz/x' '*/bar/**'
+match 1 'deep/foo/bar/baz/x' '**/bar/*/*'
 
 # Various additional tests
-match 0 0 'acrt' 

[PATCH 6/6] wildmatch test: create & test files on disk in addition to in-memory

[Ævar Arnfjörð Bjarmason]

There has never been any full roundtrip testing of what git-ls-files
and other functions that use wildmatch() actually do, rather we've
been satisfied with just testing the underlying C function.

Due to git-ls-files and friends having their own codepaths before they
call wildmatch() there's sometimes differences in the behavior between
the two, and even when we test for those (as with
9e4e8a64c2 ("pathspec: die on empty strings as pathspec", 2017-06-06))
there was no one place where you can review how these two modes
differ.

Now there is. With this admittedly very verbose code that's mostly
copy-pasted (it doesn't look worth the effort to me in clarity to
factor this into functions) we now attempt to create a file called
$haystack and match $needle against it for each pair of $needle and
$haystack that we were passing to test-wildmatch.

If we can't create the file we skip the test. This ensures that we can
run this on all platforms and not maintain some infinitely growing
whitelist of e.g. platforms that don't support certain characters in
filenames.

As a result of doing this we can now see the cases where these two
ways of testing wildmatch differ:

 * Creating a file called 'a[]b' and running ls-files 'a[]b' will show
   that file, but wildmatch("a[]b", "a[]b") will not match

 * wildmatch() won't match a file called \ against \, but ls-files
   will.

 * `git --glob-pathspecs ls-files 'foo**'` will match a file
   'foo/bba/arr', but wildmatch won't, however pathmatch will.

   This seems like a bug to me, the two are otherwise equivalent as
   these tests show.

This also reveals the case discussed in 9e4e8a64c2 above, where '' is
now an error as far as ls-files is concerned, but wildmatch() itself
happily accepts it.

Signed-off-by: Ævar Arnfjörð Bjarmason 
---
 a[]b |   0
 t/t3070-wildmatch.sh | 336 ---
 2 files changed, 319 insertions(+), 17 deletions(-)
 create mode 100644 a[]b

diff --git a/a[]b b/a[]b
new file mode 100644
index 00..e69de29bb2
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 47b479e423..d423bb01f3 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -4,31 +4,146 @@ test_description='wildmatch tests'
 
 . ./test-lib.sh
 
+create_test_file() {
+   file=$1
+
+   # `touch .` will succeed but obviously not do what we intend
+   # here.
+   test "$file" = "." && return 1
+   # We cannot create a file with an empty filename.
+   test "$file" = "" && return 1
+   # The tests that are testing that e.g. foo//bar is matched by
+   # foo/*/bar can't be tested on filesystems since there's no
+   # way we're getting a double slash.
+   echo "$file" | grep -q -F '//' && return 1
+   # When testing the difference between foo/bar and foo/bar/ we
+   # can't test the latter.
+   echo "$file" | grep -q -E '/$' && return 1
+
+   dirs=$(echo "$file" | sed -r 's!/[^/]+$!!')
+
+   # We touch "./$file" instead of "$file" because even an
+   # escaped "touch -- -" means something different.
+   if test "$file" != "$dirs"
+   then
+   mkdir -p -- "$dirs" 2>/dev/null &&
+   touch -- "./$file" 2>/dev/null &&
+   return 0
+   else
+   touch -- "./$file" 2>/dev/null &&
+   return 0
+   fi
+   return 1
+}
+
 wildtest() {
-   match_w_glob=$1
-   match_w_globi=$2
-   match_w_pathmatch=$3
-   match_w_pathmatchi=$4
-   text=$5
-   pattern=$6
+   if test "$#" = 6
+   then
+   # When test-wildmatch and git ls-files produce the same
+   # result.
+   match_w_glob=$1
+   match_f_w_glob=$match_w_glob
+   match_w_globi=$2
+   match_f_w_globi=$match_w_globi
+   match_w_pathmatch=$3
+   match_f_w_pathmatch=$match_w_pathmatch
+   match_w_pathmatchi=$4
+   match_f_w_pathmatchi=$match_w_pathmatchi
+   text=$5
+   pattern=$6
+   elif test "$#" = 10
+   then
+   match_w_glob=$1
+   match_w_globi=$2
+   match_w_pathmatch=$3
+   match_w_pathmatchi=$4
+   match_f_w_glob=$5
+   match_f_w_globi=$6
+   match_f_w_pathmatch=$7
+   match_f_w_pathmatchi=$8
+   text=$9
+   pattern=$10
+   fi
 
+   # $1: Case sensitive glob match: test-wildmatch
if test "$match_w_glob" = 1
then
-   test_expect_success "wildmatch: match '$text' '$pattern'" "
+   test_expect_success "wildmatch: match '$text' '$pattern'" "
test-wildmatch wildmatch '$text' '$pattern'
"
elif test "$match_w_glob" = 0
then
-   test_expect_success "wildmatch:  no match '$text' '$pattern'" "
+   

[PATCH 5/6] wildmatch test: perform all tests under all wildmatch() modes

[Ævar Arnfjörð Bjarmason]

Rewrite the wildmatch() test suite so that each test now tests all
combinations of the wildmatch() WM_CASEFOLD and WM_PATHNAME flags.

Before this change some test inputs were not tested on
e.g. WM_PATHNAME. Now the function is stress tested on all possible
inputs, and for each input we declare what the result should be if the
mode is case-insensitive, or pathname matching, or case-sensitive or
not matching pathnames.

Also before this change, nothing was testing case-insensitive
non-pathname matching, so I've added that to test-wildmatch.c and made
use of it.

This yields a rather scary patch, but there are no functional changes
here, just more test coverage. Some now-redundant tests were deleted
as a result of this change, since they were now duplicating an earlier
test.

Signed-off-by: Ævar Arnfjörð Bjarmason 
---
 t/helper/test-wildmatch.c |   2 +
 t/t3070-wildmatch.sh  | 478 +++---
 2 files changed, 239 insertions(+), 241 deletions(-)

diff --git a/t/helper/test-wildmatch.c b/t/helper/test-wildmatch.c
index 921d7b3e7e..66d33dfcfd 100644
--- a/t/helper/test-wildmatch.c
+++ b/t/helper/test-wildmatch.c
@@ -16,6 +16,8 @@ int cmd_main(int argc, const char **argv)
return !!wildmatch(argv[3], argv[2], WM_PATHNAME | WM_CASEFOLD);
else if (!strcmp(argv[1], "pathmatch"))
return !!wildmatch(argv[3], argv[2], 0);
+   else if (!strcmp(argv[1], "ipathmatch"))
+   return !!wildmatch(argv[3], argv[2], WM_CASEFOLD);
else
return 1;
 }
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 1624200a1e..47b479e423 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -4,278 +4,274 @@ test_description='wildmatch tests'
 
 . ./test-lib.sh
 
-match() {
-   if test "$1" = 1
+wildtest() {
+   match_w_glob=$1
+   match_w_globi=$2
+   match_w_pathmatch=$3
+   match_w_pathmatchi=$4
+   text=$5
+   pattern=$6
+
+   if test "$match_w_glob" = 1
then
-   test_expect_success "wildmatch: match '$2' '$3'" "
-   test-wildmatch wildmatch '$2' '$3'
+   test_expect_success "wildmatch: match '$text' '$pattern'" "
+   test-wildmatch wildmatch '$text' '$pattern'
"
-   elif test "$1" = 0
+   elif test "$match_w_glob" = 0
then
-   test_expect_success "wildmatch:  no match '$2' '$3'" "
-   ! test-wildmatch wildmatch '$2' '$3'
+   test_expect_success "wildmatch:  no match '$text' '$pattern'" "
+   ! test-wildmatch wildmatch '$text' '$pattern'
"
else
-   test_expect_success "PANIC: Test framework error. Unknown 
matches value $1" 'false'
+   test_expect_success "PANIC: Test framework error. Unknown 
matches value $match_w_glob" 'false'
fi
-}
 
-imatch() {
-   if test "$1" = 1
+   if test "$match_w_globi" = 1
then
-   test_expect_success "iwildmatch:match '$2' '$3'" "
-   test-wildmatch iwildmatch '$2' '$3'
+   test_expect_success "iwildmatch:match '$text' '$pattern'" "
+   test-wildmatch iwildmatch '$text' '$pattern'
"
-   elif test "$1" = 0
+   elif test "$match_w_globi" = 0
then
-   test_expect_success "iwildmatch: no match '$2' '$3'" "
-   ! test-wildmatch iwildmatch '$2' '$3'
+   test_expect_success "iwildmatch: no match '$text' '$pattern'" "
+   ! test-wildmatch iwildmatch '$text' '$pattern'
"
else
-   test_expect_success "PANIC: Test framework error. Unknown 
matches value $1" 'false'
+   test_expect_success "PANIC: Test framework error. Unknown 
matches value $match_w_globi" 'false'
fi
-}
 
-pathmatch() {
-   if test "$1" = 1
+   if test "$match_w_pathmatch" = 1
then
-   test_expect_success "pathmatch: match '$2' '$3'" "
-   test-wildmatch pathmatch '$2' '$3'
+   test_expect_success "pathmatch: match '$text' '$pattern'" "
+   test-wildmatch pathmatch '$text' '$pattern'
"
-   elif test "$1" = 0
+   elif test "$match_w_pathmatch" = 0
then
-   test_expect_success "pathmatch:  no match '$2' '$3'" "
-   ! test-wildmatch pathmatch '$2' '$3'
+   test_expect_success "pathmatch:  no match '$text' '$pattern'" "
+   ! test-wildmatch pathmatch '$text' '$pattern'
"
else
-   test_expect_success "PANIC: Test framework error. Unknown 
matches value $1" 'false'
+   test_expect_success "PANIC: Test framework error. Unknown 
matches value $match_w_pathmatch" 'false'
+   fi
+
+ 

[PATCH 3/6] wildmatch test: use a paranoia pattern from nul_match()

[Ævar Arnfjörð Bjarmason]

Use a pattern from the nul_match() function in t7008-grep-binary.sh to
make sure that we don't just fall through to the "else" if there's an
unknown parameter.

This is something I added in commit 77f6f4406f ("grep: add a test
helper function for less verbose -f \0 tests", 2017-05-20) to grep
tests, which were modeled on these wildmatch tests, and I'm now
porting back to the original wildmatch tests.

Signed-off-by: Ævar Arnfjörð Bjarmason 
---
 t/t3070-wildmatch.sh | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 4d589d1f9a..71d6ea0f56 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -10,10 +10,13 @@ match() {
test_expect_success "wildmatch: match '$3' '$4'" "
test-wildmatch wildmatch '$3' '$4'
"
-   else
+   elif test "$1" = 0
+   then
test_expect_success "wildmatch:  no match '$3' '$4'" "
! test-wildmatch wildmatch '$3' '$4'
"
+   else
+   test_expect_success "PANIC: Test framework error. Unknown 
matches value $1" 'false'
fi
 }
 
@@ -23,10 +26,13 @@ imatch() {
test_expect_success "iwildmatch:match '$2' '$3'" "
test-wildmatch iwildmatch '$2' '$3'
"
-   else
+   elif test "$1" = 0
+   then
test_expect_success "iwildmatch: no match '$2' '$3'" "
! test-wildmatch iwildmatch '$2' '$3'
"
+   else
+   test_expect_success "PANIC: Test framework error. Unknown 
matches value $1" 'false'
fi
 }
 
@@ -36,10 +42,13 @@ pathmatch() {
test_expect_success "pathmatch: match '$2' '$3'" "
test-wildmatch pathmatch '$2' '$3'
"
-   else
+   elif test "$1" = 0
+   then
test_expect_success "pathmatch:  no match '$2' '$3'" "
! test-wildmatch pathmatch '$2' '$3'
"
+   else
+   test_expect_success "PANIC: Test framework error. Unknown 
matches value $1" 'false'
fi
 }
 
-- 
2.15.1.424.g9478a66081

[PATCH 2/6] wildmatch test: use more standard shell style

[Ævar Arnfjörð Bjarmason]

Change the wildmatch test to use more standard shell style, usually we
use "if test" not "if [".

Signed-off-by: Ævar Arnfjörð Bjarmason 
---
 t/t3070-wildmatch.sh | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 27fa878f6e..4d589d1f9a 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -5,7 +5,8 @@ test_description='wildmatch tests'
 . ./test-lib.sh
 
 match() {
-   if [ $1 = 1 ]; then
+   if test "$1" = 1
+   then
test_expect_success "wildmatch: match '$3' '$4'" "
test-wildmatch wildmatch '$3' '$4'
"
@@ -17,7 +18,8 @@ match() {
 }
 
 imatch() {
-   if [ $1 = 1 ]; then
+   if test "$1" = 1
+   then
test_expect_success "iwildmatch:match '$2' '$3'" "
test-wildmatch iwildmatch '$2' '$3'
"
@@ -29,7 +31,8 @@ imatch() {
 }
 
 pathmatch() {
-   if [ $1 = 1 ]; then
+   if test "$1" = 1
+   then
test_expect_success "pathmatch: match '$2' '$3'" "
test-wildmatch pathmatch '$2' '$3'
"
-- 
2.15.1.424.g9478a66081

[PATCH 0/6] increase wildmatch test coverage

[Ævar Arnfjörð Bjarmason]

This increases the test coverage we have for wildmatch, and hopefully
doesn't break anything, but see the fantastic hack that is 6/6 and
form your own opinion.

The backstory of this is that back in June I posted an RFC series here
to the list to refactor wildmatch() itself to no-op support
precompiling patterns:
https://public-inbox.org/git/20170622213810.14785-1-ava...@gmail.com/

The intent was to swap out wildmatch() to use PCRE as an engine, my
performance tests reveal that that was probably a dumb idea.

We may still want something like those patches I submitted back in
June, in particular we could rewrite wildmatch.c itself to precompile
a pattern. if this makes it in I'll see about rebasing those on top,
but I'm not in any rush with those.

But in writing up those initial patches (and some "use PCRE for this")
that hasn't made it on the list, I discovered that I didn't have any
faith in our wildmatch tests, it was easy to find case I could break
and all tests would still pass.

This series fixes that, whatever we do with wildmatch in the future
it'll be really nice to have this, since we now have exhaustive test
coverage of wildmatch, both through the raw function as before (but as
5/6 there were holes in that), and more importantly by doing the same
tests through ls-files, which is the interface users actually use, and
as 6/6 reveals sometimes behaves differently than the underlying
matching function.

Ævar Arnfjörð Bjarmason (6):
  wildmatch test: indent with tabs, not spaces
  wildmatch test: use more standard shell style
  wildmatch test: use a paranoia pattern from nul_match()
  wildmatch test: remove dead fnmatch() test code
  wildmatch test: perform all tests under all wildmatch() modes
  wildmatch test: create & test files on disk in addition to in-memory

 a[]b  |   0
 t/helper/test-wildmatch.c |   2 +
 t/t3070-wildmatch.sh  | 802 --
 3 files changed, 558 insertions(+), 246 deletions(-)
 create mode 100644 a[]b

-- 
2.15.1.424.g9478a66081

[PATCH 1/6] wildmatch test: indent with tabs, not spaces

[Ævar Arnfjörð Bjarmason]

Replace the 4-width mixed space & tab indentation in this file with
indentation with tabs as we do in most of the rest of our tests.

Signed-off-by: Ævar Arnfjörð Bjarmason 
---
 t/t3070-wildmatch.sh | 54 ++--
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index 163a14a1c2..27fa878f6e 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -5,39 +5,39 @@ test_description='wildmatch tests'
 . ./test-lib.sh
 
 match() {
-if [ $1 = 1 ]; then
-   test_expect_success "wildmatch: match '$3' '$4'" "
-   test-wildmatch wildmatch '$3' '$4'
-   "
-else
-   test_expect_success "wildmatch:  no match '$3' '$4'" "
-   ! test-wildmatch wildmatch '$3' '$4'
-   "
-fi
+   if [ $1 = 1 ]; then
+   test_expect_success "wildmatch: match '$3' '$4'" "
+   test-wildmatch wildmatch '$3' '$4'
+   "
+   else
+   test_expect_success "wildmatch:  no match '$3' '$4'" "
+   ! test-wildmatch wildmatch '$3' '$4'
+   "
+   fi
 }
 
 imatch() {
-if [ $1 = 1 ]; then
-   test_expect_success "iwildmatch:match '$2' '$3'" "
-   test-wildmatch iwildmatch '$2' '$3'
-   "
-else
-   test_expect_success "iwildmatch: no match '$2' '$3'" "
-   ! test-wildmatch iwildmatch '$2' '$3'
-   "
-fi
+   if [ $1 = 1 ]; then
+   test_expect_success "iwildmatch:match '$2' '$3'" "
+   test-wildmatch iwildmatch '$2' '$3'
+   "
+   else
+   test_expect_success "iwildmatch: no match '$2' '$3'" "
+   ! test-wildmatch iwildmatch '$2' '$3'
+   "
+   fi
 }
 
 pathmatch() {
-if [ $1 = 1 ]; then
-   test_expect_success "pathmatch: match '$2' '$3'" "
-   test-wildmatch pathmatch '$2' '$3'
-   "
-else
-   test_expect_success "pathmatch:  no match '$2' '$3'" "
-   ! test-wildmatch pathmatch '$2' '$3'
-   "
-fi
+   if [ $1 = 1 ]; then
+   test_expect_success "pathmatch: match '$2' '$3'" "
+   test-wildmatch pathmatch '$2' '$3'
+   "
+   else
+   test_expect_success "pathmatch:  no match '$2' '$3'" "
+   ! test-wildmatch pathmatch '$2' '$3'
+   "
+   fi
 }
 
 # Basic wildmat features
-- 
2.15.1.424.g9478a66081

Re: Bring together merge and rebase

[Carl Baldwin]

On Sat, Dec 23, 2017 at 07:59:35PM +0100, Ævar Arnfjörð Bjarmason wrote:
> I think this is a worthwhile thing to implement, there are certainly
> use-cases where you'd like to have your cake & eat it too as it were,
> i.e. have a nice rebased history in "git log", but also have the "raw"
> history for all the reasons the fossil people like to talk about, or for
> some compliance reasons.

Thank you kindly for your reply. I do think we can have the cake and eat
it too in this case. At a high level, what you describe above is what
I'm after. I'm sorry if I left something out or was unclear. I hoped to
keep my original post brief. Maybe it was too brief to be useful.
However, I'd like to follow up and be understood.

> But I don't see why you think this needs a new "replaces" parent pointer
> orthagonal to parent pointers, i.e. something that would need to be a
> new field in the commit object (I may have misread the proposal, it's
> not heavy on technical details).

Just to clarify, I am proposing a new "replaces" pointer in the commit
object. Imagine starting with rebase exactly as it works today. This new
field would be inserted into any new commit created by a rebase command
to reference the original commit on which it was based. Though, I'm not
sure if it would be better to change the behavior of the existing rebase
command, provide a switch or config option to turn it on, or provide a
new command entirely (e.g. git replay or git replace) to avoid
compatibility issues with the existing rebase.

I imagine that a "git commit --amend" would also insert a "replaces"
reference to the original commit but I failed to mention that in my
original post. The amend use case is similar to adding a fixup commit
and then doing a squash in interactive mode.

> Consider a merge use case like this:
> 
>   A---B---C topic
>  / \
> D---E---F---G---H master

This is a bit different than the use cases that I've had in mind. You
show that the topic has already merged to master. I have imagined this
proposal being useful before the topic becomes a part of the master
branch. I'm thinking in the context of something like a github pull
request under active development and review or a gerrit review. So, at
this point, we still look like this:

  A---B---C topic
 /
D---E---F---G

> Here we worked on a topic with commits A,B & C, maybe we regret not
> squashing B into A, but it gives us the "raw" history. Instead we might
> rebase it like this:
> 
>   A+B---C topic
>  /
> G---H master

Since H already merged the topic. I'm not sure what the A+B and C
commits are doing.

At the point where I have C and G above, let's say I regret not having
squashed A and B as you suggested. My proposal would end up as I draw
below where the primes are the new versions of the commits (A' is A+B).
Bare with me, I'm not sure the best way to draw this in ascii. It has
that orthogoal dimension that makes the ascii drawings a little more
complex: (I left out the parent of A' which is still E)

   A--B---C
\ |\<- "replaces" rather than "parent"
 -A'C' topic
 /
D---E---F---G master

We can continue by actually changing the base. All of these commits are
kept, I just drop them from the drawings to avoid getting too complex.

A'--C'
 \   \  <- "replaces" rather than "parent"
  A"--C" topic
 /
D---E---F---G master

Normal git log operations would ignore them by default. When finally
merging to master, it ends up very simple (by default) but the history
is still there to support archealogic operations.

D---E---F---G---A"--C" master

> Now we can push "topic" to master, but as you've noted this loses the
> raw history, but now consider doing this instead:
> 
>   A---B---C   A2+B2---C2 topic
>  / \ /
> D---E---F---G---G master

There are two Gs in this drawing. Should the second be H? Sorry, I'm
just trying to understanding the use case you're describing and I don't
understand it yet which makes it difficult to comment on the rest of
your reply.

> I.e. you could have started working on commit A/B/C, now you "git
> replace" them (which would be some fancy rebase alias), and what it'll
> do is create a merge commit that entirely resolves the conflict so that
> hte tree is equivalent to what "master" was already at. Then you rewrite
> them and re-apply them on top.
> 
> If you run "git log" it will already ignore A,B,C unless you specify
> --full-history, so git already knows to ignore these sort of side
> histories that result in no changes on the branch they got merged
> into. I don't know about bisect, but if it's not doing something similar
> already it would be easy to make it do so.

I haven't had the need to use --full-history much. Let me see if I can
play around with it to see if I can figure out how to use it in a way

[PATCH] setup.c: move statement under condition

[Vadim Petrov]

I suppose that if the condition is fulfilled then the previously
obtained value will not be necessary.

Signed-off-by: Vadim Petrov 
---
 setup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/setup.c b/setup.c
index 8cc34186c..1ce0189fa 100644
--- a/setup.c
+++ b/setup.c
@@ -35,7 +35,6 @@ static int abspath_part_inside_repo(char *path)
return -1;
wtlen = strlen(work_tree);
len = strlen(path);
-   off = offset_1st_component(path);
 
/* check if work tree is already the prefix */
if (wtlen <= len && !strncmp(path, work_tree, wtlen)) {
@@ -49,6 +48,8 @@ static int abspath_part_inside_repo(char *path)
}
/* work tree might match beginning of a symlink to work tree */
off = wtlen;
+   } else {
+   off = offset_1st_component(path);
}
path0 = path;
path += off;
-- 
2.15.1.433.g936d1b989

Re: Bring together merge and rebase

[Ævar Arnfjörð Bjarmason]

On Sat, Dec 23 2017, Carl Baldwin jotted:

> The big contention among git users is whether to rebase or to merge
> changes [2][3] while iterating. I used to firmly believe that merging
> was the way to go and rebase was harmful. More recently, I have worked
> in some environments where I saw rebase used very effectively while
> iterating on changes and I relaxed my stance a lot. Now, I'm on the
> fence. I appreciate the strengths and weaknesses of both approaches. I
> waffle between the two depending on the situation, the tools being
> used, and I guess, to some extent, my mood.
>
> I think what git needs is something brand new that brings the two
> together and has all of the advantages of both approaches. Let me
> explain what I've got in mind...
>
> I've been calling this proposal `git replay` or `git replace` but I'd
> like to hear other suggestions for what to name it. It works like
> rebase except with one very important difference. Instead of orphaning
> the original commit, it keeps a pointer to it in the commit just like
> a `parent` entry but calls it `replaces` instead to distinguish it
> from regular history. In the resulting commit history, following
> `parent` pointers shows exactly the same history as if the commit had
> been rebased. Meanwhile, the history of iterating on the change itself
> is available by following `replaces` pointers. The new commit replaces
> the old one but keeps it around to record how the change evolved.
>
> The git history now has two dimensions. The first shows a cleaned up
> history where fix ups and code review feedback have been rolled into
> the original changes and changes can possibly be ordered in a nice
> linear progression that is much easier to understand. The second
> drills into the history of a change. There is no loss and you don't
> change history in a way that will cause problems for others who have
> the older commits.
>
> Replay handles collaboration between multiple authors on a single
> change. This is difficult and prone to accidental loss when using
> rebase and it results in a complex history when done with merge. With
> replay, collaborators could merge while collaborating on a single
> change and a record of each one's contributions can be preserved.
> Attempting this level of collaboration caused me many headaches when I
> worked with the gerrit workflow (which in many ways, I like a lot).
>
> I blogged about this proposal earlier this year when I first thought
> of it [1]. I got busy and didn't think about it for a while. Now with
> a little time off of work, I've come back to revisit it. The blog
> entry has a few examples showing how it works and how the history will
> look in a few examples. Take a look.
>
> Various git commands will have to learn how to handle this kind of
> history. For example, things like fetch, push, gc, and others that
> move history around and clean out orphaned history should treat
> anything reachable through `replaces` pointers as precious. Log and
> related history commands may need new switches to traverse the history
> differently in different situations. Bisect is a interesting one. I
> tend to think that bisect should prefer the regular commit history but
> have the ability to drill into the change history if necessary.
>
> In my opinion, this proposal would bring together rebase and merge in
> a powerful way and could end the contention. Thanks for your
> consideration.
>
> Carl Baldwin
>
> [1] http://blog.episodicgenius.com/post/merge-or-rebase--neither/
> [2] https://git-scm.com/book/en/v2/Git-Branching-Rebasing
> [3] http://changelog.complete.org/archives/586-rebase-considered-harmful

I think this is a worthwhile thing to implement, there are certainly
use-cases where you'd like to have your cake & eat it too as it were,
i.e. have a nice rebased history in "git log", but also have the "raw"
history for all the reasons the fossil people like to talk about, or for
some compliance reasons.

But I don't see why you think this needs a new "replaces" parent pointer
orthagonal to parent pointers, i.e. something that would need to be a
new field in the commit object (I may have misread the proposal, it's
not heavy on technical details).

Consider a merge use case like this:

  A---B---C topic
 / \
D---E---F---G---H master

Here we worked on a topic with commits A,B & C, maybe we regret not
squashing B into A, but it gives us the "raw" history. Instead we might
rebase it like this:

  A+B---C topic
 /
G---H master

Now we can push "topic" to master, but as you've noted this loses the
raw history, but now consider doing this instead:

  A---B---C   A2+B2---C2 topic
 / \ /
D---E---F---G---G master

I.e. you could have started working on commit A/B/C, now you "git
replace" them (which would be some fancy rebase alias), and what it'll
do is create a merge commit that entirely resolves the conflict so that
hte tree is equivalent to what 

RE: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Randall S. Becker]

On December 23, 2017 12:44 PM,  Ævar Arnfjörð Bjarmason wrote:
> 
> In late 2010 I bumped our perl version dependency from 5.6.* to 5.8.0[1]. Git
> had been failing for a while on <5.8, and it was suspected that nobody cared
> enough to keep using it, which turned out to be true.
> 
> Follow that up with bumping the dependency to 5.10.0. The 5.8.0 release
> was released in 2002, and the 5.10.0 release just turned 10 years old[2].

The git HPE NonStop NSE/NSX ports that I maintain has Perl 5.22 generally 
available, so no objections here. Ours is just a CPAN dependency concern as 
previously discussed. 

Cheers,
Randall

-- Brief whoami: NonStop developer since approximately 
UNIX(421664400)/NonStop(2112884442)
-- In my real life, I talk too much.

Re: [RFC PATCH v2] http: support CURLPROXY_HTTPS

[Ævar Arnfjörð Bjarmason]

On Sat, Dec 23 2017, Wei Shuyu jotted:

> Git has been taught to support an https:// used for http.proxy when
> using recent versions of libcurl.
>
> To use https proxy with self-signed certs, we need a way to
> unset CURLOPT_PROXY_SSL_VERIFYPEER and CURLOPT_PROXY_SSL_VERIFYHOST
> just like direct SSL connection. This is required if we want
> use t/lib-httpd to test proxy.
>
> In this patch I reuse http.sslverify to do this, do we need an
> independent option like http.sslproxyverify?
>
> To fully support https proxy, we also need ways to set more options
> such as CURLOPT_PROXY_SSLCERT. However, I'm not sure if we need to
> support them.

It would be good to add a link to
https://daniel.haxx.se/blog/2016/11/26/https-proxy-with-curl/ to the
commit message, since it explains in great detail what this is for and
how it compares to what we were doing before.

> Signed-off-by: Wei Shuyu 
> ---
>  http.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/http.c b/http.c
> index 215bebef1..d8a5e48f0 100644
> --- a/http.c
> +++ b/http.c
> @@ -708,6 +708,10 @@ static CURL *get_curl_handle(void)
>   if (!curl_ssl_verify) {
>   curl_easy_setopt(result, CURLOPT_SSL_VERIFYPEER, 0);
>   curl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 0);
> +#if LIBCURL_VERSION_NUM >= 0x073400
> + curl_easy_setopt(result, CURLOPT_PROXY_SSL_VERIFYPEER, 0);
> + curl_easy_setopt(result, CURLOPT_PROXY_SSL_VERIFYHOST, 0);
> +#endif
>   } else {
>   /* Verify authenticity of the peer's certificate */
>   curl_easy_setopt(result, CURLOPT_SSL_VERIFYPEER, 1);
> @@ -865,6 +869,11 @@ static CURL *get_curl_handle(void)
>   else if (starts_with(curl_http_proxy, "socks"))
>   curl_easy_setopt(result,
>   CURLOPT_PROXYTYPE, CURLPROXY_SOCKS4);
> +#endif
> +#if LIBCURL_VERSION_NUM >= 0x073400
> + else if (starts_with(curl_http_proxy, "https"))
> + curl_easy_setopt(result,
> + CURLOPT_PROXYTYPE, CURLPROXY_HTTPS);
>  #endif
>   if (strstr(curl_http_proxy, "://"))
>   credential_from_url(_auth, curl_http_proxy);

[RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

[Ævar Arnfjörð Bjarmason]

In late 2010 I bumped our perl version dependency from 5.6.* to
5.8.0[1]. Git had been failing for a while on <5.8, and it was
suspected that nobody cared enough to keep using it, which turned out
to be true.

Follow that up with bumping the dependency to 5.10.0. The 5.8.0
release was released in 2002, and the 5.10.0 release just turned 10
years old[2].

This is similar to Jeff King's jk/drop-ancient-curl series in that
we're dropping perl releases that are rarely tested anymore, however
unlike those patches git still works on e.g. 5.8.8 (I couldn't build
anything older).

The reason to do this is to be able to use features released with perl
in the last decade, 5.10 was a major feature release including things
like new regex features, state variables, the defined-or operator
etc.[3]

I expect this to be more controversial as since the 5.8 release stayed
along for longer in various distributions, e.g. it's the version
shipped with RHEL 5, replaced by 5.10 in RHEL 6 released in late 2010,
similarly the first Debian release to include 5.10 was 5.0 (Lenny)
released in early 2009. The release history for other distributions
can be seen on CPAN's "Perl Binaries" page[3].

1. d48b284183 ("perl: bump the required Perl version to 5.8 from
   5.6.[21]", 2010-09-24)

2. "perldoc perlhist" 
(https://metacpan.org/pod/distribution/perl/pod/perlhist.pod)

3. "perldoc perl5100delta" 
(https://metacpan.org/pod/distribution/perl/pod/perl5100delta.pod)

3. http://www.cpan.org/ports/binaries.html

Signed-off-by: Ævar Arnfjörð Bjarmason 
---

RFC because this'll need to be adjusted for my cooking Makefile.PL
changes, and because the patch is obviously "correct", so the question
is "do we want to do this". Discuss.

 contrib/diff-highlight/DiffHighlight.pm | 2 +-
 contrib/examples/git-difftool.perl  | 2 +-
 contrib/mw-to-git/Git/Mediawiki.pm  | 2 +-
 git-add--interactive.perl   | 2 +-
 git-archimport.perl | 2 +-
 git-cvsexportcommit.perl| 2 +-
 git-cvsimport.perl  | 2 +-
 git-cvsserver.perl  | 2 +-
 git-send-email.perl | 2 +-
 git-svn.perl| 2 +-
 gitweb/gitweb.perl  | 2 +-
 perl/Git.pm | 2 +-
 perl/Git/I18N.pm| 2 +-
 perl/Git/Packet.pm  | 2 +-
 t/t0021/rot13-filter.pl | 2 +-
 t/t0202/test.pl | 2 +-
 t/t9000/test.pl | 2 +-
 t/t9700/test.pl | 2 +-
 t/test-terminal.perl| 2 +-
 19 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/contrib/diff-highlight/DiffHighlight.pm 
b/contrib/diff-highlight/DiffHighlight.pm
index 663992e530..21fe5d424f 100644
--- a/contrib/diff-highlight/DiffHighlight.pm
+++ b/contrib/diff-highlight/DiffHighlight.pm
@@ -1,6 +1,6 @@
 package DiffHighlight;
 
-use 5.008;
+use v5.10.0;
 use warnings FATAL => 'all';
 use strict;
 
diff --git a/contrib/examples/git-difftool.perl 
b/contrib/examples/git-difftool.perl
index df59bdfe97..13c44846a8 100755
--- a/contrib/examples/git-difftool.perl
+++ b/contrib/examples/git-difftool.perl
@@ -10,7 +10,7 @@
 #
 # Any arguments that are unknown to this script are forwarded to 'git diff'.
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use Error qw(:try);
diff --git a/contrib/mw-to-git/Git/Mediawiki.pm 
b/contrib/mw-to-git/Git/Mediawiki.pm
index 917d9e2d32..5b620b8425 100644
--- a/contrib/mw-to-git/Git/Mediawiki.pm
+++ b/contrib/mw-to-git/Git/Mediawiki.pm
@@ -1,6 +1,6 @@
 package Git::Mediawiki;
 
-use 5.008;
+use v5.10.0;
 use strict;
 use POSIX;
 use Git;
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 28b325d754..b59c9eaf30 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1,6 +1,6 @@
 #!/usr/bin/perl
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use Git qw(unquote_path);
diff --git a/git-archimport.perl b/git-archimport.perl
index b7c173c345..7d13f7ef16 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -54,7 +54,7 @@ and can contain multiple, unrelated branches.
 
 =cut
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use Getopt::Std;
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d13f02da95..c50d981208 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -1,6 +1,6 @@
 #!/usr/bin/perl
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use Getopt::Std;
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 36929921ea..7d4dd07d35 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -13,7 +13,7 @@
 # The head revision is on branch "origin" by default.
 # You can change that with the '-o' option.
 
-use 5.008;
+use v5.10.0;
 use strict;
 use warnings;
 use Getopt::Long;
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index ae1044273d..ddb423dbc2 100755

Compliment of the day

[Kabore Zongo]

--
Compliment of the day , I am a professional banker with International 
and Qualified Experience. Please i seek your Urgent Attention and 
Cooperation to transfer the sum of $8.5M into your account. Risk free 
and Beneficial. Waiting response so that we can proceed to the next 
level(zongokab2...@yahoo.com)


--

[RFC PATCH v2] http: support CURLPROXY_HTTPS

[Wei Shuyu]

Git has been taught to support an https:// used for http.proxy when
using recent versions of libcurl.

To use https proxy with self-signed certs, we need a way to
unset CURLOPT_PROXY_SSL_VERIFYPEER and CURLOPT_PROXY_SSL_VERIFYHOST
just like direct SSL connection. This is required if we want
use t/lib-httpd to test proxy.

In this patch I reuse http.sslverify to do this, do we need an
independent option like http.sslproxyverify?

To fully support https proxy, we also need ways to set more options
such as CURLOPT_PROXY_SSLCERT. However, I'm not sure if we need to
support them.

Signed-off-by: Wei Shuyu 
---
 http.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/http.c b/http.c
index 215bebef1..d8a5e48f0 100644
--- a/http.c
+++ b/http.c
@@ -708,6 +708,10 @@ static CURL *get_curl_handle(void)
if (!curl_ssl_verify) {
curl_easy_setopt(result, CURLOPT_SSL_VERIFYPEER, 0);
curl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 0);
+#if LIBCURL_VERSION_NUM >= 0x073400
+   curl_easy_setopt(result, CURLOPT_PROXY_SSL_VERIFYPEER, 0);
+   curl_easy_setopt(result, CURLOPT_PROXY_SSL_VERIFYHOST, 0);
+#endif
} else {
/* Verify authenticity of the peer's certificate */
curl_easy_setopt(result, CURLOPT_SSL_VERIFYPEER, 1);
@@ -865,6 +869,11 @@ static CURL *get_curl_handle(void)
else if (starts_with(curl_http_proxy, "socks"))
curl_easy_setopt(result,
CURLOPT_PROXYTYPE, CURLPROXY_SOCKS4);
+#endif
+#if LIBCURL_VERSION_NUM >= 0x073400
+   else if (starts_with(curl_http_proxy, "https"))
+   curl_easy_setopt(result,
+   CURLOPT_PROXYTYPE, CURLPROXY_HTTPS);
 #endif
if (strstr(curl_http_proxy, "://"))
credential_from_url(_auth, curl_http_proxy);
-- 
2.15.1

[RFC] Prepend "tags/" when describing tags with embedded name

[Daniel Knittl-Frank]

On Fri, Dec 15, 2017 at 8:25 PM, Junio C Hamano  wrote:
> I think the code makes sense, but it won't be understandable by
> those who do not know what you discussed in the original thread.
>
> A proper commit log message, with a new test or two in t6120, would
> be an appropriate way to fix that.
>
> Care to follow through, along the lines in
> Documentation/SubmittingPatches?

The updated branch including tests can be found at:
http://repo.or.cz/git/dkf.git/shortlog/refs/heads/bugfix/describe-all

One existing test in t6210 needed updating to match the new behavior,
three new tests have been added: annotated tags, lightweight tags, and
branches.

Daniel

-- 
typed with http://neo-layout.org

Re: Re: Unify annotated and non-annotated tags

[anatoly techtonik]

On Sun, Dec 3, 2017 at 1:25 AM, Philip Oakley  wrote:
> From: "anatoly techtonik" 
>
> comment at end - Philip
>
>
> On Fri, Nov 24, 2017 at 1:24 PM, Ævar Arnfjörð Bjarmason
>  wrote:
>>
>> On Fri, Nov 24, 2017 at 10:52 AM, anatoly techtonik 
>> wrote:
>>>
>>> On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker
>>>  wrote:

 On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote
>
> Subject: Re: Unify annotated and non-annotated tags
> On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano 
> wrote:
>>
>> Igor Djordjevic  writes:
>>
>>> If you would like to mimic output of "git show-ref", repeating
>>> commits for each tag pointing to it and showing full tag name as
>>> well, you could do something like this, for example:
>>>
>>>   for tag in $(git for-each-ref --format="%(refname)" refs/tags)
>>>   do
>>>   printf '%s %s\n' "$(git rev-parse $tag^0)" "$tag"
>>>   done
>>>
>>>
>>> Hope that helps a bit.
>>
>>
>> If you use for-each-ref's --format option, you could do something
>> like (pardon a long line):
>>
>> git for-each-ref
>> --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end)
>> %(refname)' refs/tags
>>
>> without any loop, I would think.
>
> Thanks. That helps.
> So my proposal is to get rid of non-annotated tags, so to get all
> tags with commits that they point to, one would use:
> git for-each-ref --format='%(*objectname) %(refname)' refs/tags>
> For so-called non-annotated tags just leave the message empty.
> I don't see why anyone would need non-annotated tags though.


 I have seen non-annotated tags used in automations (not necessarily well
 written ones) that create tags as a record of automation activity. I am not
 sure we should be writing off the concept of unannotated tags entirely. 
 This
 may cause breakage based on existing expectations of how tags work at
 present. My take is that tags should include whodunnit, even if it's just
 the version of the automation being used, but I don't always get to have my
 wishes fulfilled. In essence, whatever behaviour a non-annotated tag has 
 now
 may need to be emulated in future even if reconciliation happens. An option
 to preserve empty tag compatibility with pre-2.16 behaviour, perhaps? 
 Sadly,
 I cannot supply examples of this usage based on a human memory page-fault
 and NDAs.
>>>
>>>
>>> Are there any windows for backward compatibility breaks, or git is
>>> doomed to preserve it forever?
>>> Automation without support won't survive for long, and people who rely
>>> on that, like Chromium team, usually hard set the version used.
>>
>>
>> Git is not doomed to preserve anything forever. We've gradually broken
>> backwards compatibility for a few core things like these.
>>
>> However, just as a bystander reading this thread I haven't seen any
>> compelling reason for why these should be removed. You initially had
>> questions about how to extract info about them, which you got answers
>> to.
>>
>> So what reasons remain for why they need to be removed?
>
>
> To reduce complexity and prior knowledge when dealing with Git tags.
>
> For example, http://readthedocs.io/ site contains a lot of broken
> "Edit on GitHub" links, for example -
> http://git-memo.readthedocs.io/en/stable/
>
> And it appeared that the reason for that is discrepancy between git
> annotated and non-annotated tags. The pull request that fixes the issue
> after it was researched and understood is simple
> https://github.com/rtfd/readthedocs.org/pull/3302
>
> However, while looking through linked issues and PRs, one can try to
> imagine how many days it took for people to come up with the solution,
> which came from this thread.
> --
> anatoly t.
>

>
> So if I understand correctly, the hope is that `git show-ref --tags` could
> get an alternate option `--all-tags` [proper option name required...] such
> that the user would not have to develop the rather over the complicated
> expression that used a newish capability of a different command.
>
> Would that be right?

That's correct.

> Or at least update the man page docs to clarify the annotated vs
> non-annotated tags issue (many SO questions!).

Are there stats how many users read man pages and what is their
reading session length? I mean docs may not help much,

> And indicate if the --dereference and/or --hash options would do the trick!
> - maybe the "^{}" appended would be part of the problem (and need that new
> option "--objectreference" ).

--dereference would work if it didn't require extra processing.
It is hard to think about other option name that would give
desired result.

-- 
anatoly t.

Re: Unify annotated and non-annotated tags

[anatoly techtonik]

On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano  wrote:
> Igor Djordjevic  writes:
>
>> If you would like to mimic output of "git show-ref", repeating
>> commits for each tag pointing to it and showing full tag name as
>> well, you could do something like this, for example:
>>
>>   for tag in $(git for-each-ref --format="%(refname)" refs/tags)
>>   do
>>   printf '%s %s\n' "$(git rev-parse $tag^0)" "$tag"
>>   done
>>
>>
>> Hope that helps a bit.
>
> If you use for-each-ref's --format option, you could do something
> like (pardon a long line):
>
> git for-each-ref 
> --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) 
> %(refname)' refs/tags
>
> without any loop, I would think.

This doesn't work with git 1.9.1
https://github.com/rtfd/readthedocs.org/pull/3441#issuecomment-353567756
When it was added? I searched through GitHub and docs, but can't find any
historical records.

-- 
anatoly t.

GREETINGS,

[mis.sbort...@ono.com]

GREETINGS,

I AM BORTE ,I WAS  DIAGNOSE OF OVARIAN CANCER,WHICH DOCTORS HAVE 
CONFIRMED THAT I HAVE ONLY FEW WEEKS TO LIVE, SO I HAVE DECIDED TO 
DONATE EVERYTHING I HAVE TO THE ORPHANAGE AND THE POOR WIDOWS THROUGH 
YOU .PLEASE KINDLY REPLY  ME ONLY ON MY  EMAIL ADDRES HERE
(missbrtoeogo...@gmail.com)  AS SOON AS POSIBLE TO ENABLE ME GIVE YOU 
MORE INFORMATION ABOUT MYSELF AND HOW TO GO ABOUT IT . 


THANKS 

MISS BORTE

Re: [PATCH v2 2/2] commit: add support for --fixup -m""

[Ævar Arnfjörð Bjarmason]

On Fri, Dec 22 2017, Junio C. Hamano jotted:

> Ævar Arnfjörð Bjarmason  writes:
>
>> I don't agree that git as a tool should be so opinionated. You can edit
>> these --fixup messages right now with --edit, and I do. That it doesn't
>> work with -m"" as it should is a longstanding UI wart.
>
> I think you missed the point.

I did, yes. Sorry, I was being a bit touchy and argumentative there.

> I was expressing my opinion, not an opinion of Git as a tool, that I
> think one of these two "use case" scenario was a bad way not to be
> encouraged.
>
> That is totally different from allowing --fixup and -m working
> together.  That is a good thing that helps the other "good" use case.

Re: Usability outrage as far as I am concerned

[Cristian Achim]

Basically somehow at the point when I investigated stuff on the usb
stick I found the repository at the top level of the usb folder
hierarchy. Therefore git got confused by what I was doing at
usb_subfolder which is lower in the folder hierarchy and that is way
it was having amasement inducing reports when trying to do a pull
saying that pull is not possible because of unmerged and newly added
files.

Thank you to all that replied.

Re: [PATCH v1] convert: add support for 'encoding' attribute

[Torsten Bögershausen]

On Mon, Dec 18, 2017 at 08:12:49AM -0500, Jeff King wrote:
> On Mon, Dec 18, 2017 at 11:13:34AM +0100, Torsten Bögershausen wrote:
> 
> > Just to confirm my missing knowledge here:
> > Does this mean, that git-gui and gitk can decode/reencode
> > the content of a file/blob, when the .gitattributes say so ?
> 
> That's my impression, yes.
> 
> > If yes, would it make sense to enhance the "git diff" instead ?
> > "git diff --encoding" will pick up the commited encoding from
> > .attributes, convert it into UTF-8, and run the diff ?
> 
> You can do something like this already:
> 
>   git config diff.utf16.textconv 'iconv -f utf16 -t utf8'
>   echo file diff=utf16 >.gitattributes
> 
> I have no objection to teaching it that "encoding" means roughly the
> same thing, which would have two advantages:
> 
>  - we could do it in-process, which would be much faster
> 
>  - we could skip the extra config step, which is a blocker for
>server-side diffs on sites like GitHub
> 
> I don't think you'd really need "--encoding". This could just be
> triggered by the normal "--textconv" rules (i.e., just treat this "as
> if" the textconv above was configured when we see an encoding
> attribute).

I can probably come up with a patch the next weeks or so.

> 
> > We actually could enhance the "git diff" output with a single
> > line saying
> > "Git index-encoding=cp1251"
> > or so, which can be picked up by "git apply".
> 
> That extends it beyond what textconv can do (we assume that textconv
> patches are _just_ for human consumption, and can't be applied). And it
> would mean you'd potentially want to trigger it in more places. On the
> other hand, I don't know that we're guaranteed that a round-trip
> between encodings will produce a byte-wise identical result. The nice
> thing about piggy-backing on textconv is that it's already dealt with
> that problem.
> 
> -Peff