From: "Mike Stump" <mikestump@xxxxxxxxxxx>
Sent: Friday, August 01, 2014 11:10 PM
(part 2)
On Aug 1, 2014, at 11:57 AM, Philip Oakley <philipoakley@xxxxxxx>
wrote:
For some central control use styles, the ideas behind _distributed_
version control are anathema and (Git) just grinds away at the
policies that are expected.
...
of the 'relativity' that comes with being distributed - truth has to
give way to a web of trust). Also the artefacts that Git validates
are at a different level of abstraction i.e. the whole project as a
commit, rather than just a few/one file at a time.
Ah, so that gives me an idea. [ pause ] If we try the cherry-pick as
retroactively creating a feature branch, cherrying into that, then
merge unconditionally so that no change happens that into trunk (thus
killing those conflicts), and then git merge that feature branch into
branch then it all works perfectly. See, another existence proof that
you are wrong, this time with git itself.
It was 13 lines of code, so, apparently, it is possible and easy to
do, in git. Now, we just want the cherry-pick to create a temporary
cherry branch, cherry the pick into it, merge and drop into trunk and
merge into branch…
I tested with the below and it worked just fine. Things to clean up,
we want the meta data on the cherry on the merge commit, but, you get
the idea.
I've annotated some of the bits to make sure we are on the same
wavelength as to what this does...
branch=b
master=master
base=$(git merge-base $branch $master)
cherry="$1" # not quite sure where this commit is located relative to
either $branch or $master
# create a new branch, starting at base, for our cherry picked commit
git checkout -b cherry-$branch $base
git cherry-pick "$cherry" # which also commits onto our cherry pick
barnch
git checkout $master
git merge -s ours cherry-$branch # "mark/remember" the cherry branch,
its fix and it's base point, but don't actualy use it here on $master
git checkout $branch
git merge cherry-$branch # bring the 'fix' into $branch
git branch -d cherry-$branch # remove the fix branch that started at
$base - branches are ephemeral anyway.
# still on $branch, which already has the change merged in (Git style) ?
git cherry-pick --strategy=ours --allow-empty "$cherry" # check its
all already included?
git commit --allow-empty
Does my annotation match your understanding? It wasn't clear to me where
$1 had been hiding previously, nor why the common fix didn't use a
"merge -s ours cherry-$branch" in both cases - that maybe my
misunderstanding about how your workflow goes.
I tested that with two cherries with further changes on master to
ensure that it works for more than a single one, no problem. Wow,
even tried a merge of master back into b, and it worked just fine, no
conflicts, yet, all the code was jammed up together nicely.
So, if you wish to continue your position, please explain why it can’t
get this better, given the existence proof above of it working better
in git.
...
I have two possible conflict fixups in the above. In my case (I have
a specific patch in gcc-land i wanted to cherry), those fixups were
trivial (no conflicts). When they are trivial, I don’t care much that
there were two of them. When non-trivial, well, I’m resigned to the
idea that I have to explain what is going on.
Selecting a compatible workflow is a problem of usage,
Not when the workflow is mandated on you to work around trivial little
bugs that can be fixed but for which the author’s don't even
comprehend the bug.
rather than a problem in Git.
--
Philip.
--
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