0

I have already asked a question, but I think it is too complicated, and I have been able to simplify my question enough to warrant a re-write. Please refer to that link if you want to see a real-world example of my problem!

The question is whether it is possible for me to make a special type of git commit on my branch, which is never explicitly merged in future merges of the branch.

The use case is if I have a project that has multiple different makefile configurations (one for each platform) and I want to do development work on multiple of them. So the work will be spread out across the branches (branches being specific to a platform...) and I want to merge together the branches without the merge blowing away the configurations.

Community
  • 1
  • 1
Steven Lu
  • 41,389
  • 58
  • 210
  • 364
  • I don't particularly like this suggestion myself, and I've not tried it, but what about just merging the commits across to the other branch, and setting the merge strategy so it does nothing other than create a commit with two parents? That way, the commit has been "merged", and further merges shouldn't bring that commit across as well. – stwalkerster Mar 05 '15 at 14:08
  • Having a commit that doesn't get merged is kind of like having a commit which isn't really part of the branch history: it doesn't really make sense in terms of SCM. I think your best bet in this situation is to remove them from your repo and provide instructions on how to set up the makefile for each platform. You could keep a copy of each one in a folder to make this easier. – Jon Egeland Mar 05 '15 at 14:10
  • @stwalkerster I have tried this, and basically what I did was `git merge --no-commit --no-ff` and I edited the changes back in (that I needed to keep), however upon merging THIS, those manual changes I performed still got merged into the other side. So it doesn't actually help. Basically, Git is too good at not forgetting code changes. – Steven Lu Mar 05 '15 at 14:10

1 Answers1

0

I guess unless there really is such a feature, I have to just give up on it because Git doesn't support this kind of workflow.

It seems like the "right" way so far is to basically set up cmake or other means of customizing and generating platform specific differences using the same initial seed code (which lives in the source code repository).

I feel like many projects can benefit from having this additional power in the branch, though. Many build systems for small projects can be made a lot more flexible by having a way to easily maintain basic build systems that are whipped up around whatever happens to be available on the given platform.

Meanwhile in my project, I am just going to use shell commands (uname etc) to perform the predication, so I'll no longer try to push this responsibility onto git and leave it on the Makefile.

Steven Lu
  • 41,389
  • 58
  • 210
  • 364