[Debian GNUstep maintainers] Git-fu for fixing #880460

[Yavor Doganov]

[ Moving discussion to the list only. ]

On Tue, Oct 31, 2017 at 10:01:17PM +0100, Eric Heintzmann wrote:
> On Tue, 31 Oct 2017 22:05:41 +0200 Yavor Doganov <yavor at gnu.org> wrote:
> > In fact this is fixed in master, but how do we proceed with the
> > repository now that there are lots of changes in master intended for
> > experimental? We have to prepare an upload fixing only this bug.
> 
> I think we can ignore the git repo for this upload (and import manually
> the changes and the changelog entry in the next upload).
> Except if you see a better option

I believe we should try to retain the history and record the changes
in chronological order.  If we ignore the repository, there won't be a
tag either and no evidence of the changes.  What I suggest is to copy
master as a new experimental branch, then reset master to tag 0.25.0-4
and cherry-pick the commit that is fixing this issue.  When we release
0.26.0-1 to experimental, we'll cherry-pick the commit of
debian/changelog to master (0.25.0-5).  Then, when the -gui transition
begins, we'll merge experimental into master.

I'm not a Git expert, so please let me know if this is OK:

git branch -c master experimental
git branch -f debian/0.25.0-4
# This below would work but the commit we need has unrelated changes
# to debian/control so we can't do that.
| git merge 9d27fc
# edit debian/rules & commit
# test, prepare upload
# commit changelog & tag 0.25.0-5

Then merge the 0.25.0-5 changelog commit from master to experimental.
When we merge experimental back to master for the forthcoming -gui
transition, there'll be a minor conflict in debian/rules but that is
trivial to resolve.

What I don't understand well is which command is better to use --
merge or cherry-pick.