two branches, cherrypicking when merging.

[Uwe Brauer]

>>> "Steve" == Steve Fink <sphink at gmail.com> writes:

   > It sounds like this does not match your preferred workflow, but just as a
   > comparison point, I would use a bookmark for Uwe instead of a named branch,
   > then:
well I know a lot of people prefer bookmarks over named brances, since
bookmark are so flexible, you can move, you can delete them ......



   > - record -i -m WIP # select the work in progress
   > - commit -m 'mainline bugfix'
   > - rebase -d default -s <mainline bugfix rev>

   > Then I'd push the bugfix, update to the work in progress, and probably just
   > make my additional changes in the working directory and amend them in,
   > eventually doing a chistedit to smush the changes together, or split to
   > break them apart. Or more likely, amend a bunch of things into one big
   > blob, uncommit -a, amend -i -m ..., record -i -m ..., record -i -m ..., etc.

   > I'm sure named branches are great for some people, for something.
   > For me, I want to be able to just start changing stuff, and decide
   > later which topological head each part of my changes belongs to.

However when I analyze a graph with bookmarks and I am not on the tip it
is difficult to know to which branch a particular part of the graph
belongs. For named branches that task is easy.


   > If a nondefault named branch gets recorded when I commit something,
   > it's just as likely as not to be a lie. So I'd rather stick to
   > telling truths: I am modifying whatever it is that I have checked
   > out, I'm recording independent pieces, then I'm moving them to the
   > appropriate topological head and removing them (if necessary) from
   > whatever I have checked out. No lies, just accurate recordings of
   > intermediate state.


   > Though it really isn't semantically different when using named branches.
   > They just make me feel like I'm promising too much when I use them.


That is strange: I feel the other way around. I find the use of bookmarks
and especially the use of rebase as obscuring/lieing.

The feature I use most of rebase is the collapse option in order to
avoid clutter (and of course ammend for commit), but that feature I have
also in histedit, whose interface I find more user friendly. The
«transplant» feature of rebase I consider as obscuring things. A merge
is a merge is a merge, while rebase rewrites the histroy and lies to me.

The only situation I find it useful is when I want to contribute to a
repository I have *no* write  access to. Then I will use a bookmark and
finally rebase my stuff on top of master/default and send a patch for
inspection.