Re: Phabricator workflow with Git

I think you can:

cd tools/tools/git
make install

Then open up the man page:
man git-arc

On Saturday, August 28, 2021, Danilo G. Baio <dbaio@freebsd.org> wrote:

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