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
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
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
>> 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
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
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
. 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
7 matches
Mail list logo