On 05/06/2011 09:24 AM, Vitja Makarov wrote:
2011/5/6 Dag Sverre Seljebotn<d.s.seljebotn@astro.uio.no>:
On 05/06/2011 08:20 AM, Vitja Makarov wrote:
2011/5/6 Robert Bradshaw<robertwb@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.seljebotn@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<robertwb@math.washington.edu> wrote:
On Thu, May 5, 2011 at 1:22 PM, Stefan Behnel<stefan_ml@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-w... (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