Re: reversion revulsion

[Thien-Thi Nguyen]

() Juanma Barranquero <address@hidden>
() Fri, 8 Jan 2010 11:53:40 +0100

   > That's just from a correctness pov.  I dread the performance
   > implications of having to do (and possibly screwing up):
   >
   > cd .../trunk                        # 0
   > bzr update                          # 1
   > bzr merge ../quickfixes             # 2
   > bzr commit                          # 3
   > bzr revert --forget-merges          # 4
   >
   > IIUC step 3 publishes, as does step 4, defeating atomicity.

   What would #4 do?

After reading your recent reply, i believe i have misunderstood
"bzr revert --forget-merges", which should be #3, bumping the
"bzr commit" rightly to #4.  In that case, there is no problem;
we get the equivalent (almost) to what "git merge --squash" does.
Cool.

I suppose from a policy pov, it would be good to distinguish
between "presentable" and "private" local-branch history, the
former being log entries written with publishing in mind.  In
that case, plain "bzr merge" seems to DTRT.

On the other hand, with private local-branch history (e.g.,
a series of log entries of the type "going to lunch", etc),
something like:

bzr-merge-squash () { bzr merge ;
  bzr log | grep INTERESTING-LOG-ENTRIES > LOG-ENTRY-INIT ;
  bzr revert --forget-merges ; }

is more suited (followed by "bzr commit -f LOG-ENTRY-INIT"),
and everyone defines INTERESTING-LOG-ENTRIES as they see fit.
Am i back on the right page now?

thi