Re: [Numpy-discussion] Another merge at github
Sat, 16 Oct 2010 23:23:46 -0600, Charles R Harris wrote: [clip] And I just managed the same result on a push to maintenance/1.5.x :-/ But I know how it happened, I cherry picked from master for a backport before updating the 1.5.x branch from github. In Retrospect I probably should have reset the head, pulled from 1.5.x, and then reapplied the backport. I think the main problem is in using $ git pull The solution is: DO NOT USE git pull Instead, use git fetch and after that either git merge or git rebase. Then it is explicit what you are doing, and it is more difficult to get wrong. OTOH, $ git pull --ff-only is safe in this sense. So you could in principle drop #!/bin/bash CMD=$1 shift case $CMD in pull) exec /usr/bin/git pull --ff-only $@ ;; *) exec /usr/bin/git $CMD $@ ;; esac on your $PATH. Live and learn. I do it like this: 1) Work in a separate topic branch. 2) Do not merge from master while working. Rebasing is OK, but often not needed. 3) When done, a) If it's just a single commit or a bunch of unrelated commits, rebase on upstream/master. $ git fetch upstream $ git branch tmp HEAD # make a backup in case you mess up $ git rebase upstream/master # do the rebase In case of conflicts: $ git add numpy/.../somefile # mark conflict resolved $ git rebase --continue If you mess up, you can do $ git rebase --abort and if you notice the mess-up after rebase has completed, you can do $ git reset --hard tmp # set branch to same point as `tmp` b) If it's a work consisting of multiple commits that build on each other, you can merge. $ git fetch upstream $ git merge --no-ff upstream/master 4) Then, check what is going to be pushed: $ git log --graph somebranch $ git log -p somebranch Finally, push directly from the branch: $ git push upstream somebranch:master ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Another merge at github
Mon, 18 Oct 2010 12:20:00 +0300, Pearu Peterson wrote: [clip] I see that there are long discussions in numpy ml about the git usage and mis usage. I wonder whether this has converged to something that could be used as reference for git beginners like me. I think there's agreement on what we would like to see. I tried to modify Matthew's gitwash docs in that in sight: http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html Suggestions for improvement are welcome. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Another merge at github
On Sun, Oct 17, 2010 at 1:48 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: 2010/10/17 Stéfan van der Walt ste...@sun.ac.za: On Sun, Oct 17, 2010 at 12:23 AM, Charles R Harris charlesr.har...@gmail.com wrote: IIRC, they recommended pushing from local branches to master on github and not merging master to the development branches. That doesn't sound right to me, but perhaps I misunderstood... The idea is not to keep merging the master branch into your development branch to keep up to date (this makes for really ugly history). Another merge commit: http://github.com/numpy/numpy/commit/427d3fcabe5 For single commits, merge back into master (hopefully this should be a fast-forward merge), which then creates an svn-like timeline. Actually I think that the push local branch to github master approach that Charles referred to above is better. Because that will fail if the merge is not fast-forward, so you never get merge commits if you don't want them. The merge into local master way will give you a merge (which is why you said hopefully above) if you forgot to rebase your feature branch first. For pull requests of 1 or 2 commits on github, this should work: $ git co -b local-branch http:github.com/username/branch-to-pull $ git rebase master # (or maintenance/1.5.x) $ git push origin local-branch:master This will either give a ff merge or fail. Right now it's turning into a bit of a mess, with completely unrelated commits forming small branches: http://github.com/numpy/numpy/network Cheers, Ralf For bunches of commits, merge back into master with the --no-ff switch to ensure that a merge message is generated (this makes it much easier to find those grouped commits later). After the merge, push back upstream. Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Another merge at github
2010/10/17 Stéfan van der Walt ste...@sun.ac.za: On Sun, Oct 17, 2010 at 12:23 AM, Charles R Harris charlesr.har...@gmail.com wrote: IIRC, they recommended pushing from local branches to master on github and not merging master to the development branches. That doesn't sound right to me, but perhaps I misunderstood... The idea is not to keep merging the master branch into your development branch to keep up to date (this makes for really ugly history). Another merge commit: http://github.com/numpy/numpy/commit/427d3fcabe5 For single commits, merge back into master (hopefully this should be a fast-forward merge), which then creates an svn-like timeline. Actually I think that the push local branch to github master approach that Charles referred to above is better. Because that will fail if the merge is not fast-forward, so you never get merge commits if you don't want them. The merge into local master way will give you a merge (which is why you said hopefully above) if you forgot to rebase your feature branch first. Cheers, Ralf For bunches of commits, merge back into master with the --no-ff switch to ensure that a merge message is generated (this makes it much easier to find those grouped commits later). After the merge, push back upstream. Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Another merge at github
On Sat, Oct 16, 2010 at 4:23 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, Oct 16, 2010 at 3:54 PM, Benjamin Root ben.r...@ou.edu wrote: On Sat, Oct 16, 2010 at 2:20 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, Oct 16, 2010 at 12:56 PM, Joshua Holbrook josh.holbr...@gmail.com wrote: On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris charlesr.har...@gmail.com wrote: Here. This looks harmless but it makes the history really ugly. We need to get the word out *not* to do things this way. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion So: Rebase, not merge? I'm thinking along those lines, but I'm just a dilettante git user. I tend to merge master to my development branches, merge them back to master, and then push master to github. That probably isn't the recommended way. Rebase would probably have the same effect. Chuck I think the iPython development mailing list recently had a long discussion about proper git usage. Maybe there is something we can learn from their experience? IIRC, they recommended pushing from local branches to master on github and not merging master to the development branches. That doesn't sound right to me, but perhaps I misunderstood... And I just managed the same result on a push to maintenance/1.5.x :-/ But I know how it happened, I cherry picked from master for a backport before updating the 1.5.x branch from github. In Retrospect I probably should have reset the head, pulled from 1.5.x, and then reapplied the backport. Live and learn. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Another merge at github
On Sat, Oct 16, 2010 at 12:56 PM, Joshua Holbrook josh.holbr...@gmail.comwrote: On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris charlesr.har...@gmail.com wrote: Here. This looks harmless but it makes the history really ugly. We need to get the word out *not* to do things this way. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion So: Rebase, not merge? I'm thinking along those lines, but I'm just a dilettante git user. I tend to merge master to my development branches, merge them back to master, and then push master to github. That probably isn't the recommended way. Rebase would probably have the same effect. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Another merge at github
On Sat, Oct 16, 2010 at 2:20 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, Oct 16, 2010 at 12:56 PM, Joshua Holbrook josh.holbr...@gmail.com wrote: On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris charlesr.har...@gmail.com wrote: Here. This looks harmless but it makes the history really ugly. We need to get the word out *not* to do things this way. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion So: Rebase, not merge? I'm thinking along those lines, but I'm just a dilettante git user. I tend to merge master to my development branches, merge them back to master, and then push master to github. That probably isn't the recommended way. Rebase would probably have the same effect. Chuck I think the iPython development mailing list recently had a long discussion about proper git usage. Maybe there is something we can learn from their experience? Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Another merge at github
On Sat, Oct 16, 2010 at 3:54 PM, Benjamin Root ben.r...@ou.edu wrote: On Sat, Oct 16, 2010 at 2:20 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Sat, Oct 16, 2010 at 12:56 PM, Joshua Holbrook josh.holbr...@gmail.com wrote: On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris charlesr.har...@gmail.com wrote: Here. This looks harmless but it makes the history really ugly. We need to get the word out *not* to do things this way. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion So: Rebase, not merge? I'm thinking along those lines, but I'm just a dilettante git user. I tend to merge master to my development branches, merge them back to master, and then push master to github. That probably isn't the recommended way. Rebase would probably have the same effect. Chuck I think the iPython development mailing list recently had a long discussion about proper git usage. Maybe there is something we can learn from their experience? IIRC, they recommended pushing from local branches to master on github and not merging master to the development branches. That doesn't sound right to me, but perhaps I misunderstood... Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Another merge at github
On Sun, Oct 17, 2010 at 12:23 AM, Charles R Harris charlesr.har...@gmail.com wrote: IIRC, they recommended pushing from local branches to master on github and not merging master to the development branches. That doesn't sound right to me, but perhaps I misunderstood... The idea is not to keep merging the master branch into your development branch to keep up to date (this makes for really ugly history). For single commits, merge back into master (hopefully this should be a fast-forward merge), which then creates an svn-like timeline. For bunches of commits, merge back into master with the --no-ff switch to ensure that a merge message is generated (this makes it much easier to find those grouped commits later). After the merge, push back upstream. Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Another merge at github
On Sat, Oct 16, 2010 at 11:54 PM, Benjamin Root ben.r...@ou.edu wrote: I think the iPython development mailing list recently had a long discussion about proper git usage. Maybe there is something we can learn from their experience? Here's the link again: http://mail.scipy.org/pipermail/ipython-dev/2010-October/006746.html Git makes it easy to see which changes are going to be pushed; it's a good idea to do git log -p or git log --stat to see what's being sent upstream. Cheers Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Another merge at github
2010/10/16 Stéfan van der Walt ste...@sun.ac.za: The idea is not to keep merging the master branch into your development branch to keep up to date (this makes for really ugly history). For single commits, merge back into master (hopefully this should be a fast-forward merge), which then creates an svn-like timeline. For bunches of commits, merge back into master with the --no-ff switch to ensure that a merge message is generated (this makes it much easier to find those grouped commits later). After the merge, push back upstream. Thanks for the summary, Stefan. Charles, as soon as I catch a breather (I'm at a conference right now) I'll try to write up a summary of that long discussion in an easy to digest and follow manner, that can be useful to ipython as well as numpy. But Stefan's summary is spot on for the key points. Regards, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
