* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs [not found] ` <E1YxeWz-0008TK-TD@vcs.savannah.gnu.org> @ 2015-05-28 2:40 ` Stefan Monnier 2015-05-28 8:13 ` Michael Albinus 0 siblings, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2015-05-28 2:40 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 2:40 ` [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs Stefan Monnier @ 2015-05-28 8:13 ` Michael Albinus 2015-05-28 9:27 ` Artur Malabarba 2015-05-28 14:40 ` Eli Zaretskii 0 siblings, 2 replies; 22+ messages in thread From: Michael Albinus @ 2015-05-28 8:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 8:13 ` Michael Albinus @ 2015-05-28 9:27 ` Artur Malabarba 2015-05-28 10:05 ` Michael Albinus 2015-05-28 14:46 ` Eli Zaretskii 2015-05-28 14:40 ` Eli Zaretskii 1 sibling, 2 replies; 22+ messages in thread From: Artur Malabarba @ 2015-05-28 9:27 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-devel > - 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 9:27 ` Artur Malabarba @ 2015-05-28 10:05 ` Michael Albinus 2015-05-28 10:16 ` Andreas Schwab 2015-05-28 14:46 ` Eli Zaretskii 1 sibling, 1 reply; 22+ messages in thread From: Michael Albinus @ 2015-05-28 10:05 UTC (permalink / raw) To: Artur Malabarba; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 10:05 ` Michael Albinus @ 2015-05-28 10:16 ` Andreas Schwab 2015-05-28 10:26 ` Michael Albinus 0 siblings, 1 reply; 22+ messages in thread From: Andreas Schwab @ 2015-05-28 10:16 UTC (permalink / raw) To: Michael Albinus; +Cc: Artur Malabarba, emacs-devel 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." ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 10:16 ` Andreas Schwab @ 2015-05-28 10:26 ` Michael Albinus 2015-05-28 16:55 ` Stefan Monnier 0 siblings, 1 reply; 22+ messages in thread From: Michael Albinus @ 2015-05-28 10:26 UTC (permalink / raw) To: Andreas Schwab; +Cc: Artur Malabarba, emacs-devel 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." ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 10:26 ` Michael Albinus @ 2015-05-28 16:55 ` Stefan Monnier 0 siblings, 0 replies; 22+ messages in thread From: Stefan Monnier @ 2015-05-28 16:55 UTC (permalink / raw) To: Michael Albinus; +Cc: Andreas Schwab, Artur Malabarba, emacs-devel > "In theory, there is no difference between theory and practice. In > practice, there is." That's only true in theory, Stefan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 9:27 ` Artur Malabarba 2015-05-28 10:05 ` Michael Albinus @ 2015-05-28 14:46 ` Eli Zaretskii 2015-05-28 15:05 ` Michael Albinus 2015-05-28 16:24 ` Artur Malabarba 1 sibling, 2 replies; 22+ messages in thread From: Eli Zaretskii @ 2015-05-28 14:46 UTC (permalink / raw) To: bruce.connor.am; +Cc: michael.albinus, emacs-devel > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 14:46 ` Eli Zaretskii @ 2015-05-28 15:05 ` Michael Albinus 2015-05-28 15:26 ` Eli Zaretskii 2015-05-28 15:44 ` Phillip Lord 2015-05-28 16:24 ` Artur Malabarba 1 sibling, 2 replies; 22+ messages in thread From: Michael Albinus @ 2015-05-28 15:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bruce.connor.am, emacs-devel 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 15:05 ` Michael Albinus @ 2015-05-28 15:26 ` Eli Zaretskii 2015-05-28 15:44 ` Phillip Lord 1 sibling, 0 replies; 22+ messages in thread From: Eli Zaretskii @ 2015-05-28 15:26 UTC (permalink / raw) To: Michael Albinus; +Cc: bruce.connor.am, emacs-devel > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 15:05 ` Michael Albinus 2015-05-28 15:26 ` Eli Zaretskii @ 2015-05-28 15:44 ` Phillip Lord 1 sibling, 0 replies; 22+ messages in thread From: Phillip Lord @ 2015-05-28 15:44 UTC (permalink / raw) To: Michael Albinus; +Cc: Eli Zaretskii, bruce.connor.am, emacs-devel 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 14:46 ` Eli Zaretskii 2015-05-28 15:05 ` Michael Albinus @ 2015-05-28 16:24 ` Artur Malabarba 2015-05-28 17:02 ` Eli Zaretskii 1 sibling, 1 reply; 22+ messages in thread From: Artur Malabarba @ 2015-05-28 16:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Michael Albinus, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 16:24 ` Artur Malabarba @ 2015-05-28 17:02 ` Eli Zaretskii 0 siblings, 0 replies; 22+ messages in thread From: Eli Zaretskii @ 2015-05-28 17:02 UTC (permalink / raw) To: bruce.connor.am; +Cc: michael.albinus, emacs-devel > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 8:13 ` Michael Albinus 2015-05-28 9:27 ` Artur Malabarba @ 2015-05-28 14:40 ` Eli Zaretskii 2015-05-28 15:00 ` Michael Albinus 1 sibling, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2015-05-28 14:40 UTC (permalink / raw) To: Michael Albinus; +Cc: monnier, emacs-devel > 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 14:40 ` Eli Zaretskii @ 2015-05-28 15:00 ` Michael Albinus 2015-05-28 15:19 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Michael Albinus @ 2015-05-28 15:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 15:00 ` Michael Albinus @ 2015-05-28 15:19 ` Eli Zaretskii 2015-05-28 15:52 ` Michael Albinus 2015-05-28 15:49 ` Andreas Schwab 2015-05-28 19:02 ` Stefan Monnier 2 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2015-05-28 15:19 UTC (permalink / raw) To: Michael Albinus; +Cc: monnier, emacs-devel > 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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 15:19 ` Eli Zaretskii @ 2015-05-28 15:52 ` Michael Albinus 2015-05-28 15:56 ` Dmitry Gutov 2015-05-28 16:52 ` Eli Zaretskii 0 siblings, 2 replies; 22+ messages in thread From: Michael Albinus @ 2015-05-28 15:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 15:52 ` Michael Albinus @ 2015-05-28 15:56 ` Dmitry Gutov 2015-05-28 16:52 ` Eli Zaretskii 1 sibling, 0 replies; 22+ messages in thread From: Dmitry Gutov @ 2015-05-28 15:56 UTC (permalink / raw) To: Michael Albinus, Eli Zaretskii; +Cc: monnier, emacs-devel 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 15:52 ` Michael Albinus 2015-05-28 15:56 ` Dmitry Gutov @ 2015-05-28 16:52 ` Eli Zaretskii 1 sibling, 0 replies; 22+ messages in thread From: Eli Zaretskii @ 2015-05-28 16:52 UTC (permalink / raw) To: Michael Albinus; +Cc: monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 15:00 ` Michael Albinus 2015-05-28 15:19 ` Eli Zaretskii @ 2015-05-28 15:49 ` Andreas Schwab 2015-05-28 19:02 ` Stefan Monnier 2 siblings, 0 replies; 22+ messages in thread From: Andreas Schwab @ 2015-05-28 15:49 UTC (permalink / raw) To: Michael Albinus; +Cc: Eli Zaretskii, monnier, emacs-devel 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." ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 15:00 ` Michael Albinus 2015-05-28 15:19 ` Eli Zaretskii 2015-05-28 15:49 ` Andreas Schwab @ 2015-05-28 19:02 ` Stefan Monnier 2015-05-29 2:20 ` Yuri Khan 2 siblings, 1 reply; 22+ messages in thread From: Stefan Monnier @ 2015-05-28 19:02 UTC (permalink / raw) To: Michael Albinus; +Cc: Eli Zaretskii, emacs-devel > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs 2015-05-28 19:02 ` Stefan Monnier @ 2015-05-29 2:20 ` Yuri Khan 0 siblings, 0 replies; 22+ messages in thread From: Yuri Khan @ 2015-05-29 2:20 UTC (permalink / raw) To: Stefan Monnier; +Cc: Eli Zaretskii, Michael Albinus, Emacs developers 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2015-05-29 2:20 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20150527165006.32357.80915@vcs.savannah.gnu.org> [not found] ` <E1YxeWz-0008TK-TD@vcs.savannah.gnu.org> 2015-05-28 2:40 ` [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs Stefan Monnier 2015-05-28 8:13 ` Michael Albinus 2015-05-28 9:27 ` Artur Malabarba 2015-05-28 10:05 ` Michael Albinus 2015-05-28 10:16 ` Andreas Schwab 2015-05-28 10:26 ` Michael Albinus 2015-05-28 16:55 ` Stefan Monnier 2015-05-28 14:46 ` Eli Zaretskii 2015-05-28 15:05 ` Michael Albinus 2015-05-28 15:26 ` Eli Zaretskii 2015-05-28 15:44 ` Phillip Lord 2015-05-28 16:24 ` Artur Malabarba 2015-05-28 17:02 ` Eli Zaretskii 2015-05-28 14:40 ` Eli Zaretskii 2015-05-28 15:00 ` Michael Albinus 2015-05-28 15:19 ` Eli Zaretskii 2015-05-28 15:52 ` Michael Albinus 2015-05-28 15:56 ` Dmitry Gutov 2015-05-28 16:52 ` Eli Zaretskii 2015-05-28 15:49 ` Andreas Schwab 2015-05-28 19:02 ` Stefan Monnier 2015-05-29 2:20 ` Yuri Khan
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).