Re: [tlug] Open-source repository question

[Curt Sampson <cjs@example.com>]

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

> John Fremlin writes:
>
>  > Where does the implicit theory of patches diverge from the explicit (and 
>  >   misguided) one?
> 
> The assumption that two changes which conflict partially but are
> identical on the conflict are not in conflict.  David originally had
> this right but eventually bowed to pressure from the peanut gallery.

Hm? Colour me confused. (With your favourite graph-colouring algorithm,
of course. I look back now, and realize that the first sign that I
wasn't a real computing scientist was when I wanted more than four
colours in my box of crayons.)

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

> 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, but git-rebase seems to me to take things that are not really
conflicts and get rid of them.

> What git gets right here is that it is so cheap to keep *every
> change*, whether it conflicts with an existing branch or not, and if
> you're even a little bit worried, you can make a branch (or stash).
> What git really needs is the ability to listen to the programmer
> muttering under his breath and turn that into commit logs every 15
> seconds or so. :-)

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." I'd like to
say, "merging is very expensive," but for the purposes of this paper I
belive that the assertion of lesser strength will suffice. 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.)

>  > > Now, if you're Linus (or on a more personal note, Curt), you can keep
>  > > all that in your head.  I think that's why Curt can get away with
>  > > deprecating cheap branching as he did.

Actually, I don't keep this in my head; I'm not so good at doing so,
compared to many other very impressive programmers. I have a long post
on this from a few days ago in my postponed folder that I hope I might
get to one day.

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

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 for a few
days, if not a few weeks. My own private branch won't tell me that. Only
sharing (usually painfully, if it's any sort of signficant discovery)
will do so. 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.

Some of this is about whether you should be forced to make decisions
now, based on the best available data (what we who've done our
mail-order management courses know by the acronym B.A.D. decisions) or
whether you should do it later. I might be accused of being anti-agile
at this point, but I don't think I believe very much any more in
delayed decisions: delayed decisions are usually never made. (Or, more
accurately, were already made and never used the option to change.) ,,

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

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com