"Yin Ping" <pkufranky@xxxxxxxxx> writes:
> In both case, i think the user should be notified about the inconsistence.
> My patch given in the first letter handles this by two warning messages as
> follows (where $name is module name)
>
> + cd $name >&/dev/null || { echo " Warning: fail to
> chdir to $name" && exit; }
My point was that it is wrong to make this "you do not have that
submodule checked out" a warning.
Think about somebody who does _not_ care about that particular
submodule. He is working on one branch, and tries to merge
another branch that has some interesting changes outside the
submodule, but that branch also has updates to the submodule.
As he is _not_ interested in the submodule, he does not have it
checked out. He has not changed the commit bound in his index
with 160000 mode bits for that submodule since the common
ancestor, either (that's what "he does not care about the
submodule" means).
The merge will take the submodule commit object name from the
other branches change, just like the ordinary three-way merge
rule would do (one side changed, the other did not do anything,
so take the change). Suppose some files in the project proper,
outside the submodule, had conflicts. He has an unmerged index,
that has the submodule already correctly merged. But other
parts of his index are unmerged. git-status would guide him
what are conflicting, and git-commit would show him what he
would be committing.
In that situation, all he needs to know, with respect to the
submodule, is that the submodule has been updated since his HEAD
(and that is given by the runstatus output). He does not _care_
about what the individual commits in the submodule were. It is
not an error that the information from the submodule cannot be
shown to him. He _chose_ to ignore the details of that
submodule by not checking it out to begin with.
Something like this, to be totally quiet, would be more
appropriate.
for name in $modules
do
(
... do the range, indexone, headone stuff
cd "$name" 2>/dev/null || exit 0
echo "* $name $headone...$indexone:"
... whatever log you show
) | sed ...
done
By the way, I do not know about the quoting issues with $modules
variable in the above illustration, as I am not (yet) discussing
about the implementation level of details.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
