Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect

Yaroslav Halchenko writes: > yes it does. Thanks. And that is where I realized that I should have used -X > theirs (not -s theirs), as the instruction on the option for the > (recursive) merge. And now problem is more specific: > > - conflict within file content editing

-s theirs use-case(s) Was: BUG: merge -s theirs is not in effect

On Mon, 25 Sep 2017, Junio C Hamano wrote: >It is a different matter to resurrect the age old discussion that >happend in the summer of 2008 if '-s theirs' should or should not >exist. In short, the previous discussion can be summarised to >"we don't want '-s theirs' as it

-X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect

On Mon, 25 Sep 2017, Junio C Hamano wrote: > Yaroslav Halchenko writes: > > d'oh, indeed there is no git-merge-theirs neither in debian pkg or a > > freshly > > built git and I found a rogue script in the PATH (which did nothing > > apparently, sorry!). BUT I was

Re* BUG: merge -s theirs is not in effect (does the same as -s ours)

Yaroslav Halchenko writes: > d'oh, indeed there is no git-merge-theirs neither in debian pkg or a freshly > built git and I found a rogue script in the PATH (which did nothing > apparently, sorry!). BUT I was originally mislead by the --help/manpage: Ahh, you're right.

Re: BUG: merge -s theirs is not in effect (does the same as -s ours)

On Mon, 25 Sep 2017, Junio C Hamano wrote: > Yaroslav Halchenko writes: > > My interest was to get remote branch "merge" the changes in the > > branch taking the branch's version (primarily alternative symlinks > > for git-annex'ed content) over the version in master

Re: BUG: merge -s theirs is not in effect (does the same as -s ours)

Yaroslav Halchenko writes: > My interest was to get remote branch "merge" the changes in the > branch taking the branch's version (primarily alternative symlinks > for git-annex'ed content) over the version in master (previous > merge of a similar branch). Unfortunately -s

BUG: merge -s theirs is not in effect (does the same as -s ours)

My interest was to get remote branch "merge" the changes in the branch taking the branch's version (primarily alternative symlinks for git-annex'ed content) over the version in master (previous merge of a similar branch). Unfortunately -s theirs seems to do actually -s ours -- symlinks and

Re: git fast-export/import bug with -M -C

Hi, did anyone manage to take a look at this bug? Friendly ping. Juraj On Fri, Sep 15, 2017 at 12:01 AM, Juraj Oršulić <juraj.orsu...@fer.hr> wrote: > The commands should be self explanatory. 0.2.0~20 is the first commit > where the reconstructed repository diverges, tha

Re: [PATCH v2] add test for bug in git-mv for recursive submodules

r its configurations" or > > whatever that describes "what actually happens" (in contrast to > > "what ought to happen", which you described clearly) should be > > there. > > > > Description on how you happened to have discovered the issue feels a > > l

Re: [PATCH v2] add test for bug in git-mv for recursive submodules

t;> + touch nested_level1 && >> + git init && >> + git add . && >> + git commit -m "nested level 1" >> + git submodule add ../sub_nested_nested && >> +

Re: [PATCH v2] add test for bug in git-mv for recursive submodules

Heiko Voigt writes: > When using git-mv with a submodule it will detect that and update the > paths for its configurations (.gitmodules, worktree and gitfile). This > does not work for recursive submodules where a user renames the root > submodule. > > We discovered this fact

[PATCH v2] add test for bug in git-mv for recursive submodules

When using git-mv with a submodule it will detect that and update the paths for its configurations (.gitmodules, worktree and gitfile). This does not work for recursive submodules where a user renames the root submodule. We discovered this fact when working on on-demand fetch for renamed

git fast-export/import bug with -M -C

The commands should be self explanatory. 0.2.0~20 is the first commit where the reconstructed repository diverges, that commit had a simultaneous copy and edit of one file. It seems that copy/rename detection, enabled with -M -C is confused by this. I reproduced it with git 2.14 next @ 8fa685d.

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

On 13 September 2017 at 17:22, Jeff King wrote: > On Wed, Sep 13, 2017 at 05:18:56PM +0200, demerphq wrote: > >> > Hmph. That is very disturbing. But with that information I should be >> > able to track down the culprit. Thanks for digging. >> >> FWIW, I see that

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

On Wed, Sep 13, 2017 at 05:18:56PM +0200, demerphq wrote: > > Hmph. That is very disturbing. But with that information I should be > > able to track down the culprit. Thanks for digging. > > FWIW, I see that git_config_set_multivar_in_file_gently() uses > write_in_full() which in turn uses

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

restarts write() * operations with a recoverable error (EAGAIN and EINTR). xwrite() DOES NOT * GUARANTEE that "len" bytes is written even if the operation is successful. */ I suspect that at this point I am not adding much value here, so I will leave it at this. >> I freed up space an

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

t. When I then filled up the disk and retried the error was > repeatable. Yeah, agreed. This really does look like a bug. -Peff

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

On 13 September 2017 at 16:17, Jeff King wrote: > You're welcome to read over the function to double-check, but I just > looked it over and couldn't find any unchecked writes. I can look, but I doubt I would notice something you did not. On the other hand the strace output does

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

On Wed, Sep 13, 2017 at 03:38:52PM +0200, demerphq wrote: > I just double checked the terminal history and this is all i saw: > > $ git status > On branch yves/xxx > Your branch is based on 'origin/yves/xxx', but the upstream is gone. > (use "git branch --unset-upstream" to fixup) > > nothing

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

On 13 September 2017 at 14:34, Jeff King wrote: > On Wed, Sep 13, 2017 at 01:59:17PM +0200, demerphq wrote: > >> After being away for a while I saw the following message in one of my git >> repos: >> >> $ git status >> On branch yves/xxx >> Your branch is based on

Re: Bug: git branch --unset-upstream command can nuke config when disk is full.

On Wed, Sep 13, 2017 at 01:59:17PM +0200, demerphq wrote: > After being away for a while I saw the following message in one of my git > repos: > > $ git status > On branch yves/xxx > Your branch is based on 'origin/yves/xxx', but the upstream is gone. > (use "git branch --unset-upstream" to

Bug: git branch --unset-upstream command can nuke config when disk is full.

After being away for a while I saw the following message in one of my git repos: $ git status On branch yves/xxx Your branch is based on 'origin/yves/xxx', but the upstream is gone. (use "git branch --unset-upstream" to fixup) nothing to commit, working tree clean $ git branch --unset-upstream

Re: BUG: attempt to trim too many characters

On Tue, Sep 12, 2017 at 09:29:49PM -0700, Linus Torvalds wrote: > Just reminding people that this issue would seem to still exist in > current master.. Yeah, the fix is in 1d0538e4860, but it's still working it's way up through the integration branches. -Peff

Re: BUG: attempt to trim too many characters

5 steps) [f35a1d75b5ecefaef7b1a8ec55543c82883df82f] Merge branch 'rs/t3700-clean-leftover' into maint [torvalds@i7 git]$ git rev-parse --bisect fatal: BUG: attempt to trim too many characters (Note: I use "git rev-parse --bisect" to show it as an error on the command line,

Re: [Bug] commit-tree shouldn't append an extra newline to commit messages

Thanks for following up. A few minor comments: On Tue, Sep 05, 2017 at 04:57:24PM -0400, Ross Kabus wrote: > From: Ross Kabus > Date: Tue, 5 Sep 2017 13:54:52 -0400 > Subject: [PATCH] commit-tree: don't append a newline with -F Usually you'd just omit these in favor of the

Re: BUG: attempt to trim too many characters

On Tue, Sep 5, 2017 at 3:03 PM, Jeff King wrote: > > This probably fixes it: Yup. Thanks. Linus

Re: BUG: attempt to trim too many characters

On Tue, Sep 05, 2017 at 02:55:08PM -0700, Linus Torvalds wrote: > On Tue, Sep 5, 2017 at 2:50 PM, Jeff King wrote: > > > > What version of git are you running? This should be fixed by 03df567fbf > > (for_each_bisect_ref(): don't trim refnames, 2017-06-18) which is in > > v2.14. >

Re: [Bug] commit-tree shouldn't append an extra newline to commit messages

Jeff King writes: > On Tue, Sep 05, 2017 at 12:57:21PM -0400, Ross Kabus wrote: > >> On Tue, Sep 5, 2017 at 11:36 AM, Jeff King wrote: >> >> > So I'd argue that "git commit -F" is doing a reasonable >> > thing, and "commit-tree -F" should probably change to match

Re: BUG: attempt to trim too many characters

On Tue, Sep 5, 2017 at 2:50 PM, Jeff King wrote: > > What version of git are you running? This should be fixed by 03df567fbf > (for_each_bisect_ref(): don't trim refnames, 2017-06-18) which is in > v2.14. I'm way more recent than 2.14. I'm at commit 238e487ea ("The fifth batch

Re: BUG: attempt to trim too many characters

On Tue, Sep 05, 2017 at 02:39:05PM -0700, Linus Torvalds wrote: > I just got this with > >gitk --bisect > > while doing some bisection on my current kernel. > > It happens with "git rev-parse --bisect" too, but interestingly, "git > log --bisect" works fine. > > I have not tried to figure

BUG: attempt to trim too many characters

I just got this with gitk --bisect while doing some bisection on my current kernel. It happens with "git rev-parse --bisect" too, but interestingly, "git log --bisect" works fine. I have not tried to figure out anything further, except that it was introduced by commit b9c8e7f2f

Re: [Bug] commit-tree shouldn't append an extra newline to commit messages

Gmail mangled that patch of course... Ross Kabus Software Engineer www.aerotech.com | 412-968-2833 On Tue, Sep 5, 2017 at 4:57 PM, Ross Kabus wrote: > From: Ross Kabus > Date: Tue, 5 Sep 2017 13:54:52 -0400 > Subject: [PATCH] commit-tree: don't append

Re: [Bug] commit-tree shouldn't append an extra newline to commit messages

From: Ross Kabus Date: Tue, 5 Sep 2017 13:54:52 -0400 Subject: [PATCH] commit-tree: don't append a newline with -F This change makes it such that commit-tree -F never appends a newline character to the supplied commit message (either from file or stdin). Previously,

Re: [Bug] commit-tree shouldn't append an extra newline to commit messages

On Tue, Sep 05, 2017 at 12:57:21PM -0400, Ross Kabus wrote: > On Tue, Sep 5, 2017 at 11:36 AM, Jeff King wrote: > > > So I'd argue that "git commit -F" is doing a reasonable > > thing, and "commit-tree -F" should probably change to match it (because > > it's inconsistent, and

Re: [Bug] commit-tree shouldn't append an extra newline to commit messages

On Tue, Sep 5, 2017 at 11:36 AM, Jeff King wrote: > So I'd argue that "git commit -F" is doing a reasonable > thing, and "commit-tree -F" should probably change to match it (because > it's inconsistent, and because if anything the plumbing commit-tree > should err more on the side

Re: [Bug] commit-tree shouldn't append an extra newline to commit messages

On Tue, Sep 05, 2017 at 11:09:01AM -0400, Ross Kabus wrote: > On Sat, Sep 2, 2017 at 4:33 AM, Jeff King wrote: > > > But I am confused by your "inconsistent with git commit porcelain" > > comment. The porcelain git-commit definitely _does_ add a newline if one > > isn't present

Re: [Bug] commit-tree shouldn't append an extra newline to commit messages

On Sat, Sep 2, 2017 at 4:33 AM, Jeff King wrote: > But I am confused by your "inconsistent with git commit porcelain" > comment. The porcelain git-commit definitely _does_ add a newline if one > isn't present (and in fact runs the whole thing through git-stripspace > to clean up

[PATCH 10/20] tempfile: replace die("BUG") with BUG()

Compared to die(), using BUG() triggers abort(). That may give us an actual coredump, which should make it easier to get a stack trace. And since the programming error for these assertions is not in the functions themselves but in their callers, such a stack trace is needed to actually find

Re: Bug report

On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote: > I have a file > > app/Controller/CustomerCardVerificationController.php > > And when I take a look at changes log, I get this (no matter which tool I > use): > > 2017-07-31 19:41 dule o membership renew payment

Re: [Bug] commit-tree shouldn't append an extra newline to commit messages

On Fri, Sep 01, 2017 at 02:58:52PM -0400, Ross Kabus wrote: > When doing git commit-tree to manually create a commit object, it can be seen > that the resulting commit's message has an extra appended newline (\n) that > was not present in the input for either argument -m or -F. This is both >

[Bug] commit-tree shouldn't append an extra newline to commit messages

Hello, When doing git commit-tree to manually create a commit object, it can be seen that the resulting commit's message has an extra appended newline (\n) that was not present in the input for either argument -m or -F. This is both undesirable and inconsistent with the git commit porcelain

Re: Bug report

On 08/31/2017 08:36 AM, Kevin Daudt wrote: > On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote: >> I have a file >> >> app/Controller/CustomerCardVerificationController.php >> >> And when I take a look at changes log, I get this (no matter which tool I >> use): >> >> 2017-07-31

Re: Bug report

Hm, thanks, but the link was not helpful, there are no merge commits to master branch. Those changes should have not been undone, that's how we caught it, because 1 line peace of code introduced new feature (+-10% tolerance on credit card verification amount). So most likeley they were

Re: Bug report

The following answer that I got back in 2015 from Jeff King might be relevant to your problem: https://marc.info/?l=git=144178948506788=2 Regards, Dov On Thu, Aug 31, 2017 at 9:36 AM, Kevin Daudt wrote: > On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote: >> I

Re: Bug report

On Wed, Aug 30, 2017 at 11:25:00PM +0200, Aleksandar Pavic wrote: > I have a file > > app/Controller/CustomerCardVerificationController.php > > And when I take a look at changes log, I get this (no matter which tool I > use): > > 2017-07-31 19:41 dule o membership renew payment

Bug report

I have a file app/Controller/CustomerCardVerificationController.php And when I take a look at changes log, I get this (no matter which tool I use): 2017-07-31 19:41 dule o membership renew payment email 2017-06-07 08:59 Dusan Tatic o cc refund clean 2017-04-15 00:16

Re: [BUG] rebase -i with only empty commits

On 23/08/17 15:40, Johannes Schindelin wrote: > > These days, I reflexively type `rebase -ki` instead of `rebase -i`. Maybe > you want to do that, too? > > Ciao, > Dscho > This is slightly off topic but when I was preparing the patches for [1] I noticed a couple of potential bugs with rebase

Re: [BUG] rebase -i with only empty commits

From: "Johannes Schindelin" So the problem seems to be that rebase -i (like rebase without -i) considers "empty commits" as commits to be ignored. However, when using rebase -i one expects that you can include the empty commit... Also, the behavior is odd. When I

Re: [BUG] rebase -i with only empty commits

Stephan Beyer writes: > On 08/23/2017 07:29 PM, Stefan Beller wrote: >> On Wed, Aug 23, 2017 at 8:19 AM, Stephan Beyer wrote: >>> On 08/23/2017 04:40 PM, Johannes Schindelin wrote: These days, I reflexively type `rebase -ki` instead of `rebase -i`. Maybe

Re: [BUG] rebase -i with only empty commits

ecial way. Best Stephan PS: Although -k helps, the original behavior of rebase -i is still a bug.

Re: [BUG] rebase -i with only empty commits

On Wed, Aug 23, 2017 at 8:19 AM, Stephan Beyer wrote: > Hi, > > On 08/23/2017 04:40 PM, Johannes Schindelin wrote: >> These days, I reflexively type `rebase -ki` instead of `rebase -i`. Maybe >> you want to do that, too? > > That's a very valuable hint, thank you very much!

Re: [BUG] rebase -i with only empty commits

Hi, On 08/23/2017 04:40 PM, Johannes Schindelin wrote: > These days, I reflexively type `rebase -ki` instead of `rebase -i`. Maybe > you want to do that, too? That's a very valuable hint, thank you very much! Best Stephan

Re: [BUG] rebase -i with only empty commits

k 2345 another commit > > exec make > > pick 3456 third commit > > # pick 4567 empty commit > > exec make > > pick 5678 yet another commit > > exec make > > This reminds me of another bug I stumbled over recently rega

[BUG] rebase -i with only empty commits

# pick 4567 empty commit > exec make > pick 5678 yet another commit > exec make This reminds me of another bug I stumbled over recently regarding empty commits. Do this: # repo preparation: git init :> file1 git add file1 git

[BUG] rebase -i with empty commits + exec

Currently I am working on a longer series, for which I decided to keep track of progress in an empty commit. This empty commit is in the middle of the series (to divide the commits into two sets, the foundation that I consider stable and the later parts that are not as stable for my development,

Re: Bug?: git archive exclude pathspec and gitattributes export-ignore

Am 14.08.2017 um 18:43 schrieb René Scharfe: > The real solution is probably to teach tree-walk.c::do_match() how to > handle attributes and then inject ":(attr:-export-ignore)" as a default > internal pathspec in archive.c::parse_pathspec_arg() instead of handling > it in

Re: [bug] Git submodule command interprets switch as argument and switch

Add the given repository as a submodule at the given > path [etc] > > Since the -f comes after , it is a . > Not to comment on every response to this bug, but I understand. What is confusing is that the command was failing without being forced, and without th

Re: [bug] Git submodule command interprets switch as argument and switch

Hi, R0b0t1 wrote: > The issue is as follows: > > R0b0t1@host:~/devel/project$ git submodule add > https://github.com/user/project -f > Cloning into '/home/R0b0t1/devel/project/-f'... Thanks for reporting. Confusingly, I think this is intended behavior. "git help submodule" explains:

Re: [bug] Git submodule command interprets switch as argument and switch

g is interpreted as a flag > and also as the destination directory. > > It is possible the argument parsing code for other commands exhibits this > error. Yes, though these other commands are in C, not in shell. Note that Prathamesh is currently porting the "git submodule" com

Re: [PATCH] add test for bug in git-mv with nested submodules

> I just copied the shortcut that they were adding themselfes as submodule > in 'setup submodule'. The whole setup of submodules in this test is like > this. This way we already had a nested submodule structure which I could > just add. > > I agree that this is unrealistic so I can change that in

Re: [PATCH] add test for bug in git-mv with nested submodules

On Thu, Aug 17, 2017 at 12:05:56PM -0700, Stefan Beller wrote: > On Thu, Aug 17, 2017 at 3:34 AM, Heiko Voigt wrote: > > When using git-mv with a submodule it will detect that and update the > > paths for its configurations (.gitmodules, worktree and gitfile). This > > does not

[bug] Git submodule command interprets switch as argument and switch

The issue is as follows: R0b0t1@host:~/devel/project$ git submodule add https://github.com/user/project -f Cloning into '/home/R0b0t1/devel/project/-f'... My .gitignore's first line is *, and then I explicitly allow things. Despite the presence of "project/" in the .gitignore the submodule

Re: [PATCH] add test for bug in git-mv with nested submodules

On Thu, Aug 17, 2017 at 3:34 AM, Heiko Voigt wrote: > When using git-mv with a submodule it will detect that and update the > paths for its configurations (.gitmodules, worktree and gitfile). This > does not work for nested submodules where a user renames the root > submodule.

[PATCH] add test for bug in git-mv with nested submodules

When using git-mv with a submodule it will detect that and update the paths for its configurations (.gitmodules, worktree and gitfile). This does not work for nested submodules where a user renames the root submodule. We discovered this fact when working on on-demand fetch for renamed submodules.

Re: Bug with ignorecase on Git and Cygwin

the next version the correction was made, but Git was > unable to detect it. > > That said I've tried to manually change ignorecase from true to false and I > still have the issue. Git on Cygwin cannot detect files renamed with a case > change. > > Is it a bug? > The

Bug with ignorecase on Git and Cygwin

ignorecase from true to false and I still have the issue. Git on Cygwin cannot detect files renamed with a case change. Is it a bug? # It works on Ubuntu $ git --version git version 1.8.3.1 $ # To be sure $ git config --global init.templateDir /usr/share/git-core

Re: [BUG] git am sometimes unable to apply git format-patch output file

am command. Steps to reproduce: Excellent, thanks so much for the detailed bug report. This kind of information is really appreciated. Why did I say excellent ? Because I am working on a patch, which -should- fix exactly this kind of issues. I send out a patch earlier this day, but it doesn't

Re: Bug: `git remote show ` reports different HEAD branch than refs/remotes//HEAD

On Tue, Aug 15, 2017 at 01:58:38PM -0400, Jason Karns wrote: > > On the other hand, what "git remote show" outputs for HEAD is a name > > of actually checked-out branch inside that remote repository - it`s > > what`s stored inside HEAD file of the remote repository root. > > > > So it is

Re: Bug: `git remote show ` reports different HEAD branch than refs/remotes//HEAD

On Tue, Aug 15, 2017 at 1:09 PM, Igor Djordjevic wrote: > Hi Jason, > > On 15/08/2017 16:26, Jason Karns wrote: >> I have a git repo that shows a different branch in >> `.git/refs/remotes/origin/HEAD` than is reported by `git remote show >> origin`. >> >> The branch

Re: Bug: `git remote show ` reports different HEAD branch than refs/remotes//HEAD

Hi Jason, On 15/08/2017 16:26, Jason Karns wrote: > I have a git repo that shows a different branch in > `.git/refs/remotes/origin/HEAD` than is reported by `git remote show > origin`. > > The branch is `github-rename` in refs/remotes/origin/HEAD, but shows > `master` in output of

Bug: `git remote show ` reports different HEAD branch than refs/remotes//HEAD

I have a git repo that shows a different branch in `.git/refs/remotes/origin/HEAD` than is reported by `git remote show origin`. The branch is `github-rename` in refs/remotes/origin/HEAD, but shows `master` in output of git-remote-show ``` $ cat .git/refs/remotes/origin/HEAD ref:

Re: Bug?: git archive exclude pathspec and gitattributes export-ignore

On Mon, 14 Aug 2017, René Scharfe wrote: > Am 13.08.2017 um 06:53 schrieb David Adam: > > I think I have a bug in git (tested 2.11.0 on Debian 8, 2.14.1 on OS X and > > 2.14.1.145.gb3622a4 on OS X). > > > > Given a repository with an export-ignore d

Re: Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets?

Stefan Beller writes: > On Mon, Aug 14, 2017 at 9:05 AM, Johannes Schindelin > wrote: >> Hi Christoph, >> >> On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote: >> >>> on Windows 64-bit, for a repository having a .pack file > 4GB I get >>>

Re: Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets?

On Mon, Aug 14, 2017 at 9:05 AM, Johannes Schindelin wrote: > Hi Christoph, > > On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote: > >> on Windows 64-bit, for a repository having a .pack file > 4GB I get >> during cloning: > > The reason is Git's source code that

Re: Bug?: git archive exclude pathspec and gitattributes export-ignore

Am 13.08.2017 um 06:53 schrieb David Adam: > Hi all, > > I think I have a bug in git (tested 2.11.0 on Debian 8, 2.14.1 on OS X and > 2.14.1.145.gb3622a4 on OS X). > > Given a repository with an export-ignore directive for a subdirectory in > .gitattributes, `git arc

Re: Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets?

Hi Christoph, On Fri, 11 Aug 2017, Dr.-Ing. Christoph Cullmann wrote: > on Windows 64-bit, for a repository having a .pack file > 4GB I get > during cloning: The reason is Git's source code that over-uses the `unsigned long` datatype. In a nearby-thread, an underappreciated effort by Martin

Re: Bug when stashing previously-ignored file plus associated .gitignore change

Hello Kevin, Yes, you're right - I didn't commit the change to the .gitignore file, so that addition is also being stashed. Thanks Sam Sam Partington Senior Developer www.whiteoctober.co.uk Office: +44 (0)1865 920 707 This email message and any attachments are confidential and solely for the

Re: Bug when stashing previously-ignored file plus associated .gitignore change

On Fri, Aug 11, 2017 at 04:55:38PM +0100, Sam Partington wrote: > Hi there, > > I'm running git 2.7.4 on Ubuntu 16.04. I've found a couple of > problems when "un-ignoring" files in tandem with git stash. > > Here's how to reproduce: > > Say you have a project using git, with a .gitignore file

Bug?: git archive exclude pathspec and gitattributes export-ignore

Hi all, I think I have a bug in git (tested 2.11.0 on Debian 8, 2.14.1 on OS X and 2.14.1.145.gb3622a4 on OS X). Given a repository with an export-ignore directive for a subdirectory in .gitattributes, `git archive` with a pathspec that excludes a different subdirectory produces no output

Re: [BUG] git am sometimes unable to apply git format-patch output file

ommand. > > > > > > Steps to reproduce: > > Excellent, thanks so much for the detailed bug report. > This kind of information is really appreciated. > > Why did I say excellent ? > Because I am working on a patch, which -should- fix exactly this kind of >

Re: [BUG] git am sometimes unable to apply git format-patch output file

On Sat, Aug 12, 2017 at 07:02:59PM +0300, Soul Trace wrote: > Hello. > > Using git i have found that git am command may sometimes fail to apply patch > file which was created by the git am command. > > > Steps to reproduce: Excellent, thanks so much for the detailed

[BUG] git am sometimes unable to apply git format-patch output file

Hello. Using git i have found that git am command may sometimes fail to apply patch file which was created by the git am command. Steps to reproduce: # 1. Clone test repository: git clone https://github.com/S-trace/git_am_bug_test.git # 2. Format patch file for last commit: git

Bug when stashing previously-ignored file plus associated .gitignore change

Hi there, I'm running git 2.7.4 on Ubuntu 16.04. I've found a couple of problems when "un-ignoring" files in tandem with git stash. Here's how to reproduce: Say you have a project using git, with a .gitignore file which contains the following line: bin/* You can then see the problems by

Bug with corruption on clone/fsck/... with large packs + 64-bit Windows, problem with usage of "long" datatype for sizes/offsets?

Hi, on Windows 64-bit, for a repository having a .pack file > 4GB I get during cloning: $ git clone file:///repositories/test.git test Cloning into 'test'... remote: Counting objects: 210294, done. remote: error: bad object header remote: error: bad object header remote: fatal: packed object

bug: git stash list --format='%gd' --date=format:'…'

Synopsis: When expanding '%gd' placeholder (reflog selector), git substitutes user-specified --date format, which mangles the reflog. Description: I was writing a script that expects a stash reflog and a date on stdin: % git stash list --format='%gd%n%ad' stash@{0} Sat Aug 5

Re: Fwd: bug: contrib/subtree: Commit message title should be in imperative mood

I would argue that: 1. If used on the "Git project itself" (as in my case), the commit message now cannot be used unedited because it is a conflict with the project's guidelines, and also conflicts with the format of "all" (or most) the other Git (and GitHub) commit titles. 2. If not "used on the

Re: Fwd: bug: contrib/subtree: Commit message title should be in imperative mood

Bjørn Erik Pedersen writes: > I.e. "Squash 'somedir' changes" and not "Squashed ..." > > See > > https://github.com/git/git/blob/master/contrib/subtree/git-subtree.sh#L463 I do not think this is necessarily a good change. "git subtree" (in contrib/) is not a

Fwd: bug: contrib/subtree: Commit message title should be in imperative mood

I.e. "Squash 'somedir' changes" and not "Squashed ..." See https://github.com/git/git/blob/master/contrib/subtree/git-subtree.sh#L463

Re: Bug^Feature? fetch protects only current working tree branch

Am 24.07.2017 um 00:13 schrieb Junio C Hamano: > Andreas Heiduk writes: > >> A `git fetch . origin/master:master` protects the currently checked out >> branch (HEAD) unless the `-u/--update-head-ok` is supplied. This avoids a >> mismatch between the index and HEAD.

Re: Bug^Feature? fetch protects only current working tree branch

Andreas Heiduk writes: > A `git fetch . origin/master:master` protects the currently checked out > branch (HEAD) unless the `-u/--update-head-ok` is supplied. This avoids a > mismatch between the index and HEAD. BUT branches which are HEADs in other > working trees do

Bug^Feature? fetch protects only current working tree branch

A `git fetch . origin/master:master` protects the currently checked out branch (HEAD) unless the `-u/--update-head-ok` is supplied. This avoids a mismatch between the index and HEAD. BUT branches which are HEADs in other working trees do not get that care - their state is silently screwed up. Is

Re: Bug Report - Segmentation Fault on "git add --all"

On 20 July 2017 at 02:54, Tillson Galloway wrote: > Context: > We currently have a git project with a root directory ("~/project") > for pipelines and deployment of a Node app, and then a subdirectory > ("~/project/project-app"). > After realizing that we didn't need

Bug Report - Segmentation Fault on "git add --all"

orded ("no changes added to commit"). Running "git add --all" again causes a seg fault and repeats the cycle. I would assume that the cause of the seg fault was that node_modules held too much data for git to be able to handle in one go. I'm not sure if this is considered a (likely

Re: Git Bash Bug

Hi Paul, On Fri, 14 Jul 2017, Paul Smith wrote: > On Fri, 2017-07-14 at 22:33 +0200, Johannes Schindelin wrote: > > > You absolutely have to have /bin and /usr/bin on your PATH, > > > > As Kavita talks about Git Bash, it is probably Git for Windows, for > > which /bin should not be in the PATH

Re: Git Bash Bug

On Fri, 2017-07-14 at 22:33 +0200, Johannes Schindelin wrote: > > You absolutely have to have /bin and /usr/bin on your PATH, > > As Kavita talks about Git Bash, it is probably Git for Windows, for > which /bin should not be in the PATH but /mingw64/bin or /mingw32/bin > (depending on the

Re: Git Bash Bug

Hi, On Fri, 14 Jul 2017, Paul Smith wrote: > On Fri, 2017-07-14 at 09:59 -0500, Kavita Desai wrote: > > What does "echo $PATH" show? > > /c/Users/Kavita/ > > Well, there you go. That's clearly wrong. > > You absolutely have to have /bin and /usr/bin on your PATH, As Kavita talks about Git

Re: bug with check-ref-format outside of repository

ne" then I get 3 possible responses. > > git version: 2.13.0 > 1. Valid branch name > 2. fatal: '@{-1}' is not a valid branch name > 3. fatal: BUG: setup_git_env called without repository > > git version 2.13.2.915.ga9c46e097 > 1. Valid branch name > 2. fatal: '@{-1}' is n

Re: Git Bash Bug

On Fri, 2017-07-14 at 09:59 -0500, Kavita Desai wrote: > What does "echo $PATH" show? > /c/Users/Kavita/ Well, there you go. That's clearly wrong. You absolutely have to have /bin and /usr/bin on your PATH, _at least_ if you want to be able to run standard UNIX tools. And most likely you'll

Re: Git Bash Bug

Here are the results. What does "echo $PATH" show? /c/Users/Kavita/ What does "type -a ls" show? ls is aliased to `ls -F --color=auto --show-control-chars' On Fri, Jul 14, 2017 at 9:37 AM, Paul Smith wrote: > On Fri, 2017-07-14 at 09:34 -0500, Kavita Desai wrote: >>

Re: Git Bash Bug

On Fri, 2017-07-14 at 09:34 -0500, Kavita Desai wrote: > Sorry for not being specific. What I meant by not working was that the > bash commands are not found. > Here is an example > > $ ls > bash: ls: command not found The most obvious issue is your PATH is wrong. What does "echo $PATH" show?

<    5   6   7   8   9   10   11   12   13   14   >