Re: [boost] git reset and force push

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.

Right.

>
>> 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.

Raffi