bugStacked Git - Bugs: bug #9079, "push" is unable to...

Show feedback again

bug #9079: "push" is unable to detect a merged patch when later upstream commits touch the same files

Submitted by:  Yann Dirson <ydirson>
Submitted on:  Fri May 4 22:32:32 2007  
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalStatus: None
Privacy: PublicAssigned to: None
Open/Closed: OpenRelease: v0.12
Planned Release: None

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


Thu Dec 6 21:43:07 2007, comment #1:

I agree that the merge detection can be better but reverse-applying a patch was the easiest to implement. I don't fully understand how the code below would work with detecting multiple merged patches when subsequent patches modify the same lines as the first (reverse applying solves this by, well, applying the patches in reverse order).

What about trying a three-way merge with reversed patches?

I try to fix a few bugs left and release 0.14 but I'll probably skip this one for know. I would even consider it a feature request rather than a bug.

Catalin Marinas <cmarinas>
Project Administrator
Fri May 4 22:32:32 2007, original submission:

This is due to how merged patches are detected : any conflict trying to unapply the patch causes the merge not to be noticed, and leaves the user with a useless conflict to solve.

One way to handle this is to automate the manual process I use, described here fo a single patch:

1. first, one must note that this notion only makes sense after pulling, and we are looking for patches being merged between a former stack base and the current one. The current revision of the patch being push--merged may be sometimes used to find the old base, but a rewinding-head parent makes it harder: maybe we need to track the current base as a patch attribute ?

2. try to push the patch as we currently do (maybe even use the current merge-detection code)

3. if that fails, identify the latest conflicting patch. If below the fomer base, then we have a real conflict; else temporarily rebase to the parent of this conflicting patch, and recurse, until we find it merged or until we're sure we conflict.

4. rebase back if needed, and push with conflict if needed

When we need to "push --merge" a full stack, I fear the only safe way is just to repeat these operations for all patches.

Yann Dirson <ydirson>
Project Member


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by cmarinas (Posted a comment)
  • -unavailable- added by ydirson (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu Dec 6 21:43:07 2007cmarinasPriority7 - High=>5 - Normal
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup