* Workflow to accumulate individual changes? @ 2009-12-30 21:34 Juanma Barranquero 2009-12-30 21:37 ` Juanma Barranquero ` (3 more replies) 0 siblings, 4 replies; 97+ messages in thread From: Juanma Barranquero @ 2009-12-30 21:34 UTC (permalink / raw) To: Emacs developers Let's suppose I want to create a local post-23.2 branch where I do want to commit small changes to install on the trunk post-release. I don't want to be forced to create a task branch for every one of them, because they are small changes, and a new branch implies having to bootstrap[1] anew. So I'd like to accumulate the changes into a single branch. Once the trunk is open again, what would be the procedure to install the changes? Obviously not "bzr merge ../post-23.2", because that would create a single [merge] commit. Will I be forced to repeat "bzr log" and "bzr merge --revision=REVID ../post-23.2" for each change? That seems a bit cumbersome. Is there any way to simplify it? Perhaps a plugin? Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-30 21:34 Workflow to accumulate individual changes? Juanma Barranquero @ 2009-12-30 21:37 ` Juanma Barranquero 2009-12-30 21:46 ` Óscar Fuentes ` (2 subsequent siblings) 3 siblings, 0 replies; 97+ messages in thread From: Juanma Barranquero @ 2009-12-30 21:37 UTC (permalink / raw) To: Emacs developers On Wed, Dec 30, 2009 at 22:34, Juanma Barranquero <lekktu@gmail.com> wrote: > bootstrap[1] anew. So I'd like to accumulate the changes into a single I forgot the note, so: [1] What does people do to create new branches and not having to do a full bootstrap? A recursive copy of all *.o and *.elc files in the parent branch? I know there's a plugin that helps with git-style colocated branches, but I'm asking about using normal branches. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-30 21:34 Workflow to accumulate individual changes? Juanma Barranquero 2009-12-30 21:37 ` Juanma Barranquero @ 2009-12-30 21:46 ` Óscar Fuentes 2009-12-30 23:57 ` Juanma Barranquero 2009-12-30 22:54 ` Giorgos Keramidas 2010-01-01 12:33 ` Stephen J. Turnbull 3 siblings, 1 reply; 97+ messages in thread From: Óscar Fuentes @ 2009-12-30 21:46 UTC (permalink / raw) To: emacs-devel Juanma Barranquero <lekktu@gmail.com> writes: > Let's suppose I want to create a local post-23.2 branch where I do > want to commit small changes to install on the trunk post-release. I > don't want to be forced to create a task branch for every one of them, > because they are small changes, and a new branch implies having to > bootstrap[1] anew. So I'd like to accumulate the changes into a single > branch. > > Once the trunk is open again, what would be the procedure to install > the changes? Obviously not "bzr merge ../post-23.2", because that > would create a single [merge] commit. Will I be forced to repeat "bzr > log" and "bzr merge --revision=REVID ../post-23.2" for each change? > That seems a bit cumbersome. Is there any way to simplify it? Perhaps > a plugin? *IF* they are small changes, i.e., the sort of things that you would do on the quickfixes branch, *AND* if you didn't merge with trunk, this should work keeping the history nice: <hack> bzr commit <hack> bzr commit ... <when post-release arrives>: bzr rebase bzr push The resulting history on upstream will be linear, as if you committed each change one by one on top of the previous one. -- Óscar ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-30 21:46 ` Óscar Fuentes @ 2009-12-30 23:57 ` Juanma Barranquero 2009-12-31 0:21 ` Óscar Fuentes ` (2 more replies) 0 siblings, 3 replies; 97+ messages in thread From: Juanma Barranquero @ 2009-12-30 23:57 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel On Wed, Dec 30, 2009 at 22:46, Óscar Fuentes <ofv@wanadoo.es> wrote: > *IF* they are small changes, i.e., the sort of things that you would do > on the quickfixes branch, *AND* if you didn't merge with trunk, this > should work keeping the history nice: > > <hack> > bzr commit > <hack> > bzr commit > ... > <when post-release arrives>: > bzr rebase > bzr push > > The resulting history on upstream will be linear, as if you committed > each change one by one on top of the previous one. If my post-23.2 branch is branched from my local trunk mirror, will "bzr push" push to it? Will that work when trunk is a bound branch? Or are you suggesting branching post-23.2 from bzr.savannah.gnu.org/srv/bzr/emacs/trunk? Anyway, after thinking about the issue, I'm not sure it'd work, because of ChangeLog. cd emacs branch trunk post-23.2 cd post-23.2 # hack hack hack, including editing ChangeLog # days pass # 23.2 released cd ../trunk bzr update cd ../post-23.2 bzr rebase bzr push # ugh # dates in ChangeLog are wrong, so you need an additional commit to fix the ChangeLog entries so it only really works for fixes that do not need ChangeLog entries. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-30 23:57 ` Juanma Barranquero @ 2009-12-31 0:21 ` Óscar Fuentes 2009-12-31 0:27 ` Juanma Barranquero 2009-12-31 1:04 ` Óscar Fuentes 2010-01-01 13:53 ` Stephen J. Turnbull 2 siblings, 1 reply; 97+ messages in thread From: Óscar Fuentes @ 2009-12-31 0:21 UTC (permalink / raw) To: emacs-devel Juanma Barranquero <lekktu@gmail.com> writes: > On Wed, Dec 30, 2009 at 22:46, Óscar Fuentes <ofv@wanadoo.es> wrote: > >> *IF* they are small changes, i.e., the sort of things that you would do >> on the quickfixes branch, *AND* if you didn't merge with trunk, this >> should work keeping the history nice: >> >> <hack> >> bzr commit >> <hack> >> bzr commit >> ... >> <when post-release arrives>: >> bzr rebase >> bzr push >> >> The resulting history on upstream will be linear, as if you committed >> each change one by one on top of the previous one. > > If my post-23.2 branch is branched from my local trunk mirror, will > "bzr push" push to it? You can provide a location: bzr rebase URL bzr push URL > Will that work when trunk is a bound branch? I do not recommend using your local mirror for that. > Or are you suggesting branching post-23.2 from > bzr.savannah.gnu.org/srv/bzr/emacs/trunk? No, you can branch from your local mirror if you wish (and why not?). Remember that a branch is an autonomous identity that can communicate with any other branch. > Anyway, after thinking about the issue, I'm not sure it'd work, > because of ChangeLog. [snip] > so it only really works for fixes that do not need ChangeLog entries. Yup. This requires editing before sending upstream, so the most you can do is to use a bzr branch as a patch depot. Other option for having a patch depot is to use `bzr shelve', then when you can commit unshelve each change separately, edit Changelog, commit it... It seems as feature abuse to me, but it can be manageable if the amount of changes is small and don't overlap. -- Óscar ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 0:21 ` Óscar Fuentes @ 2009-12-31 0:27 ` Juanma Barranquero 0 siblings, 0 replies; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 0:27 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel On Thu, Dec 31, 2009 at 01:21, Óscar Fuentes <ofv@wanadoo.es> wrote: > You can provide a location: > > bzr rebase URL > bzr push URL [...] > No, you can branch from your local mirror if you wish (and why > not?). Remember that a branch is an autonomous identity that can > communicate with any other branch. I understand that. I though you were saying that "bzr push" (without URL) would work in this case. > Yup. This requires editing before sending upstream, so the most you can > do is to use a bzr branch as a patch depot. Yes, I see :( Well, it's still better than having to branch for each small change. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-30 23:57 ` Juanma Barranquero 2009-12-31 0:21 ` Óscar Fuentes @ 2009-12-31 1:04 ` Óscar Fuentes 2009-12-31 1:33 ` Juanma Barranquero 2010-01-01 13:53 ` Stephen J. Turnbull 2 siblings, 1 reply; 97+ messages in thread From: Óscar Fuentes @ 2009-12-31 1:04 UTC (permalink / raw) To: emacs-devel Juanma Barranquero <lekktu@gmail.com> writes: > Anyway, after thinking about the issue, I'm not sure it'd work, > because of ChangeLog. [snip] > # dates in ChangeLog are wrong, so you need an additional commit to > fix the ChangeLog entries > > so it only really works for fixes that do not need ChangeLog entries. Thinking a bit more about this... `rebase' stops if it finds conflicts, then you need to resolve the conflicts (i.e. edit the conflicted changes) and continue the rebase. If somehow the rebase finds a conflict on the ChangeLog for every rebased revision, you could fix the dates. I know by experience that Subversion generates a conflict every time two changes append lines to a file. If bzr generates a conflict when two changes happen at the top of the ChangeLog file, you could arrange things for this to happen: the first revision should conflict right away; for the second revision to conflict, you'll need to leave the top of the ChangeLog on a way that it can't merge the second revision, etc. -- Óscar ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 1:04 ` Óscar Fuentes @ 2009-12-31 1:33 ` Juanma Barranquero 2009-12-31 1:48 ` Óscar Fuentes 2009-12-31 4:21 ` Eli Zaretskii 0 siblings, 2 replies; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 1:33 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel On Thu, Dec 31, 2009 at 02:04, Óscar Fuentes <ofv@wanadoo.es> wrote: > If somehow the rebase finds a conflict on the ChangeLog for every > rebased revision, you could fix the dates. I know by experience that > Subversion generates a conflict every time two changes append lines to a > file. If bzr generates a conflict when two changes happen at the top of > the ChangeLog file, you could arrange things for this to happen: the > first revision should conflict right away; for the second revision to > conflict, you'll need to leave the top of the ChangeLog on a way that it > can't merge the second revision, etc. I'd rather have Bazaar not to generate a conflict for changes at the top of the file; it's common enough, and I've had my share of them on CVS :-) That said, what you propose could work, but of course it's quite hackish. Let's hope someday the rebase plugin will grow an option to rebase interactively, stopping before the commit. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 1:33 ` Juanma Barranquero @ 2009-12-31 1:48 ` Óscar Fuentes 2009-12-31 2:22 ` Juanma Barranquero 2009-12-31 4:21 ` Eli Zaretskii 1 sibling, 1 reply; 97+ messages in thread From: Óscar Fuentes @ 2009-12-31 1:48 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel Juanma Barranquero <lekktu@gmail.com> writes: >> If somehow the rebase finds a conflict on the ChangeLog for every >> rebased revision, you could fix the dates. I know by experience that >> Subversion generates a conflict every time two changes append lines to a >> file. If bzr generates a conflict when two changes happen at the top of >> the ChangeLog file, you could arrange things for this to happen: the >> first revision should conflict right away; for the second revision to >> conflict, you'll need to leave the top of the ChangeLog on a way that it >> can't merge the second revision, etc. > > I'd rather have Bazaar not to generate a conflict for changes at the > top of the file; it's common enough, and I've had my share of them on > CVS :-) > > That said, what you propose could work, but of course it's quite > hackish. It works and yes, it is hackish :-) Just make sure that after every conflict resolve the first line of the ChangeLog differs from the first line of the next revision. > Let's hope someday the rebase plugin will grow an option to > rebase interactively, stopping before the commit. There is a big chance that adding that feature is very easy, and plugins are not under the very strict development policy of Bazaar, so submit a feature request to the plugin tracker: https://launchpad.net/bzr-rewrite -- Óscar ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 1:48 ` Óscar Fuentes @ 2009-12-31 2:22 ` Juanma Barranquero 0 siblings, 0 replies; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 2:22 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel On Thu, Dec 31, 2009 at 02:48, Óscar Fuentes <ofv@wanadoo.es> wrote: > It works and yes, it is hackish :-) Just make sure that after every > conflict resolve the first line of the ChangeLog differs from the first > line of the next revision. Well, I'll give it a try. Thanks for looking into it. > so submit a > feature request to the plugin tracker: > > https://launchpad.net/bzr-rewrite Will do right now. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 1:33 ` Juanma Barranquero 2009-12-31 1:48 ` Óscar Fuentes @ 2009-12-31 4:21 ` Eli Zaretskii 2009-12-31 4:36 ` Juanma Barranquero 2009-12-31 5:06 ` Óscar Fuentes 1 sibling, 2 replies; 97+ messages in thread From: Eli Zaretskii @ 2009-12-31 4:21 UTC (permalink / raw) To: Juanma Barranquero; +Cc: ofv, emacs-devel > From: Juanma Barranquero <lekktu@gmail.com> > Date: Thu, 31 Dec 2009 02:33:39 +0100 > Cc: emacs-devel@gnu.org > > That said, what you propose could work, but of course it's quite > hackish. Let's hope someday the rebase plugin will grow an option to > rebase interactively, stopping before the commit. Except that most experts on bzr I've read say rebasing is the wrong way to go[1]. So I think we should not flee to that corner so easily, upon bumping on the first problematic issue. ChangeLog files will present a problem for feature branches and quick-fix branches alike. Though an annoyance, I don't see how it is a problem significant enough to recommend rebase as the main vehicle of routine work, given the downside of rebasing (rewriting history etc.). Am I missing something? --------------- [1] http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 4:21 ` Eli Zaretskii @ 2009-12-31 4:36 ` Juanma Barranquero 2009-12-31 5:12 ` Miles Bader 2009-12-31 10:44 ` Eli Zaretskii 2009-12-31 5:06 ` Óscar Fuentes 1 sibling, 2 replies; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 4:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, emacs-devel On Thu, Dec 31, 2009 at 05:21, Eli Zaretskii <eliz@gnu.org> wrote: > Except that most experts on bzr I've read say rebasing is the wrong > way to go[1]. Personally, and with all due respect, I don't consider this: "There are many theoretical objections to rebasing, and I won’t rehash them here. There’s general consensus that rebasing is sort of icky." as a sort of expert opinion, just biased. People used to git's rebase find it extremely useful. And, in fact, this other bit: > “Why isn’t rebase support in core?” Rebase support is currently packaged > as a plugin. This plugin is widely distributed, even in the standard Mac OS > X installation bundle. isn't exactly true anymore, as it is also included at least in the standard Windows standalone installation. > So I think we should not flee to that corner so easily, > upon bumping on the first problematic issue. We're not fleeing into any corner. Weren't I thinking that ChangeLog present problems that should be discussed, I wouldn't have brought the issue. > ChangeLog files will present a problem for feature branches and > quick-fix branches alike. Though an annoyance, I don't see how it is > a problem significant enough to recommend rebase as the main vehicle > of routine work, given the downside of rebasing (rewriting history > etc.). > > Am I missing something? Yes. Neither of us is "recommending rebase as the main vehicle of routine work". I was talking very specifically of a workflow I intend to use, but I have no idea how common it'll be for other people; and for my use, an interactive rebase would be a perfect option. I wouldn't dream of suggest Karl to discuss rebase on BzrForEmacsDevs, for example. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 4:36 ` Juanma Barranquero @ 2009-12-31 5:12 ` Miles Bader 2009-12-31 10:15 ` Eli Zaretskii 2009-12-31 10:44 ` Eli Zaretskii 1 sibling, 1 reply; 97+ messages in thread From: Miles Bader @ 2009-12-31 5:12 UTC (permalink / raw) To: Juanma Barranquero; +Cc: ofv, Eli Zaretskii, emacs-devel Juanma Barranquero <lekktu@gmail.com> writes: >> Except that most experts on bzr I've read say rebasing is the wrong >> way to go[1]. > > Personally, and with all due respect, I don't consider this: "There > are many theoretical objections to rebasing, and I won’t rehash them > here. There’s general consensus that rebasing is sort of icky." as a > sort of expert opinion, just biased. People used to git's rebase find > it extremely useful. Yup. Rebasing rocks, especially interactive rebasing. To be honest, a huge amount of bzr docs and commentary seems to be essentially bzr apologia trying to compensate for technical failings in bzr by saying "ok, so bzr doesn't do that as well as the competition, but you didn't really want to do that anyway... trust us..." -Miles -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- Donald Knuth ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 5:12 ` Miles Bader @ 2009-12-31 10:15 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2009-12-31 10:15 UTC (permalink / raw) To: Miles Bader; +Cc: ofv, lekktu, emacs-devel > From: Miles Bader <miles@gnu.org> > Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org > Reply-To: Miles Bader <miles@gnu.org> > System-Type: x86_64-unknown-linux-gnu > Date: Thu, 31 Dec 2009 14:12:15 +0900 > > To be honest, a huge amount of bzr docs and commentary seems to be > essentially bzr apologia trying to compensate for technical failings in > bzr by saying "ok, so bzr doesn't do that as well as the competition, > but you didn't really want to do that anyway... trust us..." Except that not only the documentation says that, the most active bzr developers say that as well. Maybe you know enough about bzr to decide that it's FUD or cheap marketing, but I'm willing to try the recommended way first, before I decide otherwise based on problems I bump into (if and when). ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 4:36 ` Juanma Barranquero 2009-12-31 5:12 ` Miles Bader @ 2009-12-31 10:44 ` Eli Zaretskii 2009-12-31 12:37 ` Juanma Barranquero 1 sibling, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2009-12-31 10:44 UTC (permalink / raw) To: Juanma Barranquero; +Cc: ofv, emacs-devel From: Eli Zaretskii <eliz@gnu.org> To: Juanma Barranquero <lekktu@gmail.com> CC: ofv@wanadoo.es, emacs-devel@gnu.org In-reply-to: <f7ccd24b0912302036y51436f47p164fe640f926cfb7@mail.gmail.com> (message from Juanma Barranquero on Thu, 31 Dec 2009 05:36:30 +0100) Subject: Re: Workflow to accumulate individual changes? Reply-to: Eli Zaretskii <eliz@gnu.org> References: <f7ccd24b0912301334u6df4cf24k7625713ba8e4252@mail.gmail.com> <87fx6sm8yl.fsf@telefonica.net> <f7ccd24b0912301557s7e40ab26h8ee88c630757c1ce@mail.gmail.com> <873a2slzrr.fsf@telefonica.net> <f7ccd24b0912301733k510c6bbaub97223dcf2565055@mail.gmail.com> <83ws03db8v.fsf@gnu.org> <f7ccd24b0912302036y51436f47p164fe640f926cfb7@mail.gmail.com> --text follows this line-- > From: Juanma Barranquero <lekktu@gmail.com> > Date: Thu, 31 Dec 2009 05:36:30 +0100 > Cc: ofv@wanadoo.es, emacs-devel@gnu.org > > Personally, and with all due respect, I don't consider this: "There > are many theoretical objections to rebasing, and I won’t rehash them > here. There’s general consensus that rebasing is sort of icky." as a > sort of expert opinion, just biased. Me neither. I'm talking about the rest of the reasons, which _are_ described in detail. > People used to git's rebase find it extremely useful. I don't know anything about git, so I cannot talk about this. Just remember that Stephen pointed to a posting by Linus who very eloquently explained how rebasing is a bad idea in at least one situation. > Weren't I thinking that ChangeLog present problems that should be > discussed, I wouldn't have brought the issue. If ChangeLog maintenance is such a big problem, I think we should resolve it here and now. Otherwise, it's a tail wagging the dog. > > ChangeLog files will present a problem for feature branches and > > quick-fix branches alike. Though an annoyance, I don't see how it is > > a problem significant enough to recommend rebase as the main vehicle > > of routine work, given the downside of rebasing (rewriting history > > etc.). > > > > Am I missing something? > > Yes. Neither of us is "recommending rebase as the main vehicle of > routine work". I was talking very specifically of a workflow I intend > to use, but I have no idea how common it'll be for other people; and > for my use, an interactive rebase would be a perfect option. I > wouldn't dream of suggest Karl to discuss rebase on BzrForEmacsDevs, > for example. ChangeLog's are part of everyone's workflow (unless we decide to stop using them). If we think ChangeLog's are causing significant inconveniences that are not addressed in the recommended workflow, and if rebasing is the recommended solution for that, then we had better address these issues now, and by all means mention them on the wiki. IOW, what annoys Juanma Barranquero, will probably annoy a few more, so I would not dismiss that as Juanma's private problems whose solution concerns no one but Juanma ;-) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 10:44 ` Eli Zaretskii @ 2009-12-31 12:37 ` Juanma Barranquero 2009-12-31 19:44 ` Karl Fogel 0 siblings, 1 reply; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 12:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, emacs-devel On Thu, Dec 31, 2009 at 11:44, Eli Zaretskii <eliz@gnu.org> wrote: > Me neither. I'm talking about the rest of the reasons, which _are_ > described in detail. Please! The document does not show real arguments against rebase, just "questions about the necessity of rebasing in typical workflows", from the perspective of people who do not have or like rebase. For the opposite perspective, just look for a few happy git users. > I don't know anything about git, so I cannot talk about this. Just > remember that Stephen pointed to a posting by Linus who very > eloquently explained how rebasing is a bad idea in at least one > situation. Of course. Every user of rebase knows that: you shouldn't rebase a public branch (and even that is OK in cases where the users know that rebasing will be done). But here we were discussing *private* rebasing. > If ChangeLog maintenance is such a big problem, I think we should > resolve it here and now. Otherwise, it's a tail wagging the dog. Not a big problem, a small but repeated inconvencience. > IOW, what annoys Juanma Barranquero, will probably annoy a few more, > so I would not dismiss that as Juanma's private problems whose > solution concerns no one but Juanma ;-) Well, I can agree with that if you can agree that perhaps rebase *could be* the best fix after all... ;-) Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 12:37 ` Juanma Barranquero @ 2009-12-31 19:44 ` Karl Fogel 2009-12-31 20:16 ` Eli Zaretskii ` (3 more replies) 0 siblings, 4 replies; 97+ messages in thread From: Karl Fogel @ 2009-12-31 19:44 UTC (permalink / raw) To: Juanma Barranquero; +Cc: ofv, Eli Zaretskii, emacs-devel Juanma Barranquero <lekktu@gmail.com> writes: >> IOW, what annoys Juanma Barranquero, will probably annoy a few more, >> so I would not dismiss that as Juanma's private problems whose >> solution concerns no one but Juanma ;-) > >Well, I can agree with that if you can agree that perhaps rebase >*could be* the best fix after all... ;-) I've never used 'bzr rebase', and have no competency to evaluate the arguments either way here, but... wouldn't something would smell fishy if rebase were part of our regular workflow? That somehow seems wrong. If we find we're about to recommend that, please ask on the Bazaar list first (maybe you have already). ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 19:44 ` Karl Fogel @ 2009-12-31 20:16 ` Eli Zaretskii 2009-12-31 20:41 ` Juanma Barranquero ` (2 subsequent siblings) 3 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2009-12-31 20:16 UTC (permalink / raw) To: Karl Fogel; +Cc: ofv, lekktu, emacs-devel > From: Karl Fogel <kfogel@red-bean.com> > Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org > Date: Thu, 31 Dec 2009 14:44:51 -0500 > > I've never used 'bzr rebase', and have no competency to evaluate the > arguments either way here, but... wouldn't something would smell fishy > if rebase were part of our regular workflow? That somehow seems wrong. I originally thought this was the case, but I was mistaken; see Óscar's message just now. It is for a situation that hopefully will not happen too often for too many. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 19:44 ` Karl Fogel 2009-12-31 20:16 ` Eli Zaretskii @ 2009-12-31 20:41 ` Juanma Barranquero 2010-01-01 2:54 ` Richard Stallman 2010-01-01 13:49 ` Stephen J. Turnbull 3 siblings, 0 replies; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 20:41 UTC (permalink / raw) To: Karl Fogel; +Cc: ofv, Eli Zaretskii, emacs-devel On Thu, Dec 31, 2009 at 20:44, Karl Fogel <kfogel@red-bean.com> wrote: > I've never used 'bzr rebase', and have no competency to evaluate the > arguments either way here, but... wouldn't something would smell fishy > if rebase were part of our regular workflow? Only if you have a priori bias that rebase smells funny. But anyhow, I don't think anyone is proposing rebase as part of the regular workflow. I wasn't. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 19:44 ` Karl Fogel 2009-12-31 20:16 ` Eli Zaretskii 2009-12-31 20:41 ` Juanma Barranquero @ 2010-01-01 2:54 ` Richard Stallman 2010-01-01 12:35 ` Stephen J. Turnbull 2010-01-01 13:49 ` Stephen J. Turnbull 3 siblings, 1 reply; 97+ messages in thread From: Richard Stallman @ 2010-01-01 2:54 UTC (permalink / raw) To: Karl Fogel; +Cc: ofv, lekktu, eliz, emacs-devel I've never used 'bzr rebase', and have no competency to evaluate the arguments either way here, but... wouldn't something would smell fishy if rebase were part of our regular workflow? That somehow seems wrong. Are you saying that hackers who rebase can get addicted? ;-). ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 2:54 ` Richard Stallman @ 2010-01-01 12:35 ` Stephen J. Turnbull 0 siblings, 0 replies; 97+ messages in thread From: Stephen J. Turnbull @ 2010-01-01 12:35 UTC (permalink / raw) To: rms; +Cc: Karl Fogel, ofv, eliz, emacs-devel, lekktu Richard Stallman writes: > I've never used 'bzr rebase', and have no competency to evaluate the > arguments either way here, but... wouldn't something would smell fishy > if rebase were part of our regular workflow? That somehow seems wrong. > > Are you saying that hackers who rebase can get addicted? ;-). There's plenty of examples! ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 19:44 ` Karl Fogel ` (2 preceding siblings ...) 2010-01-01 2:54 ` Richard Stallman @ 2010-01-01 13:49 ` Stephen J. Turnbull 3 siblings, 0 replies; 97+ messages in thread From: Stephen J. Turnbull @ 2010-01-01 13:49 UTC (permalink / raw) To: Karl Fogel; +Cc: ofv, Juanma Barranquero, Eli Zaretskii, emacs-devel Karl Fogel writes: > Juanma Barranquero <lekktu@gmail.com> writes: > >Well, I can agree with that if you can agree that perhaps rebase > >*could be* the best fix after all... ;-) > > I've never used 'bzr rebase', and have no competency to evaluate the > arguments either way here, but... wouldn't something would smell fishy > if rebase were part of our regular workflow? That somehow seems wrong. No, it's a matter of style. Let me summarize: 1. Everybody agrees that rebasing a branch which is not 100% private is problematic. 2. Some people like rebasing private branches before pushing them, basically because it makes the history more linear. (git people generally do.) Making the history more linear often makes bisection more effective, because (except for the initial graft) the patches tend to be smaller and localize the defect better. 3. Some people dislike rebasing private branches, because it makes the history more linear. (bzr people generally do.) There are two reasons typically given: a. Work done concurrently is "misrepresented" as being sequential. I suspect these people generally have an intuition of b, but don't express it that way. b. It's easy to think that all commits have properly tested because all commits on each (original) branch and the tip have been tested, but that is false. In fact, all commits between the graft point and the tip need to be retested. Of course, "need" is assuming a "test every commit" discipline. There's a reason that is not typically given, too. c. In some DVCSes, rebase destroys history. It is in general not possible to recover the original branch from a rebase given only the "after" DAG. In bzr a rebase makes recovering the original branch a task for someone familiar with the internals. (It may even be impossible in some cases, I don't know enough about the internals to say.) If it's not obvious, let me state that I am biased toward the pro-rebase side. But that's a matter of taste. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 4:21 ` Eli Zaretskii 2009-12-31 4:36 ` Juanma Barranquero @ 2009-12-31 5:06 ` Óscar Fuentes 2009-12-31 10:26 ` Eli Zaretskii 2009-12-31 18:27 ` Eli Zaretskii 1 sibling, 2 replies; 97+ messages in thread From: Óscar Fuentes @ 2009-12-31 5:06 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> That said, what you propose could work, but of course it's quite >> hackish. Let's hope someday the rebase plugin will grow an option to >> rebase interactively, stopping before the commit. > > Except that most experts on bzr I've read say rebasing is the wrong > way to go[1]. It often is. In *this* case it is not wrong nor right. It is just what does the job. Please note the big IFs in my answer to Juanma. > So I think we should not flee to that corner so easily, upon bumping > on the first problematic issue. Agreed. If anyone thinks that rebase it the solution for his problem, please ask here first. > ChangeLog files will present a problem for feature branches and > quick-fix branches alike. Very true. On Juanma's case, if he accumulated a signicant number of small changes, rebasing can save quite a bit of work compared to creating a patch, applying it, re-writing a commit message and commit for each change. Or merging one change, edit the ChangeLog, write the commit message, commit and repeat for the next change (which possibly is the most orthodox solution and recommendable if the amount of changes is moderate.) > Though an annoyance, I don't see how it is a problem significant > enough to recommend rebase as the main vehicle of routine work, given > the downside of rebasing (rewriting history etc.). The history is rewritten at Juanma's end. For the rest of users, the final result is indistinguishable of the case where Juanma commits a series of small changes on a fast sequence. > Am I missing something? Yes. That `goto' is evil but sometimes it has its uses :-) I concede that rebase here can be questionable as the most efficient or dumb-proof solution (you have to be very careful or the whole process can be ruined and repeated; it is strongly advised to backup your branch first.) The ChangeLog is a big incovenience for working locally while upstream access is restricted. I hope that after some time, people will experience the fact that a ChangeLog is completely redundant on a changeset-based VCS. -- Óscar ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 5:06 ` Óscar Fuentes @ 2009-12-31 10:26 ` Eli Zaretskii 2009-12-31 12:28 ` Juanma Barranquero 2009-12-31 18:27 ` Eli Zaretskii 1 sibling, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2009-12-31 10:26 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: =?utf-8?Q?=C3=93scar_Fuentes?= <ofv@wanadoo.es> > Date: Thu, 31 Dec 2009 06:06:51 +0100 > > > ChangeLog files will present a problem for feature branches and > > quick-fix branches alike. > > Very true. On Juanma's case, if he accumulated a signicant number of > small changes, rebasing can save quite a bit of work compared to > creating a patch, applying it, re-writing a commit message and commit > for each change. Or merging one change, edit the ChangeLog, write the > commit message, commit and repeat for the next change (which possibly is > the most orthodox solution and recommendable if the amount of changes is > moderate.) It's an annoyance, yes, but not a large one. After all, you have everything right there in the same Emacs session. How hard is it to reorder a few log entries? > > Though an annoyance, I don't see how it is a problem significant > > enough to recommend rebase as the main vehicle of routine work, given > > the downside of rebasing (rewriting history etc.). > > The history is rewritten at Juanma's end. For the rest of users, the > final result is indistinguishable of the case where Juanma commits a > series of small changes on a fast sequence. Unless I misunderstood what I've read, that's not accurate: the final result _will_ matter for others, if and when those others will want at some point in the future to dig into Juanma's changes and understand how the final code came into existence -- which parts of it were written by Juanma, which ones by others, and which ones are result of bzr merges. In fact, Juanma himself may wish to do this kind of archeology some time after committing. > The ChangeLog is a big incovenience for working locally while upstream > access is restricted. In my work on bidi Emacs, I keep a separate ChangeLog file precisely for that reason. With CVS, it was simply an unversioned file. With bzr, I will probably have it committed to my local branch, but will delete it after copying (some of) its contents to the upstream logs when the feature is merged with upstream. If someone has a better idea for a long-term feature branch, I'm all ears. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 10:26 ` Eli Zaretskii @ 2009-12-31 12:28 ` Juanma Barranquero 0 siblings, 0 replies; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 12:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel On Thu, Dec 31, 2009 at 11:26, Eli Zaretskii <eliz@gnu.org> wrote: > Unless I misunderstood what I've read, that's not accurate: the final > result _will_ matter for others, if and when those others will want at > some point in the future to dig into Juanma's changes and understand > how the final code came into existence -- which parts of it were > written by Juanma, which ones by others, and which ones are result of > bzr merges. In fact, Juanma himself may wish to do this kind of > archeology some time after committing. No. We're discussing small patches, every one of them a single commit, all of them unrelated. Once I push the changes, the past is irrelevant. My using a private branch and rebase would be utterly indistinguishable of my having developed and committed each one on the trunk/ (as some are suggesting for such quickfixes). rebase is a tool to keep private history private, and public history clean. Nothing more, nothing less. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 5:06 ` Óscar Fuentes 2009-12-31 10:26 ` Eli Zaretskii @ 2009-12-31 18:27 ` Eli Zaretskii 2009-12-31 18:59 ` Óscar Fuentes 2009-12-31 20:39 ` Juanma Barranquero 1 sibling, 2 replies; 97+ messages in thread From: Eli Zaretskii @ 2009-12-31 18:27 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar_Fuentes <ofv@wanadoo.es> > Date: Thu, 31 Dec 2009 06:06:51 +0100 > > If anyone thinks that rebase it the solution for his problem, please > ask here first. So what problem was it in this case, for which rebase is a solution? Is it the case of a number of small unrelated changes that somehow accumulated in the local branch? Or is it something else? It cannot be a single coherent change, because for that, we still think the workflow described on the wiki for the quickfixes branch is the recommended way to go, right? ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 18:27 ` Eli Zaretskii @ 2009-12-31 18:59 ` Óscar Fuentes 2009-12-31 20:39 ` Juanma Barranquero 1 sibling, 0 replies; 97+ messages in thread From: Óscar Fuentes @ 2009-12-31 18:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> If anyone thinks that rebase it the solution for his problem, please >> ask here first. > > So what problem was it in this case, for which rebase is a solution? It was considered as a hack for editing the ChangeLog dates of old local commits before sending them upstream. > Is it the case of a number of small unrelated changes that somehow > accumulated in the local branch? Yes, it is about sending upstream a series of small changes that you accumulated on a branch (because you had no net access of because commits to upstream were temporarily restricted for whatever reason.) There are two problems with this: first, merging the ChangeLog entries correctly (mainly updating dates) and second, not having to merge and commit all those changes one by one. If you agree that the quickfixes->merge-to-trunk->commit workflow is the right thing, you don't need rebase here: you have to merge and commit to upstream each change individually and you can edit the ChangeLog at that point. If you think that having to merge a small change is an unnecessary burden and prefer to commit directly to upstream, rebase is the solution but the ChangeLog is on the way forcing you to resort to a hack for editing it. If it no were ChangeLog, sending upstream that series of small changes would need just two commands (rebase & push). The general issue here is the impact the ChangeLog has on off-line working, including into the concept of off-line feature branches that live for more than a day. [snip] -- Óscar ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 18:27 ` Eli Zaretskii 2009-12-31 18:59 ` Óscar Fuentes @ 2009-12-31 20:39 ` Juanma Barranquero 1 sibling, 0 replies; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 20:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel On Thu, Dec 31, 2009 at 19:27, Eli Zaretskii <eliz@gnu.org> wrote: > So what problem was it in this case, for which rebase is a solution? > Is it the case of a number of small unrelated changes that somehow > accumulated in the local branch? Yes. Not that "somehow accumulate", but that I want to accumulate, because I don't want to have to branch (and bootstrap) ten times for ten different small patches that cannot be committed before the release. FWIW, I *don't* have currently ten such commits, just one or two; but I'm not very inclined to branch just to remember to change "(defun xxx-mode () ...)" to "(define-derived-mode xxx-mode ...)" in a few weeks/months. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-30 23:57 ` Juanma Barranquero 2009-12-31 0:21 ` Óscar Fuentes 2009-12-31 1:04 ` Óscar Fuentes @ 2010-01-01 13:53 ` Stephen J. Turnbull 2010-01-01 14:38 ` Eli Zaretskii 2 siblings, 1 reply; 97+ messages in thread From: Stephen J. Turnbull @ 2010-01-01 13:53 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Óscar Fuentes, emacs-devel Juanma Barranquero writes: > bzr push # ugh > # dates in ChangeLog are wrong, so you need an additional commit to > fix the ChangeLog entries > > so it only really works for fixes that do not need ChangeLog entries. Why are the dates in the ChangeLog wrong? The commit history is in "bzr log", the work history is in the ChangeLog. What's the problem with that? Does Emacs have a policy that ChangeLog dates must correspond to the commit sequence or some such? ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 13:53 ` Stephen J. Turnbull @ 2010-01-01 14:38 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2010-01-01 14:38 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: ofv, lekktu, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Date: Fri, 01 Jan 2010 22:53:20 +0900 > Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org > > Does Emacs have a policy that ChangeLog dates must correspond to the > commit sequence or some such? Yes. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-30 21:34 Workflow to accumulate individual changes? Juanma Barranquero 2009-12-30 21:37 ` Juanma Barranquero 2009-12-30 21:46 ` Óscar Fuentes @ 2009-12-30 22:54 ` Giorgos Keramidas 2009-12-31 0:11 ` Juanma Barranquero 2010-01-01 12:33 ` Stephen J. Turnbull 3 siblings, 1 reply; 97+ messages in thread From: Giorgos Keramidas @ 2009-12-30 22:54 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Emacs developers On Wed, 30 Dec 2009 22:34:07 +0100, Juanma Barranquero <lekktu@gmail.com> wrote: > Let's suppose I want to create a local post-23.2 branch where I do > want to commit small changes to install on the trunk post-release. I > don't want to be forced to create a task branch for every one of them, > because they are small changes, and a new branch implies having to > bootstrap[1] anew. So I'd like to accumulate the changes into a single > branch. > > Once the trunk is open again, what would be the procedure to install > the changes? Obviously not "bzr merge ../post-23.2", because that > would create a single [merge] commit. Will I be forced to repeat "bzr > log" and "bzr merge --revision=REVID ../post-23.2" for each change? > That seems a bit cumbersome. Is there any way to simplify it? Perhaps > a plugin? Hi Juanma, If the changes are separate commits, it *may* be simple to avoid a gazillion merges (one for each small change) by using the rebase plugin of bazaar. This way instead of having a history like [1] [2] [3] / / / o --- o --- o --- o --- o --- o with 'o' revisions being trunk commits and local changes [1], [2] and [3] forking from several different ancestor changesets, you can keep your changes in a local branch like this o --- o --- o --- o --- o --- o --- [1] --- [2] --- [3] Every time you "bzr pull" from the trunk, you can re-rebase your local changesets on top of the new trunk. Without rebase, you would have to merge each one of [1], [2] and [3] separately, resulting in a final history similar to: [1] ----------------------------. / \ o --- o --- o --- o --- o --- o --- [m1] --- [m2] --- [m3] \ \ / / [2] [3] ------------ / --------' \ / `-----------------------' with one merge changeset for each local patch. This is a moderately complex history graph, that is mostly readable for three local changes, but things quickly get messy with, say, upwards of 20 local patches. The mostly linear history of rebased changesets is easier to read for local patches. At least it is for me. The good thing about keeping a local set of patches rebased to the latest version of turnk is that you can start developing the patches with revision N of the trunk: o --- o --- [N] --- [1] --- [2] then you cal pull as many times as necessary from the trunk (pull revisions marked with '*' below: o --- o --- [N] --- o --- * --- o --- o --- * --- [1] --- [2] and keep the local patches rebased until they are 'done'. When they are ready for trunk, you can simply "bzr push" them and stop rebasing the local patches. They are not part of trunk and everyone will see them. The down-sides of rebasing that I know of are: (1) You cannot publish the rebased changesets and then rebase them again. People who pulled the `old' rebase will still have it in their local branch and you cannot do anything to delete *their* local changes. (2) Rebasing modifies the history but does not necessarily leave any trace of the old state of the branch. So if you discover that you botched the rebase or one of the merges that happened *during* the rebase, you are screwed. Keeping a backup copy of the local branch *before* a rebase operation (e.g. a tarball) is always a good idea. (3) Rebasing in a bound branch is probably a bad idea. I am not sure how well the plugin will work with changes that are already pushed to the remote side of a bound branch. It is very likely that it will create a very messed up branch state both in the local and the remote side of the world. Having said that I've previously posted a, admittedly rather minimal, example of instructions for the installation and the commands of the bzr-rebase plugin at <http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00871.html>. It may be worth expanding on this if you think it would help you keep a set of local-only patches until they are ready for the public trunk. HTH, Giorgos ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-30 22:54 ` Giorgos Keramidas @ 2009-12-31 0:11 ` Juanma Barranquero 2009-12-31 9:21 ` Andreas Schwab 0 siblings, 1 reply; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 0:11 UTC (permalink / raw) To: Giorgos Keramidas; +Cc: Emacs developers On Wed, Dec 30, 2009 at 23:54, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote: > If the changes are separate commits, it *may* be simple to avoid a > gazillion merges (one for each small change) by using the rebase plugin > of bazaar. This way instead of having a history like Yes, thanks to both Óscar and you for the idea. Unfortunately, as I've said, I think it does not mess too well with ChangeLog. BTW, I'm interested in ways to deal with ChangeLog issues like this. For example, if you spend a while developing a large side project on a branch, your ChangeLog in that branch will reflect the dates of individual changes. In the past, at the moment of merging the branch back into the trunk, the dates were changed (most of unicode-2, or multi-tty, were entered into the ChangeLog at the date the merge happened). With Bazaar, we'd like to keep that kind of operation as a single merge, so perhaps the last commit in the task branch will need to be a ChangeLog fix with the day the merging is planned... Works, but seems a bit messy. I know it has been decided we still will maintain ChangeLogs, and I'm not going to discuss it, but it's a bit of a pity, when a good commit message policy and bzr log --gnu-changelog could save us the trouble. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 0:11 ` Juanma Barranquero @ 2009-12-31 9:21 ` Andreas Schwab 2009-12-31 10:11 ` Eli Zaretskii 2009-12-31 12:20 ` Juanma Barranquero 0 siblings, 2 replies; 97+ messages in thread From: Andreas Schwab @ 2009-12-31 9:21 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Giorgos Keramidas, Emacs developers Juanma Barranquero <lekktu@gmail.com> writes: > I know it has been decided we still will maintain ChangeLogs, and I'm > not going to discuss it, but it's a bit of a pity, when a good commit > message policy and bzr log --gnu-changelog could save us the trouble. ChangeLog entries and commit messages serve a different purpose. ChangeLog entries describe the "physical" changes, a commit message the "logical" change. That is, the commit message describes the changeset on a higher level than the ChangeLog entries. As such it does not make sense to repeat the ChangeLog entries in the commit message. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 9:21 ` Andreas Schwab @ 2009-12-31 10:11 ` Eli Zaretskii 2009-12-31 11:44 ` Andreas Schwab 2009-12-31 12:20 ` Juanma Barranquero 1 sibling, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2009-12-31 10:11 UTC (permalink / raw) To: Andreas Schwab; +Cc: keramida, lekktu, emacs-devel > From: Andreas Schwab <schwab@linux-m68k.org> > Date: Thu, 31 Dec 2009 10:21:05 +0100 > Cc: Giorgos Keramidas <keramida@ceid.upatras.gr>, > Emacs developers <emacs-devel@gnu.org> > > ChangeLog entries and commit messages serve a different purpose. > ChangeLog entries describe the "physical" changes, a commit message the > "logical" change. That is, the commit message describes the changeset > on a higher level than the ChangeLog entries. As such it does not make > sense to repeat the ChangeLog entries in the commit message. I agree with the principle (and I think most, if not all, of others do as well). But what does this mean in practice? Are you suggesting that the commit message should not mention the changes in individual files at all, just the general idea? If that's not what you suggest, i.e. if changes in individual files _should_ be mentioned, it will be very hard to resist the temptation of copying the ChangeLog entries, perhaps _in_addition_to_ the high-level description that we already asked to provide, a couple of weeks ago. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 10:11 ` Eli Zaretskii @ 2009-12-31 11:44 ` Andreas Schwab 2009-12-31 12:23 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: Andreas Schwab @ 2009-12-31 11:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: keramida, lekktu, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Are you suggesting that the commit message should not mention the > changes in individual files at all, just the general idea? Yes, that's what they are for. Just like a merge commit does not repeat the history of all merged revisions, but just summerizes it. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 11:44 ` Andreas Schwab @ 2009-12-31 12:23 ` Eli Zaretskii 2009-12-31 12:38 ` Juanma Barranquero 2009-12-31 13:43 ` Giorgos Keramidas 0 siblings, 2 replies; 97+ messages in thread From: Eli Zaretskii @ 2009-12-31 12:23 UTC (permalink / raw) To: Andreas Schwab; +Cc: keramida, lekktu, emacs-devel > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: lekktu@gmail.com, keramida@ceid.upatras.gr, emacs-devel@gnu.org > Date: Thu, 31 Dec 2009 12:44:46 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Are you suggesting that the commit message should not mention the > > changes in individual files at all, just the general idea? > > Yes, that's what they are for. But then the corresponding ChangeLog entries should have the text identical or very similar to the commit message in front of them, or else have some other means of locating the log entries easily. Anyway, I'm okay with this policy, if Stefan and Yidong approve it. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 12:23 ` Eli Zaretskii @ 2009-12-31 12:38 ` Juanma Barranquero 2009-12-31 13:25 ` Eli Zaretskii 2009-12-31 13:43 ` Giorgos Keramidas 1 sibling, 1 reply; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 12:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: keramida, Andreas Schwab, emacs-devel On Thu, Dec 31, 2009 at 13:23, Eli Zaretskii <eliz@gnu.org> wrote: > Anyway, I'm okay with this policy, if Stefan and Yidong approve it. I'm not, unless Stefan and Yidong force it. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 12:38 ` Juanma Barranquero @ 2009-12-31 13:25 ` Eli Zaretskii 2009-12-31 13:37 ` Juanma Barranquero 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2009-12-31 13:25 UTC (permalink / raw) To: Juanma Barranquero; +Cc: keramida, schwab, emacs-devel > From: Juanma Barranquero <lekktu@gmail.com> > Date: Thu, 31 Dec 2009 13:38:16 +0100 > Cc: Andreas Schwab <schwab@linux-m68k.org>, keramida@ceid.upatras.gr, emacs-devel@gnu.org > > On Thu, Dec 31, 2009 at 13:23, Eli Zaretskii <eliz@gnu.org> wrote: > > > Anyway, I'm okay with this policy, if Stefan and Yidong approve it. > > I'm not, unless Stefan and Yidong force it. Please tell why not, perhaps I'll change my mind ;-) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 13:25 ` Eli Zaretskii @ 2009-12-31 13:37 ` Juanma Barranquero 2009-12-31 14:13 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 13:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: keramida, schwab, emacs-devel On Thu, Dec 31, 2009 at 14:25, Eli Zaretskii <eliz@gnu.org> wrote: > Please tell why not, perhaps I'll change my mind ;-) It's already been said it, I think. Theoretically, ChangeLog is for "physical" changes, and the commit log is for "logical" changes, as Andreas pointed out. But that is difficult to enforce; so in order to understand a given change, you already have to look at both (and, sometimes, you *need* both to understand what's happened). It's better IMO to put all relevant info together, even if that means duplicating it. And that will ease the switch to a ChangeLog-less future, if and when we someday decide that it is not really useful to maintain the ChangeLogs anymore. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 13:37 ` Juanma Barranquero @ 2009-12-31 14:13 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2009-12-31 14:13 UTC (permalink / raw) To: Juanma Barranquero; +Cc: keramida, schwab, emacs-devel > From: Juanma Barranquero <lekktu@gmail.com> > Date: Thu, 31 Dec 2009 14:37:21 +0100 > Cc: schwab@linux-m68k.org, keramida@ceid.upatras.gr, emacs-devel@gnu.org > > It's better IMO to put all relevant info together, even if that > means duplicating it. I don't mind that, either. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 12:23 ` Eli Zaretskii 2009-12-31 12:38 ` Juanma Barranquero @ 2009-12-31 13:43 ` Giorgos Keramidas 2009-12-31 13:53 ` Juanma Barranquero ` (3 more replies) 1 sibling, 4 replies; 97+ messages in thread From: Giorgos Keramidas @ 2009-12-31 13:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, Andreas Schwab, emacs-devel On Thu, 31 Dec 2009 07:23:28 -0500, Eli Zaretskii <eliz@gnu.org> wrote: >> From: Andreas Schwab <schwab@linux-m68k.org> >> Cc: lekktu@gmail.com, keramida@ceid.upatras.gr, emacs-devel@gnu.org >> Date: Thu, 31 Dec 2009 12:44:46 +0100 >> >> Eli Zaretskii <eliz@gnu.org> writes: >> >> > Are you suggesting that the commit message should not mention the >> > changes in individual files at all, just the general idea? >> >> Yes, that's what they are for. > > But then the corresponding ChangeLog entries should have the text > identical or very similar to the commit message in front of them, or > else have some other means of locating the log entries easily. > > Anyway, I'm okay with this policy, if Stefan and Yidong approve it. I think it's very useful to see file changes in the ChangeLog. It helps a lot when an Emacs user downloads a tarball of the sources from the FTP site, because file changes are visible without full access to the original branch itself or access to a bzr client. Maybe we can try to strike a balance between not keeping the ChangeLog up to date at all and making it difficult to commit *one* changeset that includes both ChangeLog updates _and_ file updates by committing the ChangeLog updates separately? This way, we can have a very short summary in the ChangeLog commit, e.g.: : keramida@kobe:/tmp/bzrdemo$ cat ChangeLog : 2009-12-31 Giorgos Keramidas <keramida@ceid.upatras.gr> : : * foo: Add a new 'foo' file. : : keramida@kobe:/tmp/bzrdemo$ bzr log --show-ids : ------------------------------------------------------------ : revno: 2 : revision-id: keramida@ceid.upatras.gr-20091231133847-f7og1ku98r1ng019 : parent: keramida@ceid.upatras.gr-20091231133656-o0jwrzn09m1k3zm1 : committer: Giorgos Keramidas <keramida@ceid.upatras.gr> : branch nick: bzrdemo : timestamp: Thu 2009-12-31 15:38:47 +0200 : message: : ChangeLog for keramida@ceid.upatras.gr-20091231133656-o0jwrzn09m1k3zm1 : ------------------------------------------------------------ : revno: 1 : revision-id: keramida@ceid.upatras.gr-20091231133656-o0jwrzn09m1k3zm1 : committer: Giorgos Keramidas <keramida@ceid.upatras.gr> : branch nick: bzrdemo : timestamp: Thu 2009-12-31 15:36:56 +0200 : message: : Add a new 'foo' file. : : keramida@kobe:/tmp/bzrdemo$ To avoid doubling the revisions we keep in the repository, by following *every* single commit with a ChangeLog update, we can batch ChangeLog updates. So a developer can work in his own local branch and commit several local changes before updating the ChangeLog. Then a single ChangeLog commit on top of those can be stacked on top of the batch of local changes, right before they are pushed to the trunk. In a related side-node, it seems vc-update-change-log doesn't grok bzr branches. What are the missing bits? Can we add them now that Emacs itself uses bzr? ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 13:43 ` Giorgos Keramidas @ 2009-12-31 13:53 ` Juanma Barranquero 2009-12-31 14:07 ` Alfred M. Szmidt 2009-12-31 14:08 ` David Kastrup ` (2 subsequent siblings) 3 siblings, 1 reply; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 13:53 UTC (permalink / raw) To: Giorgos Keramidas; +Cc: Eli Zaretskii, Andreas Schwab, emacs-devel On Thu, Dec 31, 2009 at 14:43, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote: > I think it's very useful to see file changes in the ChangeLog. It helps > a lot when an Emacs user downloads a tarball of the sources from the FTP > site, because file changes are visible without full access to the > original branch itself or access to a bzr client. If we were using the commit log to put ChangeLog entries, the ChangeLog could be reconstructed as part of making the release tarball by a simple bzr log --gnu-changelog -r ... > Maybe we can try to strike a balance between not keeping the ChangeLog > up to date at all and making it difficult to commit *one* changeset that > includes both ChangeLog updates _and_ file updates by committing the > ChangeLog updates separately? That breaks the idea that commits should try to respect the ACID (atomicity, consistency, isolation, durability) principle. > To avoid doubling the revisions we keep in the repository, by following > *every* single commit with a ChangeLog update, we can batch ChangeLog > updates. So a developer can work in his own local branch and commit > several local changes before updating the ChangeLog. Then a single > ChangeLog commit on top of those can be stacked on top of the batch of > local changes, right before they are pushed to the trunk. Personally, I find this idea ugly. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 13:53 ` Juanma Barranquero @ 2009-12-31 14:07 ` Alfred M. Szmidt 2009-12-31 14:16 ` Juanma Barranquero 2010-01-01 2:55 ` Richard Stallman 0 siblings, 2 replies; 97+ messages in thread From: Alfred M. Szmidt @ 2009-12-31 14:07 UTC (permalink / raw) To: Juanma Barranquero; +Cc: keramida, eliz, schwab, emacs-devel A major problem with generating the ChangeLog from the commit messages is that you cannot fix a incorrect entry. More often than not, you need to do fixes (forgotten entries, incorrect formating, ...). ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 14:07 ` Alfred M. Szmidt @ 2009-12-31 14:16 ` Juanma Barranquero 2010-01-01 15:38 ` Alfred M. Szmidt 2010-01-01 2:55 ` Richard Stallman 1 sibling, 1 reply; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 14:16 UTC (permalink / raw) To: ams; +Cc: keramida, eliz, schwab, emacs-devel On Thu, Dec 31, 2009 at 15:07, Alfred M. Szmidt <ams@gnu.org> wrote: > A major problem with generating the ChangeLog from the commit messages > is that you cannot fix a incorrect entry. More often than not, you > need to do fixes (forgotten entries, incorrect formating, ...). I know, I've done quite a few changes to old ChangeLog entries :-) Still, that seems to me a lesser problem that having to check two places to get all relevant info. And, if you look deep at our ChangeLogs, after years and years of use I'm sure you wouldn't take more than half an hour to find some mistake (I'm not talking about typos, but missing, wrong or duplicate entries, etc.). At the end of the day, you look at the ChangeLog or the commit message to get an idea of what happened; if you need the full info, there's the diffs. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 14:16 ` Juanma Barranquero @ 2010-01-01 15:38 ` Alfred M. Szmidt 2010-01-01 17:53 ` David Kastrup 0 siblings, 1 reply; 97+ messages in thread From: Alfred M. Szmidt @ 2010-01-01 15:38 UTC (permalink / raw) To: Juanma Barranquero; +Cc: keramida, eliz, schwab, emacs-devel Still, that seems to me a lesser problem that having to check two places to get all relevant info. And, if you look deep at our ChangeLogs, after years and years of use I'm sure you wouldn't take more than half an hour to find some mistake (I'm not talking about typos, but missing, wrong or duplicate entries, etc.). That may be true, but it is not a argument to make it impossible to fix incorrect entries. Having proper entries is good for developers, and for copyright reasons. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 15:38 ` Alfred M. Szmidt @ 2010-01-01 17:53 ` David Kastrup 0 siblings, 0 replies; 97+ messages in thread From: David Kastrup @ 2010-01-01 17:53 UTC (permalink / raw) To: emacs-devel "Alfred M. Szmidt" <ams@gnu.org> writes: > Still, that seems to me a lesser problem that having to check two > places to get all relevant info. And, if you look deep at our > ChangeLogs, after years and years of use I'm sure you wouldn't take > more than half an hour to find some mistake (I'm not talking about > typos, but missing, wrong or duplicate entries, etc.). > > That may be true, but it is not a argument to make it impossible to > fix incorrect entries. Having proper entries is good for developers, > and for copyright reasons. I don't see what "copyright reasons" would make it a good idea to let a commit+message done by A be silently (or non-silently) be changed by B at a later date. -- David Kastrup ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 14:07 ` Alfred M. Szmidt 2009-12-31 14:16 ` Juanma Barranquero @ 2010-01-01 2:55 ` Richard Stallman 2010-01-01 4:03 ` Óscar Fuentes 2010-01-01 15:38 ` Alfred M. Szmidt 1 sibling, 2 replies; 97+ messages in thread From: Richard Stallman @ 2010-01-01 2:55 UTC (permalink / raw) To: ams; +Cc: keramida, lekktu, eliz, schwab, emacs-devel A major problem with generating the ChangeLog from the commit messages is that you cannot fix a incorrect entry. Is there no way to fix an error in a commit message? ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 2:55 ` Richard Stallman @ 2010-01-01 4:03 ` Óscar Fuentes 2010-01-01 8:41 ` Eli Zaretskii 2010-01-01 15:38 ` Alfred M. Szmidt 1 sibling, 1 reply; 97+ messages in thread From: Óscar Fuentes @ 2010-01-01 4:03 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > Is there no way to fix an error in a commit message? You can undo a commit with `bzr uncommit'. However, this only makes sense if you are committing to some of your local branches. Once you send your change upstream, pretending to alter the revision is like asking for the removal of a message you published on a mailing list, because the history is replicated everywhere. Because of this and other more tehcnical reasons, NEVER use `bzr uncommit' against an upstream branch. You would only cause lots of misery. -- Óscar ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 4:03 ` Óscar Fuentes @ 2010-01-01 8:41 ` Eli Zaretskii 2010-01-01 10:04 ` Óscar Fuentes ` (2 more replies) 0 siblings, 3 replies; 97+ messages in thread From: Eli Zaretskii @ 2010-01-01 8:41 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar_Fuentes <ofv@wanadoo.es> > Date: Fri, 01 Jan 2010 05:03:57 +0100 > > Richard Stallman <rms@gnu.org> writes: > > > Is there no way to fix an error in a commit message? > > You can undo a commit with `bzr uncommit'. But the issue is not to undo the commit, only fix the text of the commit message. Something similar to "cvs admin -mREV:MESSAGE". Typos in commit messages still can happen, even with bzr ;-) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 8:41 ` Eli Zaretskii @ 2010-01-01 10:04 ` Óscar Fuentes 2010-01-02 15:44 ` Richard Stallman 2010-01-01 12:19 ` Andreas Schwab 2010-01-01 14:59 ` Stephen J. Turnbull 2 siblings, 1 reply; 97+ messages in thread From: Óscar Fuentes @ 2010-01-01 10:04 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> > Is there no way to fix an error in a commit message? >> >> You can undo a commit with `bzr uncommit'. > > But the issue is not to undo the commit, only fix the text of the > commit message. Something similar to "cvs admin -mREV:MESSAGE". There is no equivalent for `cvs admin -mREV' in bazaar. Maybe it is not clear from my description that `bzr uncommit' does not throw away the change: it reverses the state to the point previous to the commit, so you do bzr uncommit bzr commit -m "the right message here" > Typos in commit messages still can happen, even with bzr ;-) AFAIK, the commit message is a part of the revision, so if bazaar allowed to simply edit it, you would be "transmuting" the revision, (i.e. it would have a different revision-id) and that is absolutely forbidden in DVCSs. What you can do is to remove some revisions and replace them with others. Just don't do it on public branches. You can change anything on the history of your private branch using a variety of techniques (being `bzr uncommit' the simplest one,) but we have to admit that changing the message of an arbitrary revision is something that can't be done due to the nature of DVCSs -- Óscar ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 10:04 ` Óscar Fuentes @ 2010-01-02 15:44 ` Richard Stallman 0 siblings, 0 replies; 97+ messages in thread From: Richard Stallman @ 2010-01-02 15:44 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel You can change anything on the history of your private branch using a variety of techniques (being `bzr uncommit' the simplest one,) but we have to admit that changing the message of an arbitrary revision is something that can't be done due to the nature of DVCSs How sad. I wonder if we could provide a different feature which would do the same job: namely, a way to enter a subsequent revision which says, "This message replaces the commit message of revision N." We could set it up so that the usual ways of looking at history will do that edit, as if the commit message of revision N had been changed. There would be an option to disable this automatic editing and show things as they really are. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 8:41 ` Eli Zaretskii 2010-01-01 10:04 ` Óscar Fuentes @ 2010-01-01 12:19 ` Andreas Schwab 2010-01-01 14:33 ` Eli Zaretskii 2010-01-01 14:59 ` Stephen J. Turnbull 2 siblings, 1 reply; 97+ messages in thread From: Andreas Schwab @ 2010-01-01 12:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > But the issue is not to undo the commit, only fix the text of the > commit message. That's fundamentally the same. > Something similar to "cvs admin -mREV:MESSAGE". You have to forget the idea that you can modify (published) history. With a DVCS you can only create history. Once you have published a commit it is immutable. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 12:19 ` Andreas Schwab @ 2010-01-01 14:33 ` Eli Zaretskii 2010-01-01 14:48 ` Andreas Schwab 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2010-01-01 14:33 UTC (permalink / raw) To: Andreas Schwab; +Cc: ofv, emacs-devel > From: Andreas Schwab <schwab@linux-m68k.org> > Cc: =?utf-8?Q?=C3=93scar?= Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org > Date: Fri, 01 Jan 2010 13:19:14 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > But the issue is not to undo the commit, only fix the text of the > > commit message. > > That's fundamentally the same. Perhaps in bzr it is, but not in real life. > > Something similar to "cvs admin -mREV:MESSAGE". > > You have to forget the idea that you can modify (published) history. > With a DVCS you can only create history. Once you have published a > commit it is immutable. A commit message is not history, it's a label of that history. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 14:33 ` Eli Zaretskii @ 2010-01-01 14:48 ` Andreas Schwab 2010-01-01 19:18 ` Karl Fogel 0 siblings, 1 reply; 97+ messages in thread From: Andreas Schwab @ 2010-01-01 14:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ofv, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > A commit message is not history It is an integral part of the commit. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 14:48 ` Andreas Schwab @ 2010-01-01 19:18 ` Karl Fogel 2010-01-01 19:56 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 97+ messages in thread From: Karl Fogel @ 2010-01-01 19:18 UTC (permalink / raw) To: Andreas Schwab; +Cc: ofv, Eli Zaretskii, emacs-devel Andreas Schwab <schwab@linux-m68k.org> writes: >Eli Zaretskii <eliz@gnu.org> writes: > >> A commit message is not history > >It is an integral part of the commit. This is an old debate in the DVCS world. The issue is that changes are distributed and there is no "master copy" of a given change; instead, there are many copies of the same change, and you can tell they're the same because they all have the same unique id (and same contents). In CVS, the master copy is always in the repository and there is exactly one repository. So if you want to read log messages, you do 'cvs log' and it contacts the repository (or, in Emacs's case, 'cvs update' gets updates to the ChangeLog files, but that also contacts the repository). In Bzr, the savannah trunk branch is sort of the equivalent CVS's "the repository"... but the changes in that branch are replicated among hundreds or thousands of developers' local branches. If you tweak a commit message on the savannah branch, bzr has no mechanism for conveying that tweak to the other branches, because the commit message is considered part of the change, just like the diff. Tweak the commit message and you've tweaked the change -- it's no longer the same change. There are other ways the system could work. IIUC, in git the commit message is *not* part of the change's identity, it's just attached to the change, so you can edit the message later. But I don't know if git has a way of propagating those edits to other clones; nor do I know what git would do if two different clones tweak a commit message for the "same" change in two different ways and then one of them has to receive the other's edits. Is there conflict resolution on "out-of-band" data, and if so, how would it work? Perhaps the difficulty of that question is why bzr doesn't support this. In any case, IMHO it is a minor feature regression that we can no longer tweak log messages after the fact, but it's not a huge problem. -Karl ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 19:18 ` Karl Fogel @ 2010-01-01 19:56 ` Eli Zaretskii 2010-01-01 20:09 ` Chong Yidong ` (2 more replies) 2010-01-01 20:07 ` Teemu Likonen 2010-01-02 4:37 ` Stephen J. Turnbull 2 siblings, 3 replies; 97+ messages in thread From: Eli Zaretskii @ 2010-01-01 19:56 UTC (permalink / raw) To: Karl Fogel; +Cc: emacs-devel > From: Karl Fogel <kfogel@red-bean.com> > Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org > Date: Fri, 01 Jan 2010 14:18:00 -0500 > > If you tweak a commit message on the savannah branch, bzr has no > mechanism for conveying that tweak to the other branches Well, that's just it: bzr _should_ have such a mechanism. I really don't care if modifying a commit message would count as a new revision of the tree, all I care is that "bzr log" and friends show the modified commit message by default (if there would be a way to see the original one before the fix, that's okay too). > because the commit message > is considered part of the change, just like the diff. Tweak the commit > message and you've tweaked the change -- it's no longer the same change. There's no requirement to pretend the tree is the same after modifying the commit message. The requirement is that "bzr log" shows it with the commit, that's all. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 19:56 ` Eli Zaretskii @ 2010-01-01 20:09 ` Chong Yidong 2010-01-01 21:34 ` Eli Zaretskii 2010-01-01 20:13 ` Karl Fogel 2010-01-01 21:25 ` Óscar Fuentes 2 siblings, 1 reply; 97+ messages in thread From: Chong Yidong @ 2010-01-01 20:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Karl Fogel, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> If you tweak a commit message on the savannah branch, bzr has no >> mechanism for conveying that tweak to the other branches > > Well, that's just it: bzr _should_ have such a mechanism. I really > don't care if modifying a commit message would count as a new revision > of the tree, all I care is that "bzr log" and friends show the > modified commit message by default (if there would be a way to see the > original one before the fix, that's okay too). I think the problem is that this involves tracking changes to changes. What if you want to change the change to the change? ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 20:09 ` Chong Yidong @ 2010-01-01 21:34 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2010-01-01 21:34 UTC (permalink / raw) To: Chong Yidong; +Cc: kfogel, emacs-devel > From: Chong Yidong <cyd@stupidchicken.com> > Cc: Karl Fogel <kfogel@red-bean.com>, emacs-devel@gnu.org > Date: Fri, 01 Jan 2010 15:09:06 -0500 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> If you tweak a commit message on the savannah branch, bzr has no > >> mechanism for conveying that tweak to the other branches > > > > Well, that's just it: bzr _should_ have such a mechanism. I really > > don't care if modifying a commit message would count as a new revision > > of the tree, all I care is that "bzr log" and friends show the > > modified commit message by default (if there would be a way to see the > > original one before the fix, that's okay too). > > I think the problem is that this involves tracking changes to changes. > What if you want to change the change to the change? Just add another revision. It's the same as with versioned files, really. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 19:56 ` Eli Zaretskii 2010-01-01 20:09 ` Chong Yidong @ 2010-01-01 20:13 ` Karl Fogel 2010-01-01 21:35 ` Eli Zaretskii 2010-01-01 21:25 ` Óscar Fuentes 2 siblings, 1 reply; 97+ messages in thread From: Karl Fogel @ 2010-01-01 20:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Karl Fogel <kfogel@red-bean.com> >> Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org >> Date: Fri, 01 Jan 2010 14:18:00 -0500 >> >> If you tweak a commit message on the savannah branch, bzr has no >> mechanism for conveying that tweak to the other branches > >Well, that's just it: bzr _should_ have such a mechanism. I really >don't care if modifying a commit message would count as a new revision >of the tree, all I care is that "bzr log" and friends show the >modified commit message by default (if there would be a way to see the >original one before the fix, that's okay too). I agree it's a bug. Having established that... the most productive place to discuss Bazaar bugs is probably the Bazaar list. -K ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 20:13 ` Karl Fogel @ 2010-01-01 21:35 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2010-01-01 21:35 UTC (permalink / raw) To: Karl Fogel; +Cc: emacs-devel > From: Karl Fogel <kfogel@red-bean.com> > Cc: emacs-devel@gnu.org > Date: Fri, 01 Jan 2010 15:13:00 -0500 > > Eli Zaretskii <eliz@gnu.org> writes: > >> From: Karl Fogel <kfogel@red-bean.com> > >> Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org > >> Date: Fri, 01 Jan 2010 14:18:00 -0500 > >> > >> If you tweak a commit message on the savannah branch, bzr has no > >> mechanism for conveying that tweak to the other branches > > > >Well, that's just it: bzr _should_ have such a mechanism. I really > >don't care if modifying a commit message would count as a new revision > >of the tree, all I care is that "bzr log" and friends show the > >modified commit message by default (if there would be a way to see the > >original one before the fix, that's okay too). > > I agree it's a bug. Having established that... the most productive > place to discuss Bazaar bugs is probably the Bazaar list. Done. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 19:56 ` Eli Zaretskii 2010-01-01 20:09 ` Chong Yidong 2010-01-01 20:13 ` Karl Fogel @ 2010-01-01 21:25 ` Óscar Fuentes 2010-01-01 21:34 ` Eli Zaretskii 2 siblings, 1 reply; 97+ messages in thread From: Óscar Fuentes @ 2010-01-01 21:25 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> If you tweak a commit message on the savannah branch, bzr has no >> mechanism for conveying that tweak to the other branches > > Well, that's just it: bzr _should_ have such a mechanism. I really > don't care if modifying a commit message would count as a new revision > of the tree, all I care is that "bzr log" and friends show the > modified commit message by default (if there would be a way to see the > original one before the fix, that's okay too). By replacing a revision with another revision, you are effectively breaking the mirror branches on all sites that updated/pulled before the "fix" (you make them diverge.) And that's the easier part. You will cause lots of problems, really. A mechanism that notices that certain revision replaces a previous one and propagates the fact when two branches communicate, not only would be very complex, but quite questionable from the ethical POV, as it could be used to modify or destroy VC history by a malicious individual. As for the commit message and other metadata such as the committer name being part of the hashed data, it is considered a fundamental requirement for keeping history integrity. [snip] -- Óscar ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 21:25 ` Óscar Fuentes @ 2010-01-01 21:34 ` Eli Zaretskii 2010-01-01 22:58 ` Andreas Schwab 0 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2010-01-01 21:34 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar_Fuentes <ofv@wanadoo.es> > Date: Fri, 01 Jan 2010 22:25:20 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> If you tweak a commit message on the savannah branch, bzr has no > >> mechanism for conveying that tweak to the other branches > > > > Well, that's just it: bzr _should_ have such a mechanism. I really > > don't care if modifying a commit message would count as a new revision > > of the tree, all I care is that "bzr log" and friends show the > > modified commit message by default (if there would be a way to see the > > original one before the fix, that's okay too). > > By replacing a revision with another revision, you are effectively > breaking the mirror branches on all sites that updated/pulled before the > "fix" (you make them diverge.) Who said anything about replacing a revision? I was talking about _adding_ a revision, if needed. It just needs to be added in a special way, such that nothing changes except the addition of a modified commit message, and "bzr log" showing that modified message instead of the original one. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 21:34 ` Eli Zaretskii @ 2010-01-01 22:58 ` Andreas Schwab 0 siblings, 0 replies; 97+ messages in thread From: Andreas Schwab @ 2010-01-01 22:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Who said anything about replacing a revision? I was talking about > _adding_ a revision, if needed. It just needs to be added in a > special way, such that nothing changes except the addition of a > modified commit message, and "bzr log" showing that modified message > instead of the original one. There needs to be a reference to this added information, otherwise nobody will see it. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 19:18 ` Karl Fogel 2010-01-01 19:56 ` Eli Zaretskii @ 2010-01-01 20:07 ` Teemu Likonen 2010-01-01 20:12 ` Karl Fogel 2010-01-02 4:37 ` Stephen J. Turnbull 2 siblings, 1 reply; 97+ messages in thread From: Teemu Likonen @ 2010-01-01 20:07 UTC (permalink / raw) To: Karl Fogel; +Cc: ofv, Eli Zaretskii, Andreas Schwab, emacs-devel On 2010-01-01 14:18 (-0500), Karl Fogel wrote: > IIUC, in git the commit message is *not* part of the change's > identity, it's just attached to the change, so you can edit the > message later. That's wrong--or your "change's identity" means something I don't understand. In Git commit's author, committer, date, parent commits' SHA1s, referenced tree object's SHA1 and commit message together make the content of a commit object. From this content is calculated the SHA1 of that commit object. If you change any of these the SHA1 of the commit object will be different and hence the whole commit object will be different (i.e. its identity is different). So no, it's not possible to change commit message (or any information the commit object contains) without making it a different commit. There is a related feature, though. New Git versions have "git notes" command which allows user to add additional notes to commits. Such extra notes can be added and removed freely and "git log" prints them after the commit message. Notes can be sent between repositories but currently it doesn't happen automatically with usual pull/push commands. http://www.kernel.org/pub/software/scm/git/docs/git-notes.html ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 20:07 ` Teemu Likonen @ 2010-01-01 20:12 ` Karl Fogel 2010-01-01 21:08 ` Teemu Likonen 0 siblings, 1 reply; 97+ messages in thread From: Karl Fogel @ 2010-01-01 20:12 UTC (permalink / raw) To: Teemu Likonen; +Cc: ofv, Eli Zaretskii, Andreas Schwab, emacs-devel Teemu Likonen <tlikonen@iki.fi> writes: >On 2010-01-01 14:18 (-0500), Karl Fogel wrote: >> IIUC, in git the commit message is *not* part of the change's >> identity, it's just attached to the change, so you can edit the >> message later. > >That's wrong--or your "change's identity" means something I don't >understand. In Git commit's author, committer, date, parent commits' >SHA1s, referenced tree object's SHA1 and commit message together make >the content of a commit object. From this content is calculated the SHA1 >of that commit object. If you change any of these the SHA1 of the commit >object will be different and hence the whole commit object will be >different (i.e. its identity is different). Someone -- whom I thought would know -- specifically told me that the commit message is *not* part of the SHA1 of the commit object. I double checked, because this was surprising to me, and they confirmed. But either they were wrong, or I misunderstood, or possibly both. In any case, I'm sorry for spreading misinformation. >There is a related feature, though. New Git versions have "git notes" >command which allows user to add additional notes to commits. Such extra >notes can be added and removed freely and "git log" prints them after >the commit message. Notes can be sent between repositories but currently >it doesn't happen automatically with usual pull/push commands. > >http://www.kernel.org/pub/software/scm/git/docs/git-notes.html Maybe this is what the person thought I was talking about. -K ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 20:12 ` Karl Fogel @ 2010-01-01 21:08 ` Teemu Likonen 2010-01-02 5:00 ` Stephen J. Turnbull 0 siblings, 1 reply; 97+ messages in thread From: Teemu Likonen @ 2010-01-01 21:08 UTC (permalink / raw) To: Karl Fogel; +Cc: ofv, Eli Zaretskii, Andreas Schwab, emacs-devel On 2010-01-01 15:12 (-0500), Karl Fogel wrote: > Someone -- whom I thought would know -- specifically told me that the > commit message is *not* part of the SHA1 of the commit object. I > double checked, because this was surprising to me, and they confirmed. > > But either they were wrong, or I misunderstood, or possibly both. In > any case, I'm sorry for spreading misinformation. No problem. I'll still repeat that it's indeed misinformation. Here's a raw content of a certain commit object in Emacs Git repository (the four-space indent is by me): $ git cat-file commit 9a339f5 tree ef4fd5bd3689b5c17a3eb6df705564a5d4fed602 parent 031c7e409992e98fefc98c3e8a6be981a00c55a9 author Chong Yidong <cyd@stupidchicken.com> 1261901472 +0000 committer Chong Yidong <cyd@stupidchicken.com> 1261901472 +0000 * minibuf.c (Fall_completions): Minor optimization. We can see the commit message in the end. "git log" prints it like this: $ git log -1 9a339f5 commit 9a339f5040b089f97a4b5c86eefa3942b2e5eda4 Author: Chong Yidong <cyd@stupidchicken.com> Date: 2009-12-27 08:11:12 +0000 * minibuf.c (Fall_completions): Minor optimization. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 21:08 ` Teemu Likonen @ 2010-01-02 5:00 ` Stephen J. Turnbull 2010-01-02 5:12 ` Karl Fogel 0 siblings, 1 reply; 97+ messages in thread From: Stephen J. Turnbull @ 2010-01-02 5:00 UTC (permalink / raw) To: Teemu Likonen; +Cc: Karl Fogel, ofv, Eli Zaretskii, Andreas Schwab, emacs-devel Teemu Likonen writes: > No problem. I'll still repeat that it's indeed misinformation. Here's a > raw content of a certain commit object in Emacs Git repository (the > four-space indent is by me): cat'ing the object doesn't prove anything. The header content is easily separable from the commit message, and in theory you could generate the SHA1 based on the header only. (I can't imagine Linus doing such a thing, but it would immediately occur to most Emacs hackers.) Here's an experimental proof: # Verify identity. $ git rev-parse HEAD f008c025d04f4bcec79f2bb463589461d95a3154 $ git cat-file commit HEAD | git hash-object --stdin -t commit f008c025d04f4bcec79f2bb463589461d95a3154 # Verify difference -- I happen to know that the word "Update" occurs # uniquely in the comment portion of this commit. $ git cat-file commit HEAD | sed -e s/Update/Rewrite/ \ | git hash-object --stdin -t commit ff2c9790c738d10205086a12ce394069ceccbb83 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 5:00 ` Stephen J. Turnbull @ 2010-01-02 5:12 ` Karl Fogel 2010-01-02 5:24 ` Miles Bader 0 siblings, 1 reply; 97+ messages in thread From: Karl Fogel @ 2010-01-02 5:12 UTC (permalink / raw) To: Stephen J. Turnbull Cc: ofv, Eli Zaretskii, Teemu Likonen, Andreas Schwab, emacs-devel "Stephen J. Turnbull" <stephen@xemacs.org> writes: >Teemu Likonen writes: > > No problem. I'll still repeat that it's indeed misinformation. Here's a > > raw content of a certain commit object in Emacs Git repository (the > > four-space indent is by me): > >cat'ing the object doesn't prove anything. The header content is >easily separable from the commit message, and in theory you could >generate the SHA1 based on the header only. (I can't imagine Linus >doing such a thing, but it would immediately occur to most Emacs >hackers.) Heh. I followed up in private mail to Teemu saying the same thing. >Here's an experimental proof: > ># Verify identity. >$ git rev-parse HEAD >f008c025d04f4bcec79f2bb463589461d95a3154 >$ git cat-file commit HEAD | git hash-object --stdin -t commit >f008c025d04f4bcec79f2bb463589461d95a3154 > ># Verify difference -- I happen to know that the word "Update" occurs ># uniquely in the comment portion of this commit. >$ git cat-file commit HEAD | sed -e s/Update/Rewrite/ \ > | git hash-object --stdin -t commit >ff2c9790c738d10205086a12ce394069ceccbb83 Now *that's* the proof we needed. Thanks. It would be very winning if some DVCS would a) Allow tweaking commit messages b) Version those tweaks c) Propagate those tweaks to other branches whenever the other branch receives data from the tweaked branch d) Have a conflict resolution mechanism for when different tweaks collide This is a tall order, however. I'm not surprised no DVCS (AFAIK) does it. -K ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 5:12 ` Karl Fogel @ 2010-01-02 5:24 ` Miles Bader 2010-01-02 11:43 ` Juanma Barranquero 0 siblings, 1 reply; 97+ messages in thread From: Miles Bader @ 2010-01-02 5:24 UTC (permalink / raw) To: Karl Fogel Cc: ofv, emacs-devel, Andreas Schwab, Stephen J. Turnbull, Teemu Likonen, Eli Zaretskii Karl Fogel <kfogel@red-bean.com> writes: > This is a tall order, however. I'm not surprised no DVCS (AFAIK) does it. Yeah, a complex infrastructure just to fix typos in commit messages seems a bit over the top. -Miles -- Bore, n. A person who talks when you wish him to listen. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 5:24 ` Miles Bader @ 2010-01-02 11:43 ` Juanma Barranquero 2010-01-02 12:09 ` Miles Bader 0 siblings, 1 reply; 97+ messages in thread From: Juanma Barranquero @ 2010-01-02 11:43 UTC (permalink / raw) To: Miles Bader Cc: ofv, emacs-devel, Karl Fogel, Andreas Schwab, Stephen J. Turnbull, Teemu Likonen, Eli Zaretskii On Sat, Jan 2, 2010 at 06:24, Miles Bader <miles@gnu.org> wrote: > Yeah, a complex infrastructure just to fix typos in commit messages > seems a bit over the top. Though I agree with you, let's not misrepresent the issue; changing commit messages is not just about typos, but also wrong or misleading information. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 11:43 ` Juanma Barranquero @ 2010-01-02 12:09 ` Miles Bader 2010-01-02 19:22 ` Karl Fogel 0 siblings, 1 reply; 97+ messages in thread From: Miles Bader @ 2010-01-02 12:09 UTC (permalink / raw) To: Juanma Barranquero Cc: ofv, emacs-devel, Karl Fogel, Andreas Schwab, Stephen J. Turnbull, Teemu Likonen, Eli Zaretskii Juanma Barranquero <lekktu@gmail.com> writes: >> Yeah, a complex infrastructure just to fix typos in commit messages >> seems a bit over the top. > > Though I agree with you, let's not misrepresent the issue; changing > commit messages is not just about typos, but also wrong or misleading > information. Nonetheless, IME, it's _extremely_ rare for it to represent a serious issue, and nowhere near enough of a problem to be worth the cost of such a mechanism. -Miles -- Kilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans in Scotland. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 12:09 ` Miles Bader @ 2010-01-02 19:22 ` Karl Fogel 2010-01-05 8:50 ` Stephen J. Turnbull 0 siblings, 1 reply; 97+ messages in thread From: Karl Fogel @ 2010-01-02 19:22 UTC (permalink / raw) To: Miles Bader Cc: ofv, Juanma Barranquero, emacs-devel, Andreas Schwab, Stephen J. Turnbull, Teemu Likonen, Eli Zaretskii Miles Bader <miles@gnu.org> writes: >Nonetheless, IME, it's _extremely_ rare for it to represent a serious >issue, and nowhere near enough of a problem to be worth the cost of such >a mechanism. I don't know how rare it is, but I saw it be important once. See http://www.red-bean.com/kfogel/beautiful-teams/bt-chapter-21.html#contribulyzer Search for the phrase "after writing the Contribulyzer code to process log messages formatted according to the new standard, we could go back and fix up all of the project's existing logs to conform to that standard" to jump straight to the paragraph about how editing log messages after the fact made a big difference. -Karl ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 19:22 ` Karl Fogel @ 2010-01-05 8:50 ` Stephen J. Turnbull 0 siblings, 0 replies; 97+ messages in thread From: Stephen J. Turnbull @ 2010-01-05 8:50 UTC (permalink / raw) To: Karl Fogel Cc: ofv, Juanma Barranquero, emacs-devel, Andreas Schwab, Eli Zaretskii, Teemu Likonen, Miles Bader Karl Fogel writes: > Search for the phrase > > "after writing the Contribulyzer code to process log messages > formatted according to the new standard, we could go back and fix up > all of the project's existing logs to conform to that standard" > > to jump straight to the paragraph about how editing log messages after > the fact made a big difference. For something like that you could use git-filter-branch and probably the equivalent in bzr (there *is* an equivalent, but I think it requires converting to fastimport format to use). To avoid the rebase issue, you'd maybe merge the resulting branch rather than rebase. git-filter-branch is very fast, although bzr's equivalent would not be if I'm correct about converting to fastimport format. But it could probably be made to be fast. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 19:18 ` Karl Fogel 2010-01-01 19:56 ` Eli Zaretskii 2010-01-01 20:07 ` Teemu Likonen @ 2010-01-02 4:37 ` Stephen J. Turnbull 2 siblings, 0 replies; 97+ messages in thread From: Stephen J. Turnbull @ 2010-01-02 4:37 UTC (permalink / raw) To: Karl Fogel; +Cc: ofv, Eli Zaretskii, Andreas Schwab, emacs-devel Karl Fogel writes: > There are other ways the system could work. IIUC, in git the commit > message is *not* part of the change's identity, No, in git the commit message is indeed part of the changes's identity. A commit is a strictly defined structure (that happens to be UTF-8 text with a final, free-form "comment" field), and the whole thing is hashed to get the SHA1 identifying the commit. What git has (and Mercurial, though implemented very differently) is tag *objects*. The tag object can contain arbitrary content (eg, a signature), but here it could be used in some conventional way (eg, by naming it "<sha1>-log-<log-rev-no>" to record an edited message for commit <sha1>. > But I don't know if git has a way of propagating those edits to > other clones; git commit --amend creates a new commit, propagated in the usual way for commits. git tag -a creates an annotated tag, propagated in the usual way for tags. > In any case, IMHO it is a minor feature regression that we can no longer > tweak log messages after the fact, but it's not a huge problem. The problem is that in a DVCS there is no reasonable way to propagate those changes, and it becomes an issue of what the "official" message for that commit is. Eg, suppose you tweak. Now different "official" messages are going to propagate -- some people already have that commit, and will *not* refetch it because the identity (SHA1) hasn't changed. Others will update or clone, and get it. In other words, in git the way to notify other clients that you've changed the commit message is to change the commit ID. This is true of all of the DVCSes I've used. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 8:41 ` Eli Zaretskii 2010-01-01 10:04 ` Óscar Fuentes 2010-01-01 12:19 ` Andreas Schwab @ 2010-01-01 14:59 ` Stephen J. Turnbull 2010-01-01 15:30 ` Eli Zaretskii 2 siblings, 1 reply; 97+ messages in thread From: Stephen J. Turnbull @ 2010-01-01 14:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel Eli Zaretskii writes: > > From: Óscar_Fuentes <ofv@wanadoo.es> > > Date: Fri, 01 Jan 2010 05:03:57 +0100 > > > > Richard Stallman <rms@gnu.org> writes: > > > > > Is there no way to fix an error in a commit message? > > > > You can undo a commit with `bzr uncommit'. > > But the issue is not to undo the commit, only fix the text of the > commit message. Something similar to "cvs admin -mREV:MESSAGE". There's no reason practical or otherwise not to do uncommit, then commit again, as long as you're on a private branch. git and darcs provide "git commit --amend" and "darcs amend-commit" which do exactly what you want, except that they change the identity of the commit (see below). Eg as a shell function bzr-amend-last-commit () { COMMIT_LOG=$1 bzr uncommit bzr commit -m "$COMMIT_LOG" } There are also filter-branch capabilities in both git and bzr (quite expensive in bzr, though) that would allow you to amend an old commit log on a private branch. If I really needed to fix a message in a published git branch I would use a heavyweight tag named "README-something". I don't think there's anything similar in bzr, though. > Typos in commit messages still can happen, even with bzr ;-) This has been endlessly discussed on at least the Darcs and Bazaar lists. The gist is that the commit log is part of the historical record, and is checksummed, along with the rest of the history data (eg date and author information). This checksum becomes part of the revision identifier, and thus if you change any of the data, including the commit log, you've changed the identity of the revision. As described elsewhere, that revision identifier is used in various places; it's not an implemention-internal datum. I don't think there's any theoretical problem with attaching the log message externally (at least, external to the checksummed content) as a comment, somehow. However, from personal experience I can say that while I still make the same number of typos in log messages as when I was using CVS, I make far fewer errors of the form of omitting important information because I commit much more frequently and my log messages are both shorter (per message) and more detailed. So I suspect you'd get resistence to such a suggestion, both on principle ("The log message is part of history") and practically ("there's no real benefit, it would take work to do, and it slightly weakens our internal consistency guarantee"). ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 14:59 ` Stephen J. Turnbull @ 2010-01-01 15:30 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2010-01-01 15:30 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: ofv, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <ofv@wanadoo.es>, > emacs-devel@gnu.org > Date: Fri, 01 Jan 2010 23:59:20 +0900 > > So I suspect you'd get resistence to such a suggestion, both on > principle ("The log message is part of history") and practically > ("there's no real benefit, it would take work to do, and it slightly > weakens our internal consistency guarantee"). Forget it. It's easier to set up flyspell for the log buffers. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 2:55 ` Richard Stallman 2010-01-01 4:03 ` Óscar Fuentes @ 2010-01-01 15:38 ` Alfred M. Szmidt 1 sibling, 0 replies; 97+ messages in thread From: Alfred M. Szmidt @ 2010-01-01 15:38 UTC (permalink / raw) To: rms; +Cc: keramida, lekktu, eliz, schwab, emacs-devel A major problem with generating the ChangeLog from the commit messages is that you cannot fix a incorrect entry. Is there no way to fix an error in a commit message? That is the case, once one publishes a revision there is no way of amending the commit message. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 13:43 ` Giorgos Keramidas 2009-12-31 13:53 ` Juanma Barranquero @ 2009-12-31 14:08 ` David Kastrup 2009-12-31 19:47 ` Karl Fogel 2009-12-31 14:12 ` Eli Zaretskii 2009-12-31 19:08 ` Stefan Monnier 3 siblings, 1 reply; 97+ messages in thread From: David Kastrup @ 2009-12-31 14:08 UTC (permalink / raw) To: emacs-devel Giorgos Keramidas <keramida@ceid.upatras.gr> writes: > I think it's very useful to see file changes in the ChangeLog. It > helps a lot when an Emacs user downloads a tarball of the sources from > the FTP site, because file changes are visible without full access to > the original branch itself or access to a bzr client. _IF_ the file change history is important, we can generate it on the source web page on the fly, from the VCS logs. ChangeLog dates from a time of VCS-less development. If we really want to distribute this sort of info, generating it from commits is quite more reliable. One point of a distributed version control system is that non-privileged users may clone their own repository and have all this historical data in case they need to work with it. My vote is for moving ChangeLog maintenance to proper commit message maintenance: that is more important for a developer with version control access, and again, DVCS use means that this info is available off-line to the user/programmer. With CVS, it wasn't. > Maybe we can try to strike a balance between not keeping the ChangeLog > up to date at all and making it difficult to commit *one* changeset > that includes both ChangeLog updates _and_ file updates by committing > the ChangeLog updates separately? I don't consider it useful anymore to artificially split relevant change info between ChangeLog and commit messages: all relevant version control tools (graphical browsers etc) access the commit messages, and those are there also offline. There is no info we want in ChangeLog that should be missing from commit messages. The price Emacs developers pay for following the proposed hair-splitting policies now is too high. With CVS, off-line access to the ChangeLog was a somewhat valid argument. With DVCS, it isn't. -- David Kastrup ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 14:08 ` David Kastrup @ 2009-12-31 19:47 ` Karl Fogel 2009-12-31 20:14 ` Chong Yidong 0 siblings, 1 reply; 97+ messages in thread From: Karl Fogel @ 2009-12-31 19:47 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel David Kastrup <dak@gnu.org> writes: >_IF_ the file change history is important, we can generate it on the >source web page on the fly, from the VCS logs. ChangeLog dates from a >time of VCS-less development. If we really want to distribute this sort >of info, generating it from commits is quite more reliable. > >One point of a distributed version control system is that non-privileged >users may clone their own repository and have all this historical data >in case they need to work with it. > >My vote is for moving ChangeLog maintenance to proper commit message >maintenance: that is more important for a developer with version control >access, and again, DVCS use means that this info is available off-line >to the user/programmer. With CVS, it wasn't. > >> Maybe we can try to strike a balance between not keeping the ChangeLog >> up to date at all and making it difficult to commit *one* changeset >> that includes both ChangeLog updates _and_ file updates by committing >> the ChangeLog updates separately? > >I don't consider it useful anymore to artificially split relevant change >info between ChangeLog and commit messages: all relevant version control >tools (graphical browsers etc) access the commit messages, and those are >there also offline. > >There is no info we want in ChangeLog that should be missing from commit >messages. > >The price Emacs developers pay for following the proposed hair-splitting >policies now is too high. With CVS, off-line access to the ChangeLog >was a somewhat valid argument. With DVCS, it isn't. +1 all over this. Our commit logs should follow the same structure ChangeLog entries currently do, and we should not maintain separate ChangeLog files. There would be zero information loss; also much less confusion, and much less time wasted discussing how to maintain the same information in two places. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 19:47 ` Karl Fogel @ 2009-12-31 20:14 ` Chong Yidong 2009-12-31 20:36 ` Óscar Fuentes 2009-12-31 20:44 ` Juanma Barranquero 0 siblings, 2 replies; 97+ messages in thread From: Chong Yidong @ 2009-12-31 20:14 UTC (permalink / raw) To: Karl Fogel; +Cc: David Kastrup, emacs-devel Karl Fogel <kfogel@red-bean.com> writes: > Our commit logs should follow the same structure ChangeLog entries > currently do, and we should not maintain separate ChangeLog files. It's already been decided that we'll continue to maintain ChangeLog files. This is an awfully marginal issue, so let's not waste any more time arguing. Just write the ChangeLog entries the way we've all been doing, and pull them into the commit log (`C-c C-a' if you're using VC). ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 20:14 ` Chong Yidong @ 2009-12-31 20:36 ` Óscar Fuentes 2009-12-31 20:44 ` Juanma Barranquero 1 sibling, 0 replies; 97+ messages in thread From: Óscar Fuentes @ 2009-12-31 20:36 UTC (permalink / raw) To: emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: >> Our commit logs should follow the same structure ChangeLog entries >> currently do, and we should not maintain separate ChangeLog files. > > It's already been decided that we'll continue to maintain ChangeLog > files. This is an awfully marginal issue, so let's not waste any more > time arguing. It's far from being a marginal issue, it affects the convenience of Bazaar for most of the work that does not consists on committing to upstream immediately (i.e. the centralized on-line workflow, CVS-style.) I agree that discussing it now is worthless, though. After some weeks of using Bazaar, people will experience the issues by themselves and then it would be much more easier to reach a consensus. [snip] -- Óscar ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 20:14 ` Chong Yidong 2009-12-31 20:36 ` Óscar Fuentes @ 2009-12-31 20:44 ` Juanma Barranquero 1 sibling, 0 replies; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 20:44 UTC (permalink / raw) To: Chong Yidong; +Cc: Karl Fogel, David Kastrup, emacs-devel On Thu, Dec 31, 2009 at 21:14, Chong Yidong <cyd@stupidchicken.com> wrote: > Just write the ChangeLog entries the way we've all been doing, ...(hopefully) remembering to put that one-line summary at the start... Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 13:43 ` Giorgos Keramidas 2009-12-31 13:53 ` Juanma Barranquero 2009-12-31 14:08 ` David Kastrup @ 2009-12-31 14:12 ` Eli Zaretskii 2009-12-31 19:08 ` Stefan Monnier 3 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2009-12-31 14:12 UTC (permalink / raw) To: Giorgos Keramidas; +Cc: lekktu, schwab, emacs-devel > From: Giorgos Keramidas <keramida@ceid.upatras.gr> > Cc: Andreas Schwab <schwab@linux-m68k.org>, lekktu@gmail.com, > emacs-devel@gnu.org > Date: Thu, 31 Dec 2009 15:43:57 +0200 > > On Thu, 31 Dec 2009 07:23:28 -0500, Eli Zaretskii <eliz@gnu.org> wrote: > >> From: Andreas Schwab <schwab@linux-m68k.org> > >> Cc: lekktu@gmail.com, keramida@ceid.upatras.gr, emacs-devel@gnu.org > >> Date: Thu, 31 Dec 2009 12:44:46 +0100 > >> > >> Eli Zaretskii <eliz@gnu.org> writes: > >> > >> > Are you suggesting that the commit message should not mention the > >> > changes in individual files at all, just the general idea? > >> > >> Yes, that's what they are for. > > > > But then the corresponding ChangeLog entries should have the text > > identical or very similar to the commit message in front of them, or > > else have some other means of locating the log entries easily. > > I think it's very useful to see file changes in the ChangeLog. The issue at hand is whether to have them in the commit messages, not in ChangeLog. ChangeLog entries always include file and function information, it's been like that since day one. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 13:43 ` Giorgos Keramidas ` (2 preceding siblings ...) 2009-12-31 14:12 ` Eli Zaretskii @ 2009-12-31 19:08 ` Stefan Monnier 3 siblings, 0 replies; 97+ messages in thread From: Stefan Monnier @ 2009-12-31 19:08 UTC (permalink / raw) To: Giorgos Keramidas; +Cc: lekktu, Eli Zaretskii, Andreas Schwab, emacs-devel > Maybe we can try to strike a balance between not keeping the ChangeLog > up to date at all and making it difficult to commit *one* changeset that > includes both ChangeLog updates _and_ file updates by committing the > ChangeLog updates separately? This way, we can have a very short > summary in the ChangeLog commit, e.g.: No, don't. It's very simple to do it in a single commit: use C-x 4 a as usual to write the ChangeLog, then use C-c C-a in the *vc-commit* buffer to pull the ChangeLog text and then C-c C-c to do the commit of all the files (including the ChangeLog). The text is duplicated but written only once and that's what counts. We may reconsider this in the future by dropping the ChangeLog file (aka auto-constructing it from the commit logs), but not now. Stefan ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2009-12-31 9:21 ` Andreas Schwab 2009-12-31 10:11 ` Eli Zaretskii @ 2009-12-31 12:20 ` Juanma Barranquero 1 sibling, 0 replies; 97+ messages in thread From: Juanma Barranquero @ 2009-12-31 12:20 UTC (permalink / raw) To: Andreas Schwab; +Cc: Giorgos Keramidas, Emacs developers On Thu, Dec 31, 2009 at 10:21, Andreas Schwab <schwab@linux-m68k.org> wrote: > ChangeLog entries and commit messages serve a different purpose. > ChangeLog entries describe the "physical" changes, a commit message the > "logical" change. That is, the commit message describes the changeset > on a higher level than the ChangeLog entries. As such it does not make > sense to repeat the ChangeLog entries in the commit message. We have plenty of ChangeLog entries that describe both, because it is (or it was, with CVS) much easier/faster to look at the ChangeLog than the cvs log. And most projects do survive withouth ChangeLogs, by using the commit logs, and having a good interface to the VCS to make the diffs easy to access. I think your distinction is theoretically sound, but as a policy difficult to implement. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Workflow to accumulate individual changes? 2009-12-30 21:34 Workflow to accumulate individual changes? Juanma Barranquero ` (2 preceding siblings ...) 2009-12-30 22:54 ` Giorgos Keramidas @ 2010-01-01 12:33 ` Stephen J. Turnbull 2010-01-02 1:56 ` Juanma Barranquero 3 siblings, 1 reply; 97+ messages in thread From: Stephen J. Turnbull @ 2010-01-01 12:33 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Emacs developers Juanma Barranquero writes: > Let's suppose I want to create a local post-23.2 branch where I do > want to commit small changes to install on the trunk post-release. I > don't want to be forced to create a task branch for every one of them, > because they are small changes, and a new branch implies having to > bootstrap[1] anew. So I'd like to accumulate the changes into a single > branch. I don't understand what you're concerned about (yes, I've seen the followup which includes the footnote). If you follow the procedure for creating a shared repository (described in BzrForEmacsDevs, among other places), then all branches under the shared repository directory share storage, and creating a branch is very cheap (ie, the cost of copying the tree, which is small since you can use hardlinks).[1] I would think this would be fine for anything requiring more than one commit. In any case, I think it would be worth trying, you might find it's perfectly satisfactory. You can make this slightly cheaper by using "checkout --lightweight" (but the main cost is still creating the tree). If you have a series of one-commit changes, the cheapest way to do it would be with rebase. (N.B. I can't help you with "bzr rebase" itself, I've never used it.) The idea would be to put each commit in the same branch. You will almost certainly have exactly one conflict per ChangeLog you touch, but after that your commits will take place on top of the previous one, and should be fine (at least, I think bzr is smart enough not to conflict again). > Once the trunk is open again, what would be the procedure to install > the changes? If you follow any of the above, you would just follow the usual procedure for installing as described in BzrForEmacsDevs. > Obviously not "bzr merge ../post-23.2", because that would create a > single [merge] commit. Yup, see attached script[2]. I don't have a plugin, but I have a script that you can use to simulate the workflow you propose (if you're on Windows you'll need to .BATify or use Cygwin). Tested and works on Gentoo GNU/Linux. Two workflows I tried unsuccessfully are also documented there for posterity. Footnotes: [1] You may need to tune the branch command to use hardlinks instead of copies. [2] # set up a trunk mirror as usual # test code: uncomment next statement to test TESTP=t if test -n "$TESTP"; then newfile () { echo $1 > $1; bzr add $1; } addlog () { echo $1 > .tmp0; cat .tmp0 ChangeLog > .tmp1; mv .tmp1 ChangeLog; } cd /tmp mkdir shared-repo cd shared-repo bzr init-repo mkdir remote-trunk cd remote-trunk bzr init newfile ChangeLog newfile foo bzr commit -m "add foo" cd .. bzr checkout remote-trunk trunk fi # set up your post 23.2 branch bzr branch trunk post-23.2 cd post-23.2 # hack ... commit ... hack ... commit ... until trunk open # more test code if test -n "$TESTP"; then newfile bar addlog 'add bar' bzr commit -m 'add bar' newfile baz addlog 'add baz' bzr commit -m 'add baz' # simulate concurrent work cd ../remote-trunk newfile quux addlog 'add quux' bzr commit -m 'add quux' fi # here's the install procedure itself cd ../trunk bzr update # trunk is now up-to-date cd ../post-23.2 # durn, in testing the update fails, branches have diverged # bzr update # durn, in testing the merge --pull succeeds but leaves you with the # remote changes at the top bzr merge --pull # what I hoped for but doesn't actually work (it creates a true merge # rather than a fast forward) # cd ../trunk # bzr pull ../post-23.2 ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-01 12:33 ` Stephen J. Turnbull @ 2010-01-02 1:56 ` Juanma Barranquero 2010-01-02 2:28 ` Óscar Fuentes 2010-01-02 3:46 ` Stephen J. Turnbull 0 siblings, 2 replies; 97+ messages in thread From: Juanma Barranquero @ 2010-01-02 1:56 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Emacs developers On Fri, Jan 1, 2010 at 13:33, Stephen J. Turnbull <stephen@xemacs.org> wrote: > I don't understand what you're concerned about (yes, I've seen the > followup which includes the footnote). Well, if you read the note, you know what am I concerned about: not the time for checking out the files, but the time to get the branch in a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s, while "make bootstrap" is ~20min. The only fix for that is creating a script to copy .o, .elc and other generated files from another branch. Quite a fuss just to commit (and store for the future) a one-liner; that's why I think of having a branch for these micro-issues. (Well, colocated branches à la git would be wonderful for this case...) > and creating a branch is very cheap (ie, the cost of > copying the tree, which is small since you can use hardlinks).[1] As I've said above, it's not the time to create the branch that worries me; that said, Bazaar does not support hardlinks on Windows, AFAIK. > I would think this would be fine for anything requiring more than one > commit. In any case, I think it would be worth trying, you might find > it's perfectly satisfactory. For more serious changes yes, absolutely. > If you have a series of one-commit changes, the cheapest way to do it > would be with rebase. That seems to be the consensus, yes. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 1:56 ` Juanma Barranquero @ 2010-01-02 2:28 ` Óscar Fuentes 2010-01-02 2:50 ` Juanma Barranquero ` (2 more replies) 2010-01-02 3:46 ` Stephen J. Turnbull 1 sibling, 3 replies; 97+ messages in thread From: Óscar Fuentes @ 2010-01-02 2:28 UTC (permalink / raw) To: emacs-devel Juanma Barranquero <lekktu@gmail.com> writes: > On Fri, Jan 1, 2010 at 13:33, Stephen J. Turnbull <stephen@xemacs.org> wrote: > >> I don't understand what you're concerned about (yes, I've seen the >> followup which includes the footnote). > > Well, if you read the note, you know what am I concerned about: not > the time for checking out the files, but the time to get the branch in > a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s, > while "make bootstrap" is ~20min. The only fix for that is creating a > script to copy .o, .elc and other generated files from another branch. > Quite a fuss just to commit (and store for the future) a one-liner; > that's why I think of having a branch for these micro-issues. (Well, > colocated branches à la git would be wonderful for this case...) https://launchpad.net/bzr-loom It is underdocumented, but it works AFAIK. You can search the internet for experiences with it. OTOH, some people emulate colocated branches with `bzr switch'. The idea is that you have a checkout for hacking that you bind to wathever branch you chose to work on. For example, lets suppose that you created your working checkout with: bzr co trunk my-playground # you need to do this only once from now on, when you need a small feature, you create a branch for it: bzr branch --no-tree trunk fix-foo this is a very fast and inexpensive operation on a shared repository, as it doesn't even require to create the working tree. Now, if you want to work on `fix-foo', from `my-playground' you do bzr switch ../fix-foo you do something and, eventually bzr commit -m "done!" this will update `fix-foo'. Later, you can proced to merge the changes from `fix-foo' into `trunk' as usual (taking care of the ChangeLog issue.) If now you wish to work on a new micro-feature: cd .. # from `my-playground' bzr branch --no-tree fix-bar cd my-playground bzr status # Test that you don't have pending changes! bzr switch ../fix-bar Note that, within a shared repository, you can organize your branches as you wish, so it is advisable to make a directory `delayed-changes' and create your mini-feature branches there. [snip] -- Óscar ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 2:28 ` Óscar Fuentes @ 2010-01-02 2:50 ` Juanma Barranquero 2010-01-02 9:11 ` Eli Zaretskii 2010-01-02 13:17 ` Juanma Barranquero 2 siblings, 0 replies; 97+ messages in thread From: Juanma Barranquero @ 2010-01-02 2:50 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel On Sat, Jan 2, 2010 at 03:28, Óscar Fuentes <ofv@wanadoo.es> wrote: > https://launchpad.net/bzr-loom > > It is underdocumented, but it works AFAIK. You can search the internet > for experiences with it. Yes, I know about loom, though I've not used it. And YES, it is underdocumented :-) AFAICS, looms are similar to colocated branches, but threads are sorted, i.e., they have an order dependency. > OTOH, some people emulate colocated branches with `bzr switch'. The idea > is that you have a checkout for hacking that you bind to wathever branch > you chose to work on. For example, lets suppose that you created your > working checkout with: And, in this case, my-playground would be usually in a runnable state, and "bzr switch ../fix-foo" would only touch the updated files, minimizing recompilation. Right? Neat idea, I'm gonna give it a try. Thanks! Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 2:28 ` Óscar Fuentes 2010-01-02 2:50 ` Juanma Barranquero @ 2010-01-02 9:11 ` Eli Zaretskii 2010-01-02 13:20 ` Juanma Barranquero 2010-01-02 13:17 ` Juanma Barranquero 2 siblings, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2010-01-02 9:11 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > From: Óscar_Fuentes <ofv@wanadoo.es> > Date: Sat, 02 Jan 2010 03:28:31 +0100 > > If now you wish to work on a new micro-feature: > > cd .. # from `my-playground' > bzr branch --no-tree fix-bar > cd my-playground > bzr status # Test that you don't have pending changes! > bzr switch ../fix-bar Why is "bzr status" above important? what happens if I do have pending changes before switching? ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 9:11 ` Eli Zaretskii @ 2010-01-02 13:20 ` Juanma Barranquero 0 siblings, 0 replies; 97+ messages in thread From: Juanma Barranquero @ 2010-01-02 13:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel On Sat, Jan 2, 2010 at 10:11, Eli Zaretskii <eliz@gnu.org> wrote: > Why is "bzr status" above important? It shouldn't be needed, though it seems sensible to do it before switching your tree... > what happens if I do have pending > changes before switching? They get merged: [...] the working tree is updated and uncommitted changes are merged. The user can commit or revert these as they desire. Pending merges need to be committed or reverted before using switch. Conflicts are marked as expected. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 2:28 ` Óscar Fuentes 2010-01-02 2:50 ` Juanma Barranquero 2010-01-02 9:11 ` Eli Zaretskii @ 2010-01-02 13:17 ` Juanma Barranquero 2 siblings, 0 replies; 97+ messages in thread From: Juanma Barranquero @ 2010-01-02 13:17 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel On Sat, Jan 2, 2010 at 03:28, Óscar Fuentes <ofv@wanadoo.es> wrote: > OTOH, some people emulate colocated branches with `bzr switch'. It works like a charm. > Note that, within a shared repository, you can organize your branches as > you wish, so it is advisable to make a directory `delayed-changes' and > create your mini-feature branches there. The fact that the branch for "bzr switch BRANCH" can be relative to the parent dir makes this even easier. It'd be worth documenting this somewhere to give it this higher visibility, IMO, than a single paragraph in bzr help checkouts: Another possible use for a checkout is to use it with a treeless repository containing your branches, where you maintain only one working tree by switching the master branch that the checkout points to when you want to work on a different branch. BTW, what's the use of "branch --switch"? Something like this: # trunk/ (main mirror) # my-playground/ ("working" checkout) # delayed-changes/branch1, branch2, etc. (treeless branches) # from my-playground bzr branch --no-tree --switch ../trunk ../delayed-changes/branchN so you create a new branch and switch to it in a single op? Sweet, worth of an alias. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 1:56 ` Juanma Barranquero 2010-01-02 2:28 ` Óscar Fuentes @ 2010-01-02 3:46 ` Stephen J. Turnbull 2010-01-02 9:10 ` Eli Zaretskii 2010-01-02 13:39 ` Juanma Barranquero 1 sibling, 2 replies; 97+ messages in thread From: Stephen J. Turnbull @ 2010-01-02 3:46 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Emacs developers Juanma Barranquero writes: > Well, if you read the note, you know what am I concerned about: not > the time for checking out the files, but the time to get the branch in > a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s, > while "make bootstrap" is ~20min. Ah, I skipped over that. The way that is often recommended to handle that is to have a test tree, which is setup as a checkout. So bzr branch trunk build-test cd build-test make bootstrap make test # if you like, but should be OK :-) for i = 1 2 3; do cd .. bzr branch trunk fix$i cd fix$i # hack bzr commit -m "fix$i" cd ../build-test bzr checkout ../fix$i make # Look Ma, no 'bootstrap'! make test done YMMV, and caveat hacer: I haven't used this workflow personally, nor have I tested that my command syntax is correct. > (Well, colocated branches à la git would be wonderful for this > case...) Maybe someday, but AFAICS the main candidates for developing such (Aaron Bentley and Robert Collins) are putting their efforts into quilt-cum-VCS efforts ("pipelines" and "looms", respectively). Somebody like you who has a fair amount of DVCS knowledge already (I don't know how much that is exactly but I'm pretty sure from your comments that it is sufficient for this) should look at pipelines (similar to Mercurial queues, and maybe Stacked Git) and looms. Pipelines really do have a sequential nature to them, which might or might not get in the way, and AFAIK they don't yet have an mq-like guard mechanism. Looms are an original idea of Robert's and some folks I really respect love them until the fur rubs off. In particular, they can sort of be abused in a "guard"-like fashion, I think. But it will require experimentation; neither pipelines nor looms are documented up to Bazaar's usual standards. (I agree with Eli about those standards, by the way; that's why I think experimenting with these requires "sufficient DVCS background".) > > If you have a series of one-commit changes, the cheapest way to do it > > would be with rebase. > > That seems to be the consensus, yes. The methods suggested above might be useful too. For one-off patches, I use mq all the time because Mercurial's support for colocated branches "should be indented 6 feet downward", at least from my relatively git-centric viewpoint. But I also use guards extensively because I often submit even one-offs for review, so it's not always the case that writing order is push order. I don't know offhand how to emulate guards in bzr. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 3:46 ` Stephen J. Turnbull @ 2010-01-02 9:10 ` Eli Zaretskii 2010-01-02 15:30 ` Stephen J. Turnbull 2010-01-02 13:39 ` Juanma Barranquero 1 sibling, 1 reply; 97+ messages in thread From: Eli Zaretskii @ 2010-01-02 9:10 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: lekktu, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Date: Sat, 02 Jan 2010 12:46:30 +0900 > Cc: Emacs developers <emacs-devel@gnu.org> > > bzr branch trunk build-test > cd build-test > make bootstrap > make test # if you like, but should be OK :-) > for i = 1 2 3; do > cd .. > bzr branch trunk fix$i > cd fix$i > # hack > bzr commit -m "fix$i" > cd ../build-test > bzr checkout ../fix$i > make # Look Ma, no 'bootstrap'! > make test > done What is the semantics of "bzr checkout ../fix$i" in this case? What does it do, exactly? Bazaar docs are not very clear on that, to say the least: Purpose: Create a new checkout of an existing branch. But fix$i is already an existing branch, and one with local changes, so this ``create'' seems not quite the right word here. Usage: bzr checkout [BRANCH_LOCATION] [TO_LOCATION] Description: If BRANCH_LOCATION is omitted, checkout will reconstitute a working tree for the branch found in ‘.’. [...] If the TO_LOCATION is omitted, the last component of the BRANCH_LOCATION will be used. In other words, “checkout ../foo/bar” will attempt to create ./bar. If the BRANCH_LOCATION has no / or path separator embedded, the TO_LOCATION is derived from the BRANCH_LOCATION by stripping a leading scheme or drive identifier, if any. For example, “checkout lp:foo-bar” will attempt to create ./foo-bar. Again, ``create ./bar'' sounds incorrect in the context of your suggestion. ``Reconstitute a working tree'', OTOH, sounds too obscure to help. So what does this "checkout" do in this case? (Btw, note the tricky convention regarding slashes, not for the faint of heart IMO.) ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 9:10 ` Eli Zaretskii @ 2010-01-02 15:30 ` Stephen J. Turnbull 2010-01-02 17:05 ` Eli Zaretskii 0 siblings, 1 reply; 97+ messages in thread From: Stephen J. Turnbull @ 2010-01-02 15:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, emacs-devel Eli Zaretskii writes: > > From: "Stephen J. Turnbull" <stephen@xemacs.org> > > Date: Sat, 02 Jan 2010 12:46:30 +0900 > > Cc: Emacs developers <emacs-devel@gnu.org> Urk, I'd been working in Mercurial and mixed semantics. (I really, really hate the way all the DVCSes insist on using each others' command names and features but with different semantics attached to the same name.) I think Óscar got it right, though. After testing, this should be revised as below > > bzr branch trunk build-test A lightweight checkout is often recommended here instead of branch: bzr checkout --lightweight trunk build-test It's more efficient. > > cd build-test > > make bootstrap > > make test # if you like, but should be OK :-) > > for i = 1 2 3; do > > cd .. > > bzr branch trunk fix$i > > cd fix$i > > # hack > > bzr commit -m "fix$i" > > cd ../build-test Oops, this is where I went WRONG: > > bzr checkout ../fix$i RIGHT: bzr switch ../fix$i > > make # Look Ma, no 'bootstrap'! > > make test > > done > > What is the semantics of "bzr checkout ../fix$i" in this case? What > does it do, exactly? (Checkout in fact will error here, or perhaps produce a fix$i subtree. Not what you want.) "bzr switch fix$i" says Purpose: Set the branch of a checkout and update. Usage: bzr switch TO_LOCATION Options: --force Switch even if local commits will be lost. -v, --verbose Display more information. -q, --quiet Only display errors and warnings. --usage Show usage message and options. -b, --create-branch Create the target branch from this one before switching to it. -h, --help Show help message. Description: For lightweight checkouts, this changes the branch being referenced. For heavyweight checkouts, this checks that there are no local commits versus the current bound branch, then it makes the local branch a mirror of the new location and binds to it. # In informal terms, the above says "this workspace now refers to the # new branch for VCS information." In both cases, the working tree is updated and uncommitted changes are merged. The user can commit or revert these as they desire. # The update happens automatically and immediately upon "bzr switch". # In the workflow described above, the "uncommitted changes" are the # build products generated by "make bootstrap", "make", and "make # test". In this workflow, no commits should ever happen in this # tree; it is purely for the convenience of testing since you will # have a usable bootstrapped tree. (Of course if the changes from # branch "fix1" to branch "fix2" would have broken the build and need # a new "make bootstrap" under CVS, you'll need that here, too.) Pending merges need to be committed or reverted before using switch. # The workflow described above should have no pending merges in this # tree. The only VCS operation you do here after initialization is # "bzr switch", which is sort of like "cvs update -r" for this workflow. The path to the branch to switch to can be specified relative to the parent directory of the current branch. For example, if you are currently in a checkout of /path/to/branch, specifying 'newbranch' will find a branch at /path/to/newbranch. # Don't you just love DWIM? Bound branches use the nickname of its master branch unless it is set locally, in which case switching will update the the local nickname to be that of the master. # I don't know what the above means, exactly; I don't use nicknames. > Bazaar docs are not very clear on that, to say the least: > > Purpose: Create a new checkout of an existing branch. > > But fix$i is already an existing branch, and one with local changes, > so this ``create'' seems not quite the right word here. My bad, I did warn that my syntax might be wrong. > (Btw, note the tricky convention regarding slashes, not for the faint > of heart IMO.) Heh. Emacsen users should be used to such things, though. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 15:30 ` Stephen J. Turnbull @ 2010-01-02 17:05 ` Eli Zaretskii 0 siblings, 0 replies; 97+ messages in thread From: Eli Zaretskii @ 2010-01-02 17:05 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: lekktu, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Cc: lekktu@gmail.com, > emacs-devel@gnu.org > Date: Sun, 03 Jan 2010 00:30:44 +0900 > > > > cd build-test > > > make bootstrap > > > make test # if you like, but should be OK :-) > > > for i = 1 2 3; do > > > cd .. > > > bzr branch trunk fix$i > > > cd fix$i > > > # hack > > > bzr commit -m "fix$i" > > > cd ../build-test > > Oops, this is where I went WRONG: > > > > bzr checkout ../fix$i > > RIGHT: > > bzr switch ../fix$i [snip] Thanks, I'm saving these recipes for when I will need them. ^ permalink raw reply [flat|nested] 97+ messages in thread
* Re: Workflow to accumulate individual changes? 2010-01-02 3:46 ` Stephen J. Turnbull 2010-01-02 9:10 ` Eli Zaretskii @ 2010-01-02 13:39 ` Juanma Barranquero 1 sibling, 0 replies; 97+ messages in thread From: Juanma Barranquero @ 2010-01-02 13:39 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Emacs developers On Sat, Jan 2, 2010 at 04:46, Stephen J. Turnbull <stephen@xemacs.org> wrote: > Somebody like you who has a fair amount of DVCS knowledge already (I > don't know how much that is exactly Not much, though a lot more than a couple months ago :-) > should look at pipelines > (similar to Mercurial queues, and maybe Stacked Git) and looms. Yes, I have both installed. But when you say > neither pipelines nor looms are > documented up to Bazaar's usual standards. that's an understatement :-) After reading "bzr help loom", the first question is, well, what's exactly a loom and what it is good for? There are too many assumptions and too few clear statements of purpose and use cases. pipeline is slightly better documented. Juanma ^ permalink raw reply [flat|nested] 97+ messages in thread
end of thread, other threads:[~2010-01-05 8:50 UTC | newest] Thread overview: 97+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-12-30 21:34 Workflow to accumulate individual changes? Juanma Barranquero 2009-12-30 21:37 ` Juanma Barranquero 2009-12-30 21:46 ` Óscar Fuentes 2009-12-30 23:57 ` Juanma Barranquero 2009-12-31 0:21 ` Óscar Fuentes 2009-12-31 0:27 ` Juanma Barranquero 2009-12-31 1:04 ` Óscar Fuentes 2009-12-31 1:33 ` Juanma Barranquero 2009-12-31 1:48 ` Óscar Fuentes 2009-12-31 2:22 ` Juanma Barranquero 2009-12-31 4:21 ` Eli Zaretskii 2009-12-31 4:36 ` Juanma Barranquero 2009-12-31 5:12 ` Miles Bader 2009-12-31 10:15 ` Eli Zaretskii 2009-12-31 10:44 ` Eli Zaretskii 2009-12-31 12:37 ` Juanma Barranquero 2009-12-31 19:44 ` Karl Fogel 2009-12-31 20:16 ` Eli Zaretskii 2009-12-31 20:41 ` Juanma Barranquero 2010-01-01 2:54 ` Richard Stallman 2010-01-01 12:35 ` Stephen J. Turnbull 2010-01-01 13:49 ` Stephen J. Turnbull 2009-12-31 5:06 ` Óscar Fuentes 2009-12-31 10:26 ` Eli Zaretskii 2009-12-31 12:28 ` Juanma Barranquero 2009-12-31 18:27 ` Eli Zaretskii 2009-12-31 18:59 ` Óscar Fuentes 2009-12-31 20:39 ` Juanma Barranquero 2010-01-01 13:53 ` Stephen J. Turnbull 2010-01-01 14:38 ` Eli Zaretskii 2009-12-30 22:54 ` Giorgos Keramidas 2009-12-31 0:11 ` Juanma Barranquero 2009-12-31 9:21 ` Andreas Schwab 2009-12-31 10:11 ` Eli Zaretskii 2009-12-31 11:44 ` Andreas Schwab 2009-12-31 12:23 ` Eli Zaretskii 2009-12-31 12:38 ` Juanma Barranquero 2009-12-31 13:25 ` Eli Zaretskii 2009-12-31 13:37 ` Juanma Barranquero 2009-12-31 14:13 ` Eli Zaretskii 2009-12-31 13:43 ` Giorgos Keramidas 2009-12-31 13:53 ` Juanma Barranquero 2009-12-31 14:07 ` Alfred M. Szmidt 2009-12-31 14:16 ` Juanma Barranquero 2010-01-01 15:38 ` Alfred M. Szmidt 2010-01-01 17:53 ` David Kastrup 2010-01-01 2:55 ` Richard Stallman 2010-01-01 4:03 ` Óscar Fuentes 2010-01-01 8:41 ` Eli Zaretskii 2010-01-01 10:04 ` Óscar Fuentes 2010-01-02 15:44 ` Richard Stallman 2010-01-01 12:19 ` Andreas Schwab 2010-01-01 14:33 ` Eli Zaretskii 2010-01-01 14:48 ` Andreas Schwab 2010-01-01 19:18 ` Karl Fogel 2010-01-01 19:56 ` Eli Zaretskii 2010-01-01 20:09 ` Chong Yidong 2010-01-01 21:34 ` Eli Zaretskii 2010-01-01 20:13 ` Karl Fogel 2010-01-01 21:35 ` Eli Zaretskii 2010-01-01 21:25 ` Óscar Fuentes 2010-01-01 21:34 ` Eli Zaretskii 2010-01-01 22:58 ` Andreas Schwab 2010-01-01 20:07 ` Teemu Likonen 2010-01-01 20:12 ` Karl Fogel 2010-01-01 21:08 ` Teemu Likonen 2010-01-02 5:00 ` Stephen J. Turnbull 2010-01-02 5:12 ` Karl Fogel 2010-01-02 5:24 ` Miles Bader 2010-01-02 11:43 ` Juanma Barranquero 2010-01-02 12:09 ` Miles Bader 2010-01-02 19:22 ` Karl Fogel 2010-01-05 8:50 ` Stephen J. Turnbull 2010-01-02 4:37 ` Stephen J. Turnbull 2010-01-01 14:59 ` Stephen J. Turnbull 2010-01-01 15:30 ` Eli Zaretskii 2010-01-01 15:38 ` Alfred M. Szmidt 2009-12-31 14:08 ` David Kastrup 2009-12-31 19:47 ` Karl Fogel 2009-12-31 20:14 ` Chong Yidong 2009-12-31 20:36 ` Óscar Fuentes 2009-12-31 20:44 ` Juanma Barranquero 2009-12-31 14:12 ` Eli Zaretskii 2009-12-31 19:08 ` Stefan Monnier 2009-12-31 12:20 ` Juanma Barranquero 2010-01-01 12:33 ` Stephen J. Turnbull 2010-01-02 1:56 ` Juanma Barranquero 2010-01-02 2:28 ` Óscar Fuentes 2010-01-02 2:50 ` Juanma Barranquero 2010-01-02 9:11 ` Eli Zaretskii 2010-01-02 13:20 ` Juanma Barranquero 2010-01-02 13:17 ` Juanma Barranquero 2010-01-02 3:46 ` Stephen J. Turnbull 2010-01-02 9:10 ` Eli Zaretskii 2010-01-02 15:30 ` Stephen J. Turnbull 2010-01-02 17:05 ` Eli Zaretskii 2010-01-02 13:39 ` Juanma Barranquero
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.