On 07/18/2011 07:38 PM, Junio C Hamano wrote:
Elijah Newren<newren@xxxxxxxxx> 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
--
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