<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Mehdi,<div class=""><br class=""></div><div class="">Hi Mehdi,</div><div class=""><br class=""></div><div class="">See my answer below</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">If you have a local `patch branch` branch for your work, *and* you guarantee that your local master branch never ever diverge separately, then why do you need another branch in the first place. I may be missing some key part of your workflow.</div></div></div></div></blockquote></div><div class=""><br class=""></div><div class="">Precisely because I do not want master to “diverge” due to my own changes !!. The remote branch keeps changing all the time, particularly while I am working on my patch. I have a neurological disability affecting my hands and this means that I am slow at making changes, thus the problem you mentioned on the first place about ‘master’ evolving, is a real one. I minimise it by not touching master. Only after I finished my patch I pull the most recent master, merge it into my patch, and if everything is ok (conflicts fixed and tests run again) I send the diff to Phabricator. After the patch is reviewed and committed I can simply delete my local patchbranch (because it’s no longer necessary) and pull master with my changes already incorporated. At this point I can eventually create the next patchbranch if I plan to submit another one. Or I can maintain several patchbranches and work on the latest one while a previous one is waiting review (and possibly requiring changes). All this without touching master. Maybe this demands more discipline than just “rebasing”, but I have more control and I avoid a ton of rebase conflicts. </div><div class=""><br class=""></div><div class="">I hope this makes sense.</div><div class=""><br class=""></div><div class="">John</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 11 Nov 2019, at 07:10, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" class="">joker.eph@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 10, 2019 at 2:58 PM Joan Lluch <<a href="mailto:joan.lluch@icloud.com" class="">joan.lluch@icloud.com</a>> wrote:<br class=""></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 style="word-wrap:break-word" class="">Hi Mehdi,<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 10 Nov 2019, at 20:27, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank" class="">joker.eph@gmail.com</a>> wrote:</div><br class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">No: the arcanist command does not suffer from the problem I was raising.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">The issue I was referring to is that your reset command will lead to *undoing* changes from master (unrelated to your branch) when you commit in the end (all the changes that are in master but not in "patchbranch").</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">(just try to add `git checkout master && git pull && git checkout tmp` before your `git reset `, and then look at the resulting commit).</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""> </div></div></blockquote></div><br class=""><div class=""><div class="">But I would never do that!. The commands "git checkout master && git pull” are only run before the whole procedure, never in the middle. </div></div></div></div></blockquote><div class=""><br class=""></div><div class="">If you have a local `patch branch` branch for your work, *and* you guarantee that your local master branch never ever diverge separately, then why do you need another branch in the first place. I may be missing some key part of your workflow.<br class=""></div><div class=""> </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 style="word-wrap:break-word" class=""><div class=""><div class=""><div class="">And the patchbranch is always merged with master before starting the procedure.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">If master didn't move then why do you need to merge it?</div><div class="">(always merging master *into* patchbranch before `git reset` is addressing the problem I mentioned though, it just wasn't part of your steps)</div><div class=""></div><div class=""> </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 style="word-wrap:break-word" class=""><div class=""><div class=""><div class=""> The Phabricator diff is created by comparing both branches after they have merged, and the point of reseting ’tmp' to ‘master’ is to obtain a fresh commit containing exactly the same diff. </div></div></div></div></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"><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">In any case, I would want to understand why the archaist command does not suffer from an “evolving” master, which is the problem that you raised first. The “arc patch” command creates a new branch from the local master, so the remote repo can still have changed even before the actual command is completed (!) or at any time after that. So what makes executing that command different?, or maybe I should ask, what is the archaist command actually doing in terms of plain git commands? </div></div></div></div></blockquote><div class=""><br class=""></div><div class="">The important part is that there is no `git reset` involved: after running arcanist you have a branch based of your local master, but you'll still need to rebase it if the remote master has moved in the meantime before being able to push.</div><div class=""><br class=""></div><div class="">-- </div><div class="">Mehdi</div><div class=""><br class=""></div></div></div></div>
</div></blockquote></div><br class=""></div></body></html>