-
-
Notifications
You must be signed in to change notification settings - Fork 85
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate with Github pull requests #4
Comments
Hi @qwertzguy, I didn't have any specific plans to integrate with GitHub. Can you clarify more about the workflow you'd like to see? Do you mean as a maintainer, to try out pull requests locally, or as a contributor, to create and update pull requests? You should be able to check out a remote pull request as per the docs here: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally. Then you can just commit/rebase/amend commits as normal. |
And if I may ask, how did you hear about this project? |
Hi @arxanas, I mean as a contributor. My idea of the workflow, would be one similar to FB:
Let me know if that makes sense. I found the project by typing 'git branchless' in Google. I typed that in to try to find tools to have a similar workflow as in FB but with git. So it's pretty by chance that I thought of searching using the same term as the name of your project :) |
Perfect 😄 You should be able to use Fundamentally, you need to have a branch somewhere in order to interface with Github, since it serves as the canonical reference to the tip of the stack you want to send upstream. You have three choices, varying in how much you want to use branches:
The Phabricator diff number D123 is surfaced in the smartlog. I would be open to adding a similar mechanism to surface which Github issues/pull requests are addressed in the commit message. |
Yea I was thinking of option 3 and having a tool that automatically does
the work of generating a remote branch name and keeping the mapping between
commit and remote branch name in order to update PRs. And like you
suggested, I was also thinking of having the pr number show up in the
smartlog (ideally with status and number of comments) and even have a
command to open it in the browser.
…On Thu, Apr 1, 2021, 16:37 Waleed Khan ***@***.***> wrote:
I found the project by typing 'git branchless' in Google. I typed that in
to try to find tools to have a similar workflow as in FB but with git. So
it's pretty by chance that I thought of searching using the same term as
the name of your project :)
Perfect 😄
You should be able to use git-branchless in conjunction with Github. I
recommend that you get the gh CLI client (https://cli.github.com/) for
Github, so that you can do things like create a pull request from the
command-line.
Fundamentally, you need to have a branch *somewhere* in order to
interface with Github, since it serves as the canonical reference to the
tip of the stack you want to send upstream. You have three choices, varying
in how much you want to use branches:
1. Use branches as normal with a Github workflow. In this workflow,
you'll check out directly to the branch and make commits there. When you're
ready to update the pull request, you'll git push (or git push -f, if
you rebased/amended/rewrote any commits). You would gain the nice
visualization for git sl, but not much else.
2. Update your local branch only when you're ready to update the pull
request. You would need to create the branch, but you wouldn't need to
check it out. Understand you make your additional commits on top of the
branch, you can squash them all together and run git restack, which
will update the branch automatically, or you can manually move the branch
with git branch -f. Then run git push/git push -f as normal. This is
how I prefer to work with Github.
3. Only create a branch in your remote repository. Then, you can
update it to an arbitrary commit using an invocation like git push
origin HEAD:my-branch (I think). If you hate branches, then this is
the way to go.
The Phabricator diff number D123 is surfaced in the smartlog. I would be
open to adding a similar mechanism to surface which Github issues/pull
requests are addressed in the commit message.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQPCYBC52KWIJCAXCDUHK3TGT7R3ANCNFSM42GIXMFQ>
.
|
Integrating with Github sounds strategically useful for the project. But I think there are a lot of design decisions that would need to be resolved first.
Since I don't use Github extensively right now, and since the design issues need to be resolved, I don't have any specific plans to tackle this myself. I'm happy to set up a call to onboard anyone who might be interested in implementing it. |
I've been thinking quite a bit about it, but I'm a bit torn on which solution to use. Ideally I would want something close to the workflows at FB, but at the same time it does not match the github workflow well: for example github doesn't support amending a commit in a PR well, it will replace the commit but not let reviewers view previous versions of the commit. Here are some thoughts on your points:
Definitely! I appreciate the discussion and I'm open to work on it. I just need to think a bit more about it and whether it fits well into your project. Out of curiosity: how were you planning to handle code reviews with your tool? Or is the idea to not have code reviews and push into the main branch directly? |
Github integration has a definite place in the project, given that most people using it will probably be using Github. At the very least, we should be able to reflect the work in progress on Github (e.g. linking commits to PRs somehow). We'll have to add write operations as necessary in order to support that workflow (e.g. creating/updating PRs).
There's no specific code review workflow prescribed by the tool at present:
Currently, none of these workflows show review status. I use the Github/Phabricator website tooling to manage my in-progress reviews.
Sounds good to me. We might want to take a step back and think more holistically about the workflow. For example, Phabricator uses a single command to both create and update code reviews ( If we do so, we should decide whether we want to support the one-commit-per-code-review workflow, or the many-commits-per-code-review-workflow, or both.
That's disappointing, but won't that be an issue for people who don't use If we want, we can update
I really don't want to move the local main branch on behalf of the user. It should always represent the remote main branch. There's also the issue that if
An alternative is that we can have local branches which correspond to PRs always correspond to the remote main branch, which will enable this. Then, instead of
I'm not sure if the approach you're proposing handles the evolution of commit: when you
Branches are a concept which the user is already familiar with, and which already has semantics in the
This feature alone itself might be a killer feature for some Github users!
So far, I've tried to avoid having long-running processes, as they significantly complicate the architecture. I would prefer to only add a synchronous update flag to |
There's a lot of prior work in this thread: https://news.ycombinator.com/item?id=26913959 |
Got a busy these past weeks. The HN thread is interesting, especially ghstack. I wonder if using git branchless and ghstack together works. |
It was made by a current Facebook engineer, so I'm hopeful that it fits our workflows! |
Hi, I found this because I have a similar project with the same name: https://github.com/krobelus/git-branchless
that is well supported by my tool. In step 4., you don't need to checkout master again, because you don't switch branches in the first place. My |
@krobelus whoops, I searched for "git branchless" before I named the project, and I thought I didn't find anything. It looks like your workflow is a lot simpler for the common case where your commits don't conflict with each other! I suppose my workflow is better only if you want to do a lot of backtracking and make tree-structured histories. I'm not sure what a better name would be. Maybe for yours, you could emphasize the single branch nature. |
Right, my workflow doesn't offer a solution for the case when there are conflicts. Thanks for your suggestions, I'm leaning towards (bit of a brain dump ahead, soz) I like the concept of hiding commits, I wonder what's the best way to attach such metadata to commits. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Is there a plan to make this tool integrate with Github's pull requests?
I work at FB right now and I notice that your tool is inspired by FB's workflow and I had the same idea of making a tool to replicate the same workflow with git and Github. Your tool seems to match pretty well what I'm looking for aside from being able to do code reviews of the commit before merging them in the main branch.
The text was updated successfully, but these errors were encountered: