threads / discuss / 27232

Strange cherry-picking issue with 1.7.5.msysgit.1.1.g05d0e

Subject: Strange cherry-picking issue with 1.7.5.msysgit.1.1.g05d0e

## tl;dr

3 messages between May 1, 2011 and May 1, 2011.

replies: 2people: 2as markdown or json

Sebastian Schuberth· May 1, 2011, 08:28 UTC · lore

Hi,

while preparing for the msysGit 1.7.5 release, I came across a strange issue with cherry-picking when using my own local build of 1.7.5.msysgit.1.1.g05d0e (built from the msysgit.git / 4msysgit.git devel branches; note that 4msysgit.git's devel is based on git.git's aka Junio's next).

To test the recent "BindImage" additions to the Windows installer, I did:

# Create a topic branch based on msysgit.git devel: sebastian@PASSAU / (devel) $ git checkout -b ss/bindimage M git Switched to a new branch 'ss/bindimage'

# Cherry-pick the "BindImage" commit from msysgit.git's mob: sebastian@PASSAU / (ss/bindimage) $ git cherry-pick 59467863efd336ba3a443a88ce140ab1e59a29f0 error: could not apply 5946786... Call BindImage on installer for all the exe and dll files hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit'

# Inspect the working tree: sebastian@PASSAU / (ss/bindimage|CHERRY-PICKING) $ git status # On branch ss/bindimage # Changes to be committed: # # modified: share/WinGit/copy-files.sh # modified: share/WinGit/install.iss # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: git (new commits) # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # share/InnoSetup/ISCmplr.dll~5946786... Call BindImage on installer for all the exe and dll files

So the cherry-pick fails although it should apply cleanly here. If I run the same command on the same working tree using msysgit 1.7.4, the cherry-pick applies fine. And where does this strangely named untracked file come from?

Note the "CHERRY-PICKING" in the prompt which comes from js/cherry-pick-usability that we picked up from junio/next during our rebasing merge. At first I thought this issue might be related to that branch, but reverting 37f7a85 and d7e5c0c did not solve the issue for me.

Any ideas what might be causing this?

Thanks for any insights.

-- 
Sebastian Schuberth

Johannes Schindelin· May 1, 2011, 09:45 UTC · re: Sebastian Schuberth · lore

Re: Strange cherry-picking issue with 1.7.5.msysgit.1.1.g05d0e

Hi,

On Sun, 1 May 2011, Sebastian Schuberth wrote:

Show 42 quoted lines

> while preparing for the msysGit 1.7.5 release, I came across a strange 
> issue with cherry-picking when using my own local build of 
> 1.7.5.msysgit.1.1.g05d0e (built from the msysgit.git / 4msysgit.git 
> devel branches; note that 4msysgit.git's devel is based on git.git's aka 
> Junio's next).
> 
> To test the recent "BindImage" additions to the Windows installer, I 
> did:
> 
> # Create a topic branch based on msysgit.git devel:
> sebastian@PASSAU / (devel)
> $ git checkout -b ss/bindimage
> M       git
> Switched to a new branch 'ss/bindimage'
> 
> # Cherry-pick the "BindImage" commit from msysgit.git's mob:
> sebastian@PASSAU / (ss/bindimage)
> $ git cherry-pick 59467863efd336ba3a443a88ce140ab1e59a29f0
> error: could not apply 5946786... Call BindImage on installer for all the exe and dll files
> hint: after resolving the conflicts, mark the corrected paths
> hint: with 'git add <paths>' or 'git rm <paths>'
> hint: and commit the result with 'git commit'
> 
> # Inspect the working tree:
> sebastian@PASSAU / (ss/bindimage|CHERRY-PICKING)
> $ git status
> # On branch ss/bindimage
> # Changes to be committed:
> #
> #       modified:   share/WinGit/copy-files.sh
> #       modified:   share/WinGit/install.iss
> #
> # Changes not staged for commit:
> #   (use "git add <file>..." to update what will be committed)
> #   (use "git checkout -- <file>..." to discard changes in working directory)
> #
> #       modified:   git (new commits)
> #
> # Untracked files:
> #   (use "git add <file>..." to include in what will be committed)
> #
> #       share/InnoSetup/ISCmplr.dll~5946786... Call BindImage on installer for all the exe and dll files

This looks like some problem trying to check out that file from another branch. Since you say that this problem does not occur when starting from the 1.7.4 tag, and you updated ISCmplr.dll 6 days after that, I could imagine that something locks the .dll. After all, the current 'mob' is still based off of 1.7.4 not off of the current 'devel'.

There should not have been a problem, though, as the .dll has not changed between the merge base and 5946786...

FWIW on Linux, the same cherry-pick works just fine.

Ciao, Dscho

Sebastian Schuberth· May 1, 2011, 10:02 UTC · re: Johannes Schindelin · lore

Re: [msysGit] Strange cherry-picking issue with 1.7.5.msysgit.1.1.g05d0e

On Sun, May 1, 2011 at 11:45, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 13 quoted lines

>> # Untracked files:
>> #   (use "git add <file>..." to include in what will be committed)
>> #
>> #       share/InnoSetup/ISCmplr.dll~5946786... Call BindImage on installer for all the exe and dll files
>
> This looks like some problem trying to check out that file from another
> branch. Since you say that this problem does not occur when starting from
> the 1.7.4 tag, and you updated ISCmplr.dll 6 days after that, I could
> imagine that something locks the .dll. After all, the current 'mob' is
> still based off of 1.7.4 not off of the current 'devel'.
>
> There should not have been a problem, though, as the .dll has not changed
> between the merge base and 5946786...

You're right, I had Inno Setup running in the background, probably locking the ISCmplr.dll. But even after closing Inno Setup and making sure ISCmplr.dll is not locked anymore, the above cherry-pick fails.

However, if I pass --strategy=resolve, it works with 1.7.5. But as you already mentioned, I'd not expect the cherry-pick to touch ISCmplr.dll in any case ... no what does that tell me, is it a regression in 1.7.5, or a new "feature"?

-- 
Sebastian Schuberth