Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

"Stephen J. Turnbull" <address@hidden> writes:

> Óscar Fuentes writes:
>
>  > >  Cf. the OP's
>  > > description of his workflow.  It gets in the way of use of Bazaar
>  > > features like "bzr log -n#" for other developers.
>  > 
>  > Uh? What's the benefit of log -n# for one-revision merges?
>
> You didn't read the OP's description of how that ChangeLog got
> committed, obviously.  Please do that.

The OP is trying to follow your recommended workflow, getting very
confused and creating the problem. If he were using the centralized
workflow, the only advice he would need is "include all modified files
on the same commit" and `-log -n#' would be as informative (but less
verbose) as with the distributed workflow.

>  > Well, there is no reason to settle on one Golden Workflow. It is clear
>  > that we want to introduce new good practices on how the VC history is
>  > developed (one changeset per purpose, etc) but that practices are not
>  > incompatible with multiple workflows.
>
> That's not at all my point.  The point is that there is a single
> public repository that everybody is aiming at, and that personal
> workflows that use centralization features *necessarily* impose that
> personal workflow's history on the rest of the project.

No. No for one-commit changes. Nobody is recommending to use `push' here.

>  > distributed workflow is asking for problems. A gradual introduction with
>  > a simpler workflow helps in several ways. That's a personal decission,
>  > no other is affected by it.
>
> You are wrong, at least in Bazaar which supports lightweight checkouts
> and bound branches.  As soon as you bind a branch, you are at risk of
> polluting the public history with personal mistakes.  Your convenience
> may conflict with what is considered good practice by other developers.

Which are those personal mistakes? Committing something you didn't
intend to? People here are accustomed to check the changes before
committing. They were using CVS for 16 years, you know.

And how is that different from merging changes you didn't intend to send
upstream, like debug or untested code?

It would help a lot to the discussion if instead of saying "this is
problematic" the actual problems were described.

-- 
Óscar