Use of "stg sync"

Use of "stg sync"

[Yann Dirson]

Hi,

In the context of Debian packaging, I have a tree with an "upstream"
branch, and 2 stgit stack, one for maintainance ("etch") and one for
the next Debian version ("lenny").  I maintain them as stgit stacks to
be able to easily port changes to new upstream releases, and tag
debian revisions on the stack heads - so the ancestry of a revision to
the previous can only be tracked through stgit patch logs.

The recent history of those stack is a bit tricky, and that may not
help here: there was originally a single "debian" stack, and I had
already done some unreleased work in existing patches, when the need
for a bugfix release appeared.  So I cloned the "main" branch, and
reproduced the previous release by deleting the only patch that had
moved since the last release, and picking it from the relevant commit.

Then to make things more interresting I imported a new release on
"upstream", and rebased stack "lenny" onto this new release.

Then I wanted to integrate the bugfix from "etch" into "lenny".  So I
just tried to use "stg sync" on this patch.  It should be noted that
this particular patch is the one that adds the Debian packaging files
(as opposed to the other ones, which modify the upstream source
files).

Here is what I get.  I suppose that could have been expected, but that
looks nevertheless annoying...

tau-git$ stg sync -b etch debian
Checking for changes in the working directory... done
Synchronising "debian"...Error: File "debian/tau.files" added in branches but different
Error: File "debian/tau-racy.files" added in branches but different
Error: File "debian/rules" added in branches but different
Error: File "debian/changelog" added in branches but different
stg sync: GIT index merging failed (possible conflicts)

Traceback (most recent call last):
  File "/export/work/yann/git/stgit/stg", line 43, in ?
    main()
  File "/export/work/yann/git/stgit/stgit/main.py", line 268, in main
    command.func(parser, options, args)
  File "/export/work/yann/git/stgit/stgit/commands/sync.py", line 163, in func
    merge_patch(patch, p)
  File "/export/work/yann/git/stgit/stgit/commands/sync.py", line 96, in <lambda>
    merge_patch = lambda patch, pname: \
  File "/export/work/yann/git/stgit/stgit/commands/sync.py", line 58, in __branch_merge_patch
    git.merge(patch.get_bottom(), git.get_head(), patch.get_top())
  File "/export/work/yann/git/stgit/stgit/git.py", line 664, in merge
    raise GitException, 'GIT index merging failed (possible conflicts)'
stgit.git.GitException: GIT index merging failed (possible conflicts)

best regards,
-- 
Yann.

Re: Use of "stg sync"

[Catalin Marinas]

On 04/02/07, Yann Dirson <ydirson@altern.org> wrote:
[...]
> Then I wanted to integrate the bugfix from "etch" into "lenny".  So I
> just tried to use "stg sync" on this patch.  It should be noted that
> this particular patch is the one that adds the Debian packaging files
> (as opposed to the other ones, which modify the upstream source
> files).
>
> Here is what I get.  I suppose that could have been expected, but that
> looks nevertheless annoying...

Have you modified the last try/except block in stgit.main.main? You
should only get an error message, not the full backtrace.

The interesting messages are:

> Synchronising "debian"...Error: File "debian/tau.files" added in branches but different
> Error: File "debian/tau-racy.files" added in branches but different
> Error: File "debian/rules" added in branches but different
> Error: File "debian/changelog" added in branches but different
> stg sync: GIT index merging failed (possible conflicts)

Which are what I would expect the 'sync' command to do - it tries a
three-way merge between the debian//top, debian@etch//top and
debian@etch//bottom (the order is probably different). Since the
debian/rules etc. files aren't present in debian@etch//bottom and you
modified them in debian@etch//top, you get a merge conflict - files
added in both branches but different.

'stg status' should show the conflict files and you have to manually
fix them. If you know that you only modified the patch in etch, you
can do 'stg resolved -a -r patched'. You could also add 'recursive =
True' argument to the git.merge() call in
stgit.commands.sync.__branch_merge_patch(). This would perform a merge
with 'git-merge-recursive' rather than 'git-read-tree -m' and it is
supposed to do a smarter two-way merging. You might not get a conflict
at all or, at least, the conflicted file would have some markers.

The reason I didn't add the recursive merge for 'sync' was the
slowness of this operation (git-read-tree -m was faster but maybe
git-merge-recursive was improved in the last weeks). Please try this
and let me know whether you get better results so I can modify the
'sync' command.

Anyway, this is a limitation of 'sync' three-way merging and I
couldn't find an easy solution. For me, the best thing is that if the
patch was synchronised, there won't be any conflicts reported and I
can be sure they are the same. You mentioned patches of patches some
time ago but these would get lost on the first rebase (unless you want
to have a patch made of sub-stacks but you get to a fractal structure
with sub-sub-...-sub-stacks :-))

-- 
Catalin