* Re: `git stash apply` deleted a random dir from my working copy
From: Stefan Monov @ 2016-11-03 17:01 UTC (permalink / raw)
To: git
In-Reply-To: <CAJtFkWsUL=9K=VGTDejE+4RR3HJevk+2aRAhUyf8-mDrqi5MRg@mail.gmail.com>
Actually, I just tried restoring my dir with `git pull origin
clipping`, but that didn't restore it. So, besides the question "why
did it get deleted", I'd like to ask "how do I restore it?", as well.
On Thu, Nov 3, 2016 at 6:06 PM, Stefan Monov <logixoul@gmail.com> wrote:
> Hi.
>
> I just tried `git stash save` for the first time. It worked fine. Then
> I tried `git stash apply` and while my uncommitted changes were
> restored, another effect was that a random dir from the root of my
> working copy was deleted. I don't know why it chose that exact dir,
> there's lots of other dirs like it in the root.
>
> `git stash save` output and shortened `git stash apply` output are attached.
>
> Note: The dir that got deleted was a committed and pushed dir. It had
> no uncommitted local changes.
>
> It's not a huge problem, because there was no data loss - I can pull
> the deleted data back from the repo. But I'd still like to know why
> this problem happened.
>
> TIA, Stefan Monov
^ permalink raw reply
* Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
From: Johannes Schindelin @ 2016-11-03 16:51 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20161103153845.nhquuoko4utecit2@sigill.intra.peff.net>
Hi Peff,
On Thu, 3 Nov 2016, Jeff King wrote:
> On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote:
>
> > This is missing a Content-Transfer-Encoding. I think the default is the
> > traditional 7-bit ascii encoding, but your body has characters with the
> > high-bit set (your UTF-8 bullet).
> >
> > Try adding:
> >
> > Content-Transfer-Encoding: 8bit
> >
> > I haven't seen this before, but I do recall that vger's MTA is very
> > picky about this and wants to rewrite transfer-encodings, so it seems
> > plausible.
>
> Technically, I think you'd also need a:
>
> MIME-Version: 1.0
>
> header.
That seems to have done the trick, thank you so much!
Ciao,
Dscho
^ permalink raw reply
* Test mail
From: Johannes Schindelin @ 2016-11-03 16:49 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
This is just a test mail to test whether the bullet offends vger, still,
even with the headers indicated by Peff:
• This is a bullet point.
Fingers crossed,
Dscho
^ permalink raw reply
* Re: Bug in git rev-parse @{push}?
From: Chris Purcell @ 2016-11-03 16:09 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20161103160716.6ygtf5iosudo2w3g@sigill.intra.peff.net>
Will do, thanks! Meanwhile, I'll work around locally by changing off
'simple' in my config—if I can figure out how not to break everything
in the process...
On 3 November 2016 at 16:07, Jeff King <peff@peff.net> wrote:
> On Thu, Nov 03, 2016 at 03:59:13PM +0000, Chris Purcell wrote:
>
>> >> Thanks, Jeff! If I remove the explicit configuration of remote.pushdefault
>> >> = "origin", I get the same error message as you, so I suspect that's _not_
>> >> the default.
>> >
>> > That's really bizarre, because I get the same behavior with or without
>> > it set. Not only that, but it shouldn't even come into play, as
>> > branch.foo.remote should take precedence anyway.
>> >
>> > So now I'm really puzzled.
>>
>> That's because I lied. Sorry! Too many branches configured. I've actually got
>>
>> [branch "foo"]
>> remote = .
>>
>> If I change that to 'origin' like I claimed it was, it starts erroring.
>
> OK, now I can reproduce. And changing remote.pushdefault _does_ matter
> because builtin/push.c:is_workflow_triangular() uses it as a key to "we
> are in a triangular workflow".
>
> That was added by ed2b18292 (push: change `simple` to accommodate
> triangular workflows, 2013-06-19). TBH, I think the right solution is
> "stop using 'simple' in a triangular setup". But since that workflow
> exists for git-push, we probably need to support it via @{push}, too.
>
> I think the solution would be something like:
>
> - move is_workflow_triangular() into remote.c so it is accessible in
> both places
>
> - when branch_get_push_1 sees that is_workflow_triangular() is true,
> treat "simple" as "current"
>
> - new tests should go into t/t1514-rev-parse-push.sh to cover this
> case
>
> Want to take a stab at it?
>
> -Peff
^ permalink raw reply
* Re: Bug in git rev-parse @{push}?
From: Jeff King @ 2016-11-03 16:07 UTC (permalink / raw)
To: Chris Purcell; +Cc: git
In-Reply-To: <CAJUoZVY0-OA7Tu=cHDPH+NwmQ8MUuWc37_5aqeGQbwKpNWVzqg@mail.gmail.com>
On Thu, Nov 03, 2016 at 03:59:13PM +0000, Chris Purcell wrote:
> >> Thanks, Jeff! If I remove the explicit configuration of remote.pushdefault
> >> = "origin", I get the same error message as you, so I suspect that's _not_
> >> the default.
> >
> > That's really bizarre, because I get the same behavior with or without
> > it set. Not only that, but it shouldn't even come into play, as
> > branch.foo.remote should take precedence anyway.
> >
> > So now I'm really puzzled.
>
> That's because I lied. Sorry! Too many branches configured. I've actually got
>
> [branch "foo"]
> remote = .
>
> If I change that to 'origin' like I claimed it was, it starts erroring.
OK, now I can reproduce. And changing remote.pushdefault _does_ matter
because builtin/push.c:is_workflow_triangular() uses it as a key to "we
are in a triangular workflow".
That was added by ed2b18292 (push: change `simple` to accommodate
triangular workflows, 2013-06-19). TBH, I think the right solution is
"stop using 'simple' in a triangular setup". But since that workflow
exists for git-push, we probably need to support it via @{push}, too.
I think the solution would be something like:
- move is_workflow_triangular() into remote.c so it is accessible in
both places
- when branch_get_push_1 sees that is_workflow_triangular() is true,
treat "simple" as "current"
- new tests should go into t/t1514-rev-parse-push.sh to cover this
case
Want to take a stab at it?
-Peff
^ permalink raw reply
* `git stash apply` deleted a random dir from my working copy
From: Stefan Monov @ 2016-11-03 16:06 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
Hi.
I just tried `git stash save` for the first time. It worked fine. Then
I tried `git stash apply` and while my uncommitted changes were
restored, another effect was that a random dir from the root of my
working copy was deleted. I don't know why it chose that exact dir,
there's lots of other dirs like it in the root.
`git stash save` output and shortened `git stash apply` output are attached.
Note: The dir that got deleted was a committed and pushed dir. It had
no uncommitted local changes.
It's not a huge problem, because there was no data loss - I can pull
the deleted data back from the repo. But I'd still like to know why
this problem happened.
TIA, Stefan Monov
[-- Attachment #2: git_stash_save_output.txt --]
[-- Type: text/plain, Size: 304 bytes --]
Saved working directory and index state WIP on clipping: cfeac4b - applying the solution from http://stackoverflow.com/questions/40385482/why-cant-i-use-opengl-es-3-0-in-qt
HEAD is now at cfeac4b - applying the solution from http://stackoverflow.com/questions/40385482/why-cant-i-use-opengl-es-3-0-in-qt
[-- Attachment #3: shortened_git_stash_apply_output.txt --]
[-- Type: text/plain, Size: 893 bytes --]
Removing debug_stencil_not_working/textureandlight.js
Removing debug_stencil_not_working/qtlogo.png
[... more removes here ...]
On branch clipping
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: documentation/textureSize_missing.txt
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: ../debug_stencil_not_working/qtlogo.png
deleted: ../debug_stencil_not_working/textureandlight.js
[... more deleted files here ...]
modified: main.cpp
modified: main.qml
[... more modified files here ...]
Untracked files:
(use "git add <file>..." to include in what will be committed)
../dbg_repeater/dbg_repeater.pro.user
debug_stencil_not_working/
[... more files and dirs here ...]
^ permalink raw reply
* Re: Bug in git rev-parse @{push}?
From: Chris Purcell @ 2016-11-03 15:59 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20161103155400.jqzopj5i2rrlj6km@sigill.intra.peff.net>
>> Thanks, Jeff! If I remove the explicit configuration of remote.pushdefault
>> = "origin", I get the same error message as you, so I suspect that's _not_
>> the default.
>
> That's really bizarre, because I get the same behavior with or without
> it set. Not only that, but it shouldn't even come into play, as
> branch.foo.remote should take precedence anyway.
>
> So now I'm really puzzled.
That's because I lied. Sorry! Too many branches configured. I've actually got
[branch "foo"]
remote = .
If I change that to 'origin' like I claimed it was, it starts erroring.
^ permalink raw reply
* ignore blank line removals
From: John Rood @ 2016-11-03 15:57 UTC (permalink / raw)
To: git
If the contents of a file initially are:
one
three
and on branch A there is a commit, removing the blank line:
one
three
and on branch B there is a commit, adding 'two':
one
two
three
Normally, if you try to merge A into B (or B into A), git recognizes a
decision needs to be made between removing the second line or add
"two" to the second line. It would be convenient to have a merge
strategy that defaults to the latter in cases where the removed line
was a blank line (or a line containing only whitespace) ...something
like -Xignore-blank-line-removals.
^ permalink raw reply
* Re: Bug in git rev-parse @{push}?
From: Jeff King @ 2016-11-03 15:54 UTC (permalink / raw)
To: Chris Purcell; +Cc: git
In-Reply-To: <CAJUoZVbnWzpjzWe_qGZTnX_6N2+OJVG39WYaBgY7OfQBNCg+rg@mail.gmail.com>
On Thu, Nov 03, 2016 at 03:48:50PM +0000, Chris Purcell wrote:
> Thanks, Jeff! If I remove the explicit configuration of remote.pushdefault
> = "origin", I get the same error message as you, so I suspect that's _not_
> the default.
That's really bizarre, because I get the same behavior with or without
it set. Not only that, but it shouldn't even come into play, as
branch.foo.remote should take precedence anyway.
So now I'm really puzzled.
-Peff
^ permalink raw reply
* Re: Bug in git rev-parse @{push}?
From: Chris Purcell @ 2016-11-03 15:52 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <CAJUoZVbnWzpjzWe_qGZTnX_6N2+OJVG39WYaBgY7OfQBNCg+rg@mail.gmail.com>
Resending to mailing list because Inbox is fighting with vger...
On 3 November 2016 at 15:48, Chris Purcell <chris.purcell.39@gmail.com> wrote:
> Thanks, Jeff! If I remove the explicit configuration of remote.pushdefault =
> "origin", I get the same error message as you, so I suspect that's _not_ the
> default.
>
> On Thu, 3 Nov 2016 at 15:14 Jeff King <peff@peff.net> wrote:
>>
>> On Thu, Nov 03, 2016 at 02:53:44PM +0000, Chris Purcell wrote:
>>
>> > I think I have discovered a bug in rev-parse's handling of @{push}:
>> >
>> > $ git push
>> > Everything up-to-date
>> > $ git rev-parse @{push}
>> > fatal: cannot resolve 'simple' push to a single destination
>> >
>> > The documentation for rev-parse says that "the suffix @{push} reports
>> > the branch 'where we would push to' if git push were run while
>> > branchname was checked out", so I would not expect this to error
>> > unless git push does.
>>
>> I'm not too surprised if there's a bug there. IIRC, the way the code is
>> structured, some of the logic had to be reimplemented for @{push} rather
>> than re-used, so there may be corner cases where they do not agree.
>>
>> > The relevant parts of my configuration are:
>> >
>> > [push]
>> > default = simple
>> > [remote]
>> > pushdefault = origin
>> > [branch "foo"]
>> > remote = origin
>> > merge = refs/heads/develop
>> >
>> > The code in branch_get_push_1 (remote.c) in the PUSH_DEFAULT_SIMPLE
>> > case is calling both branch_get_upstream and tracking_for_push_dest
>> > and erroring if they don't return the same result, which I assume is
>> > incorrect for a triangular workflow?
>>
>> I assume you have branch "foo" checked out?
>>
>> With this config I don't see how "git push" would work. Because you're
>> using "simple", it should complain that "develop" and "foo" are not the
>> same name.
>>
>> Can you give a more full reproduction recipe? If I try:
>>
>> git init tmp && cd tmp
>> git config push.default simple
>> git commit -m foo --allow-empty ;# just to have some commit to push
>>
>> git init --bare dst.git
>> git remote add origin dst.git
>> git push origin master:refs/heads/develop
>>
>> git checkout -b foo origin/develop
>>
>> # pushdefault of "origin" is already the default. checkout will have
>> # set up branch.foo.* as you specified. So let's try our push.
>> git push
>>
>> Then I get:
>>
>> fatal: The upstream branch of your current branch does not match
>> the name of your current branch. To push to the upstream branch
>> on the remote, use
>>
>> git push origin HEAD:develop
>>
>> To push to the branch of the same name on the remote, use
>>
>> git push origin foo
>>
>> which makes sense.
>>
>> If you _don't_ get that same message with "git push", then my next
>> question is: might you have any aliases or other systems like "hub" that
>> are munging the arguments to "git push"? Running with "GIT_TRACE=1" in
>> the environment might be enlightening there.
>>
>> > Please let me know if I've missed out important information by
>> > mistake. I'm happy to work on a patch if given guidance, but this is
>> > definitely outside my comfort zone for an unfamiliar codebase
>> > otherwise! e.g. I can't find the test suite.
>>
>> The tests are in the "t" directory; see t/README for details. You can
>> run them all with "make test" from the top-level directory.
>>
>> -Peff
^ permalink raw reply
* Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
From: Jeff King @ 2016-11-03 15:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <20161103153845.nhquuoko4utecit2@sigill.intra.peff.net>
On Thu, Nov 03, 2016 at 11:38:45AM -0400, Jeff King wrote:
> On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote:
>
> > This is missing a Content-Transfer-Encoding. I think the default is the
> > traditional 7-bit ascii encoding, but your body has characters with the
> > high-bit set (your UTF-8 bullet).
> >
> > Try adding:
> >
> > Content-Transfer-Encoding: 8bit
> >
> > I haven't seen this before, but I do recall that vger's MTA is very
> > picky about this and wants to rewrite transfer-encodings, so it seems
> > plausible.
>
> Technically, I think you'd also need a:
>
> MIME-Version: 1.0
>
> header. That being said, I just peeked at the send-email code and it
> looks like we try to add in these headers as necessary. It's possible
> there's a bug, though. What does "git send-email --dry-run" say is in
> the headers it sends out?
Answering my own question, it looks like send-email gets confused when
you give a content-type but no content-transfer-encoding. It wants to
fill in both or neither.
This probably helps:
diff --git a/git-send-email.perl b/git-send-email.perl
index da81be40c..784bb874b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1568,11 +1568,13 @@ foreach my $t (@files) {
push @cc, recipients_cmd("cc-cmd", "cc", $cc_cmd, $t)
if defined $cc_cmd && !$suppress_cc{'cccmd'};
- if ($broken_encoding{$t} && !$has_content_type) {
+ if ($broken_encoding{$t}) {
$xfer_encoding = '8bit' if not defined $xfer_encoding;
- $has_content_type = 1;
- push @xh, "Content-Type: text/plain; charset=$auto_8bit_encoding";
- $body_encoding = $auto_8bit_encoding;
+ if (!$has_content_type) {
+ $has_content_type = 1;
+ push @xh, "Content-Type: text/plain; charset=$auto_8bit_encoding";
+ $body_encoding = $auto_8bit_encoding;
+ }
}
if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
but I think there is more cleanup to handle this case (e.g., it
auto-guesses utf-8, but it should pull the value from the existing
content-type header).
-Peff
^ permalink raw reply related
* Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
From: Jeff King @ 2016-11-03 15:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <20161103153453.4aipi5lxkmkt3kco@sigill.intra.peff.net>
On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote:
> This is missing a Content-Transfer-Encoding. I think the default is the
> traditional 7-bit ascii encoding, but your body has characters with the
> high-bit set (your UTF-8 bullet).
>
> Try adding:
>
> Content-Transfer-Encoding: 8bit
>
> I haven't seen this before, but I do recall that vger's MTA is very
> picky about this and wants to rewrite transfer-encodings, so it seems
> plausible.
Technically, I think you'd also need a:
MIME-Version: 1.0
header. That being said, I just peeked at the send-email code and it
looks like we try to add in these headers as necessary. It's possible
there's a bug, though. What does "git send-email --dry-run" say is in
the headers it sends out?
-Peff
^ permalink raw reply
* Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
From: Jeff King @ 2016-11-03 15:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.2.20.1611031554100.3108@virtualbox>
On Thu, Nov 03, 2016 at 04:15:05PM +0100, Johannes Schindelin wrote:
> When it finally sent out the mail, and I thought everything was alright,
> thinking that I could turn out for the night with a well-deserved drink, I
> got this from vger.kernel.org:
>
> -- snip --
> SMTP error from remote server for TEXT command, host: vger.kernel.org (209.132.180.67) reason: 550 5.7.1 Content-Policy reject msg: Wrong MIME labeling on 8-bit character texts.
> -- snap --
>
> Is there *anybody* who could give me a clue what this means?
That's a new one for me. One guess, though...
> For the record, I tried to use `git send-email` to send out the
> announcement for the very first time, and the headers of the mbox file I
> fed to that command read thusly:
>
> -- snip --
> From 2.10.2.windows.1 Mon Sep 17 00:00:00 2001
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> Date: Wed, 02 Nov 2016 21:43:54 +0100
> To: git-for-windows@googlegroups.com, git@vger.kernel.org
> Subject: [ANNOUNCE] Git for Windows 2.10.2
> Content-Type: text/plain; charset=UTF-8
> Fcc: Sent
> -- snap --
This is missing a Content-Transfer-Encoding. I think the default is the
traditional 7-bit ascii encoding, but your body has characters with the
high-bit set (your UTF-8 bullet).
Try adding:
Content-Transfer-Encoding: 8bit
I haven't seen this before, but I do recall that vger's MTA is very
picky about this and wants to rewrite transfer-encodings, so it seems
plausible.
-Peff
^ permalink raw reply
* Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
From: Junio C Hamano @ 2016-11-03 15:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.2.20.1611031554100.3108@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> thinking that I could turn out for the night with a well-deserved drink, I
> got this from vger.kernel.org:
>
> -- snip --
> SMTP error from remote server for TEXT command, host: vger.kernel.org (209.132.180.67) reason: 550 5.7.1 Content-Policy reject msg: Wrong MIME labeling on 8-bit character texts.
> -- snap --
>
> Is there *anybody* who could give me a clue what this means?
Have you tried postmaster (at vger.kernel.org)?
>
> For the record, I tried to use `git send-email` to send out the
> announcement for the very first time, and the headers of the mbox file I
> fed to that command read thusly:
>
> -- snip --
> From 2.10.2.windows.1 Mon Sep 17 00:00:00 2001
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> Date: Wed, 02 Nov 2016 21:43:54 +0100
> To: git-for-windows@googlegroups.com, git@vger.kernel.org
> Subject: [ANNOUNCE] Git for Windows 2.10.2
> Content-Type: text/plain; charset=UTF-8
> Fcc: Sent
> -- snap --
>
> The only problem I could *possibly* imagine is this UTF-8 bullet character
> used in the enumerations in the mail body:
>
> • [...]
The above header you showed says "Content-type: text/plain;
charset=UTF-8" and I am hoping that this response to you will go out
with that labelling back to vger, so we will hopefully see if that
bullet is the culprit (I doubt it, though). I have no specific
suspect at this point yet, other than "somebody that gets your
message from send-email and passes to vger may be mangling it".
^ permalink raw reply
* Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
From: Johannes Schindelin @ 2016-11-03 15:15 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.2.20.1611022158140.3108@virtualbox>
[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]
Hi all,
On Wed, 2 Nov 2016, Johannes Schindelin wrote:
> Dear Git users,
>
> It is my pleasure to announce that Git for Windows 2.10.2 is available from:
>
> https://git-for-windows.github.io/
> [...]
I originally intended this to be sent out at the same time as the
announcement to the Git for Windows mailing list, finally in an automated
manner so that I do not have to sit by the keyboard waiting for the
uploads to finish (every new Git for Windows version is bundled into 9
different distributables that all want to be uploaded).
But.
When it finally sent out the mail, and I thought everything was alright,
thinking that I could turn out for the night with a well-deserved drink, I
got this from vger.kernel.org:
-- snip --
SMTP error from remote server for TEXT command, host: vger.kernel.org (209.132.180.67) reason: 550 5.7.1 Content-Policy reject msg: Wrong MIME labeling on 8-bit character texts.
-- snap --
Is there *anybody* who could give me a clue what this means?
For the record, I tried to use `git send-email` to send out the
announcement for the very first time, and the headers of the mbox file I
fed to that command read thusly:
-- snip --
From 2.10.2.windows.1 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Wed, 02 Nov 2016 21:43:54 +0100
To: git-for-windows@googlegroups.com, git@vger.kernel.org
Subject: [ANNOUNCE] Git for Windows 2.10.2
Content-Type: text/plain; charset=UTF-8
Fcc: Sent
-- snap --
The only problem I could *possibly* imagine is this UTF-8 bullet character
used in the enumerations in the mail body:
• [...]
FWIW I like that bullet very much, even if it was not my doing, but w3m's
rendering of the release notes [*1*].
I would really, really, *really* like to keep automating things to make
the release engineering of Git for Windows more painless and boring, but
this thing, this unhelpful vger error message is blocking me from doing so
right now.
Help, anyone?
Thanks,
Dscho
Footnote *1*: The release notes are actually written using Markdown:
https://github.com/git-for-windows/build-extra/blob/master/ReleaseNotes.md
Those release notes are then rendered into HTML when releasing:
https://github.com/git-for-windows/build-extra/blob/4d6097f/installer/release.sh#L86
They are also rendered into nice-looking ASCII via HTML by using both
Markdown.perl and w3m, for use in the tag message:
https://github.com/git-for-windows/build-extra/blob/4d6097f/please.sh#L1063-L1066
Same procedure is used again (to allow for very, very last-minute changes,
such as the inclusion of Git Credential Manager v1.8.1 late yesterday,
just because I still chased a bug introduced during the high-intensity
installer patching bout last Tuesday) when announcing the new version:
https://github.com/git-for-windows/build-extra/blob/4d6097f/please.sh#L1580-L1582
^ permalink raw reply
* Re: Bug in git rev-parse @{push}?
From: Jeff King @ 2016-11-03 15:14 UTC (permalink / raw)
To: Chris Purcell; +Cc: git
In-Reply-To: <CAJUoZVYF=ZCBUX6jztwhJX3BZdq4JEfrSRbi4cFPwn+7yA=VjA@mail.gmail.com>
On Thu, Nov 03, 2016 at 02:53:44PM +0000, Chris Purcell wrote:
> I think I have discovered a bug in rev-parse's handling of @{push}:
>
> $ git push
> Everything up-to-date
> $ git rev-parse @{push}
> fatal: cannot resolve 'simple' push to a single destination
>
> The documentation for rev-parse says that "the suffix @{push} reports
> the branch 'where we would push to' if git push were run while
> branchname was checked out", so I would not expect this to error
> unless git push does.
I'm not too surprised if there's a bug there. IIRC, the way the code is
structured, some of the logic had to be reimplemented for @{push} rather
than re-used, so there may be corner cases where they do not agree.
> The relevant parts of my configuration are:
>
> [push]
> default = simple
> [remote]
> pushdefault = origin
> [branch "foo"]
> remote = origin
> merge = refs/heads/develop
>
> The code in branch_get_push_1 (remote.c) in the PUSH_DEFAULT_SIMPLE
> case is calling both branch_get_upstream and tracking_for_push_dest
> and erroring if they don't return the same result, which I assume is
> incorrect for a triangular workflow?
I assume you have branch "foo" checked out?
With this config I don't see how "git push" would work. Because you're
using "simple", it should complain that "develop" and "foo" are not the
same name.
Can you give a more full reproduction recipe? If I try:
git init tmp && cd tmp
git config push.default simple
git commit -m foo --allow-empty ;# just to have some commit to push
git init --bare dst.git
git remote add origin dst.git
git push origin master:refs/heads/develop
git checkout -b foo origin/develop
# pushdefault of "origin" is already the default. checkout will have
# set up branch.foo.* as you specified. So let's try our push.
git push
Then I get:
fatal: The upstream branch of your current branch does not match
the name of your current branch. To push to the upstream branch
on the remote, use
git push origin HEAD:develop
To push to the branch of the same name on the remote, use
git push origin foo
which makes sense.
If you _don't_ get that same message with "git push", then my next
question is: might you have any aliases or other systems like "hub" that
are munging the arguments to "git push"? Running with "GIT_TRACE=1" in
the environment might be enlightening there.
> Please let me know if I've missed out important information by
> mistake. I'm happy to work on a patch if given guidance, but this is
> definitely outside my comfort zone for an unfamiliar codebase
> otherwise! e.g. I can't find the test suite.
The tests are in the "t" directory; see t/README for details. You can
run them all with "make test" from the top-level directory.
-Peff
^ permalink raw reply
* Bug in git rev-parse @{push}?
From: Chris Purcell @ 2016-11-03 14:53 UTC (permalink / raw)
To: git; +Cc: peff
Hi folks,
I think I have discovered a bug in rev-parse's handling of @{push}:
$ git push
Everything up-to-date
$ git rev-parse @{push}
fatal: cannot resolve 'simple' push to a single destination
The documentation for rev-parse says that "the suffix @{push} reports
the branch 'where we would push to' if git push were run while
branchname was checked out", so I would not expect this to error
unless git push does.
The relevant parts of my configuration are:
[push]
default = simple
[remote]
pushdefault = origin
[branch "foo"]
remote = origin
merge = refs/heads/develop
The code in branch_get_push_1 (remote.c) in the PUSH_DEFAULT_SIMPLE
case is calling both branch_get_upstream and tracking_for_push_dest
and erroring if they don't return the same result, which I assume is
incorrect for a triangular workflow?
Please let me know if I've missed out important information by
mistake. I'm happy to work on a patch if given guidance, but this is
definitely outside my comfort zone for an unfamiliar codebase
otherwise! e.g. I can't find the test suite.
Cheers,
Chris
^ permalink raw reply
* Re: [PATCH] transport: add core.allowProtocol config option
From: Jeff King @ 2016-11-03 14:38 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Brandon Williams, git, Stefan Beller, Blake Burkhart
In-Reply-To: <20161103002225.GA13369@google.com>
On Wed, Nov 02, 2016 at 05:22:25PM -0700, Jonathan Nieder wrote:
> Another difficulty with setting GIT_ALLOW_PROTOCOL globally is that it
> requires copy/pasting the default value from upstream and then adding
> the values I want. There's no straightforward way to get the current
> value and add to it, in case I want to benefit from future upstream
> fixes to the default list.
I agree that this is a big drawback of the current scheme, and it would
be nice to be able to say "also allow".
> That is, would it be possible to use something like
>
> [protocol "sso"]
> allow = always
>
> instead of
>
> [core]
> allowProtocol = file:git:http:https:....:sso
>
> ?
One complication is that the whitelist has multiple states:
1. if it's not used at all, anything goes
2. if it exists and has zero or more entries, only those entries are
allowed
And then submodules are an exception to (1), because it's not anything
goes. It's "this default safe whitelist".
So when does protocol.sso.allow kick in? We wouldn't want it to trigger
case (2) for things like fetch (disabling other non-allowed protocols).
Nor do I think we'd only want it for the submodule case, as I would
assume that "protocol.sso.allow = false" should disable it.
So I think this probably needs to be a separate parallel system where
each protocol can be white- or black-listed in a context-specific way.
Like:
protocol.X.allow = always | user | never
Where "user" specifies that the protocol is OK coming directly from the
user, but not from other sources. And we default known-common-and-good
ones like protocol.http.allow to "always", unknown ones (like "foo"
which runs "remote-foo") to "user"), and possibly known-scary ones like
"ext") to "never".
Then we need some way of telling git "you are in a context where the URL
parameter is not coming from the user". Probably via the environment in
GIT_PROTOCOL_FROM_USER or similar. Which git-submodule would sent when
recursing clones, along with things like "go get".
In other words, stop asking git-submodule or "go get" to specify policy,
and let them specify context that can be used to implement policy that
the user specifies (and have git provide a sane default policy).
I think this would all take a backseat to GIT_ALLOW_PROTOCOL, for
backwards compatibility, and then GIT_ALLOW_PROTOCOL could slowly die
off over time.
> That reminds me: external tools also set GIT_ALLOW_PROTOCOL when the
> user hasn't set it explicitly, like git-submodule.sh does. E.g.
> repo <https://gerrit.googlesource.com/git-repo/+/466b8c4e/git_command.py#171>,
> mercurial <https://www.mercurial-scm.org/repo/hg/file/b032a7b676c6/mercurial/subrepo.py#l1404>.
> Other external tools consume GIT_ALLOW_PROTOCOL, like 'go get'
> <https://go.googlesource.com/go/+/55620a0e/src/cmd/go/vcs.go#64>.
> Can we make it more convenient for them to support this configuration
> too?
I think under my proposal above this ugliness just goes away, as all
they have to do is say "trust my URLs less; they come from an automated
source" without specifying policy themselves.
But we may still want...
> An example approach would be a GIT_ALLOW_PROTOCOL var returned by
> "git var".
>
> That way git-submodule.sh could do
>
> : ${GIT_ALLOW_PROTOCOL=$(git var GIT_ALLOW_PROTOCOL)}
>
> and it would just work. Other tools could do the same, with a
> fallback to the current default until new enough git is in widespread
> use.
...some automated way to say "is this protocol supported"? I think it is
not just "give me ALLOW_PROTOCOL" anymore, though, but "apply your rules
to this protocol, and tell me if it is supported".
I don't think things like "go get" would need it, but you would if you
had a porcelain built around git that was accessing a URL _not_ via
git-fetch, but wanted to apply git's rules. That could come as a step 2
later, though.
-Peff
^ permalink raw reply
* Re: [PATCH v1 00/19] Add configuration options for split-index
From: Christian Couder @ 2016-11-03 14:34 UTC (permalink / raw)
To: Duy Nguyen
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <CACsJy8Be-_n_5Aen2-7sod=wkCbXCGxoakf_H-1Cfb4Mg=T9QA@mail.gmail.com>
On Tue, Oct 25, 2016 at 12:52 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
> <christian.couder@gmail.com> wrote:
>> Goal
>> ~~~~
>>
>> We want to make it possible to use the split-index feature
>> automatically by just setting a new "core.splitIndex" configuration
>> variable to true.
>
> Thanks. This definitely should help make split index a lot more
> convenient for day-to-day use. The series looks ok (well, except the
> pruning logic being discussed elsewhere in this thread, but I still
> think it's a good strategy).
Thanks for your review.
>> This can be valuable as split-index can help significantly speed up
>> `git rebase` especially along with the work to libify `git apply`
>> that has been recently merged to master
>> (see https://github.com/git/git/commit/81358dc238372793b1590efa149cc1581d1fbd98).
>
> I remember this. Since the apply libification work has landed, we can
> now think about not writing index out after every apply step, which
> gives the same (or more) speed up without the complication of
> split-index. But if split-index is good enough for you, we can leave
> it for another time.
Yeah, I think they are separate things that can be done.
When people do a lot of small rebases for example, then split-index
will speed up all the index writing, including the index writing at
the end of each rebase.
^ permalink raw reply
* Re: send-email garbled header with trailing doublequote in email
From: demerphq @ 2016-11-03 14:33 UTC (permalink / raw)
To: Jeff King; +Cc: Andrea Arcangeli, Git
In-Reply-To: <20161103141848.42pg6iow24prign5@sigill.intra.peff.net>
On 3 November 2016 at 15:18, Jeff King <peff@peff.net> wrote:
> On Wed, Nov 02, 2016 at 11:29:01PM +0100, Andrea Arcangeli wrote:
>
>> So this must be postfix then that out of the blue decided to garble it
>> in a strange way while parsing the input... The removal of all
>> whitespaces s/what ever/whatever/ especially I've no idea how it
>> decided to do so.
>>
>> Can you reproduce with postfix as sendmail at least? If you can
>> reproduce also see what happens if you add another --to.
>
> Yes, I can easily reproduce without using git at all by installing
> postfix in local-delivery mode and running:
>
> sendmail peff@sigill.intra.peff.net <<\EOF
> From: Jeff King <peff@peff.net>
> To: "what ever" " <peff@sigill.intra.peff.net>
> Subject: patch
>
> This is the body
> EOF
>
> Many MTAs do this kind of header-rewriting. I don't necessarily agree
> with it as a general concept, but the real problem is the syntactically
> bogus header. The munging that postfix does makes things worse, but I
> can see why it is confused and does what it does (the whole email is
> inside a double-quoted portion that is never closed, so it probably
> thinks there is no hostname portion at all).
>
> So git is possibly at fault for passing along a bogus address. OTOH, the
> user is perhaps at fault for providing the bogus address to git in the
> first place. GIGO. :)
>
> I think if any change were to be made, it would be to recognize this
> bogosity and either clean it up or abort. That ideally would happen via
> Mail::Address so git does not have to add a bunch of ad-hoc "is this
> valid rfc822" checks. Reading the manpage for that module, though, it
> says:
>
> [we do not handle all of rfc2822]
> Often requests are made to the maintainers of this code improve this
> situation, but this is not a good idea, where it will break zillions
> of existing applications. If you wish for a fully RFC2822 compliant
> implementation you may take a look at Mail::Message::Field::Full, part
> of MailBox.
>
> So it's possible that switching to a more robust module would improve
> things.
There is an RFC2822 compliant email address validator in the perl test
suite if you guys want to use it. We use it to test recursive
patterns.
http://perl5.git.perl.org/perl.git/blob/HEAD:/t/re/reg_email.t
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2016, #09; Mon, 31)
From: Lars Schneider @ 2016-11-03 14:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Torsten Bögershausen, Junio C Hamano, git
In-Reply-To: <73aed2a3-f2ad-ecc2-d43c-86b4a110a970@kdbg.org>
> On 2 Nov 2016, at 17:43, Johannes Sixt <j6t@kdbg.org> wrote:
>
> Am 02.11.2016 um 18:04 schrieb Torsten Bögershausen:
>>> * ls/filter-process (2016-10-17) 14 commits
>>> (merged to 'next' on 2016-10-19 at ffd0de042c)
>>
>> Some (late, as I recently got a new battery for the Mac OS 10.6 test system)
>> comments:
>> t0021 failes here:
>>
>>
>> Can't locate object method "flush" via package "IO::Handle" at /Users/tb/projects/git/git.next/t/t0021/rot13-filter.pl line 90.
>> fatal: The remote end hung up unexpectedly
>>
>>
>> perl itself is 5.10 and we use the one shipped with Mac OS.
>> Why that ?
>> t0021 uses the hard-coded path:
>> t0021/rot13-filter.pl (around line 345) and the nice macro
>> PERL_PATH from the Makefile is fully ignored.
>>
>> Commenting out the different "flush" makes the test hang, and I haven't digged further.
>>
>
> https://public-inbox.org/git/e8deda5f-11a6-1463-4fc5-25454084ccb1@kdbg.org/
Woooh. I am sorry Hannes - I completely missed that email! Looks like Peff addressed the issue already. His patches look very good but I want to try it on my machine tomorrow.
Thanks,
Lars
^ permalink raw reply
* Re: send-email garbled header with trailing doublequote in email
From: Jeff King @ 2016-11-03 14:18 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: git
In-Reply-To: <20161102222901.GK4611@redhat.com>
On Wed, Nov 02, 2016 at 11:29:01PM +0100, Andrea Arcangeli wrote:
> So this must be postfix then that out of the blue decided to garble it
> in a strange way while parsing the input... The removal of all
> whitespaces s/what ever/whatever/ especially I've no idea how it
> decided to do so.
>
> Can you reproduce with postfix as sendmail at least? If you can
> reproduce also see what happens if you add another --to.
Yes, I can easily reproduce without using git at all by installing
postfix in local-delivery mode and running:
sendmail peff@sigill.intra.peff.net <<\EOF
From: Jeff King <peff@peff.net>
To: "what ever" " <peff@sigill.intra.peff.net>
Subject: patch
This is the body
EOF
Many MTAs do this kind of header-rewriting. I don't necessarily agree
with it as a general concept, but the real problem is the syntactically
bogus header. The munging that postfix does makes things worse, but I
can see why it is confused and does what it does (the whole email is
inside a double-quoted portion that is never closed, so it probably
thinks there is no hostname portion at all).
So git is possibly at fault for passing along a bogus address. OTOH, the
user is perhaps at fault for providing the bogus address to git in the
first place. GIGO. :)
I think if any change were to be made, it would be to recognize this
bogosity and either clean it up or abort. That ideally would happen via
Mail::Address so git does not have to add a bunch of ad-hoc "is this
valid rfc822" checks. Reading the manpage for that module, though, it
says:
[we do not handle all of rfc2822]
Often requests are made to the maintainers of this code improve this
situation, but this is not a good idea, where it will break zillions
of existing applications. If you wish for a fully RFC2822 compliant
implementation you may take a look at Mail::Message::Field::Full, part
of MailBox.
So it's possible that switching to a more robust module would improve
things.
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] submodule-config: rename commit_sha1 to commit_or_tree
From: Jacob Keller @ 2016-11-03 5:36 UTC (permalink / raw)
To: Stefan Beller; +Cc: Junio C Hamano, bmwill, Git mailing list
In-Reply-To: <20161102231722.15787-3-sbeller@google.com>
On Wed, Nov 2, 2016 at 4:17 PM, Stefan Beller <sbeller@google.com> wrote:
> -`const struct submodule *submodule_from_path(const unsigned char *commit_sha1, const char *path)`::
> +`const struct submodule *submodule_from_path(const unsigned char *commit_or_tree, const char *path)`::
>
> Lookup values for one submodule by its commit_sha1 and path.
>
Update the doc text here as well?
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH] transport: add core.allowProtocol config option
From: Junio C Hamano @ 2016-11-03 2:44 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Brandon Williams, git, Stefan Beller, Blake Burkhart, Jeff King
In-Reply-To: <20161103002225.GA13369@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> That is, would it be possible to use something like
>
> [protocol "sso"]
> allow = always
>
> instead of
>
> [core]
> allowProtocol = file:git:http:https:....:sso
>
> ?
That sounds like quite a large usability improvement to me.
^ permalink raw reply
* [PATCH v2] transport: add core.allowProtocol config option
From: Brandon Williams @ 2016-11-03 0:50 UTC (permalink / raw)
To: git; +Cc: Brandon Williams, sbeller, bburky, peff, jrnieder
In-Reply-To: <1478125247-62372-1-git-send-email-bmwill@google.com>
Add configuration option 'core.allowProtocol' to allow users to create a
whitelist of allowed protocols for fetch/push/clone in their gitconfig.
For git-submodule.sh, fallback to default whitelist only if the user
hasn't explicitly set `GIT_ALLOW_PROTOCOL` or doesn't have a whitelist
in their gitconfig.
Signed-off-by: Brandon Williams <bmwill@google.com>
---
Documentation/config.txt | 8 ++++++++
Documentation/git.txt | 6 ++++--
git-submodule.sh | 3 ++-
t/lib-proto-disable.sh | 27 +++++++++++++++++++++++++++
t/t5815-submodule-protos.sh | 22 ++++++++++++++++++++++
transport.c | 6 ++++++
6 files changed, 69 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 27069ac..78c97e3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -455,6 +455,14 @@ core.sshCommand::
the `GIT_SSH_COMMAND` environment variable and is overridden
when the environment variable is set.
+core.allowProtocol::
+ Provide a colon-separated list of protocols which are allowed to be
+ used with fetch/push/clone. Any protocol not mentioned will be
+ disallowed (i.e., this is a whitelist, not a blacklist). If the
+ `GIT_ALLOW_PROTOCOL` environment variable is set, it is used as the
+ protocol whitelist instead of this config option. If neither is set,
+ all protocols are enabled. See git(1) for more details.
+
core.ignoreStat::
If true, Git will avoid using lstat() calls to detect if files have
changed by setting the "assume-unchanged" bit for those tracked files
diff --git a/Documentation/git.txt b/Documentation/git.txt
index ab7215e..a86ec16 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -1155,8 +1155,10 @@ of clones and fetches.
restrict recursive submodule initialization from an untrusted
repository. Any protocol not mentioned will be disallowed (i.e.,
this is a whitelist, not a blacklist). If the variable is not
- set at all, all protocols are enabled. The protocol names
- currently used by git are:
+ set at all, all protocols are enabled. The exception to this is when
+ running `git-submodule` which will use a default list of known-safe
+ protocols (file:git:http:https:ssh) in the event no whitelist is
+ provided. The protocol names currently used by git are:
- `file`: any local file-based path (including `file://` URLs,
or local paths)
diff --git a/git-submodule.sh b/git-submodule.sh
index a024a13..bfbfb8e 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -27,7 +27,8 @@ cd_to_toplevel
#
# If the user has already specified a set of allowed protocols,
# we assume they know what they're doing and use that instead.
-: ${GIT_ALLOW_PROTOCOL=file:git:http:https:ssh}
+whitelist=$(git config core.allowProtocol) || whitelist=file:git:http:https:ssh
+: ${GIT_ALLOW_PROTOCOL=$whitelist}
export GIT_ALLOW_PROTOCOL
command=
diff --git a/t/lib-proto-disable.sh b/t/lib-proto-disable.sh
index b0917d9..e8820a6 100644
--- a/t/lib-proto-disable.sh
+++ b/t/lib-proto-disable.sh
@@ -62,6 +62,33 @@ test_proto () {
test_must_fail git clone --bare "$url" tmp.git
)
'
+
+ # Run tests again using the gitconfig method for setting a whitelist
+ test_expect_success "clone $1 (enabled)" '
+ rm -rf tmp.git &&
+ git -c core.allowProtocol="$proto" clone --bare "$url" tmp.git
+ '
+
+ test_expect_success "fetch $1 (enabled)" '
+ git -C tmp.git -c core.allowProtocol="$proto" fetch
+ '
+
+ test_expect_success "push $1 (enabled)" '
+ git -C tmp.git -c core.allowProtocol="$proto" push origin HEAD:pushed
+ '
+
+ test_expect_success "push $1 (disabled)" '
+ test_must_fail git -C tmp.git -c core.allowProtocol=none push origin HEAD:pushed
+ '
+
+ test_expect_success "fetch $1 (disabled)" '
+ test_must_fail git -C tmp.git -c core.allowProtocol=none fetch
+ '
+
+ test_expect_success "clone $1 (disabled)" '
+ rm -rf tmp.git &&
+ test_must_fail git -C tmp.git -c core.allowProtocol=none clone --bare "$url" tmp.git
+ '
}
# set up an ssh wrapper that will access $host/$repo in the
diff --git a/t/t5815-submodule-protos.sh b/t/t5815-submodule-protos.sh
index 06f55a1..f85e71c 100755
--- a/t/t5815-submodule-protos.sh
+++ b/t/t5815-submodule-protos.sh
@@ -40,4 +40,26 @@ test_expect_success 'user can override whitelist' '
GIT_ALLOW_PROTOCOL=ext git -C dst submodule update ext-module
'
+test_expect_success 'reset dst repo for config tests' '
+ rm -rf dst &&
+ git clone . dst &&
+ git -C dst submodule init
+'
+
+test_expect_success 'update of ssh not allowed when not in config whitelist' '
+ test_must_fail git -C dst -c core.allowProtocol=none submodule update ssh-module
+'
+
+test_expect_success 'update of ssh allowed via config whitelist' '
+ git -C dst -c core.allowProtocol="ssh:http:https" submodule update ssh-module
+'
+
+test_expect_success 'update of ext not allowed' '
+ test_must_fail git -C dst -c core.allowProtocol=ssh submodule update ext-module
+'
+
+test_expect_success 'user can override whitelist' '
+ git -C dst -c core.allowProtocol=ext submodule update ext-module
+'
+
test_done
diff --git a/transport.c b/transport.c
index d57e8de..e3d8e88 100644
--- a/transport.c
+++ b/transport.c
@@ -652,10 +652,16 @@ static const struct string_list *protocol_whitelist(void)
if (enabled < 0) {
const char *v = getenv("GIT_ALLOW_PROTOCOL");
+ char *w = NULL;
if (v) {
string_list_split(&allowed, v, ':', -1);
string_list_sort(&allowed);
enabled = 1;
+ } else if (!git_config_get_string("core.allowProtocol", &w)) {
+ string_list_split(&allowed, w, ':', -1);
+ string_list_sort(&allowed);
+ enabled = 1;
+ free(w);
} else {
enabled = 0;
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox