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

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

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

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

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

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

git merge-tree: bug report and some feature requests

2018-01-20 Thread Josh Bleecher Snyder
. 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