Skip to content

Instantly share code, notes, and snippets.

@devinrhode2
Created June 30, 2022 05:39
Show Gist options
  • Save devinrhode2/b9195309b151f259c1f6a78c755afb4b to your computer and use it in GitHub Desktop.
Save devinrhode2/b9195309b151f259c1f6a78c755afb4b to your computer and use it in GitHub Desktop.

I would DIE for a gui

here's the thing

I create lots of well-sequenced, very intentional commits. They are small and repeatable, so it makes it easy to handle rebase conflicts. Just read commit message, see original diff, and 80-90% of the time I believe anyone should be able to see what the original commit was doing and resolve conflict such that same thing is being accomplished on new base. Almost each commit could be one PR, but maybe sometimes it's better to group few commits into one PR.

I'd like to create a PR stack so that it's easy for others to review my changes, but, I don't want to mess around with git branches locally at all. I'm already a surgeon with rebase.

Ideally, I have a gui tool.

Inside my commit messages, we'll probably need to add some meta data at the bottom, like: chore(foo): Take out the trash ...

PR title: Enhancement: improve animations branch name: enhance/animations PR description: ...

A gui tool should also help create this metadata, find/integrate with whatever templates on are github, etc.

I use github desktop a lot.

It would be amazing if I could right click a commit in a gui tool, fill out a form of PR title, branch name, PR description, etc, and have it automatically add the metadata into the commit message.

The metadata is important, specifically the branch name, because I may edit the commit message, but need a stable handle to tie that commit to a PR. (If a commit does not have metadata, it's grouped along with the next commit that does have metadata into one PR). Raw git refs could also be used for the metadata.

Ultimately, the gui tool will run this under the hood: git push origin 0eb44dd:refs/heads/chore/git-push-sha-syntax-test This one command publishes a new remote branch chore/git-push-sha-syntax-test at the given sha, and avoids creating a branch locally.

With this approach, you want to maintain one local branch (per stack). If you need to make changes lower in the stack, there's maybe two approaches: Create new commit on top, and squash it into commit lower in stack Interactive rebase, and edit the commit lower in the stack. Instead of learning gt stuff, you just use standard git rebase commands, and can use a plethora of git gui tools.

If you have totally independent work, you would have another local branch/stack for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment