On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams n...@cryptonector.com wrote:
snip
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
(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 vi...@viric.name 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
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 vi...@viric.name wrote:
sarcasmYou guys do really sound as a religious sect./sarcasm
:) well, I think that everyone expects different jobs to be done by a VCS.
As for
On Sat, Dec 29, 2012 at 9:55 AM, Konstantin Khomoutov
flatw...@users.sourceforge.net 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
On Sat, Dec 29, 2012 at 8:20 AM, Lluís Batlle i Rossell vi...@viric.namewrote:
(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
On Sat, 29 Dec 2012 10:24:05 -0600
Mike Meyer m...@mired.org 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
On Sat, Dec 29, 2012 at 10:51 AM, Konstantin Khomoutov
flatw...@users.sourceforge.net 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
On Sat, Dec 29, 2012 at 8:53 AM, Eric e...@deptj.eu wrote:
On Fri, 28 Dec 2012 16:06:08 -0600, Nico Williams n...@cryptonector.com
wrote:
snip
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
On Sat, Dec 29, 2012 at 9:20 AM, Lluís Batlle i Rossell
vi...@viric.name 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
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
vi...@viric.name 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
Nico Williams n...@cryptonector.com 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 m...@mired.org
On Sat, Dec 29, 2012 at 5:01 PM, Lluís Batlle i Rossell
vi...@viric.name 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
On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer m...@mired.org 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.
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
vi...@viric.name 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
On Sat, Dec 29, 2012 at 5:47 PM, Lluís Batlle i Rossell
vi...@viric.name 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
Nico Williams n...@cryptonector.com wrote:
On Sat, Dec 29, 2012 at 5:31 PM, Mike Meyer m...@mired.org 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
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
that
On Sat, Dec 29, 2012 at 10:29 PM, Mike Meyer m...@mired.org wrote:
Nico Williams n...@cryptonector.com 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
On Sat, Dec 29, 2012 at 10:49 PM, Michael Richter ttmrich...@gmail.com 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,
Nico Williams n...@cryptonector.com 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:
On 30 December 2012 12:56, Nico Williams n...@cryptonector.com 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
On 30 December 2012 13:02, Nico Williams n...@cryptonector.com wrote:
On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer m...@mired.org 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
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
we?
On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter ttmrich...@gmail.com wrote:
On 30 December 2012 12:56, Nico Williams n...@cryptonector.com 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
On 30 December 2012 13:23, Nico Williams n...@cryptonector.com 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 oldbase
then b) creates a new line
On Sat, Dec 29, 2012 at 11:33 PM, Michael Richter ttmrich...@gmail.com wrote:
On 30 December 2012 13:23, Nico Williams n...@cryptonector.com 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
On 30 December 2012 14:00, Nico Williams n...@cryptonector.com 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
On Sun, Dec 30, 2012 at 12:09 AM, Michael Richter ttmrich...@gmail.com wrote:
On 30 December 2012 14:00, Nico Williams n...@cryptonector.com 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
On Sun, Dec 30, 2012 at 12:19 AM, Nico Williams n...@cryptonector.com 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
On 30 December 2012 14:19, Nico Williams n...@cryptonector.com 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
On Sun, Dec 30, 2012 at 12:40 AM, Michael Richter ttmrich...@gmail.com wrote:
On 30 December 2012 14:19, Nico Williams n...@cryptonector.com 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
Nico Williams n...@cryptonector.com wrote:
On Sat, Dec 29, 2012 at 10:57 PM, Mike Meyer m...@mired.org 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
On Sun, 30 Dec 2012 14:40:27 +0800
Michael Richter ttmrich...@gmail.com
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
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.
Nico Williams n...@cryptonector.com wrote:
On Sat, Dec 29, 2012 at 11:11 PM, Michael Richter
ttmrich...@gmail.com wrote:
On 30 December 2012 12:56, Nico Williams n...@cryptonector.com
wrote:
What is it about rebase that causes so many to miss the idea of a
rebase that is NOT destructive
36 matches
Mail list logo
