Thomas Wouters writes: > On Sun, Mar 20, 2011 at 17:59, Georg Brandl <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>> 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: rebasing really only should be > > > applied if the changesets are not already known somewhere else, > > > only in the local repo you're working with.
This is not complete list. The other important limit (pointed out by Nick and Thomas) is that it creates changesets that have not yet been tested, and therefore need to be tested or collapsed (if you want bisect searches to work properly). > > > 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. That's a problem with any merging, not just with rebasing, though. > 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. In practice, people who rebase often rebase the same branch to mainline frequently. If so, they detect most conflicts with mainline as they occur, and this is often more useful context than knowing only that "this branch was developed in a different context from the current mainline tip", which is the "purist" reason most frequently given for disliking rebasing. That is, in practice people often resolve merge conflicts statically, just by looking at the diff3 output. If a developer is rebasing frequently, on the other hand, they are probably also more aware of the current context of the mainline, and why the conflicting changes were made. This dynamic context may improve the conflict resolutions. > As for my dislike, your reason (changing history) and Davids apparent > problem seem obvious enough. Aren't they? If you don't rebase correctly, > stuff goes wrong. Doing it correctly is harder than people seem to > think. I don't think it is, at least not in theory: just run the test suite on all rebased changesets. As argued above, the case for frequent rebasing is as least as strong as the case for merging a branch developed entirely in its original context, and only dealing with conflicts at the very end, quite out of context. > Merges can also contain useful information about how *future* merges of the > same changes should be handled. That hg rebasing (and git rebasing, for that matter) doesn't preserve this information is a design bug (ask any Darcs user :-). It is important in practice, of course. > 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. Ah, but merging and rebasing are done locally. The repository *is* in that state now, and building and testing the relevant changesets can be done automatically. (This may be problematic in practice due to the push race, of course.) So it's just a matter of project policy to require those tests before pushing. People who are bugged by the push race can do an ordinary merge, and provide less testing thereby. > Merging and merge changesets are a fact of DVCSes, Actually, of any decentralized development. DVCSes simply provide tools to make you aware of merges, rather than hiding problems behind "coalesced" patches that don't even know their parent version. _______________________________________________ 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
