"[email protected]" <[email protected]> writes: > Le Dec 11, 2011 à 3:04 PM, David Kastrup a écrit : > >> >> If Mike had used git pull -r instead of a plain pull without rebase, >> this "mess" would not have happened. > > > Ok - will do from here on out.
The problem is that it is hard to prescribe a universal recipe for how to use pull because pull can be used in many situations. I would actually prefer if people _never_ actually did any work on their own copy of staging. The reason is that git has no way to distinguish work done by the user himself from residue left around after the upstream staging had to back out some changes. Whether or not you use pull -r or pull or whatever else, you might have more than just your own changes in your local copy staging when compared to upstream. That's why I first do git fetch, then something like git checkout -B staging origin/staging which _destroys_ the current version of staging and replaces it with that from origin, then git cherry-pick feature-commit git rebase origin/staging feature-branch (note that you now may have the current state of staging embedded in your feature-branch and might need to back it out again if the feature-branch gets thrown out of staging along with other material) before git push origin HEAD:staging More often than not, the HEAD I push to staging is not on a proper branch. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
