Re: [PATCH] submodule: Alllow staged changes for get_superproject_working_tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sam McKelvie <sammck@xxxxxxxxx> writes:

>> Ah, that, too.  I meant to correct triple ell, though ;-)
>>  ...
>
> I wholeheartedly approve of that plan and your tweaking commit below. Thank you, Junio.

Thanks for a fix.  But now I re-read the title and think about it,
this is mistitled.  The word 'stage' in "ls-files --stage" is not
about 'stage' people use when they talk about "staged changes" at
all.  The latter is what "diff --cached" is about---what's different
between HEAD and the index.  The 'stage' "ls-files --stage" talks
about is "which parent the cache entry came from, among common
ancestor, us, or the other branch being merged".

Also we are not really "allowing" with this change; "allowing" makes
it sound as if we were earlier "forbidding" with a good reason and
the change is lifting the limitation.

We used to incorrectly die when superproject is resolving a conflict
for the submodule we are currently in, and that is what the patch
fixed.

submodule: parse output of conflicted ls-files in superproject correctly

is the shortest I could come up with, while touching all the points
that need to be touched and still being technically not-incorrect.

Or perhaps

rev-parse: --show-superproject-working-tree should work during a merge

may be more to the point.  It does not hint the root cause of the
bug like the other one, but is more direct how the breakage would
have been observed by the end users.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux