<div dir="ltr">Another aspect is that rebasing a long-lived branch leads to an history that does not make sense: you would likely just fix the APIs uses for the top of the branch after rebasing which will lead to most of the history that can't be build: this kills bisection since you can't build previous revision of your own project (unless you actually fix every individual commit during rebase, but that's not scalable).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 7, 2021 at 10:55 AM Geoffrey Martin-Noble via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">To avoid the issue of constantly having to rewrite history, you could merge from your main branch instead of rebasing. If I was contributing to a project and I constantly had to drop my local history, I'd probably be a bit grumpy. You lose the benefit of your entire stream of patches being based on HEAD, but I'm guessing that eventual upstreaming wouldn't be merging things in the historical order of patches anyway? (but maybe I'm wrong, I've never upstreamed a target). Merge commits get a bad rap, but I think they're actually quite a useful tool in git when used judiciously, and if you know about `git log --first-parent` most of people's complaints about them are handled.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 7, 2021 at 9:42 AM Min-Yih Hsu via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Hi,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 7, 2021 at 5:52 AM <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> Dear all,<br>
> <br>
> we are integrating support in Clang + LLVM for a target architecture (an<br>
> accelerator device) we are developing. Currently, we have a git<br>
> repository, which contains LLVM 9 together with the added/changed files<br>
> from us.<br>
> <br>
> Now, we want to have a sustainable strategy for handling the<br>
> llvm-project repository together with our changes. To summarize, we want<br>
> to migrate to LLVM 12, start with 12.0.0, add our target architecture<br>
> support based on this version, continue development of our target, and<br>
> from time to time get the latest changes from the official llvm-project<br>
> repo so we keep up to date over time.<br>
> <br>
> Hence, we somehow have to "merge" the llvm-project and our repository,<br>
> and keep history of both. As far as I know, there are several ways we<br>
> could do this, e.g. using submodules or subtree merge.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
I haven't personally had to deal with a new target, so someone who<br>
has done it might have different suggestions.  I've cc'd Min who<br>
seems to be the one driving the recent addition of the M68K target,<br>
which is the most recent new target added to LLVM.<br></blockquote><div><br></div><div>Yes, we actually had the exact same problem when we tried to migrate from LLVM 8 or so to mono repo. We used a script back then: <a href="https://github.com/M680x0/M680x0-llvm/issues/58" target="_blank">https://github.com/M680x0/M680x0-llvm/issues/58</a> </div><div>But note that this script only does ~70% of the work. I still spent quite some time doing some migrations manually and cleaning up.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
I do have extensive experience with managing downstream changes and <br>
handling merges, so I have suggestions based on that experience.<br>
<br>
In your situation, I think the simplest way to manage your changes<br>
is to start with a clone of upstream LLVM, which has its 'main'<br>
branch.  Then create a 'target' branch off of 'main' and do all your<br>
work on 'target'.  When you decide to update to a new revision of<br>
LLVM, you use 'git pull' to update 'main', and then *rebase* your<br>
'target' branch.  This tactic keeps all your changes at HEAD, with<br>
history intact, which vastly simplifies figuring out where bugs <br>
have come from.  It would also be straightforward to move from a<br>
rare pull/rebase to doing this more frequently, which will reduce<br>
the "merge pain" of each pull/rebase.<br></blockquote><div><br></div><div>Second this approach. This is also roughly what I did before M68k got upstreamed. It's also easier for you to collect patches if you plan to upstream your target in the future (just pick commits on the tip of your target branch). The only (little) downside was that there were some users who wanted to try our tree and using rebase meant that they needed to `git pull --force` every time they updated.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
I do *not* recommend what we (Sony) did, which is to keep our<br>
changes intermixed with upstream changes.  That decision was made<br>
too long ago to do anything about it with practical cost.  We have<br>
an automated merge system to keep ourselves continually updated to<br>
upstream HEAD, which is an ongoing maintenance cost but much much<br>
better than trying to do the same thing once every six months or so.<br>
<br>
More about how we operate can be found here:<br>
<a href="https://llvm.org/devmtg/2015-10/#tutorial4" rel="noreferrer" target="_blank">https://llvm.org/devmtg/2015-10/#tutorial4</a><br>
<br>
> In the future, if support for our target architecture is mature, and the<br>
> hardware is publicly available, for us it would be interesting to have<br>
> our target support in the official llvm-project repository, in which<br>
> case our additions potentially would have to go into the official repo.<br>
<br></blockquote><div><br></div><div>Upstream the target is another whole story. I can provide some tips and suggestions on this matter when you decide to do so.</div><div><br></div><div>Best</div><div>-Min</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
This is another reason to try to keep your downstream changes at HEAD.<br>
It will be much easier to post your new target's patches if you are<br>
already based on top of 'main'.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
Best Regards,<br>
--paulr<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Min-Yih Hsu</div><div>Ph.D Student in ICS Department, University of California, Irvine (UCI).<br></div></div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>