On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams wrote:
Actually I agree with most of Mike Meyer's reply, but I wanted to pick
this paragraph apart:
> How many times have you submitted a patch to an upstream
Well, phrasing it like that says that you are thinking git-style anyway.
Let's assume
(top post, due to the complexity of the previous post)
I've found many git-fans that are completely ashamed of how they develop. And
they would never make public how they commit things (how they use the VCS), so
they don't accept other VCS that hasn't git rebasing capabilities.
I can't tell what
On Sat, 29 Dec 2012 16:20:32 +0100
Lluís Batlle i Rossell wrote:
Top post due to... okay.
The last three messages to this thread look somewhat alarming.
In the first message of these, Mike Meyer, first ruled out the whole
tool (Git) due to hating its optional feature and then proceeded with a
fa
On Sat, Dec 29, 2012 at 07:55:28PM +0400, Konstantin Khomoutov wrote:
> On Sat, 29 Dec 2012 16:20:32 +0100
> Lluís Batlle i Rossell wrote:
> You guys do really sound as a religious sect.
:) well, I think that everyone expects different jobs to be done by a VCS.
As for me, I like it to keep histor
On Sat, Dec 29, 2012 at 9:55 AM, Konstantin Khomoutov
wrote:
> In the first message of these, Mike Meyer, first ruled out the whole
> tool (Git) due to hating its optional feature
If you're going quote someone out of context, at least get their reasons right.
You called rebase a "killer feature"
On Sat, Dec 29, 2012 at 8:20 AM, Lluís Batlle i Rossell wrote:
> (top post, due to the complexity of the previous post)
>
> I've found many git-fans that are completely ashamed of how they develop.
> And
> they would never make public how they commit things (how they use the
> VCS), so
> they don'
On Sat, 29 Dec 2012 10:24:05 -0600
Mike Meyer wrote:
> > In the first message of these, Mike Meyer, first ruled out the whole
> > tool (Git) due to hating its optional feature
>
> If you're going quote someone out of context, at least get their
> reasons right.
>
> You called rebase a "killer f
On Sat, Dec 29, 2012 at 10:51 AM, Konstantin Khomoutov
wrote:
> I suggest you to calm down. I see my plead to not being zealous was in
> vain, so just please calm down at least.
I am calm. Yes, I'm a little bit bothered about being insulted in
various ways, but I'm trying to return the discussio
On Sat, 29 Dec 2012 19:55:28 +0400,
Konstantin Khomoutov wrote:
> On Sat, 29 Dec 2012 16:20:32 +0100
> LluÃs Batlle i Rossell wrote:
>
>> Top post due to...
> okay.
> The last three messages to this thread look somewhat alarming.
>
> In the first message of these, Mike Meyer, firs
tl;dr: we agree that public history should not get rewritten. You
missed the point of when, where, and why I need rebase.
On Fri, Dec 28, 2012 at 11:08 PM, Mike Meyer wrote:
> Nico Williams wrote:
>>Rebase is one of teh killer features of git.
>
> It certainly kills any interest I have in using
On Sat, Dec 29, 2012 at 8:53 AM, Eric wrote:
> On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams
> wrote:
>
>
> Actually I agree with most of Mike Meyer's reply, but I wanted to pick
> this paragraph apart:
>
>> How many times have you submitted a patch to an upstream
>
> Well, phrasing it like
On Sat, Dec 29, 2012 at 9:20 AM, Lluís Batlle i Rossell
wrote:
> (top post, due to the complexity of the previous post)
>
> I've found many git-fans that are completely ashamed of how they develop. And
> they would never make public how they commit things (how they use the VCS), so
> they don't ac
On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote:
> On Sat, Dec 29, 2012 at 9:20 AM, Lluís Batlle i Rossell
> wrote:
> > (top post, due to the complexity of the previous post)
> >
> > I've found many git-fans that are completely ashamed of how they develop.
> > And
> > they would nev
Nico Williams wrote:
>tl;dr: we agree that public history should not get rewritten. You
>missed the point of when, where, and why I need rebase.
Which is why I asked for clarification about that point. See below.
>On Fri, Dec 28, 2012 at 11:08 PM, Mike Meyer wrote:
>> Nico Williams wrote:
>
On Sat, Dec 29, 2012 at 5:01 PM, Lluís Batlle i Rossell
wrote:
> On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote:
>> And so on. Really. Large projects need order, they need process.
>> They need clean trees in official repos.
>>
>> Without a way to clean history prior to pushing to
On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer wrote:
> You missed the point. Nothing should *ever* be rebased. It's a rewrite of
> history, which is a fundamentally bad thing. While a SCM should make
> generating patch files easy, it shouldn't require rewrites of history to do
> so.
You missed m
On Sat, Dec 29, 2012 at 05:37:35PM -0600, Nico Williams wrote:
> On Sat, Dec 29, 2012 at 5:01 PM, Lluís Batlle i Rossell
> wrote:
> > On Sat, Dec 29, 2012 at 04:40:28PM -0600, Nico Williams wrote:
> >> And so on. Really. Large projects need order, they need process.
> >> They need clean trees in
On Sat, Dec 29, 2012 at 5:47 PM, Lluís Batlle i Rossell
wrote:
> Ah sorry, I was only talking about my objections against "git rebase". I don't
> know the best way to implement a feature that allows creating 'new history' at
> will (not destroying the old).
>
> All I can imagine sounds like a lot
Nico Williams wrote:
>On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer wrote:
>> You missed the point. Nothing should *ever* be rebased. It's a
>rewrite of history, which is a fundamentally bad thing. While a SCM
>should make generating patch files easy, it shouldn't require rewrites
>of history to
I'm pretty sure that "rebase" or its equivalents will never be a part of
Fossil. Given that there are tools out there (like Git) that feature this
functionality that some (and I stress it's only *some*) users want, perhaps
this following question is to practical but … why not use Git, the tool
tha
On Sat, Dec 29, 2012 at 10:29 PM, Mike Meyer wrote:
> Nico Williams wrote:
>>You missed my proposal that a fossil rebase operation always copy the
>>branch being rebased and rebase that copy. It was in my very first
>>post on this thread:
>
> I didn't miss it. I asked for clarification, for two
On Sat, Dec 29, 2012 at 10:49 PM, Michael Richter wrote:
> I'm pretty sure that "rebase" or its equivalents will never be a part of
> Fossil. Given that there are tools out there (like Git) that feature this
> functionality that some (and I stress it's only some) users want, perhaps
> this follow
Nico Williams wrote:
>What I'm proposing is that in fossil the rebase operation create a new
>branch named after the currently checked out branch (or named by the
>> So, for the third time, can you describe your proposed new feature
>*without* saying the words "git" or "rebase".
>No: it's too mu
On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer wrote:
>>> So, for the third time, can you describe your proposed new feature
>>*without* saying the words "git" or "rebase".
>>No: it's too much work, and many people understand "git rebase", and
>
> -1.
So is that a -1 to the attitude, the proposal,
On 30 December 2012 12:56, Nico Williams wrote:
> What is it about rebase that causes so many to miss the idea of a
> rebase that is NOT destructive because it creates a new branch instead
> of doing a destructive change to an existing branch?
>
I don't know. You won't explain it. "It's too mu
On 30 December 2012 13:02, Nico Williams wrote:
> On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer wrote:
> >>> So, for the third time, can you describe your proposed new feature
> >>*without* saying the words "git" or "rebase".
> >>No: it's too much work, and many people understand "git rebase", an
Michael Richter decía, en el mensaje "Re: [fossil-users] Fossil vs.
Git/Mercurial/etc.?" del Domingo, 30 de Diciembre de 2012 02:11:46:
> There's use cases for every bizarre feature in every bizarre SCM (distributed
> or otherwise) out there. Let's not turn Fossil into the C++ of DSCMs, shall
> w
On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter wrote:
> On 30 December 2012 12:56, Nico Williams wrote:
>>
>> What is it about rebase that causes so many to miss the idea of a
>> rebase that is NOT destructive because it creates a new branch instead
>> of doing a destructive change to an exist
On 30 December 2012 13:23, Nico Williams wrote:
> A "rebase" operation takes a branch (typically the current one) and
> two commits (oldbase and newbase) in the repository and then a)
> computes the set of commits that are in the branch since
> then b) creates a new line of commits that consists
On Sat, Dec 29, 2012 at 11:33 PM, Michael Richter wrote:
> On 30 December 2012 13:23, Nico Williams wrote:
>>
>> A "rebase" operation takes a branch (typically the current one) and
>> two commits (oldbase and newbase) in the repository and then a)
>> computes the set of commits that are in the br
On 30 December 2012 14:00, Nico Williams wrote:
> > And why do they do this? I kinda/sorta get the mechanism. I just don't
> see
> > the motivation. (And "upstream maintainers insist upon this" is not
> > motivation, it's just moving the question of motivation around.)
>
> Because they want cl
On Sun, Dec 30, 2012 at 12:09 AM, Michael Richter wrote:
> On 30 December 2012 14:00, Nico Williams wrote:
>> Because they want clean history.
>
>
> This is precisely why I maintain that you're not going to see a "rebase" in
> Fossil. Quoting from
> http://www.mail-archive.com/fossil-users@lists
On Sun, Dec 30, 2012 at 12:19 AM, Nico Williams wrote:
> There's room for interpretation, and for persuasion.
That's one of the things that happen when we build religions: heresy.
Is this heresy? You can't say. Maybe not even D. Richard Hipp can
say. Unless I'm willing to fork fossil and do it
On 30 December 2012 14:19, Nico Williams 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 his
On Sun, Dec 30, 2012 at 12:40 AM, Michael Richter wrote:
> On 30 December 2012 14:19, Nico Williams 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 un
Nico Williams wrote:
>On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer wrote:
So, for the third time, can you describe your proposed new feature
>>>*without* saying the words "git" or "rebase".
>>>No: it's too much work, and many people understand "git rebase", and
>> -1.
>So is that a -1 to
On Sun, 30 Dec 2012 14:40:27 +0800
Michael Richter
wrote:
> 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.
Private-branch
I should also point out that in the Sun model once every one or two
bi-weekly mini-releases of the product gates the project gates would
have to catch up. Catching up in a way that leaves project commits
ahead of the product gate is effectively rebasing, which breaks child
gates, which is bad. So
Nico Williams wrote:
>On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter
> wrote:
>> On 30 December 2012 12:56, Nico Williams
>wrote:
>>> What is it about rebase that causes so many to miss the idea of a
>>> rebase that is NOT destructive because it creates a new branch
>instead
>>> of doing a d
39 matches
Mail list logo
