Re: I'm trying to break "git pull --rebase"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 20, 2018 at 2:00 PM, Julius Musseau <julius@xxxxxxxxxxxxx> wrote:
> 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-XkeEuheSmGvw@xxxxxxxxxxxxxx/

Thanks,
Stefan



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux