Thread: Git branching structure: ff or no-ff

Hi,

Any clue why --no-ff merges are used a lot in pgjdbc development?
Any clue why "fix here, fix there" commits are not squashed before integration?

From my point of view, it makes history browsing hard:
1) Just look at https://github.com/pgjdbc/pgjdbc/commits/master
Commits on Jul 9, 2015
Merge pull request #333 from zapov/master …
Merge pull request #343 from phillipross/master …
Merge pull request #351 from headcrashing/#328 …
Merge pull request #349 from ekoontz/jsonb-support …
...
Does that make much sense?

2) Even a single commit becomes two commits, so it clutters change log

3) It looks odd to have all those "fix here, fix there" commits in the
final history: https://github.com/pgjdbc/pgjdbc/pull/343/commits


What everyone thinks on that?

http://endoflineblog.com/gitflow-considered-harmful
http://endoflineblog.com/follow-up-to-gitflow-considered-harmful
https://news.ycombinator.com/item?id=9745966

--
Regards,
Vladimir Sitnikov

We noticed that this happens a lot on github in other projects, too, while it does not happen on our local company
repos.Possibly a bug of the github platform itself? 

About the "fix here, fix there": I think it is up to the project lead to reject non-collapsed PRs. I'd vote for such a
rule,as a shared master branch should only contain single commits per bug/feature. 

-Markus

-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Vladimir Sitnikov
Sent: Sonntag, 19. Juli 2015 04:06
To: List
Subject: [JDBC] Git branching structure: ff or no-ff

Hi,

Any clue why --no-ff merges are used a lot in pgjdbc development?
Any clue why "fix here, fix there" commits are not squashed before integration?

From my point of view, it makes history browsing hard:
1) Just look at https://github.com/pgjdbc/pgjdbc/commits/master
Commits on Jul 9, 2015
Merge pull request #333 from zapov/master … Merge pull request #343 from phillipross/master … Merge pull request #351
fromheadcrashing/#328 … Merge pull request #349 from ekoontz/jsonb-support … ... 
Does that make much sense?

2) Even a single commit becomes two commits, so it clutters change log

3) It looks odd to have all those "fix here, fix there" commits in the final history:
https://github.com/pgjdbc/pgjdbc/pull/343/commits


What everyone thinks on that?

http://endoflineblog.com/gitflow-considered-harmful
http://endoflineblog.com/follow-up-to-gitflow-considered-harmful
https://news.ycombinator.com/item?id=9745966

--
Regards,
Vladimir Sitnikov


--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

I think we'd better keep existing commits as is otherwise everybody
will have problems with on-going pull requests.

For new commits I suggest we use certain level of rebasing.
I suggest rebasing features on top of master before integration, so
the history is linear.

What do you think?

For instance: commit cddcd185  feat: Improved composite/array type support...
git checkout -b tmp cddcd185 # git fetch origin
pull/ID/head:BRANCHNAME && git checkout head:BRANCHNAME can be used
here to fetch a pull request from github
git rebase 008f6e8b2f8d # use rebase -i to squash commits as required.
008f6e8b2f8d was origin/master before cddcd185 merged in
git checkout master
git merge --ff-only tmp
git branch -D tmp # remove branch

Vladimir

I checked the GitHub docs. Unfortunately --no-ff is the default when using the "Merge" button in the browser and it
cannotbe changed! To have use fast-forward, Dave must always pull the change locally and merge it by hand. 

So for simplicitly we should live with --no-ff to make Dave's life easier, but I think it should be common to reduce
thenumber of commits per PR to one per feature/bug covered by the PR. 

-Markus


-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Vladimir Sitnikov
Sent: Montag, 20. Juli 2015 20:35
To: Dave Cramer
Cc: List
Subject: Re: [JDBC] Git branching structure: ff or no-ff

I think we'd better keep existing commits as is otherwise everybody
will have problems with on-going pull requests.

For new commits I suggest we use certain level of rebasing.
I suggest rebasing features on top of master before integration, so
the history is linear.

What do you think?

For instance: commit cddcd185  feat: Improved composite/array type support...
git checkout -b tmp cddcd185 # git fetch origin
pull/ID/head:BRANCHNAME && git checkout head:BRANCHNAME can be used
here to fetch a pull request from github
git rebase 008f6e8b2f8d # use rebase -i to squash commits as required.
008f6e8b2f8d was origin/master before cddcd185 merged in
git checkout master
git merge --ff-only tmp
git branch -D tmp # remove branch

Vladimir


--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc