On 20.03.2011 18:32, Thomas Wouters wrote:
> 
> 
> On Sun, Mar 20, 2011 at 17:59, Georg Brandl <g.bra...@gmx.net
> <mailto:g.bra...@gmx.net>> wrote:
> 
>     On 20.03.2011 16:50, Thomas Wouters wrote:
>     >
>     >
>     > On Sun, Mar 20, 2011 at 17:39, Georg Brandl <g.bra...@gmx.net
>     <mailto:g.bra...@gmx.net>
>     > <mailto:g.bra...@gmx.net <mailto:g.bra...@gmx.net>>> wrote:
>     >
>     >     The reason why rebasing is not universally applied is that the
>     >     rebased changesets are different from the original ones (therefore
>     >     I wrote A' and B') -- even if the diff is the same, the parents
>     >     are not, and therefore the changeset id (hash) changes.  This is
>     >     called "changing history", and frowned upon by purists.  In reality
>     >     it works fine if you know the limits:
>     >
>     >
>     > It's frowned upon by more than just purists, and it works "in reality" 
> as fine
>     > as handing out your creditcard and personal information over the 
> internet; you
>     > can't always tell the result is bad, and it can be very painful finding 
> out.
> 
>     Well, YMMV.  But instead of spreading FUD you might want to state *why*.
> 
> 
> I could also ask you what makes you think changing history is frowned upon by
> *just purists*, or why on earth anyone would think it's a good idea regardless
> of how practical or theoretical they are.

The "purists" (which may have been a slight hyperbole) came from the fact that
usually the only argument you're presented with is "but, but, you're changing
history!" -- and I usually reply "it's my private history, and it's none of your
concern if I change it".  I will still have to take the blame if my changesets
break the build, so or so.

> As for my dislike, your reason (changing history) and Davids apparent problem
> seem obvious enough. Aren't they?

Yes, it shows that you should know about the limits of rebase.  In particular,
it is not suited to the forward-merging branch workflow when these merges
already occurred.

> If you don't rebase correctly, stuff goes
> wrong. Doing it correctly is harder than people seem to think. You can see
> what's going on with 'hg outgoing -p', but I, as an observer, have no way of
> knowing whether you used that and were aware of what exactly you were pushing.

That isn't specific to rebased changesets though, but to all changesets.  (See
for example the recently committed changeset including merge conflict markers.)
And by pushing linear history, I'm even making it easier for others to review,
since merge commits are a real pain to review.

> Merges can also contain useful information about how *future* merges of the 
> same
> changes should be handled. This doesn't matter much to changes with short
> turnaround (or changes that are continuously reverted and re-applied) but can
> make things a lot simpler if you have lots of diverging work in multiple
> branches -- and all the getting used to Mercurial aside, I'm sure that is what
> we're actually doing it for.

Yes, and for large parallel work it totally makes sense to use all the history
tracking that hg gives us.

> Even when done correctly, in situations where merges are automatic and do not
> involve the changed code in any way, I don't like rebasing a single changeset
> because it makes it less apparent when the actual work was started.

You need to remember that not all changesets are a) large or b) involve a lot of
code in different places.  Typical bugfix commits to Python touch one module,
its docs, and the NEWS file.  Others are even smaller.  It is utterly irrelevant
if I fixed a typo in the urllib docs when os.lseek was still leaking references,
or when it was already fixed.

> It's not any
> worse than diffing and re-applying a changeset, but for example if your change
> modified a particular call pattern appearing in multiples places, and another
> place started using the same pattern somewhere in your merges that you made go
> away, did you intentionally forget to fix the pattern or was it an accident?
> This isn't a problem that is *caused* by rebasing, but it certainly isn't 
> helped
> by it.

Sure, you will be given a chance to fix all new call sites in the merge commit.
For this kind of change it makes much sense to merge.

> Rebasing multiple changesets is worse, because the intermediate
> changesets are a real lie rather than some fudging of history; your repository
> was never in that state, that changeset never looked that way and it was never
> built or tested that way. No matter that it *usually* doesn't matter, or even
> *almost never* matters, it *can* matter.

There we have the "purist" point again.

> Merging and merge changesets are a fact of DVCSes, and while I (as a grumpy
> luddite misanthrope) greatly prefer the automatic (and mostly silent) merge as
> BitKeeper does it, in the long run the actual merging and the merge changesets
> are unavoidable and something to get used to, not dodged around (at least not 
> at
> this cost.)

I think we're not that far apart -- you as a grumpy luddite misanthrope just
like to stress the negative part a bit more :)

Georg

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to