> Mercurial has a whole subsystem (mq) to manage unpublished patches. Git implements 'rebase', and allows you to move unpublished commits forward.
This is dangerous and we have faced issues when we used commit ids from a git repository managed by another team. After few months, the commit ids we used in our scripts were no longer in the repository and we could not reproduce historical packages (just a couple of months old). I assume fossil will not encourage such features. There is a feature called 'shunning' that can be used for the third use case. - Altu -----Original Message----- From: Gé Weijers <g...@weijers.org> To: e...@deptj.eu; fossil-users@lists.fossil-scm.org Sent: Sun, Apr 4, 2010 4:47 am Subject: Re: [fossil-users] Fossil GUI for local source tree operations On Thu, 1 Apr 2010, Eric wrote:> And that is the way SCM should be - _no_ opportunity to rewrite history.>There are arguments for allowing some editing in history:- 'rebasing' commits allows you to keep a linear flow the the commits in a repo which makes things easier to follow. Mercurial has a whole subsystem (mq) to manage unpublished patches. Git implements 'rebase', and allows you to move unpublished commits forward.- abandoned branches just clutter up the repo, and it would be nice if they would not clutter up the branch name space forever.- some clueless soul can commit copyrighted material to your repo, and when you find out three years later because of a cease-and-desist letter you _need_ to edit history. The FreeBSD project did not go with Mercurial for this exact reason, but stuck to SVN because of previous experience. If that ever happens to the Linux kernel Git tree...._______________________________________________fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi -bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
