Re: Watchman support for git

[Duy Nguyen]

On Sat, May 3, 2014 at 6:14 AM,   wrote:
> The most sigificant patch uses Facebook's watchman daemon[1] to monitor
> the repository work tree for changes.  This makes allows git status
> to avoid traversing the entire work tree to find changes.

I got "warning: Watchman watch error: Got bad JSON from watchman
get-sockname: '[' or '{' expected near end of file". Any ideas what I
did wrong? I'm using watchman.git and libwatchman.git. check-0.9.11
and jansson-2.4 were installed by system (gentoo).
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 20/25] contrib: remove 'contacts'

[Felipe Contreras]

brian m. carlson wrote:
> On Thu, May 08, 2014 at 07:58:31PM -0500, Felipe Contreras wrote:
> > There are better out-of-tree tools, and this tool is not planned to move
> > into the core anyway.
> 
> I have used this once or twice, and I have seen others indicate their
> use of it as well.  I am not volunteering to maintain this, but if it is
> working reasonably well for people (as it appears to be), I don't see a
> reason to remove it.

If all it took as qualification for contrib is that "somebody" uses it,
contrib would be festered by tools that right now live out-of-tree.

The reasons why some tools are not dropped from contrib, and others are
rejected to contrib are completely arbitrary.

-- 
Felipe Contreras
--
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] How to keep a project's canonical history correct.

[Stephen & Linda Smith]

On Friday, May 09, 2014 02:05:44 PM Junio C Hamano wrote:
> I needed a few tweaks on top while queuing.  You will find the
> result on 'pu' after I push it out.
> 
> In addition to one typofix ("because" lacking "c"), here are what I
> did:
> 
>  - Typeset concrete command e.g. `git pull` in monospace.
> 
>  - The second and subsequent paragraphs continued with "+" need to
>be flushed to the left; leaving them indented will format them in
>monospace (see "with `git pull --rebase` or something").
> 
>  - Be more explicit in describing 'trunk' being 'the first-parent
>chain' in the text.
> 
>  - Refer to a newer article that discusses this exact topic.
> 
>  - De-emphasize 'fix-bug-12345' in "Merge fix-bug-12345" log message.
> 
>  - Describe what the final history illustration shows.
> 
> 
> Unless you have objections to the below (or suggestions for better
> alternatives), there is no need to resend the patch.
> 

I like the changes.


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

Re: [PATCH v1 20/25] contrib: remove 'contacts'

[brian m. carlson]

On Thu, May 08, 2014 at 07:58:31PM -0500, Felipe Contreras wrote:
> There are better out-of-tree tools, and this tool is not planned to move
> into the core anyway.

I have used this once or twice, and I have seen others indicate their
use of it as well.  I am not volunteering to maintain this, but if it is
working reasonably well for people (as it appears to be), I don't see a
reason to remove it.

I don't feel I need a CC if a reply is made to this message.

-- 
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 v1 1/2] Remove 'git archimport'

[Felipe Contreras]

Eric Wong wrote:
> Thomas Adam  wrote:
> > I think I speak for everyone when I say: fuck off.
> 
> I wouldn't put it so harshly...
> 
> Felipe: I suggest you take a long vacation away from development.

Nah, I'm done.

> Whatever good you may be able to contribute today is drowned out by your
> behavior.

That's OK because I'm never contributing again.

I'd contribute patches that would be a burden to maintain on my tree
otherwise, but all the goodies will go to my git-fc fork.

There is just no point in contributin to Git, because nothing ever
changes ever. Nothing gets removed, nothing changed.

> The projects you are involved with will get by fine without you.

git-remote-hg didn't get by so fine without me.

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

Re: [PATCH v2 01/17] contrib: remove outdated README

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras  writes:
> 
> > There is no guideline as for what should be part of contrib.
> >
> > Some tools are actively maintained, others consist of a single commit.
> > Some tools have active user-base, some aren't used by anyone. Some tools
> > are on the path towards the core, others will never get there. Some
> > tools are already out-of-tree and simply mirrored, others probably
> > wouldn't survive out-of-tree. Some tools are production-ready, others
> > don't even run. Some tools have tests, most don't.
> >
> > Junio has explained that he wrote this a long time ago, when Git was a
> > different beast, now this no longer applies.
> >
> > The only way to find out if a tool belongs in contrib or not is to as
> > Junio.
> >
> > Cc: Junio C Hamano 
> > Signed-off-by: Felipe Contreras 
> > ---
> 
> This is wrong.
> 
> The reason I suggested splitting remote-hg out of my tree does not

This particular patch has nothing to do with remote-hg.

> have anything to do with "removal of disused and inactive" described
> in the document.  As written elsewhere, it was a response to
> 
> http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248457
> 
> where you said
> 
> I don't want to do anything for a "contrib" tool.

You are once more twisting the sequence of events.

*First* you blocked any progres towards graduation 2014-05-06, even
though I told you what John Keeping argued wasn't going to happen.

  http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248242

*After* that I decided not touch git-remote-hg/bzr on your tree any more
2014-05-08.

  http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248457

Do not attempt to construe the consequence as the cause. You caused it.

-- 
Felipe Contreras
--
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] Make it possible to update git_wcwidth()

[Torsten Bögershausen]

The function git_wcwidth() returns for a given unicode code point the
width on the display:
-1 for control characters,
 0 for combining or other non-visible code points
 1 for e.g. ASCII
 2 for double-width code points.

This table had been originally been extracted for one Unicode version,
probably 3.2.

Make it possible to update the to a later version of Unicode:

Factor out the table from utf8.c into unicode_width.h and
add the script update_unicode.sh to update the table based on the latest
Unicode specification files.

Thanks to
Peter Krefting  and
Kevin Bracey 
for helping with their Unicode knowledge

Signed-off-by: Torsten Bögershausen 
---
 .gitignore|   1 +
 Makefile  |   1 +
 unicode_width.h   | 288 ++
 update_unicode.sh |  37 +++
 utf8.c|  61 +---
 5 files changed, 329 insertions(+), 59 deletions(-)
 create mode 100644 unicode_width.h
 create mode 100755 update_unicode.sh

diff --git a/.gitignore b/.gitignore
index dc600f9..42294e5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -226,6 +226,7 @@
 /config.mak.autogen
 /config.mak.append
 /configure
+/unicode
 /tags
 /TAGS
 /cscope*
diff --git a/Makefile b/Makefile
index a53f3a8..2e2077a 100644
--- a/Makefile
+++ b/Makefile
@@ -730,6 +730,7 @@ LIB_H += transport.h
 LIB_H += tree-walk.h
 LIB_H += tree.h
 LIB_H += unpack-trees.h
+LIB_H += unicode_width.h
 LIB_H += url.h
 LIB_H += urlmatch.h
 LIB_H += userdiff.h
diff --git a/unicode_width.h b/unicode_width.h
new file mode 100644
index 000..4db7803
--- /dev/null
+++ b/unicode_width.h
@@ -0,0 +1,288 @@
+static const struct interval zero_width[] = {
+{ 0x0300, 0x036F },
+{ 0x0483, 0x0489 },
+{ 0x0591, 0x05BD },
+{ 0x05BF, 0x05BF },
+{ 0x05C1, 0x05C2 },
+{ 0x05C4, 0x05C5 },
+{ 0x05C7, 0x05C7 },
+{ 0x0600, 0x0604 },
+{ 0x0610, 0x061A },
+{ 0x061C, 0x061C },
+{ 0x064B, 0x065F },
+{ 0x0670, 0x0670 },
+{ 0x06D6, 0x06DD },
+{ 0x06DF, 0x06E4 },
+{ 0x06E7, 0x06E8 },
+{ 0x06EA, 0x06ED },
+{ 0x070F, 0x070F },
+{ 0x0711, 0x0711 },
+{ 0x0730, 0x074A },
+{ 0x07A6, 0x07B0 },
+{ 0x07EB, 0x07F3 },
+{ 0x0816, 0x0819 },
+{ 0x081B, 0x0823 },
+{ 0x0825, 0x0827 },
+{ 0x0829, 0x082D },
+{ 0x0859, 0x085B },
+{ 0x08E4, 0x08FE },
+{ 0x0900, 0x0902 },
+{ 0x093A, 0x093A },
+{ 0x093C, 0x093C },
+{ 0x0941, 0x0948 },
+{ 0x094D, 0x094D },
+{ 0x0951, 0x0957 },
+{ 0x0962, 0x0963 },
+{ 0x0981, 0x0981 },
+{ 0x09BC, 0x09BC },
+{ 0x09C1, 0x09C4 },
+{ 0x09CD, 0x09CD },
+{ 0x09E2, 0x09E3 },
+{ 0x0A01, 0x0A02 },
+{ 0x0A3C, 0x0A3C },
+{ 0x0A41, 0x0A42 },
+{ 0x0A47, 0x0A48 },
+{ 0x0A4B, 0x0A4D },
+{ 0x0A51, 0x0A51 },
+{ 0x0A70, 0x0A71 },
+{ 0x0A75, 0x0A75 },
+{ 0x0A81, 0x0A82 },
+{ 0x0ABC, 0x0ABC },
+{ 0x0AC1, 0x0AC5 },
+{ 0x0AC7, 0x0AC8 },
+{ 0x0ACD, 0x0ACD },
+{ 0x0AE2, 0x0AE3 },
+{ 0x0B01, 0x0B01 },
+{ 0x0B3C, 0x0B3C },
+{ 0x0B3F, 0x0B3F },
+{ 0x0B41, 0x0B44 },
+{ 0x0B4D, 0x0B4D },
+{ 0x0B56, 0x0B56 },
+{ 0x0B62, 0x0B63 },
+{ 0x0B82, 0x0B82 },
+{ 0x0BC0, 0x0BC0 },
+{ 0x0BCD, 0x0BCD },
+{ 0x0C3E, 0x0C40 },
+{ 0x0C46, 0x0C48 },
+{ 0x0C4A, 0x0C4D },
+{ 0x0C55, 0x0C56 },
+{ 0x0C62, 0x0C63 },
+{ 0x0CBC, 0x0CBC },
+{ 0x0CBF, 0x0CBF },
+{ 0x0CC6, 0x0CC6 },
+{ 0x0CCC, 0x0CCD },
+{ 0x0CE2, 0x0CE3 },
+{ 0x0D41, 0x0D44 },
+{ 0x0D4D, 0x0D4D },
+{ 0x0D62, 0x0D63 },
+{ 0x0DCA, 0x0DCA },
+{ 0x0DD2, 0x0DD4 },
+{ 0x0DD6, 0x0DD6 },
+{ 0x0E31, 0x0E31 },
+{ 0x0E34, 0x0E3A },
+{ 0x0E47, 0x0E4E },
+{ 0x0EB1, 0x0EB1 },
+{ 0x0EB4, 0x0EB9 },
+{ 0x0EBB, 0x0EBC },
+{ 0x0EC8, 0x0ECD },
+{ 0x0F18, 0x0F19 },
+{ 0x0F35, 0x0F35 },
+{ 0x0F37, 0x0F37 },
+{ 0x0F39, 0x0F39 },
+{ 0x0F71, 0x0F7E },
+{ 0x0F80, 0x0F84 },
+{ 0x0F86, 0x0F87 },
+{ 0x0F8D, 0x0F97 },
+{ 0x0F99, 0x0FBC },
+{ 0x0FC6, 0x0FC6 },
+{ 0x102D, 0x1030 },
+{ 0x1032, 0x1037 },
+{ 0x1039, 0x103A },
+{ 0x103D, 0x103E },
+{ 0x1058, 0x1059 },
+{ 0x105E, 0x1060 },
+{ 0x1071, 0x1074 },
+{ 0x1082, 0x1082 },
+{ 0x1085, 0x1086 },
+{ 0x108D, 0x108D },
+{ 0x109D, 0x109D },
+{ 0x1160, 0x11FF },
+{ 0x135D, 0x135F },
+{ 0x1712, 0x1714 },
+{ 0x1732, 0x1734 },
+{ 0x1752, 0x1753 },
+{ 0x1772, 0x1773 },
+{ 0x17B4, 0x17B5 },
+{ 0x17B7, 0x17BD },
+{ 0x17C6, 0x17C6 },
+{ 0x17C9, 0x17D3 },
+{ 0x17DD, 0x17DD },
+{ 0x180B, 0x180E },
+{ 0x18A9, 0x18A9 },
+{ 0x1920, 0x1922 },
+{ 0x1927, 0x1928 },
+{ 0x1932, 0x1932 },
+{ 0x1939, 0x193B },
+{ 0x1A17, 0x1A18 },
+{ 0x1A1B, 0x1A1B },
+{ 0x1A56, 0x1A56 },
+{ 0x1A58, 0x1A5E },
+{ 0x1A60, 0x1A60 },
+{ 0x1A62, 0x1A62 },
+{ 0x1A65, 0x1A6C },
+{ 0x1A73, 0x1A7C },
+{ 0x1A7F, 0x1A7F },
+{ 0x1B00, 0x1B03 },
+{ 0x1B34, 0x1B34 },
+{ 0x1B36, 0x1B3A },
+{ 0x1B3C, 0x1B3C },
+{ 0x1B42, 0x1B42 },
+{ 0x1B6B, 0x1B73 },
+{ 0x1B80, 0x1B81 },
+{ 0x1BA2, 0x1BA5 },
+{ 0x1BA8, 0x1BA9 },
+{ 0x1BAB, 0x1BAB },
+{ 0x1BE6, 0x1BE6 },
+{ 0x1BE8, 0x1BE9 },
+{ 0x1BED, 0x1BED },
+{ 0x1BEF, 0x1BF1 },
+{ 0x1C2C, 0x1C33 },
+{ 0x1C36, 0x1C37 },
+{ 0x1CD0, 0x1CD2 },
+{ 0x1CD4, 0x1CE0 },
+{ 0x1CE2, 0x1CE8 },
+{ 0x1CED, 0x1CED },
+{ 0x1CF4, 0x1CF4 },
+{ 0x1DC0, 0x1DE6 },
+{ 0x1DFC, 0x1DFF },
+{ 0x200B, 0x200F },
+{ 0x202A, 0x202E },
+{ 0x206

[PATCH 1/2] utf8.c: use a table for double_width

[Torsten Bögershausen]

Refactor git_wcwidth() and replace the if-else-if chain.
Use the table double_width which is scanned by the bisearch() function,
which is already used to find combining code points.

Signed-off-by: Torsten Bögershausen 
---
 utf8.c | 41 ++---
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/utf8.c b/utf8.c
index 77c28d4..b5d8136 100644
--- a/utf8.c
+++ b/utf8.c
@@ -126,6 +126,19 @@ static int git_wcwidth(ucs_char_t ch)
{ 0x1D1AA, 0x1D1AD }, { 0xE0001, 0xE0001 },
{ 0xE0020, 0xE007F }, { 0xE0100, 0xE01EF }
};
+   static const struct interval double_width[] = {
+   { 0x1100, 0x115F },
+   { 0x2329, 0x232A },
+   { 0x2E80, 0x303E },
+   { 0x3040, 0xA4CF },
+   { 0xAC00, 0xD7A3 },
+   { 0xF900, 0xFAFF },
+   { 0xFE30, 0xFE6F },
+   { 0xFF00, 0xFF60 },
+   { 0xFFE0, 0xFFE6 },
+   { 0x2, 0x2FFFD },
+   { 0x3, 0x3FFFD }
+   };
 
/* test for 8-bit control characters */
if (ch == 0)
@@ -138,30 +151,12 @@ static int git_wcwidth(ucs_char_t ch)
/ sizeof(struct interval) - 1))
return 0;
 
-   /*
-* If we arrive here, ch is neither a combining nor a C0/C1
-* control character.
-*/
+   /* binary search in table of double width characters */
+   if (bisearch(ch, double_width, sizeof(double_width)
+   / sizeof(struct interval) - 1))
+   return 2;
 
-   return 1 +
-   (ch >= 0x1100 &&
-/* Hangul Jamo init. consonants */
-(ch <= 0x115f ||
- ch == 0x2329 || ch == 0x232a ||
-  /* CJK ... Yi */
- (ch >= 0x2e80 && ch <= 0xa4cf &&
-  ch != 0x303f) ||
- /* Hangul Syllables */
- (ch >= 0xac00 && ch <= 0xd7a3) ||
- /* CJK Compatibility Ideographs */
- (ch >= 0xf900 && ch <= 0xfaff) ||
- /* CJK Compatibility Forms */
- (ch >= 0xfe30 && ch <= 0xfe6f) ||
- /* Fullwidth Forms */
- (ch >= 0xff00 && ch <= 0xff60) ||
- (ch >= 0xffe0 && ch <= 0xffe6) ||
- (ch >= 0x2 && ch <= 0x2fffd) ||
- (ch >= 0x3 && ch <= 0x3fffd)));
+   return 1;
 }
 
 /*
-- 
1.9.2.691.g8d8dc6d


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

RE: What's cooking in git.git (May 2014, #02; Fri, 9)

[Felipe Contreras]

Junio C Hamano wrote:
> * fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
>  - remote-hg: trivial cleanups
>  - remote-hg: make sure we omit multiple heads
>  - git-remote-hg: use internal clone's hgrc
>  - t: remote-hg: split into setup test
>  - remote-hg: properly detect missing contexts
>  - remote-{hg,bzr}: store marks only on success
>  - remote-hg: update to 'public' phase when pushing
>  - remote-hg: fix parsing of custom committer
>   (merged to 'next' on 2014-04-22 at fed170a)
>  + remote-helpers: move tests out of contrib
>  + remote-helpers: move out of contrib
>  + remote-helpers: squelch python import exceptions
> 
>  As there were announcements for these two to be maintained as
>  independent third-party projects ($gmane/248561, $gmane/248583),

Clarification: after Junio unlilaterally blocked any further progress
towards grauduation to the core, which was the intention since the very
beginning.

-- 
Felipe Contreras
--
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: t5539 fails on ubuntu for v2.0.0-rc2

[Junio C Hamano]

Jeff King  writes:

> Does running the tests as a non-root user fix it? If so, I think we have
> a few options in git:
>
>   1. Add a User directive to our httpd.conf. I doubt this is a good
>  idea to do unconditionally, as a non-root apache would probably be
>  unhappy with it.
>
>   2. Add a User directive when we detect that the tests are running as
>  root.  This might work, but I'm a bit iffy, as we do not know the
>  appropriate username for the system (e.g., "nobody" versus
>  "www-data" versus something else).
>
>   3. Just disable the http tests when run as root.
>
> I think I'd favor 3. But I'd like to be sure that being root is the
> problem.

I agree with both the conclusion and the precondition.

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

[ANNOUNCE] Git v2.0.0-rc3

[Junio C Hamano]

A release candidate Git v2.0.0-rc3 is now available for testing
at the usual places.

This hopefully will be the last -rc before the real 2.0.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/testing/

The following public repositories all have a copy of the 'v2.0.0-rc3'
tag and the 'master' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

Git v2.0 Release Notes (draft)
==

Backward compatibility notes


When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there).  In Git 2.0, the default is now the "simple" semantics,
which pushes:

 - only the current branch to the branch with the same name, and only
   when the current branch is set to integrate with that remote
   branch, if you are pushing to the same remote as you fetch from; or

 - only the current branch to the branch with the same name, if you
   are pushing to a remote that is not where you usually fetch from.

You can use the configuration variable "push.default" to change
this.  If you are an old-timer who wants to keep using the
"matching" semantics, you can set the variable to "matching", for
example.  Read the documentation for other possibilities.

When "git add -u" and "git add -A" are run inside a subdirectory
without specifying which paths to add on the command line, they
operate on the entire tree for consistency with "git commit -a" and
other commands (these commands used to operate only on the current
subdirectory).  Say "git add -u ." or "git add -A ." if you want to
limit the operation to the current directory.

"git add " is the same as "git add -A " now, so that
"git add dir/" will notice paths you removed from the directory and
record the removal.  In older versions of Git, "git add " used
to ignore removals.  You can say "git add --ignore-removal " to
add only added or modified paths in , if you really want to.

The "-q" option to "git diff-files", which does *NOT* mean "quiet",
has been removed (it told Git to ignore deletion, which you can do
with "git diff-files --diff-filter=d").

"git request-pull" lost a few "heuristics" that often led to mistakes.

The default prefix for "git svn" has changed in Git 2.0.  For a long
time, "git svn" created its remote-tracking branches directly under
refs/remotes, but it now places them under refs/remotes/origin/ unless
it is told otherwise with its --prefix option.


Updates since v1.9 series
-

UI, Workflows & Features

 * The "multi-mail" post-receive hook (in contrib/) has been updated
   to a more recent version from the upstream.

 * "git gc --aggressive" learned "--depth" option and
   "gc.aggressiveDepth" configuration variable to allow use of a less
   insane depth than the built-in default value of 250.

 * "git log" learned the "--show-linear-break" option to show where a
   single strand-of-pearls is broken in its output.

 * The "rev-parse --parseopt" mechanism used by scripted Porcelains to
   parse command line options and to give help text learned to take
   the argv-help (the placeholder string for an option parameter,
   e.g. "key-id" in "--gpg-sign=").

 * The pattern to find where the function begins in C/C++ used in
   "diff" and "grep -p" has been updated to help C++ source better.

 * "git rebase" learned to interpret a lone "-" as "@{-1}", the
   branch that we were previously on.

 * "git commit --cleanup=" learned a new mode, scissors.

 * "git tag --list" output can be sorted using "version sort" with
   "--sort=version:refname".

 * Discard the accumulated "heuristics" to guess from which branch the
   result wants to be pulled from and make sure what the end user
   specified is not second-guessed by "git request-pull", to avoid
   mistakes.  When you pushed out your 'master' branch to your public
   repository as 'for-linus', use the new "master:for-linus" syntax to
   denote the branch to be pulled.

 * "git grep" learned to behave in a way similar to native grep when
   "-h" (no header) and "-c" (count) options are given.

 * "git push" via transport-helper interface (e.g. remote-hg) has
   been updated to allow forced ref updates in a way similar to the
   natively supported transports.

 * The "simple" mode is the default for "git push".

 * "git add -u" and "git add -A", when run without any pathspec, is a
   tree-wide operation even when run inside a subdirectory of a
   working tree.

 * "git add " is the same as "git add -A " now.

 * "core.statinfo" configuration variable, which is a
   never-advertised syno

What's cooking in git.git (May 2014, #02; Fri, 9)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

The tip of the 'master' branch is at v2.0.0-rc3, which is in sync
with v1.9.3 with respect to bugfixes that was also tagged today.
Hopefully we can tag v2.0.0 final late next week.

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

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

--
[New Topics]

* dk/raise-core-deltabasecachelimit (2014-05-06) 1 commit
 - Bump core.deltaBaseCacheLimit to 96m

 The original 16 MiB limit for the in-core delta-base-cache
 introduced in 18bdec11 (Limit the size of the new delta_base_cache,
 2007-03-19) is turning too small.

 Will merge to 'next' and keep it there for the rest of this cycle.


* fc/remote-hg-fixes-for-hg-3.0 (2014-05-08) 5 commits
 - [DONTMERGE-not signed-off] remote-hg: work with older versions of mercurial
 - remote-hg: add support for hg v3.0
 - t: remote-hg: trivial cleanups and fixes
 - t: remote-hg: add file operation tests
 - remote-hg: add more tests

 Update remote-hg helper to work with newer versions of Mercurial,
 and fixes an incompatibility with older versions triggered by new
 tests.

 Will merge to 'next' and keep it there for the rest of this cycle.


* fc/status-printf-squelch-format-zero-length-warnings (2014-05-07) 1 commit
 - silence a bunch of format-zero-length warnings

 Will merge to 'next' and keep it there for the rest of this cycle.


* jk/grep-tell-run-command-to-cd-when-running-pager (2014-05-07) 1 commit
 - grep: use run-command's "dir" option for --open-files-in-pager

 Will merge to 'next' and keep it there for the rest of this cycle.


* jk/squelch-compiler-warning-from-funny-error-macro (2014-05-06) 2 commits
 - let clang use the constant-return error() macro
 - inline constant return from error() function

 Will merge to 'next' and keep it there for the rest of this cycle.


* rs/reflog-exists (2014-05-08) 2 commits
 - checkout.c: use ref_exists instead of file_exist
 - refs.c: add new functions reflog_exists and delete_reflog

 Will merge to 'next' and keep it there for the rest of this cycle.


* tg/tag-state-tag-name-in-editor-hints (2014-05-07) 1 commit
 - builtin/tag.c: show tag name to hint in the message editor

 Will merge to 'next' and keep it there for the rest of this cycle.


* sk/submodules-absolute-path-on-windows (2014-05-08) 1 commit
 - Revert "submodules: fix ambiguous absolute paths under Windows"

 Will merge to 'next' and keep it there for the rest of this cycle.


* jn/contrib-remove-diffall (2014-05-09) 1 commit
 - contrib: remove git-diffall

 Spring cleaning of contrib/.

 Will merge to 'next' and keep it there for the rest of this cycle.


* jn/contrib-remove-vim (2014-05-09) 1 commit
 - contrib: remove vim support instructions

 Spring cleaning of contrib/.

 Will merge to 'next' and keep it there for the rest of this cycle.


* ss/howto-manage-trunk (2014-05-09) 8 commits
 - SQUASH describe what the picture shows
 - SQUASH minor typographic fix
 - SQUASH clarify the informal description of 'trunk'
 - SQUASH typeset literal commands with `git command`
 - SQUASH use a better URL
 - SQUASH mark-up fix
 - SQUASH typofix
 - How to keep a project's canonical history correct.


* wg/svn-fe-style-fixes (2014-05-09) 1 commit
 - svn-fe: Conform to pep8

 Will merge to 'next' and keep it there for the rest of this cycle.

--
[Stalled]

* tr/merge-recursive-index-only (2014-02-05) 3 commits
 - merge-recursive: -Xindex-only to leave worktree unchanged
 - merge-recursive: internal flag to avoid touching the worktree
 - merge-recursive: remove dead conditional in update_stages()
 (this branch is used by tr/remerge-diff.)

 Will hold.


* tr/remerge-diff (2014-02-26) 5 commits
 . log --remerge-diff: show what the conflict resolution changed
 . name-hash: allow dir hashing even when !ignore_case
 . merge-recursive: allow storing conflict hunks in index
 . revision: fold all merge diff variants into an enum merge_diff_mode
 . combine-diff: do not pass revs->dense_combined_merges redundantly
 (this branch uses tr/merge-recursive-index-only.)

 "log -p" output learns a new way to let users inspect a merge
 commit by showing the differences between the automerged result
 with conflicts the person who recorded the merge would have seen
 and the final conflict resolution that was recorded in the merge.

 Needs to be rebased, now kb/fast-hashmap topic is in.


* jk/makefile (2014-02-05) 16 commits
 - FIXUP
 - move LESS/LV pager environment to Makefile
 - Makefile: teach scripts to include make variables
 - FIXUP
 - Makefile: auto-build C strings from make variables
 - Makefile: drop *_SQ variables
 - FIXUP
 - Makefile: add c-quote helper function
 - Makefile: introduce sq function for shell-quoting
 - Makefile

Re: [PATCH] How to keep a project's canonical history correct.

[Junio C Hamano]

"Stephen P. Smith"  writes:

> During the mail thread about "Pull is mostly evil" a user asked how
> the first parent could become reversed.
>
> This howto explains how the first parent can get reversed when viewed
> by the project and then explains a method to keep the history correct.
>
> Signed-off-by: Stephen P. Smith 
> ---

I needed a few tweaks on top while queuing.  You will find the
result on 'pu' after I push it out.

In addition to one typofix ("because" lacking "c"), here are what I
did:

 - Typeset concrete command e.g. `git pull` in monospace.

 - The second and subsequent paragraphs continued with "+" need to
   be flushed to the left; leaving them indented will format them in
   monospace (see "with `git pull --rebase` or something").

 - Be more explicit in describing 'trunk' being 'the first-parent
   chain' in the text.

 - Refer to a newer article that discusses this exact topic.

 - De-emphasize 'fix-bug-12345' in "Merge fix-bug-12345" log message.

 - Describe what the final history illustration shows.


Unless you have objections to the below (or suggestions for better
alternatives), there is no need to resend the patch.

Thanks.

diff --git a/Documentation/howto/keep-canonical-history-correct.txt 
b/Documentation/howto/keep-canonical-history-correct.txt
index 5979a79..35d48ef 100644
--- a/Documentation/howto/keep-canonical-history-correct.txt
+++ b/Documentation/howto/keep-canonical-history-correct.txt
@@ -38,12 +38,12 @@ central repository:
 ---o---o---A---X---Y---Z
 
 
-Now, if you "git push" at this point, beause your history that leads
+Now, if you `git push` at this point, because your history that leads
 to `C` lacks `X`, `Y` and `Z`, it will fail.  You need to somehow make
 the tip of your history a descendant of `Z`.
 
 One suggested way to solve the problem is "fetch and then merge", aka
-"git pull". When you fetch, your repository will have a history like
+`git pull`. When you fetch, your repository will have a history like
 this:
 
 
@@ -65,8 +65,9 @@ you will create a merge `M` and make the history look like 
this:
 repository.  Such a merge `M` does not lose any commit in both
 histories, so in that sense it may not be wrong, but when people want
 to talk about "the authoritative canonical history that is shared
-among the project participants", i.e. "the trunk", the way they often
-use is to do:
+among the project participants", i.e. "the trunk", they often view
+it as "commits you see by following the first-parent chain", and use
+this command to view it:
 
 
 $ git log --first-parent
@@ -91,11 +92,11 @@ did `X` and then `Y` and then `Z` and merged a change that 
consists of
 two commits `B` and `C` that achieves a single goal.  You may have
 worked on fixing the bug #12345 with these two patches, and the merge
 `M'` with swapped parents can say in its log message "Merge
-'fix-bug-12345'". Having a way to tell "git pull" to create a merge
+fix-bug-12345". Having a way to tell `git pull` to create a merge
 but record the parents in reverse order may be a way to do so.
 
 Note that I said "achieves a single goal" above, because this is
-important.  "swapping the merge order" only covers a special case
+important.  "Swapping the merge order" only covers a special case
 where the project does not care too much about having unrelated
 things done on a single merge but cares a lot about first-parent
 chain.
@@ -111,7 +112,7 @@ There are multiple schools of thought about the "trunk" 
management.
 ---o---o---A---X---Y---Z---B---C
 
 +
-with `git pull --rebase` or something.
+with `git pull --rebase` or something.
 
  2. Some projects tolerate merges in their history, but do not worry
 too much about the first-parent order, and allow fast-forward
@@ -190,7 +191,7 @@ and push it back to the central repository.
 
 It is very much possible that while you are merging topic-b and
 topic-c, somebody again advanced the history in the central repository
-to put `W` on top of `Z`, and make your "git push" fail.
+to put `W` on top of `Z`, and make your `git push` fail.
 
 In such a case, you would rewind to discard `M` and `N`, update the
 tip of your 'master' again and redo the two merges:
@@ -202,6 +203,8 @@ tip of your 'master' again and redo the two merges:
 $ git merge topic-c
 
 
+The procedure will result in a history that looks like this:
+
 
 C0--C1--C2
/ \
@@ -210,4 +213,4 @@ tip of your 'master' again and redo the two merges:
 B0--B1-B2
 
 
-See http://git-blame.blogspot.com/2012/03/fun-with-first-parent.html
+See also 
http://git-blame.blogspot.com/2013/09/fun-with-first-parent-history.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 v1 06/25] contrib: remove 'diffall'

[Tim Henigan]

Hi Jonathan,

On Fri, May 9, 2014 at 1:12 PM, Jonathan Nieder  wrote:
> Hi,
>
> Tim Henigan wrote:
>
>> However, I like the idea of simply removing the directory from contrib
>> and pointing to 'difftool --dir-diff' in the release notes.
>
> Thanks.  I believe Junio uses commit messages as reference when
> writing release notes so hopefully this should be enough to make that
> happen.

The updated commit message looks good to me.  Thanks.

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

Re: [PATCH v1 06/25] contrib: remove 'diffall'

[Jonathan Nieder]

Hi,

Tim Henigan wrote:

> However, I like the idea of simply removing the directory from contrib
> and pointing to 'difftool --dir-diff' in the release notes.

Thanks.  I believe Junio uses commit messages as reference when
writing release notes so hopefully this should be enough to make that
happen.

-- >8 --
Subject: contrib: remove git-diffall

The functionality of the "git diffall" script in contrib/ was
incorporated into "git difftool" when the --dir-diff option was added
in v1.7.11 (ca. June, 2012).  Once difftool learned those features,
the diffall script became obsolete.

The only difference in behavior is that when comparing to the working
tree, difftool copies any files modified by the user back to the
working tree when the diff tool exits.  "git diffall" required the
--copy-back option to do the same.  All other diffall options have the
same meaning in difftool.

Make life easier for people choosing a tool to use by removing the old
diffall script.  A pointer in the release notes should be enough to
help current users migrate.

Helped-by: Tim Henigan 
Signed-off-by: Jonathan Nieder 
---
 contrib/diffall/README  |  31 --
 contrib/diffall/git-diffall | 257 
 2 files changed, 288 deletions(-)
 delete mode 100644 contrib/diffall/README
 delete mode 100755 contrib/diffall/git-diffall

diff --git a/contrib/diffall/README b/contrib/diffall/README
deleted file mode 100644
index 507f17d..000
--- a/contrib/diffall/README
+++ /dev/null
@@ -1,31 +0,0 @@
-The git-diffall script provides a directory based diff mechanism
-for git.
-
-To determine what diff viewer is used, the script requires either
-the 'diff.tool' or 'merge.tool' configuration option to be set.
-
-This script is compatible with most common forms used to specify a
-range of revisions to diff:
-
-  1. git diffall: shows diff between working tree and staged changes
-  2. git diffall --cached []: shows diff between staged
- changes and HEAD (or other named commit)
-  3. git diffall : shows diff between working tree and named
- commit
-  4. git diffall  : show diff between two named commits
-  5. git diffall ..: same as above
-  6. git diffall ...: show the changes on the branch
- containing and up to the second, starting at a common ancestor
- of both 
-
-Note: all forms take an optional path limiter [-- *]
-
-The '--extcmd=' option allows the user to specify a custom
-command for viewing diffs.  When given, configured defaults are
-ignored and the script runs $command $LOCAL $REMOTE.  Additionally,
-$BASE is set in the environment.
-
-This script is based on an example provided by Thomas Rast on the
-Git list [1]:
-
-[1] http://thread.gmane.org/gmane.comp.version-control.git/124807
diff --git a/contrib/diffall/git-diffall b/contrib/diffall/git-diffall
deleted file mode 100755
index 84f2b65..000
--- a/contrib/diffall/git-diffall
+++ /dev/null
@@ -1,257 +0,0 @@
-#!/bin/sh
-# Copyright 2010 - 2012, Tim Henigan 
-#
-# Perform a directory diff between commits in the repository using
-# the external diff or merge tool specified in the user's config.
-
-USAGE='[--cached] [--copy-back] [-x|--extcmd=] {0,2} [-- 
*]
-
---cached Compare to the index rather than the working tree.
-
---copy-back  Copy files back to the working tree when the diff
- tool exits (in case they were modified by the
- user).  This option is only valid if the diff
- compared with the working tree.
-
--x=
---extcmd=  Specify a custom command for viewing diffs.
- git-diffall ignores the configured defaults and
- runs $command $LOCAL $REMOTE when this option is
- specified. Additionally, $BASE is set in the
- environment.
-'
-
-SUBDIRECTORY_OK=1
-. "$(git --exec-path)/git-sh-setup"
-
-TOOL_MODE=diff
-. "$(git --exec-path)/git-mergetool--lib"
-
-merge_tool="$(get_merge_tool)"
-if test -z "$merge_tool"
-then
-   echo "Error: Either the 'diff.tool' or 'merge.tool' option must be set."
-   usage
-fi
-
-start_dir=$(pwd)
-
-# All the file paths returned by the diff command are relative to the root
-# of the working copy. So if the script is called from a subdirectory, it
-# must switch to the root of working copy before trying to use those paths.
-cdup=$(git rev-parse --show-cdup) &&
-cd "$cdup" || {
-   echo >&2 "Cannot chdir to $cdup, the toplevel of the working tree"
-   exit 1
-}
-
-# set up temp dir
-tmp=$(perl -e 'use File::Temp qw(tempdir);
-   $t=tempdir("/tmp/git-diffall.X") or exit(1);
-   print $t') || exit 1
-trap 'rm -rf "$tmp"' EXIT
-
-left=
-right=
-paths=
-dashdash_seen=
-compare_staged=
-merge_base=
-left_dir=
-right_dir=
-diff_tool=
-copy_back=
-
-while test $# != 0
-do
-   case "$1" in
-   -h|--h|--he|--hel|--help)
-   usage
-   ;;
-   --cached)
-   compare_staged=1
-   ;;
-   

[ANNOUNCE] Git v1.9.3

[Junio C Hamano]

The latest maintenance release Git v1.9.3 is now available at
the usual places.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/testing/

The following public repositories will all have a copy of the
'v1.9.3' tag and the 'maint' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://code.google.com/p/git-core/
  url = git://git.sourceforge.jp/gitroot/git-core/git.git
  url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
  url = https://github.com/gitster/git

but I am cutting 2.0.0-rc3 today, so you may have to wait for a bit
until these repositories are updated.


Git v1.9.3 Release Notes


Fixes since v1.9.2
--

 * "git p4" dealing with changes in binary files were broken by a
   change in 1.9 release.

 * The shell prompt script (in contrib/), when using the PROMPT_COMMAND
   interface, used an unsafe construct when showing the branch name in
   $PS1.

 * "git rebase" used a POSIX shell construct FreeBSD /bin/sh does not
   work well with.

 * Some more Unicode codepoints defined in Unicode 6.3 as having
   zero width have been taught to our display column counting logic.

 * Some tests used shell constructs that did not work well on
   FreeBSD.



Changes since v1.9.2 are as follows:

Jonathan Nieder (1):
  shell doc: remove stray "+" in example

Junio C Hamano (2):
  Start preparing for 1.9.3
  Git 1.9.3

Kyle J. McKay (4):
  test: fix t7001 cp to use POSIX options
  test: fix t5560 on FreeBSD
  rebase: avoid non-function use of "return" on FreeBSD
  Revert "rebase: fix run_specific_rebase's use of "return" on FreeBSD"

Richard Hansen (1):
  git-prompt.sh: don't put unsanitized branch names in $PS1

Tolga Ceylan (1):
  git-p4: format-patch to diff-tree change breaks binary patches

Torsten Bögershausen (1):
  utf8.c: partially update to version 6.3

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

Re: [PATCH v2 01/17] contrib: remove outdated README

[Junio C Hamano]

Felipe Contreras  writes:

> There is no guideline as for what should be part of contrib.
>
> Some tools are actively maintained, others consist of a single commit.
> Some tools have active user-base, some aren't used by anyone. Some tools
> are on the path towards the core, others will never get there. Some
> tools are already out-of-tree and simply mirrored, others probably
> wouldn't survive out-of-tree. Some tools are production-ready, others
> don't even run. Some tools have tests, most don't.
>
> Junio has explained that he wrote this a long time ago, when Git was a
> different beast, now this no longer applies.
>
> The only way to find out if a tool belongs in contrib or not is to as
> Junio.
>
> Cc: Junio C Hamano 
> Signed-off-by: Felipe Contreras 
> ---

This is wrong.

The reason I suggested splitting remote-hg out of my tree does not
have anything to do with "removal of disused and inactive" described
in the document.  As written elsewhere, it was a response to

http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248457

where you said

I don't want to do anything for a "contrib" tool.

and in response I suggested that you have an option to make it a
standalone third-party project (and the other option being to stay
in contrib/ but then you have to work well with others just like
other contributors).  With the promotion to the core has already
been ruled out as not an ideal direction in the thread that begins
at this one:

http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248167

that is one of the only two alternatives I can offer.  Given that
the Git ecosystem has matured enough to let third-party tools
flourish on their own merit, if you do not want to work on a thing
in contrib/, that is now a more viable option than it used to be.

For tools that are happy to be in contrib/ and are still in use by
users, none of the above would apply.  And what the text says is
still perfectly valid.  There is nothing outdated in it.

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

Re: [PATCH v1 00/25] contrib: cleanup

[Johannes Sixt]

I know I'm late in the show, but can we please, PLEASE

  *NOT* feed the troll?

--
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: Pull is Mostly Evil

[Marc Branchaud]

After poking this hornet's nest I pretty much have stood back and not
participated in the ensuing discussions.  But having unleashed the hornets I
feel I should at least say something, if only to assure people that I'm not
ignoring their plight.

There have been various proposals to modify git-pull's defaults, and/or
extend it with new configuration settings, and/or add a new command.  As I
don't use "git pull" I feel I'm not in any position to comment about the
particulars of these proposals.

However I remain skeptical that these proposals, in any form, will really be
all that helpful to new users.  That's because in order to know whether or
not "git pull" (or "git update") does what the user wants, the user has to
understand the intricacies of both their own workflow and how git can work
within that workflow.  By the time a user gains that understanding, she is no
longer a new user.

Still, I do think the pull command is useful.  In particular I think that a
project can benefit greatly by tailoring pull's behaviour to match its
workflow, and that a project's participants can be told how to configure git
so that pull works properly for that project.  Maybe even such configuration
-- a "workflow blueprint" if you will -- can be tracked inside the project
itself, so that a fresh project clone can automatically have "git pull"
properly configured.   To me this seems like a fabulous feature for git.

But for now I go back to what I said before:  Give "git pull" enough knobs to
let people tailor it to their individual projects' needs.  But also disable
"git pull" by default, because nobody should run it until they've considered
how they want it to work.

M.

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

Re: [PATCH v2 04/17] contrib: remove 'diffall'

[Tim Henigan]

On Fri, May 9, 2014 at 12:11 PM, Felipe Contreras
 wrote:
> There is no more need for this tool since the --dir-dirr option was
> introduced.

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

Re: [PATCH v1 06/25] contrib: remove 'diffall'

[Tim Henigan]

Hi Jonathan,

On Fri, May 9, 2014 at 11:50 AM, Jonathan Nieder  wrote:
> Hi Tim,
>
> Tim Henigan wrote:
>> On Thu, May 8, 2014 at 5:58 PM, Felipe Contreras
>>  wrote:
>
>>>  contrib/diffall/README  |  31 --
>>>  contrib/diffall/git-diffall | 257 
>>> 
>>>  2 files changed, 288 deletions(-)
>>>  delete mode 100644 contrib/diffall/README
>>>  delete mode 100755 contrib/diffall/git-diffall
>>
>> I see no problem with removing this script from contrib.  However, the 
>> commit message
>> should mention that git-difftool learned all the features of git-diffall 
>> when the '--dir-diff'
>> option was added in v1.7.11 (ca. June 2012).
>
> A few questions:
>
>  * Do you still use git-diffall?  Since it hasn't been a maintenance
>burden, I wouldn't mind keeping it if it still has users.

I have not used diffall since a few months after the difftool '--dir-diff'
option was released.  Once difftool learned those features, the
diffall script became obsolete.

For people using older git (i.e. before v1.7.11), it may still be useful.
For them, the original out-of-tree repo remains available on github [1].

[1]: https://github.com/thenigan/git-diffall


>  * Any thoughts about how to help people who have been using it to
>migrate to difftool?  Would a note in the release notes to look
>into the --dir-diff option to difftool be enough, or are there
>more specific pointers that could be useful?

Pointing to 'difftool --dir-diff' should be enough.

The only change in behavior is that when a working tree file is part
of the diff and is modified during the diff, 'difftool --dir-diff' automatically
keeps the modifications.  The 'diffall' script required the user to use
the '--copy-back' option to do the same.

All other options are exactly the same.


> Once those questions are dealt with, this seems like a nice small
> cleanup.  Thanks for the quick feedback.

If it would be helpful, I can send a patch that replaces the contents
of 'contrib/diffall' with a README that explains the above and points
to the github repo for people using versions of git prior to v1.7.11.
This would be similar to what was done for 'contrib/vim'.

However, I like the idea of simply removing the directory from contrib
and pointing to 'difftool --dir-diff' in the release notes.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] Remove 'git archimport'

[Eric Wong]

Thomas Adam  wrote:
> I think I speak for everyone when I say: fuck off.

I wouldn't put it so harshly...

Felipe: I suggest you take a long vacation away from development.

Whatever good you may be able to contribute today is drowned out by your
behavior.  The projects you are involved with will get by fine without
you.

To help you with your vacation, I shall start ignoring you.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 17/17] contrib: remove 'contacts'

[Felipe Contreras]

There are better out-of-tree tools, and this tool is not planned to move
into the core anyway.

No tests either.

Cc: Eric Sunshine 
Signed-off-by: Felipe Contreras 
---
 contrib/contacts/git-contacts | 203 --
 contrib/contacts/git-contacts.txt |  94 --
 2 files changed, 297 deletions(-)
 delete mode 100755 contrib/contacts/git-contacts
 delete mode 100644 contrib/contacts/git-contacts.txt

diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
deleted file mode 100755
index dbe2abf..000
--- a/contrib/contacts/git-contacts
+++ /dev/null
@@ -1,203 +0,0 @@
-#!/usr/bin/perl
-
-# List people who might be interested in a patch.  Useful as the argument to
-# git-send-email --cc-cmd option, and in other situations.
-#
-# Usage: git contacts  ...
-
-use strict;
-use warnings;
-use IPC::Open2;
-
-my $since = '5-years-ago';
-my $min_percent = 10;
-my $labels_rx = qr/Signed-off-by|Reviewed-by|Acked-by|Cc/i;
-my %seen;
-
-sub format_contact {
-   my ($name, $email) = @_;
-   return "$name <$email>";
-}
-
-sub parse_commit {
-   my ($commit, $data) = @_;
-   my $contacts = $commit->{contacts};
-   my $inbody = 0;
-   for (split(/^/m, $data)) {
-   if (not $inbody) {
-   if (/^author ([^<>]+) <(\S+)> .+$/) {
-   $contacts->{format_contact($1, $2)} = 1;
-   } elsif (/^$/) {
-   $inbody = 1;
-   }
-   } elsif (/^$labels_rx:\s+([^<>]+)\s+<(\S+?)>$/o) {
-   $contacts->{format_contact($1, $2)} = 1;
-   }
-   }
-}
-
-sub import_commits {
-   my ($commits) = @_;
-   return unless %$commits;
-   my $pid = open2 my $reader, my $writer, qw(git cat-file --batch);
-   for my $id (keys(%$commits)) {
-   print $writer "$id\n";
-   my $line = <$reader>;
-   if ($line =~ /^([0-9a-f]{40}) commit (\d+)/) {
-   my ($cid, $len) = ($1, $2);
-   die "expected $id but got $cid\n" unless $id eq $cid;
-   my $data;
-   # cat-file emits newline after data, so read len+1
-   read $reader, $data, $len + 1;
-   parse_commit($commits->{$id}, $data);
-   }
-   }
-   close $reader;
-   close $writer;
-   waitpid($pid, 0);
-   die "git-cat-file error: $?\n" if $?;
-}
-
-sub get_blame {
-   my ($commits, $source, $from, $ranges) = @_;
-   return unless @$ranges;
-   open my $f, '-|',
-   qw(git blame --porcelain -C),
-   map({"-L$_->[0],+$_->[1]"} @$ranges),
-   '--since', $since, "$from^", '--', $source or die;
-   while (<$f>) {
-   if (/^([0-9a-f]{40}) \d+ \d+ \d+$/) {
-   my $id = $1;
-   $commits->{$id} = { id => $id, contacts => {} }
-   unless $seen{$id};
-   $seen{$id} = 1;
-   }
-   }
-   close $f;
-}
-
-sub blame_sources {
-   my ($sources, $commits) = @_;
-   for my $s (keys %$sources) {
-   for my $id (keys %{$sources->{$s}}) {
-   get_blame($commits, $s, $id, $sources->{$s}{$id});
-   }
-   }
-}
-
-sub scan_patches {
-   my ($sources, $id, $f) = @_;
-   my $source;
-   while (<$f>) {
-   if (/^From ([0-9a-f]{40}) Mon Sep 17 00:00:00 2001$/) {
-   $id = $1;
-   $seen{$id} = 1;
-   }
-   next unless $id;
-   if (m{^--- (?:a/(.+)|/dev/null)$}) {
-   $source = $1;
-   } elsif (/^@@ -(\d+)(?:,(\d+))?/ && $source) {
-   my $len = defined($2) ? $2 : 1;
-   push @{$sources->{$source}{$id}}, [$1, $len] if $len;
-   }
-   }
-}
-
-sub scan_patch_file {
-   my ($commits, $file) = @_;
-   open my $f, '<', $file or die "read failure: $file: $!\n";
-   scan_patches($commits, undef, $f);
-   close $f;
-}
-
-sub parse_rev_args {
-   my @args = @_;
-   open my $f, '-|',
-   qw(git rev-parse --revs-only --default HEAD --symbolic), @args
-   or die;
-   my @revs;
-   while (<$f>) {
-   chomp;
-   push @revs, $_;
-   }
-   close $f;
-   return @revs if scalar(@revs) != 1;
-   return "^$revs[0]", 'HEAD' unless $revs[0] =~ /^-/;
-   return $revs[0], 'HEAD';
-}
-
-sub scan_rev_args {
-   my ($commits, $args) = @_;
-   my @revs = parse_rev_args(@$args);
-   open my $f, '-|', qw(git rev-list --reverse), @revs or die;
-   while (<$f>) {
-   chomp;
-   my $id = $_;
-   $seen{$id} = 1;
-   open my $g, '-|', qw(git show -C --o

[PATCH v2 16/17] contrib: remove 'git-resurrect'

[Felipe Contreras]

No activity, no documentation, no tests, no chance of ever graduating.

Signed-off-by: Felipe Contreras 
---
 contrib/git-resurrect.sh | 182 ---
 1 file changed, 182 deletions(-)
 delete mode 100755 contrib/git-resurrect.sh

diff --git a/contrib/git-resurrect.sh b/contrib/git-resurrect.sh
deleted file mode 100755
index d7e97bb..000
--- a/contrib/git-resurrect.sh
+++ /dev/null
@@ -1,182 +0,0 @@
-#!/bin/sh
-
-USAGE="[-a] [-r] [-m] [-t] [-n] [-b ] "
-LONG_USAGE="git-resurrect attempts to find traces of a branch tip
-called , and tries to resurrect it.  Currently, the reflog is
-searched for checkout messages, and with -r also merge messages.  With
--m and -t, the history of all refs is scanned for Merge  into
-other/Merge  into  (respectively) commit subjects, which
-is rather slow but allows you to resurrect other people's topic
-branches."
-
-OPTIONS_KEEPDASHDASH=
-OPTIONS_STUCKLONG=
-OPTIONS_SPEC="\
-git resurrect $USAGE
---
-b,branch=save branch as  instead of 
-a,allsame as -l -r -m -t
-k,keep-going full rev-list scan (instead of first match)
-l,reflog scan reflog for checkouts (enabled by default)
-r,reflog-merges  scan for merges recorded in reflog
-m,merges scan for merges into other branches (slow)
-t,merge-targets  scan for merges of other branches into 
-n,dry-rundon't recreate the branch"
-
-. git-sh-setup
-
-search_reflog () {
-sed -ne 's~^\([^ ]*\) .*\tcheckout: moving from '"$1"' .*~\1~p' \
-< "$GIT_DIR"/logs/HEAD
-}
-
-search_reflog_merges () {
-   git rev-parse $(
-   sed -ne 's~^[^ ]* \([^ ]*\) .*\tmerge '"$1"':.*~\1^2~p' \
-   < "$GIT_DIR"/logs/HEAD
-   )
-}
-
-_x40="[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]"
-_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
-
-search_merges () {
-git rev-list --all --grep="Merge branch '$1'" \
---pretty=tformat:"%P %s" |
-sed -ne "/^$_x40 \($_x40\) Merge .*/ {s//\1/p;$early_exit}"
-}
-
-search_merge_targets () {
-   git rev-list --all --grep="Merge branch '[^']*' into $branch\$" \
-   --pretty=tformat:"%H %s" --all |
-   sed -ne "/^\($_x40\) Merge .*/ {s//\1/p;$early_exit} "
-}
-
-dry_run=
-early_exit=q
-scan_reflog=t
-scan_reflog_merges=
-scan_merges=
-scan_merge_targets=
-new_name=
-
-while test "$#" != 0; do
-   case "$1" in
-   -b|--branch)
-   shift
-   new_name="$1"
-   ;;
-   -n|--dry-run)
-   dry_run=t
-   ;;
-   --no-dry-run)
-   dry_run=
-   ;;
-   -k|--keep-going)
-   early_exit=
-   ;;
-   --no-keep-going)
-   early_exit=q
-   ;;
-   -m|--merges)
-   scan_merges=t
-   ;;
-   --no-merges)
-   scan_merges=
-   ;;
-   -l|--reflog)
-   scan_reflog=t
-   ;;
-   --no-reflog)
-   scan_reflog=
-   ;;
-   -r|--reflog_merges)
-   scan_reflog_merges=t
-   ;;
-   --no-reflog_merges)
-   scan_reflog_merges=
-   ;;
-   -t|--merge-targets)
-   scan_merge_targets=t
-   ;;
-   --no-merge-targets)
-   scan_merge_targets=
-   ;;
-   -a|--all)
-   scan_reflog=t
-   scan_reflog_merges=t
-   scan_merges=t
-   scan_merge_targets=t
-   ;;
-   --)
-   shift
-   break
-   ;;
-   *)
-   usage
-   ;;
-   esac
-   shift
-done
-
-test "$#" = 1 || usage
-
-all_strategies="$scan_reflog$scan_reflog_merges$scan_merges$scan_merge_targets"
-if test -z "$all_strategies"; then
-   die "must enable at least one of -lrmt"
-fi
-
-branch="$1"
-test -z "$new_name" && new_name="$branch"
-
-if test ! -z "$scan_reflog"; then
-   if test -r "$GIT_DIR"/logs/HEAD; then
-   candidates="$(search_reflog $branch)"
-   else
-   die 'reflog scanning requested, but' \
-   '$GIT_DIR/logs/HEAD not readable'
-   fi
-fi
-if test ! -z "$scan_reflog_merges"; then
-   if test -r "$GIT_DIR"/logs/HEAD; then
-   candidates="$candidates $(search_reflog_merges $branch)"
-   else
-   die 'reflog scanning requested, but' \
-   '$GIT_DIR/logs/HEAD not readable'
-   fi
-fi
-if test ! -z "$scan_merges"; then
-   candidates="$candidates $(search_merges $branch)"
-fi
-if test ! -z "$scan_merge_targets"; then
-   candidates="$candidates $(search_merge_targets $branch)"
-fi
-
-candidates="$(git rev-parse $candidates | sort -u)"
-
-if test -z "$candidates"; then
-   hint=
-   test 

[PATCH v2 15/17] contrib: remove 'persistent-https'

[Felipe Contreras]

No activity. No tests.

No chance of ever moving into the core because it uses Go.

Cc: Colby Ranger 
Signed-off-by: Felipe Contreras 
---
 contrib/persistent-https/LICENSE   | 202 -
 contrib/persistent-https/Makefile  |  38 ---
 contrib/persistent-https/README|  62 
 contrib/persistent-https/client.go | 189 --
 contrib/persistent-https/main.go   |  82 ---
 contrib/persistent-https/proxy.go  | 190 --
 contrib/persistent-https/socket.go |  97 --
 7 files changed, 860 deletions(-)
 delete mode 100644 contrib/persistent-https/LICENSE
 delete mode 100644 contrib/persistent-https/Makefile
 delete mode 100644 contrib/persistent-https/README
 delete mode 100644 contrib/persistent-https/client.go
 delete mode 100644 contrib/persistent-https/main.go
 delete mode 100644 contrib/persistent-https/proxy.go
 delete mode 100644 contrib/persistent-https/socket.go

diff --git a/contrib/persistent-https/LICENSE b/contrib/persistent-https/LICENSE
deleted file mode 100644
index d645695..000
--- a/contrib/persistent-https/LICENSE
+++ /dev/null
@@ -1,202 +0,0 @@
-
- Apache License
-   Version 2.0, January 2004
-http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-  "License" shall mean the terms and conditions for use, reproduction,
-  and distribution as defined by Sections 1 through 9 of this document.
-
-  "Licensor" shall mean the copyright owner or entity authorized by
-  the copyright owner that is granting the License.
-
-  "Legal Entity" shall mean the union of the acting entity and all
-  other entities that control, are controlled by, or are under common
-  control with that entity. For the purposes of this definition,
-  "control" means (i) the power, direct or indirect, to cause the
-  direction or management of such entity, whether by contract or
-  otherwise, or (ii) ownership of fifty percent (50%) or more of the
-  outstanding shares, or (iii) beneficial ownership of such entity.
-
-  "You" (or "Your") shall mean an individual or Legal Entity
-  exercising permissions granted by this License.
-
-  "Source" form shall mean the preferred form for making modifications,
-  including but not limited to software source code, documentation
-  source, and configuration files.
-
-  "Object" form shall mean any form resulting from mechanical
-  transformation or translation of a Source form, including but
-  not limited to compiled object code, generated documentation,
-  and conversions to other media types.
-
-  "Work" shall mean the work of authorship, whether in Source or
-  Object form, made available under the License, as indicated by a
-  copyright notice that is included in or attached to the work
-  (an example is provided in the Appendix below).
-
-  "Derivative Works" shall mean any work, whether in Source or Object
-  form, that is based on (or derived from) the Work and for which the
-  editorial revisions, annotations, elaborations, or other modifications
-  represent, as a whole, an original work of authorship. For the purposes
-  of this License, Derivative Works shall not include works that remain
-  separable from, or merely link (or bind by name) to the interfaces of,
-  the Work and Derivative Works thereof.
-
-  "Contribution" shall mean any work of authorship, including
-  the original version of the Work and any modifications or additions
-  to that Work or Derivative Works thereof, that is intentionally
-  submitted to Licensor for inclusion in the Work by the copyright owner
-  or by an individual or Legal Entity authorized to submit on behalf of
-  the copyright owner. For the purposes of this definition, "submitted"
-  means any form of electronic, verbal, or written communication sent
-  to the Licensor or its representatives, including but not limited to
-  communication on electronic mailing lists, source code control systems,
-  and issue tracking systems that are managed by, or on behalf of, the
-  Licensor for the purpose of discussing and improving the Work, but
-  excluding communication that is conspicuously marked or otherwise
-  designated in writing by the copyright owner as "Not a Contribution."
-
-  "Contributor" shall mean Licensor and any individual or Legal Entity
-  on behalf of whom a Contribution has been received by Licensor and
-  subsequently incorporated within the Work.
-
-   2. Grant of Copyright License. Subject to the terms and conditions of
-  this License, each Contributor hereby grants to You a perpetual,
-  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-

[PATCH v2 13/17] contrib: remove 'rerere-train'

[Felipe Contreras]

No activity, no nothing.

Signed-off-by: Felipe Contreras 
---
 contrib/rerere-train.sh | 52 -
 1 file changed, 52 deletions(-)
 delete mode 100755 contrib/rerere-train.sh

diff --git a/contrib/rerere-train.sh b/contrib/rerere-train.sh
deleted file mode 100755
index 36b6fee..000
--- a/contrib/rerere-train.sh
+++ /dev/null
@@ -1,52 +0,0 @@
-#!/bin/sh
-# Copyright (c) 2008, Nanako Shiraishi
-# Prime rerere database from existing merge commits
-
-me=rerere-train
-USAGE="$me rev-list-args"
-
-SUBDIRECTORY_OK=Yes
-OPTIONS_SPEC=
-. $(git --exec-path)/git-sh-setup
-require_work_tree
-cd_to_toplevel
-
-# Remember original branch
-branch=$(git symbolic-ref -q HEAD) ||
-original_HEAD=$(git rev-parse --verify HEAD) || {
-   echo >&2 "Not on any branch and no commit yet?"
-   exit 1
-}
-
-mkdir -p "$GIT_DIR/rr-cache" || exit
-
-git rev-list --parents "$@" |
-while read commit parent1 other_parents
-do
-   if test -z "$other_parents"
-   then
-   # Skip non-merges
-   continue
-   fi
-   git checkout -q "$parent1^0"
-   if git merge $other_parents >/dev/null 2>&1
-   then
-   # Cleanly merges
-   continue
-   fi
-   if test -s "$GIT_DIR/MERGE_RR"
-   then
-   git show -s --pretty=format:"Learning from %h %s" "$commit"
-   git rerere
-   git checkout -q $commit -- .
-   git rerere
-   fi
-   git reset -q --hard
-done
-
-if test -z "$branch"
-then
-   git checkout "$original_HEAD"
-else
-   git checkout "${branch#refs/heads/}"
-fi
-- 
1.9.2+fc1.28.g12374c0

--
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 12/17] contrib: remove 'svn-fe'

[Felipe Contreras]

No activity since 2012, no tests.

Cc: Jonathan Nieder 
Signed-off-by: Felipe Contreras 
---
 contrib/svn-fe/.gitignore  |  4 ---
 contrib/svn-fe/Makefile| 63 -
 contrib/svn-fe/svn-fe.c| 18 ---
 contrib/svn-fe/svn-fe.txt  | 71 --
 contrib/svn-fe/svnrdump_sim.py | 57 -
 5 files changed, 213 deletions(-)
 delete mode 100644 contrib/svn-fe/.gitignore
 delete mode 100644 contrib/svn-fe/Makefile
 delete mode 100644 contrib/svn-fe/svn-fe.c
 delete mode 100644 contrib/svn-fe/svn-fe.txt
 delete mode 100755 contrib/svn-fe/svnrdump_sim.py

diff --git a/contrib/svn-fe/.gitignore b/contrib/svn-fe/.gitignore
deleted file mode 100644
index 02a7791..000
--- a/contrib/svn-fe/.gitignore
+++ /dev/null
@@ -1,4 +0,0 @@
-/*.xml
-/*.1
-/*.html
-/svn-fe
diff --git a/contrib/svn-fe/Makefile b/contrib/svn-fe/Makefile
deleted file mode 100644
index 360d8da..000
--- a/contrib/svn-fe/Makefile
+++ /dev/null
@@ -1,63 +0,0 @@
-all:: svn-fe$X
-
-CC = gcc
-RM = rm -f
-MV = mv
-
-CFLAGS = -g -O2 -Wall
-LDFLAGS =
-ALL_CFLAGS = $(CFLAGS)
-ALL_LDFLAGS = $(LDFLAGS)
-EXTLIBS =
-
-GIT_LIB = ../../libgit.a
-VCSSVN_LIB = ../../vcs-svn/lib.a
-LIBS = $(VCSSVN_LIB) $(GIT_LIB) $(EXTLIBS)
-
-QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
-QUIET_SUBDIR1 =
-
-ifneq ($(findstring $(MAKEFLAGS),w),w)
-PRINT_DIR = --no-print-directory
-else # "make -w"
-NO_SUBDIR = :
-endif
-
-ifneq ($(findstring $(MAKEFLAGS),s),s)
-ifndef V
-   QUIET_CC  = @echo '   ' CC $@;
-   QUIET_LINK= @echo '   ' LINK $@;
-   QUIET_SUBDIR0 = +@subdir=
-   QUIET_SUBDIR1 = ;$(NO_SUBDIR) echo '   ' SUBDIR $$subdir; \
-   $(MAKE) $(PRINT_DIR) -C $$subdir
-endif
-endif
-
-svn-fe$X: svn-fe.o $(VCSSVN_LIB) $(GIT_LIB)
-   $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ svn-fe.o \
-   $(ALL_LDFLAGS) $(LIBS)
-
-svn-fe.o: svn-fe.c ../../vcs-svn/svndump.h
-   $(QUIET_CC)$(CC) -I../../vcs-svn -o $*.o -c $(ALL_CFLAGS) $<
-
-svn-fe.html: svn-fe.txt
-   $(QUIET_SUBDIR0)../../Documentation $(QUIET_SUBDIR1) \
-   MAN_TXT=../contrib/svn-fe/svn-fe.txt \
-   ../contrib/svn-fe/$@
-
-svn-fe.1: svn-fe.txt
-   $(QUIET_SUBDIR0)../../Documentation $(QUIET_SUBDIR1) \
-   MAN_TXT=../contrib/svn-fe/svn-fe.txt \
-   ../contrib/svn-fe/$@
-   $(MV) ../../Documentation/svn-fe.1 .
-
-../../vcs-svn/lib.a: FORCE
-   $(QUIET_SUBDIR0)../.. $(QUIET_SUBDIR1) vcs-svn/lib.a
-
-../../libgit.a: FORCE
-   $(QUIET_SUBDIR0)../.. $(QUIET_SUBDIR1) libgit.a
-
-clean:
-   $(RM) svn-fe$X svn-fe.o svn-fe.html svn-fe.xml svn-fe.1
-
-.PHONY: all clean FORCE
diff --git a/contrib/svn-fe/svn-fe.c b/contrib/svn-fe/svn-fe.c
deleted file mode 100644
index f363505..000
--- a/contrib/svn-fe/svn-fe.c
+++ /dev/null
@@ -1,18 +0,0 @@
-/*
- * This file is in the public domain.
- * You may freely use, modify, distribute, and relicense it.
- */
-
-#include 
-#include "svndump.h"
-
-int main(int argc, char **argv)
-{
-   if (svndump_init(NULL))
-   return 1;
-   svndump_read((argc > 1) ? argv[1] : NULL, "refs/heads/master",
-   "refs/notes/svn/revs");
-   svndump_deinit();
-   svndump_reset();
-   return 0;
-}
diff --git a/contrib/svn-fe/svn-fe.txt b/contrib/svn-fe/svn-fe.txt
deleted file mode 100644
index a3425f4..000
--- a/contrib/svn-fe/svn-fe.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-svn-fe(1)
-=
-
-NAME
-
-svn-fe - convert an SVN "dumpfile" to a fast-import stream
-
-SYNOPSIS
-
-[verse]
-mkfifo backchannel &&
-svnadmin dump --deltas REPO |
-   svn-fe [url] 3backchannel
-
-DESCRIPTION

-
-Converts a Subversion dumpfile into input suitable for
-git-fast-import(1) and similar importers. REPO is a path to a
-Subversion repository mirrored on the local disk. Remote Subversion
-repositories can be mirrored on local disk using the `svnsync`
-command.
-
-Note: this tool is very young.  The details of its commandline
-interface may change in backward incompatible ways.
-
-INPUT FORMAT
-
-Subversion's repository dump format is documented in full in
-`notes/dump-load-format.txt` from the Subversion source tree.
-Files in this format can be generated using the 'svnadmin dump' or
-'svk admin dump' command.
-
-OUTPUT FORMAT
--
-The fast-import format is documented by the git-fast-import(1)
-manual page.
-
-NOTES
--
-Subversion dumps do not record a separate author and committer for
-each revision, nor do they record a separate display name and email
-address for each author.  Like git-svn(1), 'svn-fe' will use the name
-
--
-user 
--
-
-as committer, where 'user' is the value of the `svn:author` property
-and 'UUID' the repository's identifier.
-
-To support incremental imports, 'svn-fe' puts a `git-svn-id` line at
-the end of each commit log messa

[PATCH v2 09/17] contrib: remove 'git-shell-commands'

[Felipe Contreras]

No activity, no tests.

Signed-off-by: Felipe Contreras 
---
 contrib/git-shell-commands/README | 18 --
 contrib/git-shell-commands/help   | 18 --
 contrib/git-shell-commands/list   | 10 --
 3 files changed, 46 deletions(-)
 delete mode 100644 contrib/git-shell-commands/README
 delete mode 100755 contrib/git-shell-commands/help
 delete mode 100755 contrib/git-shell-commands/list

diff --git a/contrib/git-shell-commands/README 
b/contrib/git-shell-commands/README
deleted file mode 100644
index 438463b..000
--- a/contrib/git-shell-commands/README
+++ /dev/null
@@ -1,18 +0,0 @@
-Sample programs callable through git-shell.  Place a directory named
-'git-shell-commands' in the home directory of a user whose shell is
-git-shell.  Then anyone logging in as that user will be able to run
-executables in the 'git-shell-commands' directory.
-
-Provided commands:
-
-help: Prints out the names of available commands.  When run
-interactively, git-shell will automatically run 'help' on startup,
-provided it exists.
-
-list: Displays any bare repository whose name ends with ".git" under
-user's home directory.  No other git repositories are visible,
-although they might be clonable through git-shell.  'list' is designed
-to minimize the number of calls to git that must be made in finding
-available repositories; if your setup has additional repositories that
-should be user-discoverable, you may wish to modify 'list'
-accordingly.
diff --git a/contrib/git-shell-commands/help b/contrib/git-shell-commands/help
deleted file mode 100755
index 535770c..000
--- a/contrib/git-shell-commands/help
+++ /dev/null
@@ -1,18 +0,0 @@
-#!/bin/sh
-
-if tty -s
-then
-   echo "Run 'help' for help, or 'exit' to leave.  Available commands:"
-else
-   echo "Run 'help' for help.  Available commands:"
-fi
-
-cd "$(dirname "$0")"
-
-for cmd in *
-do
-   case "$cmd" in
-   help) ;;
-   *) [ -f "$cmd" ] && [ -x "$cmd" ] && echo "$cmd" ;;
-   esac
-done
diff --git a/contrib/git-shell-commands/list b/contrib/git-shell-commands/list
deleted file mode 100755
index 6f89938..000
--- a/contrib/git-shell-commands/list
+++ /dev/null
@@ -1,10 +0,0 @@
-#!/bin/sh
-
-print_if_bare_repo='
-   if "$(git --git-dir="$1" rev-parse --is-bare-repository)" = true
-   then
-   printf "%s\n" "${1#./}"
-   fi
-'
-
-find -type d -name "*.git" -exec sh -c "$print_if_bare_repo" -- \{} \; -prune 
2>/dev/null
-- 
1.9.2+fc1.28.g12374c0

--
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 14/17] contrib: remove 'remotes2config'

[Felipe Contreras]

No activity since 2007. No documentation, no tests.

Signed-off-by: Felipe Contreras 
---
 contrib/remotes2config.sh | 33 -
 1 file changed, 33 deletions(-)
 delete mode 100755 contrib/remotes2config.sh

diff --git a/contrib/remotes2config.sh b/contrib/remotes2config.sh
deleted file mode 100755
index 1cda19f..000
--- a/contrib/remotes2config.sh
+++ /dev/null
@@ -1,33 +0,0 @@
-#!/bin/sh
-
-# Use this tool to rewrite your .git/remotes/ files into the config.
-
-. git-sh-setup
-
-if [ -d "$GIT_DIR"/remotes ]; then
-   echo "Rewriting $GIT_DIR/remotes" >&2
-   error=0
-   # rewrite into config
-   {
-   cd "$GIT_DIR"/remotes
-   ls | while read f; do
-   name=$(printf "$f" | tr -c "A-Za-z0-9-" ".")
-   sed -n \
-   -e "s/^URL:[]*\(.*\)$/remote.$name.url \1 ./p" \
-   -e "s/^Pull:[   ]*\(.*\)$/remote.$name.fetch \1 ^$ /p" \
-   -e "s/^Push:[   ]*\(.*\)$/remote.$name.push \1 ^$ /p" \
-   < "$f"
-   done
-   echo done
-   } | while read key value regex; do
-   case $key in
-   done)
-   if [ $error = 0 ]; then
-   mv "$GIT_DIR"/remotes "$GIT_DIR"/remotes.old
-   fi ;;
-   *)
-   echo "git config $key "$value" $regex"
-   git config $key "$value" $regex || error=1 ;;
-   esac
-   done
-fi
-- 
1.9.2+fc1.28.g12374c0

--
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 10/17] contrib: reomve 'thunderbird-patch-inline'

[Felipe Contreras]

No activity, no tests.

Signed-off-by: Felipe Contreras 
---
 contrib/thunderbird-patch-inline/README  | 20 
 contrib/thunderbird-patch-inline/appp.sh | 55 
 2 files changed, 75 deletions(-)
 delete mode 100644 contrib/thunderbird-patch-inline/README
 delete mode 100755 contrib/thunderbird-patch-inline/appp.sh

diff --git a/contrib/thunderbird-patch-inline/README 
b/contrib/thunderbird-patch-inline/README
deleted file mode 100644
index 000147b..000
--- a/contrib/thunderbird-patch-inline/README
+++ /dev/null
@@ -1,20 +0,0 @@
-appp.sh is a script that is supposed to be used together with ExternalEditor
-for Mozilla Thunderbird. It will let you include patches inline in e-mails
-in an easy way.
-
-Usage:
-- Generate the patch with git format-patch.
-- Start writing a new e-mail in Thunderbird.
-- Press the external editor button (or Ctrl-E) to run appp.sh
-- Select the previously generated patch file.
-- Finish editing the e-mail.
-
-Any text that is entered into the message editor before appp.sh is called
-will be moved to the section between the --- and the diffstat.
-
-All S-O-B:s and Cc:s in the patch will be added to the CC list.
-
-To set it up, just install External Editor and tell it to use appp.sh as the
-editor.
-
-Zenity is a required dependency.
diff --git a/contrib/thunderbird-patch-inline/appp.sh 
b/contrib/thunderbird-patch-inline/appp.sh
deleted file mode 100755
index 8dc73ec..000
--- a/contrib/thunderbird-patch-inline/appp.sh
+++ /dev/null
@@ -1,55 +0,0 @@
-#!/bin/sh
-# Copyright 2008 Lukas Sandström 
-#
-# AppendPatch - A script to be used together with ExternalEditor
-# for Mozilla Thunderbird to properly include patches inline in e-mails.
-
-# ExternalEditor can be downloaded at http://globs.org/articles.php?lng=en&pg=2
-
-CONFFILE=~/.appprc
-
-SEP="-=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=-"
-if [ -e "$CONFFILE" ] ; then
-   LAST_DIR=$(grep -m 1 "^LAST_DIR=" "${CONFFILE}"|sed -e 's/^LAST_DIR=//')
-   cd "${LAST_DIR}"
-else
-   cd > /dev/null
-fi
-
-PATCH=$(zenity --file-selection)
-
-if [ "$?" != "0" ] ; then
-   #zenity --error --text "No patchfile given."
-   exit 1
-fi
-
-cd - > /dev/null
-
-SUBJECT=$(sed -n -e '/^Subject: /p' "${PATCH}")
-HEADERS=$(sed -e '/^'"${SEP}"'$/,$d' $1)
-BODY=$(sed -e "1,/${SEP}/d" $1)
-CMT_MSG=$(sed -e '1,/^$/d' -e '/^---$/,$d' "${PATCH}")
-DIFF=$(sed -e '1,/^---$/d' "${PATCH}")
-
-CCS=`echo -e "$CMT_MSG\n$HEADERS" | sed -n -e 's/^Cc: \(.*\)$/\1,/gp' \
-   -e 's/^Signed-off-by: \(.*\)/\1,/gp'`
-
-echo "$SUBJECT" > $1
-echo "Cc: $CCS" >> $1
-echo "$HEADERS" | sed -e '/^Subject: /d' -e '/^Cc: /d' >> $1
-echo "$SEP" >> $1
-
-echo "$CMT_MSG" >> $1
-echo "---" >> $1
-if [ "x${BODY}x" != "xx" ] ; then
-   echo >> $1
-   echo "$BODY" >> $1
-   echo >> $1
-fi
-echo "$DIFF" >> $1
-
-LAST_DIR=$(dirname "${PATCH}")
-
-grep -v "^LAST_DIR=" "${CONFFILE}" > "${CONFFILE}_"
-echo "LAST_DIR=${LAST_DIR}" >> "${CONFFILE}_"
-mv "${CONFFILE}_" "${CONFFILE}"
-- 
1.9.2+fc1.28.g12374c0

--
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 08/17] contrib: remove 'convert-objects'

[Felipe Contreras]

No activity since 2010, no tests, no documentation.

Signed-off-by: Felipe Contreras 
---
 contrib/convert-objects/convert-objects.c   | 329 
 contrib/convert-objects/git-convert-objects.txt |  29 ---
 2 files changed, 358 deletions(-)
 delete mode 100644 contrib/convert-objects/convert-objects.c
 delete mode 100644 contrib/convert-objects/git-convert-objects.txt

diff --git a/contrib/convert-objects/convert-objects.c 
b/contrib/convert-objects/convert-objects.c
deleted file mode 100644
index f3b57bf..000
--- a/contrib/convert-objects/convert-objects.c
+++ /dev/null
@@ -1,329 +0,0 @@
-#include "cache.h"
-#include "blob.h"
-#include "commit.h"
-#include "tree.h"
-
-struct entry {
-   unsigned char old_sha1[20];
-   unsigned char new_sha1[20];
-   int converted;
-};
-
-#define MAXOBJECTS (100)
-
-static struct entry *convert[MAXOBJECTS];
-static int nr_convert;
-
-static struct entry * convert_entry(unsigned char *sha1);
-
-static struct entry *insert_new(unsigned char *sha1, int pos)
-{
-   struct entry *new = xcalloc(1, sizeof(struct entry));
-   hashcpy(new->old_sha1, sha1);
-   memmove(convert + pos + 1, convert + pos, (nr_convert - pos) * 
sizeof(struct entry *));
-   convert[pos] = new;
-   nr_convert++;
-   if (nr_convert == MAXOBJECTS)
-   die("you're kidding me - hit maximum object limit");
-   return new;
-}
-
-static struct entry *lookup_entry(unsigned char *sha1)
-{
-   int low = 0, high = nr_convert;
-
-   while (low < high) {
-   int next = (low + high) / 2;
-   struct entry *n = convert[next];
-   int cmp = hashcmp(sha1, n->old_sha1);
-   if (!cmp)
-   return n;
-   if (cmp < 0) {
-   high = next;
-   continue;
-   }
-   low = next+1;
-   }
-   return insert_new(sha1, low);
-}
-
-static void convert_binary_sha1(void *buffer)
-{
-   struct entry *entry = convert_entry(buffer);
-   hashcpy(buffer, entry->new_sha1);
-}
-
-static void convert_ascii_sha1(void *buffer)
-{
-   unsigned char sha1[20];
-   struct entry *entry;
-
-   if (get_sha1_hex(buffer, sha1))
-   die("expected sha1, got '%s'", (char *) buffer);
-   entry = convert_entry(sha1);
-   memcpy(buffer, sha1_to_hex(entry->new_sha1), 40);
-}
-
-static unsigned int convert_mode(unsigned int mode)
-{
-   unsigned int newmode;
-
-   newmode = mode & S_IFMT;
-   if (S_ISREG(mode))
-   newmode |= (mode & 0100) ? 0755 : 0644;
-   return newmode;
-}
-
-static int write_subdirectory(void *buffer, unsigned long size, const char 
*base, int baselen, unsigned char *result_sha1)
-{
-   char *new = xmalloc(size);
-   unsigned long newlen = 0;
-   unsigned long used;
-
-   used = 0;
-   while (size) {
-   int len = 21 + strlen(buffer);
-   char *path = strchr(buffer, ' ');
-   unsigned char *sha1;
-   unsigned int mode;
-   char *slash, *origpath;
-
-   if (!path || strtoul_ui(buffer, 8, &mode))
-   die("bad tree conversion");
-   mode = convert_mode(mode);
-   path++;
-   if (memcmp(path, base, baselen))
-   break;
-   origpath = path;
-   path += baselen;
-   slash = strchr(path, '/');
-   if (!slash) {
-   newlen += sprintf(new + newlen, "%o %s", mode, path);
-   new[newlen++] = '\0';
-   hashcpy((unsigned char *)new + newlen, (unsigned char 
*) buffer + len - 20);
-   newlen += 20;
-
-   used += len;
-   size -= len;
-   buffer = (char *) buffer + len;
-   continue;
-   }
-
-   newlen += sprintf(new + newlen, "%o %.*s", S_IFDIR, (int)(slash 
- path), path);
-   new[newlen++] = 0;
-   sha1 = (unsigned char *)(new + newlen);
-   newlen += 20;
-
-   len = write_subdirectory(buffer, size, origpath, 
slash-origpath+1, sha1);
-
-   used += len;
-   size -= len;
-   buffer = (char *) buffer + len;
-   }
-
-   write_sha1_file(new, newlen, tree_type, result_sha1);
-   free(new);
-   return used;
-}
-
-static void convert_tree(void *buffer, unsigned long size, unsigned char 
*result_sha1)
-{
-   void *orig_buffer = buffer;
-   unsigned long orig_size = size;
-
-   while (size) {
-   size_t len = 1+strlen(buffer);
-
-   convert_binary_sha1((char *) buffer + len);
-
-   len += 20;
-   if (len > size)
-   die("corrupt tree object");
-   size -= len;
-   buffer

[PATCH v2 11/17] contrib: remove 'workdir'

[Felipe Contreras]

No activity since 2010, no documentation, no tests.

Signed-off-by: Felipe Contreras 
---
 contrib/workdir/git-new-workdir | 82 -
 1 file changed, 82 deletions(-)
 delete mode 100755 contrib/workdir/git-new-workdir

diff --git a/contrib/workdir/git-new-workdir b/contrib/workdir/git-new-workdir
deleted file mode 100755
index 75e8b25..000
--- a/contrib/workdir/git-new-workdir
+++ /dev/null
@@ -1,82 +0,0 @@
-#!/bin/sh
-
-usage () {
-   echo "usage:" $@
-   exit 127
-}
-
-die () {
-   echo $@
-   exit 128
-}
-
-if test $# -lt 2 || test $# -gt 3
-then
-   usage "$0   []"
-fi
-
-orig_git=$1
-new_workdir=$2
-branch=$3
-
-# want to make sure that what is pointed to has a .git directory ...
-git_dir=$(cd "$orig_git" 2>/dev/null &&
-  git rev-parse --git-dir 2>/dev/null) ||
-  die "Not a git repository: \"$orig_git\""
-
-case "$git_dir" in
-.git)
-   git_dir="$orig_git/.git"
-   ;;
-.)
-   git_dir=$orig_git
-   ;;
-esac
-
-# don't link to a configured bare repository
-isbare=$(git --git-dir="$git_dir" config --bool --get core.bare)
-if test ztrue = z$isbare
-then
-   die "\"$git_dir\" has core.bare set to true," \
-   " remove from \"$git_dir/config\" to use $0"
-fi
-
-# don't link to a workdir
-if test -h "$git_dir/config"
-then
-   die "\"$orig_git\" is a working directory only, please specify" \
-   "a complete repository."
-fi
-
-# don't recreate a workdir over an existing repository
-if test -e "$new_workdir"
-then
-   die "destination directory '$new_workdir' already exists."
-fi
-
-# make sure the links use full paths
-git_dir=$(cd "$git_dir"; pwd)
-
-# create the workdir
-mkdir -p "$new_workdir/.git" || die "unable to create \"$new_workdir\"!"
-
-# create the links to the original repo.  explicitly exclude index, HEAD and
-# logs/HEAD from the list since they are purely related to the current working
-# directory, and should not be shared.
-for x in config refs logs/refs objects info hooks packed-refs remotes rr-cache 
svn
-do
-   case $x in
-   */*)
-   mkdir -p "$(dirname "$new_workdir/.git/$x")"
-   ;;
-   esac
-   ln -s "$git_dir/$x" "$new_workdir/.git/$x"
-done
-
-# now setup the workdir
-cd "$new_workdir"
-# copy the HEAD from the original repository as a default branch
-cp "$git_dir/HEAD" .git/HEAD
-# checkout the branch (either the same as HEAD from the original repository, or
-# the one that was asked for)
-git checkout -f $branch
-- 
1.9.2+fc1.28.g12374c0

--
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 04/17] contrib: remove 'diffall'

[Felipe Contreras]

There is no more need for this tool since the --dir-dirr option was
introduced.

Cc: Tim Henigan 
Signed-off-by: Felipe Contreras 
---
 contrib/diffall/README  |  31 --
 contrib/diffall/git-diffall | 257 
 2 files changed, 288 deletions(-)
 delete mode 100644 contrib/diffall/README
 delete mode 100755 contrib/diffall/git-diffall

diff --git a/contrib/diffall/README b/contrib/diffall/README
deleted file mode 100644
index 507f17d..000
--- a/contrib/diffall/README
+++ /dev/null
@@ -1,31 +0,0 @@
-The git-diffall script provides a directory based diff mechanism
-for git.
-
-To determine what diff viewer is used, the script requires either
-the 'diff.tool' or 'merge.tool' configuration option to be set.
-
-This script is compatible with most common forms used to specify a
-range of revisions to diff:
-
-  1. git diffall: shows diff between working tree and staged changes
-  2. git diffall --cached []: shows diff between staged
- changes and HEAD (or other named commit)
-  3. git diffall : shows diff between working tree and named
- commit
-  4. git diffall  : show diff between two named commits
-  5. git diffall ..: same as above
-  6. git diffall ...: show the changes on the branch
- containing and up to the second, starting at a common ancestor
- of both 
-
-Note: all forms take an optional path limiter [-- *]
-
-The '--extcmd=' option allows the user to specify a custom
-command for viewing diffs.  When given, configured defaults are
-ignored and the script runs $command $LOCAL $REMOTE.  Additionally,
-$BASE is set in the environment.
-
-This script is based on an example provided by Thomas Rast on the
-Git list [1]:
-
-[1] http://thread.gmane.org/gmane.comp.version-control.git/124807
diff --git a/contrib/diffall/git-diffall b/contrib/diffall/git-diffall
deleted file mode 100755
index 84f2b65..000
--- a/contrib/diffall/git-diffall
+++ /dev/null
@@ -1,257 +0,0 @@
-#!/bin/sh
-# Copyright 2010 - 2012, Tim Henigan 
-#
-# Perform a directory diff between commits in the repository using
-# the external diff or merge tool specified in the user's config.
-
-USAGE='[--cached] [--copy-back] [-x|--extcmd=] {0,2} [-- 
*]
-
---cached Compare to the index rather than the working tree.
-
---copy-back  Copy files back to the working tree when the diff
- tool exits (in case they were modified by the
- user).  This option is only valid if the diff
- compared with the working tree.
-
--x=
---extcmd=  Specify a custom command for viewing diffs.
- git-diffall ignores the configured defaults and
- runs $command $LOCAL $REMOTE when this option is
- specified. Additionally, $BASE is set in the
- environment.
-'
-
-SUBDIRECTORY_OK=1
-. "$(git --exec-path)/git-sh-setup"
-
-TOOL_MODE=diff
-. "$(git --exec-path)/git-mergetool--lib"
-
-merge_tool="$(get_merge_tool)"
-if test -z "$merge_tool"
-then
-   echo "Error: Either the 'diff.tool' or 'merge.tool' option must be set."
-   usage
-fi
-
-start_dir=$(pwd)
-
-# All the file paths returned by the diff command are relative to the root
-# of the working copy. So if the script is called from a subdirectory, it
-# must switch to the root of working copy before trying to use those paths.
-cdup=$(git rev-parse --show-cdup) &&
-cd "$cdup" || {
-   echo >&2 "Cannot chdir to $cdup, the toplevel of the working tree"
-   exit 1
-}
-
-# set up temp dir
-tmp=$(perl -e 'use File::Temp qw(tempdir);
-   $t=tempdir("/tmp/git-diffall.X") or exit(1);
-   print $t') || exit 1
-trap 'rm -rf "$tmp"' EXIT
-
-left=
-right=
-paths=
-dashdash_seen=
-compare_staged=
-merge_base=
-left_dir=
-right_dir=
-diff_tool=
-copy_back=
-
-while test $# != 0
-do
-   case "$1" in
-   -h|--h|--he|--hel|--help)
-   usage
-   ;;
-   --cached)
-   compare_staged=1
-   ;;
-   --copy-back)
-   copy_back=1
-   ;;
-   -x|--e|--ex|--ext|--extc|--extcm|--extcmd)
-   if test $# = 1
-   then
-   echo You must specify the tool for use with --extcmd
-   usage
-   else
-   diff_tool=$2
-   shift
-   fi
-   ;;
-   --)
-   dashdash_seen=1
-   ;;
-   -*)
-   echo Invalid option: "$1"
-   usage
-   ;;
-   *)
-   # could be commit, commit range or path limiter
-   case "$1" in
-   *...*)
-   left=${1%...*}
-   right=${1#*...}
-   merge_base=1
-   ;;
-   *..*)
-   left=${1%..*}
-   right=${1#*..}
-   ;;
-   *)
-   

[PATCH v2 07/17] contrib: remove 'stats'

[Felipe Contreras]

No real activity since 2012 (or ever), no tests, no documentation.

Signed-off-by: Felipe Contreras 
---
 contrib/stats/git-common-hash |  26 --
 contrib/stats/mailmap.pl  |  70 --
 contrib/stats/packinfo.pl | 212 --
 3 files changed, 308 deletions(-)
 delete mode 100755 contrib/stats/git-common-hash
 delete mode 100755 contrib/stats/mailmap.pl
 delete mode 100755 contrib/stats/packinfo.pl

diff --git a/contrib/stats/git-common-hash b/contrib/stats/git-common-hash
deleted file mode 100755
index e27fd08..000
--- a/contrib/stats/git-common-hash
+++ /dev/null
@@ -1,26 +0,0 @@
-#!/bin/sh
-
-# This script displays the distribution of longest common hash prefixes.
-# This can be used to determine the minimum prefix length to use
-# for object names to be unique.
-
-git rev-list --objects --all | sort | perl -lne '
-  substr($_, 40) = "";
-  # uncomment next line for a distribution of bits instead of hex chars
-  # $_ = unpack("B*",pack("H*",$_));
-  if (defined $p) {
-($p ^ $_) =~ /^(\0*)/;
-$common = length $1;
-if (defined $pcommon) {
-  $count[$pcommon > $common ? $pcommon : $common]++;
-} else {
-  $count[$common]++; # first item
-}
-  }
-  $p = $_;
-  $pcommon = $common;
-  END {
-$count[$common]++; # last item
-print "$_: $count[$_]" for 0..$#count;
-  }
-'
diff --git a/contrib/stats/mailmap.pl b/contrib/stats/mailmap.pl
deleted file mode 100755
index 9513f5e..000
--- a/contrib/stats/mailmap.pl
+++ /dev/null
@@ -1,70 +0,0 @@
-#!/usr/bin/perl
-
-use warnings 'all';
-use strict;
-use Getopt::Long;
-
-my $match_emails;
-my $match_names;
-my $order_by = 'count';
-Getopt::Long::Configure(qw(bundling));
-GetOptions(
-   'emails|e!' => \$match_emails,
-   'names|n!'  => \$match_names,
-   'count|c'   => sub { $order_by = 'count' },
-   'time|t'=> sub { $order_by = 'stamp' },
-) or exit 1;
-$match_emails = 1 unless $match_names;
-
-my $email = {};
-my $name = {};
-
-open(my $fh, '-|', "git log --format='%at <%aE> %aN'");
-while(<$fh>) {
-   my ($t, $e, $n) = /(\S+) <(\S+)> (.*)/;
-   mark($email, $e, $n, $t);
-   mark($name, $n, $e, $t);
-}
-close($fh);
-
-if ($match_emails) {
-   foreach my $e (dups($email)) {
-   foreach my $n (vals($email->{$e})) {
-   show($n, $e, $email->{$e}->{$n});
-   }
-   print "\n";
-   }
-}
-if ($match_names) {
-   foreach my $n (dups($name)) {
-   foreach my $e (vals($name->{$n})) {
-   show($n, $e, $name->{$n}->{$e});
-   }
-   print "\n";
-   }
-}
-exit 0;
-
-sub mark {
-   my ($h, $k, $v, $t) = @_;
-   my $e = $h->{$k}->{$v} ||= { count => 0, stamp => 0 };
-   $e->{count}++;
-   $e->{stamp} = $t unless $t < $e->{stamp};
-}
-
-sub dups {
-   my $h = shift;
-   return grep { keys($h->{$_}) > 1 } keys($h);
-}
-
-sub vals {
-   my $h = shift;
-   return sort {
-   $h->{$b}->{$order_by} <=> $h->{$a}->{$order_by}
-   } keys($h);
-}
-
-sub show {
-   my ($n, $e, $h) = @_;
-   print "$n <$e> ($h->{$order_by})\n";
-}
diff --git a/contrib/stats/packinfo.pl b/contrib/stats/packinfo.pl
deleted file mode 100755
index be188c0..000
--- a/contrib/stats/packinfo.pl
+++ /dev/null
@@ -1,212 +0,0 @@
-#!/usr/bin/perl
-#
-# This tool will print vaguely pretty information about a pack.  It
-# expects the output of "git verify-pack -v" as input on stdin.
-#
-# $ git verify-pack -v | packinfo.pl
-#
-# This prints some full-pack statistics; currently "all sizes", "all
-# path sizes", "tree sizes", "tree path sizes", and "depths".
-#
-# * "all sizes" stats are across every object size in the file;
-#   full sizes for base objects, and delta size for deltas.
-# * "all path sizes" stats are across all object's "path sizes".
-#   A path size is the sum of the size of the delta chain, including the
-#   base object.  In other words, it's how many bytes need be read to
-#   reassemble the file from deltas.
-# * "tree sizes" are object sizes grouped into delta trees.
-# * "tree path sizes" are path sizes grouped into delta trees.
-# * "depths" should be obvious.
-#
-# When run as:
-#
-# $ git verify-pack -v | packinfo.pl -tree
-#
-# the trees of objects are output along with the stats.  This looks
-# like:
-#
-#   0 commit 031321c6...  803  803
-#
-#   0   blob 03156f21... 1767 1767
-#   1blob f52a9d7f...   10 1777
-#   2 blob a8cc5739...   51 1828
-#   3  blob 660e90b1...   15 1843
-#   4   blob 0cb8e3bb...   33 1876
-#   2 blob e48607f0...  311 2088
-#  size: count 6 total 2187 min 10 max 1767 mean 364.50 median 51 std_dev 
635.85
-# path size: count 6 total 11179 min 1767 max 2088 mean 1863.17 median 1843 
std_dev 107.26
-#
-# The first number after the sha1 is the object size, the second
-# number is the path 

[PATCH v2 05/17] contrib: remove 'hg-to-git'

[Felipe Contreras]

There hasn't been any real activity on it since 2010.

Plus there are better out-of-tree tools.

No tests and no real documentation either.

Cc: Miklos Vajna 
Signed-off-by: Felipe Contreras 
---
 contrib/hg-to-git/hg-to-git.py  | 255 
 contrib/hg-to-git/hg-to-git.txt |  21 
 2 files changed, 276 deletions(-)
 delete mode 100755 contrib/hg-to-git/hg-to-git.py
 delete mode 100644 contrib/hg-to-git/hg-to-git.txt

diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
deleted file mode 100755
index 60dec86..000
--- a/contrib/hg-to-git/hg-to-git.py
+++ /dev/null
@@ -1,255 +0,0 @@
-#!/usr/bin/env python
-
-""" hg-to-git.py - A Mercurial to GIT converter
-
-Copyright (C)2007 Stelian Pop 
-
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2, or (at your option)
-any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-"""
-
-import os, os.path, sys
-import tempfile, pickle, getopt
-import re
-
-if sys.hexversion < 0x0203:
-   # The behavior of the pickle module changed significantly in 2.3
-   sys.stderr.write("hg-to-git.py: requires Python 2.3 or later.\n")
-   sys.exit(1)
-
-# Maps hg version -> git version
-hgvers = {}
-# List of children for each hg revision
-hgchildren = {}
-# List of parents for each hg revision
-hgparents = {}
-# Current branch for each hg revision
-hgbranch = {}
-# Number of new changesets converted from hg
-hgnewcsets = 0
-
-#--
-
-def usage():
-
-print """\
-%s: [OPTIONS] 
-
-options:
--s, --gitstate=FILE: name of the state to be saved/read
- for incrementals
--n, --nrepack=INT:   number of changesets that will trigger
- a repack (default=0, -1 to deactivate)
--v, --verbose:   be verbose
-
-required:
-hgprj:  name of the HG project to import (directory)
-""" % sys.argv[0]
-
-#--
-
-def getgitenv(user, date):
-env = ''
-elems = re.compile('(.*?)\s+<(.*)>').match(user)
-if elems:
-env += 'export GIT_AUTHOR_NAME="%s" ;' % elems.group(1)
-env += 'export GIT_COMMITTER_NAME="%s" ;' % elems.group(1)
-env += 'export GIT_AUTHOR_EMAIL="%s" ;' % elems.group(2)
-env += 'export GIT_COMMITTER_EMAIL="%s" ;' % elems.group(2)
-else:
-env += 'export GIT_AUTHOR_NAME="%s" ;' % user
-env += 'export GIT_COMMITTER_NAME="%s" ;' % user
-env += 'export GIT_AUTHOR_EMAIL= ;'
-env += 'export GIT_COMMITTER_EMAIL= ;'
-
-env += 'export GIT_AUTHOR_DATE="%s" ;' % date
-env += 'export GIT_COMMITTER_DATE="%s" ;' % date
-return env
-
-#--
-
-state = ''
-opt_nrepack = 0
-verbose = False
-
-try:
-opts, args = getopt.getopt(sys.argv[1:], 's:t:n:v', ['gitstate=', 
'tempdir=', 'nrepack=', 'verbose'])
-for o, a in opts:
-if o in ('-s', '--gitstate'):
-state = a
-state = os.path.abspath(state)
-if o in ('-n', '--nrepack'):
-opt_nrepack = int(a)
-if o in ('-v', '--verbose'):
-verbose = True
-if len(args) != 1:
-raise Exception('params')
-except:
-usage()
-sys.exit(1)
-
-hgprj = args[0]
-os.chdir(hgprj)
-
-if state:
-if os.path.exists(state):
-if verbose:
-print 'State does exist, reading'
-f = open(state, 'r')
-hgvers = pickle.load(f)
-else:
-print 'State does not exist, first run'
-
-sock = os.popen('hg tip --template "{rev}"')
-tip = sock.read()
-if sock.close():
-sys.exit(1)
-if verbose:
-print 'tip is', tip
-
-# Calculate the branches
-if verbose:
-print 'analysing the branches...'
-hgchildren["0"] = ()
-hgparents["0"] = (None, None)
-hgbranch["0"] = "master"
-for cset in range(1, int(tip) + 1):
-hgchildren[str(cset)] = ()
-prnts = os.popen('hg log -r %d --template "{parents}"' % 
cset).read().strip().split(' ')
-prnts = map(lambda x: x[:x.find(':')], prnts)
-if prnts[0] != '':
-parent = prnts[0].strip()
-else:
-parent = str(cset - 1)
-hgchildren[parent] += ( str(cset), )
-if len(prnts) > 1:
-mparent = prnts[1].strip()
-hgchildren[mparent] += ( str(cset), )
-else:
-mpa

[PATCH v2 02/17] contrib: remove 'vim'

[Felipe Contreras]

There are only instructions for old versions of vim (<7.2) which don't
apply since six years.

The vast majority of people don't need these instructions.

Let's remove them.

Cc: Jonathan Nieder 
Cc: Jeff King 
Signed-off-by: Felipe Contreras 
---
 contrib/vim/README | 22 --
 1 file changed, 22 deletions(-)
 delete mode 100644 contrib/vim/README

diff --git a/contrib/vim/README b/contrib/vim/README
deleted file mode 100644
index 8f16d06..000
--- a/contrib/vim/README
+++ /dev/null
@@ -1,22 +0,0 @@
-Syntax highlighting for git commit messages, config files, etc. is
-included with the vim distribution as of vim 7.2, and should work
-automatically.
-
-If you have an older version of vim, you can get the latest syntax
-files from the vim project:
-
-  http://ftp.vim.org/pub/vim/runtime/syntax/git.vim
-  http://ftp.vim.org/pub/vim/runtime/syntax/gitcommit.vim
-  http://ftp.vim.org/pub/vim/runtime/syntax/gitconfig.vim
-  http://ftp.vim.org/pub/vim/runtime/syntax/gitrebase.vim
-  http://ftp.vim.org/pub/vim/runtime/syntax/gitsendemail.vim
-
-These files are also available via FTP at the same location.
-
-To install:
-
-  1. Copy these files to vim's syntax directory $HOME/.vim/syntax
-  2. To auto-detect the editing of various git-related filetypes:
-
-   $ curl http://ftp.vim.org/pub/vim/runtime/filetype.vim |
-   sed -ne '/^" Git$/, /^$/ p' >>$HOME/.vim/filetype.vim
-- 
1.9.2+fc1.28.g12374c0

--
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 00/17] contrib: cleanup

[Felipe Contreras]

The contrib area is full of accumulatted cruft. Let's remove what is not used
and what is already maintained externay.


Felipe Contreras (17):
  contrib: remove outdated README
  contrib: remove 'vim'
  contrib: remove 'emacs'
  contrib: remove 'diffall'
  contrib: remove 'hg-to-git'
  contrib: remove 'hooks/multimail'
  contrib: remove 'stats'
  contrib: remove 'convert-objects'
  contrib: remove 'git-shell-commands'
  contrib: reomve 'thunderbird-patch-inline'
  contrib: remove 'workdir'
  contrib: remove 'svn-fe'
  contrib: remove 'rerere-train'
  contrib: remove 'remotes2config'
  contrib: remove 'persistent-https'
  contrib: remove 'git-resurrect'
  contrib: remove 'contacts'

 contrib/README |   43 -
 contrib/contacts/git-contacts  |  203 --
 contrib/contacts/git-contacts.txt  |   94 -
 contrib/convert-objects/convert-objects.c  |  329 ---
 contrib/convert-objects/git-convert-objects.txt|   29 -
 contrib/diffall/README |   31 -
 contrib/diffall/git-diffall|  257 --
 contrib/emacs/.gitignore   |1 -
 contrib/emacs/Makefile |   21 -
 contrib/emacs/README   |   39 -
 contrib/emacs/git-blame.el |  484 
 contrib/emacs/git.el   | 1705 -
 contrib/git-resurrect.sh   |  182 --
 contrib/git-shell-commands/README  |   18 -
 contrib/git-shell-commands/help|   18 -
 contrib/git-shell-commands/list|   10 -
 contrib/hg-to-git/hg-to-git.py |  255 --
 contrib/hg-to-git/hg-to-git.txt|   21 -
 contrib/hooks/multimail/CHANGES|   33 -
 contrib/hooks/multimail/README |  500 
 contrib/hooks/multimail/README.Git |   15 -
 .../README.migrate-from-post-receive-email |  145 --
 contrib/hooks/multimail/git_multimail.py   | 2539 
 contrib/hooks/multimail/migrate-mailhook-config|  269 ---
 contrib/hooks/multimail/post-receive   |   90 -
 contrib/persistent-https/LICENSE   |  202 --
 contrib/persistent-https/Makefile  |   38 -
 contrib/persistent-https/README|   62 -
 contrib/persistent-https/client.go |  189 --
 contrib/persistent-https/main.go   |   82 -
 contrib/persistent-https/proxy.go  |  190 --
 contrib/persistent-https/socket.go |   97 -
 contrib/remotes2config.sh  |   33 -
 contrib/rerere-train.sh|   52 -
 contrib/stats/git-common-hash  |   26 -
 contrib/stats/mailmap.pl   |   70 -
 contrib/stats/packinfo.pl  |  212 --
 contrib/svn-fe/.gitignore  |4 -
 contrib/svn-fe/Makefile|   63 -
 contrib/svn-fe/svn-fe.c|   18 -
 contrib/svn-fe/svn-fe.txt  |   71 -
 contrib/svn-fe/svnrdump_sim.py |   57 -
 contrib/thunderbird-patch-inline/README|   20 -
 contrib/thunderbird-patch-inline/appp.sh   |   55 -
 contrib/vim/README |   22 -
 contrib/workdir/git-new-workdir|   82 -
 46 files changed, 8976 deletions(-)
 delete mode 100644 contrib/README
 delete mode 100755 contrib/contacts/git-contacts
 delete mode 100644 contrib/contacts/git-contacts.txt
 delete mode 100644 contrib/convert-objects/convert-objects.c
 delete mode 100644 contrib/convert-objects/git-convert-objects.txt
 delete mode 100644 contrib/diffall/README
 delete mode 100755 contrib/diffall/git-diffall
 delete mode 100644 contrib/emacs/.gitignore
 delete mode 100644 contrib/emacs/Makefile
 delete mode 100644 contrib/emacs/README
 delete mode 100644 contrib/emacs/git-blame.el
 delete mode 100644 contrib/emacs/git.el
 delete mode 100755 contrib/git-resurrect.sh
 delete mode 100644 contrib/git-shell-commands/README
 delete mode 100755 contrib/git-shell-commands/help
 delete mode 100755 contrib/git-shell-commands/list
 delete mode 100755 contrib/hg-to-git/hg-to-git.py
 delete mode 100644 contrib/hg-to-git/hg-to-git.txt
 delete mode 100644 contrib/hooks/multimail/CHANGES
 delete mode 100644 contrib/hooks/multimail/README
 delete mode 100644 contrib/hooks/multimail/README.Git
 delete mode 100644 
contrib/hooks/multimail/README.migrate-from-post-receive-email
 delete mode 100755 contrib/hooks/multimail/git_multimail.py
 delete mode 100755 contrib/hooks/multimail/migrate-mailhook-config
 delete mode 100755 contrib/hooks/multimail/post-receive
 delete mode 100644 contrib/persistent-https/LICENSE
 delete mode 100644 contrib/persistent-https/Makef

[PATCH v2 01/17] contrib: remove outdated README

[Felipe Contreras]

There is no guideline as for what should be part of contrib.

Some tools are actively maintained, others consist of a single commit.
Some tools have active user-base, some aren't used by anyone. Some tools
are on the path towards the core, others will never get there. Some
tools are already out-of-tree and simply mirrored, others probably
wouldn't survive out-of-tree. Some tools are production-ready, others
don't even run. Some tools have tests, most don't.

Junio has explained that he wrote this a long time ago, when Git was a
different beast, now this no longer applies.

The only way to find out if a tool belongs in contrib or not is to as
Junio.

Cc: Junio C Hamano 
Signed-off-by: Felipe Contreras 
---
 contrib/README | 43 ---
 1 file changed, 43 deletions(-)
 delete mode 100644 contrib/README

diff --git a/contrib/README b/contrib/README
deleted file mode 100644
index 05f291c..000
--- a/contrib/README
+++ /dev/null
@@ -1,43 +0,0 @@
-Contributed Software
-
-Although these pieces are available as part of the official git
-source tree, they are in somewhat different status.  The
-intention is to keep interesting tools around git here, maybe
-even experimental ones, to give users an easier access to them,
-and to give tools wider exposure, so that they can be improved
-faster.
-
-I am not expecting to touch these myself that much.  As far as
-my day-to-day operation is concerned, these subdirectories are
-owned by their respective primary authors.  I am willing to help
-if users of these components and the contrib/ subtree "owners"
-have technical/design issues to resolve, but the initiative to
-fix and/or enhance things _must_ be on the side of the subtree
-owners.  IOW, I won't be actively looking for bugs and rooms for
-enhancements in them as the git maintainer -- I may only do so
-just as one of the users when I want to scratch my own itch.  If
-you have patches to things in contrib/ area, the patch should be
-first sent to the primary author, and then the primary author
-should ack and forward it to me (git pull request is nicer).
-This is the same way as how I have been treating gitk, and to a
-lesser degree various foreign SCM interfaces, so you know the
-drill.
-
-I expect that things that start their life in the contrib/ area
-to graduate out of contrib/ once they mature, either by becoming
-projects on their own, or moving to the toplevel directory.  On
-the other hand, I expect I'll be proposing removal of disused
-and inactive ones from time to time.
-
-If you have new things to add to this area, please first propose
-it on the git mailing list, and after a list discussion proves
-there are some general interests (it does not have to be a
-list-wide consensus for a tool targeted to a relatively narrow
-audience -- for example I do not work with projects whose
-upstream is svn, so I have no use for git-svn myself, but it is
-of general interest for people who need to interoperate with SVN
-repositories in a way git-svn works better than git-svnimport),
-submit a patch to create a subdirectory of contrib/ and put your
-stuff there.
-
--jc
-- 
1.9.2+fc1.28.g12374c0

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

Re: [PATCH v1 06/25] contrib: remove 'diffall'

[Jonathan Nieder]

Hi Tim,

Tim Henigan wrote:
> On Thu, May 8, 2014 at 5:58 PM, Felipe Contreras
>  wrote:

>>  contrib/diffall/README  |  31 --
>>  contrib/diffall/git-diffall | 257 
>> 
>>  2 files changed, 288 deletions(-)
>>  delete mode 100644 contrib/diffall/README
>>  delete mode 100755 contrib/diffall/git-diffall
>
> I see no problem with removing this script from contrib.  However, the commit 
> message
> should mention that git-difftool learned all the features of git-diffall when 
> the '--dir-diff'
> option was added in v1.7.11 (ca. June 2012).

A few questions:

 * Do you still use git-diffall?  Since it hasn't been a maintenance
   burden, I wouldn't mind keeping it if it still has users.

 * Any thoughts about how to help people who have been using it to
   migrate to difftool?  Would a note in the release notes to look
   into the --dir-diff option to difftool be enough, or are there
   more specific pointers that could be useful?

Once those questions are dealt with, this seems like a nice small
cleanup.  Thanks for the quick feedback.

Hope that helps,
Jonathan
--
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: Watchman support for git

[David Turner]

On Fri, 2014-05-09 at 11:27 -0700, David Lang wrote:
> >
> > That's not my understanding from Durham Goode's talk in January.  Yes,
> > operations involving history go to the server.  But the client also
> > maintains a copy of the working tree, and it is for this that watchman
> > is used.  Otherwise, why bother with watchman at all?  The server knows
> > when it changes files and could simply maintain its own index of what's
> > changed.  Watchman is built on inotify/fsevents -- it doesn't have
> > anything to do with any sort of storage device beyond a vanilla hard
> > drive.
> 
> When you have such a massive repo, your clients aren't storing the data on 
> their 
> local drives, they are accessing the data on a network attached storage (via 
> NFS 
> or through a fuse mount). So they can have their watchman send queries to the 
> storage server to find out what has changed in this massive repo rather than 
> having to walk the directory tree (or try to monitor it for changes on the 
> client machine)

Yes, you could do that.  But I repeat: that is not what Facebook is
actually doing.  If it were, they would have no need for inotify or
FSEvents, since neither even works with NFS (and a FUSE-based solution
would need special support at which point it might as well just
implement watchman itself). 

Please see this section of Durham Goode's talk for evidence that
Facebook is not doing that:
http://www.youtube.com/watch?v=Dlguc63cRXg&t=10m40s

(it's at 10:40 in case that link doesn't work)

Maybe things have changed since at Facebook since Durham gave that talk
in January and you have knowledge of that. If so, say so.  But from what
Facebook has said publicly, this is simply not what's going on.


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

Re: [PATCH v1 1/2] Remove 'git archimport'

[Thomas Adam]

On 9 May 2014 18:52, Felipe Contreras  wrote:
>
> Such incredible double standards.

I think I speak for everyone when I say: fuck off.

I'm sick and tired of seeing you pop up here with polemic and
rhetoric, publicly outing those who are making Git great, just because
you're not getting your own way.

You have a fork of git which you created, go away and use it.

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

Re: [PATCH v1 19/25] contrib: remove 'diff-highlight'

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras  writes:
> 
> > Junio C Hamano wrote:
> >> Felipe Contreras  writes:
> >> 
> >> > *You* said this[1]:
> >> 
> >> If you read the context you omitted from the quote, and realize that
> >> it was a counter-suggestion to give a middle ground to a more
> >> draconian "let's divide them into two", neither which I said I want
> >> to see go forward immediately, you see that this message does not
> >> deserve any response.
> >
> > So when you came with a guideline, that was only for git-remote-hg/bzr.
> 
> There is no guideline involved.

Exactly. It's all arbitrary.

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

Re: [PATCH v1 04/25] contrib: remove 'buildsystems'

[Jonathan Nieder]

Hi,

Erik Faye-Lund wrote:
> On Fri, May 9, 2014 at 10:14 AM, Felipe Contreras
>  wrote:
>> Erik Faye-Lund wrote:

>>> Please don't. This script is useful to build with the MSVC IDE, which
>>> enables us to use their excellent debugger.
>>
>> If you want this script to remain in contrib, please:
>>
>>  a) Write at least a few tests
>>  b) Write some documentation
>>  c) Explain why it cannot live outside the git.git repository like other
>> tools. [1][2][3]
>
> (Adding Marius, the original author to the CC-list)
>
> Uh, why is such a burden required all of a sudden?

It isn't.  As far as I can tell, the only point of this patch series
was to prove a point.  If a patch from the series happens to be useful
then that's great, but otherwise it's mostly an act of protest as far
as I can tell.

(From my point of view, this kind of protest is not really a good way
to reward people who have made good contributions to contrib/ in the
past, so I hope it doesn't happen often.)

I'm happy the MSVC build scripts are in git.git.  Thanks for keeping
them maintained well.

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

Re: [PATCH v1 19/25] contrib: remove 'diff-highlight'

[Junio C Hamano]

Felipe Contreras  writes:

> Junio C Hamano wrote:
>> Felipe Contreras  writes:
>> 
>> > *You* said this[1]:
>> 
>> If you read the context you omitted from the quote, and realize that
>> it was a counter-suggestion to give a middle ground to a more
>> draconian "let's divide them into two", neither which I said I want
>> to see go forward immediately, you see that this message does not
>> deserve any response.
>
> So when you came with a guideline, that was only for git-remote-hg/bzr.

There is no guideline involved.  Go re-read the message upthread and
find this part:

In any case, that suggestion to remove not related to the "stick",
either, and certeinly not about "prove yourself" purge that does not
even exist.

I have no more time nor desire to respond to you today.
--
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: Watchman support for git

[David Lang]

On Fri, 9 May 2014, David Turner wrote:


On Fri, 2014-05-09 at 11:08 -0700, David Lang wrote:

On Fri, 9 May 2014, David Turner wrote:


On Fri, 2014-05-09 at 00:08 -0700, David Lang wrote:

On Thu, 8 May 2014, Sebastian Schuberth wrote:


On 03.05.2014 05:40, Felipe Contreras wrote:


That's very interesting. Do you get similar improvements when doing
something similar in Merurial (watchman vs . no watchman).


I have not tried it.  My understanding is that this is why Facebook
wrote Watchman and added support for it to Mercurial, so I would assume
that the improvements are at least this good.


Yeah, my bet is that they are actually much better (because Mercurial
can't be so optimized as Git).

I'm interested in this number because if watchman in Git is improving it
by 30%, but in Mercurial it's improving it by 100% (made up number),
therefore it makes sens that you might want it more if you are using hg,
but not so much if you are using git.

Also, if similar repositories with Mercurial+watchman are actually
faster than Git+watchman, that means that there's room for improvement
in your implementation. This is not a big issue at this point of the
process, just something nice to know.


The article at [1] has some details, they claim "For our repository, enabling 
Watchman integration has made Mercurial's status command more than 5x faster than Git's 
status command".

[1] 
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/


a lot of that speed comparison is going to depend on your storage system and the
size of your repository.

if you have a high-end enterprise storage system that tracks metadata very
differently from the file contents (I've seen some that have rackes worth of
SATA drives for contents and then 'small' arrays of a few dozen flash drives for
the metadata), and then you have very large repositories (Facebook has
everything in a single repo), then you have a perfect storm where something like
watchman that talks the proprietary protocol of the storage array can be FAR
faster than anything that needs to operate with the standard POSIX calls.

That can easily account for the difference between the facebook announcement and
the results presented for normal disks that show an improvement, but with even
stock git being faster than improved mercurial.


As I recall from Facebook's presentation[1] on this (as well as from the
discussion on the git mailing list[2]), Facebook's test respository is
much larger than any known git repository.  In particular, it is larger
than WebKit.


agreed, it's huge, it's the entire codebase history of every tool that they use
crammed together in one rep


These performance improvements are not for server-side
tasks, but for client-side (e.g. git/hg status).  Facebook also made
other improvements for the client-server communication, and for
log/blame, but these are not relevant to watchman.


well, in their situation they have shared storage that clients use for this huge
repo, so I don't think they have a clear client/server boundry the way you are
thinking. Even clients have this huge repo to deal with, and they can do so
efficiently by querying the storage device rather than trying to walk the tree
or monitor access directly.


That's not my understanding from Durham Goode's talk in January.  Yes,
operations involving history go to the server.  But the client also
maintains a copy of the working tree, and it is for this that watchman
is used.  Otherwise, why bother with watchman at all?  The server knows
when it changes files and could simply maintain its own index of what's
changed.  Watchman is built on inotify/fsevents -- it doesn't have
anything to do with any sort of storage device beyond a vanilla hard
drive.


When you have such a massive repo, your clients aren't storing the data on their 
local drives, they are accessing the data on a network attached storage (via NFS 
or through a fuse mount). So they can have their watchman send queries to the 
storage server to find out what has changed in this massive repo rather than 
having to walk the directory tree (or try to monitor it for changes on the 
client machine)


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

Re: [PATCH v1 19/25] contrib: remove 'diff-highlight'

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras  writes:
> 
> > *You* said this[1]:
> 
> If you read the context you omitted from the quote, and realize that
> it was a counter-suggestion to give a middle ground to a more
> draconian "let's divide them into two", neither which I said I want
> to see go forward immediately, you see that this message does not
> deserve any response.

So when you came with a guideline, that was only for git-remote-hg/bzr.
If you apply that guideline to other tools, you would have to remove
them too, but that won't happen regarlesss of how crappy or well
maintained they are out-of-tree already.

Why? Because you say so. OK.

-- 
Felipe Contreras
--
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: Watchman support for git

[David Turner]

On Fri, 2014-05-09 at 11:08 -0700, David Lang wrote:
> On Fri, 9 May 2014, David Turner wrote:
> 
> > On Fri, 2014-05-09 at 00:08 -0700, David Lang wrote:
> >> On Thu, 8 May 2014, Sebastian Schuberth wrote:
> >>
> >>> On 03.05.2014 05:40, Felipe Contreras wrote:
> >>>
> >> That's very interesting. Do you get similar improvements when doing
> >> something similar in Merurial (watchman vs . no watchman).
> >
> > I have not tried it.  My understanding is that this is why Facebook
> > wrote Watchman and added support for it to Mercurial, so I would assume
> > that the improvements are at least this good.
> 
>  Yeah, my bet is that they are actually much better (because Mercurial
>  can't be so optimized as Git).
> 
>  I'm interested in this number because if watchman in Git is improving it
>  by 30%, but in Mercurial it's improving it by 100% (made up number),
>  therefore it makes sens that you might want it more if you are using hg,
>  but not so much if you are using git.
> 
>  Also, if similar repositories with Mercurial+watchman are actually
>  faster than Git+watchman, that means that there's room for improvement
>  in your implementation. This is not a big issue at this point of the
>  process, just something nice to know.
> >>>
> >>> The article at [1] has some details, they claim "For our repository, 
> >>> enabling Watchman integration has made Mercurial's status command more 
> >>> than 5x faster than Git's status command".
> >>>
> >>> [1] 
> >>> https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
> >>
> >> a lot of that speed comparison is going to depend on your storage system 
> >> and the
> >> size of your repository.
> >>
> >> if you have a high-end enterprise storage system that tracks metadata very
> >> differently from the file contents (I've seen some that have rackes worth 
> >> of
> >> SATA drives for contents and then 'small' arrays of a few dozen flash 
> >> drives for
> >> the metadata), and then you have very large repositories (Facebook has
> >> everything in a single repo), then you have a perfect storm where 
> >> something like
> >> watchman that talks the proprietary protocol of the storage array can be 
> >> FAR
> >> faster than anything that needs to operate with the standard POSIX calls.
> >>
> >> That can easily account for the difference between the facebook 
> >> announcement and
> >> the results presented for normal disks that show an improvement, but with 
> >> even
> >> stock git being faster than improved mercurial.
> >
> > As I recall from Facebook's presentation[1] on this (as well as from the
> > discussion on the git mailing list[2]), Facebook's test respository is
> > much larger than any known git repository.  In particular, it is larger
> > than WebKit.
> 
> agreed, it's huge, it's the entire codebase history of every tool that they 
> use 
> crammed together in one rep
> 
> > These performance improvements are not for server-side
> > tasks, but for client-side (e.g. git/hg status).  Facebook also made
> > other improvements for the client-server communication, and for
> > log/blame, but these are not relevant to watchman.
> 
> well, in their situation they have shared storage that clients use for this 
> huge 
> repo, so I don't think they have a clear client/server boundry the way you 
> are 
> thinking. Even clients have this huge repo to deal with, and they can do so 
> efficiently by querying the storage device rather than trying to walk the 
> tree 
> or monitor access directly.

That's not my understanding from Durham Goode's talk in January.  Yes,
operations involving history go to the server.  But the client also
maintains a copy of the working tree, and it is for this that watchman
is used.  Otherwise, why bother with watchman at all?  The server knows
when it changes files and could simply maintain its own index of what's
changed.  Watchman is built on inotify/fsevents -- it doesn't have
anything to do with any sort of storage device beyond a vanilla hard
drive.

--
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: Watchman support for git

[David Lang]

On Fri, 9 May 2014, David Turner wrote:


On Fri, 2014-05-09 at 00:08 -0700, David Lang wrote:

On Thu, 8 May 2014, Sebastian Schuberth wrote:


On 03.05.2014 05:40, Felipe Contreras wrote:


That's very interesting. Do you get similar improvements when doing
something similar in Merurial (watchman vs . no watchman).


I have not tried it.  My understanding is that this is why Facebook
wrote Watchman and added support for it to Mercurial, so I would assume
that the improvements are at least this good.


Yeah, my bet is that they are actually much better (because Mercurial
can't be so optimized as Git).

I'm interested in this number because if watchman in Git is improving it
by 30%, but in Mercurial it's improving it by 100% (made up number),
therefore it makes sens that you might want it more if you are using hg,
but not so much if you are using git.

Also, if similar repositories with Mercurial+watchman are actually
faster than Git+watchman, that means that there's room for improvement
in your implementation. This is not a big issue at this point of the
process, just something nice to know.


The article at [1] has some details, they claim "For our repository, enabling 
Watchman integration has made Mercurial's status command more than 5x faster than Git's 
status command".

[1] 
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/


a lot of that speed comparison is going to depend on your storage system and the
size of your repository.

if you have a high-end enterprise storage system that tracks metadata very
differently from the file contents (I've seen some that have rackes worth of
SATA drives for contents and then 'small' arrays of a few dozen flash drives for
the metadata), and then you have very large repositories (Facebook has
everything in a single repo), then you have a perfect storm where something like
watchman that talks the proprietary protocol of the storage array can be FAR
faster than anything that needs to operate with the standard POSIX calls.

That can easily account for the difference between the facebook announcement and
the results presented for normal disks that show an improvement, but with even
stock git being faster than improved mercurial.


As I recall from Facebook's presentation[1] on this (as well as from the
discussion on the git mailing list[2]), Facebook's test respository is
much larger than any known git repository.  In particular, it is larger
than WebKit.


agreed, it's huge, it's the entire codebase history of every tool that they use 
crammed together in one rep



These performance improvements are not for server-side
tasks, but for client-side (e.g. git/hg status).  Facebook also made
other improvements for the client-server communication, and for
log/blame, but these are not relevant to watchman.


well, in their situation they have shared storage that clients use for this huge 
repo, so I don't think they have a clear client/server boundry the way you are 
thinking. Even clients have this huge repo to deal with, and they can do so 
efficiently by querying the storage device rather than trying to walk the tree 
or monitor access directly.



It is entirely possible that, as repo size grows, Mercurial with
watchman is faster than git without.

With my patches, git status isn't constant-time; it's merely a roughly
constant factor faster. My initial design was to make git status
constant-time by caching the results of the wt_status_collect calls.


This is what you would have to do with traditional storage. My understanding is 
that the real benefits of watchman show up when you have non-traditional storage 
and can take advantage of the knowledge that the storage system gathers for it's 
own use.


David Lang


But there were so many cases with the various options that I got a bit
lost in the wilderness and made a big mess. Maybe I would do better if I
tried it again today.  And maybe if I just build on top of the
untracked-cache code, I would be able to get to constant-time; I'll have
to try that at some point.

[1] http://www.youtube.com/watch?v=Dlguc63cRXg
[2] http://comments.gmane.org/gmane.comp.version-control.git/189776

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


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

Re: [PATCH v1 19/25] contrib: remove 'diff-highlight'

[Junio C Hamano]

Felipe Contreras  writes:

> *You* said this[1]:

If you read the context you omitted from the quote, and realize that
it was a counter-suggestion to give a middle ground to a more
draconian "let's divide them into two", neither which I said I want
to see go forward immediately, you see that this message does not
deserve any response.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] remote-hg: more improvements

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras  writes:
> 
> > Junio C Hamano wrote:
> >> Felipe Contreras  writes:
> >> 
> >> > I already said this multiple times, but let me be clear once more:
> >> >
> >> > MASTER HAS A REGRESSION (for all versions of Mercurial).
> >> 
> >> As you said, that is not a regression, isn't it?  It is an old
> >> breakage that existed even before 1.9 (was it 1.8.3 or something?)
> >
> > No. It does't happen in 1.9, it will happen in 2.0.
> >
> > That's a REGRESSION.
> 
> You earlier said in our exchange:
> 
> > Wrong. The code in question was not recent, it was introdued in 1.8.3,
> > more than one year ago.
> 
> and "git blame -L870,880 contrib/remote-helpers/git-remote-hg" does
> show that 68d4f4f3 (remote-hg: custom method to write tags,
> 2013-04-22) is the culplit that has introduced ManifestLookupError.

That is not a regression. It's not the issue I'm talking about.

> And it is in since 1.8.3.

That is a coincidence.

> How does it break 2.0 and without breaking 1.9?

I said it breaks ALL VERSIONS. You are looking at two issues that are
unrelated to the one I'm talking about.

> If this were a core part of the system the only sensible thing we
> can do at this point is to revert at this late stage of the cycle,
> but I do not think I have time to bisect and find that culprit, as
> today is when -rc3 has been scheduled to happen.

You won't be able to find the breakage.

Good luck with your tree.

-- 
Felipe Contreras
--
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 00/32] Split index mode for very large indexes

[Junio C Hamano]

Duy Nguyen  writes:

> On Mon, Apr 28, 2014 at 02:18:44PM -0700, Shawn Pearce wrote:
>> > The read penalty is not addressed here, so I still pay 14MB hashing
>> > cost. But that's an easy problem. We could cache the validated index
>> > in a daemon. Whenever git needs to load an index, it pokes the daemon.
>> > The daemon verifies that the on-disk index still has the same
>> > signature, then sends the in-mem index to git. When git updates the
>> > index, it pokes the daemon again to update in-mem index. Next time git
>> > reads the index, it does not have to pay I/O cost any more (actually
>> > it does but the cost is hidden away when you do not have to read it
>> > yet).
>> 
>> If we are going this far, maybe it is worthwhile building a mmap()
>> region the daemon exports to the git client that holds the "in memory"
>> format of the index. Clients would mmap this PROT_READ, MAP_PRIVATE
>> and can then quickly access the base file information without doing
>> further validation, or copying the large(ish) data over a pipe.
>
> The below patch implements such a daemon to cache the index. It takes
> 91ms and 377ms to load a 25MB index with and without the daemon. I use
> share memory instead of pipe, but the format is still "on disk" not
> "in memory" for simplicity. I think we're good even without in memory
> format.

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

Re: [PATCH v1 1/2] Remove 'git archimport'

[Felipe Contreras]

Junio C Hamano wrote:
> Eric Wong  writes:
> 
> > Felipe Contreras  wrote:
> >> No updates since 2010, and no tests.
> >
> > Who benefits from this removal?  Is this causing a maintenance
> > burden for Junio?
> 
> No.  See http://thread.gmane.org/gmane.comp.version-control.git/248587

This has nothing to do with that thread.

This is a *CORE* tool, not part of contrib.

Core tools should have tests, shouldn't they?

In a previous thread you were worried that git-remote-hg might break
things because the Mercurial interface could change and break tests
(which WON'T HAPPEN). And here we have a tool which doesn't even have
tests.

So let's merge git-remote-hg without tests, that way the build cannot
break.

If an actively maintained, production-ready, well tested, and actively
used tool cannot get into the core, why is an unmaintained, no tested at
all, not actively used tool in the core?

And BTW, the argument John Keeping used for git-remote-hg doesn't apply
to git-remote-bzr where the API doesn't change at all.

Such incredible double standards.

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

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Philip Oakley]

From: "Michael Haggerty" 

On 04/26/2014 01:19 AM, Jeff King wrote:

On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
[...]

* fc/publish-vs-upstream (2014-04-21) 8 commits
 - sha1_name: add support for @{publish} marks
 - sha1_name: simplify track finding
 - sha1_name: cleanup interpret_branch_name()
 - branch: display publish branch
 - push: add --set-publish option
 - branch: add --set-publish-to option
 - Add concept of 'publish' branch
 - t5516 (fetch-push): fix test restoration

 Add branch@{publish}; it seems that this is somewhat different from
 Ram and Peff started working on.  There were many discussion
 messages going back and forth but it does not appear that the
 design issues have been worked out among participants yet.


[...]
As for the patches themselves, I have not reviewed them carefully, 
and
would prefer not to. As I mentioned before, though, I would prefer 
the

short "@{p}" not be taken for @{publish} until it has proven itself.


Is it too late and/or impossible to think of a different name for 
either

"push" or "publish" so that their single-letter abbreviations don't
coincide?


I'd initially grated against the 'publish' name. I didn't feel as that 
what I'd be pushing would be publish-worthy in the sense that when a 
book is published it's also edited before release, unless 
vanity-published.


For a basic triangular flow where the user is simply using a remote 
server as a sort of backup (e.g. github) then I thought that "self" may 
a suitable name, though it does feel too much of a specific case.


Part of the problem is that the DVCS style is new so there isn't a good 
word for 'the other side of the river', that's neither upstream, nor 
downstream, but a ferry crossing to another safe harbour.


I'm now sort of OK with push and publish being the same thing.

--
Philip
£0.02p 


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

Re: [PATCH v1 19/25] contrib: remove 'diff-highlight'

[Felipe Contreras]

Junio C Hamano wrote:
> There is no "prove yourself is worthy or get evicted" purge going on
> in the contrib/ area.  I saw contrib/README referred to a few times
> in the near-by threads, and I think these patches are done primarily
> by deliberately misinterpreting one part of it in order to grab
> attention by many people and also to sabotage the project.

*You* said this[1]:

 - Eject tools in contrib/ that would benefit the users better if
   they were outside my tree.  There are a few points to consider
   when judging "benefit better if outside":

   * Their release cycle requirements are better met outside my tree
 (the "remote-hg depends not just on Git but Hg internal" issue
 we have discussed).

   * They are actively maintained.  The overall Git maintainer would
 merely be being a bottleneck than being a helpful editor with
 respect to these tools if we keep them in my tree, and we
 expect that the tool maintainer would do a much better job
 without me.

 - Keep tools that are not actively maintained but still used by the
   users widely in my tree, but when their external dependencies
   become baggage to Git as a whole, demote them to contrib/ and
   stop installing them by default.

 - I would not mind having install.contrib-frotz target in the
   top-level Makefile for each of the remaining contrib/frotz
   hierarchies for those users and distro packagers who know their
   platform meets the dependency requirements.

So make up your mind. Which tools should be ejected from contrib and for
what reasons?

> The contrib/README file was written back when Git was still a small
> and young project

If contrib/README is not appropriate, then rewrite it. Having a
maintainer making decisions about what goes in and goes outs arbitrarily
helps no one.

Or just remove it and be done with the pretense of haing any
consistency.

> The sole mention of possible removal from contrib/ is this one:

Now you are contradicting what you said in [1]. Surely git-remote-hg/bzr
aren't the only tools that meet the criteria you set in [1].

> in which Felipe said:
> 
> I don't want to do anything for a "contrib" tool.
> 
> and I suggested that he has an option to make it a standalone
> third-party project.

You are twisting the events incredibly. *You* started by threatening the
removal[2]:

> Having said that, I agree with the conclusion of your message:...
> and I am inclined to be persuaded that the users of remote-hg/bzr
> may better off if they are unbundled from my tree.

I said I wasn't interested in working on this *after* you said they were
not going to the core, and they should move out-of-tree.

> that is one of the only two alternatives I can offer, given that the
> Git ecosystem has matured enough to let third-party tools flourish
> on their own merit.

But it hasn't matured enough. That's *YOUR ASSUMPTION*.

Look at all the fuzz my patch series has created. Does it seem to you
these are the symptoms of an ecosystem mature enough to let third-party
tools to flourish?

If you think so, then let's continue cleaning up contrib. These tools
will "flourish" according to you.

> In any case, that suggestion to remove not related to the "stick",
> either, and certeinly not about "prove yourself" purge that does not
> even exist.
> 
> So I think most of these removal patches can safely be ignored.

Excellent, so you agree you engage in double standards. Tools stay in
the core even when they haven't proven themselves (and even without
tests), tools get dropped from the tree even when they have proven
themselves.

Got it.

[1] http://article.gmane.org/gmane.comp.version-control.git/248233
[2] http://article.gmane.org/gmane.comp.version-control.git/248242

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

Re: [PATCH v1 1/2] Remove 'git archimport'

[Junio C Hamano]

Eric Wong  writes:

> Felipe Contreras  wrote:
>> No updates since 2010, and no tests.
>
> Who benefits from this removal?  Is this causing a maintenance
> burden for Junio?

No.  See http://thread.gmane.org/gmane.comp.version-control.git/248587

>> Plus, foreign SCM tools should live out-of-tree anyway.
>
> Even if so, there ought to be a transitionary period in case there are
> any users.  We would need to warn potential users of its impending
> removal in the documentation and at runtime.

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

Re: [PATCH v1 07/25] contrib: remove 'git-jump'

[Junio C Hamano]

Jeff King  writes:

> And speaking of wasted time, I do not plan on responding further to you
> in this thread. I am telling you ahead of time that this is the case,
> because elsewhere[1] I saw you complaining that Junio did not respond to
> your emails, which you seemed to think was because he cannot admit that
> he was wrong. So I want to say up front that I am going to avoid
> interacting with you further because it generally seems fruitless,
> consumes a large amount of time, and causes me a great deal of stress.
>
> -Peff
>
> [1] http://article.gmane.org/gmane.comp.version-control.git/248441

Heh, well said.  I'll follow suit, then.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: t5539 fails on ubuntu for v2.0.0-rc2

[Fabio D'Alfonso]

Hi,
yes, the problem comes from root. I made a make test using "git" user in 
my 12.04 server where there is a gitlab and the test went on for 5539.

I think the 3 could be the better solution.

This is not the place to discuss about the sudo mania, a disease I did 
not get and hope not to get, but let me share just a short think. 
Oracle, by product was never made possible to install as a root on 
linux/unix , while OEL allow the login to made any system / maintenance 
activity.
Such a kind of protection , 'product configuration based' protection, 
targeted to the needs of the specific usage , always made sense: 
smoothly configure the system , then stay in the bound of the product.


Why I should manage a possibly try and trash personal desktop (or a 3 
backups VM) as the NSA server is a mistery I do not want to solve. So 
this seems a way to give a box to a dumb, to prevent the breakage. Last 
but not least, desktop involve shortcuts and other things, that fly to 
the root when something is set up by sudo, and I used to put software in 
/opt for out of the tree stuff (e.g. netbeans or smartgit) , and should 
have to fight with myself to access my setups.
The server setup I made for gitlab has quite sense with its user for the 
same reason the oracle pretends and in both cases it is a server , you 
get access to your service not being aware of the mechanics of the backend.
In a personal desktop, where confort is the premiere  need, all this 
seems quite stupid to be forced, also any one could use if he wants.


Sorry for the digression, but it is starting to hurt, generally speaking.


Fabio D'Alfonso
'Enabling Business Through IT'
cell.  +39.348.059.40.22 ***
web: www.fabiodalfonso.com 
email: fabio.dalfo...@fabiodalfonso.com
linkedin: 
www.linkedin.com/in/fabiodalfonso 
twitter: www.twitter.com/#!/fabio_dalfonso 



fax: +39.06.874.599.581
BlackBerry® Wireless Enabled Address.


 ** Hidden  numbers are automatically rejected by the phone*

On 5/9/2014 5:59 PM, Jeff King wrote:

On Thu, May 08, 2014 at 08:02:28AM +0200, Fabio D'Alfonso wrote:


this is the error in httpd error.log

  [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
from  uid 4294967295, you probably need to modify the User directive
  [Wed May 07 20:44:10 2014] [notice] Apache/2.2.17 (Ubuntu) configured --
resuming normal operations
  [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
from  uid 4294967295, you probably need to modify the User directive
  [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
from  uid 4294967295, you probably need to modify the User directive
  [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
from  uid 4294967295, you probably need to modify the User directive
  [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
from  uid 4294967295, you probably need to modify the User directive
  [Wed May 07 20:44:11 2014] [alert] Child 12037 returned a Fatal error...
Apache is exiting!

Hmm.  Some googling turned up a similar case:

   
http://www.linuxquestions.org/questions/linux-server-73/apache-won%27t-start-because-490312/

It looks like apache is trying to getpwuid (probably as part of doing a
setuid on its children), failing, and then crashing. I suspect that this
is related to you running as root, as a non-root apache would not want
to (nor be able to) call setuid.

Does running the tests as a non-root user fix it? If so, I think we have
a few options in git:

   1. Add a User directive to our httpd.conf. I doubt this is a good
  idea to do unconditionally, as a non-root apache would probably be
  unhappy with it.

   2. Add a User directive when we detect that the tests are running as
  root.  This might work, but I'm a bit iffy, as we do not know the
  appropriate username for the system (e.g., "nobody" versus
  "www-data" versus something else).

   3. Just disable the http tests when run as root.

I think I'd favor 3. But I'd like to be sure that being root is the
problem.

-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


--
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: Output from "git blame A..B -- path" for the bottom commit is misleading

[Junio C Hamano]

Jeff King  writes:

> On Fri, May 09, 2014 at 07:04:05AM +0200, David Kastrup wrote:
>
>> Arguably if the user explicitly limited the range, he knows what he's
>> looking at. Admittedly, I don't know offhand which options _will_
>> produce boundary commit indications: there may be some without explicit
>> range limitation, and we might also be talking about limiting through
>> shallow repos (git blame on a shallow repo is probably a bad idea in the
>> first place, but anyway).
>
> Yes, I was thinking mostly of "X..Y" types of ranges, which are probably
> the most common. I hadn't considered shallow repositories, and you can
> also hit the root commit as a boundary if you do not specify --root.
>
> I guess the question still in my mind is: what use does the identity of
> the boundary commit have? That is, whether you know ahead of time where
> the boundary is or not, is there ever a case where knowing its author
> and/or commit sha1 is a useful piece of information, as opposed to
> knowing that we hit a boundary at all?
>
> I could not think of one, but I may simply lack imagination.

Well, the original message was triggered by the same "I could not
think of one" from me ;-).

We may want to flip the default to do a more sanitised version of "-b"
that has been suggested earlier:

>  ( 103) 
> 7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 104) test_expect_...
>  ( 105) test...
> 7bbc458b (Kyle J. McKay  2014-04-22 04:16:22 -0700 106) git ...
>  ( 107) test...
> 
> which does away with the misleading information altogether.

and have another option to show the current default output for those
who would want that information.

But that will be a topic for post 2.0; I should start preparing for
the -rc3 soonish, so I'll stop here.
--
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: Watchman support for git

[David Turner]

On Fri, 2014-05-09 at 00:08 -0700, David Lang wrote:
> On Thu, 8 May 2014, Sebastian Schuberth wrote:
> 
> > On 03.05.2014 05:40, Felipe Contreras wrote:
> >
>  That's very interesting. Do you get similar improvements when doing
>  something similar in Merurial (watchman vs . no watchman).
> >>>
> >>> I have not tried it.  My understanding is that this is why Facebook
> >>> wrote Watchman and added support for it to Mercurial, so I would assume
> >>> that the improvements are at least this good.
> >>
> >> Yeah, my bet is that they are actually much better (because Mercurial
> >> can't be so optimized as Git).
> >>
> >> I'm interested in this number because if watchman in Git is improving it
> >> by 30%, but in Mercurial it's improving it by 100% (made up number),
> >> therefore it makes sens that you might want it more if you are using hg,
> >> but not so much if you are using git.
> >>
> >> Also, if similar repositories with Mercurial+watchman are actually
> >> faster than Git+watchman, that means that there's room for improvement
> >> in your implementation. This is not a big issue at this point of the
> >> process, just something nice to know.
> >
> > The article at [1] has some details, they claim "For our repository, 
> > enabling Watchman integration has made Mercurial's status command more than 
> > 5x faster than Git's status command".
> >
> > [1] 
> > https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
> 
> a lot of that speed comparison is going to depend on your storage system and 
> the 
> size of your repository.
> 
> if you have a high-end enterprise storage system that tracks metadata very 
> differently from the file contents (I've seen some that have rackes worth of 
> SATA drives for contents and then 'small' arrays of a few dozen flash drives 
> for 
> the metadata), and then you have very large repositories (Facebook has 
> everything in a single repo), then you have a perfect storm where something 
> like 
> watchman that talks the proprietary protocol of the storage array can be FAR 
> faster than anything that needs to operate with the standard POSIX calls.
> 
> That can easily account for the difference between the facebook announcement 
> and 
> the results presented for normal disks that show an improvement, but with 
> even 
> stock git being faster than improved mercurial.

As I recall from Facebook's presentation[1] on this (as well as from the
discussion on the git mailing list[2]), Facebook's test respository is
much larger than any known git repository.  In particular, it is larger
than WebKit. These performance improvements are not for server-side
tasks, but for client-side (e.g. git/hg status).  Facebook also made
other improvements for the client-server communication, and for
log/blame, but these are not relevant to watchman.

It is entirely possible that, as repo size grows, Mercurial with
watchman is faster than git without.

With my patches, git status isn't constant-time; it's merely a roughly
constant factor faster. My initial design was to make git status
constant-time by caching the results of the wt_status_collect calls.
But there were so many cases with the various options that I got a bit
lost in the wilderness and made a big mess. Maybe I would do better if I
tried it again today.  And maybe if I just build on top of the
untracked-cache code, I would be able to get to constant-time; I'll have
to try that at some point.  

[1] http://www.youtube.com/watch?v=Dlguc63cRXg
[2] http://comments.gmane.org/gmane.comp.version-control.git/189776

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

Re: [PATCH 0/4] remote-hg: more improvements

[Junio C Hamano]

Felipe Contreras  writes:

> Junio C Hamano wrote:
>> Felipe Contreras  writes:
>> 
>> > I already said this multiple times, but let me be clear once more:
>> >
>> > MASTER HAS A REGRESSION (for all versions of Mercurial).
>> 
>> As you said, that is not a regression, isn't it?  It is an old
>> breakage that existed even before 1.9 (was it 1.8.3 or something?)
>
> No. It does't happen in 1.9, it will happen in 2.0.
>
> That's a REGRESSION.

You earlier said in our exchange:

> Wrong. The code in question was not recent, it was introdued in 1.8.3,
> more than one year ago.

and "git blame -L870,880 contrib/remote-helpers/git-remote-hg" does
show that 68d4f4f3 (remote-hg: custom method to write tags,
2013-04-22) is the culplit that has introduced ManifestLookupError.

And it is in since 1.8.3.  How does it break 2.0 and without
breaking 1.9?  The dormant and otherwise unused code got its first
caller, or something?

If this were a core part of the system the only sensible thing we
can do at this point is to revert at this late stage of the cycle,
but I do not think I have time to bisect and find that culprit, as
today is when -rc3 has been scheduled to happen.


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

Re: [PATCH v1 00/25] contrib: cleanup

[Felipe Contreras]

Martin Langhoff wrote:
> On Fri, May 9, 2014 at 11:57 AM, Felipe Contreras
>  wrote:
> > I already explained:
> >> That's right, and they are Cc'ed so they can respond.  Some tools have
> >> only one commit or two, and in those I didn't even bother Cc'ing
> >> anyone.
> >
> > contrib/persistent-https consist of a *single* commit, I didn't bother
> > with those.
> 
> That single commit is the "merge" into contrib. It may have had a dev
> history before.

It may, but from git.git's perspective it has no activity.

Either way it's written in Go. I fail to see why Go can be tolerated
while Ruby and any other language can't. Only C, perl, sh, or python.

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

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Felipe Contreras]

Michael Haggerty wrote:
> On 04/26/2014 01:19 AM, Jeff King wrote:
> > On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
> > [...]
> >> * fc/publish-vs-upstream (2014-04-21) 8 commits
> >>  - sha1_name: add support for @{publish} marks
> >>  - sha1_name: simplify track finding
> >>  - sha1_name: cleanup interpret_branch_name()
> >>  - branch: display publish branch
> >>  - push: add --set-publish option
> >>  - branch: add --set-publish-to option
> >>  - Add concept of 'publish' branch
> >>  - t5516 (fetch-push): fix test restoration
> >>
> >>  Add branch@{publish}; it seems that this is somewhat different from
> >>  Ram and Peff started working on.  There were many discussion
> >>  messages going back and forth but it does not appear that the
> >>  design issues have been worked out among participants yet.
> > 
> > [...]
> > As for the patches themselves, I have not reviewed them carefully, and
> > would prefer not to. As I mentioned before, though, I would prefer the
> > short "@{p}" not be taken for @{publish} until it has proven itself.
> 
> Is it too late and/or impossible to think of a different name for either
> "push" or "publish" so that their single-letter abbreviations don't
> coincide?

I'd say given the fact that this has been in the works for a long long
tie and nobody has proposed a better name. Yes.

One reason I think @{p} makes sense for publish is:

  % git push -u, @{u}, @{upstream}
  % git push -p, @{p}, @{publish}

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

Re: [PATCH v1 00/25] contrib: cleanup

[Martin Langhoff]

On Fri, May 9, 2014 at 11:57 AM, Felipe Contreras
 wrote:
> I already explained:
>> That's right, and they are Cc'ed so they can respond.  Some tools have
>> only one commit or two, and in those I didn't even bother Cc'ing
>> anyone.
>
> contrib/persistent-https consist of a *single* commit, I didn't bother
> with those.

!?

That single commit is the "merge" into contrib. It may have had a dev
history before.

> And how do you determine the author? We don't have a MAINTAINERS like
> Linux. Is it the first commit?

git blame, aggregate lines against each name?

There was a tool for that discussed a couple years ago, can't remember
name. I used it to find tha lines to my name have shrunk in all my
years inactive :-/



m

-- 
 martin.langh...@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 19/25] contrib: remove 'diff-highlight'

[Junio C Hamano]

Jeff King  writes:

> On Thu, May 08, 2014 at 07:58:30PM -0500, Felipe Contreras wrote:
>
>> No activity since 2012, no tests, no chance of ever graduating.
>
> I don't think "no activity" is an interesting indicator. This tool _is_
> actively maintained, but it has not needed any fixes since 2012. I use
> it for every single "git log" and "git diff" invocation I do via the
> pager.* config.
>
> If we are getting rid of contrib/ I would be happy to continue
> maintaining it out-of-tree.

I do not know how much attention you have been paying, and I suspect
that you may be aware of all of the following, but I'll send this
out anyway, primarily so that others involved in other subthreads
can find out the story behind this.

There is no "prove yourself is worthy or get evicted" purge going on
in the contrib/ area.  I saw contrib/README referred to a few times
in the near-by threads, and I think these patches are done primarily
by deliberately misinterpreting one part of it in order to grab
attention by many people and also to sabotage the project.

The contrib/README file was written back when Git was still a small
and young project that was trying to build an ecosystem by having an
area to host stuff that are not core-material for some reason or
other (e.g.  only useful in some environments, only useful for some
workflows, the design or code not up to par to be in core) in my
tree to ease discovery and distribution.

There, I wrote:

I expect that things that start their life in the contrib/ area
to graduate out of contrib/ once they mature, either by becoming
projects on their own, or moving to the toplevel directory.  On
the other hand, I expect I'll be proposing removal of disused
and inactive ones from time to time.

The purpose the last sentence in that paragraph is there was to
protect our codebase and our users from those who see an opportunity
to throw their ware in to our tree and go AWOL, by giving me, the
maintainer, a "stick" to prod them, saying "You as the primary
author are responsible for taking good care of the ware you created
by responding to issues (questions, suggestions, bugs, patches) in a
prompt manner, or your ware may even get evicted."

Among contrib/ materials we have today, I do not think there is
anything that requires me to exercise that "stick".  diff-highlight
certainly is not.  Perhaps subtree is the closest, as I see issues
raised from time to time but the original champion seems to be
inactive for some time, but even there, I recently saw somebody
hinting to volunteer to take it over after sending a patch or two to
it, and I do not intend to exercise the "stick" yet.

The sole mention of possible removal from contrib/ is this one:

http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248457

in which Felipe said:

I don't want to do anything for a "contrib" tool.

and I suggested that he has an option to make it a standalone
third-party project.  With the promotion to the core has already
been ruled out in the thread that begins at this one:

http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248167

that is one of the only two alternatives I can offer, given that the
Git ecosystem has matured enough to let third-party tools flourish
on their own merit.  "We may want a better plug-in registry for Git"
I mentioned in

http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248391

was to help us in that direction, but seeing that imerge mentioned
in many places I do not even regularly visit with the current
"discovery and distribution" infrastructure, perhaps yet another new
registry may not even be necessary.  I dunno.

In any case, that suggestion to remove not related to the "stick",
either, and certeinly not about "prove yourself" purge that does not
even exist.

So I think most of these removal patches can safely be ignored.

I agree with you and Jonathan that removal of contrib/vim may be a
good idea, but that is not due to "stick" nor "prove yourself",
either.  Jonathan's proposed alternative $gmane/248506 does a good
job of explaining and justifying the change.  It is a graduation "by
becoming projects on their own" that contrib/README mentions.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Michael Haggerty]

On 04/26/2014 01:19 AM, Jeff King wrote:
> On Fri, Apr 25, 2014 at 03:50:26PM -0700, Junio C Hamano wrote:
> [...]
>> * fc/publish-vs-upstream (2014-04-21) 8 commits
>>  - sha1_name: add support for @{publish} marks
>>  - sha1_name: simplify track finding
>>  - sha1_name: cleanup interpret_branch_name()
>>  - branch: display publish branch
>>  - push: add --set-publish option
>>  - branch: add --set-publish-to option
>>  - Add concept of 'publish' branch
>>  - t5516 (fetch-push): fix test restoration
>>
>>  Add branch@{publish}; it seems that this is somewhat different from
>>  Ram and Peff started working on.  There were many discussion
>>  messages going back and forth but it does not appear that the
>>  design issues have been worked out among participants yet.
> 
> [...]
> As for the patches themselves, I have not reviewed them carefully, and
> would prefer not to. As I mentioned before, though, I would prefer the
> short "@{p}" not be taken for @{publish} until it has proven itself.

Is it too late and/or impossible to think of a different name for either
"push" or "publish" so that their single-letter abbreviations don't
coincide?

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.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: [PATCH v1 23/25] contrib: remove 'hooks/multimail'

[James Denholm]

Felipe Contreras  wrote:
>Michael Haggerty wrote:
>> What's more, it has a maintainer who doesn't routinely insult other
>> people on the mailing list,
>
>Aaand skiping the rest. Good bye.

Aww, Felipe, it's no fair when you ignore other people's
slag. How ever will anyone argue with you if you don't let
them descend to your level?

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

Re: [PATCH v1 1/2] Remove 'git archimport'

[Felipe Contreras]

Felipe Contreras wrote:
> All right, I guess that' something, but I get:
> 
>   Use of each() on hash after insertion without resetting hash iterator
>   results in undefined behavior, Perl interpreter: 0x1fec010 at
>   /usr/lib/git-core/git-archimport line 129.
> 
> And a ton of:
> 
>   WARNING: no rule found for checking signatures from a...@atai.org--public
> 
> Consider creating ~/.arch-params/signing/a...@atai.org--public.check
> or ~/.arch-params/signing/=default.check
> 
> I'll leave it running and see how it goes.

It finished, but tons of errors everywhere. Unless this repository has
only 120 commits, I don't think the import worked properly.

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

[ANNOUNCE] git-remote-bzr 0.2

[Felipe Contreras]

Hi,

git-remote-bzr is a bidirectional bridge between Git and Bazaar. It is
production-ready, has been widely tested, and was previously part of
git.git.

As I already explained[1], there is no path forward for git-remote-hg
and git-remote-bzr; Junio C Hamano has retracted from his previous
statements where he wanted these tools to become part of the Git core
and distributed by default.

So it's time to move out-of-tree so they can be packaged and distributed
properly (as properly as any out-of-tree tool can).

Changes from v1.9 upstream:

 * Add manpage
 * Fix regression that will become active in Git v2.0
 * Add support for older versions of bzr

If you use ArchLinux, you can use the package I wrote[2].

Enjoy :)

https://github.com/felipec/git-remote-bzr

Felipe Contreras (10):
  Reorganize test
  Add README
  build: add install instructions
  doc: add manpage
  Add support for older versions
  Trivial test fix
  Store marks only on success
  test: fix redirection style
  travis: add initial configuration
  Use python2 instead of python

dequis (1):
  Include authors field in pushed commits

[1] http://article.gmane.org/gmane.comp.version-control.git/248561
[2] https://aur.archlinux.org/packages/git-remote-bzr/

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

[Closed] git-email: sendemail.bcc in config file overrides command line option "--bcc"

[Adam Lee]

On Fri, May 09, 2014 at 11:45:09AM -0400, Jeff King wrote:
> On Fri, May 09, 2014 at 04:13:31PM +0800, Adam Lee wrote:
> 
> > BugLink: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747068
> > 
> > "--bcc" should have higher priority than sendemail.bcc.
> > 
> > > --bcc=
> > > Specify a "Bcc:" value for each email. Default is the value of 
> > > sendemail.bcc.
> > >
> > > The --bcc option must be repeated for each user you want on the bcc 
> > > list.
> > 
> > Reproducing steps:
> > 1, set sendemail.bcc in .gitconfig.
> > 2, git send-email --bcc with another address.
> 
> Hrm, I cannot reproduce at all here:
> 
>   $ git config sendemail.bcc config-...@example.com
>   $ git send-email --dry-run --to=t...@example.com -1 origin
>   (mbox) Adding cc: Junio C Hamano  from line 'From: Junio 
> C Hamano '
>   Dry-OK. Log says:
>   Sendmail: /usr/sbin/sendmail -i t...@example.com gits...@pobox.com 
> config-...@example.com
>   > [...]
> 
> OK, so our configured bcc works. Now let's override it:
> 
>   $ git send-email --dry-run --to=t...@example.com \
>   --bcc=cmdline-...@example.com -1 origin
>   (mbox) Adding cc: Junio C Hamano  from line 'From: Junio 
> C Hamano '
>   Dry-OK. Log says:
>   Sendmail: /usr/sbin/sendmail -i t...@example.com gits...@pobox.com 
> cmdline-...@example.com
> 
> That looks like it's working as expected. Can you show us similar
> commands that demonstrate the failure?
> 
> -Peff

I can't reproduce it now, there might be something wrong in my command
lines, let's close it first. Thanks, Jeff.

-- 
Adam Lee
--
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: Conforming to pep8

[Felipe Contreras]

W. Trevor King wrote:
> The indentation for the closing parenthesis is optional [2].  You can
> of course do things like:
> 
>   from mercurial import (
>   bar, baz,
>   foo,
>   )

I prefer:

  from mercurial foo, bar, ...
  from mercurial baz, ...

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

Re: [PATCH v1 07/25] contrib: remove 'git-jump'

[Felipe Contreras]

Jeff King wrote:
> On Thu, May 08, 2014 at 09:12:36PM -0500, Felipe Contreras wrote:
> 
> > Jeff King wrote:
> > > On Thu, May 08, 2014 at 07:58:18PM -0500, Felipe Contreras wrote:
> > > 
> > > > No activity, no tests.
> > > 
> > > Like diff-highlight, I don't think "no activity" is a useful indicator.
> > > I use this daily, and several people have commented off-list to me that
> > > they use it, too.
> > 
> > Add tests then.
> 
> I don't really feel like spending time on it right now. There are better
> uses of my time.
> 
> I thought on this for a while before responding. Am I simply being lazy
> and a bad programmer not to write tests?

It depends how you define "lazy". Some people think laziness is a good
quality in a programmer.

> Am I propagating a double standard where I do not have to write tests?

Only if you are imposing those standards onto others. It doesn't seem
like you are doing it, but Junio is.

> Here's the conclusion I came to. Sure, some tests are better than no
> tests. But the code works, empirically; I use it every day. It is not
> changing, so the chances of regression are low. I can spend an hour
> writing tests that demonstrate what I already know. I can even spend
> several hours trying to come up with torture cases that might
> demonstrate a potential failure that nobody in the real world
> experiences. But why?
> 
> Because YOU, who have no interest whatsoever in either this script or
> diff-highlight, have decided to demand that I write them, or spend time
> spinning the code into its own repository. Sorry, but I have more useful
> things to do than appease you.

Nobody is forcing you to do anything. If you don't want to write tests,
move the code out of git.git, there's hundreads of tools out there
out-of-tree, and they don't have tests either.

The purpose of contrib is very clearly defined in contrib/README, and
nowhere does it say that tools belong there if Peff uses them. You need
more than that to belong in contrib.

> I have no problem with cleaning up cruft in contrib that is broken and
> nobody uses; it is a potential hazard and time-waster for people who
> look in that directory. But when people say "no, this is maintained, I
> use it, and it works", I really don't see the point in you arguing with
> them. Nobody benefits.

Then you need to talk to Junio, because it really doesn't make sense to
have such abismally different double standards.

> > It this is never meant to move to the core, then it should go
> > out-of-tree anyway.
> 
> "should" in your opinion. I know, I know, you will quote contrib/README
> at me.  If Junio wants to enforce "contrib is only for things which are
> meant to graduate" in his tree, then I will abide by that and maintain
> these scripts out-of-tree. But I would rather see an actual decision
> from the maintainer on that, and not an 8-year-old README which clearly
> has not been followed in the intervening years.

Exactly. Junio has to decide what is the standard for contrib, and what
is the standard for the core. And right now we have incredibly crappy
and unmaintained tools in contrib that nobody uses, as well as
production ready which are in better shape than some tools in the core.

This huge discrepancy should not be.

> And speaking of wasted time, I do not plan on responding further to you
> in this thread. I am telling you ahead of time that this is the case,
> because elsewhere[1] I saw you complaining that Junio did not respond to
> your emails,

Respond or not, the issue about the discrepancy of standards remains.

> which you seemed to think was because he cannot admit that he was
> wrong.

Why he didn't do it is irrelevant, the fact is that he didn't do it.
Other people wonder what is the reponse to these questions. If he
doesn't do it, that's on him.

-- 
Felipe Contreras
--
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: Conforming to pep8

[W. Trevor King]

On Fri, May 09, 2014 at 02:44:02AM -0500, William Giokas wrote:
> Maybe a time to use something like::
> 
>   from mercurial import foo \
> bar \
> baz \
> ...
> 
> Would make that import into quite a few lines, but would help organize
> things and let you easily organize things in the future.

From PEP 8 [1]:
  The preferred way of wrapping long lines is by using Python's
  implied line continuation inside parentheses, brackets and
  braces. Long lines can be broken over multiple lines by wrapping
  expressions in parentheses. These should be used in preference to
  using a backslash for line continuation.

So I prefer something like:

  from mercurial import (
  bar,
  baz,
  foo,
  )

The indentation for the closing parenthesis is optional [2].  You can
of course do things like:

  from mercurial import (
  bar, baz,
  foo,
  )

but I prefer the complete specification of “single, alphebetized entry
per line”.  I'm happy to send patches if that style is ok.

Cheers,
Trevor

[1]: http://legacy.python.org/dev/peps/pep-0008/#maximum-line-length
[2]: http://legacy.python.org/dev/peps/pep-0008/#indentation

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: t5539 fails on ubuntu for v2.0.0-rc2

[Jeff King]

On Thu, May 08, 2014 at 08:02:28AM +0200, Fabio D'Alfonso wrote:

> this is the error in httpd error.log
> 
>  [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
> from  uid 4294967295, you probably need to modify the User directive
>  [Wed May 07 20:44:10 2014] [notice] Apache/2.2.17 (Ubuntu) configured --
> resuming normal operations
>  [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
> from  uid 4294967295, you probably need to modify the User directive
>  [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
> from  uid 4294967295, you probably need to modify the User directive
>  [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
> from  uid 4294967295, you probably need to modify the User directive
>  [Wed May 07 20:44:10 2014] [alert] getpwuid: couldn't determine user name
> from  uid 4294967295, you probably need to modify the User directive
>  [Wed May 07 20:44:11 2014] [alert] Child 12037 returned a Fatal error...
> Apache is exiting!

Hmm.  Some googling turned up a similar case:

  
http://www.linuxquestions.org/questions/linux-server-73/apache-won%27t-start-because-490312/

It looks like apache is trying to getpwuid (probably as part of doing a
setuid on its children), failing, and then crashing. I suspect that this
is related to you running as root, as a non-root apache would not want
to (nor be able to) call setuid.

Does running the tests as a non-root user fix it? If so, I think we have
a few options in git:

  1. Add a User directive to our httpd.conf. I doubt this is a good
 idea to do unconditionally, as a non-root apache would probably be
 unhappy with it.

  2. Add a User directive when we detect that the tests are running as
 root.  This might work, but I'm a bit iffy, as we do not know the
 appropriate username for the system (e.g., "nobody" versus
 "www-data" versus something else).

  3. Just disable the http tests when run as root.

I think I'd favor 3. But I'd like to be sure that being root is the
problem.

-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 v1 00/25] contrib: cleanup

[Felipe Contreras]

Jeff King wrote:
> On Thu, May 08, 2014 at 09:01:32PM -0500, Felipe Contreras wrote:
> 
> > > Are you planning on CC'ing the (inactive) authors/maintainers
> > > so they know that if they care they should host those elsewhere?
> > 
> > They are already Cc'ed.
> 
> I don't think you were very thorough on this. Of the three remaining
> contrib projects I authored (and for which I am the top shortlog entry),
> you cc'd me on one. For contrib/persistent-https, you did not cc Colby,
> who is the sole author. I didn't look beyond that.

I already explained:
> That's right, and they are Cc'ed so they can respond.  Some tools have
> only one commit or two, and in those I didn't even bother Cc'ing
> anyone.

contrib/persistent-https consist of a *single* commit, I didn't bother
with those.

> If we are going to remove projects so they can be maintained out of
> tree, it seems like the prudent thing to do is make sure the original
> author is aware so that they can actually start maintaining it out of
> tree.

And how do you determine the author? We don't have a MAINTAINERS like
Linux. Is it the first commit?

-- 
Felipe Contreras
--
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: t5539 fails on ubuntu for v2.0.0-rc2 - the SAME on 12.04 server - this test was disabled up to 1.9.2

[Jeff King]

On Fri, May 09, 2014 at 10:39:32AM +0200, Fabio D'Alfonso wrote:

> this test was disabled up to 1.9.2 so it did not fail as it did not run by
> default.

Yes, in v1.9.2 we turned on http tests to run by default, but only if we
could succeed in setting up the http server automatically (and if we
can't, we skip the tests). Unfortunately your case seems to set up the
http server fine, but then it dies. It's odd that it's only on this one
test, though.

You can manually disable them by setting GIT_TEST_HTTPD=false in your
config.mak file. If this sort of spurious failure is common, we may have
to consider switching the default back to "false" from "auto".

> It seems that no one is interested to this issue. Probably I misunderstood
> the purpose of the list.

This is the right place. But your problem is confusing and hard, so it
may take time for people to look into it and respond. :)

-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: [Bug] git-email: sendemail.bcc in config file overrides command line option "--bcc"

[Jeff King]

On Fri, May 09, 2014 at 04:13:31PM +0800, Adam Lee wrote:

> BugLink: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747068
> 
> "--bcc" should have higher priority than sendemail.bcc.
> 
> > --bcc=
> > Specify a "Bcc:" value for each email. Default is the value of 
> > sendemail.bcc.
> >
> > The --bcc option must be repeated for each user you want on the bcc 
> > list.
> 
> Reproducing steps:
> 1, set sendemail.bcc in .gitconfig.
> 2, git send-email --bcc with another address.

Hrm, I cannot reproduce at all here:

  $ git config sendemail.bcc config-...@example.com
  $ git send-email --dry-run --to=t...@example.com -1 origin
  (mbox) Adding cc: Junio C Hamano  from line 'From: Junio C 
Hamano '
  Dry-OK. Log says:
  Sendmail: /usr/sbin/sendmail -i t...@example.com gits...@pobox.com 
config-...@example.com
  > [...]

OK, so our configured bcc works. Now let's override it:

  $ git send-email --dry-run --to=t...@example.com \
  --bcc=cmdline-...@example.com -1 origin
  (mbox) Adding cc: Junio C Hamano  from line 'From: Junio C 
Hamano '
  Dry-OK. Log says:
  Sendmail: /usr/sbin/sendmail -i t...@example.com gits...@pobox.com 
cmdline-...@example.com

That looks like it's working as expected. Can you show us similar
commands that demonstrate the failure?

-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: Output from "git blame A..B -- path" for the bottom commit is misleading

[Jeff King]

On Fri, May 09, 2014 at 07:04:05AM +0200, David Kastrup wrote:

> Arguably if the user explicitly limited the range, he knows what he's
> looking at. Admittedly, I don't know offhand which options _will_
> produce boundary commit indications: there may be some without explicit
> range limitation, and we might also be talking about limiting through
> shallow repos (git blame on a shallow repo is probably a bad idea in the
> first place, but anyway).

Yes, I was thinking mostly of "X..Y" types of ranges, which are probably
the most common. I hadn't considered shallow repositories, and you can
also hit the root commit as a boundary if you do not specify --root.

I guess the question still in my mind is: what use does the identity of
the boundary commit have? That is, whether you know ahead of time where
the boundary is or not, is there ever a case where knowing its author
and/or commit sha1 is a useful piece of information, as opposed to
knowing that we hit a boundary at all?

I could not think of one, but I may simply lack imagination.

-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 v1 23/25] contrib: remove 'hooks/multimail'

[Michael Haggerty]

On 05/09/2014 05:04 PM, David Kastrup wrote:
> Michael Haggerty  writes:
> 
>> On 05/09/2014 02:58 AM, Felipe Contreras wrote:
>>> No tests. No chance of ever graduating.
>>>
>>> Already out-of-tree.
>>>
>>> Cc: Michael Haggerty 
>>> Signed-off-by: Felipe Contreras 
>>
>> Thank you for your input.
>>
>> git-multimail is maintained outside of the Git project and is only
>> distributed along with Git as a convenience to Git users.  It does in
>> fact have a test suite, along with some other bits and bobs that are not
>> needed to use it, in the upstream repository at
>>
>> https://github.com/mhagger/git-multimail
>>
>> What's more, it has a maintainer who doesn't routinely insult other
>> people on the mailing list, conduct endless and pointless flame wars,
>> think that he is superior to everybody in sight, and throw temper
>> tantrums when his rudeness, argumentativeness, and arrogance for some
>> reason don't win the hearts and minds of other contributors.
> 
> Oh come on.  Junio is not _that_ bad.

lol

I would explicitly like to thank Junio for being so patient,
imperturbable, and helpful (not to mention hard-working!).  His prompt
and always thoughtful feedback was one of the big reasons that I got
involved in Git development in the first place.

In particular, I would like to say that I am in 100% disagreement with
the criticism of Junio that some people have deFeCated onto the list
recently [1].  Junio, please don't for a minute think that the trolls'
opinions are shared by others [2].

Michael

[1] Actually, it was only one person.
[2] Actually, it is only one troll.

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.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: [PATCH v1 00/25] contrib: cleanup

[Jeff King]

On Thu, May 08, 2014 at 09:01:32PM -0500, Felipe Contreras wrote:

> > Are you planning on CC'ing the (inactive) authors/maintainers
> > so they know that if they care they should host those elsewhere?
> 
> They are already Cc'ed.

I don't think you were very thorough on this. Of the three remaining
contrib projects I authored (and for which I am the top shortlog entry),
you cc'd me on one. For contrib/persistent-https, you did not cc Colby,
who is the sole author. I didn't look beyond that.

If we are going to remove projects so they can be maintained out of
tree, it seems like the prudent thing to do is make sure the original
author is aware so that they can actually start maintaining it out of
tree.

-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 v1 06/25] contrib: remove 'diffall'

[Felipe Contreras]

Tim Henigan wrote:
> On Thu, May 8, 2014 at 5:58 PM, Felipe Contreras  > wrote:
> 
> > No activity since 2010, no tests.
> >
> > Cc: Tim Henigan 
> > Signed-off-by: Felipe Contreras 
> > ---
> >  contrib/diffall/README  |  31 --
> >  contrib/diffall/git-diffall | 257
> > 
> >  2 files changed, 288 deletions(-)
> >  delete mode 100644 contrib/diffall/README
> >  delete mode 100755 contrib/diffall/git-diffall
> >
> 
> 
> I see no problem with removing this script from contrib.  However, the
> commit message should mention that git-difftool learned all the
> features of git-diffall when the '--dir-diff' option was added in
> v1.7.11 (ca. June 2012).

Will do.

> Also, the script was first added to contrib in Feb. 2012, so "no
> activity since 2010" is incorrect.

Ah, sorry about that.

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

Re: [PATCH v1 07/25] contrib: remove 'git-jump'

[Jeff King]

On Thu, May 08, 2014 at 09:12:36PM -0500, Felipe Contreras wrote:

> Jeff King wrote:
> > On Thu, May 08, 2014 at 07:58:18PM -0500, Felipe Contreras wrote:
> > 
> > > No activity, no tests.
> > 
> > Like diff-highlight, I don't think "no activity" is a useful indicator.
> > I use this daily, and several people have commented off-list to me that
> > they use it, too.
> 
> Add tests then.

I don't really feel like spending time on it right now. There are better
uses of my time.

I thought on this for a while before responding. Am I simply being lazy
and a bad programmer not to write tests? Am I propagating a double
standard where I do not have to write tests?

Here's the conclusion I came to. Sure, some tests are better than no
tests. But the code works, empirically; I use it every day. It is not
changing, so the chances of regression are low. I can spend an hour
writing tests that demonstrate what I already know. I can even spend
several hours trying to come up with torture cases that might
demonstrate a potential failure that nobody in the real world
experiences. But why?

Because YOU, who have no interest whatsoever in either this script or
diff-highlight, have decided to demand that I write them, or spend time
spinning the code into its own repository. Sorry, but I have more useful
things to do than appease you.

I have no problem with cleaning up cruft in contrib that is broken and
nobody uses; it is a potential hazard and time-waster for people who
look in that directory. But when people say "no, this is maintained, I
use it, and it works", I really don't see the point in you arguing with
them. Nobody benefits.

> It this is never meant to move to the core, then it should go
> out-of-tree anyway.

"should" in your opinion. I know, I know, you will quote contrib/README
at me.  If Junio wants to enforce "contrib is only for things which are
meant to graduate" in his tree, then I will abide by that and maintain
these scripts out-of-tree. But I would rather see an actual decision
from the maintainer on that, and not an 8-year-old README which clearly
has not been followed in the intervening years.

And speaking of wasted time, I do not plan on responding further to you
in this thread. I am telling you ahead of time that this is the case,
because elsewhere[1] I saw you complaining that Junio did not respond to
your emails, which you seemed to think was because he cannot admit that
he was wrong. So I want to say up front that I am going to avoid
interacting with you further because it generally seems fruitless,
consumes a large amount of time, and causes me a great deal of stress.

-Peff

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

Re: [PATCH v1 23/25] contrib: remove 'hooks/multimail'

[Felipe Contreras]

Michael Haggerty wrote:
> On 05/09/2014 02:58 AM, Felipe Contreras wrote:
> > No tests. No chance of ever graduating.
> > 
> > Already out-of-tree.
> > 
> > Cc: Michael Haggerty 
> > Signed-off-by: Felipe Contreras 
> 
> Thank you for your input.
> 
> git-multimail is maintained outside of the Git project and is only
> distributed along with Git as a convenience to Git users.

I do not see anywhere in contrib/README any hint that contrib is meant
for that.

> It does in fact have a test suite, along with some other bits and bobs
> that are not needed to use it, in the upstream repository at
> 
> https://github.com/mhagger/git-multimail

Good to know. But IMO the tests should be in git.git as well, or nothing
at all.

> What's more, it has a maintainer who doesn't routinely insult other
> people on the mailing list,

Aaand skiping the rest. Good bye.

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

Re: [PATCH v1 1/2] Remove 'git archimport'

[Felipe Contreras]

Jeff King wrote:
> On Fri, May 09, 2014 at 04:20:40AM -0500, Felipe Contreras wrote:
> 
> > Eric Wong wrote:
> > > Felipe Contreras  wrote:
> > > > As a minimal token that anybody might possibly be using it, I would like
> > > > to see it work at least once. Since you said you have arch repos, can
> > > > you confirm that it does something?
> > > 
> > > Those repos are in offline/offsite storage and I do not have time to
> > > retrieve them.
> > 
> > Then we have no reason to believe they still work, and therefore, no
> > reason to believe anybody is using this.
> 
> Do you have any reason to believe they do NOT work? If not, and they are
> not causing any problems, then what is the benefit to getting rid of
> them?

Ask Junio. He is the one arguing that foreign tools should live in their
own repository out-of-tree.

> > > I've forgotten how to use tla to get a public repo, even.
> 
> I haven't used tla in quite a long time, but:
> 
>   tla register-archive http://www.atai.org/archarchives/a...@atai.org--public/
>   tla my-default-archive a...@atai.org--public
>   mkdir repo
>   cd repo
>   git archimport a...@atai.org--public
> 
> seemed to work (that archive is straight off the tla homepage's
> instructions). Looks like the commit messages could use some cleanup,
> but certainly it's better than nothing.

All right, I guess that' something, but I get:

  Use of each() on hash after insertion without resetting hash iterator
  results in undefined behavior, Perl interpreter: 0x1fec010 at
  /usr/lib/git-core/git-archimport line 129.

And a ton of:

  WARNING: no rule found for checking signatures from a...@atai.org--public

Consider creating ~/.arch-params/signing/a...@atai.org--public.check
or ~/.arch-params/signing/=default.check

I'll leave it running and see how it goes.

Still, if it's part of the core, it should have tests.

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

Re: [PATCH v1 06/25] contrib: remove 'diffall'

[Tim Henigan]

On Thu, May 8, 2014 at 5:58 PM, Felipe Contreras
 wrote:
> No activity since 2010, no tests.
>
> Cc: Tim Henigan 
> Signed-off-by: Felipe Contreras 
> ---
>  contrib/diffall/README  |  31 --
>  contrib/diffall/git-diffall | 257 
> 
>  2 files changed, 288 deletions(-)
>  delete mode 100644 contrib/diffall/README
>  delete mode 100755 contrib/diffall/git-diffall

I see no problem with removing this script from contrib.  However, the
commit message
should mention that git-difftool learned all the features of
git-diffall when the '--dir-diff'
option was added in v1.7.11 (ca. June 2012).

Also, the script was first added to contrib in Feb. 2012, so "no
activity since 2010" is
incorrect.  I'm not sure this information is useful in the commit
message at all.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 18/25] contrib: remove 'emacs'

[Alexandre Julliard]

David Kågedal  writes:

> 2014-05-09 10:29 GMT+02:00 Felipe Contreras
> :
>
> David Kågedal wrote:
> > What problem does this removal solve?
> 
> 
> Please do not top post.
> 
> a) What problem does it solve by staying?
> b) Where are the tests?
> c) Why it cannot be moved to an outside repository like may other
> git-related tools?
>
> Fair enough. I guess the target should rather be to get it into the
> emacs distribution.

It's already in Emacs in a different form, as part of the generic VC
support. And nowadays, users are probably better served by using
something like Magit anyway. As far as my code is concerned I have no
objections to removing it.

-- 
Alexandre Julliard
julli...@winehq.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: [PATCH v1 23/25] contrib: remove 'hooks/multimail'

[David Kastrup]

Michael Haggerty  writes:

> On 05/09/2014 02:58 AM, Felipe Contreras wrote:
>> No tests. No chance of ever graduating.
>> 
>> Already out-of-tree.
>> 
>> Cc: Michael Haggerty 
>> Signed-off-by: Felipe Contreras 
>
> Thank you for your input.
>
> git-multimail is maintained outside of the Git project and is only
> distributed along with Git as a convenience to Git users.  It does in
> fact have a test suite, along with some other bits and bobs that are not
> needed to use it, in the upstream repository at
>
> https://github.com/mhagger/git-multimail
>
> What's more, it has a maintainer who doesn't routinely insult other
> people on the mailing list, conduct endless and pointless flame wars,
> think that he is superior to everybody in sight, and throw temper
> tantrums when his rudeness, argumentativeness, and arrogance for some
> reason don't win the hearts and minds of other contributors.

Oh come on.  Junio is not _that_ bad.

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

Re: [PATCH v1 23/25] contrib: remove 'hooks/multimail'

[Michael Haggerty]

On 05/09/2014 02:58 AM, Felipe Contreras wrote:
> No tests. No chance of ever graduating.
> 
> Already out-of-tree.
> 
> Cc: Michael Haggerty 
> Signed-off-by: Felipe Contreras 

Thank you for your input.

git-multimail is maintained outside of the Git project and is only
distributed along with Git as a convenience to Git users.  It does in
fact have a test suite, along with some other bits and bobs that are not
needed to use it, in the upstream repository at

https://github.com/mhagger/git-multimail

What's more, it has a maintainer who doesn't routinely insult other
people on the mailing list, conduct endless and pointless flame wars,
think that he is superior to everybody in sight, and throw temper
tantrums when his rudeness, argumentativeness, and arrogance for some
reason don't win the hearts and minds of other contributors.

Cheers,
Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.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: [PATCH v1 1/2] Remove 'git archimport'

[Jeff King]

On Fri, May 09, 2014 at 04:20:40AM -0500, Felipe Contreras wrote:

> Eric Wong wrote:
> > Felipe Contreras  wrote:
> > > As a minimal token that anybody might possibly be using it, I would like
> > > to see it work at least once. Since you said you have arch repos, can
> > > you confirm that it does something?
> > 
> > Those repos are in offline/offsite storage and I do not have time to
> > retrieve them.
> 
> Then we have no reason to believe they still work, and therefore, no
> reason to believe anybody is using this.

Do you have any reason to believe they do NOT work? If not, and they are
not causing any problems, then what is the benefit to getting rid of
them?

> > I've forgotten how to use tla to get a public repo, even.

I haven't used tla in quite a long time, but:

  tla register-archive http://www.atai.org/archarchives/a...@atai.org--public/
  tla my-default-archive a...@atai.org--public
  mkdir repo
  cd repo
  git archimport a...@atai.org--public

seemed to work (that archive is straight off the tla homepage's
instructions). Looks like the commit messages could use some cleanup,
but certainly it's better than nothing.

-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 v1 18/25] contrib: remove 'emacs'

[Felipe Contreras]

Alexandre Julliard wrote:
> David Kågedal  writes:
> 
> > 2014-05-09 10:29 GMT+02:00 Felipe Contreras
> > :
> >
> > David Kågedal wrote:
> > > What problem does this removal solve?
> > 
> > 
> > Please do not top post.
> > 
> > a) What problem does it solve by staying?
> > b) Where are the tests?
> > c) Why it cannot be moved to an outside repository like may other
> > git-related tools?
> >
> > Fair enough. I guess the target should rather be to get it into the
> > emacs distribution.
> 
> It's already in Emacs in a different form, as part of the generic VC
> support. And nowadays, users are probably better served by using
> something like Magit anyway. As far as my code is concerned I have no
> objections to removing it.

All right. Thanks for the clarification.

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

[ANNOUNCE] git-remote-hg 0.2

[Felipe Contreras]

Hi,

git-remote-hg is a bidirectional bridge between Git and Mercurial. It is
production-ready, has been widely tested, and was previously part of
git.git.

Junio C Hamano has retracted from his previous statements where he
wanted these tools to become part of the Git core and distributed by
default.

It is obviously production ready so it doesn't belong in contrib/
either.

Since there's no path forward, it has been split into a separate
out-of-tree project.

This will hurt our users, but it's better than having dubious prospects
of when and how these tools will be part of the core, if such a thing
was even possible to begin with.

Changes from v1.9 upstream:

 * Add manpage
 * Fix regression that will become active in Git v2.0
 * Do not fail on invalid bookmarks
 * Skip multiple heads (hg has such a thing)
 * Ported tests from gitifyhg
 * Add support for Mercurial v3.0
 * Fixes for failed imports

If you use ArchLinux, you can use the package I wrote[1].

Enjoy :)

https://github.com/felipec/git-remote-hg

Daniel Liew (1):
  Use internal clone's hgrc

Felipe Contreras (22):
  Reorganize tests
  Add README
  build: add install target
  doc: add manpage
  Always normalize paths
  Fix parsing of custom committer
  Update to 'public' phase when pushing
  Store marks only on success
  Properly detect missing contexts
  test: split into setup test
  remote-hg: make sure we omit multiple heads
  Simplify hg-git regex
  Add more tests
  test: dd file operation tests
  test: trivial cleanups and fixes
  Add support for hg v3.0
  test: trivial style cleanups
  test: fix redirection style
  travis: add initial configuration
  readme: fix link location
  test: add missing redirection
  Use python2 instead of python

Max Horn (1):
  Do not fail on invalid bookmarks

[1] https://aur.archlinux.org/packages/git-remote-hg/

-- 
Felipe Contreras
--
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: Conforming to pep8

[Michael Haggerty]

On 05/09/2014 04:09 AM, Jonathan Nieder wrote:
> (cc-ing Pete Wyckoff who maintains git-p4 and Michael Haggerty
> who maintains git-multimail)
> William Giokas wrote:
> 
>>  - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
>>
>> It's even the first thing that you see when you go looking for 'python'
>> in the coding style document. I just ran every file in the tree that
>> either ended in '.py' or had a python #!, and was greeted with a whole
>> bunch of output::
>>
>> ./git-p4.py
>> ./contrib/svn-fe/svnrdump_sim.py
>> ./contrib/remote-helpers/git-remote-bzr
>> ./contrib/hooks/multimail/post-receive
>> ./contrib/hooks/multimail/migrate-mailhook-config
>> ./contrib/hooks/multimail/git_multimail.py
>> ./contrib/hooks/multimail/README
>> ./contrib/hg-to-git/hg-to-git.py
>> ./contrib/gitview/gitview
>> ./contrib/fast-import/import-zips.py
> 
> Thanks for running this check.  Passing on the result to the
> maintainers of some of those scripts in case they have thoughts.
> 
> [...]

Thanks for the heads-up, William and Jonathan.  I wasn't aware of the
pep8 tool.  Though I think it enforces a couple of rules that go a bit
beyond PEP8, I don't mind conforming to it, at least with options

--max-line-length=99 --hang-closing

I just committed a change to my upstream repository that gets pep8 to
run cleanly on all Python files.

I don't think it is worth making an extra code drop to Git just to push
these mild stylistic changes, but if somebody disagrees you know where
to find my repo.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.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: [PATCH v1 19/25] contrib: remove 'diff-highlight'

[Felipe Contreras]

Stefan Beller wrote:
> >
> > It is serious.
> >
> > The purpose of the 'contrib/' area is not clear. The statemens coming
> > from Junio don't match what is on 'contrib/README'. So we have a huge
> > variance of quality all over 'contrib/'. Some tools in contrib have
> > higher quality than what is part of the core (e.g. they have tests,
> > while git-archimport doesn't).
> 
> How about rewriting the README then?

To say what?

> Also as I said in another mail, we could split up the contrib/ area
> into multiple areas with narrow defined use-cases, i.e. staging/,
> Documentation/historicTools (the current contrib/examples section),
> 3rdPartyTools/, Bridges/ (for cooperating with other VCS).

That won't fix the issue that these tools are not maintained. A separate
repository 'git-cruft' might do.

-- 
Felipe Contreras
--
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] How to keep a project's canonical history correct.

[Stephen Smith]

> On May 8, 2014, at 11:08 PM, "Stephen P. Smith"  wrote:
> 
> During the mail thread about "Pull is mostly evil" a user asked how
> the first parent could become reversed.
> 
> This howto explains how the first parent can get reversed when viewed
> by the project and then explains a method to keep the history correct.
> 
> Signed-off-by: Stephen P. Smith 
> ---

The reason I resubmitted as a brand new patch was because I was using the 
message ID from the original topic as requested. 

In my repository I did a "git merge --squash" then the format patch.  

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

Re: [PATCH v1 19/25] contrib: remove 'diff-highlight'

[Stefan Beller]

>
> It is serious.
>
> The purpose of the 'contrib/' area is not clear. The statemens coming
> from Junio don't match what is on 'contrib/README'. So we have a huge
> variance of quality all over 'contrib/'. Some tools in contrib have
> higher quality than what is part of the core (e.g. they have tests,
> while git-archimport doesn't).

How about rewriting the README then?
Also as I said in another mail, we could split up the contrib/ area
into multiple areas with narrow defined use-cases, i.e. staging/,
Documentation/historicTools (the current contrib/examples section),
3rdPartyTools/, Bridges/ (for cooperating with other VCS).


>
> So this is a serious attempt at making sure we remain consistent through
> the core and contrib/.
>
> Personally I would like to see everything in contrib/ have *at least*
> some tests and documentation. Otherwise we know what's going to happen;
> they are going to rot and nobody will care that the tools don't work any
> more, or they won't even know what they do and how to use them.
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 00/25] contrib: cleanup

[Stefan Beller]

For discussing these larger changes in the first version you may want to use
the -D option of git format-patch?

2014-05-09 4:01 GMT+02:00 Felipe Contreras :
> Martin Langhoff wrote:
>> On Thu, May 8, 2014 at 8:58 PM, Felipe Contreras > > wrote:
>>
>> > Let us be honest, the vast majority of tools in 'contrib/' have no chance
>> > of
>> > ever graduating, so let's remove them.
>> >
>>
>> I am curious -- have you checked what parts of contrib downstreams
>> package&ship?
>
> I have checked a few, not throughly. From what I can see most of them
> just copy everything to /usr/share/git without much consideration to
> what is actually there.
>
> The only exception is the shell completions.
>
>> Are you planning on CC'ing the (inactive) authors/maintainers
>> so they know that if they care they should host those elsewhere?
>
> They are already Cc'ed.
>
>> My candid opinion is that you're trying to force a group of people to
>> undertake a pointless exercise. Contrib in many/most projects is uneven,
>> and folks know that. But it gives upstream a chance to push for some
>> minimal quality, and in turn it gives visibility to a bunch of sometimes
>> useful tools.
>
> Yes, but that's not what our contrib/ is supposed to be. Read
> conrib/README.
>
>> If my code was going to get the axe, I'd be rather pissed off. If Junio is
>> in agreement that code quality is bad, or tools should have unit tests,
>> then the push could be to address the problem or face removal. For example:
>> contrib maintainer, show you're responsive to bug reports on the list, or
>> face removal; add unit tests (or explain why they aren't needed) or face
>> removal.
>
> That's right, and they are Cc'ed so they can respond.  Some tools have
> only one commit or two, and in those I didn't even bother Cc'ing anyone.
>
> Moreover, it's not enough that they are actively maintained. Accoding to
> Junio they need to show that they can't work properly out-of-tree, and
> thus there's a need for them to be in contrib/. Or they are temporarily
> in contrib/ so they can become part of the core. That doesn't apply to
> the tools I proposed to remove here.
>
> --
> Felipe Contreras
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bash v4 on msysgit?

[Robert Dailey]

Thanks for the info. Really quite disappointing that the discussion
linked was from 3 years ago but still no progress. I wish I could use
cygwin to use GIT but LESS doesn't work for log, reflog, and other
commands.

On Fri, May 9, 2014 at 4:37 AM, Thomas Braun
 wrote:
>> How can I get Bash v4 for msysgit 1.9.2? I need it for 'globstar'
>> shopt support. Thanks in advance.
>
> Unfortunately you can't.
> Newer bash versions don't work with the current msys layer.
>
> See http://mingw.5.n7.nabble.com/bash-4-x-for-MSYS-td5605.html for a
> more in depth discussion.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 25/25] contrib: remove 'mw-to-git'

[Stefan Beller]

On 09.05.2014 12:59, Felipe Contreras wrote:
> Matthieu Moy wrote:
>> Felipe Contreras  writes:
>>
>>> No chance of ever graduating.
>>
>> I see no relationship between the chance of graduating and the removal
>> from contrib/.
> 
> Read contrib/README.
> 
>> If you want to remove mw-to-git from contrib, then a good starting point
>> would be to explain why you want to do so in the commit message.
> 
> The purpose of the contrib area is to either a) give visibility to
> otherwise potentially ignored scripts b) serve a staging area for
> features before moving into the core.
> 
> This script doesn't match either of those. It doesn't belong in the
> contrib/ area.
> 

Maybe we could split it a little bit. Similar to the kernel there is a
staging area. Ok there are some features, which are not yet promoted
to mainline, some never will.

But some things like examples/ could be moved out to another directory.
(How about Documentation/historicEncounters/ ?)

Also we could think about renaming contrib to staging then.
However I don't think it's urgent.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 04/25] contrib: remove 'buildsystems'

[Erik Faye-Lund]

On Fri, May 9, 2014 at 12:57 PM, Felipe Contreras
 wrote:
> Erik Faye-Lund wrote:
>> On Fri, May 9, 2014 at 11:32 AM, Felipe Contreras
>>  wrote:
>> > Erik Faye-Lund wrote:
>> >> On Fri, May 9, 2014 at 10:48 AM, Felipe Contreras
>> >> > You think changing the execution bit of a file is considered "activity"?
>> >>
>> >> Well, now we're getting into semantics, which I don't care so much
>> >> about.
>> >
>> > Convenient.
>>
>> Yeah, the part above here goes in my "don't argue with idiots, they'll
>> drag you down to their level and beat you with experience"-filter.
>> Good luck trying to convince *anyone* with this line of argumentation.
>
> It has been demonstrated that there is inactivity. The fact that your
> semantics about "inactivity" differ from the rest of the world is
> irrelevant.
>
>> > The script doesn't depend on the version of the Makefile, and proof of
>> > that is that is has *never* been changed even though the Makefile has.
>>
>> Except it has, in 74cf9bd.
>
> Once change in *four* years. My god! How are people ever going to keep
> up with such amount of changes if it moves out-of-tree!
>

It's rather amusing to see you react to my definition of "activity",
when you seem to have a rather unusual definition of "never"...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 04/25] contrib: remove 'buildsystems'

[David Kastrup]

Felipe Contreras  writes:

> David Kastrup wrote:
>> Felipe Contreras  writes:
>> 
>> > David Kastrup wrote:
>> >
>> >> The idea of removing software from distribution is to get rid of
>> >> stuff without a user base rather than punishing lazy developers.
>> >
>> > No.
>> 
>> So we have you on record that you would want to get rid of stuff
>> _with_ a user base
>
> That's what Junio wants.

Let's hear it from himself.  Your track record summarizing other
people's opinions to their satisfaction would suggest that he might have
something to add to that.

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

Re: [PATCH v1 25/25] contrib: remove 'mw-to-git'

[Felipe Contreras]

Matthieu Moy wrote:
> Felipe Contreras  writes:
> 
> > No chance of ever graduating.
> 
> I see no relationship between the chance of graduating and the removal
> from contrib/.

Read contrib/README.

> If you want to remove mw-to-git from contrib, then a good starting point
> would be to explain why you want to do so in the commit message.

The purpose of the contrib area is to either a) give visibility to
otherwise potentially ignored scripts b) serve a staging area for
features before moving into the core.

This script doesn't match either of those. It doesn't belong in the
contrib/ area.

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