Re: [PATCH v3] submodule: Allow tracking of the newest revision of a branch in a submodule

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 12, 2008, 00:59 UTC
Message-ID: <7v8wqmb44l.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <8c5c35580812111631k54657bdcme8f048c77b6765eb@mail.gmail.com>

"Lars Hjemli" <hjemli@gmail.com> writes:

Show 10 quoted lines

> On Thu, Dec 11, 2008 at 21:42, Junio C Hamano <gitster@pobox.com> wrote:
>> I wonder if you can just set "assume unchanged" bit for the subproject
>> gitlink in the index to achieve the same goal.
>
> Using assume-unchanged works, in the sense that the modification to
> the submodule is not detected in the containing repo. But running `git
> submodule update` will checkout the sha1 recorded in HEAD, and I
> suspect Fabian wants something like the hypothetical command `git
> submodule update -b [branch]` which could do `(cd sub && git fetch &&
> git reset --hard origin/$branch)`.

Yeah, that would *also* make sense, but I think that is orthogonal issue.

You can update the state of the checkouts of subproject repositories in any way you want. Doing so however makes "git commit -a" inconvenient to use without assume-unchanged. The magic 0{40} which Fabian's patch addresses the same issue in a different way.

Although I would probably detach the head at that point, rather than resetting whatever branch happens to be checked out:

	( cd sub && git fetch && git checkout origin/$branch^0 )

We also need to make sure that whatever we do we should not break workflows that do not check out submodules that are uninteresting. So doing the above unconditionally to all the submodules is out. In such a sparsely populated superproject, "cd sub" would go to an empty directory, and "git fetch" step would error out.

I did not read Fabian's patch too deeply, and do not remember what checks it did before running "git pull". Perhaps it pulled unconditionally?