Re: Fwd: "show-ignore" problem after svn-git clone

2018-11-21 Thread Jamie Jackson 
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/
> >
> > ICF2008571:hudx-git-migration jjackson$ git svn show-ignore
> > fatal: bad revision 'HEAD'
> > rev-list --first-parent --pretty=medium HEAD --: command returned error: 128
> >
> > ICF2008571:hudx-git-migration jjackson$ git svn show-ignore 
> > --id=origin/trunk
> > fatal: bad revision 'HEAD'
> > rev-list --first-parent --pretty=medium HEAD --: command returned error: 128
> >
> > ICF2008571:hudx-git-migration jjackson$ cat .git/config
> > [core]
> > repositoryformatversion = 0
> > filemode = true
> > bare = false
> > logallrefupdates = true
> > ignorecase = true
> > precomposeunicode = true
> > [svn-remote "svn"]
> > noMetadata = 1
> > url = https://mydomain.com/svn/HUD
> > fetch = onecpd/trunk:refs/remotes/origin/trunk
> > [svn]
> > authorsfile = 
> > /Users/jjackson/eclipse-workspace/scraps/git_migration/users.txt
> >
> > On Wed, Nov 21, 2018 at 9:44 AM Konstantin Khomoutov  
> > wrote:
> > >
> > > 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/57e90302802f4990b36dfe28c3c71d13
> > >
> > > Please post the content supposedly available at that link in your mail
> > > message, inline.  Otherwise it's impossibly to sensibly comment on it.
> > >

Re: Fwd: "show-ignore" problem after svn-git clone

2018-11-21 Thread Jamie Jackson 
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/
>
> ICF2008571:hudx-git-migration jjackson$ git svn show-ignore
> fatal: bad revision 'HEAD'
> rev-list --first-parent --pretty=medium HEAD --: command returned error: 128
>
> ICF2008571:hudx-git-migration jjackson$ git svn show-ignore --id=origin/trunk
> fatal: bad revision 'HEAD'
> rev-list --first-parent --pretty=medium HEAD --: command returned error: 128
>
> ICF2008571:hudx-git-migration jjackson$ cat .git/config
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> ignorecase = true
> precomposeunicode = true
> [svn-remote "svn"]
> noMetadata = 1
> url = https://mydomain.com/svn/HUD
> fetch = onecpd/trunk:refs/remotes/origin/trunk
> [svn]
> authorsfile = /Users/jjackson/eclipse-workspace/scraps/git_migration/users.txt
>
> On Wed, Nov 21, 2018 at 9:44 AM Konstantin Khomoutov  wrote:
> >
> > 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/57e90302802f4990b36dfe28c3c71d13
> >
> > Please post the content supposedly available at that link in your mail
> > message, inline.  Otherwise it's impossibly to sensibly comment on it.
> >

Re: Fwd: "show-ignore" problem after svn-git clone

2018-11-21 Thread Jamie Jackson 
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/

ICF2008571:hudx-git-migration jjackson$ git svn show-ignore
fatal: bad revision 'HEAD'
rev-list --first-parent --pretty=medium HEAD --: command returned error: 128

ICF2008571:hudx-git-migration jjackson$ git svn show-ignore --id=origin/trunk
fatal: bad revision 'HEAD'
rev-list --first-parent --pretty=medium HEAD --: command returned error: 128

ICF2008571:hudx-git-migration jjackson$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[svn-remote "svn"]
noMetadata = 1
url = https://mydomain.com/svn/HUD
fetch = onecpd/trunk:refs/remotes/origin/trunk
[svn]
authorsfile = /Users/jjackson/eclipse-workspace/scraps/git_migration/users.txt

On Wed, Nov 21, 2018 at 9:44 AM Konstantin Khomoutov  wrote:
>
> 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/57e90302802f4990b36dfe28c3c71d13
>
> Please post the content supposedly available at that link in your mail
> message, inline.  Otherwise it's impossibly to sensibly comment on it.
>

Re: Fwd: "show-ignore" problem after svn-git clone

2018-11-21 Thread Konstantin Khomoutov 
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/57e90302802f4990b36dfe28c3c71d13

Please post the content supposedly available at that link in your mail
message, inline.  Otherwise it's impossibly to sensibly comment on it.

Fwd: "show-ignore" problem after svn-git clone

2018-11-21 Thread Jamie Jackson 
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

Fwd: git difftool does not give the --cached option

2018-10-09 Thread Ντέντος Σταύρος 
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
$ git difftool --
--dir-diff  --extcmd=   --gui   --no-...
 --no-prompt --symlinks  --tool-help
--tool= --trust-exit-code

Please direct me on what would require more attention.
/usr/share/bash-completion/completions/git is the same as the
git@master/contrib/completion/git-completion.bash and e.g. here:
https://github.com/git/git/commit/6cc4bc15f92e85b41d9da9075905f20c6a9008fe#diff-f37c4f4a898819f0ca4b5ff69e81d4d9

It seems that --cached exists.

(Side question: What is the "--no-..." option shown? I cannot seem to
find it anywhere in the documentation :/)

Ntentos Stavros

Re: Fwd: Git credentials not working

2018-10-03 Thread Dimitri Kopriwa 

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 were simply useless.


Read more here : 
https://github.com/semantic-release/semantic-release/issues/941#issuecomment-426691824


Thanks a lot for your help and git is the best software ever made thanks!

Dimitri Kopriwa


On 10/4/18 3:43 AM, Jeff King wrote:

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 paste log : https://paste.gnome.org/pmntlkdw0

Now that I use git approve, I dont think that I need a custom helper.

Any idea why I still can't log in using git-credential?

Looking at your pastebin, it looks like the server sometimes takes it
and sometimes not. E.g., piping the log through:

   egrep '(Send|Recv) header:' |
   perl -lpe 's/^.*?(=>|<=) //'

I see:

   Send header: GET 
/example-keys/sample-project.git/info/refs?service=git-upload-pack HTTP/1.1
   Send header: User-Agent: git/2.19.0
   ...
   Recv header: HTTP/1.1 401 Unauthorized
   Recv header: WWW-Authenticate: Basic realm="GitLab"
   ...
   Send header: GET 
/example-keys/sample-project.git/info/refs?service=git-upload-pack HTTP/1.1
   Send header: Authorization: Basic 
   Send header: User-Agent: git/2.19.0
   ...
   Recv header: HTTP/1.1 200 OK

So that works. But then later we get:

   Send header: GET 
/example-keys/sample-project.git/info/refs?service=git-upload-pack HTTP/1.1
   Send header: User-Agent: git/2.19.0
   ...
   Recv header: HTTP/1.1 401 Unauthorized
   Recv header: WWW-Authenticate: Basic realm="GitLab"
   ...
   Send header: GET 
/example-keys/sample-project.git/info/refs?service=git-upload-pack HTTP/1.1
   Send header: Authorization: Basic 
   Send header: User-Agent: git/2.19.0
   ...
   Recv header: HTTP/1.1 401 Unauthorized

And then that causes credential-store to delete the non-working entry,
after which all of them must fail (because you have no working
credential, and presumably no terminal to prompt the user).

I have no idea why the same request would sometimes be allowed and
sometimes not. It's possible the  data is different in those
two times, but I don't know why that would be. It's also possible you're
hitting different load-balancing servers that behave differently.

-Peff

Re: Fwd: Git credentials not working

2018-10-03 Thread Jeff King 
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 paste log : https://paste.gnome.org/pmntlkdw0
> 
> Now that I use git approve, I dont think that I need a custom helper.
> 
> Any idea why I still can't log in using git-credential?

Looking at your pastebin, it looks like the server sometimes takes it
and sometimes not. E.g., piping the log through:

  egrep '(Send|Recv) header:' |
  perl -lpe 's/^.*?(=>|<=) //'

I see:

  Send header: GET 
/example-keys/sample-project.git/info/refs?service=git-upload-pack HTTP/1.1
  Send header: User-Agent: git/2.19.0
  ...
  Recv header: HTTP/1.1 401 Unauthorized
  Recv header: WWW-Authenticate: Basic realm="GitLab"
  ...
  Send header: GET 
/example-keys/sample-project.git/info/refs?service=git-upload-pack HTTP/1.1
  Send header: Authorization: Basic 
  Send header: User-Agent: git/2.19.0
  ...
  Recv header: HTTP/1.1 200 OK

So that works. But then later we get:

  Send header: GET 
/example-keys/sample-project.git/info/refs?service=git-upload-pack HTTP/1.1
  Send header: User-Agent: git/2.19.0
  ...
  Recv header: HTTP/1.1 401 Unauthorized
  Recv header: WWW-Authenticate: Basic realm="GitLab"
  ...
  Send header: GET 
/example-keys/sample-project.git/info/refs?service=git-upload-pack HTTP/1.1
  Send header: Authorization: Basic 
  Send header: User-Agent: git/2.19.0
  ...
  Recv header: HTTP/1.1 401 Unauthorized

And then that causes credential-store to delete the non-working entry,
after which all of them must fail (because you have no working
credential, and presumably no terminal to prompt the user).

I have no idea why the same request would sometimes be allowed and
sometimes not. It's possible the  data is different in those
two times, but I don't know why that would be. It's also possible you're
hitting different load-balancing servers that behave differently.

-Peff

Re: Fwd: Git credentials not working

2018-10-03 Thread Bryan Turner 
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 : https://paste.gnome.org/pmntlkdw0
>
> Now that I use git approve, I dont think that I need a custom helper.
>
> Any idea why I still can't log in using git-credential?

I'm pretty sure Peff touched on this in his reply. When it works,
you're either sending a "Private-Token" header or including it in the
URL, but, as Peff said, Git will never do either of those things. It
sends an "Authorization" header, and, based on their documentation, it
doesn't appear Gitlab accepts access tokens in that header.

It looks like you're either going to need to include it in the URL
(like what happens earlier in the posted trace), or adjust your git
config with a "http.extraHeader" set to "Private-Token: " to
include the "Private-Token" header (or you could pass it on the
command line, like `git -c http.extraHeader="Private-Token: "
clone ...`.

Hope this helps!
Bryan

>
> Thanks in advance,
>
> On 10/4/18 1:24 AM, Jeff King wrote:
> > 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  => Send header: Authorization: 
> >> Basic 
> > Yeah, we redact the auth information so people don't accidentally share
> > it publicly. If you use the older GIT_CURL_VERBOSE=1, it will include
> > the credential (I think it may be base64 encoded, though, so you'll have
> > to decipher it).
> >
> >> I have retested the token locally and it work when used in the url or using
> >> `Private-Token: ` as stated in the Gitlab documentation
> >> https://docs.gitlab.com/ee/api/README.html#personal-access-tokens
> > I don't think Git will ever send your token in either of those ways. It
> > will always some as an Authorization header.
> >
> >> Peff, what would be the appropriate way to input my git credential in a 
> >> 100%
> >> success way in a CI?
> > I don't know the details of what GitLab would want, but...
> >
> >> Is this good:
> >>
> >> git credential approve < >> protocol=https
> >> host=example.com
> >> username=bob
> >> password=secr3t
> >> OEF
> > Yes, that would work to preload a token into any configured helpers.
> >
> > -Peff

Re: Fwd: Git credentials not working

2018-10-03 Thread Dimitri Kopriwa 
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 dont think that I need a custom helper.

Any idea why I still can't log in using git-credential?

Thanks in advance,

On 10/4/18 1:24 AM, Jeff King wrote:

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  => Send header: Authorization: Basic 


Yeah, we redact the auth information so people don't accidentally share
it publicly. If you use the older GIT_CURL_VERBOSE=1, it will include
the credential (I think it may be base64 encoded, though, so you'll have
to decipher it).


I have retested the token locally and it work when used in the url or using
`Private-Token: ` as stated in the Gitlab documentation
https://docs.gitlab.com/ee/api/README.html#personal-access-tokens

I don't think Git will ever send your token in either of those ways. It
will always some as an Authorization header.


Peff, what would be the appropriate way to input my git credential in a 100%
success way in a CI?

I don't know the details of what GitLab would want, but...


Is this good:

git credential approve <
Yes, that would work to preload a token into any configured helpers.

-Peff

Re: Fwd: Git credentials not working

2018-10-03 Thread Jeff King 
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  => Send header: Authorization: Basic 
> 

Yeah, we redact the auth information so people don't accidentally share
it publicly. If you use the older GIT_CURL_VERBOSE=1, it will include
the credential (I think it may be base64 encoded, though, so you'll have
to decipher it).

> I have retested the token locally and it work when used in the url or using
> `Private-Token: ` as stated in the Gitlab documentation
> https://docs.gitlab.com/ee/api/README.html#personal-access-tokens

I don't think Git will ever send your token in either of those ways. It
will always some as an Authorization header.

> Peff, what would be the appropriate way to input my git credential in a 100%
> success way in a CI?

I don't know the details of what GitLab would want, but...

> Is this good:
> 
> git credential approve < protocol=https
> host=example.com
> username=bob
> password=secr3t
> OEF

Yes, that would work to preload a token into any configured helpers.

-Peff

Re: Fwd: Git credentials not working

2018-10-03 Thread Dimitri Kopriwa 
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 work when used in the url or 
using `Private-Token: ` as stated in the Gitlab documentation 
https://docs.gitlab.com/ee/api/README.html#personal-access-tokens


Peff, what would be the appropriate way to input my git credential in a 
100% success way in a CI?


Is this good:

git credential approve

Re: Fwd: Git credentials not working

2018-10-03 Thread Jeff King 
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: Authentication failed for
> 'https://git.example.com/example/some-project.git/'
> [...]
> 
> Can you please help me found why is git credential-store erase called ?

This is expected. We tried to use a credential that was rejected by the
server, so we told all of the helpers it was invalid. You can try
running GIT_TRACE_CURL=1 to see the HTTP conversation. There will be an
HTTP 401 with the authentication failure, though it may not tell you
anything more useful than that.

git-credential-store is meant to be used interactively, to insert and
erase credentials as they're grabbed from the terminal.

It sounds more like you want to just have a stored credential that you
try to use. You could do that with a custom helper. E.g., something like
this in your ~/.gitconfig:

  [credential "https://example.com;]
  helper = "!f() { test $1 = get && echo password=$(cat /path/with/password); 
}; f"

-Peff

Fwd: Git credentials not working

2018-10-03 Thread Dimitri Kopriwa 

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 for the repository. And calling git 
fetch --tags with the full remote url that include the credentials 
always succeeded.


Tested with Git 2.11, 2.19

Git credentials in ~/.git-credentials and ~/.config/git/credentials are 
being removed by git upon reading.


This happen randomly accross my CI runner, and change that make them 
work on not related.



{ Error: Command failed: git fetch --tags 
https://git.example.com/example/some-project.git
18:25:52.554903 git.c:415   trace: built-in: git fetch 
--tags https://git.example.com/example/some-project.git
18:25:52.555234 run-command.c:637   trace: run_command: GIT_DIR=.git 
git-remote-https https://git.example.com/example/some-project.git 
https://git.example.com/example/some-project.git
18:25:52.692741 run-command.c:637   trace: run_command: 'git 
credential-store get'
18:25:52.697314 git.c:659   trace: exec: 
git-credential-store get
18:25:52.697372 run-command.c:637   trace: run_command: 
git-credential-store get
18:25:52.936024 run-command.c:637   trace: run_command: 'git 
credential-store erase'
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: Authentication failed for 
'https://git.example.com/example/some-project.git/'



See the full question here: 
https://stackoverflow.com/questions/52614467/why-does-git-credential-store-call-git-credential-erase-and-make-my-credential-f



Can you please help me found why is git credential-store erase called ?


Best regards,

Re: Fwd: spelling mistake 'rerere' on docs/git-gc

2018-09-14 Thread Taylor Blau 
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 'git rerere' command [1], which "reuse[s] recorded
resolution[s] of conflict meregs".

Thanks,
Taylor


[1]: https://git-scm.com/docs/git-rerere

Fwd: spelling mistake 'rerere' on docs/git-gc

2018-09-14 Thread Mikkel Hofstedt Juul 
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 trees.

Thanks, keep up the good work!

regards
Mikkel

Fwd: [Possible GIT Bug]

2018-09-09 Thread Dylan Young 
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



i.e.

--- /dev/null

+++ b/ PATH_TO_MY_COPIED_FILE





Hope that’s self-explanatory!!!



Best,





Casey Meijer

Fwd: Git Unrelated Histories

2018-08-29 Thread Tomas Zubiri 
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 branch created from development cannot be merged into the
> > production branch.
> >
> >
> >
> > (production)
> >
> > git merge development_feature_branch
> >
> >
> >
> > fatal: refusing to merge unrelated histories
> >
>
> See the git merge man page for the
>   --allow-unrelated-histories switch.

I have tried that switch, however when merging a small feature branch,
the merge tries to merge ALL of the differences between both branches,
and they have diverged quite a long while ago.
I am not getting the expected behaviour of just merging the changes
from the feature branch.

git-merge-base shows a common ancestor from 2 months ago,  btw.


>
> >
> >
> >
> > 2- If there is a file that only has a 1 line difference in production,
> > a git diff will return that the whole file is different:
> >
> > git diff production:folder development:folder
> >
> >
> > “
> > diff --git a/folder/file.py b/folder/file.py
> >
> > index 9bfd6612..20cce520 100644
> >
> > --- a/folder/file py
> >
> > +++ b/folder/file.py
> >
> > @@ -1,245 +1,245 @@
> >
> > “
> >
> > I’m not 100% sure what happened here. But it seems that changes and
> > added files are copied and pasted into the production branch and
> > uploaded indepenedently as separate files, contributing to a huge
> > difference between branches.
>
> It sounds to me as if there would be line ending issues or some sort
> of whitespace issues (tab vs spaces).
>
> >
> > How can I confirm this hypothesis, and what steps can I take to solve it?
>
> git diff --ignore-all-space
> or --ignore-space-at-eol

This worked. Thank you!

>
> Look at gitattributes to set your flavor for files so you don't have
> to pass these flags all the time
>
> Stefan

Fwd: Git Help !!!

2018-07-25 Thread Vishwas Kamath 
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 regarding my problem

kind regards

vishwas

Fwd: [PATCH v2 02/18] Add a new builtin: branch-diff

2018-05-26 Thread Øyvind Rønningstad 
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

Fwd: [RFC PATCH] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

2018-03-29 Thread Eddy Petrișor 
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 really. I am still unsure how is best to proceed. Details below.

> > There are projects such as llvm/clang which use several repositories, and
> they
> > might be forked for providing support for various features such as adding
> Redox
> > awareness to the toolchain. This typically means the superproject will use
> > another branch than master, occasionally even use an old commit from that
> > non-master branch.
>
> > Combined with the fact that when incorporating such a hierachy of
> repositories
> > usually the user is interested in just the exact commit specified in the
> > submodule info, it follows that a desireable usecase is to be also able to
> > provide '--depth 1' to avoid waiting for ages for the clone operation to
> > finish.
>
> Very sensible.


The only change is that I realized that hard coding the depth is not
necessary because the client can fetch more and more from the branch
until the commit hash is found or the entire history was fetched and
it wasn't found.

This is more robust but has a variable performance penalty and is
probably slower than single branch fetching from the start.

> > Git submodule seems to be very stubborn and cloning master, although the
> > wrapper script and the gitmodules-helper could work together to clone
> directly
> > the branch specified in the .gitmodules file, if specified.
>
> Also very sensible.
>
> So far so good, could you move these paragraphs before the triple dashed
> line
> and sign off so we record it as the commit message?


Sure, as long as the implementation and design makes sense.

> > Another wrinkle is that when the commit is not the tip of the branch, the
> depth
> > parameter should somehow be stored in the .gitmodules info, but any
> change in
> > the submodule will break the supermodule submodule depth info sooner or
> later,
> > which is definitly frigile.
>
> ... which is why I would not include that.
>
> git-fetch knows about --shallow-since or even better
> shallow-exclude which could be set to the (depth+1)-th commit
> (the boundary commit) recorded in the shallow information.


I am unsure what that means. Without yet looking in the docs, would
this --shallow-since be better than the try-until-found algorithm
explained above?

> > I tried digging into this section of the code and debugging with bashdb
> to see
> > where --depth might fit, but I got stuck on the shell-to-helper
> interaction and
> > the details of the submodule implementation, so I want to lay out this
> first
> > patch as starting point for the discussion in the hope somebody else
> picks it
> > up or can provide some inputs. I have the feeling there are multiple code
> paths
> > that are being ran, depending on the moment (initial clone, submodule
> > recursive, post-clone update etc.) and I have a gut feeling there
> shouldn't be
> > any code duplication just because the operation is different.
>
> > This first patch is only trying to use a non-master branch, I have some
> changes
> > for the --depth part, but I stopped working on it due to the "default
> depth"
> > issue above.
>
> > Does any of this sound reasonable?
> > Is this patch idea usable or did I managed to touch the part of the code
> that
> > should not be touched?
>
> This sounds reasonable. Thanks for writing the patch!


OK. Now I need to make it good, which is the hard part :)

> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index 2491496..370f19e 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -589,8 +589,11 @@ cmd_update()
> >  branch=$(git submodule--helper remote-branch
> "$sm_path")
> >  if test -z "$nofetch"
> >  then
> > +   # non-default branch
> > +   rbranch=$(git config -f .gitmodules
> submodule.$sm_path.branch)
> > +
> br_refspec=${rbanch:+"refs/heads/$rbranch:refs/heads/$rbranch"}
>
> Wouldn't we want to fetch into a remote tracking branch instead?
> Instead of computing all this by yourself, these two lines could be
>
>  br_refspec=$(git submodule--helper remote-branch $sm_path)
>
> I would think.


I wasn't aware of this, will implement I  the next version and see what happens.
>
>
> >  # Fetch remote before determining
> tracking $sha1
> > -   fetch_in_submodule "$sm_path" $depth ||
> > +   fetch_in_submodule "$sm_path" $depth
> $br_refspec ||
> >  die "$(eval_gettext "Unable to fetch in
> submodule path '\$sm_path'")"
> >

Re: Fwd: New Defects reported by Coverity Scan for git

2018-03-27 Thread Jeff Hostetler 



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 --

[...]


*** CID 1433539:  Null pointer dereferences  (FORWARD_NULL)
/t/helper/test-json-writer.c: 278 in scripted()
272 struct json_writer jw = JSON_WRITER_INIT;
273 int k;
274
275 if (!strcmp(argv[0], "@object"))
276 jw_object_begin();
277 else if (!strcmp(argv[0], "@array"))

 CID 1433539:  Null pointer dereferences  (FORWARD_NULL)
 Passing "" to "jw_array_begin", which dereferences null "jw.levels".

278 jw_array_begin();
279 else
280 die("first script term must be '@object' or
'@array': '%s'", argv[0]);
281
282 for (k = 1; k < argc; k++) {
283 const char *a_k = argv[k];

** CID 1433538:  Null pointer dereferences  (FORWARD_NULL)



The "jw.levels" field has been removed in the json-writer V4 reroll,
so this isn't an issue going forward.

Thanks,
Jeff

Fwd: New Defects reported by Coverity Scan for git

2018-03-26 Thread Stefan Beller 
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
Subject: New Defects reported by Coverity Scan for git
To: sbel...@google.com


Hi,

Please find the latest report on new defect(s) introduced to git found
with Coverity Scan.

44 new defect(s) introduced to git found with Coverity Scan.
32 defect(s), reported by Coverity Scan earlier, were marked fixed in
the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 20 of 44 defect(s)


** CID 1433546:  Resource leaks  (RESOURCE_LEAK)
/t/helper/test-path-utils.c: 236 in cmd__path_utils()



*** CID 1433546:  Resource leaks  (RESOURCE_LEAK)
/t/helper/test-path-utils.c: 236 in cmd__path_utils()
230 if (argc >= 4 && !strcmp(argv[1], "prefix_path")) {
231 const char *prefix = argv[2];
232 int prefix_len = strlen(prefix);
233 int nongit_ok;
234 setup_git_directory_gently(_ok);
235 while (argc > 3) {
>>> CID 1433546:  Resource leaks  (RESOURCE_LEAK)
>>> Failing to save or free storage allocated by "prefix_path(prefix, 
>>> prefix_len, argv[3])" leaks it.
236 puts(prefix_path(prefix, prefix_len, argv[3]));
237 argc--;
238 argv++;
239 }
240 return 0;
241 }

** CID 1433545:  Security best practices violations  (STRING_OVERFLOW)
/merge-recursive.c: 1955 in check_dir_renamed()



*** CID 1433545:  Security best practices violations  (STRING_OVERFLOW)
/merge-recursive.c: 1955 in check_dir_renamed()
1949  struct
hashmap *dir_renames)
1950 {
1951char temp[PATH_MAX];
1952char *end;
1953struct dir_rename_entry *entry;
1954
>>> CID 1433545:  Security best practices violations  (STRING_OVERFLOW)
>>> You might overrun the 4096-character fixed-size string "temp" by 
>>> copying "path" without checking the length.
1955strcpy(temp, path);
1956while ((end = strrchr(temp, '/'))) {
1957*end = '\0';
1958entry = dir_rename_find_entry(dir_renames, temp);
1959if (entry)
1960return entry;

** CID 1433544:  Resource leaks  (RESOURCE_LEAK)
/builtin/submodule--helper.c: 66 in print_default_remote()



*** CID 1433544:  Resource leaks  (RESOURCE_LEAK)
/builtin/submodule--helper.c: 66 in print_default_remote()
60  die(_("submodule--helper print-default-remote takes no
arguments"));
61
62  remote = get_default_remote();
63  if (remote)
64  printf("%s\n", remote);
65
>>> CID 1433544:  Resource leaks  (RESOURCE_LEAK)
>>> Variable "remote" going out of scope leaks the storage it points to.
66  return 0;
67 }
68
69 static int starts_with_dot_slash(const char *str)
70 {
71  return str[0] == '.' && is_dir_sep(str[1]);

** CID 1433543:  Null pointer dereferences  (NULL_RETURNS)
/merge-recursive.c: 812 in was_dirty()



*** CID 1433543:  Null pointer dereferences  (NULL_RETURNS)
/merge-recursive.c: 812 in was_dirty()
806 int dirty = 1;
807
808 if (o->call_depth || !was_tracked(path))
809 return !dirty;
810
811 ce = cache_file_exists(path, strlen(path), ignore_case);
>>> CID 1433543:  Null pointer dereferences  (NULL_RETURNS)
>>> Dereferencing a null pointer "ce".
812 dirty = (ce->ce_stat_data.sd_mtime.sec > 0 &&
813  verify_uptodate(ce, >unpack_opts) != 0);
814 return dirty;
815 }
816
817 static int make_room_for_path(struct merge_options *o, const char *path)

** CID 1433542:  Error handling issues  (CHECKED_RETURN)
/merge-recursive.c: 2162 in apply_directory_rename_modifications()



*** CID 1433542:  Error handling issues  (CHECKED_RETURN)
/merge-recursive.c: 2162 in apply_directory_rename_modifications()
2156 * "NOTE" in update_stages(), doing so will modify the current
2157 * in-memory index which will break calls to

Fwd: user-manual: patch proposals and questions

2018-03-18 Thread kalle 

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'

3.it would be for non-graphics-users to have the Git-Pro-book in
text-format.

thanks,
kalle

 Weitergeleitete Nachricht 
Betreff: user-manual: patch proposals and questions
Datum: Tue, 6 Mar 2018 00:08:55 +0100
Von: kalle 
An: git@vger.kernel.org

The patches are attached.
Further some questions:

-see the explanations of the branch command, ca. line 280: wouldn't it
be better to use other words than 'references'?
-sentence "it shows all commits reachable from the parent commit": it
seems wrong to me. The last commit is also shown.
- chapter "Browsing revisions": it seems counterintuitive to me to have
two different logics for the meaning of "branch1..branch2" and
"branch1...branch2", according to whether it's the argument of `git log'
or `git diff'
-section "Check whether two branches point at the same history": 'git
diff origin..master' -> shouldn't it be rather 'git diff
branch1..branch2'? … or rewrite the example with branch1=origin and
branch2=master.

greetings,
kalle


>From 19061a0dd4363edbf8757a5e9eee8ace210f4029 Mon Sep 17 00:00:00 2001
From: kalledaballe 
Date: Fri, 9 Feb 2018 20:46:52 +0100
Subject: [PATCH 2/5] 3 small formulation changes in
 Documentation/user-manual.txt

---
 Documentation/user-manual.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index eff7890..e3efc26 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -322,7 +322,7 @@ do so (now or later) by using -b with the checkout command again. Example:
 HEAD is now at 427abfa Linux v2.6.17
 
 
-The HEAD then refers to the SHA-1 of the commit instead of to a branch,
+If you haven't created a new branch yet, the HEAD then refers to the SHA-1 of the commit instead of to a branch,
 and git branch shows that you are no longer on a branch:
 
 
@@ -370,7 +370,7 @@ be updated by `git fetch` (hence `git pull`) and `git push`. See
 <> for details.
 
 You might want to build on one of these remote-tracking branches
-on a branch of your own, just as you would for a tag:
+a branch of your own, just as you would for a tag:
 
 
 $ git checkout -b my-todo-copy origin/todo
@@ -404,7 +404,7 @@ they may also be packed together in a single file; see
 linkgit:git-pack-refs[1]).
 
 As another useful shortcut, the "HEAD" of a repository can be referred
-to just using the name of that repository.  So, for example, "origin"
+to by just using the name of that repository.  So, for example, "origin"
 is usually a shortcut for the HEAD branch in the repository "origin".
 
 For the complete list of paths which Git checks for references, and
-- 
2.1.4



>From 3917eeaf8d21b8b90a773c46ee5b9d12eac901e3 Mon Sep 17 00:00:00 2001
From: kalledaballe 
Date: Sat, 10 Feb 2018 16:08:45 +0100
Subject: [PATCH 3/5] I changed the sequence of 2 sentences.

---
 Documentation/user-manual.txt | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index e3efc26..b9dc17a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -609,13 +609,9 @@ $ git show HEAD^2   # show the second parent of HEAD
 In addition to HEAD, there are several other special names for
 commits:
 
-Merges (to be discussed later), as well as operations such as
-`git reset`, which change the currently checked-out commit, generally
-set ORIG_HEAD to the value HEAD had before the current operation.
+ORIG_HEAD is set to the value HEAD before merging (to be discussed later) operations as well as operations such as `git reset'. which change the currently checked-out commit.
 
-The `git fetch` operation always stores the head of the last fetched
-branch in FETCH_HEAD.  For example, if you run `git fetch` without
-specifying a local branch as the target of the operation
+FETCH_HEAD after a `git fetch' operation stores the head of the last fetched branch. For example, if you run `git fetch' without specifying a local branch as the target of the operation.
 
 -
 $ git fetch git://example.com/proj.git theirbranch
@@ -664,7 +660,7 @@ can also make more specific requests:
 
 -
 $ git log v2.5..	# commits since (not reachable from) v2.5
-$ git log test..master	# commits reachable from master but not test
+$ git log ..master	# commits reachable from master but not

Re: Fwd: Opinions on changing add/add conflict resolution?

2018-03-13 Thread Junio C Hamano 
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 goes, estimate_similarity() is
> currently used by rename detection to compare files recorded at
> different pathnames.  By contrast, in this context, we are comparing
> two files which were recorded with the same pathname.  That suggests
> the heuristic could be a bit different and use more than just
> estimate_similarity().  (e.g. "We consider these files similar IF more
> than 50% of the lines match OR both files are less than 2K.")

Yeah, I think there is similar difference between similarity score
that is used by diffcore-rename and dissimilarity score that is used
by diffcore-break exactly for that reason.  If you start from a
100-line original file and grow it to 100-line one by adding 900
lines, as long as you kept the original 100 lines, it is easier to
view the change within the same path as a continued development,
instead of saying they are so dissimilar.

In any case, I think the way the stage #2 and stage #3 (i.e. ours
and theirs) contents are externalized during a conflicted mergy
operation should be consistent across edit/edit and add/add
conflict, so if we are adding a new way to write out extra temporary
files out of these higher stage index entries, it should be made
applicable not only to add/add conflict (i.e. there shounld't be a
code that says "oh, let's see, this lacks stage #1, so do this
different thing").

Personally, I think it is best to leave it all outside of the core
and make "git mergetool" to be responsible for the job of
externalizing higher stage index entries to temporary working tree
files.  They already need to do so in order to work with external
tools that do not read directly from our index file anyway, no?

Fwd: Opinions on changing add/add conflict resolution?

2018-03-12 Thread Elijah Newren 
[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 containing "bar":
>
> (
> rm -rf /tmp/test.git &&
> git init /tmp/test.git &&
> cd /tmp/test.git &&
> echo foo >README &&
> git add README &&
> git commit -mfoo &&
> git checkout --orphan trunk &&
> git reset --hard &&
> echo bar >README &&
> git add README &&
> git commit -mbar &&
> git merge --allow-unrelated-histories master;
> cat README
> )
>
> That instead of getting:
>
> <<< HEAD
> bar
> ===
> foo
> >>> master
>
> I'd now get these split into different files?

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 goes, estimate_similarity() is
currently used by rename detection to compare files recorded at
different pathnames.  By contrast, in this context, we are comparing
two files which were recorded with the same pathname.  That suggests
the heuristic could be a bit different and use more than just
estimate_similarity().  (e.g. "We consider these files similar IF more
than 50% of the lines match OR both files are less than 2K.")


> I don't mind this being a configurable option if you want it, but I
> don't think it should be on by default, reasons:

I don't think a configurable option makes sense, at least not for my
purposes.  Having rename/rename conflicts be "safely" mis-detected as
rename/add or add/add, and having rename/add conflicts be "safely"
mis-detected as add/add is my overriding concern.  Thus, making these
three conflict types behave consistently is what I need.  Options
would make that more difficult for me, and would thus feel like a step
backwards.

git am/rebase has been doing such mis-detections for years (almost
since the "dawn" of git time), but it feels really broken to me
because the conflict types aren't handled consistently.  (The facts
that (a) I'm the only one that has added rename/add testcases to
git.git, (b) that I've added all but one of the rename/rename(2to1)
testcases to the git.git testsuite, and (c) that rename/add has had
multiple bugs for many years, all combine to suggest to me that folks
just don't hit those conflict types in practice and thus that they
just aren't noticing this breakage -- yet.)

I also want to allow such mis-detections for cherry-picks and merges
because of the significant (nearly order-of-magnitude in some cases)
performance improvements I can get in rename detection if it's
allowed.


>  1) There's lots of cases where we totally screw up the "is this
> similar?" check, in particular with small files.
>
> E.g. let's say you have a config file like 'fs-path "/tmp/git"' and
> in two branches you change that to 'fs-path "/opt/git"' and 'fs-path
> "/var/git"'. The rename detection will think this these have nothing
> to do with each other since they share no common lines, but to a
> human reader they're really similar, and would make sense in the
> context of resolving a bigger merge where /{opt,var}/git changes are
> conflicting.
>
> This is not some theoretical concern, there's lots of things that
> e.g. use small 5-10 line config files to configure some app that
> because of some combo of indentation changes and changing a couple
> of lines will make git's rename detection totally give up, but to a
> human reader they're 95% the same.

Fair enough.  The small files case could potentially be handled by
just changing the similarity metric for these conflict types, as noted
above.  If it's a small file, that might be the easiest way for a user
to deal with it too.

I'm not sure I see the problem with the bigger files, though.  If you
have bigger files with less than 50% of the lines matching, then
you'll essentially end up with a great big conflict block with one
file on one side and the other file on the other side, which doesn't
seem that different to me than having them be in two separate files.
In fact, separate files seems easier to deal with because then the
user can run e.g. 'git diff --no-index --color-words FILE1 FILE2',
something that they can't do when it's in one file.  That has bothered
me more than once, and made me wish they were just in separate files.


>  2) This will play havoc with already established merge tools on top of
> git which a lot of users use instead of manually resolving these in
> vi or whatever.
>
> If we made this the default they'd need to to deal with this new
> state, and even if

Fwd:

2018-01-19 Thread A. ALLIED 
-- Forwarded message --
From: "A. ALLIED" 
Date: Fri, 19 Jan 2018 15:44:47 +
Subject:
To:


Hi.docx
Description: MS-Word 2007 document

Re: Fwd: Unknown option for merge-recursive: -X'diff-algorithm=patience'

2018-01-04 Thread Johannes Schindelin 
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 on top of abc-3.8. Here, I edit README.
> 
> # vim README
> # git commit -a -v
> [abc-3.8 4bf088b5d341] Hello world
> 
> Then I try to rebase abc-3.9 on top of abc-3.8 as the following:
> 
> # 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'
> Error redoing merge e84cf5d0fd53badf3a93c790e280cc92a69ed999
> 
> Attached here is GIT_TRACE=1 output.

Funnily enough, this had been reported on the Git for Windows bugtracker,
and somebody even found the culprit:

https://github.com/git-for-windows/git/issues/1321#issuecomment-337279119

Sadly, I lost track of this. Will prepare a proper patch right now.

Ciao,
Johannes

Re: Fwd: Unknown option for merge-recursive: -X'diff-algorithm=patience'

2018-01-04 Thread Matwey V. Kornilov 
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 for merge-recursive: -X'diff-algorithm=patience'
>
> The string looks like a result of a shell script that quotes any
> end-user controlled string before incorporating into a string to be
> eval-ed, or something like that.  Is this a recent regression?  Does
> a bit older version of Git, like 2.12 or older, behave differently?
>

I've just checked, 2.12.4 has the same behaviour. By the way, can you
reproduce this at all?

-- 
With best regards,
Matwey V. Kornilov

Re: Fwd: Unknown option for merge-recursive: -X'diff-algorithm=patience'

2018-01-04 Thread 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 for merge-recursive: -X'diff-algorithm=patience'

The string looks like a result of a shell script that quotes any
end-user controlled string before incorporating into a string to be
eval-ed, or something like that.  Is this a recent regression?  Does
a bit older version of Git, like 2.12 or older, behave differently?

Re: Fwd: Unknown option for merge-recursive: -X'diff-algorithm=patience'

2018-01-04 Thread Matwey V. Kornilov 

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/kernel/git/tip/tip

Where did additional quotes around diff-algorithm came from?


01.01.2018 14:28, Matwey V. Kornilov пишет:
> 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 4bf088b5d341] Hello world
> 
> Then I try to rebase abc-3.9 on top of abc-3.8 as the following:
> 
> # 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'
> Error redoing merge e84cf5d0fd53badf3a93c790e280cc92a69ed999
> 
> Attached here is GIT_TRACE=1 output.
>

Fwd: Unknown option for merge-recursive: -X'diff-algorithm=patience'

2018-01-01 Thread Matwey V. Kornilov 
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 4bf088b5d341] Hello world

Then I try to rebase abc-3.9 on top of abc-3.8 as the following:

# 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'
Error redoing merge e84cf5d0fd53badf3a93c790e280cc92a69ed999

Attached here is GIT_TRACE=1 output.

-- 
With best regards,
Matwey V. Kornilov

Re: Fwd: Has git-gui repo moved from location?

2017-10-17 Thread Gilberto Stankiewicz 
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/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 9418) ... 195.113.20.142 done.
> From git://repo.or.cz/git-gui
>  = [up to date]master -> git-gui/master
>  = [up to date]pu -> git-gui/pu
>  = [up to date]todo   -> git-gui/todo
>
> $ git fetch -v git://repo.or.cz/git-gui.git
> Looking up repo.or.cz ... done.
> Connecting to repo.or.cz (port 9418) ... 195.113.20.142 done.
> From git://repo.or.cz/git-gui
>  * branch  HEAD   -> FETCH_HEAD
>

Re: Fwd: Has git-gui repo moved from location?

2017-10-17 Thread Junio C Hamano 
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 9418) ... 195.113.20.142 done.
>From git://repo.or.cz/git-gui
 = [up to date]master -> git-gui/master
 = [up to date]pu -> git-gui/pu
 = [up to date]todo   -> git-gui/todo

$ git fetch -v git://repo.or.cz/git-gui.git
Looking up repo.or.cz ... done.
Connecting to repo.or.cz (port 9418) ... 195.113.20.142 done.
>From git://repo.or.cz/git-gui
 * branch  HEAD   -> FETCH_HEAD

Fwd: Has git-gui repo moved from location?

2017-10-17 Thread Gilberto Stankiewicz 
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

Re: Fwd: how can I conform if I succeed in sending patch to mailing list

2017-10-11 Thread Thomas Gummerer 
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. Of course I'm
> subscribing mailing list.
> 
> How can I conform if I succeed in sending patch to mailing list?

I think that's just a feature of the mailing list, where it doesn't
send you an email in which you are already Cc'd in, or something like
that.  I received your mails through the mailing list.

You can check if they arrived on the list at the public archives of
the mailing list (https://public-inbox.org/git/).

> Takahito Ogawa

Re: Fwd: how can I conform if I succeed in sending patch to mailing list

2017-10-11 Thread Jonathan Tan 
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 received email from mailing list. Of course I'm
> subscribing mailing list.
> 
> How can I conform if I succeed in sending patch to mailing list?

The easiest way I can think of is to check an online mailing list
archive [1].

I think your patch was received, as you can see in [2].

[1] for example, https://public-inbox.org/git/

[2] https://public-inbox.org/git/?q=aiueogawa217

Fwd: how can I conform if I succeed in sending patch to mailing list

2017-10-11 Thread 小川恭史 
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 list.

How can I conform if I succeed in sending patch to mailing list?

Takahito Ogawa

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

2017-08-04 Thread Bjørn Erik Pedersen 
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 Git project itself" (I assume it will always be
used on A Git project), changing the commit title to be in line with
the rest would not hurt anyone.

Bjørn Erik

2017-08-04 23:21 GMT+02:00 Junio C Hamano :
> 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 that follow the same convention as the Git project itself.

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

2017-08-04 Thread Junio C Hamano 
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 that follow the same convention as the Git project itself.

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

2017-08-04 Thread Bjørn Erik Pedersen 
I.e. "Squash 'somedir' changes" and not "Squashed ..."

See

https://github.com/git/git/blob/master/contrib/subtree/git-subtree.sh#L463

Re: Fwd: Should "head" also work for "HEAD" on case-insensitive FS?

2017-07-27 Thread Junio C Hamano 
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
>> because the pseudo_ref handling refs.c wanted to see ".git/FOO" on
>> the reading side.
>> 
>> Perhaps it is only a bug in t/t1405-main-ref-store.sh?
>
> An interesting related issue for pseudo-refs: if you encode HEAD as
> .git/%48%45%41%44, how will we recognize that directory as a git
> repository?

Yes, that is a valid point.  I may have forgot to explain why the
sample change in my message upthread special cases "HEAD" and leaves
it untouched, but it is done for this exact reason.

>   1. It should say "this is a git repo, but not a vintage I understand".
>  Not "this isn't a git repo, I'll keep looking".
>
>   2. How does a git version of the correct vintage decide "this is a git
>  repo, so I'll check its config for extensions.refBackend, and a-ha,
>  they _do_ have a HEAD". There's a chicken-and-egg problem.

Yes, exactly.

Re: Fwd: Should "head" also work for "HEAD" on case-insensitive FS?

2017-07-27 Thread Jeff King 
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/").
> >
> > Pseudo-refs (with the partial exception of "HEAD") are quite peculiar
> > beasts
> 
> I agree with the reasoning, but what I am worried about is that
> their handling in the existing refs.c code may be leaky and/or
> inconsistent.
> 
> 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
> because the pseudo_ref handling refs.c wanted to see ".git/FOO" on
> the reading side.
> 
> Perhaps it is only a bug in t/t1405-main-ref-store.sh?

An interesting related issue for pseudo-refs: if you encode HEAD as
.git/%48%45%41%44, how will we recognize that directory as a git
repository? Detecting (and doing a sanity check on) "HEAD" is one of the
key mechanisms for deciding whether we are in a git repository.

Obviously an older version of git that doesn't know about the new
encoding scheme wouldn't work on this repository anyway. But:

  1. It should say "this is a git repo, but not a vintage I understand".
 Not "this isn't a git repo, I'll keep looking".

  2. How does a git version of the correct vintage decide "this is a git
 repo, so I'll check its config for extensions.refBackend, and a-ha,
 they _do_ have a HEAD". There's a chicken-and-egg problem.

Obviously for (2) we could teach that mechanism to look for the encoded
HEAD file, too. But this is just one backend. What about a reftable or
other non-filesystem store that keeps "HEAD" inside a file?

I kind of wonder if more exotic ref storage backends should always just
place a dummy "HEAD" file that is enough to bootstrap the "this is a git
repo" process (for both new and old versions).

This is orthogonal to the rest of the pseudo-refs discussion, but just
something I thought of while reading the thread.

-Peff

Fwd: Should "head" also work for "HEAD" on case-insensitive FS?

2017-07-26 Thread Junio C Hamano 
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 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/").
>
> Pseudo-refs (with the partial exception of "HEAD") are quite peculiar
> beasts

I agree with the reasoning, but what I am worried about is that
their handling in the existing refs.c code may be leaky and/or
inconsistent.

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
because the pseudo_ref handling refs.c wanted to see ".git/FOO" on
the reading side.

Perhaps it is only a bug in t/t1405-main-ref-store.sh?

> But...since we are talking about introducing a new loose reference
> filename encoding, ...

Yes, but that is an encoding detail I do not have to get involved
and folks with platform needs can add more on top---we need to make
sure that the places that encode and decode are identified in the
code first, and the things like "FOO is encoded upon writing because
files-backend is asked to write it, but not decoded because refs.c
thinks it is pseudo-ref and does not give a say to files-backend"
shouldn't be happening before we can start working on the details of
the encoding.  Making a conscious decision that pseudo-refs are left
as-is is OK, but we need to see both reading and writing side
following the same codepath to make that decision, which does not
seem to be the case in the current code.

Fwd: Should "head" also work for "HEAD" on case-insensitive FS?

2017-07-26 Thread Michael Haggerty 
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: Should "head" also work for "HEAD" on case-insensitive FS?
To: Junio C Hamano 


On Fri, Jul 7, 2017 at 12:34 AM, Junio C Hamano  wrote:
> [...]
> The exact detail of the encoding used here is immaterial, but I just
> used "encode uppercase letters and % as % followed by two hex",
> which was simple enough.  Usual refs/heads/master and friends will
> not have to be touched when encoded this way.  Perhaps the decoding
> side should be tweaked so that uppercase letters it sees needs to be
> downcased to avoid "refs/heads/Foo" getting returned as "Foo" branch,
> as a "Foo" branch should have been encoded as "refs/heads/%46oo".
>
> Having said that, this patch alone does not quite work yet.
>
>  * In the repository discovery code, we have some logic that
>hard-codes the path in the directory (which is a candidate for
>being a repository) to check, like "refs/" and "HEAD".  In the
>attached illustration patch, files_path_encode() special cases
>"HEAD" so that it is not munged, which is a bit of ugly
>workaround for this.
>
>  * I haven't figured out why, but what refs.c calls "pseudo refs"
>bypasses the files backend layer for some but not all operations,
>which causes t1405-main-ref-store to fail.  The test creates a
>"pseudo ref" FOO and then tries to remove it.  Creation seems to
>follow the files-backend.c and thusly goes through the escaping;
>refs.::refs_delete_ref() however does not consult files-backend.c
>and fails to find and delete .git/FOO, because the creation side
>encoded it as ".git/%46%4F%4F".

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/").

Pseudo-refs (with the partial exception of "HEAD") are quite peculiar
beasts. They sometimes include other information besides the reference
value and IIRC the refs code doesn't have any idea how to write or
read those extra contents. I believe that "HEAD" is the only pseudo
ref for which reflogs are ever written. Pseudo-refs have to match
/[A-Z_]+/ (see 
https://github.com/git/git/blob/8b2efe2a0fd93b8721879f796d848a9ce785647f/refs.c#L169-L173),
so ISTM that there is no need to encode such references' filenames at
all. (It's possible that the pattern could be made even stricter, like
/[A-Z_]+HEAD/.) Moreover, IIRC, such references are never scanned for
(as in for-each-refs) but rather are always asked for by name. So
their names might never have to be *de*coded, either. On the other
hand, when trying to look them up, it would be a good idea to verify
that the requested name satisfies the above naming rule. Other than
that, I believe it would be preferable to leave pseudo-refs untouched
by your new encoding/decoding code.

Whereas other references are typically lower-case, so it makes sense
for lower-case letters to be the ones that are passed through
transparently in such references' filenames (as in your scheme).

But...since we are talking about introducing a new loose reference
filename encoding, I think it would be a good idea to address a couple
of related issues at the same time:

* Some filesystems natively use Unicode, and insist on a particular
Unicode normalization (NFC vs NFD), which might differ from the
"upstream" normalization. So such reference names get munged when
written as loose references. I'm not enough of an expert in Unicode to
know what the best solution is, except for the strong feeling that it
would require some cooperation from the rest of Git to ensure a good
user experience.

* Another bad effect of our current loose reference encoding is that
it prohibits references that D/F conflict with each other (like
"refs/heads/foo" and "refs/heads/foo/bar") because
"$GIT_DIR/refs/heads/foo" can't be a file and a directory at the same
time. Even if we don't want to support that, this problem also
prevents us from storing reflogs for deleted references, which is a
serious flaw. We could solve this problem by encoding "directory"
components of reference names differently than "leaf" components; for
example, the above references could be encoded as
"refs/heads.d/foo.ref" and "refs/heads.d/foo.d/bar.ref".

It'd be nice to solve all of these related problems at the same time,
because whatever encoding we choose now will have to be supported
forever.

Michael

Re: Fwd: New Defects reported by Coverity Scan for git

2017-07-20 Thread Junio C Hamano 
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 such a
> hypothetical bug.  Makes sense?
>
> -- >8 --
> Subject: [PATCH] pack-objects: remove unnecessary NULL check
>
> If done_pbase_paths is NULL then done_pbase_paths_num must be zero and
> done_pbase_path_pos() returns -1 without accessing the array, so the
> check is not necessary.
>
> If the invariant was violated then the check would make sure we keep
> on going and allocate the necessary amount of memory in the next
> ALLOC_GROW call.  That sounds nice, but all array entries except for
> one would contain garbage data.
>
> If the invariant was violated without the check we'd get a segfault in
> done_pbase_path_pos(), i.e. an observable crash, alerting us of the
> presence of a bug.
>
> Currently there is no such bug: Only the functions check_pbase_path()
> and cleanup_preferred_base() change pointer and counter, and both make
> sure to keep them in sync.  Get rid of the check anyway to allow us to
> see if later changes introduce such a defect, and to simplify the code.
>
> Detected by Coverity Scan.
>
> Signed-off-by: Rene Scharfe 
> ---

It's always amusing to see that a removal of conditional codepath
would result in better chance of finding possible invariant
breakers, as we often think that belt-and-suspenders safety would
require more conditionals and asserts ;-)



>  builtin/pack-objects.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index e730b415bf..c753e9237a 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -1289,7 +1289,7 @@ static int done_pbase_path_pos(unsigned hash)
>  
>  static int check_pbase_path(unsigned hash)
>  {
> - int pos = (!done_pbase_paths) ? -1 : done_pbase_path_pos(hash);
> + int pos = done_pbase_path_pos(hash);
>   if (0 <= pos)
>   return 1;
>   pos = -pos - 1;

Re: Fwd: New Defects reported by Coverity Scan for git

2017-07-20 Thread René Scharfe 
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 does not understand
>>how ALLOC_GROW works. It assumes that
>>done_pbase_paths_alloc can be larger
>>than done_pbase_paths_num + 1, while done_pbase_paths
>>is NULL, such that the memory allocation is not triggered.
>>If that were the case, then we have 2 subsequent dereferences
>>of a NULL pointer right after that. But by inspecting the use
>>of _alloc and _num the initial assumption does not seem possible.
> 
> Yes, it does appear that way.  ALLOC_GROW() calls REALLOC_ARRAY()
> which safely can realloc NULL to specified size via xrealloc().

MOVE_ARRAY is passing its pointer arguments to memmove(); all it adds
is a check for (done_pbase_paths_num - pos - 1) being zero.  I don't
understand how that change can make it more likely for one of the
pointers to be NULL.

I guess the first message ('Comparing "done_pbase_paths" to null
implies that "done_pbase_paths" might be null.') has to be understood
as an explanation of how the checker arrived at the second one?

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 such a
hypothetical bug.  Makes sense?

-- >8 --
Subject: [PATCH] pack-objects: remove unnecessary NULL check

If done_pbase_paths is NULL then done_pbase_paths_num must be zero and
done_pbase_path_pos() returns -1 without accessing the array, so the
check is not necessary.

If the invariant was violated then the check would make sure we keep
on going and allocate the necessary amount of memory in the next
ALLOC_GROW call.  That sounds nice, but all array entries except for
one would contain garbage data.

If the invariant was violated without the check we'd get a segfault in
done_pbase_path_pos(), i.e. an observable crash, alerting us of the
presence of a bug.

Currently there is no such bug: Only the functions check_pbase_path()
and cleanup_preferred_base() change pointer and counter, and both make
sure to keep them in sync.  Get rid of the check anyway to allow us to
see if later changes introduce such a defect, and to simplify the code.

Detected by Coverity Scan.

Signed-off-by: Rene Scharfe 
---
 builtin/pack-objects.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index e730b415bf..c753e9237a 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -1289,7 +1289,7 @@ static int done_pbase_path_pos(unsigned hash)
 
 static int check_pbase_path(unsigned hash)
 {
-   int pos = (!done_pbase_paths) ? -1 : done_pbase_path_pos(hash);
+   int pos = done_pbase_path_pos(hash);
if (0 <= pos)
return 1;
pos = -pos - 1;
-- 
2.13.3

Re: Fwd: New Defects reported by Coverity Scan for git

2017-07-18 Thread Stefan Beller 
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^ > 
>> >> actual
>> >>
>> >> in https://travis-ci.org/git/git/jobs/254654195 by the way.
>> >
>> > Thanks for bringing that to my attention, (I do not follow the travis 
>> > builds
>> > as closely, as there is no yelling email in my inbox).
>> >
>> > Windows builds on travis seem to be flaky.
>> > (sometimes they do not start), but there are also
>> > successful builds, including the -rc0, which may indicate
>> > bw/grep-recurse-submodules may be faulty on Windows.
>>
>> I can get valgrind complaints locally from
>>
>> $ cd t && sh t7814-grep*.sh --valgrind -i -v
>>
>> so this may not be Windows only.  Can repo_worktree_path() return a NULL
>> in repo_read_gitmodules() to cause git_config_from_file() barf on a NULL
>> gitmodule_path?
>
> Yep that's most likely the cause.  The issue is if a repository doesn't
> have a worktree then what should a worktree path look like?
> repo_read_gitmodules() should check if there is a worktree before trying
> to load the gitmodules file.  I actually noticed this and have it fixed 
> locally in
> another series I'm working on right now.  Looks like I may have to get
> that change in first though.  Thanks for finding this.

If there is no worktree, we could fallback to read it from the tree
HEAD:.gitmodules, if that doesn't exist, then there are no submodules.

Thanks,
Stefan

Re: Fwd: New Defects reported by Coverity Scan for git

2017-07-18 Thread Brandon Williams 
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 by the way.
> >
> > Thanks for bringing that to my attention, (I do not follow the travis builds
> > as closely, as there is no yelling email in my inbox).
> >
> > Windows builds on travis seem to be flaky.
> > (sometimes they do not start), but there are also
> > successful builds, including the -rc0, which may indicate
> > bw/grep-recurse-submodules may be faulty on Windows.
> 
> I can get valgrind complaints locally from
> 
> $ cd t && sh t7814-grep*.sh --valgrind -i -v
> 
> so this may not be Windows only.  Can repo_worktree_path() return a NULL
> in repo_read_gitmodules() to cause git_config_from_file() barf on a NULL
> gitmodule_path?

Yep that's most likely the cause.  The issue is if a repository doesn't
have a worktree then what should a worktree path look like?
repo_read_gitmodules() should check if there is a worktree before trying
to load the gitmodules file.  I actually noticed this and have it fixed locally 
in
another series I'm working on right now.  Looks like I may have to get
that change in first though.  Thanks for finding this.

> 
> ==20383== Syscall param open(filename) points to unaddressable byte(s)
> ==20383==at 0x5153140: __open_nocancel 
> (/build/eglibc-SvCtMH/eglibc-2.19/io/../sysdeps/unix/syscall-template.S:81)
> ==20383==by 0x50DDED7: _IO_file_fopen@@GLIBC_2.2.5 
> (/build/eglibc-SvCtMH/eglibc-2.19/libio/fileops.c:228)
> ==20383==by 0x50D23D3: __fopen_internal 
> (/build/eglibc-SvCtMH/eglibc-2.19/libio/iofopen.c:90)
> ==20383==by 0x569107: git_fopen (/home/gitster/git.git/compat/fopen.c:22)
> ==20383==by 0x55B1ED: fopen_or_warn (/home/gitster/git.git/wrapper.c:439)
> ==20383==by 0x4A2A32: git_config_from_file 
> (/home/gitster/git.git/config.c:1442)
> ==20383==by 0x540317: repo_read_gitmodules 
> (/home/gitster/git.git/submodule.c:269)
> ==20383==by 0x434389: grep_submodule 
> (/home/gitster/git.git/builtin/grep.c:422)
> ==20383==by 0x4348C8: grep_tree (/home/gitster/git.git/builtin/grep.c:580)
> ==20383==by 0x434867: grep_tree (/home/gitster/git.git/builtin/grep.c:576)
> ==20383==by 0x436034: cmd_grep (/home/gitster/git.git/builtin/grep.c:622)
> ==20383==by 0x4063DC: handle_builtin (/home/gitster/git.git/git.c:330)
> ==20383==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> 
> 

-- 
Brandon Williams

Re: Fwd: New Defects reported by Coverity Scan for git

2017-07-18 Thread Junio C Hamano 
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 attention, (I do not follow the travis builds
> as closely, as there is no yelling email in my inbox).
>
> Windows builds on travis seem to be flaky.
> (sometimes they do not start), but there are also
> successful builds, including the -rc0, which may indicate
> bw/grep-recurse-submodules may be faulty on Windows.

I can get valgrind complaints locally from

$ cd t && sh t7814-grep*.sh --valgrind -i -v

so this may not be Windows only.  Can repo_worktree_path() return a NULL
in repo_read_gitmodules() to cause git_config_from_file() barf on a NULL
gitmodule_path?

==20383== Syscall param open(filename) points to unaddressable byte(s)
==20383==at 0x5153140: __open_nocancel 
(/build/eglibc-SvCtMH/eglibc-2.19/io/../sysdeps/unix/syscall-template.S:81)
==20383==by 0x50DDED7: _IO_file_fopen@@GLIBC_2.2.5 
(/build/eglibc-SvCtMH/eglibc-2.19/libio/fileops.c:228)
==20383==by 0x50D23D3: __fopen_internal 
(/build/eglibc-SvCtMH/eglibc-2.19/libio/iofopen.c:90)
==20383==by 0x569107: git_fopen (/home/gitster/git.git/compat/fopen.c:22)
==20383==by 0x55B1ED: fopen_or_warn (/home/gitster/git.git/wrapper.c:439)
==20383==by 0x4A2A32: git_config_from_file 
(/home/gitster/git.git/config.c:1442)
==20383==by 0x540317: repo_read_gitmodules 
(/home/gitster/git.git/submodule.c:269)
==20383==by 0x434389: grep_submodule 
(/home/gitster/git.git/builtin/grep.c:422)
==20383==by 0x4348C8: grep_tree (/home/gitster/git.git/builtin/grep.c:580)
==20383==by 0x434867: grep_tree (/home/gitster/git.git/builtin/grep.c:576)
==20383==by 0x436034: cmd_grep (/home/gitster/git.git/builtin/grep.c:622)
==20383==by 0x4063DC: handle_builtin (/home/gitster/git.git/git.c:330)
==20383==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Re: Fwd: New Defects reported by Coverity Scan for git

2017-07-18 Thread Stefan Beller 
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 logic does not understand
>>   how ALLOC_GROW works. It assumes that
>>   done_pbase_paths_alloc can be larger
>>   than done_pbase_paths_num + 1, while done_pbase_paths
>>   is NULL, such that the memory allocation is not triggered.
>>   If that were the case, then we have 2 subsequent dereferences
>>   of a NULL pointer right after that. But by inspecting the use
>>   of _alloc and _num the initial assumption does not seem possible.
>
> Yes, it does appear that way.  ALLOC_GROW() calls REALLOC_ARRAY()
> which safely can realloc NULL to specified size via xrealloc().
>
> 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 attention, (I do not follow the travis builds
as closely, as there is no yelling email in my inbox).

Windows builds on travis seem to be flaky.
(sometimes they do not start), but there are also
successful builds, including the -rc0, which may indicate
bw/grep-recurse-submodules may be faulty on Windows.

Re: Fwd: New Defects reported by Coverity Scan for git

2017-07-18 Thread 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 does not understand
>   how ALLOC_GROW works. It assumes that
>   done_pbase_paths_alloc can be larger
>   than done_pbase_paths_num + 1, while done_pbase_paths
>   is NULL, such that the memory allocation is not triggered.
>   If that were the case, then we have 2 subsequent dereferences
>   of a NULL pointer right after that. But by inspecting the use
>   of _alloc and _num the initial assumption does not seem possible.

Yes, it does appear that way.  ALLOC_GROW() calls REALLOC_ARRAY()
which safely can realloc NULL to specified size via xrealloc().

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.

Fwd: New Defects reported by Coverity Scan for git

2017-07-18 Thread Stefan Beller 
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 larger
  than done_pbase_paths_num + 1, while done_pbase_paths
  is NULL, such that the memory allocation is not triggered.
  If that were the case, then we have 2 subsequent dereferences
  of a NULL pointer right after that. But by inspecting the use
  of _alloc and _num the initial assumption does not seem possible.

Stefan

-- Forwarded message --
From:  
Date: Tue, Jul 18, 2017 at 2:53 AM
Subject: New Defects reported by Coverity Scan for git
To: sbel...@google.com



Hi,

Please find the latest report on new defect(s) introduced to git found
with Coverity Scan.

2 new defect(s) introduced to git found with Coverity Scan.
1 defect(s), reported by Coverity Scan earlier, were marked fixed in
the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)


** CID 1415508:  Null pointer dereferences  (FORWARD_NULL)
/builtin/pack-objects.c: 1292 in check_pbase_path()



*** CID 1415508:  Null pointer dereferences  (FORWARD_NULL)
/builtin/pack-objects.c: 1292 in check_pbase_path()
1286}
1287return -lo-1;
1288 }
1289
1290 static int check_pbase_path(unsigned hash)
1291 {
>>> CID 1415508:  Null pointer dereferences  (FORWARD_NULL)
>>> Comparing "done_pbase_paths" to null implies that "done_pbase_paths" 
>>> might be null.
1292int pos = (!done_pbase_paths) ? -1 : done_pbase_path_pos(hash);
1293if (0 <= pos)
1294return 1;
1295pos = -pos - 1;
1296ALLOC_GROW(done_pbase_paths,
1297   done_pbase_paths_num + 1,

** CID 1415507:  Null pointer dereferences  (FORWARD_NULL)
/builtin/pack-objects.c: 1303 in check_pbase_path()



*** CID 1415507:  Null pointer dereferences  (FORWARD_NULL)
/builtin/pack-objects.c: 1303 in check_pbase_path()
1297   done_pbase_paths_num + 1,
1298   done_pbase_paths_alloc);
1299done_pbase_paths_num++;
1300if (pos < done_pbase_paths_num)
1301MOVE_ARRAY(done_pbase_paths + pos + 1,
done_pbase_paths + pos,
1302   done_pbase_paths_num - pos - 1);
>>> CID 1415507:  Null pointer dereferences  (FORWARD_NULL)
>>> Dereferencing null pointer "done_pbase_paths".
1303done_pbase_paths[pos] = hash;
1304return 0;
1305 }
1306
1307 static void add_preferred_base_object(const char *name)
1308 {



To view the defects in Coverity Scan visit,
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRb8HAP5hlBzHe8sORKm64S-2F81GsNbRdSrOteP-2FXoviMkw-3D-3D_PwiGIFugGOKqSZ6DZhASdI2SvWKInry4kHBXrJUc9pnRRRwN8fPiR-2BR4LTK2qB-2F8DwbeZJjY7Zg2FBdb8jgiAk7m6rh1YdNCvPYCPUewgRcPRcmkOFDltPB2GLYjg5Pl86kCKSRkx6inI-2BuknVr53Cjba4HgtlWmCuW5A0WMiIFvSKDW3-2BKYfPjiZDMCOFSGSLivQrUyaTeOHAHjl-2FNvbw-3D-3D

To manage Coverity Scan email notifications for "sbel...@google.com",
click 
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4rtNFBzV5kav4CghkcEfRxSYnY6rsKHvgCYp1ThXvyV0VWbGuKIDENjx2sj6ivdYZu-2BNbJM6lgB1oY5D28iuW580xRVIt7xUSma4mf0o8-2BwE-3D_PwiGIFugGOKqSZ6DZhASdI2SvWKInry4kHBXrJUc9pnRRRwN8fPiR-2BR4LTK2qB-2F8ec7P8LTccgviKTLC0eUY7vUYOHaxCJX7GTQpS8ooD-2BtrxVu-2BilxPyHEoqsJLDaUcr6ObouH5nHR8K0ccYTKk6yC1yT-2BgMwWml4OIILno46DqjVrTy1kpeg4B-2BRv4QBTs54v6KZ4s-2FPtTLU3-2BsF7qgg-3D-3D

Fwd: Best practices for updating old repos

2017-06-16 Thread Michael O'Cleirigh 
(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 differences in the surrounding code.

Merging/rebase/cherrypicking directly to the latest upstream sounds
impossible to me.

These conflicts come from the distance between the local fork branch
and the upstream branch.

You need to merge through closer commits first to have a hope of
getting something automatic to work.

Something like getting the list  of releases made in the upstream in
the last 5 years and merging them in order into the fork branch.

i.e. merge v1, merge v2, ... merge v300

I went through something similiar with a subversion repo we converted to git.

In subversion they were cherry picking done work into a release branch.

In git a feature branch mode was being used.

It turned out some commits were never cherry picked and bringing them
to the latest release was hard.

We tried many of the approaches you outlined, took what git would give
us automatically and in the most hairy cases recreated the changes on
the latest upstream by reading the diff of the original commit and
rewriting it on the latest code.

In terms of how the history looks after the merge conflicts are
resolved you could internalize the fixups into a single commit applied
onto the original fork branch.  So that history would show the 130
commit branch directly merged into the upstream.

You would use the git-commit-tree command to reuse the merged tree id
and then use it as a merge commit between the 130th commit id and the
upstream commit id.

Regards,

Michael

On Thu, Jun 15, 2017 at 8:52 PM, Michael Eager  wrote:
>
> Hi All --
>
> I'm working with code that is based on a five year old repository.
> There are 130 local commits since the repo was forked.  Naturally,
> the upstream project has moved on significantly.
>
> I'm wondering about best approaches to updating the repo to the
> current upstream version.  Here are the approaches I've considered:
>
> - Rebase from upstream.  Likely almost every patch will fail with
>   multiple merge conflicts.
>
> - Merge local branch into upstream.  Likely many merge failures, but
>   fewer than with rebase.
>
> - Apply individual patches from the old repo to the upstream repo.
>   Fix merge conflicts, rebuild, fix build failures.  There may be
>   some duplication and additional merge problems created, where a
>   later patch from the old repo fixes the same conflict or build
>   failure.
>
> I've tried each of these approaches on various projects.  Each has
> problems. After resolving merge issues there are build failures which
> need to be resolved and additional patches created.  The result is
> that the patch history is a bit chaotic, where there are later patches
> which fix problems with early patches.  I've tried to sort the fix
> patches to follow the patch they correct, so that the fixes were
> together and I could merge them, but that can be difficult.
>
> I've used Stacked Git a little, but don't know if it will make
> any of this easier.
>
> On some projects, I've reimplemented changes in the upstream repo,
> abandoning the patch history from the old repo:
>
> - Create diff of old repo and upstream.  Apply only the changes
>   to add new functionality, which are in the patches to the
>   old repo.   Fix problems caused by API changes, renamed files, etc.
>
> - Re-implement the changes on the upstream repo.  Some of the old
>   code would be re-used, but modified to fit in the current upstream.
>   Some new code would be written.
>
> One other variant of the rebase approach I've thought of is to do
> this incrementally, rebasing the old repo against an upstream commit
> a short time after the old repo was forked, fixing any conflicts,
> rebuilding and fixing build failures.  Then repeat, with a bit
> newer commit.  Then repeat, until I get to the top.  This sounds
> tedious, but some of it can be automated.  It also might result in
> my making the changes compatible with upstream code which was later
> abandoned or significantly changed.
>
> Anyone have a different approach that I should consider?  Or maybe
> offer advice on how to make one of these approaches work better?
> What is best practice to update an old repo?
>
> --
> Michael Eagerea...@eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Fwd: Git p4 sync changelist interval

2017-06-05 Thread Андрей Ефанов 
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 initial commit.
> > So I used the following command:
> >
> >  git p4 clone //depot@cl1,cl2
> >
> > And when it finished, the files, that were created before the cl1 were
> > not in the HEAD.
>
> Do you mean that if foo.c was created at cl1+1, that after doing the
> clone, it wasn't there?
>
> If so, that doesn't sound right to me.
>
> I have just tried doing what I think you mean:
>
> 1. Create p4 depot
> 2. Add foo.c (at CL 2)
> 3. Add bar.c (at CL 3)
> 4. git-p4 clone //depot@2,3
>
> I end up with both files.
>
> >
> > The problem, as I see it, is that before syncing changes in the given
> > range, p4 task does not sync to cl1 version of the repo, and applies
> > commits to the empty repository.
> > Is it a bug or my misunderstanding of how git p4 should work?
>
> Possibly I'm misunderstanding what you're doing! Can you give a
> sequence of steps to show the problem?

What I meant is:

1. Create p4 depot
2. Add first.file (CL 2)
3. Add second.file (at CL 3)
4. Add third.file (at CL 4)
5. Modify first.file (at CL 5)
4. git-p4 clone //depot@3,5

In this case first.file, will not be represented in the repository.

Regards,
Andrew

Re: Fwd: Failed shallow submodule clone for fixed SHA1 falls back to checking out HEAD

2017-04-18 Thread Sebastian Schuberth 

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 more interested in "less data" rather than
"correct data" because otherwise you would not have asked for shallow.


I do believe this is an awkward choice. What does it help to get less 
data if it's the wrong data?


--
Sebastian Schuberth

Fwd: Failed shallow submodule clone for fixed SHA1 falls back to checking out HEAD

2017-04-18 Thread Stefan Beller 
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/external/jgnash"]
>path = src/funTest/resources/projects/external/jgnash
>url = https://github.com/ccavanaugh/jgnash.git
>shallow = true
> ---8<---
>
> and configured the submodule to checkout commit 
> 2aa4cce7d7fd46164030f2b4d244c4b89e77f722 [1]. When doing a fresh clone of my 
> superproject via "git clone --recursive" I get
>
> ---8<---
> error: Server does not allow request for unadvertised object 
> 2aa4cce7d7fd46164030f2b4d244c4b89e77f722
> Fetched in submodule path 'src/funTest/resources/projects/external/jgnash', 
> but it did not contain 2aa4cce7d7fd464030f2b4d244c4b89e77f722. Direct 
> fetching of that commit failed.
> ---8<---
>
> So far so good, it simply seems that GitHub does not support 
> allowReachableSHA1InWant [2].

Maybe the error message should say so: "Bug your host admin to enable
allowReachableSHA1InWant".

> The interesting bit is that my submodule checkout still ends up being 
> shallow, but poiting to HEAD:
>
> ---8<---
> $ cd src/funTest/resources/projects/external/jgnash
> $ git log
> commit 12036fffb6c620515edd96416363fd1749b5d003 (grafted, HEAD -> master, 
> origin/master, origin/HEAD)
> Author: Craig Cavanaugh 
> Date:   Tue Apr 18 05:33:06 2017 -0400
>
> Fix typos
> ---8<---
>
> 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 more interested in "less data" rather than
"correct data" because otherwise you would not have asked for shallow.

> At least I'd be getting what I asked for in that case, even if at the cost of 
> additional network traffic. Because if I read [3] correctly, the command line 
> option belonging to "submodule..shallow" is called 
> "--[no-]recommend-shallow", i.e. it's only a recommendation, to falling back 
> to a full clone should be fine.

Heh, good point. Currently that option is more like a
"--[no-]follow-shallow-in-gitmodules" without second thought as the
"recommend" would elude to.

Thanks,
Stefan

>
> [1] 
> https://github.com/ccavanaugh/jgnash/commit/2aa4cce7d7fd46164030f2b4d244c4b89e77f722
> [2] 
> https://git-scm.com/docs/git-config#git-config-uploadpackallowReachableSHA1InWant
> [3] https://git-scm.com/docs/git-submodule
>
> Regards,
> Sebastian
>

Fwd: Errors running gitk on OS X

2017-04-15 Thread Uxío Prego 
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 
__exceptionPreprocess + 171
1   libobjc.A.dylib 0x7fffe58f2cad 
objc_exception_throw + 48
2   CoreFoundation  0x7fffd120e96d 
+[NSException raise:format:] + 205
3   QuartzCore  0x7fffd6d35520 
_ZN2CA5Layer12set_positionERKNS_4Vec2IdEEb + 152
4   QuartzCore  0x7fffd6d35695 -[CALayer 
setPosition:] + 44
5   QuartzCore  0x7fffd6d35ceb -[CALayer 
setFrame:] + 644
6   CoreUI  0x7fffdcafd4ce 
_ZN20CUICoreThemeRenderer26MakeOrUpdateScrollBarLayerEPK13CUIDescriptoraPP7CALayer
 + 1284
7   CoreUI  0x7fffdcaf94c3 
_ZN20CUICoreThemeRenderer19CreateOrUpdateLayerEPK13CUIDescriptorPP7CALayer + 
1595
8   CoreUI  0x7fffdca7a58d 
_ZN11CUIRenderer19CreateOrUpdateLayerEPK14__CFDictionaryPP7CALayer + 175
9   CoreUI  0x7fffdca7d241 
CUICreateOrUpdateLayer + 221
10  AppKit  0x7fffcf7bc21f 
-[NSCompositeAppearance _callCoreUIWithBlock:options:] + 226
11  AppKit  0x7fffcee620b3 
-[NSAppearance _createOrUpdateLayer:options:] + 76
12  AppKit  0x7fffcf0da71f 
-[NSScrollerImp _animateToRolloverState] + 274
13  AppKit  0x7fffcf09a0f9 
__49-[NSScrollerImp _installDelayedRolloverAnimation]_block_invoke + 673
14  AppKit  0x7fffcef602c5 
-[NSScrollerImp _doWork:] + 15
15  Foundation  0x7fffd2b6ec88 
__NSFireDelayedPerform + 417
16  CoreFoundation  0x7fffd110fd74 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
17  CoreFoundation  0x7fffd110f9ff 
__CFRunLoopDoTimer + 1071
18  CoreFoundation  0x7fffd110f55a 
__CFRunLoopDoTimers + 298
19  CoreFoundation  0x7fffd1106f81 
__CFRunLoopRun + 2065
20  CoreFoundation  0x7fffd1106514 
CFRunLoopRunSpecific + 420
21  Tcl 0x000106fe5b43 
Tcl_WaitForEvent + 314
22  Tcl 0x000106fb55cd 
Tcl_DoOneEvent + 274
23  Tk  0x000106e1ef4f Tk_MainLoop 
+ 33
24  Tk  0x000106e2aa5b Tk_MainEx + 
1566
25  Wish0x000106dfe55a Wish + 9562
26  libdyld.dylib   0x7fffe61d1255 start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
/usr/bin/wish: line 2:  3344 Abort trap: 6   "$(dirname 
$0)/../../System/Library/Frameworks/Tk.framework/Versions/8.5/Resources/Wish.app/Contents/MacOS/Wish"
 "$@"
bash-4.4$

I think it is new - I do not really care as long as is working mint on Linux.
Please pardon the 80th column limit exceed.

> Begin forwarded message:
> 
> From: Evan Aad 
> Subject: Errors running gitk on OS X
> Date: 13 April 2017 at 19:03:45 GMT+2
> To: git@vger.kernel.org
> 
> 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)/../../../Library/Frameworks/Tk.framework/Versions/8.5/Resources/Wish.app/Contents/MacOS/Wish"
>>  "$@"
> 
> Additionally, the following error message pops up in a window:
> 
>> Wish quit unexpectedly.
> 
>> Click Reopen to open the application again. Click Report to see more 
>> detailed information and send a report to Apple.
> 
>> Ignore | Report... | Reopen
> 
> How can this be fixed?
> 
> ***
> 
> OS: macOS Sierra, Version 10.12.4
> Git version: 2.11.0 (Apple Git-81)

Fwd: Errors running gitk on OS X

2017-04-13 Thread EvenEven Odd 
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)/../../../Library/Frameworks/Tk.framework/Versions/8.5/Resources/Wish.app/Contents/MacOS/Wish"
>  "$@"

Additionally, the following error message pops up in a window:

> Wish quit unexpectedly.

> Click Reopen to open the application again. Click Report to see more detailed 
> information and send a report to Apple.

> Ignore | Report... | Reopen

How can this be fixed?

***

OS: macOS Sierra, Version 10.12.4
Git version: 2.11.0 (Apple Git-81)

Re: Fwd: HTTP Dumb Push?

2017-03-06 Thread Jeff King 
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 goes over DAV. There are instructions in
Documentation/howto/setup-git-server-over-http.txt of the git
repository. They're quite old now, and I have no idea if they've
bit-rotted over the years. Hardly anybody uses that solution these days
(and it's much less efficient than the smart protocol).

> If that isn't an option, where can I get a smart server?

The CGI ships with the rest of git.  Try "git help http-backend", which
has some sample config for Apache and lighttpd.

-Peff

Fwd: HTTP Dumb Push?

2017-03-06 Thread Christian7573 
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?

Fwd: Re: feature request: user email config per domain

2017-02-23 Thread Igor Djordjevic 
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 based on the working tree path, like
Duy's conditional config includes. Then you write something in your
~/.gitconfig

> This would allow you to have two root directories, one for your work
projects and one for open source projects (for example).

I guess this can be extended for any number of root directories. Like,
when a consultant has multiple employer email ids.

This sounds great and it would enforce at commit time, which as
pointed out, is the correct time to do it. If for some reason it is
not adopted I at least hope that we have a simple global config which
specifies that user must set email for each repo and to ignore any
global config.

Am sure this can be done via hooks, but I would like something that is
really simple for newbies and companies to enforce with minimal
instruction.

* Will try what Igor and Grant Humphries suggests.

* Thank you all for your replies, and a big thank you for git - its a
great tool. I used to dream of something like it when I was stuck with
svn (pre 2010 I was introduced to git late.)


[1] http://stackoverflow.com/a/42354282
[2] http://stackoverflow.com/users/2167004

Re: Fwd: Typo in worktree man page

2017-02-22 Thread brian m. carlson 
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: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Fwd: Typo in worktree man page

2017-02-21 Thread Casey Rodarmor 
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

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-09 Thread Duy Nguyen 
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 "negative" element involved, it
> does not matter if we feed CWD or FULL.

Yes. Now that you put it that way, it may make more sense to rename
the options to PATHSPEC_DEFAULT_* instead of PATHSPEC_PREFER_*.

>  - builtin/checkout.c::cmd_checkout(), when argc==0, does not call
>parse_pathspec().  This codepath will get affected by Linus's
>change ("cd t && git checkout :\!perf" would try to check out
>everything except t/perf, but what is a reasonable definition of
>"everything" in the context of this command).  We need to
>decide, and I am leaning towards preferring CWD for this case.

So far I have seen arguments with single negative pathspec as
examples. What about "cd t; git checkout :^perf :^../Documentation"?
CWD is probably not the best base to be excluded from. Maybe the
common prefix of all negative pathspecs? But things start to get a bit
unintuitive on that road. Or do will still bail out on multiple
negative pathspecs with no positive one?

Also, even with single negative pathspec, what about "cd t; git
checkout :^../ewah"?

> So, I am tempted to suggest us doing the following:
>
>  * Leave a NEEDSWORK comment to archive.c::path_exists() that is
>used for checking the validation of pathspec elements.  To fix it
>properly, we need to be able to skip a negative pathspec to be
>passed to this function by the caller, and to do so, we need to
>expose a helper from the pathspec API that gets a single string
>and returns what magic it has, but that is of lower priority.

Side note. There's something else I'm not happy with pathspec handling
in "git archive". Try "cd t; git archive HEAD -- ../Documentation" and
you'll get a very unfriendly error message. But well, no time for it.

>  * Retire the PATHSPEC_PREFER_CWD bit and replace its use with the
>lack of the PATHSPEC_PREFER_FULL bit.
>
>  * Keep most of the above callsites that currently do not pass
>CWD/FULL as they are, except the ones that should take FULL (see
>above).
>
> Comments?

This comes from my experience reading files-backend.c. I didn't
realize '0' in files_downcast(ref_store, 0, "pack_refs"); meant
'submodule not allowed' because apparently I was too lazy to read
prototype. But if was files_downcast(ref_store, NO_SUBMODULE,
"pack_refs"), it would save people's time.

With that in mind, should we keep _CWD the name, so people can quickly
see and guess that it prefers _CWD than _FULL? _CWD can be defined as
zero. It there's mostly as a friendly reminder.

Other than that, yes if killing one flag helps maintenance, I'm for it.

PS. You may notice I favored ^ over ! already. ! was a pain point for
me too but I was too lazy to bring it up and fight for it. Thanks
Linus.
-- 
Duy

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-09 Thread Duy Nguyen 
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 actually sent
> follow-up patches on this, but I want to pick your brain on one
> thing that is related to this codepath.
>
> We have PATHSPEC_PREFER_CWD and PATHSPEC_PREFER_FULL bits in flags,
> added at fc12261fea ("parse_pathspec: add PATHSPEC_PREFER_{CWD,FULL}
> flags", 2013-07-14), and I think the intent is some commands when
> given no pathspec work on all paths in the current subdirectory
> while others work on the full tree, regardless of where you are.
> "grep" is in the former camp, "log" is in the latter.  And there is
> a check to catch a bug in a caller that sets both.
>
> I am wondering about this hunk (this is from the original commit
> that added it):
>
> if (!entry) {
> static const char *raw[2];
>
> +   if (flags & PATHSPEC_PREFER_FULL)
> +   return;
> +
> +   if (!(flags & PATHSPEC_PREFER_CWD))
> +   die("BUG: PATHSPEC_PREFER_CWD requires arguments");
> +
> pathspec->items = item = xmalloc(sizeof(*item));
> memset(item, 0, sizeof(*item));
> item->match = prefix;
> ... returns a single entry pathspec to cover cwd ...
>
> The BUG message is given when
>
>  - The command got no pathspec from the caller; and
>  - PATHSPEC_PREFER_FULL is not set; and
>  - PATHSPEC_PREFER_CWD is NOT set.
>
> but the message says that the caller must have args when it sets
> prefer-cwd.  Is this a simple typo?  If so what should it say?
>
> die("BUG: one of PATHSPEC_PREFER_FULL or _CWD must be set");

Without reading through your next mail, I'd say "BUG: this command
requires arguments".

> Does this third possibility (i.e. a caller is allowed to pass
> "flags" that does not prefer either) exist to support a command
> where the caller MUST have at least one pathspec?  If that were the
> case, this wouldn't be a BUG but an end-user error, e.g.
>
> die("at least one pathspec element is required");

Or this. Yes. I might have just been defensive at then and kept the
third option open.

> 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.

I don't usually remember what I ate yesterday and this commit was from
2013 :D But I'll see if your findings spark anything in my brain.
-- 
Duy

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-08 Thread Junio C Hamano 
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 conclusion.

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 "negative" element involved, it
does not matter if we feed CWD or FULL.

There are only a handful of callers that pass neither preference
bits to parse_pathspec().  Here are my observations on them that
tells me that most of them are OK if we change them to prefer
either CWD or FULL:

 - archive.c::path_exists() feeds a pathspec with a single element
   to see if read_tree_recursive() finds any matching paths, to
   allow its caller to iterate over the original pathspec and see
   if there is a typo (i.e. an element that matches nothing).  It
   should prefer FULL to match what parse_pathspec_arg(), its
   caller, uses.

   The caller probably should refrain from passing ones with
   negative magic.  I.e. "git archive -- t :\!t/perf" errors out
   because checking each element independently in the loop means
   that ":\!t/perf" is checked alone, triggering "there is nothing
   to exclude from".

 - blame.c::find_origin() feeds a pathspec with a single element,
   which is a path in the history and does so as a literal, hence
   no room for "negative" to kick in.

 - builtin/check-ignore.c::check_ignore(), when argc==0, does not
   call parse_pathspec().  It does not take any magic other than
   FROMTOP, so "negative" won't come into the picture.

 - builtin/checkout.c::cmd_checkout(), when argc==0, does not call
   parse_pathspec().  This codepath will get affected by Linus's
   change ("cd t && git checkout :\!perf" would try to check out
   everything except t/perf, but what is a reasonable definition of
   "everything" in the context of this command).  We need to
   decide, and I am leaning towards preferring CWD for this case.

 - revision.c::setup_revisions() calls parse_pathspec() only when
   the caller gave a non-empty pathspec.  This pathspec is used for
   pruning log traversal (e.g. "only show commits that touch these
   paths") and is affected by Linus's change.  It should favor
   FULL.

 - tree-diff.c::try_to_follow_renames() feeds a pathspec with a
   single element as a literal, hence no room for "negative" to
   kick in.

So, I am tempted to suggest us doing the following:

 * Leave a NEEDSWORK comment to archive.c::path_exists() that is
   used for checking the validation of pathspec elements.  To fix it
   properly, we need to be able to skip a negative pathspec to be
   passed to this function by the caller, and to do so, we need to
   expose a helper from the pathspec API that gets a single string
   and returns what magic it has, but that is of lower priority.

 * Retire the PATHSPEC_PREFER_CWD bit and replace its use with the
   lack of the PATHSPEC_PREFER_FULL bit.

 * Keep most of the above callsites that currently do not pass
   CWD/FULL as they are, except the ones that should take FULL (see
   above).

Comments?

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-08 Thread Junio C Hamano 
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 on one
thing that is related to this codepath.

We have PATHSPEC_PREFER_CWD and PATHSPEC_PREFER_FULL bits in flags,
added at fc12261fea ("parse_pathspec: add PATHSPEC_PREFER_{CWD,FULL}
flags", 2013-07-14), and I think the intent is some commands when
given no pathspec work on all paths in the current subdirectory
while others work on the full tree, regardless of where you are.
"grep" is in the former camp, "log" is in the latter.  And there is
a check to catch a bug in a caller that sets both.

I am wondering about this hunk (this is from the original commit
that added it):

if (!entry) {
static const char *raw[2];
 
+   if (flags & PATHSPEC_PREFER_FULL)
+   return;
+
+   if (!(flags & PATHSPEC_PREFER_CWD))
+   die("BUG: PATHSPEC_PREFER_CWD requires arguments");
+
pathspec->items = item = xmalloc(sizeof(*item));
memset(item, 0, sizeof(*item));
item->match = prefix;
... returns a single entry pathspec to cover cwd ...

The BUG message is given when 

 - The command got no pathspec from the caller; and
 - PATHSPEC_PREFER_FULL is not set; and
 - PATHSPEC_PREFER_CWD is NOT set.

but the message says that the caller must have args when it sets
prefer-cwd.  Is this a simple typo?  If so what should it say?

die("BUG: one of PATHSPEC_PREFER_FULL or _CWD must be set");

If that were the case, we are expressing only one bit of information
(do we limit to cwd, or do we work on full-tree?), but there must
have been a reason why we added two bits and made them mutually
incompatible so that we can express three possibilities.

Does this third possibility (i.e. a caller is allowed to pass
"flags" that does not prefer either) exist to support a command
where the caller MUST have at least one pathspec?  If that were the
case, this wouldn't be a BUG but an end-user error, e.g.

die("at least one pathspec element is required");

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.

Thanks.

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Duy Nguyen 
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

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Linus Torvalds 


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 will grab hits from ../Documentation/ etc.  We need to pay
> attention to PATHSPEC_PREFER_CWD bit in the flags word, I think.

Ok, that's easy enough.

Two-patch series to follow.

  Linus

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Junio C Hamano 
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 point no amount of "but but think about set theory" will
> matter, methinks.

I do not feel too strongly about it, either, but when we invoke
"what would people who go down into subdirectories expect", the
issue becomes a lot bigger.

"git diff/log" without any pathspec in a subdirectory still shows
the whole diff.  "git grep" looks for hits inside that subdirectory,
on the other hand.

I think the former design decision is mostly a historical accident.
"The project tree as the whole is what matters" was one reason, and
another is that historically we didn't have ":/"--defaulting to the
whole tree and telling people to give "." was easier than defaulting
to the current and telling people to give "../.." after counting how
many levels deep you started at.  If we were designing the system
today with "." and ":/", I wouldn't be surprised if we chose "always
limit to cwd if there is no pathspec" for any command for the sake
of consistency.  We can easily say "if you want whole-tree, pass :/"
instead.

But we do not live in that world, and I do not think change them to
make things consistent is what we are discussing in this thread.
Given users accept and expect that "diff" without pathspec is whole
tree, while "grep" without pathspec is limited to cwd, what is the
reasonable definition of "everything from which negative ones are
excluded"?  That is the question I am trying to answer.

As Mike mentioned earlier in the thread, if we used "." (limit to
cwd) for "diff/log" when there are only negative pathspec elements,
the resulting UI would become inconsistent within a single command,
as in my world view, giving no pathspec means "work on everything
you would ordinarily work on", a positive pathspec means "among
everything you would ordinarily work on, only work on the ones that
match this pattern", and giving only a negative one ought to mean
"among everything you would ordinarily work on, only work on the
ones that do NOT match this pattern."

>  pathspec.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/pathspec.c b/pathspec.c
> index 7ababb315..2a91247bc 100644
> --- a/pathspec.c
> +++ b/pathspec.c
> @@ -224,6 +224,12 @@ static const char *parse_short_magic(unsigned *magic, 
> const char *elem)
>   char ch = *pos;
>   int i;
>  
> + // Special case alias for '!'

/* style? */

> + if (ch == '^') {
> + *magic |= PATHSPEC_EXCLUDE;
> + continue;
> + }
> +
>   if (!is_pathspec_magic(ch))
>   break;
>  
> + /*
> +  * If everything is an exclude pattern, add one positive pattern
> +  * that matches everyting. We allocated an extra one for this.
> +  */
> + if (nr_exclude == n) {
> + init_pathspec_item(item + n, 0, "", 0, "");
> + pathspec->nr++;
> + }

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 will grab hits from ../Documentation/ etc.  We need to pay
attention to PATHSPEC_PREFER_CWD bit in the flags word, I think.

A real change probably wants to become a two-patch series (one for
the new :^ alias, the other is for "everything except...") with log
message ;-)

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Linus Torvalds 
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 cmd -- ":!net/"
>
> should have no overlap (obviously) and when you take union of the
> two sets, that should equal to
>
> git cmd --
>
> i.e. no pathspecs.

Well, as mentioned, I won't ever care. I'm certainly ok with the "make
the default positive entry be everything".

I just suspect that from a user perspective that actually delves into
the subdirectories, the much bigger question will be: "I gave you a
pathspec, and suddenly you start giving me stuff from outside the area
entirely".

And then you can say "well, just add '.' to the pathspec", and you'd
be right, but I still think it's not what a naive user would expect.

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 point no amount of "but but think about set theory" will
matter, methinks.

But I really don't feel strongly about it. The path I sent out (and
the slightly modified version attached in this email) actually acts
the way you suggest. It's certainly the simplest implementation. I
just suspect it's not the implementation people who go down into
subdirectories would want/expect.

>>>  2. I am not sure what ctype.c change is about.  Care to elaborate?
>>
>> I didn't see the need for it either until I made the rest of the
>> patch, and it didn't work at all.
>>
>> The pathspec.c code uses "if (is_pathspec_magic(..))" to test whether
>> a character is a short magiic pathspec character.  But '^' wasn't in
>> that set, because it was already marked as being (only) in the regex
>> set.
>>
>> Does that whole is_pathspec_magic() thing make any sense when we have
>> an array that specifies the special characters we react to? No it does
>> not.
>>
>> But it is what the code does, and I just made that code work.
>
> Ah, OK.

Side note: here's an alternative patch that avoids that issue
entirely, and also avoids a problem with prefix_magic() being uphappy
when one bit shows up multiple times in the array.

It's slightly hacky in parse_short_magic(), but it's smaller and
simpler, and avoids the two subtle cases. No need for ctype changes,
and no issues with prefix_magic() being somewhat stupid.

   Linus
 pathspec.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/pathspec.c b/pathspec.c
index 7ababb315..2a91247bc 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -224,6 +224,12 @@ static const char *parse_short_magic(unsigned *magic, 
const char *elem)
char ch = *pos;
int i;
 
+   // Special case alias for '!'
+   if (ch == '^') {
+   *magic |= PATHSPEC_EXCLUDE;
+   continue;
+   }
+
if (!is_pathspec_magic(ch))
break;
 
@@ -516,7 +522,7 @@ void parse_pathspec(struct pathspec *pathspec,
}
 
pathspec->nr = n;
-   ALLOC_ARRAY(pathspec->items, n);
+   ALLOC_ARRAY(pathspec->items, n+1);
item = pathspec->items;
prefixlen = prefix ? strlen(prefix) : 0;
 
@@ -540,10 +546,14 @@ void parse_pathspec(struct pathspec *pathspec,
pathspec->magic |= item[i].magic;
}
 
-   if (nr_exclude == n)
-   die(_("There is nothing to exclude from by :(exclude) 
patterns.\n"
- "Perhaps you forgot to add either ':/' or '.' ?"));
-
+   /*
+* If everything is an exclude pattern, add one positive pattern
+* that matches everyting. We allocated an extra one for this.
+*/
+   if (nr_exclude == n) {
+   init_pathspec_item(item + n, 0, "", 0, "");
+   pathspec->nr++;
+   }
 
if (pathspec->magic & PATHSPEC_MAXDEPTH) {
if (flags & PATHSPEC_KEEP_ORDER)

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Junio C Hamano 
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 pathspec very
> much acts as relative to the cwd.

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 cmd -- ":!net/"

should have no overlap (obviously) and when you take union of the
two sets, that should equal to

git cmd --

i.e. no pathspecs.

>>  2. I am not sure what ctype.c change is about.  Care to elaborate?
>
> I didn't see the need for it either until I made the rest of the
> patch, and it didn't work at all.
>
> The pathspec.c code uses "if (is_pathspec_magic(..))" to test whether
> a character is a short magiic pathspec character.  But '^' wasn't in
> that set, because it was already marked as being (only) in the regex
> set.
>
> Does that whole is_pathspec_magic() thing make any sense when we have
> an array that specifies the special characters we react to? No it does
> not.
>
> But it is what the code does, and I just made that code work.

Ah, OK.

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Mike Hommey 
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 subdirectory. So I'd suggest that in the absence
> >   of any positive pattern, there is simply no filtering at all, so
> >   whenever I say '.' as a pattern, I really meant ":(top)." which is
> >   even more of a cumbersom syntax that the current model really
> >   encourages. Crazy. Since I tend to always work in the top directory,
> >   the two are the same for me ]
> 
> 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.
> 
> Now _I_ don't much care, since I only work from the top level, but without 
> the "." behavior, you get into an odd situation that the negative match 
> will be relative to the current directory, but then the positive matches 
> will be everywhere else. 
> 
> Obviously, a negative match that has "top" set would change that logic. So 
> this patch is purely a request for further discussion.
> 
> When I wrote the patch, I actually also removed the now stale entries from 
> the 'po' files, but I'm not including that part here because it just 
> distracts from the meat of it all. So this diff was actually generated 
> with the new syntax:
> 
>   git diff -p --stat -- :^po/
> 
> and the only thing even remotely subtle here is that it changes our ctype 
> array to make '^' be both a regex and a pathspec magic character.
> 
> Everything else should be pretty darn obvious.
> 
> The code *could* just track all the 'relative to top or not' bits in the 
> exclusion pattern, and then use whatever top-ness the exclusion patterns 
> have (and maybe fall back to the old warning if it had a mixture of 
> exclusionary patterns). I'll happily change it to act that way if people 
> think that makes sense.
> 
> Comments?

It seems to me that `git diff` and `git diff -- :^stuff` should have the
same output if there aren't changes in stuff, and `git diff` does the
same as `git diff -- :/` if you are in a subdirectory, not the same as
`git diff .`.

As such, the default positive match should be ':/' (which is shorter and
less cumbersome than ':(top)', btw)

Mike

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Mike Hommey 
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 actually very counter-intuitive in a subdirectory.
> 
> Git doesn't do much of that, but let me give you an example from the
> kernel. Again, this is not an example of anything I would do (because
> I'm always at the top), but:
> 
>   [torvalds@i7 linux]$ cd drivers/
>   [torvalds@i7 drivers]$ ll
> 
>   .. whee, *lots* of diorectories ..
>   .. lets see what happened in net/ ..
> 
>   [torvalds@i7 drivers]$ git diff -M --dirstat=1,cumulative
> v4.10-rc6..v4.10-rc7 -- net/
>  7.4% drivers/net/ethernet/adaptec/
> 47.9% drivers/net/ethernet/cadence/
>  7.1% drivers/net/ethernet/emulex/benet/
>  1.1% drivers/net/ethernet/freescale/
>  3.6% drivers/net/ethernet/mellanox/mlx4/
> 23.5% drivers/net/ethernet/mellanox/mlx5/core/
> 27.2% drivers/net/ethernet/mellanox/
> 92.5% drivers/net/ethernet/
>  5.3% drivers/net/wireless/intel/iwlwifi/mvm/
>  5.9% drivers/net/wireless/intel/iwlwifi/
>100.0% drivers/net/
> 
>   .. let's see what happened *outside* of net/ ..
> 
> [torvalds@i7 drivers]$ git diff -M --dirstat=1,cumulative
> v4.10-rc6..v4.10-rc7 -- :^net/
>2.4% arch/arm64/crypto/
>2.1% arch/powerpc/include/asm/
>1.5% arch/powerpc/kernel/
>3.9% arch/powerpc/
>3.5% arch/sparc/kernel/
>4.1% arch/sparc/
>8.3% arch/x86/events/intel/
>1.7% arch/x86/kernel/cpu/mcheck/
>1.6% arch/x86/kernel/cpu/microcode/
>3.3% arch/x86/kernel/cpu/
>3.8% arch/x86/kernel/
>1.0% arch/x86/platform/efi/
>   13.3% arch/x86/
>   24.0% arch/
>1.1% drivers/base/
>2.9% drivers/dma/
>   12.3% drivers/gpu/drm/i915/
>1.0% drivers/gpu/drm/nouveau/
>   16.2% drivers/gpu/drm/
>3.9% drivers/hid/
>1.6% drivers/iio/
>2.3% drivers/regulator/
>...
> 
> Notice? When you say "show only the net subdirectory" it does the
> obvious thing relative to the current working directory, but if you
> say "show everything _but_ the net subdirectory" it suddenly starts
> showing other things.

I can totally see how this can be confusing, but the case can be made
that the problem is that `git diff` would be showing everything if you
didn't pass an exclusion list. Now, what you're suggesting introduces
some inconsistency, which, in itself, can cause confusion.

I'm not sure which confusion is worse.

Mike

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Linus Torvalds 
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 of "everything" to that.
> IOW, "cd t && git grep -e foo" shows everything in t/ directory,
> so the default you would add would be "." for "grep"; "cd t &&
> git diff HEAD~100 HEAD" would show everything, so you would give
> ":(top)." for "diff".

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 pathspec very
much acts as relative to the cwd.

So no, absolute (ie ":(top)" or ":/") doesn't actually make sense for
"diff" either, even though diff by default is absolute when not given
a pathname at all.

But if you do

  cd drivers
  git diff A..B -- :^/arch

then suddenly an absolute positive root _does_ make sense,. because
now the negative pathspec was absolute..

Odd? Yes it is. But the positive pathspec rules are what they are, and
they are actually what I suspect everybody really wants. The existing
negative ones match the rules for the positive ones.

So I suspect that the best thing is if the "implicit positive rule
when there are no explicit ones" ends up matching the same semantics
as the (explicit) negative entries have..

>  2. I am not sure what ctype.c change is about.  Care to elaborate?

I didn't see the need for it either until I made the rest of the
patch, and it didn't work at all.

The pathspec.c code uses "if (is_pathspec_magic(..))" to test whether
a character is a short magiic pathspec character.  But '^' wasn't in
that set, because it was already marked as being (only) in the regex
set.

Does that whole is_pathspec_magic() thing make any sense when we have
an array that specifies the special characters we react to? No it does
not.

But it is what the code does, and I just made that code work.

>  3. I think our recent trend is to wean ourselves away from "an
> empty element in pathspec means all paths match", and I think we
> even have accepted a patch to emit a warning.  Doesn't the
> warning trigger for the new code below?

It didn't trigger for me in my testing, I suspect the warning is at an
earlier level when it walks through the argv[] array and fills in the
pathspec arrays. But I didn't actually look for it.

   Linus

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Linus Torvalds 
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 let me give you an example from the
kernel. Again, this is not an example of anything I would do (because
I'm always at the top), but:

  [torvalds@i7 linux]$ cd drivers/
  [torvalds@i7 drivers]$ ll

  .. whee, *lots* of diorectories ..
  .. lets see what happened in net/ ..

  [torvalds@i7 drivers]$ git diff -M --dirstat=1,cumulative
v4.10-rc6..v4.10-rc7 -- net/
 7.4% drivers/net/ethernet/adaptec/
47.9% drivers/net/ethernet/cadence/
 7.1% drivers/net/ethernet/emulex/benet/
 1.1% drivers/net/ethernet/freescale/
 3.6% drivers/net/ethernet/mellanox/mlx4/
23.5% drivers/net/ethernet/mellanox/mlx5/core/
27.2% drivers/net/ethernet/mellanox/
92.5% drivers/net/ethernet/
 5.3% drivers/net/wireless/intel/iwlwifi/mvm/
 5.9% drivers/net/wireless/intel/iwlwifi/
   100.0% drivers/net/

  .. let's see what happened *outside* of net/ ..

[torvalds@i7 drivers]$ git diff -M --dirstat=1,cumulative
v4.10-rc6..v4.10-rc7 -- :^net/
   2.4% arch/arm64/crypto/
   2.1% arch/powerpc/include/asm/
   1.5% arch/powerpc/kernel/
   3.9% arch/powerpc/
   3.5% arch/sparc/kernel/
   4.1% arch/sparc/
   8.3% arch/x86/events/intel/
   1.7% arch/x86/kernel/cpu/mcheck/
   1.6% arch/x86/kernel/cpu/microcode/
   3.3% arch/x86/kernel/cpu/
   3.8% arch/x86/kernel/
   1.0% arch/x86/platform/efi/
  13.3% arch/x86/
  24.0% arch/
   1.1% drivers/base/
   2.9% drivers/dma/
  12.3% drivers/gpu/drm/i915/
   1.0% drivers/gpu/drm/nouveau/
  16.2% drivers/gpu/drm/
   3.9% drivers/hid/
   1.6% drivers/iio/
   2.3% drivers/regulator/
   ...

Notice? When you say "show only the net subdirectory" it does the
obvious thing relative to the current working directory, but if you
say "show everything _but_ the net subdirectory" it suddenly starts
showing other things.

Now, it would be easy enough to say "if you don't give a positive
path, we'll just use the empty path that matches the negative paths".
So if you ask for a negative relative "net" directory, we'll use the
relative empty path. And if you ask for a negative absolute path,
we'll use the empty absolute path.

It's a couple of lines more, and I think it might avoid some confusion.

And I suspect almost nobody has ever done any of this before,. because
the syntax was/is so cumbersome.

Linus

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Junio C Hamano 
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.
> ...
>
> Comments?

 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 of "everything" to that.
IOW, "cd t && git grep -e foo" shows everything in t/ directory,
so the default you would add would be "." for "grep"; "cd t &&
git diff HEAD~100 HEAD" would show everything, so you would give
":(top)." for "diff".

 2. I am not sure what ctype.c change is about.  Care to elaborate?

 3. I think our recent trend is to wean ourselves away from "an
empty element in pathspec means all paths match", and I think we
even have accepted a patch to emit a warning.  Doesn't the
warning trigger for the new code below?

> - if (nr_exclude == n)
> - die(_("There is nothing to exclude from by :(exclude) 
> patterns.\n"
> -   "Perhaps you forgot to add either ':/' or '.' ?"));
> -
> + /*
> +  * If everything is an exclude pattern, add one positive pattern
> +  * that matches everyting. We allocated an extra one for this.
> +  */
> + if (nr_exclude == n) {
> + init_pathspec_item(item + n, 0, "", 0, "");
> + pathspec->nr++;
> + }
>  
>   if (pathspec->magic & PATHSPEC_MAXDEPTH) {
>   if (flags & PATHSPEC_KEEP_ORDER)

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Linus Torvalds 


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 is simply no filtering at all, so
>   whenever I say '.' as a pattern, I really meant ":(top)." which is
>   even more of a cumbersom syntax that the current model really
>   encourages. Crazy. Since I tend to always work in the top directory,
>   the two are the same for me ]

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.

Now _I_ don't much care, since I only work from the top level, but without 
the "." behavior, you get into an odd situation that the negative match 
will be relative to the current directory, but then the positive matches 
will be everywhere else. 

Obviously, a negative match that has "top" set would change that logic. So 
this patch is purely a request for further discussion.

When I wrote the patch, I actually also removed the now stale entries from 
the 'po' files, but I'm not including that part here because it just 
distracts from the meat of it all. So this diff was actually generated 
with the new syntax:

git diff -p --stat -- :^po/

and the only thing even remotely subtle here is that it changes our ctype 
array to make '^' be both a regex and a pathspec magic character.

Everything else should be pretty darn obvious.

The code *could* just track all the 'relative to top or not' bits in the 
exclusion pattern, and then use whatever top-ness the exclusion patterns 
have (and maybe fall back to the old warning if it had a mixture of 
exclusionary patterns). I'll happily change it to act that way if people 
think that makes sense.

Comments?

Linus

---
 ctype.c|  3 ++-
 pathspec.c | 15 ++-
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/ctype.c b/ctype.c
index fc0225ceb..250e2ce15 100644
--- a/ctype.c
+++ b/ctype.c
@@ -14,6 +14,7 @@ enum {
P = GIT_PATHSPEC_MAGIC, /* other non-alnum, except for ] and } */
X = GIT_CNTRL,
U = GIT_PUNCT,
+   Y = GIT_REGEX_SPECIAL | GIT_PATHSPEC_MAGIC,
Z = GIT_CNTRL | GIT_SPACE
 };
 
@@ -23,7 +24,7 @@ const unsigned char sane_ctype[256] = {
S, P, P, P, R, P, P, P, R, R, G, R, P, P, R, P, /*  32.. 47 */
D, D, D, D, D, D, D, D, D, D, P, P, P, P, P, G, /*  48.. 63 */
P, A, A, A, A, A, A, A, A, A, A, A, A, A, A, A, /*  64.. 79 */
-   A, A, A, A, A, A, A, A, A, A, A, G, G, U, R, P, /*  80.. 95 */
+   A, A, A, A, A, A, A, A, A, A, A, G, G, U, Y, P, /*  80.. 95 */
P, A, A, A, A, A, A, A, A, A, A, A, A, A, A, A, /*  96..111 */
A, A, A, A, A, A, A, A, A, A, A, R, R, U, P, X, /* 112..127 */
/* Nothing in the 128.. range */
diff --git a/pathspec.c b/pathspec.c
index 7ababb315..ef59d080d 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -72,6 +72,7 @@ static struct pathspec_magic {
{ PATHSPEC_GLOB,'\0', "glob" },
{ PATHSPEC_ICASE,   '\0', "icase" },
{ PATHSPEC_EXCLUDE,  '!', "exclude" },
+   { PATHSPEC_EXCLUDE,  '^', "exclude" },
 };
 
 static void prefix_magic(struct strbuf *sb, int prefixlen, unsigned magic)
@@ -516,7 +517,7 @@ void parse_pathspec(struct pathspec *pathspec,
}
 
pathspec->nr = n;
-   ALLOC_ARRAY(pathspec->items, n);
+   ALLOC_ARRAY(pathspec->items, n+1);
item = pathspec->items;
prefixlen = prefix ? strlen(prefix) : 0;
 
@@ -540,10 +541,14 @@ void parse_pathspec(struct pathspec *pathspec,
pathspec->magic |= item[i].magic;
}
 
-   if (nr_exclude == n)
-   die(_("There is nothing to exclude from by :(exclude) 
patterns.\n"
- "Perhaps you forgot to add either ':/' or '.' ?"));
-
+   /*
+* If everything is an exclude pattern, add one positive pattern
+* that matches everyting. We allocated an extra one for this.
+*/
+   if (nr_exclude == n) {
+   init_pathspec_item(item + n, 0, "", 0, "");
+   pathspec->nr++;
+   }
 
if (pathspec->magic & PATHSPEC_MAXDEPTH) {
if (flags & PATHSPEC_KEEP_ORDER)

Re: Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Junio C Hamano 
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 wonderfully.

It is, I think, a no-brainer to lift the "you must have at least one
positive".  If the user says "not this and that", it is reasonable
to assume that "but include everything else" is implied.

As to "!" that triggers history substitution without quoting, it may
be annoying and I think it is probably OK to pick a synonym letter,
perhaps "^", now that the set of pathspec magics do not seem to be
growing rapidly and there may not be any other existing magic that
the natural meaning of "^" would match better than "negate".  The
primary reason why we used ! is, I think, to match patterns in the
exclude files.

As to the leading ":", that is shared between the ":(long form)" and
the short form, I am a bit hesitant to lose it.  It allows the users
to be trained only once, i.e. "if you want to match a path without
magic in your working tree, you need to watch out for an unusual
path that begins with a colon, which may be quite minority to begin
with.  You just prefix ./ in front to defeat it.  Everything else
you can type as-is, modulo wildcard metacharacters, but you know
that already." and their brains need no upgrading.  Once we start
accepting short forms without the ":", every time we add a short
form magic, the users need to be retrained.

In short, this

> Or even just allowing ^ in addition to ! for negation, and otherwise
> keeping the current syntax.

in addition to "no positives?  let's pretend you also said '.' as a
positive", would not be too bad, methinks.  And that allows this

> git diff -M --dirstat .. -- ':!drivers' ':!arch' .

to become

git diff -M --dirstat .. -- :^{drivers,arch}

which is a bit shorter.  I personally am perfectly fine without ^, i.e.

git diff -M --dirstat .. -- :\!{drivers,arch}

though.

By the way, I am wondering why this is private, not cc'ed to the
mailing list.  As messages addressed to gitster@ without git@vger
bypass my Inbox and gets thrown into spam box, which I only
occasionally scan to resurrect messages worth responding, and this
is one of those cases ;-)

Fwd: Possibly nicer pathspec syntax?

2017-02-07 Thread Linus Torvalds 
[ 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 fine, but the syntax for that is just
really cumbersome.

That's due to two issues:

 - the magic characters seem to have been chosen to be annoying on purpose

 - there's an extra "you can't exclude things without having positive
patterns" check

and both of those are rather nasty.

So to explain where I come from, during releases I do things like this:

git diff -M --dirstat=2,cumulative v4.10-rc6..v4.10-rc7

and this is literaly why that "dirstat" diff exists - I find this very
useful for a project like the kernel that has a good hierarchical
directory structure. So the whole dirstat option came about from my
statistics gathering (see more explanations in my original commit
7df7c019c ("Add "--dirstat" for some directory statistics").

However, what often happens for the kernel is that a few big
subsystems end up dominating the discussion (usually drivers and
architecture), and then you want to drill down into everything else to
get that part. Long ago, that used to be painful, and I did things
like

git diff -M --dirstat ... -- $(ls | egrep -v '(drivers)|(arch)')

which works, and gives me the dirstat for stuff that isn't arch or
driver updates.

However, git actually added exclude patterns, and I don't need to do
that crazy thing with shell expansion any more. Now I can do this
crazy thing with git natively instead:

git diff -M --dirstat .. -- ':!drivers' ':!arch' .

but honestly, the git native interface really isn't much simpler than
what I used to do.

Is there really any reason for requiring the '.'?

[ 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 absense
of any positive pattern, there is simply no filtering at all, so
whenever I say '.' as a pattern, I really meant ":(top)." which is
even more of a cumbersom syntax that the current model really
encourages. Crazy. Since I tend to always work in the top directory,
the two are the same for me ]

And did we really have to pick such annoying characters that we need
the shell escaping?

(I never use the other ones with long forms, but they have the same
issue: parenthesis need escaping too, so you have to write them as

':(exclude,icase)drivers'

and you have to remember that a final colon is *not* allowed, and they
still need the escaping).

It really isn't all that wonderful to use from the command line.

In revisions, we use "^" for negation, partly exactly because '!' is
such a nasty character for shell users. With exclusion being the only
case I particularly use, I'd like that for pathspecs too, but maybe
others use icase etc?

IOW, what I'd like to do is just

git diff -M --dirstat .. ^drivers ^arch

without needing the ugly quoting, and without needing the pointless
positive 'match everything else' marker.

Or even just allowing ^ in addition to ! for negation, and otherwise
keeping the current syntax.

[ Clarification from original message, since Junio asked: yes, this
suggestion still assumes the "don't need to specify the positive
pattern", so you could just do

git diff :^drivers

  to avoid the drivers directory ]

Comments? Other ideas?

This is certainly not a high priority, but I hit it once again when
doing the 4.10-rc7 statistics, which is why I bring up the
discussion..

 Linus

Fwd: [PATCH 1/2] doc: add doc for git-push --recurse-submodules=only

2017-02-02 Thread Brandon Williams 
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 
> >
> > Add documentation for the `--recurse-submodules=only` option of
> > git-push. The feature was added in commit 225e8bf (add option to
> > push only submodules).
> >
> > Signed-off-by: Cornelius Weig 
> > ---
> >
> > Notes:
> > This feature is already in 'next' but was undocumented. Unless somebody 
> > reads
> > the release notes, there is no way of knowing about it.
>
> Good eyes; the topic bw/push-submodule-only is already in 'master'.
>
> Looks good to me; Brandon?
>
> >
> >  Documentation/git-push.txt | 13 +++--
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> > index 8eefabd..1624a35 100644
> > --- a/Documentation/git-push.txt
> > +++ b/Documentation/git-push.txt
> > @@ -272,7 +272,7 @@ origin +master` to force a push to the `master` 
> > branch). See the
> >   standard error stream is not directed to a terminal.
> >
> >  --no-recurse-submodules::
> > ---recurse-submodules=check|on-demand|no::
> > +--recurse-submodules=check|on-demand|only|no::
> >   May be used to make sure all submodule commits used by the
> >   revisions to be pushed are available on a remote-tracking branch.
> >   If 'check' is used Git will verify that all submodule commits that
> > @@ -280,11 +280,12 @@ origin +master` to force a push to the `master` 
> > branch). See the
> >   remote of the submodule. If any commits are missing the push will
> >   be aborted and exit with non-zero status. If 'on-demand' is used
> >   all submodules that changed in the revisions to be pushed will be
> > - pushed. If on-demand was not able to push all necessary revisions
> > - it will also be aborted and exit with non-zero status. A value of
> > - 'no' or using `--no-recurse-submodules` can be used to override the
> > - push.recurseSubmodules configuration variable when no submodule
> > - recursion is required.
> > + pushed. If on-demand was not able to push all necessary revisions it 
> > will
> > + also be aborted and exit with non-zero status. If 'only' is used all
> > + submodules will be recursively pushed while the superproject is left
> > + unpushed. A value of 'no' or using `--no-recurse-submodules` can be 
> > used
> > + to override the push.recurseSubmodules configuration variable when no
> > + submodule recursion is required.
> >
> >  --[no-]verify::
> >   Toggle the pre-push hook (see linkgit:githooks[5]).  The

Re: Fwd: git diff with “--word-diff-regex” extremely slow compared to “--word-diff”?

2016-11-22 Thread Jeff King 
On Tue, Nov 22, 2016 at 10:08:33AM -0800, Matthieu S wrote:

> You are right, I should have compared with the same regex, and indeed,
> --word-diff-regex=[^[:space:]] is also much slower than just
> --word-diff, although they do the same job. Maybe this is a hint that
> the --word-diff-regex code could be made faster?

Maybe. If most of the time is spent in the regex engine, there may not
be much we can do. But perhaps there is something in the surrounding
code that can be improved. Looking at find_word_boundaries() (and this
is the first time I've done so), it does look like we regex-match the
whole buffer, and only then find the end-of-line. Now that we have
regexec_buf(), it might be possible to constrain the regex buffer more.

> I have a small understanding of git, but is git diff computing the
> diff value for the whole file, and then showing in the terminal the 10
> first values? In some cases, it seems to be a lot of unnecessary
> computation! Is there any possibility to ask git-diff to only compare
> say the first 100 lines? Or compute only when necessary, i.e.
> when"enter" is prompted in the console?

Git always computes the diff for the whole file. The paging is done by
an external program. So no, there's no easy way to do it incrementally
as the user interacts with the pager, as the pager does not communicate
back to git in any way. However, git should generally be streaming out
results (and the pager showing them) as they're computed, so in an ideal
world you get output immediately, and then the pager buffers the rest of
it while you're reading the first page.

Git does have to look at the whole file in order to do the initial
line-by-line diff, so it would be hard to make that incremental. It
could do the word-coloring for each hunk incrementally, though. I would
have assumed that is already how it is done, though I didn't dig into
it.

-Peff

Re: Fwd: git diff with “--word-diff-regex” extremely slow compared to “--word-diff”?

2016-11-22 Thread Matthieu S 
Thanks Jeff for the answer!

You are right, I should have compared with the same regex, and indeed,
--word-diff-regex=[^[:space:]] is also much slower than just
--word-diff, although they do the same job. Maybe this is a hint that
the --word-diff-regex code could be made faster?

I have a small understanding of git, but is git diff computing the
diff value for the whole file, and then showing in the terminal the 10
first values? In some cases, it seems to be a lot of unnecessary
computation! Is there any possibility to ask git-diff to only compare
say the first 100 lines? Or compute only when necessary, i.e.
when"enter" is prompted in the console?

Thanks!

Matthieu

2016-11-20 12:17 GMT-08:00 Jeff King :
> On Fri, Nov 18, 2016 at 03:40:22PM -0800, Matthieu S wrote:
>
>> Why is the speed so different if one uses --word-diff instead of
>> --word-diff-regex= ? Is it just because my expression is (slightly)
>> more complex than the default one (split on period instead of only
>> whitespace) ? Or is it that the default word-diff is implemented
>> differently/more efficiently? How can I overcome this speed slowdown?
>
> I think it's probably both.
>
> See diff.c:find_word_boundaries(). If there's no regex, we use a simple
> loop over isspace() to find the boundaries. I don't recall anybody
> measuring the performance before, but I'm not surprised to hear that
> matching a regex is slower.
>
> If I look at the output of "perf", though, it looks like we also spend a
> lot more time in xdl_clean_mmatch(). Which isn't surprising. Your regex
> treats commas as boundaries, which is going to generate a lot more
> matches for this particular data set (though the output is the same, I
> think, because of the nature of the change).
>
> I would have expected "--word-diff-regex=[^[:space:]]" to be faster than
> your regex, though, and it does not seem to be.
>
> -Peff

Re: Fwd: git diff with “--word-diff-regex” extremely slow compared to “--word-diff”?

2016-11-20 Thread Jeff King 
On Fri, Nov 18, 2016 at 03:40:22PM -0800, Matthieu S wrote:

> Why is the speed so different if one uses --word-diff instead of
> --word-diff-regex= ? Is it just because my expression is (slightly)
> more complex than the default one (split on period instead of only
> whitespace) ? Or is it that the default word-diff is implemented
> differently/more efficiently? How can I overcome this speed slowdown?

I think it's probably both.

See diff.c:find_word_boundaries(). If there's no regex, we use a simple
loop over isspace() to find the boundaries. I don't recall anybody
measuring the performance before, but I'm not surprised to hear that
matching a regex is slower.

If I look at the output of "perf", though, it looks like we also spend a
lot more time in xdl_clean_mmatch(). Which isn't surprising. Your regex
treats commas as boundaries, which is going to generate a lot more
matches for this particular data set (though the output is the same, I
think, because of the nature of the change).

I would have expected "--word-diff-regex=[^[:space:]]" to be faster than
your regex, though, and it does not seem to be.

-Peff

Fwd: git diff with “--word-diff-regex” extremely slow compared to “--word-diff”?

2016-11-18 Thread Matthieu S 
Hi

When giving a custom regex to git diff --word-diff-regex= instead of
using the default --word-diff (which splits words on whitespace), git
slows down very considerably... I don't understand why such a speed
difference?

(this question was asked on stack overflow, but after two month
without answer, I'm asking it here instead. Post:
http://stackoverflow.com/questions/39027864/git-diff-with-word-diff-regex-extremely-slow-compared-to-word-diff).

Example (sorry, UNIX specific code): create two one-line files, and
two 20-lines files:

echo aaa,bbb ,12,12,15 >file1.txt
echo aaa,bbb ,12,12,16 >file2.txt

awk '{for(i=0;i<20;i++)print}' file1.txt > file1BIG.txt
awk '{for(i=0;i<20;i++)print}' file2.txt > file2BIG.txt

Default --word-diff has no issues with the BIG files (cannot see time
difference):

git diff --word-diff file1.txt file2.txt
git diff --word-diff file1BIG.txt file2BIG.txt

Now use instead --word-diff-regex= argument (with regex from post:
http://stackoverflow.com/questions/10482773/also-use-comma-as-a-word-separator-in-diff
)

git diff --word-diff-regex=[^[:space:],] file1.txt file2.txt
git diff --word-diff-regex=[^[:space:],] file1BIG.txt file2BIG.txt

Why is the speed so different if one uses --word-diff instead of
--word-diff-regex= ? Is it just because my expression is (slightly)
more complex than the default one (split on period instead of only
whitespace) ? Or is it that the default word-diff is implemented
differently/more efficiently? How can I overcome this speed slowdown?

Thanks!!

Matthieu


PS: using git 2.7.4 on Ubuntu 16.04

Re: Fwd: New Defects reported by Coverity Scan for git

2016-10-20 Thread Junio C Hamano 
Jeff King  writes:

> On Thu, Oct 20, 2016 at 10:58:39AM -0700, Stefan Beller wrote:
>
>> > By the way, do you know who is managing the service on our end
>> > (e.g. approving new people to be "defect viewer")?
>> 
>> I do it most of the time, but I did not start managing it.
>> And I have been pretty lax/liberal about handing out rights to do stuff,
>> because I did not want to tip on anyone's toes giving to few rights
>> and thereby annoying them.
>
> I also do this, though I admit with more urgency when I recognize the
> name as somebody who has showed up on the git list.

Well, then huge thanks to both of you.

Re: Fwd: New Defects reported by Coverity Scan for git

2016-10-20 Thread Jeff King 
On Thu, Oct 20, 2016 at 10:58:39AM -0700, Stefan Beller wrote:

> > By the way, do you know who is managing the service on our end
> > (e.g. approving new people to be "defect viewer")?
> 
> I do it most of the time, but I did not start managing it.
> And I have been pretty lax/liberal about handing out rights to do stuff,
> because I did not want to tip on anyone's toes giving to few rights
> and thereby annoying them.

I also do this, though I admit with more urgency when I recognize the
name as somebody who has showed up on the git list.

I wish there was a flag to simply make the results public. There is no
point in anybody logging in just to view them, but I don't think
Coverity makes that an option.

-Peff

Re: Fwd: New Defects reported by Coverity Scan for git

2016-10-20 Thread Jeff King 
On Thu, Oct 20, 2016 at 10:05:38AM -0700, Stefan Beller wrote:

> Not sure what triggered the new finding of coverity as seen below as the
> parse_commit() was not touched. Junios series regarding the merge base
> optimization touches a bit of code nearby though.

I have noticed that "old" problems sometimes reappear when nearby code
changes. I assume that they have some kind of heuristic to identify the
location of a defect, that it probably includes the line number in the
file, and that it can be fooled by too much code appearing nearby.

-Peff

Re: Fwd: New Defects reported by Coverity Scan for git

2016-10-20 Thread Stefan Beller 
On Thu, Oct 20, 2016 at 11:05 AM, Junio C Hamano  wrote:
>
> Good to know that you have been managing it; I was mostly worried
> about not having anybody managing it (i.e. imagining Coverity
> nominated/volunteered me as manager with everybody else as viewers)
> and the new viewer requests get totally ignored by the project as
> the whole.

No, I have been paying attention, but in case I suddenly stop contributing
to the git project I thought it's better to have a couple of people there.

>
>> I see that some of these emails may be inconvenient to you, I can
>> change your role to defect viewer/contributor if you prefer.
>
> It is not a huge inconvenience to me, because any piece of e-mail
> that is addressed directly to gitster@ without CC'ing to git@vger
> and is not a follow-up to any earlier message goes to a separate
> lowest-priority mailbox that I rarely look at.  But if it is easy
> to recategorize me, please do so.

done.

Re: Fwd: New Defects reported by Coverity Scan for git

2016-10-20 Thread Junio C Hamano 
Stefan Beller  writes:

> I do it most of the time, but I did not start managing it.
> And I have been pretty lax/liberal about handing out rights to do stuff,
> because I did not want to tip on anyone's toes giving to few rights
> and thereby annoying them.

Good to know that you have been managing it; I was mostly worried
about not having anybody managing it (i.e. imagining Coverity
nominated/volunteered me as manager with everybody else as viewers)
and the new viewer requests get totally ignored by the project as
the whole.

> I see that some of these emails may be inconvenient to you, I can
> change your role to defect viewer/contributor if you prefer.

It is not a huge inconvenience to me, because any piece of e-mail
that is addressed directly to gitster@ without CC'ing to git@vger
and is not a follow-up to any earlier message goes to a separate
lowest-priority mailbox that I rarely look at.  But if it is easy
to recategorize me, please do so.

Thanks.

Re: Fwd: New Defects reported by Coverity Scan for git

2016-10-20 Thread Stefan Beller 
On Thu, Oct 20, 2016 at 10:50 AM, Junio C Hamano  wrote:
> Stefan Beller  writes:
>
>> Not sure what triggered the new finding of coverity as seen below as the
>> parse_commit() was not touched. Junios series regarding the merge base
>> optimization touches a bit of code nearby though.
>>
>> Do we want to replace the unchecked places of parse_commit with
>> parse_commit_or_die ?
>
> The reason parse_commit() would fail at this point would be because
> the repository is corrupt, I do not think it would hurt to do such a
> change.
>
> I agree that it is curious why it shows up as a "new defect",
> though.
>
> By the way, do you know who is managing the service on our end
> (e.g. approving new people to be "defect viewer")?

I do it most of the time, but I did not start managing it.
And I have been pretty lax/liberal about handing out rights to do stuff,
because I did not want to tip on anyone's toes giving to few rights
and thereby annoying them.

I see that some of these emails may be inconvenient to you, I can
change your role to defect viewer/contributor if you prefer.

Thanks,
Stefan

Re: Fwd: New Defects reported by Coverity Scan for git

2016-10-20 Thread Junio C Hamano 
Stefan Beller  writes:

> Not sure what triggered the new finding of coverity as seen below as the
> parse_commit() was not touched. Junios series regarding the merge base
> optimization touches a bit of code nearby though.
>
> Do we want to replace the unchecked places of parse_commit with
> parse_commit_or_die ?

The reason parse_commit() would fail at this point would be because
the repository is corrupt, I do not think it would hurt to do such a
change.  

I agree that it is curious why it shows up as a "new defect",
though.

By the way, do you know who is managing the service on our end
(e.g. approving new people to be "defect viewer")?  The site seems
to think I have the power to manage others' subscription, which I do
not think I have (I do not go to the site myself).  As it spewed
quite a many false positives into my mailbox in the past, I do not
pay very close attention to these reports these days, but I still
read the e-mailed reports every once in a while.

Thanks.

Fwd: New Defects reported by Coverity Scan for git

2016-10-20 Thread Stefan Beller 
Not sure what triggered the new finding of coverity as seen below as the
parse_commit() was not touched. Junios series regarding the merge base
optimization touches a bit of code nearby though.

Do we want to replace the unchecked places of parse_commit with
parse_commit_or_die ?

Thanks,
Stefan
_
*** CID 1374088:  Error handling issues  (CHECKED_RETURN)
/commit.c: 913 in mark_redundant()
907
908 work = xcalloc(cnt, sizeof(*work));
909 redundant = xcalloc(cnt, 1);
910 ALLOC_ARRAY(filled_index, cnt - 1);
911
912 for (i = 0; i < cnt; i++)
>>> CID 1374088:  Error handling issues  (CHECKED_RETURN)
>>> Calling "parse_commit" without checking return value (as is done 
>>> elsewhere 37 out of 45 times).
913 parse_commit(array[i]);
914 for (i = 0; i < cnt; i++) {
915 struct commit_list *common;
916
917 if (redundant[i])
918 continue;

Fwd: [git/git-scm.com] Git Gui crash on Mac OS Sierra (#853)

2016-09-22 Thread Přemek Koch 

> Hello, maybe right place this time...
> 
> 
> I want to report a bug:
> 
> On MacOS Sierra git gui crashes randomly with this message:
> 
> 2016-09-22 13:17:36.759 Wish[23615:1501726] *** Terminating app due to 
> uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer position 
> contains NaN: [0 nan]'
> *** First throw call stack:
> (
> 0   CoreFoundation  0x7fff7f0407bb 
> __exceptionPreprocess + 171
> 1   libobjc.A.dylib 0x7fff937ada2a 
> objc_exception_throw + 48
> 2   CoreFoundation  0x7fff7f0bda65 
> +[NSException raise:format:] + 197
> 3   QuartzCore  0x7fff84c09980 
> _ZN2CA5Layer12set_positionERKNS_4Vec2IdEEb + 152
> 4   QuartzCore  0x7fff84c09af5 -[CALayer 
> setPosition:] + 44
> 5   QuartzCore  0x7fff84c0a14b -[CALayer 
> setFrame:] + 644
> 6   CoreUI  0x7fff8a9b0112 
> _ZN20CUICoreThemeRenderer26MakeOrUpdateScrollBarLayerEPK13CUIDescriptoraPP7CALayer
>  + 1284
> 7   CoreUI  0x7fff8a9ac317 
> _ZN20CUICoreThemeRenderer19CreateOrUpdateLayerEPK13CUIDescriptorPP7CALayer + 
> 1755
> 8   CoreUI  0x7fff8a92e4d1 
> _ZN11CUIRenderer19CreateOrUpdateLayerEPK14__CFDictionaryPP7CALayer + 175
> 9   CoreUI  0x7fff8a931185 
> CUICreateOrUpdateLayer + 221
> 10  AppKit  0x7fff7d675623 
> -[NSCompositeAppearance _callCoreUIWithBlock:options:] + 226
> 11  AppKit  0x7fff7cd22a9d 
> -[NSAppearance _createOrUpdateLayer:options:] + 76
> 12  AppKit  0x7fff7cf9b143 
> -[NSScrollerImp _animateToRolloverState] + 274
> 13  AppKit  0x7fff7cf5ab79 
> __49-[NSScrollerImp _installDelayedRolloverAnimation]_block_invoke + 673
> 14  AppKit  0x7fff7ce21331 
> -[NSScrollerImp _doWork:] + 15
> 15  Foundation  0x7fff80a3ec88 
> __NSFireDelayedPerform + 417
> 16  CoreFoundation  0x7fff7efc0f44 
> __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
> 17  CoreFoundation  0x7fff7efc0bd3 
> __CFRunLoopDoTimer + 1075
> 18  CoreFoundation  0x7fff7efc072a 
> __CFRunLoopDoTimers + 298
> 19  CoreFoundation  0x7fff7efb82f1 
> __CFRunLoopRun + 2081
> 20  CoreFoundation  0x7fff7efb7874 
> CFRunLoopRunSpecific + 420
> 21  HIToolbox   0x7fff7e557f6c 
> RunCurrentEventLoopInMode + 240
> 22  HIToolbox   0x7fff7e557ca9 
> ReceiveNextEventCommon + 184
> 23  HIToolbox   0x7fff7e557bd6 
> _BlockUntilNextEventMatchingListInModeWithFilter + 71
> 24  AppKit  0x7fff7cc4e5f5 
> _DPSNextEvent + 1093
> 25  AppKit  0x7fff7d35e8eb 
> -[NSApplication(NSEvent) 
> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1637
> 26  Tk  0x0001047cc285 
> TkGenerateButtonEvent + 494
> 27  Tk  0x0001047cc54d 
> Tk_MacOSXSetupTkNotifier + 395
> 28  Tcl 0x0001048be5a8 
> Tcl_DoOneEvent + 237
> 29  Tk  0x000104726f4f 
> Tk_MainLoop + 33
> 30  Tk  0x000104732a5b Tk_MainEx 
> + 1566
> 31  Wish0x00010470d55a Wish + 9562
> 32  libdyld.dylib   0x7fff94089255 start + 1
> )
> libc++abi.dylib: terminating with uncaught exception of type NSException
> error: git-gui died of signal 6
> 
> 
> Premek Koch
> premek.k...@gmail.com
> 
> 
> 
>> Začátek přeposílané zprávy:
>> 
>> Od: Jean-Noël Avila 
>> Předmět: Re: [git/git-scm.com] Git Gui crash on Mac OS Sierra (#853)
>> Datum: 22. září 2016 19:43:30 SELČ
>> Komu: "git/git-scm.com" 
>> Kopie: Premek Koch , Author 
>> 
>> Odpověď na: "git/git-scm.com" 
>> 
>> 
>> This issue tracker is dedicated to the git-scm.com website.
>> 
>> The issue you have raised is related to the git program. If you think there 
>> is a bug in the git program, please, send your issue to the git mailing list 
>> git@vger.kernel.org
>> 
>> —
>> You are receiving this because you authored the thread.
>> Reply to

Fwd: Git and SHA-1 security (again)

2016-07-17 Thread Herczeg Zsolt 
Do you think the multi-hash approach worth the added complexity? It'll
break a lot of things. I mean almost everything. All git algorithms
rely on the "same hash => same content" "same content => same hash"
statements.

I think converting is a much better option. Use a single-hash storage,
and convert everything to that on import/clone/pull. I would only
introduce a a two-way mapping table (old-hash <=> new-hash) to help
the users. In the normal workflow, everything can go with new-hashes
only.

That leaves most algorithms and code intact, and introduces a very few
new cases:

On import:
If the imported data does not match your selected new-hash format, add
it's hash to the lookup table, than convert it to your selected
format, and handle it as such.

If a user references an old hash:
We can look-up that table forward, and find the referenced object in
storage. We can handle it from now as normal.

On an old signature verify:
Look-up the table forward, find the object by knew key. Look-up
backwards for all referenced objects, reconstruct the "old-format" and
verify the hash on that.

If you double-check your hashes as you build the mapping, you can even
trust it, which makes the lookups and verifys very fast. You can
introduce as many hash mapping tables as you want, so you can not only
support old-to-new has transition, but there can be as many different
hashes in the world as you want. Your only rule is "you reference your
work in your current format", but you can look-up any references which
was valid at the moment it was made.

(There are slight issues with this aproach if we "convert than
convert". As for example, when you import from A (sha1) repo to B
(sha2) repo it's perfectl. But when you import the same commits from B
to C (sha3), you might loose sha1 references. That could be considered
normal if we wan't to keep-it-simple-stupid, only support a few
hashes, always going forward. Or you may add an extra "list" field to
objects, which could show what type of hashes you have to keep in
lookup-tables for that particular object. Or, you can even include a
list of old hashes in the object itself, which should make it to the
lookup table on import.)

Anyway, I think a single-hash storage, and the ability to hide any old
hashes from most of the internal algorithms is a key point in making
transition. If we want to provide multi-hash interface to users, than
we should look for "wrapper" solutions, that translates multi-hash
user needs to a single-hash backend.

Zsolt
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: git rm

2016-07-10 Thread Andreas Schwab 
Peter  writes:

> Ah, ok, I see now. But are there any other situations where the "-f"
> switch is not needed?

When the file is unmodified and matches the index.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: git rm

2016-07-10 Thread Peter 
Ah, ok, I see now. But are there any other situations where the "-f"
switch is not needed?

Peter

On 10 July 2016 at 12:57, Andreas Schwab  wrote:
> Peter  writes:
>
>> So if I do:
>>
>> touch abc
>> git add abc
>>
>>
>> And after that I do:
>>
>> git rm abc
> error: the following file has changes staged in the index:
> abc
> (use --cached to keep the file, or -f to force removal)
>
> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: git rm

2016-07-10 Thread Andreas Schwab 
Peter  writes:

> So if I do:
>
> touch abc
> git add abc
>
>
> And after that I do:
>
> git rm abc
error: the following file has changes staged in the index:
abc
(use --cached to keep the file, or -f to force removal)

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: git rm

2016-07-10 Thread Peter 
So if I do:

touch abc
git add abc


And after that I do:

git rm abc


Can you agree that there is an asymmetry of two commands vs. one? Git
add only touches the files in .git/ and git rm ALSO affects the
working tree...

Is "git rm" or "git rm --cache" used more often in practice?


Peter

On 7 July 2016 at 05:35, Jeff King  wrote:
> On Wed, Jul 06, 2016 at 06:42:19PM +0200, Andreas Schwab wrote:
>
>> Peter  writes:
>>
>> > I am a lightweigt git user so by all means not a reference, but I was
>> > wondering why exactly does "git rm" also delete the file (remove it
>> > from the working tree). I see it as an unintended behaviour as git is
>> > written in a way that it preserves the most data.
>>
>> The data is still preserved.  You can restore it with "git checkout HEAD
>> ".
>
> Assuming the file is present in HEAD, of course. But if it is not, then
> git should (and does) complain and ask for "-f".
>
> -Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  1   2   3   4   >