Make merging into child streams optional #49
Labels
Comments
orao
added a commit
that referenced
this issue
Mar 16, 2016
I've added yet another flag to the configuration file to allow users to control if the MergeIntoChildren() function actually performs merges or cherry-picks. This is because of a yet unresolved and reasonably complex problem. The issue arises from when a stream is promoted into and is at that point different from its parent (basis) stream. Here we record a branch operation in git. Some time later the stream is then purged which is a transaction that occurs in the child stream (making it effectively the same as the parent/basis stream) but this transaction does not occur on the parent (basis) stream. Hence, the question is: how do we represent this in git? As usual there are several options, all of which have their own drawbacks. Since Accurev promisses that your stream's history is immutable, if we try and replicate this in Git we will have to record this change and revert action on the child stream in some way and then link it back to the parent (basis) stream. The only way I can think of to do this is by making a commit on the parent stream but this is a lie since no transaction occurred on the parent stream. However, it is one way to represent what occurred. Alternatively, we could simply say that since the streams are now the same and the user chose to discard their changes, had they originally done this in Git they would have simply deleted that branch and `reset` it onto the parent streams HEAD commit. But this loses history. Regardless, this situation causes the current version of the script to start a chain of merges from the parent (basis) stream into the child stream for each promote into the parent stream. This looks a little like a ladder and causes havoc with various graphing tools if it continues for a long time. In order to make the graphs prettier I've added the option that makes these merges treated as cherry-picks instead. It is a way to make the graph look simpler at the cost of having shadow-commits (cherry-picks into each affected child stream for each transaction into the parent), which too makes things ugly. At some point, I would like to implement both of the options discussed above but I'm unlikely to get the time to do it. So as a temporary measure this option will have to do.
|
@fatfreddie This should solve our problem. |
This was referenced Mar 17, 2016
ghost
removed
the
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If a stream has a basis and is promoted into then all subsequent promotes into the basis stream will show up as merges down into the child stream.
This enhancement regards creating a configuration flag that changes the behavior of the script so that these merges turn into cherry-picks instead.
The function where this needs to happen is the
MergeIntoChildren().The text was updated successfully, but these errors were encountered: