emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs-w3m?


From: Óscar Fuentes
Subject: Re: emacs-w3m?
Date: Fri, 26 Feb 2010 00:59:08 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.92 (gnu/linux)

address@hidden (Robert J. Chassell) writes:

>     Definitely, those files were added with `bzr add'. You did it
>     inadvertently.
>
> I did not.

Yes, you did. Bazaar does not add files without being told so.

> I did a commit and the command must have moved W3M mode
> files in my running Emacs to the master, which I did not intend.  Why is
> that?

Without knowing the precise steps you follow, it's hard to tell.

>  How do I commit one file?

That's explained on

http://www.emacswiki.org/emacs/BzrQuickStartForEmacsDevs

which supposedly you are using as a guide.

The command is

bzr commit one-file another-file ...

but if some of the files are not versioned yet, you need to add them
first:

bzr add one-file

this is why I say that you did a `bzr add' before the commit (this or
your bzr version has a tremendous bug, but I think that that is
unlikely.)

>     Last time I looked, it wasn't a good idea to mix the instructions of
>    those documents. Stick to one or another, but not both.
>
> Where in BzrForEmacsDevs and BzrQuickStartForEmacsDevs does it say that
> you should not commit?  The command is in both.  (I am serious;
> remember, those who wrote BzrForEmacsDevs and BzrQuickStartForEmacsDevs
> tried to explain Bazaar and I thought they did a good job.)

I'm being serious too. You say that you are following the instructions
of *both* documents. And I insist on that you should pick just one.

>     > What are the `unthinkable' ways of removing unwanted files?
>
>     I'm not sure I understand your question. With bzr, you do `bzr
>     uncommit --revision N'. DON'T EVER DO THAT ON A PUBLIC BRANCH ...
>     just in case that setting's implementation has bugs, don't try it.
>
> OK, I won't.  Are you saying that no one has a low-probability-of-error
> method in bzr that removes mistakes?  As Leo said,
>
>    ... if this mistake can happen so easily it will happen again
>
> which is true.

As explained here on the past, pretending to correct an error on bzr is
similar to pretending to correct an error on a e-mail you sent to a
public mailing list. For fixing typos on commit messages and other
meta-information, some tools have mechanisms for amending one commit
with another commit, but the first commit remains there.

As for the mistakes, yes, they happen. We need to try hard to not incur
on them, but they will happen anyways. In this case, a simple `bzr diff'
just before committing would spit a diff 100 K-lines long and you would
notice that something was wrong.

If erroneous commits turns to be a serious problem, we could set up a
gatekeeper(*), although that workflow is a bit more complex than what
we have now.

* http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/using_gatekeepers.html





reply via email to

[Prev in Thread] Current Thread [Next in Thread]