From: Jens Lehmann <Jens.Lehmann@web.de>
To: "Edward Z. Yang" <ezyang@mit.edu>
Cc: git <git@vger.kernel.org>
Subject: Re: Diffs for submodule conflicts during rebase usually empty
Date: Sat, 13 Sep 2014 13:07:35 +0200 [thread overview]
Message-ID: <54142577.3080104@web.de> (raw)
In-Reply-To: <1410526589-sup-2306@sabre>
Am 12.09.2014 um 15:03 schrieb Edward Z. Yang:
> Hello Jens,
>
> Excerpts from Jens Lehmann's message of 2014-09-11 15:29:28 -0400:
>> Git does know what's going on, just fails to display it properly
>> in the diff, as the output of ls-files shows:
>>
>> $git ls-files -u
>> 160000 6a6e215138b7f343fba67ba1b6ffc152019c6085 1 b
>> 160000 fc12d3455b120916ec508c3ccd04f23957c08ea5 2 b
>> 160000 33d9fa9f9e25de2a85f84993d8f6c752f84c769a 3 b
>
> Right. But I'd also add that even though Git knows what's going
> on, even if we reported /that/ it wouldn't be user friendly:
> namely, because submodules are not updated automatically so the
> first line would always be what the submodule was pointed to
> before we started rebasing. That's not so useful either...
>
>> I agree that this needs to be improved, but am currently lacking
>> the time to do it myself. But I believe this will get important
>> rather soonish when we recursively update submodules too ...
>
> As I've said, I'm happy to contribute a patch, if we can agree
> what the right resolution is...
Me thinks the next step would be that "git diff --submodule"
should learn to not only show 2-way diffs but also 3-way diffs.
Then we'll be able to display submodule merge results in a human
readable way. After that we would have to find a way to display
submodule merge conflicts in a human readable way, similar to
what we do with conflict markers for regular files.
prev parent reply other threads:[~2014-09-13 11:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 17:50 Diffs for submodule conflicts during rebase usually empty ezyang
2014-09-11 19:29 ` Jens Lehmann
2014-09-12 13:03 ` Edward Z. Yang
2014-09-13 11:07 ` Jens Lehmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54142577.3080104@web.de \
--to=jens.lehmann@web.de \
--cc=ezyang@mit.edu \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.