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.
Related
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
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.
I often see the below errors on doing git pull on totally untouched files which I am NOT working on.
Pull is not possible because you have unmerged files
It is clear the conflicted files have changed in the git repo. But I don't understand why git pull cannot over-write on these untouched files - which I've not touched?
What can I or my team do to avoid getting these errors?
Edited -
Along with the solution I want to understand why the errors are coming.
Just to make clear, the other team members are working on other files (say xyz). And I am working on a separate set of files having no dependency on xyz files. So if I pull the repo changes after a long time with no changes from my side in xyz, why the conflicts in those files?
use git diff to see problem files
look at this git cheat shets for usefull commands
http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf
http://jan-krueger.net/wordpress/wp-content/uploads/2007/09/git-cheat-sheet-v2-back.svg
There are some tips from my own experience. i'm not sure whether they're 100% corerect)
Split work with your team on paralel threads. Try not to work in the same files.
Try to avoid situations when 2 or more persons are adding new files simalteniously. When one added new files others should make pull as soon as possible
the last but not least - make git push very often. this will keep your project git up to date
Since git pull does not pull individual files, it's git merge phase will stop for manual correction of any merge conflicts. git merge and/or git pull (and by nature of the fact that git pull is essentially git fetch followed by git merge) is an all-or-nothing operation - you either successfully merge the changes introduced on both (or all) of the branches you are merging together, or you don't merge any of them. The catch in that is when conflicts arise that must be manually resolved - but in that situation, you are in an in-between state, having neither completed and committed the merge nor rolled it back to your previous state.
The message you are getting implies that you have previously done a git pull or a git merge, which stopped in the middle, requesting that you manually resolve some conflicts, which you have not yet done, but have rather continued on doing other stuff, and are now trying to do another git pull / git merge without ever having completed the first one.
Take a look at git status, and follow the suggested directions for either resolving your in-progress merge issues or resetting back to a not-in-the-middle-of-a-merge state.
I am using Git to share my code with my team and Eclipse as my IDE. I have installed the EGit plugin for Git functionality. The problem is that I am not sure what the correct steps to sync my local branch with the remote one are (something like: 1. Right click on your repository and team->fetch 2. Pull 3. and so on...).
Currently I know that first I have to fetch (this will update my remote branch) and next I need to pull. Let's say there is a conflict between the remote and local branch; how should I resolve it?
I have read a lot of tutorials on the net, but it seems that my case is too obvious to explain elaborately.
Currently I know that first I have to fetch (this will update my remote branch) next I need to pull
No, you can pull directly: it combines a fetch and a merge.
Any merge conflict that might arise during a pull will be handle like any other merge
If your merge resulted in conflicts (note the red symbols on the file icons), you will have to resolve these manually. Open the conflicting files and scroll to the conflicting changes marked with “<<<<<<<”.
After you are finished the manual part of the merge, you will have to tell Git that the conflicts are resolved. To do so, Add the files and Commit to complete your merge.
How can I restore files before a certain commit in GitHub?
If you want to retrieve an individual file from before the commit f4l4fe1, for example, you can do:
git checkout f4l4fe1^ -- some/file.txt
(When you add a ^ to a ref in git, it means the parent of that commit.) You should find some/file.txt back in your working tree, but note that it will also be staged as a change to commit.
If you want to just see the working tree as it was on the previous commit, you can check out the commit as if it were a branch:
git checkout f4l4fe1^
That puts you into a state known as "detached HEAD" where you're no longer on a particular branch, so making new commits won't advance any branch. To get back to master, say, you'd just do git checkout master.
As a third option, suppose you want to extract a whole directory from that commit, or a whole subdirectory, you can use git archive and pipe the output to tar, as explained in: What's the best way to extract a tree from a git repository?