从Bitbucket / Stash查找“拉取请求”的差异

Question

(Stash = locally hosted Bitbucket.)

I have the typical git workflow: create a branch, work on it, push it to Stash periodically, rebase off master periodically, merge to master via Stash.

The result is a pull request in Stash that contains just the right commits.

• Is there a way to find these commits using git on command line? git log does contain them, but git reflog <my-feature-branch> shows only some of them.
• Having found these commits, how do I produce a diff of my PR? The last commit is obvious, but I can't find the right initial point.

Answer 1

Update - from comments, you say you're doing analysis after the branch has been merged and after some rebases. I wouldn't normally assume that matters, because:

1) Either you have my_feature_branch sitting on the commit before the merge, or you don't. You've mentioned being able to see the commits with git log , so I assume finding the branch tip isn't a problem.

2) Rebasing things onto master generally won't change anything with respect to the meaning of master..my_feature_branch or master...my_feature_branch (in their respective contexts).

But since I assume you're not the sort of person who reads the first sentence of an answer and then writes a defensive comment without having tried the advice the answer gave you, that suggests you may have done a rebase that would change the relationship between the branches - in which case the nature of that rebase should be spelled out in the question.

You say you understand that git doesn't know anything of pull requests, yet you dismiss comparisons based on things git does know about and continue to ask if there's a way to have git tell you about the pull request... No, there isn't. What you want is the history of the commit at which my_feature_branch pointed when the PR was created, less any history of the ocmmit at which master pointed at the same time. You may have done operations that complicate that, or you may only think that you have.

If the commit that master pointed to at that time, is reachable (by parent pointers) from master now; and if you have any ref pointing to (or the SHA ID of) the commit my_feature_branch pointed to at that time, then the notation I already recommended will work.

Even if my_feature_branch was rebased, so long as its new base is still in the history of master and the rebase didn't drop or edit commits, the same notation would still work using the rewritten commit corresponding to the old my_feature_branch tip.

If you've rewritten my_feature_branch in some other way (and didn't keep track of the original commit), then your best bet would be to find the tip commit in the reflog and then use regular git log and git diff (as outlined below) using that commit's SHA instead of the branch ref name.

---

Note that a pull request is not a "core git" concept; it is peculiar to the service in which the repo is hosted. What you're really examining is a branch, for which you have issued a pull request.

I don't understand your first question. As you have correctly identified, git log shows the history of the branch. The reflog is something else (a local history of where the ref has pointed in this particular clone) and isn't what you want. I guess the trouble with git log is, how to make it only show the commits that are not yet in master? You can do this by

git log master..my_feature_branch

(Note: two dots in this case.) So if you have

x --- x --- x --- x <--(master)
       \
        A --- B --- C <--(my_feature_branch)

this log output will list A , B , and C .

As for how to do the diff, it's similar but a little different:

git diff master...my_feature_branch

(Note: 3 dots this time.)

This automatically finds the "merge base" for master and my_feature_branch and diffs my_feature_branch against the base.