* Stupid git! @ 2015-09-12 10:15 Alan Mackenzie 2015-09-12 10:21 ` Alan Mackenzie ` (3 more replies) 0 siblings, 4 replies; 41+ messages in thread From: Alan Mackenzie @ 2015-09-12 10:15 UTC (permalink / raw) To: emacs-devel Hello, Emacs. git has struck again, and another couple of hours valuable time have been lost. Having "staged" a change with `git add', I then tried to commit it with `git commit'. Somebody else had got in before me, so I had to pull their changes first - fair enough. So I did `git pull'. I was then dumped into an editing session for a merge operation for .../test/automated/file-notify-tests.el. Eh? I've never touched this file in my life, and didn't even know it existed. So why is a merge necessary/why has a merge been (half-)done? Why didn't git pull simply merge the changes to this file into my repository and working directory? So I aborted this merge operation, in order to see what it's doing first. git has kindly discarded my (staged) change, leaving no record of its existence - good job I've still got a copy of the changed file in Emacs. Scrabbling around in the .git directory, I found the commit message in a file there. So all is not lost. How do I see what changes are in file-notify-tests.el, which is in the staging area? I would have thought some variety of `git diff' ought to do the trick, but how to do this is not made obvious in the fine manual for `git diff'. Time to save my changed file and have a coffee. Isn't git wonderful! -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 10:15 Stupid git! Alan Mackenzie @ 2015-09-12 10:21 ` Alan Mackenzie 2015-09-12 10:40 ` Dmitry Gutov ` (2 subsequent siblings) 3 siblings, 0 replies; 41+ messages in thread From: Alan Mackenzie @ 2015-09-12 10:21 UTC (permalink / raw) To: emacs-devel Hello, Emacs. On Sat, Sep 12, 2015 at 10:15:14AM +0000, Alan Mackenzie wrote: > git has struck again, and another couple of hours valuable time have > been lost. > Having "staged" a change with `git add', I then tried to commit it with > `git commit'. Somebody else had got in before me, so I had to pull > their changes first - fair enough. > So I did `git pull'. I was then dumped into an editing session for a > merge operation for .../test/automated/file-notify-tests.el. Eh? I've > never touched this file in my life, and didn't even know it existed. So > why is a merge necessary/why has a merge been (half-)done? Why didn't > git pull simply merge the changes to this file into my repository and > working directory? > So I aborted this merge operation, in order to see what it's doing > first. git has kindly discarded my (staged) change, leaving no record > of its existence - good job I've still got a copy of the changed file in > Emacs. Scrabbling around in the .git directory, I found the commit > message in a file there. So all is not lost. Sorry, scrub that bit! My commit had saved the file OK. I'd got confused with another situation in which git delete[sd] changes. > How do I see what changes are in file-notify-tests.el, which is in the > staging area? I would have thought some variety of `git diff' ought to > do the trick, but how to do this is not made obvious in the fine manual > for `git diff'. > Time to save my changed file and have a coffee. Isn't git wonderful! > -- > Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 10:15 Stupid git! Alan Mackenzie 2015-09-12 10:21 ` Alan Mackenzie @ 2015-09-12 10:40 ` Dmitry Gutov 2015-09-12 12:29 ` Alan Mackenzie 2015-09-12 20:37 ` Stefan Monnier 2015-09-12 10:40 ` David Kastrup 2015-09-12 11:45 ` Giuseppe Scrivano 3 siblings, 2 replies; 41+ messages in thread From: Dmitry Gutov @ 2015-09-12 10:40 UTC (permalink / raw) To: Alan Mackenzie, emacs-devel On 09/12/2015 01:15 PM, Alan Mackenzie wrote: > Having "staged" a change with `git add', I then tried to commit it with > `git commit'. Somebody else had got in before me, so I had to pull > their changes first - fair enough. I don't get it. This sounds like the commit failed because someone has pushed to master in the upstream repo first. Which obviously can't happen because git doesn't have "bound branches" a la Bazaar. But in general, you either 'git stage' and then 'git pull', or 'git add', 'git commit' (!), and then either rebase or merge upstream. The fact that git allows pulling after 'git add' sounds like a bug to me, but apparently it sort-of fine because you can do two-way merge, or even abort the merge and return to the previous state. > So I did `git pull'. I was then dumped into an editing session for a > merge operation for .../test/automated/file-notify-tests.el. Eh? I've > never touched this file in my life, and didn't even know it existed. So > why is a merge necessary/why has a merge been (half-)done? Why didn't > git pull simply merge the changes to this file into my repository and > working directory? Was there a conflict in this file, or not? If yes, you can see the diverging changes. If not, then you don't need to merge it at all, just resolve the conflicts. How were you even "dumped into an editing session"? What tool did that? > So I aborted this merge operation, in order to see what it's doing > first. git has kindly discarded my (staged) change, leaving no record > of its existence - good job I've still got a copy of the changed file in > Emacs. That might be a good subject for a bug report. > How do I see what changes are in file-notify-tests.el, which is in the > staging area? I would have thought some variety of `git diff' ought to > do the trick, but how to do this is not made obvious in the fine manual > for `git diff'. git diff --cached (or --staged, it's a synonym) It's pretty easy to find out in the output of 'man git diff' on my system. Not sure what manual you've been reading. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 10:40 ` Dmitry Gutov @ 2015-09-12 12:29 ` Alan Mackenzie 2015-09-12 12:34 ` David Kastrup ` (2 more replies) 2015-09-12 20:37 ` Stefan Monnier 1 sibling, 3 replies; 41+ messages in thread From: Alan Mackenzie @ 2015-09-12 12:29 UTC (permalink / raw) To: Dmitry Gutov; +Cc: emacs-devel Hello, Dmitry. On Sat, Sep 12, 2015 at 01:40:03PM +0300, Dmitry Gutov wrote: > On 09/12/2015 01:15 PM, Alan Mackenzie wrote: > > Having "staged" a change with `git add', I then tried to commit it with > > `git commit'. Somebody else had got in before me, so I had to pull > > their changes first - fair enough. > I don't get it. This sounds like the commit failed because someone has > pushed to master in the upstream repo first. Which obviously can't > happen because git doesn't have "bound branches" a la Bazaar. Sorry, I got confused. I thought I'd only half-committed the change (with `git add'), whereas I had in fact fully committed it. > But in general, you either 'git stage' and then 'git pull', or 'git > add', 'git commit' (!), and then either rebase or merge upstream. It's when first doing `git add', then `git pull' when I've lost changes before. > The fact that git allows pulling after 'git add' sounds like a bug to > me, but apparently it sort-of fine because you can do two-way merge, or > even abort the merge and return to the previous state. I've always done a final `git pull' before committing in the past, so as to avoid merges as far as possible. This is what has lost me changes. > > So I did `git pull'. I was then dumped into an editing session for a > > merge operation for .../test/automated/file-notify-tests.el. Eh? I've > > never touched this file in my life, and didn't even know it existed. So > > why is a merge necessary/why has a merge been (half-)done? Why didn't > > git pull simply merge the changes to this file into my repository and > > working directory? > Was there a conflict in this file, or not? If yes, you can see the > diverging changes. If not, then you don't need to merge it at all, just > resolve the conflicts. There were no conflicts, just the other contributer's changes that my `git pull' had pulled. > How were you even "dumped into an editing session"? What tool did that? git did, on my `git pull'. I think I can see what happened now - when there's a pending push already committed, git refuses to merge in even unrelated changes. Instead it merged the file in my working directory, leaving me to commit it. I'm not sure why. > > So I aborted this merge operation, in order to see what it's doing > > first. git has kindly discarded my (staged) change, leaving no record > > of its existence - good job I've still got a copy of the changed file in > > Emacs. > That might be a good subject for a bug report. That was my mistake: the commit had already been fully committed, not just half committed like I'd thought. > > How do I see what changes are in file-notify-tests.el, which is in the > > staging area? I would have thought some variety of `git diff' ought to > > do the trick, but how to do this is not made obvious in the fine manual > > for `git diff'. > git diff --cached (or --staged, it's a synonym) OK, thanks! > It's pretty easy to find out in the output of 'man git diff' on my > system. Not sure what manual you've been reading. It's not easy at all - I've got the collected edition of git man pages in an info file. The one for git diff is 1036 lines long. I tried searching for "index" and "staging", to no avail - I think I stopped the search after getting beyond the OPTIONS section. Now that I know that "--cached" is the answer, that is specified in the EXAMPLES section. "--staged" doesn't appear at all. Anyhow, I used --staged to look at the file. Thanks! -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 12:29 ` Alan Mackenzie @ 2015-09-12 12:34 ` David Kastrup 2015-09-12 12:59 ` Alan Mackenzie 2015-09-12 20:14 ` Dmitry Gutov 2015-09-14 10:09 ` Steinar Bang 2 siblings, 1 reply; 41+ messages in thread From: David Kastrup @ 2015-09-12 12:34 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel, Dmitry Gutov Alan Mackenzie <acm@muc.de> writes: > It's not easy at all - I've got the collected edition of git man pages > in an info file. The one for git diff is 1036 lines long. Well, the conversion to Texinfo from AsciiDoc is understandably worse in quality with regard to indices and references than stuff written originally in Texinfo. I still prefer that version (and you'll find that the "make info" target is pretty much my doing). -- David Kastrup ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 12:34 ` David Kastrup @ 2015-09-12 12:59 ` Alan Mackenzie 0 siblings, 0 replies; 41+ messages in thread From: Alan Mackenzie @ 2015-09-12 12:59 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel, Dmitry Gutov Hello, David. On Sat, Sep 12, 2015 at 02:34:43PM +0200, David Kastrup wrote: > Alan Mackenzie <acm@muc.de> writes: > > It's not easy at all - I've got the collected edition of git man pages > > in an info file. The one for git diff is 1036 lines long. > Well, the conversion to Texinfo from AsciiDoc is understandably worse in > quality with regard to indices and references than stuff written > originally in Texinfo. But a good deal better than struggling through lots of individual man pages. > I still prefer that version (and you'll find that the "make info" target > is pretty much my doing). :-) I take my hat off to you, sir! > -- > David Kastrup -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 12:29 ` Alan Mackenzie 2015-09-12 12:34 ` David Kastrup @ 2015-09-12 20:14 ` Dmitry Gutov 2015-09-14 10:09 ` Steinar Bang 2 siblings, 0 replies; 41+ messages in thread From: Dmitry Gutov @ 2015-09-12 20:14 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel On 09/12/2015 03:29 PM, Alan Mackenzie wrote: > Sorry, I got confused. I thought I'd only half-committed the change > (with `git add'), whereas I had in fact fully committed it. Then you were simply doing a merge, which is the second step of 'git pull' ('git fetch' + 'git merge'). > It's when first doing `git add', then `git pull' when I've lost changes > before. Is this about some other, older situation? >> The fact that git allows pulling after 'git add' sounds like a bug to >> me, but apparently it sort-of fine because you can do two-way merge, or >> even abort the merge and return to the previous state. > > I've always done a final `git pull' before committing in the past, so as > to avoid merges as far as possible. This is what has lost me changes. That's inadvisable: one is most likely to lose changed by not committing them. Committing before pull is the Git Way. 'git pull --rebase' can also be used if you want cleaner history, but judiciously: if you're absolutely sure that none of the new commits on the current branch have ever been published (pushed to the remote). So don't rebase if you've done any merges, just accept the default behavior of 'git pull'. >> Was there a conflict in this file, or not? If yes, you can see the >> diverging changes. If not, then you don't need to merge it at all, just >> resolve the conflicts. > > There were no conflicts, just the other contributer's changes that my > `git pull' had pulled. Then you didn't need to open it, just needed to resolve any remaining conflicts (in other files), then type 'git commit'. >> How were you even "dumped into an editing session"? What tool did that? > > git did, on my `git pull'. I'm pretty sure Git launches $EDITOR only when asking the user for the commit message. > I think I can see what happened now - when > there's a pending push already committed, git refuses to merge in even > unrelated changes. That's implausible. If you could write a sample scenario step by step using two local repos, one close of another, we'll discuss this further. > Instead it merged the file in my working directory, > leaving me to commit it. I'm not sure why. Maybe you have '--no-commit' somewhere in your .gitconfig. > It's not easy at all - I've got the collected edition of git man pages > in an info file. The one for git diff is 1036 lines long. Why don't you check out the original man page, too? Do you have it installed? > I tried > searching for "index" and "staging", to no avail - I think I stopped the > search after getting beyond the OPTIONS section. Now that I know that > "--cached" is the answer, that is specified in the EXAMPLES section. > "--staged" doesn't appear at all. In my git-diff man page (that comes with Git 2.1.0), the examples section is at the top (it's called DESCRIPTION). The third paragraph both includes the words "staged changes" and "--staged": git diff [--options] --cached [<commit>] [--] [<path>...] This form is to view the changes you staged for the next commit relative to the named <commit>. Typically you would want comparison with the latest commit, so if you do not give <commit>, it defaults to HEAD. If HEAD does not exist (e.g. unborn branches) and <commit> is not given, it shows all staged changes. --staged is a synonym of --cached. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 12:29 ` Alan Mackenzie 2015-09-12 12:34 ` David Kastrup 2015-09-12 20:14 ` Dmitry Gutov @ 2015-09-14 10:09 ` Steinar Bang 2 siblings, 0 replies; 41+ messages in thread From: Steinar Bang @ 2015-09-14 10:09 UTC (permalink / raw) To: emacs-devel >>>>> Alan Mackenzie <acm@muc.de>: >> But in general, you either 'git stage' and then 'git pull', or 'git >> add', 'git commit' (!), and then either rebase or merge upstream. > It's when first doing `git add', then `git pull' when I've lost changes > before. It happens sometimes, when you stash files that have been staged with "git add". It happened to me once (when I was trying to disprove Alan's claims earlier) but I have been unable to reproduce it since. If someone can get a reproducible case, it would be a good idea to make a bug report with the case to git. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 10:40 ` Dmitry Gutov 2015-09-12 12:29 ` Alan Mackenzie @ 2015-09-12 20:37 ` Stefan Monnier 1 sibling, 0 replies; 41+ messages in thread From: Stefan Monnier @ 2015-09-12 20:37 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Alan Mackenzie, emacs-devel > The fact that git allows pulling after 'git add' sounds like a bug to me, In my experience, git allows pulling before as well as after "git add". The main restriction is that it doesn't let you pull/merge if one of the locally modified files has also been modified in the pulled/merge code. Stefan ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 10:15 Stupid git! Alan Mackenzie 2015-09-12 10:21 ` Alan Mackenzie 2015-09-12 10:40 ` Dmitry Gutov @ 2015-09-12 10:40 ` David Kastrup 2015-09-12 10:53 ` Dmitry Gutov 2015-09-12 12:52 ` Alan Mackenzie 2015-09-12 11:45 ` Giuseppe Scrivano 3 siblings, 2 replies; 41+ messages in thread From: David Kastrup @ 2015-09-12 10:40 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel Alan Mackenzie <acm@muc.de> writes: > Hello, Emacs. > > git has struck again, and another couple of hours valuable time have > been lost. > > Having "staged" a change with `git add', I then tried to commit it with > `git commit'. Somebody else had got in before me, so I had to pull > their changes first - fair enough. Uh, no? git commit goes to your local repository. There is nobody else who could "get in before you". You never need to pull before committing. You may want to rebase after pulling, depending on your kind of change. > So I aborted this merge operation, in order to see what it's doing > first. git has kindly discarded my (staged) change, leaving no record > of its existence - good job I've still got a copy of the changed file > in Emacs. Scrabbling around in the .git directory, I found the commit > message in a file there. So all is not lost. > > How do I see what changes are in file-notify-tests.el, which is in the > staging area? git diff --cached > Time to save my changed file and have a coffee. Isn't git wonderful! When things start looking fishy, don't just stumble on blindly. Save what you got somewhere else, and _then_ try muddling through. That's not particular to Git. -- David Kastrup ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 10:40 ` David Kastrup @ 2015-09-12 10:53 ` Dmitry Gutov 2015-09-12 12:52 ` Alan Mackenzie 1 sibling, 0 replies; 41+ messages in thread From: Dmitry Gutov @ 2015-09-12 10:53 UTC (permalink / raw) To: David Kastrup, Alan Mackenzie; +Cc: emacs-devel On 09/12/2015 01:40 PM, David Kastrup wrote: > When things start looking fishy, don't just stumble on blindly. Save > what you got somewhere else, and _then_ try muddling through. And in the case of Git, you don't even need to go "somewhere else". Committing changes is a safe way to remember them. Even if you commit them to master, and then do something unsafe like rebase or 'reset --hard', 'git reflog' will still allow you to find any commit previously created in this local repository. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 10:40 ` David Kastrup 2015-09-12 10:53 ` Dmitry Gutov @ 2015-09-12 12:52 ` Alan Mackenzie 1 sibling, 0 replies; 41+ messages in thread From: Alan Mackenzie @ 2015-09-12 12:52 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel Hello, David. On Sat, Sep 12, 2015 at 12:40:20PM +0200, David Kastrup wrote: > Alan Mackenzie <acm@muc.de> writes: > > Hello, Emacs. > > git has struck again, and another couple of hours valuable time have > > been lost. > > Having "staged" a change with `git add', I then tried to commit it with > > `git commit'. Somebody else had got in before me, so I had to pull > > their changes first - fair enough. > Uh, no? git commit goes to your local repository. There is nobody else > who could "get in before you". You never need to pull before > committing. You may want to rebase after pulling, depending on your > kind of change. My mistake. I'd committed the change, then tried to push it. Sorry about that. > > So I aborted this merge operation, in order to see what it's doing > > first. git has kindly discarded my (staged) change, leaving no record > > of its existence - good job I've still got a copy of the changed file > > in Emacs. Scrabbling around in the .git directory, I found the commit > > message in a file there. So all is not lost. > > How do I see what changes are in file-notify-tests.el, which is in the > > staging area? > git diff --cached Thanks! > > Time to save my changed file and have a coffee. Isn't git wonderful! > When things start looking fishy, don't just stumble on blindly. Save > what you got somewhere else, and _then_ try muddling through. That's > not particular to Git. Not totally, no. > -- > David Kastrup -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 10:15 Stupid git! Alan Mackenzie ` (2 preceding siblings ...) 2015-09-12 10:40 ` David Kastrup @ 2015-09-12 11:45 ` Giuseppe Scrivano 2015-09-12 13:02 ` Alan Mackenzie 3 siblings, 1 reply; 41+ messages in thread From: Giuseppe Scrivano @ 2015-09-12 11:45 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel Alan Mackenzie <acm@muc.de> writes: > Hello, Emacs. > > git has struck again, and another couple of hours valuable time have > been lost. > > Having "staged" a change with `git add', I then tried to commit it with > `git commit'. Somebody else had got in before me, so I had to pull > their changes first - fair enough. > > So I did `git pull'. I was then dumped into an editing session for a > merge operation for .../test/automated/file-notify-tests.el. Eh? I've > never touched this file in my life, and didn't even know it existed. So > why is a merge necessary/why has a merge been (half-)done? Why didn't > git pull simply merge the changes to this file into my repository and > working directory? are you working and pulling on the same branch? Have you used --rebase to pull to apply your commits after you pulled all the changes from the remote repository? Regards, Giuseppe ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 11:45 ` Giuseppe Scrivano @ 2015-09-12 13:02 ` Alan Mackenzie 2015-09-12 14:12 ` Andreas Schwab 2015-09-12 15:16 ` Eli Zaretskii 0 siblings, 2 replies; 41+ messages in thread From: Alan Mackenzie @ 2015-09-12 13:02 UTC (permalink / raw) To: Giuseppe Scrivano; +Cc: emacs-devel Hello, Giuseppe. On Sat, Sep 12, 2015 at 01:45:38PM +0200, Giuseppe Scrivano wrote: > Alan Mackenzie <acm@muc.de> writes: > > Hello, Emacs. > > > > git has struck again, and another couple of hours valuable time have > > been lost. > > > > Having "staged" a change with `git add', I then tried to commit it with > > `git commit'. Somebody else had got in before me, so I had to pull > > their changes first - fair enough. > > > > So I did `git pull'. I was then dumped into an editing session for a > > merge operation for .../test/automated/file-notify-tests.el. Eh? I've > > never touched this file in my life, and didn't even know it existed. So > > why is a merge necessary/why has a merge been (half-)done? Why didn't > > git pull simply merge the changes to this file into my repository and > > working directory? > are you working and pulling on the same branch? Yes. > Have you used --rebase to pull to apply your commits after you pulled > all the changes from the remote repository? No, I didn't. I should have done. I don't think there are any disadvantages to doing so. > Regards, > Giuseppe -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 13:02 ` Alan Mackenzie @ 2015-09-12 14:12 ` Andreas Schwab 2015-09-12 15:16 ` Eli Zaretskii 1 sibling, 0 replies; 41+ messages in thread From: Andreas Schwab @ 2015-09-12 14:12 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Giuseppe Scrivano, emacs-devel Alan Mackenzie <acm@muc.de> writes: > Hello, Giuseppe. > > On Sat, Sep 12, 2015 at 01:45:38PM +0200, Giuseppe Scrivano wrote: >> Have you used --rebase to pull to apply your commits after you pulled >> all the changes from the remote repository? > > No, I didn't. I should have done. I don't think there are any > disadvantages to doing so. `git config pull.rebase true' to make that the default. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 13:02 ` Alan Mackenzie 2015-09-12 14:12 ` Andreas Schwab @ 2015-09-12 15:16 ` Eli Zaretskii 2015-09-12 20:36 ` Alan Mackenzie 1 sibling, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2015-09-12 15:16 UTC (permalink / raw) To: Alan Mackenzie; +Cc: gscrivano, emacs-devel > Date: Sat, 12 Sep 2015 13:02:55 +0000 > From: Alan Mackenzie <acm@muc.de> > Cc: emacs-devel@gnu.org > > > Have you used --rebase to pull to apply your commits after you pulled > > all the changes from the remote repository? > > No, I didn't. I should have done. I don't think there are any > disadvantages to doing so. We already considered that around the time we switched to Git, and decided against it. The disadvantages you don't see come up when you are merging from a feature branch, and you have also merged from master to that branch. So instead of rebasing we recommend just "git pull", which will merge the upstream changes with yours. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 15:16 ` Eli Zaretskii @ 2015-09-12 20:36 ` Alan Mackenzie 2015-09-12 20:43 ` Dmitry Gutov 2015-09-13 6:42 ` Eli Zaretskii 0 siblings, 2 replies; 41+ messages in thread From: Alan Mackenzie @ 2015-09-12 20:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gscrivano, emacs-devel Hello, Eli. On Sat, Sep 12, 2015 at 06:16:51PM +0300, Eli Zaretskii wrote: > > Date: Sat, 12 Sep 2015 13:02:55 +0000 > > From: Alan Mackenzie <acm@muc.de> > > Cc: emacs-devel@gnu.org > > > Have you used --rebase to pull to apply your commits after you pulled > > > all the changes from the remote repository? > > No, I didn't. I should have done. I don't think there are any > > disadvantages to doing so. > We already considered that around the time we switched to Git, and > decided against it. The disadvantages you don't see come up when you > are merging from a feature branch, and you have also merged from > master to that branch. > So instead of rebasing we recommend just "git pull", which will merge > the upstream changes with yours. I just did `git pull'. This didn't merge the upstream changes into my repository. Instead it put the upstream file change into my working directory, discarding the other contributer's change log. If I understand correctly, that is. I think the best thing for me to do now is `git checkout <file>' to revert that changed file, then `git pull --rebase' to get the change again (and likely, quite a few others which have been done since), then `git push' to get my change into savannah. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 20:36 ` Alan Mackenzie @ 2015-09-12 20:43 ` Dmitry Gutov 2015-09-12 21:51 ` Alan Mackenzie 2015-09-13 6:42 ` Eli Zaretskii 1 sibling, 1 reply; 41+ messages in thread From: Dmitry Gutov @ 2015-09-12 20:43 UTC (permalink / raw) To: Alan Mackenzie, Eli Zaretskii; +Cc: gscrivano, emacs-devel On 09/12/2015 11:36 PM, Alan Mackenzie wrote: > I just did `git pull'. This didn't merge the upstream changes into > my repository. Instead it put the upstream file change into my working > directory, discarding the other contributer's change log. If I > understand correctly, that is. What does 'git status' say? > I think the best thing for me to do now is `git checkout <file>' to > revert that changed file, If you're in the middle of a merge, it's a recipe for disaster. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 20:43 ` Dmitry Gutov @ 2015-09-12 21:51 ` Alan Mackenzie 2015-09-13 6:22 ` Sven Axelsson ` (3 more replies) 0 siblings, 4 replies; 41+ messages in thread From: Alan Mackenzie @ 2015-09-12 21:51 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Eli Zaretskii, gscrivano, emacs-devel Hello, Dmitry. On Sat, Sep 12, 2015 at 11:43:43PM +0300, Dmitry Gutov wrote: > On 09/12/2015 11:36 PM, Alan Mackenzie wrote: > > I just did `git pull'. This didn't merge the upstream changes into > > my repository. Instead it put the upstream file change into my working > > directory, discarding the other contributer's change log. If I > > understand correctly, that is. > What does 'git status' say? On branch master Your branch and 'origin/master' have diverged, and have 1 and 1 different commit each, respectively. (use "git pull" to merge the remote branch into yours) All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: test/automated/file-notify-tests.el Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: .gitignore modified: lisp/textmodes/paragraphs.el modified: src/search.c > > I think the best thing for me to do now is `git checkout <file>' to > > revert that changed file, > If you're in the middle of a merge, it's a recipe for disaster. :-). OK, but the immediate problem is that _I_ didn't modify file-notify-tests.el. Somebody else did, and git put his changes into my working directory and `git add'ed it. I don't have the log entry for this change. So am I supposed to just commit this, with my own log entry? I don't really understand what "you are still merging" is supposed to mean. How do I get out of the "merging" state cleanly, without commiting somebody else's changes? -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 21:51 ` Alan Mackenzie @ 2015-09-13 6:22 ` Sven Axelsson 2015-09-14 10:21 ` Alan Mackenzie 2015-09-13 6:49 ` Eli Zaretskii ` (2 subsequent siblings) 3 siblings, 1 reply; 41+ messages in thread From: Sven Axelsson @ 2015-09-13 6:22 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Eli Zaretskii, emacs, gscrivano, Dmitry Gutov On 12 September 2015 at 23:51, Alan Mackenzie <acm@muc.de> wrote: > Hello, Dmitry. > > On Sat, Sep 12, 2015 at 11:43:43PM +0300, Dmitry Gutov wrote: >> On 09/12/2015 11:36 PM, Alan Mackenzie wrote: > >> > I just did `git pull'. This didn't merge the upstream changes into >> > my repository. Instead it put the upstream file change into my working >> > directory, discarding the other contributer's change log. If I >> > understand correctly, that is. > >> What does 'git status' say? > > On branch master > Your branch and 'origin/master' have diverged, > and have 1 and 1 different commit each, respectively. > (use "git pull" to merge the remote branch into yours) > All conflicts fixed but you are still merging. > (use "git commit" to conclude merge) > > Changes to be committed: > > modified: test/automated/file-notify-tests.el > > Changes not staged for commit: > (use "git add <file>..." to update what will be committed) > (use "git checkout -- <file>..." to discard changes in working > directory) > > modified: .gitignore > modified: lisp/textmodes/paragraphs.el > modified: src/search.c > >> > I think the best thing for me to do now is `git checkout <file>' to >> > revert that changed file, > >> If you're in the middle of a merge, it's a recipe for disaster. > > :-). OK, but the immediate problem is that _I_ didn't modify > file-notify-tests.el. Somebody else did, and git put his changes into > my working directory and `git add'ed it. I don't have the log entry for > this change. So am I supposed to just commit this, with my own log > entry? > > I don't really understand what "you are still merging" is supposed to > mean. How do I get out of the "merging" state cleanly, without > commiting somebody else's changes? > > -- > Alan Mackenzie (Nuremberg, Germany). > `git status` tells you if you are in a merge operation, as you can see from the message above. To back out and undo all changes introduced by the merge, you can use `git merge --abort`. -- Sven Axelsson ++++++++++[>++++++++++>+++++++++++>++++++++++>++++++ >++++<<<<<-]>++++.+.++++.>+++++.>+.<<-.>>+.>++++.<<. +++.>-.<<++.>>----.<++.>>>++++++.<<<<.>>++++.<----. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-13 6:22 ` Sven Axelsson @ 2015-09-14 10:21 ` Alan Mackenzie 2015-09-14 10:29 ` David Kastrup 0 siblings, 1 reply; 41+ messages in thread From: Alan Mackenzie @ 2015-09-14 10:21 UTC (permalink / raw) To: Sven Axelsson; +Cc: emacs Hello, Sven. On Sun, Sep 13, 2015 at 08:22:26AM +0200, Sven Axelsson wrote: > `git status` tells you if you are in a merge operation, as you can > see from the message above. To back out and undo all changes > introduced by the merge, you can use `git merge --abort`. Thanks! I'll note that down in case I even need it in the future. > -- > Sven Axelsson > ++++++++++[>++++++++++>+++++++++++>++++++++++>++++++ > >++++<<<<<-]>++++.+.++++.>+++++.>+.<<-.>>+.>++++.<<. > +++.>-.<<++.>>----.<++.>>>++++++.<<<<.>>++++.<----. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 10:21 ` Alan Mackenzie @ 2015-09-14 10:29 ` David Kastrup 2015-09-14 12:19 ` Eli Zaretskii 2015-09-14 12:38 ` Stefan Monnier 0 siblings, 2 replies; 41+ messages in thread From: David Kastrup @ 2015-09-14 10:29 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Sven Axelsson, emacs Alan Mackenzie <acm@muc.de> writes: > Hello, Sven. > > On Sun, Sep 13, 2015 at 08:22:26AM +0200, Sven Axelsson wrote: > >> `git status` tells you if you are in a merge operation, as you can >> see from the message above. To back out and undo all changes >> introduced by the merge, you can use `git merge --abort`. > > Thanks! I'll note that down in case I even need it in the future. I think that if you have unstaged changes (possibly in files not touched by the merge) and start a merge (like with git pull or something), then do git merge --abort this may well get the changes killed for good: git merge --abort basically has only the index and repository to return to. I actually don't use git pull much myself: I rather use git fetch and then decide whether I want to merge or rebase or do whatever. And then I can choose just how I want to keep work from getting lost, by stashing it, or putting it in a branch or whatever else. Pulling is not a really good thing to do if you have uncommitted work. -- David Kastrup ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 10:29 ` David Kastrup @ 2015-09-14 12:19 ` Eli Zaretskii 2015-09-14 12:28 ` David Kastrup 2015-09-14 12:38 ` Stefan Monnier 1 sibling, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2015-09-14 12:19 UTC (permalink / raw) To: David Kastrup; +Cc: acm, sven.axelsson, emacs-devel > From: David Kastrup <dak@gnu.org> > Date: Mon, 14 Sep 2015 12:29:37 +0200 > Cc: Sven Axelsson <sven.axelsson@gmail.com>, emacs <emacs-devel@gnu.org> > > Pulling is not a really good thing to do if you have uncommitted work. I'm doing it all the time, and have yet to report a single problem. It's the simplest way of minimizing the probability of spurious merges, when someone else pushes before you. If you commit then pull, and someone else pushed in between, you will get that "merged branch master" thing. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 12:19 ` Eli Zaretskii @ 2015-09-14 12:28 ` David Kastrup 2015-09-14 12:37 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: David Kastrup @ 2015-09-14 12:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: acm, sven.axelsson, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: David Kastrup <dak@gnu.org> >> Date: Mon, 14 Sep 2015 12:29:37 +0200 >> Cc: Sven Axelsson <sven.axelsson@gmail.com>, emacs <emacs-devel@gnu.org> >> >> Pulling is not a really good thing to do if you have uncommitted work. > > I'm doing it all the time, and have yet to report a single problem. > > It's the simplest way of minimizing the probability of spurious > merges, when someone else pushes before you. Nope. The simplest way is to git fetch rather than git pull. Then nothing at all happens to your work directory and index and you are completely free to choose your course of action. > If you commit then pull, and someone else pushed in between, you will > get that "merged branch master" thing. It that's not what you want, git pull -r will rebase just fine. -- David Kastrup ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 12:28 ` David Kastrup @ 2015-09-14 12:37 ` Eli Zaretskii 2015-09-14 12:47 ` David Kastrup 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2015-09-14 12:37 UTC (permalink / raw) To: David Kastrup; +Cc: acm, sven.axelsson, emacs-devel > From: David Kastrup <dak@gnu.org> > Cc: acm@muc.de, sven.axelsson@gmail.com, emacs-devel@gnu.org > Date: Mon, 14 Sep 2015 14:28:06 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> From: David Kastrup <dak@gnu.org> > >> Date: Mon, 14 Sep 2015 12:29:37 +0200 > >> Cc: Sven Axelsson <sven.axelsson@gmail.com>, emacs <emacs-devel@gnu.org> > >> > >> Pulling is not a really good thing to do if you have uncommitted work. > > > > I'm doing it all the time, and have yet to report a single problem. > > > > It's the simplest way of minimizing the probability of spurious > > merges, when someone else pushes before you. > > Nope. The simplest way is to git fetch rather than git pull. How is using 2 commands instead of one, and learning an additional command, simpler? > > If you commit then pull, and someone else pushed in between, you will > > get that "merged branch master" thing. > > It that's not what you want, git pull -r will rebase just fine. We've concluded long ago that "pull --rebase" is trouble when you merge from and to feature branches, so I'm trying to stay away of that path. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 12:37 ` Eli Zaretskii @ 2015-09-14 12:47 ` David Kastrup 2015-09-14 13:38 ` Eli Zaretskii 0 siblings, 1 reply; 41+ messages in thread From: David Kastrup @ 2015-09-14 12:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: acm, sven.axelsson, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: David Kastrup <dak@gnu.org> >> Cc: acm@muc.de, sven.axelsson@gmail.com, emacs-devel@gnu.org >> Date: Mon, 14 Sep 2015 14:28:06 +0200 >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> >> From: David Kastrup <dak@gnu.org> >> >> Date: Mon, 14 Sep 2015 12:29:37 +0200 >> >> Cc: Sven Axelsson <sven.axelsson@gmail.com>, emacs <emacs-devel@gnu.org> >> >> >> >> Pulling is not a really good thing to do if you have uncommitted work. >> > >> > I'm doing it all the time, and have yet to report a single problem. >> > >> > It's the simplest way of minimizing the probability of spurious >> > merges, when someone else pushes before you. >> >> Nope. The simplest way is to git fetch rather than git pull. > > How is using 2 commands instead of one, and learning an additional > command, simpler? The "simplest way of minimizing the probability of spurious merges" is not to execute commands doing possibly unintended merges. If you insist on only ever using git pull, it also has an option --ff-only which will refuse to do anything non-trivial. >> > If you commit then pull, and someone else pushed in between, you >> > will get that "merged branch master" thing. >> >> It that's not what you want, git pull -r will rebase just fine. > > We've concluded long ago that "pull --rebase" is trouble when you > merge from and to feature branches, so I'm trying to stay away of that > path. That's ridiculous. What we have concluded is that setting --rebase as a default was not likely a good idea because of feature branches. But it is quite absurd not to use the option for those cases where you indeed want a rebase instead of a merge commit. There is a reason it is available as a command line option and not just as a configuration variable. -- David Kastrup ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 12:47 ` David Kastrup @ 2015-09-14 13:38 ` Eli Zaretskii 2015-09-14 13:44 ` David Kastrup 0 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2015-09-14 13:38 UTC (permalink / raw) To: David Kastrup; +Cc: acm, sven.axelsson, emacs-devel > From: David Kastrup <dak@gnu.org> > Cc: acm@muc.de, sven.axelsson@gmail.com, emacs-devel@gnu.org > Date: Mon, 14 Sep 2015 14:47:15 +0200 > > >> >> Pulling is not a really good thing to do if you have uncommitted work. > >> > > >> > I'm doing it all the time, and have yet to report a single problem. > >> > > >> > It's the simplest way of minimizing the probability of spurious > >> > merges, when someone else pushes before you. > >> > >> Nope. The simplest way is to git fetch rather than git pull. > > > > How is using 2 commands instead of one, and learning an additional > > command, simpler? > > The "simplest way of minimizing the probability of spurious merges" is > not to execute commands doing possibly unintended merges. If your recipe would have been "don't use pull", it would have been simpler. But that's not what it says, it says "use fetch and merge instead", which is definitely not simpler. > If you insist on only ever using git pull, it also has an option > --ff-only which will refuse to do anything non-trivial. At the cost of having to learn the option. Not simpler. > >> > If you commit then pull, and someone else pushed in between, you > >> > will get that "merged branch master" thing. > >> > >> It that's not what you want, git pull -r will rebase just fine. > > > > We've concluded long ago that "pull --rebase" is trouble when you > > merge from and to feature branches, so I'm trying to stay away of that > > path. > > That's ridiculous. What we have concluded is that setting --rebase as a > default was not likely a good idea because of feature branches. But it > is quite absurd not to use the option for those cases where you indeed > want a rebase instead of a merge commit. It's not absurd when you take muscle memory into consideration. We are talking here about routine operations (since you don't know in advance whether a pull will cause conflicts or a need to merge), not about an option to be used in specific rare circumstances. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 13:38 ` Eli Zaretskii @ 2015-09-14 13:44 ` David Kastrup 0 siblings, 0 replies; 41+ messages in thread From: David Kastrup @ 2015-09-14 13:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: acm, sven.axelsson, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: David Kastrup <dak@gnu.org> >> Cc: acm@muc.de, sven.axelsson@gmail.com, emacs-devel@gnu.org >> Date: Mon, 14 Sep 2015 14:47:15 +0200 >> >> >> >> Pulling is not a really good thing to do if you have uncommitted work. >> >> > >> >> > I'm doing it all the time, and have yet to report a single problem. >> >> > >> >> > It's the simplest way of minimizing the probability of spurious >> >> > merges, when someone else pushes before you. >> >> >> >> Nope. The simplest way is to git fetch rather than git pull. >> > >> > How is using 2 commands instead of one, and learning an additional >> > command, simpler? >> >> The "simplest way of minimizing the probability of spurious merges" is >> not to execute commands doing possibly unintended merges. > > If your recipe would have been "don't use pull", it would have been > simpler. But that's not what it says, it says "use fetch and merge > instead", which is definitely not simpler. > >> If you insist on only ever using git pull, it also has an option >> --ff-only which will refuse to do anything non-trivial. > > At the cost of having to learn the option. Not simpler. > >> >> > If you commit then pull, and someone else pushed in between, you >> >> > will get that "merged branch master" thing. >> >> >> >> It that's not what you want, git pull -r will rebase just fine. >> > >> > We've concluded long ago that "pull --rebase" is trouble when you >> > merge from and to feature branches, so I'm trying to stay away of that >> > path. >> >> That's ridiculous. What we have concluded is that setting --rebase as a >> default was not likely a good idea because of feature branches. But it >> is quite absurd not to use the option for those cases where you indeed >> want a rebase instead of a merge commit. > > It's not absurd when you take muscle memory into consideration. We > are talking here about routine operations (since you don't know in > advance whether a pull will cause conflicts or a need to merge), not > about an option to be used in specific rare circumstances. The simplest option taking muscle memory into account is throwing the computer against the wall. If you are not interested in actually achieving the objective ("minimizing the probability of spurious merges"), that seems by far the simplest action. I just don't see the point in discussing the simplest action you can take without actually achieving the objective at the same point of time. -- David Kastrup ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 10:29 ` David Kastrup 2015-09-14 12:19 ` Eli Zaretskii @ 2015-09-14 12:38 ` Stefan Monnier 1 sibling, 0 replies; 41+ messages in thread From: Stefan Monnier @ 2015-09-14 12:38 UTC (permalink / raw) To: David Kastrup; +Cc: Alan Mackenzie, Sven Axelsson, emacs > I think that if you have unstaged changes (possibly in files not touched > by the merge) and start a merge (like with git pull or something), then > do git merge --abort this may well get the changes killed for good: git > merge --abort basically has only the index and repository to return to. I don't think this problem exists: the merge code never tries to merge changes into local uncommitted changes (staged or not). The merge doesn't even start if a file has both uncommitted changes and incoming changes. Stefan PS: At least that's my experience, based on looking for ways to do exactly that, since I like to live dangerously and would be really happy if git let me do this. Instead I wrote a "git-merge-force" script which does stash+merge+unstash, with the major downside that the stash+unstash ends up "touch"ing all the locally modified files. So if I have many of them and the merge only touches a could files, that's a lot of wasted work in the subsequent "make". ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 21:51 ` Alan Mackenzie 2015-09-13 6:22 ` Sven Axelsson @ 2015-09-13 6:49 ` Eli Zaretskii 2015-09-14 10:49 ` Alan Mackenzie 2015-09-13 20:28 ` Dmitry Gutov 2015-09-14 10:37 ` Steinar Bang 3 siblings, 1 reply; 41+ messages in thread From: Eli Zaretskii @ 2015-09-13 6:49 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel, gscrivano, dgutov > Date: Sat, 12 Sep 2015 21:51:14 +0000 > Cc: Eli Zaretskii <eliz@gnu.org>, gscrivano@gnu.org, emacs-devel@gnu.org > From: Alan Mackenzie <acm@muc.de> > > > What does 'git status' say? > > On branch master > Your branch and 'origin/master' have diverged, > and have 1 and 1 different commit each, respectively. > (use "git pull" to merge the remote branch into yours) > All conflicts fixed but you are still merging. > (use "git commit" to conclude merge) > > Changes to be committed: > > modified: test/automated/file-notify-tests.el > > Changes not staged for commit: > (use "git add <file>..." to update what will be committed) > (use "git checkout -- <file>..." to discard changes in working > directory) > > modified: .gitignore > modified: lisp/textmodes/paragraphs.el > modified: src/search.c > > > > > I think the best thing for me to do now is `git checkout <file>' to > > > revert that changed file, > > > If you're in the middle of a merge, it's a recipe for disaster. > > :-). OK, but the immediate problem is that _I_ didn't modify > file-notify-tests.el. Somebody else did, and git put his changes into > my working directory and `git add'ed it. That's what happens when there are merge conflicts: Git suspends the merge in its middle. > I don't have the log entry for this change. So am I supposed to > just commit this, with my own log entry? Commit everything in one go, with "git commit", and give it a single log entry, something like "resolve merge conflicts". > I don't really understand what "you are still merging" is supposed to > mean. How do I get out of the "merging" state cleanly, without > commiting somebody else's changes? You _must_ commit. A successful merge in Git always ends in a commit, and in this case you need to do it manually, because the automatic merge failed due to diverging. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-13 6:49 ` Eli Zaretskii @ 2015-09-14 10:49 ` Alan Mackenzie 2015-09-15 0:24 ` Stephen J. Turnbull 0 siblings, 1 reply; 41+ messages in thread From: Alan Mackenzie @ 2015-09-14 10:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, gscrivano, dgutov Hello, Eli. On Sun, Sep 13, 2015 at 09:49:43AM +0300, Eli Zaretskii wrote: > > Date: Sat, 12 Sep 2015 21:51:14 +0000 > > Cc: Eli Zaretskii <eliz@gnu.org>, gscrivano@gnu.org, emacs-devel@gnu.org > > From: Alan Mackenzie <acm@muc.de> [ .... ] > > > If you're in the middle of a merge, it's a recipe for disaster. > > :-). OK, but the immediate problem is that _I_ didn't modify > > file-notify-tests.el. Somebody else did, and git put his changes into > > my working directory and `git add'ed it. > That's what happens when there are merge conflicts: Git suspends the > merge in its middle. Yes. I had misunderstood "conflict". I had thought it meant a merge conflict in some file, whereas it just meant that other, possibly unrelated, changes had taken place. > > I don't have the log entry for this change. So am I supposed to > > just commit this, with my own log entry? Acutally, I did have this log entry, but `git log' didn't display it. It needed `git log --all' to see it. > Commit everything in one go, with "git commit", and give it a single > log entry, something like "resolve merge conflicts". Thanks, I've done this. > > I don't really understand what "you are still merging" is supposed to > > mean. How do I get out of the "merging" state cleanly, without > > commiting somebody else's changes? > You _must_ commit. A successful merge in Git always ends in a commit, > and in this case you need to do it manually, because the automatic > merge failed due to diverging. OK. I suppose there's a good reason for git aborting the merge rather than completing it in the obvious manner, but I can't see it at the moment. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 10:49 ` Alan Mackenzie @ 2015-09-15 0:24 ` Stephen J. Turnbull 0 siblings, 0 replies; 41+ messages in thread From: Stephen J. Turnbull @ 2015-09-15 0:24 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel Alan Mackenzie writes: > Yes. I had misunderstood "conflict". I had thought it meant a merge > conflict in some file, whereas it just meant that other, possibly > unrelated, changes had taken place. No, "conflict" means that there are conflicts in a file so that the expected outcome of the merge is indeterminate, just like every other VCS. There could be a bug in git's implementation, but this terminology is standard in git as in other VCSes. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 21:51 ` Alan Mackenzie 2015-09-13 6:22 ` Sven Axelsson 2015-09-13 6:49 ` Eli Zaretskii @ 2015-09-13 20:28 ` Dmitry Gutov 2015-09-14 3:11 ` Stephen J. Turnbull 2015-09-14 11:09 ` Alan Mackenzie 2015-09-14 10:37 ` Steinar Bang 3 siblings, 2 replies; 41+ messages in thread From: Dmitry Gutov @ 2015-09-13 20:28 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Eli Zaretskii, gscrivano, emacs-devel On 09/13/2015 12:51 AM, Alan Mackenzie wrote: > On branch master > Your branch and 'origin/master' have diverged, > and have 1 and 1 different commit each, respectively. > (use "git pull" to merge the remote branch into yours) > All conflicts fixed but you are still merging. > (use "git commit" to conclude merge) I think what Git says here is pretty transparent: commit to conclude the merge. > :-). OK, but the immediate problem is that _I_ didn't modify > file-notify-tests.el. Somebody else did, and git put his changes into > my working directory and `git add'ed it. Yes, it did. Have you done any non-trivial merges before? That's how they usually look. The merge commit shouldn't, generally, include any non-mergy changes, so you're not expected to stage any of the files you've been working on, before committing. > I don't have the log entry for > this change. So am I supposed to just commit this, with my own log > entry? The log entry should describe the merge (you could leave the default message there, unless it's necessary to add more info). > I don't really understand what "you are still merging" is supposed to > mean. How do I get out of the "merging" state cleanly, without > commiting somebody else's changes? The merge commit is *supposed to* include all the changes that have been merged in. If you take it upon yourself to remove those changes from the staging area, as a result Emacs won't include them, and it won't be obvious to most of the people who read emacs-diffs, and then someone will have to find out the hard way that something's missing. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-13 20:28 ` Dmitry Gutov @ 2015-09-14 3:11 ` Stephen J. Turnbull 2015-09-14 13:47 ` Dmitry Gutov 2015-09-14 11:09 ` Alan Mackenzie 1 sibling, 1 reply; 41+ messages in thread From: Stephen J. Turnbull @ 2015-09-14 3:11 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Alan Mackenzie, emacs-devel Dmitry Gutov writes: > On 09/13/2015 12:51 AM, Alan Mackenzie wrote: > > :-). OK, but the immediate problem is that _I_ didn't modify > > file-notify-tests.el. Somebody else did, and git put his changes into > > my working directory and `git add'ed it. > > Yes, it did. Have you done any non-trivial merges before? That's how > they usually look. @Dmitry: Weren't you here for the last "git is a screw" thread? Yes, he's seen this before. He doesn't understand it yet. @Alan: In "DAGgy" systems that emphasize branching[1], the first step in a "pull" to include external changes is to fetch them. The changes are stored in the local database and constitute a complete tree including all your commits as well as those fetched from the other repo, but the workspace doesn't change during the fetch. Next the system conducts the merge. Conceptually, the VCS traces each branch back to a common ancestor, and checks that version out into the workspace. Then it applies your commits[2] and those of the external branch to each file. For each file with changes, if there are no lines in common between your changes and the outside changes, the file is marked "done". If a conflict exists, the file is marked "pending". Note that since no commit has take place but both branch's changes have been applied, the other branch's changes will be present in your workspace, as files needing commit (or conflicts). This is normal, and occurs in all DAGgy VCSes, including bzr. What may differ is how the situation is reported. > The merge commit shouldn't, generally, include any non-mergy changes, so > you're not expected to stage any of the files you've been working on, > before committing. @Dmitry: I have no idea what you mean by this, especially not in the context of helping someone who probably thinks[3] of a merge as equivalent to git fetch origin git diff last-synced-rev > /tmp/patch git reset --hard origin/master patch -p1 < /tmp/patch (that's my guess because that's like what CVS does, except that CVS's patch is actually "git diff last-synced-rev origin/master" applied to the current workspace). @Alan: Back to the merge process. After the process above, git does the equivalent of if test -z "$CONFLICTED_FILES"; then git commit -m "Merge from origin/master." fi Other systems (hg, bzr) require an explicit commit here, because "review after commit and uncommit if bad" is philosophically distasteful, so they recommend a careful review before committing a merge. git's philosophy is that if on review, you don't like the commit, you can just reset to a commit you do like, with or without reverting the the workspace. (Of course you shouldn't do this after pushing the merge commit!) > > I don't have the log entry for this change. So am I supposed to > > just commit this, with my own log entry? > > The log entry should describe the merge (you could leave the default > message there, unless it's necessary to add more info). There should be a file in .git/ named "MERGE_MSG" or something like that with a preformatted message you can use with the -F option. Lines beginning with "#" are comments, and stripped from the message actually used. In most cases, something like "merge from origin/master" is sufficient. If you found that you had to do "real work" to resolve a conflict, that should be described here too. Most of the time conflicts are trivial, though (eg, somebody fixed a typo in a comment you changed to reflect reality), and that kind of change doesn't need to be mentioned, or can be disposed of en masse with "fixed trivial conflicts." > > I don't really understand what "you are still merging" is > > supposed to mean. It means that the workspace has not yet been committed to the repository, and that you need to resolve any remaining conflicts before git will allow you to commit. > > How do I get out of the "merging" state cleanly, without > > commiting somebody else's changes? > > The merge commit is *supposed to* include all the changes that have > been merged in. @Dmitry: This probably doesn't help Alan because his mental model of merging differs from what git is reporting. Alan seems to be thinking of the post-merge commit as recording a diff of his workspace against current upstream master. The changes on master should *already be there* (in some sense), and it doesn't make sense to Alan that changes that are already in master are reported as changes in *his* workspace. @Alan: But git doesn't think of master as "canonical" or whatever. git puts your changes on an equal footing with the changes in master, and so reports *all* changes on *both* branches since last-synced-rev. Those files that were successfully merged from either branch will already be in the "to be committed" list. You primarily care about the "conflicted" files. You should also check "your" files to make sure they all make sense -- in particular, other people may have made changes to "your" files that conflict with what you're doing semantically, but not syntactically. If one of "your" files is listed but you didn't change it, that should be a red flag. (Of course I'm sure you also review the diff, and should see it there. Call YAGNI if you like on this "feature".) But you can ignore all the "other" files, unless they're conflicted -- in that case something is odd in *your* pre-merge workspace, because git thinks you changed that file but you don't remember doing so. (To be precise, git doesn't commit diffs, it commits snapshots of workspaces. To git, your workspace after merge is just a snapshot that hasn't yet been recorded in the DAG. From git's point of view, there is no diff, only the revisions and the parent-child relationships among them. "diff" is a derived concept that humans find useful in thinking about traversing the DAG, not a fundamental part of the git machinery.[4] But you may not need to think about this; it may be sufficient to think of git as "unnecessarily" -- "stupidly", if you like -- reporting all changes since last-synced-rev.) Footnotes: [1] These systems include git and hg. bzr is also DAGgy, but it's schizoid about branching. It can be operated in a mode that tries to hide the fact that multiple branches are present in your local repo as much as possible, giving a UX like CVS and Subversion where branches exist only in the server. [2] Note that this process implies you will lose any changes that you haven't committed -- that's why it's best practice to be "committed up" before merging. [3] @Alan: Here and below I am *guessing* what you think in order to phrase things consistently with what you think is happening, or what I call your "model" of the merge process. I'm not telling you what to think, I'm trying to give you a reference point to understand what I'm saying. If I'm wrong, but close enough, good. If not, tell me where I'm wrong and maybe I can come up with a better way to express what's actually happening and how to interpret what you are seeing. [4] Of course git provides the "diff" subcommand, and uses "diff compression" when packing objects. But neither is necessary to the fundamental processes of commit and checkout. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 3:11 ` Stephen J. Turnbull @ 2015-09-14 13:47 ` Dmitry Gutov 0 siblings, 0 replies; 41+ messages in thread From: Dmitry Gutov @ 2015-09-14 13:47 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Alan Mackenzie, emacs-devel On 09/14/2015 06:11 AM, Stephen J. Turnbull wrote: > @Dmitry: Weren't you here for the last "git is a screw" thread? Yes, > he's seen this before. He doesn't understand it yet. It was Richard's thread, and it was quite a while ago. Plenty of time to learn and play around. > > The merge commit shouldn't, generally, include any non-mergy changes, so > > you're not expected to stage any of the files you've been working on, > > before committing. > > @Dmitry: I have no idea what you mean by this, especially not in the > context of helping someone who probably thinks[3] of a merge as > equivalent to I have a feeling that a person that did 'git add xyz' before 'git pull' might try to make xyz a part of the ensuing merge commit. They shouldn't do that. > There should be a file in .git/ named "MERGE_MSG" or something like > that with a preformatted message you can use with the -F option. 'git commit' will pre-fill it for you automatically. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-13 20:28 ` Dmitry Gutov 2015-09-14 3:11 ` Stephen J. Turnbull @ 2015-09-14 11:09 ` Alan Mackenzie 2015-09-14 12:22 ` Eli Zaretskii 2015-09-14 13:42 ` Dmitry Gutov 1 sibling, 2 replies; 41+ messages in thread From: Alan Mackenzie @ 2015-09-14 11:09 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Eli Zaretskii, gscrivano, emacs-devel Hello, Dmitry. On Sun, Sep 13, 2015 at 11:28:25PM +0300, Dmitry Gutov wrote: > On 09/13/2015 12:51 AM, Alan Mackenzie wrote: > > On branch master > > Your branch and 'origin/master' have diverged, > > and have 1 and 1 different commit each, respectively. > > (use "git pull" to merge the remote branch into yours) > > All conflicts fixed but you are still merging. > > (use "git commit" to conclude merge) > I think what Git says here is pretty transparent: commit to conclude the > merge. What confused me is that git aborted the merge despite there being no conflicts (i.e., nothing requiring the use of an editor to resolve). git could quite easily have just completed the merge itself instead of aborting it then requiring me to take mechanical actions to complete it. > > :-). OK, but the immediate problem is that _I_ didn't modify > > file-notify-tests.el. Somebody else did, and git put his changes into > > my working directory and `git add'ed it. > Yes, it did. Have you done any non-trivial merges before? That's how > they usually look. No, I've never done a non-trivial merge in git. This one presumably must count as a trivial merge. > The merge commit shouldn't, generally, include any non-mergy changes, so > you're not expected to stage any of the files you've been working on, > before committing. I take it that by "shouldn't .. include include .. non-mergy changes" you mean that when initiating a merge commit, git won't include any non-merge changes in the commit. (The alternative interpretation is that in a merge commit, the user shouldn't include any other changes.) > > I don't have the log entry for > > this change. So am I supposed to just commit this, with my own log > > entry? > The log entry should describe the merge (you could leave the default > message there, unless it's necessary to add more info). I did actually have this log entry, but `git log' didn't display it. The flag --all was needed for that. > > I don't really understand what "you are still merging" is supposed to > > mean. How do I get out of the "merging" state cleanly, without > > commiting somebody else's changes? > The merge commit is *supposed to* include all the changes that have been > merged in. If you take it upon yourself to remove those changes from the > staging area, as a result Emacs won't include them, and it won't be > obvious to most of the people who read emacs-diffs, and then someone > will have to find out the hard way that something's missing. OK, I've got it now. For some reason, git choses to abort the merge, despite there being no conflicts between the changes from upstream and the changes I've committed locally - indeed, to complete the merge is a fully mechanical action, `git commit'. This seeming illogicality is what confused me in the first place. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 11:09 ` Alan Mackenzie @ 2015-09-14 12:22 ` Eli Zaretskii 2015-09-14 13:42 ` Dmitry Gutov 1 sibling, 0 replies; 41+ messages in thread From: Eli Zaretskii @ 2015-09-14 12:22 UTC (permalink / raw) To: Alan Mackenzie; +Cc: emacs-devel, gscrivano, dgutov > Date: Mon, 14 Sep 2015 11:09:20 +0000 > Cc: Eli Zaretskii <eliz@gnu.org>, gscrivano@gnu.org, emacs-devel@gnu.org > From: Alan Mackenzie <acm@muc.de> > > > The merge commit is *supposed to* include all the changes that have been > > merged in. If you take it upon yourself to remove those changes from the > > staging area, as a result Emacs won't include them, and it won't be > > obvious to most of the people who read emacs-diffs, and then someone > > will have to find out the hard way that something's missing. > > OK, I've got it now. For some reason, git choses to abort the merge, > despite there being no conflicts between the changes from upstream and > the changes I've committed locally - indeed, to complete the merge is a > fully mechanical action, `git commit'. This seeming illogicality is > what confused me in the first place. I think this was because you did a "git add" before pulling. But I'm not sure. (I almost never use "git add", except when adding new files.) ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 11:09 ` Alan Mackenzie 2015-09-14 12:22 ` Eli Zaretskii @ 2015-09-14 13:42 ` Dmitry Gutov 2015-09-14 17:05 ` Steinar Bang 1 sibling, 1 reply; 41+ messages in thread From: Dmitry Gutov @ 2015-09-14 13:42 UTC (permalink / raw) To: Alan Mackenzie; +Cc: Eli Zaretskii, gscrivano, emacs-devel Hi Alan, On 09/14/2015 02:09 PM, Alan Mackenzie wrote: > What confused me is that git aborted the merge despite there being no > conflicts (i.e., nothing requiring the use of an editor to resolve). Indeed, I don't usually see that. Hence my question about --no-commit in your gitconfig. But others' suggestion that it might be because of 'git add' beforehand is also plausible. I never do that, because it makes little sense. >> Yes, it did. Have you done any non-trivial merges before? That's how >> they usually look. > > No, I've never done a non-trivial merge in git. This one presumably > must count as a trivial merge. I any case, a merge with maybe just one tiny conflict, looks similar to this if there are also non-conflicting changes in it: it shows you staged changes from files *you* didn't modify. > I take it that by "shouldn't .. include include .. non-mergy changes" > you mean that when initiating a merge commit, git won't include any > non-merge changes in the commit. (The alternative interpretation is > that in a merge commit, the user shouldn't include any other changes.) Kinda both. It means that you shouldn't 'git add' any changes that you've worked on just now, before committing. Leave them for a following, non-merge commit. > I did actually have this log entry, but `git log' didn't display it. > The flag --all was needed for that. Apparently, you will be able to see the log entries for the commits you're merging, after you conclude the merge, and so the current branch includes them. Makes sense, doesn't it? > OK, I've got it now. For some reason, git choses to abort the merge, > despite there being no conflicts between the changes from upstream and > the changes I've committed locally - indeed, to complete the merge is a > fully mechanical action, `git commit'. This seeming illogicality is > what confused me in the first place. I agree. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-14 13:42 ` Dmitry Gutov @ 2015-09-14 17:05 ` Steinar Bang 0 siblings, 0 replies; 41+ messages in thread From: Steinar Bang @ 2015-09-14 17:05 UTC (permalink / raw) To: emacs-devel >>>>> Dmitry Gutov <dgutov@yandex.ru>: > Hi Alan, > On 09/14/2015 02:09 PM, Alan Mackenzie wrote: >> What confused me is that git aborted the merge despite there being no >> conflicts (i.e., nothing requiring the use of an editor to resolve). > Indeed, I don't usually see that. Actually, I've never seen that. > Hence my question about --no-commit in your gitconfig. > But others' suggestion that it might be because of 'git add' > beforehand is also plausible. I never do that, because it makes little > sense. Hm... easy enough to try. cd ~/git mkdir add-test cd add-test git init echo "Hello" >hello.txt git add hello.txt git commit -m "Added hello file" mkdir ../add-test.git cd ../add-test.git git init --bare cd ../add-test git remote add origin ../add-test.git git push -u origin HEAD cd .. git clone ./add-test.git add-test2 cd add-test echo "Hello world!" >hello.txt git add hello.txt git commit -m "Add a new commit that can be pulled in the other clone" git push cd ../add-test2 git add hello.txt git pull Nah... the result of the final command: ~/git/add-test2$ git pull remote: Counting objects: 5, done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From c:/Users/sbang/git/./add-test 1887bde..446444d master -> origin/master Updating 1887bde..446444d Fast-forward hello.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Ie. no conflict. ~/git/add-test2$ git --version git version 1.9.4.msysgit.1 I tried a variant with "git add ." before pull, but I got the same result, ie. no conflict, no merge. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 21:51 ` Alan Mackenzie ` (2 preceding siblings ...) 2015-09-13 20:28 ` Dmitry Gutov @ 2015-09-14 10:37 ` Steinar Bang 3 siblings, 0 replies; 41+ messages in thread From: Steinar Bang @ 2015-09-14 10:37 UTC (permalink / raw) To: emacs-devel >>>>> Alan Mackenzie <acm@muc.de>: > :-). OK, but the immediate problem is that _I_ didn't modify > file-notify-tests.el. Somebody else did, and git put his changes into > my working directory and `git add'ed it. I don't have the log entry for > this change. Don't worry about it. That log message is in the history of origin/master, and "git log" will display it, and "git blame" will bind the correct modified lines to the git commit. The changes you see, are the changes that has been upstream since your last pull. Your "incoming changes", so to speak. > So am I supposed to just commit this, with my own log entry? Yes, since this is the commit of a merge, git will usually suggest a message for you. I usually go with that, and maybe add some comments on the merges I've resolved. > I don't really understand what "you are still merging" is supposed to > mean. It means that the merge operation in "git pull" needs a "git commit" to complete. > How do I get out of the "merging" state cleanly, "git commit" > without commiting somebody else's changes? You won't be committing somebody else's changes... or rather: you won't be commiting somebody else's changes in a way that will mess up the git history (which is something that _may_ happen when rebase is involved) ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Stupid git! 2015-09-12 20:36 ` Alan Mackenzie 2015-09-12 20:43 ` Dmitry Gutov @ 2015-09-13 6:42 ` Eli Zaretskii 1 sibling, 0 replies; 41+ messages in thread From: Eli Zaretskii @ 2015-09-13 6:42 UTC (permalink / raw) To: Alan Mackenzie; +Cc: gscrivano, emacs-devel > Date: Sat, 12 Sep 2015 20:36:58 +0000 > Cc: gscrivano@gnu.org, emacs-devel@gnu.org > From: Alan Mackenzie <acm@muc.de> > > > So instead of rebasing we recommend just "git pull", which will merge > > the upstream changes with yours. > > I just did `git pull'. This didn't merge the upstream changes into > my repository. Instead it put the upstream file change into my working > directory, discarding the other contributer's change log. If I > understand correctly, that is. You must be misunderstanding, then, because "git pull" never does that kind of atrocities. > I think the best thing for me to do now is `git checkout <file>' to > revert that changed file, then `git pull --rebase' to get the change > again (and likely, quite a few others which have been done since), then > `git push' to get my change into savannah. Not sure this is the best way. But if you want to start from a clean slate, then this is the sequence of commands: git checkout <file> git status If the last command says that only that your branch is ahead of origin/master, then continue: git pull If this causes merge conflicts, resolve them by editing and issuing "git add" for each file whose conflicts you resolved (Emacs should do this automatically when you save the file). Finally: git commit git pull git push The final "git pull" is for the slim chance that someone pushed to savannah while you were resolving the conflicts. If that pull produces conflicts (highly unlikely), repeat the whole process, and only then push. ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2015-09-15 0:24 UTC | newest] Thread overview: 41+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-09-12 10:15 Stupid git! Alan Mackenzie 2015-09-12 10:21 ` Alan Mackenzie 2015-09-12 10:40 ` Dmitry Gutov 2015-09-12 12:29 ` Alan Mackenzie 2015-09-12 12:34 ` David Kastrup 2015-09-12 12:59 ` Alan Mackenzie 2015-09-12 20:14 ` Dmitry Gutov 2015-09-14 10:09 ` Steinar Bang 2015-09-12 20:37 ` Stefan Monnier 2015-09-12 10:40 ` David Kastrup 2015-09-12 10:53 ` Dmitry Gutov 2015-09-12 12:52 ` Alan Mackenzie 2015-09-12 11:45 ` Giuseppe Scrivano 2015-09-12 13:02 ` Alan Mackenzie 2015-09-12 14:12 ` Andreas Schwab 2015-09-12 15:16 ` Eli Zaretskii 2015-09-12 20:36 ` Alan Mackenzie 2015-09-12 20:43 ` Dmitry Gutov 2015-09-12 21:51 ` Alan Mackenzie 2015-09-13 6:22 ` Sven Axelsson 2015-09-14 10:21 ` Alan Mackenzie 2015-09-14 10:29 ` David Kastrup 2015-09-14 12:19 ` Eli Zaretskii 2015-09-14 12:28 ` David Kastrup 2015-09-14 12:37 ` Eli Zaretskii 2015-09-14 12:47 ` David Kastrup 2015-09-14 13:38 ` Eli Zaretskii 2015-09-14 13:44 ` David Kastrup 2015-09-14 12:38 ` Stefan Monnier 2015-09-13 6:49 ` Eli Zaretskii 2015-09-14 10:49 ` Alan Mackenzie 2015-09-15 0:24 ` Stephen J. Turnbull 2015-09-13 20:28 ` Dmitry Gutov 2015-09-14 3:11 ` Stephen J. Turnbull 2015-09-14 13:47 ` Dmitry Gutov 2015-09-14 11:09 ` Alan Mackenzie 2015-09-14 12:22 ` Eli Zaretskii 2015-09-14 13:42 ` Dmitry Gutov 2015-09-14 17:05 ` Steinar Bang 2015-09-14 10:37 ` Steinar Bang 2015-09-13 6:42 ` Eli Zaretskii
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).