0

From git-merge Documentation:

By default, git merge command refuses to merge histories that do not share a common ancestor. This option can be used to override this safety when merging histories of two projects that started their lives independently. As that is a very rare occasion, no configuration variable to enable this by default exists and will not be added.

I am in that rare occasion frequently, for it is much convenient for my users to download the repo manually, not clone, then after that add the remote and merge. Since the local repo is always news, it is always safe to bypass this on the first pull. Is it possible to set this as default, at least on the first pull? This would be their first time to use any thing technical, so I want them to a GUI software as much as possible. I can setup a script for them to double click.

Ooker
  • 1,969
  • 4
  • 28
  • 58
  • 1
    You can't, at least not in Git. Some IDE may or may not have such a setting. But you shouldn't use it anyway: making the histories unrelated like this is a bad idea in general. – torek Oct 30 '22 at 14:31
  • Yeah, but as I explained I can guarantee that pulling for the first time is always safe in my specific case – Ooker Oct 30 '22 at 14:56
  • "I can setup a script for them to double click" Then set it up. What's the question? – matt Oct 30 '22 at 15:28
  • 1
    How is this more convenient than cloning: "for it is much convenient for my users to download the repo manually, not clone, then after that add the remote and merge". – TTT Oct 30 '22 at 15:30
  • @TTT Sorry. It's because I suspect that there are some files that have a long name, so the cloning terminated in the middle. At least in my Windows machine. Together with [this requirement](https://softwarerecs.stackexchange.com/q/84233/6389), I think it would be neater for the inexperienced users to download it via Google Drive to explore the data first, then granularly teach them using git later – Ooker Oct 30 '22 at 17:13
  • Hi @matt, I'm reading your series at [Picturing Git: Conceptions and Misconceptions](https://www.biteinteractive.com/picturing-git-conceptions-and-misconceptions/ "Picturing Git: Conceptions and Misconceptions - BiTE Interactive"). You are surely good at grasping the insight of the issue as well as the inside voice of the readers to address their concerns magnificently. Thank you so much for your time writing it. I will absolutely recommend anyone who are new to git to read it. – Ooker Oct 30 '22 at 17:27
  • Anyway, what I want is to make sure that my script won't set `--allow-unrelated-histories` by default. And I realize that the bare command already *won't*. I'll need to test if my question is already solved or not. Many thanks – Ooker Oct 30 '22 at 17:27
  • 2
    I'm not sure I'm following what you're trying to do, but regarding long paths in the repo, [this may help you](https://stackoverflow.com/a/52699496/184546). – TTT Oct 30 '22 at 18:07
  • 1
    I think this is an ABA question : you have an idea in mind, you thought about a way to implement it with `git merge` and ask a question about git merge. But the few elements you give point to a pretty weird usage of git merge, and do not describe your initial idea. (for starters : in your use case, users would systematically have a conflict on each file they modified, and each file that got modified in `master`). Can you please describe your initial idea ? – LeGEC Oct 31 '22 at 08:52

0 Answers0