How do I regularly clean up .git/objects/pack/tmp_* files?
Hi there, I try to follow the best practice of regular repo maintenance, which afaik consists of running `git gc` every week or so. So I thought I had a well-maintained repository, and was quite surprised to discover some very large .git/objects/pack/tmp_* files, which apparently are entirely needless and should be cleaned up, but `git gc` doesn't clean them. Is there another command I should regularly run, instead or in addition to `git gc`, to keep my repo well-maintained, and specifically, to remove such unnecessary files from my .git directory? Thanks, D.
Re: trustExitCode doesn't apply to vimdiff mergetool
Thanks, Jeff. Ignoring a non-zero exit code from the merge tool, and assuming a successful merge in that case, seems like the wrong default behavior to me. If your merge tool quit with an error, it is more sensible to assume that the resolution you were working on has not been successfully concluded. In the rare case where one did successfully conclude the resolution, you can always quickly mark the file resolved. I'm not even sure how to do that short of `git checkout -m -- file`, which would lose any work you've already done towards the merge. Long story short, I hope the developers change this default, or at least let us override it for the builtin invocations. Finally, if you're not using mergetools, how do you resolve conflicts? On Sun, Nov 27, 2016 at 12:08 AM, Jeff King <p...@peff.net> wrote: > On Sat, Nov 26, 2016 at 09:44:36PM -0500, Dun Peal wrote: > >> I'm using vimdiff as my mergetool, and have the following lines in >> ~/.gitconfig: >> >> [merge] >> tool = vimdiff >> [mergetool "vimdiff"] >> trustExitCode = true >> >> >> My understanding from the docs is that this sets >> mergetool.vimdiff.trustExitCode to true, thereby concluding that a >> merge hasn't been successful if vimdiff's exit code is non-zero. >> >> Unfortunately, when I exit Vim using `:cq` - which returns code 1 - >> the merge is still presumed to have succeeded. >> >> Is there a way to accomplish the desired effect, such that exiting >> vimdiff with a non-zero code would prevent git from resolving the >> conflict in the merged file? > > I don't use mergetool myself, but peeking at the code, it looks like > trustExitCode is used only for a "user" tool, not for the builtin tool > profiles. That sounds kind of confusing to me, but I'll leave discussion > of that to people more interested in mergetool. > > However, I think you can work around it by defining your own tool that > runs vimdiff: > > git config merge.tool foo > git config mergetool.foo.cmd 'vimdiff "$LOCAL" "$BASE" "$REMOTE" "$MERGED"' > git config mergetool.foo.trustExitCode true > > Though note that the builtin vimdiff invocation is a little more > complicated than that. You may want to adapt what is in git.git's > mergetools/vimdiff to your liking. > > -Peff
trustExitCode doesn't apply to vimdiff mergetool
I'm using vimdiff as my mergetool, and have the following lines in ~/.gitconfig: [merge] tool = vimdiff [mergetool "vimdiff"] trustExitCode = true My understanding from the docs is that this sets mergetool.vimdiff.trustExitCode to true, thereby concluding that a merge hasn't been successful if vimdiff's exit code is non-zero. Unfortunately, when I exit Vim using `:cq` - which returns code 1 - the merge is still presumed to have succeeded. Is there a way to accomplish the desired effect, such that exiting vimdiff with a non-zero code would prevent git from resolving the conflict in the merged file?
Re: $GIT_DIR/info/exclude fails to negate a pattern defined by core.excludesfile
Hey Duy, I'm not sure why the pattern would have to be as you describe - I'm just looking to ignore `*.out` as a general configuration, and disable it for one specific project, so it would seem a plain `!*.out` should work. In any case, I added a `.gitignore` file with the single pattern `!*.out` at the root of the project, and now .out files are no longer ignored for the project. It's not an ideal solution because now all the other developers of the project who do not have `*.out` in their `core.excludesfile` will have an unnecessary pattern in their exclusion logic, but it does work as expected. Thanks, D. On Sun, Oct 12, 2014 at 7:53 PM, Duy Nguyen pclo...@gmail.com wrote: On Sun, Oct 12, 2014 at 9:58 AM, Dun Peal dunpea...@gmail.com wrote: I have the pattern `*.out` defined in my `core.excludesfile`. According to the documentation[1], patterns defined in `$GIT_DIR/info/exclude` take precedence over `core.excludesfile`, so for one particular project that needs to track some `.out` files, I created `$GIT_DIR/info/exclude` with just one pattern: `!*.out`. Yet for some reason, `git status` still fails to report newly created `.out` files for that project. Am I misunderstanding the documentation? We process in groups, so rules in core.excludesfile are in one group, those in $GIT_DIR/info/exclude in another group. Negative patterns only has effects within their group, so !*out in .../exclude can't revert *.out in core.excludesfile. Probably implementation limitation, not by design.. But even if we flatten them into one group, i'm not sure you can achieve that. The patterns would be !*.out *.out !*.out has nothing to revert because it's before *.out. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: $GIT_DIR/info/exclude fails to negate a pattern defined by core.excludesfile
I used `check-ignore -v`, and the `.out` file is being ignored by the `*.out` pattern in the `core.excludesfile` file. Its parent folder is not being ignored. So as a rule, `core.excludesfile` overrides `$GIT_DIR/info/exclude`. That doesn't make much sense to me, because I'm much more likely to want to override global exclusions for a specific project, than override specific project settings with a global exclusion file (that last one really makes no sense imho). Thoughts? On Sat, Oct 11, 2014 at 10:58 PM, Dun Peal dunpea...@gmail.com wrote: I have the pattern `*.out` defined in my `core.excludesfile`. According to the documentation[1], patterns defined in `$GIT_DIR/info/exclude` take precedence over `core.excludesfile`, so for one particular project that needs to track some `.out` files, I created `$GIT_DIR/info/exclude` with just one pattern: `!*.out`. Yet for some reason, `git status` still fails to report newly created `.out` files for that project. Am I misunderstanding the documentation? Thanks, D. [1] http://jk.gs/gitignore.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
$GIT_DIR/info/exclude fails to negate a pattern defined by core.excludesfile
I have the pattern `*.out` defined in my `core.excludesfile`. According to the documentation[1], patterns defined in `$GIT_DIR/info/exclude` take precedence over `core.excludesfile`, so for one particular project that needs to track some `.out` files, I created `$GIT_DIR/info/exclude` with just one pattern: `!*.out`. Yet for some reason, `git status` still fails to report newly created `.out` files for that project. Am I misunderstanding the documentation? Thanks, D. [1] http://jk.gs/gitignore.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
warning: There are too many unreachable loose objects; run 'git prune' to remove them.
Hi, I am getting this error every time I pull. All the following have been executed, but failed to remove this warning: git prune git prune --expire now git gc git gc --aggressive What should I do? Thanks, D. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
