no common ancestors ...

(1) By Alfred M. Szmidt (ams) on 2022-06-28 19:00:18 [source]

I'm in a small pickle, and not sure how to solve it.

I need to keep track of a bunch of files that are from a bunch of tapes, sometimes these files are named the same for better or worse, but different. Where I want to pick one side or the other depending on what is more correct. Each file has a version attached to its file-name, but some files might have been generated from a common source, and the output was different.

The end result is to collect all these "random" tapes into one single tree that represents some sort of tree history of things.

The scheme I've come up with is that I put one tape into one branch per tape (this allows me to do some post-processing of the files as well) -- branched from a "initial point", and then merge the different branches into trunk (or let them live on a branch). So a work flow that looks like this:

f update trunk
f add foo.text.1
f commit -m "tape 1" foo.text.1" --branch tape/1

f update trunk
f add foo.text.1
f commit -m "tape 2" foo.text.1" --branch tape/2

f update trunk
f merge tape/1; f commit -m "tape/1 merge"
f merge tape/2; f commit -m "tape/1 merge"

Of course, this won't work well if you "f add" a file in two different branches, resulting in a uncommon ancestor. What I'd like to see/track is that foo.text.1 was at some point picked from one or the other, and being able to see the diff as well.

So just throwing this out, to see if someone might have an idea on something better than this. I realise that this is a weird pickle.

(2) By Jacob MacDonald (jaccarmac) on 2022-06-28 19:46:24 in reply to 1 [link] [source]

I don't think I quite understand what you're going for, but it seems that having two files with the same name forces you to do a manual merge anyway. Would it be feasible to add each tape's files to a different directory, merge the branches, and then perform that manual merge? It would turn your merge commit into a "merge pair", but the chosen file would have history reflecting which directory it used to be in.

(3) By Alfred M. Szmidt (ams) on 2022-06-28 20:09:05 in reply to 2 [link] [source]

Yeah, not sure I explained it well.

Say that you have three tapes, those tapes contain the following files:

Tape 1:
  foo.text.123
  foo.out.123            foo.out.123 here was created on a different (earlier) date than the one in tape 2, and has slightly different content

Tape 2:
  foo.text.123
  foo.out.123            foo.out.123 here was created on a different (later) date than the one in tape 1, and has slightly different content

Tape 3:
  foo.text.124
  foo.text.123
  foo.out.124
  foo.out.123            same as in tape 1!

Working from "trunk"; you'd "insert" tape 1 first, then 2, and finally 3 (or any other order really). The end result of this should be:

foo.text.123
foo.out.123 (from tape _2_, i.e. we do not want the foo.out.124 from tape 1 or 3 though those might have been "inserted" before tape 2)
foo.text.124
foo.out.124

I just tried doing something like this with git, and it seems to manage it slightly better. One is to create the branches using --orphan, and then import the content of the tape. Then, switch to "master", and do a "git merge TAPE --ours --allow-unrelated-histories"; switching --ours to --theirs depending on the situation.

Maybe one could import that into a fossil repository later on... what a pickle.

(4) By Jacob MacDonald (jaccarmac) on 2022-06-28 20:14:26 in reply to 3 [link] [source]

Ah, I see. I'm not familiar with --allow-unrelated-histories, so won't try to speak to its impact on the merge objects.

Maybe one could import that into a fossil repository later on

It might be worth doing that for a minimal case to see

If Fossil handles the history you envision.
How the resulting Fossil commits look.

(5) By Alfred M. Szmidt (ams) on 2022-06-28 20:32:54 in reply to 4 [link] [source]

Seems to work, and looks like what I think I want to see, will try experimenting some more before I commit to this.