Bumping of libgfortran major version number and git

[Fritz Reese]

On Mon, Oct 10, 2016 at 12:09 PM, Jerry DeLisle <jvdelisle@charter.net> wrote:
> Hi all,
>
> I plan to submit a patch for approval that will bump the libgfortran version
> number and do a few cleanup things.  I have the impression that we have a
> consensus on this. I think it should be done before GCC 7 release.
...
> I ran a merging test using git merge of fortran-dev and trunk. There are
> only four files that need some manual conflict resolution. I would like to
> say that the merge should go into trunk as soon as possible to coincide with
> the library version change. I would hate to have to bump the version twice.

FYI: I have two DEC compatibility patches which mess with libgfortran.
One is for the I/O specifiers CARRIAGECONTROL/SHARE/READONLY. The
other allows assuming default exponents for real constants, e.g. '9e'
becomes '9e0'. I don't think these patches break the ABI, but it seems
convenient to roll them in with 7.0.0 as the version gets bumped
anyway.

> I don't know how many have figured out the git paradigm shift, but I have
> been using it a lot. Merging is hugely simplified because it is done on
> local copies of your trees.
...
> Not a sales pitch, but I am willing to recommend it. I particularly like the
> git stash feature where I can push all my current work away to a stack,
> update the trunk, work on some other issue, fix it, commit it, and then pop
> the previous work back which is then merged for you. This feature alone is
> worth the learning curve.
...

On the subject, I find 'git rebase' absolutely invaluable. You can
keep a patch (or set of patches) based on another branch so they
appear fresh, and avoid merges entirely. The rebase tool saved me
weeks/months of work re-basing my original set of DEC extension
patches from gfortran-4.8.3 to 7.0.0/trunk. I can keep bitrot away
from my new patches which haven't been submitted yet by constantly
rebasing them on trunk and applying any fixups. Thus I retain a
singular commit for each patch which I can just 'git diff' and then
submit to the mailing list, instead of worrying about consolidating
merges.

IMHO svn has been outdated for many years and is entirely inferior to git.