git mergetool vs stash apply

git mergetool vs stash apply

[Alexander Gladysh]

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.

Re: git mergetool vs stash apply

[Jeff King]

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

> 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.

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

Re: git mergetool vs stash apply

[Alexander Gladysh]

On Tue, May 20, 2008 at 1:02 PM, Jeff King <peff@peff.net> wrote:
> On Tue, May 20, 2008 at 12:02:44PM +0400, Alexander Gladysh wrote:
>
>> 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.
>
> 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):

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.

> So there is perhaps something specific about your setup or your conflict
> that is causing mergetool not to work as expected.

Most likely so.

> Can you give us a test case that fails?

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

Alexander.

Re: git mergetool vs stash apply

[Jakub Narebski]

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

> On Tue, May 20, 2008 at 1:02 PM, Jeff King <peff@peff.net> wrote:
>>
>> So there is perhaps something specific about your setup or your conflict
>> that is causing mergetool not to work as expected.
> 
> Most likely so.
> 
>> Can you give us a test case that fails?
> 
> No, unfortunately I can not. I was unable to produce a minimal test
> case, and I can not share the whole repo.

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...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: git mergetool vs stash apply

[Alexander Gladysh]

On Tue, May 20, 2008 at 3:52 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Alexander Gladysh" <agladysh@gmail.com> writes:
>
>> On Tue, May 20, 2008 at 1:02 PM, Jeff King <peff@peff.net> wrote:
>>>
>>> So there is perhaps something specific about your setup or your conflict
>>> that is causing mergetool not to work as expected.
>>
>> Most likely so.
>>
>>> Can you give us a test case that fails?
>>
>> No, unfortunately I can not. I was unable to produce a minimal test
>> case, and I can not share the whole repo.
>
> 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 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.

Re: git mergetool vs stash apply

[Jeff King]

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

> 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?

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.

> 2. Would that tool obfuscate binaries as well?

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...

> 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...

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