keith / git-pile

Stacked diff support for GitHub workflows
MIT License
148 stars 11 forks source link

Converting PR to commit on the pile #4

Open keith opened 2 years ago

keith commented 2 years ago

One thing I've found myself needing to do sometimes is take a PR, and "convert" it to a commit on my pile. I think I could create a git pullpr command for this that merged the PR locally, and squashed all the commits. Ideally it gets it into a state where you could then update the PR if you needed. I started working on this here https://github.com/keith/dotfiles/pull/13

buildbreaker commented 2 years ago

I was running into this issue just now. The use case that I have is that I am working with another engineer on a project and we're working on independent tasks. For the integration step, I would like to pick some of the pending PRs from my teammate and pull it into my local git pile so I can start integration work ahead of the PR merge.

What this would be nice too is when I update the PR commit outside the context of my git pile. I'm usually making lint fixes on the GitHub web UI and it would also be nice to pull those changes back and remediate the differences in my git pile from my poor choices.

keith commented 2 years ago

Totally. If the PRs you want to pull in are single commits you can technically just cherry pick those changes, which isn't too bad. If they're multiple commits you can merge them into your branch and rebase -i to squash them all.

As far as updating the commit with remote changes that would definitely also be nice, right now pile does ask you if you want to update the underlying branch if it has been updated remotely, if you go to push a new commit, but that's only to help with making sure you can push new commits, not updating your pile state.

keith commented 1 year ago

I wrote my own script for this that seems to work, but I haven't thought if it would work in all cases or not https://github.com/keith/dotfiles/blob/7667eb94ef1682915a4622e86cad79f44a8ec3bd/bin/git-cp-pr

IanEdington commented 3 months ago

How branch names are generated from commits in git-pilebranchname make this difficult. There isn't a clean way to map from a branch name to a commit name and then back to a branch name. For example, there is no commit that will generate the branch "feat/pre-commit-hooks".

Any change to git-pilebranchname is a relatively large breaking change since it will cause a users current pile be become out of sync with their branchs.

keith commented 3 months ago

Can you expand on your example? Do you mean in the case you have some custom branch name? Or if you change the first message to be out of sync?

One thing I've been thinking about for a while is to store the info about the PR somewhere in git locally only, you see this in messages with some systems like copybara, but also I think you could potentially use git notes to do this as well. I'm not sure if that would help for the issue you're thinking but then we could prefer whatever was stored there vs the default mapping

IanEdington commented 3 months ago

In my case, I'm pulling a branch from another contributor who doesn't use git-pile, but this would happen if I was using GIT_PILE_PREFIX=ian and you were using GIT_PILE_PREFIX=keith.

My co-contributors branch name is feat/pre-commit-hooks.

I tried writing a script to pull the branch and squash it into a commit on the pile, but when it came to naming the commit I ran into an issue. I can't write a commit message that will resolve to the original branch name.

commit message: feat/pre-commit-hooks -> branch name feat-pre-commit-hooks

If I only wanted to pull the branch onto my pile once, this isn't a problem. However, I'd also like to push commits once it's pulled, and might need to update if my co-contributor pushes a commit.

One thing I've been thinking about for a while is to store the info about the PR somewhere in git locally...

I love this idea. Having some kind of data would solve all kinds of issues.

keith commented 3 months ago

in that example, if they're contributing from a fork, i think it would take an extra step to correctly setup the tracking branch to their remote too

IanEdington commented 3 months ago

yeah that would makes sense. Fortunately, that's not the case I'm in since we're both working on the same repo.