Re: Request re git status

[Konstantin Khomoutov]

On Mon, 6 Feb 2017 22:46:53 -0800
Ron Pero  wrote:

[...]
> Still, one way or another, it was easy to feel tripped up by that and
> some kind of verbal cue could help.
> I wonder if this kind of message would help: Latest fetch: {timestamp}
[...]

Timestamps have little to no sense with regard to histories.

What you should make use of is the concept of "tracking branches".
The basic idea is outlined below.

When you fetch from a named remote, like with

  git fetch origin

Git creates/updates the so-called "remote" branches for that named
remote in your local repository.  They live in a special hierarchy of
branches distinct from your "normal" branches, and you typically refer
to them using short (incomplete in fact) names which include the name
of the remote they came from.

For instance, if the repo known as "origin" to your local one
contains the branches "master", "foo" and "devel" at the time the
command above was run, Git would create remote branches "origin/master",
"origin/foo" and "origin/devel".

The whole "remote branches" thing serves to provide you with sort of
bookmarks to the state of a remote repository it was last seen.

You can't commit your own work on remote branches, and can't push them
either (I'm oversimplifying things now but let's not digress).
That's because they are, well, bookmarks, and they are not "yours" --
as opposed to normal local branches.

Now another thing Git offers is the possibility to "link" any local
branch to any remote branch.  This mechanism is called "tracking".
The remote branch linked to a local branch is then called "an upstream"
for that local branch, and that local branch is said to be tracking
that upstream branch.

Say, if you've just fetched from a remote repository and want to work
on a branch "foo" someone created there, you can do

  git checkout -b foo --track origin/foo

if you have existing local branch which doesn't track any remote branch,
you can call

  git branch --set-upstream-to origin/whatever

when it's checked out to make it track the origin/whatever remote
branch.

Tracking makes many Git commands be extra chatty about the state of the
tracking local branch compared to the state of its upstream branch.
Say, `git status` will tell you how many different commits your local
and its upstream branch have compared to each other -- a clear sign
that you should consider merging or rebasing your local work if you're
about to push it to the upstream branch.

While tracking helps in this case, you must understand that Git is a
DVCS, and "D" in it means "distributed" which, in turn, implies
"disconnected".  You should very well understand, that pushing to a
remote repository is inherently racy in this model.  That is, by the
time your `git fetch origin` completed, the state of the branches it
just fetched might have already changed by someone else's push.
So unless your organization / team employs some policy on pushing (that
is, each push to certain "shared" branches must be discussed first and
receive a go-ahead from everyone) you have to be prepared for your
push being rejected because someone else will have managed to push
faster than you.

What I'm leading you to, is that showing you any sort of "last fetch
time" won't really help anyway.  You just should know the drill:

* Make use of the tracking feature.
* Never use --force with `git push` unless you absolutely positively
  understand what happens and you have discussed this with everyone
  else in the team or whoever is in charge for the project.
* If pushing fails, run `git fetch` and reconcile your local changes
  with whatever changes crept in there into the "upstream" branch,
  re-attempt pushing.  Rinse, repeat, if needed.

You're advised to read at least [1], or -- better -- the whole chapter
on branching (even better just read the whole book).

1. https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches

Re: Request re git status

[Ron Pero]

Hi Phil

Thanks very much for your reply.

I do understand why git status should not automatically fetch from the
server. The solution is that I become aware of that nuance (yes, I am
fairly new to git) and conduct myself that way.

Still, one way or another, it was easy to feel tripped up by that and
some kind of verbal cue could help.
I wonder if this kind of message would help: Latest fetch: {timestamp}

BTW, you might consider posting your answer on
http://stackoverflow.com/questions/27828404/why-does-git-status-show-branch-is-up-to-date-when-changes-exist-upstream

Why? Because someone suggested emailing this suggestion to git@vger.kernel.org.

>From the stackoverflow page:
"It would certainly be possible to add that extra text (behind a
config option so that redundant noise isn't shown if you how Git
works) but asking for it here isn't going to change it, try emailing
git@vger.kernel.org"

In answer to a couple of your points, I was not using force. And I do
understand that if I pushed to origin master it would have stopped the
merge, alerting me to the conflict. Thanks for that.

Thanks again,

Ron

On Mon, Feb 6, 2017 at 4:45 PM, Phil Hord  wrote:
> On Mon, Feb 6, 2017 at 3:36 PM Ron Pero  wrote:
>> I almost got bit by git: I knew there were changes on the remote
>> server, but git status said I was uptodate with the remote.
>>
>
> Do you mean you almost pushed some changed history with "--force"
> which would have lost others' changes?  Use of this option is
> discouraged on shared branches for this very reason.  But if you do
> use it, the remote will tell you the hash of the old branch so you can
> undo the damage.
>
> But if you did not use --force, then you were not in danger of being
> bit.  Git would have prevented the push in that case.
>
>
>> Why ... not design it to [optionally] DO a fetch and THEN declare
>> whether it is up to date?
>
> It's because `git status` does not talk to the remote server, by
> design.  The only Git commands that do talk to the remote are push,
> pull and fetch.  All the rest work off-line and they do so
> consistently.
>
> Imagine `git status` did what you requested; that is, it first did a
> fetch and then reported the status.  Suppose someone pushed a commit
> to the remote immediately after your fetch completed.  Now git will
> still report "up to date" but it will be wrong as soon as the remote
> finishes adding the new push.  Yet the "up to date" message will
> remain on your console, lying to you.  If you leave and come back in
> two days, the message will remain there even if it is no longer
> correct.
>
> So you should accept that `git status` tells you the status with
> respect to your most recent fetch, and that you are responsible for
> the timing of the most recent fetch.  To have git try to do otherwise
> would be misleading.
>
>> Or change the message to tell what it really
>> did, e.g. "Your branch was up-to-date with 'origin/master' when last
>> checked at {timestamp}"? Or even just say, "Do a fetch to find out
>> whether your branch is up to date"?
>
> These are reasonable suggestions, but i don't think the extra wording
> adds anything for most users.  Adding a timestamp seems generally
> useful, but it could get us into other trouble since we have to depend
> on outside sources for timestamps.  :-\

[PATCH v2] Document the --no-gui option in difftool

[Denton Liu]

Prior to this, the `--no-gui` option was not documented in the manpage.
This commit introduces this into the manpage

Signed-off-by: Denton Liu 
---
 Documentation/git-difftool.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 224fb3090..96c26e6aa 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -86,10 +86,11 @@ instead.  `--no-symlinks` is the default on Windows.
Additionally, `$BASE` is set in the environment.
 
 -g::
---gui::
+--[no-]gui::
When 'git-difftool' is invoked with the `-g` or `--gui` option
the default diff tool will be read from the configured
-   `diff.guitool` variable instead of `diff.tool`.
+   `diff.guitool` variable instead of `diff.tool`. The `--no-gui`
+   option can be used to override this setting.
 
 --[no-]trust-exit-code::
'git-difftool' invokes a diff tool individually on each file.
-- 
2.11.1

Re: idea: light-weight pull requests

[Paul Wise]

On Tue, 2017-02-07 at 03:11 +, Eric Wong wrote:

> How would discussion and review happen?  People seem to use
> either mail, or centralized messaging (and the latter often
> involves non-Free systems like GitHub or Slack).

It would depend on the setup for the particular repo. Information about
where that happens could be part of the output of the git push.

> This is a big one.  Maybe CRM114 or another generic/trainable
> option can be made usable; but I think there'll always be cases
> where hardcoded rules need to be written (for SpamAssassin,
> at least) and real-time blacklists need to be checked.

TBH, I doubt spam would become a problem at all.

> Anyways, I ultimately decided it would be better to continue
> supporting and improving email (which is at least entrenched in
> a few communities, like this one), rather than trying to get
> people to adopt something new.

Email is great for people used to the old ways but it is gradually
being replaced by APIs and web interfaces :(

-- 
bye,
pabs

http://bonedaddy.net/pabs3/

signature.asc
Description: This is a digitally signed message part

Re: idea: light-weight pull requests

[Eric Wong]

Paul Wise  wrote:
> Hi all,
> 
> I had an idea that might be interesting to git folks:
> 
> light-weight pull requests:
> 
> Anonymous and ssh/http-identified users should be able to push just
> using git, within the refs/pull/ namespace, to any non-existent branch
> name or to a branch they created when previously identified, without
> forking off a new repository.

I considered something similar to this a few years ago,
but decided it wasn't worth the effort (see below).

> Advantages:
> 
> Removes the need to look up who to send the pull request notification
> to since configuring that is up to the project itself.
> 
> Removes the annoying scenario of having lots of remotes that have been
> removed after the corresponding pull request was closed.
> 
> Moves popular git hosting services from primarily a model of forests of
> forks to one of contributions to well maintained ongoing projects.
> 
> Allows users to use their preferred git clients to issue pull requests
> instead of using web interfaces of popular git hosting services.
> 
> Creates a new standard for contributing to repositories on all git
> repository hosting services.
> 
> Contributions from people without an account on those services are
> possible.
> 
> Contributions from people without any git repository hosting of their
> own are possible.

All of these are great goals which I'd love to see realized, but...

> Contributions from people who don't use or dislike MUAs are possible.

How would discussion and review happen?  People seem to use
either mail, or centralized messaging (and the latter often
involves non-Free systems like GitHub or Slack).

> Disadvantages:
> 
> Pull request spam, could be mitigated with configuration options.

This is a big one.  Maybe CRM114 or another generic/trainable
option can be made usable; but I think there'll always be cases
where hardcoded rules need to be written (for SpamAssassin,
at least) and real-time blacklists need to be checked.

At some point, you might end up having to recreate everything we
have in place to combat email spam.  Or, use blockchain or
something similarly expensive for reputation, which isn't good
for poor folks with slow computers.

Anyways, I ultimately decided it would be better to continue
supporting and improving email (which is at least entrenched in
a few communities, like this one), rather than trying to get
people to adopt something new.

Re: idea: light-weight pull requests

[Paul Wise]

On Mon, 2017-02-06 at 19:57 -0500, Santiago Torres wrote:

> IMHO, the notion of a PR/MR is more specific to Git repository
> management tools (e.g., GitHub, GitLab). They all have specific
> concepts/ways to manage the way how their hosted repositories behave ---
> and I believe this flexibility is one of the beauties in Git . I could
> see how this could be implemented by tools like this rather easily
> (e.g., using symlinks + inotify or something less hacky).

Right, but I would like to see this everywhere (including kernel.org),
so support in git-daemon and the http/ssh equivalents is needed too.
git already has support for anonymous push but this idea is more complex.

> I'm wondering if standardizing this would be more interesting to those
> communities?

I've pitched this to github.com/contact but couldn't find any feature
request address for GitLab.

> I would like to see what becomes of this.

Likewise :)

-- 
bye,
pabs

http://bonedaddy.net/pabs3/

signature.asc
Description: This is a digitally signed message part

Re: What's cooking in git.git (Feb 2017, #02; Mon, 6)

[Jacob Keller]

On Mon, Feb 6, 2017 at 4:24 PM, SZEDER Gábor  wrote:
>> * sg/completion-refs-speedup (2017-02-06) 13 commits
>>  - squash! completion: fill COMPREPLY directly when completing refs
>>  - completion: fill COMPREPLY directly when completing refs
>>  - completion: list only matching symbolic and pseudorefs when completing 
>> refs
>>  - completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery
>>  - completion: let 'for-each-ref' filter remote branches for 'checkout' 
>> DWIMery
>>  - completion: let 'for-each-ref' strip the remote name from remote branches
>>  - completion: let 'for-each-ref' and 'ls-remote' filter matching refs
>>  - completion: don't disambiguate short refs
>>  - completion: don't disambiguate tags and branches
>>  - completion: support excluding full refs
>>  - completion: support completing full refs after '--option=refs/'
>>  - completion: wrap __git_refs() for better option parsing
>>  - completion: remove redundant __gitcomp_nl() options from _git_commit()
>>  (this branch uses sg/completion.)
>>
>>  Will hold.
>>  This seems to break 9902 when merged to 'pu'.
>
> All failing tests fail with the same error:
>
>   fatal: unrecognized %(refname:strip=2) argument: strip=2
>
> That's because of this topic:
>
>> * kn/ref-filter-branch-list (2017-01-31) 20 commits
>>   (merged to 'next' on 2017-01-31 at e7592a5461)
>>  + branch: implement '--format' option
>>  + branch: use ref-filter printing APIs
>>  + branch, tag: use porcelain output
>>  + ref-filter: allow porcelain to translate messages in the output
>>  + ref-filter: add an 'rstrip=' option to atoms which deal with refnames
>>  + ref-filter: modify the 'lstrip=' option to work with negative ''
>>  + ref-filter: Do not abruptly die when using the 'lstrip=' option
>>  + ref-filter: rename the 'strip' option to 'lstrip'
>
> And in particular this commit, which, well, does what it's subject
> says it's doing, thus breaking backwards compatibility.
>

What about making strip a deprecated variant of lstrip?

Thanks,
Jake

Re: git-daemon shallow checkout fail

[Bob Proulx]

Bob Proulx wrote:
>   17:20:40.590177 pkt-line.c:46   packet:clone< 
> 34e7202270c381f4e5734180dc19426ce69f2e1e HEAD\0multi_ack thin-pack side-band 
> side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed 
> symref=HEAD:refs/heads/master agent=git/1.9.1

The evidence of it running the wrong version being the 1.9.1 which is
not the bits I built.

> Therefore it looks like it is invoking some other command by a hard
> coded path and avoiding PATH to my development bits.  It must be
> invoking some other binary.  I will get more agressive about disabling
> the packaged version and hopefully find out which one.

I did and of course it is /usr/bin/git-upload-pack and if I disable
that binary then git-daemon no longer operates.

  error: cannot run upload-pack: No such file or directory

But shouldn't it find git-upload-pack from PATH?  Since I have
git-upload-pack installed in PATH?  Apparently not.  At least not when
invoking as /path/to/git-daemon directly.

In any case with the all of your very good help, especially the
version echo print, guiding me to the problem that I was able to make
this work.

  cd /run/git && env -i HOME=/run/git 
PATH=$HOME/src/git-stuff/git:/usr/bin:/bin $HOME/src/git-stuff/git/git 
--exec-path=$HOME/src/git-stuff/git daemon --export-all --base-path=/srv/git 
--verbose

That works for the git-daemon.  It does not require me to modify
anything else on the system.  Good enough.  Problem solved.

Thanks!
Bob

Re: idea: light-weight pull requests

[Santiago Torres]

Hello, pabs.

IMHO, the notion of a PR/MR is more specific to Git repository
management tools (e.g., GitHub, GitLab). They all have specific
concepts/ways to manage the way how their hosted repositories behave ---
and I believe this flexibility is one of the beauties in Git . I could
see how this could be implemented by tools like this rather easily
(e.g., using symlinks + inotify or something less hacky).

I'm wondering if standardizing this would be more interesting to those
communities?

I would like to see what becomes of this.

Cheers!
-Santiago.

On Tue, Feb 07, 2017 at 08:32:17AM +0800, Paul Wise wrote:
> Hi all,
> 
> I had an idea that might be interesting to git folks:
> 
> light-weight pull requests:
> 
> Anonymous and ssh/http-identified users should be able to push just
> using git, within the refs/pull/ namespace, to any non-existent branch
> name or to a branch they created when previously identified, without
> forking off a new repository.
> 
> Advantages:
> 
> Removes the need to look up who to send the pull request notification
> to since configuring that is up to the project itself.
> 
> Removes the annoying scenario of having lots of remotes that have been
> removed after the corresponding pull request was closed.
> 
> Moves popular git hosting services from primarily a model of forests of
> forks to one of contributions to well maintained ongoing projects.
> 
> Allows users to use their preferred git clients to issue pull requests
> instead of using web interfaces of popular git hosting services.
> 
> Creates a new standard for contributing to repositories on all git
> repository hosting services.
> 
> Contributions from people without an account on those services are
> possible.
> 
> Contributions from people without any git repository hosting of their
> own are possible.
> 
> Contributions from people who don't use or dislike MUAs are possible.
> 
> Disadvantages:
> 
> Pull request spam, could be mitigated with configuration options.
> 
> Extra configuration and complexity on the server side. This is once
> only and means less complexity on the pull requester side.
> 
> Will not work with typical setups where the git/http/ssh user does not
> have write access to the repositories. A workaround could be some sort
> of hybrid-repository setup with the new refs and objects in a second
> repository which would be shared by all pull requesters.
> 
> -- 
> bye,
> pabs
> 
> http://bonedaddy.net/pabs3/




signature.asc
Description: PGP signature

idea: light-weight pull requests

[Paul Wise]

Hi all,

I had an idea that might be interesting to git folks:

light-weight pull requests:

Anonymous and ssh/http-identified users should be able to push just
using git, within the refs/pull/ namespace, to any non-existent branch
name or to a branch they created when previously identified, without
forking off a new repository.

Advantages:

Removes the need to look up who to send the pull request notification
to since configuring that is up to the project itself.

Removes the annoying scenario of having lots of remotes that have been
removed after the corresponding pull request was closed.

Moves popular git hosting services from primarily a model of forests of
forks to one of contributions to well maintained ongoing projects.

Allows users to use their preferred git clients to issue pull requests
instead of using web interfaces of popular git hosting services.

Creates a new standard for contributing to repositories on all git
repository hosting services.

Contributions from people without an account on those services are
possible.

Contributions from people without any git repository hosting of their
own are possible.

Contributions from people who don't use or dislike MUAs are possible.

Disadvantages:

Pull request spam, could be mitigated with configuration options.

Extra configuration and complexity on the server side. This is once
only and means less complexity on the pull requester side.

Will not work with typical setups where the git/http/ssh user does not
have write access to the repositories. A workaround could be some sort
of hybrid-repository setup with the new refs and objects in a second
repository which would be shared by all pull requesters.

-- 
bye,
pabs

http://bonedaddy.net/pabs3/

signature.asc
Description: This is a digitally signed message part

Re: Request re git status

[Phil Hord]

On Mon, Feb 6, 2017 at 3:36 PM Ron Pero  wrote:
> I almost got bit by git: I knew there were changes on the remote
> server, but git status said I was uptodate with the remote.
>

Do you mean you almost pushed some changed history with "--force"
which would have lost others' changes?  Use of this option is
discouraged on shared branches for this very reason.  But if you do
use it, the remote will tell you the hash of the old branch so you can
undo the damage.

But if you did not use --force, then you were not in danger of being
bit.  Git would have prevented the push in that case.


> Why ... not design it to [optionally] DO a fetch and THEN declare
> whether it is up to date?

It's because `git status` does not talk to the remote server, by
design.  The only Git commands that do talk to the remote are push,
pull and fetch.  All the rest work off-line and they do so
consistently.

Imagine `git status` did what you requested; that is, it first did a
fetch and then reported the status.  Suppose someone pushed a commit
to the remote immediately after your fetch completed.  Now git will
still report "up to date" but it will be wrong as soon as the remote
finishes adding the new push.  Yet the "up to date" message will
remain on your console, lying to you.  If you leave and come back in
two days, the message will remain there even if it is no longer
correct.

So you should accept that `git status` tells you the status with
respect to your most recent fetch, and that you are responsible for
the timing of the most recent fetch.  To have git try to do otherwise
would be misleading.

> Or change the message to tell what it really
> did, e.g. "Your branch was up-to-date with 'origin/master' when last
> checked at {timestamp}"? Or even just say, "Do a fetch to find out
> whether your branch is up to date"?

These are reasonable suggestions, but i don't think the extra wording
adds anything for most users.  Adding a timestamp seems generally
useful, but it could get us into other trouble since we have to depend
on outside sources for timestamps.  :-\

Re: git-daemon shallow checkout fail

[Bob Proulx]

Duy Nguyen wrote:
> Jeff King wrote:
> > It depends on the git version on the server. The interesting code is in
> > upload-pack.c, which is spawned by git-daemon to serve a fetch or clone
> > request.
> >
> > See commit b790e0f67 (upload-pack: send shallow info over stdin to
> > pack-objects, 2014-03-11), which lays out the history. Since that commit
> > (in git v2.0.0), there should be no tmpfile needed.
> 
> It must be it. There's nowhere else that upload-pack can create
> shallow_XX. (receive-pack and fetch-pack can).

I am sure the file creation is there.  Because it isn't being done
anywhere.  But the problem is before that time period.  By then the
paths are already set.

> >Bob Proulx wrote:
> >>   git --version  # from today's git clone build
> >>   git version 2.11.0.485.g4e59582
> >
> > This shouldn't be happening with git v2.11. Are you sure that the "git
> > daemon" invocation is running that same version? I notice you set up a
> > restricted PATH. Is it possible that /usr/local/bin or /usr/bin has an
> > older version of git?

I have been starting it with PATH set to my directory.  But given this
question I start it with a full path.

  PATH=~/src/git-stuff/git:$PATH ~/src/git-stuff/git/git-daemon --export-all 
--base-path=/srv/git --verbose

But then I worry about the package installed binary still getting
invoked with the fork somehow.  Therefore I disable it.  There should
be no possibility of it invoking the packaged daemon.  I moved it out
of the way.

  mv /usr/lib/git-core/git-daemon /usr/lib/git-core/git-daemon.disabled

I can't trivially remove the packaged version because other things
depend upon it.  I could get more agressive about disabling it in a
non-destructive and reversible way though.

> One easy way to verify is clone or fetch again with GIT_TRACE_PACKET=1
> since we send the server's version as a capability since 1.8.0

And here is the interesting part.  If I read this right the client is
reporting 1.9.1 from the server!  But how?  

  $ GIT_TRACE_PACKET=1 git clone --depth 1 
git://git0.savannah.gnu.org/test-project.git
  Cloning into 'test-project'...
  17:20:40.482970 pkt-line.c:46   packet:clone> git-upload-pack 
/test-project.git\0host=git0.savannah.gnu.org\0
  17:20:40.590177 pkt-line.c:46   packet:clone< 
34e7202270c381f4e5734180dc19426ce69f2e1e HEAD\0multi_ack thin-pack side-band 
side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed 
symref=HEAD:refs/heads/master agent=git/1.9.1
  17:20:40.662623 pkt-line.c:46   packet:clone< 
34e7202270c381f4e5734180dc19426ce69f2e1e refs/heads/master
  17:20:40.662653 pkt-line.c:46   packet:clone< 
  17:20:40.663682 pkt-line.c:46   packet:clone> want 
34e7202270c381f4e5734180dc19426ce69f2e1e multi_ack_detailed side-band-64k 
thin-pack include-tag ofs-delta agent=git/2.1.4
  17:20:40.663701 pkt-line.c:46   packet:clone> want 
34e7202270c381f4e5734180dc19426ce69f2e1e
  17:20:40.663713 pkt-line.c:46   packet:clone> deepen 1
  17:20:40.663724 pkt-line.c:46   packet:clone> 
  17:20:40.739502 pkt-line.c:46   packet:clone< shallow 
34e7202270c381f4e5734180dc19426ce69f2e1e
  17:20:40.854338 pkt-line.c:46   packet:clone< 
  17:20:40.854360 pkt-line.c:46   packet:clone> done
  17:20:40.929349 pkt-line.c:46   packet:clone< NAK
  fatal: The remote end hung up unexpectedly
  fatal: early EOF
  fatal: index-pack failed

I am assuming that the "agent=git/1.9.1" is the evidence that it isn't
running the code that I am trying to make it run?  Of course the
packaged installed git version is 1.9.1 (from Trisquel 7, an Ubuntu
14.04 fork) so that matches.  My client is "agent=git/2.1.4" (from
Debian Jessie) so that matches my client end.

Therefore it looks like it is invoking some other command by a hard
coded path and avoiding PATH to my development bits.  It must be
invoking some other binary.  I will get more agressive about disabling
the packaged version and hopefully find out which one.

Thank you very much for the good hints here.  They are very helpful.

Bob

Re: git-daemon shallow checkout fail

[Bob Proulx]

Hello Johannes,

Thank you very much for the good hints here.  They are very helpful.

Johannes Schindelin wrote:
> Assuming that you can rebuild your Git with debug symbols and without
> optimization (simply remove the -O2 from CFLAGS in the Makefile, I never
> had any luck with single-stepping in gdb when compiled with -O2), you

I always debug with -g and without -O because otherwise it leads to a
lot of confusion.  But git-daemon is a forking daemon which makes
debugging it with the debugger somewhere more default and requiring
more setup to debug past the fork points.  As you note and hint with
later setting up an attach point for gdb.

> - that error message comes from shallow.c's setup_temporary_shallow()
>   function

Yes.  I find that too.

> - that function is only called from fetch-pack and receive-pack, neither
>   of which should be called by upload-pack, so it is a puzzle

The choice of directionality for upload and download might be
confusing me here too.  Since from the client side of things it is a
download.  But on the server side it is an upload.

> - adding a test case to t5570-git-daemon.sh that tests specifically your
>   described scenario seems *not* to fail:

I have seen some of the patches that seems like should have fixed this
problem.  It is perplexing.  But see my next mail on this too.

> - I even modified t/lib-git-daemon.sh to start the daemon as `nobody` and
>   kill it as `root`, and I won't share that patch because it is as
>   ugly, but *even then* the test succeeded.

It succeeds for me on other systems.  It is only the one (where I need
it) that it is failing.

> So my suspicion is that the repository you try to serve may already be
> shallow, or something else funky is going on that has not been included in
> your report.

It happens to any repository.  I picked a small repository and copied
it verbatim using rsync to my working environment.  The identical bits
of a repository copied by rsync work okay on one system but fail on
the other.

> The most direct way to get to the bottom of this may be to do something
> like this:
...
>   if (write_shallow_commits(, 0, extra)) {
> +error("About to create shallow_XX: pid = %d", getpid());
> +while (!debug_me) {
> + sleep(1);
> +}
>   fd = xmks_tempfile(_shallow, 
> git_path("shallow_XX"));
>  
>   if (write_in_full(fd, sb.buf, sb.len) != sb.len)
> -- snap --
> 
> Then let it run, wait for the error message "About to create
> shallow_XX" and then attach with a gdb started as nobody via `attach
> ` to see the stack trace.
> 
> That should give you an idea where that code path is hit (unexpectedly).

That is a good hint.  I will give that a try.  However see my next
email for more (confusing) information.

Bob

Re: What's cooking in git.git (Feb 2017, #02; Mon, 6)

[SZEDER Gábor]

> * sg/completion-refs-speedup (2017-02-06) 13 commits
>  - squash! completion: fill COMPREPLY directly when completing refs
>  - completion: fill COMPREPLY directly when completing refs
>  - completion: list only matching symbolic and pseudorefs when completing refs
>  - completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery
>  - completion: let 'for-each-ref' filter remote branches for 'checkout' 
> DWIMery
>  - completion: let 'for-each-ref' strip the remote name from remote branches
>  - completion: let 'for-each-ref' and 'ls-remote' filter matching refs
>  - completion: don't disambiguate short refs
>  - completion: don't disambiguate tags and branches
>  - completion: support excluding full refs
>  - completion: support completing full refs after '--option=refs/'
>  - completion: wrap __git_refs() for better option parsing
>  - completion: remove redundant __gitcomp_nl() options from _git_commit()
>  (this branch uses sg/completion.)
>
>  Will hold.
>  This seems to break 9902 when merged to 'pu'.

All failing tests fail with the same error:

  fatal: unrecognized %(refname:strip=2) argument: strip=2

That's because of this topic:

> * kn/ref-filter-branch-list (2017-01-31) 20 commits
>   (merged to 'next' on 2017-01-31 at e7592a5461)
>  + branch: implement '--format' option
>  + branch: use ref-filter printing APIs
>  + branch, tag: use porcelain output
>  + ref-filter: allow porcelain to translate messages in the output
>  + ref-filter: add an 'rstrip=' option to atoms which deal with refnames
>  + ref-filter: modify the 'lstrip=' option to work with negative ''
>  + ref-filter: Do not abruptly die when using the 'lstrip=' option
>  + ref-filter: rename the 'strip' option to 'lstrip'

And in particular this commit, which, well, does what it's subject
says it's doing, thus breaking backwards compatibility.


>  + ref-filter: make remote_ref_atom_parser() use 
> refname_atom_parser_internal()
>  + ref-filter: introduce refname_atom_parser()
>  + ref-filter: introduce refname_atom_parser_internal()
>  + ref-filter: make "%(symref)" atom work with the ':short' modifier
>  + ref-filter: add support for %(upstream:track,nobracket)
>  + ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
>  + ref-filter: introduce format_ref_array_item()
>  + ref-filter: move get_head_description() from branch.c
>  + ref-filter: modify "%(objectname:short)" to take length
>  + ref-filter: implement %(if:equals=) and %(if:notequals=)
>  + ref-filter: include reference to 'used_atom' within 'atom_value'
>  + ref-filter: implement %(if), %(then), and %(else) atoms
>
>  The code to list branches in "git branch" has been consolidated
>  with the more generic ref-filter API.
>
>  Will cook in 'next'.

Re: Cross-referencing the Git mailing list archive with their corresponding commits in `pu`

[Eric Wong]

Jeff King  wrote:
> On Mon, Feb 06, 2017 at 08:48:20PM +, Eric Wong wrote:
> 
> > I haven't hit insurmountable performance problems, even on
> > low-end hardware; especially since I started storing blob ids in
> > Xapian itself, avoiding the expensive tree lookup via git.
> 
> The painful thing is traversing the object graph for clones and fetches.
> Bitmaps help, but you still have to generate them.

Yep.  "public-inbox-init" defaults to enabling bitmaps in the
config for this reason.

> > The main problem seems to be tree size.  Deepening (2/2/36 vs
> > 2/38) might be an option (I think Peff brought that up); but it
> > might be easier to switch to MM refs (working like
> > logrotate) and rely on Xapian to tie the entire thing together.
> 
> Yes, the hashing is definitely one issue. Some numbers here:
> 
>   
> http://public-inbox.org/git/20160805092805.w3nwv2l6jkbuw...@sigill.intra.peff.net/
> 
> If you have C commits on a tree with T entries, you have to do C*T hash
> lookups for a flat tree (for each commit, you have to see "yup, already
> saw that object"). Sharding that across H entries at the top level drops
> the tree cost from T to H + T/H (actually, it's a bit worse because we
> have to read the secondary tree, too). Sharding again (at H') gets you
> H + H' + T/H/H'.
> 
> Let's imagine you do one message per commit, so C=T. At 400K messages,
> that's about 160 billion hash lookups flat. At H=256, it's about 700
> million. If you shard again with H'=256, it's 200 million. After that,
> the additive terms start to dominate, and it's not worth going any
> further (and also, we're ignoring the extra-tree cost to each level).

Just to make sure I'm following, here; the entire formulas are:

C * H + H' + (T / H / H') # 2/2/36
C * H + (T / H)   # 2/38 (current)

Right?

> At that point you're better off to start having fewer commits. I know
> that the schema you use does put useful information into the commit
> message, but it's also redundant with what's in the messages themselves.
> And it sounds like you push most of that out to Xapian anyway.

Yeah, there's no benefit to Xapian users for having any info in
the commit.  However, keeping commit-per-message is still
important to me to for better robustness from hardware and
network failures.

But yes, historical stuff could be squashed into a single commit
(much like how linux.git started with v2.6.12-rc2 without
history).  Perhaps some folks will care about NNTP article
numbering being non-chronological...

> Imagine your repo had one commit with 400K historical messages, and then
> grouped the new messages so that on average we got about 10 messages per
> commit (this doesn't seem unrealistic for something that commits every
> few minutes; the messages tend to be bunched in time; I ran some
> numbers against a 10-minute mark in the earlier message).
> 
> Then after another 100K messages, we'd have C=10,001 and T=500K. With
> two levels of hashing at 256 each, that's ~5 million hash lookups to
> walk the graph. And those numbers would be reasonable for a hosting site
> like GitHub.
> 
> I don't know what C is for the kernel repo, but I suspect with the right
> tuning it could be made into large-but-reasonable.

LKML probably has an upper bound of 30K messages per month;
so it could hit 100K in less than 4 months.  Worst case might
be 360K messages a year

36 * (256 + 256 + ((36 + old) / 256 / 256))

That's still at least 180 million hash lookups after a year or
so of real-time updates; right?  (But probably closer to 240
million if there's 10 million old messages in there.

Instead, I think I will add an option to support logrotate-style
monthly heads (MM); keeping 2/38 and C == T:

3 * (256 + (3 / 256))   => 11 million
3 * (256 + 256 + (3 / 256 / 256))   => 15 million

The monthly heads would each be discontiguous history-wise;
so Xapian would become a requirement for users of this option
for Message-ID lookups, but histories would still be readable
with "git log"

One good side-effect of using monthly heads is --single-branch
clones may be used if someone lacks the bandwidth or space to do
a full mirror.  I'm not sure if the server-side (pack reuse,
bitmaps) will benefit other aside from bandwidth reductions,
though.


A (far-fetched) option I've considered would be to store entire
messages in the commit and have no trees or blobs at all.  But
that would require a significant rework, and would also make
Xapian a hard requirement for even checking if a message is
deleted or not.

Re: [PATCH 00/12] completion: speed up refs completion

[Jacob Keller]

On Mon, Feb 6, 2017 at 11:36 AM, SZEDER Gábor  wrote:
> On Mon, Feb 6, 2017 at 7:31 PM, Jacob Keller  wrote:
>> On Fri, Feb 3, 2017 at 7:15 PM, Jacob Keller  wrote:
>>> I haven't had a chance to further investigate, but I tried this series
>>> out (from your github) and it appears that this series (or the
>>> previous series for __gitdir work) breaks "git log" ref completion.
>>> I'll have further details when I am able to investigate a it more.
>>>
>>> Thanks,
>>> Jake
>>
>> At first I had the same problem, but I verified by re-installing the
>> completion script and the problem appears to have gone away. I suspect
>> what happened is that the original time, I forgot to actually install
>> the new version of git, and only installed the completion script, so
>> when some of the commands were run with new options they (silently)
>> failed and the result was missing completion values.
>>
>> Once I properly re-installed everything it appears to work as
>> expected. I haven't found any other issues yet.
>
> Thanks, that's good to hear.
>
> Still, I'm a bit puzzled as to what exactly might have caused your
> problem.  Considering new options:
>
>   - the __gitdir()-related series added the 'git rev-parse
> --absolute-git-dir' option, but only ever used it if you invoked
> completion after 'git -C some/where'.
>
>  - The refs completion speedup didn't add any new options but started
>to use two that it previously didn't:
>
>- 'git for-each-ref --sort=' option, but that's with us since
>  the earliest ever 'for-each-ref' version from more than a decade
>  ago...
>
>- 'git for-each-ref' format modifier 'strip=2', which was
>  introduced in v2.7.1~15^2 (tag: do not show ambiguous tag names
>  as "tags/foo", 2016-01-25), only about a year ago.  Were you
>  using a pre-2.7.1 version when seeing the problems?
>
> Gábor

Nope. I was using some version of next at some point recently (less
than a couple months old). I do not know exactly what caused it, and
I'm not really able to find out because I can't reproduce it any more.
(after a fresh make install).

Thanks,
Jake

Request re git status

[Ron Pero]

Hi

I almost got bit by git: I knew there were changes on the remote
server, but git status said I was uptodate with the remote.

This page explains it well.

http://stackoverflow.com/questions/27828404/why-does-git-status-show-branch-is-up-to-date-when-changes-exist-upstream

That page also contains a good suggestion:

Why ... not design it to [optionally] DO a fetch and THEN declare
whether it is up to date? Or change the message to tell what it really
did, e.g. "Your branch was up-to-date with 'origin/master' when last
checked at {timestamp}"? Or even just say, "Do a fetch to find out
whether your branch is up to date"?

Thanks, and best wishes,

Ron

Re: [PATCH/RFC] WIP: log: allow "-" as a short-hand for "previous branch"

[Junio C Hamano]

Siddharth Kannan  writes:

> Hey Junio, I did some more digging into the codepath:
> ...
> In case you would prefer for me to not work on this anymore
> because I am new to the codebase, I will leave it at this.

The above is nicely analized and summarized.

The earlier mention of "those new to the codebase" by me was "this
is an inappropriate topic as a GSoC microproject for people new to
the codebase" and it wasn't meant to say "this part of the code is
too precious to let unknown folks touch it."

The focus of GSoC being mentoring those who are new to the open
source development, and hopefully retain them in the community after
GSoC is over, we do expect microprojects to be suitable for those
who are new to the codebase.

The focus of microprojects are twofold.  It is a way for new people
to learn the way in which they will be interacting with the
community once they become Git developers, sending their patches
(which includes analyzing and explaining the problem they are trying
to solve and their solution to it) and receiving and responding to
review comments.  We also want to find out which candidates are
willing to learn and which ones are difficult to work with during
the process.  And its primary focus is not about solving the real
issues the project has with its code---something "bite-sized" is
sufficient (and desirable) for microprojects for both GSoC student
candidates and GSoC mentors and reviewers to work with.

> (c) -> Else look for "r1^-"
> ...
> Case (c) is a bit confusing. This could be something like "-^-", and
> something like "^-" could mean "Not commits on previous branch" or it
> could mean "All commits on this branch except for the parent of HEAD"

Do you mean:

"git rev-parse ^-" does not mean "git rev-parse HEAD^-", but we
probably would want to, and if that is what is going to happen,
"^-" should mean "HEAD^-", and cannot be used for "^@{-1}"?

It's friend "^!" does not mean "HEAD^!", and "^@" does not mean
"HEAD^@", either (the latter is somewhat borked, though, and "^@"
translates to "^HEAD" because confusingly "@" stands for "HEAD"
sometimes).  

So my gut feeling is that it is probably OK to make "^-" mean
"^@{-1}"; it may be prudent to at least initially keep "^-" an error
like it currently is already, though.

Re: [PATCH] Completion: Add support for --submodule=diff

[Peter Law]

Hi,

Junio C Hamano  wrote:
> Peter Law  writes:
>
>>> Teach git-completion.bash about the 'diff' option to 'git diff
>>> --submodule=', which was added in Git 2.11.
>>
>> I posted this patch back in December, but I've not heard anything. I'm
>> sure as maintainers you're all quite busy, but I was wondering how
>> long it usually takes to get a response to patches? (also whether I'd
>> gotten some part of the submission process wrong?)
>
> When there is clear "subsystem maintainer(s)" in the area, I try to
> refrain from commenting until they speak up, and completion scripts
> are one of these areas.  I usually ping them after a few days but in
> December with holidays and things people are usually slow, and so
> was I X-<.
>
> Will pick it up.  Thanks for a reminder; you absolutely did the
> right thing (i.e. sending it out with people who are likely to know
> about the area CC'ed, waiting for a while and then sending a
> reminder).

Awesome, many thanks!

Peter

What's cooking in git.git (Feb 2017, #02; Mon, 6)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.  The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[Graduated to "master"]

* cw/log-updates-for-all-refs-really (2017-02-01) 4 commits
  (merged to 'next' on 2017-02-02 at 3e11673fcc)
 + doc: add note about ignoring '--no-create-reflog'
  (merged to 'next' on 2017-01-31 at 53f71d2401)
 + update-ref: add test cases for bare repository
 + refs: add option core.logAllRefUpdates = always
 + config: add markup to core.logAllRefUpdates doc

 The "core.logAllRefUpdates" that used to be boolean has been
 enhanced to take 'always' as well, to record ref updates to refs
 other than the ones that are expected to be updated (i.e. branches,
 remote-tracking branches and notes).


* js/re-running-failed-tests (2017-01-27) 1 commit
  (merged to 'next' on 2017-01-31 at 30c3a9e0cf)
 + t/Makefile: add a rule to re-run previously-failed tests

 "make -C t failed" will now run only the tests that failed in the
 previous run.  This is usable only when prove is not use, and gives
 a useless error message when run after "make clean", but otherwise
 is serviceable.


* pl/complete-diff-submodule-diff (2017-01-30) 1 commit
  (merged to 'next' on 2017-01-31 at 7e668d325c)
 + Completion: Add support for --submodule=diff

 The command line completion (in contrib/) learned that
 "git diff --submodule=" can take "diff" as a recently added option.


* rs/object-id (2017-01-30) 3 commits
  (merged to 'next' on 2017-01-31 at c442e4780c)
 + checkout: convert post_checkout_hook() to struct object_id
 + use oidcpy() for copying hashes between instances of struct object_id
 + use oid_to_hex_r() for converting struct object_id hashes to hex strings

 "uchar [40]" to "struct object_id" conversion continues.


* sb/submodule-recursive-absorb (2017-01-26) 3 commits
  (merged to 'next' on 2017-01-31 at 0a24cfd06b)
 + submodule absorbing: fix worktree/gitdir pointers recursively for non-moves
 + cache.h: expose the dying procedure for reading gitlinks
 + setup: add gentle version of resolve_git_dir

 When a submodule "A", which has another submodule "B" nested within
 it, is "absorbed" into the top-level superproject, the inner
 submodule "B" used to be left in a strange state.  The logic to
 adjust the .git pointers in these submodules has been corrected.


* sb/submodule-update-initial-runs-custom-script (2017-01-26) 1 commit
  (merged to 'next' on 2017-01-31 at d794f894c6)
 + submodule update: run custom update script for initial populating as well

 The user can specify a custom update method that is run when
 "submodule update" updates an already checked out submodule.  This
 was ignored when checking the submodule out for the first time and
 we instead always just checked out the commit that is bound to the
 path in the superproject's index.


* sb/unpack-trees-super-prefix (2017-01-25) 4 commits
  (merged to 'next' on 2017-01-31 at dabe6ca2b1)
 + unpack-trees: support super-prefix option
 + t1001: modernize style
 + t1000: modernize style
 + read-tree: use OPT_BOOL instead of OPT_SET_INT

 "git read-tree" and its underlying unpack_trees() machinery learned
 to report problematic paths prefixed with the --super-prefix option.

--
[New Topics]

* bw/push-submodule-only (2017-02-01) 2 commits
  (merged to 'next' on 2017-02-06 at 851edafb14)
 + completion: add completion for --recurse-submodules=only
 + doc: add doc for git-push --recurse-submodules=only

 Add missing documentation update to a recent topic.

 Will merge to 'master'.


* cw/completion (2017-02-03) 7 commits
 - completion: recognize more long-options
 - completion: teach remote subcommands to complete options
 - completion: teach replace to complete options
 - completion: teach ls-remote to complete options
 - completion: improve bash completion for git-add
 - completion: add subcommand completion for rerere
 - completion: teach submodule subcommands to complete options

 More command line completion (in contrib/) for recent additions.

 Needs review.


* cw/tag-reflog-message (2017-02-06) 1 commit
 - tag: generate useful reflog message

 "git tag", because refs/tags/* doesn't keep reflog by default, did
 not leave useful message when adding a new entry to reflog.

 Waiting for review to conclude.
 An uneven error handling is somewhat disturbing.


* dl/document-that-difftool-takes-no-gui-option (2017-02-06) 1 commit
 - Document the --no-gui option in difftool

 A minor doc update.

 Waiting for review to conclude.
 A minor inconsistency is somewhat disturbing.


* ew/complete-svn-authorship-options 

[PATCH v4] tag: generate useful reflog message

[cornelius . weig]

From: Cornelius Weig 

Thanks for taking a look at my last version.

> On the other hand, it's not like failing to describe the tagged
> commit in the reflog is such a grave error.  If we can get away with
> being vague on a tag that points at an object of unknown type like
> the above code does, we could loosen the "oops, we thought we got a
> commit, but it turns out that we cannot read it" case below from
> die() to just stuffing generic _("commit object") in the reflog.

Good point. I agree that failing to create the message should be no reason to
die().
As you also pointed out, "internal object" is no reliable description
for unhandled object types. I changed that as well.

Changes wrt v3 (interdiff below):
 - change default message for unhandled object types
 - do not die if commit is not readable, but use default description instead
 - test: use verbatim HT character instead of \t


Cornelius Weig (1):
  tag: generate useful reflog message

 builtin/tag.c  | 54 +-
 t/t7004-tag.sh | 16 +++-
 2 files changed, 68 insertions(+), 2 deletions(-)

Interdiff v3..v4:
diff --git a/builtin/tag.c b/builtin/tag.c
index 638b68e..9b2eabd 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -323,19 +323,19 @@ static void create_reflog_msg(const unsigned char *sha1, 
struct strbuf *sb)
type = sha1_object_info(sha1, NULL);
switch (type) {
default:
-   strbuf_addstr(sb, _("internal object"));
+   strbuf_addstr(sb, _("object of unknown type"));
break;
case OBJ_COMMIT:
-   c = lookup_commit_reference(sha1);
-   buf = read_sha1_file(sha1, , );
-   if (!c || !buf) {
-   die(_("commit object %s could not be read"),
-   sha1_to_hex(sha1));
+   if ((buf = read_sha1_file(sha1, , )) != NULL) {
+   subject_len = find_commit_subject(buf, _start);
+   strbuf_insert(sb, sb->len, subject_start, subject_len);
+   } else {
+   strbuf_addstr(sb, _("commit object"));
}
-   subject_len = find_commit_subject(buf, _start);
-   strbuf_insert(sb, sb->len, subject_start, subject_len);
-   strbuf_addf(sb, ", %s", show_date(c->date, 0, 
DATE_MODE(SHORT)));
free(buf);
+
+   if ((c = lookup_commit_reference(sha1)) != NULL)
+   strbuf_addf(sb, ", %s", show_date(c->date, 0, 
DATE_MODE(SHORT)));
break;
case OBJ_TREE:
strbuf_addstr(sb, _("tree object"));
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 3c4cb58..894959f 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -86,7 +86,7 @@ test_expect_success 'creating a tag with --create-reflog 
should create reflog' '
test_when_finished "git tag -d tag_with_reflog" &&
git tag --create-reflog tag_with_reflog &&
git reflog exists refs/tags/tag_with_reflog &&
-   sed -e "s/^.*\t//" .git/logs/refs/tags/tag_with_reflog > actual &&
+   sed -e "s/^.*   //" .git/logs/refs/tags/tag_with_reflog > actual &&
test_cmp expected actual
 '

@@ -96,7 +96,7 @@ test_expect_success 'annotated tag with --create-reflog has 
correct message' '
test_when_finished "git tag -d tag_with_reflog" &&
git tag -m "annotated tag" --create-reflog tag_with_reflog &&
git reflog exists refs/tags/tag_with_reflog &&
-   sed -e "s/^.*\t//" .git/logs/refs/tags/tag_with_reflog > actual &&
+   sed -e "s/^.*   //" .git/logs/refs/tags/tag_with_reflog > actual &&
test_cmp expected actual
 '
-- 
2.10.2

[PATCH v4] tag: generate useful reflog message

[cornelius . weig]

From: Cornelius Weig 

When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:

Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging  ()". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
()" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)

If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:

 - "tree object"
 - "blob object"
 - "other tag object"

Signed-off-by: Cornelius Weig 
Reviewed-by: Junio C Hamano 
---
 builtin/tag.c  | 54 +-
 t/t7004-tag.sh | 16 +++-
 2 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/builtin/tag.c b/builtin/tag.c
index e40c4a9..bca890f 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -302,6 +302,54 @@ static void create_tag(const unsigned char *object, const 
char *tag,
}
 }
 
+static void create_reflog_msg(const unsigned char *sha1, struct strbuf *sb)
+{
+   enum object_type type;
+   struct commit *c;
+   char *buf;
+   unsigned long size;
+   int subject_len = 0;
+   const char *subject_start;
+
+   char *rla = getenv("GIT_REFLOG_ACTION");
+   if (rla) {
+   strbuf_addstr(sb, rla);
+   } else {
+   strbuf_addstr(sb, _("tag: tagging "));
+   strbuf_add_unique_abbrev(sb, sha1, DEFAULT_ABBREV);
+   }
+
+   strbuf_addstr(sb, " (");
+   type = sha1_object_info(sha1, NULL);
+   switch (type) {
+   default:
+   strbuf_addstr(sb, _("object of unknown type"));
+   break;
+   case OBJ_COMMIT:
+   if ((buf = read_sha1_file(sha1, , )) != NULL) {
+   subject_len = find_commit_subject(buf, _start);
+   strbuf_insert(sb, sb->len, subject_start, subject_len);
+   } else {
+   strbuf_addstr(sb, _("commit object"));
+   }
+   free(buf);
+
+   if ((c = lookup_commit_reference(sha1)) != NULL)
+   strbuf_addf(sb, ", %s", show_date(c->date, 0, 
DATE_MODE(SHORT)));
+   break;
+   case OBJ_TREE:
+   strbuf_addstr(sb, _("tree object"));
+   break;
+   case OBJ_BLOB:
+   strbuf_addstr(sb, _("blob object"));
+   break;
+   case OBJ_TAG:
+   strbuf_addstr(sb, _("other tag object"));
+   break;
+   }
+   strbuf_addch(sb, ')');
+}
+
 struct msg_arg {
int given;
struct strbuf buf;
@@ -335,6 +383,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
 {
struct strbuf buf = STRBUF_INIT;
struct strbuf ref = STRBUF_INIT;
+   struct strbuf reflog_msg = STRBUF_INIT;
unsigned char object[20], prev[20];
const char *object_ref, *tag;
struct create_tag_options opt;
@@ -494,6 +543,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
else
die(_("Invalid cleanup mode %s"), cleanup_arg);
 
+   create_reflog_msg(object, _msg);
+
if (create_tag_object) {
if (force_sign_annotate && !annotate)
opt.sign = 1;
@@ -504,7 +555,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (!transaction ||
ref_transaction_update(transaction, ref.buf, object, prev,
   create_reflog ? REF_FORCE_CREATE_REFLOG : 0,
-  NULL, ) ||
+  reflog_msg.buf, ) ||
ref_transaction_commit(transaction, ))
die("%s", err.buf);
ref_transaction_free(transaction);
@@ -514,5 +565,6 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
strbuf_release();
strbuf_release();
strbuf_release();
+   strbuf_release(_msg);
return 0;
 }
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 072e6c6..894959f 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -80,10 +80,24 @@ test_expect_success 'creating a tag using default HEAD 
should succeed' '
test_must_fail git reflog exists refs/tags/mytag
 '
 
+git log -1 > expected \
+   --format="format:tag: tagging %h (%s, %cd)%n" --date=format:%F
 test_expect_success 'creating a tag with --create-reflog should create reflog' 
'
test_when_finished "git tag -d tag_with_reflog" &&
git tag --create-reflog tag_with_reflog &&
-   

Re: Git clonebundles

[Junio C Hamano]

Christian Couder  writes:

> There is also Junio's work on Bundle v3 that was unfortunately
> recently discarded.
> Look for "jc/bundle" in:
>
> http://public-inbox.org/git/xmqq4m0cry60@gitster.mtv.corp.google.com/
>
> and previous "What's cooking in git.git" emails.

If people think it might be useful to have it around to experiment,
I can resurrect and keep that in 'pu' (or rather 'jch'), as long as
it does not overlap and conflict with other topics in flight.  Let
me try that in today's integration cycle.

Re: Cross-referencing the Git mailing list archive with their corresponding commits in `pu`

[Jeff King]

On Mon, Feb 06, 2017 at 08:48:20PM +, Eric Wong wrote:

> I haven't hit insurmountable performance problems, even on
> low-end hardware; especially since I started storing blob ids in
> Xapian itself, avoiding the expensive tree lookup via git.

The painful thing is traversing the object graph for clones and fetches.
Bitmaps help, but you still have to generate them.

> The main problem seems to be tree size.  Deepening (2/2/36 vs
> 2/38) might be an option (I think Peff brought that up); but it
> might be easier to switch to MM refs (working like
> logrotate) and rely on Xapian to tie the entire thing together.

Yes, the hashing is definitely one issue. Some numbers here:

  
http://public-inbox.org/git/20160805092805.w3nwv2l6jkbuw...@sigill.intra.peff.net/

If you have C commits on a tree with T entries, you have to do C*T hash
lookups for a flat tree (for each commit, you have to see "yup, already
saw that object"). Sharding that across H entries at the top level drops
the tree cost from T to H + T/H (actually, it's a bit worse because we
have to read the secondary tree, too). Sharding again (at H') gets you
H + H' + T/H/H'.

Let's imagine you do one message per commit, so C=T. At 400K messages,
that's about 160 billion hash lookups flat. At H=256, it's about 700
million. If you shard again with H'=256, it's 200 million. After that,
the additive terms start to dominate, and it's not worth going any
further (and also, we're ignoring the extra-tree cost to each level).

At that point you're better off to start having fewer commits. I know
that the schema you use does put useful information into the commit
message, but it's also redundant with what's in the messages themselves.
And it sounds like you push most of that out to Xapian anyway.

Imagine your repo had one commit with 400K historical messages, and then
grouped the new messages so that on average we got about 10 messages per
commit (this doesn't seem unrealistic for something that commits every
few minutes; the messages tend to be bunched in time; I ran some
numbers against a 10-minute mark in the earlier message).

Then after another 100K messages, we'd have C=10,001 and T=500K. With
two levels of hashing at 256 each, that's ~5 million hash lookups to
walk the graph. And those numbers would be reasonable for a hosting site
like GitHub.

I don't know what C is for the kernel repo, but I suspect with the right
tuning it could be made into large-but-reasonable.

-Peff

Re: git/git-scm.com GH Issue Tracker

[Jeff King]

On Mon, Feb 06, 2017 at 12:49:34PM -0800, Junio C Hamano wrote:

> Of course, that will make it easier to let broken objects created by
> newer reimplementations of Git (and bugs in our code that cause us
> to create such broken objects) go unnoticed, so we would want to
> keep them at warn (not ignore) for the end-users.

Yes, sorry if that wasn't clear. By "loosen" I just meant to warn,
not ignore.

So a viable path forward is perhaps:

  1. Add fetch.fsck.* (and probably transfer.fsck.*) to match the
 receive-pack options.

  2. Go over the current list of default warning/error settings and make
 sure they are sensible.

  3. Add a "light" mode to transfer.fsckObjects and friends that blocks
 only errors, not warnings. Maybe setting the config bool to
 "errors-only" instead of "true" or something.

  4. (Optional) Default transfer.fsckObjects to "errors-only".

 The escape hatch is to set fsckObjects to "false", or to downgrade
 your specific problem to a warning via transfer.fsck.*.

-Peff

Re: [PATCH v2 0/7] completion bash: add more options and commands

[Junio C Hamano]

cornelius.w...@tngtech.com writes:

> From: Cornelius Weig 
>
> This is the re-roll of patch series 
> <2017015724.19360-1-cornelius.w...@tngtech.com>.
>
> This patch series adds all long-options that are mentioned in the synopsis of
> the man-page for the respective git-command. There are only a few exceptions,
> as discussed in the above thread. For example, no unsafe options should be
> completed.
> Furthermore, the patches add subommand option completion for git-submodule and
> git-remote.

Reviewers, do these look good now?

Thanks all.

Re: [PATCHv2 00/21] completion: various __gitdir()-related improvements

[Junio C Hamano]

SZEDER Gábor  writes:

> This is a long overdue reroll of a bunch of bugfixes, cleanups and
> optimizations related to how the completion script finds the path to
> the repository and how it uses that path.  Most importantly this
> series adds support for completion following 'git -C path', and it
> eliminates a few subshells and git processes, for the sake of
> fork()+exec() challenged OSes.

Thanks. Queued.

Re: git/git-scm.com GH Issue Tracker

[Junio C Hamano]

Jeff King  writes:

> [1] If we had a more permissive set of defaults, it would probably make
> sense to turn on fsckObjects by default. Some of the checks are
> security-relevant, like disallowing trees with ".GIT",
> "../../etc/passwd", etc. Those _should_ be handled sanely by the
> rest of Git, but it serves as a belt-and-suspenders check, and also
> protects anybody with a buggy Git downstream from you.

Yeah, we really should encourage people to turn it on.  Turning it
on by default is one way to do so, of course.

I think the reason why the transfer side is stricter than the local
checking [*1*] is because the problem in the local history is
already done and there is not much the user can do to fix it, while
objects that originate from outside world could be rejected to keep
the receiving repository clean.


> GitHub has had the feature turned on for ages, with a few caveats:
>
>   - we loosened the zero-padded mode warning, because it was causing
>   too many false positives
>
>   - we loosened the timezone checks for the same reason; we've seen
>   time zones that aren't exactly 4 characters before
>
>   - we occasionally get complaints from people trying to push old
>   histories with bogus committer idents. Usually a missing name or
>   similar.

As long as we are sure that modern Git and its reimplementations no
longer create objects with this problems, I think loosening these
checks is perfectly sensible, as the only objects that trigger the
check will be the ones buried deep in the history made back when Git
was young.

Of course, that will make it easier to let broken objects created by
newer reimplementations of Git (and bugs in our code that cause us
to create such broken objects) go unnoticed, so we would want to
keep them at warn (not ignore) for the end-users.

>  So those are the ones we'd probably need to loosen off the bat, and
>  they're all pretty harmless. But it would be a potential irritating
>  regression for somebody if they have a history with other minor
>  flaws, and Git suddenly starts refusing to clone it.

[Footnote]

*1* ... which is what Jonathan Nieder originally wondered at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227

Re: Cross-referencing the Git mailing list archive with their corresponding commits in `pu`

[Eric Wong]

Johannes Schindelin  wrote:
> For details, see:
> http://public-inbox.org/git/11340844841342-git-send-email-mailing-lists@rawuncut.elitemail.org/
> (this is also an example where public-inbox' thread detection went utterly
> wrong, including way too many mails in the "thread")

Thanks, it should be fixed in an hour or two when reindexing
finishes...



but it looks like reindexing is a little buggy in that it reuses
thread IDs, too... (will fix)

The Tor .onion mirrors should be done, first, since they're on
better hardware:
http://hjrcffqmbrq6wope.onion/git/11340844841342-git-send-email-mailing-lists@rawuncut.elitemail.org/
http://czquwvybam4bgbro.onion/git/11340844841342-git-send-email-mailing-lists@rawuncut.elitemail.org/

> This last example also demonstrates a very curious test case for a
> different difficulty in trying to reconstruct lost correspondences: the
> patch series was applied *twice*, independently of each other. First, on
> the day v3 was submitted, it was applied on top of v1.8.1-rc0 (as commits
> ee26a6e2b8..dd465ce66f), although it was not merged until v1.8.1-rc3. 22
> days later, it was reapplied on top of maint so it could enter v1.8.0.3
> (back then, Git still had "patchlevel" versions): c2999adcd5..008c208c2c.
> 
> As you can see, there is a many-to-many relationship here, even if you do
> leave the *original* branch out of the picture entirely.

Fwiw, I've always seen the search ability of public-inbox as
analogous to rename detection in git; in that it can never be
perfect, but can still be tweaked and improved after-the-fact
and be used more flexibly.

Right now, the thread searching public-inbox is loose in that it
favors overmatching based on Subject in addition to References.
But the actual threading algorithm (for display) is strict,
relying only on References.  But yeah, there can be tweaks to
improve matching and introducing git (code) repository awareness
into the mail search...

> Will keep you posted,

Likewise :>

> P.S.: I used public-inbox.org links instead of commit references to the
> Git repository containing the mailing list archive, because the format of
> said Git repository is so unfavorable that it was determined very quickly
> in a discussion between Patrick Reynolds (GitHub) and myself that it would
> put totally undue burden on GitHub to mirror it there (compare also Carlos
> Nieto's talk at GitMerge titled "Top Ten Worst Repositories to host on
> GitHub").

Any suggestions on how the repository format can be improved?

I haven't hit insurmountable performance problems, even on
low-end hardware; especially since I started storing blob ids in
Xapian itself, avoiding the expensive tree lookup via git.

The main problem seems to be tree size.  Deepening (2/2/36 vs
2/38) might be an option (I think Peff brought that up); but it
might be easier to switch to MM refs (working like
logrotate) and rely on Xapian to tie the entire thing together.

Some change will definitely be needed for all LKML, but most
projects have less traffic than even git, and should be fine.


But, I am working to undermine centralized messaging systems
(which GitHub and GitLab both are), so they would be wise to
undermine public-inbox all the same ;>

Re: warning in tree xxx: contains zero-padded file modes

[Jeff King]

On Mon, Feb 06, 2017 at 02:23:37PM -0600, Samuel Lijin wrote:

> >> There are some discussions in the past [1] [2] about this.
> 
> I think you forgot to link to [2] :p

I think the [1] [2] there were recursive quotes from Duy's email. Those
footnotes were:

[1] 
http://public-inbox.org/git/%3CCAEBDL5W3DL0v=TusuB7Vg-4bWdAJh5d2Psc1N0Qe+KK3bZH3=q...@mail.gmail.com%3E/
[2] http://public-inbox.org/git/%3c20100326215600.ga10...@spearce.org%3E/

> The linked issue on bugs.debian.org has seen activity recently, which
> is the main reason I mentioned it separately as still relevant:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227

Yeah. I think that's not quite solvable with Git as we have it now.  We
have fsck.* and receive.fsck.* to tweak severity levels, but no matching
fetch.fsck.* for handling a push (and presumably a transfer.fsck.* to
cover both fetching and pushing). So there's a potential patch series
for anybody interested.

-Peff

Re: warning in tree xxx: contains zero-padded file modes

[Samuel Lijin]

On Mon, Feb 6, 2017 at 2:23 PM, Samuel Lijin  wrote:
> I'm just going to go ahead and split this off the git/git-scm.com
> issues thread since this is a distinct topic.
>
> On Mon, Feb 6, 2017 at 12:49 PM, Jeff King  wrote:
>> On Mon, Feb 06, 2017 at 05:18:03PM +0700, Duy Nguyen wrote:
>>
>>> On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin  wrote:
>>> > # Irrelevant but someone should take a look
>>> >
>>> > 693
>>>
>>> To save people some time (and since i looked at it anyway), this is
>>> about whether "warning in tree xxx: contains zero-padded file modes:
>>> from fsck should be a warning or error. It is a warning now even
>>> though "git -c transfer.fsckobjects=true clone" treats it as an error.
>>> There are some discussions in the past [1] [2] about this.
>
> I think you forgot to link to [2] :p
>
>> The bug that caused the trees is long-fixed. There's a question of
>> how severity levels should be handled in transfer.fsckObjects. By
>> default it treats everything as a reason to reject the object. Dscho
>> added configurable levels a few versions ago. It may be a good idea to
>> tweak the defaults to something more permissive[1].
>>
>>> There's also a question "And I failed to find in the documentation if
>>> transfer.fsckobjects could be disabled per repository, can you confirm
>>> it's not possible for now ?"
>>
>> I don't know why it wouldn't be, though note that it won't override
>> the operation-specific {receive,fetch}.fsckObjects.
>>
>> -Peff
>>
>> [1] If we had a more permissive set of defaults, it would probably make
>> sense to turn on fsckObjects by default. Some of the checks are
>> security-relevant, like disallowing trees with ".GIT",
>> "../../etc/passwd", etc. Those _should_ be handled sanely by the
>> rest of Git, but it serves as a belt-and-suspenders check, and also
>> protects anybody with a buggy Git downstream from you.
>>
>> GitHub has had the feature turned on for ages, with a few caveats:
>>
>>   - we loosened the zero-padded mode warning, because it was causing
>> too many false positives
>>
>>   - we loosened the timezone checks for the same reason; we've seen
>> time zones that aren't exactly 4 characters before
>>
>>   - we occasionally get complaints from people trying to push old
>> histories with bogus committer idents. Usually a missing name or
>> similar.
>>
>>  So those are the ones we'd probably need to loosen off the bat, and
>>  they're all pretty harmless. But it would be a potential irritating
>>  regression for somebody if they have a history with other minor
>>  flaws, and Git suddenly starts refusing to clone it.
>
> The linked issue on bugs.debian.org has seen activity recently, which
> is the main reason I mentioned it separately as still relevant:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227

I take it back: last activity was in Feb 2016. >_<

warning in tree xxx: contains zero-padded file modes

[Samuel Lijin]

I'm just going to go ahead and split this off the git/git-scm.com
issues thread since this is a distinct topic.

On Mon, Feb 6, 2017 at 12:49 PM, Jeff King  wrote:
> On Mon, Feb 06, 2017 at 05:18:03PM +0700, Duy Nguyen wrote:
>
>> On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin  wrote:
>> > # Irrelevant but someone should take a look
>> >
>> > 693
>>
>> To save people some time (and since i looked at it anyway), this is
>> about whether "warning in tree xxx: contains zero-padded file modes:
>> from fsck should be a warning or error. It is a warning now even
>> though "git -c transfer.fsckobjects=true clone" treats it as an error.
>> There are some discussions in the past [1] [2] about this.

I think you forgot to link to [2] :p

> The bug that caused the trees is long-fixed. There's a question of
> how severity levels should be handled in transfer.fsckObjects. By
> default it treats everything as a reason to reject the object. Dscho
> added configurable levels a few versions ago. It may be a good idea to
> tweak the defaults to something more permissive[1].
>
>> There's also a question "And I failed to find in the documentation if
>> transfer.fsckobjects could be disabled per repository, can you confirm
>> it's not possible for now ?"
>
> I don't know why it wouldn't be, though note that it won't override
> the operation-specific {receive,fetch}.fsckObjects.
>
> -Peff
>
> [1] If we had a more permissive set of defaults, it would probably make
> sense to turn on fsckObjects by default. Some of the checks are
> security-relevant, like disallowing trees with ".GIT",
> "../../etc/passwd", etc. Those _should_ be handled sanely by the
> rest of Git, but it serves as a belt-and-suspenders check, and also
> protects anybody with a buggy Git downstream from you.
>
> GitHub has had the feature turned on for ages, with a few caveats:
>
>   - we loosened the zero-padded mode warning, because it was causing
> too many false positives
>
>   - we loosened the timezone checks for the same reason; we've seen
> time zones that aren't exactly 4 characters before
>
>   - we occasionally get complaints from people trying to push old
> histories with bogus committer idents. Usually a missing name or
> similar.
>
>  So those are the ones we'd probably need to loosen off the bat, and
>  they're all pretty harmless. But it would be a potential irritating
>  regression for somebody if they have a history with other minor
>  flaws, and Git suddenly starts refusing to clone it.

The linked issue on bugs.debian.org has seen activity recently, which
is the main reason I mentioned it separately as still relevant:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743227

Re: [PATCH 00/12] completion: speed up refs completion

[SZEDER Gábor]

On Mon, Feb 6, 2017 at 7:31 PM, Jacob Keller  wrote:
> On Fri, Feb 3, 2017 at 7:15 PM, Jacob Keller  wrote:
>> I haven't had a chance to further investigate, but I tried this series
>> out (from your github) and it appears that this series (or the
>> previous series for __gitdir work) breaks "git log" ref completion.
>> I'll have further details when I am able to investigate a it more.
>>
>> Thanks,
>> Jake
>
> At first I had the same problem, but I verified by re-installing the
> completion script and the problem appears to have gone away. I suspect
> what happened is that the original time, I forgot to actually install
> the new version of git, and only installed the completion script, so
> when some of the commands were run with new options they (silently)
> failed and the result was missing completion values.
>
> Once I properly re-installed everything it appears to work as
> expected. I haven't found any other issues yet.

Thanks, that's good to hear.

Still, I'm a bit puzzled as to what exactly might have caused your
problem.  Considering new options:

  - the __gitdir()-related series added the 'git rev-parse
--absolute-git-dir' option, but only ever used it if you invoked
completion after 'git -C some/where'.

 - The refs completion speedup didn't add any new options but started
   to use two that it previously didn't:

   - 'git for-each-ref --sort=' option, but that's with us since
 the earliest ever 'for-each-ref' version from more than a decade
 ago...

   - 'git for-each-ref' format modifier 'strip=2', which was
 introduced in v2.7.1~15^2 (tag: do not show ambiguous tag names
 as "tags/foo", 2016-01-25), only about a year ago.  Were you
 using a pre-2.7.1 version when seeing the problems?

Gábor

Re: [PATCH v3] tag: generate useful reflog message

[Junio C Hamano]

cornelius.w...@tngtech.com writes:

> + strbuf_addstr(sb, " (");
> + type = sha1_object_info(sha1, NULL);
> + switch (type) {
> + default:
> + strbuf_addstr(sb, _("internal object"));
> + break;

The code does not even know if this is an "internal" object, does
it?  What it got was simply an object of an unknown type that it is
not prepared to handle.  It's not like you are trying to die() in
this function (I see a die() upon failing to read the referent
commit), so I wonder if this should be a die("BUG").

On the other hand, it's not like failing to describe the tagged
commit in the reflog is such a grave error.  If we can get away with
being vague on a tag that points at an object of unknown type like
the above code does, we could loosen the "oops, we thought we got a
commit, but it turns out that we cannot read it" case below from
die() to just stuffing generic _("commit object") in the reflog.

Between the two extremes above, I am leaning towards making it more
lenient myself, but others may have different opinions.

> + case OBJ_COMMIT:
> + c = lookup_commit_reference(sha1);
> + buf = read_sha1_file(sha1, , );
> + if (!c || !buf) {
> + die(_("commit object %s could not be read"),
> + sha1_to_hex(sha1));
> + }
> + subject_len = find_commit_subject(buf, _start);
> + strbuf_insert(sb, sb->len, subject_start, subject_len);
> + strbuf_addf(sb, ", %s", show_date(c->date, 0, 
> DATE_MODE(SHORT)));
> + free(buf);
> + break;
> + case OBJ_TREE:
> + strbuf_addstr(sb, _("tree object"));
> + break;
> ...

> +git log -1 > expected \
> + --format="format:tag: tagging %h (%s, %cd)%n" --date=format:%F
>  test_expect_success 'creating a tag with --create-reflog should create 
> reflog' '
>   test_when_finished "git tag -d tag_with_reflog" &&
>   git tag --create-reflog tag_with_reflog &&
> - git reflog exists refs/tags/tag_with_reflog
> + git reflog exists refs/tags/tag_with_reflog &&
> + sed -e "s/^.*\t//" .git/logs/refs/tags/tag_with_reflog > actual &&

I'd spell that "\t" with an actual HT to make it portable [*1*].  

We have one example that uses the form in git-filter-branch
documentation and a script in the contrib/ area, but otherwise do
not have anything that relies on \t to be turned into HT by sed.

> + test_cmp expected actual
> +'
> +
> +git log -1 > expected \
> + --format="format:tag: tagging %h (%s, %cd)%n" --date=format:%F
> +test_expect_success 'annotated tag with --create-reflog has correct message' 
> '
> + test_when_finished "git tag -d tag_with_reflog" &&
> + git tag -m "annotated tag" --create-reflog tag_with_reflog &&
> + git reflog exists refs/tags/tag_with_reflog &&
> + sed -e "s/^.*\t//" .git/logs/refs/tags/tag_with_reflog > actual &&

Likewise.


[Reference]

*1* 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03

9.3.2 BRE Ordinary Characters

An ordinary character is a BRE that matches itself: any character in
the supported character set, except for the BRE special characters
listed in BRE Special Characters.

The interpretation of an ordinary character preceded by an unescaped
 ( '\\' ) is undefined, except for:

- The characters ')', '(', '{', and '}'

- The digits 1 to 9 inclusive (see BREs Matching Multiple Characters)

- A character inside a bracket expression

Re: Cross-referencing the Git mailing list archive with their corresponding commits in `pu`

[Junio C Hamano]

Johannes Schindelin  writes:

> So I thought maybe the From: line (from the body, if available, otherwise
> from the header) in conjunction with the "Date:" header would work.

FYI, I use a post-applypatch hook to populate refs/notes/amlog notes
tree when I queue a new patch; I am not sure how well the notes in
it are preserved across rebases, but it could be a good starting
point.  The notes tree is mirrored at git://github.com/git/gitster
repository.

E.g.

$ git show --notes=amlog --stat
commit 2488dcab22cee343fe35d9951160f0966a45fdb3
Author: Patrick Steinhardt 
Date:   Mon Feb 6 14:13:59 2017 +0100

worktree: fix option descriptions for `prune`

The `verbose` and `expire` options of the `git worktree prune`
subcommand have wrong descriptions in that they pretend to relate to
objects. But as the git-worktree(1) correctly states, these options have
nothing to do with objects but only with worktrees. Fix the description
accordingly.

Signed-off-by: Patrick Steinhardt 
Signed-off-by: Junio C Hamano 

Notes (amlog):
Message-Id: 


 builtin/worktree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH] Document the --no-gui option in difftool

[Junio C Hamano]

Denton Liu  writes:

> diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
> index 224fb3090..a2661d9cc 100644
> --- a/Documentation/git-difftool.txt
> +++ b/Documentation/git-difftool.txt
> @@ -87,9 +87,11 @@ instead.  `--no-symlinks` is the default on Windows.
>  
>  -g::
>  --gui::
> +--no-gui::
>   When 'git-difftool' is invoked with the `-g` or `--gui` option
>   the default diff tool will be read from the configured
> - `diff.guitool` variable instead of `diff.tool`.
> + `diff.guitool` variable instead of `diff.tool`. The `--no-gui`
> + option can be used to override this setting.
>  
>  --[no-]trust-exit-code::
>   'git-difftool' invokes a diff tool individually on each file.

Reading the whole of this file before applying this patch, I notice
that we have descriptions of negative forms only for some but not
all options. "--[no-]symlinks" and "--[no-]trust-exit-code" are
already there, but not this one.  

Shouldn't the patch be more like

---gui::
+--[no-]gui::

to be consistent with its existing friends, though?

Re: git/git-scm.com GH Issue Tracker

[Jeff King]

On Mon, Feb 06, 2017 at 12:15:08AM -0600, Samuel Lijin wrote:

> I've went through a bunch of open issues on the git/git-scm.com repo
> (specifically, everything after #600) and I think the bulk of them can
> be closed.
> 
> I've taken the liberty of classifying them as shown below.

Thanks, this is incredibly helpful. I'll close the appropriate ones you
identified.

-Peff

Re: [PATCH 00/12] completion: speed up refs completion

[Jacob Keller]

On Fri, Feb 3, 2017 at 7:15 PM, Jacob Keller  wrote:
> I haven't had a chance to further investigate, but I tried this series
> out (from your github) and it appears that this series (or the
> previous series for __gitdir work) breaks "git log" ref completion.
> I'll have further details when I am able to investigate a it more.
>
> Thanks,
> Jake

At first I had the same problem, but I verified by re-installing the
completion script and the problem appears to have gone away. I suspect
what happened is that the original time, I forgot to actually install
the new version of git, and only installed the completion script, so
when some of the commands were run with new options they (silently)
failed and the result was missing completion values.

Once I properly re-installed everything it appears to work as
expected. I haven't found any other issues yet.

Regards,
Jake

Re: git-scm.com status report

[Jeff King]

On Thu, Feb 02, 2017 at 03:33:50AM +0100, Jeff King wrote:

> We (the Git project) got control of the git-scm.com domain this year. We
> have never really had an "official" website, but I think a lot of people
> consider this to be one.
> 
> This is an overview of the current state, as well as some possible
> issues and future work.

Thanks everybody, for your responses here and off-list. After my mail
got posted to HN, I got quite a lot of private responses, including
offers to sponsor hosting, work on the site, etc. I'm still working my
way through them, but I wanted to try to respond in aggregate here.

First, a few clarifications:

  - The money for the site wasn't mentioned to me by GitHub at all.  I'm
quite sure they would continue to sponsor the site financially if
need be. The only reason I didn't promise that is because I hadn't
arranged it specifically, and "step 0" seemed like first making sure
our costs were reasonable.

  - Spinning the site out of GitHub's Heroku account isn't an urgent or
impending change. It came out of a conversation I had with people
auditing the GitHub account, where it is clearly a funny historical
anomaly. So I suspect we could just stay there indefinitely if need
be. But it seems to me like the right thing is to move it out for
two reasons:

  1. The site was always intended to serve the Git community, not
 GitHub, and it has increasingly become a community asset (e.g.,
 with the transfer of the domain name). The hosting assets
 should be held by the community, too, to help with things like
 continuity. If I get hit by a bus, the rest of the Git PLC
 should have access to the site without having to figure out who
 owns what.

  2. Right now I can't add any other co-admins to handle operational
 issues. So the bus factor and load of that part of operating
 the site can't be spread.

The responses I've gotten fall into a few buckets, I think:

  - Yes, the current hosting cost really is unnecessarily high. Most of
this is due to scaling wrong. The main costs are:

  1. Using 2x dynos; these have 1GB of RAM versus 512MB. The site
 does seem to use about 750MB. I have no idea why that is the
 case. There's probably some low-hanging fruit in reducing the
 memory use to keep it below 512MB, but I don't think anybody
 has dug in there.

  2. The site is scaled by using 3 dynos. It would be simpler and
 cheaper to stick a CDN in front of it, since the pages change
 very rarely. That's something I haven't looked into setting up
 yet.

 The prerequisite to using a CDN is actually making sure the
 content is deterministic and cacheable. There was a nice PR
 opened at https://github.com/git/git-scm.com/pull/941 towards
 that end.

  - It's mostly silly for this to be a Rails app at all. It's a static
site which occasionally sucks in and formats new content (like the
latest git version, new manpages, etc). The intent here was to make
something that would "just run" forever and pick up new versions
without human intervention. And that _does_ work, but it also makes
things more expensive and complicated than they need to be.

So a viable alternative is to use some kind of static site
generator and have someone (or something) responsible for pulling in
the new git versions occasionally.

A few people have expressed interesting this. There's some
preliminary work here:

  https://github.com/git/git-scm.com/pull/941

and at least GitLab has expressed some interest. So I'll let people
coordinate in that PR or a new one what the result should look like.
Working patches trump discussion. :)

I have also talked with the GitHub Pages people, and they think
hosting it as a Jekyll page wouldn't be a big deal performance-wise
(with the caveat that we'd need to pre-render the asciidoctor bits
ourselves, as Jekyll doesn't do asciidoc). So that's a viable option
for hosting it for effectively free (though I think we _would_ still
want to put a CDN in front of it). But if somebody has an
alternative option, that's fine, too.

  - Some people offered to help with running the site, or making major
transitions (like converting to a static site). The most important
thing to me there is that we have a solid maintenance plan. So I
would want some evidence that anybody doing a major work would stick
around in the community afterwards, or that it be done in a way that
the handoff back to community members is easy. So I'd probably look
for somebody already involved in the community, or somebody who
wants to join it building up that trust by taking on site
responsibilities over time.

  - Lots of people asked about small tasks to do. Mostly reviewing and
responding to issues and PR is 

[PATCH] squash! completion: fill COMPREPLY directly when completing refs

[SZEDER Gábor]

Care should be taken, though, because that prefix might contain
'for-each-ref' format specifiers as part of the left hand side of a
'..' range or '...' symmetric difference notation or fetch/push/etc.
refspec, e.g. 'git log "evil-%(refname)..br'.  Doubling every '%'
in the prefix will prevent 'git for-each-ref' from interpolating any
of those contained format specifiers.
---

This is really pathological, and I'm sure this has nothing to do with
whatever breakage Jacob experienced.
The shell metacharacters '(' and ')' still cause us trouble in various
ways, but that's nothing new and has been the case for quite a while
(always?).

It's already incorporated into (the rewritten)

  https://github.com/szeder/git completion-refs-speedup

 contrib/completion/git-completion.bash |  8 +---
 t/t9902-completion.sh  | 11 +++
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/contrib/completion/git-completion.bash 
b/contrib/completion/git-completion.bash
index dbbb62f5f..058f1d0ee 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -381,6 +381,7 @@ __git_refs ()
local list_refs_from=path remote="${1-}"
local format refs
local pfx="${3-}" cur_="${4-$cur}" sfx="${5-}"
+   local fer_pfx="${pfx//\%/%%}"
 
__git_find_repo_path
dir="$__git_repo_path"
@@ -406,6 +407,7 @@ __git_refs ()
if [ "$list_refs_from" = path ]; then
if [[ "$cur_" == ^* ]]; then
pfx="$pfx^"
+   fer_pfx="$fer_pfx^"
cur_=${cur_#^}
fi
case "$cur_" in
@@ -429,13 +431,13 @@ __git_refs ()
"refs/remotes/$cur_*" "refs/remotes/$cur_*/**")
;;
esac
-   __git_dir="$dir" __git for-each-ref 
--format="$pfx%($format)$sfx" \
+   __git_dir="$dir" __git for-each-ref 
--format="$fer_pfx%($format)$sfx" \
"${refs[@]}"
if [ -n "$track" ]; then
# employ the heuristic used by git checkout
# Try to find a remote branch that matches the 
completion word
# but only output if the branch name is unique
-   __git for-each-ref 
--format="$pfx%(refname:strip=3)$sfx" \
+   __git for-each-ref 
--format="$fer_pfx%(refname:strip=3)$sfx" \
--sort="refname:strip=3" \
"refs/remotes/*/$cur_*" 
"refs/remotes/*/$cur_*/**" | \
uniq -u
@@ -457,7 +459,7 @@ __git_refs ()
case "HEAD" in
$cur_*) echo "${pfx}HEAD$sfx" ;;
esac
-   __git for-each-ref 
--format="$pfx%(refname:strip=3)$sfx" \
+   __git for-each-ref 
--format="$fer_pfx%(refname:strip=3)$sfx" \
"refs/remotes/$remote/$cur_*" \
"refs/remotes/$remote/$cur_*/**"
else
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 1206a38ed..be584c069 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -951,6 +951,17 @@ test_expect_success 'teardown after filtering matching 
refs' '
git update-ref -d refs/remotes/other/matching/branch-in-other
 '
 
+test_expect_success '__git_refs - for-each-ref format specifiers in prefix' '
+   cat >expected <<-EOF &&
+   evil-%%-%42-%(refname)..master
+   EOF
+   (
+   cur="evil-%%-%42-%(refname)..mas" &&
+   __git_refs "" "" "evil-%%-%42-%(refname).." mas >"$actual"
+   ) &&
+   test_cmp expected "$actual"
+'
+
 test_expect_success '__git_complete_refs - simple' '
sed -e "s/Z$//g" >expected <<-EOF &&
HEAD Z
-- 
2.11.1.499.gb6fcc8b3a

Re: [PATCH v3] parse-remote: remove reference to unused op_prep

[Junio C Hamano]

Siddharth Kannan  writes:

> Hey Pranit,
> On Sun, Feb 05, 2017 at 02:45:46AM +0530, Pranit Bauva wrote:
>> Hey Siddharth,
>> 
>> On Sat, Feb 4, 2017 at 8:01 PM, Siddharth Kannan
>>  wrote:
>> > The error_on_missing_default_upstream helper function learned to
>> > take op_prep argument with 15a147e618 ("rebase: use @{upstream}
>> > if no upstream specified", 2011-02-09), but as of 045fac5845
>> > ("i18n: git-parse-remote.sh: mark strings for translation",
>> >  2016-04-19), the argument is no longer used.  Remove it.
>> >
>> > Signed-off-by: Siddharth Kannan 
>> 
>> This looks good to me! Thanks :)
>> 
>> Regards,
>> Pranit Bauva
>
> Should I send this patch with "To:" set to Junio and "Cc:" set to the
> mailing list, as mentioend in the SubmittingPatches document?

Nah, I was watching the discussion from the sideline.  I'll pick it
up after doing one final read on the patch myself.

Thanks, both.

Re: [PATCH] difftool: fix bug when printing usage

[Junio C Hamano]

Johannes Schindelin  writes:

>> +test_expect_success 'basic usage requires no repo' '
>> +lines=$(git difftool -h | grep ^usage: | wc -l) &&
>> +test "$lines" -eq 1 &&
>
> It may be easier to debug future breakages if you wrote
>
>   git difftool -h | grep ^usage: >output &&
>   test_line_count = 1 output &&
> or even better (changing the semantics now):
>
>   test_expect_code 129 git difftool -h >output &&
>   grep ^usage: output &&

True.

>> +# create a ceiling directory to prevent Git from finding a repo
>> +mkdir -p not/repo &&
>> +ceiling="$PWD/not" &&
>> +lines=$(cd not/repo &&
>> +GIT_CEILING_DIRECTORIES="$ceiling" git difftool -h |
>> +grep ^usage: | wc -l) &&
>> +test "$lines" -eq 1 &&
>
> Likewise, this would become
>
>   GIT_CEILING_DIRECTORIES="$PWD/not" \
>   test_expect_code 129 git -C not/repo difftool -h >output &&
>   grep ^usage: output

I agree with the intent, but the execution here is "Not quite".
test_expect_code being a shell function, it does not take the
"one-shot environment assignment for this single invocation," like
external commands do.

> More importantly: When I read $PWD all kinds of alarm bells go off in my
> head, as I immediately think of all the issues we have on Windows due to
> Git's regression test using POSIX paths all over the place.

And we appreciate that somebody who is more familiar with the issue
is watching ;-).

> Insofar as I am the author of the builtin difftool:
>
> Acked-by: Johannes Schindelin 

OK, thanks.

Re: [PATCH/RFC] WIP: log: allow "-" as a short-hand for "previous branch"

[Siddharth Kannan]

Hey Junio, I did some more digging into the codepath:

On Sun, Feb 05, 2017 at 04:15:03PM -0800, Junio C Hamano wrote:
> 
> A correct solution needs to know if the argument is at the position
> where a revision (or revision range) is expected and then give the
> tip of the previous branch when it sees "-" (and other combinations
> this patch tries to cover).  In other words, the parser always knows
> what it is parsing, and if and only if it is parsing a rev, react to
> "-" and think "ah, the user wants me to use the tip of the previous
> branch".
> 
> But the code that knows that it expects to see a revision already
> exists, and it is the real parser.  In the above snippet,
> setup_revisions() is the one that does the real parsing of argv[].
> The code there knows when it wants to see a rev, and takes argv[i]
> and turns into an object to call add_pending_object().  That codepath
> may not yet know that "-" means the tip of the previous branch, and
> that is where the change needs to go.

Inside setup_revisions, it tries to parse arguments and options. In
there, is this line of code:

if (*arg == '-') {

Once control enters this branch, it will either parse the argument as
an option / pseudo-option, or simply leave this argument as is in the
argv[] array and move forward with the other arguments.

So, first I need to teach setup_revisions that something starting with
a "-" might be a revision or a revision range.

After this, going further down the codepath, in
revision.c:handle_revision_arg: 

The argument is parsed to find out if it is of the form
rev1...rev2 or rev1..rev2 or just rev1, etc.

(a) -> If `..` or `...` was found, then two pointers "this" and "next"
now hold the from and to revisions, and the function
get_sha1_committish is called on them. In case both were found to be
committish, then the char pointers now hold the sha1 in them, they are
parsed into objects.

(b) -> Else look for "r1^@", "r1^!" (This could be "-^@", "-^!") To
get r1, again the function get_sha1_committish is called with only r1
as the parameter.

(c) -> Else look for "r1^-"

(d) -> Else look for the argument using the same get_sha1_committish
function (It any "^" was present in it, it has already been noted and
removed)

Cases (a), (b) and (d) can be handled by putting this inside
get_sha1_committish. (Further discussion about that below)

Case (c) is a bit confusing. This could be something like "-^-", and
something like "^-" could mean "Not commits on previous branch" or it
could mean "All commits on this branch except for the parent of HEAD"
Please tell me if this is confusing or undesired altogether.
Personally, I feel that people who have been using "^-" would be
very confused if it's behaviour changed.

So, all the code till now points at adding the patch for "-" = "@{-1}"
inside get_sha1_committish or downstream from there.

get_sha1_committish 
-> get_sha1_with_context 
-> get_sha1_with_context_1
-> get_sha1_1 
  -> peel_onion -> calling get_sha1_basic again with the ref
  only (after peeling) 
  -> get_sha1_basic -> includes parsing of "@{-N}" type revs. So, 
  this indicates that if we can convert the "-" appropriately 
  before this point, then it would be good.
  -> get_short_sha1

So, this patch reduces to the following 2 tasks:

1. Teach setup_revisions that something starting with "-" can be an
argument as well
2. Teach get_sha1_basic that "-" means the tip of the previous branch
perhaps by replacing it with "@{-1}" just before the reflog parsing is
done

> A correct solution will be a lot more involved, of course, and I
> think it will be larger than a reasonable microproject for people
> new to the codebase.

So true :) I had spent a fair bit of time already on my previous patch,
and I thought I might as well complete my research into this, and send
this write-up to the mailing list, so that I could write a patch some
time later. In case you would prefer for me to not work on this
anymore because I am new to the codebase, I will leave it at this.

- Siddharth Kannan

Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references

[Marc Branchaud]

On 2016-12-19 11:44 AM, Michael Haggerty wrote:

This patch series changes a bunch of details about how remote-tracking
references are rendered in the commit list of gitk:


I don't see this series in git v2.12.0-rc0, nor in Paul's gitk repo.

I hope this is an oversight, and not that the series got dropped for 
some reason.


M.




* Omit the "remote/" prefix on normal remote-tracking references. They
  are already distinguished via their two-tone rendering and (usually)
  longer names, and this change saves a lot of visual clutter and
  horizontal space.

* Render remote-tracking references that have more than the usual
  three slashes like

  origin/foo/bar
  ^^^

  rather than

  origin/foo/bar (formerly remotes/origin/foo/bar)
  ^^^  ^^^

  , where the indicated part is the prefix that is rendered in a
  different color. Usually, such a reference represents a remote
  branch that contains a slash in its name, so the new split more
  accurately portrays the separation between remote name and remote
  branch name.

* Introduce a separate constant to specify the background color used
  for the branch name part of remote-tracking references, to allow it
  to differ from the color used for local branches (which by default
  is bright green).

* Change the default background colors for remote-tracking branches to
  light brown and brown (formerly they were pale orange and bright
  green).

I understand that the colors of pixels on computer screens is an even
more emotional topic that that of bikesheds, so I implemented the last
change as a separate commit, the last one in the series. Feel free to
drop it if you don't want the default color change.

Along the way, I did a bunch of refactoring in the area to make these
changes easier, and introduced a constant for the background color of
"other" references so that it can also be adjusted by users.

(Unfortunately, these colors can only be adjusted by editing the
configuration file. Someday it would be nice to allow them to be
configured via the preferences dialog.)

It's been a while since I've written any Tcl code, so I apologize in
advance for any howlers :-)

This branch applies against the `master` branch in
git://ozlabs.org/~paulus/gitk.

Michael

Michael Haggerty (13):
  gitk: when processing tag labels, don't use `marks` as scratch space
  gitk: keep track of tag types in a separate `types` array
  gitk: use a type "tags" to indicate abbreviated tags
  gitk: use a type "mainhead" to indicate the main HEAD branch
  gitk: fill in `wvals` as the tags are first processed
  gitk: simplify regexp
  gitk: extract a method `remotereftext`
  gitk: only change the color of the "remote" part of remote refs
  gitk: shorten labels displayed for modern remote-tracking refs
  gitk: use type "remote" for remote-tracking references
  gitk: introduce a constant otherrefbgcolor
  gitk: add a configuration setting `remoterefbgcolor`
  gitk: change the default colors for remote-tracking references

 gitk | 114 ---
 1 file changed, 76 insertions(+), 38 deletions(-)

Re: subtree merging fails

[Johannes Schindelin]

Hi Stavros,


On Mon, 6 Feb 2017, Stavros Liaskos wrote:

> Please check this issue for a description of the bug:
> https://github.com/git/git-scm.com/issues/896#issuecomment-277587626

Just an observation from my side: if I see a request for help on this
mailing list where the sender merely pastes a link and does not bother to
condense and summarize the information in the linked page, to help
potential helpers, I am highly unlikely to even click on that link, let
alone to try to help.

Maybe you would want to spend as much effort on a request for help as you
would like to ask people to spend on a reply?

Ciao,
Johannes

Re: [PATCH] difftool: fix bug when printing usage

[Johannes Schindelin]

Hi David,

On Sun, 5 Feb 2017, David Aguilar wrote:

> "git difftool -h" reports an error:
> 
>   fatal: BUG: setup_git_env called without repository
> 
> Defer repository setup so that the help option processing happens before
> the repository is initialized.
> 
> Add tests to ensure that the basic usage works inside and outside of a
> repository.
> 
> Signed-off-by: David Aguilar 
> ---
> This bug exists in both "master" and "next".
> This patch has been tested on both branches.

Thanks for noticing and for patching!

> diff --git a/builtin/difftool.c b/builtin/difftool.c
> index b5e85ab079..d13350ce83 100644
> --- a/builtin/difftool.c
> +++ b/builtin/difftool.c
> @@ -647,10 +647,6 @@ int cmd_difftool(int argc, const char **argv, const char 
> *prefix)
>   OPT_END()
>   };
>  
> - /* NEEDSWORK: once we no longer spawn anything, remove this */
> - setenv(GIT_DIR_ENVIRONMENT, absolute_path(get_git_dir()), 1);
> - setenv(GIT_WORK_TREE_ENVIRONMENT, absolute_path(get_git_work_tree()), 
> 1);
> -
>   git_config(difftool_config, NULL);
>   symlinks = has_symlinks;
>  
> @@ -661,6 +657,10 @@ int cmd_difftool(int argc, const char **argv, const char 
> *prefix)
>   if (tool_help)
>   return print_tool_help();
>  
> + /* NEEDSWORK: once we no longer spawn anything, remove this */
> + setenv(GIT_DIR_ENVIRONMENT, absolute_path(get_git_dir()), 1);
> + setenv(GIT_WORK_TREE_ENVIRONMENT, absolute_path(get_git_work_tree()), 
> 1);
> +
>   if (use_gui_tool && diff_gui_tool && *diff_gui_tool)
>   setenv("GIT_DIFF_TOOL", diff_gui_tool, 1);
>   else if (difftool_cmd) {

Aaargh. You know, when you are used to code review systems where you can
easily increase the context of the diff hunks, static patches are...
tedious to review.

For the record: the context between those two hunks is:

   argc = parse_options(argc, argv, prefix, builtin_difftool_options,
 builtin_difftool_usage, PARSE_OPT_KEEP_UNKNOWN |
 PARSE_OPT_KEEP_DASHDASH);

> diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
> index aa0ef02597..21e2ac4ad6 100755
> --- a/t/t7800-difftool.sh
> +++ b/t/t7800-difftool.sh
> @@ -23,6 +23,19 @@ prompt_given ()
>   test "$prompt" = "Launch 'test-tool' [Y/n]? branch"
>  }
>  
> +test_expect_success 'basic usage requires no repo' '
> + lines=$(git difftool -h | grep ^usage: | wc -l) &&
> + test "$lines" -eq 1 &&

It may be easier to debug future breakages if you wrote

git difftool -h | grep ^usage: >output &&
test_line_count = 1 output &&

or even better (changing the semantics now):

test_expect_code 129 git difftool -h >output &&
grep ^usage: output &&

> + # create a ceiling directory to prevent Git from finding a repo
> + mkdir -p not/repo &&
> + ceiling="$PWD/not" &&
> + lines=$(cd not/repo &&
> + GIT_CEILING_DIRECTORIES="$ceiling" git difftool -h |
> + grep ^usage: | wc -l) &&
> + test "$lines" -eq 1 &&

Likewise, this would become

GIT_CEILING_DIRECTORIES="$PWD/not" \
test_expect_code 129 git -C not/repo difftool -h >output &&
grep ^usage: output

> + rmdir -p not/repo

I am not sure how portable `rmdir -p` is. Why not use

test_when_finished rm -r not

instead?

But those are all really minor bike-sheddings, and I promised myself that
I would avoid those (as I find them rather pointless) unless there is at
least one real benefit. In this case, I think the result becomes more
readable:

-- snip --
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 21e2ac4ad6d..7d7cb63d61e 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -24,16 +24,14 @@ prompt_given ()
 }
 
 test_expect_success 'basic usage requires no repo' '
-   lines=$(git difftool -h | grep ^usage: | wc -l) &&
-   test "$lines" -eq 1 &&
-   # create a ceiling directory to prevent Git from finding a repo
-   mkdir -p not/repo &&
-   ceiling="$PWD/not" &&
-   lines=$(cd not/repo &&
-   GIT_CEILING_DIRECTORIES="$ceiling" git difftool -h |
-   grep ^usage: | wc -l) &&
-   test "$lines" -eq 1 &&
-   rmdir -p not/repo
+   test_expect_code 129 git difftool -h >output &&
+   grep ^usage: output &&
+   # create a ceiling directory to prevent Git from finding a repo
+   mkdir -p not/repo &&
+   test_when_finished rm -r not &&
+   GIT_CEILING_DIRECTORIES="$PWD/not" \
+   test_expect_code 129 git -C not/repo difftool -h >output &&
+   grep ^usage: output
 '
 
 # Create a file on master and change it on branch
-- snap --

More importantly: When I read $PWD all kinds of alarm bells go off in my
head, as I immediately think of all the issues we have on Windows due to
Git's regression test using POSIX paths all over the place.

In this particular instance, it *does* work, magically, 

Re: [PATCH] tag: generate useful reflog message

[Cornelius Weig]

On 02/06/2017 12:25 AM, Junio C Hamano wrote:
> cornelius.w...@tngtech.com writes
> For a tag, I would imagine something like "tag: tagged 4e59582ff7
> ("Seventh batch for 2.12", 2017-01-23)" would be more appropriate.

Yes, I agree that this is much clearer. The revised version v3
implements this behavior.

>> Notes:
>> While playing around with tag reflogs I also found a bug that was present
>> before this patch. It manifests itself when the sha1-ref in the reflog 
>> does not
>> point to a commit object but something else.
> 
> I think the fix would involve first ripping out the "reflog walking"
> code that was bolted on and stop allowing it to inject the entries
> taken from the reflog into the "walk the commit DAG" machinery.
> Then "reflog walking" code needs to be taught to have its own "now
> we got a single object to show, show it (using the helper functions
> to show a single object that is already used by 'git show')" code,
> instead of piggy-backing on the output codepath used by "log" and
> "rev-list".

I'll start investigating how that could be done. My first glance tells
me that it won't be easy. Especially because I'm not yet familiar with
the git code.

Thanks for your advice!

Re: feature request: add -q to "git branch"

[Kevin Layer]

I think I got my git versions (old and new) mixed up.  Sorry for the noise.

On Sat, Feb 4, 2017 at 1:17 PM, Pranit Bauva  wrote:
> Hey Kevin,
>
> Sorry for the previous message.
>
> On Sun, Feb 5, 2017 at 2:47 AM, Pranit Bauva  wrote:
>> Hey Kevin,
>>
>> On Fri, Feb 3, 2017 at 11:59 PM, Kevin Layer  wrote:
>>> It should be possible to quietly create a branch.
>
> I think `git branch` is already quiet. Are you seeing something else?
>
> Regards,
> Pranit Bauva

Re: BUG: "git checkout -q -b foo origin/foo" is not quiet

[Kevin Layer]

Yeah, my bad.  I was confused.  Sorry for the noise.

On Fri, Feb 3, 2017 at 4:55 PM, Cornelius Weig
 wrote:
> On 02/03/2017 10:36 PM, Kevin Layer wrote:
>> Note that git version 1.8.3.1 is quiet and does not print the
>> "tracking remote" message.
>
> So what you are saying is, that git v1.8.3.1 *is* quiet, but v1.7.1 is
> not? Sounds like a fixed bug to me.
>
> I also checked with the latest version and it did not print anything
> when used with -q.
>
>
> You seem to urgently need quiet branch creation. Have you thought about
> dumping unwanted output in the shell? E.g. in bash
>
> $ git whatever >&/dev/null

Re: git-scm.com status report

[Jeff King]

On Mon, Feb 06, 2017 at 01:41:04AM +0530, Pranit Bauva wrote:

> On Thu, Feb 2, 2017 at 8:03 AM, Jeff King  wrote:
> > ## What's on the site
> >
> > We have the domains git-scm.com and git-scm.org (the latter we've had
> > for a while). They both point to the same website, which has general
> > information about Git, including:
> 
> Since we have an "official" control over the website, shouldn't we be
> using the .org domain more because we are more of an organization?
> What I mean is that in many places, we have referred to git-scm.com,
> which was perfectly fine because it was done by github which is a
> company but now I think it would be more appropriate to use
> git-scm.org domain. We can forward all .com requests to .org and try
> to move all reference we know about, to .org. What do you all think?

I don't have a preference myself. I know a lot of non-commercial groups
(which I think the Git project is) try to prefer ".org" to signal that.

Switching it around would require some DNS changes. I think ".org" goes
to a server the DNS provider (Gandi) runs which issues an HTTP 301 to
".com". So we'd want to reverse that, or possibly just treat them both
as equals. That shouldn't be too hard, and will have to be done via
Conservancy.

I don't know what it would mean in terms of search-engine optimization.
I know Google tries to detect duplicate names for sites and treat one as
canonical. And that's going to be ".com" now, based on the existing
redirect and on the fact that most people will have linked to .com.

I'm not sure what disadvantages there are to switching now, or if there
are things we should be doing to tell search engines (I seem to recall
Google's Webmaster tools have options to say "this is the canonical
name"). This is pretty far outside my area of expertise, so it may not
even be something to care about at all. Just things to consider (and
hopefully more clueful people than I can comment on it).

-Peff

Re: [PATCH v3 0/5] stash: support pathspec argument

[Jeff King]

On Sun, Feb 05, 2017 at 08:26:37PM +, Thomas Gummerer wrote:

> Thanks Junio for the review in the previous round.
> 
> Changes since v2:
> 
> - $IFS should now be supported by using "$@" everywhere instead of using
>   a $files variable.
> - Added a new patch showing the old behaviour of git stash create is
>   preserved.
> - Rephrased the documentation
> - Simplified the option parsing in save_stash, by leaving the
>   actual parsing to push_stash instead.

Overall, I like the direction this is heading. I raised a few issues,
the most major of which is whether we want to allow the minor regression
in "git stash create -m foo".

This also makes "git stash push -p " work, which is good. I
don't think "git stash -p " does, though. I _think_ it
would be trivial to do on top, since we already consider that case an
error. That's somewhat outside the scope of your series, so I won't
complain (too much :) ) if you don't dig into it, but it might just be
trivial on top.

A few other random bits I noticed while playing with the new code:

  $ git init
  $ echo content >file && git add file && git commit -m file
  $ echo change >file

  $ git stash push -p not-file
  No changes.
  No changes selected

Probably only one of those is necessary. :)

Let's keep trying a few things:

  $ git stash push not-file
  Saved working directory and index state WIP on master: 5d5f951 file
  Unstaged changes after reset:
  M file
  M file

The unstaged change is mentioned twice, which is weird. But weirder
still is that we created a stash at all, as it's empty. Why didn't we
hit the "no changes selected" path?

And one more:

  $ echo foo >untracked
  $ git stash push untracked
  Saved working directory and index state WIP on master: 5d5f951 file
  Unstaged changes after reset:
  M file
  M file
  Removing untracked

We removed the untracked file, even though it wasn't actually stashed! I
thought at first this was because it was mentioned as a pathspec, but it
seems to happen even with a different name:

  $ echo foo >untracked
  $ git stash push does-not-exist
  ...
  Removing untracked

That seems dangerous.

-Peff

Re: [PATCH v3 4/5] stash: introduce new format create

[Jeff King]

On Sun, Feb 05, 2017 at 08:26:41PM +, Thomas Gummerer wrote:

> git stash create currently supports a positional argument for adding a
> message.  This is not quite in line with how git commands usually take
> comments (using a -m flag).
> 
> Add a new syntax for adding a message to git stash create using a -m
> flag.  This is with the goal of deprecating the old style git stash
> create with positional arguments.
> 
> This also adds a -u argument, for untracked files.  This is already used
> internally as another positional argument, but can now be used from the
> command line.

How do we tell the difference between new-style invocations, and
old-style ones that look new-style? IOW, I think:

  git stash create -m works

currently treats "-m works" as the full message, and it would now become
just "works".

That may be an acceptable loss for the benefit we are getting. The
alternative is to make yet another verb for create, as we did with
save/push). I have a feeling that hardly anybody uses "create", though,
and it's mostly an implementation detail. So given the obscure nature,
maybe it's an acceptable level of regression. I dunno.

But either way, it should probably be in the commit message in case
somebody does have to track it down later.

-Peff

Re: [PATCH v3 3/5] stash: add test for the create command line arguments

[Jeff King]

On Sun, Feb 05, 2017 at 08:26:40PM +, Thomas Gummerer wrote:

> +test_expect_success 'create stores correct message' '
> + >foo &&
> + git add foo &&
> + STASH_ID=$(git stash create "create test message") &&
> + echo "On master: create test message" >expect &&
> + git show --pretty=%s ${STASH_ID} | head -n1 >actual &&
> + test_cmp expect actual
> +'

This misses failure exit codes from "git show" because it's on the left
side of a pipe. Perhaps "git show -s" or "git log -1" would get you the
same output without needing "head" (and saving a process and the time
spent generating the diff, as a bonus).

Ditto in the other tests from this patch and later ones.

-Peff

Re: [PATCH v3 2/5] stash: introduce push verb

[Jeff King]

On Sun, Feb 05, 2017 at 08:26:39PM +, Thomas Gummerer wrote:

> + -m|--message)
> + shift
> + stash_msg=${1?"-m needs an argument"}
> + ;;

I think this is our first use of the "?" parameter expansion magic. It
_is_ in POSIX, so it may be fine. We may get complaints from people on
weird shell variants, though. If that's the only reason to avoid it, I'd
be inclined to try it and see, as it is much shorter.

OTOH, most of the other usage errors call usage(), and this one doesn't.
Nor is the error message translatable. Perhaps we should stick to the
longer form (and add a helper function if necessary to reduce the
boilerplate).

> +save_stash () {
> + push_options=
> + while test $# != 0
> + do
> + case "$1" in
> + --help)
> + show_help
> + ;;
> + --)
> + shift
> + break
> + ;;
> + -*)
> + # pass all options through to push_stash
> + push_options="$push_options $1"
> + ;;
> + *)
> + break
> + ;;
> + esac
> + shift
> + done

I suspect you could just let "--help" get handled in the pass-through
case (it generally takes precedence over errors found in other options,
but I do not see any other parsing errors that could be found by this
loop). It is not too bad to keep it, though (the important thing is that
we're not duplicating all of the push_stash options here).

> + if test -z "$stash_msg"
> + then
> + push_stash $push_options
> + else
> + push_stash $push_options -m "$stash_msg"
> + fi

Hmm. So $push_options is subject to word-splitting here. That's
necessary to split the options back apart. It does the wrong thing if
any of the options had spaces in them. But I don't think there are any
valid options which do so, and "save" would presumably not grow any new
options (they would go straight to "push").

So there is a detectable behavior change:

  [before]
  $ git stash "--bogus option"
  error: unknown option for 'stash save': --bogus option
 To provide a message, use git stash save -- '--bogus option'
  [etc...]

  [after]
  $ git stash "--bogus option"
  error: unknown option for 'stash save': --bogus
 To provide a message, use git stash save -- '--bogus'

but it's probably an acceptable casualty (the "right" way would be to
shell-quote everything you stuff into $push_options and then eval the
result when you invoke push_stash).

Likewise, it's usually a mistake to just stick a new option (like "-m")
after a list of unknown options. But it's OK here because we know we
removed any "--" or non-option arguments.

-Peff

Cross-referencing the Git mailing list archive with their corresponding commits in `pu`

[Johannes Schindelin]

Hi Josh,

as discussed at the GitMerge, I am trying to come up with tooling that
will allow for substantially less tedious navigation between the local
repository, the mailing list, and what ends up in the `pu` branch.

That tooling would *still* not help lowering the barrier of entry for
contributing to Git by a lot, as it would *still* not address the problem
that mails sent from the most prevalent desktop mail client, as well as
mails sent from the most prevalent web mail client, are simply and
unceremoniously dropped. (This problem was acknowledged by quite a few
nods even at the Contributors' Summit...) But still, we decided to start
*somewhere* and this tooling is what we agreed on.

It is quite a bit harder going than I would like: as we have figured out,
the Subject: line is not a good way to link the commits with the original
mails containing the patches, as commit messages are modified before being
pushed often enough to make this a fragile matching.

So I thought maybe the From: line (from the body, if available, otherwise
from the header) in conjunction with the "Date:" header would work. But a
preliminary study shows that there are 336 From: + Date: combinations in
the Git mailing list archive that are not unique. 71 of these are shared
by three or more mails, even, and 9 are shared by more than 10 mails,
respectively. This is bad!

Unsurprisingly, the top 10 of these cases were obviously caused by the
builtin `git am` bug where it would not reset the author date properly.
Surprisingly, though, there were a few cases from 2005, too.

I had a quick look to find out what was the culprit (looking at the
17-strong patch series "Documentation fixes in response to my previous
listing" by Nikolai Weibull, but I am at a loss there: the mail claims to
be sent by git-send-email and the patches appear to be generated by
git-format-patch as of v0.99.9l, neither of which had a Date:-related bug
back in that time frame. My best guess is that the patches were mishandled
by a tool similar to rebase -i (which entered Git only at v1.5.3).

For details, see:
http://public-inbox.org/git/11340844841342-git-send-email-mailing-lists@rawuncut.elitemail.org/
(this is also an example where public-inbox' thread detection went utterly
wrong, including way too many mails in the "thread")

There was even a case of duplicated Date: headers in 2012. Now, this case
is very curious, as there have been 7 mails with identical Date: header,
but it was not a 6-strong patch series. Instead, it was a 4-strong patch
series that needed three iterations before it was accepted, and the
identical Date: header appears only in v2's patches (*not* in its cover
letter) and it *disappeared* in v3's 4/4, where it was set *back* by a
week (to the Date: it had in v1).

For details, see
http://public-inbox.org/git/cover.1354693001.git.sebastian.le...@sleske.name/
and
http://public-inbox.org/git/cover.1354324110.git.sebastian.le...@sleske.name/
and
http://public-inbox.org/git/b115a546fa783b4121d118bb8fdb9270443f90fa.1353691892.git.sebastian.le...@sleske.name/

This last example also demonstrates a very curious test case for a
different difficulty in trying to reconstruct lost correspondences: the
patch series was applied *twice*, independently of each other. First, on
the day v3 was submitted, it was applied on top of v1.8.1-rc0 (as commits
ee26a6e2b8..dd465ce66f), although it was not merged until v1.8.1-rc3. 22
days later, it was reapplied on top of maint so it could enter v1.8.0.3
(back then, Git still had "patchlevel" versions): c2999adcd5..008c208c2c.

As you can see, there is a many-to-many relationship here, even if you do
leave the *original* branch out of the picture entirely.

Will keep you posted,
Dscho

P.S.: I used public-inbox.org links instead of commit references to the
Git repository containing the mailing list archive, because the format of
said Git repository is so unfavorable that it was determined very quickly
in a discussion between Patrick Reynolds (GitHub) and myself that it would
put totally undue burden on GitHub to mirror it there (compare also Carlos
Nieto's talk at GitMerge titled "Top Ten Worst Repositories to host on
GitHub").

Re: [PATCH v3 1/5] Documentation/stash: remove mention of git reset --hard

[Jeff King]

On Sun, Feb 05, 2017 at 08:26:38PM +, Thomas Gummerer wrote:

> diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
> index 2e9cef06e6..2e9e344cd7 100644
> --- a/Documentation/git-stash.txt
> +++ b/Documentation/git-stash.txt
> @@ -47,8 +47,9 @@ OPTIONS
>  
>  save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] 
> [-q|--quiet] []::
>  
> - Save your local modifications to a new 'stash', and run `git reset
> - --hard` to revert them.  The  part is optional and gives
> + Save your local modifications to a new 'stash' and roll them
> + back to HEAD (in the working tree and in the index).
> + The  part is optional and gives

Nice. I think what you ended up with here is concise and accurate.

-Peff

Re: [PATCH v3 5/5] stash: teach 'push' (and 'create') to honor pathspec

[Jeff King]

On Sun, Feb 05, 2017 at 11:09:14PM -0800, Junio C Hamano wrote:

> > @@ -99,6 +104,10 @@ create_stash () {
> > if test -z "$new_style"
> > then
> > stash_msg="$*"
> > +   while test $# != 0
> > +   do
> > +   shift
> > +   done
> > fi
> 
> The intent is correct, but I would probaly empty the "$@" not with
> an iteration of shifts but with a single
> 
>   set x && shift
> 
> ;-)

Perhaps it is not portable, but I think "set --" does the same thing and
is perhaps less obscure.

-Peff

Re: [PATCH] p5302: create repositories for index-pack results explicitly

[Jeff King]

On Sun, Feb 05, 2017 at 12:43:29PM +0100, René Scharfe wrote:

> Before 7176a314 (index-pack: complain when --stdin is used outside of a
> repo) index-pack silently created a non-existing target directory; now
> the command refuses to work unless it's used against a valid repository.
> That causes p5302 to fail, which relies on the former behavior.  Fix it
> by setting up the destinations for its performance tests using git init.

Ah, right. Thanks for catching this.

I think p5302 was wrong to rely on the old behavior, and your patch is
the right fix.

-Peff

[PATCH v3] tag: generate useful reflog message

[cornelius . weig]

From: Cornelius Weig 

When tags are created with `--create-reflog` or with the option
`core.logAllRefUpdates` set to 'always', a reflog is created for them.
So far, the description of reflog entries for tags was empty, making the
reflog hard to understand. For example:
6e3a7b3 refs/tags/test@{0}:

Now, a reflog message is generated when creating a tag, following the
pattern "tag: tagging  ()". If
GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION
()" instead. If the tag references a commit object, the
description is set to the subject line of the commit, followed by its
commit date. For example:
6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03)

If the tag points to a tree/blob/tag objects, the following static
strings are taken as description:

 - "tree object"
 - "blob object"
 - "other tag object"

Signed-off-by: Cornelius Weig 
---
 builtin/tag.c  | 54 +-
 t/t7004-tag.sh | 16 +++-
 2 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/builtin/tag.c b/builtin/tag.c
index e40c4a9..638b68e 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -302,6 +302,54 @@ static void create_tag(const unsigned char *object, const 
char *tag,
}
 }
 
+static void create_reflog_msg(const unsigned char *sha1, struct strbuf *sb)
+{
+   enum object_type type;
+   struct commit *c;
+   char *buf;
+   unsigned long size;
+   int subject_len = 0;
+   const char *subject_start;
+
+   char *rla = getenv("GIT_REFLOG_ACTION");
+   if (rla) {
+   strbuf_addstr(sb, rla);
+   } else {
+   strbuf_addstr(sb, _("tag: tagging "));
+   strbuf_add_unique_abbrev(sb, sha1, DEFAULT_ABBREV);
+   }
+
+   strbuf_addstr(sb, " (");
+   type = sha1_object_info(sha1, NULL);
+   switch (type) {
+   default:
+   strbuf_addstr(sb, _("internal object"));
+   break;
+   case OBJ_COMMIT:
+   c = lookup_commit_reference(sha1);
+   buf = read_sha1_file(sha1, , );
+   if (!c || !buf) {
+   die(_("commit object %s could not be read"),
+   sha1_to_hex(sha1));
+   }
+   subject_len = find_commit_subject(buf, _start);
+   strbuf_insert(sb, sb->len, subject_start, subject_len);
+   strbuf_addf(sb, ", %s", show_date(c->date, 0, 
DATE_MODE(SHORT)));
+   free(buf);
+   break;
+   case OBJ_TREE:
+   strbuf_addstr(sb, _("tree object"));
+   break;
+   case OBJ_BLOB:
+   strbuf_addstr(sb, _("blob object"));
+   break;
+   case OBJ_TAG:
+   strbuf_addstr(sb, _("other tag object"));
+   break;
+   }
+   strbuf_addch(sb, ')');
+}
+
 struct msg_arg {
int given;
struct strbuf buf;
@@ -335,6 +383,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
 {
struct strbuf buf = STRBUF_INIT;
struct strbuf ref = STRBUF_INIT;
+   struct strbuf reflog_msg = STRBUF_INIT;
unsigned char object[20], prev[20];
const char *object_ref, *tag;
struct create_tag_options opt;
@@ -494,6 +543,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
else
die(_("Invalid cleanup mode %s"), cleanup_arg);
 
+   create_reflog_msg(object, _msg);
+
if (create_tag_object) {
if (force_sign_annotate && !annotate)
opt.sign = 1;
@@ -504,7 +555,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (!transaction ||
ref_transaction_update(transaction, ref.buf, object, prev,
   create_reflog ? REF_FORCE_CREATE_REFLOG : 0,
-  NULL, ) ||
+  reflog_msg.buf, ) ||
ref_transaction_commit(transaction, ))
die("%s", err.buf);
ref_transaction_free(transaction);
@@ -514,5 +565,6 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
strbuf_release();
strbuf_release();
strbuf_release();
+   strbuf_release(_msg);
return 0;
 }
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 072e6c6..3c4cb58 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -80,10 +80,24 @@ test_expect_success 'creating a tag using default HEAD 
should succeed' '
test_must_fail git reflog exists refs/tags/mytag
 '
 
+git log -1 > expected \
+   --format="format:tag: tagging %h (%s, %cd)%n" --date=format:%F
 test_expect_success 'creating a tag with --create-reflog should create reflog' 
'
test_when_finished "git tag -d tag_with_reflog" &&
git tag --create-reflog tag_with_reflog &&
-   git reflog exists refs/tags/tag_with_reflog

[PATCH] worktree: fix option descriptions for `prune`

[Patrick Steinhardt]

The `verbose` and `expire` options of the `git worktree prune`
subcommand have wrong descriptions in that they pretend to relate to
objects. But as the git-worktree(1) correctly states, these options have
nothing to do with objects but only with worktrees. Fix the description
accordingly.

Signed-off-by: Patrick Steinhardt 
---
 builtin/worktree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/builtin/worktree.c b/builtin/worktree.c
index 9a97e37a3..831fe058a 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -125,9 +125,9 @@ static int prune(int ac, const char **av, const char 
*prefix)
 {
struct option options[] = {
OPT__DRY_RUN(_only, N_("do not remove, show only")),
-   OPT__VERBOSE(, N_("report pruned objects")),
+   OPT__VERBOSE(, N_("report pruned working trees")),
OPT_EXPIRY_DATE(0, "expire", ,
-   N_("expire objects older than ")),
+   N_("expire working trees older than ")),
OPT_END()
};
 
-- 
2.11.1

Re: A little help understanding output from git blame --reverse

[Edmundo Carmona Antoranz]

On Mon, Feb 6, 2017 at 6:38 AM, Edmundo Carmona Antoranz
 wrote:
> I'm "difflaming" HEAD~100 (02db2d0421b97fcb6211) and HEAD
> (066fb0494e6398eb). Specifically file abspath.c.

I just noticed that I'm standing on a private branch. Replace HEAD for
"4e59582ff" when doing your analysis. You should get the same results.

A little help understanding output from git blame --reverse

[Edmundo Carmona Antoranz]

Hi!

While doing some research developing difflame I found some output from
git blame --reverse that I can't quite understand. Perhaps another set
of eyeballs could help me.

I'm "difflaming" HEAD~100 (02db2d0421b97fcb6211) and HEAD
(066fb0494e6398eb). Specifically file abspath.c.

If we diff (as in plain old git diff) HEAD~100..HEAD we can see that
line 63 (from HEAD~100 revision) was deleted between HEAD~100 and
HEAD:

@@ -58,86 +95,136 @@ blah blah
   goto error_out;
   }

-   strbuf_reset();
-   strbuf_addstr(, path);
-
-   while (depth--) {
-   if (!is_directory(sb.buf)) {


So, if I do a "reverse" blame operation on the file, I would expect to
see the last revision where that line was _present_ on the file:

c5f3cba126  61) strbuf_reset();
c5f3cba126  62) strbuf_addstr(, path);
066fb0494e  63)
c5f3cba126  64) while (depth--) {
c5f3cba126  65) if (!is_directory(sb.buf)) {

line 63 shows up as if it had been last present on the file on
revision 066fb0494e, which is HEAD, which kind of doesn't make a lot
of sense to me because given that the line is not present on the file
on HEAD (as we can guess from diff output) it means it was "forcefully
present" on some previous revision (and that's what I would expect to
see reported on blame --reverse output).

What am I missing? Thanks in advance.

Re: gitconfig get out of sync with submodule entries on branch switch

[Benjamin Schindler]

On 06.02.2017 11:35, Stefan Beller wrote:

Answering the original email, as I feel we're going down the wrong rabbit
hole in the existing thread.

On Mon, Jan 30, 2017 at 8:21 AM, Benjamin Schindler
 wrote:

Hi

Consider the following usecase: I have the master branch where I have a
submodule A. I create a branch where I rename the submodule to be in the
directory B. After doing all of this, everything looks good.
Now, I switch back to master. The first oddity is, that it fails to remove
the folder B because there are still files in there:

bschindler@metis ~/Projects/submodule_test (testbranch) $ git checkout
master
warning: unable to rmdir other_submodule: Directory not empty
Switched to branch 'master'


checkout currently doesn't support submodules, so it should neither
try to delete B nor try to repopulate A when switching back to master.
checkout ought to not even touch the existing submodule B.


Well, it tried to remove the folder (the rmdir warning) but it failed so 
in some sense you are right. Is there a technical reason for this 
default though? Here, I frequently have to point out to people that they 
need to initialize/update the submodule on e.g. clone.






Git submodule deinit on B fails because the submodule is not known to git
anymore (after all, the folder B exists only in the other branch). I can
easily just remove the folder B from disk and initialize the submodule A
again, so all seems good.


by initializing you mean populating(?), i.e.

git submodule update

would work without the --init flag or preceding "git submodule init A".
That ought to not redownload A, but just put files back in the working tree
from the submodule git directory inside the superprojects git dir.



However, what is not good is that the submodule b is still known in
.git/config.


Oh, I see. You did not just rename the path, but also the name
in the .gitmodules?


I wasn't even aware that the submodule name was something different from 
the path because the name is by default set to be the path to it. So 
yes, I didn't just relocate it, it had a different name.





This is in particular a problem for us, because I know a number
of tools which use git config to retrieve the submodule list. Is it
therefore a bug that upon branch switch, the submodule gets deregistered,
but its entry in .git/config remains?


The config remains as it indicates that you express(ed) interest in
submodule A, such that when switching branches

  master->renamedToB->master

then we'd still care about A. As for the tools, I'd rather see them use

git submodule status/summary

instead of directly looking at the config, because the config may
change in the future.


That was my feeling but its good to know to have more solid reasons why 
that would be.


Cheers
Benjamin





thanks a lot
Benjamin Schindler

P.s. I did not subscribe to the mailing list, please add me at least do CC.
Thanks

Re: gitconfig get out of sync with submodule entries on branch switch

[Stefan Beller]

Answering the original email, as I feel we're going down the wrong rabbit
hole in the existing thread.

On Mon, Jan 30, 2017 at 8:21 AM, Benjamin Schindler
 wrote:
> Hi
>
> Consider the following usecase: I have the master branch where I have a
> submodule A. I create a branch where I rename the submodule to be in the
> directory B. After doing all of this, everything looks good.
> Now, I switch back to master. The first oddity is, that it fails to remove
> the folder B because there are still files in there:
>
> bschindler@metis ~/Projects/submodule_test (testbranch) $ git checkout
> master
> warning: unable to rmdir other_submodule: Directory not empty
> Switched to branch 'master'

checkout currently doesn't support submodules, so it should neither
try to delete B nor try to repopulate A when switching back to master.
checkout ought to not even touch the existing submodule B.

>
> Git submodule deinit on B fails because the submodule is not known to git
> anymore (after all, the folder B exists only in the other branch). I can
> easily just remove the folder B from disk and initialize the submodule A
> again, so all seems good.

by initializing you mean populating(?), i.e.

git submodule update

would work without the --init flag or preceding "git submodule init A".
That ought to not redownload A, but just put files back in the working tree
from the submodule git directory inside the superprojects git dir.

>
> However, what is not good is that the submodule b is still known in
> .git/config.

Oh, I see. You did not just rename the path, but also the name
in the .gitmodules?

> This is in particular a problem for us, because I know a number
> of tools which use git config to retrieve the submodule list. Is it
> therefore a bug that upon branch switch, the submodule gets deregistered,
> but its entry in .git/config remains?

The config remains as it indicates that you express(ed) interest in
submodule A, such that when switching branches

  master->renamedToB->master

then we'd still care about A. As for the tools, I'd rather see them use

git submodule status/summary

instead of directly looking at the config, because the config may
change in the future.

>
> thanks a lot
> Benjamin Schindler
>
> P.s. I did not subscribe to the mailing list, please add me at least do CC.
> Thanks

Re: git/git-scm.com GH Issue Tracker

[Duy Nguyen]

On Mon, Feb 6, 2017 at 1:15 PM, Samuel Lijin  wrote:
> # Irrelevant but someone should take a look
>
> 693

To save people some time (and since i looked at it anyway), this is
about whether "warning in tree xxx: contains zero-padded file modes:
from fsck should be a warning or error. It is a warning now even
though "git -c transfer.fsckobjects=true clone" treats it as an error.
There are some discussions in the past [1] [2] about this.

There's also a question "And I failed to find in the documentation if
transfer.fsckobjects could be disabled per repository, can you confirm
it's not possible for now ?"

(sorry no answer from me)

[1] 
http://public-inbox.org/git/%3CCAEBDL5W3DL0v=TusuB7Vg-4bWdAJh5d2Psc1N0Qe+KK3bZH3=q...@mail.gmail.com%3E/
[2] http://public-inbox.org/git/%3c20100326215600.ga10...@spearce.org%3E/
-- 
Duy

Re: [PATCH 1/4] git-prompt.sh: add submodule indicator

[Stefan Beller]

On Sun, Feb 5, 2017 at 9:55 PM, Jacob Keller  wrote:
> On Sun, Feb 5, 2017 at 8:23 PM, Stefan Beller  wrote:
>>
>> (unrelated side note:)
>> At GitMerge facebook presented their improvements on mercurial
>> and one of the things was "hg absorb". It would take the dirty hunks/lines
>> of the working tree and amend them into the "stack of commits", i.e. into
>> your local unpublished history. So instead of making fixup commits
>> and doing the whole interactive rebase thing, it would do it automatically
>> for you. I think that is a neat time saver.
>>
>> Thanks,
>> Stefan
>
> How exactly was it different from doing "git  commit --fixup xyz" and
> "git rebase -i --autosquash"? Like, what was the advantage to the user
> facing workflow? Just curious to see if we could learn something from
> it.

My impression is that all local changes were split up and the "xyz"
was determined based off a heuristic, e.g. blame(?) and then the
rebase is run automatically after that, i.e. having just one command for
a complete workflow here, moving up a whole level in abstraction.

Re: git/git-scm.com GH Issue Tracker

[Thomas Ferris Nicolaisen]

Adding Peff to cc as he is the current maintainer of the git-scm.com site/repo.

On Mon, Feb 6, 2017 at 7:15 AM, Samuel Lijin  wrote:
>
> I've taken the liberty of classifying them as shown below.
>

As a community member who cares a lot about that site, thank you! I
would love to contribute by reviewing your reviews, but personally
can't find the time (focusing free time on podcast production from
Git-Merge instead ;)).

subtree merging fails

[Stavros Liaskos]

Hi,

Please check this issue for a description of the bug:
https://github.com/git/git-scm.com/issues/896#issuecomment-277587626

Regards,

Stavros