On Mon, Mar 19, 2018 at 08:33:15PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The best you can probably do is:
> >
> > /.readme-docs/* diff=foo
> >
> > Since you have no diff.foo.* config, that will behave in the default way
> > (including respecting the usual "is it binary" checks
On Mon, Mar 19, 2018 at 11:33 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> The best you can probably do is:
>>
>> /.readme-docs/* diff=foo
>>
>> Since you have no diff.foo.* config, that will behave in the default way
>> (including respecting the usual "is it binary" checks). So a bit hac
Jeff King writes:
> The best you can probably do is:
>
> /.readme-docs/* diff=foo
>
> Since you have no diff.foo.* config, that will behave in the default way
> (including respecting the usual "is it binary" checks). So a bit hacky,
> but I think it would work as "ignore prior diff".
You can s
Sorry to tack on to my previous email, but I just thought of this:
If something like "-diff=lfs" won't do what I (and git-lfs) thought it
would, do you think it would be prudent/reasonable to suggest git-lfs
add a "no-lfs" filter for exactly this case? That way I could have
explicit exclusions wit
Thanks for the quick reply!
On Mon, Mar 19, 2018 at 10:34 PM, Jeff King wrote:
> On Mon, Mar 19, 2018 at 09:49:28PM -0400, Dakota Hawkins wrote:
>
>> Summary: Trying to apply attributes to file extensions everywhere
>> except in one directory.
>>
>> .gitattributes:
>>
>> *.[Pp][Nn][Gg] filter
On Mon, Mar 19, 2018 at 09:49:28PM -0400, Dakota Hawkins wrote:
> Summary: Trying to apply attributes to file extensions everywhere
> except in one directory.
>
> .gitattributes:
>
> *.[Pp][Nn][Gg] filter=lfs diff=lfs merge=lfs -text
> /.readme-docs/ -filter=lfs -diff=lfs -merge=lfs
>
>
According to the gitattributes docs:
"When more than one pattern matches the path, a later line overrides
an earlier line. This overriding is done per attribute."
I had a need to do this recently, and while the attributes are git-lfs
specific, I think the issue may be generic.
Summary: Trying to
Joseph Strauss writes:
> I found the following erroneous behavior with "git rebase -p".
>
> My current version is git version 2.16.2.windows.1
>
> I made an example at GitHub, https://github.com/jkstrauss/git-bug/
>
> There seem to be two problems when rebasing m
I found the following erroneous behavior with "git rebase -p".
My current version is git version 2.16.2.windows.1
I made an example at GitHub, https://github.com/jkstrauss/git-bug/
There seem to be two problems when rebasing merge commits with git rebase -p :
1. All lines of mer
On Mon, Mar 19, 2018 at 04:14:31PM -0400, Nick Hunt wrote:
> oh, wait, switching branches didn't vaporize my changes, it auto-committed
> them.
> which is still weird and possibly a bug?
Are you sure that the changes were not already present on the
switched-to branch?
-Peff
oh, wait, switching branches didn't vaporize my changes, it auto-committed them.
which is still weird and possibly a bug?
Nick Hunt
nhun...@gmail.com
404-988-1845
On Mon, Mar 19, 2018 at 3:13 PM, Nick Hunt wrote:
> i committed my changes, then ran
> git reset --soft HEAD^
>
i committed my changes, then ran
git reset --soft HEAD^
at this point everything is fine
then i switched branches, and all of my changes vaporized into thin
air. uhhh, is this supposed to happen?
anyway, thank god intellij saves my work for me as i go, so i didn't
have to re-write all my code.
my
I've just been reviewing some patches with 'git log --graph --patch' and
came across what looked like a bug:
| @@ -272,6 +272,9 @@ do
| --keep-empty)
| keep_empty=yes
| ;;
| --allow-empty-message)
| + --no-keep-empty)
| +
On 15/03/2018 17:52, Junio C Hamano wrote:
>
> > Hi, I ran into what I believe is a bug today. I’m using primarily Git
> > for Windows 2.16.2 and also reproduced the behavior on Git for Windows
> > 2.15.1 and Git 2.14.1 on Ubuntu:
> >
> > Given any reposito
> -Original Message-
> From: git-ow...@vger.kernel.org On Behalf
> Of Junio C Hamano
> Sent: March 15, 2018 12:52 PM
> To: Jake Stine
> Cc: git@vger.kernel.org
> Subject: Re: [bug] git stash push {dir-pathspec} wipes untracked files
>
> Jake Stine writes:
&
Jake Stine writes:
> Hi, I ran into what I believe is a bug today. I’m using primarily Git
> for Windows 2.16.2 and also reproduced the behavior on Git for Windows
> 2.15.1 and Git 2.14.1 on Ubuntu:
>
> Given any repository with at least one subdirectory:
>
> 1.
Hi, I ran into what I believe is a bug today. I’m using primarily Git
for Windows 2.16.2 and also reproduced the behavior on Git for Windows
2.15.1 and Git 2.14.1 on Ubuntu:
Given any repository with at least one subdirectory:
1. Create some untracked files in the subdir
2. Modify a
On Tue, Mar 13 2018, Alexander Mills jotted:
> $ git log -50 ### I get 50 results
>
> $ git log -50 --grep="*" ### I get a lot more than 50...
>
> shouldn't `-50` minimize the results length to 50 or fewer?
On what git version? On my 2.16.2.804.g6dcf76e118 on git.git this works
as expected:
$ git log -50 ### I get 50 results
$ git log -50 --grep="*" ### I get a lot more than 50...
shouldn't `-50` minimize the results length to 50 or fewer?
-alex
--
Alexander D. Mills
! New cell phone number: (415)766-8243
alexander.d.mi...@gmail.com
www.linkedin.com/pub/alexander-mills/b/7a
On Tue, Mar 13 2018, Stan Hu jotted:
> To be clear, this is how I think we got into this state:
>
> We have worktrees that are created to squash and rebase a branch. They were
> left around inadvertently for one reason or another.
>
> Since we were using git v2.14.3, a git gc would prune danglin
On Friday 26 January 2018 02:54 PM, Duy Nguyen wrote:
>
> Sort of. It smells bad design to me when a mistake can easily become a
> feature. But with your help, I think I should be able to disable this
> feature on my local build. Thanks.
>
In case you're still facing this issue, it just struck m
To be clear, this is how I think we got into this state:
We have worktrees that are created to squash and rebase a branch. They were
left around inadvertently for one reason or another.
Since we were using git v2.14.3, a git gc would prune dangling objects because
it never saw that a worktree s
On Mon, Mar 12, 2018 at 10:39 PM, Ævar Arnfjörð Bjarmason
wrote:
> Now, obviously the root cause is that the repo is corrupt through some
> other bug (since fixed?), but the error message here is really bad, and
> should at least say "fatal: bad object HEAD in worktree blah"
u?
>
> It doesn't seem to help.
>
> $ git worktree prune -n
>
> $ git worktree prune
> $ git fetch
> remote: Counting objects: 35, done.
> remote: Compressing objects: 100% (20/20), done.
> remote: Total 21 (delta 17), reused 5 (delta 1)
> Unpacking objects: 100% (21
l.com] On Behalf Of Junio C Hamano
Sent: Wednesday, March 07, 2018 23:03
To: Vromen, Tomer
Cc: git@vger.kernel.org
Subject: Re: Bug report: git-stash doesn't return correct status code
Junio C Hamano writes:
> "Vromen, Tomer" writes:
>
>>> git stash && git c
Junio C Hamano writes:
> "Vromen, Tomer" writes:
>
>>> git stash && git checkout -b new-feature-branch && git stash pop
>>
>> This is useful when I realize that I want to open a new branch for my
>> changes (that I haven't committed yet).
>> However, I might have forgotten to save my changes in
"Vromen, Tomer" writes:
>> git stash && git checkout -b new-feature-branch && git stash pop
>
> This is useful when I realize that I want to open a new branch for my changes
> (that I haven't committed yet).
> However, I might have forgotten to save my changes in the editor, so
> git-stash will
Hi all,
I often use this one-liner:
> git stash && git checkout -b new-feature-branch && git stash pop
This is useful when I realize that I want to open a new branch for my changes
(that I haven't committed yet).
However, I might have forgotten to save my changes in the editor, so git-stash
wi
is an invalid bug report.
I'm running Git version: 2.16.2 (Debian Unstable)
--
Sean Behan
signature.asc
Description: PGP signature
the github documentation:
https://help.github.com/articles/generating-a-new-gpg-key/
that saves my keys in ~/AppData/Roaming/GnuPG.
2018-03-05 15:29 GMT+01:00 Johannes Schindelin :
> Hi Larry,
>
> On Sun, 4 Mar 2018, Larry Hunter wrote:
>
>> There is bug using "git log --s
Jeff King wrote:
> On Fri, Mar 02, 2018 at 09:15:44AM -0800, Junio C Hamano wrote:
>> Jeff King writes:
>>> That's probably a reasonable sanity check, but I think we need to abort
>>> and not just have a too-small DISPLAY array. Because later code like the
>>> hunk-splitting is going to assume th
On Mon, Mar 05, 2018 at 03:49:13PM +0100, Johannes Schindelin wrote:
> > I think that is doing the right thing for half of the problem. But
> > there's something else funny where we do not include the "upstream"
> > commits from the split history (i.e., we rebase onto nothing,
> > whereas a normal
Hi Peff,
On Wed, 28 Feb 2018, Jeff King wrote:
> On Tue, Feb 27, 2018 at 12:33:56AM +0100, Johannes Schindelin wrote:
>
> > > So something like this helps:
> > >
> > > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > > index 81c5b42875..71e6cbb388 100644
> > > --- a/git-
Hi Larry,
On Sun, 4 Mar 2018, Larry Hunter wrote:
> There is bug using "git log --show-signature" in my installation
>
> git 2.16.2.windows.1
> gpg (GnuPG) 2.2.4
> libgcrypt 1.8.2
The gpg.exe shipped in Git for Windows should say something like this:
There is bug using "git log --show-signature" in my installation
git 2.16.2.windows.1
gpg (GnuPG) 2.2.4
libgcrypt 1.8.2
that prints (with colors) an extra ^M (carriage return?) at the end of
the gpg lines. As an example, the output of "git log --show-signature
H
On Fri, Mar 02, 2018 at 01:53:32PM -0800, Junio C Hamano wrote:
> Sam Kuper writes:
>
> > 1. It would yield, IIUC, less flexibility to create new kinds of view
> > based on a consistent, standardised underlying model.
> >
> > 2. It is harder to read, for some types of input (e.g. prose) than the
On Fri, Mar 02, 2018 at 05:30:28PM +, Sam Kuper wrote:
> On 02/03/2018, Jeff King wrote:
> > Unfortunately, I don't think there's an easy way to do what you want
> > (show word-diffs but apply the full diff).
>
> Oh :(
>
> That would be a *very* useful feature to have, especially where
> mu
On Fri, Mar 02, 2018 at 09:15:44AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > That's probably a reasonable sanity check, but I think we need to abort
> > and not just have a too-small DISPLAY array. Because later code like the
> > hunk-splitting is going to assume that there's a 1:1
Sam Kuper writes:
> 1. It would yield, IIUC, less flexibility to create new kinds of view
> based on a consistent, standardised underlying model.
>
> 2. It is harder to read, for some types of input (e.g. prose) than the
> view generated by the existing word-diff algorithm.
The loss of line-end
On 02/03/2018, Junio C Hamano wrote:
> Jeff King writes:
>> Unfortunately, I don't think there's an easy way to do what you want
>> (show word-diffs but apply the full diff).
>
> The current "word-diff" discards the information on where the lines
> end, and it is pretty much hopeless/useless in t
Jeff King writes:
> Unfortunately, I don't think there's an easy way to do what you want
> (show word-diffs but apply the full diff).
The current "word-diff" discards the information on where the lines
end, and it is pretty much hopeless/useless in the context of "add
-p". It would be a good ad
On 02/03/2018, Jeff King wrote:
> Unfortunately, I don't think there's an easy way to do what you want
> (show word-diffs but apply the full diff).
Oh :(
That would be a *very* useful feature to have, especially where
multiple small (e.g. single character or single word) changes are
sprinkled th
On 02/03/2018, Jonathan Nieder wrote:
> Is this reproducible for you?
Yes. It seems to occur consistently, given the same input.
> Do you have more details about how I can reproduce it?
Unfortunately, the particular git repo I encountered it on is private,
otherwise I would point you to it.
I
Jeff King writes:
> That's probably a reasonable sanity check, but I think we need to abort
> and not just have a too-small DISPLAY array. Because later code like the
> hunk-splitting is going to assume that there's a 1:1 line
> correspondence. We definitely don't want to end up in a situation wh
On Fri, Mar 02, 2018 at 08:53:34AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Because the array is full of "undef". See parse_diff(), which does this:
> >
> > my @diff = run_cmd_pipe("git", @diff_cmd, "--", $path);
> > ...
> > @colored = run_cmd_pipe(@display_cmd);
> > ...
>
Jeff King writes:
> Because the array is full of "undef". See parse_diff(), which does this:
>
> my @diff = run_cmd_pipe("git", @diff_cmd, "--", $path);
> ...
> @colored = run_cmd_pipe(@display_cmd);
> ...
> for (my $i = 0; $i < @diff; $i++) {
> ...
> push @{$hunk[-1
On Thu, Mar 01, 2018 at 11:04:34PM -0800, Jonathan Nieder wrote:
> > Use of uninitialized value $_ in print at
> > /usr/lib/git-core/git-add--interactive line 1371, line 75.
> [...]
>
> Strange. The relevant line, for reference:
>
> $ dpkg-deb --fsys-tarfile git_2.11.0-3+deb9u2_amd64.deb |
>
On Fri, Mar 02, 2018 at 01:19:35AM +, Sam Kuper wrote:
> The bug is that in the midst of running
>
> git -c interactive.diffFilter="git diff --word-diff --color" add --patch
That's not how interactive.diffFilter is supposed to work.
It's meant to have the out
Hi,
Sam Kuper wrote:
> First, background. I encountered a bug on Debian Stretch, using this
> git version:
>
> $ git --version
> git version 2.11.0
>
> The bug is that in the midst of running
>
> git -c interactive.diffFilter="git diff --word-diff --color&q
First, background. I encountered a bug on Debian Stretch, using this
git version:
$ git --version
git version 2.11.0
The bug is that in the midst of running
git -c interactive.diffFilter="git diff --word-diff --color" add --patch
and after having answered "y" to some patch
b4906a7c "revision walker: Fix --boundary when limited". Here is an
>> excerpt:
>>
>> - After get_revision() finishes giving out all the positive
>>commits, if we are doing the boundary processing, we look at
>>the parents that we marked as p
On Tue, Feb 27, 2018 at 12:33:56AM +0100, Johannes Schindelin wrote:
> > So something like this helps:
> >
> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > index 81c5b42875..71e6cbb388 100644
> > --- a/git-rebase--interactive.sh
> > +++ b/git-rebase--interactive.sh
> >
l .. o’man , really, is this
> > intended?
>
> Yeah, the bug seems to be in --preserve-merges. Here's an easier
> reproduction:
>
> git init
> >one && git add one && git commit -m one
> git checkout --orphan other
> git mv one two &a
Hi all,
On Thu, 22 Feb 2018, Stefan Beller wrote:
> On Wed, Feb 21, 2018 at 9:22 PM, Jonathan Nieder wrote:
> > +git-for-windows
First of all, this is clearly not a Windows-specific problem, as the index
file *is* updated, and that is simply the same behavior as on Linux/macOS.
> > Raining Cha
On Fri, Feb 23, 2018 at 06:29:55AM +0100, "Marcel 'childNo͡.de' Trautwein"
wrote:
> shows me a quite different behavior, so solely rebase not seems the full
> problem
> BUT
> `--rebase=preserve` will .. o’man , really, is this intended?
Yeah, the bug seems to be
> Am 23.02.2018 um 00:20 schrieb Jonathan Nieder :
>
> Hi Marcel,
>
> …
> Sorry, this is not the most helpful reply but:
>
> Can you describe a reproduction recipe so that I can experience the
> same thing?
>
> That is:
>
> 1. steps to reproduce
> 2. expected result
> 3. actual result
> 4. the
Hi Marcel,
Marcel 'childNo͡.de' Trautwein" wrote:
> I think we have a problem … or at least I had
> and I’m not quite sure if this is „working as designed“
> but I’m sure it „should not work as it did“.
[...]
> I wanted to clone another repository … but yeah … it’s late for me today and
> I put
Hi,
I think we have a problem … or at least I had
and I’m not quite sure if this is „working as designed“
but I’m sure it „should not work as it did“.
Because? It pruned a lot of files and even the local repository.
by pull
by giving another repository URL instead of a known remote
While working
> On Feb 22, 2018, at 12:02 PM, Junio C Hamano wrote:
>
> I saw somewhere "Apple-Mail" and a phrase "repaste". So perhaps
> copy&paste on the client is involved in the whitespace damage (of
> course the original could be broken, but I somehow doubt it).
https://doriantaylor.com/file/well-ill-b
Jeff King writes:
> This indentation is funny. But I suspect it is because your whole patch
> seems to have been whitespace-damaged (see the section on gmail in
> "git help git-format-patch").
I saw somewhere "Apple-Mail" and a phrase "repaste". So perhaps
copy&paste on the client is involved i
d give them out.
The boundary commits are correctly sorted by topo-order among themselves
as of commit 4603ec0f960 "get_revision(): honor the topo_order flag for
boundary commits".
So, I'm not sure that this is a bug (it is working "as designed") but it
certainly is n
On Wed, Feb 21, 2018 at 9:22 PM, Jonathan Nieder wrote:
> +git-for-windows
> Hi,
>
> Raining Chain wrote:
>
>> On Windows 10, git version 2.16.2.windows.1, running the command
>>
>> git status
>>
>> will trigger a file change event to file C:\myPath\.git "Attributes
>> changed."
>>
>> This cause
On 02/21, Dorian Taylor wrote:
>
> > On Feb 21, 2018, at 9:37 PM, Jonathan Nieder wrote:
> >
> > Thanks for writing it.
> >
> > Do you mind if we forge your sign-off? (See Documentation/SubmittingPatches
> > item '(5) Certify your work' for details about what this means.)
>
> Sure, or I can j
> On Feb 22, 2018, at 2:08 AM, Jeff King wrote:
>
>
> This indentation is funny. But I suspect it is because your whole patch
> seems to have been whitespace-damaged (see the section on gmail in
> "git help git-format-patch").
That is, bit-for-bit, what came out of that submitGit thing that is
On Wed, Feb 21, 2018 at 11:23:52PM -0800, Dorian Taylor wrote:
> diff --git a/Documentation/technical/http-protocol.txt
> b/Documentation/technical/http-protocol.txt
> index a0e45f2889e6e..19d73f7efb338 100644
> --- a/Documentation/technical/http-protocol.txt
> +++ b/Documentation/technical/http-
> On Feb 21, 2018, at 9:37 PM, Jonathan Nieder wrote:
>
> Thanks for writing it.
>
> Do you mind if we forge your sign-off? (See Documentation/SubmittingPatches
> item '(5) Certify your work' for details about what this means.)
Sure, or I can just re-paste:
Signed-off-by: Dorian Taylor
---
(+cc: bmwill@, who is working on protocol v2)
Hi,
Dorian Taylor wrote:
> On Feb 21, 2018, at 2:15 PM, Jeff King wrote:
>> Thanks, I agree the document is buggy. Do you want to submit a patch?
>
> Will this do?
Thanks for writing it.
Do you mind if we forge your sign-off? (See Documentation/Su
+git-for-windows
Hi,
Raining Chain wrote:
> On Windows 10, git version 2.16.2.windows.1, running the command
>
> git status
>
> will trigger a file change event to file C:\myPath\.git "Attributes changed."
>
> This causes problems when using scripts that detect file changes such
> as tsc -w (Typ
On Windows 10, git version 2.16.2.windows.1, running the command
git status
will trigger a file change event to file C:\myPath\.git "Attributes changed."
This causes problems when using scripts that detect file changes such
as tsc -w (Typescript compiler) and using softwares that regularly
call
When using git log, boundary commits (ie, those commits added by
specifying --boundary) do not respect the order (e.g., --date-order,
--topo-order). Consider the following commit history, where number
indicates the order of the commit timestamps:
0125 <--A
\ \
TYPO IN EXPECTED OUTPUT.
To avoid inevitable confusion, creating new thread "Bug: git log:
boundary commits do not respect order (e.g. date-order, topo-order)
2".
DON'T REPLY TO THIS MESSAGE. Instead reply to the new message
On Wed, Feb 21, 2018 at 6:28 PM, Josh Tepper wrote:
&
> On Feb 21, 2018, at 2:15 PM, Jeff King wrote:
>
> Thanks, I agree the document is buggy. Do you want to submit a patch?
Will this do?
Note I am not sure what the story is behind that `version 1` element, whether
it's supposed to go before or after the null packet or if there should be
anot
When using git log, boundary commits (ie, those commits added by
specifying --boundary) do not respect the order (e.g., --date-order,
--topo-order). Consider the following commit history, where number
indicates the order of the commit timestamps:
0125 <--A
\ \
On Wed, Feb 21, 2018 at 10:29:35AM -0800, Dorian Taylor wrote:
> I didn’t get an insight until I ran with GIT_TRACE_PACKET=true on a
> known-good remote (i.e. GitHub), that the null packet-line `` has to
> follow the service line. This is not reflected in the example here:
>
> https://githu
Hello list,
I had been banging my head all morning trying to figure out why I couldn’t get
a little HTTP implementation to clone/push via the smart protocol (just
wrapping git-receive-pack/git-upload-pack). I kept getting the following
(likely familiar to some) error:
```
fatal: Could not read
st would be to prepare a minimal example of shell
> commands to reproduce the behavior you're trying to illustrate.)
Good point. Again, my bad - very long day debugging. I wanted to show where I
was in the directory so I sacrificed brevity for completeness and noise. My
apologies.
So, no bug, just a buggy user.
Cheers,
Randall
On Tue, Feb 20, 2018 at 3:36 PM, Randall S. Becker
wrote:
> I’m a bit confused about this, as I thought I understood worktrees :(.
>
> /home/randall/nsgit/test/test dir.mytest: rm -rf dest.wt
> /home/randall/nsgit/test/test dir.mytest/dest: git worktree prune -v
> Removing worktrees/dest.wt: gitdi
Im a bit confused about this, as I thought I understood worktrees :(.
/home/randall/nsgit/test/test dir.mytest/dest git worktree list
/home/randall/nsgit/test/test dir.mytest/dest: git worktree list
/home/randall/nsgit/test/test dir.mytest/dest 4e901ca [master]
/home/randall/nsgit/test/test d
System: Ubuntu 17.10 Gnome
When opening git-gui from a directory which is a repository, minimize
and maximize buttons are showing and functional in git-gui.
However, if I open git-gui in a non-repo directory, git-gui opens a
dialog where I can "Create New Repository", "Clone Existing
Repository",
This series fixes a small quoting problem in 511155db51 (remote-curl:
allow push options, 2017-03-22). The interesting one is the second
patch.
[1/2]: t5545: factor out http repository setup
[2/2]: remote-curl: unquote incoming push-options
remote-curl.c | 11 ++-
t/t5545-p
Jeff King writes:
> Here's the patch to make "show -B --stat" work. I'll give some more
> thought to whether this is a good idea and prepare a series.
>
> One downside is that in the common case it causes us to look up each
> object twice (once to get its size, and then again to load the content)
The title says it all.
If I run `git init --template=~/path/to/my/template` I get the following
message:
warning: templates not found ~/path/to/my/template
But, if I run:
$ env GIT_TEMPLATE_DIR=~/path/to/my/template git init
I don't get a warning and the template is used just f
ie.
>
> Agreed. While at there perhaps we need to improve this "unable to
> generate diffstat" message a bit too.
One reason the message is so vague is that we don't actually have any
kind of error code. Though really the only reason for xdiff to fail is
due to file size. So
On Thu, Feb 8, 2018 at 3:45 AM, Jeff King wrote:
> On Mon, Feb 05, 2018 at 08:59:52PM +0700, Duy Nguyen wrote:
>
>> On Mon, Feb 5, 2018 at 8:48 PM, Andreas Kalz wrote:
>> > Hello,
>> >
>> > I am using git frequently and usually it is running great.
>> >
>> > I read to write to this eMail address
On Fri, Feb 09 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>>> Will queue with the above typofix, together with the other one. I
>>> am not sure if we want to say "Before 2.17", though.
>>
>> I'm just keeping in mind the user who later on upgrades git from say
>> 2.14 to 2
Ævar Arnfjörð Bjarmason writes:
>> Will queue with the above typofix, together with the other one. I
>> am not sure if we want to say "Before 2.17", though.
>
> I'm just keeping in mind the user who later on upgrades git from say
> 2.14 to 2.18 or something, and is able to find in the docs when/
On Fri, Feb 09 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> +Before 2.17, the untracked cache had a bug where replacing a directory
>> +with a symlink to another directory could cause it to incorrectly show
>> +files tracked by git as untracked
Ævar Arnfjörð Bjarmason writes:
> +Before 2.17, the untracked cache had a bug where replacing a directory
> +with a symlink to another directory could cause it to incorrectly show
> +files tracked by git as untracked. See the "status: add a failing test
> +showing a core.u
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
Hello,
Git versions tested: 2.13.6, 2.1.4
When passing-in a large context value for the --unified option for
git-diff, Git will produce an invalid-looking range information for
hunks.
For example, if running 'git diff --unified=10 HEAD^', the output will
include (this is just a run against my lo
On Mon, Feb 5, 2018 at 1:45 PM, Junio C Hamano wrote:
> Given that all references to this shell function seem to do
>
> sometree=$(toptree_for_commit $something)
>
> and then $sometree is used as if it were a tree object name, I can
> understand why the lack of --no-show-signature in the o
On Mon, Feb 05, 2018 at 08:59:52PM +0700, Duy Nguyen wrote:
> On Mon, Feb 5, 2018 at 8:48 PM, Andreas Kalz wrote:
> > Hello,
> >
> > I am using git frequently and usually it is running great.
> >
> > I read to write to this eMail address regarding problems and possible bugs.
> > I am using git ve
On Wed, Feb 07, 2018 at 09:25:42AM -0800, Elijah Newren wrote:
> > So other_head_refs knows that it's looking at the worktrees. And it
> > passes the alternate ref-store to refs_head_ref(), with "add_one_ref" as
> > the callback. But the knowledge that we're not talking about the real
> > "HEAD" i
age
> that it also fails to do).
>
> I guess that's two more items on my todo list :)
Cool, if you're taking a look at those, I'll take a look at the other
one mentioned by Peff in this thread -- "make fsck pay attention to
other worktree HEADs" :-)
> Sorr
On Wed, Feb 7, 2018 at 8:29 AM, Birger Skogeng Pedersen
wrote:
> Steps to reproduce (on Ubuntu 17.10):
> - Open git-gui in a repository with two or more unstaged, changed files
> - Select two or more files in the "Unstaged Changes"
> - Click CTRL+T to stage the files that you have selected
> (Only
On Wed, Feb 7, 2018 at 5:21 AM, Jeff King wrote:
> On Tue, Feb 06, 2018 at 04:00:32PM -0800, Elijah Newren wrote:
>
>> It took me hours to figure it out, after users ran out of ideas and
>> came and asked me for help. (Maybe if I was familiar with worktree,
>> and knew they had been using it, the
Apologies if this is the wrong place to send a bug report for
Contributed software.
I've run into what seems like an issue/bug with git subtree.
I am trying to split a single directory of our repo into its own repo
using git subtree. I ran the the following command from our project
root
spected in my earlier mail),
then you successfully confirmed that we fixed a bug, and that you expected
the buggy behavior.
> - with change SHA.
>
> It seems to be bug in recent version.
>
> Should I provide additional information?
Ciao,
Johannes
> On 02/06/2018 12:47 PM, J
In git-gui, multiple files from the "Unstaged Changes" widget can be
selected. Once multiple files are selected, they can be staged by
clicking (toolbar) "Commit"->"Stage To Commit". All the files that
were selected then gets staged for the commit. The "Stage To Commit"
hotkey (CTRL+T) behaves like
On Wed, Feb 07, 2018 at 08:21:57AM -0500, Jeff King wrote:
> The best PSA for this particular bug may be "try pruning the worktrees":
>
> $ git worktree prune -v
> Removing worktrees/foo: gitdir file points to non-existent location
>
> $ git prune; echo
1001 - 1100 of 4624 matches
Mail list logo
