What's "wrong" with this fast-import?

What's "wrong" with this fast-import?

[com.git-scm]

Hello!

I'm trying to track down an issue with the Fossil SCM, specifically the
export feature that can produce the fast-import files consumed by Git.

The symptom of the bug seems to be that if a branch B is created from
branch A, files committed to B, and then B merged with A, the committed
files are not present in the head of A.

As an example:

  http://waste.io7m.com/2015/12/12/fossilexport/

The given test.fossil repository was populated with the following steps:

  1. Create fossil repository.
  2. Add README.txt and commit in trunk.
  3. Create branch 'b0' and switch to it.
  4. Add README-b0.txt and commit in b0.
  5. Switch to trunk.
  6. Merge and commit 'b0'.

The HEAD of the fossil repository now contains README.txt and
README-b0.txt.

Exporting the repository (see test.export) produces:

--
blob
mark :4
data 7
Hello.

blob
mark :10
data 10
Hello b0.

commit refs/heads/trunk
mark :3
committer someone <someone> 1449930286 +0000
data 22
initial empty check-in
deleteall

commit refs/heads/trunk
mark :7
committer someone <someone> 1449930317 +0000
data 7
Initial
from :3
M 100644 :4 README.txt

commit refs/heads/b0
mark :9
committer someone <someone> 1449930338 +0000
data 28
Create new branch named "b0"
from :7

commit refs/heads/b0
mark :13
committer someone <someone> 1449930374 +0000
data 13
Add README-b0
from :9
M 100644 :10 README-b0.txt

commit refs/heads/trunk
mark :15
committer someone <someone> 1449930396 +0000
data 8
Merge b0
from :7
merge :13
--

Importing that into git produces a trunk branch that only
contains the file README.txt. Something is evidently being lost in the
merge, but it's not clear how.

Does anyone have any idea what Fossil is doing wrong?

M

Re: What's "wrong" with this fast-import?

[SZEDER Gábor]

> The symptom of the bug seems to be that if a branch B is created from
> branch A, files committed to B, and then B merged with A, the committed
> files are not present in the head of A.

fast-import's 'merge' command doesn't actually perform a merge, it
merely records that the new commit has one more parent.  All changes
compared to the first parent (i.e. the addition of that new readme file
on the side branch) have to be listed explicitly.

> As an example:
> 
>   http://waste.io7m.com/2015/12/12/fossilexport/
> 
> The given test.fossil repository was populated with the following steps:
> 
>   1. Create fossil repository.
>   2. Add README.txt and commit in trunk.
>   3. Create branch 'b0' and switch to it.
>   4. Add README-b0.txt and commit in b0.
>   5. Switch to trunk.
>   6. Merge and commit 'b0'.
> 
> The HEAD of the fossil repository now contains README.txt and
> README-b0.txt.
> 
> Exporting the repository (see test.export) produces:
> 
> --
> blob
> mark :4
> data 7
> Hello.
> 
> blob
> mark :10
> data 10
> Hello b0.
> 
> commit refs/heads/trunk
> mark :3
> committer someone <someone> 1449930286 +0000
> data 22
> initial empty check-in
> deleteall
> 
> commit refs/heads/trunk
> mark :7
> committer someone <someone> 1449930317 +0000
> data 7
> Initial
> from :3
> M 100644 :4 README.txt
> 
> commit refs/heads/b0
> mark :9
> committer someone <someone> 1449930338 +0000
> data 28
> Create new branch named "b0"
> from :7
> 
> commit refs/heads/b0
> mark :13
> committer someone <someone> 1449930374 +0000
> data 13
> Add README-b0
> from :9
> M 100644 :10 README-b0.txt
> 
> commit refs/heads/trunk
> mark :15
> committer someone <someone> 1449930396 +0000
> data 8
> Merge b0
> from :7
> merge :13

I.e. this commit should also contain the following filemodify command
to add that new readme file:

  M 100644 :10 README-b0.txt

Re: What's "wrong" with this fast-import?

[com.git-scm]

On 2015-12-13T01:53:39 +0100
SZEDER Gábor <szeder@ira.uka.de> wrote:

> All changes
> compared to the first parent (i.e. the addition of that new readme file
> on the side branch) have to be listed explicitly.
> 

Apologies for the delay: Thanks for this!

It seems that this issue was actually unintentionally fixed in newer
versions of Fossil, but the schema of repositories created with older
versions had to be updated in order to actually get the benefits of the
fix.

M