Re: [PATCH 1/2] clone: add disassociate alias to dissociate option

[Jeff King]

On Fri, Feb 20, 2015 at 11:13:47PM -0800, Junio C Hamano wrote:

> >>OPT_BOOL(0, "dissociate", &option_dissociate,
> >> N_("use --reference only while cloning")),
> >> +  OPT_BOOL(0, "disassociate", &option_dissociate,
> >> +   N_("use --reference only while cloning")),
> >
> > Should this second one be marked as OPT_HIDDEN? I do not think we need
> > to show both in "git clone --help".
> 
> For that matter, I am not sure why we want to add this synonym in
> the first place.
> 
> http://www.merriam-webster.com/dictionary/dissociate
> 
> : to end your relationship with or connection to someone or
> something : to separate (yourself) from someone or something
> 
> which is exactly what I wanted the option to achieve.

That is also the definition of disassociate. :) They are both equally
correct here, and some people tend to use one over the other:

  http://grammarist.com/usage/dissociate-disassociate/

So I don't think the spirit of the patch is wrong, in that sense. I am
open to the argument that we do not want to get in the habit of
providing every possible synonym, as it would clutter the interface.
This case is a bit more extreme; given the similarity of the two words,
it is easy to use the wrong one. But I do not personally care much
either way.

As a side note, while writing out an explanation of "--reference
--dissociate" recently, Michael (cc'd) and I noticed that it seems quite
verbose to have to specify both options.

By itself, --dissociate does nothing. It _could_ imply --reference (but
right now complains that --reference was not provided and turns itself
off). But if we were to have a single-option version of "reference and
dissociate", I do not think "--dissociate" is the best choice. By itself
it does not mean much (dissociate from _what_?).

I wonder if there is some better word that could become a synonym for
"--reference --dissociate". Maybe "--borrow", but that does not
necessarily carry the implication that the relationship ends as soon as
the clone is done. What is really happening is that we are reusing
objects in order to save bandwidth. Maybe "--reuse-from" would work?

I dunno. I am not extremely happy with any of the suggestions I made,
nor is any of this of extreme importance to me. But I thought I would
mention it while we are on the subject.

-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 1/2] clone: add disassociate alias to dissociate option

[Junio C Hamano]

Jeff King  writes:

> On Fri, Feb 20, 2015 at 11:10:22AM -0800, Matt Whiteley wrote:
>
>> diff --git a/builtin/clone.c b/builtin/clone.c
>> index 316c75d..7e193ae 100644
>> --- a/builtin/clone.c
>> +++ b/builtin/clone.c
>> @@ -97,6 +97,8 @@ static struct option builtin_clone_options[] = {
>>  N_("clone only one branch, HEAD or --branch")),
>>  OPT_BOOL(0, "dissociate", &option_dissociate,
>>   N_("use --reference only while cloning")),
>> +OPT_BOOL(0, "disassociate", &option_dissociate,
>> + N_("use --reference only while cloning")),
>
> Should this second one be marked as OPT_HIDDEN? I do not think we need
> to show both in "git clone --help".

For that matter, I am not sure why we want to add this synonym in
the first place.

http://www.merriam-webster.com/dictionary/dissociate

: to end your relationship with or connection to someone or
something : to separate (yourself) from someone or something

which is exactly what I wanted the option to achieve.
--
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] log --decorate: do not leak "commit" color into the next item

[Junio C Hamano]

Jeff King  writes:

> On Fri, Feb 20, 2015 at 03:06:39PM -0800, Junio C Hamano wrote:
>
>> -- >8 --
>> Subject: config.txt: spell out how certain typed values are written
>> 
>> Many variables have values that are not arbitrary strings and there
>> are ways to spell these values of certain types.  The way to spell
>> colors was described in a section for color.branch. and other
>> variables refered to that section, which was technically wrong, but
>> was a bit awkward.
>
> Did you mean "not technically" here?

Yes.

> I think this patch is certainly an improvement with respect to the
> colors. And I like that it organizes the types into one place using a
> list, which is easier to scan when you are looking at a manpage. But...
>
>> +Values
>> +~~
>> +
>> +Values of many variables are treated as a simple string, but there
>> +are variables that take values of specific types and there are rules
>> +as to how to spell them.
>> +
>> +boolean::
>> +When a variable is said to take a boolean value, many
>> +synonyms are accepted for 'true' and 'false'.
>> +true;; Boolean true can be spelled as `yes`, `on`, `true`,
>> +or `1`.  Also, a variable defined without `= `
>> +is taken as true.
>> +false;; Boolean false can be spelled as `no`, `off`,
>> +`false`, or `0`.
>
> This information is redundant with what is in the `Syntax` section:
> ...

Heh, thanks.  That is what I wanted to say when I said "other types
may need de-duping" ;-).
--
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/2] clone: add disassociate alias to dissociate option

[Jeff King]

On Fri, Feb 20, 2015 at 11:10:22AM -0800, Matt Whiteley wrote:

> diff --git a/builtin/clone.c b/builtin/clone.c
> index 316c75d..7e193ae 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -97,6 +97,8 @@ static struct option builtin_clone_options[] = {
>   N_("clone only one branch, HEAD or --branch")),
>   OPT_BOOL(0, "dissociate", &option_dissociate,
>N_("use --reference only while cloning")),
> + OPT_BOOL(0, "disassociate", &option_dissociate,
> +  N_("use --reference only while cloning")),

Should this second one be marked as OPT_HIDDEN? I do not think we need
to show both in "git clone --help".

-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] log --decorate: do not leak "commit" color into the next item

[Jeff King]

On Fri, Feb 20, 2015 at 03:06:39PM -0800, Junio C Hamano wrote:

> -- >8 --
> Subject: config.txt: spell out how certain typed values are written
> 
> Many variables have values that are not arbitrary strings and there
> are ways to spell these values of certain types.  The way to spell
> colors was described in a section for color.branch. and other
> variables refered to that section, which was technically wrong, but
> was a bit awkward.

Did you mean "not technically" here?

I think this patch is certainly an improvement with respect to the
colors. And I like that it organizes the types into one place using a
list, which is easier to scan when you are looking at a manpage. But...

> +Values
> +~~
> +
> +Values of many variables are treated as a simple string, but there
> +are variables that take values of specific types and there are rules
> +as to how to spell them.
> +
> +boolean::
> + When a variable is said to take a boolean value, many
> + synonyms are accepted for 'true' and 'false'.
> + true;; Boolean true can be spelled as `yes`, `on`, `true`,
> + or `1`.  Also, a variable defined without `= `
> + is taken as true.
> + false;; Boolean false can be spelled as `no`, `off`,
> + `false`, or `0`.

This information is redundant with what is in the `Syntax` section:

  The values following the equals sign in variable assign are all either
  a string, an integer, or a boolean.  Boolean values may be given as
  yes/no, 1/0, true/false or on/off.  Case is not significant in boolean
  values, when converting value to the canonical form using '--bool'
  type specifier; 'git config' will ensure that the output is "true" or
  "false".

I think that paragraph can go away in favor of what you've written. We
should mention case-insensitivity there. And the final sentence about
`git-config` should go in the section `--bool` description of
`git-config`.

Immediately after that paragraph we discuss string values and quoting.
Technically those quoting rules apply to all values (e.g., colors, which
are just strings with special meaning), but I it may make sense to put
them in a "strong::" bullet here.

> +integer::
> + The value for many variables that specify various sizes can
> + be suffixed with `k`, `M`,... to mean "scale the number by
> + 1024", "by 1024x1024", etc.

I had a feeling we only did this for ulong's, but I checked the code and
we do indeed handle handle unit sizes everywhere. Is it worth mentioning
range limits here? I think since c7c377d83f4 it is probably not a big
deal. "git config --int" uses 64-bit integers everywhere. Internally we
use "unsigned long" for big things. There are still some uses of "int"
internally, but only for things that should obviously be small. And in
any case we complain if there is overflow. So probably it is not
something users need to think about.

-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: [Discuss] soften warning message after cloning "void"

[Junio C Hamano]

Stefan Beller  writes:

> On Wed, Feb 18, 2015 at 6:54 PM, Junio C Hamano  wrote:
>> On Wed, Feb 18, 2015 at 4:43 PM, Shawn Pearce  wrote:
>>>
>>> This fails from a JGit server because the ref advertisement for an
>>> empty repository differs and disagrees with the format used by
>>> git-core. The result is a confused client spewing an odd checkout
>>> message.
>>
>> That is exactly why the rephrasing was brought up, wasn't it?
>>
>> As the Subject: line says, this thread is for people who want to
>> help those users with un-odd message, so discuss away
>> and come up with a final applicable patch ;-).
>
> "warning: remote HEAD does not exist, not checking out any branch."
>
> would then be the correct answer.

Technically speaking, that is incorrect because HEAD already points
at 'master'.  We DO check out a 'master' branch.  What is unusual is
that the branch has not been born yet, and that is exactly the same
state after 'git init' created an empty directory.  I.e.

$ git init new
$ cd new
$ git remote add origin $URL
$ git symbolic-ref HEAD
refs/heads/master

would be exactly the same place where you are when you see that
message.

What we are not doing is not "not checking out". What we are not
doing is to fast-forwarding the void to any of the branches the
remote has, because we do not know which branch the remote wants
us to start our history from by default.

So, "warning: not starting history of 'master' from any of the
remote's branches, as their HEAD does not point to a valid branch"
or something like that?

--
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: Support customized reordering in version sort

[Junio C Hamano]

Junio C Hamano  writes:

> You can define values to optional negatives and optional positives to
> express a more
> elaborate sort order e.g.
>
>   1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1
>
> even though "-post" does not have to be declared as optional positive.

... that is, you say "-pre" is a more negative optional than "-rc"
that is also a negative optional.
--
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: Identifying user who ran “git reset” command

[Technext]

Thanks Junio for the prompt reply! :) Yes, that's exactly how i would like
things to be. I'll definitely try to push this thing and see if this flow
can be implemented.

However, can you please guide me whether there's any way i could have
figured out about the git reset command that the developer executed on his
local? (my first query)

Also, am i right in thinking that a check cannot be implemented using hooks
or any other similar way? (my second query)



--
View this message in context: 
http://git.661346.n2.nabble.com/Identifying-user-who-ran-git-reset-command-tp7625788p7625791.html
Sent from the git mailing list archive at Nabble.com.
--
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: Support customized reordering in version sort

[Junio C Hamano]

On Fri, Feb 20, 2015 at 7:33 PM, Duy Nguyen  wrote:
> On Sat, Feb 21, 2015 at 10:25 AM, Junio C Hamano  wrote:
>> On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen  wrote:
>>>
>>> My idea is to make it easy for the user to change the sort algorithm.
>>> And it's probably intuitive to just substitute a string with
>>> something. So if "1-rc1" is put incorrectly before "1.1" and you
>>> realize that "1.999" ought to be the last one before "2". You could
>>> tell git to internally replace "1-rc1" with "1.999".
>>>
>>> This patch does that. The user feeds substitution rules via
>>> versionsort.substitute config keys, e.g.
>>>
>>> git config versionsort.substitute "-rc .999"
>>
>> I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then
>> 1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, 
>> ...
>> and then 1.1 (aka 1.1-final).
>>
>> If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does
>> it make 1 come after 1.99911, and 1.1.9992 come before 1.1?
>>
>> I didn't read the patch text and perhaps the explanation above is the only
>> thing faulty about your message, or perhaps my reading is faulty and the
>> above describes a sound idea, but I do not see how the above makes sense.
>
> No, faulty thinking. Back to the whiteboard..

One version of vercmp() I read went like this:

 (1) Chomp the version strings into an alternate runs of digits and
non-digits. e.g. 1.2.13 becomes
  "1", ".", "2", "." and "13" while 1.2.9 becomes "1", ".", "2",
"." and "9".
 (2) Compare corresponding elements with strcmp() for runs of
non-digits, and numerically for
  runs of digits. In the above example, up to the shared "1.2."
would compare equal, and the
  final run of digits, "13" and "9" are compared numerically and
we declare that 1.2.13 comes
  later.

I think you can add a twist by introducing "optionally this can
appear" substring. When there is
such an optional substring defined, you also define if the side that
lack the optional substring
comes before or after the side that has one. For example, you declare
"[-]rc" as "optional
substring that makes the owner of such a substring sort before others"
(call it "optional negative
substring") and comparing 2.0-rc12, 2.0-rc2 and 2.0:

 - "2.0" becomes "2", ".", "0" and "2.0-rc2" becomes "2", ".", "0",
"-rc", "2". Comparing them
   from left to right, the first difference is "lack of anything (2.0
side runs out tokens)" and
   "-rc", which is marked as optional negative. Hence 2.0-rc2 sorts before 2.0

 - "2.0-rc12" and "2.0-rc2" splits into tokens similarly. The first
difference you see will be
   after you match "-rc" and "-rc", which is "12" vs "2". Comparing
them numerically, you
   know "2.0-rc12" comes later.

You can define values to optional negatives and optional positives to
express a more
elaborate sort order e.g.

  1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1

even though "-post" does not have to be declared as optional positive.
--
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: Identifying user who ran “git reset” command

[Junio C Hamano]

On Fri, Feb 20, 2015 at 8:46 PM, Technext  wrote:
> The biggest problem that I see here is that
> every developer has the rights to commit, which I feel is not right.

Hmm, if you have some way to classify developers into two (or more?)
categories, what would you do instead? Allow some to commit, and
what can others do? Show their change to more senior people and
ask them to commit?

That is more or less in a traditional centralized SCM set-up, I think.

With Git, you can do something similar with "rights to push", if you
prefer such a workflow. It would go like this:

 (1) Everybody can commit to their own repository and grow their own
  history. What you want to protect is the shared view of the project
  history, and restricting what people can do in their own playpen is
  unnecessary.

 (2) Senior people can push into the project's central repository, just
  like in the set-up you currently have.

 (3) Junior people can ask senior people to pull from them. Senior
  people will pull their changes, review, and if the changes are
  good, merge them and push the result to the project's central
  repository. Alternatively, junior people can do this asking by
  sending patches to senior people, who will review and then
  apply to their tree and push the result out to the common history.
--
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

Identifying user who ran “git reset” command

[Technext]

I came across a problem recently. One of the developers committed some
changes in a branch. When he checked the branch log (git checkout branch;
git log), the commit (say, abc) was showing up but when he checked the log
for a file (git log ), which was part of the given commit (abc),
the associated commit (abc) was not showing up; instead, an older commit id
(say, xyz) was there.

When the issue came to my notice, I tried using "git log --follow
" to check complete history of a file just to make sure whether
the file was renamed to its current name. The output of "git log --follow
" was actually showing the commit id (abc) that was missing in
the output of "git log " command. On asking developer whether the
file was renamed, i came to know that no renames were done ever for that
file. This was confusing and i was stuck because i was not able to figure
out what happened. Later, it turned out that another developer while pushing
his code encountered merge conflict and instead of resolving it, he simply
did a "git reset ." and the HEAD got shifted.

Q.1) Is there any way i could have figured out about the "git reset" command
that the other developer executed on his machine? FYI, i have admin access
to Git.

Q.2) Is there any way we can control such things from happening in future?
I’m not sure whether this can be controlled using hook because this is not a
‘push’ command. It's something that's being done just before push. Please
correct me if I’m mistaken. The biggest problem that I see here is that
every developer has the rights to commit, which I feel is not right. I feel,
even restricting it cannot be foolproof but it can certainly bring down such
occurrences significantly. Any suggestions?



--
View this message in context: 
http://git.661346.n2.nabble.com/Identifying-user-who-ran-git-reset-command-tp7625788.html
Sent from the git mailing list archive at Nabble.com.
--
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 Scaling: What factors most affect Git performance for a large repo?

[Duy Nguyen]

On Fri, Feb 20, 2015 at 7:42 AM, David Turner  wrote:
> On Fri, 2015-02-20 at 06:38 +0700, Duy Nguyen wrote:
>> >* 'git push'?
>>
>> This one is not affected by how deep your repo's history is, or how
>> wide your tree is, so should be quick..
>>
>> Ah the number of refs may affect both git-push and git-pull. I think
>> Stefan knows better than I in this area.
>
> I can tell you that this is a bit of a problem for us at Twitter.  We
> have over 100k refs, which adds ~20MiB of downstream traffic to every
> push.
>
> I added a hack to improve this locally inside Twitter: The client sends
> a bloom filter of shas that it believes that the server knows about; the
> server sends only the sha of master and any refs that are not in the
> bloom filter.  The client  uses its local version of the servers' refs
> as if they had just been sent.  This means that some packs will be
> suboptimal, due to false positives in the bloom filter leading some new
> refs to not be sent.  Also, if there were a repack between the pull and
> the push, some refs might have been deleted on the server; we repack
> rarely enough and pull frequently enough that this is hopefully not an
> issue.

I wonder how efficient rsync is for transferring these refs: the
client generates a "file" containing all refs, the server does the
same with their refs, then the client rsync their file to the server..
The changes between the server and the client files are usually small,
I'm hoping rsync can take advantage of that.
-- 
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 Scaling: What factors most affect Git performance for a large repo?

[Duy Nguyen]

On Fri, Feb 20, 2015 at 7:09 PM, Ævar Arnfjörð Bjarmason
 wrote:
>>> But actually most of "git fetch" is spent in the reachability check
>>> subsequently done by "git-rev-list" which takes several seconds. I
>>
>> I wonder if reachability bitmap could help here..
>
> I could have sworn I had that enabled already but evidently not. I did
> test it and it cut down on clone times a bit. Now our daily repacking
> is:
>
> git --git-dir={} gc &&
> git --git-dir={} pack-refs --all --prune &&
> git --git-dir={} repack -Ad --window=250 --depth=100
> --write-bitmap-index --pack-kept-objects &&
>
> It's not clear to me from the documentation whether this should just
> be enabled on the server, or the clients too. In any case I've enabled
> it on both.

Pack bitmaps matter most on the server side. What I was not sure was
whether it helped the client side as well because you do rev-list on
the client side for reachability test. But thinking again, I don't
think enabling pack bitmaps on the client side helps much. The "--not
--all" part in rev-list basically just traverses commits, not trees
and objects (where pack bitmaps shine). The big problem here is
"--all" which will go examine all refs. So big ref number problem
again..

> Even then with it enabled on both a "git pull" that pulls down just
> one commit on one branch is 13s. Trace attached at the end of the
> mail.
>
>>> haven't looked into it but there's got to be room for optimization
>>> there, surely it only has to do reachability checks for new refs, or
>>> could run in some "I trust this remote not to send me corrupt data"
>>> completely mode (which would make sense within a company where you can
>>> trust your main Git box).
>>
>> No, it's not just about trusting the server side, it's about catching
>> data corruption on the wire as well. We have a trick to avoid
>> reachability check in clone case, which is much more expensive than a
>> fetch. Maybe we could do something further to help the fetch case _if_
>> reachability bitmaps don't help.
>
> Still, if that's indeed a big bottleneck what's the worst-case
> scenario here? That the local repository gets hosed? The server will
> still recursively validate the objects it gets sent, right?

The server is under pressure to pack and send data fast so it does not
validate as heavily as the client. When deltas are reused, only crc32
is verified. When deltas are generated, the server must unpack some
objects for deltification, but I don't think it rehashes the content
to see if it produces the same SHA-1. Single bit flips could go
unnoticed..

> I wonder if a better trade-off in that case would be to skip this in
> some situations and instead put something like "git fsck" in a
> cronjob.

Either that or be optimistic, accept the pack (i.e. git-fetch returns
quickly) and validate it in the background. If the pack is indeed
good, you don't have to wait until validation is done. If the pack is
bad, you would know after a minute or two, hopefully you can still
recover from that point.
-- 
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: Support customized reordering in version sort

[Duy Nguyen]

On Sat, Feb 21, 2015 at 10:25 AM, Junio C Hamano  wrote:
> On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen  wrote:
>>
>> My idea is to make it easy for the user to change the sort algorithm.
>> And it's probably intuitive to just substitute a string with
>> something. So if "1-rc1" is put incorrectly before "1.1" and you
>> realize that "1.999" ought to be the last one before "2". You could
>> tell git to internally replace "1-rc1" with "1.999".
>>
>> This patch does that. The user feeds substitution rules via
>> versionsort.substitute config keys, e.g.
>>
>> git config versionsort.substitute "-rc .999"
>
> I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then
> 1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, 
> ...
> and then 1.1 (aka 1.1-final).
>
> If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does
> it make 1 come after 1.99911, and 1.1.9992 come before 1.1?
>
> I didn't read the patch text and perhaps the explanation above is the only
> thing faulty about your message, or perhaps my reading is faulty and the
> above describes a sound idea, but I do not see how the above makes sense.

No, faulty thinking. Back to the whiteboard..

-- 
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: Support customized reordering in version sort

[Junio C Hamano]

On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen  wrote:
>
> My idea is to make it easy for the user to change the sort algorithm.
> And it's probably intuitive to just substitute a string with
> something. So if "1-rc1" is put incorrectly before "1.1" and you
> realize that "1.999" ought to be the last one before "2". You could
> tell git to internally replace "1-rc1" with "1.999".
>
> This patch does that. The user feeds substitution rules via
> versionsort.substitute config keys, e.g.
>
> git config versionsort.substitute "-rc .999"

I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then
1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ...
and then 1.1 (aka 1.1-final).

If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does
it make 1 come after 1.99911, and 1.1.9992 come before 1.1?

I didn't read the patch text and perhaps the explanation above is the only
thing faulty about your message, or perhaps my reading is faulty and the
above describes a sound idea, but I do not see how the above makes sense.
--
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

Support customized reordering in version sort

[Duy Nguyen]

On Fri, Feb 20, 2015 at 12:26:29AM -0800, Junio C Hamano wrote:
> On Thu, Feb 19, 2015 at 11:13 PM, Jeff King  wrote:
> 
> >> There is debian bug 777690 [1] that's basically about making tag's
> >> version sort aware about -rc, -pre suffixes. I imagine it would touch
> >> versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
> >> file).
> >>
> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690
> >
> > I think that's a reasonable thing to work on, but it's too big for a
> > microproject and too small for a GSoC.
> 
> That is certainly too big as a Micro, but I do not think it is too small
> for GSoC, if it is to be done right (meaning, not just implementing an
> arbitrary version comparison hardwired, but design how to make it
> extensible).

I did write "maybe more of mini-size than micro" then looked at the
micro list again and somehow decided to delete that. Anyway while I
still have my attention on it, might as well do it.

My idea is to make it easy for the user to change the sort algorithm.
And it's probably intuitive to just substitute a string with
something. So if "1-rc1" is put incorrectly before "1.1" and you
realize that "1.999" ought to be the last one before "2". You could
tell git to internally replace "1-rc1" with "1.999".

This patch does that. The user feeds substitution rules via
versionsort.substitute config keys, e.g.

git config versionsort.substitute "-rc .999"

Performance is not a concern because I don't think people would throw
100k tags to it. There are two issues I'm aware of but not addressed:

 - the order of substitution matters, but right now it's up in the air
 - case-sensitiveness may surprise users

-- 8< --
diff --git a/versioncmp.c b/versioncmp.c
index 7511e08..2419e38 100644
--- a/versioncmp.c
+++ b/versioncmp.c
@@ -1,4 +1,5 @@
 #include "cache.h"
+#include "strbuf.h"
 
 /*
  * versioncmp(): copied from string/strverscmp.c in glibc commit
@@ -20,6 +21,57 @@
 #define  CMP2
 #define  LEN3
 
+struct subst_rule
+{
+   const char *before;
+   const char *after;
+};
+static struct subst_rule *rules;
+static int rule_nr, rule_alloc;
+
+static int versioncmp_config(const char *k, const char *v, void *cb)
+{
+   char *p, *s;
+   if (strcmp(k, "versionsort.substitute"))
+   return 0;
+   ALLOC_GROW(rules, rule_nr + 1, rule_alloc);
+   s = xstrdup(v);
+   p = strchr(s, ' ');
+   if (!p)
+   return error("missing space in %s", v);
+   *p = '\0';
+   rules[rule_nr].before = s;
+   rules[rule_nr].after = p + 1;
+   rule_nr++;
+   return 0;
+}
+
+static char *substitute(const unsigned char **strp)
+{
+   struct strbuf sb = STRBUF_INIT;
+   const char *str = (const char *)*strp;
+   int i;
+   if (!rules) {
+   rules = xmalloc(sizeof(*rules));
+   rule_alloc = 1;
+   git_config(versioncmp_config, NULL);
+   }
+   for (i = 0; i < rule_nr; i++) {
+   const struct subst_rule *r = rules + i;
+   const char *p = strstr(str, r->before);
+   if (!p)
+   continue;
+   if (!sb.len)
+   strbuf_addstr(&sb, str);
+   strbuf_splice(&sb, p - str, strlen(r->before),
+ r->after, strlen(r->after));
+   str = sb.buf;
+   }
+   if ((const unsigned char *)str == *strp)
+   return NULL;
+   *strp = (const unsigned char *)sb.buf;
+   return sb.buf;
+}
 
 /*
  * Compare S1 and S2 as strings holding indices/version numbers,
@@ -32,6 +84,7 @@ int versioncmp(const char *s1, const char *s2)
 {
const unsigned char *p1 = (const unsigned char *) s1;
const unsigned char *p2 = (const unsigned char *) s2;
+   char *free1, *free2;
unsigned char c1, c2;
int state, diff;
 
@@ -58,6 +111,8 @@ int versioncmp(const char *s1, const char *s2)
 
if (p1 == p2)
return 0;
+   free1 = substitute(&p1);
+   free2 = substitute(&p2);
 
c1 = *p1++;
c2 = *p2++;
@@ -75,6 +130,10 @@ int versioncmp(const char *s1, const char *s2)
}
 
state = result_type[state * 3 + (((c2 == '0') + (isdigit (c2) != 0)))];
+   if (state != LEN) {
+   free(free1);
+   free(free2);
+   }
 
switch (state) {
case CMP:
@@ -82,10 +141,16 @@ int versioncmp(const char *s1, const char *s2)
 
case LEN:
while (isdigit (*p1++))
-   if (!isdigit (*p2++))
+   if (!isdigit (*p2++)) {
+   free(free1);
+   free(free2);
return 1;
+   }
 
-   return isdigit (*p2) ? -1 : diff;
+   c2 = *p2;
+   free(free1);
+   free(free2);
+   return isdigit (c2) ? -1 : diff;
 
 

Re: [RFH] GSoC 2015 application

[Jeff King]

On Fri, Feb 20, 2015 at 04:48:44AM -0500, Jeff King wrote:

> > From your list, it seems we can target 1 or 2 slots. I'd say it's still
> > worth applying, but if we don't find more mentors then perhaps it would
> > make sense to say so explicitely in
> > http://git.github.io/SoC-2015-Ideas.html so that students looking for
> > organization know that we'll have very few slots.
> 
> I don't mind doing 1 slot if that's what we have resources for. But if
> we have to say "eh, we do not really have enough mentors to support
> you", then I wonder if it is worth doing.  They do not know how many
> people have applied, or how tight the competition is.

So that being said, I did complete the application. We can still
withdraw if we want before students start applying, or we can put a
disclaimer on the ideas page.

I tweaked the application text to update it for this year, but nothing
too major. The result is at:

  http://git.github.io/SoC-2015-Org-Application.html

That content was cut-and-pasted into Google's application interface.
Matthieu, as backup admin you should have access to tweak that if there
are typos, etc (and I will probably not be available to apply fixes from
now until the deadline, so please do so if you see anything).

We can continue to improve the ideas page as time goes on. At some point
Google will look at as part of the application, but probably not right
at the deadline. :)

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

Re: Git Scaling: What factors most affect Git performance for a large repo?

[David Turner]

On Fri, 2015-02-20 at 13:37 -0700, Martin Fick wrote:
> On Friday, February 20, 2015 01:29:12 PM David Turner wrote:
> >...
> > For a more general solution, perhaps a log of ref updates
> > could be used. Every time a ref is updated on the server,
> > that ref would be written into an append-only log.  Every
> > time a client pulls, their pull data includes an index
> > into that log.  Then on push, the client could say, "I
> > have refs as-of $index", and the server could read the
> > log (or do something more-optimized) and send only refs
> > updated since that index.
> 
> Interesting idea, I like it.
> 
> How would you make this reliable?  It relies on updates 
> being reliably recorded which would mean that you would have 
> to ensure that any tool which touches the repo follows this 
> convention.  That is unfortunately a tough thing to enforce 
> for most people.

I think it only truly relies on the server reliably updating its state
on ref updates. Which of course the server will do because why would you
let arbitrary processes write to your central git repo?  (That is, most
people use git in a roughly-centralized way, and if you turn on this
config option, you promise to only do ref updates that write to the
log).

If the client fails to update its state (on a fetch), it will send
larger-than-necessary packs but not otherwise fail.  And this situation
is sometimes be detectable on the client side -- if
mtime(.git/refs/remotes/$remote ) > mtime
(.git/server-ref-log-index/$remote), then we know our
server-ref-log-index is out-of-date.


--
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 v3] submodule: Improve documentation of update subcommand

[Junio C Hamano]

Michal Sojka  writes:

> This patch fixes all these problems. Now, submodule.$name.update is
> fully documented in git-submodule.txt and the other files just refer to

"Fix all these problems by documenting submodule.*.update in
git-submodule.txt and make everybody else refer to it" in imperative
mood, as if you are giving an order to the source to "be this way".
It would be sweeter and shorter that way.

> it. This is based on discussion between Junio C Hamano, Jens Lehmann and
> myself.

It's customary to just mention them on Helped-by: around here, I
think.

> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index 8e6af65..72c6fb2 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -154,14 +154,36 @@ If `--force` is specified, the submodule's work tree 
> will be removed even if
>  it contains local modifications.
>  
>  update::
> + Update the registered submodules to match what the superproject
> + expects by cloning missing submodules and updating the working
> + tree of the submodules. The "updating" can be done in several
> + ways depending on command line options and the value of
> + `submodule..update` in .git/config:

No quoting around .git/config?  Actually, it is probably better not
to spell out that path.  "... and the value of the `...`
configuration variable" would be better.

> + checkout;; the new commit recorded in the superproject will be
> + checked out in the submodule on a detached HEAD. This is

Drop "new".  It does not add anything to the description, and you
may even be checking out an old commit in the superproject.

> @@ -238,10 +261,11 @@ OPTIONS

Totally offtopic, but we may want a custom xfuncname for our AsciiDoc
documentation; we would want to see "--force::" not "OPTIONS" on the
above line, I would think.

>   When running add, allow adding an otherwise ignored submodule path.
>   When running deinit the submodule work trees will be removed even if
>   they contain local changes.
> - When running update, throw away local changes in submodules when
> - switching to a different commit; and always run a checkout operation
> - in the submodule, even if the commit listed in the index of the
> - containing repository matches the commit checked out in the submodule.
> + When running update and the checkout method is used, throw away
> + local changes in submodules when switching to a different
> + commit; and always run a checkout operation in the submodule,
> + even if the commit listed in the index of the containing
> + repository matches the commit checked out in the submodule.

This makes a reader wonder what --force would do when --merge or
--rebase is given from the command line (or specifiedy in the
configuration).  The original (unfortunately) did not have that
problem because it did not single out the --checkout mode.

The use of the phrase "the checkout method" is iffy, as nobody
defines what it is (I just said "--checkout mode" to mean the same
thing, but I do not think anybody defines it).  See below.


> @@ -302,7 +326,7 @@ the submodule itself.
>   Checkout the commit recorded in the superproject on a detached HEAD
>   in the submodule. This is the default behavior, the main use of
>   this option is to override `submodule.$name.update` when set to
> - `merge`, `rebase` or `none`.
> + other value than `checkout`.

"... when set to a value other than `checkout`", would read better,
I would think.

> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
> index f6c0dfd..a51183c 100644
> --- a/Documentation/gitmodules.txt
> +++ b/Documentation/gitmodules.txt
> @@ -38,18 +38,12 @@ submodule..url::
>  In addition, there are a number of optional keys:
>  
>  submodule..update::
> + Defines what to do when the submodule is updated by the
> + superproject. This is only used by `git submodule init` to
> + initialize the variable of the same name in .git/config.
> + Allowed values here are 'checkout', 'rebase', 'merge' or
> + 'none'. See description of 'update' command in
> + linkgit:git-submodule[1] for their meaning.

Whatever word we decide to use, this may be a good place to
introduce it, perhaps like this (if we were to go with 'update
method'):

submodule..update::

Define the default update method for the named submodule,
how the submodule is updated by "git submodule update"
command in the superproject.

The enumeration of the allowed values is correct, I think, but we
might want to be very clear that we do not copy the !command form
and that is on purpose.
--
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: [RFH] GSoC 2015 application

[Eric Sunshine]

On Fri, Feb 20, 2015 at 5:06 AM, Matthieu Moy
 wrote:
> Jeff King  writes:
>> I think these might be getting a little larger than "micro".
>
> The ~/.git-credential-cache may be a bit harder, but the case of
> ~/.git-credentials should follow the same pattern as files for which
> this is already done. So, doing it by mimicking existing code shouldn't
> be too hard.
>
> But maybe that's me being optimistic ;-).

As a person who did a significant number of GSoC 2014 micro-project
reviews (as well as many actual GSoC reviews), I probably ought to
weigh in and say that this may be too optimistic. In fact, most of the
GSoC 2015 micro-project suggestions[1] seem far too large and
involved.

For 2014, most of the GSoC micro-projects were extremely simple, of
the form "replace starts_with() with skip_prefix()", yet most
applicants still required three or four (or more) attempts to get it
right (and some never did), even with extremely detailed hand-holding
reviews at each step. (And, such reviews are quite time-consuming. I
was allocating six to eight hours each day to those reviews, yet I
couldn't keep up with all the submissions.)

Although quite simple, many of the 2014 micro-projects[2]
(particularly from Michael Haggerty) had a bit of a twist (or trick
question) thrown in, requiring a tad more thought and effort than mere
mechanical search-and-replace. That was useful because it helped
identify potentially acceptable candidates more easily, however, that
added twist was probably a good upper limit on difficulty for
micro-projects.

Another important aspect of 2014's micro-projects was that they could
be accomplished with only very localized knowledge: that is, a student
could read the logic of the one function being touched and learn
enough to be successful. The micro-projects did not require global
knowledge of Git internals or hours of research.

The attitude in 2014 was that it was important for students to get a
taste of what it is like working on the Git project and what would be
expected of them as submitters, and for GSoC administrators and
mentors to get a feel for the applicants by how they interacted with
reviewers. By going through the review process on a project with high
engineering standards, it also was hope that students would learn and
benefit from the experience even if not selected. Extremely simple
micro-projects (possibly with a twist) in the style of 2014's were
more than sufficient to satisfy these goals, and were more than enough
to consume significant reviewer time. The suggested 2015's
micro-projects seem far in excess.

[1]: http://git.github.io/SoC-2015-Microprojects.html
[2]: http://git.github.io/SoC-2014-Microprojects.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] log --decorate: do not leak "commit" color into the next item

[Junio C Hamano]

Jeff King  writes:

> I'd agree it is worth a mention in the log (and possibly release notes),
> but I don't think it is worth polluting the documentation forever
> (though explaining that we never inherit might be worth doing, and that
> is perhaps what you meant).

Yes, I do not know how well the attached will render, but something
along the lines of this patch is what I had in mind.

-- >8 --
Subject: config.txt: spell out how certain typed values are written

Many variables have values that are not arbitrary strings and there
are ways to spell these values of certain types.  The way to spell
colors was described in a section for color.branch. and other
variables refered to that section, which was technically wrong, but
was a bit awkward.

I didn't attempt to de-dup descriptions for boolean and integer
valued variables in this change, but somebody may want to read
the existing descriptions of these variables over and drop them
as necessary.

Signed-off-by: Junio C Hamano 
---
 Documentation/config.txt | 58 +++-
 1 file changed, 42 insertions(+), 16 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 097fdd4..171287e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -126,6 +126,45 @@ Example
path = foo ; expand "foo" relative to the current file
path = ~/foo ; expand "foo" in your $HOME directory
 
+Values
+~~
+
+Values of many variables are treated as a simple string, but there
+are variables that take values of specific types and there are rules
+as to how to spell them.
+
+boolean::
+   When a variable is said to take a boolean value, many
+   synonyms are accepted for 'true' and 'false'.
+   true;; Boolean true can be spelled as `yes`, `on`, `true`,
+   or `1`.  Also, a variable defined without `= `
+   is taken as true.
+   false;; Boolean false can be spelled as `no`, `off`,
+   `false`, or `0`.
+
+integer::
+   The value for many variables that specify various sizes can
+   be suffixed with `k`, `M`,... to mean "scale the number by
+   1024", "by 1024x1024", etc.
+
+color::
+   The value for a variables that takes a color is a list of
+   colors (at most two) and attributes (at most one), separated
+   by spaces.  The colors accepted are `normal`, `black`,
+   `red`, `green`, `yellow`, `blue`, `magenta`, `cyan` and
+   `white`; the attributes are `bold`, `dim`, `ul`, `blink` and
+   `reverse`.  The first color given is the foreground; the
+   second is the background.  The position of the attribute, if
+   any, doesn't matter.
++
+The attributes are meant to be reset at the beginning of each item
+in the colored output, so setting color.decorate.branch to `black`
+will paint that branch name in a plain `black`, even if the previous
+thing on the same output line (e.g. opening parenthesis before the
+list of branch names in `log --decorate` output) is set to be painted
+with `bold` or some other attribute.
+
+
 Variables
 ~
 
@@ -817,14 +856,6 @@ color.branch.::
`remote` (a remote-tracking branch in refs/remotes/),
`upstream` (upstream tracking branch), `plain` (other
refs).
-+
-The value for these configuration variables is a list of colors (at most
-two) and attributes (at most one), separated by spaces.  The colors
-accepted are `normal`, `black`, `red`, `green`, `yellow`, `blue`,
-`magenta`, `cyan` and `white`; the attributes are `bold`, `dim`, `ul`,
-`blink` and `reverse`.  The first color given is the foreground; the
-second is the background.  The position of the attribute, if any,
-doesn't matter.
 
 color.diff::
Whether to use ANSI escape sequences to add color to patches.
@@ -844,8 +875,7 @@ color.diff.::
of `plain` (context text), `meta` (metainformation), `frag`
(hunk header), 'func' (function in hunk header), `old` (removed lines),
`new` (added lines), `commit` (commit headers), or `whitespace`
-   (highlighting whitespace errors). The values of these variables may be
-   specified as in color.branch..
+   (highlighting whitespace errors).
 
 color.decorate.::
Use customized color for 'git log --decorate' output.  `` is one
@@ -878,8 +908,6 @@ color.grep.::
separators between fields on a line (`:`, `-`, and `=`)
and between hunks (`--`)
 --
-+
-The values of these variables may be specified as in color.branch..
 
 color.interactive::
When set to `always`, always use colors for interactive prompts
@@ -892,8 +920,7 @@ color.interactive.::
Use customized color for 'git add --interactive' and 'git clean
--interactive' output. `` may be `prompt`, `header`, `help`
or `error`, for four distinct types of normal output from
-   interactive commands.  The values of these variables may be
-   specified as in color.branch..
+   interactive c

Re: Git Scaling: What factors most affect Git performance for a large repo?

[brian m. carlson]

On Fri, Feb 20, 2015 at 11:08:55PM +0100, Sebastian Schuberth wrote:

On 20.02.2015 01:03, brian m. carlson wrote:


If you want good performance, I'd recommend the latest version of Git
both client- and server-side.  Newer versions of Git provide pack
bitmaps, which can dramatically speed up clones and fetches, and Git


Do you happen now which version, if at all, of JGit and Gerrit support 
pack bitmaps?


They were originally implemented in JGit, but I don't know what version, 
sorry.  Some googling tells me that it's probably version 3.0.



2.3.0 fixes a performance regression with large numbers of refs in
non-shallow repositories.


Do you also know in what Git version the regression was introduced?


v1.8.4-rc3-8-gfbd4a70.  It was fixed in v2.2.1-65-g2dacf26.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: git mac 10.7.x

[Kyle J. McKay]

On Feb 20, 2015, at 12:01, sojourner wrote:
What's the difference between this installer and the other one? Why  
is this installer going to work?


See the website for a description.  It was built to work with 10.4.8  
or later.  It was built using Apple's older GCC specifically to be  
compatible so does not contain any "illegal instructions" that only  
work on 10.8.x or later.  Besides, I've actually run it on the older  
systems without problem so I'm pretty confident you won't have an  
issue with it.


-Kyle


On 20 Feb 2015, at 13:32, Kyle J. McKay wrote:


On Feb 20, 2015, at 02:38, sojourner wrote:
Installed Git via installer. Updated path in .bash_profile. Get  
error Illegal instruction: 4 when trying to run Git.


Built Git from source. Searches for the compiled source  
unsuccessful. Which is nice: there's nothing to uninstall.


Searching online has a lot of suggestions and ideas. Anybody have  
anything that actually works?--


You can get a working installer from  that should work for you on 10.7.x just fine.


-Kyle




--
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: [ANNOUNCE] Git Merge, April 8-9, Paris

[Junio C Hamano]

Yi EungJun  writes:

> I heard Git Contributors Summit is scheduled on April 8th at Git Merge 2015.
>
> Does anyone know the agenda of the summit? I am considering to attend the
> summit.

I am curious, too; the event is marked as invitation-only and I do
not know who decides the eligibility criteria.
--
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] connect.c: Improve parsing of literal IPV6 addresses

[Torsten Bögershausen]

On 2015-02-19 20.40, brian m. carlson wrote:
> On Thu, Feb 19, 2015 at 09:54:52AM -0800, Junio C Hamano wrote:
>> I can see that you do not agree with the "If we accept it" part
>> (where "it" refers to "allowing [...] was a bug.")---past acceptance
>> was not a bug for you.
Do we talk about the same thing here ?

The support for the ssh://host/path was introduced 2005, I think here:
commit 2386d65822c912f0889ac600b1698b0659190133
Author: Linus Torvalds 
Date:   Wed Jul 13 18:46:20 2005 -0700

Add first cut at "git protocol" connect logic.


It happily accepted everything for host, including 
 ssh://bmc@2001:470:1f05:79::1/git/bmc/homedir.git/

And this was the only way to connect to a server using a literal IPV6
address, the support for [] came in later.

Today, in 2015, we can declare this syntax as deprecated, no problem.

The parser we have in git.master does not handle URLs like
ssh://bmc@[2001:470:1f05:79::1]/git/bmc/homedir.git/ correctly.

Instead of this,
ssh://[bmc@2001:470:1f05:79::1]/git/bmc/homedir.git/
needs to be used, and this is the main purpose of the series.
(If we ignore updates of the test cases, which I think are good
to prevent regressions)


I could probably shorten the commit message of [1/3] to read like this: 

  Improve the parsing to handle URLs which have a user name and a literal
IPV6 like "ssh://user@[2001:db8::1]/repo.git".
(Thanks to Christian Taube  for reporting this long
standing issue)


>>
>> Brian is for that "If we accept it", and sees it as a bug.
>>
>> So let's see what he comes up with as a follow-up to the "we should
>> explicitly document it" part.
> 
> Here's what I propose:
> 
> -- >8 --
> Subject: [PATCH] Documentation: note deprecated syntax for IPv6 SSH URLs
> 
> We have historically accepted some invalid syntax for SSH URLs
> containing IPv6 literals.  Older versions of Git accepted URLs missing
> the brackets required by RFC 2732.  Note that this behavior is
> deprecated and that other protocol handlers will not accept this syntax.
> 
> Signed-off-by: brian m. carlson 
> ---
> Documentation/urls.txt | 4 
> 1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/urls.txt b/Documentation/urls.txt
> index 9ccb246..2c1a84f 100644
> --- a/Documentation/urls.txt
> +++ b/Documentation/urls.txt
> @@ -38,6 +38,10 @@ The ssh and git protocols additionally support ~username 
> expansion:
> - git://host.xz{startsb}:port{endsb}/~{startsb}user{endsb}/path/to/repo.git/
> - {startsb}user@{endsb}host.xz:/~{startsb}user{endsb}/path/to/repo.git/
> 
> +For backwards compatibility reasons, Git, when using ssh URLs, accepts
> +some URLs containing IPv6 literals that are missing the brackets. This
> +syntax is deprecated, and other protocol handlers do not permit this.
> +
> For local repositories, also supported by Git natively, the following
> syntaxes may be used:
> 

--
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 Scaling: What factors most affect Git performance for a large repo?

[Sebastian Schuberth]

On 20.02.2015 01:03, brian m. carlson wrote:


If you want good performance, I'd recommend the latest version of Git
both client- and server-side.  Newer versions of Git provide pack
bitmaps, which can dramatically speed up clones and fetches, and Git


Do you happen now which version, if at all, of JGit and Gerrit support 
pack bitmaps?



2.3.0 fixes a performance regression with large numbers of refs in
non-shallow repositories.


Do you also know in what Git version the regression was introduced?

--
Sebastian Schuberth
--
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 Scaling: What factors most affect Git performance for a large repo?

[Sebastian Schuberth]

On 20.02.2015 15:25, Ævar Arnfjörð Bjarmason wrote:


tl;dr: After some more testing it turns out the performance issues we
have are almost entirely due to the number of refs. Some of these I


Interesting. We currently have similar performance issues when pushing 
to a Git repo hosted on Gerrit. The only difference of our repo compared 
to others on the same server that do not have any performance issues is 
the large number of refs (about 40k) in refs/changes.


I still wonder why that would slow down a push as we have not configured 
our clients to fetch / push refs/changes.


--
Sebastian Schuberth
--
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] --disassociate alias for --dissociate clone option

[Eric Sunshine]

On Fri, Feb 20, 2015 at 2:10 PM, Matt Whiteley  wrote:
> I find the new --dissociate option for clone very helpful but I have a
> hard time with the spelling. It seems reasonable to have an alias since
> one exists for --recursive.

You may be undermining your own argument for inclusion of a new
--dissociate option by citing the aliased "recursive" option.

git-clone's --recursive-submodules was added (see ccdd3da6) for
disambiguation long after --recursive; and not the other way around
with --recursive being more convenient or easier to remember or spell
than --recursive-submodules. The implication of ccdd3da6 is that
--recursive-submodules is favored over --recursive (and perhaps the
latter may some day be deprecated).
--
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 Scaling: What factors most affect Git performance for a large repo?

[Junio C Hamano]

Ævar Arnfjörð Bjarmason  writes:

> I actually ran this a few times while testing it, so this is a before
> and after on a hot cache of linux.git with 406 tags v.s. ~140k. I ran
> the gc + repack + bitmaps for both repos noted in an earlier reply of
> mine, and took the fastest run out of 3:
>
> $ time (git log master -100 >/dev/null)
> Before: real0m0.021s
> After: real0m2.929s

Do you force --decorate with some config?  Or do you see similar
performance difference with "git rev-parse master", too?

> $ time (git status >/dev/null)
> # Around 150ms, no noticeable difference

This is understandable, as it will not look at any ref other than
HEAD.
--
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 Scaling: What factors most affect Git performance for a large repo?

[Junio C Hamano]

David Turner  writes:

> On Fri, 2015-02-20 at 06:38 +0700, Duy Nguyen wrote:
>> >* 'git push'?
>> 
>> This one is not affected by how deep your repo's history is, or how
>> wide your tree is, so should be quick..
>> 
>> Ah the number of refs may affect both git-push and git-pull. I think
>> Stefan knows better than I in this area.
>
> I can tell you that this is a bit of a problem for us at Twitter.  We
> have over 100k refs, which adds ~20MiB of downstream traffic to every
> push.
>
> I added a hack to improve this locally inside Twitter: The client sends
> a bloom filter of shas that it believes that the server knows about; the
> server sends only the sha of master and any refs that are not in the
> bloom filter.  The client  uses its local version of the servers' refs
> as if they had just been sent

Interesting.

Care to extend the discussion to improve the protocol exchange,
which starts at $gmane/263932 [*1*], where I list the known issues
around the current protocol (and a possible way to correct them in
footnotes)?


[Footnote]

*1* http://thread.gmane.org/gmane.comp.version-control.git/263898/focus=263932
--
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 Scaling: What factors most affect Git performance for a large repo?

[Martin Fick]

On Friday, February 20, 2015 01:29:12 PM David Turner wrote:
>...
> For a more general solution, perhaps a log of ref updates
> could be used. Every time a ref is updated on the server,
> that ref would be written into an append-only log.  Every
> time a client pulls, their pull data includes an index
> into that log.  Then on push, the client could say, "I
> have refs as-of $index", and the server could read the
> log (or do something more-optimized) and send only refs
> updated since that index.

Interesting idea, I like it.

How would you make this reliable?  It relies on updates 
being reliably recorded which would mean that you would have 
to ensure that any tool which touches the repo follows this 
convention.  That is unfortunately a tough thing to enforce 
for most people.

But perhaps, instead of logging updates, the server could 
log snapshots of all refs using an atomically increasing 
sequence number.  Then missed updates do not matter, a 
sequence number is simplly an opaque handle to some full ref 
state that can be diffed against.  The snapshots need not 
even be taken inline with the client connection, or with 
every update for this to work.  It might mean that some 
extra updates are sent when they don't need to be, but at 
least they will be accurate.

I know in the past similar ideas have been passed around, 
but they typically relied on the server keeping track of the 
state of each client.  Instead, here we are talking about 
clients keeping track of state for a particular server.  
Clients already store info about remotes.

A very neat idea indeed, thanks!

-Martin

-- 
The Qualcomm Innovation Center, Inc. is a member of Code 
Aurora Forum, hosted by The Linux Foundation
--
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 mac 10.7.x

[sojourner]

Yeah, the neuroimaging site's info was unhelpful. 

Does anybody have anything that's actually worked? 


On 20 Feb 2015, at 11:35, Matthew Brett wrote:

> Hi,
> 
> On Fri, Feb 20, 2015 at 2:38 AM, sojourner  wrote:
>> Installed Git via installer. Updated path in .bash_profile. Get error 
>> Illegal instruction: 4 when trying to run Git.
> 
> I've seen the installer problem - suggestions here:
> http://practical-neuroimaging.github.io/installation.html#if-you-are-on-osx-10-8-mountain-lion-or-below
> 
>> Built Git from source. Searches for the compiled source unsuccessful. Which 
>> is nice: there's nothing to uninstall.
> 
> I'm not sure what happened there :)
> 
> Best,
> 
> Matthew

--
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 v3 1/2] Documentation/config.txt: document mailinfo.scissors

[Matthieu Moy]

The variable was documented in git-mailinfo.txt, but not in config.txt.
The detailed documentation is still the one of --scissors in
git-mailinfo.txt, but we give enough information here to let the user
understand what it is about, and to make it easy to find it (e.g.
searching ">8" and "8<" finds it).

Signed-off-by: Matthieu Moy 
---
Hopefully, I'd have fixed all intances of my typo now :-\.

Sorry for the noise.

 Documentation/config.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index ae6791d..15f8695 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1740,6 +1740,13 @@ log.mailmap::
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
linkgit:git-whatchanged[1] assume `--use-mailmap`.
 
+mailinfo.scissors::
+   If true, makes linkgit:git-mailinfo[1] (and therefore
+   linkgit:git-am[1]) act by default as if the --scissors option
+   was provided on the command-line. When active, this features
+   removes everything from the message body before a scissors
+   line (i.e. consisting mainly of ">8", "8<" and "-").
+
 mailmap.file::
The location of an augmenting mailmap file. The default
mailmap, located in the root of the repository, is loaded
-- 
2.3.0.157.g79e124b

--
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 v3 2/2] Documentation/git-am.txt: mention mailinfo.scissors config variable

[Matthieu Moy]

It was already documented, but the user had to follow the link to
git-mailinfo.txt to find it.

Signed-off-by: Matthieu Moy 
---
 Documentation/git-am.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index f4eea28..0d8ba48 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -52,7 +52,8 @@ OPTIONS
 -c::
 --scissors::
Remove everything in body before a scissors line (see
-   linkgit:git-mailinfo[1]).
+   linkgit:git-mailinfo[1]). Can be activated by default using
+   the `mailinfo.scissors` configuration variable.
 
 --no-scissors::
Ignore scissors lines (see linkgit:git-mailinfo[1]).
-- 
2.3.0.157.g79e124b

--
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 Scaling: What factors most affect Git performance for a large repo?

[Randall S. Becker]

-Original Message-
On Feb 20, 2015 1:58AM Martin Fick wrote:
>On Feb 19, 2015 5:42 PM, David Turner  wrote:
> > This one is not affected by how deep your repo's history is, or how 
> > wide your tree is, so should be quick.. 
>Good to hear that others are starting to experiment with solutions to this 
>problem!  I hope to hear more updates on this.



Now that Jojo and I  have git 2.3.0 ported to the HP NonStop platform, there 
are some very large code bases out there that may start being managed using 
git. These will tend to initially shallow histories (100's not 1000's of 
commits, and fairly linear) but large source and binaries - I know of a few 
where just the distributed set of sources are above 1Gb and are unlikely to be 
managed in multiple repos despite my previous best efforts to change that. 
Fortunately, It is a relatively simple matter to profile the code on the 
platform for various operations so data on where to improve may be available - 
I hope. 

With that said, for NonStop file system tends to be heavier weight than on 
Linux (many more moving parts by virtue of the MPP nature of the OS and 
hardware). Packing up changes seems pretty good, but any operating involving 
creating a large number of small files does hurt a bunch.


--
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 2/2] clone: Realign lines near disassociate option

[Matt Whiteley]

Fix long line splitting format while adding to builtin_clone_options.

Signed-off-by: Matt Whiteley 
---
 builtin/clone.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/builtin/clone.c b/builtin/clone.c
index 7e193ae..fd6bcf4 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -72,15 +72,15 @@ static struct option builtin_clone_options[] = {
OPT_BOOL(0, "mirror", &option_mirror,
 N_("create a mirror repository (implies bare)")),
OPT_BOOL('l', "local", &option_local,
-   N_("to clone from a local repository")),
+N_("to clone from a local repository")),
OPT_BOOL(0, "no-hardlinks", &option_no_hardlinks,
-   N_("don't use local hardlinks, always copy")),
+N_("don't use local hardlinks, always copy")),
OPT_BOOL('s', "shared", &option_shared,
-   N_("setup as shared repository")),
+N_("setup as shared repository")),
OPT_BOOL(0, "recursive", &option_recursive,
-   N_("initialize submodules in the clone")),
+N_("initialize submodules in the clone")),
OPT_BOOL(0, "recurse-submodules", &option_recursive,
-   N_("initialize submodules in the clone")),
+N_("initialize submodules in the clone")),
OPT_STRING(0, "template", &option_template, N_("template-directory"),
   N_("directory from which templates will be used")),
OPT_CALLBACK(0 , "reference", &option_reference, N_("repo"),
@@ -92,9 +92,9 @@ static struct option builtin_clone_options[] = {
OPT_STRING('u', "upload-pack", &option_upload_pack, N_("path"),
   N_("path to git-upload-pack on the remote")),
OPT_STRING(0, "depth", &option_depth, N_("depth"),
-   N_("create a shallow clone of that depth")),
+  N_("create a shallow clone of that depth")),
OPT_BOOL(0, "single-branch", &option_single_branch,
-   N_("clone only one branch, HEAD or --branch")),
+N_("clone only one branch, HEAD or --branch")),
OPT_BOOL(0, "dissociate", &option_dissociate,
 N_("use --reference only while cloning")),
OPT_BOOL(0, "disassociate", &option_dissociate,
-- 
2.3.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 1/2] clone: add disassociate alias to dissociate option

[Matt Whiteley]

Enable clone to accept alternate spelling for dissociate option. Add
alias to documentation following existing recursive/recurse-submodules
convention.

Signed-off-by: Matt Whiteley 
---
 Documentation/git-clone.txt | 3 ++-
 builtin/clone.c | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index f1f2a3f..0b4c1b2 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -12,7 +12,7 @@ SYNOPSIS
 'git clone' [--template=]
  [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
  [-o ] [-b ] [-u ] [--reference ]
- [--dissociate] [--separate-git-dir ]
+ [--dissociate | --disassociate] [--separate-git-dir ]
  [--depth ] [--[no-]single-branch]
  [--recursive | --recurse-submodules] [--] 
  []
@@ -102,6 +102,7 @@ objects from the source repository into a pack in the 
cloned repository.
 `--dissociate` option.
 
 --dissociate::
+--disassociate::
Borrow the objects from reference repositories specified
with the `--reference` options only to reduce network
transfer and stop borrowing from them after a clone is made
diff --git a/builtin/clone.c b/builtin/clone.c
index 316c75d..7e193ae 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -97,6 +97,8 @@ static struct option builtin_clone_options[] = {
N_("clone only one branch, HEAD or --branch")),
OPT_BOOL(0, "dissociate", &option_dissociate,
 N_("use --reference only while cloning")),
+   OPT_BOOL(0, "disassociate", &option_dissociate,
+N_("use --reference only while cloning")),
OPT_STRING(0, "separate-git-dir", &real_git_dir, N_("gitdir"),
   N_("separate git dir from working tree")),
OPT_STRING_LIST('c', "config", &option_config, N_("key=value"),
-- 
2.3.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] --disassociate alias for --dissociate clone option

[Matt Whiteley]

I find the new --dissociate option for clone very helpful but I have a
hard time with the spelling. It seems reasonable to have an alias since
one exists for --recursive.

--
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 mac 10.7.x

[Kyle J. McKay]

On Feb 20, 2015, at 02:38, sojourner wrote:
Installed Git via installer. Updated path in .bash_profile. Get  
error Illegal instruction: 4 when trying to run Git.


Built Git from source. Searches for the compiled source  
unsuccessful. Which is nice: there's nothing to uninstall.


Searching online has a lot of suggestions and ideas. Anybody have  
anything that actually works?--


You can get a working installer from  that should work for you on 10.7.x just fine.


-Kyle
--
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 Scaling: What factors most affect Git performance for a large repo?

[David Turner]

On Thu, 2015-02-19 at 23:57 -0700, Martin Fick wrote:
> On Feb 19, 2015 5:42 PM, David Turner  wrote:
> >
> > On Fri, 2015-02-20 at 06:38 +0700, Duy Nguyen wrote: 
> > > >* 'git push'? 
> > > 
> > > This one is not affected by how deep your repo's history is, or how 
> > > wide your tree is, so should be quick.. 
> > > 
> > > Ah the number of refs may affect both git-push and git-pull. I think 
> > > Stefan knows better than I in this area. 
> >
> > I can tell you that this is a bit of a problem for us at Twitter.  We 
> > have over 100k refs, which adds ~20MiB of downstream traffic to every 
> > push. 
> >
> > I added a hack to improve this locally inside Twitter: The client sends 
> > a bloom filter of shas that it believes that the server knows about; the 
> > server sends only the sha of master and any refs that are not in the 
> > bloom filter.  The client  uses its local version of the servers' refs 
> > as if they had just been sent.  This means that some packs will be 
> > suboptimal, due to false positives in the bloom filter leading some new 
> > refs to not be sent.  Also, if there were a repack between the pull and 
> > the push, some refs might have been deleted on the server; we repack 
> > rarely enough and pull frequently enough that this is hopefully not an 
> > issue. 
> >
> > We're still testing to see if this works.  But due to the number of 
> > assumptions it makes, it's probably not that great an idea for general 
> > use. 
> 
> Good to hear that others are starting to experiment with solutions to this 
> problem!  I hope to hear more updates on this.
> 
> I have a prototype of a simpler, and
> I believe more robust solution, but aimed at a smaller use case I think.  On 
> connecting, the client sends a sha of all its refs/shas as defined by a 
> refspec, which it also sends to the server, which it believes the server 
> might have the same refs/shas values for.  The server can then calculate the 
> value of its refs/shas which meet the same refspec, and then omit sending 
> those refs if the "verification" sha matches, and instead send only a 
> confirmation that they matched (along with any refs outside of the refspec).  
> On a match, the client can inject the local values of the refs which met the 
> refspec and be guaranteed that they match the server's values.
> 
> This optimization is aimed at the worst case scenario (and is thus the 
> potentially best case "compression"), when the client and server match for 
> all refs (a refs/* refspec)  This is something that happens often on Gerrit 
> server startup, when it verifies that its mirrors are up-to-date.  One reason 
> I chose this as a starting optimization, is because I think it is one use 
> case which will actually not benefit from "fixing" the git protocol to only 
> send relevant refs since all the refs are in fact relevant here! So something 
> like this will likely be needed in any future git protocol in order for it to 
> be efficient for this use case.  And I believe this use case is likely to 
> stick around.
> 
> With a minor tweak, this optimization should work when replicating actual 
> expected updates also by excluding the expected updating refs from the 
> verification so that the server always sends their values since they will 
> likely not match and would wreck the optimization.  However, for this use 
> case it is not clear whether it is actually even worth caring about the non 
> updating refs?  In theory the knowledge of the non updating refs can 
> potentially reduce the amount of data transmitted, but I suspect that as the 
> ref count increases, this has diminishing returns and mostly ends up chewing 
> up CPU and memory in a vain attempt to reduce network traffic.

For a more general solution, perhaps a log of ref updates could be used.
Every time a ref is updated on the server, that ref would be written
into an append-only log.  Every time a client pulls, their pull data
includes an index into that log.  Then on push, the client could say, "I
have refs as-of $index", and the server could read the log (or do
something more-optimized) and send only refs updated since that index.


--
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 Scaling: What factors most affect Git performance for a large repo?

[brian m. carlson]

On Fri, Feb 20, 2015 at 11:06:44AM -0500, Stephen Morton wrote:

2. I'd not heard about bitmap indexes before this thread but it sounds
like they should help me. In limited searching I can't find much
useful documentation about them. It is also not clear to me if I have
to explicitly run "git repack --write-bitmap-indexes" or if git will
automatically detect when they're needed; first experiments seem to
indicate that I need to explicitly generate them. I assume that once
the index is there, git will just use it automatically.


Pack bitmaps are a way of speeding up clones and fetches by precomputing 
reachability information.  Practically, this means that the initial 
"Counting objects" phase is instantaneous for clones and much faster for 
fetches.


The way I've done it in the past is to set repack.writeBitmaps = true in 
/etc/gitconfig on the server.  (I highly recommend enabling reflogs in 
the same place.)  Then you'll need to ensure that git gc runs 
periodically so that bitmaps are generated.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: [PATCH v2 1/2] Documentation/config.txt: document mailinfo.scissor

[Eric Sunshine]

On Fri, Feb 20, 2015 at 5:29 AM, Matthieu Moy  wrote:
> Subject: Documentation/config.txt: document mailinfo.scissor
>
> The variable was documented in git-mailinfo.txt, but not in config.txt.
> The detailed documentation is still the one of --scissors in
> git-mailinfo.txt, but we give enough information here to let the user
> understand what it is about, and to make it easy to find it (e.g.
> searching ">8" and "8<" finds it).
>
> Signed-off-by: Matthieu Moy 
> ---
> Changes since v1 for both patches : typos noted by Peff.

The same typo (s/scissor/scissors/) exists in the subjects.

>  Documentation/config.txt | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index ae6791d..15f8695 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1740,6 +1740,13 @@ log.mailmap::
> If true, makes linkgit:git-log[1], linkgit:git-show[1], and
> linkgit:git-whatchanged[1] assume `--use-mailmap`.
>
> +mailinfo.scissors::
> +   If true, makes linkgit:git-mailinfo[1] (and therefore
> +   linkgit:git-am[1]) act by default as if the --scissors option
> +   was provided on the command-line. When active, this features
> +   removes everything from the message body before a scissors
> +   line (i.e. consisting mainly of ">8", "8<" and "-").
> +
>  mailmap.file::
> The location of an augmenting mailmap file. The default
> mailmap, located in the root of the repository, is loaded
> --
> 2.3.0.157.g79e124b
--
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 Scaling: What factors most affect Git performance for a large repo?

[Matthieu Moy]

Stephen Morton  writes:

> 1. Ævar : I'm a bit concerned by your statement that git rebases take
> about 1-2 s per commit. Does that mean that a "git pull --rebase", if
> it is picking up say 120 commits (not at all unrealistic), could
> potentially take 4 minutes to complete? Or have I misinterpreted your
> comment.

Ævar talked about "applied commits" during rebase. When you "git pull
--rebase", you fast-forward the history you just fetched, which is
almost instantaneous, and then you reapply your local history on top of
it.

So, the performance depends on how long your local history is, not on
how many commits you're fetching.

-- 
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: git mac 10.7.x

[Matthew Brett]

Hi,

On Fri, Feb 20, 2015 at 2:38 AM, sojourner  wrote:
> Installed Git via installer. Updated path in .bash_profile. Get error Illegal 
> instruction: 4 when trying to run Git.

I've seen the installer problem - suggestions here:
http://practical-neuroimaging.github.io/installation.html#if-you-are-on-osx-10-8-mountain-lion-or-below

> Built Git from source. Searches for the compiled source unsuccessful. Which 
> is nice: there's nothing to uninstall.

I'm not sure what happened there :)

Best,

Matthew
--
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 Scaling: What factors most affect Git performance for a large repo?

[Stephen Morton]

This is fantastic. I really appreciate all the answers. And it's great
that I think I've sparked some general discussion that could lead
somewhere too.

Notes:

I'm currently using 2.1.3. I'll move to 2.3.x

I'm experimenting with git-annex to reduce repo size on disk. We'll see.

I could remove all tags older than /n/ years old in the active repo
and just maintain them in the historical repo. (We have quite a lot of
CI-generated tags.) It sounds like that might improve performance.

Questions:

1. Ævar : I'm a bit concerned by your statement that git rebases take
about 1-2 s per commit. Does that mean that a "git pull --rebase", if
it is picking up say 120 commits (not at all unrealistic), could
potentially take 4 minutes to complete? Or have I misinterpreted your
comment.

2. I'd not heard about bitmap indexes before this thread but it sounds
like they should help me. In limited searching I can't find much
useful documentation about them. It is also not clear to me if I have
to explicitly run "git repack --write-bitmap-indexes" or if git will
automatically detect when they're needed; first experiments seem to
indicate that I need to explicitly generate them. I assume that once
the index is there, git will just use it automatically.


Steve


On Thu, Feb 19, 2015 at 7:03 PM, brian m. carlson
 wrote:
> On Thu, Feb 19, 2015 at 04:26:58PM -0500, Stephen Morton wrote:
>> I posted this to comp.version-control.git.user and didn't get any response. I
>> think the question is plumbing-related enough that I can ask it here.
>>
>> I'm evaluating the feasibility of moving my team from SVN to git. We have a 
>> very
>> large repo. [1] We will have a central repo using GitLab (or similar) that
>> everybody works with. Forks, code sharing, pull requests etc. will be done
>> through this central server.
>>
>> By 'performance', I guess I mean speed of day to day operations for devs.
>>
>>* (Obviously, trivially, a (non-local) clone will be slow with a large 
>> repo.)
>>* Will a few simultaneous clones from the central server also slow down
>>  other concurrent operations for other users?
>
> This hasn't been a problem for us at $DAYJOB.  Git doesn't lock anything
> on fetches, so each process is independent.  We probably have about
> sixty developers (and maybe twenty other occasional users) that manage
> to interact with our Git server all day long.  We also have probably
> twenty smoker (CI) systems pulling at two hour intervals, or, when
> there's nothing to do, every two minutes, plus probably fifteen to
> twenty build systems pulling hourly.
>
> I assume you will provide adequate resources for your server.
>
>>* Will 'git pull' be slow?
>>* 'git push'?
>
> The most pathological case I've seen for git push is a branch with a
> single commit merged into the main development branch.  As of Git 2.3.0,
> the performance regression here is fixed.
>
> Obviously, the speed of your network connection will affect this.  Even
> at 30 MB/s, cloning several gigabytes of data takes time.  Git tries
> hard to eliminate sending a lot of data, so if your developers keep
> reasonably up-to-date, the cost of establishing the connection will tend
> to dominate.
>
> I see pull and push times that are less than 2 seconds in most cases.
>
>>* 'git commit'? (It is listed as slow in reference [3].)
>>* 'git stautus'? (Slow again in reference 3 though I don't see it.)
>
> These can be slow with slow disks or over remote file systems.  I
> recommend not doing that.  I've heard rumbles that disk performance is
> better on Unix, but I don't use Windows so I can't say.
>
> You should keep your .gitignore files up-to-date to avoid enumerating
> untracked files.  There's some work towards making this less of an
> issue.
>
> git blame can be somewhat slow, but it's not something I use more than
> about once a day, so it doesn't bother me that much.
>
>> Assuming I can put lots of resources into a central server with lots of CPU,
>> RAM, fast SSD, fast networking, what aspects of the repo are most likely to
>> affect devs' experience?
>>* Number of commits
>>* Sheer disk space occupied by the repo
>
> The number of files can impact performance due to the number of stat()s
> required.
>
>>* Number of tags.
>>* Number of branches.
>
> The number of tags and branches individually is really less relevant
> than the total number of refs (tags, branches, remote branches, etc).
> Very large numbers of refs can impact performance on pushes and pulls
> due to the need to enumerate them all.
>
>>* Binary objects in the repo that cause it to bloat in size [1]
>>* Other factors?
>
> If you want good performance, I'd recommend the latest version of Git
> both client- and server-side.  Newer versions of Git provide pack
> bitmaps, which can dramatically speed up clones and fetches, and Git
> 2.3.0 fixes a performance regression with large numbers of refs in
> non-shallow repositories.
>
> It is totally worth it

Gitweb error: XML Parsing Error: not well-formed

[Juan J. Martinez]

Hi,

I'm experiencing a problem with gitweb and some utf-8 bits like £ (the
pound sign) when showing diffs.

Example (Firefox's output):

XML Parsing Error: not well-formed Location:
https://hostname/gitweb?p=redacted.git;a=commitdiff;h=16ae27d6b030949772b298c6e2935a09c48169a7
Line Number 913, Column 492:@@ -1043,7
+1044,7
@@ outstanding amount is �10.00.

That should be "£10.00".

This is with latest gitweb  code
(sha:f3f407747c1cce420ae4b4857c4a6806efe38680) and perl v5.10.1.

The problem seems to be in gitweb.perl around line 1543.

Looks like utf8::is_utf8 returns false, and the conversion "in place"
with utf8::decode doesn't seem to work (although it returns success,
Firefox doesn't like it).

As a workaround I removed the "|| utf8::decode($str)" on the condition
and the error is gone, although I'm not sure about the consequences of
doing that (I guess it returns part of the content in the fallback
encoding; latin1 in this case).

Regards,

Juan

-- 
Juan J. Martinez
Development Manager, MEMSET

mail: j...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey GU6 8TB, UK.
--
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 Scaling: What factors most affect Git performance for a large repo?

[Ævar Arnfjörð Bjarmason]

On Fri, Feb 20, 2015 at 1:09 PM, Ævar Arnfjörð Bjarmason
 wrote:
> On Fri, Feb 20, 2015 at 1:04 AM, Duy Nguyen  wrote:
>> On Fri, Feb 20, 2015 at 6:29 AM, Ævar Arnfjörð Bjarmason
>>  wrote:
>>> Anecdotally I work on a repo at work (where I'm mostly "the Git guy") 
>>> that's:
>>>
>>>  * Around 500k commits
>>>  * Around 100k tags
>>>  * Around 5k branches
>>>  * Around 500 commits/day, almost entirely to the same branch
>>>  * 1.5 GB .git checkout.
>>>  * Mostly text source, but some binaries (we're trying to cut down[1] on 
>>> those)
>>
>> Would be nice if you could make an anonymized version of this repo
>> public. Working on a "real" large repo is better than an artificial
>> one.
>
> Yeah, I'll try to do that.

tl;dr: After some more testing it turns out the performance issues we
have are almost entirely due to the number of refs. Some of these I
knew about and were obvious (e..g. git pull), but some aren't so
obvious (why does "git log" without "--all" slow down as a function of
the overall number of refs?).

Rather than getting an anonymized version of the repo we have, a
simpler isolated test case is just doing this on linux.git:

$ git rev-list --all | perl -ne 'my $cnt; while (<>) {
s<([a-f0-9]+)>gm; next unless int rand 10
== 1; $cnt++; s/TAG/tagnr-$cnt/; print }'  | sh -x

That'll create a tag for every 10th commit or so, which is around 50k
tags for linux.git.

I actually ran this a few times while testing it, so this is a before
and after on a hot cache of linux.git with 406 tags v.s. ~140k. I ran
the gc + repack + bitmaps for both repos noted in an earlier reply of
mine, and took the fastest run out of 3:

$ time (git log master -100 >/dev/null)
Before: real0m0.021s
After: real0m2.929s
$ time (git status >/dev/null)
# Around 150ms, no noticeable difference
$ time git fetch
# I'm fetching from g...@github.com:torvalds/linux.git here, the
# cache is hot but upstream has *no* changes
Before: real0m1.826s
After: real0m8.458s

Details on why "git fetch" is slow in this situation:

$ time GIT_TRACE=1 git fetch
15:15:00.435420 git.c:349   trace: built-in: git 'fetch'
15:15:00.654428 run-command.c:341   trace: run_command: 'ssh'
'g...@github.com' 'git-upload-pack '\''torvalds/linux.git'\'''
15:15:02.426121 run-command.c:341   trace: run_command:
'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
15:15:05.507327 run-command.c:341   trace: run_command:
'rev-list' '--objects' '--stdin' '--not' '--all'
15:15:05.508329 exec_cmd.c:134  trace: exec: 'git'
'rev-list' '--objects' '--stdin' '--not' '--all'
15:15:05.510490 git.c:349   trace: built-in: git
'rev-list' '--objects' '--stdin' '--not' '--all'
15:15:08.874116 run-command.c:341   trace: run_command: 'gc' '--auto'
15:15:08.879570 exec_cmd.c:134  trace: exec: 'git' 'gc' '--auto'
15:15:08.882495 git.c:349   trace: built-in: git 'gc' '--auto'
real0m8.458s
user0m6.548s
sys 0m0.204s

Even things you'd expect to not be impacted are, like a reverse log
search on the master branch:

$ time (git log --reverse -p --grep=arm64 origin/master >/dev/null)
Before: real0m4.473s
After: real0m6.194s

Or doing 10 commits and rebasing on the upstream:

$ time (git checkout origin/master~ && for i in {1..10}; do echo
$i > file && git add file && git commit -m"moo" $file; done && git
rebase origin/master)
Before: real0m6.798s
After: real0m12.340s

The remaining slowdown comes from the size of the tree, which we can
deal with by either reducing it in size (we have some copied JS
libraries and whatnot) or trying the inotify-powered git-status.

In our case there's no good reason for why we have this many refs in
the repository everyone uses. We basically just have a bunch of dated
rollout tags that have been accumulating for years, and a bunch of
mostly unused branches people just haven't cleaned up.

So I'm going to:

 1. Write a hook that rejects tags that aren't new (i.e. forbid
re-pushes of old tags)
 2. Create an archive repository that contains all the old tags (i.e.
just run "git fetch" on the main one from cron)
 3. Run a script to regularly delete tags from the main repo
 4. Run the same script on the clients that clone the repo

The branches are slightly harder, deleting those that are fully merged
into the same branch is easy, deleting those whose contents 100%
matches patch-id's already in the main branch is another thing we can
do, and just clean up branches unconditionally after they've reached a
certain age (they'll still be archived).
--
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: [ANNOUNCE] Git Merge, April 8-9, Paris

[Matthieu Moy]

Yi EungJun  writes:

> I heard Git Contributors Summit is scheduled on April 8th at Git Merge 2015.
>
> Does anyone know the agenda of the summit? I am considering to attend the
> summit.

It's all online now:

  http://git-merge.com/

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

Question on shallow clones.

[Alfred Perlstein]

Hello,

Very sorry if this has been explained before, I have been doing research past 
few weeks in spare time and have not found a good answer yet on the safety of 
doing something with git.

Basically we have some repos with huge history, namely FreeBSD source and 
FreeBSD ports.  In order to reduce the space in $repo/.git as well as speed up 
clone time we were thinking of doing a shallow clone of the repo with something 
like --depth 5000.

I am wondering, if we such a thing, basically:

# get a shallow mirror of let's say 5000 entries
git clone --depth 5000 --mirror our-freebsd.git  smaller-freebsd.git
# move our current repo to a backup
mv our-freebsd.git our-freebsd.git.backup
# make shallow repo our primary
mv smaller-freebsd.git our-freebsd.git

Will we be able to push/pull from our "new" repo as if nothing happened?  Will 
hashes remain the same?

Can we in theory later do this:

# merge branches from the "github" remote and push back to "our-freebsd.git"
git clone /url/our-freebsd.git  our-freebsd.git
cd our-freebsd.git
git remote add github https://github.com/freebsd/freebsd.git
git fetch github
# get from our-freebsd
git checkout -b master origin/master
# now merge in freebsd changes
git merge --no-ff github/master
git push origin HEAD

Or will this break terribly?

Thank you very much.

-Alfred



--
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: [ANNOUNCE] Git Merge, April 8-9, Paris

[Yi EungJun]

I heard Git Contributors Summit is scheduled on April 8th at Git Merge 2015.

Does anyone know the agenda of the summit? I am considering to attend the
summit.



--
View this message in context: 
http://git.661346.n2.nabble.com/ANNOUNCE-Git-Merge-April-8-9-Paris-tp7624561p7625750.html
Sent from the git mailing list archive at Nabble.com.
--
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

vcs chuckles

[Michael J Gruber]

[just for chuckles, no flames please]

$ hg branch topic
Arbeitsverzeichnis wurde als Zweig topic markiert
(branches are permanent and global, did you want a bookmark?)

I have no idea since when hg cautions against using their version of
branches (embedded into the commits), but that line made me smile -
because it reminds me of one of the reasons why I switched to git rather
than hg back then (despite my exposure to python).

Also, it's comforting to see that we can compete on the l10n front...
good to be here :)

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: Git Scaling: What factors most affect Git performance for a large repo?

[Ævar Arnfjörð Bjarmason]

On Fri, Feb 20, 2015 at 1:09 PM, Ævar Arnfjörð Bjarmason
 wrote:
> On Fri, Feb 20, 2015 at 1:04 AM, Duy Nguyen  wrote:
>> On Fri, Feb 20, 2015 at 6:29 AM, Ævar Arnfjörð Bjarmason
>>  wrote:
>>> Anecdotally I work on a repo at work (where I'm mostly "the Git guy") 
>>> that's:
>>>
>>>  * Around 500k commits
>>>  * Around 100k tags
>>>  * Around 5k branches
>>>  * Around 500 commits/day, almost entirely to the same branch
>>>  * 1.5 GB .git checkout.
>>>  * Mostly text source, but some binaries (we're trying to cut down[1] on 
>>> those)
>>
>> Would be nice if you could make an anonymized version of this repo
>> public. Working on a "real" large repo is better than an artificial
>> one.
>
> Yeah, I'll try to do that.
>
>>> But actually most of "git fetch" is spent in the reachability check
>>> subsequently done by "git-rev-list" which takes several seconds. I
>>
>> I wonder if reachability bitmap could help here..
>
> I could have sworn I had that enabled already but evidently not. I did
> test it and it cut down on clone times a bit. Now our daily repacking
> is:
>
> git --git-dir={} gc &&
> git --git-dir={} pack-refs --all --prune &&
> git --git-dir={} repack -Ad --window=250 --depth=100
> --write-bitmap-index --pack-kept-objects &&
>
> It's not clear to me from the documentation whether this should just
> be enabled on the server, or the clients too. In any case I've enabled
> it on both.
>
> Even then with it enabled on both a "git pull" that pulls down just
> one commit on one branch is 13s. Trace attached at the end of the
> mail.
>
>>> haven't looked into it but there's got to be room for optimization
>>> there, surely it only has to do reachability checks for new refs, or
>>> could run in some "I trust this remote not to send me corrupt data"
>>> completely mode (which would make sense within a company where you can
>>> trust your main Git box).
>>
>> No, it's not just about trusting the server side, it's about catching
>> data corruption on the wire as well. We have a trick to avoid
>> reachability check in clone case, which is much more expensive than a
>> fetch. Maybe we could do something further to help the fetch case _if_
>> reachability bitmaps don't help.
>
> Still, if that's indeed a big bottleneck what's the worst-case
> scenario here? That the local repository gets hosed? The server will
> still recursively validate the objects it gets sent, right?
>
> I wonder if a better trade-off in that case would be to skip this in
> some situations and instead put something like "git fsck" in a
> cronjob.
>
> Here's a "git pull" trace mentioned above:
>
> $ time GIT_TRACE=1 git pull
> 13:06:13.603781 git.c:555   trace: exec: 'git-pull'
> 13:06:13.603936 run-command.c:351   trace: run_command: 'git-pull'
> 13:06:13.620615 git.c:349   trace: built-in: git
> 'rev-parse' '--git-dir'
> 13:06:13.631602 git.c:349   trace: built-in: git
> 'rev-parse' '--is-bare-repository'
> 13:06:13.636103 git.c:349   trace: built-in: git
> 'rev-parse' '--show-toplevel'
> 13:06:13.641491 git.c:349   trace: built-in: git 'ls-files' '-u'
> 13:06:13.719923 git.c:349   trace: built-in: git
> 'symbolic-ref' '-q' 'HEAD'
> 13:06:13.728085 git.c:349   trace: built-in: git 'config'
> 'branch.trunk.rebase'
> 13:06:13.738160 git.c:349   trace: built-in: git 'config' 
> 'pull.ff'
> 13:06:13.743286 git.c:349   trace: built-in: git
> 'rev-parse' '-q' '--verify' 'HEAD'
> 13:06:13.972091 git.c:349   trace: built-in: git
> 'rev-parse' '--verify' 'HEAD'
> 13:06:14.149420 git.c:349   trace: built-in: git
> 'update-index' '-q' '--ignore-submodules' '--refresh'
> 13:06:14.294098 git.c:349   trace: built-in: git
> 'diff-files' '--quiet' '--ignore-submodules'
> 13:06:14.467711 git.c:349   trace: built-in: git
> 'diff-index' '--cached' '--quiet' '--ignore-submodules' 'HEAD' '--'
> 13:06:14.683419 git.c:349   trace: built-in: git
> 'rev-parse' '-q' '--git-dir'
> 13:06:15.189707 git.c:349   trace: built-in: git
> 'rev-parse' '-q' '--verify' 'HEAD'
> 13:06:15.335948 git.c:349   trace: built-in: git 'fetch'
> '--update-head-ok'
> 13:06:15.691303 run-command.c:351   trace: run_command: 'ssh'
> 'git.example.com' 'git-upload-pack '\''/gitrepos/core.git'\'''
> 13:06:17.095662 run-command.c:351   trace: run_command: 'rev-list'
> '--objects' '--stdin' '--not' '--all' '--quiet'
> remote: Counting objects: 6, done.
> remote: Compressing objects: 100% (6/6), done.
> 3:06:20.426346 run-command.c:351   trace: run_command:
> 'unpack-objects' '--pack_header=2,6'
> 13:06:20.431806 exec_cmd.c:130  trace: exec: 'git'
> 'unpack-objects' '--pack_header=2,6'
> 13:06:20.437343 git.c:349   trace: built-in: git
> 'unpack-objects' '--pack_header=2,6'
> remote: Total 6 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (6/

Re: Git Scaling: What factors most affect Git performance for a large repo?

[Ævar Arnfjörð Bjarmason]

On Fri, Feb 20, 2015 at 1:04 AM, Duy Nguyen  wrote:
> On Fri, Feb 20, 2015 at 6:29 AM, Ævar Arnfjörð Bjarmason
>  wrote:
>> Anecdotally I work on a repo at work (where I'm mostly "the Git guy") that's:
>>
>>  * Around 500k commits
>>  * Around 100k tags
>>  * Around 5k branches
>>  * Around 500 commits/day, almost entirely to the same branch
>>  * 1.5 GB .git checkout.
>>  * Mostly text source, but some binaries (we're trying to cut down[1] on 
>> those)
>
> Would be nice if you could make an anonymized version of this repo
> public. Working on a "real" large repo is better than an artificial
> one.

Yeah, I'll try to do that.

>> But actually most of "git fetch" is spent in the reachability check
>> subsequently done by "git-rev-list" which takes several seconds. I
>
> I wonder if reachability bitmap could help here..

I could have sworn I had that enabled already but evidently not. I did
test it and it cut down on clone times a bit. Now our daily repacking
is:

git --git-dir={} gc &&
git --git-dir={} pack-refs --all --prune &&
git --git-dir={} repack -Ad --window=250 --depth=100
--write-bitmap-index --pack-kept-objects &&

It's not clear to me from the documentation whether this should just
be enabled on the server, or the clients too. In any case I've enabled
it on both.

Even then with it enabled on both a "git pull" that pulls down just
one commit on one branch is 13s. Trace attached at the end of the
mail.

>> haven't looked into it but there's got to be room for optimization
>> there, surely it only has to do reachability checks for new refs, or
>> could run in some "I trust this remote not to send me corrupt data"
>> completely mode (which would make sense within a company where you can
>> trust your main Git box).
>
> No, it's not just about trusting the server side, it's about catching
> data corruption on the wire as well. We have a trick to avoid
> reachability check in clone case, which is much more expensive than a
> fetch. Maybe we could do something further to help the fetch case _if_
> reachability bitmaps don't help.

Still, if that's indeed a big bottleneck what's the worst-case
scenario here? That the local repository gets hosed? The server will
still recursively validate the objects it gets sent, right?

I wonder if a better trade-off in that case would be to skip this in
some situations and instead put something like "git fsck" in a
cronjob.

Here's a "git pull" trace mentioned above:

$ time GIT_TRACE=1 git pull
13:06:13.603781 git.c:555   trace: exec: 'git-pull'
13:06:13.603936 run-command.c:351   trace: run_command: 'git-pull'
13:06:13.620615 git.c:349   trace: built-in: git
'rev-parse' '--git-dir'
13:06:13.631602 git.c:349   trace: built-in: git
'rev-parse' '--is-bare-repository'
13:06:13.636103 git.c:349   trace: built-in: git
'rev-parse' '--show-toplevel'
13:06:13.641491 git.c:349   trace: built-in: git 'ls-files' '-u'
13:06:13.719923 git.c:349   trace: built-in: git
'symbolic-ref' '-q' 'HEAD'
13:06:13.728085 git.c:349   trace: built-in: git 'config'
'branch.trunk.rebase'
13:06:13.738160 git.c:349   trace: built-in: git 'config' 'pull.ff'
13:06:13.743286 git.c:349   trace: built-in: git
'rev-parse' '-q' '--verify' 'HEAD'
13:06:13.972091 git.c:349   trace: built-in: git
'rev-parse' '--verify' 'HEAD'
13:06:14.149420 git.c:349   trace: built-in: git
'update-index' '-q' '--ignore-submodules' '--refresh'
13:06:14.294098 git.c:349   trace: built-in: git
'diff-files' '--quiet' '--ignore-submodules'
13:06:14.467711 git.c:349   trace: built-in: git
'diff-index' '--cached' '--quiet' '--ignore-submodules' 'HEAD' '--'
13:06:14.683419 git.c:349   trace: built-in: git
'rev-parse' '-q' '--git-dir'
13:06:15.189707 git.c:349   trace: built-in: git
'rev-parse' '-q' '--verify' 'HEAD'
13:06:15.335948 git.c:349   trace: built-in: git 'fetch'
'--update-head-ok'
13:06:15.691303 run-command.c:351   trace: run_command: 'ssh'
'git.example.com' 'git-upload-pack '\''/gitrepos/core.git'\'''
13:06:17.095662 run-command.c:351   trace: run_command: 'rev-list'
'--objects' '--stdin' '--not' '--all' '--quiet'
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (6/6), done.
3:06:20.426346 run-command.c:351   trace: run_command:
'unpack-objects' '--pack_header=2,6'
13:06:20.431806 exec_cmd.c:130  trace: exec: 'git'
'unpack-objects' '--pack_header=2,6'
13:06:20.437343 git.c:349   trace: built-in: git
'unpack-objects' '--pack_header=2,6'
remote: Total 6 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
13:06:20.444196 run-command.c:351   trace: run_command: 'rev-list'
'--objects' '--stdin' '--not' '--all'
13:06:20.447135 exec_cmd.c:130  trace: exec: 'git' 'rev-list'
'--objects' '--stdin' '--not' '--all'
13:06:20.451283 git.c

Re: Interested in helping open source friends on HP-UX?

[H.Merijn Brand]

On Fri, 20 Feb 2015 05:49:21 -0500, Jeff King  wrote:

> On Fri, Feb 20, 2015 at 11:36:27AM +0100, Michael J Gruber wrote:
> 
> > > It's not quite so bad as you make out. We write the value to the
> > > GIT-BUILD-OPTIONS file during "make", no matter where it comes from, and
> > > load that in test-lib.sh. So:
> > > 
> > >   make NO_ICONV=Nope
> > >   cd t
> > >   ./t3901-i18n-patch.sh
> > > 
> > > works just fine (for this and for any of the other options we mark
> > > there).
> > 
> > It survives a cd, sure...
> 
> I think the interesting thing is that it survives running `./t`
> rather than running the test through make.

I always use prove

$ prove -v t1234.sh

> > Now, change your config.mak before the cd and
> > forget the make. Not everyone does
> > 
> > make -C t t3901-i18n-patch.sh
> > 
> > Though, having just discovered that shell completion works for that
> > form, too, I may do it more often (and then complain about having to use
> > GIT_TEST_OPTS ;) )
> 
> Yeah, I never use "make t" myself. But nor would I expect the tests
> to respect a version of git I had not actually built. E.g., if you build
> with NO_PERL, and then remove NO_PERL from your config.mak but do _not_
> actually run "make", should that work? Ditto for NO_ICONV, for that
> matter. The tests must match the binary, and the best guess we have
> about the binary is the last thing we built.
> 
> Adding "git --build-options" would give us a better guess (it may not be
> what the user _wanted_ to test, but it is what they _are_ testing).
> 
> > > I suspect GIT_TEST_INSTALLED is not all that widely used, or somebody
> > > would have complained before. But if we really want to support it, I
> > > think the right thing is to bake GIT-BUILD-OPTIONS into the binary, so
> > > that "git --build-options" dumps it. It might also have value for
> > > debugging and forensics in general.
> > 
> > Yep, that would be helpful in general. I don't think we should worry
> > about GIT_TEST_INSTALLED too much. Who came up with that feature anyway...?
> 
> Clearly a crazy person. :) I am not saying it is a _bad_ idea. Only that
> the responsibility to make sure the installed version matches the
> current build parameters lies with the user (and for that matter, the
> current set of tests; we add new tests that would fail on old versions,
> and you cannot mix and match).
> 
> So an alternate explanation than "not widely used" is "all of the users
> of it are responsible individuals who do not make bogus bug reports to
> the list". :)
> 
> -Peff


-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/


pgpKiZndwpjvB.pgp
Description: OpenPGP digital signature

Re: Interested in helping open source friends on HP-UX?

[Jeff King]

On Fri, Feb 20, 2015 at 11:36:27AM +0100, Michael J Gruber wrote:

> > It's not quite so bad as you make out. We write the value to the
> > GIT-BUILD-OPTIONS file during "make", no matter where it comes from, and
> > load that in test-lib.sh. So:
> > 
> >   make NO_ICONV=Nope
> >   cd t
> >   ./t3901-i18n-patch.sh
> > 
> > works just fine (for this and for any of the other options we mark
> > there).
> 
> It survives a cd, sure...

I think the interesting thing is that it survives running `./t`
rather than running the test through make.

> Now, change your config.mak before the cd and
> forget the make. Not everyone does
> 
> make -C t t3901-i18n-patch.sh
> 
> Though, having just discovered that shell completion works for that
> form, too, I may do it more often (and then complain about having to use
> GIT_TEST_OPTS ;) )

Yeah, I never use "make t" myself. But nor would I expect the tests
to respect a version of git I had not actually built. E.g., if you build
with NO_PERL, and then remove NO_PERL from your config.mak but do _not_
actually run "make", should that work? Ditto for NO_ICONV, for that
matter. The tests must match the binary, and the best guess we have
about the binary is the last thing we built.

Adding "git --build-options" would give us a better guess (it may not be
what the user _wanted_ to test, but it is what they _are_ testing).

> > I suspect GIT_TEST_INSTALLED is not all that widely used, or somebody
> > would have complained before. But if we really want to support it, I
> > think the right thing is to bake GIT-BUILD-OPTIONS into the binary, so
> > that "git --build-options" dumps it. It might also have value for
> > debugging and forensics in general.
> 
> Yep, that would be helpful in general. I don't think we should worry
> about GIT_TEST_INSTALLED too much. Who came up with that feature anyway...?

Clearly a crazy person. :) I am not saying it is a _bad_ idea. Only that
the responsibility to make sure the installed version matches the
current build parameters lies with the user (and for that matter, the
current set of tests; we add new tests that would fail on old versions,
and you cannot mix and match).

So an alternate explanation than "not widely used" is "all of the users
of it are responsible individuals who do not make bogus bug reports to
the list". :)

-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: odb_mkstemp's 0444 permission broke write/delete access on AFP

[Matthieu Moy]

"brian m. carlson"  writes:

> On Tue, Feb 17, 2015 at 09:51:38AM +0100, Matthieu Moy wrote:
>> This should be fixable from Git itself, by replacing the calls to
>> "unlink" with something like
>> 
>> int unlink_or_chmod(...) {
>>  if (unlink(...)) {
>>  chmod(...); // give user write permission
>>  return unlink(...);
>>  }
>> }
>> 
>> This does not add extra cost in the normal case, and would fix this
>> particular issue for afp shares. So, I think that would fix the biggest
>> problem for afp-share users without disturbing others. It seems
>> reasonable to me to do that unconditionnally.
>
> This can have security issues if you're trying to unlink a symlink, as 
> chmod will dereference the symlink but unlink will not.  Giving the file 
> owner write permission may not be sufficient, as the user may be a 
> member of a group with write access to the repo.  A malicious user who 
> also has access to the repo could force the current user to chmod an 
> arbitrary file such that it had looser permissions.

Ouch, indeed. I don't think that would be so problematic in practice (if
the attacker has access to the repo, it's easier to write arbitrary code
in hooks or config), but clearly we don't want to take the risk.

So, the right solution should be stg like Junio's

 * in init-db.c, autoprobe by doing something like this:

create a test file with 0444 permission bits;
if (unlink(that test file)) {
chmod(that test file, 0644);
if (!unlink(that test file)) {
broken_unlink = 1;
git_config_set("core.brokenunlink", broken_unlink);
} else {
die("aaargh");
}
}

But when core.brokenunlink is set, just use 0666 instead of 0444 as
default mode for object files.

But right now, I'm not sure we're actually to work around an issue with
AFP shares or only one particular case of problematic configurtion for
one user.

-- 
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 mac 10.7.x

[sojourner]

Installed Git via installer. Updated path in .bash_profile. Get error Illegal 
instruction: 4 when trying to run Git.

Built Git from source. Searches for the compiled source unsuccessful. Which is 
nice: there's nothing to uninstall. 

Searching online has a lot of suggestions and ideas. Anybody have anything that 
actually works?--
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: Interested in helping open source friends on HP-UX?

[Michael J Gruber]

Jeff King venit, vidit, dixit 20.02.2015 02:48:
> On Thu, Feb 19, 2015 at 02:21:11PM +0100, Michael J Gruber wrote:
> 
>>> It passes NO_ICONV through to the test suite, sets up a prerequisite,
>>> disables some test scripts which are purely about i18n (e.g.,
>>> t3900-i18n-commit), and marks some of the scripts with one-off tests
>>> using the ICONV prereq.
>>
>> Hmm. I know we pass other stuff down, but is this really a good idea? It
>> relies on the fact that the git that we test was built with the options
>> from there. This assumptions breaks (with) GIT_TEST_INSTALLED, if not more.
>>
>> Basically, it may break as soon as we run the tests by other means than
>> "make", which is quite customary if you run single tests.
>>
>> (And we do pass config.mak down, me thinks, but NO_ICONV may come from
>> the command line.)
> 
> It's not quite so bad as you make out. We write the value to the
> GIT-BUILD-OPTIONS file during "make", no matter where it comes from, and
> load that in test-lib.sh. So:
> 
>   make NO_ICONV=Nope
>   cd t
>   ./t3901-i18n-patch.sh
> 
> works just fine (for this and for any of the other options we mark
> there).

It survives a cd, sure... Now, change your config.mak before the cd and
forget the make. Not everyone does

make -C t t3901-i18n-patch.sh

Though, having just discovered that shell completion works for that
form, too, I may do it more often (and then complain about having to use
GIT_TEST_OPTS ;) )

> It won't work for GIT_TEST_INSTALLED, but that is not a new problem.
> Fundamentally you cannot expect to test a version built without option X
> without telling git _somehow_ that it was built that way.
> 
> I suspect GIT_TEST_INSTALLED is not all that widely used, or somebody
> would have complained before. But if we really want to support it, I
> think the right thing is to bake GIT-BUILD-OPTIONS into the binary, so
> that "git --build-options" dumps it. It might also have value for
> debugging and forensics in general.

Yep, that would be helpful in general. I don't think we should worry
about GIT_TEST_INSTALLED too much. Who came up with that feature anyway...?

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: [RFH] GSoC 2015 application

[Matthieu Moy]

Dennis Kaarsemaker  writes:

> given a config file name tells
> you where it should be, maybe in the resident kitchen-sink that is
> rev-parse:

It's actually a bit harder than this, since when both XDG and ~/.
exist, we read from both but write to one only. So there's not just one
answer to the question.

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

[PATCH 1/3] microprojects: tweaks after discussion with Peff

[Matthieu Moy]

Signed-off-by: Matthieu Moy 
---
 SoC-2015-Microprojects.md | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md
index e49cb07..c6123bb 100644
--- a/SoC-2015-Microprojects.md
+++ b/SoC-2015-Microprojects.md
@@ -158,14 +158,16 @@ approach is:
 
 * Update the documentation
 
+Even though the amount of code to write is small, these projects
+involve a lot of prior work to understand the specification and deal
+with all potential corner-cases.
+
 ### Add configuration options for some commonly used command-line options
 
 This includes:
 
 * git am -3
 
-* git am -c
-
 Some people always run the command with these options, and would
 prefer to be able to activate them by default in ~/.gitconfig.
 
@@ -177,3 +179,5 @@ the way to find the function name is built-in Git's source 
code as
 regular expressions (see userdiff.c). A few languages are common
 enough to deserve a built-in driver, but are not yet recognized. For
 example, CSS, shell.
+
+This project requires a very good knowledge of regular expressions.
-- 
2.3.0.157.g79e124b

--
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 2/3] GSoC ideas: git bisect fixed/unfixed

[Matthieu Moy]

Signed-off-by: Matthieu Moy 
---
 SoC-2015-Ideas.md | 45 -
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md
index a3e988e..4641800 100644
--- a/SoC-2015-Ideas.md
+++ b/SoC-2015-Ideas.md
@@ -34,7 +34,9 @@ should be honored without checking the ownership.  Cf. 
$gmane/243628
 Takes eol attributes into account to correct lossage/addition of CR at
 the end of line, with updates to "am".  Cf. $gmane/257445
 
-### "git bisect --first-parent".
+### git bisect improvements
+
+ "git bisect --first-parent".
 
 When your project is strictly "new features are merged into trunk,
 never the other way around", it is handy to be able to first find
@@ -42,6 +44,47 @@ a merge on the trunk that merged a topic to point fingers at 
when
 a bug appears, instead of having to drill down to the individual
 commit on the faulty side branch.
 
+ "git bisect fixed/unfixed"
+
+"git bisect" is initially meant to find regressions (i.e. the new code
+is bad, and the old one used to work). The opposite may happen too:
+look for the commit which fixed a bug. It is already possible using
+"git bisect", but the user has to type "good" to mean "the bug is
+there" and "bad" to mean "the bug is fixed", which isn't convenient.
+
+It would be nice to allow the user to explicitely say "git bisect
+fixed" and "git bisect unfixed" instead. It is actually much harder
+than defining "fixed"/"unfixed" as aliases for "bad"/"good".
+
+A patch for this feature was sent to the mailing list in this thread a
+few years ago by Dscho:
+http://thread.gmane.org/gmane.comp.version-control.git/86063
+
+Unfortunately there were some problems with the patch and no one tried
+to fix them. So the same problem/suggestion is often reported on the
+mailing list, for example:
+
+http://thread.gmane.org/gmane.comp.version-control.git/165141
+http://thread.gmane.org/gmane.comp.version-control.git/170113
+http://thread.gmane.org/gmane.comp.version-control.git/182398 
+
+A patch series to let "old/new" be used instead of "good/bad" was
+started here:
+
+http://thread.gmane.org/gmane.comp.version-control.git/199758/focus=199869
+
+There is still work to be done to complete it.
+
+Note than another feature with the name "git bisect fix" was suggested
+to do something else:
+
+http://thread.gmane.org/gmane.comp.version-control.git/169026
+
+Since there have already been discussions and patches, the remaining
+work is probably less than a GSoC, so this project should be grouped
+with another one (like git bisect --first-parent) to make a full GSoC
+proposal.
+
 ### Unifying `git branch -l`, `git tag -l`, and `git for-each-ref`
 
 These three commands are all about selecting a subset of a repository's
-- 
2.3.0.157.g79e124b

--
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 3/3] idea: Be nicer to the user on tracked/untracked merge conflicts

[Matthieu Moy]

Signed-off-by: Matthieu Moy 
---
 SoC-2015-Ideas.md | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md
index 4641800..86de476 100644
--- a/SoC-2015-Ideas.md
+++ b/SoC-2015-Ideas.md
@@ -117,3 +117,30 @@ Cf. $gmane/213180 $gmane/212950
 ### Introduce threading to checkout codepath, possibly helping Windows folks.
 
 Cf. $gmane/235874
+
+### Be nicer to the user on tracked/untracked merge conflicts
+
+When merging a commit which has tracked files with the same name as
+local untracked files, Git refuses to proceed. It could be nice to:
+
+ - Accept the situation without conflict when the tracked file has the
+   exact same content as the local untracked file (which would become
+   tracked). No data is lost, nothing can be committed accidentally.
+
+ - Possibly, for fast-forward merges, if a local files belongs to the
+   index but not to the last commit, attempt a merge between the
+   upstream version and the local one (resulting in the same content
+   as if the file had just been committed, but without introducing an
+   extra commit).
+
+Recent versions SVN do something similar: on update, it considers
+added but not committed files like normal tracked files, and attempts
+a merge of the upstream version with the local one (which always
+succeeds when the files have identical content). Attempting a merge
+for non-fast forward cases would probably not make sense: it would mix
+changes coming from the merge with other changes that do not come from
+a commit.
+
+One difficulty with this project is to identify uncontroversial cases
+(where Git should merge without complaining) and all the possible
+corner-cases.
-- 
2.3.0.157.g79e124b

--
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 2/2] Documentation/git-am.txt: mention mailinfo.scissors config variable

[Matthieu Moy]

It was already documented, but the user had to follow the link to
git-mailinfo.txt to find it.

Signed-off-by: Matthieu Moy 
---
 Documentation/git-am.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index f4eea28..0d8ba48 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -52,7 +52,8 @@ OPTIONS
 -c::
 --scissors::
Remove everything in body before a scissors line (see
-   linkgit:git-mailinfo[1]).
+   linkgit:git-mailinfo[1]). Can be activated by default using
+   the `mailinfo.scissors` configuration variable.
 
 --no-scissors::
Ignore scissors lines (see linkgit:git-mailinfo[1]).
-- 
2.3.0.157.g79e124b

--
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 1/2] Documentation/config.txt: document mailinfo.scissor

[Matthieu Moy]

The variable was documented in git-mailinfo.txt, but not in config.txt.
The detailed documentation is still the one of --scissors in
git-mailinfo.txt, but we give enough information here to let the user
understand what it is about, and to make it easy to find it (e.g.
searching ">8" and "8<" finds it).

Signed-off-by: Matthieu Moy 
---
Changes since v1 for both patches : typos noted by Peff.

 Documentation/config.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index ae6791d..15f8695 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1740,6 +1740,13 @@ log.mailmap::
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
linkgit:git-whatchanged[1] assume `--use-mailmap`.
 
+mailinfo.scissors::
+   If true, makes linkgit:git-mailinfo[1] (and therefore
+   linkgit:git-am[1]) act by default as if the --scissors option
+   was provided on the command-line. When active, this features
+   removes everything from the message body before a scissors
+   line (i.e. consisting mainly of ">8", "8<" and "-").
+
 mailmap.file::
The location of an augmenting mailmap file. The default
mailmap, located in the root of the repository, is loaded
-- 
2.3.0.157.g79e124b

--
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: [RFH] GSoC 2015 application

[Dennis Kaarsemaker]

On vr, 2015-02-20 at 11:06 +0100, Matthieu Moy wrote:
> The ~/.git-credential-cache may be a bit harder, but the case of
> ~/.git-credentials should follow the same pattern as files for which
> this is already done. So, doing it by mimicking existing code
> shouldn't
> be too hard.
> 
> But maybe that's me being optimistic ;-)

Having just copied that logic to one of my tools, I reaclly would have
fount if useful to have something that, given a config file name tells
you where it should be, maybe in the resident kitchen-sink that is
rev-parse:

$ git rev-parse --config git
/home/dennis/.gitconfig
$ git rev-parse --config gitk
/home/dennis/.gitk
$ git rev-parse --config foobar
/home/dennis/.foobar

Or, when XDG config files are used:

$ git rev-parse --config gitk
/home/dennis/.config/git/gitk
$ git rev-parse --config git
/home/dennis/.config/git/config
$ git rev-parse --config foobar
/home/dennis/.config/git/foobar

So, ~/.$filename or $XDG_CONFIG_HOME/git/filename, with a special case
only for git itself, with consistent selection of which to use
(currently gitk and git are inconsistent).

-- 
Dennis Kaarsemaker
http://www.kaarsemaker.net

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

Re: [PATCH 2/2] Documentation/git-am.txt: mention mailinfo.scissor config variable

[Jeff King]

On Fri, Feb 20, 2015 at 11:09:07AM +0100, Matthieu Moy wrote:

> It was already documented, but the user had to follow the link to
> git-mailinfo.txt to find it.
> 
> Signed-off-by: Matthieu Moy 
> ---
> This one may be more controversial. I think it makes sense to apply
> it, but I won't fight for it if you think it adds too much noise to
> the doc.

I recently looked up the option to reply to your other mail, knowing it
existed but forgetting the exact name. It took me several minutes to
find it. I'm in favor of this.

>  --scissors::
>   Remove everything in body before a scissors line (see
> - linkgit:git-mailinfo[1]).
> + linkgit:git-mailinfo[1]). Can be activated by default using
> + the `mailinfo.scissor` configuration variable.

As in the other patch, "scissors", with a trailing "s".

-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 1/2] Documentation/config.txt: document mailinfo.scissor

[Jeff King]

On Fri, Feb 20, 2015 at 11:09:06AM +0100, Matthieu Moy wrote:

> The variale was documented in git-mailinfo.txt, but not in config.txt.

Missing 'b' in variable.

> +mailinfo.scissor::

s/scissor/&s/

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

Re: Git Feature Request - show current branch

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 19.02.2015 19:10:
> Michael J Gruber  writes:
> 
>> Randall S. Becker venit, vidit, dixit 19.02.2015 14:32:
>>> git symbolic-ref --short HEAD
>>
>> That errors out when HEAD is detached.
> 
> Isn't that what you would want to happen anyway?
> 
>   if current=$(that command)
> then
>   you know $current is checked out
>   else
>   you know HEAD is detached
>   fi
> 
> If you used another command that gives either the name of the
> current branch or 4-letter H-E-A-D without any other indication, you
> cannot tell if you checked out the "HEAD" branch aka refs/heads/HEAD
> or you are not on any branch.  The former would happen after doing
> this:
> 
> $ git update-ref refs/heads/HEAD HEAD
> $ git checkout HEAD
> 
> Of course, this is not a recommended practice, and "git branch"
> these days refuses to create refs/heads/HEAD to discourage you from
> doing so by mistake, but there is no guarantee that the repository
> whatever script you are writing to work in was created and used by
> sane people ;-) so you would want to be defensive, no?
> 

If you want to be defenive, don't use --abbrev-ref, just git rev-parse
--symbolic-full-name  HEAD

The original request was for a one-liner, I think.

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

[PATCH 1/2] Documentation/config.txt: document mailinfo.scissor

[Matthieu Moy]

The variale was documented in git-mailinfo.txt, but not in config.txt.
The detailed documentation is still the one of --scissors in
git-mailinfo.txt, but we give enough information here to let the user
understand what it is about, and to make it easy to find it (e.g.
searching ">8" and "8<" finds it).

Signed-off-by: Matthieu Moy 
---
 Documentation/config.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index ae6791d..4a2a078 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1740,6 +1740,13 @@ log.mailmap::
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
linkgit:git-whatchanged[1] assume `--use-mailmap`.
 
+mailinfo.scissor::
+   If true, makes linkgit:git-mailinfo[1] (and therefore
+   linkgit:git-am[1]) act by default as if the --scissors option
+   was provided on the command-line. When active, this features
+   removes everything from the message body before a scissors
+   line (i.e. consisting mainly of ">8", "8<" and "-").
+
 mailmap.file::
The location of an augmenting mailmap file. The default
mailmap, located in the root of the repository, is loaded
-- 
2.3.0.157.g79e124b

--
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 2/2] Documentation/git-am.txt: mention mailinfo.scissor config variable

[Matthieu Moy]

It was already documented, but the user had to follow the link to
git-mailinfo.txt to find it.

Signed-off-by: Matthieu Moy 
---
This one may be more controversial. I think it makes sense to apply
it, but I won't fight for it if you think it adds too much noise to
the doc.

 Documentation/git-am.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index f4eea28..1128570 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -52,7 +52,8 @@ OPTIONS
 -c::
 --scissors::
Remove everything in body before a scissors line (see
-   linkgit:git-mailinfo[1]).
+   linkgit:git-mailinfo[1]). Can be activated by default using
+   the `mailinfo.scissor` configuration variable.
 
 --no-scissors::
Ignore scissors lines (see linkgit:git-mailinfo[1]).
-- 
2.3.0.157.g79e124b

--
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: [RFH] GSoC 2015 application

[Matthieu Moy]

Jeff King  writes:

>> * Be nicer to the user on tracked/untracked merge conflicts
>> [...]
>
> Sounds OK to me, though I agree the merging of untracked files is a
> little controversial.

Yes. To me, part of the project is to identify cases where this is
actually not controversial (OTOH, it's a bit frustrating when I do a
trivial pull and Git complains because I already have the file).

>> +### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git
>> +
>> +Most of git dotfiles can be located, at the user's option, in
>> +~/. or in ~/.config/git/, following the [XDG
>> +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
>> +~/.git-credentials and ~/.git-credential-cache are still hardcoded as
>> +~/., and should allow using the XDG directory layout too
>> +(~/.git-credentials could be allowed as ~/.config/git/credential and
>> +~/.git-credential-cache could be allowed as ~/.cache/git/credential,
>> +possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME).
>> +
>> +Each of these files can be a microproject of its own. The suggested
>> +approach is:
>> +
>> +* See how XDG was implemented for other files (run "git log --grep
>> +  XDG" in Git's source code) and read the XDG specification.
>> +
>> +* Implement and test the new behavior, without breaking compatibility
>> +  with the old behavior.
>> +
>> +* Update the documentation
>
> I think these might be getting a little larger than "micro".

The ~/.git-credential-cache may be a bit harder, but the case of
~/.git-credentials should follow the same pattern as files for which
this is already done. So, doing it by mimicking existing code shouldn't
be too hard.

But maybe that's me being optimistic ;-).

>> +### Add configuration options for some commonly used command-line options
>> +
>> +This includes:
>> +
>> +* git am -3
>> +
>> +* git am -c
>> +
>> +Some people always run the command with these options, and would
>> +prefer to be able to activate them by default in ~/.gitconfig.
>
> The direction here seems reasonable, though I think we have
> mailinfo.scissors already, so "-c" may not be a good example.

Ah, indeed. The documentation makes it a bit hard to find, but I'll send
a patch.

>> +### Add more builtin patterns for userdiff
>> +
>> +"git diff" shows the function name corresponding to each hunk after
>> +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...),
>> +the way to find the function name is built-in Git's source code as
>> +regular expressions (see userdiff.c). A few languages are common
>> +enough to deserve a built-in driver, but are not yet recognized. For
>> +example, CSS, shell.
>
> I am not sure that understanding the horrible regexes involved in some
> userdiff counts as "micro", but OK. :)

I agree the regexes are horrible, but here also the project is not about
doing something really new, but reproducing what has already been done
for others.

At least, students not fluent with regular expressions have a pointer to
userdiff.c and can quickly see that the microproject is not meant for
them ;-).

-- 
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: [RFH] GSoC 2015 application

[Jeff King]

On Fri, Feb 20, 2015 at 10:39:42AM +0100, Matthieu Moy wrote:

> Jeff King  writes:
> 
> >   - Matthieu, who also cited time constraints
> 
> Just to clarify: last year we were co-mentoring with Ram. I ended up
> having a lot of time and did most of the work (not blaming Ram, and I
> enjoyed the experience). I'm still motivated to co-mentor, but this time
> the co-mentoring has to be more balanced (or unballanced to the other
> mentor ;-) ).

Yes, but who is your co-mentor this year? :)

> From your list, it seems we can target 1 or 2 slots. I'd say it's still
> worth applying, but if we don't find more mentors then perhaps it would
> make sense to say so explicitely in
> http://git.github.io/SoC-2015-Ideas.html so that students looking for
> organization know that we'll have very few slots.

I don't mind doing 1 slot if that's what we have resources for. But if
we have to say "eh, we do not really have enough mentors to support
you", then I wonder if it is worth doing.  They do not know how many
people have applied, or how tight the competition is.

-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: [RFH] GSoC 2015 application

[Matthieu Moy]

Jeff King  writes:

>   - Matthieu, who also cited time constraints

Just to clarify: last year we were co-mentoring with Ram. I ended up
having a lot of time and did most of the work (not blaming Ram, and I
enjoyed the experience). I'm still motivated to co-mentor, but this time
the co-mentoring has to be more balanced (or unballanced to the other
mentor ;-) ).

>   - Junio, who contributed some project ideas, but who in the past has
> declined to mentor in order to remain impartial as the maintainer
> who evaluates student results (which I think is quite reasonable)

Yes, as a mentor I did appreciate having Junio as impartial
maintainer/reviewer. And he did for sure contribute even without being a
mentor!

>From your list, it seems we can target 1 or 2 slots. I'd say it's still
worth applying, but if we don't find more mentors then perhaps it would
make sense to say so explicitely in
http://git.github.io/SoC-2015-Ideas.html so that students looking for
organization know that we'll have very few slots.

-- 
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: [RFH] GSoC 2015 application

[Junio C Hamano]

On Thu, Feb 19, 2015 at 11:13 PM, Jeff King  wrote:

>> There is debian bug 777690 [1] that's basically about making tag's
>> version sort aware about -rc, -pre suffixes. I imagine it would touch
>> versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
>> file).
>>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690
>
> I think that's a reasonable thing to work on, but it's too big for a
> microproject and too small for a GSoC.

That is certainly too big as a Micro, but I do not think it is too small
for GSoC, if it is to be done right (meaning, not just implementing an
arbitrary version comparison hardwired, but design how to make it
extensible).

I have a feeling that I am complaining that student projects are
designed to be too grand and getting told that I am overly pessimistic
by everybody else every year. Perhaps this year others may prove
me wrong, if we can find mentors, that is ;-)
--
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

You can upload your Invited Paper until heend of this week

[Zoe Michel .]

Dear Invited Author,

Further to our previous communication, we would like to inform you that you can
upload your Invited Paper in our conferences in Vienna, Austria, March 15-17, 
2015: 
www.inase.org until the end of this week

Extended Versions of all the Invited papers will be promoted for direct 
publication
in 36 Collaborating ISI/SCI Journals (with Impact Factor from Thomson Reuters)

Proceedings will be published both in CD-ROM and Hard-Copy by INASE Press and 
will
be indexed in ISI/SCI, SCOPUS, EI Compendex, IET(IEE), AMS, ACS, CiteSeerX,
Zentralblatt, British Library, EBSCO, SWETS, EMBASE, CAS, Scholar Google

Invited Authors have a special privileged position in the conference program 
with
double time for their presentation. The number of Invited Papers do not surpass 
the
4-5% of the total number of papers and Invited Authors can be members of the
committee of the next INASE Conferences.

Inform us that you uploaded your invited paper, very simply, by writing in the
Field: 
Short CV of the Main Author, the phrase:  "
invited-by-zoe-michel-...@vger.kernel.org " 

So, kindly upload your invited paper with the correct INASE format until 
February
22, 2015.

All the extended versions of the papers of 2013, 2014 and 2015 have been 
published
and indexed in our collaborating ISI/SCI/SCOPUS Journals. Contact me for more
details now as well as for giving you more assistance on this matter.

@ See reports and photos from former INASE conferences in our web site inase.org

Best Regards

Dr. Zoe Michel
INASE Headquarters


In case that you do not intend to participate in any of our future conferences 
of
2015 or of the upcoming years (2016,...), please, send an email to 
i...@inase.org
with Subject in the Subject Line of your Email exactly the phrase:   
" DO NOT INVITE ME AGAIN git@vger.kernel.org "
--
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: Should "git log --decorate" indicate whether the HEAD is detached?

[Junio C Hamano]

On Thu, Feb 19, 2015 at 3:13 AM, Julien Cretel  wrote:
> On Wed, Feb 18, 2015 at 5:07 PM, Junio C Hamano  wrote:
>
>> Julien's "HEAD=master, other" vs "HEAD, master, other" may be
>> subdued enough to be undistracting, I would guess.  I do not think
>> the distinction between "HEAD = master" and "HEAD -> master" would
>> be useful, on the other hand.
>
> Just to clarify, I suggested these two notations as alternatives for
> denoting the same state: "HEAD is attached to master". They were not
> meant to denote different states. Accordingly, a detached HEAD could
> be denoted by "HEAD, master, other" (i.e. the same as the current
> output of "git log --decorate").

That makes it even better than my misunderstood version ;-)  A list
that is usually "A, B, C" that sometimes has "A, B=C" is inconspicuous
enough not to be distracting too much, I would say.

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

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

On Thu, Feb 19, 2015 at 11:29 PM, Jeff King  wrote:
>
> This brings up an important issue. We cannot do GSoC without mentors. I
> had hoped that people populating the "ideas" list would volunteer to
> mentor for their projects.
>
> But so far the possibilities are:
>
>   - Stefan
>
>   - me, who has already promised to be stingy
>
>   - Matthieu, who also cited time constraints
>
>   - Junio, who contributed some project ideas, but who in the past has
> declined to mentor in order to remain impartial as the maintainer
> who evaluates student results (which I think is quite reasonable)
>
> So...basically 1 mentor and 2 reticent maybes? That doesn't look good.

Indeed, the mentor panel looks particularly weak this year, if nobody
can afford the time for proper mentoring.

Even though I can indirectly help by giving reviews at a more hand-holding
level than usual, there is a limit. And I definitely do not foresee acting as a
mentor myself.
--
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