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

[Stephen J. Turnbull]

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

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.

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.

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?

 > So, how would you like data-not-in-a-particular-ancestry to be
 > labelled (and what aliases would you like to be able to use to
 > refer to them)?

Hm?  What do you mean, "not in a particular ancestry"?  There is
no abiogenesis here, all my puppies have papers from the Kennel
Association, and all acknowledge the Grand Champion NULL as the
ultimate source of their line.  Usually they share more of their
pedigrees than that, of course.

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).