On Sun, Dec 30, 2012 at 7:58 AM, Eric <e...@deptj.eu> wrote:
> On Sun, 30 Dec 2012 01:24:44 -0600, Mike Meyer <m...@mired.org> wrote:
>>
>> Nico Williams <n...@cryptonector.com> wrote:
> <snip>
>>> Other things that can be redone in a rebase would include:
>>
>> From what you've said, I believe that it's these *other things*
>> that you want: an easy way to munge commits as they get copied to a
>> new branch. I don' think that's an unreasonable request, as opposed
>> to wanting rebase. After all, we can do that now with repeated
>> cherry-picking merges. But without a more detailed description than
>> "I want rebase", it's hard to tell if that's the case or not, propose
>> alternatives, and otherwise engage in the process of refinement that
>> peer review is supposed to provide.
>
> So perhaps all we need is a streamlined way to do multiple
> cherry-picks (which may even end up with a similar feel to "git
> rebase --interactive").
That's the essense of rebase. Glad we agree.
> Whatever we do we can't call it rebase, because people will then assume
> that it is just like git rebase, and it won't be because it must
> not manipulate the pre-existing tree. If you don't believe that the
I repeat: git rebase does not "manipulate the pre-existing tree", it
does not destroy any history already in the tree. The only
destructive action that git rebase does is change the commit that a
branch _name_ points to, and from a fossil philosophy perspective this
is the only aspect of git rebase that is worth differing on.
> name matters, just read the "why does `fossil rm' not do the "real"
> thing?" thread.
Gratuitous terminology differences only burden users. Calling this
something else will only placate the anti-git police.
> Now for a few more general comments (30 messages overnight!!):
Depressing, I know.
> "Because upstream wants it" is not necessarily a good reason. Upstream
> can be just as misguided as downstream. Also they should not be making
> requests that are difficult in their VCS of choice, and likely workflows
> should have been part of the process of choosing a VCS.
Sometimes you don't get to argue with upstream. It's either their way
or the highway. But I've also explained in much detail why upstream
actually *is* justified in asking for contributions to be nicely
organized as a linear sequence of properly ordered commits that
applies cleanly to the upstream trunk and where each commit stands
alone, etcetera.
As for making requests that are difficult in the VCS of their
choice... I agree entirely. And that is why Fossil (as it is) cannot
be considered for the large projects I've worked with.
> That commits should do only one thing is a sensible idea (whether the
> one thing is a one line bug fix or a major feature implementation), but
> this is about project policy, and developers should work in such a way
> as to be able to achieve it. You can do it in Fossil, and if something
> you have to do to achieve it "takes too long", then write, design,
> or ask for functionality to streamline it (in that order of preference!).
Agreed. I should show up with code in hand. I just did that for a
different open source community (LyX), and I wish I could do it for
this one. But I'm out of time for the next six months.
What if I had intended response to that 3-paragraph initial post to
help me gauge interest levels in a possible contribution of fossil
rebase functionality? Why should I spend valuable time and effort on
a contribution that will be rejected? The contribution I made to
lyx-devel last week was one I weighed carefully through an earlier
discussion on lyx-users.
Your (that's general "your") hospitality, or lack thereof, matters.
This goes for me too: obviously I've allowed frustration to show, and
this is bad since it only heightens hostility, and for this I'm sorry.
> One of the things that people seems to miss is that if you are working on
> several things in parallel (say a "nearly finished" feature, a feature
> in "early exploration", and a few bugs some of which are on different
> branches) you should really be doing each in a separate working directory
> based on the same repository. This is easy in Fossil, and is possible
> in git (or even CVS!). You will of course have to do various merges,
> but everything will be fairly clean, and you won't even need stash!
I never git stash -- it's a git feature I've yet to internalize (and
you all thought I was a git zealot! ha). I generally commit
everything, even work in progress, then switch to another branch, then
back, and eventually I rebase to squash the work-in-progress commits
if need be.
> Upstream will always have to do some merges!
The upstreams I've worked with only ever accept merge-free
("fast-forward", in git terms) commits. Occasionally one has such a
large project to contribute that it's difficult to ensure that no
other commits will slip in while one is updating the project to the
trunk, in which case the upstream should "lock" the upstream so that
no commits can be pushed until the project's commits are updated,
tested, and pushed to the trunk.
> Someone on every project should have a clear idea of how branches can
> and should be used, and write a branching policy. Being sensible about
> branches and merges covers many of the apparent problems.
Indeed.
> And finally, if you want something that Fossil can't do at all, even
> in a round-about or tedious way, you need to be able to express it in
> terms of development needs, not just as "I want 'somevcs mangle'".
Go back through those 30 posts you mentioned. Go back to the very
first one from me. I tried to be concise and wrote just three
paragraphs that, IMO, captured what was needed. I certainly did not
say "I want git rebase in fossil" and then watched the fireworks --
no, I explained *concisely* (or at least that was my aim).
If I had written a ten-page post explaining in excruciating detail
what rebase is, why it matters, and how to adapt it to the Fossil
philosophy, who -but who!- would have read that first post? I was
being (I thought!) considerate. And judging by last night's 30 posts,
would it have made any difference to post a thesis-length argument for
rebase? And if so, how was I to know that? Or should I have given up
at the very first sign of trouble?
Nico
--
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
