Thread: Git branching structure: ff or no-ff

Git branching structure: ff or no-ff

From
Vladimir Sitnikov
Date:
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


Re: Git branching structure: ff or no-ff

From
Dave Cramer
Date:
The answer to your question(s) is mostly ignorance.

Is there a way to fix the previous commits ?

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 18 July 2015 at 22:05, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
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


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

Re: Git branching structure: ff or no-ff

From
"Markus KARG"
Date:
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



Re: Git branching structure: ff or no-ff

From
"Markus KARG"
Date:

While git actually is able to fix previous commits, it implies rewriting the history by rebasing, hence will break any unmerged forks (i. e. all contributors will have to merge their open branches against the new master). Due to that, it is a bad practice in general. Anyways, if all developers agree upon a history rewrite, we could do it. The question is, whether it is worth the cost.

 

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

 

The answer to your question(s) is mostly ignorance.

 

Is there a way to fix the previous commits ?


Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

 

On 18 July 2015 at 22:05, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:

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


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

 

Re: Git branching structure: ff or no-ff

From
Vladimir Sitnikov
Date:
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


Re: Git branching structure: ff or no-ff

From
"Markus KARG"
Date:
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



Re: Git branching structure: ff or no-ff

From
Dave Cramer
Date:
Well I can do it, it's not that difficult. But it does mean I can't do it from the web.

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 20 July 2015 at 16:16, Markus KARG <markus@headcrashing.eu> wrote:
I checked the GitHub docs. Unfortunately --no-ff is the default when using the "Merge" button in the browser and it cannot be 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 the number 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



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

Re: Git branching structure: ff or no-ff

From
Sehrope Sarkuni
Date:
+1 to squashing commits for PRs prior to merging them. The "fix blah" commits make it difficult to figure the full contents of the PR and arguably nobody cares about the sausage factory aspect of it. If there's an actual fix to something broken in a PR then it's a separate PR anyway.

I'm neutral on the no-ff merge commit for PRs. It's really convenient to click to merge from the GitHub web UI and it gives decent place to put the PR reference # (which I think GitHub autopopulates for you). Otherwise the original PR author has to create the PR, then update it again to add the "PR # blah" line in their own commit. Not a ton of work but anything circular like that is annoying.

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/