* Re: clarification of `rev-list --no-walk ^<rev>`?
From: Michael J Gruber @ 2016-09-21 14:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Philip Oakley, Git List
In-Reply-To: <affca640-4ed8-268a-9f7d-e2c7ce6d66fc@drmicha.warpmail.net>
[So many typos, sorry]
Michael J Gruber venit, vidit, dixit 21.09.2016 16:46:
> Junio C Hamano venit, vidit, dixit 19.09.2016 18:12:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>
>>>> It can be read that
>>>>
>>>> $ git cherry-pick maint next
>>>>
>>>> would pick two single commits, while
>>>>
>>>> $ git cherry-pick maint next ^master
>>>>
>>>> could implicitly be read as
>>>>
>>>> $ git cherry-pick maint next --do-walk ^master
>>
>> You can read it as "master..next maint" that does force walking.
>>
>>>> Clearly that's not what is intended, which is
>>>>
>>>> $ git cherry-pick --do-walk maint next ^master
>>
>> I do not see the distinction betwee the above two you seem to be
>> trying to make. Care to explain?
>
> I think you answered to e-mail (in-reply-to) and to Philip's actual text
> (quotes), but just in case:
"my e-mail"
>
> [git]✓ git rev-list --no-walk ^HEAD~3 HEAD
> 47d74601f5c6bbef215a887be2ca877e34391c9f
> 574dece7b651fbae385add51d7aaea1cc414007a
> 3fbbf6e9e40b151215cce6c6e25cd4db0232d870
> [git]✓ git rev-list ^HEAD~3 --no-walk HEAD
> 47d74601f5c6bbef215a887be2ca877e34391c9f
>
> The order of revision arguments and options does play role (but where I
> put my HEAD does not, uhm), i.e. walk-options vs. negative refs.
"play a role"
"negative revs"
>
> The reason is that negative revs come with an implicit --do-walk (we
> need to walk to mark uninteresting revs), and the last
"in order to mark"
> --do-walk/--no-walk wins. That's what I meant with my comment.
>
> But there is only one walk (or none), and one setting effective for all
> revision arguments.
>
> Michael
>
^ permalink raw reply
* Re: clarification of `rev-list --no-walk ^<rev>`?
From: Michael J Gruber @ 2016-09-21 14:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Philip Oakley, Git List
In-Reply-To: <xmqq8tunhns4.fsf@gitster.mtv.corp.google.com>
Junio C Hamano venit, vidit, dixit 19.09.2016 18:12:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>>> It can be read that
>>>
>>> $ git cherry-pick maint next
>>>
>>> would pick two single commits, while
>>>
>>> $ git cherry-pick maint next ^master
>>>
>>> could implicitly be read as
>>>
>>> $ git cherry-pick maint next --do-walk ^master
>
> You can read it as "master..next maint" that does force walking.
>
>>> Clearly that's not what is intended, which is
>>>
>>> $ git cherry-pick --do-walk maint next ^master
>
> I do not see the distinction betwee the above two you seem to be
> trying to make. Care to explain?
I think you answered to e-mail (in-reply-to) and to Philip's actual text
(quotes), but just in case:
[git]✓ git rev-list --no-walk ^HEAD~3 HEAD
47d74601f5c6bbef215a887be2ca877e34391c9f
574dece7b651fbae385add51d7aaea1cc414007a
3fbbf6e9e40b151215cce6c6e25cd4db0232d870
[git]✓ git rev-list ^HEAD~3 --no-walk HEAD
47d74601f5c6bbef215a887be2ca877e34391c9f
The order of revision arguments and options does play role (but where I
put my HEAD does not, uhm), i.e. walk-options vs. negative refs.
The reason is that negative revs come with an implicit --do-walk (we
need to walk to mark uninteresting revs), and the last
--do-walk/--no-walk wins. That's what I meant with my comment.
But there is only one walk (or none), and one setting effective for all
revision arguments.
Michael
^ permalink raw reply
* Re: 2.10.0: git log --oneline prints gpg signatures in 4 lines
From: Leandro Lucarella @ 2016-09-21 13:53 UTC (permalink / raw)
To: Jeff King; +Cc: Mehul Jain, git
In-Reply-To: <20160920231533.fxcdjgphz25hnbxt@sigill.intra.peff.net>
On Tue, 20 Sep 2016 19:15:33 -0400
Jeff King <peff@peff.net> wrote:
> On Tue, Sep 20, 2016 at 05:09:54PM +0200, Leandro Lucarella wrote:
>
> > Hi, starting from 2.10.0 I noticed that when using git log
> > --oneline, if commits are signed with GPG, now the signatures are
> > printed too, and it takes 3 lines for the signature information + 1
> > line for the title of the commit, so suddenly --oneline became
> > --fourline :)
> >
> > Is this really intended?
>
> I don't think anything has changed here in 2.10. Running "git log
> --oneline --show-signature" has _always_ been horribly ugly. However,
> 2.10 did introduce the "log.showsignature" config, which makes "git
> log --oneline" pretty unusable when it is enabled. Ditto for
> one-liner uses of "--format".
>
> I think we should probably ignore the config entirely when using any
> of the one-liner formats (and I'd include --format, too, even though
> it can sometimes be multi-line; it already has %GG to include that
> information as appropriate).
Woops! Definitely it shouldn't be added when --format is used, this is
also breaking some scripts I have using git log --format to get some
information about commits, and GPG information is being output even
when there is anything about GPG requested in the chosen format.
I guess I will disable log.showsignatures for now... :(
--
Leandro Lucarella
Technical Development Lead
Sociomantic Labs GmbH <http://www.sociomantic.com>
^ permalink raw reply
* Re: v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name
From: Steffen Nurpmeso @ 2016-09-21 14:21 UTC (permalink / raw)
To: Jakub Narębski; +Cc: Bryan Turner, Git Users
In-Reply-To: <b1d35732-4b4c-e0c1-59da-44d3e3b28799@gmail.com>
Hello.
Jakub Narębski <jnareb@gmail.com> wrote:
|W dniu 20.09.2016 o 20:54, Bryan Turner pisze:
|> On Tue, Sep 20, 2016 at 9:23 AM, Steffen Nurpmeso <steffen@sdaoden.eu> \
|> wrote:
|>> Hello again,
|>>
|>> yah, sorry, i'm back again..
|>> I try to find a way to find the name of the current branch in an
|>> automated way, because i need to ensure that a commit happens on
|>> it and no other branch. Now the problem arises that the commit
|>> ref at the time of that commit maybe shared in between several
|>> different branches, but no more thereafter, of course:
|>>
|>> ?0[steffen@wales ]$ git branch|grep '^*'
|>> * stable/v14.9
|
|Not good, 'git branch' is a porcelain (user facing) command, so it
|output may change; e.g. '*' could be replaced with '•'. For example
|output for detached HEAD had changed!
Ok. I went the road Bryan suggested, i had only forgotten this.
Yes, it caused mysterious bugs once rev-parse reversed the output,
but i didn't understand the order at first, anyway. With todays'
ever-rotating distributions i don't even try to keep up; currently
unthinkable to use the same release of an OS for five years, like
FreeBSD 5.3. Well.
...
|>> Is there another way except looking into .git/HEAD or using sed(1)
|>> on the output of `branch' to find the right name?
|>
|> Have you tried "git symbolic-ref HEAD"?
...
|This does not work for detached HEAD, but perhaps you don't need
|to worry about this.
No, not for me: it will only switch in between two different
stable/ which exist. But thanks, just give it to me!
| $ git rev-parse --symbolic-full-name HEAD
| refs/heads/master
This is a really good suggestion, which i will remember. I didn't
know this at all yet:
$ git rev-parse --symbolic-full-name --abbrev-ref=strict HEAD
Seems to do exactly what i want, non-fragile, then.
...
|But
...
| You are in 'detached HEAD' state. [...]
|
| $ git rev-parse --symbolic-full-name HEAD
| HEAD
|
| $ git symbolic-ref HEAD
| fatal: ref HEAD is not a symbolic ref
|
| $ git branch
| * (HEAD detached at 3e2ebf9)
| master
And name-rev gives "HEAD master~2" in a test of mine, or only
"master~2", or "undefined" if i use --tags, for completeness sake.
Thanks, Jakub. I'm using the plumbing.
--steffen
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786
From: Ævar Arnfjörð Bjarmason @ 2016-09-21 14:17 UTC (permalink / raw)
To: Jakub Narębski; +Cc: Git, Junio C Hamano, Kay Sievers
In-Reply-To: <d047a76d-8f13-5c90-3946-6821957d9278@gmail.com>
On Wed, Sep 21, 2016 at 3:33 PM, Jakub Narębski <jnareb@gmail.com> wrote:
> W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał:
>
>> Subject: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786
>
> It is more "ancient typo from v1.7.7-rc1-1-g0866786", but perhaps more
> important is "ancient typo in a comment"
Yeah, will rephrase.
>>
>> The Content-Type is application/xhtml+xml, not application/xhtm+xml.
>
> Right. Thanks for the patch.
>
> Signoff?
Blast! I forgot that for these 3x patches. I'll re-submit pending
further comments on the rest of the code changes in the series.
>> ---
>> gitweb/gitweb.perl | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index 33d701d..9473daf 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -1616,7 +1616,7 @@ sub esc_path {
>> return $str;
>> }
>>
>> -# Sanitize for use in XHTML + application/xml+xhtm (valid XML 1.0)
>> +# Sanitize for use in XHTML + application/xml+xhtml (valid XML 1.0)
>
> Nb. I wonder how common is use of XHTML nowadays, with HTML5 as standard...
It's sent to modern browsers, I noticed it because when doing the rest
of the patches in the series the slightest mistake in the HTML syntax
would cause the page not to render in Chrome, because
application/xml+xhtm activates its anal parsing mode.
>> sub sanitize {
>> my $str = shift;
>>
>>
>
^ permalink raw reply
* Re: v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name
From: Jakub Narębski @ 2016-09-21 13:43 UTC (permalink / raw)
To: Bryan Turner, Steffen Nurpmeso; +Cc: Git Users
In-Reply-To: <CAGyf7-FR11Ludt3vNZX7Ek4n_JLSON5+Y9By83GvNgpg94TWcg@mail.gmail.com>
W dniu 20.09.2016 o 20:54, Bryan Turner pisze:
> On Tue, Sep 20, 2016 at 9:23 AM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
>> Hello again,
>>
>> yah, sorry, i'm back again..
>> I try to find a way to find the name of the current branch in an
>> automated way, because i need to ensure that a commit happens on
>> it and no other branch. Now the problem arises that the commit
>> ref at the time of that commit maybe shared in between several
>> different branches, but no more thereafter, of course:
>>
>> ?0[steffen@wales ]$ git branch|grep '^*'
>> * stable/v14.9
Not good, 'git branch' is a porcelain (user facing) command, so it
output may change; e.g. '*' could be replaced with '•'. For example
output for detached HEAD had changed!
>> ?0[steffen@wales ]$ git name-rev --name-only HEAD
>> stable/v14.8
>>
>> Is there another way except looking into .git/HEAD or using sed(1)
>> on the output of `branch' to find the right name?
>
> Have you tried "git symbolic-ref HEAD"?
>
> $ git symbolic-ref HEAD
> refs/heads/master
>
> If you don't want the fully-qualified ref, you can add --short:
>
> $ git symbolic-ref --short HEAD
> master
This does not work for detached HEAD, but perhaps you don't need
to worry about this.
$ git rev-parse --symbolic-full-name HEAD
refs/heads/master
But
$ git checkout HEAD^0
Note: checking out 'HEAD^0'.
You are in 'detached HEAD' state. [...]
$ git rev-parse --symbolic-full-name HEAD
HEAD
$ git symbolic-ref HEAD
fatal: ref HEAD is not a symbolic ref
$ git branch
* (HEAD detached at 3e2ebf9)
master
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786
From: Jakub Narębski @ 2016-09-21 13:33 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason, git; +Cc: Junio C Hamano, Kay Sievers
In-Reply-To: <20160921114428.28664-1-avarab@gmail.com>
W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał:
> Subject: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786
It is more "ancient typo from v1.7.7-rc1-1-g0866786", but perhaps more
important is "ancient typo in a comment"
>
> The Content-Type is application/xhtml+xml, not application/xhtm+xml.
Right. Thanks for the patch.
Signoff?
> ---
> gitweb/gitweb.perl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 33d701d..9473daf 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1616,7 +1616,7 @@ sub esc_path {
> return $str;
> }
>
> -# Sanitize for use in XHTML + application/xml+xhtm (valid XML 1.0)
> +# Sanitize for use in XHTML + application/xml+xhtml (valid XML 1.0)
Nb. I wonder how common is use of XHTML nowadays, with HTML5 as standard...
> sub sanitize {
> my $str = shift;
>
>
^ permalink raw reply
* Re: [PATCH v1] travis-ci: ask homebrew for the its path instead of hardcoding it
From: Lars Schneider @ 2016-09-21 13:28 UTC (permalink / raw)
To: stefan.naewe; +Cc: git, gitster
In-Reply-To: <83e3049c-34ea-4440-7b4d-061cb98ba2dd@atlas-elektronik.com>
> On 21 Sep 2016, at 11:31, stefan.naewe@atlas-elektronik.com wrote:
>
> In the Subject: s/the //
>
> Am 21.09.2016 um 10:45 schrieb larsxschneider@gmail.com:
>> From: Lars Schneider <larsxschneider@gmail.com>
>>
>> The TravisCI macOS build is broken because homebrew (a macOS depedency
>
> s/depedency/dependency/
Thanks for spotting both errors!
@Junio: Should I make a v2?
Thanks,
Lars
^ permalink raw reply
* v2.10.0: ls-tree exit status is always 0, this differs from ls(1)
From: Steffen Nurpmeso @ 2016-09-21 13:26 UTC (permalink / raw)
To: git
I think this behaviour contradicts the manual which strongly links
ls-tree to ls(1):
?0[steffen@wales ]$ ls NEWSS
ls: cannot access 'NEWSS': No such file or directory
?2[steffen@wales ]$ git ls-tree --name-only master NEWSS
?0[steffen@wales ]$ ls NEWS
NEWS
?0[steffen@wales ]$ git ls-tree --name-only master NEWS
NEWS
?0[steffen@wales ]$
Ciao.
--steffen
^ permalink raw reply
* Re: Git garden shears, was Re: [PATCH 13/22] sequencer: remember the onelines when parsing the todo file
From: Jakub Narębski @ 2016-09-21 13:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Stefan Haller
In-Reply-To: <alpine.DEB.2.20.1609111027330.129229@virtualbox>
Hello Dscho,
W dniu 11.09.2016 o 10:33, Johannes Schindelin napisał:
> On Fri, 9 Sep 2016, Jakub Narębski wrote:
[...]
>> When preserving merges, there are (as far as I understand it), two
>> problems:
>> - what it means to preserve changes (which change to pick,
>> that is what is the mainline changes rebase is re-applying)
>> - what are parents of the merge commit (at least one parent
>> would be usually rewritten)
>>
>> Maybe the internal (and perhaps also user-visible) representation
>> of merge in instruction sheet could use the notation of filter-branch,
>> that is 'map(<sha-1>)'... it could also imply the mainline.
>>
>> That is the instruction in the internal instruction sheet could
>> look like this:
>>
>> merge -m 1 map(2fd4e1c6...) da39a3ee... \t Merge 'foo' into master
>>
>>
>> Note that it has nothing to do with this series!
>
> Right. But I did solve that already. In the Git garden shears [*1*]
> (essentially my New And Improved attempt at recreating branch structures
> while rebasing), I generate and process scripts like this:
>
> mark onto
>
> # Branch: super-cool-feature
> rewind onto
> pick 00001 feature
> pick 00002 documentation
> mark super-cool-feature
>
> # Branch: typo-fix
> rewind onto
> pick 0000a fix a tyop
There probably should be there
mark typo-fix
>
> rewind onto
> merge -C cafebabe super-cool-feature
> merge -C babecafe typo-fix
>
> cleanup super-cool-feature typo-fix
>
> Of course this will change a little, still, once I get around to implement
> this on top of the rebase--helper.
Do I understand it correctly that it is user-visible instruction sheet, and
not the internal instruction sheet for sequencer? This looks very nice
and is well readable.
I guess that it needs to be pre-populated by Git based on topology of the
branch being rebased.
As I see, there are three basic topologies of non-linear branch to be
rebased; all else is combination of thereof, or derivative:
1. Merge commit without branching point, that is we need to go
from the following situation
*---*---*---#---o---o---o <-- old base
\\
\\=a===b===M===c <-- branch being rebased
/
...---x---x---x-/ <-- side branch
to the following:
*---*---*---#---o---o---o
\
\-a'--b'--M'--c'
/
...---x---x---x-------------/
I think this case is the only one supported by `--preserve-merges`,
but I may be mistaken - I never had the need to use this feature IRL.
2. Branching point without accompanying merge commit, or in other words
rebasing many branches tied together; a shrub if you will. That is,
we want to go from the following situation:
*---*---*---#---o---o---o <-- old base
\
\--a---b---c <-- branch being rebased
\
\-1 <-- dependent branch
to the following one:
*---*---*---#---o---o---o
\
\--a'--b'--c'
\
\-1'
I don't think Git supports something like that out of the box, but it
is not hard to create something like that "by hand". It is not much
of a problem... unless you forget to rebase the second dependent branch.
3. Branching point with merge point, that is subbranch created and
merged - an "eye" (it is not a loop in DAG):
*---*---*---#---o---o---o <-- old base
\
\--a---b---c---M---d <-- branch being rebased
\ /
\-1---2-/ [ <-- possibly a branch ]
All edges are directed edges, with arrows pointing from right to
left; that is *---* is really *<---*
The expected result is:
*---*---*---#---o---o---o
\
\--a'--b'--c'--M'--d'
\ /
\-1'--2'/
I guess that is the main purpose of your git-garden-shears script,
isn't it?
>
> For example, I am not so hot about the "merge -C ..." syntax. I'll
> probably split that into a "remerge <SHA-1> <mark>" and a new "merge
> <mark>" command (the latter asking interactively for the merge commit
> message).
There is also an additional complication in that merge commit message
may be *partially* automatically generated. First there is the subject
generated by 'git merge' ("Merge branch 'foo'") or 'git pull <URL>'.
It might have been translated, or extended. Second there is a place
for branch cover letter. Third, subject to merge.log / merge.summary
there is a shortlog.
From those shortlog should be surely updated to correspond to the
post-rebase state. The first line could be used to pre-populate
mark lines, but during merge it should be, I think, updated to the
new name of internal branch if it was changed.
As to 'merge -C <sha1> <marker>' vs 'remerge <sha1> <marker>',
I don't have specified opinion. It would be nice to have one
character shortcuts for insn sheet instructions, to which
'm -C <sha1> <marker>' is more amendable...
>
> And also: the cleanup stage should not be necessary, as the "mark"
> commands can accumulate the known marks into a file in the state
> directory.
>
> But you get the idea.
Right. No need to make user do something that computer can easily
and without errors do.
>
> No :1 or some such. That's machine readable. But it's utter nonsense for
> user-facing UIs.
Of course. It's all right for machine-facing instructions, like the
'todo' file for the sequencer, or for git-fast-import stream...
>
> Ciao,
> Dscho
>
> Footnote *1*:
> https://github.com/git-for-windows/build-extra/blob/master/shears.sh
P.S. I wonder if git-imerge[2] requires for integrated branches to have
both linear history for it to work.
[2]: https://github.com/mhagger/git-imerge
http://softwareswirl.blogspot.com/2013/05/git-imerge-practical-introduction.html
https://www.youtube.com/watch?v=FMZ2_-Ny_zc
Best,
--
Jakub Narębski
^ permalink raw reply
* Re: 2.10.0: git log --oneline prints gpg signatures in 4 lines
From: Leandro Lucarella @ 2016-09-21 10:24 UTC (permalink / raw)
To: Jeff King; +Cc: Mehul Jain, git
In-Reply-To: <20160920231533.fxcdjgphz25hnbxt@sigill.intra.peff.net>
On Tue, 20 Sep 2016 19:15:33 -0400
Jeff King <peff@peff.net> wrote:
> On Tue, Sep 20, 2016 at 05:09:54PM +0200, Leandro Lucarella wrote:
>
> > Hi, starting from 2.10.0 I noticed that when using git log
> > --oneline, if commits are signed with GPG, now the signatures are
> > printed too, and it takes 3 lines for the signature information + 1
> > line for the title of the commit, so suddenly --oneline became
> > --fourline :)
> >
> > Is this really intended?
>
> I don't think anything has changed here in 2.10. Running "git log
> --oneline --show-signature" has _always_ been horribly ugly. However,
> 2.10 did introduce the "log.showsignature" config, which makes "git
> log --oneline" pretty unusable when it is enabled. Ditto for
> one-liner uses of "--format".
Right! Now I remember, I changed my configuration when I read the
release notes, before I upgraded. Now that I did upgrade I'm seeing the
results.
Anyway, yeah, using the new configuration makes --oneline pretty
unusable, so ignoring that option for --oneline seems like a good idea.
> I think we should probably ignore the config entirely when using any
> of the one-liner formats (and I'd include --format, too, even though
> it can sometimes be multi-line; it already has %GG to include that
> information as appropriate).
>
> Another option would be to somehow represent the signature information
> in the --oneline output, but I think I'd rather leave that for people
> to experiment with using "--format".
I think it might be nice to show the information in one line in a ver
succinct way, like just showing a green unicode check mark (✓) or a red
cross mark (❌) if it failed (or just colour the commit subject in
green/red if a signature is present and is passing/failing).
Thanks!
--
Leandro Lucarella
Technical Development Lead
Sociomantic Labs GmbH <http://www.sociomantic.com>
^ permalink raw reply
* [PATCH 3/3] gitweb: Link to "git describe"'d commits in log messages
From: Ævar Arnfjörð Bjarmason @ 2016-09-21 11:44 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jakub Narebski, Kay Sievers,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20160921114428.28664-1-avarab@gmail.com>
Change the log formatting function to know about "git describe" output
like v2.8.0-4-g867ad08 in addition to just plain 867ad08.
This also fixes a micro-regression in my change of the minimum SHA1
length from 8 to 7, which is that dated tags like
hadoop-20160921-113441-20-g094fb7d would start thinking the "20160921"
part was a commit.
There are still many valid refnames that we don't link to
e.g. v2.10.0-rc1~2^2~1 is also a valid way to refer to
v2.8.0-4-g867ad08, but I'm not supporting that with this commit,
similarly it's trivially possible to create some refnames like
"æ/var-gf6727b0" or whatever which won't be picked up by this regex.
There's surely room for improvement here, but I just wanted to address
the very common case of sticking "git describe" output into commit
messages without trying to link to all possible refnames, that's going
to be a rather futile exercise given that this is free text, and it
would be prohibitively expensive to look up whether the references in
question exist in our repository.
---
gitweb/gitweb.perl | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 101dbc0..3a52bc7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2036,10 +2036,24 @@ sub format_log_line_html {
my $line = shift;
$line = esc_html($line, -nbsp=>1);
- $line =~ s{\b([0-9a-fA-F]{7,40})\b}{
+ $line =~ s{
+ \b
+ (
+ # The output of "git describe", e.g. v2.10.0-297-gf6727b0
+ # or hadoop-20160921-113441-20-g094fb7d
+ (?<!-) # see strbuf_check_tag_ref(). Tags can't start with -
+ [A-Za-z0-9.-]+
+ (?!\.) # refs can't end with ".", see check_refname_format()
+ -g[0-9a-fA-F]{7,40}
+ |
+ # Just a normal looking Git SHA1
+ [0-9a-fA-F]{7,40}
+ )
+ \b
+ }{
$cgi->a({-href => href(action=>"object", hash=>$1),
-class => "text"}, $1);
- }eg;
+ }egx;
return $line;
}
--
2.1.3
^ permalink raw reply related
* [PATCH 2/3] gitweb: Link to 7-character SHA1SUMS in commit messages
From: Ævar Arnfjörð Bjarmason @ 2016-09-21 11:44 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jakub Narebski, Kay Sievers,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20160921114428.28664-1-avarab@gmail.com>
Change the minimum length of a commit we'll link to from 8 to 7.
This arbitrary minimum length of 8 was introduced in
v1.4.4.2-151-gbfe2191, but as seen in e.g. v1.7.4-1-gdce9648 the
default abbreviation length is 7.
It's still possible to reference SHA1s down to 4 characters in length,
see v1.7.4-1-gdce9648's MINIMUM_ABBREV, but I can't see how to make
git actually produce that, so I doubt anyone is putting that into log
messages in practice, but people definitely do put 7 character SHA1s
into log messages.
I think it's fairly dubious to link to things matching [0-9a-fA-F]
here as opposed to just [0-9a-f], that dates back to the initial
version of gitweb from 161332a. Git will accept all-caps SHA1s, but
didn't ever produce them as far as I can tell.
---
gitweb/gitweb.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9473daf..101dbc0 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2036,7 +2036,7 @@ sub format_log_line_html {
my $line = shift;
$line = esc_html($line, -nbsp=>1);
- $line =~ s{\b([0-9a-fA-F]{8,40})\b}{
+ $line =~ s{\b([0-9a-fA-F]{7,40})\b}{
$cgi->a({-href => href(action=>"object", hash=>$1),
-class => "text"}, $1);
}eg;
--
2.1.3
^ permalink raw reply related
* [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786
From: Ævar Arnfjörð Bjarmason @ 2016-09-21 11:44 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jakub Narebski, Kay Sievers,
Ævar Arnfjörð Bjarmason
The Content-Type is application/xhtml+xml, not application/xhtm+xml.
---
gitweb/gitweb.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 33d701d..9473daf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1616,7 +1616,7 @@ sub esc_path {
return $str;
}
-# Sanitize for use in XHTML + application/xml+xhtm (valid XML 1.0)
+# Sanitize for use in XHTML + application/xml+xhtml (valid XML 1.0)
sub sanitize {
my $str = shift;
--
2.1.3
^ permalink raw reply related
* [PATCH v2 3/3] init: reuse original_git_dir in set_git_dir_init()
From: Nguyễn Thái Ngọc Duy @ 2016-09-21 11:29 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, git, max.nordlund,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20160921112939.3444-1-pclouds@gmail.com>
Since original_git_dir is a copy of real_path(git_dir), let's reuse it
and avoid calling real_path() more than necessary.
The xstrdup() is removed too because original_git_dir is already a copy,
and we're not going to free git_link in this code probably forever.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/init-db.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 0d5cc76..d70fc45 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -330,11 +330,11 @@ int set_git_dir_init(const char *git_dir, const char *real_git_dir,
* make sure symlinks are resolved because we'll be
* moving the target repo later on in separate_git_dir()
*/
- git_link = xstrdup(real_path(git_dir));
+ git_link = original_git_dir;
set_git_dir(real_path(real_git_dir));
}
else {
- set_git_dir(real_path(git_dir));
+ set_git_dir(original_git_dir);
git_link = NULL;
}
startup_info->have_repository = 1;
--
2.8.2.524.g6ff3d78
^ permalink raw reply related
* [PATCH v2 2/3] init: do not set core.worktree more often than necessary
From: Nguyễn Thái Ngọc Duy @ 2016-09-21 11:29 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, git, max.nordlund,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20160921112939.3444-1-pclouds@gmail.com>
When "git init" is called with GIT_WORK_TREE environment set, we want to
keep this worktree's location in core.worktree so the user does not have
to set the environment again and again. See ef6f0af (git-init: set
core.worktree if GIT_WORK_TREE is specified - 2007-07-04)
We detect that by this logic (in needs_work_tree_config): normally
worktree's top dir would contains ".git" directory, if this is not true,
worktree is probably set to elsewhere by the user.
Unfortunately when it calls get_git_dir() it does not take ".git" files
into account. When we find a .git file, we immediately follow the file
until we find the real ".git" directory. The location of this first
".git" file is lost.
The .git file would satisfy the logic above and not create
core.worktree (correct). But because the final .git's location is used,
needs_work_tree_config() is misled and creates core.worktree anyway.
This would not be a huge deal normally. But if this happens in a
multiple worktree setup it becomes a real problem because up until now,
core.worktree will be applied to the main worktree only. If you
accidentally do "git init" from a linked worktree, you set
core.worktree (for the main repo) pointing to the _linked_ worktree.
After that point, may you live in interesting times.
Record the .git file location and use it here.
PS. real_path() resolves symlinks So original_git_dir is not truly
original if '.git' is a symlink. Hopefully it's not longer used in favor
of .git files.
Noticed-by: Max Nordlund <max.nordlund@sqore.com>
Helped-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/init-db.c | 5 ++++-
t/t0001-init.sh | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index d5d7558..0d5cc76 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -23,6 +23,7 @@ static int init_is_bare_repository = 0;
static int init_shared_repository = -1;
static const char *init_db_template_dir;
static const char *git_link;
+static const char *original_git_dir;
static void copy_templates_1(struct strbuf *path, struct strbuf *template,
DIR *dir)
@@ -263,7 +264,7 @@ static int create_default_files(const char *template_path)
/* allow template config file to override the default */
if (log_all_ref_updates == -1)
git_config_set("core.logallrefupdates", "true");
- if (needs_work_tree_config(get_git_dir(), work_tree))
+ if (needs_work_tree_config(original_git_dir, work_tree))
git_config_set("core.worktree", work_tree);
}
@@ -314,6 +315,8 @@ static void create_object_directory(void)
int set_git_dir_init(const char *git_dir, const char *real_git_dir,
int exist_ok)
{
+ original_git_dir = xstrdup(real_path(git_dir));
+
if (real_git_dir) {
struct stat st;
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 488564b..b8fc588 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -400,9 +400,11 @@ test_expect_success 're-init from a linked worktree' '
test_commit first &&
git worktree add ../linked-worktree &&
mv .git/info/exclude expected-exclude &&
+ cp .git/config expected-config &&
find .git/worktrees -print | sort >expected &&
git -C ../linked-worktree init &&
test_cmp expected-exclude .git/info/exclude &&
+ test_cmp expected-config .git/config &&
find .git/worktrees -print | sort >actual &&
test_cmp expected actual
)
--
2.8.2.524.g6ff3d78
^ permalink raw reply related
* [PATCH v2 1/3] init: correct re-initialization from a linked worktree
From: Nguyễn Thái Ngọc Duy @ 2016-09-21 11:29 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, git, max.nordlund,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20160921112939.3444-1-pclouds@gmail.com>
When 'git init' is called from a linked worktree, we treat '.git'
dir (which is $GIT_COMMON_DIR/worktrees/something) as the main
'.git' (i.e. $GIT_COMMON_DIR) and populate the whole repository skeleton
in there. It does not harm anything (*) but it is still wrong.
Since 'git init' calls set_git_dir() at preparation time, which
indirectly calls get_common_dir() and correctly detects multiple
worktree setup, all git_path_buf() calls in create_default_files() will
return correct paths in both single and multiple worktree setups. The
only thing left is copy_templates(), which targets $GIT_DIR, not
$GIT_COMMON_DIR.
Fix that with get_git_common_dir(). This function will return $GIT_DIR
in single-worktree setup, so we don't have to make a special case for
multiple-worktree here.
(*) It does in fact, thanks to another bug. More on that later.
Noticed-by: Max Nordlund <max.nordlund@sqore.com>
Helped-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/init-db.c | 2 +-
t/t0001-init.sh | 15 +++++++++++++++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index cc09fca..d5d7558 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -138,7 +138,7 @@ static void copy_templates(const char *template_dir)
goto close_free_return;
}
- strbuf_addstr(&path, get_git_dir());
+ strbuf_addstr(&path, get_git_common_dir());
strbuf_complete(&path, '/');
copy_templates_1(&path, &template_path, dir);
close_free_return:
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 8ffbbea..488564b 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -393,4 +393,19 @@ test_expect_success 'remote init from does not use config from cwd' '
test_cmp expect actual
'
+test_expect_success 're-init from a linked worktree' '
+ git init main-worktree &&
+ (
+ cd main-worktree &&
+ test_commit first &&
+ git worktree add ../linked-worktree &&
+ mv .git/info/exclude expected-exclude &&
+ find .git/worktrees -print | sort >expected &&
+ git -C ../linked-worktree init &&
+ test_cmp expected-exclude .git/info/exclude &&
+ find .git/worktrees -print | sort >actual &&
+ test_cmp expected actual
+ )
+'
+
test_done
--
2.8.2.524.g6ff3d78
^ permalink raw reply related
* [PATCH v2 0/3] Fix git-init in linked worktrees
From: Nguyễn Thái Ngọc Duy @ 2016-09-21 11:29 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, git, max.nordlund,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20160908134719.27955-1-pclouds@gmail.com>
v2 requires jk/setup-sequence-update so I could kill my workaround
patch and avoid conflicts in t0001. And:
- 1/3 has a few missing words back in its commit message
- 2/3, which was 3/3 in v1, no longer has the ugly hacky
get_first_git_dir()
- 3/3 is a new tiny code improvement after the new 2/3
Nguyễn Thái Ngọc Duy (3):
init: correct re-initialization from a linked worktree
init: do not set core.worktree more often than necessary
init: reuse original_git_dir in set_git_dir_init()
builtin/init-db.c | 11 +++++++----
t/t0001-init.sh | 17 +++++++++++++++++
2 files changed, 24 insertions(+), 4 deletions(-)
--
2.8.2.524.g6ff3d78
^ permalink raw reply
* Re: [PATCH v2 2/2] mailinfo: unescape quoted-pair in header fields
From: Jeff King @ 2016-09-21 11:09 UTC (permalink / raw)
To: Kevin Daudt; +Cc: git, Swift Geek, Junio C Hamano
In-Reply-To: <20160919185440.18234-3-me@ikke.info>
On Mon, Sep 19, 2016 at 08:54:40PM +0200, Kevin Daudt wrote:
> diff --git a/mailinfo.c b/mailinfo.c
> index e19abe3..6a7c2f2 100644
> --- a/mailinfo.c
> +++ b/mailinfo.c
> @@ -54,6 +54,50 @@ static void parse_bogus_from(struct mailinfo *mi, const struct strbuf *line)
> get_sane_name(&mi->name, &mi->name, &mi->email);
> }
>
> +static void unquote_quoted_string(struct strbuf *line)
> +{
> + const char *in = strbuf_detach(line, NULL);
I see that this version uses the "detach, and then write into the
replacement" approach, which is good. But...
> + int c, take_next_literally = 0;
> + int found_error = 0;
> +
> + /*
> + * Stores the character that started the escape mode so that we know what
> + * character will stop it
> + */
> + char escape_context = 0;
> +
> + while ((c = *in++) != 0) {
> + if (take_next_literally) {
> + take_next_literally = 0;
> + } else {
> [...]
> + }
> +
> + strbuf_addch(line, c);
> + }
> +}
It needs to `free(in)` at the end of the function.
Your original also fed "line->len" as a hint, but I doubt it really
matters in practice, so I don't mind losing that.
-Peff
^ permalink raw reply
* Re: [PATCH v1] travis-ci: ask homebrew for the its path instead of hardcoding it
From: stefan.naewe @ 2016-09-21 9:31 UTC (permalink / raw)
To: larsxschneider, git; +Cc: gitster
In-Reply-To: <20160921084518.13091-1-larsxschneider@gmail.com>
In the Subject: s/the //
Am 21.09.2016 um 10:45 schrieb larsxschneider@gmail.com:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> The TravisCI macOS build is broken because homebrew (a macOS depedency
s/depedency/dependency/
> manager) changed its internal directory structure [1]. This is a problem
> because we modify the Perforce dependencies in the homebrew repository
> before installing them.
>
> Fix it by asking homebrew for its path instead of hardcoding it.
>
> [1] https://github.com/Homebrew/brew/commit/0a09ae30f8b6117ad699b4a0439010738989c547
>
> Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
> ---
>
> Hi Junio,
>
> the problem affects all branches (pu, next, master, maint):
> https://travis-ci.org/git/git/branches
>
> Is it possible for this fix to graduate more quickly?
>
> Thanks,
> Lars
>
> .travis.yml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 477c3d2..37a1e1f 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -78,7 +78,7 @@ before_install:
> FORMULA=$1
> SHA=$(brew fetch --force $FORMULA 2>&1 | grep ^SHA256: | cut -d ' ' -f 2)
> sed -E -i.bak "s/sha256 \"[0-9a-f]{64}\"/sha256 \"$SHA\"/g" \
> - /usr/local/Library/Taps/homebrew/homebrew-binary/$FORMULA.rb
> + "$(brew --repository homebrew/homebrew-binary)/$FORMULA.rb"
> }
> brew update --quiet
> brew tap homebrew/binary --quiet
> --
> 2.10.0
>
>
--
----------------------------------------------------------------
/dev/random says: If winning isn't important then why keep score?
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2016, #05; Mon, 19)
From: Duy Nguyen @ 2016-09-21 9:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <xmqqd1jzcvs5.fsf@gitster.mtv.corp.google.com>
On Tue, Sep 20, 2016 at 6:30 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * nd/checkout-disambiguation (2016-09-09) 4 commits
> - fixup! checkout.txt: document a common case that ignores ambiguation rules
> - checkout: fix ambiguity check in subdir
> - checkout.txt: document a common case that ignores ambiguation rules
> - checkout: add some spaces between code and comment
>
> "git checkout <word>" does not follow the usual disambiguation
> rules when the <word> can be both a rev and a path, to allow
> checking out a branch 'foo' in a project that happens to have a
> file 'foo' in the working tree without having to disambiguate.
> This was poorly documented and the check was incorrect when the
> command was run from a subdirectory.
>
> Waiting for an Ack for fixup!
Oops, I didn't know (I have about 300 unread git mails in my inbox), Ack.
--
Duy
^ permalink raw reply
* Re: Re: Homebrew and Git
From: Jeff King @ 2016-09-21 8:48 UTC (permalink / raw)
To: John Keeping; +Cc: Heiko Voigt, Jonas Thiel, git
In-Reply-To: <20160920191555.GB1673@john.keeping.me.uk>
On Tue, Sep 20, 2016 at 08:15:55PM +0100, John Keeping wrote:
> > BTW, here is the callstack inlined from the crashreport:
> >
> > bsystem_platform.dylib 0x00007fff840db41c _platform_strchr$VARIANT$Haswell + 28
> > 1 git 0x000000010ba1d3f4 ident_default_email + 801
> > 2 git 0x000000010ba1d68f fmt_ident + 66
> > 3 git 0x000000010ba4b495 files_log_ref_write + 175
> > 4 git 0x000000010ba4b0a6 commit_ref_update + 106
> > 5 git 0x000000010ba4c3a8 ref_transaction_commit + 468
> > 6 git 0x000000010b994dd8 s_update_ref + 271
> > 7 git 0x000000010b994556 fetch_refs + 1969
> > 8 git 0x000000010b9935f2 fetch_one + 1913
> > 9 git 0x000000010b992bc4 cmd_fetch + 549
> > 10 git 0x000000010b9666c4 handle_builtin + 478
> > 11 git 0x000000010b96602f main + 376
> > 12 libdyld.dylib 0x00007fff834ef5ad start + 1
> >
> > Maybe someone else has an idea what might be causing this...
>
> The only strchr I can see that could be called here is in
> canonical_name(), where it's called with addrinfo::ai_canonname.
There's one in add_domainname(), too, but it can never be NULL (we could
walk off the end of the buffer, but only if gethostname() lies to us
about its result code, which seems unlikely). So I agree it's probably
the call in canonical_name().
> Searching for OS X and ai_canonname, leads me straight back to this
> list, although 7 years ago! I think ident.c needs a fix similar to
> commit 3e8a00a (daemon.c: fix segfault on OS X, 2009-04-27); from the
> commit message there:
>
> On OS X (and maybe other unices), getaddrinfo(3) returns NULL
> in the ai_canonname field if it's called with an IP address for
> the hostname.
Interesting. We are already prepared for failure from getaddrinfo()
here, so probably:
diff --git a/ident.c b/ident.c
index e20a772..d17b5bd 100644
--- a/ident.c
+++ b/ident.c
@@ -101,7 +101,7 @@ static int canonical_name(const char *host, struct strbuf *out)
memset (&hints, '\0', sizeof (hints));
hints.ai_flags = AI_CANONNAME;
if (!getaddrinfo(host, NULL, &hints, &ai)) {
- if (ai && strchr(ai->ai_canonname, '.')) {
+ if (ai && ai->ai_canonname && strchr(ai->ai_canonname, '.')) {
strbuf_addstr(out, ai->ai_canonname);
status = 0;
}
would be sufficient. Jonas, can you see if that patch helps?
-Peff
^ permalink raw reply related
* [PATCH v1] travis-ci: ask homebrew for the its path instead of hardcoding it
From: larsxschneider @ 2016-09-21 8:45 UTC (permalink / raw)
To: git; +Cc: gitster, Lars Schneider
From: Lars Schneider <larsxschneider@gmail.com>
The TravisCI macOS build is broken because homebrew (a macOS depedency
manager) changed its internal directory structure [1]. This is a problem
because we modify the Perforce dependencies in the homebrew repository
before installing them.
Fix it by asking homebrew for its path instead of hardcoding it.
[1] https://github.com/Homebrew/brew/commit/0a09ae30f8b6117ad699b4a0439010738989c547
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
---
Hi Junio,
the problem affects all branches (pu, next, master, maint):
https://travis-ci.org/git/git/branches
Is it possible for this fix to graduate more quickly?
Thanks,
Lars
.travis.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.travis.yml b/.travis.yml
index 477c3d2..37a1e1f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -78,7 +78,7 @@ before_install:
FORMULA=$1
SHA=$(brew fetch --force $FORMULA 2>&1 | grep ^SHA256: | cut -d ' ' -f 2)
sed -E -i.bak "s/sha256 \"[0-9a-f]{64}\"/sha256 \"$SHA\"/g" \
- /usr/local/Library/Taps/homebrew/homebrew-binary/$FORMULA.rb
+ "$(brew --repository homebrew/homebrew-binary)/$FORMULA.rb"
}
brew update --quiet
brew tap homebrew/binary --quiet
--
2.10.0
^ permalink raw reply related
* Re: 2.10.0: git log --oneline prints gpg signatures in 4 lines
From: Jeff King @ 2016-09-20 23:15 UTC (permalink / raw)
To: Leandro Lucarella; +Cc: Mehul Jain, git
In-Reply-To: <20160920170954.38b24284@labs-064.localdomain>
On Tue, Sep 20, 2016 at 05:09:54PM +0200, Leandro Lucarella wrote:
> Hi, starting from 2.10.0 I noticed that when using git log --oneline,
> if commits are signed with GPG, now the signatures are printed too, and
> it takes 3 lines for the signature information + 1 line for the title
> of the commit, so suddenly --oneline became --fourline :)
>
> Is this really intended?
I don't think anything has changed here in 2.10. Running "git log
--oneline --show-signature" has _always_ been horribly ugly. However,
2.10 did introduce the "log.showsignature" config, which makes "git log
--oneline" pretty unusable when it is enabled. Ditto for one-liner uses
of "--format".
I think we should probably ignore the config entirely when using any of
the one-liner formats (and I'd include --format, too, even though it can
sometimes be multi-line; it already has %GG to include that information
as appropriate).
Another option would be to somehow represent the signature information
in the --oneline output, but I think I'd rather leave that for people to
experiment with using "--format".
-Peff
^ permalink raw reply
* Re: [PATCH v3 0/3] handle multiline in-body headers
From: Jeff King @ 2016-09-20 23:06 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git, gitster
In-Reply-To: <cover.1474391594.git.jonathantanmy@google.com>
On Tue, Sep 20, 2016 at 10:17:50AM -0700, Jonathan Tan wrote:
> Changes since v2:
> o Removed utf8 translation before scissors line check in
> check_inbody_header (I was thinking of support for encodings like
> UTF-16, but I guess those don't work with the current reencode_string
> anyway since it uses strlen internally)
Yeah, I'd be surprised if UTF-16 works very well with our code in
general. If we want to address that, though, the sanest thing is
probably to convert it internally to UTF-8 when we remove the transfer
encoding in handle_body().
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox