llvm dev - Nov 2019 - Workflow to commit changes using git alone (?)

Hi Mehdi,
> On 10 Nov 2019, at 20:27, Mehdi AMINI <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. And the
patchbranch is always merged with master before starting the procedure. 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?

Thanks 

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191110/900d7116/attachment-0001.html>

On Sun, Nov 10, 2019 at 2:58 PM Joan Lluch <joan.lluch at icloud.com>
wrote:
> Hi Mehdi,
>
> On 10 Nov 2019, at 20:27, Mehdi AMINI <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/20191110/f95ac645/attachment.html>

Hi Mehdi,

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>