Re: Gnus overrides.texi and WEBHACKDEVEL

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:

 > If this is what you had in mind, then it's still manual work, and
 > thus prone to errors.  I can do the same in a bound branch with
 > "bzr ci FILE1 FILE2 ...", thus "cherrypicking" only what should be
 > pushed.

Not necessarily.  For example, you may have pushable and non-pushable
changes in the same file, in which case that doesn't allow you to
select what to commit.  Also, if the local changes would benefit from
being preserved, you can commit them *immediately*, so the problem
becomes more granular (and you can add hints to the commit message to
indicate that some commits should not be cherry-picked).  In some
VCSes, there are tools that allow you to prohibit pulling certain
revisions (eg, svnmerge.py), but I don't think bzr has such yet.

 > The original problem was that some people do not pay attention to what
 > "bzr status" says, and just do a "bzr ci", which pushes all the
 > modified files.  I guess there's no way around vigilance.

No, there isn't.  However, committing all changes, using
branch-per-feature in your workflow, and using appropriate commit
messages for coherent changesets can reduce the amount of effort
needed to implement vigilance.  All of which are best practices, and
don't involve that much extra effort once you're disciplined to them.