On 05/06/2011 09:24 AM, Vitja Makarov wrote:
2011/5/6 Dag Sverre Seljebotn<d.s.seljeb...@astro.uio.no>:
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
Right.
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.)
Thank you for explanation.
So btw, when I do rebase and my changes were already pushed I have to
use forced push.
Is forced push ok?
Forced push is trivially OK if the commits you are "overwriting" has not
been fetched anywhere else (or, you plan to immediately erase them at
their other location). Otherwise, you really need to pay attention.
In general, if you make the following cycle "atomic", you're OK:
- Fetch branch from github
- Make some commits
- Force-push back to github
However, if you interrupt the cycle in the middle, you'll need to spend
time to recover from your "race" :-)
Here's a similar question which lists some convenient commands:
http://stackoverflow.com/questions/3815193/how-can-i-safely-use-git-rebase-when-working-on-multiple-computers
(Although I'm not sure if I recommend getting into the habit of doing
"git push -f", just typing "git push -f origin mybranch" seems a lot safer.)
Dag Sverre
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
