On Aug 1, 2014, at 11:57 AM, Philip Oakley <philipoak...@iee.org> wrote:
> But that goes both ways, and is a philosophical issue about what is to be 
> expected in various cases.

The problem is, users expect merge to merge.  There isn’t a user that expects 
it to scramble the source code, because the command is called merge, not 
scramble.  That word has semantics that were not invented by your project.  You 
cannot change the semantic of the word.  Merge has a nice mathematical 
definition.  Merge branch into master means, place into into master the work 
from that branch.  git already does this 99% correct, it is missing one corner 

This is not a philosophical issue.  It is a definitional one.

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

This is irrelevant to the issue at hand.

> That said, Git doesn't claim to be perfect

Again, irrelevant.

> (and can't because

Do you mean, and can’t be?  If so, you are wrong in the case at hand.  svn is 
an existence proof that you are wrong.

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

base=$(git merge-base $branch $master)

git checkout -b cherry-$branch $base
git cherry-pick "$cherry"
git checkout $master
git merge -s ours cherry-$branch
git checkout $branch
git merge cherry-$branch
git branch -d cherry-$branch
git cherry-pick --strategy=ours --allow-empty "$cherry"
git commit --allow-empty

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.

> In your example (when generalized)

I’m not interested in other bugs that I didn’t state, in this email.  I don’t 
care about those.  Please don’t detract from fixing this issue, because you can 
identify other things that might not be perfect.  We attain perfection one step 
at a time.

> the problem is deciding when, in the change sequence, the cherry pick is to 
> be backed out, especially if there are conflicts in the change sequence that 
> would need fixing anyway, and in a long change sequence that would be a lot 
> of conflict fix-ups, hence the current choice of getting the merge conflicts 
> all resolved in the one go.

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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to