On github, is there a way to see all the previous commits in a repository that resulted in a conflict and require human to resolve at the end?
Edit: if I try to push an update to the repo and it resulted in a conflict, does github records that at all? I can definitely see if on my local clone.
Not that I know of.
You have a tool which allows you to pinpoints the commits causing conflicts during a merge (see "How can I find out which Git commits cause conflicts?")
But once the merge is done, the resolution information is not recorded with it.
(a mechanism like git rerere is only local to your clone, not on the GitHub side)
Github does not do it but another tool can be used to have a track on GitHub. git which comes with (git-gui) automatically includes the conflicts in the merge commit. So it is recorded in the github.com in merge comments automatically. One can look in the history of each file individually it see the changes.
An example comment is like:
Precedes:
Merge branch 'upstream_master' into local_master
# Conflicts:
# lib/Styles/variables.scss
# lib/Views/UserInterface.jsx
# wwwroot/config.json
# wwwroot/favicons/manifest.json
# wwwroot/index.html
Related
I'd like to know how to proceed in GitHub where I could to be able to get the updates from the original repo but prevent opening a PR after each time I push a change made by myself?
The concept I want to apply this is to use a blog template for my GitHub pages. I'd like to get the feature for the future if the contributors would make any but at the same time, I'd like to prevent pushing anything to the original repo as a PR since those commits wouldn't include anything related to making a contribution to the project.
PRs aren't generated automatically, you need to explicitly create them from a branch.
You can fork a repo and work on it, and when needed, fetch and rebase from the original repo you forked from. As long as you don't explicitly use this repo to create PRs on the original repo, you should be fine.
EDIT - Adding some details as per the last comment:
Assume there's a repo called something owned by someone. You can start off by forking it to youruser using the GitHub UI. Then you can clone your fork and work on it:
git clone https://github.com/youruser/something.git
In order to get the recent changes from the original someone/something repo, you need to set it up as a remote. By convention you'd call this remote your "upstream", but you can really give it any name you choose:
git remote add upstream https://github.com/someone/something.git
Once you've added it as a remote, you can fetch from it and rebase on top of it:
git fetch upstream && git rebase upstream/main
(note that using the main branch is just an example. You can of course rebase on top of any branch in the remote repo)
I think it's not possible because when you clone or fork that repo, from that time, you start to add your own content to it since it's your personal blog. So you cannot keep getting the features from main repo. Maybe you can try rebase but I'm not sure if it works for this case. Or you can add those features to your repo by your own whenever you need them.
Using gitHub (and Eclipse Egit, and SourceTree) with a forked repo, how can I make a pull request that just contains a few select files I want pulled?
This question asks almost the same thing, but addresses 'cherry-picking' a single or group of commits. I seem to need to have a pull request with just a few files from within a larger commit.
I tend to make a lot of changes to a lot of files putting in debugging code then find a solution that may involve only a change to a file or two. I don't commit very frequently so I don't have have a commit that contains only the changes that fix the problem (and I like keeping the debugging hooks in my copy of the code.)
I'd like SourceTree or eGit/Eclipse to: 1) show me which files are different between two commits and 2) let me select which files to include in a pull request. Perhaps I could do some selective merge files in my current master head and the master of the upstream repo?
I think what you want to do is to check out a number of files from a given commit / tree / revision.
To do this use:
git checkout [tree-ish] -- [paths]
[tree-ish] is a git-ism that basically means a commit, tag or branch, or something that refers to one of those. So if you have a remote remotes/foo/bar and you want baz.c from that revision, you do:
git checkout remotes/foo/bar -- baz.c
A 'pull request' is not a git thing, but a github thing. You will need to do a git remote add to add the repo you want to pull, then use git fetch or git remote update to pull the relevant information, then use the appropriate branch name in the above to get the file(s) you want.
I've accidentally deleted a branch on my github repository.
I've searched up for a solution, and tried the methods mentioned here and here, but because I never merged that branch into master - I don't see it in the reflog at all.
My only local working copy that still has that branch on it is unreachable for few days because of technical issues.
Is there any way to recover that deleted branch?
The quickest way remains to write to GitHub support: they do have access to the refleg of the GitHub repo, and can restore that branch for you.
Then a simple fetch would allow you to recover that same branch in your local repo.
If you are not working through GitHub(say BitBucket..) and the branch you have in your local does not lave the log for unmerged branches in reflog, then there are two options
1) find a team member who has last fetched from the repo and can access all the branches in his fetched repo. He can then transfer to each of the remote branch and push that particular code up to the repo. You can go back in your other workspaces/folders to see if you have fetched from any other feature branches and can do the same.
2) ask all other team members who are working on their local branch to push their code up the repo recreating the structure for (only live) branches.
This will be still incomplete as the restructuring will miss the commits after the last fetch till the current merge and the tree history will be modified in its refs . But at least it will avoid complete loss of code base and history.
I have a git project that I'm about to push to SourceForge. The origin for my local repo is a shared file system repo that gives me a backup facility.
When I eventually add SF as another remote I just want to push the latest (= versioned) commit to it as the starting base of my code on that repo, and not include all the previous commits that contain possibly rubbish/sensitive/embarrassing code.
My question is similar to this one, except that question was about just leaving out some of the history - I want to leave out all of the history and have the latest commit to become the starting point of the project code on SF. Importantly, having done this, I want "push to upstream" to continue to work even though origin and SF will be different.
Is this possible? Incidentally I'm doing this through Eclipse ie. eGit.
Update
My original question should have been clearer, although the answers so far have helped clarify exactly what I'm trying to achieve.
I want just consolidated commits pushed to SF, representing the published versions.
This is what I want to do:
[master] A--B--C--D--E--F--G--H--I... --> push to origin (private)
\ \
[public] V1----------V2... --> push to public remote repo
#michas's answer starts me off with V1 on branch public, but I can't figure out how to continue to extend this branch with subsequent version commits. I've experimented with rebase but can't get the result I want.
It sounds like you want to start with a new repo. Why don't you just delete or rename your old repo and create a brand new one. Then copy all of your files in, commit them, and push.
Well, you cannot push the current commit, as this commit contains the whole "rubbish" history.
However you can create a new commit with the same content but without any history.
git checkout --orphan fresh # create a new branch called `fresh` without any history
git commit # add your work as a new commit
git diff fresh master # the both branches should contain the same content (assuming you original branch was called `master`)
git log # verify the current branch does not contain any history
git push sf fresh # push that branch
git push sf fresh:master # (or you might want to call that branch master on sf)
The answer provided by #michas didn't allow me to subsequently maintain the branch with consolidated history. This required the use of git merge --squash. The scheme I eventually came up with was similar to the one described here.
Just tidying up so the question has an upvoted answer.
There is a project on GitHub that I have forked. My workflow involves cloning my fork to my local machine.
Occassionally I commit my changes to my local branch. And eventually I push those changes to my fork on GitHub. I do this so I can work on my project at work, push my changes, then go home, pull the latest from my fork and continue working.
At this point, on my branch, I have several commits. I want to link my changes to some people for code reviews, but when I view an individual commit, it's diff is only compared to the previous commit from me. I don't want my peers to have to sift through all my commits trying to understand what changed from the beginning.
Is it possible to specify exactly which commit you are diffing against? In my case, I want to diff my latest commit against the latest commit in the origin branch.
If not, is there a way to rebase a fork on GitHub so that it combines my selected commits into one commit?
In most git based code reviews, it's normal practice to go through and review every commit and comment separately for each one. This is normally to help enforce good coding practices in terms of commit size and scope and testability.
In the command line, almost all commands support a revision interval as an argument
git diff <some commit>..<some other commit>
git log <some commit>..<some other commit>
and that will give you the results for changes solely within that range
also there is a difference between
git diff <some commit>..<some other commit>
and
git diff <some commit>...<some other commit>
as the third dot means inclusive, also showing results for which defaults to HEAD
In the github web client I don't think you can do this, I just checked their native client and it's a no go as well.
I did just look at Atlassian/bitbucket's SourceTree and that allows you to shift-select a range of commits as you're expecting