From: Sergei Organov <osv@javad•com>
To: git@vger•kernel.org
Subject: Re: Newbie: report of first experience with git-rebase.
Date: Wed, 31 Oct 2007 23:28:38 +0300 [thread overview]
Message-ID: <874pg73u6h.fsf@osv.gnss.ru> (raw)
In-Reply-To: <20071031195702.GB24332@atjola.homenet> ("Björn Steinbrink"'s message of "Wed\, 31 Oct 2007 20\:57\:02 +0100")
Björn Steinbrink <B.Steinbrink@gmx•de> writes:
> 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.
Yes, and that's the problem. Why 'git --continue' didn't just skip this
patch that *already became no-op* after conflict resolution and forced
me to explicitly use 'git --skip' instead?
This forces one to use 'git --skip' if the patch happens to become a
no-op after conflict resolution, and 'git --continue' otherwise. Why
this complication?
--
Sergei.
next prev parent reply other threads:[~2007-10-31 20:28 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
2007-10-31 20:28 ` Sergei Organov [this message]
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=874pg73u6h.fsf@osv.gnss.ru \
--to=osv@javad$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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