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 libgit2,
> but it's not been
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 a
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 git_index_entry.
libgit2 sh
>> 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 time.
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 command for
> doing the
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 indicat
6 matches
Mail list logo
