About git-thought [was: brisbane: initial cut at a mergeline cache]

[Robert Collins]

On Fri, 2009-04-03 at 03:08 +0900, Stephen J. Turnbull wrote:
> Andrew Bennetts writes:
> 
>  > > If now you ask "what?", then you still don't get it.  There are lots
>  > 
>  > I don't know.  You're being awfully abstract...
> 
> Well, yes.  What I want is pretty abstract: I want access to the DAG.
> I don't want it dismembered, and the parts encapsulated in disjoint
> branches, simply because there happens to be a node there.
> 
> I want to be able to work with 3 or 4 branches simultaneously.  For
> example, in git you can say something like
> 
>     git log cairo earl ^master ^amd64-warnings
> 
> to get the log of commits that are in the cairo or earl branches, but
> not in the master (== trunk) or amd64-warnings branches.  Or

This is something nice we should definitely make possible in bzr.

> git checkout master
> for i in `git rev-list cairo earl ^master ^amd64-warnings`; do
>   git cherry-pick $i
> done
> 
> to cherry-pick all of them.

This is nearly as easy though a little more verbose.

> A more practical (and to me, workflow-relevant) example.  In writing
> up a presentation, I often do several rather different drafts of the
> same topic.  In that case, I'll typically represent my work as several
> branches from "yesterday's" version of the text, then merge.  Ie,
> rather than rewriting a draft in place, for each edit I branch,
> revert, and restart that part from scratch.  Like this:
> 
> git checkout master         # now I'm on trunk, where I left off yesterday
> 
> #     edit, decide I'm not satisfied, save the file
> 
> git commit -a -m "Nyet."
> git branch versionA         # I'm still on the trunk, but my work is safe
>                             # I know where to find it, in branch versionA
> git reset --hard master^    # "erase the blackboard"
> 
> #     mung until no good
> 
> Of course, the initial checkout is usually implicit, and I have a
> command defined in XEmacs so that the commit-branch-reset operation
> takes 3 keystrokes, plus typing the name of the new branch.  The time
> taken is the same as it takes to save the file, ie, imperceptibly
> short.

So, we have this ongoing unsolved disconnect between branches-are-urls
and making-new-trees-can-be-expensive. We need to come up with a
tasteful answer to that [which may well let us remove some of the
'cruft' :)]. That sais:
bzr checkout master working
#edit etc working
bzr commit -m "Nyet."
bzr push ../versionA # or bzr branch . ../versionA
bzr pull --overwrite ..master

Etc. Its totally sane, easy and fast [assuming a shared repo exists
at .., see the discussion about needing to fix the setup overhead there]
to work this way.

> I don't know what you think, but I think this is a decidedly weird
> workflow that no sane person would come up with.<wink>  But ... I did,
> I like it, and git lets me do it.  Easily, safely, and quickly.
> 
> How would you do that with a lightweight checkout?

See above.

> I'm also not clear on the concept of "aliases".  In git I don't need
> aliases, I just use tags (for "important" individual revisions) and
> branches (for dynamically developing versions).

One of the things git has by making the repository
the-place-where-branches-are is very reliable short names; we have a
nice solution too (see 'switch''s behaviour, but we haven't made it a
deep, automatic hook for all commands. We should.) I think your workflow
of tagging and branches is sensible - its what I do in bzr.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090403/e183c09b/attachment.pgp