I have following situation, github is my origin, and I see there is branch with name Release1.0. I see it also in my console:
xyz#yxz MINGW64 /c/myreponame (Development)
$ git remote show origin
* remote origin
Fetch URL: https://github.com/myorganization/myreponame
Push URL: https://github.com/myorganization/myreponame
HEAD branch: Development
Remote branches:
Release1.0 tracked
Development tracked
But when I try to switch to that branch I see:
xyz#yxz MINGW64 /c/myreponame (Development)
$ git checkout --track Release1.0 origin/Release1.0
fatal: Missing branch name; try -b
I think important note, here Im using Windows, may it is some problem with upper case in branch name? Windows is case insensitive.
UPDATED to reflect an edge case that would mess with the checkout shortcut
This means that you haven't yet created the local branch Release1.0. The branch exists on the remote, and you have a tracking ref for it - that's what the show origin output is telling you.
But the checkout syntax you're using isn't correct for setting up the local branch to track the remote branch. Simply
git checkout Release1.0
will likely work. This is a special case "shortcut" built into the checkout command, because it's common to want to "copy" a branch from the one available remote. The cases where it won't work:
If there are multiple remotes with the same branch name, then git will not know which one to check out so will refuse to use the shortcut.
If you have a tag with the same name, git will check that out (in detached HEAD state) instead. In that case you can still create the branch (without the shortcut; see below), but beware of having a tag and a branch with the same name. (In practice git has fairly sensible rules for how any given command will behave, and you always can disambiguate between the tag and the branch; but it's better not to have to think about such things.)
The other way, besides the shortcut, to create the branch: you can use the -b option (as the error message indicates), as that's the more general way to create a branch during a checkout operation. Or you can use git branch.
Unless there's more going on than you've spelled out, this is not a windows / case sensitivity issue. Note that saying "Windows is case insensitive" is not meaningful. It is correct that Windows typically uses file system with case-insensitive filenames, and this would cause problems if you tried to create two branches whose names are identical except for case. But nothing says that branch names have to be all-lowercase (which would actually be a peculiar form of case-sensitivity).
Related
Branch "abcd/child" is created from "abcd/master" . Changes are made to "abcd/child" and meanwhile "abcd/master" also have added changes. Now how to make sure the latest changes are pulled from "abcd/master" is available in "abcd/child" using git commands in git bash?
Assuming abcd is the name of your remote, here's how I'd do it:
git checkout child
git pull
git merge abcd/master
git push
When you checkout child, it'll probably say "set up to track remote abcd" or similar.
The git pull command does two things: It fetches all updates from the server (on all branches) to your local git repo, and it updates your branch to match what's on the remote.
The git merge abcd\master means to specifically bring in all of the commits that are on the remote's copy of the master branch. That's important because you may not have updated your local master to have all those commits.
Note also that you might get conflicts in the git merge if both abcd and master have edited the same sections of the same file. There's lots of help in resolving git merge conflicts.
Also: You want to make sure everything works after the merge. It's possible that the changes on master broke an API that you were using, so you may need to make edits to deal with that.
Update: My assumption about abcd being the name of the remote is wrong.
First, get the name of your remote with the git remote command. Mine goes like this.
git remote
origin
So I only have one remote, and I call it origin. That's pretty common. If you've got more than one remote, it'll be trickier.
So, with "origin" as the remote it goes like this:
git checkout abcd/child
git pull
git merge origin/abcd/master
git push
Obviously substitute the name of your remote if it's not origin.
Same caveats apply about conflicts and making sure it works.
After an "unsuccessful" git pull on my local master, an error prevents to switch back to master:
C: repo_folder> git checkout master
error: invalid path '?'
The ? must be because it is a keybase repo.
From another branch where I checked out some files of the last commit:
C: repo_folder> git diff origin/master --compact-summary
"\004" (gone) | 1902 ---------------------------
some irrelevant stuff | (num) -
The removed file "\004" (that was never present in my local) seems to come from some Mac OS (someone might have opened a csv and a temporary file was created when that user did the commit and pushed?).
observe that the file that is marked as (gone) is to be removed by git
the problem is that the filename has characters that are not compatible with the Windows file system and that the file never existed in my local Windows repo.
If I clone from a Linux platform, I can checkout to master with no problems. However, in Windows, there's no way back to the master branch.
Any ideas on how to solve this issue? (already tried some posts with no success)
I can't really understand how it comes git doesn't even allow me to checkout to master. Should I file a bug report?
Alternatively, perhaps I could create a new master branch and get rid of the current one.
EDIT
A clone from Linux helped to identify that the file ? was actually there.
This could be checked directly from Windows as well by using the command: git ls-tree origin/master (which was showing the original problematic name "\004")
The accepted answer includes the case where you want to save the content of the file, while in my case I only wanted to get rid of it. So in my case, I have just deleted the file from Linux, committed and pushed the change, and did a git fetch origin master:master to fetch my local master with being checked out in another branch (as I was not able to checkout to master). This finally did the trick and I could checkout to master.
Hope this clarifies to someone with a similar problem.
? (or maybe it's EOT) cannot be used as a filename on Windows. The file will have to be deleted or renamed. You can do this most easily by cloning on a system which does allow ? and making the fix.
If you only have Windows, Fixing Invalid Git Paths on Windows offers a method of renaming the file without checking it out. In brief...
git checkout origin/master -f to get the checkout without the problematic file.
Make a branch.
Add and commit the "deleted" problematic file.
Use git ls-tree HEAD^ to get the ID of the problem file.
Use git cat-file -p <ID> to get the content of the problem file.
Put the content into a new file.
Add and commit.
I need to extend a given tool with a Bash script that is supposed to work with Linux and MacOS. The script gets 2 parameters:
A repository location (file system, ssh, http(s), ...)
A commitish, e.g. branch, tag, commit hash
I have no influence on the parameters
The result of the script's run should be that
the repository is cloned to a fixed destination (always the same for one repository)
the repositorie's working tree should correspond to the latest state of the comittish (e.g. if it was a branch the tip of that branch)
If the repository does not (yet) exist locally, the procedure is as simple as
git clone $REPO_SOURCE $REPO_DIR
cd $REPO_DIR
git checkout $REPO_REF
My question: Consider a repository is already cloned to /repos/foo. After an obvios git fetch, how to I update that repository to the provided $REPO_REF?
If $REPO_REF was a branch, a git checkout $REPO_REF && git pull should work
If it was a commit hash, there was no update needed (just git checkout $REPO_REF?)
If it was a tag, then the tag might have been moved on the origin, how to handle this?
How to handle other edge cases?
Is there a simple reset-repository-to-this-commitsh way, so the repository behaves just as if it was freshly cloned?
Side nodes:
The same repository might be used with different commitish's, but only sequentially: It is guaranteed that the script isn't invoked more than once at the same time
All external changes to the repository might be always discarded without notification
While deleting and cloning the repository would work, it is impractical due to their sizes and it being an ugly solution
No (git) changes are needed, so checking out a detached head is okay
The only totally-foolproof yet convenient way is to have the other Git (the one you might be cloning, but might not) resolve the name for you. Then you have a hash ID and a hash ID is universal.
If the name is a branch or tag name, you can use git ls-remote to achieve that step. If it might be some other formulation (e.g., master~13) you're out of luck here. So, if you need to resolve the name locally:
If tag discipline is obeyed, no tag will ever move. This means that if you have an existing clone that has the tag, it has the right tag, and you're OK here, and if you have an existing clone that doesn't have the tag, you can add the tag and resolve it.
If tag discipline is not obeyed, you'd have to delete and re-create the tags (yuck), or else re-invent remote tags: copy their refs/tags/* names to your refs/rtags/<remote>/* name-space. See Git - Checkout a remote tag when two remotes have the same tag name.
If you have a branch name or something relative to a branch name, turn the branch name into your own remote-tracking name (e.g., replace master~13 with refs/remotes/origin/master~13) and resolve it.
In any case, you now have a hash ID and can use detached HEAD mode.
Using a "standard" git clone you could to this:
# cleanup old cruft
git reset --hard HEAD
git clean -fdx
# detach from current branch (if on any)
git checkout --detach
# delete all local branches
git for-each-ref --format="%(refname:strip=2)" refs/heads |xargs -r git branch -D
# fetch and update all remote refs and tags
git fetch --force --all --tags --prune --prune-tags
# checkout
git checkout "$COMMITISH"
That way you can rely on git checkout to do its job as usual and you don't need to replicate any of its heuristics, shortcuts etc.
First, let me tell you that I have already checked all the similar threads and searched google to find what the problem may be, but no success. My problem is that I'm trying to use sparse checkout in git, but I get this error:
error: Sparse checkout leaves no entry on working directory
I have this 60GB repository, which I need to clone. I need only a part of it, so to save a disk space I wanted to use sparse checkout. This is what I do:
mkdir repoDir
git init repoDir
cd repoDir
git remote add origin <repo url>
git config core.sparsecheckout true
echo "some/dir/" >> .git/info/sparse-checkout
git pull --depth=1 origin master
Note I add the remote without -f flag, so nothing is fetched.
The result:
error: Sparse checkout leaves no entry on working directory
I tried several things:
Instead of initialising new repo and adding the remote manually, I did git clone --no-checkout and then set up the sparse checkout. This didn't help as my git status showed as if I deleted all the files in my repo. The git pull origin master command results in the same error.
Tried all possible combination of paths in step 6, with preceding slashes, slashes after the path, stars, spaces between path and > or >>. Btw I'm confused what is the correct format here, from the comments on SO I see mutually exclusive ways of formatting this.
Tried to make sure my .git/info/sparse-checkout is ASCII, and has proper line endings as found here. This is probably only problematic on Windows, but I just checked this anyway.
My git version: git version 1.9.3 (Apple Git-50)
OSX Yosemite 10.10.2 (14C109)
It turns out that "some/dir/" was wrong, since I didn't have the repository I didn't know it's real structure. I was able to browse it through web interface but I just discovered the folders don't correspond exactly to the real repository folder structure.
Lesson for the future: make sure you know the folder structure before creating sparse-checkout file.
The sequence of operations I wanted to follow is similar, namely the one suggested in this other post https://stackoverflow.com/a/13738951/5459638. I get the error message
error: Sparse checkout leaves no entry on working directory
when launching git pull <remote> <branch> with branch being master.
As #lawicko said, in the project webpage I can click my way to the subdirectory to be cloned and copy the URL of that page; ctrl+L ctrl+C makes doing this nice and quick. This URL has the form
https://gitlab.com/<username>/<project>/tree/master/<subdir>/<subdir>
The part that my sparse-checkout file accepts is the children of master
<subdir>/<subdir>/
with the trailing slash.
As an alternative to the same aim, there is another path in the form <project>/<subdir>/<subdir> to the right of the drop-down menu for switching branches at the top of the webpage.
In this case, I would have copied and pasted the children of <project> plus the trailing slash.
And this path is not as easy to copy and paste as the URL is.
Note that if you are using sparse-checkout on windows, you may need to add core.protectNTFS false per https://github.com/git-for-windows/git/issues/2777
I'm having a hard time understanding some git/DCVS concepts. Here's what happened:
I created a git project, and imported it from an SVN repo
I made some commits
I wanted to experiment something, so I created a branch called constants-update
I switched to constants-updatebranch, moved some files, deleted others and added many more
I committed to this branch
Now I'm trying to switch to my master branch using git checkout master
I got this error: error: You have local changes to 'src/groovy/Constants.groovy'; cannot switch branches.
My understanding of DCVS is that I can switch branches at will, even if some branch has more or less files than the others, as long as I commit my files. I've tried committing with git commit -a and switching to master branch, but I have the same error.
As a side note, when I commit git warns me that LF will be replaced by CRLF and warns me about some trailing whitespaces also; after I commit I do a git status and a bunch of files always appear as #modified ....
Is this related to git/windows, or I do not understand correctly what it is supposed to happen? I just want to switch to my master branch without losing my changes in the other branch.
Lookup git-stash for changing branches while there are unsaved changes in the current branch.
You are correct in your thinking about how this should work.
However, it sounds like git is having issues with the line endings, and it thinks all your files are modified even when they aren't. I don't use git on Windows, but I was going to suggest the "core.autocrlf" option to make the crlf handling work. However, the following blog entry indicates that this might not be a good idea: http://weierophinney.net/matthew/archives/191-git-svn-Tip-dont-use-core.autocrlf.html
I solved the problem hacking my pre-commit hook (commenting these lines in .git/hooks/pre-commit with a #):
# if (/\s$/) {
# bad_line("trailing whitespace", $_);
# }
Just use the following option in .gitconfig file which resides in your users directory.
[core]
autocrlf = true
And it will solve the issue.