Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Stefan Monnier]

> branch: master
> commit f9fabb2bb099d944cc97a87933b86b9eae02d067
> Merge: 570edf2 b0f3a49
> Author: Michael Albinus <michael.albinus@gmx.de>
> Commit: Michael Albinus <michael.albinus@gmx.de>

>     Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs
    
What happened, here?

   git diff 570edf2..f9fabb2bb099d944cc97a87933b86b9eae02d067

is empty (i.e. the "merge" just threw away all the changes from
b0f3a49, i.e. from "master").  And indeed:

   git diff b0f3a49..f9fabb2bb099d944cc97a87933b86b9eae02d067

shows that you reverted a bunch of the recent commits
applied to "master".  How did this happen?


        Stefan

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> branch: master
>> commit f9fabb2bb099d944cc97a87933b86b9eae02d067
>> Merge: 570edf2 b0f3a49
>> Author: Michael Albinus <michael.albinus@gmx.de>
>> Commit: Michael Albinus <michael.albinus@gmx.de>
>
>>     Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs
>     
> What happened, here?
>
>    git diff 570edf2..f9fabb2bb099d944cc97a87933b86b9eae02d067
>
> is empty (i.e. the "merge" just threw away all the changes from
> b0f3a49, i.e. from "master").  And indeed:
>
>    git diff b0f3a49..f9fabb2bb099d944cc97a87933b86b9eae02d067
>
> shows that you reverted a bunch of the recent commits
> applied to "master".  How did this happen?

Oh shit. Something like this:

- I've seen the messages in emacs-devel that I did an error syncing
  tramp.el from the Tramp repository. Panic.

- I've fixed this in the local Emacs repository, and committed it.

- I've tried to push tramp.el, which failed (due to further commits in
  the remote Emacs repository).

- I've pulled from the remote Emacs repository, getting a conflict in
  tramp.el. Glenn had fixed the problem already, but there are
  whitespace difference between his and my change.

- I've fixed the conflict in tramp.el, and committed it.

- I've tried to push, but I was said that it's not possible because the
  previous merge wasn't finished.

- ERROR: I've reverted all open changes in my Emacs repository.

- I've pushed.

I must claim, that I'm still in fight with git. After a merge conflict,
it let's *other* items edited I have never touched, and I often don't
know what to do :-(

Conclusion: I will try to implement a local pull-before-and-push-after
commit policy. This shall minimize merge conflicts.

I am very sorry that I have brought to you additional work, again.

>         Stefan

Best regards, Michael.

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Artur Malabarba]

> - I've pulled from the remote Emacs repository, getting a conflict in
>   tramp.el. Glenn had fixed the problem already, but there are
>   whitespace difference between his and my change.
>
> - I've fixed the conflict in tramp.el, and committed it.

As a general tip. Next time you try to pull and find out someone
already has already done what you just did, don't resolve the merge
conflict. Instead, abort the merge with `git merge --abort` (this will
get you back to the state you had right before the pull), and then
locally revert your commit.

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Michael Albinus]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> As a general tip. Next time you try to pull and find out someone
> already has already done what you just did, don't resolve the merge
> conflict. Instead, abort the merge with `git merge --abort` (this will
> get you back to the state you had right before the pull), and then
> locally revert your commit.

Thanks. Will try it.

Best regards, Michael.

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Andreas Schwab]

Especially: Don't Panic!

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Michael Albinus]

Andreas Schwab <schwab@suse.de> writes:

> Especially: Don't Panic!

In theory, I know. 

> Andreas.

Best regards, Michael.

"In theory, there is no difference between theory and practice. In
practice, there is."

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Thu, 28 May 2015 10:13:49 +0200
> Cc: emacs-devel@gnu.org
> 
> - I've tried to push, but I was said that it's not possible because the
>   previous merge wasn't finished.

You should have finished it (whatever that means; you didn't show
enough info about that to tell what else needed to be done).

> - ERROR: I've reverted all open changes in my Emacs repository.
> 
> - I've pushed.

Not sure how it is possible, nor what "all open changes in my
repository" means here.  I think it's important to analyze and
understand what happened, in order for you to make sure you don't make
such mistakes in the future.

> I must claim, that I'm still in fight with git. After a merge conflict,
> it let's *other* items edited I have never touched, and I often don't
> know what to do :-(

What exactly do you mean by "it let's *other* items edited I have
never touched"?  Can you show an example?

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> Date: Thu, 28 May 2015 10:27:15 +0100
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> As a general tip. Next time you try to pull and find out someone
> already has already done what you just did, don't resolve the merge
> conflict. Instead, abort the merge with `git merge --abort` (this will
> get you back to the state you had right before the pull), and then
> locally revert your commit.

I don't see how this advice will be able to keep Michael out of
trouble next time.  AFAICT, it will just get him in a different
situation, one that isn't simpler or safer to deal with.  Locally
reverting commits risks losing them, for example.

OTOH, merge conflicts are nothing to be afraid of, the procedure to
handle them is simple and straightforward.  Michael (and every one
else here) should IMO master that simple procedure, instead of
avoiding it.

In a dVCS, you cannot rely on being able to avoid merges all the time
anyway.  There are always races with other developers.

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> - ERROR: I've reverted all open changes in my Emacs repository.
>> 
>> - I've pushed.
>
> Not sure how it is possible, nor what "all open changes in my
> repository" means here.  I think it's important to analyze and
> understand what happened, in order for you to make sure you don't make
> such mistakes in the future.

I try to use vc-dir as much as possible. At this step, several files
were marked as "edited", surprisingly. IIRC all files which were
reported between my two previous pull requests, while I did commit
tramp.el locally. That's to say the files, Stefan has repaired with
f655987d63e181deb5e6fef1f93b409d96184fae. Since I didn't know it better,
I've reverted all the local changes of them.

>> I must claim, that I'm still in fight with git. After a merge conflict,
>> it let's *other* items edited I have never touched, and I often don't
>> know what to do :-(
>
> What exactly do you mean by "it let's *other* items edited I have
> never touched"?  Can you show an example?

The files I've mentioned above.

Best regards, Michael.

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> As a general tip. Next time you try to pull and find out someone
>> already has already done what you just did, don't resolve the merge
>> conflict. Instead, abort the merge with `git merge --abort` (this will
>> get you back to the state you had right before the pull), and then
>> locally revert your commit.
>
> I don't see how this advice will be able to keep Michael out of
> trouble next time.  AFAICT, it will just get him in a different
> situation, one that isn't simpler or safer to deal with.  Locally
> reverting commits risks losing them, for example.

That's what I did, likely.

However, the tip might give me a way to bring the git repo back to a
stable state, with potential loosing of local changes. As long as I'm
not fluent in solving merge conflicts, that's good to know.

> OTOH, merge conflicts are nothing to be afraid of, the procedure to
> handle them is simple and straightforward.  Michael (and every one
> else here) should IMO master that simple procedure, instead of
> avoiding it.
>
> In a dVCS, you cannot rely on being able to avoid merges all the time
> anyway.  There are always races with other developers.

If git would be more friendly to tell what happens ... why the hell I
must take care on files I've never touched myself.

Best regards, Michael.

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Thu, 28 May 2015 17:00:03 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> - ERROR: I've reverted all open changes in my Emacs repository.
> >> 
> >> - I've pushed.
> >
> > Not sure how it is possible, nor what "all open changes in my
> > repository" means here.  I think it's important to analyze and
> > understand what happened, in order for you to make sure you don't make
> > such mistakes in the future.
> 
> I try to use vc-dir as much as possible. At this step, several files
> were marked as "edited", surprisingly. IIRC all files which were
> reported between my two previous pull requests, while I did commit
> tramp.el locally. That's to say the files, Stefan has repaired with
> f655987d63e181deb5e6fef1f93b409d96184fae. Since I didn't know it better,
> I've reverted all the local changes of them.

In this situation, it is better to invoke "git status" from the shell
prompt, it would have probably explained the situation much better.
IOW, I'm guessing you were tripped by some vc-dir bug or misfeature,
and the files marked "edited" were actually successfully merged and
staged for committing, which you should have done after resolving the
conflicts.

Btw, when you say you've committed tramp.el after resolving the
conflicts, what exactly did you do?  Did you commit only that file, or
did you commit all the files that were ready to be committed?

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: bruce.connor.am@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 28 May 2015 17:05:08 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> As a general tip. Next time you try to pull and find out someone
> >> already has already done what you just did, don't resolve the merge
> >> conflict. Instead, abort the merge with `git merge --abort` (this will
> >> get you back to the state you had right before the pull), and then
> >> locally revert your commit.
> >
> > I don't see how this advice will be able to keep Michael out of
> > trouble next time.  AFAICT, it will just get him in a different
> > situation, one that isn't simpler or safer to deal with.  Locally
> > reverting commits risks losing them, for example.
> 
> That's what I did, likely.
> 
> However, the tip might give me a way to bring the git repo back to a
> stable state, with potential loosing of local changes. As long as I'm
> not fluent in solving merge conflicts, that's good to know.

IMO, that's a misconception.  There's nothing "unstable" in having
conflicts or having a merge initiated by "git pull" be aborted due to
conflicts.  You can make safe changes from this situation, and you can
make unsafe changes from a reset tip (as it seems you did).

The procedure to resolve merge conflicts is simple: edit the
conflicted files, run "git add" on each one of them (VC should do this
automatically), make sure "git status" shows only staged files, and
then "git commit" all of them.  That's it.

And at any stage, you can always use "git status" and
"git diff origin/master" to show what still needs to be done to bring
your local clone in sync with upstream.

> > OTOH, merge conflicts are nothing to be afraid of, the procedure to
> > handle them is simple and straightforward.  Michael (and every one
> > else here) should IMO master that simple procedure, instead of
> > avoiding it.
> >
> > In a dVCS, you cannot rely on being able to avoid merges all the time
> > anyway.  There are always races with other developers.
> 
> If git would be more friendly to tell what happens ...

It will be more helpful if you use "git status" more frequently.

> why the hell I must take care on files I've never touched myself.

You don't.  You just need to commit them after all conflicts have been
resolved.

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Phillip Lord]

Michael Albinus <michael.albinus@gmx.de> writes:
> That's what I did, likely.
>
> However, the tip might give me a way to bring the git repo back to a
> stable state, with potential loosing of local changes. As long as I'm
> not fluent in solving merge conflicts, that's good to know.
>
>> OTOH, merge conflicts are nothing to be afraid of, the procedure to
>> handle them is simple and straightforward.  Michael (and every one
>> else here) should IMO master that simple procedure, instead of
>> avoiding it.
>>
>> In a dVCS, you cannot rely on being able to avoid merges all the time
>> anyway.  There are always races with other developers.
>
> If git would be more friendly to tell what happens ... why the hell I
> must take care on files I've never touched myself.


Perhaps the sensible way forward would be to push to a branch either on
or off the the main repo and then do a request pull. Much easier for
anyone scared of git (like me).

Of course, some one has to be able to answer the request, but then
having this set up would be no bad thing anyway, for those without
commit access, as well as those just scared.

Phil

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Andreas Schwab]

Michael Albinus <michael.albinus@gmx.de> writes:

> I try to use vc-dir as much as possible.

vc-dir is only useful for very simple operations.  It doesn't understand
anything about merges, for example.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Btw, when you say you've committed tramp.el after resolving the
> conflicts, what exactly did you do?  Did you commit only that file, or
> did you commit all the files that were ready to be committed?

I've touched only tramp.el (and likely, I did something like "git reset
lisp/net/tramp.el" first). The other files I've simply reverted in
Emacs' vc-dir buffer, via "C-x v u", IIRC.

Best regards, Michael.

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Dmitry Gutov]

On 05/28/2015 06:52 PM, Michael Albinus wrote:

> The other files I've simply reverted in
> Emacs' vc-dir buffer, via "C-x v u", IIRC.

Yeah, you shouldn't have done that. When you're merging the upstream 
into the current branch, and there's a conflict, it stages all new 
changes that apply without conflicts and asks you to resolve the 
conflicts in the rest of files (and stage them too).

Reverting any of the already staged files means you remove those changes 
from the tree the merge will result in.

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 2663 bytes --]

>> As a general tip. Next time you try to pull and find out someone
>> already has already done what you just did, don't resolve the merge
>> conflict. Instead, abort the merge with git merge --abort (this will
>> get you back to the state you had right before the pull), and then
>> locally revert your commit.
>
> I don't see how this advice will be able to keep Michael out of
> trouble next time.  AFAICT, it will just get him in a different
> situation, one that isn't simpler or safer to deal with.  Locally
> reverting commits risks losing them, for example.

Yes, that was the point. If I wrote a commit to fix something that's
already fixed, that commit is now useless, so I discard it.

The reason I prefer that instead of merging is that it's just easier and
simpler that way (at least to me), mainly because:


1. Reverting a commit only affects code I've just written, so it takes very
little mental energy. I know what I'm changing with 100% certainty.
2. Resolving a merge conflict involves both mine and someone else's code,
so I'll need to invest some energy to read and interpret that code (might
be a little or a lot, depending on the code).
3. Even after I've read and interpreted the new remote code, there's always
a small chance I miss some tiny detail inside a large diff when resolving
the conflict. (I've introduced bugs this way a couple of times, whereas
I've never introduced a bug while reverting).
4. Even when the conflict is simple and I know I can solve it without risk,
doing the merge will still keep redundant commits in the history. It's not
a huge deal, but there's no reason to have two commits doing the exact same
thing.

I'm not saying merge conflicts are the devil, or that they're any reason to
panick. But if I can prevent the conflict by killing a redundant commit,
then that is easier, safer, and cleaner.

However, you're right that a person who is not very familiar with git is
better off not mucking around with things like reset, revert, and rebase.
OTOH, you can always just create a branch wherever you are and use that as
a backup. When I was first learning git, that was the first thing I did
everytime I panicked, and it never failed me.

> OTOH, merge conflicts are nothing to be afraid of, the procedure to
> handle them is simple and straightforward.  Michael (and every one
> else here) should IMO master that simple procedure, instead of
> avoiding it.
>
> In a dVCS, you cannot rely on being able to avoid merges all the time
> anyway.  There are always races with other developers.

Agreed. Merge conflicts are just part of the deal. I was just explaining
how I avoid one specific type of conflict.

[-- Attachment #2: Type: text/html, Size: 3019 bytes --]

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Thu, 28 May 2015 17:52:19 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw, when you say you've committed tramp.el after resolving the
> > conflicts, what exactly did you do?  Did you commit only that file, or
> > did you commit all the files that were ready to be committed?
> 
> I've touched only tramp.el (and likely, I did something like "git reset
> lisp/net/tramp.el" first). The other files I've simply reverted in
> Emacs' vc-dir buffer, via "C-x v u", IIRC.

That's a mistake.  You were in the middle of a failed merge, with most
of the new stuff successfully merged and ready to be committed.  What
you needed to do is commit all of them, including tramp.el, after
resolving the conflicts, and making sure "git status" shows only files
that are staged for commit.

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Stefan Monnier]

> "In theory, there is no difference between theory and practice. In
> practice, there is."

That's only true in theory,


        Stefan

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> Date: Thu, 28 May 2015 17:24:30 +0100
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: Michael Albinus <michael.albinus@gmx.de>, emacs-devel <emacs-devel@gnu.org>
> Yes, that was the point. If I wrote a commit to fix something that's already
> fixed, that commit is now useless, so I discard it. 

This is a singular situation that happens very rarely, so it's really
more of exception than the rule.

Learning to deal with merge conflicts, OTOH, will teach the user to
cope with a much broader class of problems.

> 1. Reverting a commit only affects code I've just written, so it takes very
> little mental energy. I know what I'm changing with 100% certainty.
> 2. Resolving a merge conflict involves both mine and someone else's code, so
> I'll need to invest some energy to read and interpret that code (might be a
> little or a lot, depending on the code).

If you got a conflict, it means you've modified the same areas as that
someone, so presumably you know enough about that code to deal with
the conflict.

> 3. Even after I've read and interpreted the new remote code, there's always a
> small chance I miss some tiny detail inside a large diff when resolving the
> conflict. (I've introduced bugs this way a couple of times, whereas I've never
> introduced a bug while reverting).

Talking with the persons involved is allowed.  Git doesn't make us
speechless.

> 4. Even when the conflict is simple and I know I can solve it without risk,
> doing the merge will still keep redundant commits in the history. It's not a
> huge deal, but there's no reason to have two commits doing the exact same
> thing. 

Yes, there is a reason: use a routine procedure as frequently as it
fits the bill, and you will become fluent with it and stop being
scared.

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Stefan Monnier]

> I try to use vc-dir as much as possible. At this step, several files
> were marked as "edited", surprisingly. IIRC all files which were
> reported between my two previous pull requests, while I did commit
> tramp.el locally. That's to say the files, Stefan has repaired with

Yes, it's something annoys me in other ways as well.
When you do a "git pull" (or equivalent) when ends up being a merge
rather than a fast-forward, you're basically adding the *other* branch's
code to yours, so when there's a conflict it shows you that other code
and those places where it conflicts with yours.

Furthermore, it messes up the repository's "mainline".

The way Git intends you to use it, you should basically never
"commit+push" on the "master" branch.  Instead you should do all
development on some other branch, and then to push it to master, you
need to do "checkout master; git pull; git merge <branch>; git push" and
if the push fails, you need to "git reset --soft HEAD^" and try again.

I should sit down and write a "git update" command which would work like
"git pull" but which pulls the current branch into the other branch
instead of the other way around.


        Stefan

Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Yuri Khan]

On Fri, May 29, 2015 at 1:02 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> I should sit down and write a "git update" command which would work like
> "git pull" but which pulls the current branch into the other branch
> instead of the other way around.

You might want to look at github:nvie/gitflow, especially its "git
flow feature finish" command.