Re: [PATCH 12/48] t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify

From: Phil Hord <hordp@cisco.com>
Date: Jul 20, 2011, 23:15 UTC
Message-ID: <4E276180.1050406@cisco.com>
In-Reply-To: <7vvcuzcg73.fsf@alter.siamese.dyndns.org>

On 07/18/2011 07:38 PM, Junio C Hamano wrote:

Show 22 quoted lines

> Elijah Newren<newren@gmail.com>  writes:
>
>> Now THAT's a corner case.
>> ...
>> +# criss-cross with rename/rename(1to2)/add-source + resolvable modify/modify:
>> +#
>> +#      B   D
>> +#      o---o
>> +#     / \ / \
>> +#  A o   X   ? F
>> +#     \ / \ /
>> +#      o---o
>> +#      C   E
>> +#
>> +#   Commit A: new file: a
>> +#   Commit B: rename a->b
>> +#   Commit C: rename a->c, add different a
>> +#   Commit D: merge B&C, keeping b&c and (new) a modified at beginning
>> +#   Commit E: merge B&C, keeping b&c and (new) a modified at end
> THAT may be a corner case, but is it a useful corner case?  What on earth
> the person who did D (or E) was thinking to keep both b and c that are
> derived from A:a to begin with?

I think this may happen rather commonly in one of our repos. I must say I was quite surprised when I recognized it in this discussion.

The details are boring, so feel free to ignore the rest of this message unless you just want to understand or contradict me. There is one difference in my real workflow, but for now I'll imagine this difference is not there.

Ciao.

Begin boring details:

We have an expensive, enterprise, config control system that tracks "low-volume" file revisions by unique filenames in a specific format. Here's the life story of a file named foo:

    foo_00    # Revision 00 (initial rev)
    foo_01    # Revision 01
    foo_02    # Revision 02
    foo_A     # Revision A (first 'published' version)
    foo_B     # Revision B (all subsequent versions get published)

When we transition to an externally published version (a one-time event), the revisions change from numbers to letters.

We often need to refer to a specific file version by 'versioned name', so we keep all the revisions around in a pool of files.

If I have pending changes not yet in the "config control" system, I keep a source file in git to hold them until I'm ready to label them with the next revision number.

I have some tools that promote my current edition into the next appropriately named-revision.

   'next' is used to promote the current source to the next appropriate 
revision-named file.

   'publish' does the same thing, but it explicitly promotes the file to 
revision 'A' from the current numeric revision.

A few weeks ago, this is how foo showed up in my repo:

     pending/foo
     deploy/foo_00
     deploy/foo_01

Here's a greatly simplified overview of the tools with this state:

     next foo        # "mv -n pending/foo deploy/foo_02"
     publish foo     # "mv -n pending/foo deploy/foo_A"

[Elijah's "Commit A: new file: a": a=pending/foo]

The story begins.

[Elijah's "Commit B: rename a->b": b=deploy/foo_01]

Changes in pending/foo need to be released, so I prep with 'next foo'.

     $ next foo        # "mv pending/foo deploy/foo_02"
     deploy/foo_00
     deploy/foo_01
     deploy/foo_02

Then I commit and push.
     $ git add -u . && git add . && git commit -m "next foo" && git push

[Elijah's "Commit C: rename a->c, add different a": c=deploy/foo_A]

My boss has been told (but he forgot to tell me) that we need to go to rev A in this release so the package can be published externally.  So, in his repo he preps with 'publish foo'.

     $publish foo     #"mv -n pending/foo deploy/foo_A"
     deploy/foo_00
     deploy/foo_01
     deploy/foo_A

My boss also has some changes for a future version (probably rev B) so 
he adds those, too.
     $ echo Frabnotz > pending/foo

Then he commits and pushes.
     $ git add -u . && git add . && git commit -m "publish foo" && git push

It's easy to embellish the rest.  It's so easy, I won't.  But you can imagine it.

The only deviation in this story from my real workflow is that I never delete pending/foo.  But if it changed radically each time, I probably would.

Phil