That's correct. Though I recommend putting this in the global .gitconfig because
it gives you a more consistent Git experience. The default pull behavior will
either do a fast-forward or a merge commit, but you never know which one it will be.
On 30.01.19 21:16, Francois Saint-Jacques wrote:
This is also applicable to a per-repository basis by modifying the clone
`.git/config` file instead of the global one in your home.
On Wed, Jan 30, 2019 at 1:49 PM Antoine Pitrou <anto...@python.org> wrote:
That will be activated for all repositories, though, not only Arrow?
Regards
Antoine.
Le 30/01/2019 à 19:48, Maximilian Michels a écrit :
With the no-merge-commits policy, you might find it helpful to add the
following
to the .gitconfig in your home folder:
[pull]
rebase = true
That way you can use `git pull` without having to fear that it creates a
merge
commit. It does a `git fetch upstream branch && git rebase
upstream/branch` for
you automatically.
-Max
On 30.01.19 13:07, Tanya Schlusser wrote:
This information might be useful to put on the 'contributing' page:
https://cwiki.apache.org/confluence/display/ARROW/Contributing+to+Apache+Arrow
I attempted to add it but don't have permission. It was one of my
stumbling
points too and I'm thankful someone else asked about it.
On Wed, Jan 30, 2019 at 12:00 AM Ravindra Pindikura <
ravin...@dremio.com>
wrote:
On Jan 30, 2019, at 11:05 AM, Andy Grove <andygrov...@gmail.com>
wrote:
Got it. Thanks for the clarification.
On Tue, Jan 29, 2019 at 10:30 PM Wes McKinney <wesmck...@gmail.com>
wrote:
hi Andy,
yes, in this project I recommend never using "git merge". Merge
commits just make branches harder to maintain when master is not
using
"merge" for merging patches.
It is semantically simpler in the case of conflicts with master to
use
"git rebase -i" to combine your changes into a single commit, then
"git rebase master" and resolve the conflicts then.
Here’s the workflow that I use :
git fetch upstream
git log -> count my local commits, and remember it as ‘X'
git rebase -i HEAD~x
git rebase upstream/master
git push -f
I’m not able to avoid the ‘-f’ in the last step. But, Wes had
recommended
that we avoid the force option. Is there a better way to do this ?
Thanks & regards,
Ravindra,
A linear commit history, with all patches landing in master as single
commits, significantly eases downstream users who may be cherry
picking fixes into maintenance branches. The alternative -- trying to
sift the changes you want out of a tangled web of merge commits --
would be utter madness.
- Wes
On Tue, Jan 29, 2019 at 11:20 PM Andy Grove <andygrov...@gmail.com>
wrote:
I've been struggling a bit with the workflow and I think I see what
I'm
doing wrong now but wanted to confirm.
I've been running the following to keep my fork up to date:
git checkout master
git fetch upstream
git merge upstream/master
git push origin
And then to update my branch I have been doing:
git checkout ARROW-nnnn
git merge master
git push origin
This generally has worked but sometimes I seem to pick up random
commits
on
my branch.
Reading the github fork workflow docs again it looks like I should
have
been running "git rebase master" instead of "git merge master" ?
Is that the only mistake I'm making?
Thanks,
Andy.
