uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <...@apache.org>
Subject Re: git process to make changes, for committers
Date Thu, 06 Jun 2019 14:11:33 GMT
On 30. Nov 2018, at 09:08, Joern Kottmann <kottmann@gmail.com> wrote:
> In git you can rebase the PR on top of master and then commit it, and
> this leads to a much clearer and easier to understand linear history
> compared to merge every PR with a merge commit.

For small PRs, that works - but what if you work on something longer
and regularly wish to pull in the changes from master? Ok, I could 
re-base the PR, but then I have to do a force-push and people who
might be collaborating with me on the PR need to drop their local
versions and fetch my force-pushed version.

It happens often to me that I work on a PR and need to pull in changes
from master. Usually, I do this using the "Update branch" button 
on the GitHub page for the PR - this creates a merge commit. And after
that, trying to rebase the commit on the final merge would probably 
cause more effort then it's worth.

So my experience:

- rebase is nice for small commits
- squash is ok for larger commits, in particular those where it
  would be tedious to go through the history and fix the commit
  messages where contributors have e.g. forgotten to reference the
  issue number
- merge commits are the normal case for me, even if the repo graph
  may look funky at times. They preserve all commits (contrary to
  squash) and there is no risk to annoy anybody with force-pushes.


-- Richard

View raw message