<div dir="ltr">Yep, that's the case. I would say that we're no worse off than we were in terms of testing, as you note. Previously svn would let us racily commit to separate files without testing the new result. Now we're forced to observe the race.<div><br></div><div>At the dev meeting I heard Doug Gregor say something like, "what kind of dirty animals are you, you just push directly to master!?" Based on that, I think other communities may set up workflows where they push branches to places, and some automation rebases and updates master asynchronously, optionally conditioned on some (light) testing or approval.</div><div><br></div><div>Maybe we'll want something like that one day, but for now, we just have to pull, rebase, push, and hope.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 28, 2019 at 4:19 PM Nemanja Ivanovic 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:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Now that we have switched to git and I had to leave behind my wonderfully simple svn workflow I have noticed something curious when committing.</div><div><br></div><div>My typical workflow once my patch is approved on Phabricator has always been:</div><div>- Update my source tree to latest</div><div>- Apply the approved patch</div><div>- Rebuild</div><div>- Retest</div><div>- If all is well, commit</div><div><br></div><div>Having to update again after rebuilding/retesting was extremely rare since SVN only prevented the commit if I am modifying the same file(s) that have been modified upstream since my update.</div><div><br></div><div>So I tried replicating that workflow with git, but apparently that isn't really an option. Apparently git won't let me push if there have been any commits upstream at all between my last pull and my push. This means that I can never push from a fully tested state since it is almost impossible to find a window of 20-30 minutes without any commits (which is how long a rebuild/retest takes for me).</div><div><br></div><div>One might argue that this is no worse than what I had with SVN since I would commit on top of changes that already happened upstream. But this is not always the case. Namely, if an upstream commit modifies the same file, causing a semantic conflict, I would not end up committing with the old svn workflow whereas I would end up committing with the new git workflow.</div><div><br></div><div>I am not sure if this is something that can be solved (nor if it is something that needs to be solved) but I thought I would just bring it up.<br></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>