Using the command line I can commit a single file to the repo at any time, regardless of the existence of other uncommitted files in the index, for instance:
git commit my_file.py
In GitPython, I tried the following:
repo.index.add(path)
repo.index.commit("commit-message")
But this commits all currently staged files. I couldn't find the equivalent operation in the GitPython API so I resorted to repo.git to issue a direct command, as in
repo.index.add(path)
repo.git.commit("-m","commit-message",path)
Is this the proper way to accomplish this, or is there a way using the API?
Related
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 just cloned an hg project that is typically maintained by Windows users (I'm an a Mac). I just did an hg add . and got a bazillion of the following messages:
adding out/blah
adding out/meh
adding out/fizz
adding out/buzz
...etc.
I do not want anything under out/* getting committed & pushed! So I added the following entry to .hgignore:
out/*
And then re-ran hg add .. Have I successfully prevented all this cruft living under out/* from being committed & pushed to the remote repo? If not, what else (specifically) do I need to do, and in what order?
First, check with
hg status
which files were actually added (you can also use hg status -a to restrict yourself to added files). Unless you removed them, the files in out still remain added. In order to get rid of them, use:
hg forget out
Then use hg status or hg status -a again to verify that they are no longer part of the planned commit.
I'll also note that out/* will also exclude any files in subdirectories that are named out, e.g. foo/out/bar.txt. To ignore only files in the directory out at the root, use the following line instead for your .hgignore:
re:^out/
The re: prefix will use regular expression matching instead and ^out/ will match all paths that start with out/.
I have ruby console application which is using grit gem to manipulate git repositories on MacOS.
When call that application from git folder I want to edit, and edit some files, that files will appear in modified as well as in added files in git status. And when want to commit and push those files I get this error:
git '--git-dir=/Users/user/some_dir/.git' '--work-tree=/Users/user/some_dir' add '--' 'edited_file.yaml' 2>&1:fatal: pathspec 'edited_file.yaml' did not match any files
Is there some known reason why this is happening, and also what would be the best way to avoid this?
I'm able to edit the code of this ruby console application, so looking for suggestions how to handle cases like this from application if they can't be handled on git level.
Every command I make in terminal while in zsh I get the mercurial help appended.
Example:
$ ls
Applications Developer Library Pictures VirtualBox VMs
Consensus Documents Movies Projects
Desktop Downloads Music Public
haaduken at nachi in ~Mercurial Distributed SCM
basic commands:
add add the specified files on the next commit
annotate show changeset information by line for each file
clone make a copy of an existing repository
commit commit the specified files or all outstanding changes
diff diff repository (or selected files)
export dump the header and diffs for one or more changesets
forget forget the specified files on the next commit
init create a new repository in the given directory
log show revision history of entire repository or files
merge merge working directory with another revision
pull pull changes from the specified source
push push changes to the specified destination
remove remove the specified files on the next commit
serve start stand-alone webserver
status show changed files in the working directory
summary summarize working directory state
update update working directory (or switch revisions)
use "hg help" for the full list of commands or "hg -v" for details
$
I have absolutely no idea why. Any ideas how I can stop this? A lot of people are saying alias, but hg isn't in my alias list at all.
Did you add a Mercurial command to your PS1 variable? Some people do this, to display the current branch or bookmark.
What does 'echo $PS1' show?
It's possible you added an incorrect Mercurial command there, which results in printing the help message.
I just got an error after a recent commit using Tortoise Git:
"Could not get all refs. libgit2 returned: corrupted loose reference
file"
which pops up when I go to check the Log.
Any ideas on how to rectify this?
Your refs are stored inside the raw repository (in .git) in directories (named for each branch) under the "refs" directory. The problem is that one of these files has been corrupted. If you check the code here you'll see that the problem is either that the ref file is less than 40 bytes long, or has a 41st byte that is not a space (or tab, newline, etc). Search through the files in the .git/refs directory and you'll find the bad one. It should contain the 40-character hash of the commit which that branch refers to. You can safely fix it using Notepad.
In my case it was the use of "junction tool" (sysinternals). Got that error only when adding new sub directory and files. Using git bash the problem does not occur. Everything else works fine with "junction tool" and TortoiseGit ...
I had the exact same error and managed to get my repo back without losing my changes.
I:
Made several backups of the corrupt git repository just in case
Cloned the lasted pushed version from the remote repository
Copied all the files from the corrupt .git folder EXCEPT all files related to HEAD, FETCH_HEAD, ORG_HEAD etc ... the most important are the refs, obj, and index
Ended up with a valid history, but corrupt index, applied the solution from this post How to resolve "Error: bad index – Fatal: index file corrupt" when using Git
And my repository was back working ...
To make sure I did not push anything wrong, I cloned again from the remote, checked-out the changes I wanted to save from the restored repository, and comited them fresh.