This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Replacing CVS - decision time: part 2


On 01/05/10 11:08, Andrew Lunn wrote:
> Hi Alex
> 
>> Rewriting history is IMHO very very dangerous and defeats the purpose of
>> a RCS.  That purpose is after all to track changes to your code.  IMHO
>> this ability to change history is more about protecting an individual's
>> vanity than anything else.
> 
> I guess this is a emacs vs vi type of discussion....

I think there's a certain amount of that :).

> I do find it useful to change history, but i use it sparingly. The
> major usage i have for it is to make sure git bisect works. I take
> patches from downstream and feed them upstream. I sometime see patches
> in a patch set where one patch breaks the build and the next fixes it.
> So i will change history and merge these two patches into one.

NB you can still do that in mercurial using queues. Perhaps someone with
more mercurial experience can tell me if there are other ways too.

> What i don't want is somebody doing a git bisect to happen to land on
> broken state, so making their bisect harder to do.

That would be true, although it's always a risk. We have to be more sure
about things when pushing to the master repo. More care is needed than
we've been used to with CVS.

> Jifl made an interesting comment. He expects contributors to submit
> patches, not pull requests.

I think it's better for review to be seeing the patches and being able to
discuss them; and we've talked about using bugzilla for patch management.
Maybe in future we could use pull requests for more experienced
contributors. NB hg doesn't have pull requests.

> So an eCos maintainer has no idea if
> history has been changed when he receives a set of patches. The
> contributors are free to decide for themselves, if they wish to change
> the history or not. Similarly, the eCos maintainer who receives a set
> of patches can also change the history, squashing patches together
> etc. Just care has to be taken to do this in private, before the
> changes are pushed into a public repo where such changes could cause
> problems.

Yes, what people do in their own repo is up to them, just like their own
choice of VCS is up to them. My main concern is certainly what appears in
the public repo. So as long as it's done in private, it's fine. The risk
would be that something slips through.... after some searching I've found
you can set receive.denyNonFastForwards in git to avoid receiving amended
commits which have been pushed with 'git push -f'.

I've also found an example in mercurial where history is changed: 'hg
rollback'. But as long as no-one runs that directly within the public repo
(directly on sourceware), then it's safe - rollbacks can't be pushed into
an upstream repo... they're intended for a local repository only.

So FAOD, whichever VCS is used, IMHO I would not want any history changing
in the public repo in principle, unless there is some sort of  exceptional
reason which people are informed about.

Jifl

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]