Stephen J. Turnbull wrote: Sure. Technically, what it does is pretty simple: it propagates the no_fallback flag at places where it was missing before. I'll explain in greater detail below. I don't have an image problem anymore :-) But yes, I've noticed the bug because of my background pixmap. I suspect however that the patch fixes a more general problem. Here's what was happening: - I have a background pixmap and a background color set in my default face. - my font-lock-string-face has a foreground color set, and that's all. When it is in use, I was correctly seing the background pixmap behind the text. - slime-repl-output-face is defined as (:inherit font-lock-string-face). However, the background was drawn with the color, not the pixmap. The problem was that a call to: (face-property-instance font-lock-string-face 'background nil nil t) correctly returned Qunbound, but (face-property-instance 'slime-repl-output-face 'background nil nil t) incorrectly returned a instantiated background color. That was because the instantiation process invoked specifier-instance on the inheritance special construct (an array containing font-lock-string-face), which in turned invoked specifier-instance on the font-lock-string-face background property, but this time without the no_fallback flag. This is why I think my patch fixes a more general problem than only the one I was experimenting: probably all instantiations of properties defined by inheritance. I don't mind doing it, but I have no idea where you would like to see this happening, given that it's a bug fix. Unless the bug is "documented" somewhere of course :-) No comprendo. Nope. I hope it's clearer now ? Err, no, because it was my understanding that after the transition to mercurial, we were not supposed to do so anymore, precisely because the automatic commit notice was doing that. See the new chapter in Patcher's documentation... which I might have to rewrite then ?? :-/ It's my auto-cleanup that's been at work since I started hacking in XEmacs 14 years ago. You've never noticed before probably because the patches I explicitely sent to xeamcs-patches＠ with Patcher were whitespace-clean (remember the "this patch in informational only..." mention at the top of Patcher posts). -- 5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/ Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85 94276 Le Kremlin-Bicêtre, France Fax.+33 (0)1 53 14 59 22 didier(a)xemacs.org _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

Stephen J. Turnbull wrote: I can understand that. Only, this wouldn't be a problem if everybody committed whitespace clean patches in the fist place. I almost took maintainership of whitespace.el for that. -- 5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/ Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85 94276 Le Kremlin-Bicêtre, France Fax.+33 (0)1 53 14 59 22 didier(a)xemacs.org _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Just a naked club won't help. What exactly would you like to see? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: I guess I still don't understand what you're trying to accomplish: A merge commit has *two* parents. We could get the output of the other parent for a merge revision REV like this: hg diff -r`hg log -rREV --template '{parents}\n' | cut -d ' ' -f 2 | cut -d : -f 2` -rREV Is this what you want? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: I'm confused even more: I thought we're talking about the *commit bot*, not your local setup. Yeah, well, it can be refined to work for non-merge commits: My question was whether it's what you want to see for merge commits. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: That's right - Aidan did something to remove them a while ago. I'm still not sure - does the hg command I posted give you the output you want *for merges*? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

Michael Sperber writes: I mostly don't want to see merge commits at all, unless non-trivial work was done (ie, conflict resolution). _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

Didier Verna <didier(a)xemacs.org&gt; writes: You can also do this after the fact with Mercurial Queues. Opinions differ on that: http://changelog.complete.org/posts/586-Rebase-Considered-Harmful.html -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

Didier Verna writes: Bah. John Goerzen has been, uh, less than perceptive since at least 2003. Darcs is fundamentally all about rebasing. The thing is, that's not apparent because Darcs's fundamental data structures and algorithms are designed for rebasing implicitly. The problem with Darcs is that Darcs is pretty bad at rebasing anything interesting (the exponential merge problem), and doesn't provide a way to do it manually. As a comment to that blog points out $ git update-ref refs/heads/temp topic $ git rebase somewhere temp $ do-something-with-temp is perfectly safe. The reason why git-rebase isn't implemented that way is that people want to manipulate a topic branch as if it were a patch in a patch queue. That's the primary use-case, and you want to get rid of refs to the previous commit list to keep the namespace clean. Long-lived branches, on the other hand, pull from the mainline rather than being rebased onto the mainline. Where did you post that? I don't see it locally. A "good" VCS would make them look equivalent, as Darcs does. _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

Didier Verna writes: I work this way too. But this is an annoying, CVS-like way to work. And I see no easy way to enforce it (see below, however). Working that way is what most people consider the main advantage of modern VCSes, and Mercurial is designed to make it especially easy. What we should have done, I think, is to use a DAG-oriented VCS, I'll use git below because it makes sense to me, and had a commit hook that automatically rebases. Then the workflow in the usual case would be committer$ git push my-topic-branch:temp-branch commit-hook$ git rebase --onto master master temp-branch commit-hook$ git diff -r master -r temp-branch | send-commit-notice commit-hook$ git checkout master commit-hook$ git pull . temp-branch commit-hook$ git branch -D temp-branch and in the conflict case committer$ git push my-topic-branch:temp-branch commit-hook$ git rebase --onto master master temp-branch commit-hook$ git rebase --abort commit-hook$ echo "Try, try again!" | send-commit-notice commit-hook$ git branch -D temp-branch At times of low code churn, this would work pretty much as currently, except that we'd automatically get sane commit notices, and there would be no merge turds in the public history (all of the pulls would be fast-forwards by construction). At times of high code churn, people who did the rebasing locally would have a big advantage in getting their stuff safely committed. _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

Michael Sperber writes: By which you mean committers can pretend their line of development is a straight line, and not worry about nodes, right? It doesn't work so well for reviewers, though. Yes. That's the right thing to do for the reviewers, especially given how strongly array-oriented Mercurial's UI is. (Hint: show how to retrieve the hash ID of the parent of a non-merge commit.) By "preserve patch identity" you mean that the developer can work in a single workspace, push his patch, and when he later pulls from the public repo, not get a conflict. Right? That's a nice property, I agree. But with a UI that made handling named branches convenient, this wouldn't be a problem. You just drop the branch on the floor after you push its content, and pull that right back in with your next update. _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

Dominique Quatravaux writes: It's not that *presence* of array indicies bugs me; it's that *absence* of ancestor operators is a serious bug in a DAG processor. Ie, this was added as an afterthought. It seems to be implemented fully[2], though, so I feel a lot better. Apparently with a big enough stick you *can* beat Mercurial into behavior sensible enough to be usable. Footnotes: [1] By which I do *not* mean "conformant to git usage", although I appreciate the fact that it is. What I mean is that in light testing all paths tried through a couple of merges were traceable. _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

I rather like the model that no one gets to push to other peoples' repositories, people only pull. I think that's how Linus works. His "trusted lieutenants" let him know when they would like him to pull, and he does.... but presumably first into an "incoming" private-to-Linus repository that he can peruse before pulling into his public-for-export repository. I also rather like keeping the revision history in the important repositories "clean", which may mean forcing or strongly encouraging other people to throw away their patch development histories. I rather like the idea that a subsystem repository can keep more history than a "master" repository. Not every developer needs to have the entire history of the project in their own repository at all times. In a world where a project might have a thousand separate repositories, one quickly gets to the point where almost all changesets are trivial merge changesets, polluting the history. I don't know why you refer to the Linux model as "single integrator". I see it as rather the opposite -- Linus encourages multiple specialized trees, each with their own integrator. Martin M> "Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: M> The problem is that it just doesn't scale, in various ways: M> - It doesn't work for longer-lived branches like Carbon, where things M> are resynchronized multiple times. M> - It doesn't solve the problem I believe you're seeing, namely that the M> patch you reviewed isn't the patch that gets committed. "server-side M> git rebase" would be prone to breaking to build automatically, because M> "no conflicts" doesn't mean that that merge was actually correct. M> - If you don't to server-side rebasing, you impose an undue burden on M> the developers who keep rebasing their patches. M> - I agree things are different when there's a single integrators, like M> Linus. We don't. M> The most natural way of doing business with Mercurial and, I conjecture, M> git, is to do it the way we are doing it, and that means making explicit M> what revision a developer started from when making changes. However, M> for small, one-off patches, I'd have no objection to stating a policy M> that asks developers to push on top when possible, and give them M> instructions on how to get there using Mercurial Queues. M> -- M> Cheers =8-} Mike M> Friede, Völkerverständigung und überhaupt blabla M> _______________________________________________ M> XEmacs-Patches mailing list M> XEmacs-Patches(a)xemacs.org M> http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches

Stephen J. Turnbull wrote: But the whole commit message appears in the commit mail, right? So it's more a matter of people actually writing it (Patcher is here to help for that). And also maybe: (3): a filter for removing uninteresting changes (like whitespace cleanup). -- 5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/ Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85 94276 Le Kremlin-Bicêtre, France Fax.+33 (0)1 53 14 59 22 didier(a)xemacs.org _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches