* Re: master c6f03ed: Fix a problem in url.el without GnuTLS [not found] ` <E1Xz67Y-00036o-Vf@vcs.savannah.gnu.org> @ 2014-12-11 16:47 ` Leo Liu 2014-12-11 18:08 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: Leo Liu @ 2014-12-11 16:47 UTC (permalink / raw) To: emacs-devel; +Cc: Lars Magne Ingebrigtsen On 2014-12-11 15:57 +0000, Lars Ingebrigtsen wrote: > + (when (and (fboundp 'gnutls-available-p) > + (gnutls-available-p)) Does this defeat the purpose of gnutls-available-p? BTW, why aren't all these -available-p functions replaced by features? Leo ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-11 16:47 ` master c6f03ed: Fix a problem in url.el without GnuTLS Leo Liu @ 2014-12-11 18:08 ` Eli Zaretskii 2014-12-11 23:00 ` Ted Zlatanov 2014-12-12 0:30 ` Leo Liu 0 siblings, 2 replies; 63+ messages in thread From: Eli Zaretskii @ 2014-12-11 18:08 UTC (permalink / raw) To: Leo Liu; +Cc: larsi, emacs-devel > From: Leo Liu <sdl.web@gmail.com> > Date: Fri, 12 Dec 2014 00:47:48 +0800 > Cc: Lars Magne Ingebrigtsen <larsi@gnus.org> > > why aren't all these -available-p functions replaced by features? Because the feature might be available, but inoperable (e.g., if some underlying library is missing). This happens all the times in the Windows build, where optional shared libraries are loaded dynamically only when needed, even though Emacs itself was compiled with support for that library. We will see more of that once we support some kind of dynamic modules. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-11 18:08 ` Eli Zaretskii @ 2014-12-11 23:00 ` Ted Zlatanov 2014-12-12 9:23 ` Eli Zaretskii 2014-12-12 0:30 ` Leo Liu 1 sibling, 1 reply; 63+ messages in thread From: Ted Zlatanov @ 2014-12-11 23:00 UTC (permalink / raw) To: emacs-devel On Thu, 11 Dec 2014 20:08:12 +0200 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Leo Liu <sdl.web@gmail.com> >> Date: Fri, 12 Dec 2014 00:47:48 +0800 >> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org> >> >> why aren't all these -available-p functions replaced by features? EZ> Because the feature might be available, but inoperable (e.g., if some EZ> underlying library is missing). This happens all the times in the EZ> Windows build, where optional shared libraries are loaded dynamically EZ> only when needed, even though Emacs itself was compiled with support EZ> for that library. We will see more of that once we support some kind EZ> of dynamic modules. I made a fix for this one in the emacs-24 branch, and the discussion of bug#19346 has the details. I don't know if it will DTRT for W32 as Eli describes, sorry. For the dynamic modules, it will definitely have to be a general facility. Ted ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-11 23:00 ` Ted Zlatanov @ 2014-12-12 9:23 ` Eli Zaretskii 2014-12-12 13:24 ` Ted Zlatanov 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2014-12-12 9:23 UTC (permalink / raw) To: emacs-devel > From: Ted Zlatanov <tzz@lifelogs.com> > Date: Thu, 11 Dec 2014 18:00:55 -0500 > > On Thu, 11 Dec 2014 20:08:12 +0200 Eli Zaretskii <eliz@gnu.org> wrote: > > >> From: Leo Liu <sdl.web@gmail.com> > >> Date: Fri, 12 Dec 2014 00:47:48 +0800 > >> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org> > >> > >> why aren't all these -available-p functions replaced by features? > > EZ> Because the feature might be available, but inoperable (e.g., if some > EZ> underlying library is missing). This happens all the times in the > EZ> Windows build, where optional shared libraries are loaded dynamically > EZ> only when needed, even though Emacs itself was compiled with support > EZ> for that library. We will see more of that once we support some kind > EZ> of dynamic modules. > > I made a fix for this one in the emacs-24 branch, and the discussion of > bug#19346 has the details. I don't know if it will DTRT for W32 as Eli > describes, sorry. Your change works for w32, but I've pushed a slightly better fix for that. In general, it is undesirable to have more than a single DEFUN or DEFVAR for the same symbol, so we try to have just one, unless it's impractical. If nothing else, it keeps all the code and the doc strings in one place. Thanks. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-12 9:23 ` Eli Zaretskii @ 2014-12-12 13:24 ` Ted Zlatanov 2014-12-12 14:28 ` Eli Zaretskii 2014-12-12 20:46 ` Lars Magne Ingebrigtsen 0 siblings, 2 replies; 63+ messages in thread From: Ted Zlatanov @ 2014-12-12 13:24 UTC (permalink / raw) To: emacs-devel On Fri, 12 Dec 2014 11:23:12 +0200 Eli Zaretskii <eliz@gnu.org> wrote: EZ> Your change works for w32, but I've pushed a slightly better fix for EZ> that. In general, it is undesirable to have more than a single DEFUN EZ> or DEFVAR for the same symbol, so we try to have just one, unless it's EZ> impractical. If nothing else, it keeps all the code and the doc EZ> strings in one place. Thanks. I'll keep that in mind. It should get merged into master soon. I can attempt another merge of the emacs-24 branch... with fear :) Ted ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-12 13:24 ` Ted Zlatanov @ 2014-12-12 14:28 ` Eli Zaretskii 2014-12-12 16:06 ` Stefan Monnier 2014-12-13 0:25 ` Ted Zlatanov 2014-12-12 20:46 ` Lars Magne Ingebrigtsen 1 sibling, 2 replies; 63+ messages in thread From: Eli Zaretskii @ 2014-12-12 14:28 UTC (permalink / raw) To: emacs-devel > From: Ted Zlatanov <tzz@lifelogs.com> > Date: Fri, 12 Dec 2014 08:24:58 -0500 > > I can attempt another merge of the emacs-24 branch... with fear :) No need to fear, just remember to review what "git show" displays, after the merge and before you push. If it doesn't look OK to you, you can always reset to cancel the merge. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-12 14:28 ` Eli Zaretskii @ 2014-12-12 16:06 ` Stefan Monnier 2014-12-13 0:25 ` Ted Zlatanov 1 sibling, 0 replies; 63+ messages in thread From: Stefan Monnier @ 2014-12-12 16:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel >> I can attempt another merge of the emacs-24 branch... with fear :) Don't forget to use gitmerge.el. Stefan ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-12 14:28 ` Eli Zaretskii 2014-12-12 16:06 ` Stefan Monnier @ 2014-12-13 0:25 ` Ted Zlatanov 2014-12-13 0:28 ` Lars Magne Ingebrigtsen ` (3 more replies) 1 sibling, 4 replies; 63+ messages in thread From: Ted Zlatanov @ 2014-12-13 0:25 UTC (permalink / raw) To: emacs-devel On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: EZ> No need to fear, just remember to review what "git show" displays, EZ> after the merge and before you push. If it doesn't look OK to you, EZ> you can always reset to cancel the merge. Yup. I did it, carefully. On Fri, 12 Dec 2014 11:06:03 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: >>> I can attempt another merge of the emacs-24 branch... with fear :) SM> Don't forget to use gitmerge.el. Right, thanks. It works well. On Fri, 12 Dec 2014 21:46:05 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Ted Zlatanov <tzz@lifelogs.com> writes: >> It should get merged into master soon. I can attempt another merge of >> the emacs-24 branch... with fear :) LMI> Oops. I didn't notice that this fix went into the emacs-24 branch, so I LMI> removed the `fboundp' checks from the trunk. Which means that trunk LMI> doesn't work for people without gnutls support. LMI> So if you could do the merge, that would be nice, otherwise I'll have to LMI> re-revert those `fboundp' changes again. It's merged. Sorry for the delay. Ted ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 0:25 ` Ted Zlatanov @ 2014-12-13 0:28 ` Lars Magne Ingebrigtsen 2014-12-13 1:25 ` Ted Zlatanov ` (2 subsequent siblings) 3 siblings, 0 replies; 63+ messages in thread From: Lars Magne Ingebrigtsen @ 2014-12-13 0:28 UTC (permalink / raw) To: emacs-devel Ted Zlatanov <tzz@lifelogs.com> writes: > It's merged. Sorry for the delay. Great; thanks. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 0:25 ` Ted Zlatanov 2014-12-13 0:28 ` Lars Magne Ingebrigtsen @ 2014-12-13 1:25 ` Ted Zlatanov 2014-12-13 8:04 ` Eli Zaretskii 2014-12-13 9:04 ` David Engster 3 siblings, 0 replies; 63+ messages in thread From: Ted Zlatanov @ 2014-12-13 1:25 UTC (permalink / raw) To: emacs-devel On Fri, 12 Dec 2014 19:25:38 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: TZ> On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: EZ> No need to fear, just remember to review what "git show" displays, EZ> after the merge and before you push. If it doesn't look OK to you, EZ> you can always reset to cancel the merge. TZ> Yup. I did it, carefully. Damn it: commit 805074d059b5bdb868a4f795a0aca58f49302f66 Author: Paul Eggert <eggert@cs.ucla.edu> Date: Fri Dec 12 16:48:06 2014 -0800 Remove duplicate ChangeLog entries Thanks, Paul. I missed that. Ted ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 0:25 ` Ted Zlatanov 2014-12-13 0:28 ` Lars Magne Ingebrigtsen 2014-12-13 1:25 ` Ted Zlatanov @ 2014-12-13 8:04 ` Eli Zaretskii 2014-12-13 10:16 ` David Engster 2014-12-13 9:04 ` David Engster 3 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2014-12-13 8:04 UTC (permalink / raw) To: David Engster; +Cc: emacs-devel > From: Ted Zlatanov <tzz@lifelogs.com> > Date: Fri, 12 Dec 2014 19:25:38 -0500 > > On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: > > EZ> No need to fear, just remember to review what "git show" displays, > EZ> after the merge and before you push. If it doesn't look OK to you, > EZ> you can always reset to cancel the merge. > > Yup. I did it, carefully. Thanks. I fixed the dates of the ChangeLog entries merged by that. David, is it possible to enhance gitmerge.el to take care of that automatically? Otherwise I predict that people will keep making these mistakes forever. Thanks. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 8:04 ` Eli Zaretskii @ 2014-12-13 10:16 ` David Engster 2014-12-18 22:38 ` David Engster 0 siblings, 1 reply; 63+ messages in thread From: David Engster @ 2014-12-13 10:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii writes: > David, is it possible to enhance gitmerge.el to take care of that > automatically? Otherwise I predict that people will keep making these > mistakes forever. I was hoping that gitmerge already does it, since I lifted the ChangeLog merge stuff directly from bzrmerge, which AFAIK also did the date fixes. I'll take a look why that doesn't work anymore. -David ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 10:16 ` David Engster @ 2014-12-18 22:38 ` David Engster 2014-12-19 8:50 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: David Engster @ 2014-12-18 22:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel David Engster writes: > Eli Zaretskii writes: >> David, is it possible to enhance gitmerge.el to take care of that >> automatically? Otherwise I predict that people will keep making these >> mistakes forever. > > I was hoping that gitmerge already does it, since I lifted the ChangeLog > merge stuff directly from bzrmerge, which AFAIK also did the date > fixes. I'll take a look why that doesn't work anymore. It seems that this code will only fix dates for conflicted ChangeLog files. However, the changelog merge driver will avoid those conflicts, so nothing happens (Bzr had a changelog driver as well, so I'm not sure how it ever worked). I think the dates might get fixed when you disable the changelog merge driver before running gitmerge.el. I know this is not really a solution, but this is not trivial to fix and we'll switch to generated ChangeLogs anyway, so I'm not inclined to work on this. -David ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-18 22:38 ` David Engster @ 2014-12-19 8:50 ` Eli Zaretskii 0 siblings, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2014-12-19 8:50 UTC (permalink / raw) To: David Engster; +Cc: emacs-devel > From: David Engster <deng@randomsample.de> > Cc: emacs-devel@gnu.org > Date: Thu, 18 Dec 2014 23:38:54 +0100 > > David Engster writes: > > Eli Zaretskii writes: > >> David, is it possible to enhance gitmerge.el to take care of that > >> automatically? Otherwise I predict that people will keep making these > >> mistakes forever. > > > > I was hoping that gitmerge already does it, since I lifted the ChangeLog > > merge stuff directly from bzrmerge, which AFAIK also did the date > > fixes. I'll take a look why that doesn't work anymore. > > It seems that this code will only fix dates for conflicted ChangeLog > files. However, the changelog merge driver will avoid those conflicts, > so nothing happens (Bzr had a changelog driver as well, so I'm not sure > how it ever worked). AFAIR, Bazaar's changelog merge plugin would simply put all the merged ChangeLog entries from the other branch on top, so all you needed to do was manually update the dates of the top entries. Git's driver tries to be more sophisticated, so some entries which come from the other branch are inserted in-between the existing entries. Which makes the merged entries harder to find. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 0:25 ` Ted Zlatanov ` (2 preceding siblings ...) 2014-12-13 8:04 ` Eli Zaretskii @ 2014-12-13 9:04 ` David Engster 2014-12-13 9:50 ` David Engster 3 siblings, 1 reply; 63+ messages in thread From: David Engster @ 2014-12-13 9:04 UTC (permalink / raw) To: emacs-devel Ted Zlatanov writes: > On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: > > EZ> No need to fear, just remember to review what "git show" displays, > EZ> after the merge and before you push. If it doesn't look OK to you, > EZ> you can always reset to cancel the merge. > > Yup. I did it, carefully. I'm afraid something went wrong. You did not actually merge. Could it be that you somehow rebased before pushing (by doing 'pull --rebase', for instance)? -David ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 9:04 ` David Engster @ 2014-12-13 9:50 ` David Engster 2014-12-13 13:19 ` Ted Zlatanov 0 siblings, 1 reply; 63+ messages in thread From: David Engster @ 2014-12-13 9:50 UTC (permalink / raw) To: emacs-devel David Engster writes: > Ted Zlatanov writes: >> On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: >> >> EZ> No need to fear, just remember to review what "git show" displays, >> EZ> after the merge and before you push. If it doesn't look OK to you, >> EZ> you can always reset to cancel the merge. >> >> Yup. I did it, carefully. > > I'm afraid something went wrong. You did not actually merge. > > Could it be that you somehow rebased before pushing (by doing 'pull > --rebase', for instance)? Hmm. Even that wouldn't explain it, since I cannot see any rebased commits from 'emacs-24' on 'master'. It seems like they're all squashed into this one commit. I'd really like to see your reflog. Anyway, I guess the best way to fix this is to do another merge of emacs-24 with merge strategy 'ours'? -David ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 9:50 ` David Engster @ 2014-12-13 13:19 ` Ted Zlatanov 2014-12-13 14:13 ` David Engster 0 siblings, 1 reply; 63+ messages in thread From: Ted Zlatanov @ 2014-12-13 13:19 UTC (permalink / raw) To: emacs-devel On Sat, 13 Dec 2014 10:50:13 +0100 David Engster <deng@randomsample.de> wrote: DE> David Engster writes: >> Ted Zlatanov writes: >>> On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: >>> EZ> No need to fear, just remember to review what "git show" displays, EZ> after the merge and before you push. If it doesn't look OK to you, EZ> you can always reset to cancel the merge. >>> >>> Yup. I did it, carefully. >> >> I'm afraid something went wrong. You did not actually merge. >> >> Could it be that you somehow rebased before pushing (by doing 'pull >> --rebase', for instance)? I don't think so? Now I'm just perplexed, too. I must have rebased the commit accidentally. I *started* to rebase because a commit came in before I pushed. But I aborted the rebase, then redid the merge. DE> Hmm. Even that wouldn't explain it, since I cannot see any rebased DE> commits from 'emacs-24' on 'master'. It seems like they're all squashed DE> into this one commit. I'd really like to see your reflog. DE> Anyway, I guess the best way to fix this is to do another merge of DE> emacs-24 with merge strategy 'ours'? It's definitely pilot error, you can assume it's not gitmerge.el. Andreas has redone the merge, it seems. I'm sorry about this, I'll get it right next time. Ted ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 13:19 ` Ted Zlatanov @ 2014-12-13 14:13 ` David Engster 2014-12-13 14:25 ` Ted Zlatanov 2014-12-13 15:18 ` Eli Zaretskii 0 siblings, 2 replies; 63+ messages in thread From: David Engster @ 2014-12-13 14:13 UTC (permalink / raw) To: emacs-devel Ted Zlatanov writes: > On Sat, 13 Dec 2014 10:50:13 +0100 David Engster <deng@randomsample.de> wrote: > > DE> David Engster writes: >>> Ted Zlatanov writes: >>>> On Fri, 12 Dec 2014 16:28:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: >>>> > EZ> No need to fear, just remember to review what "git show" displays, > EZ> after the merge and before you push. If it doesn't look OK to you, > EZ> you can always reset to cancel the merge. >>>> >>>> Yup. I did it, carefully. >>> >>> I'm afraid something went wrong. You did not actually merge. >>> >>> Could it be that you somehow rebased before pushing (by doing 'pull >>> --rebase', for instance)? > > I don't think so? Now I'm just perplexed, too. I must have rebased the > commit accidentally. I *started* to rebase because a commit came in > before I pushed. Never rebase commits that are upstream. Rebasing will always create new commits (in case if you wondering, 'pull --rebase=preserve' doesn't change that; it will keep a merge commit, but that will not merge origin/emacs-24 anymore but a new set of commits). Instead, simply merge master into your tree. Despite what others may say, this is still a perfectly valid thing to do in Git. :-) This what 'git pull' will do by default (unless you configured it otherwise). > But I aborted the rebase, then redid the merge. Yes, it seems there was a pending commit when you finished the merge, so it was all squashed into one. When you want to start from scratch, the best thing to do is a hard reset on 'origin/master'. This will make sure you're in the same state as upstream. In any case, as much as I like Emacs, I really recommend to use 'gitk --all' to inspect your tree before pushing. This will show you immediately if you have created a proper merge from origin/emacs-24. > I'm sorry about this, Don't be. > I'll get it right next time. That's the spirit. -David ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 14:13 ` David Engster @ 2014-12-13 14:25 ` Ted Zlatanov 2014-12-13 15:18 ` Eli Zaretskii 1 sibling, 0 replies; 63+ messages in thread From: Ted Zlatanov @ 2014-12-13 14:25 UTC (permalink / raw) To: emacs-devel On Sat, 13 Dec 2014 15:13:25 +0100 David Engster <deng@randomsample.de> wrote: DE> Never rebase commits that are upstream. Rebasing will always create new DE> commits (in case if you wondering, 'pull --rebase=preserve' doesn't DE> change that; it will keep a merge commit, but that will not merge DE> origin/emacs-24 anymore but a new set of commits). Yes. I have a pull alias that I shouldn't have used. I realized the issue this morning after people noticed, but it was too late. DE> Instead, simply merge master into your tree. Despite what others may DE> say, this is still a perfectly valid thing to do in Git. :-) This what DE> 'git pull' will do by default (unless you configured it otherwise). >> But I aborted the rebase, then redid the merge. DE> Yes, it seems there was a pending commit when you finished the merge, so DE> it was all squashed into one. When you want to start from scratch, the DE> best thing to do is a hard reset on 'origin/master'. This will make sure DE> you're in the same state as upstream. DE> In any case, as much as I like Emacs, I really recommend to use 'gitk DE> --all' to inspect your tree before pushing. This will show you DE> immediately if you have created a proper merge from origin/emacs-24. Yes, will do. I guess I'm too hard-headed to give up after doing this wrong twice... I'll try the process again in a few days, third time's a charm. Ted ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 14:13 ` David Engster 2014-12-13 14:25 ` Ted Zlatanov @ 2014-12-13 15:18 ` Eli Zaretskii 2014-12-13 19:44 ` David Engster 1 sibling, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2014-12-13 15:18 UTC (permalink / raw) To: David Engster; +Cc: emacs-devel > From: David Engster <deng@randomsample.de> > Date: Sat, 13 Dec 2014 15:13:25 +0100 > > Never rebase commits that are upstream. Rebasing will always create new > commits (in case if you wondering, 'pull --rebase=preserve' doesn't > change that; it will keep a merge commit, but that will not merge > origin/emacs-24 anymore but a new set of commits). English, please: what does that mean? The documentation seems to suggest that "pull --rebase=preserve" is exactly the right thing in this situation. > Instead, simply merge master into your tree. Despite what others may > say, this is still a perfectly valid thing to do in Git. :-) This what > 'git pull' will do by default (unless you configured it otherwise). Yes, but then my commits will appear as merge-commits, won't they? ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 15:18 ` Eli Zaretskii @ 2014-12-13 19:44 ` David Engster 2014-12-13 19:59 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: David Engster @ 2014-12-13 19:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii writes: >> From: David Engster <deng@randomsample.de> >> Date: Sat, 13 Dec 2014 15:13:25 +0100 >> >> Never rebase commits that are upstream. Rebasing will always create new >> commits (in case if you wondering, 'pull --rebase=preserve' doesn't >> change that; it will keep a merge commit, but that will not merge >> origin/emacs-24 anymore but a new set of commits). > > English, please: what does that mean? When you rebase a commit, it becomes a new one. Therefore, you can only safely rebase "local" commits (meaning: commits only *you* have). > The documentation seems to suggest that "pull --rebase=preserve" is > exactly the right thing in this situation. The name "preserve" is misleading. It does not mean that you have the same merge after the rebase. That's not possible, since the commits change during this operation. It helps to think of a rebase simply as a series of cherry-picks. Any conflicts you resolved in a merge commit are now resolved commit by commit. If you do 'rebase=preserve', what git does is: it tries to re-create(!) the merge commit with the rebased commits afterwards. This merge commit is pure metadata now, since there are no conflicts to resolve. So practically, 'rebase=preserve' is only meant for *unpushed* local branches you have merged, and you want to keep the metadata of this local merge. >> Instead, simply merge master into your tree. Despite what others may >> say, this is still a perfectly valid thing to do in Git. :-) This what >> 'git pull' will do by default (unless you configured it otherwise). > > Yes, but then my commits will appear as merge-commits, won't they? Not sure what you mean. This is equivalent to the merge-based workflow we had with Bazaar. -David ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 19:44 ` David Engster @ 2014-12-13 19:59 ` Eli Zaretskii 2014-12-13 22:00 ` Dmitry Gutov 2014-12-13 23:13 ` David Engster 0 siblings, 2 replies; 63+ messages in thread From: Eli Zaretskii @ 2014-12-13 19:59 UTC (permalink / raw) To: David Engster; +Cc: emacs-devel > From: David Engster <deng@randomsample.de> > Cc: emacs-devel@gnu.org > Date: Sat, 13 Dec 2014 20:44:18 +0100 > > When you rebase a commit, it becomes a new one. Therefore, you can only > safely rebase "local" commits (meaning: commits only *you* have). If "safely" here means "while preserving the commit's sha1", then it's quite obvious. But why would that matter in this scenario? And why does that cause the merged versions appear as if they were not merged at all, even when rebase=preserve was/is used? > > The documentation seems to suggest that "pull --rebase=preserve" is > > exactly the right thing in this situation. > > The name "preserve" is misleading. I didn't mean the name, I meant its documentation. It says: locally committed merge commits will not be flattened by running 'git pull' "locally committed" seems to fit the scenario we are discussing, no? > It does not mean that you have the same merge after the > rebase. That's not possible, since the commits change during this > operation. I didn't say I want to have the same merge. All I want is to have _some_ indication there was a merge from the other branch, including when that branch is a public branch. You seem to say it's not possible with Git. > It helps to think of a rebase simply as a series of cherry-picks. Any > conflicts you resolved in a merge commit are now resolved commit by > commit. If you do 'rebase=preserve', what git does is: it tries to > re-create(!) the merge commit with the rebased commits afterwards. This > merge commit is pure metadata now, since there are no conflicts to > resolve. Sorry, I still don't understand. Which commits from what branches does Git merge after 'rebase=preserve'? And how do conflicts enter this picture? Suppose there were no conflicts at all during the original merge -- would the merge still disappear after 'rebase=preserve'? > >> Instead, simply merge master into your tree. Despite what others may > >> say, this is still a perfectly valid thing to do in Git. :-) This what > >> 'git pull' will do by default (unless you configured it otherwise). > > > > Yes, but then my commits will appear as merge-commits, won't they? > > Not sure what you mean. This is equivalent to the merge-based workflow > we had with Bazaar. But I didn't work on a separate branch, I worked in master. Therefore, I'd like to avoid merge-commits if possible, and I thought using 'rebase=preserve' does that, and also lets me merge branches, whether my local branches or the emacs-24 release branch. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 19:59 ` Eli Zaretskii @ 2014-12-13 22:00 ` Dmitry Gutov 2014-12-14 3:36 ` Eli Zaretskii 2014-12-13 23:13 ` David Engster 1 sibling, 1 reply; 63+ messages in thread From: Dmitry Gutov @ 2014-12-13 22:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: David Engster, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> When you rebase a commit, it becomes a new one. Therefore, you can only >> safely rebase "local" commits (meaning: commits only *you* have). > > If "safely" here means "while preserving the commit's sha1", then it's > quite obvious. Rebasing *never* preserves a commit's SHA. So basically, you always get a set of new commits that look very much like the old ones. > at all, even when rebase=preserve was/is used? What rebase=preserve does, is "pass --preserve-merges along to git rebase so that locally created merge commits will not be flattened" (quoting the 'git pull' man page). ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 22:00 ` Dmitry Gutov @ 2014-12-14 3:36 ` Eli Zaretskii 0 siblings, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2014-12-14 3:36 UTC (permalink / raw) To: Dmitry Gutov; +Cc: deng, emacs-devel > From: Dmitry Gutov <dgutov@yandex.ru> > Cc: David Engster <deng@randomsample.de>, emacs-devel@gnu.org > Date: Sun, 14 Dec 2014 00:00:15 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> When you rebase a commit, it becomes a new one. Therefore, you can only > >> safely rebase "local" commits (meaning: commits only *you* have). > > > > If "safely" here means "while preserving the commit's sha1", then it's > > quite obvious. > > Rebasing *never* preserves a commit's SHA. So basically, you always get > a set of new commits that look very much like the old ones. That's what I said. > > at all, even when rebase=preserve was/is used? > > What rebase=preserve does, is "pass --preserve-merges along to git > rebase so that locally created merge commits will not be flattened" > (quoting the 'git pull' man page). That's what I said. Thanks. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 19:59 ` Eli Zaretskii 2014-12-13 22:00 ` Dmitry Gutov @ 2014-12-13 23:13 ` David Engster 2014-12-14 16:09 ` Eli Zaretskii 1 sibling, 1 reply; 63+ messages in thread From: David Engster @ 2014-12-13 23:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 3121 bytes --] Eli Zaretskii writes: >> From: David Engster <deng@randomsample.de> >> Cc: emacs-devel@gnu.org >> Date: Sat, 13 Dec 2014 20:44:18 +0100 >> >> When you rebase a commit, it becomes a new one. Therefore, you can only >> safely rebase "local" commits (meaning: commits only *you* have). > > If "safely" here means "while preserving the commit's sha1", then it's > quite obvious. But why would that matter in this scenario? And why > does that cause the merged versions appear as if they were not merged > at all, even when rebase=preserve was/is used? I think we really have to discuss this on an actual example. I've attached a small script which will create three directories underneath a directory called "MERGE_REBASE_TEST": 'upstream', 'ted' and 'eli'. There are two branches, 'master' and 'stable', which Ted sets up and pushes. I put some sleeps in there just so that the commits have different time stamps. Ted merges 'stable' into 'master', but does not push yet. Then Eli makes a new commit on 'master' and pushes. This is where the script ends. Now go to 'ted' and do 'gitk --all' to see the situation. If you try to push with 'git push origin master', then this will fail because there's this new commit from Eli. Now do 'git pull --rebase=preserve', and then again do 'gitk --all'. You'll see that the 'stable' branch was rebased onto 'origin/master'. This changed the SHA1 of those two commits on 'stable', as they now descend from a different parent. You *have* a merge, but it is *not* a merge from origin/stable, but from a new (unnamed) branch that was created by rebasing origin/stable. Simply delete the MERGE_REBASE_TEST directory and run the script again to try the alternatives for Ted. 'git pull --rebase' will do the same as '--rebase=preserve' but will simply drop the merge commit ("flatten the history"). Again, this will *not* merge the two commits from origin/stable (a 'git log stable ^master' will list all commits that are in stable but not in master). If you simply do 'git pull', this will merge origin/master into your tree. If you push this, everything will be OK. The above log command will show nothing, just as it should after a succesful merge. > I didn't say I want to have the same merge. All I want is to have > _some_ indication there was a merge from the other branch, including > when that branch is a public branch. You seem to say it's not > possible with Git. You can't at the same time move a branch onto a new parent (which is what rebase does) and then merge it, so that it looks like you've merged the original one which had another parent. > Sorry, I still don't understand. Which commits from what branches > does Git merge after 'rebase=preserve'? It merges the branch that is implicitly created by moving 'origin/emacs-24' to a newer parent. > And how do conflicts enter this picture? Suppose there were no > conflicts at all during the original merge -- would the merge still > disappear after 'rebase=preserve'? I guess it's better to forget conflicts. I was hoping it would make clearer how rebase works, but it just complicates things. -David [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: merge-rebase-test.sh --] [-- Type: text/x-sh, Size: 993 bytes --] #!/bin/sh mkdir MERGE_REBASE_TEST cd MERGE_REBASE_TEST # Create bare upstream mkdir upstream cd upstream git init --bare cd .. # Ted clones, creates two commits on master and pushes. git clone upstream ted cd ted echo "bla" > foo git add foo sleep 2 git commit -a -m "first commit on master" echo "bla2" >> foo sleep 2 git commit -a -m "second commit on master" git push origin master # Ted now creates branch 'stable' with two commits and pushes. git checkout -b stable echo "bla" > bar git add bar sleep 2 git commit -a -m "commit to stable 1" echo "bla2" >> bar sleep 2 git commit -a -m "commit to stable 2" git push origin stable # Ted goes back to master and merges 'origin/stable', but does NOT push. git checkout master sleep 2 git merge --no-ff origin/stable -m "merge stable" cd .. # Eli clones, creates new commit on master and pushes git clone upstream eli cd eli git checkout master echo "bla3" >> foo sleep 2 git commit -a -m "New commit on master" git push origin master cd .. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-13 23:13 ` David Engster @ 2014-12-14 16:09 ` Eli Zaretskii 2014-12-14 16:37 ` Ted Zlatanov ` (3 more replies) 0 siblings, 4 replies; 63+ messages in thread From: Eli Zaretskii @ 2014-12-14 16:09 UTC (permalink / raw) To: David Engster; +Cc: emacs-devel > From: David Engster <deng@randomsample.de> > Cc: emacs-devel@gnu.org > Date: Sun, 14 Dec 2014 00:13:20 +0100 > > > Sorry, I still don't understand. Which commits from what branches > > does Git merge after 'rebase=preserve'? > > It merges the branch that is implicitly created by moving > 'origin/emacs-24' to a newer parent. That's the missing link, thanks. So this means that: . Using "pull --rebase=preserve" always rewrites the merge to come from some unnamed branch, which is different from the branch that originated the merged commits. . This is true for merges from local branches as well. Therefore, using this option is not advisable for local branches, because doing that would mean trouble when I next merge from master into my local branch -- I will get the same commits back again. . IOW, rebase=preserve is not useful in a merge-based workflow. Is my interpretation correct? If it is, then here's my conundrum. When I make changes in master, I don't want them to look as if they were made on some branch when I push them. Why? for starters, because "log --first-parent" won't show them. So I use "pull --rebase" to avoid that. This works well as long as I didn't make any local merge-commits, be it from my local branches or from public branches such as emacs-24. I thought that using rebase=preserve would cover the latter use cases as well, but now I understand I was mistaken: I can use "pull --rebase" only if there were no merge-commits since the last refs update; otherwise I need to use "pull". So I cannot configure Git to always use some option when pulling, and forget about that. AFAIU, an alternative, when I have local merge-commits, is to use "pull --ff-only", and when it refuses to pull, use "reset --hard origin/master", and then "merge -no-ff" and commit, before pushing. That's significantly more complicated, sigh. Which means there's no easy way with Git to support a workflow that preserves mainline, without jumping through some hoops. Is that correct? Or is there a better workflow that preserves the mainline? If there is no better workflow, perhaps we need to radically rethink our recommended project workflow, like not base it on merges but on rebase, or push fixes to master and then cherry-pick them to the release branch, or something else. Because what bzr supported easily and almost seamlessly, Git doesn't -- in the sense that emulating the same workflow is more complicated and thus error-prone. To me, this spells that we fight the tool, i.e. our workflow should change. > You can't at the same time move a branch onto a new parent (which is > what rebase does) and then merge it, so that it looks like you've merged > the original one which had another parent. I only use rebase because I don't know of another way of being able to work on master without having my commits look as if they were made on a branch, after I push them, which AFAIU will happen if someone else pushes before I push my local commits made on master. If there's a reasonably simple way to avoid this effect without rebasing, I guess I'll switch to that. I didn't use rebase with bzr, because there was a simple way to preserve the mainline without rebasing. Btw, I think we need to do something urgently in gitmerge.el to avoid this kind of mistakes. Otherwise, people will keep making these mistakes, and no amount of explanations will ever be able to prevent that. Thanks. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-14 16:09 ` Eli Zaretskii @ 2014-12-14 16:37 ` Ted Zlatanov 2014-12-14 16:55 ` Eli Zaretskii 2014-12-14 23:21 ` Stefan Monnier 2014-12-14 17:46 ` Paul Eggert ` (2 subsequent siblings) 3 siblings, 2 replies; 63+ messages in thread From: Ted Zlatanov @ 2014-12-14 16:37 UTC (permalink / raw) To: emacs-devel On Sun, 14 Dec 2014 18:09:49 +0200 Eli Zaretskii <eliz@gnu.org> wrote: EZ> If there is no better workflow, perhaps we need to radically rethink EZ> our recommended project workflow, like not base it on merges but on EZ> rebase, or push fixes to master and then cherry-pick them to the EZ> release branch, or something else. Because what bzr supported easily EZ> and almost seamlessly, Git doesn't -- in the sense that emulating the EZ> same workflow is more complicated and thus error-prone. To me, this EZ> spells that we fight the tool, i.e. our workflow should change. I think cherry-picking fixes from emacs-24 to master or vice-versa is the best way: * we tend to make commits in isolation, so there's no need to merge the whole branch in one shot. It's also much less risky as far as methodology. * "cherry-pick -x" will preserve the original commit info * "git diff" and "git log --cherry-pick" will do what people expect Ted ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-14 16:37 ` Ted Zlatanov @ 2014-12-14 16:55 ` Eli Zaretskii 2014-12-14 17:00 ` Ted Zlatanov 2014-12-14 23:21 ` Stefan Monnier 1 sibling, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2014-12-14 16:55 UTC (permalink / raw) To: emacs-devel; +Cc: emacs-devel > From: Ted Zlatanov <tzz@lifelogs.com> > Date: Sun, 14 Dec 2014 11:37:49 -0500 > > I think cherry-picking fixes from emacs-24 to master or vice-versa is > the best way: IMO, if we go for cherry-picking, then it's best to fix bugs on master and cherry-pick from there to emacs-24. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-14 16:55 ` Eli Zaretskii @ 2014-12-14 17:00 ` Ted Zlatanov 0 siblings, 0 replies; 63+ messages in thread From: Ted Zlatanov @ 2014-12-14 17:00 UTC (permalink / raw) To: emacs-devel On Sun, 14 Dec 2014 18:55:35 +0200 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Ted Zlatanov <tzz@lifelogs.com> >> Date: Sun, 14 Dec 2014 11:37:49 -0500 >> >> I think cherry-picking fixes from emacs-24 to master or vice-versa is >> the best way: EZ> IMO, if we go for cherry-picking, then it's best to fix bugs on master EZ> and cherry-pick from there to emacs-24. It's OK to go either way. The patch is simply getting copied between the branches, so the direction doesn't matter. Ted ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-14 16:37 ` Ted Zlatanov 2014-12-14 16:55 ` Eli Zaretskii @ 2014-12-14 23:21 ` Stefan Monnier 1 sibling, 0 replies; 63+ messages in thread From: Stefan Monnier @ 2014-12-14 23:21 UTC (permalink / raw) To: emacs-devel I think cherry-picking fixes from emacs-24 to master or vice-versa is > the best way: Good for you, but this has been decided long ago, and I have no intention to discuss this again. Stefan ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-14 16:09 ` Eli Zaretskii 2014-12-14 16:37 ` Ted Zlatanov @ 2014-12-14 17:46 ` Paul Eggert 2014-12-14 17:50 ` Eli Zaretskii 2014-12-14 18:28 ` Ted Zlatanov 2014-12-14 21:40 ` David Engster 2014-12-14 22:42 ` Stefan Monnier 3 siblings, 2 replies; 63+ messages in thread From: Paul Eggert @ 2014-12-14 17:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii wrote: > perhaps we need to radically rethink > our recommended project workflow, like not base it on merges but on > rebase, or push fixes to master and then cherry-pick them to the > release branch, or something else Part of the problem is the mundane business of maintaining ChangeLogs by hand, an error-prone process with merges. We're planning to fix this (currently scheduled for next month) by generating ChangeLogs automatically. Perhaps once we've done that the remaining problems with merging will be so small that we can just live with them. (The particular problem Ted ran into seems pretty complicated; I'm not sure it's a good use case for us when designing our development workflow.) More fundamentally there's the issue of how much we want commits to be serialized. That is, do we want development history to look as if it was done one commit at a time in a single branch? If so, merges are not the way to go, because they're DAG-based. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-14 17:46 ` Paul Eggert @ 2014-12-14 17:50 ` Eli Zaretskii 2014-12-14 18:28 ` Ted Zlatanov 1 sibling, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2014-12-14 17:50 UTC (permalink / raw) To: Paul Eggert; +Cc: emacs-devel > Date: Sun, 14 Dec 2014 09:46:12 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: emacs-devel@gnu.org > > Eli Zaretskii wrote: > > perhaps we need to radically rethink > > our recommended project workflow, like not base it on merges but on > > rebase, or push fixes to master and then cherry-pick them to the > > release branch, or something else > > Part of the problem is the mundane business of maintaining ChangeLogs by hand, > an error-prone process with merges. We're planning to fix this (currently > scheduled for next month) by generating ChangeLogs automatically. Perhaps once > we've done that the remaining problems with merging will be so small that we can > just live with them. I'm not sure. The problem of using incorrect Git commands in the case that triggered this discussion was unrelated to ChangeLogs. > (The particular problem Ted ran into seems pretty complicated; I'm > not sure it's a good use case for us when designing our development > workflow.) People are running into problems all over. It's not just Ted and not just that particular push. > More fundamentally there's the issue of how much we want commits to be > serialized. That is, do we want development history to look as if it was done > one commit at a time in a single branch? If so, merges are not the way to go, > because they're DAG-based. That's what I was asking, in different words. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-14 17:46 ` Paul Eggert 2014-12-14 17:50 ` Eli Zaretskii @ 2014-12-14 18:28 ` Ted Zlatanov 2014-12-14 19:41 ` David Engster 1 sibling, 1 reply; 63+ messages in thread From: Ted Zlatanov @ 2014-12-14 18:28 UTC (permalink / raw) To: emacs-devel On Sun, 14 Dec 2014 09:46:12 -0800 Paul Eggert <eggert@cs.ucla.edu> wrote: PE> (The particular problem Ted ran into seems pretty complicated; I'm PE> not sure it's a good use case for us when designing our development PE> workflow.) No, please assume I screwed up :) But I still think generally, cherry-picks are easier to manage and harder to screw up. The gitmerge.el workflow is basically a sequence of cherry-picks. Ted ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-14 18:28 ` Ted Zlatanov @ 2014-12-14 19:41 ` David Engster 0 siblings, 0 replies; 63+ messages in thread From: David Engster @ 2014-12-14 19:41 UTC (permalink / raw) To: emacs-devel Ted Zlatanov writes: > But I still think generally, cherry-picks are easier to manage and > harder to screw up. Cherry-picks are *terrible* to manage. Git tries a bit to do that, either be giving you tools to record additional information in the commit log (see the '-x' option of cherry-pick), or by using patch-id's, but all of that stuff pretty much falls apart when you have conflicts, so it's nothing you can really rely on (especially not us, because of ChangeLogs). > The gitmerge.el workflow is basically a sequence of cherry-picks. No, that's precisely what gitmerge.el avoids. It is a sequence of merges. -David ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-14 16:09 ` Eli Zaretskii 2014-12-14 16:37 ` Ted Zlatanov 2014-12-14 17:46 ` Paul Eggert @ 2014-12-14 21:40 ` David Engster 2014-12-15 3:47 ` Eli Zaretskii 2014-12-14 22:42 ` Stefan Monnier 3 siblings, 1 reply; 63+ messages in thread From: David Engster @ 2014-12-14 21:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii writes: > So this means that: > > . Using "pull --rebase=preserve" always rewrites the merge to come > from some unnamed branch, which is different from the branch that > originated the merged commits. Yes. > . This is true for merges from local branches as well. Therefore, > using this option is not advisable for local branches, because > doing that would mean trouble when I next merge from master into > my local branch -- I will get the same commits back again. Do you mean you have a long-living local branch which you regularly merge to master? You're right that in this case doing 'pull --rebase=preserve' is problematic. If you continue to work on your branch and merge from master, you will indeed merge the rebased commits. To avoid that, you would have to delete the old branch and continue working on the rebased one. > . IOW, rebase=preserve is not useful in a merge-based workflow. Rebasing is the anti-thesis to merging, so a purely merge-based workflow wouldn't touch it in the first place (see: Bazaar). > If it is, then here's my conundrum. When I make changes in master, I > don't want them to look as if they were made on some branch when I > push them. Why? for starters, because "log --first-parent" won't show > them. So I use "pull --rebase" to avoid that. This works well as > long as I didn't make any local merge-commits, be it from my local > branches or from public branches such as emacs-24. Isn't flattening of the history precisely what you want when you have merges of local branches, so that they appear like they were made on master? > AFAIU, an alternative, when I have local merge-commits, is to use > "pull --ff-only", and when it refuses to pull, use "reset --hard > origin/master", and then "merge -no-ff" and commit, before pushing. That would also mean you have to fix conflicts again (unless you use the 'rerere' feature, but let's not go there yet). > Which means there's no easy way with Git to support a workflow that > preserves mainline, without jumping through some hoops. > > Is that correct? I would say it is. AFAIK, Git has no notion of 'mainline' like Bazaar had, so trying to preserve it does require a lot of discipline. > If there is no better workflow, perhaps we need to radically rethink > our recommended project workflow, like not base it on merges but on > rebase, or push fixes to master and then cherry-pick them to the > release branch, or something else. Cherry-picking to emacs-24 would indeed make some things easier. Most importantly, it would make gitmerge.el obsolete (which I consider a good thing). -David ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-14 21:40 ` David Engster @ 2014-12-15 3:47 ` Eli Zaretskii 2014-12-15 20:39 ` David Engster 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2014-12-15 3:47 UTC (permalink / raw) To: David Engster; +Cc: emacs-devel > From: David Engster <deng@randomsample.de> > Cc: emacs-devel@gnu.org > Date: Sun, 14 Dec 2014 22:40:41 +0100 > > Eli Zaretskii writes: > > So this means that: > > > > . Using "pull --rebase=preserve" always rewrites the merge to come > > from some unnamed branch, which is different from the branch that > > originated the merged commits. > > Yes. > > > . This is true for merges from local branches as well. Therefore, > > using this option is not advisable for local branches, because > > doing that would mean trouble when I next merge from master into > > my local branch -- I will get the same commits back again. > > Do you mean you have a long-living local branch which you regularly > merge to master? No. But when I work on a feature branch that takes weeks, sometimes months, to complete, I merge from master near the end of the development, to make sure landing the feature will not introduce regressions. Sometimes there's more than one such merge, especially if I discover subtle issues as result of merging. > You're right that in this case doing 'pull > --rebase=preserve' is problematic. If you continue to work on your > branch and merge from master, you will indeed merge the rebased > commits. To avoid that, you would have to delete the old branch and > continue working on the rebased one. Sad. > > . IOW, rebase=preserve is not useful in a merge-based workflow. > > Rebasing is the anti-thesis to merging, so a purely merge-based workflow > wouldn't touch it in the first place (see: Bazaar). But rebase=preserve seemed to be advertised to give you the best of both worlds. Now it turns out to be a sales gimmick at best, and a time bomb at worst... > > If it is, then here's my conundrum. When I make changes in master, I > > don't want them to look as if they were made on some branch when I > > push them. Why? for starters, because "log --first-parent" won't show > > them. So I use "pull --rebase" to avoid that. This works well as > > long as I didn't make any local merge-commits, be it from my local > > branches or from public branches such as emacs-24. > > Isn't flattening of the history precisely what you want when you have > merges of local branches, so that they appear like they were made on > master? No. When development was on a branch, I generally want to preserve that branch in the history, not flatten it. My commits on a feature branch follow some logic that is important to me (and documented in the commit log messages), so that long after the job is done these commits make it easier to understand why something was done the way it was, and also find the reasons for bugs or misfeatures. > > AFAIU, an alternative, when I have local merge-commits, is to use > > "pull --ff-only", and when it refuses to pull, use "reset --hard > > origin/master", and then "merge -no-ff" and commit, before pushing. > > That would also mean you have to fix conflicts again (unless you use the > 'rerere' feature, but let's not go there yet). Yes. Like I said: more complicated. > > Which means there's no easy way with Git to support a workflow that > > preserves mainline, without jumping through some hoops. > > > > Is that correct? > > I would say it is. AFAIK, Git has no notion of 'mainline' like Bazaar > had, so trying to preserve it does require a lot of discipline. Discipline I have. It's memory that I no longer have enough to prevent me from making mistakes when certain everyday actions need small variations. Thanks. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-15 3:47 ` Eli Zaretskii @ 2014-12-15 20:39 ` David Engster 2014-12-16 19:42 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: David Engster @ 2014-12-15 20:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii writes: >> From: David Engster <deng@randomsample.de> >> Cc: emacs-devel@gnu.org >> Date: Sun, 14 Dec 2014 22:40:41 +0100 >> > . This is true for merges from local branches as well. Therefore, >> > using this option is not advisable for local branches, because >> > doing that would mean trouble when I next merge from master into >> > my local branch -- I will get the same commits back again. >> >> Do you mean you have a long-living local branch which you regularly >> merge to master? > > No. But when I work on a feature branch that takes weeks, sometimes > months, to complete, I merge from master near the end of the > development, to make sure landing the feature will not introduce > regressions. Sometimes there's more than one such merge, especially > if I discover subtle issues as result of merging. I see. I guess you could avoid those problems by merging origin/master instead. But actually, instead of merging master into your feature branch, I'd rather recommend rebasing it *onto* master, but explicitly and not as a side effect of pull. I'm not a big fan of 'pull --rebase'; it works nice until it doesn't. As you've seen, this combination of pull+rebase can lead to pretty surprising results, and the '=preserve' simply changes what kind of surprise you're getting. For local feature branches, I would recommend the following (not saying this is "the right way" or anything, but maybe you find something useful in there): - Instead of merging master into my feature branch, I rebase it explicitly by doing git checkout featurebranch git rebase master - I only merge feature branches into master when they are finished and I plan to push directly afterwards. - Before merging to master, I rebase onto it one last time so that the merge has no conflicts, then I merge with '--no-ff' and push. - If the push fails because there are new commits upstream, instead of using 'pull --rebase=preserve', I rather delete the merge so that I get a "normal" fast-forward pull and merge again. If I'm really unlucky, this new commit from upstream causes a conflict now, in which case I usually just resolve it, simply hoping that the push will work next time. Of course, for *public* branches like emacs-24, one must not use 'rebase' in any way but do a normal merge. If the push fails, do a regular 'pull' so that the new commits are merged and push again. >> Isn't flattening of the history precisely what you want when you have >> merges of local branches, so that they appear like they were made on >> master? > > No. When development was on a branch, I generally want to preserve > that branch in the history, not flatten it. My commits on a feature > branch follow some logic that is important to me (and documented in > the commit log messages), so that long after the job is done these > commits make it easier to understand why something was done the way it > was, and also find the reasons for bugs or misfeatures. I agree. I misunderstood your statement that your commits should not look like they were made on another branch, but if I understand you correctly now, you mean you don't want to have merge commits from master before pushing, but you rather prefer to rebase (to which I agree as well). -David ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-15 20:39 ` David Engster @ 2014-12-16 19:42 ` Eli Zaretskii 2014-12-17 9:58 ` Steinar Bang 2014-12-17 20:37 ` David Engster 0 siblings, 2 replies; 63+ messages in thread From: Eli Zaretskii @ 2014-12-16 19:42 UTC (permalink / raw) To: David Engster; +Cc: emacs-devel Thanks for taking the time to explain and make suggestions. > From: David Engster <deng@randomsample.de> > Cc: emacs-devel@gnu.org > Date: Mon, 15 Dec 2014 21:39:58 +0100 > > > when I work on a feature branch that takes weeks, sometimes > > months, to complete, I merge from master near the end of the > > development, to make sure landing the feature will not introduce > > regressions. Sometimes there's more than one such merge, especially > > if I discover subtle issues as result of merging. > I see. I guess you could avoid those problems by merging origin/master > instead. Sorry, I don't understand: doesn't origin/master have the same commits as master (modulo the local commits I did on master since the last pull)? If so, how would merging origin/master help me? Once again, the problem is in this situation: . My work on a feature branch is almost finished, so I merge from master to make sure my feature doesn't break anything and isn't broken by development on master. . I then merge from the feature branch to master and attempt to push, but the push is rejected. . I then pull --rebase=preserve and push again It's the last step that causes trouble, and the "trouble" here is that commits I merged from master before merging back might be merged again in the future, if I need for some reason to continue working on that feature branch again. Where will origin/master help in this situation? > But actually, instead of merging master into your feature > branch, I'd rather recommend rebasing it *onto* master, but explicitly That'd lose too much information, so I'd like to avoid that if possible. It might also cause complications if I have more than 1 active feature branch, and want to compare or merge between them. It is also a bad idea when the branch is a public one, as you point out. > For local feature branches, I would recommend the following (not saying > this is "the right way" or anything, but maybe you find something useful > in there): > > - Instead of merging master into my feature branch, I rebase it > explicitly by doing > > git checkout featurebranch > git rebase master > > - I only merge feature branches into master when they are finished and I > plan to push directly afterwards. > > - Before merging to master, I rebase onto it one last time so that the > merge has no conflicts, then I merge with '--no-ff' and push. > > - If the push fails because there are new commits upstream, instead of > using 'pull --rebase=preserve', I rather delete the merge so that I > get a "normal" fast-forward pull and merge again. If I'm really > unlucky, this new commit from upstream causes a conflict now, in which > case I usually just resolve it, simply hoping that the push will work > next time. If "merge --no-ff" and aborting the merge when a push is rejected are to be used anyway, why do I need to rebase the feature branch onto master? That doesn't seem necessary. I could use normal merges, no? > Of course, for *public* branches like emacs-24, one must not use > 'rebase' in any way but do a normal merge. If the push fails, do a > regular 'pull' so that the new commits are merged and push again. I would like to have the same workflow for both local branches and public ones, such as emacs-24, if at all possible. That will relieve the "memory pressure" and reduce the probability of errors. > > No. When development was on a branch, I generally want to preserve > > that branch in the history, not flatten it. My commits on a feature > > branch follow some logic that is important to me (and documented in > > the commit log messages), so that long after the job is done these > > commits make it easier to understand why something was done the way it > > was, and also find the reasons for bugs or misfeatures. > I agree. I misunderstood your statement that your commits should not > look like they were made on another branch, but if I understand you > correctly now, you mean you don't want to have merge commits from master > before pushing, but you rather prefer to rebase (to which I agree as > well). I actually don't mind merge commits, as long as they reflect what was actually done, as opposed to being generated by Git out of thin air. What I certainly want to avoid is any kind of rebasing, cherry-picking or similar things that will then put me at risk of having the same commits merged again, because the original commits are rewritten or not recorded in the DAG. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-16 19:42 ` Eli Zaretskii @ 2014-12-17 9:58 ` Steinar Bang 2014-12-17 10:52 ` Steinar Bang 2014-12-17 15:35 ` Eli Zaretskii 2014-12-17 20:37 ` David Engster 1 sibling, 2 replies; 63+ messages in thread From: Steinar Bang @ 2014-12-17 9:58 UTC (permalink / raw) To: emacs-devel >>>>> Eli Zaretskii <eliz@gnu.org>: > Once again, the problem is in this situation: > . My work on a feature branch is almost finished, so I merge from > master to make sure my feature doesn't break anything and isn't > broken by development on master. > . I then merge from the feature branch to master and attempt to push, > but the push is rejected. > . I then pull --rebase=preserve and push again > It's the last step that causes trouble, and the "trouble" here is that > commits I merged from master before merging back might be merged again > in the future, if I need for some reason to continue working on that > feature branch again. Let me see if I understand, you branch off from master like so: -a---b-c-d- master \ e-f- eli-feature-1 Then you wish to prepare for a push so you merge in master: -a---b-c-d--- master \ \ e-f----g- eli-feature-1 (where "g" is the merge commit) You merge your feature branch into master (ff merge): -a---b-c-d------ master \ \ / e-f----g---- eli-feature-1 And then push of master fails, and you do git pull --rebase=preserve and at this point I have no idea what the branches look like, since I've never used "--rebase=preserve". But if I understand you correctly, you're concerned that if you continue to work on eli-feature-1 and then merge into master, then the commits "b", "c", and "d" that were merged into your feature branch will be re-applied? Have you seen this happen? The "git merge" command seems to be generally very good at backing off when the changes are already in place (e.g. when I cherry pick changes from master back to a release branch, and later merge the release branch, I rarely see conflicts). At least, if you were doing ordinary merges in pull, it would never be a problem... but I'm guessing (note: "guessing") now that what happens is that what you end up with on master, is a rebased version of the merge commit "g", ie. something like this: -a---b-c-d-i-j-h- master \ \ / e-f----\/ \g---- eli-feature-1 where "i" and "j" are the commits that blocked your push, and "h" is a rebased version of "g"? (I saw later that my guessing might be off, see below for more) Hm... what would happend if you continue to work on eli-feature-1 and then merge back into master, I have no idea... probably nothing good. The simplest way to proceed would be to just delete the existing eli-feature-1 and create a new eli-feature-1 off the rebased merge commit "h". You could pop off "g" of eli-feature-1, ie. git checkout eli-feature-1 git reset --hard HEAD~1 and then merge in master to get "h" in its place git merge master But it amounts to the more or less same thing (and it all depends on the behaviour being like I describe, which may not be the case, since I'm just guessing). > Where will origin/master help in this situation? Not directly, but you can prepare for the newest that will be on master after the pull before push, without moving off your feature branch, ie. git fetch git merge origin/master >> But actually, instead of merging master into your feature >> branch, I'd rather recommend rebasing it *onto* master, but explicitly > That'd lose too much information, so I'd like to avoid that if > possible. It might also cause complications if I have more than 1 > active feature branch, and want to compare or merge between them. It > is also a bad idea when the branch is a public one, as you point out. FWIW I agree on all of Eli's saying here. [snip! rebasing feature branches] > I would like to have the same workflow for both local branches and > public ones, such as emacs-24, if at all possible. That will > relieve the "memory pressure" and reduce the probability of errors. I'm again in complete agreement with Eli. [snip!] > I actually don't mind merge commits, as long as they reflect what > was actually done, as opposed to being generated by Git out of thin > air. +10 > What I certainly want to avoid is any kind of rebasing, cherry-picking > or similar things that will then put me at risk of having the same > commits merged again, because the original commits are rewritten or > not recorded in the DAG. Aah... so that's what happens: "b", "c", "d" in the example above (that come from master into your feature branch), are rebased, and then later reapplied...? If so that's bad! (I *knew* there were good reasons to shun rebase, and if this is the case I have some real ammunition the next time a discussion with a rebase entusiast comes up) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-17 9:58 ` Steinar Bang @ 2014-12-17 10:52 ` Steinar Bang 2014-12-17 15:36 ` Eli Zaretskii 2014-12-17 15:35 ` Eli Zaretskii 1 sibling, 1 reply; 63+ messages in thread From: Steinar Bang @ 2014-12-17 10:52 UTC (permalink / raw) To: emacs-devel >>>>> Steinar Bang <sb@dod.no>: > and at this point I have no idea what the branches look like, since > I've never used "--rebase=preserve". I still haven't used it, but I have googled a bit, and I found this: http://stackoverflow.com/a/15915431 Example 3 looks a lot like what I outlined, ie. you would get something like this: > -a---b-c-d-i-j-h- master > \ \ / > e-f----\/ > \g---- eli-feature-1 > where "i" and "j" are the commits that blocked your push, and "h" is a > rebased version of "g"? And if so, there will never be a problem with "b", "c", and "d", because they are recorded in "h" (which is the rebased "g"). But there _will_ be a problem if you continue with eli-feature-1 with "g" in the graph. Ie. you will need to pop off a non-rebased merge commit and replace it with the rebased one on one of the the two branches with you proceed (the merge commit can be rebased on either branch, but it's probably less work to do the rebase together with the pull on master, and then fix it later in the feature branch). Unless someone has written an extension to let you rebase two branches simultanously...? It wouldn't surprise me, but a quick googling didn't turn up anything. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-17 10:52 ` Steinar Bang @ 2014-12-17 15:36 ` Eli Zaretskii 0 siblings, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2014-12-17 15:36 UTC (permalink / raw) To: Steinar Bang; +Cc: emacs-devel > From: Steinar Bang <sb@dod.no> > Date: Wed, 17 Dec 2014 11:52:54 +0100 > > > and at this point I have no idea what the branches look like, since > > I've never used "--rebase=preserve". > > I still haven't used it, but I have googled a bit, and I found this: > http://stackoverflow.com/a/15915431 Yes, I've read it when I tried to understand what exactly does rebase=preserve do. > Example 3 looks a lot like what I outlined, ie. you would get something > like this: > > -a---b-c-d-i-j-h- master > > \ \ / > > e-f----\/ > > \g---- eli-feature-1 > > > where "i" and "j" are the commits that blocked your push, and "h" is a > > rebased version of "g"? > > And if so, there will never be a problem with "b", "c", and "d", because > they are recorded in "h" (which is the rebased "g"). > > But there _will_ be a problem if you continue with eli-feature-1 with > "g" in the graph. Yes, that's the problem. AFAIU, there are 2 possible ways to escape this problem: . Let go of the desire to keep the "mainline" linear, and just use "pull" when updating master from upstream. . Use "pull --ff-only", and if it refuses to pull, cancel the merge, pull, and merge again using "merge --no-ff". This will probably preserve the mainline (unless Git has more surprises ;-), and also keep the merge-commits intact, but at the cost of more complicated and error-prone workflow. For GitForEmacsDevs, I tend to prefer the former, since I don't hear too many voices in support of the linear mainline desire. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-17 9:58 ` Steinar Bang 2014-12-17 10:52 ` Steinar Bang @ 2014-12-17 15:35 ` Eli Zaretskii 1 sibling, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2014-12-17 15:35 UTC (permalink / raw) To: Steinar Bang; +Cc: emacs-devel > From: Steinar Bang <sb@dod.no> > Date: Wed, 17 Dec 2014 10:58:15 +0100 > > Let me see if I understand, you branch off from master like so: > > -a---b-c-d- master > \ > e-f- eli-feature-1 > > Then you wish to prepare for a push so you merge in master: > -a---b-c-d--- master > \ \ > e-f----g- eli-feature-1 > > (where "g" is the merge commit) > You merge your feature branch into master (ff merge): > -a---b-c-d------ master > \ \ / > e-f----g---- eli-feature-1 > > And then push of master fails, and you do > git pull --rebase=preserve Yes, this is the workflow and the scenario I was describing. With bzr, it actually happened more or less every time I finished a feature and was about to land it on trunk. So naturally, I would like to preserve the workflow if it's practically possible. > But if I understand you correctly, you're concerned that if you > continue to work on eli-feature-1 and then merge into master, then the > commits "b", "c", and "d" that were merged into your feature branch > will be re-applied? Yes. Also note that I'm not only concerned about myself alone, but about all those who read or will read GitForEmacsDevs, and try to follow the instructions there. They current suggest "pull --rebase", although stop short of mentioning rebase=preserve. > Have you seen this happen? No, not yet (thankfully). > The "git merge" command seems to be generally very good at backing > off when the changes are already in place (e.g. when I cherry pick > changes from master back to a release branch, and later merge the > release branch, I rarely see conflicts). I know and agree, but I'd prefer not to rely on sheer luck, even if the chances are very high. If the danger exists, then the costs of the failure, however rare, can be too high, so I'd like to avoid that completely, especially for the audience of GitForEmacsDevs. > The simplest way to proceed would be to just delete the existing > eli-feature-1 and create a new eli-feature-1 off the rebased merge > commit "h". That's mostly what happens, at least in my sandboxes. But again, there are others who might not delete the branch right away, and there's emacs-24, of course. > > What I certainly want to avoid is any kind of rebasing, cherry-picking > > or similar things that will then put me at risk of having the same > > commits merged again, because the original commits are rewritten or > > not recorded in the DAG. > > Aah... so that's what happens: "b", "c", "d" in the example above > (that come from master into your feature branch), are rebased, and > then later reapplied...? Yes. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-16 19:42 ` Eli Zaretskii 2014-12-17 9:58 ` Steinar Bang @ 2014-12-17 20:37 ` David Engster 2014-12-18 4:55 ` Stephen J. Turnbull 2014-12-18 15:38 ` Eli Zaretskii 1 sibling, 2 replies; 63+ messages in thread From: David Engster @ 2014-12-17 20:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: David Engster <deng@randomsample.de> >> Cc: emacs-devel@gnu.org >> Date: Mon, 15 Dec 2014 21:39:58 +0100 >> >> > when I work on a feature branch that takes weeks, sometimes >> > months, to complete, I merge from master near the end of the >> > development, to make sure landing the feature will not introduce >> > regressions. Sometimes there's more than one such merge, especially >> > if I discover subtle issues as result of merging. > >> I see. I guess you could avoid those problems by merging origin/master >> instead. > > Sorry, I don't understand: doesn't origin/master have the same commits > as master (modulo the local commits I did on master since the last > pull)? If so, how would merging origin/master help me? > > Once again, the problem is in this situation: > > . My work on a feature branch is almost finished, so I merge from > master to make sure my feature doesn't break anything and isn't > broken by development on master. > > . I then merge from the feature branch to master and attempt to push, > but the push is rejected. > > . I then pull --rebase=preserve and push again > > It's the last step that causes trouble, and the "trouble" here is that > commits I merged from master before merging back might be merged again > in the future, if I need for some reason to continue working on that > feature branch again. Thank you for explaining it again. You are right that 'origin/master' won't help you in this case. As soon as you rebase, merge and push, you simply cannot work on your old branch. You have to delete it and set it up anew. If HEAD is your merge commit, this would mean doing git branch -D branchname git branch branchname HEAD^2 (You have to delete with '-D', since Git won't see your non-rebased branch as merged...). This is why I prefer an explicit rebase onto master, as it will not keep the old one lying around. >> But actually, instead of merging master into your feature >> branch, I'd rather recommend rebasing it *onto* master, but explicitly > > That'd lose too much information, so I'd like to avoid that if > possible. What kind of information do you mean here? I'm guessing you want to see the merges from master and how you reacted to them? You're right that this will be lost. >> - If the push fails because there are new commits upstream, instead of >> using 'pull --rebase=preserve', I rather delete the merge so that I >> get a "normal" fast-forward pull and merge again. If I'm really >> unlucky, this new commit from upstream causes a conflict now, in which >> case I usually just resolve it, simply hoping that the push will work >> next time. > > If "merge --no-ff" and aborting the merge when a push is rejected are > to be used anyway, why do I need to rebase the feature branch onto > master? That doesn't seem necessary. I could use normal merges, no? Yes. I do that instead of merging master into my feature branch. I just happen to not like this "merge from trunk" business, and I also prefer to resolve conflicts commit-by-commit. Also, I usually do an interactive rebase to clean up my branch before merging (I usually never get a feature branch "right" the first time). >> look like they were made on another branch, but if I understand you >> correctly now, you mean you don't want to have merge commits from master >> before pushing, but you rather prefer to rebase (to which I agree as >> well). > > I actually don't mind merge commits, as long as they reflect what was > actually done, as opposed to being generated by Git out of thin air. > > What I certainly want to avoid is any kind of rebasing, cherry-picking > or similar things that will then put me at risk of having the same > commits merged again, because the original commits are rewritten or > not recorded in the DAG. OK, let me try to summarize what I think are the two main conflicting requirements: . You want to handle merges of local feature branches and public branches (like 'emacs-24') in the same way. I think this one is the strongest requirement, since it means you simply cannot use 'rebase' in any way. Also, you've pointed out several other problems with 'rebase', like loosing the "real" history of a feature branch, and accidental merging of rebased commits. Therefore, I think a purely merge-based workflow is really the only option for you, which however brings us to . You want to keep a clear history of 'mainline', meaning you want to achieve a similar log view to that from Bazaar, using 'git log --first-parent'. This conflicts with how Git orders the parents of a merge. The first parent is always the tip of the branch you're currently on. And since you do 'git pull' while being on your local master, that will be the first parent. I happen to dislike that about Git as well, but I agree with Stefan that this is not something we should worry about. Probably the easiest way without resorting to rebase you've already said yourself: delete the merge, do a fast-forward pull, merge again. An alternative would be to swap the parents after the merge of a normal 'git pull', but that requires some Git plumbing, which however can be easily scripted. Of course, while *you* can take care in keeping the correct ordering of mainline, others won't do that (I guess most are not even aware of this issue), so I'm afraid you will be greeted with git's usual spaghetti history soon enough. One could implement a git hook that checks for a linear git history of mainline and that rejects pushes otherwise, but I guess Stefan isn't very inclined to agree to that. -David ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-17 20:37 ` David Engster @ 2014-12-18 4:55 ` Stephen J. Turnbull 2014-12-18 15:39 ` Eli Zaretskii 2014-12-18 21:18 ` David Engster 2014-12-18 15:38 ` Eli Zaretskii 1 sibling, 2 replies; 63+ messages in thread From: Stephen J. Turnbull @ 2014-12-18 4:55 UTC (permalink / raw) To: David Engster; +Cc: Eli Zaretskii, emacs-devel David Engster writes: > up anew. If HEAD is your merge commit, this would mean doing > > git branch -D branchname > git branch branchname HEAD^2 > > (You have to delete with '-D', since Git won't see your non-rebased > branch as merged...). Aside: can't you do this in one operation with "git branch -f branchname HEAD^2"? (Real question, I don't understand your reference to "seeing ... branch as merged". The docs seem to indicate it should work.) > > That'd lose too much information, so I'd like to avoid that if > > possible. > > What kind of information do you mean here? I'm guessing you want to see > the merges from master and how you reacted to them? You're right that > this will be lost. I think this is the crucial question. git documents are very good at explaining implementations, but people have a habit of deciding what they think a command does based on its name. That matters a little for Eli, and a lot for GitForEmacsDevs. We really need to see what DAG Eli wants to construct. Then we can see how to create it using primitives, and finally see if there's a reasonable shortcut by using more complex commands and appropriate options (where "reasonable" is defined "Eli feels comfortable with it for the purposes he has in mind" -- we have to ask Eli :-). > OK, let me try to summarize what I think are the two main conflicting > requirements: > > . You want to handle merges of local feature branches and public > branches (like 'emacs-24') in the same way. > > I think this one is the strongest requirement, since it means you simply > cannot use 'rebase' in any way. Also, you've pointed out several other > problems with 'rebase', like loosing the "real" history of a feature > branch, and accidental merging of rebased commits. > > Therefore, I think a purely merge-based workflow is really the only > option for you, which however brings us to > > . You want to keep a clear history of 'mainline', meaning you want to > achieve a similar log view to that from Bazaar, using 'git log > --first-parent'. > > This conflicts with how Git orders the parents of a merge. The first > parent is always the tip of the branch you're currently on. And since > you do 'git pull' while being on your local master, that will be the > first parent. I don't see a conflict here. What I do see is an ambiguity in the discription of entry conditions. If you bzr-think, on a feature branch the "local master" is likely to be the feature branch.[1] That is, the workflow is git clone git:emacs ./feature-1 cd feature-1 emacs file1 ... git commit git pull git:emacs # we've just swapped master and # origin/master, ie, the public mainline, # when we push mainline is nonlinear without actually defining a branch. I agree this is problematic. It's more complex, but if you do git clone git:emacs ./feature-1 cd feature-1 git checkout -b feature-1 emacs file1 ... git commit git pull git:emacs # origin/master contains public mainline # feature-1 contains local mainline To push to public: git checkout master git push # public mainline is preserved git checkout feature-1 # #### these three commands are error-prone AFAICS this is what you need to do for emacs-24, too. The problems are (1) a convenient discipline for those last three commands and (2) recovery from failed push due to concurrent development. I think that one way to provide convenience and discipline would be to (a) require that the feature branch workspace be located in a directory with the same name as the feature branch, and (b) provide git-pull-emacs and git-push-emacs scripts that check for $(basename $cwd) == feature-name as a precondition. I don't know about the failed merge recovery, though. > Of course, while *you* can take care in keeping the correct ordering of > mainline, others won't do that (I guess most are not even aware of this > issue), All bzr fans are aware of it though. It's an important part of Bazaar's identity in VCS space. The problem will be git users who are used to a spaghetti DAG. > One could implement a git hook that checks for a linear git history > of mainline and that rejects pushes otherwise, but I guess Stefan > isn't very inclined to agree to that. My impression is that Stefan is not inclined to encourage work on this problem; he thinks it's a waste of time. I think he'd come around quickly if presented with either another problem that would be solved by the same workflow that preserves linear mainline, or a "sufficiently convenient" workflow that preserves linear mainline. I don't intend to speak for Stefan, just to encourage you to not give up on the idea of a hook before you've clarified the point with him. Footnotes: [1] I think Eli means that in his feature branch workspace he uses a branch named for the feature rather than master, but we need to be clear about this. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-18 4:55 ` Stephen J. Turnbull @ 2014-12-18 15:39 ` Eli Zaretskii 2014-12-18 20:00 ` Steinar Bang 2014-12-18 21:18 ` David Engster 1 sibling, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2014-12-18 15:39 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: deng, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Cc: Eli Zaretskii <eliz@gnu.org>, > emacs-devel@gnu.org > Date: Thu, 18 Dec 2014 13:55:26 +0900 > > > > That'd lose too much information, so I'd like to avoid that if > > > possible. > > > > What kind of information do you mean here? I'm guessing you want to see > > the merges from master and how you reacted to them? You're right that > > this will be lost. > > I think this is the crucial question. git documents are very good at > explaining implementations, but people have a habit of deciding what > they think a command does based on its name. That matters a little > for Eli, and a lot for GitForEmacsDevs. > > We really need to see what DAG Eli wants to construct. The one that would be there if the push from master following a merge from a feature branch succeeded. I hope this is clear enough; if not, please ask more specific questions. > (where "reasonable" is defined "Eli feels comfortable with it > for the purposes he has in mind" -- we have to ask Eli :-). I don't think I've invented something unnatural here. What I'd like is to have a merge-based workflow where the DAG reflects all the merges between 2 branches as they happened in real time. Race conditions interfere with that, but I'd like to resolve that issue in a way that only affects the last merge before the final successful push from the local master to upstream. > > . You want to keep a clear history of 'mainline', meaning you want to > > achieve a similar log view to that from Bazaar, using 'git log > > --first-parent'. > > > > This conflicts with how Git orders the parents of a merge. The first > > parent is always the tip of the branch you're currently on. And since > > you do 'git pull' while being on your local master, that will be the > > first parent. > I don't see a conflict here. What I do see is an ambiguity in the > discription of entry conditions. If you bzr-think, on a feature > branch the "local master" is likely to be the feature branch.[1] That > is, the workflow is > git clone git:emacs ./feature-1 > cd feature-1 > emacs file1 ... > git commit > git pull git:emacs # we've just swapped master and > # origin/master, ie, the public mainline, > # when we push mainline is nonlinear > > without actually defining a branch. This is not how work on a branch happens (and not how it happened with bzr). There's an actual named branch, and changes are merged from there to master, before pushing them. > git clone git:emacs ./feature-1 > cd feature-1 > git checkout -b feature-1 > emacs file1 ... > git commit > git pull git:emacs # origin/master contains public mainline > # feature-1 contains local mainline > To push to public: > git checkout master > git push # public mainline is preserved > git checkout feature-1 # #### these three commands are error-prone > AFAICS this is what you need to do for emacs-24, too. What I do for emacs-24 is similar, but not identical: git clone git:emacs ./emacs-24 cd emacs-24 git checkout emacs-24 <hack, hack> git commit git push cd ../trunk # another clone git checkout master git pull git merge origin/emacs-24 <test, fix problems, commit> git push > The problems are (1) a convenient discipline for those last three > commands What is error-prone about them? > I think that one way to provide convenience and discipline would be > to (a) require that the feature branch workspace be located in a > directory with the same name as the feature branch, and (b) provide > git-pull-emacs and git-push-emacs scripts that check for $(basename > $cwd) == feature-name as a precondition. Sounds complicated, and I'm not sure it's really needed. Local feature branches (unlike emacs-24) don't need to be in a separate directory, because they usually don't diverge from master enough to justify that. What remains is the requirement to be aware of the currently checked-out branch, something that is quite easy both at the shell prompt (where Git instructs Bash to show the branch) and in Emacs. A significant disadvantage of this proposal, at least for me, is that it defines a set of commands and some details of the workflow that are specific to Emacs and not available and/or unneeded in any other project that uses Git. So it gets in the way of a more efficient learning to use Git by combining the experience from other projects. > > One could implement a git hook that checks for a linear git history > > of mainline and that rejects pushes otherwise, but I guess Stefan > > isn't very inclined to agree to that. > > My impression is that Stefan is not inclined to encourage work on this > problem; he thinks it's a waste of time. I think he'd come around > quickly if presented with either another problem that would be solved > by the same workflow that preserves linear mainline, or a > "sufficiently convenient" workflow that preserves linear mainline. But there doesn't appear to be such a sufficiently convenient workflow, not with Git. > [1] I think Eli means that in his feature branch workspace he uses a > branch named for the feature rather than master Of course! ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-18 15:39 ` Eli Zaretskii @ 2014-12-18 20:00 ` Steinar Bang 2014-12-18 20:40 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: Steinar Bang @ 2014-12-18 20:00 UTC (permalink / raw) To: emacs-devel >>>>> Eli Zaretskii <eliz@gnu.org>: > What I do for emacs-24 is similar, but not identical: > git clone git:emacs ./emacs-24 > cd emacs-24 > git checkout emacs-24 > <hack, hack> > git commit > git push > cd ../trunk # another clone > git checkout master > git pull > git merge origin/emacs-24 What I would do here, is: git merge --no-ff --no-commit origin/emacs-24 Then I would inspect the diffs in magit, fix any conflicts, and stage the conflict-fixed files, revert the changes that shouldn't be there (typically version-related stuff, and this is mostly taken care off on the first merge, but it never hurts to check), and then do 'c c' in magit to commit the merge. > <test, fix problems, commit> > git push ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-18 20:00 ` Steinar Bang @ 2014-12-18 20:40 ` Eli Zaretskii 2014-12-19 8:09 ` Steinar Bang 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2014-12-18 20:40 UTC (permalink / raw) To: Steinar Bang; +Cc: emacs-devel > From: Steinar Bang <sb@dod.no> > Date: Thu, 18 Dec 2014 21:00:00 +0100 > > > cd ../trunk # another clone > > git checkout master > > git pull > > git merge origin/emacs-24 > > What I would do here, is: > git merge --no-ff --no-commit origin/emacs-24 > > Then I would inspect the diffs in magit, fix any conflicts, and stage > the conflict-fixed files, revert the changes that shouldn't be there > (typically version-related stuff, and this is mostly taken care off on > the first merge, but it never hurts to check), and then do 'c c' in > magit to commit the merge. > > > <test, fix problems, commit> > > git push Not sure how what you suggest is different, in principle. Why does it matter if I examine the results of a merge before or after I commit it? It's a local commit, and I can always go back if I need to. But I see no reason to assume up front I'd need to back up, since we are talking about a merge from the release branch, not from a development branch. So I have all the reasons to believe the merge will be uneventful, and there will be no conflicts most of the time. Which makes all the precautions like --no-ff and --no-commit unnecessary, I think. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-18 20:40 ` Eli Zaretskii @ 2014-12-19 8:09 ` Steinar Bang 2014-12-19 9:16 ` Eli Zaretskii 0 siblings, 1 reply; 63+ messages in thread From: Steinar Bang @ 2014-12-19 8:09 UTC (permalink / raw) To: emacs-devel >>>>> Eli Zaretskii <eliz@gnu.org>: > Not sure how what you suggest is different, in principle. Not different, just convenient. > Why does it matter if I examine the results of a merge before or after > I commit it? It's a local commit, and I can always go back if I need > to. Yes, of course. But magit's presentation of a staged, but yet uncommitted merge, is a very convenient and keyboard-only way of viewing the merge resuls (a compact representation of new files, for one thing, compared to a diff), and it's easy to fix conflicts, and revert files without leaving emacs. > But I see no reason to assume up front I'd need to back up, since we > are talking about a merge from the release branch, not from a > development branch. So I have all the reasons to believe the merge > will be uneventful, and there will be no conflicts most of the time. Not so much conflicts merging that way, but version number stuff always show up on the first merge, and sometimes later as well (it's good to check). And in emacs' case there has been the ChangeLog stuff (are they autogenerated and not committed these days?). > Which makes all the precautions like --no-ff and --no-commit > unnecessary, I think. I don't do it merging in to my own branches, but I always give published merges a final look-over in this way before pushing them (ie. merges _to_ master and release branches). ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-19 8:09 ` Steinar Bang @ 2014-12-19 9:16 ` Eli Zaretskii 2014-12-19 10:33 ` Steinar Bang 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2014-12-19 9:16 UTC (permalink / raw) To: Steinar Bang; +Cc: emacs-devel > From: Steinar Bang <sb@dod.no> > Date: Fri, 19 Dec 2014 09:09:03 +0100 > > > But I see no reason to assume up front I'd need to back up, since we > > are talking about a merge from the release branch, not from a > > development branch. So I have all the reasons to believe the merge > > will be uneventful, and there will be no conflicts most of the time. > > Not so much conflicts merging that way, but version number stuff always > show up on the first merge, and sometimes later as well (it's good to > check). What do you mean by "version number stuff"? > And in emacs' case there has been the ChangeLog stuff This doesn't cause conflicts most of the time, if you use the git-merge-changelog driver. > > Which makes all the precautions like --no-ff and --no-commit > > unnecessary, I think. > > I don't do it merging in to my own branches, but I always give published > merges a final look-over in this way before pushing them (ie. merges > _to_ master and release branches). Yes, but "git show" before pushing will do it well enough. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-19 9:16 ` Eli Zaretskii @ 2014-12-19 10:33 ` Steinar Bang 0 siblings, 0 replies; 63+ messages in thread From: Steinar Bang @ 2014-12-19 10:33 UTC (permalink / raw) To: emacs-devel >>>>> Eli Zaretskii <eliz@gnu.org>: > What do you mean by "version number stuff"? The version of the package itself (eg. AC_INIT in configure.ac and the line in the README file), and versions of dependencies. Stuff like the AC_INIT line will usually be taken care of in the first merge, however if the configure.ac is changed for some reason on the emacs-24 branch, one should examine the merge results. Git tries to be clever in merges, and usually manages to be so, but I've seen it fail in cases like this (ie. making changes in the file containing a package's version number). And in a staged-but-uncommitted merge in magit, the workflow is simple and emacs-ish: - Edit configure.ac (fix the AC_INIT line and keep the rest) - 'C-x v =' to check the diff - Go back to magit ('q' to close the vc diff, 'C-x b RET' from the source file) the unstaged version of the file ('s' in front of the file) - In magit 'c c' to commit the merge ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-18 4:55 ` Stephen J. Turnbull 2014-12-18 15:39 ` Eli Zaretskii @ 2014-12-18 21:18 ` David Engster 1 sibling, 0 replies; 63+ messages in thread From: David Engster @ 2014-12-18 21:18 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Eli Zaretskii, emacs-devel Stephen J. Turnbull writes: > David Engster writes: > > > up anew. If HEAD is your merge commit, this would mean doing > > > > git branch -D branchname > > git branch branchname HEAD^2 > > > > (You have to delete with '-D', since Git won't see your non-rebased > > branch as merged...). > > Aside: can't you do this in one operation with "git branch -f > branchname HEAD^2"? Yes, thanks. > (Real question, I don't understand your reference > to "seeing ... branch as merged". The docs seem to indicate it should > work.) I posted a script which will set up a few repositories where you can test this: http://article.gmane.org/gmane.emacs.devel/180043 Simply enter the 'ted' repository, do 'git pull --rebase=preserve' and then do 'git branch -d stable'. It won't work. > > This conflicts with how Git orders the parents of a merge. The first > > parent is always the tip of the branch you're currently on. And since > > you do 'git pull' while being on your local master, that will be the > > first parent. > > I don't see a conflict here. What I do see is an ambiguity in the > discription of entry conditions. I don't know what that means. But I can show you how it should *not* look. Simply set up the above test repositories again, now go into 'ted' and do 'git pull', which will merge origin/master. Now do 'git log --first-parent' and you'll see something like this: 82d09a7 Merge branch 'master' of MERGE_REBASE_TEST/upstream 0da1327 merge stable 1f487c9 second commit on master 106847b first commit on master Note how the commit with subject "New commit on master" is not visible anymore, although it was previously (go to 'eli' and type the same log command there, then pull, do it again). AFAIU, this is what Eli wants to avoid. > To push to public: > > git checkout master > git push # public mainline is preserved > git checkout feature-1 # #### these three commands are error-prone > > AFAICS this is what you need to do for emacs-24, too. The problems > are (1) a convenient discipline for those last three commands and (2) > recovery from failed push due to concurrent development. (2) is the problem we are talking about. > > Of course, while *you* can take care in keeping the correct ordering of > > mainline, others won't do that (I guess most are not even aware of this > > issue), > > All bzr fans are aware of it though. There are not many. (FTR, I'm not actually seeing myself as a "bzr fan". I do think however that the bad reputation it got around here was undeserved.) > It's an important part of Bazaar's identity in VCS space. The problem > will be git users who are used to a spaghetti DAG. Yes, as I've written: "most are not aware of this issue". From my experience, many Git users don't even recognize the problem (and when they do, it's usually answered with 'just use gitk', which is kinda sad). > > One could implement a git hook that checks for a linear git history > > of mainline and that rejects pushes otherwise, but I guess Stefan > > isn't very inclined to agree to that. > > My impression is that Stefan is not inclined to encourage work on this > problem; he thinks it's a waste of time. I think he'd come around > quickly if presented with either another problem that would be solved > by the same workflow that preserves linear mainline, or a > "sufficiently convenient" workflow that preserves linear mainline. I > don't intend to speak for Stefan, just to encourage you to not give up > on the idea of a hook before you've clarified the point with him. On further thought, I think such a hook that rejects pushes because of "non-linear mainline" would confuse people to no end. I don't know any project which would do this, and as I've written above, many Git users do not recognize the problem, which makes it hard to fix for them... -David ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-17 20:37 ` David Engster 2014-12-18 4:55 ` Stephen J. Turnbull @ 2014-12-18 15:38 ` Eli Zaretskii 2014-12-18 19:46 ` Steinar Bang 2014-12-18 20:46 ` David Engster 1 sibling, 2 replies; 63+ messages in thread From: Eli Zaretskii @ 2014-12-18 15:38 UTC (permalink / raw) To: David Engster; +Cc: emacs-devel > From: David Engster <deng@randomsample.de> > Cc: emacs-devel@gnu.org > Date: Wed, 17 Dec 2014 21:37:06 +0100 > > >> But actually, instead of merging master into your feature > >> branch, I'd rather recommend rebasing it *onto* master, but explicitly > > > > That'd lose too much information, so I'd like to avoid that if > > possible. > What kind of information do you mean here? I'm guessing you want to see > the merges from master and how you reacted to them? Yes, that's right. > Therefore, I think a purely merge-based workflow is really the only > option for you, which however brings us to > > . You want to keep a clear history of 'mainline', meaning you want to > achieve a similar log view to that from Bazaar, using 'git log > --first-parent'. > > This conflicts with how Git orders the parents of a merge. The first > parent is always the tip of the branch you're currently on. And since > you do 'git pull' while being on your local master, that will be the > first parent. > > I happen to dislike that about Git as well, but I agree with Stefan that > this is not something we should worry about. Probably the easiest way > without resorting to rebase you've already said yourself: delete the > merge, do a fast-forward pull, merge again. But if we follow Stefan and stop worrying about the linearity of mainline, then just "git pull" followed by another push is enough, right? > Of course, while *you* can take care in keeping the correct ordering of > mainline, others won't do that (I guess most are not even aware of this > issue), so I'm afraid you will be greeted with git's usual spaghetti > history soon enough. Again, if we don't care about the mainline being linear, this spaghetti is nothing to worry about, right? It's just a "normal" Git DAG, right? What really worries me about all this is that I _know_ some of the more-or-less veteran contributors do have long-living branches, where they do all their work, and from where they merge to master before pushing. For those people, using "pull --rebase" might be trouble waiting to happen at the most inopportune moment. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-18 15:38 ` Eli Zaretskii @ 2014-12-18 19:46 ` Steinar Bang 2014-12-18 20:35 ` Eli Zaretskii 2014-12-18 20:46 ` David Engster 1 sibling, 1 reply; 63+ messages in thread From: Steinar Bang @ 2014-12-18 19:46 UTC (permalink / raw) To: emacs-devel >>>>> Eli Zaretskii <eliz@gnu.org>: > But if we follow Stefan and stop worrying about the linearity of > mainline, then just "git pull" followed by another push is enough, > right? Yes. > Again, if we don't care about the mainline being linear, this > spaghetti is nothing to worry about, right? It's just a "normal" Git > DAG, right? Yes. > What really worries me about all this is that I _know_ some of the > more-or-less veteran contributors do have long-living branches, where > they do all their work, and from where they merge to master before > pushing. For those people, using "pull --rebase" might be trouble > waiting to happen at the most inopportune moment. Indeed,... unless you can break them of the habit of merging master into the feature branch before merging with master...? If they always merge from the feature branch into master and then push, they will be safe. They can merge back from master after they have successfully pushed master. But the safest will always be not to worry about the linearity of the mainline. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-18 19:46 ` Steinar Bang @ 2014-12-18 20:35 ` Eli Zaretskii 2014-12-19 6:07 ` Yuri Khan 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2014-12-18 20:35 UTC (permalink / raw) To: Steinar Bang; +Cc: emacs-devel > From: Steinar Bang <sb@dod.no> > Date: Thu, 18 Dec 2014 20:46:51 +0100 > > > What really worries me about all this is that I _know_ some of the > > more-or-less veteran contributors do have long-living branches, where > > they do all their work, and from where they merge to master before > > pushing. For those people, using "pull --rebase" might be trouble > > waiting to happen at the most inopportune moment. > > Indeed,... unless you can break them of the habit of merging master into > the feature branch before merging with master...? Unlikely. My take of that workflow is that those people try to keep 'master' pristine, so they won't want to merge there until they are really ready to push; any real work gets done on a branch. > If they always merge from the feature branch into master and then push, > they will be safe. They can merge back from master after they have > successfully pushed master. They must merge from master before the push, to test the merge results. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-18 20:35 ` Eli Zaretskii @ 2014-12-19 6:07 ` Yuri Khan 2014-12-19 7:57 ` Steinar Bang 2014-12-19 9:09 ` Eli Zaretskii 0 siblings, 2 replies; 63+ messages in thread From: Yuri Khan @ 2014-12-19 6:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Steinar Bang, Emacs developers On Fri, Dec 19, 2014 at 2:35 AM, Eli Zaretskii <eliz@gnu.org> wrote: > They must merge from master before the push, to test the merge > results. Why not merge *into* master and test that before pushing? ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-19 6:07 ` Yuri Khan @ 2014-12-19 7:57 ` Steinar Bang 2014-12-19 9:09 ` Eli Zaretskii 1 sibling, 0 replies; 63+ messages in thread From: Steinar Bang @ 2014-12-19 7:57 UTC (permalink / raw) To: emacs-devel >>>>> Yuri Khan <yuri.v.khan@gmail.com>: > On Fri, Dec 19, 2014 at 2:35 AM, Eli Zaretskii <eliz@gnu.org> wrote: >> They must merge from master before the push, to test the merge >> results. > Why not merge *into* master and test that before pushing? My guess would be that they merge in regularily from master or emacs-24, to make sure they stay in sync...? Ie. git checkout my-feature-branch git fetch git merge origin/master <build-and-test> <work-work-work> <new day> git fetch git merge origin/master <build-and-test> <work-work-work> etc. And that's OK, it's only the final merge to master (and subsequent commits) that will be rebased with a pull. So if they do: git checkout master git merge --no-ff my-feature-branch git push <error message> git pull git push the rebased commit will only be on master and not on my-feature-branch (the --no-ff argument to merge, causes git to always create a merge commit, even if the merge is a FF) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-19 6:07 ` Yuri Khan 2014-12-19 7:57 ` Steinar Bang @ 2014-12-19 9:09 ` Eli Zaretskii 1 sibling, 0 replies; 63+ messages in thread From: Eli Zaretskii @ 2014-12-19 9:09 UTC (permalink / raw) To: Yuri Khan; +Cc: sb, emacs-devel > Date: Fri, 19 Dec 2014 13:07:12 +0700 > From: Yuri Khan <yuri.v.khan@gmail.com> > Cc: Steinar Bang <sb@dod.no>, Emacs developers <emacs-devel@gnu.org> > > On Fri, Dec 19, 2014 at 2:35 AM, Eli Zaretskii <eliz@gnu.org> wrote: > > > They must merge from master before the push, to test the merge > > results. > > Why not merge *into* master and test that before pushing? Because they want to keep master pristine, and so do no development at all there. (Please keep in mind that I'm describing what I think is someone else's state of mind, as I gleaned it from their commits in the past. It's not what I do or think.) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-18 15:38 ` Eli Zaretskii 2014-12-18 19:46 ` Steinar Bang @ 2014-12-18 20:46 ` David Engster 1 sibling, 0 replies; 63+ messages in thread From: David Engster @ 2014-12-18 20:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii writes: >> From: David Engster <deng@randomsample.de> >> This conflicts with how Git orders the parents of a merge. The first >> parent is always the tip of the branch you're currently on. And since >> you do 'git pull' while being on your local master, that will be the >> first parent. >> >> I happen to dislike that about Git as well, but I agree with Stefan that >> this is not something we should worry about. Probably the easiest way >> without resorting to rebase you've already said yourself: delete the >> merge, do a fast-forward pull, merge again. > > But if we follow Stefan and stop worrying about the linearity of > mainline, then just "git pull" followed by another push is enough, > right? Yes, that is always safe. >> Of course, while *you* can take care in keeping the correct ordering of >> mainline, others won't do that (I guess most are not even aware of this >> issue), so I'm afraid you will be greeted with git's usual spaghetti >> history soon enough. > > Again, if we don't care about the mainline being linear, this > spaghetti is nothing to worry about, right? It's just a "normal" Git > DAG, right? Yes. > What really worries me about all this is that I _know_ some of the > more-or-less veteran contributors do have long-living branches, where > they do all their work, and from where they merge to master before > pushing. For those people, using "pull --rebase" might be trouble > waiting to happen at the most inopportune moment. Yes, although for local branches, really the worst that can happen is that you merge rebased commits, leading to a duplication of those commits in the history, which might be ugly and confusing, but it actually does no "real" harm. I'm not sure, but I think Git detects that those commits are identical through the patch-id, so you won't get conflicts. Also, you can delete those duplicates with another (interactive) rebase. -David ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-14 16:09 ` Eli Zaretskii ` (2 preceding siblings ...) 2014-12-14 21:40 ` David Engster @ 2014-12-14 22:42 ` Stefan Monnier 2014-12-15 3:37 ` Eli Zaretskii 3 siblings, 1 reply; 63+ messages in thread From: Stefan Monnier @ 2014-12-14 22:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: David Engster, emacs-devel > When I make changes in master, I don't want them to look as if they > were made on some branch when I push them. I think that's a mistake. Emacs's history should be less linear. Stefan ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-14 22:42 ` Stefan Monnier @ 2014-12-15 3:37 ` Eli Zaretskii 2014-12-15 4:46 ` Stefan Monnier 0 siblings, 1 reply; 63+ messages in thread From: Eli Zaretskii @ 2014-12-15 3:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: deng, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: David Engster <deng@randomsample.de>, emacs-devel@gnu.org > Date: Sun, 14 Dec 2014 17:42:42 -0500 > > > When I make changes in master, I don't want them to look as if they > > were made on some branch when I push them. > > I think that's a mistake. Emacs's history should be less linear. Feel free to describe a better workflow in more detail. The "mistaken" one is the basis for what's described on the Wiki, so if we think that should change, we need to know better how to describe it. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-15 3:37 ` Eli Zaretskii @ 2014-12-15 4:46 ` Stefan Monnier 0 siblings, 0 replies; 63+ messages in thread From: Stefan Monnier @ 2014-12-15 4:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: deng, emacs-devel >> > When I make changes in master, I don't want them to look as if they >> > were made on some branch when I push them. >> I think that's a mistake. Emacs's history should be less linear. > Feel free to describe a better workflow in more detail. I'm just saying that "not wanting to make them look as if they were made on a branch" is not something very important. Stefan ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-12 13:24 ` Ted Zlatanov 2014-12-12 14:28 ` Eli Zaretskii @ 2014-12-12 20:46 ` Lars Magne Ingebrigtsen 1 sibling, 0 replies; 63+ messages in thread From: Lars Magne Ingebrigtsen @ 2014-12-12 20:46 UTC (permalink / raw) To: emacs-devel Ted Zlatanov <tzz@lifelogs.com> writes: > It should get merged into master soon. I can attempt another merge of > the emacs-24 branch... with fear :) Oops. I didn't notice that this fix went into the emacs-24 branch, so I removed the `fboundp' checks from the trunk. Which means that trunk doesn't work for people without gnutls support. So if you could do the merge, that would be nice, otherwise I'll have to re-revert those `fboundp' changes again. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: master c6f03ed: Fix a problem in url.el without GnuTLS 2014-12-11 18:08 ` Eli Zaretskii 2014-12-11 23:00 ` Ted Zlatanov @ 2014-12-12 0:30 ` Leo Liu 1 sibling, 0 replies; 63+ messages in thread From: Leo Liu @ 2014-12-12 0:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: larsi, emacs-devel On 2014-12-11 20:08 +0200, Eli Zaretskii wrote: > Because the feature might be available, but inoperable (e.g., if some > underlying library is missing). This happens all the times in the > Windows build, where optional shared libraries are loaded dynamically > only when needed, even though Emacs itself was compiled with support > for that library. We will see more of that once we support some kind > of dynamic modules. I see and thanks for the info. Leo ^ permalink raw reply [flat|nested] 63+ messages in thread
end of thread, other threads:[~2014-12-19 10:33 UTC | newest] Thread overview: 63+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20141211155740.11916.1584@vcs.savannah.gnu.org> [not found] ` <E1Xz67Y-00036o-Vf@vcs.savannah.gnu.org> 2014-12-11 16:47 ` master c6f03ed: Fix a problem in url.el without GnuTLS Leo Liu 2014-12-11 18:08 ` Eli Zaretskii 2014-12-11 23:00 ` Ted Zlatanov 2014-12-12 9:23 ` Eli Zaretskii 2014-12-12 13:24 ` Ted Zlatanov 2014-12-12 14:28 ` Eli Zaretskii 2014-12-12 16:06 ` Stefan Monnier 2014-12-13 0:25 ` Ted Zlatanov 2014-12-13 0:28 ` Lars Magne Ingebrigtsen 2014-12-13 1:25 ` Ted Zlatanov 2014-12-13 8:04 ` Eli Zaretskii 2014-12-13 10:16 ` David Engster 2014-12-18 22:38 ` David Engster 2014-12-19 8:50 ` Eli Zaretskii 2014-12-13 9:04 ` David Engster 2014-12-13 9:50 ` David Engster 2014-12-13 13:19 ` Ted Zlatanov 2014-12-13 14:13 ` David Engster 2014-12-13 14:25 ` Ted Zlatanov 2014-12-13 15:18 ` Eli Zaretskii 2014-12-13 19:44 ` David Engster 2014-12-13 19:59 ` Eli Zaretskii 2014-12-13 22:00 ` Dmitry Gutov 2014-12-14 3:36 ` Eli Zaretskii 2014-12-13 23:13 ` David Engster 2014-12-14 16:09 ` Eli Zaretskii 2014-12-14 16:37 ` Ted Zlatanov 2014-12-14 16:55 ` Eli Zaretskii 2014-12-14 17:00 ` Ted Zlatanov 2014-12-14 23:21 ` Stefan Monnier 2014-12-14 17:46 ` Paul Eggert 2014-12-14 17:50 ` Eli Zaretskii 2014-12-14 18:28 ` Ted Zlatanov 2014-12-14 19:41 ` David Engster 2014-12-14 21:40 ` David Engster 2014-12-15 3:47 ` Eli Zaretskii 2014-12-15 20:39 ` David Engster 2014-12-16 19:42 ` Eli Zaretskii 2014-12-17 9:58 ` Steinar Bang 2014-12-17 10:52 ` Steinar Bang 2014-12-17 15:36 ` Eli Zaretskii 2014-12-17 15:35 ` Eli Zaretskii 2014-12-17 20:37 ` David Engster 2014-12-18 4:55 ` Stephen J. Turnbull 2014-12-18 15:39 ` Eli Zaretskii 2014-12-18 20:00 ` Steinar Bang 2014-12-18 20:40 ` Eli Zaretskii 2014-12-19 8:09 ` Steinar Bang 2014-12-19 9:16 ` Eli Zaretskii 2014-12-19 10:33 ` Steinar Bang 2014-12-18 21:18 ` David Engster 2014-12-18 15:38 ` Eli Zaretskii 2014-12-18 19:46 ` Steinar Bang 2014-12-18 20:35 ` Eli Zaretskii 2014-12-19 6:07 ` Yuri Khan 2014-12-19 7:57 ` Steinar Bang 2014-12-19 9:09 ` Eli Zaretskii 2014-12-18 20:46 ` David Engster 2014-12-14 22:42 ` Stefan Monnier 2014-12-15 3:37 ` Eli Zaretskii 2014-12-15 4:46 ` Stefan Monnier 2014-12-12 20:46 ` Lars Magne Ingebrigtsen 2014-12-12 0:30 ` Leo Liu
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).