On 23.06.2017 22:39, René Scharfe wrote:
> The changed test script passes just fine for me even without your change
> to xdiff-interface.c, which is odd.
Sorry, I've apparently messed this up - it seems to be the case for me, too.
I would assume that using the functions.c context/diff in this
When -U0 is used, trim_common_tail should be called after `xdl_diff`, so
that `--indent-heuristic` (and other diff processing) works as expected.
It also removes the check for `!(xecfg->flags & XDL_EMIT_FUNCCONTEXT)`
added in e0876bca4, which does not appear to be necessary anymore after
moving
I have used "git stash --include-untracked", checked out another branch,
went back, and "git stash pop"ed the changes.
Then my system crashed/hung (music that was playing was repeated in a
loop). I have waited for some minutes, and then turned it off.
Afterwards, the repository in question was
TEST CASE:
1. Modify a file that need to get stashed on rebasing
2. Run "EDITOR=vim git rebase -i --autostash"
3. Abort with ":cq", which will make Vim exit non-zero
Git then will create an autostash, but aborts with "Could not execute
editor", via the following code in
Although the man page mentions the "--no-autostash" option, it is not supported:
% git rebase --no-autostash
error: unknown option `no-autostash'
% git --version
git version 2.5.1.dirty
Please CC me in case of replies.
Regards,
Daniel.
--
http://daniel.hahler.de/
Hi,
I've just experienced an issue, where the system hung after git stash -k,
and I've had to use Alt-SysRq-REISUB to reboot.
Afterwards git diff and git status failed with:
fatal: unable to read 7eaa1fb32551b16198924bfb8b9d3674fed2a59a
When looking at Git's source I've found several places
Hi,
I am a bit surprised that this bug still exists in maint / v2.2.2.
Cherry-picking/merging 0ddedd4 fixes it.
Regards,
Daniel.
On 26.12.2014 02:12, Daniel Hahler wrote:
Hi David,
sorry for the confusion - the patch / fix I've mentioned was meant to be
applied on the commit that caused
Hi David,
sorry for the confusion - the patch / fix I've mentioned was meant to be
applied on the commit that caused the regression and not current master.
Cheers,
Daniel.
On 26.12.2014 02:00, David Aguilar wrote:
On Tue, Dec 23, 2014 at 08:08:34PM +0100, Daniel Hahler wrote:
Hi
Hi,
this is in reply to the commits from David:
commit 0ddedd4d6b9b3e8eb3557d8ed28e1a0b354a25f8
Refs: v2.2.0-60-g0ddedd4
Merge: e886efd 1e86d5b
Author: Junio C Hamano gits...@pobox.com
AuthorDate: Fri Dec 12 14:31:39 2014 -0800
Commit: Junio C Hamano
Hi,
I'm wondering why the built-in patterns (defined in userdiff.c) are not
being applied by default, e.g. what you would normally do in
core.attributesfile via:
*.py diff=python
Wouldn't it make sense to provide certain defaults for attributes, where
Git provides enhanced patterns?
After staging the removal of a submodule, diff-index does not consider this
when --ignore-submodules is being used:
# In a repository with submodule sm:
% git rm --cached sm
% git diff-index --cached --quiet --ignore-submodules HEAD
% echo $?
0
% git status
On branch
I have noticed that the output from git rev-parse --resolve-git-dir changed.
While it used to only print the resolved git dir, it now prints the argument
passed to it itself:
% git rev-parse --resolve-git-dir .git
/path/to/root/.git/modules/vim/bundle/reporoot
.git
This is with Git
On 09.02.2014 10:08, Duy Nguyen wrote:
On Tue, Feb 04, 2014 at 11:20:39AM +0100, Daniel Hahler wrote:
Thanks for looking into this.
when using a submodule sm, there is a relative worktree in its config:
.git/modules/sm/config:
[core]
worktree = ../../../smworktree
git-new
Hi,
when using a submodule sm, there is a relative worktree in its config:
.git/modules/sm/config:
[core]
worktree = ../../../smworktree
git-new-worktree (from contrib) symlinks this config the new worktree.
From inside the new worktree, git reads the config, but resolves the
14 matches
Mail list logo
