In a private repo I created a PR to merge changes from dev into master. The PR shows 168 to be merged automatically - I proceeded with merge and all was ok.
I then created another PR to merge changes from dev to master - I expected 0 files as I had just merged, however it showed the same 168 files, curious I proceeded with the merge and when I looked at the commit, it showed 0 files
This wasn't across a fork - just 2 branches in the same repo - can anyone explain why the PR showed 168 files - was this a caching issue?
The difference between the number of files to be merged and actually merged (0) does indeed point out to a cache issue on the remote side.
I would test the caching issue by making the second PR a day after the first, and checking that 0 (or only a few file if you have pushed new commits on dev) show up.
If the PR does a three-dots comparison (using the base commit), not that since Sept. 2018, you can also do, from GitHub, a two-dots comparison.
See more with:
"What are the differences between double-dot “..” and triple-dot “...” in Git?"
"What are the differences between double-dot “..” and triple-dot “...” in Git commit ranges?"
Related
I have main as default branch and dev as non-default.
I created one issue and one PR to merge from new temp branch to dev branch
In PR, I have mentioned Resolves #1.
When I merge PR to dev branch, the issue #1 does not gets closed as it is non-default branch.
Then I using git commandline inside main branch, I did git merge dev so dev branch is merged to main.
In main branch commits, I can see the Merge pull request ... commit as well.
But the issue #1 does not gets closed even as PR is indirectly merged to main (from temp to dev to main)
Any reasons for the bug ?
Update: -
When merging dev to main , next time I did not used git merge dev on main branch, but I created new PR to merge dev to main.
And it closes the issue.
Why I worked while merging with PR and not when git merge is used ?
This is by design and not a bug
When you merge a linked pull request into the default branch of a repository, its linked issue is automatically closed
And
Note: The special keywords in a pull request description are interpreted when the pull request targets the repository's default branch. However, if the PR's base is any other branch, then these keywords are ignored, no links are created and merging the PR has no effect on the issues. If you want to link a pull request to an issue using a keyword, the PR must be on the default branch.
From
https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue
PS: I have emailed GitHub support also for this in the past. Unfortunately is hasn't changed (yet)
I am analyzing commits from project apache/mina-sshd but I am running to a problem:
All commits in the branch 0.9.x from project mina-sshd (except for the first 3 commits) belongs to branch master but still be shown in branch 0.9.x. Can anyone explain this for me, please? I am thinking it might be because those commits are merged, maybe?
Is there anyway to check what branch a commit belongs to by Python?
Your branch 0.9.x is derived from master. So at the point the branch gets created, it contains all the commits that the other branch has at that point. If you add additional commits to the master after the branch is created, they will not appear anymore unless you merge them.
I was working locally on master branch. (by mistake) but it's ok with me this time as I control my code.
I took the following steps:
Egit->commit and push (to master)
Egit -> pull (to get other developers changes)
I got a message that there is a conflict with one file and I merged it.
Now I see: [My Product | Merged Master (up arrow)2 (down arrow)1]
I see in the symbols next to the files that the other developers created - black sign as if there are uncommitted.
A. What does the 2 up arrow and 1 down arrow mean?
B. Why do I see uncommitted changes? they are not mine
C. How can I work out on master after my merge?
D. I looked in bitbucket and didn't see that my changes were committed to the remote branch. What is wrong?
I know that I am supposed to work on branches - but for now - how do I fix the situation?
A. Two arrows up means you have two commits in your local branch that aren't in the remove branch. The one arrow down means there is one commit in the remote branch that you don't have locally. The solution is to do a git pull followed by a git push
B. Uncommitted changes are probably from your conflict. After a conflict, you have to resolve the conflict, add it to index and then commit that change. This is known as a merge commit. My guess is you have not done this.
C. Work out on master? You mean you want to work directly on top of master? After you resolve your conflict, you should be all set to do that. Branching is better though. To create your own branch just do git checkout -b my_featue_branch
I have 2 branches - master and develop
I have been doing some pull requests in my develop branch where it contains 5 items, in which it is the same as the number of items in master.
However, someone did some commits and pushed in a few more items into the master branch, and hence now it has 8 items.
As my pull request in the develop is still not yet approved/merged, whenever I tried to update my pull request, I am getting the message stating that This pull request can't be merged. You will need to resolve conflicts to be able to merge and asked me to do the following:
git fetch origin master
git checkout develop
git merge FETCH_HEAD
git commit
git push origin HEAD
And this happens after I have 'pushed' out my commits, making me confused at times. Then I realized that it is asking me to re-add and re-commit in the additional 3 new items. So does this means I must ensure that the items and contents between these 2 branches of mine should be the same as always? I have always used git pull/fetch but will there be a better way for me to make sure?
What this means is that GitHub would like to merge your PR branch into master, but it can't, because there are conflicts. As you've discussed in the question comments, the best way to deal with this (usually) is to merge your master branch into develop on the command line. That will show you the conflicts and ask you to resolve them. Once you've completed and pushed that merge, the PR will be mergeable back into master using the green button on GitHub.
You could simply merge your deploy branch into master (which I realize sounds a bit more sensible). In that case, you'd be bypassing the PR entirely. You'd have to close the PR "unmerged", and separately you'd manually push the merge commit to master.
By doing it the first way,
you make a better audit trail by merging to master on GitHub, using the PR;
you give your team a chance to review your code after the merge, before it lands on master; and
if you have automatic tests (such as Travis CI or CircleCI) which check PRs, you give them a chance to run your merged code as well.
In plain language (hopefully with a simple example), what do the ahead/behind metrics on a Github repo's branch mean?
And what are the implications for that branch and the attention it's receiving? Is being "behind" a bad sign for a branch?
Ahead is the number of commits on this branch that do not exist on the base branch. Behind is the number of commits on the base branch that do not exist on this branch.
Ahead and behind are almost like a kind of "age" metric. The ahead number tells you roughly how much impact the branch will have on the base branch should it be merged. The behind number tells you how much work has happened on the base branch since this branch was started.
I find the behind number really useful for judging whether a branch is likely to merge cleanly. When a lot of work has happened on the base branch, it's more likely that the two branches have modified the same line(s). When behind is large, it's a sign that you should probably merge the base branch into this branch to sync up. Once you merge the base branch into this branch, behind will be 0.
If you're more of a visual type, take a look here:
◈ - ◈ - A - ◈ - B
\
◈ - C
A is 2 commits behind and 0 commits ahead of B
B is 0 commits behind and 2 commits ahead of A
C is 1 commit behind and 2 commits ahead of A
C is 3 commits behind and 2 commits ahead of B
So "behind" means the other branch has commits this one doesn't, and "ahead" means this branch has commits the other does not.
The metrics like those you can see for this project describe, compare to a branch from the repo (like master):
the number of new commits that the GitHub repo has done compared to another branch of another repo: those are the behind commits: the other repo is behind compared to the current repo (see those commits).
the number of new commits another branch of another repo has done compared to the current repo: those are the ahead commits: the other repo is ahead compared to the current repo (see those commits).
The technical detail is illustrated by the script "determining which repos are ahead/behind origin":
It is about checking:
what commits are reachable from another branch, but not from the local branch: ahead
git rev-list "$localref..$anotherref"
what commits are reachable from the local branch, but not from the other branch: behind
git rev-list "$anotherref..$localref"
On thing to note is that github's "behind" also counts merge commits. You can check the "behind" stuff with: git log mybranch1 ^mybranch2 and it should show you the same number of commits. If you have merge commits you can exclude them with --no-merges in the last command.