Re: [BUG] Weird breakages in t1450 #2 on NonStop

On Thu, Jan 11, 2018 at 04:39:04PM -0500, Randall S. Becker wrote: > > executed because the test_commit fails with a non-zero git commit > > completion code. There is no rn (actual r n 252 252 252 252) in > > the objects directory - even the 'rn' does not correspond to > > anything.. I am

RE: [BUG] Weird breakages in t1450 #2 on NonStop

On January 11, 2018 9:46 AM, I wrote: > This one has me scratching my head: > > The object file name being reported below in t1450, subtest 2 is corrupt, but I > can't figure out why the script might be generating this condition - there's > nothing apparent, but it looks like the git commit -m C

[BUG] Weird breakages in t1450 #2 on NonStop

This one has me scratching my head: The object file name being reported below in t1450, subtest 2 is corrupt, but I can't figure out why the script might be generating this condition - there's nothing apparent, but it looks like the git commit -m C step is reporting or using a bad name. This

[BUG] Breakage in t5509 # 2 from read(stdin) EINVAL

Hi All, Here’s the situation. In the NonStop port, since time immemorial, we’ve had a breakage in 5509 that I’ve finally had the chance to track down. The error report at the breakage is: ./trash directory.t5509-fetch-push-namespaces/original: GIT_TRACE=true GIT_PACKET_TRACE=true

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

s part of the loop. OK. I have nothing to offer, then. Thank you for taking care of this! >> I also found a bug in show_list(). I'm attaching a patch as well. > > Could you send it inline as explained in Documentation/SubmittingPatches? Done that. Thanks, -- yashi

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

/* clean-up unused elements if any */ +free_commit_list(p->next); +p->next = NULL; +} ... "i == cnt" is always false above. I think it should be "i == cnt - 1". And with your code one can wonder why the cleanup is part of the loop. >

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

Hi all, Thank you guys for insightful help. I just read the code and now I understand what you guys are saying. Yeah, I can say the fix is "spot on". But, to be honest, it's hard to see why you need "if (p)" at the first glance. So, how about this fix, instead?

Re: Possible bug report: git checkout tag problem

Hi Myles, On Mon, 8 Jan 2018, Myles Fong wrote: > Brief description: > When two tags are pointing to the same commit, e.g. tagA and tagB, if I > do `git checkout tagA` then `git checkout tagB`, and then `git status`, > it shows `HEAD detached at tagA` > > Expected behaviour: > I'm expecting it

Possible bug report: git checkout tag problem

Hi, Brief description: When two tags are pointing to the same commit, e.g. tagA and tagB, if I do `git checkout tagA` then `git checkout tagB`, and then `git status`, it shows `HEAD detached at tagA` Expected behaviour: I'm expecting it to show `HEAD detached at tagB`, though I understand

[BUG] "git stash -p" doesn't work well when splitting nearby changes

the other. The stash was created successfully but the discarding that change from the work tree failed with the following error, error: patch failed: Documentation/gitsubmodules.txt:57 error: Documentation/gitsubmodules.txt: patch does not apply Cannot remove worktree changes I guess this a bug tha

Bug Report: Subtrees and GPG Signed Commits

Hi all, I've noticed an issue regarding the use of `git subtree add` and `git subtree pull` when the subtree repository's commit (either HEAD or whatever commit specified by the subtree command) is signed with GPG. It seems to work properly if the commit is not signed but previous commits are.

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

Hi Yasushi, On Sat, Jan 6, 2018 at 3:27 PM, Yasushi SHOJI wrote: > best_bisection_sorted() seems to do > > - get the commit list along with the number of elements in the list > - walk the list one by one to check whether a element have TREESAME or not > - if

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

On 6 January 2018 at 15:27, Yasushi SHOJI wrote: > best_bisection_sorted() seems to do > > - get the commit list along with the number of elements in the list > - walk the list one by one to check whether a element have TREESAME or not > - if TREESAME, skip > - if

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

Hi Martin, Thank you for your comment. I haven't have time to read the code carefully so bare with me. On Sat, Jan 6, 2018 at 5:21 PM, Martin Ågren wrote: >> On Fri, Jan 5, 2018 at 11:45 AM, Yasushi SHOJI >> wrote: >>> When does the list

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

> On Fri, Jan 5, 2018 at 11:45 AM, Yasushi SHOJI > wrote: >> When does the list allowed to contain NULLs? Short answer: there are no commits left to test. The list is built in the for-loop in `find_bisection()`. So the technical answer is: if all commits in the initial

Re: Bug report: git clone with dest

On Fri, Jan 05, 2018 at 02:37:25PM -0800, Junio C Hamano wrote: > Well, MaintNotes on the 'todo' branch needs a bit of updating, as it > says something somewhat misleading. > > -- >8 -- > Subject: MaintNotes: clarify the purpose of maint->master upmerge Yup, this makes sense. Thanks for

Re: Bug report: git clone with dest

Jeff King writes: > On Fri, Jan 05, 2018 at 12:45:03PM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > Out of curiosity, did this change at some point? I thought the process >> > used to be to merge to maint, and then pick up topics in master by >> >

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

Yasushi SHOJI writes: > The patch (actually, I've tested the one in pu, 2e9fdc795cb27) avoids > the seg fault for sure, but the question is: > > When does the list allowed to contain NULLs? A very legitimate question. With the proposed log message alone, it is even

Re: Bug report: git clone with dest

Hi Peff, On Fri, 5 Jan 2018, Jeff King wrote: > On Fri, Jan 05, 2018 at 09:22:07PM +0100, Johannes Schindelin wrote: > > > On Fri, 5 Jan 2018, Isaac Shabtay wrote: > > > > > Done: https://github.com/git-for-windows/git/pull/1421 > > > > > > I added credit to Jeff in the PR's description. > >

Re: Bug report: git clone with dest

Hi, On Fri, 5 Jan 2018, Junio C Hamano wrote: > Jeff King writes: > > > On Wed, Jan 03, 2018 at 02:42:51PM -0800, Isaac Shabtay wrote: > > > >> Indeed interesting... this one's for the books... > >> Thanks for the patches. Any idea when these are going to make it to the > >>

Re: Bug report: git clone with dest

On Fri, Jan 05, 2018 at 12:45:03PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Out of curiosity, did this change at some point? I thought the process > > used to be to merge to maint, and then pick up topics in master by > > merging maint to master. > > If you look at

Re: Bug report: git clone with dest

Jeff King writes: > Out of curiosity, did this change at some point? I thought the process > used to be to merge to maint, and then pick up topics in master by > merging maint to master. If you look at "Sync with maint" merges made to 'master', you'd notice that most of them are

Re: Bug report: git clone with dest

On Fri, Jan 05, 2018 at 09:22:07PM +0100, Johannes Schindelin wrote: > On Fri, 5 Jan 2018, Isaac Shabtay wrote: > > > Done: https://github.com/git-for-windows/git/pull/1421 > > > > I added credit to Jeff in the PR's description. > > Sadly, the PR's description won't make it into the commit

Re: Bug report: git clone with dest

Johannes Schindelin writes: > Hi Isaac, > > On Fri, 5 Jan 2018, Isaac Shabtay wrote: > >> Done: https://github.com/git-for-windows/git/pull/1421 >> >> I added credit to Jeff in the PR's description. > > Sadly, the PR's description won't make it into the commit

Re: Bug report: git clone with dest

Hi Isaac, On Fri, 5 Jan 2018, Isaac Shabtay wrote: > Done: https://github.com/git-for-windows/git/pull/1421 > > I added credit to Jeff in the PR's description. Sadly, the PR's description won't make it into the commit history, and the authorship really should have been retained. I found

Re: Apparent bug in 'git stash push ' loses untracked files

On 12/18, Junio C Hamano wrote: > Thomas Gummerer <t.gumme...@gmail.com> writes: > > > Ah interesting, what you have below looks good to me indeed, it > > matches what I'd expect it to do and fixes the bug that was reported. > > Thanks! > > > > I've tak

Re: Bug report: git clone with dest

the next > > major release. For a pure bug-fix, it may instead go to 'maint' and > > become part of the next minor release. > > Even a pure bug-fix, unless it is something no longer needed on the > 'master' front, goes thru 'pu'->'next'->'master' avenue first, and > is reco

Re: Bug report: git clone with dest

(specifically the Windows one) > > They haven't even been reviewed yet. If they get good feedback, then the > maintainer will pick them up, then merge them to 'next', and then > eventually to 'master', after which they'd become part of the next > major release. For a pure bug-fix, i

Re: Bug report: git clone with dest

Done: https://github.com/git-for-windows/git/pull/1421 I added credit to Jeff in the PR's description. Note that I tried compiling master, but failed due to a reason unrelated to this patch: builtin/checkout.c:24:10: fatal error: fscache.h: No such file or directory Maybe I wasn't building it

Re: Bug report: git clone with dest

Hi Isaac, On Thu, 4 Jan 2018, Isaac Shabtay wrote: > I cloned git's codebase, applied the four patches on master, built and > tested on Ubuntu Trusty. (After verifying that master indeed exhibits > this behaviour on Linux as well. Just checking). > Seems to work fine. > I also looked at the

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

Hi, On Fri, Jan 5, 2018 at 11:45 AM, Yasushi SHOJI wrote: > So that I can make a test case. OK, here is the step to reproduce on git.git $ git bisect start $ git bisect bad v2.16.0-rc0 $ git bisect good 0433d533f13671f4313c31e34707f0f5281a18e0 $ git bisect good $ git

Re: Bug report: git clone with dest

Hello Johannes, Jeff, I cloned git's codebase, applied the four patches on master, built and tested on Ubuntu Trusty. (After verifying that master indeed exhibits this behaviour on Linux as well. Just checking). Seems to work fine. I also looked at the code. Most of the patched lines relate to

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

isect.c >> +++ b/bisect.c >> @@ -229,8 +229,10 @@ static struct commit_list *best_bisection_sorted(struct >> commit_list *list, int n >> if (i < cnt - 1) >> p = p->next; >> } >> - free_commit_list(p-

Re: Rewrite cat-file.c : need help to find a bug

On Thu, Jan 4, 2018 at 11:23 PM, Оля Тележная wrote: > > So for now 2 of my last commits fail, and I am tired of searching for the > error. > I was also trying to leave cat_file_info variable and fill in both new > and old variables and then compare resulting values by

Re: Bug report: git clone with dest

Hi Isaac, On Wed, 3 Jan 2018, Isaac Shabtay wrote: > Indeed interesting... this one's for the books... > Thanks for the patches. Any idea when these are going to make it to > the official Git client builds? (specifically the Windows one) If you help them getting reviewed, tested, and validated,

Re: Rewrite cat-file.c : need help to find a bug

from ref-filter in cat-file >>> command. Now cat-file uses its own formatting code. >>> I am trying to achieve that step-by-step, Happy to say that my previous bug is fixed, and I am struggling with the next one. Now I want to get rid of using expand_data structure (I took it

Re: Bug/feature request: Can’t disable fsck warnings during clone

Hi Kevin, On Thu, 28 Dec 2017, Kevin A. Mitchell wrote: > I’ve set transfer.fsckObjects to true globally, for safety. > Unfortunately, this messed up my Spacevim install. > > Doing some digging, I found that some of the repos had a warning. I > can turn the warning off, but that only affects

Re: Bug report: git clone with dest

iewed yet. If they get good feedback, then the maintainer will pick them up, then merge them to 'next', and then eventually to 'master', after which they'd become part of the next major release. For a pure bug-fix, it may instead go to 'maint' and become part of the next minor release. Right now we're enterin

Re: Bug report: git clone with dest

Indeed interesting... this one's for the books... Thanks for the patches. Any idea when these are going to make it to the official Git client builds? (specifically the Windows one) On 3 January 2018 at 14:28, Jeff King wrote: > On Wed, Jan 03, 2018 at 12:59:48PM -0800, Isaac

Re: Bug report: git clone with dest

On Wed, Jan 03, 2018 at 12:59:48PM -0800, Isaac Shabtay wrote: > Target directory is deleted on clone failures. > > Steps to reproduce, for example on Windows: > > cd /d %TEMP% > mkdir dest > git clone https://some-fake-url/whatever-makes-git-clone-fail dest > > Of course, the clone will fail

Bug report: git clone with dest

Hello, Target directory is deleted on clone failures. Steps to reproduce, for example on Windows: cd /d %TEMP% mkdir dest git clone https://some-fake-url/whatever-makes-git-clone-fail dest Of course, the clone will fail as it should. But looks like the Git client also ends up deleting the

[PATCH v2 4/5] update-index doc: note a fixed bug in the untracked cache

Document the bug tested for in my "status: add a failing test showing a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir invalidation in untracked code". Since this is very likely something others will encounter in the future on older versions, and it's no

[PATCH v2 1/5] status: add a failing test showing a core.untrackedCache bug

quot; are needed to reproduce this, presumably due to the untracked cache tracking on the basis of cached whole seconds from stat(2). When git gets into this state, a workaround to fix it is to issue a one-off: git -c core.untrackedCache=false status For the non-symlink case, the bug is that

[PATCH v2 0/5] untracked cache bug fixes

): dir.c: avoid stat() in valid_cached_dir() dir.c: fix missing dir invalidation in untracked code dir.c: stop ignoring opendir() error in open_cached_dir() Ævar Arnfjörð Bjarmason (2): status: add a failing test showing a core.untrackedCache bug update-index doc: note a fixed bug

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

ect.c > @@ -229,8 +229,10 @@ static struct commit_list *best_bisection_sorted(struct > commit_list *list, int n > if (i < cnt - 1) > p = p->next; > } > - free_commit_list(p->next); > - p->next = NULL; > + if

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

p->next = NULL; + } strbuf_release(); free(array); return list; But given the commit message by Martin maybe there's some deeper bug here.

[BUG] v2.16.0-rc0 seg faults when git bisect skip

d "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation r

RE: [Bug] NO_INTPTR_T not being honoured in compat/regex/regcomp.c

On January 1, 2018 4:51 PM Eric Sunshine wrote: > On Mon, Jan 1, 2018 at 4:21 PM, Randall S. Becker > wrote: > > * I have defined NO_INTPTR_T = UnfortunatelyYes in config.mak.uname > > for my platform. The c99 compiler I have does not define it. > > * The code compiles

RE: [Bug] NO_INTPTR_T not being honoured in compat/regex/regcomp.c

On January 1, 2018 4:51 PM Eric Sunshine wrote: > On Mon, Jan 1, 2018 at 4:21 PM, Randall S. Becker > wrote: > > * I have defined NO_INTPTR_T = UnfortunatelyYes in config.mak.uname > > for my platform. The c99 compiler I have does not define it. > > * The code compiles

Re: [Bug] NO_INTPTR_T not being honoured in compat/regex/regcomp.c

On Mon, Jan 1, 2018 at 4:21 PM, Randall S. Becker wrote: > * I have defined NO_INTPTR_T = UnfortunatelyYes in config.mak.uname for my > platform. The c99 compiler I have does not define it. > * The code compiles except for compat/regex/regcomp.c - not sure why this is >

[Bug] NO_INTPTR_T not being honoured in compat/regex/regcomp.c

I'm looking for the proper approach for dealing with the following situation in 2.8.5: * I have defined NO_INTPTR_T = UnfortunatelyYes in config.mak.uname for my platform. The c99 compiler I have does not define it. * The code compiles except for compat/regex/regcomp.c - not sure why this is being

Re: possible completion bug with --set-upstream-to=

culprit: $ grep COMP_WORDBREAKS /etc/bash_completion.d/* /etc/bash_completion.d/npm:COMP_WORDBREAKS=${COMP_WORDBREAKS/=/} /etc/bash_completion.d/npm:COMP_WORDBREAKS=${COMP_WORDBREAKS/@/} /etc/bash_completion.d/npm:export COMP_WORDBREAKS $ dpkg -S /etc/bash_completion.d/npm npm: /etc/bash

Re: possible completion bug with --set-upstream-to=

> Whenever I type the last to complete origin/master, as in below: > > > git branch --set-upstream-to=orig > > what I get is: > > > git branch origin/master Yeah, this shouldn't happen. > instead of the expected: > > > git branch --set-upstream-to=origin/master And indeed this is the

possible completion bug with --set-upstream-to=

Whenever I type the last to complete origin/master, as in below: > git branch --set-upstream-to=orig what I get is: > git branch origin/master instead of the expected: > git branch --set-upstream-to=origin/master git version and OS: >git version 2.1.4 > >Distributor ID:Debian

Re: [BUG] git bisect colour output contrary to configuration

quot;\33[33mcommit > 3e6fc602e433dbd76941ac0ef7a438a77fbe9a05\33[m\n", 56) = 56 > > Given the configuration, that line should be free of escape sequences. > > I'm mainly using git 2.1.4 via Debian, but I've also > reproduced this problem with the latest from git.git (commit > 1eaabe34f

[BUG] git bisect colour output contrary to configuration

My ~/.gitconfig sets color.ui=never, which should prevent attempts at colouring output from all git commands. I do not have any git configuration enabling colour in any situation (such as for specific commands). But when a git bisect completes, the output identifying the first bad commit

Re: Rewrite cat-file.c : need help to find a bug

gt; I am trying to achieve that step-by-step, now I want to invoke >> populate_value function, and I have a bug somewhere. >> My code is here. >> https://github.com/telezhnaya/git/commits/catfile >> All commits that starts from "cat-file: " are successfully

Re: Rewrite cat-file.c : need help to find a bug

function, and I have a bug somewhere. > My code is here. > https://github.com/telezhnaya/git/commits/catfile > All commits that starts from "cat-file: " are successfully passing all tests. > So for now my last commit fails, and I am tired of searching for the > error. Actual

Rewrite cat-file.c : need help to find a bug

Hi everyone, I am trying to reuse formatting logic from ref-filter in cat-file command. Now cat-file uses its own formatting code. I am trying to achieve that step-by-step, now I want to invoke populate_value function, and I have a bug somewhere. My code is here. https://github.com/telezhnaya/git

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

Duy Nguyen writes: >> Duy, what am I missing here? > > The problem is there, it's just easier to see or verify with > symlinks. Below is my test patch on top of your original one. Two > points: > > - if you look at the test-dump-untracked-cache output, you can see the >

Bug/feature request: Can’t disable fsck warnings during clone

Hi! I’ve set transfer.fsckObjects to true globally, for safety. Unfortunately, this messed up my Spacevim install. Doing some digging, I found that some of the repos had a warning. I can turn the warning off, but that only affects git fsck, not git clone. Turning off transfer.fsckObjects also

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Wed, Dec 27, 2017 at 07:50:29PM +0100, Ævar Arnfjörð Bjarmason wrote: > > This needs SYMLINKS prereq, which in turn means it cannot be tested > > on certain platforms. I thought Duy's answer was that this does not > > need to involve a symbolic link at all? If so, perhaps we can have > >

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Wed, Dec 27 2017, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> +status_is_clean() { >> +>../status.expect && >> +git status --porcelain >../status.actual && >> +test_cmp ../status.expect ../status.actual >> +} >> + >> test_lazy_prereq

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

Ævar Arnfjörð Bjarmason writes: > +status_is_clean() { > + >../status.expect && > + git status --porcelain >../status.actual && > + test_cmp ../status.expect ../status.actual > +} > + > test_lazy_prereq UNTRACKED_CACHE ' > { git update-index

Re: [PATCH 3/1] update-index doc: note a fixed bug in the untracked cache

Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > Document the bug tested for in my "status: add a failing test showing > a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir > invalidation in untracked code". > > Since this is ve

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Wed, Dec 27, 2017 at 5:25 AM, Duy Nguyen wrote: > Subject: [PATCH] dir.c: fix missing dir invalidation in untracked code > [...] > After step 3, we mark the cache valid. Any stale subdir with incorrect > recurse flagbecomes a real subdir next time we traverse the directory

[PATCH 3/1] update-index doc: note a fixed bug in the untracked cache

Document the bug tested for in my "status: add a failing test showing a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir invalidation in untracked code". Since this is very likely something others will encounter in the future on older versions, and it's no

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Tue, Dec 26, 2017 at 05:47:19PM +0700, Duy Nguyen wrote: > Strangely, root dir is not cached (no valid flag). I don't know why > but that's ok we'll roll with it. I figured this out. Which is good because now I know how/why the bug happens. > An invalidate_directory() call before th

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Tue, Dec 26, 2017 at 1:45 AM, Ævar Arnfjörð Bjarmason wrote: > > On Mon, Dec 25 2017, Duy Nguyen jotted: > >> On Fri, Dec 22, 2017 at 9:00 PM, Ævar Arnfjörð Bjarmason >> wrote: >>> The untracked cache gets confused when a directory is swapped out for >>> a

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Mon, Dec 25 2017, Duy Nguyen jotted: > On Fri, Dec 22, 2017 at 9:00 PM, Ævar Arnfjörð Bjarmason > wrote: >> The untracked cache gets confused when a directory is swapped out for >> a symlink to another directory. Whatever files are inside the target >> of the symlink will

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Fri, Dec 22, 2017 at 9:00 PM, Ævar Arnfjörð Bjarmason wrote: > The untracked cache gets confused when a directory is swapped out for > a symlink to another directory. Whatever files are inside the target > of the symlink will be incorrectly shown as untracked. This issue does

Re: [BUG] File move with `add -N` shows as rename to same name

On Sat, Dec 23, 2017 at 9:42 AM, Alex Vandiver wrote: > I just stumbled across the following oddity: Thanks. I'm looking into it. -- Duy

[PATCH] status: add a failing test showing a core.untrackedCache bug

The untracked cache gets confused when a directory is swapped out for a symlink to another directory. Whatever files are inside the target of the symlink will be incorrectly shown as untracked. This issue does not happen if the symlink links to another file, only if it links to another directory.

Re: [PATCH] Re: Bug with "git submodule update" + subrepo with differing path/name?

On Thu, Dec 21, 2017 at 2:17 PM, Andreas Urke wrote: > Thanks for the detailed explanation. Although I am not too git savvy, > I believe I got the gist of it. > > Regarding your question, > I would say the term "name" in an IT context makes me primarily think > of something that

Re: [PATCH] Re: Bug with "git submodule update" + subrepo with differing path/name?

On Thu, Dec 21, 2017 at 2:08 PM, Junio C Hamano wrote: > That sounds like a bit of revisionist history, but you weren't around > back then, so... > > https://public-inbox.org/git/11793556371774-git-send-email-jun...@cox.net/#r > > is my summarization of discussions before that

Re: [PATCH] Re: Bug with "git submodule update" + subrepo with differing path/name?

Thanks for the detailed explanation. Although I am not too git savvy, I believe I got the gist of it. Regarding your question, I would say the term "name" in an IT context makes me primarily think of something that is specified by a user (as opposed to e.g. an "id"), and can be altered by a user.

Re: [PATCH] Re: Bug with "git submodule update" + subrepo with differing path/name?

On Thu, Dec 21, 2017 at 8:21 AM, Andreas Urke wrote: > If I am entering into undefined behavior territory with the renaming > then there might not be any point to pursue this further, but in any > case, script below: > > Apologies up-front for the verbosity, there are probably a

Re: [PATCH] Re: Bug with "git submodule update" + subrepo with differing path/name?

If I am entering into undefined behavior territory with the renaming then there might not be any point to pursue this further, but in any case, script below: Apologies up-front for the verbosity, there are probably a lot of unnecessary steps and git shortcuts missed - I just wanted it to exactly

Re: [PATCH] Re: Bug with "git submodule update" + subrepo with differing path/name?

On Wed, Dec 20, 2017 at 12:22 AM, Andreas Urke wrote: > Thanks for looking into this. > > I was able to reproduce it from scratch, but I followed my earlier > workflow where I first created the subrepos, and then later renamed > it. At the time I was not able to find any command

Re: [PATCH] Re: Bug with "git submodule update" + subrepo with differing path/name?

Thanks for looking into this. I was able to reproduce it from scratch, but I followed my earlier workflow where I first created the subrepos, and then later renamed it. At the time I was not able to find any command to rename without changing the path (and I was not able find one now either, is

Re: [PATCH] Re: Bug with "git submodule update" + subrepo with differing path/name?

On Tue, Dec 19, 2017 at 2:19 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> I tried reproducing the issue (based on the `next` branch, not 2.15, >> but I do not recall any changes in the submodule area lately), and >> could not come up with a

Re: [PATCH] Re: Bug with "git submodule update" + subrepo with differing path/name?

Stefan Beller writes: > I tried reproducing the issue (based on the `next` branch, not 2.15, > but I do not recall any changes in the submodule area lately), and > could not come up with a reproduction recipe,... I do not offhand recall anything; the closest I can think of

[PATCH] Re: Bug with "git submodule update" + subrepo with differing path/name?

I tried reproducing the issue (based on the `next` branch, not 2.15, but I do not recall any changes in the submodule area lately), and could not come up with a reproduction recipe, but here is what I got so far, maybe you can take it from here (i.e. either make the test case more like your

Bug with "git submodule update" + subrepo with differing path/name?

Hi, I have a repo with two submodules. I regularly use "git submodule update", which works fine for one subrepo, but not for the other. The only relevant difference I can think of between these two subrepos is that the latter one does not have a matching path and name: $ cat .gitmodules

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Sun, Dec 17, 2017 at 10:40 PM, Jeff King wrote: > On Sun, Dec 17, 2017 at 08:03:41PM -0800, Jacob Keller wrote: > >> I do find it a bit weird that --global writes to one of either file, >> and doesn't read from both. I'd rather have --global "only" be >> .gitconfig, and instead

Re: Apparent bug in 'git stash push ' loses untracked files

Thomas Gummerer <t.gumme...@gmail.com> writes: > Ah interesting, what you have below looks good to me indeed, it > matches what I'd expect it to do and fixes the bug that was reported. > Thanks! > > I've taken the liberty to take what you have below and turned into a >

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

Yaroslav Halchenko writes: > On Mon, 18 Dec 2017, Jeff King wrote: > >> To complete that abstraction it seems like reading via "--global" should >> read from both (in the same precedence order that normal config lookup >> uses). > > FWIW +1 from me on that ;) FWIW I do not

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Mon, 18 Dec 2017, Jeff King wrote: > To complete that abstraction it seems like reading via "--global" should > read from both (in the same precedence order that normal config lookup > uses). FWIW +1 from me on that ;) -- Yaroslav O. Halchenko Center for Open Neuroscience

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Sun, Dec 17, 2017 at 08:03:41PM -0800, Jacob Keller wrote: > I do find it a bit weird that --global writes to one of either file, > and doesn't read from both. I'd rather have --global "only" be > .gitconfig, and instead add a new option for handling XDG file, and > then have it such that it

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Sat, Dec 16, 2017 at 2:01 PM, brian m. carlson wrote: > On Mon, Dec 11, 2017 at 05:05:01PM -0800, Junio C Hamano wrote: >> Jonathan Nieder writes: >> > As for "git config --global", I think the best thing would be to split >> > it into two

Re: Apparent bug in 'git stash push ' loses untracked files

spelling this out below. After reading that I definitely agree that 'git reset --hard -- ' wouldn't be a good UI, and something like that would belong in checkout. > But I suspect that you do not have to do shell "logic" nor low-level > plumbing update in this case. Would t

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Mon, Dec 11, 2017 at 05:05:01PM -0800, Junio C Hamano wrote: > Jonathan Nieder writes: > > As for "git config --global", I think the best thing would be to split > > it into two options: something like "git config --user" and "git > > config --xdg-user". That way, it is

Re: Apparent bug in 'git stash push ' loses untracked files

Thomas Gummerer writes: > Maybe the best solution would be to introduce 'git reset --hard -- > ', or maybe someone who knows shell programming a little > better than me has an idea? > > diff --git a/git-stash.sh b/git-stash.sh > index 1114005ce2..01bf74015e 100755 > ---

Re: Apparent bug in 'git stash push ' loses untracked files

Hi Thomas, On 14/12/2017 00:14, Thomas Gummerer wrote: > > > For what it`s worth, using `git stash save ` instead seems > > to (still) work as expected... > > I think that depends on what you expect ;) 'git stash save ' > will create a stash of the whole working directory with the message >

Re: Apparent bug in 'git stash push ' loses untracked files

On 12/13, Igor Djordjevic wrote: > Hi Reid, > > On 13/12/2017 18:32, Reid Price wrote: > > > > When running 'git stash push ' if there are both tracked and > > untracked files in this subdirectory, the tracked files are stashed > > but the untracked files are discarded. > > I can reproduce this

Re: Apparent bug in 'git stash push ' loses untracked files

> below script as > > bash -x ./stashbug.sh &> output.txt > > I could not find this indicated anywhere as an existing issue by > performing generic searches, apologies if this is known. Thanks for the detailed bug report below. This is indeed a bug, and indeed

Re: Apparent bug in 'git stash push ' loses untracked files

Hi Reid, On 13/12/2017 18:32, Reid Price wrote: > > When running 'git stash push ' if there are both tracked and > untracked files in this subdirectory, the tracked files are stashed > but the untracked files are discarded. I can reproduce this as well (git version 2.15.1.windows.2). For what

Apparent bug in 'git stash push ' loses untracked files

When running 'git stash push ' if there are both tracked and untracked files in this subdirectory, the tracked files are stashed but the untracked files are discarded. I can reproduce this on my system (OSX, git 2.14.1) by running the below script as bash -x ./stashbug.sh &> output.txt I

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Tue, Dec 12, 2017 at 6:13 AM, Yaroslav Halchenko wrote: > > On Mon, 11 Dec 2017, Junio C Hamano wrote: > >> Jonathan Nieder writes: > >> > I think the documentation > >> > ~/.gitconfig >> > User-specific configuration file. Also called

Re: Q: rational for $XDG_CONFIG_HOME/git/config to be "non global" or just a bug?

On Tue, Dec 12, 2017 at 11:36 AM, Junio C Hamano wrote: > Jacob Keller writes: > >>> I actually thought that the plan was "you either have this, or the >>> other one, never both at the same time" (and I think those who >>> pushed the XDG thing in to the

<    3   4   5   6   7   8   9   10   11   12   >