git cherry-picking and Mercurial features (was: Re: How to fix roundup.org's customizing.txt)

* Ralf Schlatterbeck <[email protected]> [20180907 09:46]:
> On Fri, Sep 07, 2018 at 09:07:32AM +0200, Thomas Arendsen Hein wrote:
> > P.S.: Can anyone here tell me how above can be done with git?
> 
> the equivalent of graft is 'cherry-pick' with git.

OK, I think I didn't say what I already know and what not :)
What I meant: How do I find the changesets I want to cherry-pick in
an automatic way? How do I list all changesets not included in the
1.6.0 release, that affect one of the two directories or the one
file, and that were done by John Rouillard?

I think "git log" has all the needed parts (--author,
--grep-reflog), but how do I specify "not in 1.6.0 and before?"
without using --since and having to verify first that the date stamp
of all those commits is later than 1.6.0's date stamp?
I think the "SPECIFYING RANGES" section of the gitrevisions man page
may help me here. The Mercurial equivalent of the gitrevisions man
page is: "hg help revisions", which contains the same text as e.g.
https://hg.intevation.de/adminton/help/revisions

> 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.

Yes, both have their benefits, and usually both workflows can be
used within a single project without too many problems.

> 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.

https://www.mercurial-scm.org/wiki/GitConcepts#Command_equivalence_table
(link points to the commands, but the whole page is interesting in
this regard)

> Some things -- like rebasing -- to my knowledge can't currently be done
> with mercurial.

The rebase extension is included with Mercurial for about 10 years
now, but only with the changeset evolution concept (in short: being
able to communicate during push/pull that certain changesets become
obsolete) this is really easy to use when you already have pushed
the changes that you want to rebase.

This evolution concept is available as a 3rd-party extension for
some years now. The work started in 2011 and is now nearing its
completion, i.e. that it will be enabled by default in Mercurial's
core.

If you haven't pushed your changes yet, you can simply use the
current rebase extension by adding this to your ~/.hgrc:

  [extensions]
  rebase=

(no path after the "=", Mercurial will automatically find it)

> Also interactive rebase to clean up local changes before pushing them is
> a feature I miss with mercurial.

Interactive history editing can be done with the histedit extension:
https://www.mercurial-scm.org/wiki/HisteditExtension

> Not to speak of a staging step before
> commit (git add then git commit)

Most of the time I am annoyed by having to stage my changes, but in
certain situations this would be nice. But more often than not I'm
in a situation where I want to stage/commit some of my changes to a
single file, but not others, and here even git's staging area does
not help.

With Mercurial I use a little trick: You can specify a filter that
is applied to certain files before committing them, here I use sed
or "egrep -v" to invert the changes I don't want to commit, e.g. a
database host+password configuration entries or automatically
inserted uuids of connected hardware devices.
Not trivial, but very powerful.

> and stashing changes.

And again an extension: mq, included in Mercurial since 2006 :)

Or a simpler, but for some people easier to use variant: shelve,
included in Mercurial since 2013.


Yes, there are many extensions for Mercurial that hide advanced
functionality from users. Many extensions have already been moved
into Mercurial core by now, as this has been accepted as a problem
with how people perceive Mercurial's feature set as too limited,
and more extensions will follow (e.g. evolve mentioned above, maybe
rebase too).

Regards,
Thomas

-- 
Thomas Arendsen Hein <[email protected]> - OpenPGP key: 0x5BB3F5195816791A
https://blogs.intevation.de/thomas/         - https://intevation.de/~thomas/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot