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
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
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
Hi All,
Heres the situation. In the NonStop port, since time immemorial, weve had
a breakage in 5509 that Ive 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
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
/* 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.
>
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?
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
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
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
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.
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
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
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
> 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
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
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
>> >
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
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.
> >
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
> >>
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
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
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
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
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
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
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
(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
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
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
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
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
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-
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
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,
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
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
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
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
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
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
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
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
):
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
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
p->next = NULL;
+ }
strbuf_release();
free(array);
return list;
But given the commit message by Martin maybe there's some deeper bug here.
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
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
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
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
>
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
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
> 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
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
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
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
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
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
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
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
>
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
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
> >
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
Æ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
Æ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
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
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
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
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
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
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
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
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.
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
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
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.
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
> ---
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
>
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
> 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
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
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
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
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
701 - 800 of 4422 matches
Mail list logo