About git-thought [was: brisbane: initial cut at a mergeline cache]
robert.collins at canonical.com
Thu Apr 2 21:43:36 BST 2009
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
> 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
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?
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090403/e183c09b/attachment.pgp
More information about the bazaar