Re: Phabricator workflow with Git

On Sat, Aug 28, 2021 at 03:02:00PM -0600, Warner Losh wrote:
> Wow! That's convoluted.

/me hides

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


Yes, sorry.

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



Glad that I sent this message here.

So, I'll test/use `git arc`.

Is there anything written about it elsewhere?

Thank you for the prompt reply and the tips.

Regards.
-- 
Danilo G. Baio (dbaio)