On 05/06/2011 08:20 AM, Vitja Makarov wrote:
2011/5/6 Robert Bradshaw<rober...@math.washington.edu>:
I don't like the default to be "don't pull from me"--I'd rather there
be some convention to indicate a branch is being used as a queue.
Maybe even foo-queue, or a leading underscore if people like that.
On Thu, May 5, 2011 at 2:03 PM, Dag Sverre Seljebotn
<d.s.seljeb...@astro.uio.no> wrote:
Yes, that is the only time it happens.
Do we agree on a) ask before you pull anything that is not in cython/* (ie
in private repos), b) document it in hackerguide?
DS
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Robert Bradshaw<rober...@math.washington.edu> wrote:
On Thu, May 5, 2011 at 1:22 PM, Stefan Behnel<stefan...@behnel.de> wrote:
Dag Sverre Seljebotn, 05.05.2011 21:52:>> >> There was just a messup in
git history: Mark's OpenMP pull request got>> merged twice; all commits
show up two times.> > What (I think) happened, was that Vitja pulled in
Mark's changes into his> unreachable code removal branch, and they ended up
in his pull request. I> guess I was assuming that git wouldn't care too
much about branch> duplication, so I just accepted the pull request via the
web interface.> Apparently, it did care.> > I tend to rebase my local
change sets before pushing them, and I think it> makes sense to continue
doing that. +1, I think for as-yet-unpublished changes, it makes the most
sense to rebase, but for a longer-term branch, merging isn't as disruptive
to the history (in fact is probably more reflective of what's going on) and
is much better than duplication. To clarify, is this only a problem when we
have A cloned from master B cloned from A (or from master and then pulls in
A) A rebases A+B merged into master ? If this is the case, then we could
simply make the rule that you should ask before hacking a clone atop
anything but master. (Multiple people can share a repeatedly-rebased branch,
right.) We could also us the underscore (or another) convention to mean
"this branch is being used as a queue, puller beware." Surely other projects
have dealt with this. - Robert
About my branch:
I've rebased it from upstream/master at home and made "forced push"
At work I pulled it back and rebased from origin, then I tried to
rebase if again from upstream/master
Do I understand correctly that you:
a) You make local changes at home
b) Rebase them on cython/master
c) Force-push to vitja/somebranch
d) Go to work, where you have other local changes
e) Rebase your work changes at work on top of vitja/somebranch
If this is correct; then this can't work. The reason is that after the
force-push in c), there are no shared commits (apart from what's shared
from cython/master) between your work computer and vitja/somebranch.
So the rule is: If you rebase a branch, then if you have other copies of
that branch (like on a work computer), destroy them (e.g., git branch
-D)! And then fetch new copies of the branches.
(And as you say, if you do have different changes in many places then
you can recover from an unfortunate rebase by cherry-picking. And you
can always undo a rebase by looking at "git reflog" and manually check
out the old HEAD.)
Dag Sverre
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
