Sometimes a git checkout command gives progress feedback:
$ git checkout develop
Checking out files: 100% (10779/10779), done.
Switched to branch 'develop'
Sometimes it doesn't, (very next command line, same repo context):
$ git checkout master
Switched to branch 'master'
It's not because the branches are equal, because switching back on the very next command shows this feedback:
$ git checkout develop
Checking out files: 47% (5067/10779), done.
Switched to branch 'develop'
This happens for small repos also. I have a repo with just 13 files in it and when I add a file in a branch and use checkout to switch back and forth, I get no feedback either way. Is it some kind of "this is taking a long time, start showing feedback" timer?
I searched (Google, Stackoverflow) but didn't find anything specific. I did find some patch documentation that shows the addition of a --verbose flag to checkout that forces feedback to always happen, but I couldn't find an explanation for why feedback only happens sometimes without that patch. The same notes pointed out that feedback only happens if isatty() returns true, but that's not relevant here, since all of the commands above were typed into the same bash window, which presumably isatty.
I'm using git version 1.8.1.msysgit.1 (downloaded from git-scm.com as 1.8.1.3), which does not have the --verbose patch as far as I can tell.
This checkout output should now be more consistent with Git 2.7 (Nov./Dec. 2015)
See commit 870ebdb (01 Nov 2015) by Edmundo Carmona Antoranz (eantoranz).
(Merged by Junio C Hamano -- gitster -- in commit 6a38bd6, 05 Nov 2015)
"git checkout" did not follow the usual "--[no-]progress" convention and implemented only "--quiet" that is essentially a superset of "--no-progress".
Extend the command to support the usual "--[no-]progress".
The git checkout doc now shows:
--[no-]progress::
Progress status is reported on the standard error stream by default when it is attached to a terminal, unless --quiet is specified.
This flag enables progress reporting even if not attached to a terminal, regardless of --quiet.
checkout: add --progress option
Under normal circumstances, and like other git commands, git checkout will write progress info to stderr if attached to a terminal.
This option allows progress to be forced even if not using a terminal.
Also, progress can be skipped if using option --no-progress.
Under normal conditions, you will see output when checking out if the operation's been running for more than one second.
Related
This question already has answers here:
How do I reset or revert a file to a specific revision?
(35 answers)
Closed 3 years ago.
Just a dumb question from just a newb in git, Messed up alot with git, but now I was wondering if how can I restore to a previous version in the application, since my .env environment configuration file is now gone in my current master branch, I did merge my other branch with this one. I knew I made my latest work on my chat-feature branch, pretty much the 100% of the application was there, since the chat part and the payment feature of the application was there but when I checkout there, its not even working, I was wondering how can I go back to that previous commit that I made. When I git log I want to be back to this specific version.
Restore + push --force
I don't like to recommend anything that requires --force but in your case it may be the cleanest solution. If you shared your code with others, don't follow this - you're changing history.
Let's make master be like chat-feature.
Make a copy of the repo (on your drive), just in case.
git checkout master
git checkout -b master_copy (optional, but let's store what we currently have in master as a new branch; this will make it easy to use it if rewind too much)
git checkout chat-feature
Check that this is what you want master to look like.
git log -n 1
Copy the commit id
git checkout master
git reset --hard <commit-id>
Double check that things work and that's what you want.
git push --force
I have started to work with project, which I cloned from bitbucket.
I use as Git Bash, as SourceTree.
I changed one file and try to commit my change.
I can execute the command "add", but when I try to execute the command "commit" (git commit -m "for testing"), I get the following error:
Segmentation fault.
I got an error in SourceTree too.
But if I create my new folder & file, the commit happens successfully
How I can fix the problem situation?
Thanks in advance.
Running git 2.15.1.windows.2 on Windows 10 x64 v1709
For me the problem was caused by a faulty index. To resolve I ran the following from the project directory:
rm .git/index
git reset
As you can see from the image in this link, I didn't loose any changes by performing a reset.
If you already have Git installed, you can get the latest development version via Git itself:
git clone https://github.com/git/git
but this didn't work for me.I uninstalled the git and then again downloaded then my problem got resolved.
I have resolved the problem.
The last git version (2.13.1) has the bug - it has been released 05.06.2017.
I installed previous version (2.12.2) and now all is OK.
I had the same issue on some project, I could no checkout a new or an existing branch.
I installed the latest version of git from the website and now my version is
> git --version
git version 2.13.1.windows.2
The issue seems fixed with this build. For now.
use git reset SHA --hard
Where SHA points to a valid SHA before the error
Changes done after this point is lost. But repo is saved.
For me the problem was caused by a faulty index.
With Git 2.36 (Q2 2022), you will see more details instead of a segfault.
Git now check the return value from parse_tree_indirect() to turn segfaults into calls to die().
For clone/checkout, but can also be applied to commit.
See commit 8d2eaf6 (01 Mar 2022) by Glen Choo (chooglen).
(Merged by Junio C Hamano -- gitster -- in commit bde1e3e, 13 Mar 2022)
checkout, clone: die if tree cannot be parsed
Signed-off-by: Glen Choo
When a tree oid is invalid, parse_tree_indirect() can return NULL.
Check for NULL instead of proceeding as though it were a valid pointer and segfaulting.
I'm trying to find a comprehensive list of tortoise git functionality for the git command line (cmd version, not bash). I'm stuck at graphical log viewing. In tortoiseGit I can
Open log of repo
Navigate between commits and browse files in each commit
Open diff directly from log
Are there any command line tools, scripts or aliases for that?
I was amazed that git contains interactive staging dialog and I'm looking for something similar.
The upstream git package comes with a graphical tool called gitk, which does exactly what you want. However, the command line tool does not offer an interactive way to browse the commits. Instead, you have to use separate commands to do this:
git log
This will show you a log. Note that each log entry starts with the commit identifier. You can then view the diff of that commit using:
git show <identifier>
To browse the files as they were at a specific commit, just check out that commit:
git checkout <identifier>
After you are done, you can go back with git checkout master (assuming you are on the master branch).
I'm playing with pronto since done the line I wish to integrate it to my process.
I have followed the instruction on the Github page (at least I think so) but when I run pronto (with pronto-rubocop and pronto-spell) no messages are posted to Github even if I have several issues in the code.
You may check this test repo.
In the repo I have
a variable not in english
a couple of not camel cased classes
a misspelled commit message
Shouldn't pronto find this issues and post on Github?
After pushing my commit I execute pronto by running
GITHUB_ACCESS_TOKEN=xxx482cb9b577de5a216xxxxxxxxxxxxxxxxxxxx pronto
run -f github -c origin/master
The same happens when I run pronto locally pronto run: nothing is printed out.
Thanks
-c/--commit flag determines against which commit your current HEAD will be compared to. In your case, I don't see another branch besides master. You're probably running Pronto and comparing master against origin/master. That's very likely the same commit. You can observe it by:
git show HEAD
git show master
git show origin/master
To see some result in that repo, you can run Pronto like this (replaced origin/master with HEAD~5):
GITHUB_ACCESS_TOKEN=xxx482cb9b577de5a216xxxxxxxxxxxxxxxxxxxx pronto run -f github -c HEAD~5
Or alternatively, create another branch, make some bad commits, git push and run Pronto while being on that branch.
I have recently decided to take the git plunge, and am really enjoying using git, even on Windows.
My current open source project lives on subversion, all devs are familiar with subversion so I would like to keep subversion as the "source of truth" for now.
Nonetheless, I want to use git, so I went ahead and created a copy of the source on github using git svn. All my work is done against the source in github and I push my changes to github. Once every few days I also push my changes to svn and rebase.
The initial import seemed to go ok, but now every time I do a "git svn rebase" I keep on getting conflicts, even on files I have not changed in my get repository. This is causing me much pain.
Eg.
$ git svn rebase
First, rewinding head to replay your work on top of it...
Applying: Added git ignore file
c:/Users/sam/Desktop/MediaBrowserGit/trunk/.git/rebase-apply/patch:12: trailing
whitespace.
*/obj/*
error: .gitignore: already exists in index
Using index info to reconstruct a base tree...
:12: trailing whitespace.
*/obj/*
warning: 1 line adds whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
Failed to merge in the changes.
Patch failed at 0001 Added git ignore file
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
rebase refs/remotes/git-svn: command returned error: 1
My questions:
Is there any way I can tell git to sync itself up with svn using svn as the source, so I can start with a clean slate. (export latest, check in changes and reset the svn refs somewhere)
Are there any tips and tricks to getting this scenario to work consistently?
Should I have the core.safecrlf and core.autocrlf options set to true? It seems I will need a bit of hoop jumping.
Related:
http://kerneltrap.org/index.php?q=mailarchive/git/2008/4/16/1450834/thread
http://markmail.org/message/vaois4kkr5ggugqs#query:git%20crlf+page:1+mid:i4flex6vmt5tdala+state:results
http://code.google.com/p/msysgit/issues/detail?id=271
It seems getting line endings right is a bit of a black art.
(I realize that this question probably needs to be expanded, please comment on the places that need expanding)
Are you getting line-ending conflicts? Git has a few configuration properties you can set that change how it handles the end of line characters. I have the following set:
# this makes git NOT attempt to convert line endings on commit and checkout
core.autocrlf=false
# this makes git check if the conversion done by autocrlf would be reversible
# this is probably not required because I do not have autocrlf turned on
core.safecrlf=true
Note that I am on windows, all my coworkers are on windows and I am interfacing with SVN through git-svn. These settings seem to do the trick for me.
(source: codinghorror.com)