Re: cherry picking and merge

From: Philip Oakley <philipoakley@iee.org>
Date: Aug 2, 2014, 10:39 UTC
Message-ID: <FAC83E31AC1645EB83068122320F35AE@PhilipOakley>
In-Reply-To: <FC00A4BB-6CB9-421D-83D6-4E1AFBB4CB3C@comcast.net>

From: "Mike Stump" <mikestump@comcast.net>
Sent: Friday, August 01, 2014 11:10 PM

Show 8 quoted lines

> On Aug 1, 2014, at 11:57 AM, Philip Oakley <philipoakley@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.

Unfortunately we are back at the problem af what 'merge' means. Git uses a snapshot model, while most other version control systems uses a changeset model (which has been used since before the Titanic was built for various reasons [1]) for their storage. Thus most VCS users see merge as the addition of a delta "A + delta -> B", while Git sees merge as the union of snapshots "A + G -> Q".

The cherry-pick and rebase methods determine the change deltas between adjacent snaphots (i.e. patches) and then apply that to a different snapshot. In those cases we are not merging snapshots, rather applying patches (note my changed use of 'merge').

Show 28 quoted lines

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

<snipped remainder because of time limitations>

-- Philip

[1] Way back when blueprints really were blue, and real drawing were on kaolin & linen drawing sheets with indian ink, the 'master' drawings were the most prized items, that if damaged would stop production, so there were many layers of drawing office controls to avoid touching it (e.g. tracers to copy drawings) and keep the master drawings pristine.

From that, the ideas of Change requests, Change orders, Approved changes etc. became the norm. It was the changes that were recorded. These processes are still in place today in most engineering companies and the military, in fact anyone with real artefacts. These techniques were copied into the computing world when it was young.

The big change has been that Computing has reduced the cost of production (duplication, replication) to zero, so now the problem is in trying to validate and verify which alledged copy is actually the 'master' - especially in a fully distributed environment, such as the many different Linux distributions and applications. It was into this gap that Git steps, with the use of the sha1 to both validate the history chain and verify any specific snapshot. It doesn't get hung up on what the change was, that can be determined easily after the fact by a simple diff between adjacent snapshots, though having lots of small changes and crisp commit messages does help.

That's the way I view it anyway. (When I first started work, they still had blue prints, but had moved to microfiche and melinex (polyester) drawing sheets, and the 8088 / IBM PC was new and powerful! I still work in engineering where the old VC model is ubiquitous)