On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams <n...@cryptonector.com> wrote:
<snip>
Actually I agree with most of Mike Meyer's reply, but I wanted to pick
this paragraph apart:
> How many times have you submitted a patch to an upstream
Well, phrasing it like that says that you are thinking git-style anyway.
Let's assume a Fossil push with one commit nominated as "this is my
current contribution".
> and then been told to make a bunch of changes,
That's only to be expected, so you create a new commit based on your
previous nominated one, push it and tell them which is your new commit.
> re-organize your commits,
I don't see why they (the centre) should do that. It's the result that
matters, and if they want a pristine tree that includes only approved
commits they can do that. (See below.)
> make specific changes to specific commits,
Why, why, why? It's the result that matters, this is just rewriting
_your_ history because they feel like it.
> and/or squash commits?
Again, this is about them wanting a pristine tree. Their problem.
> Yeah, that's why rebase is good.
Rebase is a lie!
Rebase is a lie!
Rebase is a lie!
Now for the "pristine tree" thing. I don't agree with it but if that's
what the project leads want, they can
1) not permit pushes or syncs, only pulls, and take only real patches,
which they turn into commits themselves
or
2) have two repositories, a working rep which everybody syncs with, and
a clean one. Then have a command/script like
accept <commit-in-working-rep> <parent-in-clean-rep>
which creates a new child commit in the clean rep and does a pull back
into the working rep, and which is simple in concept, though there
will be issues about moves and deletes.
Working this way also raises issues about what to do with wiki pages,
tickets, and events.
These approaches are not the outright lie that rebase tends to be,
but merely the leads saying "here is the history of the things we have
approved". They are then depriving everyone of the history of blind
alleys (which will therefore be followed again and again) and of the
ideas whose time had not yet come (which will therefore have to be
re-invented from scratch, or may even be forgotten altogether!).
I think the correct way to deal with "unwanted" commits is to make proper
use of branches, and perhaps to have a UI option which shows only things
in a specified set of branches.
Incidentally, there is nothing stopping you, as a remote, barely-trusted
developer (which is what you are in that sort of scenario) from running
the two-repository process yourself, so that you sync only from your
"clean" repository.
I also think that much of the "mess" in repositories that people seem to
want to hide is the result of committing far too frequently, usually in
the mistaken belief that their VCS is some sort of backup system.
Eric
--
ms fnd in a lbry
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
