Re: How to fix roundup.org's customizing.txt

Ralf Schlatterbeck <[email protected]>
Newsgroups gmane.comp.bug-tracking.roundup.devel
Message-ID <[email protected]>
On Fri, Sep 07, 2018 at 09:07:32AM +0200, Thomas Arendsen Hein wrote:
> * John P. Rouillard <[email protected]> [20180906 23:27]:
> 
> > 3) branch the doc in hg (to 1.6.0_branch), roll back the gpg/pyme
> >    change and publish that. Advantage: in hg and reproducable if we
> >    need to do another 1.6.x release not based on trunk, working
> >    example and url's.  Disadvantage: not the same as released 1.6.0,
> >    need to figure out how to do the required hg work.
> 
> My suggestion here would be to to a 1.6 branch, branching off at
> the 1.6.0 tag that will lead to a 1.6.1 release at some point.

Thanks Thomas for the detailed instructions.
I also prefer 3)

> P.S.: Can anyone here tell me how above can be done with git?

the equivalent of graft is 'cherry-pick' with git.
Creating a branch from an already-existing tag is left as something
basic as an exercise to the reader
The additional merge step is not necessary with git

For maintenance I'd prefer to commit all fixes to head and only
cherry-pick selected changes to the release branch. Not commit them to
the relase branch and merge to head, but that's just a preference that
can be realized with git or mercurial.

The problem for me with mercurial -- maybe like for you with git -- is
that I know my way around with git and always have to look up things
with mercurial. A git-to-mercurial cheat sheet would be a great help
here.

Some things -- like rebasing -- to my knowledge can't currently be done
with mercurial. This makes it hard to maintain features (like in our
case the REST API implementation from GSOC) without clogging them up
with frequent merge-changes from head. At least in the Linux
development, keeping a new feature that is not yet accepted upstream in
a state that applies to head but only has the necessary feature-related
changes is something that makes life easier for all people involved.

Also interactive rebase to clean up local changes before pushing them is
a feature I miss with mercurial.  Not to speak of a staging step before
commit (git add then git commit) and stashing changes.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.