Here<http://github.com/numpy/numpy/commit/43b05fdd1c0ba1c6686297d16d257985dd986d3...>. This looks harmless but it makes the history really ugly. We need to get the word out *not* to do things this way. Chuck
On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris <charlesr.harris@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? --Josh
On Sat, Oct 16, 2010 at 12:56 PM, Joshua Holbrook <josh.holbrook@gmail.com>wrote:
On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris <charlesr.harris@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
On Sat, Oct 16, 2010 at 2:20 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Sat, Oct 16, 2010 at 12:56 PM, Joshua Holbrook <josh.holbrook@gmail.com
wrote:
On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris <charlesr.harris@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
On Sat, Oct 16, 2010 at 3:54 PM, Benjamin Root <ben.root@ou.edu> wrote:
On Sat, Oct 16, 2010 at 2:20 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Sat, Oct 16, 2010 at 12:56 PM, Joshua Holbrook < josh.holbrook@gmail.com> wrote:
On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris <charlesr.harris@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
On Sun, Oct 17, 2010 at 12:23 AM, Charles R Harris <charlesr.harris@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
2010/10/16 Stéfan van der Walt <stefan@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
2010/10/17 Stéfan van der Walt <stefan@sun.ac.za>:
On Sun, Oct 17, 2010 at 12:23 AM, Charles R Harris <charlesr.harris@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
On Sun, Oct 17, 2010 at 1:48 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
2010/10/17 Stéfan van der Walt <stefan@sun.ac.za>:
On Sun, Oct 17, 2010 at 12:23 AM, Charles R Harris <charlesr.harris@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
On Sat, Oct 16, 2010 at 4:23 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Sat, Oct 16, 2010 at 3:54 PM, Benjamin Root <ben.root@ou.edu> wrote:
On Sat, Oct 16, 2010 at 2:20 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Sat, Oct 16, 2010 at 12:56 PM, Joshua Holbrook < josh.holbrook@gmail.com> wrote:
On Sat, Oct 16, 2010 at 10:53 AM, Charles R Harris <charlesr.harris@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
FYI for general readers, I found the following discussion on this topic really helpful: http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-q... --Hoyt ++++++++++++++++++++++++++++++++++++++++++++++++ + Hoyt Koepke + University of Washington Department of Statistics + http://www.stat.washington.edu/~hoytak/ + hoytak@gmail.com ++++++++++++++++++++++++++++++++++++++++++
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
On Sat, Oct 16, 2010 at 11:54 PM, Benjamin Root <ben.root@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
On 10/16/2010 09:53 PM, Charles R Harris wrote:
Here <http://github.com/numpy/numpy/commit/43b05fdd1c0ba1c6686297d16d257985dd986d3...>. This looks harmless but it makes the history really ugly. We need to get the word out *not* to do things this way.
Sorry, that was me and my git ignorance. I was trying to commit a small patch but got push rejection. I presumed that my tree was not updated. So I did `git pull` and then `git push` again which resulted the unindented merge above. 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. Thanks and sorry about messing up the history, Pearu
On 10/16/2010 09:53 PM, Charles R Harris wrote:
Here <http://github.com/numpy/numpy/commit/43b05fdd1c0ba1c6686297d16d257985dd986d3...>. This looks harmless but it makes the history really ugly. We need to get the word out *not* to do things this way.
Sorry, that was me and my git ignorance. I was trying to commit a small patch but got push rejection. I presumed that my tree was not updated. So I did `git pull` and then `git push` again which resulted the unindented merge above. 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. Thanks and sorry about messing up the history, Pearu
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
participants (9)
-
Benjamin Root -
Charles R Harris -
Fernando Perez -
Hoyt Koepke -
Joshua Holbrook -
Pauli Virtanen -
Pearu Peterson -
Ralf Gommers -
Stéfan van der Walt