Re: I'm trying to break "git pull --rebase"
On Tue, Feb 20, 2018 at 5:00 PM, Julius Musseauwrote: > I was hoping to concoct a situation where "git pull --rebase" makes a > mess of things. It breaks quite easily with some workflows. They are all in the "don't do that" territory. Open a long-lived feature-dev branch, work on it. Other folks are working on master. Merge master into feature-dev. Make sure some merges might need conflict resolution. Reorg some code on master, move files around. Code some more on feature-dev branch. Merge master into feature-dev; the merge machinery will probably cope with the code move, file renames. If it doesn't, resolve it by hand. Let all that simmer for a little bit. Then try to rebase. "Doctor, it hurts when I rebase after merging with conflict resolution... " cheers, m
Re: I'm trying to break "git pull --rebase"
On Tue, Feb 20, 2018 at 2:00 PM, Julius Musseauwrote: > Hi, Git Developers, > > I'm currently writing a blog post about "git pull --rebase". The > point of the blog post is to examine scenarios where two people are > working together on a short-lived feature branch, where history > rewrites are allowed, and where both are using "git pull --rebase" to > stay in sync with each other. > > I was hoping to concoct a situation where "git pull --rebase" makes a > mess of things. > > So far I have been unable to do this. I tried version v1.7.2 of Git > as well as version v2.14.1, and as far as I can tell, "git pull > --rebase" is bulletproof. > > Does anyone here happen to know a situation where "git pull --rebase" > makes a mess? If you are inclined to experiment with submodules, I would have an easy answer for you. :) But instead of giving an answer myself (as I love reading about things the usual mailing list folks miss), maybe this is a good starting point to poke at things https://github.com/git/git/commit/a6d7eb2c7a6a402a938824bcf1c5f331dd1a06bb For the non-submodule use case, I would think pull is pretty solid, as you lay out in your blog draft. (If you finish by Wednesday 21st), you may be interested in submitting to Git rev-news (or a later edition if you take time writing) https://public-inbox.org/git/CAP8UFD1HPruE3N_0k8_TFreBML9V8K=ss8lqd-xkeeuhesm...@mail.gmail.com/ Thanks, Stefan
I'm trying to break "git pull --rebase"
Hi, Git Developers, I'm currently writing a blog post about "git pull --rebase". The point of the blog post is to examine scenarios where two people are working together on a short-lived feature branch, where history rewrites are allowed, and where both are using "git pull --rebase" to stay in sync with each other. I was hoping to concoct a situation where "git pull --rebase" makes a mess of things. So far I have been unable to do this. I tried version v1.7.2 of Git as well as version v2.14.1, and as far as I can tell, "git pull --rebase" is bulletproof. Does anyone here happen to know a situation where "git pull --rebase" makes a mess? Here's a draft of the blog post: Title: "(Too much) fun with git pull --rebase" https://mergebase.com/doing-git-wrong/2018/02/17/fun-with-git-pull-rebase/ Here are the "git pull --rebase" scenarios I've tested so far: 1. origin/feature rebased against origin/master 2. origin/feature squash-merged against origin/master 3. origin/feature squashed in-place` 4. origin/feature dropped a commit 5. origin/feature insanity (adjusted merge-base, reversed commits, squashed some commits) 6. undo of 5 So far "git pull --rebase" does the exact right thing in every case! If anyone knows a scenario where "git pull --rebase" fails to do the right thing, I would be very grateful to hear of it. Thanks! yours sincerely, Julius Musseau