git mergetool vs stash apply

Hi, list!

The git mergetool ignores conflicts by git stash apply:

$ git stash apply Auto-merged path/file.ext CONFLICT (content): Merge conflict in path/file.ext

$ git mergetool merge tool candidates: kdiff3 kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff No files need merging

While path/file.ext do contain merge conflict.

The git mergetool works for git merge and git rebase. Maybe it should work for git stash as well? I automatically type git mergetool when I see CONFLICT in Git output. %-)

Alexander.

On Tue, May 20, 2008 at 12:02:44PM +0400, Alexander Gladysh wrote:

I think there is something else going on, because it _does_ generally work. This simple test case should confirm:

  mkdir repo && cd repo && git init
  echo content >file && git add . && git commit -m one
  echo changes >>file && git commit -a -m two
  echo more >>file && git stash
  git checkout -b other HEAD^
  echo different changes >>file && git commit -a -m three
  git stash apply
  git mergetool

I get:
  Normal merge conflict for 'file':
    {local}: modified
    {remote}: modified
  Hit return to start merge resolution tool (xxdiff):

So there is perhaps something specific about your setup or your conflict that is causing mergetool not to work as expected. Can you give us a test case that fails?

-Peff

On Tue, May 20, 2008 at 1:02 PM, Jeff King <peff@peff.net> wrote:

Yes, I get the that output on clean repo. And I get that output also if I use actual conflict data (that is, three snapshots of conflicted file) instead.

Most likely so.

No, unfortunately I can not. I was unable to produce a minimal test case, and I can not share the whole repo.

Alexander.

"Alexander Gladysh" <agladysh@gmail.com> writes:

Can you use contents-scrambling tool by Jeff King from
  Message-ID: <20080510055332.GB11556@sigill.intra.peff.net>
  http://permalink.gmane.org/gmane.comp.version-control.git/81652

I hope it would be aded at least to contrib when it is tested more...

On Tue, May 20, 2008 at 3:52 PM, Jakub Narebski <jnareb@gmail.com> wrote:

I have some questions:

1. My repo is 650+ MB, my working copy is 350+ KLOC. That size is hard
to share. Would that tool reduce it enough? Is it possible to filter
out irrelevant content somehow?
2. Would that tool obfuscate binaries as well?

Furthermore, I have tried to reproduce that bug once again (by checking out that problematic revision and trying to apply that git stash on it) and was unable to (but my repo has changed since that). Perhaps it was some "moonphase-related" fluctuation...

Sorry for the noise. Alexander.

On Tue, May 20, 2008 at 04:32:49PM +0400, Alexander Gladysh wrote:

It doesn't really shrink it very much. You can always filter out some content with filter-branch, but the trick is trying to produce a repo that still exhibits the problem. In your case, it might be enough to simply provide the stashed state and the state upon which you are trying to apply.

It looks at lines, so wherever your binary happened to have a newline, it would get split into chunks. So the answer is yes, it would obfuscate them, but the diffs won't necessarily be meaningful.

All that being said...

Obfuscating your repository to let us reproduce is pointless if you can't reproduce on the repository itself. So I would keep an eye on it, and if it happens again, try to save the broken state.

-Peff