"bzr status" in a lightweight checkout

[Stephen J. Turnbull]

Martin Pool writes:
 > On 11 August 2010 04:58, Stephen J. Turnbull <stephen at xemacs.org>
 > wrote:

 > > To be honest, I've never missed a check for changes upstream.  I
 > > don't think in 15 years of CVS usage I can recall more than one
 > > or two cases where I wanted to know where upstream was, but *not*
 > > update my local workspace.

 > It's not precisely a check for changes upstream.  (Well, depending
 > on precisely how one defines 'upstream'.)  It's a check for the
 > working tree being out of date with its branch, which may be be
 > 'upstream' if you're in a checkout of trunk, or might be just your
 > own branch.

OK, I acknowledge that the choice of "upstream" was bad.  What I meant
is that I don't care if the tip of the branch is no longer equal to
the parent revision of my workspace.  I personally would not want that
check done by "$VCS status".  "bzr missing" is exactly what I want: a
separate command to get that information when I need it (in the twice
in fifteen years case that "bzr update" is for some reason
inappropriate).

 > I'm not sure if you can create that situation in git.

You can create multiple working trees from different parent revisions
on the same current branch by using GIT_DIR or GIT_WORK_TREE.
However, this would be a bad idea (except in very stylized workflows)
since a commit in work-tree-a followed by a commit in work-tree-b
would effectively revert all the changes recorded by the work-tree-a
commit, and there's no way in git to distinguish parent revisions from
the branch head.  (One could argue a skew between a local branch and
its associated tracking branch would be similar to the situation in
bzr in a certain sense, but since you *never* work in a tracking
branch unless you're suicidal, it's not the same.)

Of course in git there's no need to record a parent other than the
branch head, since "git checkout -b tmp" is very cheap in both time
and space, and the git UI makes it hard to separate the branch from
the working tree (you have to mess with command line options or
environment variables).  What can happen easily is a "detached head,"
which is created by checking out a commit directly (instead of
indirectly via a branch).  Then there is no branch associated with the
workspace, but the HEAD is a head (ie, can be committed to).  This is
a bad idea, of course, because it's easy to forget that you made those
changes, but apparently it's not something that people tend to do in
practice, so not a problem.

So yes, I think you can create similar situations in git, but the git
UI strongly discourages workflows where it might cause problems.

The thing is, I can't really see a use case for a lightweight checkout
of a personal branch (which might be a mirror of upstream, the point
is that it's local) that isn't equally well-served by git-style
colocated branches with shared repositories.  AFAICS lightweight
checkouts only have semantic significance if checkouts are used to
ensure frequent synchronization of team's work.  But in that case I
would expect that the branch is likely to be located across a network,
possibly a WAN, in which case going out on the network as a matter of
course is a recipe for unnecessary latency.