GIT_WORK_TREE not set as expected when changing git repository from a script using a git alias

[Gabriel Ganne]

Hi,

Following commit d95138e695d99d32dcad528a2a7974f434c51e79 (since
v2.5.1) the following workflow I use seems broken :

I wrote a script to list all git repositories that can be found from
where I am, and then call for each repository a given command.

Given the following tree, where "a" & "b" are git repositories,
├── a
│   ├── a_file
│   └── b
│   └── b_file

If I call the script from a git alias, the content of "a" will be
listed as untracked files from "b".
This is true only when called using the alias.

For example :
$ git all status # called from repository a
 [a]
On branch master
Untracked files:
  (use "git add ..." to include in what will be committed)

b/

nothing added to commit but untracked files present (use "git add" to track)
 [b]
On branch master
Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

deleted:../b_file

Untracked files:
  (use "git add ..." to include in what will be committed)

../a_file
./

no changes added to commit (use "git add" and/or "git commit -a"

I am afraid I did not understand the commit
d95138e695d99d32dcad528a2a7974f434c51e79, and do not know how to fix
this.
I am working around the issue by setting GIT_WORK_TREE manually.

I attached a sample with my example, the script, and the alias I used.

Best regards,

--
Gabriel Ganne


git_all_issue.tar.gz
Description: GNU Zip compressed data

Re: [PATCH] revision.c: fix possible null pointer access

[Junio C Hamano]

"Philip Oakley"  writes:

> From: "Junio C Hamano" 
>> Stefan Naewe  writes:
>>
>>> Two functions dereference a tree pointer before checking
>>
>> Reading them a bit carefully, a reader would notice that they
>> actually do not dereference the pointer at all.  It just computes
>> another pointer and that is done by adding the offset of object
>> member in the tree struct.
>
> But you can't do that computation (in the error case under
> consideration). Null can't be added to anything (as far as the
> implications of the standards go). These are horrid gotchas because
> they go against the grain of all that binary arithmetic and
> simplifications we learnt long ago.

Yeah, but in that hunk that does check !tree, because the function
can be fed a NULL, the computed result assigned to object, which is
undefined, is never used ;-)

Of course, there used to be exotic platforms that are still standard
compliant that triggered a trap when such a pointer computation was
made (rather, such a bogus pointer was assigned to a pointer
variable).  I do not think anybody attempted to port Git to such a
platform, but I agree that it is better to "fix" such a codepath, if
only to stop wasting time dealing with them discussing with language
lawyers ;-)

So as I said in my review, the first hunk is a reject, the second
one is OK.

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

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

[Junio C Hamano]

Stefan Beller  writes:

>> A single dot "." would be a possibility
>> (i.e. a ref component cannot begin with a dot), but squating on it
>> and saying "anything that begins with . must be followed by 40-hex
>> (and in the future by an extended SHA-1)" would rob extensibility
>> from us, so perhaps ".@c78f7b5ed9dc1c6edc8db06ac65860151d54fd07" or
>> something?
>
> My gut reaction is to reject that notation, as it is very cryptic.
> Looking at the @ sign, it reminds me of the reflog notion such as HEAD@{-1}.
> So maybe it would be more appealing to specify
> HEAD@{c78f7b5ed9dc1c6edc8db06ac65860151d54fd07}
> to mean a specific commit. By saying HEAD we indicate it is not meant as
> a branch (both on the remote as well as locally).
> By having the @{ sequence this would also be dis-ambiguous from any
> branch.

I specifically rejected that when I wrote the message you are
responding to, because I think that would make it harder to later
enhance the mechanism to ask for HEAD@{...}, i.e. extended SHA-1
expression.

But bikeshedding can be left as an exercise to those who have too
much time on hand.

> Looking at the big picture here, this being a preparation for improving
> submodule cloning, we also want to allow tags here?

The reason why we need to restrict to raw 40-hex in the initial
iteration is because we do not want protocol update for an uncooked
idea.  Hence a tag object name in 40-hex is fine, but a tag refname
e.g. v1.0 is not.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Split .git/config in multiple worktree setup

[Duy Nguyen]

On Thu, Dec 3, 2015 at 9:53 PM, Max Kirillov  wrote:
> On Thu, Dec 03, 2015 at 09:07:07AM +0100, Duy Nguyen wrote:
>> On Thu, Dec 3, 2015 at 7:15 AM, Max Kirillov  wrote:
>>> Using builtin defaults might be confusing for users -
>>> editing the info/config.worktree they must keep in mind the
>>> list of defaults (which they seem to don't know).
>>
>> All per-worktree variables are marked so in config.txt
>
> If I were user I would like the list to be more explicit.

I wouldn't. I mean, I have more than a dozen of git repos lying
around, some I don't even remember where. Should I check git release
notes at every upgrade then fix up _all_ of my repos? That's something
I rather not do.

>>> Also, if
>>> anybody wants to extend the default list (like myself, for
>>> submodules), should they edit the info/config.worktree in
>>> provided template of extend the builtin list? What was wrong
>>> with the default in template?
>>
>> Suppose you introduce a new
>> per-worktree variable in the new git version. If it's in the builtin
>> list, we don't have to update every repo's info/config,worktree.
>
> But how do you see it? Let's, for example, git-N consider
> some variable as per-repository, and user does have it their
> .git/config. Then git-N+1 considers it as per-worktree. How
> does it find the variable while opening some existing
> worktree? Then, if user sets the variable in some worktree
> using git-N+1, git-N will no longer be able to see the
> correct variable value. Does this mean that any change in
> builtin list should cause repository incompatibility?

Behavior differences between git versions have been alway will always
be the problem. Yes providing some forward compatibility (by storing
some logic outside the binary in this case) helps, but I don't think
it eliminates it. If incompatibilities may lead to a big problem, then
we can always make the new behavior an "repo extension" to stop older
binaries from accessing the touched repos.

Most of the time there's only one git version being used. So it should
not be a big problem. But yes, if a repo is shared over network, then
multiple git versions accessing the same repo can happen.

On Thu, Dec 3, 2015 at 8:52 PM, Junio C Hamano  wrote:
> I agree with your reasoning to have built-in set of files that are
> per-worktree. I actually prefer *not* to have any configurability
> to avoid confusion between users.

There are a set of variables where whether they are shared or
per-worktree is pretty much preference. For example, core.ignoreCase.
What if I put one worktree on that case-insensitive file system? This
gives the user some flexibility in managing those variables. _But_
they can also manage another way with include.path (or a new variant
that is worktree-aware), with a bit of work.

So killing info/core.worktree is not a bad idea. Even better, we can
avoid pulling exclude machinery in. But yeah, need to sort out the
upgrade issue Max mentioned first.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: best practices against long git rebase times?

[John Keeping]

On Fri, Dec 04, 2015 at 04:05:46PM +0100, Andreas Krey wrote:
> our workflow is pretty rebase-free for diverse reasons yet.
> 
> One obstacle now appearing is that rebases simply take
> very long - once you might want to do a rebase there are
> several hundred commits on the remote branch, and our tree
> isn't small either.
> 
> This produces rebase times in the minute range.
> I suppose this is because rebase tries to see
> if there are new commits in the destination
> branch that are identical to one of the local
> commits, to be able to skip them. (I didn't
> try to verify this hypothesis.)
> 
> What can we do to make this faster?

I'm pretty sure that you're right and the cherry-pick analysis is where
the time is spent.

I looked into this a couple of years ago and I have a variety of
(half-finished) experiments that might improve the performance of this:

https://github.com/johnkeeping/git/commits/log-cherry-no-merges
https://github.com/johnkeeping/git/commits/patch-id-limit-paths

https://github.com/johnkeeping/git/commits/revision-cherry-respect-ancestry-path
https://github.com/johnkeeping/git/commits/patch-id-notes-cache
http://comments.gmane.org/gmane.comp.version-control.git/224006

I have no idea if any of these changes will apply to modern Git (or if
some of them are even correct) but I can try to clean them up if there's
interest.

The commit for patch-id-limit-paths includes some numbers that might be
relevant for your case:

Before:
$ time git log --cherry master...jk/submodule-subdirectory-ok >/dev/null

real0m0.373s
user0m0.341s
sys 0m0.031s

After:
$ time git log --cherry master...jk/submodule-subdirectory-ok >/dev/null

real0m0.060s
user0m0.055s
sys 0m0.005s
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

best practices against long git rebase times?

[Andreas Krey]

Hi all,

our workflow is pretty rebase-free for diverse reasons yet.

One obstacle now appearing is that rebases simply take
very long - once you might want to do a rebase there are
several hundred commits on the remote branch, and our tree
isn't small either.

This produces rebase times in the minute range.
I suppose this is because rebase tries to see
if there are new commits in the destination
branch that are identical to one of the local
commits, to be able to skip them. (I didn't
try to verify this hypothesis.)

What can we do to make this faster?

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GIT_WORK_TREE not set as expected when changing git repository from a script using a git alias

[Duy Nguyen]

On Fri, Dec 4, 2015 at 10:54 AM, Gabriel Ganne  wrote:
> Hi,
>
> Following commit d95138e695d99d32dcad528a2a7974f434c51e79 (since
> v2.5.1) the following workflow I use seems broken :

You are not the first one bitten [1] by that commit. A fix is being
worked on [2]. Sorry for the trouble.

[1] http://thread.gmane.org/gmane.comp.version-control.git/281608
[2] http://article.gmane.org/gmane.comp.version-control.git/281960
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Feature request - allow requesting a lock timeout

[Nathan Neulinger]

It appears that almost all of the locking calls in the current code use hold_lock_file_for_update() which translates 
into a request with zero timeout.


This effectively means that for certain classes of usage, you can't use git concurrently without either external locking 
or retry logic. It would be nice to see a global option "--lock-timeout" that would request a specific non-zero default 
timeout for many of those operations.


Even having the option to have a couple-second timeout would eliminate most typical concurrency issues, simplifying some 
automated use cases.


Horrible/contrived example, but demonstrates the issue:

for f in `seq 1 150`; do touch $f; (git add $f &); done

You'll get a whole bunch of:

fatal: Unable to create '/tmp/dummy/.git/index.lock': File exists.

-- Nathan


Nathan Neulinger   nn...@neulinger.org
Neulinger Consulting   (573) 612-1412
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: best practices against long git rebase times?

[demerphq]

On 4 December 2015 at 18:28, John Keeping  wrote:
> On Fri, Dec 04, 2015 at 06:09:33PM +0100, demerphq wrote:
>> On 4 December 2015 at 16:05, Andreas Krey  wrote:
>> > Hi all,
>> >
>> > our workflow is pretty rebase-free for diverse reasons yet.
>> >
>> > One obstacle now appearing is that rebases simply take
>> > very long - once you might want to do a rebase there are
>> > several hundred commits on the remote branch, and our tree
>> > isn't small either.
>> >
>> > This produces rebase times in the minute range.
>> > I suppose this is because rebase tries to see
>> > if there are new commits in the destination
>> > branch that are identical to one of the local
>> > commits, to be able to skip them. (I didn't
>> > try to verify this hypothesis.)
>> >
>> > What can we do to make this faster?
>>
>> I bet you have a lot of refs; tags, or branches.
>>
>> git rebase performance along with many operations seems to scale
>> proportionately to the number of tags.
>>
>> At $work we create a tag every time we "roll out" a "server type".
>>
>> This produces many tags a day.
>>
>> Over time rebase, and many operations actually, start slowing down to
>> the point of painfulness.
>>
>> The workaround we ended up using was to set up a cron job and related
>> infra that removed old tags.
>>
>> Once we got rid of most of our old tags git became nice to use again.
>
> This is quite surprising.  Were you using packed or loose tags?

It didn't matter.

> It would be interesting to run git-rebase with GIT_TRACE_PERFORMANCE to
> see which subcommand is slow in this particular scenario.

These days it isn't that slow :-)

But I cc'ed Avar, he did the work on that, all I know is when he
finished the tag remover I stopped cursing every time I rebased.

I believe I remember him saying that you can reproduce it using a
public repo by taking the linux repo and creating a tag every 10
commits or so. Once you are done git in many operations will be nice
and slow!

In all fairness however, I do believe that some of the recent changes
to git helped, but I dont how much or which. What I do know is we
still have the cron sweeper process cleaning refs. (It broke one of my
repos that I set up with --reference just the other day).

Yves




-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 6/8] config: add core.untrackedCache

[Torsten Bögershausen]

> Current state of affairs:
> 
>  * Enable on a per-repo basis: git update-index --untracked-cache
>  * Disable on a per-repo basis: git update-index --no-cache
>  * Enable system-wide: N/A
>  * Disable system-wide: N/A
> 
> With this patch:
> 
>  * Enable on a per-repo basis: git update-index --untracked-cache OR
> "git config core.untrackedCache true"
>  * Disable on a per-repo basis: git update-index --no-cache OR "git
> config core.untrackedCache false"
>  * Enable system-wide: git config --global core.untrackedCache true
>  * Disable system-wide: git config --global core.untrackedCache false
>  * Caveat: The core.untrackedCache config has precidence over "git 
> update-index"
> 
> With the rest of the patches in this series:
> 
>  * Enable system-wide & per-repo the same, just tweak
> core.untrackedCache either for the local .git or --globally
>  * If you want to test things either per-repo or globally just use
> "git update-index --test-untracked-cache"
>  * If you want something exactly like the old --untracked-cache do:
> "git update-index --test-untracked-cache && git config
> core.untrackedCache true"
> 
> I think applying this whole series makes sense. Enabling this feature
> doesn't work like anything else in Git, usually you just tweak a
> config option and thus can easily enable things either system-wide or
> per-repo (or any combination of the two), which makes both system
> administration and local configuration easy.
> 
> A much saner UI for the CLI tools if we're going to ship git with
> tests for filesystem features is to separate the testing from the
> enabling of those features.

My spontanous feeling: squash 6-8 together and add this nice explanation
to the commit message.

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

Re: best practices against long git rebase times?

[demerphq]

On 4 December 2015 at 16:05, Andreas Krey  wrote:
> Hi all,
>
> our workflow is pretty rebase-free for diverse reasons yet.
>
> One obstacle now appearing is that rebases simply take
> very long - once you might want to do a rebase there are
> several hundred commits on the remote branch, and our tree
> isn't small either.
>
> This produces rebase times in the minute range.
> I suppose this is because rebase tries to see
> if there are new commits in the destination
> branch that are identical to one of the local
> commits, to be able to skip them. (I didn't
> try to verify this hypothesis.)
>
> What can we do to make this faster?

I bet you have a lot of refs; tags, or branches.

git rebase performance along with many operations seems to scale
proportionately to the number of tags.

At $work we create a tag every time we "roll out" a "server type".

This produces many tags a day.

Over time rebase, and many operations actually, start slowing down to
the point of painfulness.

The workaround we ended up using was to set up a cron job and related
infra that removed old tags.

Once we got rid of most of our old tags git became nice to use again.

Try making a clone, nuking all the refs in it, and then time rebase and friends.

Yves





-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: best practices against long git rebase times?

[John Keeping]

On Fri, Dec 04, 2015 at 06:09:33PM +0100, demerphq wrote:
> On 4 December 2015 at 16:05, Andreas Krey  wrote:
> > Hi all,
> >
> > our workflow is pretty rebase-free for diverse reasons yet.
> >
> > One obstacle now appearing is that rebases simply take
> > very long - once you might want to do a rebase there are
> > several hundred commits on the remote branch, and our tree
> > isn't small either.
> >
> > This produces rebase times in the minute range.
> > I suppose this is because rebase tries to see
> > if there are new commits in the destination
> > branch that are identical to one of the local
> > commits, to be able to skip them. (I didn't
> > try to verify this hypothesis.)
> >
> > What can we do to make this faster?
> 
> I bet you have a lot of refs; tags, or branches.
> 
> git rebase performance along with many operations seems to scale
> proportionately to the number of tags.
> 
> At $work we create a tag every time we "roll out" a "server type".
> 
> This produces many tags a day.
> 
> Over time rebase, and many operations actually, start slowing down to
> the point of painfulness.
> 
> The workaround we ended up using was to set up a cron job and related
> infra that removed old tags.
> 
> Once we got rid of most of our old tags git became nice to use again.

This is quite surprising.  Were you using packed or loose tags?

It would be interesting to run git-rebase with GIT_TRACE_PERFORMANCE to
see which subcommand is slow in this particular scenario.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] add test to demonstrate that shallow recursive clones fail

[Junio C Hamano]

Stefan Beller  writes:

> Did you have any reason to pick . specifically or are we welcome to bikeshed
> why a colon might be better? (or ":", "?", "[", "\", "^", "~", SP, or TAB)
>
> We could use [id]c78f7b5ed9dc1c6edc8db06ac65860151d54fd07
> or [const]c78f7b5ed9dc1c6edc8db06ac65860151d54fd07 ?

As to the bikeshedding, I kind of like the above.

[object:c78f7b5ed9dc1c6edc8db06ac65860151d54fd07]

would be a more natural way to use the pairwise magic characters
like [], I suspect.

Thanks.


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

Re: Multiple fetches when unshallowing a shallow clone

[Stefan Beller]

On Fri, Dec 4, 2015 at 1:27 PM, Jeff King  wrote:
>>
>> and could not see a second fetch, but only a
>> fetch-pack with --depth=2147483647
>
> This seems to reproduce consistently for me:
>
>   $ git clone --depth=1 git://github.com/git/git

I used the http protocol, so I guess that's the difference.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix quoting of redirect in test script

[Charles Bailey]

On Fri, Dec 04, 2015 at 01:05:20PM -0800, Junio C Hamano wrote:
> Do you want to sign-off this patch?
> 
> Thanks.

Oops, yes please.

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

Re: [RFC/PATCH 6/8] config: add core.untrackedCache

[Christian Couder]

On Fri, Dec 4, 2015 at 6:54 PM, Torsten Bögershausen  wrote:
>> Current state of affairs:
>>
>>  * Enable on a per-repo basis: git update-index --untracked-cache
>>  * Disable on a per-repo basis: git update-index --no-cache
>>  * Enable system-wide: N/A
>>  * Disable system-wide: N/A
>>
>> With this patch:
>>
>>  * Enable on a per-repo basis: git update-index --untracked-cache OR
>> "git config core.untrackedCache true"
>>  * Disable on a per-repo basis: git update-index --no-cache OR "git
>> config core.untrackedCache false"
>>  * Enable system-wide: git config --global core.untrackedCache true
>>  * Disable system-wide: git config --global core.untrackedCache false
>>  * Caveat: The core.untrackedCache config has precidence over "git 
>> update-index"
>>
>> With the rest of the patches in this series:
>>
>>  * Enable system-wide & per-repo the same, just tweak
>> core.untrackedCache either for the local .git or --globally
>>  * If you want to test things either per-repo or globally just use
>> "git update-index --test-untracked-cache"
>>  * If you want something exactly like the old --untracked-cache do:
>> "git update-index --test-untracked-cache && git config
>> core.untrackedCache true"
>>
>> I think applying this whole series makes sense. Enabling this feature
>> doesn't work like anything else in Git, usually you just tweak a
>> config option and thus can easily enable things either system-wide or
>> per-repo (or any combination of the two), which makes both system
>> administration and local configuration easy.
>>
>> A much saner UI for the CLI tools if we're going to ship git with
>> tests for filesystem features is to separate the testing from the
>> enabling of those features.
>
> My spontanous feeling: squash 6-8 together and add this nice explanation
> to the commit message.

Ok, I will do that then.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when ..

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> ... Now I conclude
> that setup-messed-by-alias is always evil. So the env restoration is
> done for _all_ commands  whenever aliases are involved.

So a side effect of this is whenever an alias is involved, all
commands are re-spawned, not just the external ones but builtins as
well.

>  This may be a brilliant fix, or another invitation for regressions.

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

Re: [PATCH v6] Add git-grep threads param

[Junio C Hamano]

This version seems to break t7811 when applied on top of 37023ba3
(Seventh batch for 2.7, 2015-10-26).

I'll eject it from 'pu' for today's integration.

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

Re: What's cooking in git.git (Dec 2015, #02; Fri, 4)

[Jeff King]

On Fri, Dec 04, 2015 at 03:15:58PM -0800, Junio C Hamano wrote:

> You can find the normal integration branches at:
> 
> https://github.com/git/git/
> 
> and all topic branches at:
> 
> https://github.com/peff/git/
> 
> But note that I will _not_ be pushing to kernel.org.

You may want to update this in the whats-cooking template. :)

diff --git a/whats-cooking.txt b/whats-cooking.txt
index 43394b7..04f6208 100644
--- a/whats-cooking.txt
+++ b/whats-cooking.txt
@@ -25,7 +25,11 @@ and all topic branches at:
 
 https://github.com/peff/git/
 
-But note that I will _not_ be pushing to kernel.org.
+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"]

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

Re: [PATCHv2] document submodule sync --recursive

[Junio C Hamano]

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

Re: Multiple fetches when unshallowing a shallow clone

[Jeff King]

On Fri, Dec 04, 2015 at 01:57:30PM -0800, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > This seems to reproduce consistently for me:
> >
> >   $ git clone --depth=1 git://github.com/git/git
> >   Cloning into 'git'...
> >   remote: Counting objects: 2925, done.
> >   remote: Compressing objects: 100% (2602/2602), done.
> >   remote: Total 2925 (delta 230), reused 2329 (delta 206), pack-reused 0
> >   Receiving objects: 100% (2925/2925), 6.17 MiB | 10.80 MiB/s, done.
> >   Resolving deltas: 100% (230/230), done.
> >
> >   $ cd git
> >   $ git fetch --unshallow
> >   remote: Counting objects: 185430, done.
> >   remote: Compressing objects: 100% (46933/46933), done.
> >   remote: Total 185430 (delta 140505), reused 181589 (delta 136694), 
> > pack-reused 0
> >   Receiving objects: 100% (185430/185430), 52.80 MiB | 10.84 MiB/s, done.
> >   Resolving deltas: 100% (140505/140505), completed with 1784 local objects.
> >   remote: Counting objects: 579, done.
> >   remote: Compressing objects: 100% (579/579), done.
> >   remote: Total 579 (delta 0), reused 579 (delta 0), pack-reused 0
> >   Receiving objects: 100% (579/579), 266.85 KiB | 0 bytes/s, done.
> >   [... fetch output ...]
> >
> > That looks like two packs being received for the --unshallow case.
> 
> What is puzzling is that I do not seem to see this "two fetches"
> with the local transport.  I only see "deepen 2147483647" in the
> protocol log.

Yeah, I do not ever see "deepen 0" from GIT_TRACE_PACKET output. FWIW,
here's the output I am using to reproduce this locally:

  # do this once
  git clone --bare git://github.com/git/git src.git

  # do this for each test run
  rm -rf repo
  git clone --no-local --depth=1 src.git repo
  cd repo
  echo "==> unshallow" &&
  git fetch --progress --unshallow 2>&1 | grep remote

And you can see that there are two separate sections (and I traced this
to backfill_tags() with gdb).

Note that the issue goes away if the shallow clone is done with "--bare"
(I guess because we pick up tags differently in the initial clone?).

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

Re: Multiple fetches when unshallowing a shallow clone

[Junio C Hamano]

Jeff King  writes:

>> But why would fetching a tag (or set of tags) merit a depth of zero?
>> Doesn't depth 1 mean "give me the the objects, and none of their
>> descendants"?  Why use 0?
>
> That comes from this line:
>
>   transport_set_option(transport, TRANS_OPT_DEPTH, "0");
>
> That line blame back to b888d61 (Make fetch a builtin, 2007-09-10),
> which isn't incredibly helpful.

Hmm, "0" means "no depth limitations", which is exactly what we want
in this "unshallow" case, I would think.  The behaviour observed is
just like a regular fetch that auto-follows tags, where it has to
make a second fetch if the primary fetch fails to include everything
that is needed for propagating the tag for whatever reason.

Having said that, IIRC, these days a depth limited clone is created
implicitly with --single-branch option, and I am not sure what the
right behaviour for the auto-following of tags in such a repository.

> I think that comes from the original git-fetch.sh, which had:
>
>   ?*)
>   # do not deepen a shallow tree when following tags
>   shallow_depth=
>
> Which makes sense. I think the code at that point is not aware that we
> just "unshallowed" and can therefore drop the depth parameter
> altogether. But I admit I am not all that familiar with the shallow
> code.
>
> +cc Duy, who can probably say something way more intelligent about this
> off the top of his head. :)
>
> -Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

What's cooking in git.git (Dec 2015, #02; Fri, 4)

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

A big thank-you to Peff for managing the list traffic during my
absence for the past few weeks.  I think my tree is now back in
shape and I started merging a handful of topics to 'next' and
'master'.  What's in 'master' plus just a few trivial topics in
'next' should be pretty much "it" for the upcoming release.

You can find the normal integration branches at:

https://github.com/git/git/

and all topic branches at:

https://github.com/peff/git/

But note that I will _not_ be pushing to kernel.org.

--
[Graduated to "master"]

* ad/sha1-update-chunked (2015-11-05) 2 commits
  (merged to 'next' on 2015-12-01 at a22bf47)
 + sha1: allow limiting the size of the data passed to SHA1_Update()
 + sha1: provide another level of indirection for the SHA-1 functions

 Apple's common crypto implementation of SHA1_Update() does not take
 more than 4GB at a time, and we now have a compile-time workaround
 for it.


* jk/filter-branch-no-index (2015-11-06) 1 commit
  (merged to 'next' on 2015-11-24 at e31946e)
 + filter-branch: skip index read/write when possible

 Speed up filter-branch for cases where we only care about rewriting
 commits, not tree data.


* jk/send-email-complete-aliases (2015-11-20) 2 commits
  (merged to 'next' on 2015-11-24 at a50094f)
 + completion: add support for completing email aliases
 + sendemail: teach git-send-email to dump alias names

 Teach send-email to dump mail aliases, so that we can do tab completion
 on the command line.


* np/credential-cache-sighup (2015-11-20) 1 commit
  (merged to 'next' on 2015-11-24 at 410167f)
 + credential-cache: new option to ignore sighup

 Workaround for using credential-cache with emacs.


* rs/parseopt-short-help (2015-11-20) 5 commits
  (merged to 'next' on 2015-11-24 at f22b6e0)
 + show-ref: stop using PARSE_OPT_NO_INTERNAL_HELP
 + grep: stop using PARSE_OPT_NO_INTERNAL_HELP
 + parse-options: allow -h as a short option
 + parse-options: inline parse_options_usage() at its only remaining caller
 + parse-options: deduplicate parse_options_usage() calls

 Make "-h" command line option work more consistently in all commands.


* sg/bash-prompt-dirty-orphan (2015-11-24) 3 commits
  (merged to 'next' on 2015-11-24 at ac6eb1c)
 + bash prompt: indicate dirty index even on orphan branches
 + bash prompt: remove a redundant 'git diff' option
 + bash prompt: test dirty index and worktree while on an orphan branch

 Produce correct "dirty" marker for shell prompts, even when we
 are on an orphan or an unborn branch.

--
[New Topics]

* cb/t3404-shellquote (2015-12-04) 1 commit
 - t3404: fix quoting of redirect for some versions of bash

 Will merge to 'next'.


* nd/clear-gitenv-upon-use-of-alias (2015-12-04) 2 commits
 - setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when ..
 - git.c: make it clear save_env() is for alias handling only

 d95138e6 (setup: set env $GIT_WORK_TREE when work tree is set, like
 $GIT_DIR, 2015-06-26) attempted to work around a glitch in alias
 handling by overwriting GIT_WORK_TREE environment variable to
 affect subprocesses when set_git_work_tree() gets called, which
 resulted in a rather unpleasant regression to "clone" and "init".
 Try to address the same issue by always restoring the environment
 and respawning the real underlying command when handling alias.

 Waiting for review.


* nd/doc-check-ref-format-typo (2015-12-04) 1 commit
 - git-check-ref-format.txt: typo, s/avoids/avoid/

 Will merge to 'next'.


* sb/doc-submodule-sync-recursive (2015-12-04) 1 commit
 - document submodule sync --recursive

 Will merge to 'next'.

--
[Stalled]

* nd/ita-cleanup (2015-09-06) 6 commits
 - grep: make it clear i-t-a entries are ignored
 - checkout(-index): do not checkout i-t-a entries
 - apply: make sure check_preimage() does not leave empty file on error
 - apply: fix adding new files on i-t-a entries
 - add and use a convenience macro ce_intent_to_add()
 - blame: remove obsolete comment

 Paths that have been told the index about with "add -N" are not yet
 in the index, but various commands behaved as if they already are.

 Some commits need better explanation.

 Waiting for a reroll.


* mg/httpd-tests-update-for-apache-2.4 (2015-04-08) 2 commits
 - t/lib-git-svn: check same httpd module dirs as lib-httpd
 - t/lib-httpd: load mod_unixd

 This is the first two commits in a three-patch series $gmane/266962

 Becoming tired of waiting for a reroll.
 with updated log message ($gmane/268061).


* wp/sha1-name-negative-match (2015-06-08) 2 commits
 - sha1_name.c: introduce '^{/!-}' notation
 - test for '!' handling in rev-parse's named commits

 Introduce "branch^{/!-}" notation to name a commit
 reachable from branch that 

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

[Jeff King]

On Fri, Dec 04, 2015 at 12:05:52PM -0800, Junio C Hamano wrote:

> > This probably _does_ trigger setup_git_env() when it was not otherwise
> > called, and it will back to looking at ".git/config" for the repo-level
> > config. That may fail to find the file if we are in a bare repository,
> > or a subdirectory of the working tree. IOW, I suspect this:
> >
> >   git init --bare foo.git
> >   cd foo.git
> >   git config credential.helper cache
> >   git config credentialcache.ignoreSIGHUP true ;# goes into local config
> >   git fetch https://example.com/foo.git
> >
> > may fail to respect the ignoreSIGHUP option.
> >
> > I guess the solution would be to setup_git_director_gently() in the
> > daemon process.
> 
> So I guess I did notice the right breakage ;-)
> 
> At least, this won't be a regression but "a new feature initially
> shipped with a broken corner case", so a follow-up fix is welcome,
> but not a big deal that I've already merged it to 'master'.

Yeah, agreed on all counts. Thanks for noticing.

I suspect in practice is a pretty rare corner case, but I will leave it
to those who are interested in the feature to do the fixup.

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

Re: Multiple fetches when unshallowing a shallow clone

[Jason Paller-Rzepka]

It appears that it happens when the shallow history grows to include a
commit that's pointed to by a previously unseen tag.  For example,
when I deepen a checkout of git to depth 8, I hit v2.5.2, and a second
fetch takes place.

```
$ git clone --depth=1 http://github.com/git/git
Cloning into 'git'...
remote: Counting objects: 2925, done.
remote: Compressing objects: 100% (2602/2602), done.
remote: Total 2925 (delta 230), reused 2329 (delta 206), pack-reused 0
Receiving objects: 100% (2925/2925), 6.17 MiB | 0 bytes/s, done.
Resolving deltas: 100% (230/230), done.
Checking connectivity... done.
$ git -C git fetch --depth=8
remote: Counting objects: 858, done.
remote: Compressing objects: 100% (774/774), done.
remote: Total 858 (delta 793), reused 138 (delta 80), pack-reused 0
Receiving objects: 100% (858/858), 364.53 KiB | 0 bytes/s, done.
Resolving deltas: 100% (793/793), completed with 476 local objects.
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 1 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
>From http://github.com/git/git
 * [new tag] v2.5.2 -> v2.5.2
$
```

But why would fetching a tag (or set of tags) merit a depth of zero?
Doesn't depth 1 mean "give me the the objects, and none of their
descendants"?  Why use 0?

Thanks!
Jason

On Fri, Dec 4, 2015 at 4:27 PM, Jeff King  wrote:
> On Fri, Dec 04, 2015 at 12:46:59PM -0800, Stefan Beller wrote:
>
>> On Mon, Nov 30, 2015 at 11:35 AM, Jason Paller-Rzepka
>>  wrote:
>> > Hi all,
>> >
>> > Would anyone be willing to help me understand some shallow-clone
>> > behavior?  (I found a bug in Dulwich, and I'm looking for some context
>> > so I can determine how to fix it.)
>> >
>> > I learned that cgit sometimes performs two fetches for a `git fetch
>> > --unshallow`: one with depth 'infinity', and a subsequent one with
>> > depth zero.
>>
>> Is there a condition to trigger this 'sometimes' ?
>>
>> I just tried reproducing via
>> $ GIT_TRACE=1 git fetch --unshallow
>>
>> and could not see a second fetch, but only a
>> fetch-pack with --depth=2147483647
>
> This seems to reproduce consistently for me:
>
>   $ git clone --depth=1 git://github.com/git/git
>   Cloning into 'git'...
>   remote: Counting objects: 2925, done.
>   remote: Compressing objects: 100% (2602/2602), done.
>   remote: Total 2925 (delta 230), reused 2329 (delta 206), pack-reused 0
>   Receiving objects: 100% (2925/2925), 6.17 MiB | 10.80 MiB/s, done.
>   Resolving deltas: 100% (230/230), done.
>
>   $ cd git
>   $ git fetch --unshallow
>   remote: Counting objects: 185430, done.
>   remote: Compressing objects: 100% (46933/46933), done.
>   remote: Total 185430 (delta 140505), reused 181589 (delta 136694), 
> pack-reused 0
>   Receiving objects: 100% (185430/185430), 52.80 MiB | 10.84 MiB/s, done.
>   Resolving deltas: 100% (140505/140505), completed with 1784 local objects.
>   remote: Counting objects: 579, done.
>   remote: Compressing objects: 100% (579/579), done.
>   remote: Total 579 (delta 0), reused 579 (delta 0), pack-reused 0
>   Receiving objects: 100% (579/579), 266.85 KiB | 0 bytes/s, done.
>   [... fetch output ...]
>
> That looks like two packs being received for the --unshallow case.
>
> -Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Multiple fetches when unshallowing a shallow clone

[Jeff King]

On Fri, Dec 04, 2015 at 04:38:16PM -0500, Jason Paller-Rzepka wrote:

> It appears that it happens when the shallow history grows to include a
> commit that's pointed to by a previously unseen tag.  For example,
> when I deepen a checkout of git to depth 8, I hit v2.5.2, and a second
> fetch takes place.

Yeah. The code is in builtin/fetch.c:backfill_tags.

> But why would fetching a tag (or set of tags) merit a depth of zero?
> Doesn't depth 1 mean "give me the the objects, and none of their
> descendants"?  Why use 0?

That comes from this line:

  transport_set_option(transport, TRANS_OPT_DEPTH, "0");

That line blame back to b888d61 (Make fetch a builtin, 2007-09-10),
which isn't incredibly helpful.

I think that comes from the original git-fetch.sh, which had:

  ?*)
  # do not deepen a shallow tree when following tags
  shallow_depth=

Which makes sense. I think the code at that point is not aware that we
just "unshallowed" and can therefore drop the depth parameter
altogether. But I admit I am not all that familiar with the shallow
code.

+cc Duy, who can probably say something way more intelligent about this
off the top of his head. :)

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

change to allow cross compile ARM and MIPS‏

[Ronny Borchert]

I have add an description into INSTALL, that other user have direct an
indicator.

diff --git a/INSTALL b/INSTALL
index ffb071e..5918182 100644
--- a/INSTALL
+++ b/INSTALL
@@ -2,13 +2,13 @@
 Git installation
 
 Normally you can just do "make" followed by "make install", and that
-will install the git programs in your own ~/bin/ directory.  If you want
+will install the git programs in your own ~/bin/ directory. If you want
 to do a global install, you can do
 
 $ make prefix=/usr all doc info ;# as yourself
 # make prefix=/usr install install-doc install-html install-info ;# as root
 
-(or prefix=/usr/local, of course).  Just like any program suite
+(or prefix=/usr/local, of course). Just like any program suite
 that uses $prefix, the built results have some paths encoded,
 which are derived from $prefix, so "make all; make prefix=/usr
 install" would not work.
@@ -25,6 +25,31 @@ set up install paths (via config.mak.autogen), so you can
write instead
 $ make all doc ;# as yourself
 # make install install-doc install-html;# as root
 
+If you want to create a cross build of git, i.e. ARM or MIPS, you
+need to add addtional arguments to configure,
+i.e. for MIPS little endian
+
+$ ./configure --build=x86_64-linux \
+  --host=mipsel-oe-linux \
+  --cache-file=config.cache
+
+i.e. for ARM
+
+$ ./configure --build=x86_64-linux \
+  --host=arm-eabi \
+  --cache-file=config.cache
+
+To make this now work you need to create a config.cache file next to
+the configure. In this file you have to configure architecture
+specific behavior, example content could be
+
+ac_cv_snprintf_returns_bogus=${ac_cv_snprintf_returns_bogus=no}
+ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=no}
+
+For details about the meaning refer to the source code of the tests
+in the configure.ac by search of the ac_cv_...
+Important is that you assign 'no' or 'yes'.
+

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

Re: Multiple fetches when unshallowing a shallow clone

[Stefan Beller]

On Mon, Nov 30, 2015 at 11:35 AM, Jason Paller-Rzepka
 wrote:
> Hi all,
>
> Would anyone be willing to help me understand some shallow-clone
> behavior?  (I found a bug in Dulwich, and I'm looking for some context
> so I can determine how to fix it.)
>
> I learned that cgit sometimes performs two fetches for a `git fetch
> --unshallow`: one with depth 'infinity', and a subsequent one with
> depth zero.

Is there a condition to trigger this 'sometimes' ?

I just tried reproducing via
$ GIT_TRACE=1 git fetch --unshallow

and could not see a second fetch, but only a
fetch-pack with --depth=2147483647
>
> Could anyone answer:
> 1) What is the purpose of the second fetch?
> 2) What does this depth of zero mean? Is it the same as a depth of
> infinity?  (I assume not... but, since I thought the smallest
> meaningful depth was 1, I don't know what else it might mean.)
>
> Thank you!
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Multiple fetches when unshallowing a shallow clone

[Jeff King]

On Fri, Dec 04, 2015 at 12:46:59PM -0800, Stefan Beller wrote:

> On Mon, Nov 30, 2015 at 11:35 AM, Jason Paller-Rzepka
>  wrote:
> > Hi all,
> >
> > Would anyone be willing to help me understand some shallow-clone
> > behavior?  (I found a bug in Dulwich, and I'm looking for some context
> > so I can determine how to fix it.)
> >
> > I learned that cgit sometimes performs two fetches for a `git fetch
> > --unshallow`: one with depth 'infinity', and a subsequent one with
> > depth zero.
> 
> Is there a condition to trigger this 'sometimes' ?
> 
> I just tried reproducing via
> $ GIT_TRACE=1 git fetch --unshallow
> 
> and could not see a second fetch, but only a
> fetch-pack with --depth=2147483647

This seems to reproduce consistently for me:

  $ git clone --depth=1 git://github.com/git/git
  Cloning into 'git'...
  remote: Counting objects: 2925, done.
  remote: Compressing objects: 100% (2602/2602), done.
  remote: Total 2925 (delta 230), reused 2329 (delta 206), pack-reused 0
  Receiving objects: 100% (2925/2925), 6.17 MiB | 10.80 MiB/s, done.
  Resolving deltas: 100% (230/230), done.

  $ cd git
  $ git fetch --unshallow
  remote: Counting objects: 185430, done.
  remote: Compressing objects: 100% (46933/46933), done.
  remote: Total 185430 (delta 140505), reused 181589 (delta 136694), 
pack-reused 0
  Receiving objects: 100% (185430/185430), 52.80 MiB | 10.84 MiB/s, done.
  Resolving deltas: 100% (140505/140505), completed with 1784 local objects.
  remote: Counting objects: 579, done.
  remote: Compressing objects: 100% (579/579), done.
  remote: Total 579 (delta 0), reused 579 (delta 0), pack-reused 0
  Receiving objects: 100% (579/579), 266.85 KiB | 0 bytes/s, done.
  [... fetch output ...]

That looks like two packs being received for the --unshallow case.

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

Re: [PATCH] revision.c: fix possible null pointer access

[Jeff King]

On Fri, Dec 04, 2015 at 07:39:10AM -0800, Junio C Hamano wrote:

> > But you can't do that computation (in the error case under
> > consideration). Null can't be added to anything (as far as the
> > implications of the standards go). These are horrid gotchas because
> > they go against the grain of all that binary arithmetic and
> > simplifications we learnt long ago.
> 
> Yeah, but in that hunk that does check !tree, because the function
> can be fed a NULL, the computed result assigned to object, which is
> undefined, is never used ;-)
> 
> Of course, there used to be exotic platforms that are still standard
> compliant that triggered a trap when such a pointer computation was
> made (rather, such a bogus pointer was assigned to a pointer
> variable).  I do not think anybody attempted to port Git to such a
> platform, but I agree that it is better to "fix" such a codepath, if
> only to stop wasting time dealing with them discussing with language
> lawyers ;-)

FWIW, I'd worry much more about compilers which do aggressive
optimizations based on language-lawyering (e.g., removing the null-check
as dead code, which is legal according to the standard because after you
computed the pointer based on it, it's all undefined behavior).

I don't think that changes your conclusion, though:

> So as I said in my review, the first hunk is a reject, the second
> one is OK.

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

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

[Junio C Hamano]

Jeff King  writes:

> On Fri, Dec 04, 2015 at 10:55:32AM -0800, Junio C Hamano wrote:
>> 
>> I was puzzled that git_config_get_bool() is used here without even
>> checking if we are inside any Git repository and wondered if it was
>> correct
>
> This probably _does_ trigger setup_git_env() when it was not otherwise
> called, and it will back to looking at ".git/config" for the repo-level
> config. That may fail to find the file if we are in a bare repository,
> or a subdirectory of the working tree. IOW, I suspect this:
>
>   git init --bare foo.git
>   cd foo.git
>   git config credential.helper cache
>   git config credentialcache.ignoreSIGHUP true ;# goes into local config
>   git fetch https://example.com/foo.git
>
> may fail to respect the ignoreSIGHUP option.
>
> I guess the solution would be to setup_git_director_gently() in the
> daemon process.

So I guess I did notice the right breakage ;-)

At least, this won't be a regression but "a new feature initially
shipped with a broken corner case", so a follow-up fix is welcome,
but not a big deal that I've already merged it to 'master'.

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

Re: [PATCH] Fix quoting of redirect in test script

[Junio C Hamano]

Do you want to sign-off this patch?

Thanks.

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

Re: [PATCH 2/2] push: Use "last one wins" convention for --recurse-submodules

[Junio C Hamano]

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

Push --follow tags does not agree with its documentation

[Dennis Kaarsemaker]

When deleting an annotated tag with git push -d while having
push.follwTags set to true, causes push to push other annotated tags. I
was surprised by this as this does not agree with the documentation

Push all the refs that would be pushed without this option, and
also push annotated tags in refs/tags that are missing from the
remote but are pointing at commit-ish that are reachable from
the refs being pushed. This can also be specified with
configuration variable push.followTags. For more information,
see push.followTags in git-config(1).

Note also that the tag pushed in error is not even reachable from the
tag that's being deleted.

$ git config push.followTags
true

$ git push origin --delete v2.5.1
To /tmp/whelk.git/
 - [deleted] v2.5.1

$ git push origin --delete 2.5

Counting objects: 1, done.
Writing objects: 100% (1/1), 166 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 1 (delta 0)
To /tmp/whelk.git/
 - [deleted] 2.5
 * [new tag] v2.5.1 -> v2.5.1

Which one is correct in this case, the behaviour or the documentation?
-- 
Dennis Kaarsemaker
www.kaarsemaker.net


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

Re: Multiple fetches when unshallowing a shallow clone

[Stefan Beller]

I can reproduce it now. Instead of using my $random version, I just
needed origin/master
to reproduce.

The second fetch is invoked via
(as outputted via GIT_TRACE=1 git -C git fetch --depth=8)

13:44:56.863841 run-command.c:343   trace: run_command:
'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' '--thin'
'https://github.com/git/git/'

so it seems like there is no explicit depth given, so I think the 0
comes from the initialization step and nobody touched it to fill with
meaningful values.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Multiple fetches when unshallowing a shallow clone

[Junio C Hamano]

Jeff King  writes:

> This seems to reproduce consistently for me:
>
>   $ git clone --depth=1 git://github.com/git/git
>   Cloning into 'git'...
>   remote: Counting objects: 2925, done.
>   remote: Compressing objects: 100% (2602/2602), done.
>   remote: Total 2925 (delta 230), reused 2329 (delta 206), pack-reused 0
>   Receiving objects: 100% (2925/2925), 6.17 MiB | 10.80 MiB/s, done.
>   Resolving deltas: 100% (230/230), done.
>
>   $ cd git
>   $ git fetch --unshallow
>   remote: Counting objects: 185430, done.
>   remote: Compressing objects: 100% (46933/46933), done.
>   remote: Total 185430 (delta 140505), reused 181589 (delta 136694), 
> pack-reused 0
>   Receiving objects: 100% (185430/185430), 52.80 MiB | 10.84 MiB/s, done.
>   Resolving deltas: 100% (140505/140505), completed with 1784 local objects.
>   remote: Counting objects: 579, done.
>   remote: Compressing objects: 100% (579/579), done.
>   remote: Total 579 (delta 0), reused 579 (delta 0), pack-reused 0
>   Receiving objects: 100% (579/579), 266.85 KiB | 0 bytes/s, done.
>   [... fetch output ...]
>
> That looks like two packs being received for the --unshallow case.

What is puzzling is that I do not seem to see this "two fetches"
with the local transport.  I only see "deepen 2147483647" in the
protocol log.

Moreover, the only interesting lines in the output from

$ git grep -B1 'deepen ' \*.[ch]

are

fetch-pack.c-   if (args->depth > 0)
fetch-pack.c:   packet_buf_write(_buf, "deepen %d", args->depth);

so I do not see how anybody would be sending "deepen 0" as Jason
saw.

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

Re: [PATCH 01/16] refs: add a backend method structure with transaction functions

[Junio C Hamano]

David Turner  writes:

> diff --git a/refs.c b/refs.c
> index 0f7628d..babba8a 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -10,6 +10,31 @@
>  #include "tag.h"
>  
>  /*
> + * We always have a files backend and it is the default.
> + */
> +extern struct ref_be refs_be_files;

It is customary to s/extern //; in C sources.

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

Re: [PATCH 13/16] init: allow alternate backends to be set for new repos

[Junio C Hamano]

David Turner  writes:

> diff --git a/setup.c b/setup.c
> index d343725..de6b8ac 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -1,5 +1,6 @@
>  #include "cache.h"
>  #include "dir.h"
> +#include "refs.h"
>  #include "string-list.h"
>  
>  static int inside_git_dir = -1;
> @@ -263,6 +264,15 @@ int get_common_dir_noenv(struct strbuf *sb, const char 
> *gitdir)
>   return ret;
>  }
>  
> +int refdb_config(const char *var, const char *value, void *ptr)
> +{
> +   struct refdb_config_data *cdata = ptr;
> +
> +   if (!strcmp(var, "core.refsbackendtype"))
> +cdata->refs_backend_type = xstrdup((char *)value);
> +   return 0;
> +}
> +

These lines seem to be indented with SPs not HTs.

>  /*
>   * Test if it looks like we're at a git directory.
>   * We want to see:
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 15/16] refs: add LMDB refs backend

[Junio C Hamano]

David Turner  writes:

> + while (!mdb_ret) {
> + if (starts_with(key.mv_data, refname) &&
> + ((char*)key.mv_data)[refname_len - 2] == '/') {

ERROR: "(foo*)" should be "(foo *)"
#877: FILE: refs/lmdb-backend.c:514:
+   ((char*)key.mv_data)[refname_len - 2] == '/') {

> +static int show_one_reflog_ent(struct strbuf *sb, each_reflog_ent_fn fn, 
> void *cb_data)
> +{
> + unsigned char osha1[20], nsha1[20];
> + char *email_end, *message;
> + unsigned long timestamp;
> + int tz;
> +
> + /* old (raw) new (raw) name  SP time TAB msg LF */
> + if (sb->len < 41 || sb->buf[sb->len - 1] != '\n' ||
> + !(email_end = strchr(sb->buf + 40, '>')) ||
> + email_end[1] != ' ' ||
> + !(timestamp = strtoul(email_end + 2, , 10)) ||
> + !message || message[0] != ' ' ||
> + (message[1] != '+' && message[1] != '-') ||
> + !isdigit(message[2]) || !isdigit(message[3]) ||
> + !isdigit(message[4]) || !isdigit(message[5]))
> + return 0; /* corrupt? */

ERROR: do not use assignment in if condition
#1024: FILE: refs/lmdb-backend.c:661:
+   if (sb->len < 41 || sb->buf[sb->len - 1] != '\n' ||

> +static char *check_ref(MDB_txn *txn, const char *refname,
> +const unsigned char *old_sha1,
> +unsigned char *resolved_sha1, int flags,
> +int *type_p)
> +{
> + int mustexist = (old_sha1 && !is_null_sha1(old_sha1));
> + int resolve_flags = 0;
> + int type;
> + char *resolved_refname;
> +
> + if (mustexist)
> + resolve_flags |= RESOLVE_REF_READING;
> + if (flags & REF_DELETING) {
> + resolve_flags |= RESOLVE_REF_ALLOW_BAD_NAME;
> + if (flags & REF_NODEREF)
> + resolve_flags |= RESOLVE_REF_NO_RECURSE;
> + }
> +
> + /*
> +  * The first time we resolve the refname, we're just trying to
> +  * see if there is any ref at all by this name, even if it is
> +  * a broken symref.
> +  */
> + refname = resolve_ref_unsafe(refname, resolve_flags,
> +  resolved_sha1, );
> + if (type_p)
> + *type_p = type;

WARNING: suspect code indent for conditional statements (8, 12)
#1177: FILE: refs/lmdb-backend.c:814:
+   if (type_p)
+   *type_p = type;

Indeed, this line should be indented with two HTs.

> + while (!mdb_ret) {
> + if (key.mv_size < len)
> + break;
> +
> + if (!starts_with(key.mv_data, log_path) || 
> ((char*)key.mv_data)[len - 1] != 0)

ERROR: "(foo*)" should be "(foo *)"
#1254: FILE: refs/lmdb-backend.c:891:
+   if (!starts_with(key.mv_data, log_path) || 
((char*)key.mv_data)[len - 1] != 0)

> + if (strcmp (refname, orig_refname) &&

WARNING: space prohibited between function name and open parenthesis '('
#1366: FILE: refs/lmdb-backend.c:1003:
+   if (strcmp (refname, orig_refname) &&


This concludes my first pass, mechanical "lint" (with help from
checkpatch.pl).  I'll hopefully have time to do the more meaningful
design and implementation review later.

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

Re: What's cooking in git.git (Dec 2015, #02; Fri, 4)

[Junio C Hamano]

Jeff King  writes:

> You may want to update this in the whats-cooking template. :)

X-<.  This is a bit tricky in that most of the time I want to retain
the customization I made to the top-portion, and this part does not
go through a three-way merge as it probably should.

>
> diff --git a/whats-cooking.txt b/whats-cooking.txt
> index 43394b7..04f6208 100644
> --- a/whats-cooking.txt
> +++ b/whats-cooking.txt
> @@ -25,7 +25,11 @@ and all topic branches at:
>  
>  https://github.com/peff/git/
>  
> -But note that I will _not_ be pushing to kernel.org.
> +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
> +

Thanks, but the patch is not quite right, as I won't be pushing to
peff/git ;-)

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

Re: [PATCH 15/16] refs: add LMDB refs backend

[David Turner]

On Fri, 2015-12-04 at 16:08 -0800, Junio C Hamano wrote:
> David Turner  writes:
> 
> > +   while (!mdb_ret) {
> > +   if (starts_with(key.mv_data, refname) &&
> > +   ((char*)key.mv_data)[refname_len - 2] == '/') {
> 
> ERROR: "(foo*)" should be "(foo *)"
> #877: FILE: refs/lmdb-backend.c:514:
> +   ((char*)key.mv_data)[refname_len - 2] == '/') {
> 
> > +static int show_one_reflog_ent(struct strbuf *sb, each_reflog_ent_fn fn, 
> > void *cb_data)
> > +{
> > +   unsigned char osha1[20], nsha1[20];
> > +   char *email_end, *message;
> > +   unsigned long timestamp;
> > +   int tz;
> > +
> > +   /* old (raw) new (raw) name  SP time TAB msg LF */
> > +   if (sb->len < 41 || sb->buf[sb->len - 1] != '\n' ||
> > +   !(email_end = strchr(sb->buf + 40, '>')) ||
> > +   email_end[1] != ' ' ||
> > +   !(timestamp = strtoul(email_end + 2, , 10)) ||
> > +   !message || message[0] != ' ' ||
> > +   (message[1] != '+' && message[1] != '-') ||
> > +   !isdigit(message[2]) || !isdigit(message[3]) ||
> > +   !isdigit(message[4]) || !isdigit(message[5]))
> > +   return 0; /* corrupt? */
> 
> ERROR: do not use assignment in if condition
> #1024: FILE: refs/lmdb-backend.c:661:
> +   if (sb->len < 41 || sb->buf[sb->len - 1] != '\n' ||

This code is based on code from files-backend.c.  But I can change it
anyway.

I'll also fix the rest, but wait for further review to post.

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

Re: [PATCH 13/16] init: allow alternate backends to be set for new repos

[Duy Nguyen]

On Thu, Dec 3, 2015 at 1:35 AM, David Turner  wrote:
> git init learns a new argument --refs-backend-type.  Presently, only
> "files" is supported, but later we will add other backends.
>
> When this argument is used, the repository's core.refsBackendType
> configuration value is set, and the refs backend's initdb function is
> used to set up the ref database.

git-init can also be used on existing repos. What happens in that case
if we use --refs-backend-type. Will existing  refs be migrated to the
new backend or hidden away?
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Multiple fetches when unshallowing a shallow clone

[Duy Nguyen]

On Fri, Dec 4, 2015 at 11:45 PM, Junio C Hamano  wrote:
> Jeff King  writes:
>
>>> But why would fetching a tag (or set of tags) merit a depth of zero?
>>> Doesn't depth 1 mean "give me the the objects, and none of their
>>> descendants"?  Why use 0?
>>
>> That comes from this line:
>>
>>   transport_set_option(transport, TRANS_OPT_DEPTH, "0");
>>
>> That line blame back to b888d61 (Make fetch a builtin, 2007-09-10),
>> which isn't incredibly helpful.
>
> Hmm, "0" means "no depth limitations", which is exactly what we want
> in this "unshallow" case, I would think.  The behaviour observed is

No depth 0 means "do not change depth", which is why Jeff saw no
'deepen' lines (and those lines should be rejected any way). It's
equivalent of doing "git fetch" without --depth.

> just like a regular fetch that auto-follows tags, where it has to
> make a second fetch if the primary fetch fails to include everything
> that is needed for propagating the tag for whatever reason.
>
> Having said that, IIRC, these days a depth limited clone is created
> implicitly with --single-branch option, and I am not sure what the
> right behaviour for the auto-following of tags in such a repository.

I suppose followtags feature has been around long enough that we can
simply trust that and skip the second fetch? But it's not that easy
for subsequent fetches after the initial fetch in git-clone, because
we no longer know if --single-branch was used (of if there is any new
branch fetched since).
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when ..

[Duy Nguyen]

On Fri, Dec 4, 2015 at 9:35 PM, Junio C Hamano  wrote:
> Nguyễn Thái Ngọc Duy   writes:
>
>> ... Now I conclude
>> that setup-messed-by-alias is always evil. So the env restoration is
>> done for _all_ commands  whenever aliases are involved.
>
> So a side effect of this is whenever an alias is involved, all
> commands are re-spawned, not just the external ones but builtins as
> well.

I missed that while re-reading c056261, but yes that's true. So
Windows folks will be grumpy anyway. Maybe we can avoid that in
certain (safe) cases, when we know the second setup_git_... will be
executed by the builtin command and won't have any side effects, which
is probably the common case. But let's see how it goes.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] externalize is_git_repository

[Jeff King]

On Fri, Dec 04, 2015 at 07:15:15PM +0100, Andreas Krey wrote:

> diff --git a/cache.h b/cache.h
> index 736abc0..6626e97 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -439,6 +439,7 @@ extern int is_inside_work_tree(void);
>  extern const char *get_git_dir(void);
>  extern const char *get_git_common_dir(void);
>  extern int is_git_directory(const char *path);
> +extern int is_git_repository(struct strbuf *sb);

I wonder if we need to give this a better name if it is going to be
globally available. Seeing these two functions defined next to each
other, I have to wonder: what is the difference?

The first one ("is_git_directory") is about testing whether a particular
path is a ".git" directory. The second is about looking for a ".git"
inside the path, and seeing if _that_ points to a valid repository.
That's one way for it to be a repository, but not all (a repository
could itself simply be a bare repo that passes is_git_directory(), after
all).

So maybe a better name for the new function would be
"directory_contains_dotgit_repo" or something?

>  /*
> + * Return 1 if the given path is the root of a git repository or
> + * submodule else 0. Will not return 1 for bare repositories with the
> + * exception of creating a bare repository in "foo/.git" and calling
> + * is_git_repository("foo").
> + */
> +int is_git_repository(struct strbuf *path)

I think it's more useful to put a descriptive comment like this in the
header, where the interface is defined (I know you are just cutting and
pasting this, but in the prior version the declaration and the
definition were in the same place).

> +{
> + int ret = 0;
> + int gitfile_error;
> + size_t orig_path_len = path->len;
> + assert(orig_path_len != 0);
> + strbuf_complete(path, '/');
> + strbuf_addstr(path, ".git");
> + if (read_gitfile_gently(path->buf, _error) || 
> is_git_directory(path->buf))
> + ret = 1;
> + if (gitfile_error == READ_GITFILE_ERR_OPEN_FAILED ||
> + gitfile_error == READ_GITFILE_ERR_READ_FAILED)
> + ret = 1;  /* This could be a real .git file, take the
> +* safe option and avoid cleaning */

This comment is somewhat stale; we don't know we're cleaning.

Is it always going to be appropriate to err on the side of "yes, this
could be a repository?". My hunch is "yes", because we generally
consider sub-repos to be precious, so that's the safer thing to do.

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

Re: [PATCH 2/3] add is_git_repo (is_git_repository for char*)

[Jeff King]

On Fri, Dec 04, 2015 at 07:15:16PM +0100, Andreas Krey wrote:

> diff --git a/cache.h b/cache.h
> index 6626e97..42ab0c3 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -440,6 +440,7 @@ extern const char *get_git_dir(void);
>  extern const char *get_git_common_dir(void);
>  extern int is_git_directory(const char *path);
>  extern int is_git_repository(struct strbuf *sb);
> +extern int is_git_repo(const char *path);

If we have two functions which do the same thing but differ only in
their interface (here strbuf versus a C-string), we should probably give
them related names that indicate the difference.

So "is_git_repository_str()" or something. (though per my previous
email, I think we should have a new name for the first one, too).

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

Re: [PATCH 13/16] init: allow alternate backends to be set for new repos

[Jeff King]

On Sat, Dec 05, 2015 at 07:30:13AM +0100, Duy Nguyen wrote:

> On Thu, Dec 3, 2015 at 1:35 AM, David Turner  wrote:
> > git init learns a new argument --refs-backend-type.  Presently, only
> > "files" is supported, but later we will add other backends.
> >
> > When this argument is used, the repository's core.refsBackendType
> > configuration value is set, and the refs backend's initdb function is
> > used to set up the ref database.
> 
> git-init can also be used on existing repos. What happens in that case
> if we use --refs-backend-type. Will existing  refs be migrated to the
> new backend or hidden away?

It would be neat if it migrated, but I suspect that may introduce
complications. It's probably OK in the initial implementation to bail if
the option is used in an existing repo.

I think the config option needs to be extensions.refsBackendType, too,
per the logic in 00a09d5 (introduce "extensions" form of
core.repositoryformatversion, 2015-06-23). And I guess it needs to bump
core.repositoryformatversion to "1".

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

Re: [PATCH/RFC 3/3] ls-files/dir: use is_git_repo to detect submodules

[Jeff King]

On Fri, Dec 04, 2015 at 07:15:17PM +0100, Andreas Krey wrote:

> Using resolve_gitlink_ref to check for submodules
> creates submodule list entries even when it isn't
> one, and causes O(n^2) runtime behaviour in repos
> with many untracked directories.
> 
> Use is_git_repo instead for detection.
> 
> Signed-off-by: Andreas Krey 
> ---
> This looks good, but it breaks test - at least
> number 67 ('../bar/a/b/c works with relative local
> path - ../foo/bar.git') in t7400-submodule-basic.sh
> 
> I don't really understand yet how to fix that,
> but it is due to resolve_gitlink_ref looking
> for a valid HEAD which is_git_repo doesn't.

Hrm. Weird. You'd think it would break with the existing code if I do
this, then:

diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 540771c..944e9f5 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -754,7 +754,7 @@ test_expect_success '../bar/a/b/c works with relative local 
path - ../foo/bar.gi
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
mkdir -p a/b/c &&
-   (cd a/b/c; git init) &&
+   (cd a/b/c; git init && git commit --allow-empty -m foo) &&
git config remote.origin.url ../foo/bar.git &&
git submodule add ../bar/a/b/c ./a/b/c &&
git submodule init &&

But it doesn't. So presumably there is a mismatch where some other code
expects that anything which gets marked as a repo in the code you
changed can also be resolved to a sha1. I'm not sure where that other
code is though (in git-submodule.sh, or elsewhere in add).

Perhaps we end up in index_path(), which then barfs? That would explain
this (run in the trash directory after the test fails):

  $ cd reltest && git add a/b/c
  error: unable to index file a/b/c/
  fatal: adding files failed

We know it is a git dir, but there is no sha1 for us to actually add as
the gitlink entry.

If that is the case, then there is either some very tricky refactoring
required, or what we are trying to do here is simply wrong. Maybe it
would be simpler to just speed up resolve_gitlink_ref with a better data
structure.

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

[PATCH] git-check-ref-format.txt: typo, s/avoids/avoid/

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Documentation/git-check-ref-format.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-check-ref-format.txt 
b/Documentation/git-check-ref-format.txt
index 9044dfa..91a3622 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -60,7 +60,7 @@ Git imposes the following rules on how references are named:
 
 These rules make it easy for shell script based tools to parse
 reference names, pathname expansion by the shell when a reference name is used
-unquoted (by mistake), and also avoids ambiguities in certain
+unquoted (by mistake), and also avoid ambiguities in certain
 reference name expressions (see linkgit:gitrevisions[7]):
 
 . A double-dot `..` is often used as in `ref1..ref2`, and in some
-- 
2.2.0.513.g477eb31

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

Re: best practices against long git rebase times?

[Stefan Beller]

On Fri, Dec 4, 2015 at 9:33 AM, demerphq  wrote:
> In all fairness however, I do believe that some of the recent changes
> to git helped, but I dont how much or which. What I do know is we
> still have the cron sweeper process cleaning refs. (It broke one of my
> repos that I set up with --reference just the other day).
>
> Yves

git-am was rewritten in C, which is used to apply patches.
This also speeds up rebase.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] show-ref: stop using PARSE_OPT_NO_INTERNAL_HELP

[Junio C Hamano]

René Scharfe  writes:

> The flag PARSE_OPT_NO_INTERNAL_HELP is set to allow overriding the
> option -h, except when it's the only one given.
> This is the default behavior now,...

OK, so in the old world order, "-h" used to trigger the internal
help even before consulting parse_short_opt() to see if there is a
handler supplied by the caller, and NO_INTERNAL_HELP was invented as
a kludge to to disable this behaviour.  The existing two users
(dealt with 4/5 and 5/5) both used this mechanism to let their own
handler kick in, but they had to make "-h" without anything else on
the command line behave just like the internal one, while handling
"-h" with something else on the command line do a custom thing.

In the new world order, internal "-h" handler is called only after
seeing that parse_short_opt() decides there is no handler for "-h"
as a fallback.

Side note.  Not really.  Among the three uses of
intenal_help in parse_options_step(), the first one ("lone
-h asks for help") is used before we ask parse_short_opt().

I wonder if we can/want to further tweak this in a follow-up
series.  If that is done, I think NO_INTERNAL_HELP can go away, as
its only effect would be to make us say "unknown option" when "-h"
alone was given from the command line for an options[] array that
does not have a handler for "-h".


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

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

[Junio C Hamano]

Jeff King  writes:

>> diff --git a/credential-cache--daemon.c b/credential-cache--daemon.c
>> index eef6fce..6cda9c0 100644
>> --- a/credential-cache--daemon.c
>> +++ b/credential-cache--daemon.c
>> @@ -256,6 +256,9 @@ int main(int argc, const char **argv)
>>  OPT_END()
>>  };
>>  
>> +int ignore_sighup = 0;
>> +git_config_get_bool("credentialcache.ignoresighup", _sighup);
>> +
>
> Style-wise, I think the declaration should go above the options-list.

I was about to merge this to 'master', following your last issue of
"What's cooking" report.

I was puzzled that git_config_get_bool() is used here without even
checking if we are inside any Git repository and wondered if it was
correct.  I'd imagine this is not a problem, as this process is
spawned by "credential-cache" that was spawned by somebody (either
push or fetch) who has read $GIT_DIR/config for credential.helper to
determine that credential-cache needs to be used.

>> @@ -264,6 +267,10 @@ int main(int argc, const char **argv)
>>  
>>  check_socket_directory(socket_path);
>>  register_tempfile(_file, socket_path);
>> +
>> +if (ignore_sighup)
>> +signal(SIGHUP, SIG_IGN);
>> +
>
> This part looks obviously correct. :)
>
> I don't think there's any need to use sigchain_push here (we have no
> intention of ever popping it).
>
> -Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

[Jeff King]

On Fri, Dec 04, 2015 at 10:55:32AM -0800, Junio C Hamano wrote:

> >> +  int ignore_sighup = 0;
> >> +  git_config_get_bool("credentialcache.ignoresighup", _sighup);
> >> +
> >
> > Style-wise, I think the declaration should go above the options-list.
> 
> I was about to merge this to 'master', following your last issue of
> "What's cooking" report.
> 
> I was puzzled that git_config_get_bool() is used here without even
> checking if we are inside any Git repository and wondered if it was
> correct.  I'd imagine this is not a problem, as this process is
> spawned by "credential-cache" that was spawned by somebody (either
> push or fetch) who has read $GIT_DIR/config for credential.helper to
> determine that credential-cache needs to be used.

That does not have to be the case; I imagine most people would put
credential.helper in their ~/.gitconfig.

But I'm not sure I understand how that is relevant. The config subsystem
should work just fine whether we are in a repository or not (and if not,
return results only from system and user-wide config).

This probably _does_ trigger setup_git_env() when it was not otherwise
called, and it will back to looking at ".git/config" for the repo-level
config. That may fail to find the file if we are in a bare repository,
or a subdirectory of the working tree. IOW, I suspect this:

  git init --bare foo.git
  cd foo.git
  git config credential.helper cache
  git config credentialcache.ignoreSIGHUP true ;# goes into local config
  git fetch https://example.com/foo.git

may fail to respect the ignoreSIGHUP option.

I guess the solution would be to setup_git_director_gently() in the
daemon process.

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