<br><br><div class="gmail_quote">On Sun, Mar 20, 2011 at 17:59, Georg Brandl <span dir="ltr"><<a href="mailto:g.brandl@gmx.net">g.brandl@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 20.03.2011 16:50, Thomas Wouters wrote:<br>
><br>
><br>
> On Sun, Mar 20, 2011 at 17:39, Georg Brandl <<a href="mailto:g.brandl@gmx.net">g.brandl@gmx.net</a><br>
</div><div class="im">> <mailto:<a href="mailto:g.brandl@gmx.net">g.brandl@gmx.net</a>>> wrote:<br>
><br>
> The reason why rebasing is not universally applied is that the<br>
> rebased changesets are different from the original ones (therefore<br>
> I wrote A' and B') -- even if the diff is the same, the parents<br>
> are not, and therefore the changeset id (hash) changes. This is<br>
> called "changing history", and frowned upon by purists. In reality<br>
> it works fine if you know the limits:<br>
><br>
><br>
> It's frowned upon by more than just purists, and it works "in reality" as fine<br>
> as handing out your creditcard and personal information over the internet; you<br>
> can't always tell the result is bad, and it can be very painful finding out.<br>
<br>
</div>Well, YMMV. But instead of spreading FUD you might want to state *why*.</blockquote></div><div><br></div><div>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.</div>
<div><br></div><div>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. 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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. 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. 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.</div>
<div><br></div><div>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.)</div>
-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!<br>