Re: [tlug] Open-source repository question

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > What happened with darcs', "these two file adds conflict, so delete them
 > both" algorithm?

That's a different issue.  I don't know what happened there, probably
a special case that wasn't properly special cased.

 > On 2009-07-22 21:33 +0900 (Wed), Stephen J. Turnbull wrote:

 > > Of course git has to worry about conflicts.  If it didn't, there would
 > > be no need for git-rebase --continue and/or git-rebase --skip.
 > 
 > That's a little, err.., facile. Perhaps I'm not entirely up to speed
 > on this,

I think you are not.  The --continue and --skip flags are applicable
only in the case where a merge conflict has occurred, and the rebase
cannot continue without human intervention.  At that point, it has to
do conflict marking and record metadata to allow convenient
continuation.  Does that make the intent clear, or am I missing
something?

 > While I see your point here, I'm going to claim that that sort of
 > thing is not really a good thing. My--(arm-waving, but I'm in good
 > company here)--"theory of patches," is that "merging is work."

Sure, but "cheap branching is good" doesn't depend on "merging is
(nearly) free".  It depends on "those who don't have history are
doomed to repeat the bad parts and forget the good parts".  Cheap
enough branching also means that the VCS can become an adjunct to your
editor.

 > More or less, my general thought is that quite often if you force
 > someone to make a decision earlier (i.e., delete one or the other
 > option now) as opposed to later (i.e., save both, and choose one
 > some time in the future) you'll save effort. And that this is in
 > the majority of cases true even if you take the other course later
 > on. (Huge, but very convincing, arm-waving here.)

I think you spend a lot of time writing relatively straightforward
dedicated apps, and not much working on maintenance of large-scale,
multi-module, complex, user-driven programs that were designed by
people who may or may not have been even brighter than you but sure as
shooting didn't think like you, and maintained by people who didn't
have the stamina to insist on quality control as you do.  I'm the
opposite (except that I *know* for sure that Jamie Zawinski and Ben
Wing are far better programmers than I :-), and I am 100% unconvinced
of anything by your arm-waving (except that maybe your boyhood dream
was to grow up to play for Yomiuri and get the nickname "Godzilla"?)

 > >  > Even with smaller scale projects (four or five people) it's incredibly 
 > >  > useful to be able to branch quickly to make changes that benefit one 
 > >  > feature but break a lot of others.
 > 
 > Well, yeah. I call that a "checkout." :-) 

Why not record it?  With really cheap branching, it can be done in the
background without you noticing it unless you want to.

 > But being rather less sarcastic for a moment, I do wonder about this.
 > There are some experiments in your codebase you can do all by yourself,
 > of course. But for a lot of the significant ones, I find I'm not sure
 > whether I've actually made some better sense of the world (or discovered
 > something about the world) until I involve a few other people

Sure.  So?  Cheap branches make that easy to do.  Problem is, you
can't *force* others to become involved with a branch, you have to
make them want to.  If everything goes into the mainline, hey, *fsck
you harder, you got NO choice, hah-ha!*  Maybe that's cool in a
company, but in a volunteer organization, that drives workers *out*.

Both those who feel abused by mainline churn, and those who lack the
confidence to think everything they write automatically belongs in the
mainline.  (Note, neither of these descriptions can be applied to the
business environment where goals are much clearer and presumably the
subject of consensus---whether by general approval or by management
fiat.)

 > And the cost of going back, not by a VCS revert command but by
 > painfully undoing what you've done, is just part of the risk.

What's wrong with going back via VCS revert?  (As long as that doesn't
mean deleting history, of course.)

 > Some of this is about whether you should be forced to make decisions
 > now, based on the best available data

Again, "forcing" is something that management should do, not the VCS.

 > > Heh.  It's a lot easier than that.  Git is a specialized Lisp with
 > > annotated conses (commits), multiway trees (trees), symbols (tags),
 > > and hash tables with stable universal hashes (all objects).
 > 
 > Oh, God. Sounds like a Lisp-2 instead of a Lisp-1. And with dynamic
 > scope to boot....

Dynamic scope?  No.  All the SHA-1 hashes that ever were already exist
and are not going to change.  You don't get more static than that.