Rebasing against GCC

[philberty]

Last time the front-end was rebased against GCC Master was on:

b8ae081

We need a strategy for when we rebase the front-end as this requires a force push back to master

[tschwinge]

@philberty, do you really intend to git rebase, or rather git merge? The latter would be much simpler to do (and I shall offer to do that every once in a while; I'm loosely tracking GCC master branch for work purposes anyway). Doing it this way also avoids the non-fast-forward issue (Git history rewriting). What, for this project here, would be the benefit of a (periodical) real git rebase?

[philberty]

Good point, I have been assuming that in the event of going upstream to GCC this would require a rebase against GCC so all the front-end work is ontop at that point but if merges are ok then let's do that.

[tschwinge]

Eventually integrating this work into GCC upstream would -- per current upstream rules; I didn't invent these ;-) -- not be done as a git merge, but also would not preserve the individual development commits (of this repository here), but would rather squash all development commits into one big commit. So, some kind of rebase will be required at that point, but that's then the simple matter of (logically) rebasing/squashing the whole development history into one commit, on top of upstream master branch. (And that's not something we have to worry about right now, so no point spending any effort on that, from my point of view.)

[tschwinge]

..., and of course, any changes to existing GCC code (bug fixes, enhancements, etc.) shall be contributed individually, at any point in time, outside of the big "Add Rust front end" commit. Also, adding run-time libraries, etc. is often done in separate commits from the one adding the front end proper. We'll sort that out once we get to that point. ;-)

[NalaGinrut]

I think we've been using git rebase for a long time since this project was awake last year. Why not just keep it?

[tschwinge]

@NalaGinrut: a git rebase rewrites Git history (making invalid existing refernces to Git commits), requires force-push, and thus requires that any open development branches also be rebased, too. And on the other hand, I don't see any benefit of a git rebase over a simple git merge; the latter would seem simpler. Would you prefer git rebase?

[NalaGinrut]

@tschwinge @philberty Well, I realized that you guys are talking about using git merge when synchronizing with the upstream code, If so then I agree, otherwise, people have to reset the local repo for few commits then pull again. When the code goes to GCC someday, we'll not submit the git history, but a patch set. So merge is fine even it looks ugly in git commit-graph for a while.

What I mean is to keep using git rebase for contributors, so that we can keep the branch code on the top of the target branch. And it's OK to let branch contributors push with -f. I think it's unrelated to this issue.

[tschwinge]

As again mentioned in today's Status Report Call, I'm working on this.

---

Aside from the GCC/Rust-specific files (not existing in GCC upstream), we also carry a lot of changes in gcc/config/ (GCC back ends implementations), originating in @SimplyTheOther's work on Rust Target Hooks. For a few of these files/changes we run into merge conflicts (which I did sort out), but also this work may need updates corresponding to GCC upstream changes. As that work is (per the Git commit logs etc.) still very much work in progress, and I assume hasn't been tested with all the respective many GCC back ends, I'm not going to spend much effort on that, and just make sure that x86_64-pc-linux-gnu continues to work.

[philberty]

Looks like we can close this issue since we can merge from upstream rather than a rebase