stgit - continue rebase after merge conflict?

Hi Catalin,

How does one do a stg rebase if there are merge conflicts?

I see:

-------------------------------------------------------
achiang@blender:~/kernels/linux-2.6$ stg rebase origin
Upgraded branch stg-pci-slots to format version 2
Checking for changes in the working directory ... done
Popping all applied patches ... done
Rebasing to "origin" ... done
Pushing patch "0001-Remove-path-attribute-from-sgi_hotplug.patch" ... done
Pushing patch "0002-Construct-one-fakephp-slot-per-pci-slot.patch" ... 
  CONFLICT (content): Merge conflict in drivers/pci/hotplug/fakephp.c
  Error: The merge failed during "push".
         Revert the operation with "push --undo".
  stg rebase: 1 conflict(s)
-------------------------------------------------------

This output tells you how to undo the rebase, but doesn't give any clues on how to continue it, like git would:

------------------------------------------------------- When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort". -------------------------------------------------------

Doing an 'stg help rebase' isn't so helpful.

My *guess* is that I want to:

	- manually resolve the merge conflicts
	- stg refresh
	- ???

Any hints are appreciated.

Thanks.

/ac

On 26/02/2008, Alex Chiang <achiang@hp.com> wrote:

Basically, you solve the conflict, refresh the current patch and continue with 'stg push' or 'stg goto <top patch>'. The 'rebase' command does 'pop --all', 'git reset', 'push --all'. In your conflict, the base of the stack was already changed to the latest and hence only push/goto is needed. To fix it:

$ vi files # or simply use 'resolved -i' below $ stg resolved -a [-i] $ stg refresh $ stg goto top-patch

or (if you want to skip that patch):

$ stg push --undo $ stg push next-patch..

The 'rebase' command doesn't store any information about the state of the stack and cannot continue it. Maybe we'll do something in the next release as the refactored code has support for transactions.

Yet another option is to enable the automatic interactive merge ('git config stgit.autoimerge yes') and, at a conflict, it calls your three-way merge tool (emacs, xxdiff etc.). If the merge tool succeeds, the rebase will simply continue.

Yes, indeed. It could be made better.

* Catalin Marinas <catalin.marinas@gmail.com>:

Thanks.

I see.

How about this?

/ac

From: Alex Chiang <achiang@hp.com>

Enhance rebase help string by providing guidance on merge conflict resolution during a rebase.

Based on text suggested by Catalin Marinas.

Signed-off-by: Alex Chiang <achiang@hp.com>
---

On 2008-02-26 16:56:53 +0000, Catalin Marinas wrote:

Better use

  $ stg push next-patch..top-patch

which works even if you don't want to push _all_ patches.

Hmm, that's an interesting idea. Maybe an "stg resume" command that one would run after having resolved the conflicts.

One implementation would be to save a .stgit-todo file with contents like this:

  push foo
  push bar
  push baz

It would have to handle more than just pushes, however. For example, stg coalesce will try to first push the given patches in order, and then coalesce them, so for that case .stgit-todo might look like this:

  push bar
  push baz
  coalesce foo bar baz
  push frotz

We should be able to redefine each non-atomic stgit command in terms of such atomic commands, and get resumeability all over the place.

I'm not sure this is a good idea, but it is intriguing.

* Catalin Marinas <catalin.marinas@gmail.com>:

That goto command doesn't tell you about merge conflicts:

achiang@blender:~/kernels/linux-2.6$ stg series
+ 0001-Remove-path-attribute-from-sgi_hotplug.patch

- 0003-Introduce-pci_slot.patch
- 0004-ACPI-PCI-slot-detection-driver.patch

achiang@blender:~/kernels/linux-2.6$ stg goto 0004-ACPI-PCI-slot-detection-driver.patch 
Pushed 0003-Introduce-pci_slot.patch (conflict)
Error: Merge conflict
Now at patch "0003-Introduce-pci_slot.patch"

achiang@blender:~/kernels/linux-2.6$ stg series
+ 0001-Remove-path-attribute-from-sgi_hotplug.patch
+ 0002-Construct-one-fakephp-slot-per-pci-slot.patch

- 0004-ACPI-PCI-slot-detection-driver.patch

Since this patch series is small, I just did a 'stg push' and now it tells me about the conflicts. But I don't think I'd want to do that if I was managing tens or hundreds of patches...

achiang@blender:~/kernels/linux-2.6$ stg push --undo
Undoing push of "0003-Introduce-pci_slot.patch" ... done
Now at patch "0002-Construct-one-fakephp-slot-per-pci-slot.patch"
achiang@blender:~/kernels/linux-2.6$ stg push
Checking for changes in the working directory ... done
Pushing patch "0003-Introduce-pci_slot.patch" ... 
  CONFLICT (content): Merge conflict in drivers/pci/hotplug/acpiphp_ibm.c
  CONFLICT (content): Merge conflict in drivers/pci/hotplug/pci_hotplug_core.c
  CONFLICT (content): Merge conflict in drivers/pci/hotplug/rpadlpar_sysfs.c
  CONFLICT (content): Merge conflict in include/linux/pci.h
  CONFLICT (content): Merge conflict in include/linux/pci_hotplug.h
  Error: The merge failed during "push".
         Revert the operation with "push --undo".
  stg push: 5 conflict(s)

Is this pilot error? Or is goto misbehaving?

Thanks.

/ac

On 28/02/2008, Alex Chiang <achiang@hp.com> wrote:

[...]

It says that it's a merge conflict but isn't more precise than that. You can run 'stg status' to check the conflicts.

The reason is that you are probably using the development branch of StGIT and we (actually Karl) are refactoring the GIT objects handling. The 'goto' command (but not 'push') was moved to the new infrastructure but missed some of the UI stuff. They'll be added back.

I could use the stable branch until we sort out these issues.

On 2008-02-28 21:50:04 +0000, Catalin Marinas wrote:

Yeah, I'd forgotten all about that. I rarely get conflicts when running "stg goto".