Bumping of libgfortran major version number and git

[Janne Blomqvist]

On Mon, Oct 10, 2016 at 7:09 PM, Jerry DeLisle <jvdelisle@charter.net> wrote:
> 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. As a test, I ran a merge of trunk into
> fortran-dev and it took about 15 seconds to do. That is a lot quicker than
> svn because it avoids the network back and forth to do it. Merge conflicts
> are nicely marked.
>
> 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. During dtio development I used it a lot so save
> things, try other patches, discard stuff, and retrieve.

I usually work on separate branches instead of using stash. I keep my
master branch as a pristine copy of the upstream, pull from upstream
to master, then rebase my development branches on top of master. Works
quite well IMHO, switching from one branch to another takes a few
seconds, and you don't need a zillion checked out trees.

That being said, I don't use git-svn, rather when a patch is Ok'd I
manually apply it to my svn tree and commit with svn.

Another cool git feature that I only recently started using is "git
format-patch". This creates a number of files (one for each commit)
that you can edit a little bit, then send to the list with "git
send-email". With this kind of workflow, the git commit message is
then essentially the mail you send to the list presenting the patch
and what it does (the first line of the commit message becomes the
email Subject:). IMHO it's nice that the commit message then contains
a description of what the patch as a whole does, rather than just the
ChangeLog entry.


-- 
Janne Blomqvist