~renerocksai/telekasten.nvim-devel

2 2

Simpler way to checkout GH's PR locally

Details
Message ID
<5FyjQN71LcQ8Azl8dgz1P6mjLpZx0z_6VpG1yMqm4dd8Rb0d4O56Rb-mr0TGqqpHuCIHBSA6XOjNHJlMb5r17bl3bPTv3FaI42FB-NS-b5Q=@tlambert.be>
DKIM signature
missing
Download raw message
Hi Rene,

In your reply on PR 158, you mentioned a workflow for checking locally GitHub
PRs using `curl` and `git am`. I did not want to go off topic on that PR
discussion, so I send this email instead...

> BTW: If you add `.patch` to the PR URL, you get a nicely formatted patch:
>
> https://patch-diff.githubusercontent.com/raw/renerocksai/telekasten.nvim/pull/158.patch
>
> Curling the patch and piping it to `git am` is super easy. relaxed - well,
> usually. Unfortunately, you using tabs and spaces, this somehow makes git
> complain. So I had to re-format the patch to make it apply in order to
> briefly smoke-test it.

I don't know if you know about that, but there is an other option that I like
better (mainly because it does not require you to copy/paste and edit the URL).
This would probably also prevent the reformatting you needed to do before applying
the patch...

Just add the following in your git config:

```
[alias]
  pullify = config --add remote.origin.fetch '+refs/pull/*/head:refs/remotes/origin/pr/*'
```

You can then just use `git pullify` then `git fetch` and it will fetch the PRs
in separate branches. Then simply `git checkout pr/158` for instance. No need
to leave the terminal or copy/paste and edit stuff.

Like that, the alias expects you to have github's repo as origin, but you could
likely change that by adding github's repo as a second remote 'github' and
replace 'origin' by 'github' in the alias.


- Thomas
Details
Message ID
<CM7J2RQXUP3I.19M84M83W2GW0@nixos>
In-Reply-To
<5FyjQN71LcQ8Azl8dgz1P6mjLpZx0z_6VpG1yMqm4dd8Rb0d4O56Rb-mr0TGqqpHuCIHBSA6XOjNHJlMb5r17bl3bPTv3FaI42FB-NS-b5Q=@tlambert.be> (view parent)
DKIM signature
missing
Download raw message
On Tue Aug 16, 2022 at 4:16 PM CEST, Thomas Lambert wrote:

> In your reply on PR 158, you mentioned a workflow for checking locally
> GitHub
> PRs using `curl` and `git am`. I did not want to go off topic on that PR
> discussion, so I send this email instead...
>
> > BTW: If you add `.patch` to the PR URL, you get a nicely formatted patch:
> >
> > https://patch-diff.githubusercontent.com/raw/renerocksai/telekasten.nvim/pull/158.patch
>
> I don't know if you know about that, but there is an other option that I
> like
> better (mainly because it does not require you to copy/paste and edit
> the URL).
> This would probably also prevent the reformatting you needed to do
> before applying
> the patch...
>
> Just add the following in your git config:
>
> ```
> [alias]
> pullify = config --add remote.origin.fetch '+refs/pull/*/head:refs/remotes/origin/pr/*'
> ```
>
> You can then just use `git pullify` then `git fetch` and it will fetch
> the PRs
> in separate branches. Then simply `git checkout pr/158` for instance. No
> need
> to leave the terminal or copy/paste and edit stuff.

Thanks for the hint, I didn't know that. It looks vaguely similar to
"manually checking out a pull request" somewhere in the GitHub docs [1],
only slightly more convenient, as you can put your solution into the git
config and it's easy to remember how to checkout a PR.

I think this strikes a good balance between cumbersomeness,
repetitiveness and flexibility to checkout specific PRs.

What I like about the patch curling, is: I don't have to add an
additional (GitHub) remote (which is also the case when pulling in a
PR directly from one specific PR author's repo) polluting my .git
directory, and don't have to pollute my repo with a million branches of
stale PRs either (which I assume is the case - I haven't tried it).

Instead, I can just apply the patch and if I don't like it, I git rebase
-i and delete the commit.

So, assuming that not many PRs will have git confused with tabs and
spaces in the same line, due to correct use of stylua, I think at the
moment I still prefer the patch version. However, everyone's milage
varies 😊.

Irregardless of my preference: thanks for letting me know!!! Maybe this
kind of knowledge is also worth a section in the migrate-to-sourchut
wiki. Maybe a "what to do if I receive a PR on GitHub after having
migrated / while migrating to SourceHut". 

> Like that, the alias expects you to have github's repo as origin, but
> you could
> likely change that by adding github's repo as a second remote 'github'
> and
> replace 'origin' by 'github' in the alias.

Understood. That's what I would've done, too.

[1] : https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally
Details
Message ID
<JkLc_mDoSNTj9vDpUpZEJIMiPXRZbasg_Ftf5WuT3TMuykrmFjyI5F8Y2nzDOpmuvOzaFQBJl8VT48Q-AUIqgwK9nnLqMdulN2vWCut8c2w=@tlambert.be>
In-Reply-To
<CM7J2RQXUP3I.19M84M83W2GW0@nixos> (view parent)
DKIM signature
missing
Download raw message
> What I like about the patch curling, is: I don't have to add an
> additional (GitHub) remote (which is also the case when pulling in a
> PR directly from one specific PR author's repo) polluting my .git
> directory, and don't have to pollute my repo with a million branches of
> stale PRs either (which I assume is the case - I haven't tried it).

True. Indeed this adds all PRs all the time and pollutes your git quite
a lot for repo with many PRs and stuff. I never had this issue before as
I worked only on some very small scale projects. But I just found a fix
while looking a bit more [1]. This allows to only pull one PR at a time
and is a bit more elegant (and it has a clean alias to remove old PR
branches). You would still need to add the second remote though...

> I think at the moment I still prefer the patch version. However,
> everyone's milage varies 😊.

Yep makes sense. It was just to let you know of alternatives in case
it might interest you 😉.

Anyway, this is only useful as long as you continue working with GH
on the side. When telekasten will be fully on SH all contributions
will be through patches and this won't be that useful...


[1]: https://gist.github.com/gnarf/5406589

- Thomas
Reply to thread Export thread (mbox)