subject:"Bug Report"

On Tue, 2018-12-04 at 13:01 +0100, Christian Couder wrote:
> To debug I think it would be interesting to see the output of the
> following commands just before we get different results:
> 
> git for-each-ref 'refs/bisect/*'
> 
> and
> 
> git log -1 --format=oneline
> 

I placed the following snippet at the end of the loop in bisect_replay():
echo "COMMAND: '$git' '$bisect' '$command' '$rev'"  
git for-each-ref 'refs/bisect/*'
echo "current HEAD: $(git log -1 --format=oneline)"
echo "---"

$ env GIT_TRACE=0 git bisect replay /var/tmp/git-bisect.log 

We are not bisecting.
COMMAND: 'git' 'bisect' 'start' ''
current HEAD: 2595646791c319cadfdbf271563aac97d0843dc7 Linux 4.20-rc5
---
COMMAND: 'git' 'bisect' 'bad' '5b394b2ddf0347bef56e50c69a58773c94343ff3'
5b394b2ddf0347bef56e50c69a58773c94343ff3 commit refs/bisect/bad
current HEAD: 2595646791c319cadfdbf271563aac97d0843dc7 Linux 4.20-rc5
---
COMMAND: 'git' 'bisect' 'good' '94710cac0ef4ee177a63b5227664b38c95bbf703'
5b394b2ddf0347bef56e50c69a58773c94343ff3 commit refs/bisect/bad
94710cac0ef4ee177a63b5227664b38c95bbf703 commit 
refs/bisect/good-94710cac0ef4ee177a63b5227664b38c95bbf703
current HEAD: 2595646791c319cadfdbf271563aac97d0843dc7 Linux 4.20-rc5
---
COMMAND: 'git' 'bisect' 'bad' '54dbe75bbf1e189982516de179147208e90b5e45'
54dbe75bbf1e189982516de179147208e90b5e45 commit refs/bisect/bad
94710cac0ef4ee177a63b5227664b38c95bbf703 commit 
refs/bisect/good-94710cac0ef4ee177a63b5227664b38c95bbf703
current HEAD: 2595646791c319cadfdbf271563aac97d0843dc7 Linux 4.20-rc5
---
COMMAND: 'git' 'bisect' 'bad' '0a957467c5fd46142bc9c52758ffc552d4c5e2f7'
0a957467c5fd46142bc9c52758ffc552d4c5e2f7 commit refs/bisect/bad
94710cac0ef4ee177a63b5227664b38c95bbf703 commit 
refs/bisect/good-94710cac0ef4ee177a63b5227664b38c95bbf703
current HEAD: 2595646791c319cadfdbf271563aac97d0843dc7 Linux 4.20-rc5
---
COMMAND: 'git' 'bisect' 'good' '958f338e96f874a0d29442396d6adf9c1e17aa2d'
0a957467c5fd46142bc9c52758ffc552d4c5e2f7 commit refs/bisect/bad
94710cac0ef4ee177a63b5227664b38c95bbf703 commit 
refs/bisect/good-94710cac0ef4ee177a63b5227664b38c95bbf703
958f338e96f874a0d29442396d6adf9c1e17aa2d commit 
refs/bisect/good-958f338e96f874a0d29442396d6adf9c1e17aa2d
current HEAD: 2595646791c319cadfdbf271563aac97d0843dc7 Linux 4.20-rc5
---
COMMAND: 'git' 'bisect' 'bad' '2c20443ec221dcb76484b30933593e8ecd836bbd'
2c20443ec221dcb76484b30933593e8ecd836bbd commit refs/bisect/bad
94710cac0ef4ee177a63b5227664b38c95bbf703 commit 
refs/bisect/good-94710cac0ef4ee177a63b5227664b38c95bbf703
958f338e96f874a0d29442396d6adf9c1e17aa2d commit 
refs/bisect/good-958f338e96f874a0d29442396d6adf9c1e17aa2d
current HEAD: 2595646791c319cadfdbf271563aac97d0843dc7 Linux 4.20-rc5
---
COMMAND: 'git' 'bisect' 'bad' 'c2fc71c9b74c1e87336a27dba1a5edc69d2690f1'
c2fc71c9b74c1e87336a27dba1a5edc69d2690f1 commit refs/bisect/bad
94710cac0ef4ee177a63b5227664b38c95bbf703 commit 
refs/bisect/good-94710cac0ef4ee177a63b5227664b38c95bbf703
958f338e96f874a0d29442396d6adf9c1e17aa2d commit 
refs/bisect/good-958f338e96f874a0d29442396d6adf9c1e17aa2d
current HEAD: 2595646791c319cadfdbf271563aac97d0843dc7 Linux 4.20-rc5
---
COMMAND: 'git' 'bisect' 'bad' 'b86d865cb1cae1e61527ea0b8977078bbf694328'
b86d865cb1cae1e61527ea0b8977078bbf694328 commit refs/bisect/bad
94710cac0ef4ee177a63b5227664b38c95bbf703 commit 
refs/bisect/good-94710cac0ef4ee177a63b5227664b38c95bbf703
958f338e96f874a0d29442396d6adf9c1e17aa2d commit 
refs/bisect/good-958f338e96f874a0d29442396d6adf9c1e17aa2d
current HEAD: 2595646791c319cadfdbf271563aac97d0843dc7 Linux 4.20-rc5
---
COMMAND: 'git' 'bisect' 'bad' '1b0d274523df5ef1caedc834da055ff721e4d4f0'
1b0d274523df5ef1caedc834da055ff721e4d4f0 commit refs/bisect/bad
94710cac0ef4ee177a63b5227664b38c95bbf703 commit 
refs/bisect/good-94710cac0ef4ee177a63b5227664b38c95bbf703
958f338e96f874a0d29442396d6adf9c1e17aa2d commit 
refs/bisect/good-958f338e96f874a0d29442396d6adf9c1e17aa2d
current HEAD: 2595646791c319cadfdbf271563aac97d0843dc7 Linux 4.20-rc5
---
Bisecting: a merge base must be tested
[1e4b044d22517cae7047c99038abb23243ca] Linux 4.18-rc4







# I placed git for-each-ref 'refs/bisect/*' after each command in the file:

$ . /var/tmp/git-bisect.log 
5b394b2ddf0347bef56e50c69a58773c94343ff3 commit refs/bisect/bad
Bisecting: 6112 revisions left to test after this (roughly 13 steps)
[54dbe75bbf1e189982516de179147208e90b5e45] Merge tag 'drm-next-2018-08-15' of 
git://anongit.freedesktop.org/drm/drm
5b394b2ddf0347bef56e50c69a58773c94343ff3 commit refs/bisect/bad
94710cac0ef4ee177a63b5227664b38c95bbf703 commit 
refs/bisect/good-94710cac0ef4ee177a63b5227664b38c95bbf703
Bisecting: 3881 revisions left to test after this (roughly 12 steps)
[0a957467c5fd46142bc9c52758ffc552d4c5e2f7] x86: i8259: Add missing include file
54dbe75bbf1e189982516de179147208e90b5e45 commit refs/bisect/bad
94710cac0ef4ee177a63b5227664b38c95bbf703 commit 
refs/bisect/good-94710cac0ef4ee177a63b5227664b38c95bbf703
Bisecting: 1595 revisions left to test after this

Re: [BUG REPORT] Git does not correctly replay bisect log

2018-12-04 Thread Christian Couder

On Tue, Dec 4, 2018 at 12:20 PM Lukáš Krejčí  wrote:
>
> On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote:
> >
> > Could you try to check that? And first could you give us the output of:
> >
> > git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
> > 94710cac0ef4ee177a63b5227664b38c95bbf703
>
> $ git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3 
> 94710cac0ef4ee177a63b5227664b38c95bbf703
> 94710cac0ef4ee177a63b5227664b38c95bbf703
> $ git log -1 --format=oneline 94710cac0ef4ee177a63b5227664b38c95bbf703
> 94710cac0ef4ee177a63b5227664b38c95bbf703 (tag: v4.18) Linux 4.18

94710cac0ef4ee177a63b5227664b38c95bbf703 is the good commit that was
initially given. This means that the good commit
94710cac0ef4ee177a63b5227664b38c95bbf703 is an ancestor of the bad
commit 5b394b2ddf0347bef56e50c69a58773c94343ff3 i and there should be
no reason to test a merge base when replaying.

After testing on my machine, it seems that the problem is not
happening at the beginning of the replay.

To debug I think it would be interesting to see the output of the
following commands just before we get different results:

git for-each-ref 'refs/bisect/*'

and

git log -1 --format=oneline

in the case we are using `git bisect replay` and in the case we are
running the commands from the bisect log manually.

(You might need to temporarily remove the last command from the bisect
log to do that.)

Re: [BUG REPORT] Git does not correctly replay bisect log

(I'm sorry about the formatting, here's the message again.)

Executing git bisect replay reaches a different commit than
the one that is obtained by running the commands from the bisect log manually.

Distribution: Arch Linux
git: 2.19.2-1
perl: 5.28.1-1
pcre2: 10.32-1
expat: 2.2.6-1
perl-error: 0.17027-1
grep: 3.1-2
bash: 4.4.023-1

no system /etc/gitconfig is present
tried with no ~/.gitconfig

$ cat .git/config 
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master

$ git fsck
Checking object directories: 100% (256/256), done.
warning in tag 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c: missingTaggerEntry: 
invalid format - expected 'tagger' line
warning in tag 26791a8bcf0e6d33f43aef7682bdb555236d56de: missingTaggerEntry: 
invalid format - expected 'tagger' line
warning in tag 9e734775f7c22d2f89943ad6c745571f1930105f: missingTaggerEntry: 
invalid format - expected 'tagger' line
warning in tag 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a: missingTaggerEntry: 
invalid format - expected 'tagger' line
warning in tag ebb5573ea8beaf000d4833735f3e53acb9af844c: missingTaggerEntry: 
invalid format - expected 'tagger' line
warning in tag 06f6d9e2f140466eeb41e494e14167f90210f89d: missingTaggerEntry: 
invalid format - expected 'tagger' line
warning in tag 701d7ecec3e0c6b4ab9bb824fd2b34be4da63b7e: missingTaggerEntry: 
invalid format - expected 'tagger' line
warning in tag 733ad933f62e82ebc92fed988c7f0795e64dea62: missingTaggerEntry: 
invalid format - expected 'tagger' line
warning in tag c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19: missingTaggerEntry: 
invalid format - expected 'tagger' line
warning in tag a339981ec18d304f9efeb9ccf01b1f04302edf32: missingTaggerEntry: 
invalid format - expected 'tagger' line
Checking objects: 100% (6428247/6428247), done.
Checking connectivity: 6369862, done.

$ cat /var/tmp/git-bisect.log
git bisect start
# bad: [5b394b2ddf0347bef56e50c69a58773c94343ff3] Linux 4.19-rc1
git bisect bad 5b394b2ddf0347bef56e50c69a58773c94343ff3
# good: [94710cac0ef4ee177a63b5227664b38c95bbf703] Linux 4.18
git bisect good 94710cac0ef4ee177a63b5227664b38c95bbf703
# bad: [54dbe75bbf1e189982516de179147208e90b5e45] Merge tag 
'drm-next-2018-08-15' of git://anongit.freedesktop.org/drm/drm
git bisect bad 54dbe75bbf1e189982516de179147208e90b5e45
# bad: [0a957467c5fd46142bc9c52758ffc552d4c5e2f7] x86: i8259: Add missing 
include file
git bisect bad 0a957467c5fd46142bc9c52758ffc552d4c5e2f7
# good: [958f338e96f874a0d29442396d6adf9c1e17aa2d] Merge branch 'l1tf-final' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 958f338e96f874a0d29442396d6adf9c1e17aa2d
# bad: [2c20443ec221dcb76484b30933593e8ecd836bbd] Merge tag 'acpi-4.19-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 2c20443ec221dcb76484b30933593e8ecd836bbd
# bad: [c2fc71c9b74c1e87336a27dba1a5edc69d2690f1] Merge tag 'mtd/for-4.19' of 
git://git.infradead.org/linux-mtd
git bisect bad c2fc71c9b74c1e87336a27dba1a5edc69d2690f1
# bad: [b86d865cb1cae1e61527ea0b8977078bbf694328] blkcg: Make 
blkg_root_lookup() work for queues in bypass mode
git bisect bad b86d865cb1cae1e61527ea0b8977078bbf694328
# bad: [1b0d274523df5ef1caedc834da055ff721e4d4f0] nvmet: don't use uuid_le type
git bisect bad 1b0d274523df5ef1caedc834da055ff721e4d4f0

$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

$ git log -1 --format=oneline
2595646791c319cadfdbf271563aac97d0843dc7 (HEAD -> master, tag: v4.20-rc5, 
origin/master, origin/HEAD) Linux 4.20-rc5

$ git bisect replay /var/tmp/git-bisect.log 
We are not bisecting.
Bisecting: a merge base must be tested
[d72e90f33aa4709ebecc5005562f52335e106a60] Linux 4.18-rc6

$ git log -1 --format=oneline
d72e90f33aa4709ebecc5005562f52335e106a60 (HEAD, tag: v4.18-rc6) Linux 4.18-rc6





# Running the commands from the bisect log manually, however:

$ git bisect reset
Checking out files: 100% (18326/18326), done.
Previous HEAD position was d72e90f33aa4 Linux 4.18-rc6
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

$ . /var/tmp/git-bisect.log 
Bisecting: 6112 revisions left to test after this (roughly 13 steps)
[54dbe75bbf1e189982516de179147208e90b5e45] Merge tag 'drm-next-2018-08-15' of 
git://anongit.freedesktop.org/drm/drm
Bisecting: 3881 revisions left to test after this (roughly 12 steps)
[0a957467c5fd46142bc9c52758ffc552d4c5e2f7] x86: i8259: Add missing include file
Bisecting: 1595 revisions left to test after this (roughly 11 steps)
[958f338e96f874a0d29442396d6adf9c1e17aa2d] Merge branch 'l1tf-final' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Bisecting: 854 revisions left to test after this (roughly 10

Re: [BUG REPORT] Git does not correctly replay bisect log

On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote:
> 
> Could you try to check that? And first could you give us the output of:
> 
> git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
> 94710cac0ef4ee177a63b5227664b38c95bbf703

$ git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3 
94710cac0ef4ee177a63b5227664b38c95bbf703
94710cac0ef4ee177a63b5227664b38c95bbf703
$ git log -1 --format=oneline 94710cac0ef4ee177a63b5227664b38c95bbf703
94710cac0ef4ee177a63b5227664b38c95bbf703 (tag: v4.18) Linux 4.18

Re: [BUG REPORT] Git does not correctly replay bisect log

2018-12-04 Thread Christian Couder

On Tue, Dec 4, 2018 at 10:53 AM Lukáš Krejčí  wrote:
>
> Executing git bisect replay reaches a different commit than
> the one that is obtained by running the commands from the bisect log manually.

> $ git bisect replay /var/tmp/git-bisect.log
> We are not bisecting.
> Bisecting: a merge base must be tested
> [d72e90f33aa4709ebecc5005562f52335e106a60] Linux 4.18-rc6

Merge bases are tested only when the good commit is not an ancestor of
the bad commit. If this didn't happen when the log was recorded, it
shouldn't happen when it is replayed.

Here it seems that this is happening at the beginning of the replay.
Perhaps git bisect replay is taking into account the current
branch/commit though it shouldn't.

I wonder if this would happen if the current branch/commit has the
good commit as an ancestor.

Could you try to check that? And first could you give us the output of:

git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
94710cac0ef4ee177a63b5227664b38c95bbf703

[BUG REPORT] Git does not correctly replay bisect log

Executing git bisect replay reaches a different commit than
the one that is obtained by running the commands from the bisect log manually.

Distribution: Arch Linux
git: 2.19.2-1
perl: 5.28.1-1
pcre2: 10.32-1
expat: 2.2.6-1
perl-error: 0.17027-1
grep: 3.1-2
bash: 4.4.023-1

no system /etc/gitconfig is present
tried with no ~/.gitconfig

$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master

$ git fsck
Checking object directories: 100% (256/256), done.
warning in tag 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c:
missingTaggerEntry: invalid format - expected 'tagger' line
warning in tag 26791a8bcf0e6d33f43aef7682bdb555236d56de:
missingTaggerEntry: invalid format - expected 'tagger' line
warning in tag 9e734775f7c22d2f89943ad6c745571f1930105f:
missingTaggerEntry: invalid format - expected 'tagger' line
warning in tag 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a:
missingTaggerEntry: invalid format - expected 'tagger' line
warning in tag ebb5573ea8beaf000d4833735f3e53acb9af844c:
missingTaggerEntry: invalid format - expected 'tagger' line
warning in tag 06f6d9e2f140466eeb41e494e14167f90210f89d:
missingTaggerEntry: invalid format - expected 'tagger' line
warning in tag 701d7ecec3e0c6b4ab9bb824fd2b34be4da63b7e:
missingTaggerEntry: invalid format - expected 'tagger' line
warning in tag 733ad933f62e82ebc92fed988c7f0795e64dea62:
missingTaggerEntry: invalid format - expected 'tagger' line
warning in tag c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19:
missingTaggerEntry: invalid format - expected 'tagger' line
warning in tag a339981ec18d304f9efeb9ccf01b1f04302edf32:
missingTaggerEntry: invalid format - expected 'tagger' line
Checking objects: 100% (6428247/6428247), done.
Checking connectivity: 6369862, done.

$ cat /var/tmp/git-bisect.log
git bisect start
# bad: [5b394b2ddf0347bef56e50c69a58773c94343ff3] Linux 4.19-rc1
git bisect bad 5b394b2ddf0347bef56e50c69a58773c94343ff3
# good: [94710cac0ef4ee177a63b5227664b38c95bbf703] Linux 4.18
git bisect good 94710cac0ef4ee177a63b5227664b38c95bbf703
# bad: [54dbe75bbf1e189982516de179147208e90b5e45] Merge tag
'drm-next-2018-08-15' of git://anongit.freedesktop.org/drm/drm
git bisect bad 54dbe75bbf1e189982516de179147208e90b5e45
# bad: [0a957467c5fd46142bc9c52758ffc552d4c5e2f7] x86: i8259: Add
missing include file
git bisect bad 0a957467c5fd46142bc9c52758ffc552d4c5e2f7
# good: [958f338e96f874a0d29442396d6adf9c1e17aa2d] Merge branch
'l1tf-final' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 958f338e96f874a0d29442396d6adf9c1e17aa2d
# bad: [2c20443ec221dcb76484b30933593e8ecd836bbd] Merge tag
'acpi-4.19-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 2c20443ec221dcb76484b30933593e8ecd836bbd
# bad: [c2fc71c9b74c1e87336a27dba1a5edc69d2690f1] Merge tag
'mtd/for-4.19' of git://git.infradead.org/linux-mtd
git bisect bad c2fc71c9b74c1e87336a27dba1a5edc69d2690f1
# bad: [b86d865cb1cae1e61527ea0b8977078bbf694328] blkcg: Make
blkg_root_lookup() work for queues in bypass mode
git bisect bad b86d865cb1cae1e61527ea0b8977078bbf694328
# bad: [1b0d274523df5ef1caedc834da055ff721e4d4f0] nvmet: don't use uuid_le type
git bisect bad 1b0d274523df5ef1caedc834da055ff721e4d4f0

$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

$ git log -1 --format=oneline
2595646791c319cadfdbf271563aac97d0843dc7 (HEAD -> master, tag:
v4.20-rc5, origin/master, origin/HEAD) Linux 4.20-rc5

$ git bisect replay /var/tmp/git-bisect.log
We are not bisecting.
Bisecting: a merge base must be tested
[d72e90f33aa4709ebecc5005562f52335e106a60] Linux 4.18-rc6

$ git log -1 --format=oneline
d72e90f33aa4709ebecc5005562f52335e106a60 (HEAD, tag: v4.18-rc6) Linux 4.18-rc6





Running the commands from the bisect log manually, however:

$ git bisect reset
Checking out files: 100% (18326/18326), done.
Previous HEAD position was d72e90f33aa4 Linux 4.18-rc6
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

$ . /var/tmp/git-bisect.log
Bisecting: 6112 revisions left to test after this (roughly 13 steps)
[54dbe75bbf1e189982516de179147208e90b5e45] Merge tag
'drm-next-2018-08-15' of git://anongit.freedesktop.org/drm/drm
Bisecting: 3881 revisions left to test after this (roughly 12 steps)
[0a957467c5fd46142bc9c52758ffc552d4c5e2f7] x86: i8259: Add missing include file
Bisecting: 1595 revisions left to test after this (roughly 11 steps)
[958f338e96f874a0d29442396d6adf9c1e17aa2d] Merge branch 'l1tf-final'
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Bisecting: 854 revisions left to test after this (roughly 10 steps)
[2c20443ec221dcb76484b30933593e8ecd836bbd] Merge tag 'acpi-4.19-rc1'
of

Re: [bug report] git-gui child windows are blank

2018-11-29 Thread Kenn Sebesta

Just checked gitk, it seems to work fine including children windows.
This problem seems to affect git-gui only.
On Thu, Nov 29, 2018 at 5:16 AM Eric Sunshine  wrote:
>
> On Wed, Nov 28, 2018 at 2:29 PM Stefan Beller  wrote:
> > On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta  wrote:
> > > v2.19.2, installed from brew on macOS Mojave 14.2.1.
> > >
> > > `git-gui` is my much beloved go-to tool for everything git.
> > > Unfortunately, on my new Macbook Air it seems to have a bug. When I
> > > first load the program, the parent window populates normally with the
> > > stage/unstaged and diff panes. However, when I click Push, the child
> > > window is completely blank. The frame is there, but there is no
> > > content.
> >
> > Looking through the mailing list archive, this
> > seemed to be one of the last relevant messges
> > https://public-inbox.org/git/20180724065120.7664-1-sunsh...@sunshineco.com/
>
> I was hoping that Junio would patch-monkey that one since that
> crash-at-launch makes gitk unusable for Mojave users, but apparently
> it never got picked up.
>
> Anyhow, the issue fixed by that patch has to do with 'osascript' on
> Apple, and it's the only such invocation in the source code of
> gitk/git-gui. The 'osascript' invocation merely attempts to foreground
> the application at launch, so is almost certainly unrelated to the
> above reported behavior. Somebody running Mojave will likely need to
> spend some time debugging it. (Unfortunately, I'm a couple major
> releases behind and don't plan on upgrading.)

Re: [bug report] git-gui child windows are blank

2018-11-29 Thread Eric Sunshine

On Wed, Nov 28, 2018 at 2:29 PM Stefan Beller  wrote:
> On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta  wrote:
> > v2.19.2, installed from brew on macOS Mojave 14.2.1.
> >
> > `git-gui` is my much beloved go-to tool for everything git.
> > Unfortunately, on my new Macbook Air it seems to have a bug. When I
> > first load the program, the parent window populates normally with the
> > stage/unstaged and diff panes. However, when I click Push, the child
> > window is completely blank. The frame is there, but there is no
> > content.
>
> Looking through the mailing list archive, this
> seemed to be one of the last relevant messges
> https://public-inbox.org/git/20180724065120.7664-1-sunsh...@sunshineco.com/

I was hoping that Junio would patch-monkey that one since that
crash-at-launch makes gitk unusable for Mojave users, but apparently
it never got picked up.

Anyhow, the issue fixed by that patch has to do with 'osascript' on
Apple, and it's the only such invocation in the source code of
gitk/git-gui. The 'osascript' invocation merely attempts to foreground
the application at launch, so is almost certainly unrelated to the
above reported behavior. Somebody running Mojave will likely need to
spend some time debugging it. (Unfortunately, I'm a couple major
releases behind and don't plan on upgrading.)

Re: [BUG REPORT] t5322: demonstrate a pack-objects bug

2018-11-28 Thread Derrick Stolee


On 11/28/2018 2:45 PM, Derrick Stolee wrote:

I was preparing a new "sparse" algorithm for calculating the
interesting objects to send on push. The important steps happen
during 'git pack-objects', so I was creating test cases to see
how the behavior changes in narrow cases. Specifically, when
copying a directory across sibling directories (see test case),
the new logic would accidentally send that object as an extra.

However, I found a bug in the existing logic. The included test
demonstrates this during the final 'git index-pack' call. It
fails with the message

'fatal: pack has 1 unresolved delta'


I realize now that I've gone through this effort that the problem is me 
(of course it is).



+   git pack-objects --stdout --thin --revs nonsparse.pack 
&&


Since I'm packing thin packs, the index operation is complaining about 
deltas. So, I need to use a different mechanism to list the objects in 
the pack (say, 'git verify-pack -v').


Sorry for the noise!

Thanks,

-Stolee

[BUG REPORT] t5322: demonstrate a pack-objects bug

2018-11-28 Thread Derrick Stolee

I was preparing a new "sparse" algorithm for calculating the
interesting objects to send on push. The important steps happen
during 'git pack-objects', so I was creating test cases to see
how the behavior changes in narrow cases. Specifically, when
copying a directory across sibling directories (see test case),
the new logic would accidentally send that object as an extra.

However, I found a bug in the existing logic. The included test
demonstrates this during the final 'git index-pack' call. It
fails with the message

'fatal: pack has 1 unresolved delta'

It is probable that this is not a minimal test case, but happens
to be the test I had created before discovering the problem.

I compiled v2.17.0 and v2.12.0 as checks to see if I could find
a "good" commit with which to start a bisect, but both failed.
This is an old bug!

Signed-off-by: Derrick Stolee 
---
 t/t5322-pack-objects-sparse.sh | 94 ++
 1 file changed, 94 insertions(+)
 create mode 100755 t/t5322-pack-objects-sparse.sh

diff --git a/t/t5322-pack-objects-sparse.sh b/t/t5322-pack-objects-sparse.sh
new file mode 100755
index 00..36faa70fe9
--- /dev/null
+++ b/t/t5322-pack-objects-sparse.sh
@@ -0,0 +1,94 @@
+#!/bin/sh
+
+test_description='pack-objects object selection using sparse algorithm'
+. ./test-lib.sh
+
+test_expect_success 'setup repo' '
+   test_commit initial &&
+   for i in $(test_seq 1 3)
+   do
+   mkdir f$i &&
+   for j in $(test_seq 1 3)
+   do
+   mkdir f$i/f$j &&
+   echo $j >f$i/f$j/data.txt
+   done
+   done &&
+   git add . &&
+   git commit -m "Initialized trees" &&
+   for i in $(test_seq 1 3)
+   do
+   git checkout -b topic$i master &&
+   echo change-$i >f$i/f$i/data.txt &&
+   git commit -a -m "Changed f$i/f$i/data.txt"
+   done &&
+   cat >packinput.txt <<-EOF &&
+   topic1
+   ^topic2
+   ^topic3
+   EOF
+   git rev-parse   \
+   topic1  \
+   topic1^{tree}   \
+   topic1:f1   \
+   topic1:f1/f1\
+   topic1:f1/f1/data.txt | sort >actual_objects.txt
+'
+
+test_expect_success 'non-sparse pack-objects' '
+   git pack-objects --stdout --thin --revs nonsparse.pack 
&&
+   git index-pack -o nonsparse.idx nonsparse.pack &&
+   git show-index nonsparse_objects.txt &&
+   test_cmp actual_objects.txt nonsparse_objects.txt
+'
+
+# Demonstrate that both algorithms send "extra" objects because
+# they are not in the frontier.
+
+test_expect_success 'duplicate a folder from f3 and commit to topic1' '
+   git checkout topic1 &&
+   echo change-3 >f3/f3/data.txt &&
+   git commit -a -m "Changed f3/f3/data.txt" &&
+   git rev-parse   \
+   topic1~1\
+   topic1~1^{tree} \
+   topic1^{tree}   \
+   topic1  \
+   topic1:f1   \
+   topic1:f1/f1\
+   topic1:f1/f1/data.txt   \
+   topic1:f3   \
+   topic1:f3/f3\
+   topic1:f3/f3/data.txt | sort >actual_objects.txt
+'
+
+test_expect_success 'non-sparse pack-objects' '
+   git pack-objects --stdout --thin --revs nonsparse.pack 
&&
+   git index-pack -o nonsparse.idx nonsparse.pack &&
+   git show-index nonsparse_objects.txt &&
+   test_cmp actual_objects.txt nonsparse_objects.txt
+'
+
+test_expect_success 'duplicate a folder from f3 and commit to topic1' '
+   mkdir f3/f4 &&
+   cp -r f1/f1/* f3/f4 &&
+   git add f3/f4 &&
+   git commit -m "Copied f1/f1 to f3/f4" &&
+   cat >packinput.txt <<-EOF &&
+   topic1
+   ^topic1~1
+   EOF
+   git rev-parse   \
+   topic1  \
+   topic1^{tree}   \
+   topic1:f3 | sort >actual_objects.txt
+'
+
+test_expect_success 'non-sparse pack-objects' '
+   git pack-objects --stdout --thin --revs nonsparse.pack 
&&
+   git index-pack -o nonsparse.idx nonsparse.pack &&
+   git show-index nonsparse_objects.txt &&
+   test_cmp actual_objects.txt nonsparse_objects.txt
+'
+
+test_done
-- 
2.20.0.rc1

Re: [bug report] git-gui child windows are blank

2018-11-28 Thread Stefan Beller

On Wed, Nov 28, 2018 at 6:13 AM Kenn Sebesta  wrote:
>
> v2.19.2, installed from brew on macOS Mojave 14.2.1.
>
> `git-gui` is my much beloved go-to tool for everything git.
> Unfortunately, on my new Macbook Air it seems to have a bug. When I
> first load the program, the parent window populates normally with the
> stage/unstaged and diff panes. However, when I click Push, the child
> window is completely blank. The frame is there, but there is no
> content.
>
> This same behavior is seen if I do a `git gui blame`, where the
> primary blame window opens normally but all the children windows are
> empty.
>
> I have googled but was unsuccessful in finding a solution. Is this a
> known issue?

Looking through the mailing list archive, this
seemed to be one of the last relevant messges
https://public-inbox.org/git/20180724065120.7664-1-sunsh...@sunshineco.com/

>
>
> --Kenn

[bug report] git-gui child windows are blank

2018-11-28 Thread Kenn Sebesta

v2.19.2, installed from brew on macOS Mojave 14.2.1.

`git-gui` is my much beloved go-to tool for everything git.
Unfortunately, on my new Macbook Air it seems to have a bug. When I
first load the program, the parent window populates normally with the
stage/unstaged and diff panes. However, when I click Push, the child
window is completely blank. The frame is there, but there is no
content.

This same behavior is seen if I do a `git gui blame`, where the
primary blame window opens normally but all the children windows are
empty.

I have googled but was unsuccessful in finding a solution. Is this a
known issue?


--Kenn

Re: BUG REPORT: git clone of non-existent repository results in request for credentials

2018-11-11 Thread Federico Lucifredi

I was afraid that was the reason. Oh well, at least we know why :-)

Thanks Ævar!

Best-F

> On Nov 11, 2018, at 9:00 AM, Ævar Arnfjörð Bjarmason  wrote:
> 
> 
>> On Sun, Nov 11 2018, Federico Lucifredi wrote:
>> 
>> git clone of non-existent repository results in request for credentials
>> 
>> REPRODUCING:
>> sudo apt install git
>> git clone https://github.com/xorbit/LiFePo4owered-Pi.git#this repo does 
>> not exist
>> 
>> Git will then prompt for username and password on Github.
>> 
>> I can see a valid data-leak concern (one could probe for private repository 
>> names in a brute-force fashion), but then again the UX impact is appalling. 
>> Chances of someone typing an invalid repo name are pretty high, and this 
>> error message has nothing to do with the actual error.
>> 
>> RESOLUTION:
>> The error message should indicate that the repository name does not exist.
> 
> This is a legitimate thing to complain about, but it has nothing to do
> with git itself maintained on this mailing list, but the response codes
> of specific git hosting websites. E.g. here's two issues for fixing this
> on GitLab:
> 
> https://gitlab.com/gitlab-org/gitlab-ce/issues/50201
> https://gitlab.com/gitlab-org/gitlab-ce/issues/50660
> 
> These hosting platforms are intentionally producing bad error messages
> to not leak information, as you note.
> 
> So I doubt it's something they'll ever change, the bug I have open with
> this on GitLab is to make this configurable for privately run instances.
>

Re: BUG REPORT: git clone of non-existent repository results in request for credentials

2018-11-11 Thread Ævar Arnfjörð Bjarmason

On Sun, Nov 11 2018, Federico Lucifredi wrote:

> git clone of non-existent repository results in request for credentials
>
> REPRODUCING:
> sudo apt install git
> git clone https://github.com/xorbit/LiFePo4owered-Pi.git#this repo does 
> not exist
>
> Git will then prompt for username and password on Github.
>
> I can see a valid data-leak concern (one could probe for private repository 
> names in a brute-force fashion), but then again the UX impact is appalling. 
> Chances of someone typing an invalid repo name are pretty high, and this 
> error message has nothing to do with the actual error.
>
> RESOLUTION:
> The error message should indicate that the repository name does not exist.

This is a legitimate thing to complain about, but it has nothing to do
with git itself maintained on this mailing list, but the response codes
of specific git hosting websites. E.g. here's two issues for fixing this
on GitLab:

https://gitlab.com/gitlab-org/gitlab-ce/issues/50201
https://gitlab.com/gitlab-org/gitlab-ce/issues/50660

These hosting platforms are intentionally producing bad error messages
to not leak information, as you note.

So I doubt it's something they'll ever change, the bug I have open with
this on GitLab is to make this configurable for privately run instances.

BUG REPORT: git clone of non-existent repository results in request for credentials

2018-11-11 Thread Federico Lucifredi

git clone of non-existent repository results in request for credentials

REPRODUCING:
sudo apt install git
git clone https://github.com/xorbit/LiFePo4owered-Pi.git#this repo does not 
exist

Git will then prompt for username and password on Github.

I can see a valid data-leak concern (one could probe for private repository 
names in a brute-force fashion), but then again the UX impact is appalling. 
Chances of someone typing an invalid repo name are pretty high, and this error 
message has nothing to do with the actual error.

RESOLUTION:
The error message should indicate that the repository name does not exist. 


Best -F



_
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - flucifredi at acm.org - GnuPG 0x4A73884C

Re: [Bug report] Git incorrectly selects language in macos

2018-09-16 Thread Eric Sunshine

On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus  wrote:
> Looks like the issue appeared after updating git from brew.
>
> A quick search revealed that brew changed how it builds git recently.
> I think, it just didn't include i18n by default before, so I never
> noticed this.
>
> Anybody here familiar enough with the build process and dependencies
> of git to pinpoint what exactly is causing this and how to fix it?...

This problem is not specific to Git. Earlier in the thread, Ævar
asked[1] if the problem also occurs with other command-line programs,
and indeed it does. For instance, I tried with 'wget' installed via
brew, and it exhibits the same odd behavior. Ævar suggested that there
might be some magic special-casing English, which makes me wonder if
brew builds such magic into gettext(?) or if the magic is part of
MacOS itself.

[1]: https://public-inbox.org/git/87a7ojlp31@evledraar.gmail.com/

Re: [Bug report] Git incorrectly selects language in macos

2018-09-14 Thread Niko Dzhus

Looks like the issue appeared after updating git from brew.

I tried it on a different mac laptop, git 2.18 still used English, but
after updating to 2.19 it started using secondary language.

A quick search revealed that brew changed how it builds git recently.
I think, it just didn't include i18n by default before, so I never
noticed this.
Here's the history of formula changes:
https://github.com/Homebrew/homebrew-core/commits/master/Formula/git.rb
Also, I found this thread https://github.com/Homebrew/homebrew-core/issues/31980

Anybody here familiar enough with the build process and dependencies
of git to pinpoint what exactly is causing this and how to fix it?...

On Fri, Sep 14, 2018 at 10:08 PM Niko Dzhus  wrote:
>
> It doesn't use English when other language is available as a secondary 
> language.
>
> Reproducing:
>
> 1. Open "Language & Region" in macos settings
> 2. In "Preferred languages" box, set English as a primary language.
> 3. Add another language, that git is translated to, as a secondary
> language, for example, French or German.
> 4. Run any git command - git will use the secondary language, instead
> of English.
>
> When the secondary language is removed, then git starts using English again.
>
> I have git 2.19.0, installed from brew, and my OS is macOS 10.13.6 .

Re: [Bug report] Git incorrectly selects language in macos

2018-09-14 Thread Niko Dzhus

Tried what you suggested - it seems, it only ignores English. In you
example, with Swedish as primary and German as secondary, git uses
Swedish.

With more that one secondary language, the one with a higher priority
is being used, as expected. I also tried using non-generic English
(English-UK and English-US), but they also get ignored.

Terminal commands return the following:

➜  ~ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
➜  ~ env | grep -e LC -e LANG
LC_CTYPE=UTF-8
➜  ~

It doesn't change with primary/secondary language switching. I don't
have any manual overrides in my .zshrc and .zprofile for those
neither.

On Sat, Sep 15, 2018 at 12:57 AM Ævar Arnfjörð Bjarmason
 wrote:
>
>
> On Fri, Sep 14 2018, Niko Dzhus wrote:
>
> > It doesn't use English when other language is available as a secondary 
> > language.
> >
> > Reproducing:
> >
> > 1. Open "Language & Region" in macos settings
> > 2. In "Preferred languages" box, set English as a primary language.
> > 3. Add another language, that git is translated to, as a secondary
> > language, for example, French or German.
> > 4. Run any git command - git will use the secondary language, instead
> > of English.
> >
> > When the secondary language is removed, then git starts using English again.
> >
> > I have git 2.19.0, installed from brew, and my OS is macOS 10.13.6 .
>
> What's the output of these two commands for you:
>
>  1. locale
>  2. env | grep -e LC -e LANG
>
> We don't do any such magic ourselves, so whatever this is is down to how
> i18n in general works on your system, do you have any other translated
> command-line program that works differently?
>
> I suspect there's some DWYM logic here that always treats English as a
> secondary language.
>
> Do you also e.g. get the same results if you select say Swedish as a
> primary language and German as a secondary? I.e. a Git in German, as
> opposed to Swedish?

Re: [Bug report] Git incorrectly selects language in macos

2018-09-14 Thread Ævar Arnfjörð Bjarmason

On Fri, Sep 14 2018, Niko Dzhus wrote:

> It doesn't use English when other language is available as a secondary 
> language.
>
> Reproducing:
>
> 1. Open "Language & Region" in macos settings
> 2. In "Preferred languages" box, set English as a primary language.
> 3. Add another language, that git is translated to, as a secondary
> language, for example, French or German.
> 4. Run any git command - git will use the secondary language, instead
> of English.
>
> When the secondary language is removed, then git starts using English again.
>
> I have git 2.19.0, installed from brew, and my OS is macOS 10.13.6 .

What's the output of these two commands for you:

 1. locale
 2. env | grep -e LC -e LANG

We don't do any such magic ourselves, so whatever this is is down to how
i18n in general works on your system, do you have any other translated
command-line program that works differently?

I suspect there's some DWYM logic here that always treats English as a
secondary language.

Do you also e.g. get the same results if you select say Swedish as a
primary language and German as a secondary? I.e. a Git in German, as
opposed to Swedish?

[Bug report] Git incorrectly selects language in macos

2018-09-14 Thread Niko Dzhus

It doesn't use English when other language is available as a secondary language.

Reproducing:

1. Open "Language & Region" in macos settings
2. In "Preferred languages" box, set English as a primary language.
3. Add another language, that git is translated to, as a secondary
language, for example, French or German.
4. Run any git command - git will use the secondary language, instead
of English.

When the secondary language is removed, then git starts using English again.

I have git 2.19.0, installed from brew, and my OS is macOS 10.13.6 .

Re: (Bug report + fix) gitk "IgnCase" search doesn't ignore case

2018-06-14 Thread Eric Sunshine

On Thu, Jun 14, 2018 at 02:53:03PM +0200, Juan Navarro wrote:
> Gitk "find commit" search function doesn't follow the "IgnCase" option that
> is selectable with a combo selector on the right side of the window; it
> should be searching in a case-insensitive way, but it doesn't.
> 
> Steps to reproduce:
> [...]
> 3. In the "Find commit" bar, select "changing lines matching"
> 4. In the right side of the same bar, select "IgnCase"
> [...]
> 
> Proposed solution is almost trivial: check if the "IgnCase" option is
> enabled, and in that case add the flag "-i" to the git command. Now that we
> are at it, it's probably correct to add that option to all search modes.
> A diff is attached to this email, hoping that someone is able to apply it
> (sorry I'm not familiarized with contributing with patch files, but the diff
> is pretty small anyways).

Thanks for reporting this.

A different way to interpret the situation is that the user-interface
is being inconsistent. For instance, the "fields" pop-up next to the
"exact/ignore-case/regexp" pop-up does not seem to make sense for
search types other than "containing", so it probably ought to be
disabled for anything other than "containing". By extension, one could
argue that the "exact/ignore-case/regexp" pop-up also ought be
disabled for non-"containing" searches. The fact that they are not
disabled confuses people into thinking that they should be functional
for all searches, not just for "containing" searches, even though such
functionality was never implemented (and indeed, may be difficult to
implement fully).

Your proposed fix handles only the "ignore case" item; it does not
implement "regexp" functionality, so it could be considered
incomplete. A more complete fix would also disable the "regexp" item
to avoid misleading users, and to head off future bug reports similar
to this one saying that "regexp" doesn't work for non-"containing"
searches. (Bonus points for also disabling the "fields" pop-up for
non-"containing" searches when it's not applicable.)

Below is your fix wrapped up as a proper patch and sent in-line rather
than as an attachment. It's also slightly simplified by dropping the
unnecessary extra variable. You'll need to sign-off on the patch if it
is ever to be accepted. You can do so by adding it after my sign-off.
If you don't feel like re-sending the patch with your sign-off, you
can alternately reply to this email with a "Signed-off-by: Your Name
" line.

Note, however, that the gitk project is, at best, deeply slumbering,
so it's not clear when or even if patches will be incorporated.
(Indeed, other recent gitk-related patches sent to the mailing list
have not yet been picked up.)

--- >8 ---
From: Juan Navarro 
Subject: [PATCH] gitk: support "ignore case" for non-"containing" searches

The "Exact/Ignore Case/Regexp" pop-up control only affects "containing"
searches. Other types of searches ("touching paths", "adding/removing
strings", "changing lines matching") ignore this option. Improve the
user experience by also recognizing "ignore case" for non-"containing"
searches.

Note: This change only implements the "ignore case" option for these
other search types; it does not add support for the "regexp" option
(which still only affects "containing" searches). A more complete "fix"
would improve the user experience even more by making the UI more
consistent; namely, by disabling options which don't make sense or are
not easily implemented for non-"containing" searches. In particular, the
"regexp" pop-up item and the neighboring "fields" pop-up control ought
perhaps be disabled when a non-"containing" search is selected.

[es: wrote commit message; slightly simplified proposed "fix"]

Signed-off-by: Eric Sunshine 
---
diff --git a/gitk-git/gitk b/gitk-git/gitk
index a14d7a16b2..fbb75f7390 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -4806,6 +4806,9 @@ proc do_file_hl {serial} {
# must be "containing:", i.e. we're searching commit info
return
 }
+if {$findtype eq [mc "IgnCase"]} {
+   set gdtargs [linsert $gdtargs 0 "-i"]
+}
 set cmd [concat | git diff-tree -r -s --stdin $gdtargs]
 set filehighlight [open $cmd r+]
 fconfigure $filehighlight -blocking 0
-- 
2.18.0.rc1.256.g331a1db143

(Bug report + fix) gitk "IgnCase" search doesn't ignore case

2018-06-14 Thread Juan Navarro


Hi,

this question was originally posted on the Google Groups list, trying to 
get help 
(https://groups.google.com/d/topic/git-users/QAFKOQU4eUo/discussion).
Now that it's confirmed as a bug and I have a proposed solution, I'm 
posting here.


Gitk "find commit" search function doesn't follow the "IgnCase" option 
that is selectable with a combo selector on the right side of the 
window; it should be searching in a case-insensitive way, but it doesn't.


Steps to reproduce:
1. Clone any repo. I'm right now using 
https://github.com/Kurento/kms-core.git 


2. cd into the repo and launch gitk
3. In the "Find commit" bar, select "changing lines matching"
4. In the right side of the same bar, select "IgnCase"
5. Search for a term that you know exists in uppercase, but write the 
search in lowercase. In my example, I'm searching for "leaky_time".

6. No search results appear.
7. Change your search word to uppercase.
8. Some search results appear, thus proving that the search is being 
done case-sensitive.


The command that gets called when searching is in lines 4804 & 4809 
(https://github.com/git/git/blob/master/gitk-git/gitk#L4804 
):

git diff-tree -r -s --stdin -G

Proposed solution is almost trivial: check if the "IgnCase" option is 
enabled, and in that case add the flag "-i" to the git command. Now that 
we are at it, it's probably correct to add that option to all search modes.
A diff is attached to this email, hoping that someone is able to apply 
it (sorry I'm not familiarized with contributing with patch files, but 
the diff is pretty small anyways).


Regards,
Juan
4809c4809,4815
< set cmd [concat | git diff-tree -r -s --stdin $gdtargs]
---
> 
> set igncase_arg ""
> if {$findtype eq [mc "IgnCase"]} {
> set igncase_arg "-i"
> }
> 
> set cmd [concat | git diff-tree $igncase_arg -r -s --stdin $gdtargs]

Re: Bug report for git push

2018-05-12 Thread Jeff King

On Fri, May 11, 2018 at 09:44:54PM -0400, Surenkumar Nihalani wrote:

> Push summary: [remote rejected] (cannot lock ref 'refs/heads/master': is at 
> cf2cc0c147d8215ec87d3ddaf32f0b2c58630423 but expected 
> fdda486ad43a6e6b5dc5f2795ce27124e0686752)

This generally indicates that somebody was pushing at the same time as
you, and you lost the race. The push conversation works basically like
this:

 1. server advertise master at some sha1 (like fdda486ad)

 2. client checks that moving from fdda486ad to whatever the new value is
(let's say 1234abcd) matches its criteria (e.g., not a fast-forward)
and prepares a pack with the appropriate objects

 3. client tells server "update master from fdda486ad to 1234abcd"

 4. server locks master and then under lock checks that it's still at
fdda486ad. In this case it's not, so it aborts the lock. This is
likely due to somebody else pushing in the interim.

If you push again at this point, the client will notice in step that
it's not a fast-forward and give you the "somebody else has pushed, you
need to pull first" error message.

The only difference here is that because of the timing (i.e., somebody
pushing at the exact same time as you), only the server's locking
operation noticed the conflict. But the fix is the same (pull their
work, then push).

-Peff

Bug report for git push

2018-05-11 Thread Surenkumar Nihalani

Hi everyone!

I am facing this spurious issue (not easily reproducible and usually a retry 
fixes it) with git push:

Warning: Permanently added 'github.com,192.30.255.112' (RSA) to the list of 
known hosts.
Counting objects: 8, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 971 bytes | 971.00 KiB/s, done.
Total 8 (delta 7), reused 0 (delta 0)
remote: Resolving deltas:   0% (0/7)
remote: Resolving deltas:  14% (1/7)
remote: Resolving deltas:  28% (2/7)
remote: Resolving deltas:  42% (3/7)
remote: Resolving deltas:  57% (4/7)
remote: Resolving deltas:  71% (5/7)
remote: Resolving deltas:  85% (6/7)
remote: Resolving deltas: 100% (7/7)
remote: Resolving deltas: 100% (7/7), completed with 7 local objects.
error: failed to push some refs to 'g...@github.com:quora/qcore.git'
[May 12 12:14 AM remote._get_push_info] Error lines received while fetching: 
error: failed to push some refs to 'g...@github.com:quora/qcore.git'
Push flags:  1040
Push summary: [remote rejected] (cannot lock ref 'refs/heads/master': is at 
cf2cc0c147d8215ec87d3ddaf32f0b2c58630423 but expected 
fdda486ad43a6e6b5dc5f2795ce27124e0686752)

Remote repo rejected your commit.


This is happening in git version 2.17.0

I've tried searching stack overflow and the git mailing list but the answers 
aren't recent enough or don’t seem to be permanent fixes.
How do I fix this issue?

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

2018-04-30 Thread Elijah Newren

Hi,

On Fri, Apr 27, 2018 at 2:45 PM, Totsten Bögershausen  wrote:
> On 2018-04-26 19:23, Elijah Newren wrote:

>> Sure.  First, though, note that I can make it pass (or at least "not
>> ok...TODO known breakage") with the following patch (may be
>> whitespace-damaged by gmail):
>>
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> index 483c8d6d7..770b91f8c 100644
>> --- a/t/test-lib.sh
>> +++ b/t/test-lib.sh
>> @@ -1106,12 +1106,7 @@ test_lazy_prereq UTF8_NFD_TO_NFC '
>>  auml=$(printf "\303\244")
>>  aumlcdiar=$(printf "\141\314\210")
>>  >"$auml" &&
>> -   case "$(echo *)" in
>> -   "$aumlcdiar")
>> -   true ;;
>> -   *)
>> -   false ;;
>> -   esac
>> +   stat "$aumlcdiar" >/dev/null 2>/dev/null
>
>
> Nicely analyzed and improved.
>
> The "stat" statement is technically correct.
> I think that a more git-style fix would be
> [] ---
> +   test -r "$aumlcdiar"
>
> instead of the stat.
>
> I looked into the 2 known breakages.
> In short: they test use cases which are not sooo important for a user in
> practice, but do a good test if the code is broken.
> IOW: I can't see a need for immediate action.
>
> As you already did all the analyzes:
> Do you want to send a patch ?

You know, despite seeing the "test_expect_failure" and "TODO...known
breakage" with these tests and even mentioning them, it somehow didn't
sink in and I was still thinking that there might be some kind of
unicode normalization handling in the codebase somewhere (similar to
the case insensitivy handling that I've seen in a place or two) that
now needed to be extended.  I should have realized that
test_expect_failure meant there wasn't, and thus all we needed to do
was to mark it as continuing to fail with the new filesystem,  Should
have realized, but didn't.  Oops.

Anyway, it looks like you've already submitted a patch and marked it
as having been reported by me, which is just fine.  Thanks!

Elijah

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

2018-04-27 Thread Totsten Bögershausen




On 2018-04-26 19:23, Elijah Newren wrote:

On Thu, Apr 26, 2018 at 10:13 AM, Torsten Bögershausen  wrote:

Hm,
thanks for the report.
I don't have a high sierra box, but I can probably get one.
t0050 -should- pass automagically, so I feel that I can do something.
Unless someone is faster of course.


Sweet, thanks for taking a look.


Is it possible that  you run
debug=t verbose=t ./t0050-filesystem.sh
and send the output to me ?


Sure.  First, though, note that I can make it pass (or at least "not
ok...TODO known breakage") with the following patch (may be
whitespace-damaged by gmail):

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 483c8d6d7..770b91f8c 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1106,12 +1106,7 @@ test_lazy_prereq UTF8_NFD_TO_NFC '
 auml=$(printf "\303\244")
 aumlcdiar=$(printf "\141\314\210")
 >"$auml" &&
-   case "$(echo *)" in
-   "$aumlcdiar")
-   true ;;
-   *)
-   false ;;
-   esac
+   stat "$aumlcdiar" >/dev/null 2>/dev/null


Nicely analyzed and improved.

The "stat" statement is technically correct.
I think that a more git-style fix would be
[] ---
+   test -r "$aumlcdiar"

instead of the stat.

I looked into the 2 known breakages.
In short: they test use cases which are not sooo important for a user in 
practice, but do a good test if the code is broken.

IOW: I can't see a need for immediate action.

As you already did all the analyzes:
Do you want to send a patch ?

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

2018-04-26 Thread Elijah Newren

On Thu, Apr 26, 2018 at 10:13 AM, Torsten Bögershausen  wrote:
> Hm,
> thanks for the report.
> I don't have a high sierra box, but I can probably get one.
> t0050 -should- pass automagically, so I feel that I can do something.
> Unless someone is faster of course.

Sweet, thanks for taking a look.

> Is it possible that  you run
> debug=t verbose=t ./t0050-filesystem.sh
> and send the output to me ?

Sure.  First, though, note that I can make it pass (or at least "not
ok...TODO known breakage") with the following patch (may be
whitespace-damaged by gmail):

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 483c8d6d7..770b91f8c 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1106,12 +1106,7 @@ test_lazy_prereq UTF8_NFD_TO_NFC '
auml=$(printf "\303\244")
aumlcdiar=$(printf "\141\314\210")
>"$auml" &&
-   case "$(echo *)" in
-   "$aumlcdiar")
-   true ;;
-   *)
-   false ;;
-   esac
+   stat "$aumlcdiar" >/dev/null 2>/dev/null
 '

 test_lazy_prereq AUTOIDENT '

I'm just worried there are bugs elsewhere in dealing with filesystems
like this that would need to be fixed and that this papers over them.

Anyway, the output you requested, at least for the last two failing tests, is:

expecting success:
git mv "$aumlcdiar" "$auml" &&
git commit -m rename

fatal: destination exists, source=ä, destination=ä
not ok 9 - rename (silent unicode normalization)

#
# git mv "$aumlcdiar" "$auml" &&
# git commit -m rename
#

expecting success:
git reset --hard initial &&
git merge topic

HEAD is now at 1b3caf6 initial
Updating 1b3caf6..2db1bf9
error: The following untracked working tree files would be overwritten by merge:
ä
Please move or remove them before you merge.
Aborting
not ok 10 - merge (silent unicode normalization)

#
# git reset --hard initial &&
# git merge topic
#

# still have 1 known breakage(s)
# failed 2 among remaining 9 test(s)

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

2018-04-26 Thread Torsten Bögershausen

On 26.04.18 18:48, Elijah Newren wrote:
> On HFS (which appears to be the default Mac filesystem prior to High
> Sierra), unicode names are "normalized" before recording.  Thus with a
> script like:
> 
> mkdir tmp
> cd tmp
> 
> auml=$(printf "\303\244")
> aumlcdiar=$(printf "\141\314\210")
> >"$auml"
> 
> echo "auml:  " $(echo -n "$auml" | xxd)
> echo "aumlcdiar: " $(echo -n "$aumlcdiar" | xxd)
> echo "Dir contents:  " $(echo -n * | xxd)
> 
> echo "Stat auml: " "$(stat -f "%i   %Sm   %Su %N" "$auml")"
> echo "Stat aumlcdiar:" "$(stat -f "%i   %Sm   %Su %N" "$aumlcdiar")"
> 
> We see output like:
> 
> auml:   : c3a4 ..
> aumlcdiar:  : 61cc 88 a..
> Dir contents:   : 61cc 88 a..
> Stat auml:  857473   Apr 26 09:40:40 2018   newren ä
> Stat aumlcdiar: 857473   Apr 26 09:40:40 2018   newren ä
> 
> On APFS, which appears to be the new default filesystem in Mac OS High
> Sierra, we instead see:
> 
> auml:   : c3a4 ..
> aumlcdiar:  : 61cc 88 a..
> Dir contents:   : c3a4 ..
> Stat auml:  8591766636   Apr 26 09:40:59 2018   newren ä
> Stat aumlcdiar: 8591766636   Apr 26 09:40:59 2018   newren ä
> 
> i.e. APFS appears to record the filename as specified by the user, but
> continues to allow the user to access it via any name that normalizes
> to the same thing.  This difference causes t0050-filesystem.sh to fail
> the final two tests.  I could change the "UTF8_NFD_TO_NFC" flag
> checking in test-lib.sh to instead test the exit code of stat to make
> it pass these two tests, but I have no idea if there are problems
> elsewhere that this would just be papering over.
> 
> I dislike Mac OS and avoid it, so I'd prefer to find someone else
> motivated to fix this.  If no one is, I may eventually try to fix this
> up...in a year or three from now.  But is someone else interested?
> Would this serve as a good microproject for our microprojects list (or
> are the internals hairy enough that this is too big of a project for
> that list)?
> 
> 
> Elijah
> 

Hm,
thanks for the report.
I don't have a high sierra box, but I can probably get one.
t0050 -should- pass automagically, so I feel that I can do something.
Unless someone is faster of course.

Is it possible that  you run
debug=t verbose=t ./t0050-filesystem.sh 
and send the output to me ?

BUG report: unicode normalization on APFS (Mac OS High Sierra)

2018-04-26 Thread Elijah Newren

On HFS (which appears to be the default Mac filesystem prior to High
Sierra), unicode names are "normalized" before recording.  Thus with a
script like:

mkdir tmp
cd tmp

auml=$(printf "\303\244")
aumlcdiar=$(printf "\141\314\210")
>"$auml"

echo "auml:  " $(echo -n "$auml" | xxd)
echo "aumlcdiar: " $(echo -n "$aumlcdiar" | xxd)
echo "Dir contents:  " $(echo -n * | xxd)

echo "Stat auml: " "$(stat -f "%i   %Sm   %Su %N" "$auml")"
echo "Stat aumlcdiar:" "$(stat -f "%i   %Sm   %Su %N" "$aumlcdiar")"

We see output like:

auml:   : c3a4 ..
aumlcdiar:  : 61cc 88 a..
Dir contents:   : 61cc 88 a..
Stat auml:  857473   Apr 26 09:40:40 2018   newren ä
Stat aumlcdiar: 857473   Apr 26 09:40:40 2018   newren ä

On APFS, which appears to be the new default filesystem in Mac OS High
Sierra, we instead see:

auml:   : c3a4 ..
aumlcdiar:  : 61cc 88 a..
Dir contents:   : c3a4 ..
Stat auml:  8591766636   Apr 26 09:40:59 2018   newren ä
Stat aumlcdiar: 8591766636   Apr 26 09:40:59 2018   newren ä

i.e. APFS appears to record the filename as specified by the user, but
continues to allow the user to access it via any name that normalizes
to the same thing.  This difference causes t0050-filesystem.sh to fail
the final two tests.  I could change the "UTF8_NFD_TO_NFC" flag
checking in test-lib.sh to instead test the exit code of stat to make
it pass these two tests, but I have no idea if there are problems
elsewhere that this would just be papering over.

I dislike Mac OS and avoid it, so I'd prefer to find someone else
motivated to fix this.  If no one is, I may eventually try to fix this
up...in a year or three from now.  But is someone else interested?
Would this serve as a good microproject for our microprojects list (or
are the internals hairy enough that this is too big of a project for
that list)?


Elijah

Re: Bug Report - Pull remote branch does not retrieve new tags

2018-04-20 Thread Ævar Arnfjörð Bjarmason


On Fri, Apr 20 2018, Andrew Ducker wrote:

> Thanks Bryan, that does clear it up a bit.
>
> The reason that this came up is that Visual Studio Code has switched from 
> "git pull" to "git pull remote branch" when the "sync" button is clicked, and 
> this has meant that tags are no longer being fetched.
>
> What _does_ seem to work is adding "--tags" on the end of the git pull.  But 
> this isn't actually in the documentation[1], and I'm a bit nervous that this 
> is mid-deprecation.
>
> Is "--tags" going away shortly?  Or are they ok to depend on this?
>
> The bug is at https://github.com/Microsoft/vscode/issues/48211 if anyone 
> wants to chime in with advice over there :-)

It's in the documentation, it's just in the git-fetch documentation, and
the git-pull docs say:

More precisely, git pull runs git fetch with the given parameters

So --tags is not going away, however using --tags is likely not the
right thing either, because it'll also get tags that don't point to any
of the refs being tracked as the docs explain, which isn't what was
happening with "git pull".

As to what VS /should/ be doing, I have no idea because I don't know why
they switched away from "git pull" to "git pull remote branch" in the
first place. Maybe they'd like to clone with --single-branch?

Unfortunately there's no way to replicate that on an existing repo
without re-cloning, as my
https://public-inbox.org/git/874lkuvtve@evledraar.gmail.com/
explains.

>
>> -Original Message-
>> From: Bryan Turner [mailto:btur...@atlassian.com]V
>> Sent: 19 April 2018 23:14
>> To: Andrew Ducker
>> Cc: git@vger.kernel.org
>> Subject: Re: Bug Report - Pull remote branch does not retrieve new tags
>>
>> Andrew,
>>
>> On Thu, Apr 19, 2018 at 6:55 AM, Andrew Ducker
>> <andrew_duc...@standardlife.com> wrote:
>> >
>> > What happens:
>> > When I create a new tag on the remote (changing nothing else)
>> > "git pull origin master" produces the following:
>> >   From git.internal.company.com:team/testrepo
>> >* branchmaster -> FETCH_HEAD
>> >   Already up-to-date.
>> >
>> > If I instead do a "git pull" I get:
>> >   From git.internal.company.com:team/testrepo
>> >* [new tag] Testing11  -> Testing11
>> >   Already up-to-date.
>> >
>> > What I think should happen:
>> > The "git pull origin master" should retrieve the tag.
>> >
>> > This is with 2.16.2.windows.1, but also occurred on my previously installed
>> version (2.12.2.windows.2)
>> >
>> > My understanding is that "git pull" and "git pull $repo $currentbranch"
>> should function identically.
>> >
>> > Is this a bug, or am I misunderstanding the manual page?
>>
>> Looks like a misunderstanding, to me. Perhaps I can help clarify.
>>
>> "git pull" without arguments fetches from the "origin" repository
>> using the configured "fetch" refspecs, which typically looks something
>> like "fetch = +refs/heads/*:refs/remotes/origin/*". It _doesn't_
>> actually fetch all tags, but any tag referencing any object/commit
>> included in the branches is brought along for the ride. This is
>> documented on "git pull":
>>
>> --no-tags
>>
>> By default, tags that point at objects that are downloaded from
>> the remote repository are fetched and stored locally. This option
>> disables this automatic tag following. The default behavior for a
>> remote may be specified with the remote..tagOpt setting. See
>> git-config(1).
>>
>> By comparison, on your "git pull $repo $currentBranch", what you're
>> calling "$currentBranch" is actually "[...]" from the
>> documentation. In other words, by passing "master", you've told "git
>> pull" to fetch _nothing but "master"_, ignoring the configured
>> refspec(s). Additionally, since you haven't told "git pull" where to
>> _put_ "master" once it's fetched, it writes it to "FETCH_HEAD". If you
>> have a tracking branch setup, "git pull origin master" will also
>> update the tracking branch. For example, the same command for me
>> produces:
>>
>> $ git pull origin master
>> From ...
>>  * branchmaster -> FETCH_HEAD
>>aca5eb0fef5..ad484477508  master -> origin/master
>>
>> As you can see, both FETC

RE: Bug Report - Pull remote branch does not retrieve new tags

2018-04-20 Thread Andrew Ducker

Thanks Bryan, that does clear it up a bit.

The reason that this came up is that Visual Studio Code has switched from "git 
pull" to "git pull remote branch" when the "sync" button is clicked, and this 
has meant that tags are no longer being fetched.

What _does_ seem to work is adding "--tags" on the end of the git pull.  But 
this isn't actually in the documentation[1], and I'm a bit nervous that this is 
mid-deprecation.

Is "--tags" going away shortly?  Or are they ok to depend on this?

The bug is at https://github.com/Microsoft/vscode/issues/48211 if anyone wants 
to chime in with advice over there :-)

Thanks,

Andy

> -Original Message-
> From: Bryan Turner [mailto:btur...@atlassian.com]
> Sent: 19 April 2018 23:14
> To: Andrew Ducker
> Cc: git@vger.kernel.org
> Subject: Re: Bug Report - Pull remote branch does not retrieve new tags
>
> Andrew,
>
> On Thu, Apr 19, 2018 at 6:55 AM, Andrew Ducker
> <andrew_duc...@standardlife.com> wrote:
> >
> > What happens:
> > When I create a new tag on the remote (changing nothing else)
> > "git pull origin master" produces the following:
> >   From git.internal.company.com:team/testrepo
> >* branchmaster -> FETCH_HEAD
> >   Already up-to-date.
> >
> > If I instead do a "git pull" I get:
> >   From git.internal.company.com:team/testrepo
> >* [new tag] Testing11  -> Testing11
> >   Already up-to-date.
> >
> > What I think should happen:
> > The "git pull origin master" should retrieve the tag.
> >
> > This is with 2.16.2.windows.1, but also occurred on my previously installed
> version (2.12.2.windows.2)
> >
> > My understanding is that "git pull" and "git pull $repo $currentbranch"
> should function identically.
> >
> > Is this a bug, or am I misunderstanding the manual page?
>
> Looks like a misunderstanding, to me. Perhaps I can help clarify.
>
> "git pull" without arguments fetches from the "origin" repository
> using the configured "fetch" refspecs, which typically looks something
> like "fetch = +refs/heads/*:refs/remotes/origin/*". It _doesn't_
> actually fetch all tags, but any tag referencing any object/commit
> included in the branches is brought along for the ride. This is
> documented on "git pull":
>
> --no-tags
>
> By default, tags that point at objects that are downloaded from
> the remote repository are fetched and stored locally. This option
> disables this automatic tag following. The default behavior for a
> remote may be specified with the remote..tagOpt setting. See
> git-config(1).
>
> By comparison, on your "git pull $repo $currentBranch", what you're
> calling "$currentBranch" is actually "[...]" from the
> documentation. In other words, by passing "master", you've told "git
> pull" to fetch _nothing but "master"_, ignoring the configured
> refspec(s). Additionally, since you haven't told "git pull" where to
> _put_ "master" once it's fetched, it writes it to "FETCH_HEAD". If you
> have a tracking branch setup, "git pull origin master" will also
> update the tracking branch. For example, the same command for me
> produces:
>
> $ git pull origin master
> From ...
>  * branchmaster -> FETCH_HEAD
>aca5eb0fef5..ad484477508  master -> origin/master
>
> As you can see, both FETCH_HEAD and origin/master were updated, since
> my local "master" tracks "origin"'s "master":
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> Hope this helps!
> Bryan
Confidentiality - This email is confidential.
Not meant for you? - If you don't think this email is meant for you, please let 
us know. Do not copy or forward the information it contains, and delete this 
email from your system.
Views expressed - Any personal views or opinions expressed in this email are 
the sender's, and do not necessarily reflect the views of Standard Life 
Aberdeen group.
Monitoring - We filter and monitor emails to protect our systems and to keep 
them running smoothly.
Emailing us - Email isn't a secure form of communication. If you want to send 
us confidential information please send it by post. However, if you do 
communicate with us by email on any subject, you are giving us permission to 
email you back.
Phoning us - Calls may be monitored and/or recorded to protect both you and us 
and help with our training. Call charges will vary.
Standard Life Aberdeen group - Standa

Re: Bug Report - Pull remote branch does not retrieve new tags

2018-04-19 Thread Bryan Turner

Andrew,

On Thu, Apr 19, 2018 at 6:55 AM, Andrew Ducker
 wrote:
>
> What happens:
> When I create a new tag on the remote (changing nothing else)
> "git pull origin master" produces the following:
>   From git.internal.company.com:team/testrepo
>* branchmaster -> FETCH_HEAD
>   Already up-to-date.
>
> If I instead do a "git pull" I get:
>   From git.internal.company.com:team/testrepo
>* [new tag] Testing11  -> Testing11
>   Already up-to-date.
>
> What I think should happen:
> The "git pull origin master" should retrieve the tag.
>
> This is with 2.16.2.windows.1, but also occurred on my previously installed 
> version (2.12.2.windows.2)
>
> My understanding is that "git pull" and "git pull $repo $currentbranch" 
> should function identically.
>
> Is this a bug, or am I misunderstanding the manual page?

Looks like a misunderstanding, to me. Perhaps I can help clarify.

"git pull" without arguments fetches from the "origin" repository
using the configured "fetch" refspecs, which typically looks something
like "fetch = +refs/heads/*:refs/remotes/origin/*". It _doesn't_
actually fetch all tags, but any tag referencing any object/commit
included in the branches is brought along for the ride. This is
documented on "git pull":

--no-tags

By default, tags that point at objects that are downloaded from
the remote repository are fetched and stored locally. This option
disables this automatic tag following. The default behavior for a
remote may be specified with the remote..tagOpt setting. See
git-config(1).

By comparison, on your "git pull $repo $currentBranch", what you're
calling "$currentBranch" is actually "[...]" from the
documentation. In other words, by passing "master", you've told "git
pull" to fetch _nothing but "master"_, ignoring the configured
refspec(s). Additionally, since you haven't told "git pull" where to
_put_ "master" once it's fetched, it writes it to "FETCH_HEAD". If you
have a tracking branch setup, "git pull origin master" will also
update the tracking branch. For example, the same command for me
produces:

$ git pull origin master
>From ...
 * branchmaster -> FETCH_HEAD
   aca5eb0fef5..ad484477508  master -> origin/master

As you can see, both FETCH_HEAD and origin/master were updated, since
my local "master" tracks "origin"'s "master":

[branch "master"]
remote = origin
merge = refs/heads/master

Hope this helps!
Bryan

Bug Report - Pull remote branch does not retrieve new tags

2018-04-19 Thread Andrew Ducker

What happens:
When I create a new tag on the remote (changing nothing else)
"git pull origin master" produces the following:
  From git.internal.company.com:team/testrepo
   * branchmaster -> FETCH_HEAD
  Already up-to-date.

If I instead do a "git pull" I get:
  From git.internal.company.com:team/testrepo
   * [new tag] Testing11  -> Testing11
  Already up-to-date.

What I think should happen:
The "git pull origin master" should retrieve the tag.

This is with 2.16.2.windows.1, but also occurred on my previously installed 
version (2.12.2.windows.2)

My understanding is that "git pull" and "git pull $repo $currentbranch" should 
function identically.

Is this a bug, or am I misunderstanding the manual page?

Thanks,

Andy
Confidentiality - This email is confidential.
Not meant for you? - If you don't think this email is meant for you, please let 
us know. Do not copy or forward the information it contains, and delete this 
email from your system.
Views expressed - Any personal views or opinions expressed in this email are 
the sender's, and do not necessarily reflect the views of Standard Life 
Aberdeen group.
Monitoring - We filter and monitor emails to protect our systems and to keep 
them running smoothly.
Emailing us - Email isn't a secure form of communication. If you want to send 
us confidential information please send it by post. However, if you do 
communicate with us by email on any subject, you are giving us permission to 
email you back.
Phoning us - Calls may be monitored and/or recorded to protect both you and us 
and help with our training. Call charges will vary.
Standard Life Aberdeen group - Standard Life Aberdeen group comprises Standard 
Life Aberdeen plc and its subsidiaries. For more information on Standard Life 
Aberdeen group visit our website http://www.standardlifeaberdeen.com/.
Standard Life Aberdeen plc (SC286832), Standard Life Assurance Limited 
(SC286833) and Standard Life Employee Services Limited (SC271355) are all 
registered in Scotland at Standard Life House, 30 Lothian Road, Edinburgh EH1 
2DH. Standard Life Assurance Limited is authorised by the Prudential Regulation 
Authority and regulated by the Financial Conduct Authority and the Prudential 
Regulation Authority.
For more information on Standard Life Assurance limited visit our website 
http://www.standardlife.co.uk

RE: Bug report: git-stash doesn't return correct status code

2018-03-08 Thread Vromen, Tomer

> But stepping back a bit, why do you even need stash save/pop around
> "checkout -b new-feature-branch" (that implicitly branches at the
> tip) in the first place?  

Sorry about that, I meant something like

git stash && git checkout develop && git pull && git checkout -b 
new-feature-branch && git stash pop

My point is that it is the user's expectation that "git stash" will push to the 
stash.
Not pushing anything should be considered a failure.

Tomer.

-Original Message-
From: Junio C Hamano [mailto:jch2...@gmail.com] On Behalf Of Junio C Hamano
Sent: Wednesday, March 07, 2018 23:03
To: Vromen, Tomer <tomer.vro...@intel.com>
Cc: git@vger.kernel.org
Subject: Re: Bug report: git-stash doesn't return correct status code

Junio C Hamano <gits...@pobox.com> writes:

> "Vromen, Tomer" <tomer.vro...@intel.com> writes:
>
>>> git stash && git checkout -b new-feature-branch && git stash pop
>>
>> This is useful when I realize that I want to open a new branch for my 
>> changes (that I haven't committed yet).
>> However, I might have forgotten to save my changes in the editor, so 
>> git-stash will give this error:
>>
>> No local changes to save
>
> This is given with "say" and not with "die", as this is merely an
> informational diagnosis.  The command did not find any erroneous
> condition, the command did not fail to do anything it was supposed
> to do, so the command exited with 0 status.

I guess that is only half an answer.  If you really want to avoid
creating the new branch when the working tree and the index are
clean, you'd need to check that yourself before that three-command
sequence.  In our shell script, we use these as such a check:

git update-index --refresh -q --ignore-submodules
git diff-files --quiet --ignore-submodules &&
git diff-index --cached --quiet --ignore-submodules HEAD --

But stepping back a bit, why do you even need stash save/pop around
"checkout -b new-feature-branch" (that implicitly branches at the
tip) in the first place?  "checkout -b" that begins at the current
HEAD does not touch the index nor the working tree and take the
local changes with you to the new branch, so save/pop around it
seems totally pointless.
-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Bug report: git-stash doesn't return correct status code

2018-03-07 Thread Junio C Hamano

Junio C Hamano  writes:

> "Vromen, Tomer"  writes:
>
>>> git stash && git checkout -b new-feature-branch && git stash pop
>>
>> This is useful when I realize that I want to open a new branch for my 
>> changes (that I haven't committed yet).
>> However, I might have forgotten to save my changes in the editor, so 
>> git-stash will give this error:
>>
>> No local changes to save
>
> This is given with "say" and not with "die", as this is merely an
> informational diagnosis.  The command did not find any erroneous
> condition, the command did not fail to do anything it was supposed
> to do, so the command exited with 0 status.

I guess that is only half an answer.  If you really want to avoid
creating the new branch when the working tree and the index are
clean, you'd need to check that yourself before that three-command
sequence.  In our shell script, we use these as such a check:

git update-index --refresh -q --ignore-submodules
git diff-files --quiet --ignore-submodules &&
git diff-index --cached --quiet --ignore-submodules HEAD --

But stepping back a bit, why do you even need stash save/pop around
"checkout -b new-feature-branch" (that implicitly branches at the
tip) in the first place?  "checkout -b" that begins at the current
HEAD does not touch the index nor the working tree and take the
local changes with you to the new branch, so save/pop around it
seems totally pointless.

Re: Bug report: git-stash doesn't return correct status code

2018-03-07 Thread Junio C Hamano

"Vromen, Tomer"  writes:

>> git stash && git checkout -b new-feature-branch && git stash pop
>
> This is useful when I realize that I want to open a new branch for my changes 
> (that I haven't committed yet).
> However, I might have forgotten to save my changes in the editor, so 
> git-stash will give this error:
>
> No local changes to save

This is given with "say" and not with "die", as this is merely an
informational diagnosis.  The command did not find any erroneous
condition, the command did not fail to do anything it was supposed
to do, so the command exited with 0 status.

Bug report: git-stash doesn't return correct status code

2018-03-07 Thread Vromen, Tomer

Hi all,

I often use this one-liner:

> git stash && git checkout -b new-feature-branch && git stash pop

This is useful when I realize that I want to open a new branch for my changes 
(that I haven't committed yet).
However, I might have forgotten to save my changes in the editor, so git-stash 
will give this error:

No local changes to save

Despite the error, the command returns status code 0, and so the branch is 
created and the stash is popped, which was not my intention.
I think that git-stash should return a non-zero status code if it didn't push a 
new stash.

git version: 2.8.4


Thank you,
Tomer Vromen

-
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Bug report: "Use of uninitialized value $_ in print"

2018-03-05 Thread Jonathan Nieder

Jeff King wrote:
> On Fri, Mar 02, 2018 at 09:15:44AM -0800, Junio C Hamano wrote:
>> Jeff King  writes:

>>> That's probably a reasonable sanity check, but I think we need to abort
>>> and not just have a too-small DISPLAY array. Because later code like the
>>> hunk-splitting is going to assume that there's a 1:1 line
>>> correspondence. We definitely don't want to end up in a situation where
>>> we show one thing but apply another.
>>
>> Yes, agreed completely.
>
> Let's add this sanity check while we're thinking about it. Here's a
> series.
>
>   [1/2]: t3701: add a test for interactive.diffFilter
>   [2/2]: add--interactive: detect bogus diffFilter output
>
>  git-add--interactive.perl  |  8 
>  t/t3701-add-interactive.sh | 20 
>  2 files changed, 28 insertions(+)

With or without the tweak Ævar Arnfjörð Bjarmason suggested,
Reviewed-by: Jonathan Nieder 

Thanks.  It's probably also worth adding Sam's reported-by to patch 2/2:
Reported-by: Sam Kuper

Re: Bug report: "Use of uninitialized value $_ in print"

On Fri, Mar 02, 2018 at 01:53:32PM -0800, Junio C Hamano wrote:

> Sam Kuper  writes:
> 
> > 1. It would yield, IIUC, less flexibility to create new kinds of view
> > based on a consistent, standardised underlying model.
> >
> > 2. It is harder to read, for some types of input (e.g. prose) than the
> > view generated by the existing word-diff algorithm.
> 
> The loss of line-end by the lossy "word-diff" output does not matter
> if you never split hunks, but to be able to split a hunk at an
> in-between context line (which you can already do) and new features
> like per-line selection that are emerging, keeping 1:1 line
> correspondence between what is shown and what is applied is a must.
> 
> Unless you are volunteering to design (notice that I am not saying
> "implement") both diff generation/coloration side _and_ patch
> application side, that is.  In which case, you may be able to come
> up with a magic ;-)

IIRC, we do the word-diff by first finding the individual hunks with a
normal line diff, and then doing a word diff inside those hunks. So one
easy option would be to add a --color-words option that gets passed
along to the underlying display diff and just disables hunk splitting. I
think we'd also need to start parsing the DISPLAY hunks more carefully
to make sure we re-sync at hunk boundaries.

-Peff

Re: Bug report: "Use of uninitialized value $_ in print"

On Fri, Mar 02, 2018 at 05:30:28PM +, Sam Kuper wrote:

> On 02/03/2018, Jeff King  wrote:
> > Unfortunately, I don't think there's an easy way to do what you want
> > (show word-diffs but apply the full diff).
> 
> Oh :(
> 
> That would be a *very* useful feature to have, especially where
> multiple small (e.g. single character or single word) changes are
> sprinkled throughout a large file.

You might want to try diff-highlight from Git's contrib/ directory. It
was the reason I added interactive.diffFilter in the first place. E.g.:

  cd contrib/diff-highlight
  make
  cp diff-highlight /to/your/$PATH
  git config --global interactive.diffFilter diff-highlight

It's not quite the same as a word-diff, because it doesn't find matches
across word boundaries. So if you re-wrap a paragraph, for example, it
won't be much help. But I do find it useful (and also as a general
filter for log and diff output).

> Should I start a separate thread for this as a feature request?

I think this thread can serve.

-Peff

Re: Bug report: "Use of uninitialized value $_ in print"

On Fri, Mar 02, 2018 at 09:15:44AM -0800, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > That's probably a reasonable sanity check, but I think we need to abort
> > and not just have a too-small DISPLAY array. Because later code like the
> > hunk-splitting is going to assume that there's a 1:1 line
> > correspondence. We definitely don't want to end up in a situation where
> > we show one thing but apply another.
> 
> Yes, agreed completely.

Let's add this sanity check while we're thinking about it. Here's a
series.

  [1/2]: t3701: add a test for interactive.diffFilter
  [2/2]: add--interactive: detect bogus diffFilter output

 git-add--interactive.perl  |  8 
 t/t3701-add-interactive.sh | 20 
 2 files changed, 28 insertions(+)

-Peff

Re: Bug report: "Use of uninitialized value $_ in print"

Sam Kuper  writes:

> 1. It would yield, IIUC, less flexibility to create new kinds of view
> based on a consistent, standardised underlying model.
>
> 2. It is harder to read, for some types of input (e.g. prose) than the
> view generated by the existing word-diff algorithm.

The loss of line-end by the lossy "word-diff" output does not matter
if you never split hunks, but to be able to split a hunk at an
in-between context line (which you can already do) and new features
like per-line selection that are emerging, keeping 1:1 line
correspondence between what is shown and what is applied is a must.

Unless you are volunteering to design (notice that I am not saying
"implement") both diff generation/coloration side _and_ patch
application side, that is.  In which case, you may be able to come
up with a magic ;-)

Re: Bug report: "Use of uninitialized value $_ in print"

2018-03-02 Thread Sam Kuper

On 02/03/2018, Junio C Hamano  wrote:
> Jeff King  writes:
>> Unfortunately, I don't think there's an easy way to do what you want
>> (show word-diffs but apply the full diff).
>
> The current "word-diff" discards the information on where the lines
> end, and it is pretty much hopeless/useless in the context of "add
> -p".

This is unfortunate.

I am familiar with the model-view-controller ("MVC") paradigm used in
some software packages. I had hoped that Git followed this paradigm
somewhat, and cleanly separated the underlying model of the diff (i.e.
a representation that would be generated in all cases where a diff is
needed), and the view of the diff (i.e. the visual representation,
e.g. word-diff, line diff, colored, non-colored, etc, as requested by
the user).

Such separation of concerns strikes me as being the best approach
here. It could be a lot of work, but I would be grateful if the Git
developers/maintainers could work towards it as an end goal for this
aspect of Git's architecture.

Unfortunately, I am not very familiar with the Git codebase, nor
well-versed in its primary languages, so I can't be of much help here
:(

> It would be a good addition to revamp it so that it keeps the
> original lines in pre/post images but only colors/highlights the
> byte ranges in such a way that (1) on a pre-image line, paint only
> the byte range that do not appear in the post-image, and (2) on a
> post-image line, paint only the byte range that do not appear in the
> pre-image.
>
> E.g. Given these two
>
> diff --git a/1 b/2
> index aa49234b68..1cd9f6b5fd 100644
> --- a/1
> +++ b/2
> @@ -1,2 +1 @@
> -a b c e
> -f g i j
> +a b d f g h
>
> the current word-diff would give (I cannot do colors here, so I'll
> upcase the colored letters):
>
> @@ -1,2 +1 @@
> a b C ED f g I JH
>
> as the output, but if we produced
>
> @@ -1,2 +1 @@
> -a b C E
> -f g I J
> +a b D f g H
>
> instead, then colored "add -p" would become easier to see.
>
> And that would be useful outside the context of "add -p", which is a
> huge plus.

This would be much better than the current situation, where the visual
representation gives misleading feedback about the underlying diff,
and where the error I reported crops up.

However, in my opinion your proposed solution would still be not as
good as separating the two concerns, as described earlier in this
email, on two fronts:

1. It would yield, IIUC, less flexibility to create new kinds of view
based on a consistent, standardised underlying model.

2. It is harder to read, for some types of input (e.g. prose) than the
view generated by the existing word-diff algorithm. Your approach, as
outlined in your example above, requires the reader to visually jump
(saccade) between two lines that are separated by an intervening line,
in order to see what has changed. The existing word-diff is much
easier to use: it puts the changes right next to each other, avoiding
line-skipping and allowing horizontal saccades (which are much more
familiar to people used to languages written in left-to-right or
right-to-left scripts).

I don't want to sound negative. As I say, I think your solution is a
big improvement on what currently exists. But I would see it as an
intermediate solution - a stopgap - rather than an endpoint of
development.

In other words, if your solution would be much quicker to implement
than the one I proposed, then please go ahead with yours first, and
please add mine to the longer-term to-do list :)

Thank you again for helping to make Git such a great tool, and for
working tirelessly to improve it further!

P.S. There is a related StackOverflow question here:
https://stackoverflow.com/questions/49058817/git-add-patch-with-word-diff

Re: Bug report: "Use of uninitialized value $_ in print"

Jeff King  writes:

> Unfortunately, I don't think there's an easy way to do what you want
> (show word-diffs but apply the full diff).

The current "word-diff" discards the information on where the lines
end, and it is pretty much hopeless/useless in the context of "add
-p".  It would be a good addition to revamp it so that it keeps the
original lines in pre/post images but only colors/highlights the
byte ranges in such a way that (1) on a pre-image line, paint only
the byte range that do not appear in the post-image, and (2) on a
post-image line, paint only the byte range that do not appear in the
pre-image.  

E.g. Given these two

diff --git a/1 b/2
index aa49234b68..1cd9f6b5fd 100644
--- a/1
+++ b/2
@@ -1,2 +1 @@
-a b c e
-f g i j
+a b d f g h

the current word-diff would give (I cannot do colors here, so I'll
upcase the colored letters):

@@ -1,2 +1 @@
a b C ED f g I JH

as the output, but if we produced

@@ -1,2 +1 @@
-a b C E
-f g I J
+a b D f g H

instead, then colored "add -p" would become easier to see.

And that would be useful outside the context of "add -p", which is a
huge plus.

Re: Bug report: "Use of uninitialized value $_ in print"

2018-03-02 Thread Sam Kuper

On 02/03/2018, Jeff King  wrote:
> Unfortunately, I don't think there's an easy way to do what you want
> (show word-diffs but apply the full diff).

Oh :(

That would be a *very* useful feature to have, especially where
multiple small (e.g. single character or single word) changes are
sprinkled throughout a large file.

Should I start a separate thread for this as a feature request?

Re: Bug report: "Use of uninitialized value $_ in print"

2018-03-02 Thread Sam Kuper

On 02/03/2018, Jonathan Nieder  wrote:
> Is this reproducible for you?

Yes. It seems to occur consistently, given the same input.

> Do you have more details about how I can reproduce it?

Unfortunately, the particular git repo I encountered it on is private,
otherwise I would point you to it.

I haven't attempted to create a MWE. Am I correct that doing so is now
not needed, in the light of Jeff King's email below?

> What arch are you on?  What perl version do you use?  Can you report
> this using "reportbug git"?

All perfectly decent questions. For a modicum of security/privacy, I
would prefer to avoid answering them unless necessary.

Am I right in thinking that these answers are no longer needed, in the
light of Jeff King's email below?

On 02/03/2018, Jeff King  wrote:
>   3. Your invocation in particular is a problem because it uses
>  --word-diff, which will not have a one-to-one line correspondence
>  with the bare diff.
>
>  add--interactive handles pretty-printing by running the diff
>  command twice: once with no special options, and once with
>  "--color" and piped through the diffFilter. It assumes that the two
>  match each other line for line, so it shows you the "DISPLAY"
>  variant, but then ultimately applies the "TEXT" variant.
>
> And that last one is the cause of the errors you see:
>
>> Use of uninitialized value $_ in print at
>> /usr/lib/git-core/git-add--interactive line 1371,  line 74.
>
> The "DISPLAY" run for your case generates fewer lines than the "TEXT"
> run, and we complain on trying to show those extra lines.

Re: Bug report: "Use of uninitialized value $_ in print"

Jeff King  writes:

> That's probably a reasonable sanity check, but I think we need to abort
> and not just have a too-small DISPLAY array. Because later code like the
> hunk-splitting is going to assume that there's a 1:1 line
> correspondence. We definitely don't want to end up in a situation where
> we show one thing but apply another.

Yes, agreed completely.

Re: Bug report: "Use of uninitialized value $_ in print"

On Fri, Mar 02, 2018 at 08:53:34AM -0800, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > Because the array is full of "undef". See parse_diff(), which does this:
> >
> >   my @diff = run_cmd_pipe("git", @diff_cmd, "--", $path);
> >   ...
> >   @colored = run_cmd_pipe(@display_cmd);
> >   ...
> >   for (my $i = 0; $i < @diff; $i++) {
> >   ...
> >   push @{$hunk[-1]{TEXT}}, $diff[$i];
> >   push @{$hunk[-1]{DISPLAY}},
> >(@colored ? $colored[$i] : $diff[$i]);
> >   }
> >
> > If the @colored output is shorter than the normal @diff output, we'll
> > push a bunch of "undef" onto the DISPLAY array (the ternary there is
> > because sometimes @colored is completely empty if the user did not ask
> > for color).
> 
> An obvious sanity check would be to ensure @colored == @diff
> 
> push @{$hunk[-1]{DISPLAY}},
> -(@colored ? $colored[$i] : $diff[$i]);
> +(@colored && @colored == @diff ? $colored[$i] : 
> $diff[$i]);
>  }
> 
> or something like that?

That's probably a reasonable sanity check, but I think we need to abort
and not just have a too-small DISPLAY array. Because later code like the
hunk-splitting is going to assume that there's a 1:1 line
correspondence. We definitely don't want to end up in a situation where
we show one thing but apply another.

-Peff

Re: Bug report: "Use of uninitialized value $_ in print"

Jeff King  writes:

> Because the array is full of "undef". See parse_diff(), which does this:
>
>   my @diff = run_cmd_pipe("git", @diff_cmd, "--", $path);
>   ...
>   @colored = run_cmd_pipe(@display_cmd);
>   ...
>   for (my $i = 0; $i < @diff; $i++) {
>   ...
>   push @{$hunk[-1]{TEXT}}, $diff[$i];
>   push @{$hunk[-1]{DISPLAY}},
>(@colored ? $colored[$i] : $diff[$i]);
>   }
>
> If the @colored output is shorter than the normal @diff output, we'll
> push a bunch of "undef" onto the DISPLAY array (the ternary there is
> because sometimes @colored is completely empty if the user did not ask
> for color).

An obvious sanity check would be to ensure @colored == @diff

push @{$hunk[-1]{DISPLAY}},
-(@colored ? $colored[$i] : $diff[$i]);
+(@colored && @colored == @diff ? $colored[$i] : $diff[$i]);
 }

or something like that?

Re: Bug report: "Use of uninitialized value $_ in print"

On Thu, Mar 01, 2018 at 11:04:34PM -0800, Jonathan Nieder wrote:

> > Use of uninitialized value $_ in print at
> > /usr/lib/git-core/git-add--interactive line 1371,  line 75.
> [...]
> 
> Strange.  The relevant line, for reference:
> 
> $ dpkg-deb --fsys-tarfile git_2.11.0-3+deb9u2_amd64.deb |
>   tar Oxf - ./usr/lib/git-core/git-add--interactive |
>   sed -n '1370,1372 p'
> 
>   for (@{$hunk[$ix]{DISPLAY}}) {
>   print; < this one
>   }
> 
> This is a foreach loop, so it's supposed to have set $_ to each value
> in the list @{$hunk[$ix]{DISPLAY}).  So why is Perl considering it
> uninitialized?

Because the array is full of "undef". See parse_diff(), which does this:

  my @diff = run_cmd_pipe("git", @diff_cmd, "--", $path);
  ...
  @colored = run_cmd_pipe(@display_cmd);
  ...
  for (my $i = 0; $i < @diff; $i++) {
  ...
  push @{$hunk[-1]{TEXT}}, $diff[$i];
  push @{$hunk[-1]{DISPLAY}},
   (@colored ? $colored[$i] : $diff[$i]);
  }

If the @colored output is shorter than the normal @diff output, we'll
push a bunch of "undef" onto the DISPLAY array (the ternary there is
because sometimes @colored is completely empty if the user did not ask
for color).

-Peff

Re: Bug report: "Use of uninitialized value $_ in print"

On Fri, Mar 02, 2018 at 01:19:35AM +, Sam Kuper wrote:

> The bug is that in the midst of running
> 
> git -c interactive.diffFilter="git diff --word-diff --color" add --patch

That's not how interactive.diffFilter is supposed to work.

It's meant to have the output of an existing diff piped into it.
Generating the diff anew will appear to work for some simple cases, but
fall down for others:

  1. Any of the flavors besides "add -p" will be running the wrong diff
 (e.g., "reset -p" runs a diff between the index and HEAD).

  2. Any pathspec limiters would be ignored (e.g., "add -p file").

  3. Your invocation in particular is a problem because it uses
 --word-diff, which will not have a one-to-one line correspondence
 with the bare diff.

 add--interactive handles pretty-printing by running the diff
 command twice: once with no special options, and once with
 "--color" and piped through the diffFilter. It assumes that the two
 match each other line for line, so it shows you the "DISPLAY"
 variant, but then ultimately applies the "TEXT" variant.

And that last one is the cause of the errors you see:

> Use of uninitialized value $_ in print at
> /usr/lib/git-core/git-add--interactive line 1371,  line 74.

The "DISPLAY" run for your case generates fewer lines than the "TEXT"
run, and we complain on trying to show those extra lines.

Unfortunately, I don't think there's an easy way to do what you want
(show word-diffs but apply the full diff).

-Peff

Re: Bug report: "Use of uninitialized value $_ in print"

2018-03-01 Thread Jonathan Nieder

Hi,

Sam Kuper wrote:

> First, background. I encountered a bug on Debian Stretch, using this
> git version:
>
> $ git --version
> git version 2.11.0
>
> The bug is that in the midst of running
>
> git -c interactive.diffFilter="git diff --word-diff --color" add --patch
>
> and after having answered "y" to some patches and "n" to others, git
> suddenly spewed the following output:
>
> Use of uninitialized value $_ in print at
> /usr/lib/git-core/git-add--interactive line 1371,  line 74.
> Stage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]? n
> Use of uninitialized value $_ in print at
> /usr/lib/git-core/git-add--interactive line 1371,  line 75.
[...]

Strange.  The relevant line, for reference:

$ dpkg-deb --fsys-tarfile git_2.11.0-3+deb9u2_amd64.deb |
  tar Oxf - ./usr/lib/git-core/git-add--interactive |
  sed -n '1370,1372 p'

for (@{$hunk[$ix]{DISPLAY}}) {
print; < this one
}

This is a foreach loop, so it's supposed to have set $_ to each value
in the list @{$hunk[$ix]{DISPLAY}).  So why is Perl considering it
uninitialized?

Is this reproducible for you?  Do you have more details about how I
can reproduce it?

What arch are you on?  What perl version do you use?  Can you report
this using "reportbug git"?

Thanks,
Jonathan

Bug report: "Use of uninitialized value $_ in print"

2018-03-01 Thread Sam Kuper

First, background. I encountered a bug on Debian Stretch, using this
git version:

$ git --version
git version 2.11.0


The bug is that in the midst of running

git -c interactive.diffFilter="git diff --word-diff --color" add --patch

and after having answered "y" to some patches and "n" to others, git
suddenly spewed the following output:


Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 74.
Stage this hunk [y,n,q,a,d,/,K,j,J,g,e,?]? n
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.
Use of uninitialized value $_ in print at
/usr/lib/git-core/git-add--interactive line 1371,  line 75.


I hope that this bug report can help the git core maintainers to
either fix the problem upstream, or to co-ordinate a fix with the
Debian git maintainer(s) if the bug does not exist upstream.

Thanks for the great DVCS :)

P.S. I am not subscribed to this mailing list, so please CC me in your
reply if you want me to see it.

Re: Bug Report: git status triggers a file change event

2018-02-23 Thread Johannes Schindelin

Hi all,

On Thu, 22 Feb 2018, Stefan Beller wrote:

> On Wed, Feb 21, 2018 at 9:22 PM, Jonathan Nieder  wrote:
> > +git-for-windows

First of all, this is clearly not a Windows-specific problem, as the index
file *is* updated, and that is simply the same behavior as on Linux/macOS.

> > Raining Chain wrote:
> >
> >> On Windows 10, git version 2.16.2.windows.1, running the command
> >>
> >> git status
> >>
> >> will trigger a file change event to file C:\myPath\.git  "Attributes
> >> changed."

Correct, because .git\index changed.

> >> This causes problems when using scripts that detect file changes such
> >> as tsc -w (Typescript compiler) and using softwares that regularly
> >> call git status such as VisualStudioCode.

Visual Studio Code most likely does not look at .git for worktree changes.

As to the Typescript compiler: it should only look for .ts files, I would
be very surprised if it was confused by .git's filesystem attributes
changing!

If tsw is still confused, try adding

"exclude": [
".git"
]

to your tsconfig.json.

Ciao,
Johannes

Re: Bug Report: git status triggers a file change event

2018-02-22 Thread Stefan Beller

On Wed, Feb 21, 2018 at 9:22 PM, Jonathan Nieder  wrote:
> +git-for-windows
> Hi,
>
> Raining Chain wrote:
>
>> On Windows 10, git version 2.16.2.windows.1, running the command
>>
>> git status
>>
>> will trigger a file change event to file C:\myPath\.git  "Attributes 
>> changed."
>>
>> This causes problems when using scripts that detect file changes such
>> as tsc -w (Typescript compiler) and using softwares that regularly
>> call git status such as VisualStudioCode.
>>
>> Thanks.

Does
https://github.com/git/git/commit/27344d6a6c8056664966e11acf674e5da6dd7ee3
help?

>
> Can you say more about how "tsc -w" reacts to the file change?  Is there
> a way to tell it to exclude particular files from the files it watches?
>
> Thanks,
> Jonathan

Re: Bug Report: git status triggers a file change event

2018-02-21 Thread Jonathan Nieder

+git-for-windows
Hi,

Raining Chain wrote:

> On Windows 10, git version 2.16.2.windows.1, running the command
>
> git status
>
> will trigger a file change event to file C:\myPath\.git  "Attributes changed."
>
> This causes problems when using scripts that detect file changes such
> as tsc -w (Typescript compiler) and using softwares that regularly
> call git status such as VisualStudioCode.
>
> Thanks.

Can you say more about how "tsc -w" reacts to the file change?  Is there
a way to tell it to exclude particular files from the files it watches?

Thanks,
Jonathan

Bug Report: git status triggers a file change event

2018-02-21 Thread Raining Chain

On Windows 10, git version 2.16.2.windows.1, running the command

git status

will trigger a file change event to file C:\myPath\.git  "Attributes changed."

This causes problems when using scripts that detect file changes such
as tsc -w (Typescript compiler) and using softwares that regularly
call git status such as VisualStudioCode.

Thanks.

Re: Bug Report: Subtrees and GPG Signed Commits

2018-02-08 Thread Stephen R Guglielmo

On Mon, Feb 5, 2018 at 1:45 PM, Junio C Hamano  wrote:
> Given that all references to this shell function seem to do
>
> sometree=$(toptree_for_commit $something)
>
> and then $sometree is used as if it were a tree object name, I can
> understand why the lack of --no-show-signature in the original
> breaks it when the user has show-signature configured.
>
> It probably makes more sense to replace the "git log" with something
> more appropirate for the job, like
>
> git rev-parse --verify "$commit^{tree}"
>
> though.

Junio,

Thanks for the feedback. I read the documentation on `rev-parse` and I
agree it makes more sense for this case. I've modified
`toptree_for_commit()` to use `rev-parse` instead. However, there's a
few other calls to `log` that I'm not sure can be replaced. For those,
I've kept `--no-show-signature`, making this require at least v2.10.0.

Below is the full diff against v2.16.1. Or, for the GitHub-savvy among us:

https://github.com/srguglielmo/git/compare/8279ed033f703d4115bee620dccd32a9ec94d9aa...srguglielmo:4b92b4494da057ed52c2ff8c329457a1c294d135

Thanks,
Steve

diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index dec085a23..9594ca4b5 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -297,7 +297,7 @@ find_latest_squash () {
 main=
 sub=
 git log --grep="^git-subtree-dir: $dir/*\$" \
---pretty=format:'START %H%n%s%n%n%b%nEND%n' HEAD |
+--no-show-signature --pretty=format:'START %H%n%s%n%n%b%nEND%n' HEAD |
 while read a b junk
 do
 debug "$a $b $junk"
@@ -341,7 +341,7 @@ find_existing_splits () {
 main=
 sub=
 git log --grep="^git-subtree-dir: $dir/*\$" \
---pretty=format:'START %H%n%s%n%n%b%nEND%n' $revs |
+--no-show-signature --pretty=format:'START %H%n%s%n%n%b%nEND%n' $revs |
 while read a b junk
 do
 case "$a" in
@@ -382,7 +382,7 @@ copy_commit () {
 # We're going to set some environment vars here, so
 # do it in a subshell to get rid of them safely later
 debug copy_commit "{$1}" "{$2}" "{$3}"
-git log -1 --pretty=format:'%an%n%ae%n%aD%n%cn%n%ce%n%cD%n%B' "$1" |
+git log --no-show-signature -1
--pretty=format:'%an%n%ae%n%aD%n%cn%n%ce%n%cD%n%B' "$1" |
 (
 read GIT_AUTHOR_NAME
 read GIT_AUTHOR_EMAIL
@@ -462,8 +462,8 @@ squash_msg () {
 oldsub_short=$(git rev-parse --short "$oldsub")
 echo "Squashed '$dir/' changes from $oldsub_short..$newsub_short"
 echo
-git log --pretty=tformat:'%h %s' "$oldsub..$newsub"
-git log --pretty=tformat:'REVERT: %h %s' "$newsub..$oldsub"
+git log --no-show-signature --pretty=tformat:'%h %s' "$oldsub..$newsub"
+git log --no-show-signature --pretty=tformat:'REVERT: %h %s'
"$newsub..$oldsub"
 else
 echo "Squashed '$dir/' content from commit $newsub_short"
 fi
@@ -475,7 +475,7 @@ squash_msg () {

 toptree_for_commit () {
 commit="$1"
-git log -1 --pretty=format:'%T' "$commit" -- || exit $?
+git rev-parse --verify "$commit^{tree}" || exit $?
 }

 subtree_for_commit () {

Bug report: Subtree split including extra commits

2018-02-07 Thread Daniel Karp

Apologies if this is the wrong place to send a bug report for
Contributed software.

I've run into what seems like an issue/bug with git subtree.

I am trying to split a single directory of our repo into its own repo
using git subtree. I ran the the following command from our project
root:
git subtree split --prefix=geekui2 -b geekui2-split
where geekui2 is the name of the subdir.

For commits before mid 2017, the created split branch contains our
entire commit history, regardless whether or not they include changes
in geekui2. For commits after that point, the commits are properly
filtered to include only commits that contain changes in geekui2.

The upshot is that if I push the branch to a new repo, and check out
one of those earlier commits, I can essentially recover the entire
codebase of our application (at that point), not just the content in
geekui2. Since our goal was to share part of our repo while keeping
the rest of it private, this is obviously a problem.

I've also tried using git-subrepo for this split--it seems to
correctly filter the commits, excluding all commits without changes to
geekui2. So something seems to be going wrong with the way git-subtree
handles this relative to git subrepo.

Unfortunately, there is a lot going on in our repo--I have no idea how
I would generate a minimal reproduction of this.

While our repo is private, I'm happy to help try to help debug this if
someone wants to take a look at this issue, although it is not my area
of expertise.

My git version is 2.16.1, and I am running it on macOS 10.12.6.

I am not subscribed to the git mailing list, so if anyone wants to get
in touch with me about this, I'm most likely to see it if you send an
email.

--
Daniel Karp

Re: [bug report]: error doing_rebase

2018-02-07 Thread Johannes Schindelin

Hi Bulat,

Please make sure to keep the Git mailing list in Cc: (I get *very* prickly
when Git users treat me as a free-of-cost help desk, and when I get that
annoyed, I stop helping).

On Tue, 6 Feb 2018, Bulat Musin wrote:

> Yes, I tested again.
> 
> With built 2.16... and it shows error message. git rebase --abort restores
> 
> state before rebase.

You misunderstood me. I am convinced that that error message *is correct*.
It shows an incorrect usage. You cannot start off an interactive rebase by
a `squash` command.

> With git 2.14 from Ubuntu's repo it works - 3 commits are squashed into first
> one

Yes, but you called `git rebase -i HEAD~2`, which means that only two
commits were up for rebasing. The third commit is outside the range
`HEAD~2..` which the command `git rebase -i HEAD~2` wants to let you rebase.

If v2.14 indeed modified `HEAD~2` (as I suspected in my earlier mail),
then you successfully confirmed that we fixed a bug, and that you expected
the buggy behavior.

> - with change SHA.
> 
> It seems to be bug in recent version.
> 
> Should I provide additional information?

Ciao,
Johannes

> On 02/06/2018 12:47 PM, Johannes Schindelin wrote:
> > Hi,
> >
> > On Mon, 5 Feb 2018, Bulat Musin wrote:
> >
> > > Now there are 3 sequential commits, I want to squash them into 1:
> > >
> > > git rebase -i HEAD~2
> > >
> > > In editor I changed all "pick" to "squash", saved file, I got:
> > >
> > > error: cannot 'squash' without a previous commit
> > You cannot start with a squash. You have to pick the first one, then
> > squash the second into the first.
> >
> > > However, 2.14.1 from Ubuntu's repo does the job - squashes 3 commits into
> > > 1.
> > It may be careless enough to do that, however, it might now have modified
> > the *wrong* commit, i.e. squashed the two patches *into HEAD~2*.
> >
> > Please verify that your HEAD~2 is still intact and part of the rebased
> > history, otherwise you will have a problem.
> >
> > Ciao,
> > Johannes
> 
>

Re: [bug report]: error doing_rebase

2018-02-06 Thread Johannes Schindelin

Hi,

On Mon, 5 Feb 2018, Bulat Musin wrote:

> Now there are 3 sequential commits, I want to squash them into 1:
> 
> git rebase -i HEAD~2
> 
> In editor I changed all "pick" to "squash", saved file, I got:
> 
> error: cannot 'squash' without a previous commit

You cannot start with a squash. You have to pick the first one, then
squash the second into the first.

> However, 2.14.1 from Ubuntu's repo does the job - squashes 3 commits into 1.

It may be careless enough to do that, however, it might now have modified
the *wrong* commit, i.e. squashed the two patches *into HEAD~2*.

Please verify that your HEAD~2 is still intact and part of the rebased
history, otherwise you will have a problem.

Ciao,
Johannes

[bug report]: error doing_rebase

2018-02-05 Thread Bulat Musin


Hi.

To reproduce:

git init testrepo

cd testrepo

echo 1 >> file

git add file

git commit -m'1'

echo 2 >> file

git add file

git commit -m'2'

echo 3 >> file

git add file

git commit -m'3'

Now there are 3 sequential commits, I want to squash them into 1:

git rebase -i HEAD~2

In editor I changed all "pick" to "squash", saved file, I got:

error: cannot 'squash' without a previous commit
You can fix this with 'git rebase --edit-todo' and then run 'git rebase 
--continue'.

Or you can abort the rebase with 'git rebase --abort'.

However, 2.14.1 from Ubuntu's repo does the job - squashes 3 commits into 1.

Thanks.




git version 2.16.1.72.g5be1f00a9

Re: Bug Report: Subtrees and GPG Signed Commits

2018-02-05 Thread Junio C Hamano

Stephen R Guglielmo  writes:

> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> index cc033af73..dec085a23 100755
> --- a/contrib/subtree/git-subtree.sh
> +++ b/contrib/subtree/git-subtree.sh
> @@ -475,7 +475,7 @@ squash_msg () {
>
>  toptree_for_commit () {
> commit="$1"
> -   git log -1 --pretty=format:'%T' "$commit" -- || exit $?
> +   git log --no-show-signature -1 --pretty=format:'%T' "$commit"
> -- || exit $?
>  }

Given that all references to this shell function seem to do

sometree=$(toptree_for_commit $something)

and then $sometree is used as if it were a tree object name, I can
understand why the lack of --no-show-signature in the original
breaks it when the user has show-signature configured.

It probably makes more sense to replace the "git log" with something
more appropirate for the job, like

git rev-parse --verify "$commit^{tree}"

though.

Re: Bug Report: Subtrees and GPG Signed Commits

2018-02-05 Thread Stephen R Guglielmo

On Mon, Feb 5, 2018 at 9:30 AM, Stephen R Guglielmo
 wrote:
> On Wed, Jan 31, 2018 at 7:33 AM, Stephen R Guglielmo
>  wrote:
>> On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun  wrote:
>>> On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano  wrote:
 Stefan Beller  writes:
> There has not been feedback for a while on this thread.
> I think that is because subtrees are not in anyone's hot
> interest area currently.
>
> This is definitely the right place to submit bugs.
> Looking through "git log --format="%ae %s" -S subtree",
> it seems as if Avery (apenw...@gmail.com) was mostly
> interested in developing subtrees, though I think he has
> moved on. Originally it was invented by Junio, who is
> the active maintainer of the project in 68faf68938
> (A new merge stragety 'subtree'., 2007-02-15)

 Thanks for trying to help, but I have *NOTHING* to do with the "git
 subtree" subcommand (and I personally have no interest in it).  What
 I did was a subtree merge strategy (i.e. "git merge -s subtree"),
 which is totally a different thing.

 David Greene offered to take it over in 2015, and then we saw some
 activity by David Aguilar in 2016, but otherwise the subcommand from
 contrib/ has pretty much been dormant these days.
>>>
>>> Strictly speaking, the 'git subtree' command does in fact use 'git
>>> merge -s subtree' under the covers, so Junio is at least partly
>>> responsible for giving me the idea :)
>>>
>>> I actually have never looked into how signed commits work and although
>>> I still use git-subtree occasionally (it hasn't needed any
>>> maintenance, for my simple use cases), I have never used it with
>>> signed commits.
>>>
>>> git-subtree maintains a cache that maps commit ids in the "original
>>> project" with their equivalents in the "merged project."  If there's
>>> something magic about how commit ids work with signed commits, I could
>>> imagine that causing the "no a valid object name" problems.  Or,
>>> git-subtree in --squash mode actually generates new commit objects
>>> using some magic of its own.  If it were to accidentally copy a
>>> signature into a commit that no longer matches the original, I imagine
>>> that new object might get rejected.
>>>
>>> Unfortunately I don't have time to look into it.  The git-subtree code
>>> is pretty straightforward, though, so if Stephen has an hour or two to
>>> look deeper it's probably possible to fix it up.  The tool is not
>>> actually as magical and difficult as it might seem at first glance :)
>>>
>>> Sorry I can't help more.
>>>
>>> Good luck,
>>>
>>> Avery
>>
>> Thanks all for the discussion/replies.
>>
>> We use subtrees extensively in our environment right now. The "sub"
>> repos (90+) are located on GitHub, while the "main/parent" repo is
>> provided by a vendor on website hosting infrastructure.
>>
>> I will take a look at:
>> git/Documentation/CodingGuidelines
>> git/Documentation/SubmittingPatches
>> git/contrib/subtree/
>>
>> Should I follow up in this thread with a patch (it might be a while)?
>>
>> Thanks!
>> Steve
>
> Hi all,
>
> It looks like I've found the cause of the issue. I have
> log.showsignature=true in my gitconfig. The toptree_for_commit()
> function calls `git log` and passes the output to `git commit-tree` in
> new_squash_commit(). Apparently commit-tree doesn't like GPG sigs.
>
> The fix was simple: --no-show-signature. However, I believe this was
> added in git v2.10.0, so it's not fully backwards compatible. I'm open
> to suggestions on a better fix if this is not acceptable.
>
> Thanks!
>
>
> https://github.com/srguglielmo/git/commit/822c8a45d049f86ea5c59c0b434303964e4e6f3d
>
>
>
> diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
> index cc033af73..dec085a23 100755
> --- a/contrib/subtree/git-subtree.sh
> +++ b/contrib/subtree/git-subtree.sh
> @@ -475,7 +475,7 @@ squash_msg () {
>
>  toptree_for_commit () {
> commit="$1"
> -   git log -1 --pretty=format:'%T' "$commit" -- || exit $?
> +   git log --no-show-signature -1 --pretty=format:'%T' "$commit"
> -- || exit $?
>  }
>
>  subtree_for_commit () {

Hey again,

Actually, to follow up on this, I added --no-show-signature to several
other locations. The above patch fixes the fatal, however the GPG sig
info is still included in the commit merge message for `subtree pull`.
This fixes that as well.

https://github.com/srguglielmo/git/commit/ebd2f628ddb960931aac5087c45a54b953976e99


diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index cc033af73..8126132dc 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -297,7 +297,7 @@ find_latest_squash () {
main=
sub=
git log --grep="^git-subtree-dir: $dir/*\$" \
-   --pretty=format:'START %H%n%s%n%n%b%nEND%n' HEAD

Re: Bug Report: Subtrees and GPG Signed Commits

2018-02-05 Thread Stephen R Guglielmo

On Wed, Jan 31, 2018 at 7:33 AM, Stephen R Guglielmo
 wrote:
> On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun  wrote:
>> On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano  wrote:
>>> Stefan Beller  writes:
 There has not been feedback for a while on this thread.
 I think that is because subtrees are not in anyone's hot
 interest area currently.

 This is definitely the right place to submit bugs.
 Looking through "git log --format="%ae %s" -S subtree",
 it seems as if Avery (apenw...@gmail.com) was mostly
 interested in developing subtrees, though I think he has
 moved on. Originally it was invented by Junio, who is
 the active maintainer of the project in 68faf68938
 (A new merge stragety 'subtree'., 2007-02-15)
>>>
>>> Thanks for trying to help, but I have *NOTHING* to do with the "git
>>> subtree" subcommand (and I personally have no interest in it).  What
>>> I did was a subtree merge strategy (i.e. "git merge -s subtree"),
>>> which is totally a different thing.
>>>
>>> David Greene offered to take it over in 2015, and then we saw some
>>> activity by David Aguilar in 2016, but otherwise the subcommand from
>>> contrib/ has pretty much been dormant these days.
>>
>> Strictly speaking, the 'git subtree' command does in fact use 'git
>> merge -s subtree' under the covers, so Junio is at least partly
>> responsible for giving me the idea :)
>>
>> I actually have never looked into how signed commits work and although
>> I still use git-subtree occasionally (it hasn't needed any
>> maintenance, for my simple use cases), I have never used it with
>> signed commits.
>>
>> git-subtree maintains a cache that maps commit ids in the "original
>> project" with their equivalents in the "merged project."  If there's
>> something magic about how commit ids work with signed commits, I could
>> imagine that causing the "no a valid object name" problems.  Or,
>> git-subtree in --squash mode actually generates new commit objects
>> using some magic of its own.  If it were to accidentally copy a
>> signature into a commit that no longer matches the original, I imagine
>> that new object might get rejected.
>>
>> Unfortunately I don't have time to look into it.  The git-subtree code
>> is pretty straightforward, though, so if Stephen has an hour or two to
>> look deeper it's probably possible to fix it up.  The tool is not
>> actually as magical and difficult as it might seem at first glance :)
>>
>> Sorry I can't help more.
>>
>> Good luck,
>>
>> Avery
>
> Thanks all for the discussion/replies.
>
> We use subtrees extensively in our environment right now. The "sub"
> repos (90+) are located on GitHub, while the "main/parent" repo is
> provided by a vendor on website hosting infrastructure.
>
> I will take a look at:
> git/Documentation/CodingGuidelines
> git/Documentation/SubmittingPatches
> git/contrib/subtree/
>
> Should I follow up in this thread with a patch (it might be a while)?
>
> Thanks!
> Steve

Hi all,

It looks like I've found the cause of the issue. I have
log.showsignature=true in my gitconfig. The toptree_for_commit()
function calls `git log` and passes the output to `git commit-tree` in
new_squash_commit(). Apparently commit-tree doesn't like GPG sigs.

The fix was simple: --no-show-signature. However, I believe this was
added in git v2.10.0, so it's not fully backwards compatible. I'm open
to suggestions on a better fix if this is not acceptable.

Thanks!


https://github.com/srguglielmo/git/commit/822c8a45d049f86ea5c59c0b434303964e4e6f3d



diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index cc033af73..dec085a23 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -475,7 +475,7 @@ squash_msg () {

 toptree_for_commit () {
commit="$1"
-   git log -1 --pretty=format:'%T' "$commit" -- || exit $?
+   git log --no-show-signature -1 --pretty=format:'%T' "$commit"
-- || exit $?
 }

 subtree_for_commit () {

Re: Bug Report: Subtrees and GPG Signed Commits

2018-02-02 Thread Junio C Hamano

Stephen R Guglielmo  writes:

> On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun  wrote:
>>
>> Sorry I can't help more.
>>
>> Good luck,
>>
>> Avery
>
> Thanks all for the discussion/replies.
>
> We use subtrees extensively in our environment right now. The "sub"
> repos (90+) are located on GitHub, while the "main/parent" repo is
> provided by a vendor on website hosting infrastructure.
>
> I will take a look at:
> git/Documentation/CodingGuidelines
> git/Documentation/SubmittingPatches
> git/contrib/subtree/
>
> Should I follow up in this thread with a patch (it might be a while)?

These three are good place to start at.  You may find the output of
"git shortlog --no-merges --since=N.months contrib/subtree" and "git
blame contrib/subtree" also a good source of whom to ask for help.
As we said on this thread, this is a corner of the contrib/ section
that nobody seems to be actively working on, so if you really depend
on it working well, you might have to take the ownership of it ;-)

Thanks.

Re: Bug Report: Subtrees and GPG Signed Commits

2018-01-31 Thread Stephen R Guglielmo

On Tue, Jan 30, 2018 at 6:37 PM, Avery Pennarun  wrote:
> On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano  wrote:
>> Stefan Beller  writes:
>>> There has not been feedback for a while on this thread.
>>> I think that is because subtrees are not in anyone's hot
>>> interest area currently.
>>>
>>> This is definitely the right place to submit bugs.
>>> Looking through "git log --format="%ae %s" -S subtree",
>>> it seems as if Avery (apenw...@gmail.com) was mostly
>>> interested in developing subtrees, though I think he has
>>> moved on. Originally it was invented by Junio, who is
>>> the active maintainer of the project in 68faf68938
>>> (A new merge stragety 'subtree'., 2007-02-15)
>>
>> Thanks for trying to help, but I have *NOTHING* to do with the "git
>> subtree" subcommand (and I personally have no interest in it).  What
>> I did was a subtree merge strategy (i.e. "git merge -s subtree"),
>> which is totally a different thing.
>>
>> David Greene offered to take it over in 2015, and then we saw some
>> activity by David Aguilar in 2016, but otherwise the subcommand from
>> contrib/ has pretty much been dormant these days.
>
> Strictly speaking, the 'git subtree' command does in fact use 'git
> merge -s subtree' under the covers, so Junio is at least partly
> responsible for giving me the idea :)
>
> I actually have never looked into how signed commits work and although
> I still use git-subtree occasionally (it hasn't needed any
> maintenance, for my simple use cases), I have never used it with
> signed commits.
>
> git-subtree maintains a cache that maps commit ids in the "original
> project" with their equivalents in the "merged project."  If there's
> something magic about how commit ids work with signed commits, I could
> imagine that causing the "no a valid object name" problems.  Or,
> git-subtree in --squash mode actually generates new commit objects
> using some magic of its own.  If it were to accidentally copy a
> signature into a commit that no longer matches the original, I imagine
> that new object might get rejected.
>
> Unfortunately I don't have time to look into it.  The git-subtree code
> is pretty straightforward, though, so if Stephen has an hour or two to
> look deeper it's probably possible to fix it up.  The tool is not
> actually as magical and difficult as it might seem at first glance :)
>
> Sorry I can't help more.
>
> Good luck,
>
> Avery

Thanks all for the discussion/replies.

We use subtrees extensively in our environment right now. The "sub"
repos (90+) are located on GitHub, while the "main/parent" repo is
provided by a vendor on website hosting infrastructure.

I will take a look at:
git/Documentation/CodingGuidelines
git/Documentation/SubmittingPatches
git/contrib/subtree/

Should I follow up in this thread with a patch (it might be a while)?

Thanks!
Steve

Re: Bug Report: Subtrees and GPG Signed Commits

2018-01-30 Thread Avery Pennarun

On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano  wrote:
> Stefan Beller  writes:
>> There has not been feedback for a while on this thread.
>> I think that is because subtrees are not in anyone's hot
>> interest area currently.
>>
>> This is definitely the right place to submit bugs.
>> Looking through "git log --format="%ae %s" -S subtree",
>> it seems as if Avery (apenw...@gmail.com) was mostly
>> interested in developing subtrees, though I think he has
>> moved on. Originally it was invented by Junio, who is
>> the active maintainer of the project in 68faf68938
>> (A new merge stragety 'subtree'., 2007-02-15)
>
> Thanks for trying to help, but I have *NOTHING* to do with the "git
> subtree" subcommand (and I personally have no interest in it).  What
> I did was a subtree merge strategy (i.e. "git merge -s subtree"),
> which is totally a different thing.
>
> David Greene offered to take it over in 2015, and then we saw some
> activity by David Aguilar in 2016, but otherwise the subcommand from
> contrib/ has pretty much been dormant these days.

Strictly speaking, the 'git subtree' command does in fact use 'git
merge -s subtree' under the covers, so Junio is at least partly
responsible for giving me the idea :)

I actually have never looked into how signed commits work and although
I still use git-subtree occasionally (it hasn't needed any
maintenance, for my simple use cases), I have never used it with
signed commits.

git-subtree maintains a cache that maps commit ids in the "original
project" with their equivalents in the "merged project."  If there's
something magic about how commit ids work with signed commits, I could
imagine that causing the "no a valid object name" problems.  Or,
git-subtree in --squash mode actually generates new commit objects
using some magic of its own.  If it were to accidentally copy a
signature into a commit that no longer matches the original, I imagine
that new object might get rejected.

Unfortunately I don't have time to look into it.  The git-subtree code
is pretty straightforward, though, so if Stephen has an hour or two to
look deeper it's probably possible to fix it up.  The tool is not
actually as magical and difficult as it might seem at first glance :)

Sorry I can't help more.

Good luck,

Avery

Re: Bug Report: Subtrees and GPG Signed Commits

2018-01-30 Thread Junio C Hamano

Stefan Beller  writes:

> There has not been feedback for a while on this thread.
> I think that is because subtrees are not in anyone's hot
> interest area currently.
>
> This is definitely the right place to submit bugs.
> Looking through "git log --format="%ae %s" -S subtree",
> it seems as if Avery (apenw...@gmail.com) was mostly
> interested in developing subtrees, though I think he has
> moved on. Originally it was invented by Junio, who is
> the active maintainer of the project in 68faf68938
> (A new merge stragety 'subtree'., 2007-02-15)

Thanks for trying to help, but I have *NOTHING* to do with the "git
subtree" subcommand (and I personally have no interest in it).  What
I did was a subtree merge strategy (i.e. "git merge -s subtree"),
which is totally a different thing.

David Greene offered to take it over in 2015, and then we saw some
activity by David Aguilar in 2016, but otherwise the subcommand from
contrib/ has pretty much been dormant these days.

Re: Bug Report: Subtrees and GPG Signed Commits

2018-01-30 Thread Stefan Beller

On Tue, Jan 30, 2018 at 11:15 AM, Stephen R Guglielmo
<srguglie...@gmail.com> wrote:
> Hi, just following up on this bug report. I have not heard back. Is
> there additional information that's needed? Is there a better place to
> file bug reports?
>
> Additionally, I have confirmed that this bug still exists with git
> version 2.16.1.
>
> Thanks
>
> On Thu, Jan 18, 2018 at 11:19 AM, Stephen R Guglielmo
> <srguglie...@gmail.com> wrote:
>> Hi, just following up on this bug report. I have not heard back. Is
>> there additional information that's needed? Is there a better place to
>> file bug reports?
>>
>> Thanks
>>
>> On Sat, Jan 6, 2018 at 5:45 PM, Stephen R Guglielmo
>> <srguglie...@gmail.com> wrote:
>>> Hi all,
>>>
>>> I've noticed an issue regarding the use of `git subtree add` and `git
>>> subtree pull` when the subtree repository's commit (either HEAD or
>>> whatever commit specified by the subtree command) is signed with GPG.
>>> It seems to work properly if the commit is not signed but previous
>>> commits are.
>>>
>>> The gist of the issue is that `git subtree add` does not add the
>>> subree properly and a "fatal: Not a valid object name" error is
>>> thrown. Running `git subtree pull` does not pull any upstream changes
>>> after that ("'subtree' was never added").
>>>
>>> I have not done extensive testing, however, below are instructions to
>>> reproduce the issue. This was tested using git version 2.15.1
>>> installed via Homebrew on MacOS. I did not test with the built-in
>>> version of git on MacOS.
>>>
>>> Thanks,
>>> Steve
>>>
>>> # Create a new repository
>>> mkdir repoA && cd repoA
>>> git init
>>> echo "Test File in Repo A" > FileA
>>> git add -A && git commit -m 'Initial commit in repo A'
>>>
>>> # Create a second repository
>>> cd .. && mkdir repoB && cd repoB
>>> git init
>>> echo "Test File in Repo B" > FileB
>>> git add -A && git commit -m 'Initial commit in repo B'
>>>
>>> # Create a signed commit in repo B
>>> echo "Signed Commit" >> FileB
>>> git commit -a -S  -m 'Signed commit in repo B'
>>>
>>> # Now, add repoB as a subtree of RepoA
>>> cd ../repoA
>>> git subtree add --prefix repoB_subtree/ ../repoB/ master --squash
>>> # Output:
>>> git fetch ../repoB/ master
>>> warning: no common commits
>>> remote: Counting objects: 6, done.
>>> remote: Compressing objects: 100% (2/2), done.
>>> remote: Total 6 (delta 0), reused 0 (delta 0)
>>> Unpacking objects: 100% (6/6), done.
>>> From ../repoB
>>>  * branchmaster -> FETCH_HEAD
>>> fatal: Not a valid object name gpg: Signature made Sat Jan  6 17:38:31 2018 
>>> EST
>>> gpg:using RSA key 6900E9CFDD39B6A741D601F50999759F2DCF3E7C
>>> gpg: Good signature from "Stephen Robert Guglielmo (Temple University
>>> Computer Services) <s...@temple.edu>" [ultimate]
>>> Primary key fingerprint: 6900 E9CF DD39 B6A7 41D6  01F5 0999 759F 2DCF 3E7C
>>> 4b700b1a4ebb9e2c1011aafd6b0f720b38f059a4
>>> # Note, git exits with status 128 at this point.
>>>
>>> # FileB was in fact added and staged to repoA, despite the "fatal"
>>> above. Commit it:
>>> git commit -m 'Add repoB subtree'
>>>
>>> # Ok, let's make another commit in repoB and try a `subtree pull`
>>> instead of `subtree add`
>>> cd ../repoB
>>> echo "Another Line" >> FileB
>>> git commit -a -S -m 'Another signed commit'
>>> cd ../repoA
>>> git subtree pull --prefix repoB_subtree/ ../repoB master --squash
>>> # Output:
>>> warning: no common commits
>>> remote: Counting objects: 9, done.
>>> remote: Compressing objects: 100% (3/3), done.
>>> remote: Total 9 (delta 0), reused 0 (delta 0)
>>> Unpacking objects: 100% (9/9), done.
>>> From ../repoB
>>>  * branchmaster -> FETCH_HEAD
>>> Can't squash-merge: 'repoB_subtree' was never added.
>>> # Note, git exits with status 1 at this point.
>>>
>>> # RepoB's third commit ('Another signed commit') is not pulled into
>>> the subree in repo A.
>>> # This can be verified by running a diff:
>>> diff -qr --exclude ".git" repoB_subtree ../repoB
>>> # Output:
>>> Files repoB_subtree/FileB and ../repoB/FileB differ

There has not been feedback for a while on this thread.
I think that is because subtrees are not in anyone's hot
interest area currently.

This is definitely the right place to submit bugs.
Looking through "git log --format="%ae %s" -S subtree",
it seems as if Avery (apenw...@gmail.com) was mostly
interested in developing subtrees, though I think he has
moved on. Originally it was invented by Junio, who is
the active maintainer of the project in 68faf68938
(A new merge stragety 'subtree'., 2007-02-15)

Thanks,
Stefan

Re: Bug Report: Subtrees and GPG Signed Commits

2018-01-30 Thread Stephen R Guglielmo

Hi, just following up on this bug report. I have not heard back. Is
there additional information that's needed? Is there a better place to
file bug reports?

Additionally, I have confirmed that this bug still exists with git
version 2.16.1.

Thanks

On Thu, Jan 18, 2018 at 11:19 AM, Stephen R Guglielmo
<srguglie...@gmail.com> wrote:
> Hi, just following up on this bug report. I have not heard back. Is
> there additional information that's needed? Is there a better place to
> file bug reports?
>
> Thanks
>
> On Sat, Jan 6, 2018 at 5:45 PM, Stephen R Guglielmo
> <srguglie...@gmail.com> wrote:
>> Hi all,
>>
>> I've noticed an issue regarding the use of `git subtree add` and `git
>> subtree pull` when the subtree repository's commit (either HEAD or
>> whatever commit specified by the subtree command) is signed with GPG.
>> It seems to work properly if the commit is not signed but previous
>> commits are.
>>
>> The gist of the issue is that `git subtree add` does not add the
>> subree properly and a "fatal: Not a valid object name" error is
>> thrown. Running `git subtree pull` does not pull any upstream changes
>> after that ("'subtree' was never added").
>>
>> I have not done extensive testing, however, below are instructions to
>> reproduce the issue. This was tested using git version 2.15.1
>> installed via Homebrew on MacOS. I did not test with the built-in
>> version of git on MacOS.
>>
>> Thanks,
>> Steve
>>
>> # Create a new repository
>> mkdir repoA && cd repoA
>> git init
>> echo "Test File in Repo A" > FileA
>> git add -A && git commit -m 'Initial commit in repo A'
>>
>> # Create a second repository
>> cd .. && mkdir repoB && cd repoB
>> git init
>> echo "Test File in Repo B" > FileB
>> git add -A && git commit -m 'Initial commit in repo B'
>>
>> # Create a signed commit in repo B
>> echo "Signed Commit" >> FileB
>> git commit -a -S  -m 'Signed commit in repo B'
>>
>> # Now, add repoB as a subtree of RepoA
>> cd ../repoA
>> git subtree add --prefix repoB_subtree/ ../repoB/ master --squash
>> # Output:
>> git fetch ../repoB/ master
>> warning: no common commits
>> remote: Counting objects: 6, done.
>> remote: Compressing objects: 100% (2/2), done.
>> remote: Total 6 (delta 0), reused 0 (delta 0)
>> Unpacking objects: 100% (6/6), done.
>> From ../repoB
>>  * branchmaster -> FETCH_HEAD
>> fatal: Not a valid object name gpg: Signature made Sat Jan  6 17:38:31 2018 
>> EST
>> gpg:using RSA key 6900E9CFDD39B6A741D601F50999759F2DCF3E7C
>> gpg: Good signature from "Stephen Robert Guglielmo (Temple University
>> Computer Services) <s...@temple.edu>" [ultimate]
>> Primary key fingerprint: 6900 E9CF DD39 B6A7 41D6  01F5 0999 759F 2DCF 3E7C
>> 4b700b1a4ebb9e2c1011aafd6b0f720b38f059a4
>> # Note, git exits with status 128 at this point.
>>
>> # FileB was in fact added and staged to repoA, despite the "fatal"
>> above. Commit it:
>> git commit -m 'Add repoB subtree'
>>
>> # Ok, let's make another commit in repoB and try a `subtree pull`
>> instead of `subtree add`
>> cd ../repoB
>> echo "Another Line" >> FileB
>> git commit -a -S -m 'Another signed commit'
>> cd ../repoA
>> git subtree pull --prefix repoB_subtree/ ../repoB master --squash
>> # Output:
>> warning: no common commits
>> remote: Counting objects: 9, done.
>> remote: Compressing objects: 100% (3/3), done.
>> remote: Total 9 (delta 0), reused 0 (delta 0)
>> Unpacking objects: 100% (9/9), done.
>> From ../repoB
>>  * branchmaster -> FETCH_HEAD
>> Can't squash-merge: 'repoB_subtree' was never added.
>> # Note, git exits with status 1 at this point.
>>
>> # RepoB's third commit ('Another signed commit') is not pulled into
>> the subree in repo A.
>> # This can be verified by running a diff:
>> diff -qr --exclude ".git" repoB_subtree ../repoB
>> # Output:
>> Files repoB_subtree/FileB and ../repoB/FileB differ

Re: git merge-tree: bug report and some feature requests

2018-01-24 Thread Elijah Newren

On Tue, Jan 23, 2018 at 3:52 AM, Edward Thomson
 wrote:
> Indeed, when I added merge to libgit2, we put the higher-level conflict
> analysis into application code because there was not much interest in it
> at the time.  I've been meaning to add this to `git_status` in libgit2,
> but it's not been a high priority.

That sounds pretty cool.  I'm actually dealing with a similar problem
in git itself with my replacement merge strategy; since I try to
perform the merge in-core, and then only try to update the index and
working copy if there'd be no loss of information (no overwriting of
dirty or untracked content), there's a delay between when a conflict
is detected and when I can report it, meaning that I have to store
information about the conflict somehow, and then report later.  So
that means I have to go through the trouble of storing this
information internally, which naturally raises the question of whether
I want to provide this information to the user in some fashion other
than just simple "CONFLICT: ..." messages printed out to the user.

>> This which
>> leaves it unclear what exactly the conflict was, at which point any
>> user (read: porcelain developer) will end up having to recreate some
>> merge logic to figure out what went wrong. And if merge-tree starts
>> doing rename detection, the user might then have to emulate that as
>> well.
>
> That's not a good idea.  Trying to figure out what merge did would be
> painful at best, and likely impossible, since a rename conflict is
> recorded in the main index without any way to piece it together.  eg:
>
> 100644 deadbeefdeadbeefdeadbeefdeadbeefdeadbeef 1   bar.c
> 100644 cafec4fecafec4fecafec4fecafec4fecafec4fe 2   bar.c
> 100644 c4cc188a892898e13927dc4a02e7f68814b874b2 1   foo.c
> 100644 71f5af150b25e3d2d67ff46759311401036f 2   foo.c
> 100644 351cfbdd55d656edd2c5c995aae3caafb9ec11fa 3   rename1.c
> 100644 e407c7d138fb457674c3b114fcf47748169ab0c5 3   rename2.c
>
> This is the main index that results when bar.c has a rename/edit
> conflict, and foo.c also has a rename/edit conflict.  One was renamed
> to rename1.c and the other to rename2.c.  Trying to determine which is
> which _after the fact_ would be regrettable.  Especially since rename
> detection is not static - you would need to know the thresholds that
> were configured at the time merge was performed and try to replay
> the rename detection with that.
>
> libgit2 records a `NAME` section in the index that pairs the rename
> detection decisions that it performed so that you can analyze them
> and display them after the fact.

Ooh, I like that idea.  Could we do the same in git itself?  Having
not messed with the index format at all, what commands do users use to
view this supplementary info?

Also, if you have this NAME section, you could make other commands
smarter.  For example, if you had a normal content conflict on some
file without rename detection being involved, you'd expect the index
to look something like

100644 deadbeefdeadbeefdeadbeefdeadbeefdeadbeef 1   file.c
100644 cafec4fecafec4fecafec4fecafec4fecafec4fe 2   file.c
100644 ba5eba11ba5eba11ba5eba11ba5eba11ba5eba11 3   file.c

and then when you do a 'git add file.c' you expect all the higher
stages to go away, i.e.

100644 5ca1ab1e5ca1ab1e5ca1ab1e5ca1ab1e5ca1ab1e 0   file.c

With your NAME section trick, could one expect 'git add rename1.c' to
delete not only the higher stage for rename1.c but also the two for
whichever of bar.c or foo.c is relevant?

Elijah

Re: git merge-tree: bug report and some feature requests

2018-01-24 Thread Josh Bleecher Snyder

Thanks, Ed. I think I'll pursue the libgit2 route; sounds promising.


>> But the alternative appears to be punting entirely, as libgit2 does,
>> and merely providing something akin to three index entries.
>
> Indeed, when I added merge to libgit2, we put the higher-level conflict
> analysis into application code because there was not much interest in it
> at the time.  I've been meaning to add this to `git_status` in libgit2,
> but it's not been a high priority.

Is your conflict analysis application code public? I might be game to
do some of the legwork to get it into libgit2's git_status (although
I'm probably not the right person to do the API design). At a minimum,
it would be helpful as a reference, as I'm probably about to recreate
some subset of it myself.


-josh

Re: git merge-tree: bug report and some feature requests

2018-01-23 Thread Edward Thomson

On Tue, Jan 23, 2018 at 7:08 AM, Josh Bleecher Snyder
 wrote:
> Looking over your list above, at a minimum, libgit2 might not have a
> particularly good way to represent submodule/file or
> submodule/directory conflicts, because is-a-submodule is defined
> external to a git_index_entry.

libgit2 should detect submodule/file and submodule/directory
conflicts.

While, yes, some metadata about the submodule is located outside the
index, you can look at the mode to determine that this _is_ a
submodule.  You should be able to reliably detect submodule/file
conflicts because one will be a regular or executable file (mode
0100644 or 0100755), while the other entry at the same path will
be a gitlink (mode 016).

Similarly, submodule/directory conflict detection works just like
regular file/directory conflict detection.  If some path `foo` is
a submodule (or a regular file) then some path `foo/bar` existing
in the other side of the merge causes a conflict.

> Cataloging or special-casing all possible conflict types does seem
> unwise because of the sheer number of kinds of conflicts.
>
> But the alternative appears to be punting entirely, as libgit2 does,
> and merely providing something akin to three index entries.

Indeed, when I added merge to libgit2, we put the higher-level conflict
analysis into application code because there was not much interest in it
at the time.  I've been meaning to add this to `git_status` in libgit2,
but it's not been a high priority.

> This which
> leaves it unclear what exactly the conflict was, at which point any
> user (read: porcelain developer) will end up having to recreate some
> merge logic to figure out what went wrong. And if merge-tree starts
> doing rename detection, the user might then have to emulate that as
> well.

That's not a good idea.  Trying to figure out what merge did would be
painful at best, and likely impossible, since a rename conflict is
recorded in the main index without any way to piece it together.  eg:

100644 deadbeefdeadbeefdeadbeefdeadbeefdeadbeef 1   bar.c
100644 cafec4fecafec4fecafec4fecafec4fecafec4fe 2   bar.c
100644 c4cc188a892898e13927dc4a02e7f68814b874b2 1   foo.c
100644 71f5af150b25e3d2d67ff46759311401036f 2   foo.c
100644 351cfbdd55d656edd2c5c995aae3caafb9ec11fa 3   rename1.c
100644 e407c7d138fb457674c3b114fcf47748169ab0c5 3   rename2.c

This is the main index that results when bar.c has a rename/edit
conflict, and foo.c also has a rename/edit conflict.  One was renamed
to rename1.c and the other to rename2.c.  Trying to determine which is
which _after the fact_ would be regrettable.  Especially since rename
detection is not static - you would need to know the thresholds that
were configured at the time merge was performed and try to replay
the rename detection with that.

libgit2 records a `NAME` section in the index that pairs the rename
detection decisions that it performed so that you can analyze them
and display them after the fact.

-ed

Re: git merge-tree: bug report and some feature requests

2018-01-22 Thread Josh Bleecher Snyder

>> I'm experimenting with some new porcelain for interactive rebase. One
>> goal is to leave the work tree untouched for most operations. It looks
>> to me like 'git merge-tree' may be the right plumbing command for
>> doing the merge part of the pick work of the todo list, one commit at
>> a time. If I'm wrong about this, I'd love pointers; what follows may
>> still be interesting anyway.
>
> I don't have a concrete alternative (yet?) but here are some pointers
> to two alternate merge-without-touching-working-tree possibilities, if
> your current route doesn't pan out as well as you like:
>
> I posted some patches last year to make merge-recursive.c be able to
> do merges without touching the working tree.  Adding a few flags would
> then enable it for any of 'merge', 'cherry-pick', 'am', or
> 'rebase'...though for unsuccessful merges, there's a clear question of
> what/how conflicts should be reported to the user.  That probably
> depends a fair amount on the precise use-case.
>
> Although that series was placed on the backburner due to the immediate
> driver of the feature going away, I'm still interested in such a
> change, though I think it would fall out as a nice side effect of
> implementing Junio's proposed ideal-world-merge-recursive rewrite[1].
> I have started looking into that[2], but no guarantees about how
> quickly I'll find time to finish or even whether I will.
>
> [1] https://public-inbox.org/git/xmqqd147kpdm@gitster.mtv.corp.google.com
> [2] https://github.com/newren/git/blob/ort/ort-cover-letter contains
> overview of ideas and notes to myself about what I was hoping to
> accomplish; currently it doesn't even compile or do anything

Thanks for the pointer. That does seem promising.

And yes, I see now that serialization of conflicts is decidedly
challenging. More on that below.


>> 4. API suggestion
>>
>> Here's what I really want 'git merge-tree' to output. :)
> ...
>> If the merge had conflicts, write the "as merged as possible" tree to
>
> You'd need to define "as merged as possible" more carefully, because I
> thought you meant a tree containing all the three-way merge conflict
> markers and such being present in the "resolved" file, but from your
> parenthetical note below it appears you think that is a different tree
> that would also be useful to diff against the first one.  That leaves
> me wondering what the first tree is. (Is it just the tree where for
> each path, if that path had no conflicts associated with it then it's
> the merge-resolved-file, and otherwise it's the file contents from the
> merge-base?).

FWIW, the parenthetical suggestion was indeed what I had in mind. But
non-content conflicts appear to make that a non-starter. Or at least
woefully incomplete.


> Both of these trees are actually rather non-trivial to define.  The
> wording above isn't actually sufficient, because content conflicts
> aren't the only kind of conflict.  More on that below.
>
> There is already a bunch of code in merge-recursive.c to create a
> forcibly-merged-accepting-conflict-markers-in-the-resolution and
> record it as a tree (this is used for creating virtual merge bases in
> the recursive case, namely when there isn't a single merge-base for
> the two branches you are merging).  It might be reusable for what you
> want here, but it's not immediately clear whether all the things it
> does are appropriate; someone would have to consider the non-content
> (path-based) conflicts carefully.

Ack. I assume this is also the code that generates the existing 'git
merge-tree' patches, which includes conflict markers.


>> the object database and give me its sha, and then also give me the
>> three-way merge diff output for all conflicts, as a regular patch
>> against that tree, using full path names and shas. (Alternatively,
>> maybe better, give me a second sha for a tree containing all the
>> three-way merge diff patches applied, which I can diff against the
>> first tree to find the conflict patches.)
>
> As far as I can tell, you're assuming that it's possible with two
> trees that are crafted "just right", that you can tell where the merge
> conflicts are, with binary files being your only difficulty.  Content
> conflicts aren't the only type that exist; there are also path-based
> conflicts.  These type of conflicts also make it difficult to know how
> the two trees you are requesting should even be created.
>
> For example, if there is a modify/delete conflict, how can that be
> determined from just two trees?  If the first tree has the base
> version of the file, then the second tree either has a file at the
> same position or it doesn't.  Neither case looks like a conflict, but
> the original merge had one.  You need more information.  The exact
> same thing can be said for rename/delete conflicts.
>
> Similarly, rename/add (one side renames an existing file to some new
> path (say, "new_path"), and the other adds a brand new file at
> "new_path), or rename/rename(2to1) (each

Re: git merge-tree: bug report and some feature requests

2018-01-22 Thread Elijah Newren

On Sat, Jan 20, 2018 at 7:00 PM, Josh Bleecher Snyder
 wrote:
> Hi, all.
>
> I'm experimenting with some new porcelain for interactive rebase. One
> goal is to leave the work tree untouched for most operations. It looks
> to me like 'git merge-tree' may be the right plumbing command for
> doing the merge part of the pick work of the todo list, one commit at
> a time. If I'm wrong about this, I'd love pointers; what follows may
> still be interesting anyway.

I don't have a concrete alternative (yet?) but here are some pointers
to two alternate merge-without-touching-working-tree possibilities, if
your current route doesn't pan out as well as you like:

I posted some patches last year to make merge-recursive.c be able to
do merges without touching the working tree.  Adding a few flags would
then enable it for any of 'merge', 'cherry-pick', 'am', or
'rebase'...though for unsuccessful merges, there's a clear question of
what/how conflicts should be reported to the user.  That probably
depends a fair amount on the precise use-case.

Although that series was placed on the backburner due to the immediate
driver of the feature going away, I'm still interested in such a
change, though I think it would fall out as a nice side effect of
implementing Junio's proposed ideal-world-merge-recursive rewrite[1].
I have started looking into that[2], but no guarantees about how
quickly I'll find time to finish or even whether I will.

[1] https://public-inbox.org/git/xmqqd147kpdm@gitster.mtv.corp.google.com
[2] https://github.com/newren/git/blob/ort/ort-cover-letter contains
overview of ideas and notes to myself about what I was hoping to
accomplish; currently it doesn't even compile or do anything

> 4. API suggestion
>
> Here's what I really want 'git merge-tree' to output. :)
...
> If the merge had conflicts, write the "as merged as possible" tree to

You'd need to define "as merged as possible" more carefully, because I
thought you meant a tree containing all the three-way merge conflict
markers and such being present in the "resolved" file, but from your
parenthetical note below it appears you think that is a different tree
that would also be useful to diff against the first one.  That leaves
me wondering what the first tree is. (Is it just the tree where for
each path, if that path had no conflicts associated with it then it's
the merge-resolved-file, and otherwise it's the file contents from the
merge-base?).

Both of these trees are actually rather non-trivial to define.  The
wording above isn't actually sufficient, because content conflicts
aren't the only kind of conflict.  More on that below.

There is already a bunch of code in merge-recursive.c to create a
forcibly-merged-accepting-conflict-markers-in-the-resolution and
record it as a tree (this is used for creating virtual merge bases in
the recursive case, namely when there isn't a single merge-base for
the two branches you are merging).  It might be reusable for what you
want here, but it's not immediately clear whether all the things it
does are appropriate; someone would have to consider the non-content
(path-based) conflicts carefully.

> the object database and give me its sha, and then also give me the
> three-way merge diff output for all conflicts, as a regular patch
> against that tree, using full path names and shas. (Alternatively,
> maybe better, give me a second sha for a tree containing all the
> three-way merge diff patches applied, which I can diff against the
> first tree to find the conflict patches.)

As far as I can tell, you're assuming that it's possible with two
trees that are crafted "just right", that you can tell where the merge
conflicts are, with binary files being your only difficulty.  Content
conflicts aren't the only type that exist; there are also path-based
conflicts.  These type of conflicts also make it difficult to know how
the two trees you are requesting should even be created.

For example, if there is a modify/delete conflict, how can that be
determined from just two trees?  If the first tree has the base
version of the file, then the second tree either has a file at the
same position or it doesn't.  Neither case looks like a conflict, but
the original merge had one.  You need more information.  The exact
same thing can be said for rename/delete conflicts.

Similarly, rename/add (one side renames an existing file to some new
path (say, "new_path"), and the other adds a brand new file at
"new_path), or rename/rename(2to1) (each side renames a different file
to the same location), won't be detectable just by diffing two trees.
These are often handled by moving both files to some other location,
so there's no way to record in a tree that there was a conflict.

rename/rename(1to2) is similar, but instead of two different original
files being renamed to the same thing, this is one file being renamed
differently on different sides of history.

I know that several of the examples above involved rename

Re: git merge-tree: bug report and some feature requests

2018-01-21 Thread Ævar Arnfjörð Bjarmason


On Sun, Jan 21 2018, Josh Bleecher Snyder jotted:

> 3. Feature suggestion
>
> There's no direct indication of whether any given file's merge
> succeeded. Currently I sniff for merge conflicts by looking for
> "+<<< .our", which feels like an ugly kludge. Could we provide an
> explicit indicator? (And maybe also one for binary vs text
> processing?)
>
> Note that binary file merge conflicts don't generate patches with
> three-way merge markers but instead say "warning: Cannot merge binary
> files: binary (.our vs. .their)". Looking for this case even further
> complicates the output parser.

I thought I had a way to do this, but looking back in my logs I find
that I was just using:

git merge-tree $(git merge-base A B) A B | grep -e '^\+==='; echo $?

I.e. a variation of what you're doing, which as you note won't work for
binary files.

git merge-tree: bug report and some feature requests

2018-01-20 Thread Josh Bleecher Snyder

Hi, all.

I'm experimenting with some new porcelain for interactive rebase. One
goal is to leave the work tree untouched for most operations. It looks
to me like 'git merge-tree' may be the right plumbing command for
doing the merge part of the pick work of the todo list, one commit at
a time. If I'm wrong about this, I'd love pointers; what follows may
still be interesting anyway.

I've encountered some bumps with 'git merge-tree'. A bug report and
some feature requests follow. Apologies for the long email.


1. Bug

When a binary file containing NUL is added on only one side, the
resulting patch is malformed. Reproduction script:

mkdir test
cd test
git init .
touch shared
git add shared
git commit -m "base"
git checkout -b left
echo "left" > x
printf '\1\0\1\n' > binary
git add x binary
git commit -m "left"
git checkout master
git checkout -b right
echo "right" > x
git add x
git commit -m "right"
git merge-tree master right left
git merge-tree master right left | xxd
cd ..
rm -rf test

The merge-tree results I get with 2.15.1 are:

added in remote
  their  100644 ddc50ce55647db1421b18aa33417442e29f63d2f binary
@@ -0,0 +1 @@
+added in both
  our100644 c376d892e8b105bd712d06ec5162b5f31ce949c3 x
  their  100644 45cf141ba67d59203f02a54f03162f3fcef57830 x
@@ -1 +1,5 @@
+<<<<<<< .our
 right
+===
+left
+>>>>>>> .their

: 6164 6465 6420 696e 2072 656d 6f74 650a  added in remote.
0010: 2020 7468 6569 7220 2031 3030 3634 3420their  100644
0020: 6464 6335 3063 6535 3536 3437 6462 3134  ddc50ce55647db14
0030: 3231 6231 3861 6133 3334 3137 3434 3265  21b18aa33417442e
0040: 3239 6636 3364 3266 2062 696e 6172 790a  29f63d2f binary.
0050: 4040 202d 302c 3020 2b31 2040 400a 2b01  @@ -0,0 +1 @@.+.
0060: 6164 6465 6420 696e 2062 6f74 680a 2020  added in both.
0070: 6f75 7220 2020 2031 3030 3634 3420 6333  our100644 c3
0080: 3736 6438 3932 6538 6231 3035 6264 3731  76d892e8b105bd71
0090: 3264 3036 6563 3531 3632 6235 6633 3163  2d06ec5162b5f31c
00a0: 6539 3439 6333 2078 0a20 2074 6865 6972  e949c3 x.  their
00b0: 2020 3130 3036 3434 2034 3563 6631 3431100644 45cf141
00c0: 6261 3637 6435 3932 3033 6630 3261 3534  ba67d59203f02a54
00d0: 6630 3331 3632 6633 6663 6566 3537 3833  f03162f3fcef5783
00e0: 3020 780a 4040 202d 3120 2b31 2c35 2040  0 x.@@ -1 +1,5 @
00f0: 400a 2b3c 3c3c 3c3c 3c3c 202e 6f75 720a  @.+<<<<<<< .our.
0100: 2072 6967 6874 0a2b 3d3d 3d3d 3d3d 3d0a   right.+===.
0110: 2b6c 6566 740a 2b3e 3e3e 3e3e 3e3e 202e  +left.+>>>>>>> .
0120: 7468 6569 720a   their.

Note that the "added in both" explanation appears to be part of the
diff for binary. The diff line should be '\1\0\1\n', but it is only
'\1', obviously suggesting a C string operation gone awry.

I haven't checked whether regular 'git diff' operations contain a
similar bug. (The NUL would have to be pretty far into the file, to
confuse the binary file detection heuristic, but that is possible.)

I don't see any particularly good work-arounds. Looking for all
possible explanations as a trigger to detect a malformed patch runs
into false positives with the explanation "merged", which occurs in
regular code.


2. Feature suggestion

Related to the bug, may I suggest a flag to omit unnecessary patches?
For "added in remote" and "deleted in remote", I don't actually need
the patch--I can grab the blob contents from the SHA myself if needed.
These cases need special handling anyway (to create/delete the file),
so the (often large) patch doesn't add much anyway. This would provide
a workaround for the bug.


3. Feature suggestion

There's no direct indication of whether any given file's merge
succeeded. Currently I sniff for merge conflicts by looking for
"+<<<<<<< .our", which feels like an ugly kludge. Could we provide an
explicit indicator? (And maybe also one for binary vs text
processing?)

Note that binary file merge conflicts don't generate patches with
three-way merge markers but instead say "warning: Cannot merge binary
files: binary (.our vs. .their)". Looking for this case even further
complicates the output parser.


4. API suggestion

Here's what I really want 'git merge-tree' to output. :)

If the merge had no conflicts, write the resulting tree to the object
database and give me its sha. I can always diff that tree against
branch1's tree if I want to see what has changed.

If the merge had conflicts, write the "as merged as possible" tree to
the object database and give me its sha, and then also give me the
three-way merge diff output for all conflicts, as a regular patch
against that tree, using full path names and shas. (Alternatively,
maybe better, give me a second sha for a tree containing

Re: Bug Report: Subtrees and GPG Signed Commits

2018-01-18 Thread Stephen R Guglielmo

Hi, just following up on this bug report. I have not heard back. Is
there additional information that's needed? Is there a better place to
file bug reports?

Thanks

On Sat, Jan 6, 2018 at 5:45 PM, Stephen R Guglielmo
<srguglie...@gmail.com> wrote:
> Hi all,
>
> I've noticed an issue regarding the use of `git subtree add` and `git
> subtree pull` when the subtree repository's commit (either HEAD or
> whatever commit specified by the subtree command) is signed with GPG.
> It seems to work properly if the commit is not signed but previous
> commits are.
>
> The gist of the issue is that `git subtree add` does not add the
> subree properly and a "fatal: Not a valid object name" error is
> thrown. Running `git subtree pull` does not pull any upstream changes
> after that ("'subtree' was never added").
>
> I have not done extensive testing, however, below are instructions to
> reproduce the issue. This was tested using git version 2.15.1
> installed via Homebrew on MacOS. I did not test with the built-in
> version of git on MacOS.
>
> Thanks,
> Steve
>
> # Create a new repository
> mkdir repoA && cd repoA
> git init
> echo "Test File in Repo A" > FileA
> git add -A && git commit -m 'Initial commit in repo A'
>
> # Create a second repository
> cd .. && mkdir repoB && cd repoB
> git init
> echo "Test File in Repo B" > FileB
> git add -A && git commit -m 'Initial commit in repo B'
>
> # Create a signed commit in repo B
> echo "Signed Commit" >> FileB
> git commit -a -S  -m 'Signed commit in repo B'
>
> # Now, add repoB as a subtree of RepoA
> cd ../repoA
> git subtree add --prefix repoB_subtree/ ../repoB/ master --squash
> # Output:
> git fetch ../repoB/ master
> warning: no common commits
> remote: Counting objects: 6, done.
> remote: Compressing objects: 100% (2/2), done.
> remote: Total 6 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (6/6), done.
> From ../repoB
>  * branchmaster -> FETCH_HEAD
> fatal: Not a valid object name gpg: Signature made Sat Jan  6 17:38:31 2018 
> EST
> gpg:using RSA key 6900E9CFDD39B6A741D601F50999759F2DCF3E7C
> gpg: Good signature from "Stephen Robert Guglielmo (Temple University
> Computer Services) <s...@temple.edu>" [ultimate]
> Primary key fingerprint: 6900 E9CF DD39 B6A7 41D6  01F5 0999 759F 2DCF 3E7C
> 4b700b1a4ebb9e2c1011aafd6b0f720b38f059a4
> # Note, git exits with status 128 at this point.
>
> # FileB was in fact added and staged to repoA, despite the "fatal"
> above. Commit it:
> git commit -m 'Add repoB subtree'
>
> # Ok, let's make another commit in repoB and try a `subtree pull`
> instead of `subtree add`
> cd ../repoB
> echo "Another Line" >> FileB
> git commit -a -S -m 'Another signed commit'
> cd ../repoA
> git subtree pull --prefix repoB_subtree/ ../repoB master --squash
> # Output:
> warning: no common commits
> remote: Counting objects: 9, done.
> remote: Compressing objects: 100% (3/3), done.
> remote: Total 9 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (9/9), done.
> From ../repoB
>  * branchmaster -> FETCH_HEAD
> Can't squash-merge: 'repoB_subtree' was never added.
> # Note, git exits with status 1 at this point.
>
> # RepoB's third commit ('Another signed commit') is not pulled into
> the subree in repo A.
> # This can be verified by running a diff:
> diff -qr --exclude ".git" repoB_subtree ../repoB
> # Output:
> Files repoB_subtree/FileB and ../repoB/FileB differ

Re: Possible bug report: git checkout tag problem

2018-01-08 Thread Johannes Schindelin

Hi Myles,

On Mon, 8 Jan 2018, Myles Fong wrote:

> Brief description:
> When two tags are pointing to the same commit, e.g. tagA and tagB, if I
> do `git checkout tagA` then `git checkout tagB`,  and then `git status`,
> it shows `HEAD detached at tagA`
> 
> Expected behaviour:
> I'm expecting it to show `HEAD detached at tagB`, though I understand
> this makes no difference for the repo code, but still a bit confusing
> for me.

The problem here is that Git understands something different from what you
intended: if you say `git checkout `, Git is mostly interested
in the revision, i.e. the commit. Only if that parameter refers to a local
branch name (which is the only type of ref Git expects to advance via the
worktree) does it switch to a named branch. Otherwise it switches to what
I like to call "unnamed branch" (and which for historical reasons is
called "detached HEAD" by Git, something that is unlikely to be understood
without explicit explanation).

Now, as a convenience, Git tries to name the revision when it is on such
an unnamed branch. If a tag points to it, it uses the name of that tag to
describe it. If *multiple* tags point to it, it uses the newest one.

That's why you see what you see. It is intended behavior...

Ciao,
Johannes

Possible bug report: git checkout tag problem

2018-01-07 Thread Myles Fong

Hi,

Brief description:
When two tags are pointing to the same commit, e.g. tagA and tagB, if I do `git
checkout tagA` then `git checkout tagB`, and then `git status`, it shows `HEAD
detached at tagA`

Expected behaviour:
I'm expecting it to show `HEAD detached at tagB`, though I understand this
makes no difference for the repo code, but still a bit confusing for me.

Found workaround:
If I do an extra step `git checkout master`, followed by `git checkout tagB`,
and then `git status`, it shows `HEAD detached at tagB` as expected. ("master"
can be any branch name)

Affected version:
This happens with the latest git version 2.14.3.

Detailed background:
We have a system consists of many git repos, and are using tags of global
version numbers to ensure the same version of repos are deployed in the whole
system. Sometimes when we have a new minor version of the system, there is no
new commits for some repos. Still we need a new version tag for those repos to
match the system version number, so we put a new version tag pointing to the
same commit as the previous version tag. This is how we ran into the above
situation and I was suspecting that our deploying script didn't run properly
when I see `HEAD detached at {old-version}` in some locations of a
{new-version} system.
I'm not sure if this is an expected behaviour or not because I didn't found any
useful information after some Goolgling, except the following discussion.

Related discussion:
I found this discussion to be related to the same problem:
https://stackoverflow.com/questions/30631000/git-checkout-tag-issues-tag-is-unchanged/30631434#30631434

Regards,
Myles Fong

Bug Report: Subtrees and GPG Signed Commits

2018-01-06 Thread Stephen R Guglielmo

Hi all,

I've noticed an issue regarding the use of `git subtree add` and `git
subtree pull` when the subtree repository's commit (either HEAD or
whatever commit specified by the subtree command) is signed with GPG.
It seems to work properly if the commit is not signed but previous
commits are.

The gist of the issue is that `git subtree add` does not add the
subree properly and a "fatal: Not a valid object name" error is
thrown. Running `git subtree pull` does not pull any upstream changes
after that ("'subtree' was never added").

I have not done extensive testing, however, below are instructions to
reproduce the issue. This was tested using git version 2.15.1
installed via Homebrew on MacOS. I did not test with the built-in
version of git on MacOS.

Thanks,
Steve

# Create a new repository
mkdir repoA && cd repoA
git init
echo "Test File in Repo A" > FileA
git add -A && git commit -m 'Initial commit in repo A'

# Create a second repository
cd .. && mkdir repoB && cd repoB
git init
echo "Test File in Repo B" > FileB
git add -A && git commit -m 'Initial commit in repo B'

# Create a signed commit in repo B
echo "Signed Commit" >> FileB
git commit -a -S  -m 'Signed commit in repo B'

# Now, add repoB as a subtree of RepoA
cd ../repoA
git subtree add --prefix repoB_subtree/ ../repoB/ master --squash
# Output:
git fetch ../repoB/ master
warning: no common commits
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
>From ../repoB
 * branchmaster -> FETCH_HEAD
fatal: Not a valid object name gpg: Signature made Sat Jan  6 17:38:31 2018 EST
gpg:using RSA key 6900E9CFDD39B6A741D601F50999759F2DCF3E7C
gpg: Good signature from "Stephen Robert Guglielmo (Temple University
Computer Services) " [ultimate]
Primary key fingerprint: 6900 E9CF DD39 B6A7 41D6  01F5 0999 759F 2DCF 3E7C
4b700b1a4ebb9e2c1011aafd6b0f720b38f059a4
# Note, git exits with status 128 at this point.

# FileB was in fact added and staged to repoA, despite the "fatal"
above. Commit it:
git commit -m 'Add repoB subtree'

# Ok, let's make another commit in repoB and try a `subtree pull`
instead of `subtree add`
cd ../repoB
echo "Another Line" >> FileB
git commit -a -S -m 'Another signed commit'
cd ../repoA
git subtree pull --prefix repoB_subtree/ ../repoB master --squash
# Output:
warning: no common commits
remote: Counting objects: 9, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 9 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (9/9), done.
>From ../repoB
 * branchmaster -> FETCH_HEAD
Can't squash-merge: 'repoB_subtree' was never added.
# Note, git exits with status 1 at this point.

# RepoB's third commit ('Another signed commit') is not pulled into
the subree in repo A.
# This can be verified by running a diff:
diff -qr --exclude ".git" repoB_subtree ../repoB
# Output:
Files repoB_subtree/FileB and ../repoB/FileB differ

Re: Bug report: git clone with dest

On Fri, Jan 05, 2018 at 02:37:25PM -0800, Junio C Hamano wrote:

> Well, MaintNotes on the 'todo' branch needs a bit of updating, as it
> says something somewhat misleading.
> 
> -- >8 --
> Subject: MaintNotes: clarify the purpose of maint->master upmerge

Yup, this makes sense. Thanks for clarifying.

-Peff

Re: Bug report: git clone with dest

Jeff King  writes:

> On Fri, Jan 05, 2018 at 12:45:03PM -0800, Junio C Hamano wrote:
>
>> Jeff King  writes:
>> 
>> > Out of curiosity, did this change at some point? I thought the process
>> > used to be to merge to maint, and then pick up topics in master by
>> > merging maint to master.
>> 
>> If you look at "Sync with maint" merges made to 'master', you'd
>> notice that most of them are only updating Documentation/RelNotes/*
>> and otherwise no-effect merges, simply because when such an up-merge
>> is made, everything in 'maint' is already in 'master' because topics
>> are merged to the latter first.  Security fixes that go through
>> embargoes are excempt for obvious reasons ;-)
>
> OK, that makes sense. Pretty sure I did it wrong when I was interim
> maintainer back in the day, then. :)

Well, MaintNotes on the 'todo' branch needs a bit of updating, as it
says something somewhat misleading.

-- >8 --
Subject: MaintNotes: clarify the purpose of maint->master upmerge

Even though the paragraph before this one is pretty clear that
topics are first merged to 'master' and then to 'maint', it was
misleading to say 'maint' is merged to 'master' to propagate fixes
forward, as most of the time, such an upmerge is a noop because
topics merged to 'maint' are usually merged to 'master' already.

These up-merges are done primarily to make sure that the tip of
'master' has updated release notes from all the maintenance tracks,
so be explicit about that to avoid confusion.

Signed-off-by: Junio C Hamano 
---
 MaintNotes | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MaintNotes b/MaintNotes
index 3a70b88..393d81f 100644
--- a/MaintNotes
+++ b/MaintNotes
@@ -173,8 +173,8 @@ feature release).  These days, maintenance releases are 
named by
 incrementing the last digit of three-dotted decimal name (e.g. "2.12.1"
 was the first maintenance release for the "2.12" series).

-New features never go to the 'maint' branch.  This branch is also
-merged into "master" to propagate the fixes forward as needed.
+New features never go to the 'maint' branch.  It is merged into "master"
+primarily to propagate the description in the release notes forward.

 A new development does not usually happen on "master". When you send a
 series of patches, after review on the mailing list, a separate topic

Re: Bug report: git clone with dest

Hi Peff,

On Fri, 5 Jan 2018, Jeff King wrote:

> On Fri, Jan 05, 2018 at 09:22:07PM +0100, Johannes Schindelin wrote:
> 
> > On Fri, 5 Jan 2018, Isaac Shabtay wrote:
> > 
> > > Done: https://github.com/git-for-windows/git/pull/1421
> > > 
> > > I added credit to Jeff in the PR's description.
> > 
> > Sadly, the PR's description won't make it into the commit history, and the
> > authorship really should have been retained.
> > 
> > I found Peff's topic branch in his fork and force-pushed, to demonstrate
> > what I wanted to have. Currently the test suite is running (I test 64-bit
> > builds of the three major platforms Windows, macOS and Linux), and once
> > that is done and passed, I will merge the Pull Request.
> 
> I think the discussion has ended at "don't do anything else", but note
> that Junio and I were musing on whether to update the series around the
> dir_exists() function.

I briefly looked over this discussion and got the same impression.

> Which would then create headaches for you later when you try to merge a
> subtly-different series that makes it upstream.

Subtly-different is not a big problem. It is typically solved by `git
rebase --skip` ;-)

> Like I said, I think we've resolved not to do anything, but I wanted to
> point out a potential pitfall with this kind of "pick up a topic early"
> strategy (I'm intimately familiar with this pitfall because I do it all
> the time for the fork we run on our servers at GitHub).

Thanks for your concern.

And not to worry, I have plenty of expertise, won over the years, in
dealing with subtly different variants of patches having been accepted
upstream and conflicting with patches that were carried in Git for
Windows.

Ciao,
Dscho

Re: Bug report: git clone with dest

Hi,

On Fri, 5 Jan 2018, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > On Wed, Jan 03, 2018 at 02:42:51PM -0800, Isaac Shabtay wrote:
> >
> >> Indeed interesting... this one's for the books...
> >> Thanks for the patches. Any idea when these are going to make it to the
> >> official Git client builds? (specifically the Windows one)
> >
> > They haven't even been reviewed yet.

FWIW I went through them in that PR that Isaac opened (and which I updated
with Peff's patches, rebased), and I found nothing obviously wrong with
them. They seem to be straight-forward enough.

Just s/m(y temporarily removing its objects)/b\1/ and s/(call stat
directly)( the same scratch)/\1 using\2/

Ciao,
Dscho

Re: Bug report: git clone with dest

On Fri, Jan 05, 2018 at 12:45:03PM -0800, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > Out of curiosity, did this change at some point? I thought the process
> > used to be to merge to maint, and then pick up topics in master by
> > merging maint to master.
> 
> If you look at "Sync with maint" merges made to 'master', you'd
> notice that most of them are only updating Documentation/RelNotes/*
> and otherwise no-effect merges, simply because when such an up-merge
> is made, everything in 'maint' is already in 'master' because topics
> are merged to the latter first.  Security fixes that go through
> embargoes are excempt for obvious reasons ;-)

OK, that makes sense. Pretty sure I did it wrong when I was interim
maintainer back in the day, then. :)

-Peff

Re: Bug report: git clone with dest

Jeff King  writes:

> Out of curiosity, did this change at some point? I thought the process
> used to be to merge to maint, and then pick up topics in master by
> merging maint to master.

If you look at "Sync with maint" merges made to 'master', you'd
notice that most of them are only updating Documentation/RelNotes/*
and otherwise no-effect merges, simply because when such an up-merge
is made, everything in 'maint' is already in 'master' because topics
are merged to the latter first.  Security fixes that go through
embargoes are excempt for obvious reasons ;-)

I do not recall how it was before 2012.

Re: Bug report: git clone with dest

On Fri, Jan 05, 2018 at 09:22:07PM +0100, Johannes Schindelin wrote:

> On Fri, 5 Jan 2018, Isaac Shabtay wrote:
> 
> > Done: https://github.com/git-for-windows/git/pull/1421
> > 
> > I added credit to Jeff in the PR's description.
> 
> Sadly, the PR's description won't make it into the commit history, and the
> authorship really should have been retained.
> 
> I found Peff's topic branch in his fork and force-pushed, to demonstrate
> what I wanted to have. Currently the test suite is running (I test 64-bit
> builds of the three major platforms Windows, macOS and Linux), and once
> that is done and passed, I will merge the Pull Request.

I think the discussion has ended at "don't do anything else", but note
that Junio and I were musing on whether to update the series around the
dir_exists() function. Which would then create headaches for you later
when you try to merge a subtly-different series that makes it upstream.

Like I said, I think we've resolved not to do anything, but I wanted to
point out a potential pitfall with this kind of "pick up a topic early"
strategy (I'm intimately familiar with this pitfall because I do it all
the time for the fork we run on our servers at GitHub).

-Peff

Re: Bug report: git clone with dest

Johannes Schindelin  writes:

> Hi Isaac,
>
> On Fri, 5 Jan 2018, Isaac Shabtay wrote:
>
>> Done: https://github.com/git-for-windows/git/pull/1421
>> 
>> I added credit to Jeff in the PR's description.
>
> Sadly, the PR's description won't make it into the commit history, and the
> authorship really should have been retained.
>
> I found Peff's topic branch in his fork and force-pushed, to demonstrate
> what I wanted to have. Currently the test suite is running (I test 64-bit
> builds of the three major platforms Windows, macOS and Linux), and once
> that is done and passed, I will merge the Pull Request.
>
>> Note that I tried compiling master, but failed due to a reason
>> unrelated to this patch:
>> 
>> builtin/checkout.c:24:10: fatal error: fscache.h: No such file or directory
>
> That was an oversight in a previously-merged Pull Request. I have fixed
> that locally and will soon push it out onto `master`.
>
> Ciao,
> Johannes

FWIW, I do not mind including this as part of -rc2 if not -rc1 for
the upcoming release.

Re: Bug report: git clone with dest

Hi Isaac,

On Fri, 5 Jan 2018, Isaac Shabtay wrote:

> Done: https://github.com/git-for-windows/git/pull/1421
> 
> I added credit to Jeff in the PR's description.

Sadly, the PR's description won't make it into the commit history, and the
authorship really should have been retained.

I found Peff's topic branch in his fork and force-pushed, to demonstrate
what I wanted to have. Currently the test suite is running (I test 64-bit
builds of the three major platforms Windows, macOS and Linux), and once
that is done and passed, I will merge the Pull Request.

> Note that I tried compiling master, but failed due to a reason
> unrelated to this patch:
> 
> builtin/checkout.c:24:10: fatal error: fscache.h: No such file or directory

That was an oversight in a previously-merged Pull Request. I have fixed
that locally and will soon push it out onto `master`.

Ciao,
Johannes

Re: Bug report: git clone with dest

On Fri, Jan 05, 2018 at 11:53:50AM -0800, Junio C Hamano wrote:

> > They haven't even been reviewed yet. If they get good feedback, then the
> > maintainer will pick them up, then merge them to 'next', and then
> > eventually to 'master', after which they'd become part of the next
> > major release. For a pure bug-fix, it may instead go to 'maint' and
> > become part of the next minor release.
> 
> Even a pure bug-fix, unless it is something no longer needed on the
> 'master' front, goes thru 'pu'->'next'->'master' avenue first, and
> is recorded in the RelNotes with the notes like "(merge d45420c1c8
> jk/abort-clone-with-existing-dest later to maint)" when it happens.
> 
>   side note: in fact "grep -e 'later to maint' RelNotes" is
>   how I remind myself what to merge down to 'maint'; the
>   actual procedure is a bit more involved (those interested in
>   the details can find the 'ML' script on the 'todo' branch;
>   its name stands for 'merge later')
> 
> Later, after not hearing from people that the "fix" breaks things,
> the topic is also mreged to 'maint' and becomes part of the next
> minor release.

Out of curiosity, did this change at some point? I thought the process
used to be to merge to maint, and then pick up topics in master by
merging maint to master.

-Peff

Re: Bug report: git clone with dest

Jeff King  writes:

> On Wed, Jan 03, 2018 at 02:42:51PM -0800, Isaac Shabtay wrote:
>
>> Indeed interesting... this one's for the books...
>> Thanks for the patches. Any idea when these are going to make it to the
>> official Git client builds? (specifically the Windows one)
>
> They haven't even been reviewed yet. If they get good feedback, then the
> maintainer will pick them up, then merge them to 'next', and then
> eventually to 'master', after which they'd become part of the next
> major release. For a pure bug-fix, it may instead go to 'maint' and
> become part of the next minor release.

Even a pure bug-fix, unless it is something no longer needed on the
'master' front, goes thru 'pu'->'next'->'master' avenue first, and
is recorded in the RelNotes with the notes like "(merge d45420c1c8
jk/abort-clone-with-existing-dest later to maint)" when it happens.

side note: in fact "grep -e 'later to maint' RelNotes" is
how I remind myself what to merge down to 'maint'; the
actual procedure is a bit more involved (those interested in
the details can find the 'ML' script on the 'todo' branch;
its name stands for 'merge later')

Later, after not hearing from people that the "fix" breaks things,
the topic is also mreged to 'maint' and becomes part of the next
minor release.

> Right now we're entering release freeze for v2.16.0. We'd still take
> fixes for recent breakages there, but given the age of the problem I
> doubt it will make the cutoff. But as this is a bug-fix, it might make
> it into v2.16.1.

Yup.  From the usual timeline, I'd expect this to be part of
'master' working towards 2.17 and to become a part of 2.16.x
series.

Thanks.

Re: Bug report: git clone with dest

2018-01-05 Thread Isaac Shabtay

Done: https://github.com/git-for-windows/git/pull/1421

I added credit to Jeff in the PR's description.

Note that I tried compiling master, but failed due to a reason
unrelated to this patch:

builtin/checkout.c:24:10: fatal error: fscache.h: No such file or directory

Maybe I wasn't building it right.



On 5 January 2018 at 02:33, Johannes Schindelin
 wrote:
> Hi Isaac,
>
> On Thu, 4 Jan 2018, Isaac Shabtay wrote:
>
>> I cloned git's codebase, applied the four patches on master, built and
>> tested on Ubuntu Trusty. (After verifying that master indeed exhibits
>> this behaviour on Linux as well. Just checking).
>> Seems to work fine.
>> I also looked at the code. Most of the patched lines relate to tests,
>> and the one for clone.c seems reasonable to me. Added tests seem to
>> have very good coverage too.
>
> Thanks.
>
>> I qualify everything I had written above by saying that it's my first
>> time ever looking at Git's source code.
>
> We all started at some point.
>
> Now, if you want to make this easier for me, could you please apply those
> patches on top of Git for Windows' master branch and open a Pull Request
> at https://github.com/git-for-windows/git?
>
> Thank you,
> Johannes

Re: Bug report: git clone with dest