Re: Slightly off topic, question about git

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

>>> [H]istory rewriting seems to be a favorite pastime of git users.
>> That's not a fault of git; that's a fault of how some people use
>> git.
> Well, you could argue that it's a fault in git that it allows it.

> If there is a way, then some people will use it that way.

But, if there isn't, some people will add it.  git rebase is very
little more than a loop containing git cherry-pick.

>> No VCS is ever truly never-change, [...]
> Sure.  You can change history in CVS as well.  But you'll have to go
> in there and much with the data that is beind.

And in git, that's significantly harder to do than it is in CVS (well,
as I recall CVS; it's been long enough since I used it that my memory
is fuzzy).  If you just change (say) a commit message in the underlying
data, the resulting repo will be corrupt and will be noticed as corrupt
by certain operations; git is built on a foundation of a
content-addressible data store, in which a data blob's name is its
SHA-1.  Pointers are to that SHA-1, so if you change the contents you
will change the SHA-1 (unless you can second-preimage SHA-1 to give the
content you want).

> It's not like the UI itself allows you to work that way.

If the UI supports cherry-picks, the UI allows it.  As I remarked
above, rebasing is very little more than just a bunch of cherry-picks.

And I submit that a VCS that doesn't support cherry-picks is
significantly crippled.

> And I sortof can see why people want to go that way, since with
> distributed VCSs, it becomes much harder to have a linear history.
> But they still want to kindof/sortof fake it.

Some people do, perhaps.  Personally, I have no problem with merges.
My own repos, even those which have only me working on them, typically
include "Merge work from multiple machines" commits.

>> Not really; history doesn't _have_ to be rewritten.  That's what
>> merge commits are for.  People just choose to rebase work instead of
>> merging.
> It sortof have to.  Since if you've done various work, and others
> have done various work on the same files, and both have done commits,
> it might not be possible to merge as is.

Yes, merging can require manual assistance.  git includes tools to make
it easier to handle manual-assist merges; others exist as addons.

The need for them is one of the prices of the distributed model, just
as needing to manually perform much the same operations before
committing is a price of the centralized model.

> And so you'll have to rewrite parts that you already committed in
> order to get things back to a coherent state.

Merging two changesets that affect the same portions of the same files
inevitably will require that in some cases.

> This is a nasty problem when you have separate VCSs.  Well, it
> becomes nasty because somewhere in the end, you still have a master
> VCS, which holds the source of truth.  Distributed VCSs are not truly
> distributed.  There is still just one master.

Only if the humans involved insist on seeing it that way.  There is no
technical reason that has to be true.  git lends itself very well to
the "sure, fork it and see whose fork the userbase prefers" model.  Is
that a strength or a weakness?  Each use case has to decide that for
itself.

If the repo in question is used to produce a product with a single
distribution channel, then there will inevitably be some kind of master
in the sense of the one used to produce the distribution.  But that's
inevitable in that case; it's an artifact of the use case, nothing
inherent to the underlying VCS.

/~\ 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