Date: Sat, 28 Aug 2021 15:02:00 -0600 From: Warner Losh <imp@bsdimp.com> To: "Danilo G. Baio" <dbaio@freebsd.org> Cc: freebsd-git <freebsd-git@freebsd.org> Subject: Re: Phabricator workflow with Git Message-ID: <CANCZdfqb4VMpa%2BLD1C5tmdf93Mp%2BjoEjE_tVdHigsQB9rLVA0w@mail.gmail.com> In-Reply-To: <20210828204434.n45rsndnehy2tsnb@t480.local> References: <20210828204434.n45rsndnehy2tsnb@t480.local>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000e0a46405caa4e912 Content-Type: text/plain; charset="UTF-8" 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 --000000000000e0a46405caa4e912--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqb4VMpa%2BLD1C5tmdf93Mp%2BjoEjE_tVdHigsQB9rLVA0w>