Newbie: report of first experience with git-rebase.

Newbie: report of first experience with git-rebase.

[Sergei Organov]

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
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:

$ gitk

me> The result is as expected, -- the only patch on top of current origin
me> HEAD, -- nice.

-- 
Sergei.

Re: Newbie: report of first experience with git-rebase.

[Björn Steinbrink]

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

Re: Newbie: report of first experience with git-rebase.

[Sergei Organov]

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.

Re: Newbie: report of first experience with git-rebase.

[Johannes Schindelin]

Hi,

On Wed, 31 Oct 2007, Sergei Organov wrote:

> 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?

Isn't that obvious?  To prevent you from accidentally losing a commit.

Ciao,
Dscho

Re: Newbie: report of first experience with git-rebase.

[Alex Riesen]

Sergei Organov, Wed, Oct 31, 2007 20:39:06 +0100:
> $ 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'?

This "No changes" was meant as a hint

> 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? 

Well, you edited you tree to look exactly like it already is.

> 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

Exactly.

> 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
> me> automatically? Well, anyway , now I have a new expected conflict,

it was not a noop patch before you resolved the 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)

Well... This one kind of hard: git-rebase _cannot_ know whether it is
safe to just drop all changes in the index and work tree (you could
have made the changes on purpose). It was decided not to drop
anything. You always can do

    $ git reset --hard # kills all changes in index and work tree
    $ git rebase --skip

(or maybe git-rebase is just too careful...)

> 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:

Yes. It was the last commit. You were just too unlucky to hit all the
hard cases your first day.

Re: Newbie: report of first experience with git-rebase.

[J. Bruce Fields]

On Wed, Oct 31, 2007 at 09:12:06PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Wed, 31 Oct 2007, Sergei Organov wrote:
> 
> > 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?
> 
> Isn't that obvious?  To prevent you from accidentally losing a commit.

That would make sense to me if this was a mistake that could easily
happen.

I'd assumed that in the case of a conflict that stopped the rebase
process, the index and working tree are always left dirty, so that if
they both agree with the HEAD at the time of commit, then it's because
the user explicitly made them that way.

I ran into the same confusion as the original poster when starting to
use rebase, so I suspect it's common.

--b.

Re: Newbie: report of first experience with git-rebase.

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Wed, 31 Oct 2007, Sergei Organov wrote:
>
>> 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?
>
> Isn't that obvious?  To prevent you from accidentally losing a commit.

In case it is not obvious...

A rebase conflict resolution that results in emptiness is a
rather rare event (especially because rebase drops upfront the
identical changes from the set of commits to be replayed), but
it does happen.  One could argue that "rebase --continue" can
notice that the resolved index is identical to the tree of the
HEAD commit and skip it automatically.

Given an index that is identical to HEAD, however, it is not
easy to safely determine if that is because the patch did not
apply at all, or the patch was applied with conflicts _and_ the
user decided to make the patch a no-op by resolving.  The
automatic droppage of the commit needs to happen only on the
latter and never on the former.

Re: Newbie: report of first experience with git-rebase.

[Steven Grimm]

J. Bruce Fields wrote:
> I ran into the same confusion as the original poster when starting to
> use rebase, so I suspect it's common.
>   

I've been using rebase just about every day for close to a year and it 
*still* annoys me when it happens. Especially the "Did you forget to git 
add?" part of the message. The thought that always goes through my head 
is, "No, Mr. Rebase, I did NOT forget to git add. I remembered to git 
add, then you were too stupid to do the right thing after that."

Just happened to me this morning, in fact: I had a quick hack in place 
to work around a bug, the bug got fixed for real, and I rebased. In the 
process of conflict resolution I saw that my workaround wasn't needed 
any more and accepted the upstream version of that particular part of 
the file. Ran git-add on it, then rebase --continue, and boom, was 
accused of forgetting to run git-add.

It is a minor annoyance and nowadays I just sigh a bit and run --skip 
instead, but it'd be nice if it didn't happen. I don't like having to 
care whether or not I happened to change other files in a particular 
commit after I resolve conflicts in one file in favor of the upstream 
version.

-Steve

Re: Newbie: report of first experience with git-rebase.

[Daniel Barkalow]

On Wed, 31 Oct 2007, Steven Grimm wrote:

> J. Bruce Fields wrote:
> > I ran into the same confusion as the original poster when starting to
> > use rebase, so I suspect it's common.
> >   
> 
> I've been using rebase just about every day for close to a year and it *still*
> annoys me when it happens. Especially the "Did you forget to git add?" part of
> the message. The thought that always goes through my head is, "No, Mr. Rebase,
> I did NOT forget to git add. I remembered to git add, then you were too stupid
> to do the right thing after that."
> 
> Just happened to me this morning, in fact: I had a quick hack in place to work
> around a bug, the bug got fixed for real, and I rebased. In the process of
> conflict resolution I saw that my workaround wasn't needed any more and
> accepted the upstream version of that particular part of the file. Ran git-add
> on it, then rebase --continue, and boom, was accused of forgetting to run
> git-add.
> 
> It is a minor annoyance and nowadays I just sigh a bit and run --skip instead,
> but it'd be nice if it didn't happen. I don't like having to care whether or
> not I happened to change other files in a particular commit after I resolve
> conflicts in one file in favor of the upstream version.

I think it's worth requiring you to say --skip in order to acknowledge 
that you won't have as many commits and you'll lose the commit message. On 
the other hand, the message should probably suggest that you might want to 
skip this commit instead of suggesting that you come up with some other 
change to include in it.

Certainly, if "git diff" returns no changes, "git add" is a bad 
suggestion, and it would be nicer to suggest something possibly correct.

	-Daniel
*This .sig left intentionally blank*

Re: Newbie: report of first experience with git-rebase.

[J. Bruce Fields]

On Wed, Oct 31, 2007 at 03:06:20PM -0700, Steven Grimm wrote:
> I've been using rebase just about every day for close to a year and it 
> *still* annoys me when it happens. Especially the "Did you forget to git 
> add?" part of the message. The thought that always goes through my head is, 
> "No, Mr. Rebase, I did NOT forget to git add. I remembered to git add, then 
> you were too stupid to do the right thing after that."
>
> Just happened to me this morning, in fact: I had a quick hack in place to 
> work around a bug, the bug got fixed for real, and I rebased. In the 
> process of conflict resolution I saw that my workaround wasn't needed any 
> more and accepted the upstream version of that particular part of the file. 
> Ran git-add on it, then rebase --continue, and boom, was accused of 
> forgetting to run git-add.
>
> It is a minor annoyance and nowadays I just sigh a bit and run --skip 
> instead, but it'd be nice if it didn't happen. I don't like having to care 
> whether or not I happened to change other files in a particular commit 
> after I resolve conflicts in one file in favor of the upstream version.

Yeah, I think a message saying "patch is now empty, skipping..." would
be sufficient to let the user know what's going on.  This doesn't seem
so perilous to me that it's worth requiring a positive acknowledgement.

--b.

Re: Newbie: report of first experience with git-rebase.

[David Kastrup]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Wed, 31 Oct 2007, Sergei Organov wrote:
>
>> 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?
>
> Isn't that obvious?  To prevent you from accidentally losing a commit.

The commit would not change anything, so what is there to lose?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Newbie: report of first experience with git-rebase.

[David Kastrup]

Junio C Hamano <gitster@pobox.com> writes:

> A rebase conflict resolution that results in emptiness is a rather
> rare event (especially because rebase drops upfront the identical
> changes from the set of commits to be replayed), but it does happen.
> One could argue that "rebase --continue" can notice that the resolved
> index is identical to the tree of the HEAD commit and skip it
> automatically.
>
> Given an index that is identical to HEAD, however, it is not
> easy to safely determine if that is because the patch did not
> apply at all,

Wouldn't there be a conflict in the index?  A conflict which can only be
resolved by adding?  Which then results in a question whether you forgot
to add?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Newbie: report of first experience with git-rebase.

[Nicolas Pitre]

On Wed, 31 Oct 2007, Junio C Hamano wrote:

> A rebase conflict resolution that results in emptiness is a
> rather rare event (especially because rebase drops upfront the
> identical changes from the set of commits to be replayed), but
> it does happen.  One could argue that "rebase --continue" can
> notice that the resolved index is identical to the tree of the
> HEAD commit and skip it automatically.
> 
> Given an index that is identical to HEAD, however, it is not
> easy to safely determine if that is because the patch did not
> apply at all, or the patch was applied with conflicts _and_ the
> user decided to make the patch a no-op by resolving.  The
> automatic droppage of the commit needs to happen only on the
> latter and never on the former.

Probably some additional clue could be displayed for the user benefit.  
This might solve the issue nicely.


Nicolas

Re: Newbie: report of first experience with git-rebase.

[Sergei Organov]

Junio C Hamano <gitster@pobox.com> writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Wed, 31 Oct 2007, Sergei Organov wrote:
>>
>>> 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?
>>
>> Isn't that obvious?  To prevent you from accidentally losing a commit.
>
> In case it is not obvious...
>
> A rebase conflict resolution that results in emptiness is a
> rather rare event (especially because rebase drops upfront the
> identical changes from the set of commits to be replayed), but
> it does happen.

Funny how 2 of my first 3 commits suffer from this "rather rare event",
and it was not Friday, 13 ;)

-- 
Sergei.

Re: Newbie: report of first experience with git-rebase.

[Johannes Schindelin]

Hi,

On Thu, 1 Nov 2007, Sergei Organov wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> On Wed, 31 Oct 2007, Sergei Organov wrote:
> >>
> >>> 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?
> >>
> >> Isn't that obvious?  To prevent you from accidentally losing a commit.
> >
> > In case it is not obvious...
> >
> > A rebase conflict resolution that results in emptiness is a
> > rather rare event (especially because rebase drops upfront the
> > identical changes from the set of commits to be replayed), but
> > it does happen.
> 
> Funny how 2 of my first 3 commits suffer from this "rather rare event",
> and it was not Friday, 13 ;)

They are rare events.  In your case I guess that subtly different versions 
were _actually_ applied (such as white space fixes), which is why such a 
rare event hit you.

Ciao,
Dscho

Re: Newbie: report of first experience with git-rebase.

[J. Bruce Fields]

On Thu, Nov 01, 2007 at 02:24:37PM +0000, Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 1 Nov 2007, Sergei Organov wrote:
> 
> > Junio C Hamano <gitster@pobox.com> writes:
> > 
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > >> On Wed, 31 Oct 2007, Sergei Organov wrote:
> > >>
> > >>> 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?
> > >>
> > >> Isn't that obvious?  To prevent you from accidentally losing a commit.
> > >
> > > In case it is not obvious...
> > >
> > > A rebase conflict resolution that results in emptiness is a
> > > rather rare event (especially because rebase drops upfront the
> > > identical changes from the set of commits to be replayed), but
> > > it does happen.
> > 
> > Funny how 2 of my first 3 commits suffer from this "rather rare event",
> > and it was not Friday, 13 ;)
> 
> They are rare events.  In your case I guess that subtly different versions 
> were _actually_ applied (such as white space fixes),

That's actually pretty common, in my experience.

> which is why such a rare event hit you.

I'm using git to track some changes I submitted to a project that's
mainly text, and that I only get release tarballs of.  On my most recent
rebase all my patches got applied, but the text also got re-wrapped and
re-indented at the same time.  So all but I think one or two of a dozen
patches ended up with a conflict resolution and then --skip.

Which may not be a case git's really intended for--fair enough.  But
I've found it's pretty common in my kernel work too.  Either I'm
rebasing against changes I made myself, or else a maintainer took my
changes but fixed up some minor style problems along the way.

--b.

Re: Newbie: report of first experience with git-rebase.

[Junio C Hamano]

"J. Bruce Fields" <bfields@fieldses.org> writes:

> On Thu, Nov 01, 2007 at 02:24:37PM +0000, Johannes Schindelin wrote:
>> 
>> They are rare events.  In your case I guess that subtly different versions 
>> were _actually_ applied (such as white space fixes),
>
> That's actually pretty common, in my experience.
>
>> which is why such a rare event hit you.
>
> I'm using git to track some changes I submitted to a project that's
> mainly text, and that I only get release tarballs of.  On my most recent
> rebase all my patches got applied, but the text also got re-wrapped and
> re-indented at the same time.  So all but I think one or two of a dozen
> patches ended up with a conflict resolution and then --skip.
>
> Which may not be a case git's really intended for--fair enough.  But
> I've found it's pretty common in my kernel work too.  Either I'm
> rebasing against changes I made myself, or else a maintainer took my
> changes but fixed up some minor style problems along the way.

Ok, so I retract that "rare" comment.

Now, we have established that this is a real problem worth
solving, what's next?

Re: Newbie: report of first experience with git-rebase.

[Andreas Ericsson]

Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
>> On Thu, Nov 01, 2007 at 02:24:37PM +0000, Johannes Schindelin wrote:
>>> They are rare events.  In your case I guess that subtly different versions 
>>> were _actually_ applied (such as white space fixes),
>> That's actually pretty common, in my experience.
>>
>>> which is why such a rare event hit you.
>> I'm using git to track some changes I submitted to a project that's
>> mainly text, and that I only get release tarballs of.  On my most recent
>> rebase all my patches got applied, but the text also got re-wrapped and
>> re-indented at the same time.  So all but I think one or two of a dozen
>> patches ended up with a conflict resolution and then --skip.
>>
>> Which may not be a case git's really intended for--fair enough.  But
>> I've found it's pretty common in my kernel work too.  Either I'm
>> rebasing against changes I made myself, or else a maintainer took my
>> changes but fixed up some minor style problems along the way.
> 
> Ok, so I retract that "rare" comment.
> 
> Now, we have established that this is a real problem worth
> solving, what's next?

Make "git rebase --skip" skip patches regardless of tree and index state,
but still refuse to *start* with dirty tree or index. That way, there's
no risk of losing anything that can't be re-created unless the user asks
for it.

To be really anal, stash the current mess somewhere, re-apply the same
patch and diff the two states. If they're identical, do "git reset --hard"
and hop to next patch in rebase-series. If they're not, ask user to say
"--force-skip" instead.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Newbie: report of first experience with git-rebase.

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> Junio C Hamano wrote:
>>
>> Now, we have established that this is a real problem worth
>> solving, what's next?
>
> Make "git rebase --skip" skip patches regardless of tree and index state,
> but still refuse to *start* with dirty tree or index. That way, there's
> no risk of losing anything that can't be re-created unless the user asks
> for it.

Sounds like a plan.

Re: Newbie: report of first experience with git-rebase.

[Andreas Ericsson]

Steven Grimm wrote:
> Junio C Hamano wrote:
>> Andreas Ericsson <ae@op5.se> writes:
>>  
>>> Make "git rebase --skip" skip patches regardless of tree and index 
>>> state,
>>> but still refuse to *start* with dirty tree or index. That way, there's
>>> no risk of losing anything that can't be re-created unless the user asks
>>> for it.
>>>     
>>
>> Sounds like a plan.
>>   
> 
> I'm unclear how that helps the usability issue here at all, though it 
> doesn't sound like an unreasonable change on its own merit.
> 

Because 'git commit --skip' will not require the user to first edit the
tree so the index matches the upstream thing, and he doesn't have to
manually run 'git reset --hard' before --skip'ing.

It's a small improvement, but one that goes in the right direction.

Btw, the above sentence should've read "but still refuse to *start*
(as in, start a brand new rebase) with dirty tree or index"

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231