On Wed, Oct 5, 2011 at 11:38 AM, Michal Suchanek <hramr...@centrum.cz>wrote:
> On 5 October 2011 20:12, Mike Meyer <m...@mired.org> wrote:
> > On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov
> > <flatw...@users.sourceforge.net> wrote:
> >>
> >> That sort of "we don't need it, we don't need it" mantra is a typical
> >> case of the famous "Blub paradox".
> >> I mean, if we have two DVCS tools one of which makes you able to
> >> rewrite history and another one which doesn't, the first one is more
> >> powerful _in this particular respect_. It's as simple as that.
> >> By supporting a feature, the tool does not force you to employ that
> >> feature in your workflow.
> >
> > First, note that there is a difference between "rewriting history",
> which
> > is what git supports, and "deleting unwanted items", which is the request
> > that started this.
> > Second, that a feature doesn't affect you if you "just don't use it" is a
> > fallacy. Sure, I think history should be sacrosanct, so I won't use
> rebase
> > even if it's available. That doesn't stop others on the project (who
> don't
> > agree with me) from using it . The only way to make sure that doesn't
> happen
> > is to not have the feature available *at all*.
>
> No, that's not how things work.
>
> Rebase is nothing more than taking commits comprising a branch from
> its branching point and applying them somewhere else. Not that
> complicated, really.
>
No, that's not how things work. Either that, or the git rebase documentation
is really badly broken. It sure looks to me like rebase moves the patches
from one point to another in the repo.
> As applying patches is doable, even patches stored in fossil history
> already, this is doable with a bit of scripting around fossil as it is
> doable with git. So not having the feature is not perfect defence, it
> only defends against people who don't care about the feature. People
> who find it useful for their workflow and want to use fossil for
> compatibility with upstream of for other features it provides can do
> so.
If rebase moves the patches, then the two operations are different. This is
basically a merge - except you're doing it outside the SCM, so you get two
copies of the patches. But whether you do it inside or outside the SCM, you
wind up with a history of the patches having been applied twice. Rebase
changes that.
<mike
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
