Boost logo

Boost :

Subject: Re: [boost] git reset and force push
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2015-10-07 11:26:09

Le 07/10/15 16:52, Andrey Semashev a écrit :
> Well, I'm using quite a few libraries. Selecting ones I don't use and
> excluding them from the checkout is just a waste of time for me - it's
> easier to check out everything. In any case, I don't think Boost.Test
> qualifies as a library that is rarely used.

I am not saying to not checkout the full superproject with all
submodules, I am saying not checking out a particular **branch** of a
submodule. This works just fine, and this is what the superproject is
supposed to do: having a consistent state with a revision across all
components, the revision of the superproject referring to specific
revisions of the submodules.

git submodule update --recursive

checks out everything incl. submodules, submodules are without HEAD
since they are SHA1/revisions. This is why the previous command *should*
work when history is rewritten (refers to SHA1, does not check out a
specific branch).

>> and a submodule develop/master might not
>> be part of any version of the superproject itself (and hence not being
>> able to test it).
> The superproject is automatically updated to refer to the latest commits
> in develop and master branches. I think it may skip a few pushed commits
> if pushes are done in quick succession, but really, I don't care. For
> all practical purposes you can assume that the superproject always
> refers to the latest commit.

You're counting on the fact that things get updated fast, etc etc. What
counts is the "VC" part in DVCS: the revision of the superproject and
the associated submodules. What you are doing does might lead to an
inconsistent state (plus the fact that I do not see any added value in
having the branches). But that is another topic.

>> Also with your merge you might create new commits that
>> are not on the remote.
> No, it can't. Not with the --ff-only argument. And that's the reason why
> it fails when the history is rewritten.


>> So far, 1 is against :) (but since you are an experienced git user, you
>> would not mind neither to reset boost.test).
> I would mind, that's why I objected in the first place.

I know, and I respect and heard your points.


Boost list run by bdawes at, gregod at, cpdaniel at, john at