Hi list,
cc Pratyush,
[resend without attached png file]
While rebasing an old series, I had a 3-way merge fall back that didn't
show the `||| merged common ancestors` very well in git-gui.
That is, the conflict markers, and common ancestor lines, are treated as
being part of the current
Hello!
Not sure if I’m doing something wrong here, but it seems that when
calling “git checkout [--] ”, the last argument
is not interpreted correctly.
I have a repository that contains a multi-module Maven project, and as
such it contains several “pom.xml” files, one in the root directory
and a
On 2019-07-05 at 22:01:59, scott douglass wrote:
> Hi,
>
> I’d like to be able to discover the new parents-to-be SHA-1s during
> the hooks that run before a commit*. Essentially I’d like be able to
> distinguish the ‘git commit’ case from ‘git commit —amend’. Is there
> already a way to do this t
Hi,
I’d like to be able to discover the new parents-to-be SHA-1s during
the hooks that run before a commit*. Essentially I’d like be able to
distinguish the ‘git commit’ case from ‘git commit —amend’. Is there
already a way to do this that I have overlooked? (I’ve read ‘man
githooks’ and searched
Hi all
Interesting discussion.
Though it's a pretty distant memory now, this "forgot to commit"
scenario was really frequent for me when I started using git. Then I'd
run commit and forget that it's split (from an outsider's perspective)
into add and then commit. I like the design of git, trees,
Hi Junio,
On Thu, 9 May 2019, Junio C Hamano wrote:
> Git Gadget writes:
>
> > Forwarding this mail to the Git mailing list, as the original did not
> > make it there (for reasons unknown).
>
> It seems that the forwarding mechansim (if this weren't manual---I
> cannot tell) mangles whitespaces?
Git Gadget writes:
> Forwarding this mail to the Git mailing list, as the original did not
> make it there (for reasons unknown).
It seems that the forwarding mechansim (if this weren't manual---I
cannot tell) mangles whitespaces? No need to resend, as the
receiving end manually fixed them up.
Forwarding this mail to the Git mailing list, as the original did not
make it there (for reasons unknown).
-- Forwarded message -
From: Chris. Webster via GitGitGadget
Date: Wed, Oct 31, 2018 at 11:58 PM
Subject: [PATCH v2 1/1] diff-highlight: Use correct /dev/null for UNIX
and Wi
Sorry, I forgot to Cc, again.
-- Forwarded message -
From: ttjtftx
Date: Tue, Mar 12, 2019 at 12:32 AM
Subject: Re: [GSoC][PATCH] tests: avoid using pipes
To: Christian Couder
On Sun, Mar 10, 2019 at 11:05 PM Christian Couder
wrote:
>
> On Sun, Mar 10, 2019 at 9:28 AM ttjtftx
Sorry, I forgot to Cc.
-- Forwarded message -
From: ttjtftx
Date: Mon, Mar 11, 2019 at 11:43 PM
Subject: Re: [GSoC][PATCH v2 4/5] t0022-crlf-rename: avoid using pipes
To: Eric Sunshine
On Sun, Mar 10, 2019 at 6:03 PM Eric Sunshine wrote:
> All of the patches in this series ar
Пересылаемое сообщение
12.02.2019, 01:54, "Sergey Lukashev" :
Indeed. Sorry, this was how I thought it works.
So the hook runs even if the commit is cancelled. A bit odd.
Then let's have someone else from git list to answer your question.
12.02.2019, 01:11, "Fernando Chorne
Hi Team,
I've query for which we have no solutions from Stackoverflow. Or we
couldn't find one. Would be great if you have one or can provide
suggestions with.
SO Link:
https://stackoverflow.com/questions/53704320/git-merge-remote-repository-project-to-sub-directory-of-current-repository-proje
Adding a worktree from a working copy with submodules doesn't work.
In the config file I have
[submodule]
recurse = true
It that's not present, I don't find the problem.
# Preparation
$ git --version
git version 2.20.1
$ cd /tmp/
$ git init main_repo
Initialized empty Git reposito
Jeff King writes:
> On Thu, Jan 24, 2019 at 06:34:29PM +, Lucy Phipps wrote:
>
>> honestly i just like optimizing files. the test images still work but
>> one of them is half the size as before. i don't know if it needs to be
>> bigger. it doesn't make any actual difference
>
> I'm not sure i
On Thu, Jan 24, 2019 at 06:34:29PM +, Lucy Phipps wrote:
> honestly i just like optimizing files. the test images still work but
> one of them is half the size as before. i don't know if it needs to be
> bigger. it doesn't make any actual difference
I'm not sure if we actually see any benefit
honestly i just like optimizing files. the test images still work but
one of them is half the size as before. i don't know if it needs to be
bigger. it doesn't make any actual difference
On Thu, 24 Jan 2019, 18:11 Stefan Beller
> On Thu, Jan 24, 2019 at 10:08 AM Lucy Phipps wrote:
> >
> > Signed
A user over there at the git-users ML is having troubles with the
wording of the `git check-ignore` manual page which, in their opinion,
fails to clearly communicate the twist about tracked files being not
eligible for ignored/non-ignored checks:
- Forwarded message from cl.robitai...@gmail.co
On Fri, Jan 18, 2019 at 4:21 AM Duy Nguyen wrote:
>
> On Fri, Jan 18, 2019 at 9:28 AM Patrick Hogg wrote:
> >
> > ac77d0c37 ("pack-objects: shrink size field in struct object_entry",
> > 2018-04-14) added an extra usage of read_lock/read_unlock in the newly
> > introduced oe_get_size_slow for thr
I think I've got it now; maybe I just needed to sleep on it. It's
happier if I use the whole URL for trunk in the -T parameter.
I'll see how the rest of it plays out, but the `git svn show-ignore
--id=origin/trunk` command is working now.
On Wed, Nov 21, 2018 at 10:45 AM Jamie Jackson wrote:
>
>
By the way, my goal is to pull in trunk (only) at first, and possibly
pull in certain branches (later) on an as-needed basis. I'll need to
sync the Git repo with SVN for a while, until we permanently switch to
Git (and put SVN in read-only).
On Wed, Nov 21, 2018 at 10:38 AM Jamie Jackson wrote:
>
ICF2008571:eclipse-workspace jjackson$ git svn clone \
> -r 95115:HEAD https://mydomain.com/svn/HUD/onecpd \
> -T trunk \
> --no-metadata \
> -A ~/eclipse-workspace/scraps/git_migration/users.txt \
> hudx-git-migration
ICF2008571:eclipse-workspace jjackson$ cd hudx-git-migration/
ICF2008
On Wed, Nov 21, 2018 at 08:37:03AM -0500, Jamie Jackson wrote:
> I'm brand new to svn-git and I'm having a problem right out of the
> gate. I suspect I need a different ID, but I have no clue how to get
> it.
>
> Here's the failed attempt:
> https://gist.github.com/jamiejackson/57e90302802f4990b3
I'm brand new to svn-git and I'm having a problem right out of the
gate. I suspect I need a different ID, but I have no clue how to get
it.
Here's the failed attempt:
https://gist.github.com/jamiejackson/57e90302802f4990b36dfe28c3c71d13
What am I doing wrong?
Thanks,
Jamie
I have install the latest git version from the PPA:
$ git --version
git version 2.19.1
$ lsb_release -rd
Description: Ubuntu 16.04.5 LTS
Release: 16.04
However, trying to autocomplete git difftool --cached gives:
$ env -i bash --rcfile /etc/profile
$ . /usr/share/bash-completion/completions/git
$
Thanks everyone.
All your answers helped. I found out that the issue was not related to git.
I am using semantic-release to perform a release, apparently
git-credentials is not working with semantic-release.
I did also setup the double authentication and every fix applied on
git-credentials
On Thu, Oct 04, 2018 at 02:34:17AM +0700, Dimitri Kopriwa wrote:
> I have replaced the way I fill the git credentials store, I have verify
> ~/.git-credentials and information are there, the ~/.gitconfig look fine
> too.
>
> I still have 401 error when reading from that file.
>
> This is the pas
On Wed, Oct 3, 2018 at 12:34 PM Dimitri Kopriwa wrote:
>
> I have replaced the way I fill the git credentials store, I have verify
> ~/.git-credentials and information are there, the ~/.gitconfig look fine
> too.
>
> I still have 401 error when reading from that file.
>
> This is the paste log : h
I have replaced the way I fill the git credentials store, I have verify
~/.git-credentials and information are there, the ~/.gitconfig look fine
too.
I still have 401 error when reading from that file.
This is the paste log : https://paste.gnome.org/pmntlkdw0
Now that I use git approve, I don
On Thu, Oct 04, 2018 at 01:12:11AM +0700, Dimitri Kopriwa wrote:
> Thanks for your reply. I have activated GIT_TRACE_CURL=1 and I can see that
> the request is failing 401.
>
> I can't see which token is used and using what header ?
>
> The log say:
>
> 17:50:26.414654 http.c:657 =
Thanks for your reply. I have activated GIT_TRACE_CURL=1 and I can see
that the request is failing 401.
I can't see which token is used and using what header ?
The log say:
17:50:26.414654 http.c:657 => Send header: Authorization: Basic
I have retested the token locally and it
On Wed, Oct 03, 2018 at 09:06:38PM +0700, Dimitri Kopriwa wrote:
> 18:25:52.940307 git.c:659 trace: exec: git-credential-store
> erase
> 18:25:52.940365 run-command.c:637 trace: run_command:
> git-credential-store erase
> remote: HTTP Basic: Access denied
> fatal: Authenticat
Dear Git list,
I have tried to used git credentials within Gitlab-CI runners. I have 4
instance of GitLab and discovered a weird bug with Git credentials when
use within a CI process.
Please note before all that the time spend allowed me multiple time to
check that my credentials are valid
Hi Mikkel,
On Fri, Sep 14, 2018 at 02:31:04PM +0200, Mikkel Hofstedt Juul wrote:
> See title
> in sentence:
> ...invocations of git add, packing refs, pruning reflog, rerere
> metadata or stale working trees.
I think that 'rerere' in this case, is correct, since it refers
bookkeeping from the 'gi
retry -- plain text mode
-- Forwarded message -
From: Mikkel Hofstedt Juul
Date: Fri, 14 Sep 2018 at 14:28
Subject: spelling mistake 'rerere' on docs/git-gc
To:
Hi
See title
in sentence:
...invocations of git add, packing refs, pruning reflog, rerere
metadata or stale working
Works:
git show -C --find-copies-harder 055f6c89fa4506037d1621761f13430f469b8029
git show -C --find-copies-harder
055f6c89fa4506037d1621761f13430f469b8029 --name-status
Doesn’t Work:
git show -C --find-copies-harder
055f6c89fa4506037d1621761f13430f469b8029 -- PATH_TO_MY_COPIED_FILE
Thank you for taking the time to help me Stefan
On Aug 29, 2018 15:15, "Stefan Beller" wrote:
>
> On Wed, Aug 29, 2018 at 9:49 AM Tomas Zubiri wrote:
> >
> > Hello all,
> >
> > I have recently joined a team there seems to be a couple of issue
> > with the git repositories:
> >
> >
> > 1- A bra
Hi,
I am unable to use Git (version 2.18 latest). Since i couldnt find any
help/support/contact email on https://git-scm.com and i couldnt find the
solution using Google as well i am directly contacting you as i need to get
git working. Hope you can help me.
please find attached an image file reg
Just want to throw my support in for range-diff since ranges is what
you pass to the command.
Alternatively, diff-diff since that's how I've crudely tried to
accomplish this before.
git diff A..B > diff1
git diff C..D > diff2
winmerge diff1 diff2
mar., 27 mar. 2018, 02:07 Stefan Beller a scris:
>
> [snipped the cc list as well]
>
> On Tue, Mar 6, 2018 at 12:06 PM Eddy Petrișor
> wrote:
>
> > Signed-off-by: Eddy Petrișor
> > ---
>
> Did this go anywhere?
> (I just came back from a longer vacation, sorry for the delay on my site)
Not rea
On 3/26/2018 7:39 PM, Stefan Beller wrote:
coverity scan failed for the last couple month (since Nov 20th)
without me noticing, I plan on running it again nightly for the
Git project.
Anyway, here are issues that piled up (in origin/pu) since then.
Stefan
-- Forwarded message --
coverity scan failed for the last couple month (since Nov 20th)
without me noticing, I plan on running it again nightly for the
Git project.
Anyway, here are issues that piled up (in origin/pu) since then.
Stefan
-- Forwarded message --
From:
Date: Mon, Mar 26, 2018 at 4:24 PM
hello,
1.I wonder, why the "user-manual" is so hidden on the (official?) site
git-scm.com [it is accessible at git-scm.com/docs/user-manual ,but is
not viewable in /docs ]
2.I did not receive an answer to my mail. Maybe it could have to do with
a possible stopped maintainment of the 'user-manual
Elijah Newren writes:
> As currently implemented, yes. However, I was more concerned the idea
> of handling files differently based on whether or not they were
> similar, rather than on what the precise definition of "similar" is
> for this context.
>
> As far as the definition of similarity goe
[Re-sending because this computer happened to have plain-text mode
turned off for some weird reason, and thus the email bounced]
Hi,
On Mon, Mar 12, 2018 at 3:19 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> Does this mean that e.g. in this case of merging two files, one
> containing "foo" and one cont
-- Forwarded message --
From: "A. ALLIED"
Date: Fri, 19 Jan 2018 15:44:47 +
Subject:
To:
Hi.docx
Description: MS-Word 2007 document
Hi Matwey,
On Mon, 1 Jan 2018, Matwey V. Kornilov wrote:
> Hello,
>
> I am running git 2.15.1 and facing the following issue with linux kernel
> tree.
>
> # git checkout v3.8
> # git branch abc-3.8
> # git checkout v3.9
> # git branch abc-3.9
> # git checkout abc-3.8
>
> Introduce new commit o
2018-01-04 21:57 GMT+03:00 Junio C Hamano :
> "Matwey V. Kornilov" writes:
>
>> It seems there is some issue with double escaping:
>> ...
>>> # git rebase --preserve-merges -s recursive -Xdiff-algorithm=patience
>>> --onto abc-3.8 v3.8 abc-3.9
>>>
>>> And then I see:
>>>
>>> fatal: Unknown option
"Matwey V. Kornilov" writes:
> It seems there is some issue with double escaping:
> ...
>> # git rebase --preserve-merges -s recursive -Xdiff-algorithm=patience
>> --onto abc-3.8 v3.8 abc-3.9
>>
>> And then I see:
>>
>> fatal: Unknown option for merge-recursive: -X'diff-algorithm=patience'
The
Hi,
It seems there is some issue with double escaping:
14:57:18.524010 git.c:344 trace: built-in: git 'merge'
'--no-log' '--no-ff' '--strategy=recursive' '-X' ''\''diff-algorithm=p
atience'\''' '-m' 'Merge branch '\''core-rcu-for-linus'\'' of
git://git.kernel.org/pub/scm/linux/kern
Hello,
I am running git 2.15.1 and facing the following issue with linux kernel
tree.
# git checkout v3.8
# git branch abc-3.8
# git checkout v3.9
# git branch abc-3.9
# git checkout abc-3.8
Introduce new commit on top of abc-3.8. Here, I edit README.
# vim README
# git commit -a -v
[abc-3.8 4b
Weird, it was not working for me earlier today, but now it works.
Thank you,
Gilberto
On Tue, Oct 17, 2017 at 5:57 PM, Junio C Hamano wrote:
> Gilberto Stankiewicz writes:
>
>> I am trying to clone git://repo.or.cz/git-gui.git as described at
>> https://github.com/git/git/blob/master/Documenta
Gilberto Stankiewicz writes:
> I am trying to clone git://repo.or.cz/git-gui.git as described at
> https://github.com/git/git/blob/master/Documentation/SubmittingPatches
> but it seems the repo does not exist.
$ git fetch -v git-gui
Looking up repo.or.cz ... done.
Connecting to repo.or.cz (port
Hello,
I am trying to clone git://repo.or.cz/git-gui.git as described at
https://github.com/git/git/blob/master/Documentation/SubmittingPatches
but it seems the repo does not exist.
Has the repo changed from location?
Thank you,
Gilberto
On 10/12, 小川恭史 wrote:
> Hello, I found a mistake in documents, fixed it, and send patch to mailing
> list.
>
> Sending patches by 'git send-email' with Gmail smtp seemed to be
> successful because CC included my email address and I received it.
> However, I never received email from mailing list.
On Thu, 12 Oct 2017 04:14:18 +0900
小川恭史 wrote:
> Hello, I found a mistake in documents, fixed it, and send patch to mailing
> list.
>
> Sending patches by 'git send-email' with Gmail smtp seemed to be
> successful because CC included my email address and I received it.
> However, I never receiv
Hello, I found a mistake in documents, fixed it, and send patch to mailing list.
Sending patches by 'git send-email' with Gmail smtp seemed to be
successful because CC included my email address and I received it.
However, I never received email from mailing list. Of course I'm
subscribing mailing
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
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 tool limited to be used on
projects
I.e. "Squash 'somedir' changes" and not "Squashed ..."
See
https://github.com/git/git/blob/master/contrib/subtree/git-subtree.sh#L463
Jeff King writes:
> On Wed, Jul 26, 2017 at 05:49:47PM -0700, Junio C Hamano wrote:
>
>> What I saw was that a test have ended up with .git/%46%4F%4F when it
>> was told to create a ref "FOO" (which indicates that "FOO" was
>> passed to the files backend), which later failed to read it back
>> be
On Wed, Jul 26, 2017 at 05:49:47PM -0700, Junio C Hamano wrote:
> Michael Haggerty writes:
>
> > I think the most natural thing would be to use different encoding
> > rules for pseudo-refs (references like "HEAD" and "FETCH_HEAD") and
> > for other references (those starting with "refs/").
> >
>
Heh, then I'll forward my response and we are even ;-)
-- Forwarded message --
From: Junio C Hamano
Date: Mon, Jul 10, 2017 at 10:48 AM
Subject: Re: Should "head" also work for "HEAD" on case-insensitive FS?
To: Michael Haggerty
Michael Haggerty writes:
> I think the most na
Dang, I just noticed that I hit "reply" rather than "reply-to-all" on
the below email (stupid GMail default). Junio, your response to this
email accordingly went only to me.
Michael
-- Forwarded message --
From: Michael Haggerty
Date: Mon, Jul 10, 2017 at 7:52 AM
Subject: Re: Sho
René Scharfe writes:
> We could remove that NULL check -- it's effectively just a shortcut.
> But how would that improve safety? Well, if the array is unallocated
> (NULL) and _num is greater than zero we'd get a segfault without it,
> and thus would notice it. That check currently papers over
Am 18.07.2017 um 19:23 schrieb Junio C Hamano:
> Stefan Beller writes:
>
>> I looked at this report for a while. My current understanding:
>> * its detection was triggered by including rs/move-array,
>>f331ab9d4c (use MOVE_ARRAY, 2017-07-15)
>> * But it is harmless, because the scan logic doe
On Tue, Jul 18, 2017 at 11:00 AM, Brandon Williams wrote:
> On 07/18, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>> >> I'd be more worried about segfault we seem to be getting only on
>> >> Windows from this:
>> >>
>> >> git -C parent grep -e "(1|2)d(3|4)" --recurse-submodules HEAD^ >
On 07/18, Junio C Hamano wrote:
> Stefan Beller writes:
>
> >> I'd be more worried about segfault we seem to be getting only on
> >> Windows from this:
> >>
> >> git -C parent grep -e "(1|2)d(3|4)" --recurse-submodules HEAD^ > actual
> >>
> >> in https://travis-ci.org/git/git/jobs/254654195 b
Stefan Beller writes:
>> I'd be more worried about segfault we seem to be getting only on
>> Windows from this:
>>
>> git -C parent grep -e "(1|2)d(3|4)" --recurse-submodules HEAD^ > actual
>>
>> in https://travis-ci.org/git/git/jobs/254654195 by the way.
>
> Thanks for bringing that to my at
On Tue, Jul 18, 2017 at 10:23 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> I looked at this report for a while. My current understanding:
>> * its detection was triggered by including rs/move-array,
>> f331ab9d4c (use MOVE_ARRAY, 2017-07-15)
>> * But it is harmless, because the scan l
Stefan Beller writes:
> I looked at this report for a while. My current understanding:
> * its detection was triggered by including rs/move-array,
> f331ab9d4c (use MOVE_ARRAY, 2017-07-15)
> * But it is harmless, because the scan logic does not understand
> how ALLOC_GROW works. It assumes th
I looked at this report for a while. My current understanding:
* its detection was triggered by including rs/move-array,
f331ab9d4c (use MOVE_ARRAY, 2017-07-15)
* But it is harmless, because the scan logic does not understand
how ALLOC_GROW works. It assumes that
done_pbase_paths_alloc can be
(Sorry I sent this originally last night in gmail but not in plain
text mode and it bounced)
Hi Michael,
In git if you don't merge often then you get these merge conflict hell
situations.
In my experience the main conflicts come not from the unified diff of
those 130 commits but from difference
2017-06-04 14:09 GMT+03:00 Luke Diamand :
>
> On 4 June 2017 at 10:56, Андрей Ефанов <1134t...@gmail.com> wrote:
> > Hello,
> >
> > My goal is to sync the repository from p4 using an interval of
> > changelists so that the first changelist version of the repository
> > would be considered as an ini
On 2017-04-18 21:12, Stefan Beller wrote:
Wouldn't it make more sense to unshallow the submodule clone in this case and
checkout the configured commit 2aa4cce7d7fd46164030f2b4d244c4b89e77f722
afterwards?
If I remember correctly the conclusion of the discussion at the time
was that people are
On Tue, Apr 18, 2017 at 6:04 AM, Sebastian Schuberth
wrote:
> Hi,
>
> this is using "git version 2.12.2.windows.2" on Windows / "git version
> 2.12.2-639-g584f897" on Linux.
>
> I have configured my superproject with .gitmodules saying
>
> ---8<---
> [submodule "src/funTest/resources/projects/ext
I have a similar one
bash-4.4$ gitk
2017-04-15 13:09:52.514 Wish[3344:197352] *** Terminating app due to uncaught
exception 'CALayerInvalidGeometry', reason: 'CALayer position contains NaN:
[nan 0]'
*** First throw call stack:
(
0 CoreFoundation 0x7fffd119048b
Running gitk from the command line, while at the top level of a Git
working directory, produces the following error message, and gitk
fails to open:
> objc[1031]: Objective-C garbage collection is no longer supported.
> /usr/local/bin/wish: line 2: 1031 Abort trap: 6 "$(dirname
> $0)/
On Mon, Mar 06, 2017 at 09:38:33AM -0600, Christian7573 wrote:
> Is there a way for git to push to a server using the dumb protocol?
> Perhaps using the PUT method to upload files?
> Just wondering cause I just set up a dumb server and pushing to it
> doesn't work.
Git dumb-http push protocol goe
Is there a way for git to push to a server using the dumb protocol?
Perhaps using the PUT method to upload files?
Just wondering cause I just set up a dumb server and pushing to it
doesn't work. If that isn't an option, where can I get a smart server?
Forwarding a message that ended on my end only, probably by accident.
Forwarded Message
Subject: Re: feature request: user email config per domain
Date: Thu, 23 Feb 2017 13:32:56 +0530
From: Tushar Kapila
To: Igor Djordjevic BugA
Hello All,
> I'd much rather see something base
On Tue, Feb 21, 2017 at 04:52:11PM -0800, Casey Rodarmor wrote:
> Hi there,
>
> The git worktree man page mentions the `--detached` flag in the
> section on `add`, but the flag is actually called `--detach`.
Thanks for reporting this. I'll send a patch.
--
brian m. carlson / brian with sandals:
Hi there,
The git worktree man page mentions the `--detached` flag in the
section on `add`, but the flag is actually called `--detach`.
Best,
Casey
On Thu, Feb 9, 2017 at 4:11 AM, Junio C Hamano wrote:
> With or without the patch in this thread, parse_pathspec() behaves
> the same way for either CWD or FULL if you feed a non-empty
> pathspec with at least one positive element. IOW, if a caller feeds
> a non-empty pathspec and there is no "ne
On Thu, Feb 9, 2017 at 12:39 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Wed, Feb 8, 2017 at 12:12 PM, Linus Torvalds
>> wrote:
>>> Two-patch series to follow.
>>
>> glossary-content.txt update for both patches would be nice.
>
> I am no longer worried about it as I saw somebody actua
Junio C Hamano writes:
> If you know offhand which callers pass neither of the two
> PATHSPEC_PREFER_* bits and remember for what purpose you allowed
> them to do so, please remind me. I'll keep digging in the meantime.
Answering my own questions, here are my findings so far and a
tentative con
Duy Nguyen writes:
> On Wed, Feb 8, 2017 at 12:12 PM, Linus Torvalds
> wrote:
>> Two-patch series to follow.
>
> glossary-content.txt update for both patches would be nice.
I am no longer worried about it as I saw somebody actually sent
follow-up patches on this, but I want to pick your brain o
On Wed, Feb 8, 2017 at 12:12 PM, Linus Torvalds
wrote:
> Two-patch series to follow.
glossary-content.txt update for both patches would be nice.
--
Duy
On Tue, 7 Feb 2017, Junio C Hamano wrote:
> > + // Special case alias for '!'
>
> /* style? */
Will fix.
> I somehow do not think this is correct. I expect
>
> cd t && git grep -e foo -- :^perf/
>
> to look into things in 't' except for things in 't/perf', but the
> above wi
Linus Torvalds writes:
> People don't expect set theory from their pathspecs. They expect their
> pathspecs to limit the output. They've learnt that within a
> subdirectory, the pathspec limits to that subdirectory. And now it
> suddenly starts showing things outside the subdirectory?
>
> At that
On Tue, Feb 7, 2017 at 7:12 PM, Junio C Hamano wrote:
>
> But that is not what I was talking about. Let's simplify. I'd say
> for any command that acts on "everything" when pathspec is not
> given, the two sets of actual paths affected by these two:
>
> git cmd -- "net/"
> git cm
Linus Torvalds writes:
> No. The thing is, "git diff" is relative too - for path
> specifications. And the negative entries are pathspecs - and they act
> as relative ones.
>
> IOW, that whole
>
> cd drivers
> git diff A..B -- net/
>
> will actually show the diff for drivers/net - so the path
On Tue, Feb 07, 2017 at 05:48:26PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 7 Feb 2017, Linus Torvalds wrote:
> >
> > [ Clarification from original message, since Junio asked: I didn't
> > actually want the semantics of '.' at all, since in a subdirectory it
> > limits to the current subdi
On Tue, Feb 07, 2017 at 06:49:24PM -0800, Linus Torvalds wrote:
> On Tue, Feb 7, 2017 at 6:40 PM, Mike Hommey wrote:
> >
> > As such, the default positive match should be ':/' (which is shorter and
> > less cumbersome than ':(top)', btw)
>
> So that's what my patch does.
>
> However, it's actual
On Tue, Feb 7, 2017 at 6:42 PM, Junio C Hamano wrote:
>
> 1. I think some commands limit their operands to cwd and some work
> on the whole tree when given no pathspec. I think the "no
> positive? then let's give you everything except these you
> excluded" should base the definition
On Tue, Feb 7, 2017 at 6:40 PM, Mike Hommey wrote:
>
> As such, the default positive match should be ':/' (which is shorter and
> less cumbersome than ':(top)', btw)
So that's what my patch does.
However, it's actually very counter-intuitive in a subdirectory.
Git doesn't do much of that, but l
Linus Torvalds writes:
> So here's an RFC patch, and I'm quoting the above part of my thinking
> because it's what the patch does, but it turns out that it's probably not
> what we want, and I suspect the "." behavior (as opposed to "no filtering
> at all") is actually better.
> ...
>
> Commen
On Tue, 7 Feb 2017, Linus Torvalds wrote:
>
> [ Clarification from original message, since Junio asked: I didn't
> actually want the semantics of '.' at all, since in a subdirectory it
> limits to the current subdirectory. So I'd suggest that in the absence
> of any positive pattern, there
Linus Torvalds writes:
> [ Duh, I sent this just to Junio initially due to a brainfart. Here
> goes the list also ]
And my earlier response goes to the list ;-)
Linus Torvalds writes:
> Most of the time when I use pathspecs, I just use the bog-standard
> normal ones, and everything works wond
[ Duh, I sent this just to Junio initially due to a brainfart. Here
goes the list also ]
Most of the time when I use pathspecs, I just use the bog-standard
normal ones, and everything works wonderfully.
But then occasionally I want to exclude a directory (usually
"drivers/"), and it all works fin
Looks good to me! Thanks for writing the documentation. I really
need to be better about getting documentation done at the same time
I'm adding features :)
-Brandon
On Wed, Feb 1, 2017 at 3:16 PM, Junio C Hamano wrote:
>
> cornelius.w...@tngtech.com writes:
>
> > From: Cornelius Weig
> >
> >
1 - 100 of 367 matches
Mail list logo
