Re: RFC/RFH submodule handling in big setups

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

 



On Mon, Jan 07, 2008 at 11:23:27 +0100, Finn Arne Gangstad wrote:
> 3. each time you push a submodule, do a merge ours to a
>    "internal-submodule-tracking" branch, and push to that. Something
>    like this in other words:
> 
>      git fetch origin internal-submodule-tracking
>      git merge -s ours origin/internal-submodule-tracking
>      git push origin internal-submodule-tracking
>      git reset --hard HEAD^1
> 
>    Issue: feels wrong somehow?

Only one thing feels wrong here -- the merge -s ours. For one thing, the
commit is probably descendant of what was in the internal-submodule-tracking
branch (the branch name should actually have product2 in it's name).
If it is not, you should not artificially make it so, but rewind the branch.

But as Junio already told you, you should really manage the subproject like
a project (because it is a project), so the change should get to a topic
branch where the other superprojects can look at the change and decide
whether they want it or not.

-- 
						 Jan 'Bulb' Hudec <bulb@xxxxxx>
-
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

[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