Re: Phabricator workflow with Git

From: Warner Losh <imp_at_bsdimp.com>
Date: Sat, 28 Aug 2021 21:02:00 UTC
Wow! That's convoluted.

On Sat, Aug 28, 2021 at 2:44 PM Danilo G. Baio <dbaio@freebsd.org> wrote:

> Hi.
>
> I'm currently using this workflow:
>
> - - - - - - - - - - - - - - - - - - - - - - - - -
>
> // Create a new branch
> $ git checkout -b FEATURE
>
> // Change stuff and git commit
> // Note that you already can include the Review information in
> // Phabricator format.
>
> ```
>   <<Replace this line with your Revision Title>>
>
>   Summary:
>
>   Test Plan:
>
>   Reviewers:
>
>   Subscribers:
> ```
>
> // Open a review with the first commit
> $ arc diff --create HEAD~
>
>
> // If it's accepted, fix the commit log message, rebase with main
> // branch, and push
>

All that's replaced by 'git arc create HEAD'


> $ git commit --amend
> $ git rebase -i main
> $ git push remote_name FEATURE:main
>

git arc stage. This also takes care of adding differential revision, etc.

will stage it into main, then you can just 'git push freebsd' to put it in
the the tree.


> // If it's NOT accepted
> // Change stuff and add a second git commit
>
> // Update review with the two commits
> $ arc diff --update DXXXXX HEAD~2
>

git arc update <commits>

does this automatically.


> // If it's accepted, you can soft reset both commits and do a new one
> // or, just use `git merge and squash`.
>
> // merge/squash way
> // Set the second commit to be squashed
>
> $ git rebase -i main
>
> ```
>   pick   954c5d4626 Readme: First commit
>   squash 7231873f23 Makefile: Second commit
> ```
>
> or
>
> $ git reset --soft HEAD~2
> // And add a final commit
>

I'd document only rebase. The git reset workflow is somewhat more dangerous
and error-prone.

// Submit
> $ git push remote_name FEATURE:main
>

git arc stage
git push

is what I use, but I know lots of people like the branch:main notation.
It's harder to use, though when you lose the race. If you stage on main,
then git pull --rebase will do the right thing in one step rather than
several.


> // Delete FEATURE branch
>
> $ git checkout main
> $ git pull origin main --no-ff
>

--ff-only don't you mean? You *NEVER* want a non-ff pull with upstream.
Ever. It leads to great evil and lost changes.


> $ git branch -d FEATURE
>

Yea, this is what I use, but I have a script that does this over all the
branches....


> I know there are git-arc (tools/tools/git-arc) on base, but I still
> didn't use it.
>

We should only document it, since it hides all this ugliness and makes
things easier, less tedious and less error-prone.


> I just want to check if there are other ways to do that (that you
> recommend), or if can I document it, at least for now, on our
> Phabricator Wiki page [1].
>
>
> 1 - https://wiki.freebsd.org/Phabricator


While you can document what you've said, I found it somewhat confusing to
follow, especially relative
to git arc.

Warner