Thread (10 messages) flat view 10 messages, 4 authors, 2016-06-15

Re: erratic behavior commit --allow-empty

From: Angelo Borsotti <hidden>
Date: 2016-06-15 22:54:56

Hi Philip,
This has the developers having a full copy/history of the integrators
relevant branches, so that when the pull of the developers branch occurs
there is a proper link to the integrators history.
True.
There are other ways to create a branch which has all the developers feature
history removed, rather tha using an --orphan, which removes the integrators
history as well.
The topic branches are populated only by the developers. The integrators merge
all the topic branches into branches dedicated to the integration. In
case of need,
the developers can pull these (with all the integrators' history).
The disconnection of the D' source branch makes it sound like you have a
second SCM system that you have to put stuff into, which is independent of
the development teams git repos. I have this [hassle] at my $dayjob -one
almost has to hide git from the powers-that-be.
Well, there is another way to see this: think to a distributed SCM in
which there are some parts of the contents that are shared and some
that are not.
The technique to use disconnected branches is only a way of implementing this.
If, say, git push had an option to filter out the binaries there would
be no need for disconnected branches.
A reasonable solution. You can also create a sentinel (--root) commit for
any time that you need to create the source branch, just so it (the real
source code commit) has a different parent when on source branch to that on
the binaries branch.
Do you mean I could create an empty root commit to be used as parent for the
real source commit? Or that there is some --root option to be used?

-Angelo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help