Git development
 help / color / mirror / Atom feed
From: "Björn Steinbrink" <B.Steinbrink@gmx.de>
To: Sergei Organov <osv@javad.com>
Cc: git@vger.kernel.org
Subject: Re: Newbie: report of first experience with git-rebase.
Date: Wed, 31 Oct 2007 20:57:02 +0100	[thread overview]
Message-ID: <20071031195702.GB24332@atjola.homenet> (raw)
In-Reply-To: <87d4uv3wh1.fsf@osv.gnss.ru>

On 2007.10.31 22:39:06 +0300, Sergei Organov wrote:
> Hello,
> 
> I've made my first attempt at tracking my changes to upstream git
> repository using git-fetch/git-rebase workflow. I did three commits to
> my master branch, and then upstream incorporated two of them in slightly
> modified form, so that some conflicts are to be expected. I did
> git-fetch followed by git-rebase, and finally have got the end result I
> hoped for, but there were some confusion along the way. I think I'd post
> the log of the session here along with my thoughts so that an interested
> person could see how it works for a newbie (my thoughts and non-git
> actions at the time of rebasing are marked with 'me>' prefix):
> 
> $ git fetch
> [...]
> $ git rebase origin
> First, rewinding head to replay your work on top of it...
> HEAD is now at 9c51414... Merge branch 'maint' into HEAD
> 
> Applying Fix a typo.
> 
> Wrote tree f5b2feefc021486eae9d2d84c69e0d6ead027a9d
> Committed: 983e907b1360c17c7ac925d6035d82cc7243f406
> 
> Applying Use new syntax (-m option) for git-merge.
> 
> error: patch failed: Documentation/core-tutorial.txt:878
> error: Documentation/core-tutorial.txt: patch does not apply
> Using index info to reconstruct a base tree...
> Falling back to patching base and 3-way merge...
> Auto-merged Documentation/core-tutorial.txt
> CONFLICT (content): Merge conflict in Documentation/core-tutorial.txt
> Failed to merge in the changes.
> Patch failed at 0002.
> 
> 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".
> 
> me> Nice, this conflict is expected.
> me> Editing Documentation/core-tutorial.txt to resolve the
> me> conflict... Conflict is resolved so that the working file matches
> me> upstream version.
> 
> $ git rebase --continue
> You must edit all merge conflicts and then
> mark them as resolved using git add
> 
> me> Nice helpful message, -- need to do git-add
> 
> $ git add Documentation/core-tutorial.txt
> $ git rebase --continue
> 
> Applying Use new syntax (-m option) for git-merge.
> 
> No changes - did you forget to use 'git add'?
> 
> 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".
> 
> me> What?! I just did the git-add! Moreover, before I did git-add, the
> me> error was different and helpful. Something went wrong? 
> me> Well, it's unlikely, but maybe I made a mistake of not specifying
> me> the 'origin'?
> 
> $ git rebase --continue origin
> 
> Applying Use new syntax (-m option) for git-merge.
> 
> No changes - did you forget to use 'git add'?
> 
> 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".
> 
> me> No luck :( A few seconds of thinking... Hmm... no-op patch, do I
> me> need to skip it? Let's try the --skip:
> 
> $ git rebase --skip
> 
> Applying Fix SYNOPSIS.
> 
> error: patch failed: Documentation/git-merge.txt:10
> error: Documentation/git-merge.txt: patch does not apply
> Using index info to reconstruct a base tree...
> Falling back to patching base and 3-way merge...
> Auto-merged Documentation/git-merge.txt
> CONFLICT (content): Merge conflict in Documentation/git-merge.txt
> Failed to merge in the changes.
> Patch failed at 0003.
> 
> 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".
> 
> me> Aha, that's it! But why git didn't just skip the no-op patch

It wasn't a no-op patch. It had conflicts which you resolved to the
upstream version and _then_ you had a no-op.

> me> automatically? Well, anyway , now I have a new expected conflict,
> me> and I'm sure I just want to skip this patch, so let's try exactly
> me> that:
> 
> $ git rebase --skip
> Dirty index: cannot apply patches (dirty: Documentation/git-merge.txt)
> 
> me> No luck :( Well, let's go the long way, -- edit conflicting
> me> Documentation/git-merge.txt (so that it matches upstream),
> 
> $ git add Documentation/git-merge.txt
> $ git rebase --skip
> Nothing to do.
> 
> me> Well, I already knew this will work, but why should I edit the file
> me> and then git-add it just to skip the patch? Is there better way?
> me> Anyway, the "Nothing to do." above is slightly confusing, -- did it
> me> actually skip the patch? So let's check the result:

There seems to be some bug in rebase that makes it fail in this case.
Someone on #git also reported that --abort failed to reset his branch to
the old head in a similar case, but I didn't manage to reproduce that
yet (well, I didn't try that hard), so I don't know if it's really a bug
or a misuse by that guy.

Björn

  reply	other threads:[~2007-10-31 19:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-31 19:39 Newbie: report of first experience with git-rebase Sergei Organov
2007-10-31 19:57 ` Björn Steinbrink [this message]
2007-10-31 20:28   ` Sergei Organov
2007-10-31 21:12     ` Johannes Schindelin
2007-10-31 21:29       ` J. Bruce Fields
2007-10-31 22:06         ` Steven Grimm
2007-10-31 22:35           ` Daniel Barkalow
2007-10-31 22:38           ` J. Bruce Fields
2007-10-31 21:39       ` Junio C Hamano
2007-10-31 22:53         ` David Kastrup
2007-11-01  2:27         ` Nicolas Pitre
2007-11-01 12:13         ` Sergei Organov
2007-11-01 14:24           ` Johannes Schindelin
2007-11-01 15:10             ` J. Bruce Fields
2007-11-01 20:20               ` Junio C Hamano
2007-11-02 10:13                 ` Andreas Ericsson
2007-11-02 19:11                   ` Junio C Hamano
     [not found]                     ` <472B77AC.5080507@midwinter.com>
2007-11-02 19:22                       ` Andreas Ericsson
2007-10-31 22:49       ` David Kastrup
2007-10-31 21:25 ` Alex Riesen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071031195702.GB24332@atjola.homenet \
    --to=b.steinbrink@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=osv@javad.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox