[llvm-dev] Workflow to commit changes using git alone (?)

Mon Nov 11 00:06:59 PST 2019

Hi Mehdi,

See my answer below

> 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.

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. 

I hope this makes sense.

John

> On 11 Nov 2019, at 07:10, Mehdi AMINI <joker.eph at gmail.com> wrote:
> 
> 
> 
> On Sun, Nov 10, 2019 at 2:58 PM Joan Lluch <joan.lluch at icloud.com <mailto:joan.lluch at icloud.com>> wrote:
> Hi Mehdi,
> 
>> On 10 Nov 2019, at 20:27, Mehdi AMINI <joker.eph at gmail.com <mailto:joker.eph at gmail.com>> wrote:
>> 
>> No: the arcanist command does not suffer from the problem I was raising.
>> 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").
>> (just try to add `git checkout master && git pull && git checkout tmp` before your `git reset `, and then look at the resulting commit).
>>  
> 
> But I would never do that!. The commands "git checkout master && git pull” are only run before the whole procedure, never in the middle.
> 
> 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.
>  
> And the patchbranch is always merged with master before starting the procedure.
> 
> If master didn't move then why do you need to merge it?
> (always merging master *into* patchbranch before `git reset` is addressing the problem I mentioned though, it just wasn't part of your steps)
>  
> 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. 
> 
> 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? 
> 
> 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.
> 
> -- 
> Mehdi
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191111/2fca0325/attachment.html>