On Sun, Dec 30, 2012 at 12:40 AM, Michael Richter <ttmrich...@gmail.com> wrote:
> On 30 December 2012 14:19, Nico Williams <n...@cryptonector.com> wrote:
>>
>> > There are differing philosophies here. Some say it is important to
>> > present a clean, linear narrative of what took place - a narrative
>> > that is easy to follow and easy to understand. Others say that it is
>> > more important to present history as it actually occurred, in all its
>> > messy detail, not how you wish it had occurred. Git and Hg tend more
>> > toward the first view whereas Fossil leans toward the second.
>>
>> There's room for interpretation, and for persuasion.
>
>
> Not really, no. Any interpretation that says anything other than "it is
> more important to present history as it actually occurred" isn't
> interpretation, it's dissembling.
But you're coming around, check it:
>>
>> Fossil didn't always have private branched. It does now. Isn't that
>> a concession that sets precedent?
>
>
> I'd say the private branches pretty much eliminate your need for rebasing
> entirely given what you've described as rebasing. Make your mess in your
> private branches. Expose the pretty stuff in non-private branches.
>
> Problem solved.
Sure! You came around, see?
Except that it's not easy to clean up history in private branches with
fossil. You have to manually cherry-pick each commit from one branch
onto another in the order that you want. Either splitting or merging
commits (forget which) is harder still. git gives you a nice
interface for doing this.
>> At Sun, for example, we had official repos for products ("gates"),
>> project repos aiming at eventual integration into product gates, and
>> individual repos. Individuals pushed to either project gates or
>> product gates, depending on what they were working on. Product gates
>> were always archived and available, even for ancient releases of the
>> products. Project gates were generally (but not always) archived and
>> available. Individual repos were generally littered across the place,
>> with no real way for one to find them without asking the developer
>> working on them. History was cleaned prior to pushing to gates higher
>> up the hierarchy, but past history in product gates was never
>> rewritten. This worked spectacularly well. Who wants to see typos
>> made and fixed before the commits landed on the product gates??
>> Answer: no one, because such things are useless and a burden.
>
> So … have a public-facing "clean" repository and a private "dirty"
> repository with private branches? Again, I don't see what screwing with the
Exactly. Nothing awful about that, is there.
> DAG of the SCM buys you besides trouble.
There... is no "playing around with the DAG of the SCM". A rebase is
just a new branch in this scheme. New branches are hardly "playing
around with the DAG of the SCM". This is true even in git -- the old
commits in the repo don't change, they're not even deleted -- the only
thing destructive git does in a rebase is change commit that a branch
name points to.
So if you want to go from
A---B---C---a---b---c
to
A---B---C---D---ac'---b'
you'll find that a, b, and c are still left behind. In fossil there'd
be a new branch name to refer to the line of commits headed by b'. In
git c is no unreachable, unless there was some other branch or tag
referring to it, but c is still in the repo, and if there's no other
way to reach it there's always the "reflog".
You seem to think that git rewrites history. It does not. The only
destructive actions in git are: changing what a branch or tag point
to, and pruning unreachable commits.
And yes, rebasing private branches is easy, except it's a very manual
task in fossil, so it's not easy.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
