Re: Slightly off topic, question about git

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> That git thinks of the whole content of the tree, and that a filter
> is applied to narrow the result set when you specify dirs or files,
> was mentioned before.  Changes your perspective.

Also breaks git for certain uses, though.  Much as I like git, there
are places where I'd like to use it but effectively can't because of
its insistence on owning an entire directory per repo as work tree.
This makes it impossible to, for example, keep one repo for ~/.cshrc, a
different repo for ~/.gdbinit, and a third for ~/.procmailrc, without
creating a directory somewhere for each one and playing games with
links.  But that's very different from its designed-for use case, so
it's not too surprising.

> Bisection lets you quickly navigate to a commit of interest.

Very useful.  I agree.

> When HEAD works for you, and an older version is said to have an
> issue, then 'git bisect' lets you identify the commit which probably
> introduced the change in behaviour.

Minor note: the command line ("git bisect good", "git bisect bad") is
designed for the reverse, where the earlier commit works and the later
commit doesn't.  People are more often interested in when bugs were
introduced than in when they were fixed.

> Linear history helps there.  That's again why rebase is useful.

Linear history is not necessary, though; git bisect can deal with
branches-and-merges just fine, at the cost of slightly more tests.
(Personally, I don't like rebasing.)

> Interactive add ('git add -u -p', and 'git reset -p' before 'git
> commit') lets you separate unrelated changes into individual commits
> as they should be.

Based on the documentation I've seen, though, they're somewhat
crippled, in that they work at diff-hunk granularity, and tend to be
single-pass - I haven't used them myself, because they depend on perl,
so I have to depend on documentation.  I wrote a curses tool that,
while still pre-alpha quality, does philosophically similar things
(without needing perl).

That it was feasible for me to write it is, I would say, another point
in favour of git, albeit a relatively mild one for most use cases.

> And do not mistake github.com the service provider or its many
> unaware users as representative for git-scm.org the tool and concept.

Eh.  The tool is git.  git-scm.org is a domain name (colloquially used
to refer to a website), not the tool.

> Though I can see how github enables those who otherwise would never
> have shared, or used a VCS at all, I strongly disagree with many
> things that are done at this site.

Me too.  I gave up on them partially when I discovered they thought the
MUSTs in the ssh spec didn't apply to them and they thus couldn't
interoperate with my ssh implementation; I gave up on them the rest of
the way when they, ironically enough, stopped supporting git's own
protocol for access to (supposedly) publicly accessible repos.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B