* Re: [PATCH] contrib/hooks: avoid requiring root access in usage instructions
From: Junio C Hamano @ 2012-10-20 4:19 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Olivier Berger, Michael Haggerty, Kevin P. Fleming,
Chris Hiestand, Miklos Vajna
In-Reply-To: <20121020003104.GA26596@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Comments in hooks/post-receive-email suggest:
>
> For example, on debian the hook is stored in
> /usr/share/git-core/contrib/hooks/post-receive-email:
>
> chmod a+x post-receive-email
> cd /path/to/your/repository.git
> ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
>
> Doing that means changing permissions on a file provided by a package,
> which is problematic in a number of ways: the permissions would be
> likely to change back in later upgrades, and changing them requires
> root access. Copying the script into each repo that uses it is not
> much better, since each copy would be maintained separately and not
> benefit from bugfixes in the master copy.
>
> Better to ship the hook with executable permission and remove the
> chmod line so enabling the hook becomes a one-step process: just
> symlink it into place.
>
> Likewise for the pre-auto-gc-battery hook.
>
> Reported-by: Olivier Berger <olivier.berger@it-sudparis.eu>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> From <http://bugs.debian.org/687391>.
>
> Thoughts?
We already encourage casting-in-stone a particular version of the
sample hook when a new repository is created by copying them from
the template directory. This prevents from surprising users when an
updated version of Git changes the behaviour of these samples. Even
if you think bugs in older ones may be corrected in newer ones,
silently updating the hook the user chose to use by inspecting one
particular version is not something we would want to do lightly. A
buggy devil you know is better than a devil that suddenly changes
its behaviour depending on when your sysadmin updates the version of
Git without your knowing.
I personally think the same applies to these contrib/ hooks, and I
would think it is simpler and more consistent to correct the
instruction in these files to tell users to copy them.
Adding +x bits to these files is a good idea but that is orthogonal
to copying vs symlinking, I think.
> Jonathan
>
> contrib/hooks/post-receive-email | 1 -
> contrib/hooks/pre-auto-gc-battery | 1 -
> 2 files changed, 2 deletions(-)
> mode change 100644 => 100755 contrib/hooks/pre-auto-gc-battery
>
> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
> index 8ca6607a..359f1ad2 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -13,7 +13,6 @@
> # For example, on debian the hook is stored in
> # /usr/share/git-core/contrib/hooks/post-receive-email:
> #
> -# chmod a+x post-receive-email
> # cd /path/to/your/repository.git
> # ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
> #
> diff --git a/contrib/hooks/pre-auto-gc-battery b/contrib/hooks/pre-auto-gc-battery
> old mode 100644
> new mode 100755
> index 1f914c94..9d0c2d19
> --- a/contrib/hooks/pre-auto-gc-battery
> +++ b/contrib/hooks/pre-auto-gc-battery
> @@ -13,7 +13,6 @@
> # For example, if the hook is stored in
> # /usr/share/git-core/contrib/hooks/pre-auto-gc-battery:
> #
> -# chmod a+x pre-auto-gc-battery
> # cd /path/to/your/repository.git
> # ln -sf /usr/share/git-core/contrib/hooks/pre-auto-gc-battery \
> # hooks/pre-auto-gc
^ permalink raw reply
* Re: libgit2 status
From: Thiago Farina @ 2012-10-20 1:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, git, dag, Nicolas Sebrecht,
Andreas Ericsson, greened
In-Reply-To: <7vvce6i5j2.fsf@alter.siamese.dyndns.org>
On Fri, Oct 19, 2012 at 5:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I actually hate "include/git.h vs src/git.c"; you have distinction
> between .c and .h already.
Which distinction are you talking about? This is not an issue of
header file versus source file, but a public header file to be
included by external projects versus internal header files that are
intended to be included only by git itself and that will probably live
under src/ directory.
^ permalink raw reply
* [PATCH] contrib/hooks: avoid requiring root access in usage instructions
From: Jonathan Nieder @ 2012-10-20 0:31 UTC (permalink / raw)
To: git
Cc: Olivier Berger, Michael Haggerty, Kevin P. Fleming,
Chris Hiestand, Miklos Vajna
Comments in hooks/post-receive-email suggest:
For example, on debian the hook is stored in
/usr/share/git-core/contrib/hooks/post-receive-email:
chmod a+x post-receive-email
cd /path/to/your/repository.git
ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
Doing that means changing permissions on a file provided by a package,
which is problematic in a number of ways: the permissions would be
likely to change back in later upgrades, and changing them requires
root access. Copying the script into each repo that uses it is not
much better, since each copy would be maintained separately and not
benefit from bugfixes in the master copy.
Better to ship the hook with executable permission and remove the
chmod line so enabling the hook becomes a one-step process: just
symlink it into place.
Likewise for the pre-auto-gc-battery hook.
Reported-by: Olivier Berger <olivier.berger@it-sudparis.eu>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
From <http://bugs.debian.org/687391>.
Thoughts?
Jonathan
contrib/hooks/post-receive-email | 1 -
contrib/hooks/pre-auto-gc-battery | 1 -
2 files changed, 2 deletions(-)
mode change 100644 => 100755 contrib/hooks/pre-auto-gc-battery
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 8ca6607a..359f1ad2 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -13,7 +13,6 @@
# For example, on debian the hook is stored in
# /usr/share/git-core/contrib/hooks/post-receive-email:
#
-# chmod a+x post-receive-email
# cd /path/to/your/repository.git
# ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
#
diff --git a/contrib/hooks/pre-auto-gc-battery b/contrib/hooks/pre-auto-gc-battery
old mode 100644
new mode 100755
index 1f914c94..9d0c2d19
--- a/contrib/hooks/pre-auto-gc-battery
+++ b/contrib/hooks/pre-auto-gc-battery
@@ -13,7 +13,6 @@
# For example, if the hook is stored in
# /usr/share/git-core/contrib/hooks/pre-auto-gc-battery:
#
-# chmod a+x pre-auto-gc-battery
# cd /path/to/your/repository.git
# ln -sf /usr/share/git-core/contrib/hooks/pre-auto-gc-battery \
# hooks/pre-auto-gc
--
1.8.0.rc2
^ permalink raw reply related
* Re: L10n regression in 1.8.0.rc2: diffstat summary (git diff --stat, git format-patch)
From: Peter Krefting @ 2012-10-19 23:38 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Jiang Xin
In-Reply-To: <CACsJy8CS9TKGaT8+MQ_JOEQD+fgnc9HVAbr1pjQ3JE_3ZjE9=A@mail.gmail.com>
Nguyen Thai Ngoc Duy:
> It's the result of this discussion [1]. I don't remember exactly the
> open issues. But I think it involves drawing a line between team
> language vs local language, whether team language can be anything
> other than English, the maintenance cost for supporting it
Like I said, I can see that defaulting format-patch to output English
is a good idea (since its output is "protocol data" and not something
for human consumption), it is the output from diff and show that I
want to have localized.
I'll see if I can come up with a patch that cater for both use-cases.
Maybe I can also fix so that log output is fully localized at the same
time (translating "commit", "author", "date" and outputting locale
dates (although my locale usess ISO dates, so I can get proper
formatting there already)).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: libgit2 status
From: Junio C Hamano @ 2012-10-19 22:43 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Thiago Farina, git, dag, Nicolas Sebrecht, Andreas Ericsson,
greened
In-Reply-To: <7vvce6i5j2.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Thiago Farina wrote:
>>> [...]
>>> With some structure like:
>>>
>>> include/git.h
>>> src/git.c
>>>
>>> ...
>>>
>>> whatever.
>>> [...]
>>
>> Junio- is it reasonable to expect the directory-restructuring by 2.0?
>
> I actually hate "include/git.h vs src/git.c"; you have distinction
> between .c and .h already.
Having said that, I do not mind moving codeblocks around to make
some files purely library-ish while others purely commands.
Ideally, if you run
$ nm --defined-only -g builtin/frotz.o
you should see nothing but "T cmd_frotz" (there are exceptions, most
notably, what the commands in the "log" family do are so close with
each other that builtin/log.o can define cmd_* for all of them).
$ nm --defined-only -og builtin/*.o | grep -v 'T cmd_'
a handful of offenders. If these functions with external linkage
are truly useful across subcommands, we should move them to a more
library-ish location.
It may require splitting the bits that are too closely tied to the
external interface they are implementing from these functions,
generalizing only the core-ish logic from them, and moving them to a
more library-ish file as a preparatory step. Such a library-ish file
may be created inside lib/ subdirectory from the get-go.
Until that kind of code restructure happens, I do not see much sense
in just moving files, e.g. renaming revision.c to src/revision.c or
lib/revision.c or somesuch.
^ permalink raw reply
* Re: Rebase doesn't restore branch pointer back on out of memory
From: Junio C Hamano @ 2012-10-19 22:24 UTC (permalink / raw)
To: Alexander Kostikov; +Cc: Andrew Wong, git
In-Reply-To: <CAGAhT3nNdPxtDKtVCnPAa4OWOhGygzoq6DqHVEckQ60XWAAKZA@mail.gmail.com>
Alexander Kostikov <alex.kostikov@gmail.com> writes:
> Sorry to bother but I was wondering what would be the release version
> that would have this patch.
That depends on how well the people who are interested in this
change test it to smoke out potential issues (if any) in it.
It currently is on the 'pu' branch.
^ permalink raw reply
* Re: libgit2 status
From: dag @ 2012-10-19 22:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, Thiago Farina, git, Nicolas Sebrecht,
Andreas Ericsson, greened
In-Reply-To: <7vvce6i5j2.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I actually hate "include/git.h vs src/git.c"; you have distinction
> between .c and .h already.
+1
-David
^ permalink raw reply
* Re: [msysGit] Re: Git for Windows and line endings
From: John Szakmeister @ 2012-10-19 21:53 UTC (permalink / raw)
To: Chris B; +Cc: Johannes Schindelin, Erik Faye-Lund, git, msysgit
In-Reply-To: <CADKp0pxuFsSEeZoeemyaqhSJEcsjj1arEOsF4Ub8=76y7tkwHg@mail.gmail.com>
On Fri, Oct 19, 2012 at 10:39 AM, Chris B <chris.blaszczynski@gmail.com> wrote:
[snip]
> - Windows has been able to cope with UNIX line endings a long time; no
> developer is using a default Notepad to open files with high
> expectations. Any Windows development tool and editor worth anything
> I've used is able to handle both just fine.
That's simply not a true, across the board statement. I really wish
it was, because I find the issue troublesome as well. Unfortunately,
there are still plenty of applications that don't cope with mixed line
endings very well. We have a backend that targets several platforms,
and the Windows toolchain is quite keen on having CRLF endings, but we
like LF under Linux, and others.
I also wish that no developers were using Notepad either. Any time
I've run across it, I've tried to point folks at much more capable
environments... but that only has moderate success. Of course, it's
even worse these days because Notepad puts a BOM at the front of the
file, making Git think it's a binary file.
One thing I do wish is that I didn't have to do the song and dance to
convert all the files when I set gitattributes:
$ echo "* text=auto" >>.gitattributes
$ rm .git/index # Remove the index to force git to
$ git reset # re-scan the working directory
$ git status # Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"
One thing that I like about Subversion was that when you set
svn:eol-style, it took.
-John
^ permalink raw reply
* Re: Rebase doesn't restore branch pointer back on out of memory
From: Alexander Kostikov @ 2012-10-19 21:49 UTC (permalink / raw)
To: Andrew Wong; +Cc: gitster, git
In-Reply-To: <1349927643-7195-1-git-send-email-andrew.kw.w@gmail.com>
Sorry to bother but I was wondering what would be the release version
that would have this patch.
-- Alexander
On Wed, Oct 10, 2012 at 8:54 PM, Andrew Wong <andrew.kw.w@gmail.com> wrote:
>
> For the 'format-patch' part, originally I was going to do something like:
>
> git format-patch ... || {
> ...
> }
>
> But later I thought it's better to use a consistent style as the following
> 'am' part.
>
> For the 'am' part, if we kept the following line at the end of the if-block:
>
> fi && move_to_original_branch
>
> then, before exiting the if-block, we would have to do something like:
>
> test 0 != $ret && false
>
> which seems a bit ugly to me. So I removed the use of '&&', and rearrange the
> 'write_basic_state' and 'move_to_original_branch' to make the logic flow a bit
> better and easier to read.
>
> Andrew Wong (1):
> rebase: Handle cases where format-patch fails
>
> git-rebase--am.sh | 51 +++++++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 45 insertions(+), 6 deletions(-)
>
> --
> 1.8.0.rc0.19.gc58a63a.dirty
>
--
Alexander Kostikov
^ permalink raw reply
* Re: [PATCH] Fix potential hang in https handshake.
From: Junio C Hamano @ 2012-10-19 21:49 UTC (permalink / raw)
To: szager; +Cc: git, daniel, sop, peff
In-Reply-To: <5081c896.cMdU6VySSwFm0uOa%szager@google.com>
Thanks.
^ permalink raw reply
* [PATCH] Fix potential hang in https handshake.
From: szager @ 2012-10-19 21:39 UTC (permalink / raw)
To: git; +Cc: daniel, sop, gitster, peff
It has been observed that curl_multi_timeout may return a very long
timeout value (e.g., 294 seconds and some usec) just before
curl_multi_fdset returns no file descriptors for reading. The
upshot is that select() will hang for a long time -- long enough for
an https handshake to be dropped. The observed behavior is that
the git command will hang at the terminal and never transfer any
data.
This patch is a workaround for a probable bug in libcurl. The bug
only seems to manifest around a very specific set of circumstances:
- curl version (from curl/curlver.h):
#define LIBCURL_VERSION_NUM 0x071307
- git-remote-https running on an ubuntu-lucid VM.
- Connecting through squid proxy running on another VM.
Interestingly, the problem doesn't manifest if a host connects
through squid proxy running on localhost; only if the proxy is on
a separate VM (not sure if the squid host needs to be on a separate
physical machine). That would seem to suggest that this issue
is timing-sensitive.
This patch is more or less in line with a recommendation in the
curl docs about how to behave when curl_multi_fdset doesn't return
and file descriptors:
http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
Signed-off-by: Stefan Zager <szager@google.com>
---
http.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c
index df9bb71..b7e7ab4 100644
--- a/http.c
+++ b/http.c
@@ -631,6 +631,18 @@ void run_active_slot(struct active_request_slot *slot)
FD_ZERO(&excfds);
curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
+ /*
+ * It can happen that curl_multi_timeout returns a pathologically
+ * long timeout when curl_multi_fdset returns no file descriptors
+ * to read. See commit message for more details.
+ */
+ if (max_fd < 0 &&
+ (select_timeout.tv_sec > 0 ||
+ select_timeout.tv_usec > 50000)) {
+ select_timeout.tv_sec = 0;
+ select_timeout.tv_usec = 50000;
+ }
+
select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
}
}
--
1.7.7.3
^ permalink raw reply related
* Re: Fix potential hang in https handshake (v3)
From: Junio C Hamano @ 2012-10-19 21:21 UTC (permalink / raw)
To: Jeff King; +Cc: szager, git, sop, daniel
In-Reply-To: <20121019210851.GD24184@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> + if (max_fd < 0 &&
>> + select_timeout.tv_sec > 0 ||
>> + select_timeout.tv_usec > 50000) {
>> + select_timeout.tv_sec = 0;
>> + select_timeout.tv_usec = 50000;
>> + }
>
> Should there be parentheses separating the || bit from the &&?
Yeah, I think there should be. Thanks for sharp eyes.
^ permalink raw reply
* Re: Fix potential hang in https handshake (v3)
From: Jeff King @ 2012-10-19 21:08 UTC (permalink / raw)
To: szager; +Cc: git, gitster, sop, daniel
In-Reply-To: <5081c054.eD2hEWR8K8zW5vdM%szager@google.com>
On Fri, Oct 19, 2012 at 02:04:20PM -0700, szager@google.com wrote:
> From 32e06128dbc97ceb0d060c88ec8db204fa51be5c Mon Sep 17 00:00:00 2001
> From: Stefan Zager <szager@google.com>
> Date: Thu, 18 Oct 2012 16:23:53 -0700
Drop these lines.
> Subject: [PATCH] Fix potential hang in https handshake.
And make this one your actual email subject.
> It has been observed that curl_multi_timeout may return a very long
> timeout value (e.g., 294 seconds and some usec) just before
> curl_multi_fdset returns no file descriptors for reading. The
> upshot is that select() will hang for a long time -- long enough for
> an https handshake to be dropped. The observed behavior is that
> the git command will hang at the terminal and never transfer any
> data.
>
> This patch is a workaround for a probable bug in libcurl. The bug
> only seems to manifest around a very specific set of circumstances:
>
> - curl version (from curl/curlver.h):
>
> #define LIBCURL_VERSION_NUM 0x071307
>
> - git-remote-https running on an ubuntu-lucid VM.
> - Connecting through squid proxy running on another VM.
>
> Interestingly, the problem doesn't manifest if a host connects
> through squid proxy running on localhost; only if the proxy is on
> a separate VM (not sure if the squid host needs to be on a separate
> physical machine). That would seem to suggest that this issue
> is timing-sensitive.
Thanks, that explanation makes much more sense.
> diff --git a/http.c b/http.c
> index df9bb71..51eef02 100644
> --- a/http.c
> +++ b/http.c
> @@ -631,6 +631,17 @@ void run_active_slot(struct active_request_slot *slot)
> FD_ZERO(&excfds);
> curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
>
> + /* It can happen that curl_multi_timeout returns a pathologically
> + * long timeout when curl_multi_fdset returns no file descriptors
> + * to read. See commit message for more details.
> + */
Minor nit, but our multi-line comment style is:
/*
* blah blah blah
*/
> + if (max_fd < 0 &&
> + select_timeout.tv_sec > 0 ||
> + select_timeout.tv_usec > 50000) {
> + select_timeout.tv_sec = 0;
> + select_timeout.tv_usec = 50000;
> + }
Should there be parentheses separating the || bit from the &&?
-Peff
^ permalink raw reply
* Fix potential hang in https handshake (v3)
From: szager @ 2012-10-19 21:04 UTC (permalink / raw)
To: git; +Cc: peff, gitster, sop, daniel
>From 32e06128dbc97ceb0d060c88ec8db204fa51be5c Mon Sep 17 00:00:00 2001
From: Stefan Zager <szager@google.com>
Date: Thu, 18 Oct 2012 16:23:53 -0700
Subject: [PATCH] Fix potential hang in https handshake.
It has been observed that curl_multi_timeout may return a very long
timeout value (e.g., 294 seconds and some usec) just before
curl_multi_fdset returns no file descriptors for reading. The
upshot is that select() will hang for a long time -- long enough for
an https handshake to be dropped. The observed behavior is that
the git command will hang at the terminal and never transfer any
data.
This patch is a workaround for a probable bug in libcurl. The bug
only seems to manifest around a very specific set of circumstances:
- curl version (from curl/curlver.h):
#define LIBCURL_VERSION_NUM 0x071307
- git-remote-https running on an ubuntu-lucid VM.
- Connecting through squid proxy running on another VM.
Interestingly, the problem doesn't manifest if a host connects
through squid proxy running on localhost; only if the proxy is on
a separate VM (not sure if the squid host needs to be on a separate
physical machine). That would seem to suggest that this issue
is timing-sensitive.
This patch is more or less in line with a recommendation in the
curl docs about how to behave when curl_multi_fdset doesn't return
and file descriptors:
http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
Signed-off-by: Stefan Zager <szager@google.com>
---
http.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c
index df9bb71..51eef02 100644
--- a/http.c
+++ b/http.c
@@ -631,6 +631,17 @@ void run_active_slot(struct active_request_slot *slot)
FD_ZERO(&excfds);
curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
+ /* It can happen that curl_multi_timeout returns a pathologically
+ * long timeout when curl_multi_fdset returns no file descriptors
+ * to read. See commit message for more details.
+ */
+ if (max_fd < 0 &&
+ select_timeout.tv_sec > 0 ||
+ select_timeout.tv_usec > 50000) {
+ select_timeout.tv_sec = 0;
+ select_timeout.tv_usec = 50000;
+ }
+
select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
}
}
--
1.7.7.3
^ permalink raw reply related
* What's cooking in git.git (Oct 2012, #06; Fri, 19)
From: Junio C Hamano @ 2012-10-19 21:03 UTC (permalink / raw)
To: git
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 1.8.0 release is expected to be tagged this weekend, after which
I'd disappear for a few weeks, and Git will be in steady and good
hands of Jeff King (thanks) in the meantime.
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]
* js/mingw-fflush-errno (2012-10-17) 1 commit
(merged to 'next' on 2012-10-18 at 43d6ebb)
+ maybe_flush_or_die: move a too-loose Windows specific error
Will merge to 'master' in the first batch after 1.8.0 ships.
* mo/cvs-server-cleanup (2012-10-16) 10 commits
(merged to 'next' on 2012-10-18 at 5a60da1)
+ cvsserver status: provide real sticky info
+ cvsserver: cvs add: do not expand directory arguments
+ cvsserver: use whole CVS rev number in-process; don't strip "1." prefix
+ cvsserver: split up long lines in req_{status,diff,log}
+ cvsserver: clean up client request handler map comments
+ cvsserver: remove unused functions _headrev and gethistory
+ cvsserver update: comment about how we shouldn't remove a user-modified file
+ cvsserver: add comments about database schema/usage
+ cvsserver: removed unused sha1Or-k mode from kopts_from_path
+ cvsserver t9400: add basic 'cvs log' test
(this branch is used by mo/cvs-server-updates.)
* mo/cvs-server-updates (2012-10-16) 10 commits
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
(this branch uses mo/cvs-server-cleanup.)
* ta/doc-cleanup (2012-10-18) 5 commits
- Documentation/howto: convert plain text files to asciidoc
- Documentation/technical: convert plain text files to asciidoc
- Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
- Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
- Split over-long synopsis in git-fetch-pack.txt into several lines
Misapplication of a patch fixed; the ones near the tip needs to
update the links to point at the html files, though.
* lt/diff-stat-show-0-lines (2012-10-17) 1 commit
- Fix "git diff --stat" for interesting - but empty - file changes
We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
* jc/prettier-pretty-note (2012-10-19) 7 commits
- Documentation: decribe format-patch --notes
- format-patch --notes: show notes after three-dashes
- format-patch: append --signature after notes
- pretty_print_commit(): do not append notes message
- pretty: prepare notes message at a centralized place
- format_note(): simplify API
- pretty: remove reencode_commit_message()
Needs updates to the placeholder documentation.
* jk/sh-setup-in-filter-branch (2012-10-18) 2 commits
(merged to 'next' on 2012-10-18 at 3864adc)
+ filter-branch: use git-sh-setup's ident parsing functions
+ git-sh-setup: refactor ident-parsing functions
Will merge to 'master' in the second batch after 1.8.0 ships.
* jk/strbuf-detach-always-non-null (2012-10-18) 1 commit
(merged to 'next' on 2012-10-18 at 54561c7)
+ strbuf: always return a non-NULL value from strbuf_detach
Will merge to 'master' in the first batch after 1.8.0 ships.
* nd/status-long (2012-10-18) 1 commit
(merged to 'next' on 2012-10-18 at 53940a1)
+ status: add --long output format option
Allow an earlier "--short" option on the command line to be
countermanded with the "--long" option for "git status" and "git
commit".
Will merge to 'master' in the second batch after 1.8.0 ships.
* rs/branch-del-symref (2012-10-18) 5 commits
(merged to 'next' on 2012-10-18 at 68ee254)
+ branch: show targets of deleted symrefs, not sha1s
+ branch: skip commit checks when deleting symref branches
+ branch: delete symref branch, not its target
+ branch: factor out delete_branch_config()
+ branch: factor out check_branch_commit()
A symbolic ref refs/heads/SYM was not correctly removed with
"git branch -d SYM"; the command removed the ref pointed by
SYM instead.
Will merge to 'master' in the second batch after 1.8.0 ships.
* sz/maint-curl-multi-timeout (2012-10-18) 1 commit
- Fix potential hang in https handshake
Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptors to wait on and the http
transport ended up sleeping for minutes in select(2) system call.
Detect this and reduce the wait timeout in such a case.
* jc/same-encoding (2012-10-18) 1 commit
- reencode_string(): introduce and use same_encoding()
Various codepaths checked if two encoding names are the same using
ad-hoc code and some of them ended up asking iconv() to convert
between "utf8" and "UTF-8". The former is not a valid way to spell
the encoding name, but often people use it by mistake, and we
equated them in some but not all codepaths. Introduce a new helper
function to make these codepaths consistent.
* nd/tree-walk-enum-cleanup (2012-10-19) 1 commit
- tree-walk: use enum interesting instead of integer
--------------------------------------------------
[Stalled]
* mh/ceiling (2012-09-29) 9 commits
- t1504: stop resolving symlinks in GIT_CEILING_DIRECTORIES
- longest_ancestor_length(): resolve symlinks before comparing paths
- longest_ancestor_length(): use string_list_longest_prefix()
- longest_ancestor_length(): always add a slash to the end of prefixes
- longest_ancestor_length(): explicitly filter list before loop
- longest_ancestor_length(): use string_list_split()
- Introduce new function real_path_if_valid()
- real_path_internal(): add comment explaining use of cwd
- Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
The solution felt a bit unnecessarily convoluted to me.
Expecting a reroll.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-09-25 at 116e58f)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* fa/vcs-svn (2012-10-07) 4 commits
- vcs-svn: remove repo_tree
- vcs-svn/svndump: rewrite handle_node(), begin|end_revision()
- vcs-svn/svndump: restructure node_ctx, rev_ctx handling
- svndump: move struct definitions to .h
(this branch uses fa/remote-svn.)
A follow-up to a GSoC project, but seems not quite ready.
Will discard.
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-10-07) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* ph/credential-refactor (2012-09-02) 5 commits
- wincred: port to generic credential helper
- Merge branch 'ef/win32-cred-helper' into ph/credential-refactor
- osxkeychain: port to generic credential helper implementation
- gnome-keyring: port to generic helper implementation
- contrib: add generic credential helper
Attempts to refactor to share code among OSX keychain, Gnome keyring
and Win32 credential helpers.
* ms/contrib-thunderbird-updates (2012-08-31) 2 commits
- [SQUASH] minimum fixup
- Thunderbird: fix appp.sh format problems
Update helper to send out format-patch output using Thunderbird.
Seems to have design regression for silent users.
* jx/test-real-path (2012-08-27) 1 commit
- test: set the realpath of CWD as TRASH_DIRECTORY
Running tests with the "trash" directory elsewhere with the "--root"
option did not work well if the directory was specified by a symbolic
link pointing at it.
Seems broken as it makes $(pwd) and TRASH_DIRECTORY inconsistent.
Will discard.
* jc/maint-push-refs-all (2012-08-27) 2 commits
- get_fetch_map(): tighten checks on dest refs
- [BROKEN] fetch/push: allow refs/*:refs/*
Allows pushing and fetching everything including refs/stash.
This is broken (see the log message there).
Not ready.
* jc/add-delete-default (2012-08-13) 1 commit
(merged to 'next' on 2012-10-11 at bd9e5cb)
+ git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* tx/relative-in-the-future (2012-08-16) 2 commits
- date: show relative dates in the future
- date: refactor the relative date logic from presentation
Not my itch; rewritten an earlier submission by Tom Xue into
somewhat more maintainable form, though it breaks existing i18n.
Waiting for a voluteer to fix it up.
Otherwise may discard.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
"The first remote becomes the default" bit is better done as a
separate step.
* jc/split-blob (2012-04-03) 6 commits
- chunked-object: streaming checkout
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- packfile: use varint functions
Not ready.
I finished the streaming checkout codepath, but as explained in
127b177 (bulk-checkin: support chunked-object encoding, 2011-11-30),
these are still early steps of a long and painful journey. At least
pack-objects and fsck need to learn the new encoding for the series
to be usable locally, and then index-pack/unpack-objects needs to
learn it to be used remotely.
Given that I heard a lot of noise that people want large files, and
that I was asked by somebody at GitTogether'11 privately for an
advice on how to pay developers (not me) to help adding necessary
support, I am somewhat disappointed that the original patch series
that was sent long time ago still remains here without much comments
and updates from the developer community. I even made the interface
to the logic that decides where to split chunks easily replaceable,
and I deliberately made the logic in the original patch extremely
stupid to entice others, especially the "bup" fanbois, to come up
with a better logic, thinking that giving people an easy target to
shoot for, they may be encouraged to help out. The plan is not
working :-<.
--------------------------------------------------
[Cooking]
* jk/maint-http-init-not-in-result-handler (2012-10-12) 2 commits
(merged to 'next' on 2012-10-16 at cc88829)
+ http: do not set up curl auth after a 401
+ remote-curl: do not call run_slot repeatedly
Further clean-up to the http codepath that picks up results after
cURL library is done with one request slot.
Will merge to 'master' in the second batch after 1.8.0 ships.
* nd/grep-true-path (2012-10-12) 1 commit
(merged to 'next' on 2012-10-16 at 8a75ac8)
+ grep: stop looking at random places for .gitattributes
"git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
Will merge to 'master' in the second batch after 1.8.0 ships.
* cr/cvsimport-local-zone (2012-10-16) 1 commit
- git-cvsimport: allow author-specific timezones
Allows "cvsimport" to read per-author timezone from the author info
file.
* fc/completion-send-email-with-format-patch (2012-10-16) 1 commit
- completion: add format-patch options to send-email
* fc/zsh-completion (2012-10-15) 3 commits
- completion: add new zsh completion
- tests: use __gitcompadd to simplify completion tests
- completion: add new __gitcompadd helper
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
- apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Extra set of eyeballs appreciated.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
- config: exit on error accessing any config file
- doc: advertise GIT_CONFIG_NOSYSTEM
- config: treat user and xdg config permission problems as errors
- config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT; I think a bit more refactored approach to consistently
address permission errors across config, exclude and attrs is
desirable. Don't we also need a check for an opposite situation
where we open .config/git/config or .gitattributes for reading but
they turn out to be directories?
* rs/lock-correct-ref-during-delete (2012-10-16) 1 commit
(merged to 'next' on 2012-10-16 at 850b5b2)
+ refs: lock symref that is to be deleted, not its target
When "update-ref -d --no-deref SYM" tried to delete a symbolic ref
SYM, it incorrectly locked the underlying reference pointed by SYM,
not the symbolic ref itself.
* as/check-ignore (2012-10-19) 13 commits
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
(this branch uses nd/attr-match-optim and nd/attr-match-optim-more; is tangled with nd/wildmatch.)
Duy helped to reroll this.
* js/format-2047 (2012-10-18) 7 commits
(merged to 'next' on 2012-10-18 at 5b9a629)
+ format-patch tests: check quoting/encoding in To: and Cc: headers
+ format-patch: fix rfc2047 address encoding with respect to rfc822 specials
+ format-patch: make rfc2047 encoding more strict
+ format-patch: introduce helper function last_line_length()
+ format-patch: do not wrap rfc2047 encoded headers too late
+ format-patch: do not wrap non-rfc2047 headers too early
+ utf8: fix off-by-one wrapping of text
Fixes many rfc2047 quoting issues in the output from format-patch.
* km/send-email-compose-encoding (2012-10-10) 1 commit
(merged to 'next' on 2012-10-11 at d94bd05)
+ git-send-email: introduce compose-encoding
"git send-email --compose" can let the user create a non-ascii
cover letter message, but there was not a way to mark it with
appropriate content type before sending it out.
Will merge to 'master' in the second batch after 1.8.0 ships.
* so/prompt-command (2012-10-17) 4 commits
(merged to 'next' on 2012-10-17 at 0843a8b)
+ coloured git-prompt: paint detached HEAD marker in red
(merged to 'next' on 2012-10-16 at adf81be)
+ Fix up colored git-prompt
(merged to 'next' on 2012-10-11 at 1a14825)
+ show color hints based on state of the git tree
+ Allow __git_ps1 to be used in PROMPT_COMMAND
Updates __git_ps1 so that it can be used as $PROMPT_COMMAND,
instead of being used for command substitution in $PS1, to embed
color escape sequences in its output.
* jc/test-say-color-avoid-echo-escape (2012-10-11) 1 commit
(merged to 'next' on 2012-10-11 at 639036d)
+ test-lib: Fix say_color () not to interpret \a\b\c in the message
Recent nd/wildmatch series was the first to reveal this ancient bug
in the test scaffolding.
Will merge to 'master' in the first batch after 1.8.0 ships.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* da/mergetools-p4 (2012-10-11) 1 commit
(merged to 'next' on 2012-10-12 at 16f5c06)
+ mergetools/p4merge: Handle "/dev/null"
Will merge to 'master' in the first batch after 1.8.0 ships.
* nd/wildmatch (2012-10-15) 13 commits
(merged to 'next' on 2012-10-16 at 5eaf3a4)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
(this branch uses nd/attr-match-optim and nd/attr-match-optim-more; is tangled with as/check-ignore.)
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* nd/attr-match-optim (2012-10-05) 2 commits
(merged to 'next' on 2012-10-08 at bfbdd8a)
+ attr: avoid searching for basename on every match
+ attr: avoid strlen() on every match
(this branch is used by as/check-ignore, nd/attr-match-optim-more and nd/wildmatch.)
Trivial and obvious optimization for finding attributes that match
a given path.
Will merge to 'master' in the first batch after 1.8.0 ships.
* nd/attr-match-optim-more (2012-10-15) 7 commits
(merged to 'next' on 2012-10-16 at 9baac99)
+ attr: more matching optimizations from .gitignore
+ gitignore: make pattern parsing code a separate function
+ exclude: split pathname matching code into a separate function
+ exclude: fix a bug in prefix compare optimization
+ exclude: split basename matching code into a separate function
+ exclude: stricten a length check in EXC_FLAG_ENDSWITH case
+ Merge commit 'f9f6e2c' into nd/attr-match-optim-more
(this branch is used by as/check-ignore and nd/wildmatch; uses nd/attr-match-optim.)
Start laying the foundation to build the "wildmatch" after we can
agree on its desired semantics.
* jc/grep-pcre-loose-ends (2012-10-09) 7 commits
(merged to 'next' on 2012-10-11 at fec8530)
+ log: honor grep.* configuration
+ log --grep: accept --basic-regexp and --perl-regexp
+ log --grep: use the same helper to set -E/-F options as "git grep"
+ revisions: initialize revs->grep_filter using grep_init()
+ grep: move pattern-type bits support to top-level grep.[ch]
+ grep: move the configuration parsing logic to grep.[ch]
+ builtin/grep.c: make configuration callback more reusable
"git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally. The early part of this series is a fix for it.
Will merge to 'master' in the second batch after 1.8.0 ships.
* jk/peel-ref (2012-10-04) 4 commits
(merged to 'next' on 2012-10-08 at 4adfa2f)
+ upload-pack: use peel_ref for ref advertisements
+ peel_ref: check object type before loading
+ peel_ref: do not return a null sha1
+ peel_ref: use faster deref_tag_noverify
Speeds up "git upload-pack" (what is invoked by "git fetch" on the
other side of the connection) by reducing the cost to advertise the
branches and tags that are available in the repository.
Will merge to 'master' in the first batch after 1.8.0 ships.
* fa/remote-svn (2012-10-07) 16 commits
(merged to 'next' on 2012-10-07 at 7b90cf4)
+ Add a test script for remote-svn
+ remote-svn: add marks-file regeneration
+ Add a svnrdump-simulator replaying a dump file for testing
+ remote-svn: add incremental import
+ remote-svn: Activate import/export-marks for fast-import
+ Create a note for every imported commit containing svn metadata
+ vcs-svn: add fast_export_note to create notes
+ Allow reading svn dumps from files via file:// urls
+ remote-svn, vcs-svn: Enable fetching to private refs
+ When debug==1, start fast-import with "--stats" instead of "--quiet"
+ Add documentation for the 'bidi-import' capability of remote-helpers
+ Connect fast-import to the remote-helper via pipe, adding 'bidi-import' capability
+ Add argv_array_detach and argv_array_free_detached
+ Add svndump_init_fd to allow reading dumps from arbitrary FDs
+ Add git-remote-testsvn to Makefile
+ Implement a remote helper for svn in C
(this branch is used by fa/vcs-svn.)
A GSoC project.
Will merge to 'master' in the first batch after 1.8.0 ships.
* bw/config-lift-variable-name-length-limit (2012-10-01) 1 commit
(merged to 'next' on 2012-10-08 at 69f54f4)
+ Remove the hard coded length limit on variable names in config files
The configuration parser had an unnecessary hardcoded limit on
variable names that was not checked consistently. Lift the limit.
Will merge to 'master' in the first batch after 1.8.0 ships.
* jm/diff-context-config (2012-10-02) 2 commits
(merged to 'next' on 2012-10-02 at e57700a)
+ t4055: avoid use of sed 'a' command
(merged to 'next' on 2012-10-01 at 509a558)
+ diff: diff.context configuration gives default to -U
Teaches a new configuration variable to "git diff" Porcelain and
its friends.
Will merge to 'master' in the first batch after 1.8.0 ships.
* jl/submodule-add-by-name (2012-09-30) 2 commits
(merged to 'next' on 2012-10-08 at 9408d8d)
+ submodule add: Fail when .git/modules/<name> already exists unless forced
+ Teach "git submodule add" the --name option
If you remove a submodule, in order to keep the repository so that
"git checkout" to an older commit in the superproject history can
resurrect the submodule, the real repository will stay in $GIT_DIR
of the superproject. A later "git submodule add $path" to add a
different submodule at the same path will fail. Diagnose this case
a bit better, and if the user really wants to add an unrelated
submodule at the same path, give the "--name" option to give it a
place in $GIT_DIR of the superproject that does not conflict with
the original submodule.
Will merge to 'master' in the second batch after 1.8.0 ships.
* jl/submodule-rm (2012-09-29) 1 commit
(merged to 'next' on 2012-10-01 at 4e5c4fc)
+ submodule: teach rm to remove submodules unless they contain a git directory
"git rm submodule" cannot blindly remove a submodule directory as
its working tree may have local changes, and worse yet, it may even
have its repository embedded in it. Teach it some special cases
where it is safe to remove a submodule, specifically, when there is
no local changes in the submodule working tree, and its repository
is not embedded in its working tree but is elsewhere and uses the
gitfile mechanism to point at it.
Will merge to 'master' in the second batch after 1.8.0 ships.
* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
- pretty: support %>> that steal trailing spaces
- pretty: support truncating in %>, %< and %><
- pretty: support padding placeholders, %< %> and %><
- pretty: two phase conversion for non utf-8 commits
- utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
- utf8.c: move display_mode_esc_sequence_len() for use by other functions
- pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
- pretty: split parsing %C into a separate function
- pretty: share code between format_decoration and show_decorations
* jk/no-more-pre-exec-callback (2012-06-05) 1 commit
(merged to 'next' on 2012-10-12 at 69fed45)
+ pager: drop "wait for output to run less" hack
(Originally merged to 'next' on 2012-07-23)
Removes a workaround for buggy version of less older than version
406.
Will merge to 'master' in the first batch after 1.8.0 ships.
^ permalink raw reply
* Re: Re: Git for Windows and line endings
From: Jeff King @ 2012-10-19 20:59 UTC (permalink / raw)
To: Chris B; +Cc: Johannes Schindelin, Erik Faye-Lund, git, msysgit
In-Reply-To: <CADKp0pxuFsSEeZoeemyaqhSJEcsjj1arEOsF4Ub8=76y7tkwHg@mail.gmail.com>
On Fri, Oct 19, 2012 at 10:39:27AM -0400, Chris B wrote:
> I would like to point out:
> - Git on Linux does not mess around with line endings. I can create
> and edit a file in either line ending on Linux and commit and still
> have it untouched.
> - Git on Windows via Cygwin also does not mess around.
> - If those flavors of Git don't mess around, why should msysgit do it?
Most platforms (i.e., the userspace of most unix-y distributions) do not
mess around with line endings, either, so it is easy to have a sane
default there. I think the Cygwin build just followed that existing
defaults.
But msysgit's behavior was directly responding to user complaints. And
there were a lot of them. I do not use Windows myself, so I have only
the perspective of reading the list discussions. And that only what
bleeds onto the git@vger list, not the msysgit list.
Searching for "crlf" on the list yields over 2300 messages, many of
which discuss specific problems people are having without CRLF support.
I do not think any decision in the open source world is final, and
correcting a wrong decision from the past should always be an option.
But I do not think it is constructive to say "your decision is wrong"
without responding to the arguments that led to that decision. All I see
in your email is "your default is not my preference" without responding
to the discussion and perspectives of others through the years.
> - Windows has been able to cope with UNIX line endings a long time; no
> developer is using a default Notepad to open files with high
> expectations. Any Windows development tool and editor worth anything
> I've used is able to handle both just fine.
Again, I do not use Windows, so my anecdotes are purely culled from the
list. But people have mentioned that Visual Studio is bad for writing
our CRLFs for files which already have LFs. This makes diffs unreadable,
and gives merges, rebases and cherry-picks lots of spurious conflicts.
> - If there was SO MUCH thought into this, then it was too much; it was
> the wrong thought. There should not have been much at all, and just
> allow Git to do what it does: store things *exactly* as you put it in.
> Allow the clients to worry about things like line endings should they
> have the need to worry about it. I'm not seeing how the revision
> system has any business making alterations to things one commits into
> it.
One of the problems is that people do not realize the issue until they
have built a lot of history with CRLFs or mixed line endings (which they
might not even realize until the project starts being used by somebody
with a different editor or platform), and then they have a very painful
flag day turning on these options and normalizing the repository.
-Peff
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* [PATCH] diff: diff.context configuration gives default to -U
From: Jeff Muizelaar @ 2012-10-19 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3923p0tb.fsf@alter.siamese.dyndns.org>
Introduce a configuration variable diff.context that tells
Porcelain commands to use a non-default number of context
lines instead of 3 (the default). With this variable, users
do not have to keep repeating "git log -U8" from the command
line; instead, it becomes sufficient to say "git config
diff.context 8" just once.
Signed-off-by: Jeff Muizelaar <jmuizelaar@mozilla.com>
---
On 2012-09-27, at 6:18 PM, Junio C Hamano wrote:
> Jeff Muizelaar <jmuizelaar@mozilla.com> writes:
>
>> + if (!strcmp(var, "diff.context")) {
>> + diff_context_default = git_config_int(var, value);
>> + if (diff_context_default < 0)
>> + return -1;
>> + return 0;
>
> I am somewhat torn on this part. This fails the entire command when
> diff.context is set to non integer or negative integer, which means
> trouble for a user of a future version of git that accepts such a
> value to do something intelligent we do not anticipate today. The
> useful configuration value cannot be given unless the user is
> certain that .gitconfig file will never be read by older version of
> git.
>
> Perhaps it is OK, at least for now. We'd have the same worry for
> what is given to -U<n> anyway.
I left this as is.
>> +test_expect_success 'diff.context affects log' '
>> + git log -1 -p >output &&
>> + ! grep firstline output &&
>> + git config diff.context 8 &&
>> + git log -1 -p >output &&
>> + grep firstline output
>> +'
>
> Is there a reason to favor "log -1 -p" over something a lot simpler
> like "show"? Not requesting to change anything, but just being
> curious.
No. I changed it to "show" to avoid the surprise.
Other than that I included the test changes you suggested. I did however
adjust the sed 'a' command. It seems that GNU sed and BSD sed have incompatible behaviour
here. Unfortunately this also seems to screw up the indentation.
---
Documentation/diff-config.txt | 4 ++
diff.c | 9 ++++-
t/t4055-diff-context.sh | 94 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 106 insertions(+), 1 deletions(-)
create mode 100755 t/t4055-diff-context.sh
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 67a90a8..75ab8a5 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -56,6 +56,10 @@ diff.statGraphWidth::
Limit the width of the graph part in --stat output. If set, applies
to all commands generating --stat output except format-patch.
+diff.context::
+ Generate diffs with <n> lines of context instead of the default of
+ 3. This value is overridden by the -U option.
+
diff.external::
If this config variable is set, diff generation is not
performed using the internal diff machinery, but using the
diff --git a/diff.c b/diff.c
index 35d3f07..86e5f2a 100644
--- a/diff.c
+++ b/diff.c
@@ -26,6 +26,7 @@ static int diff_detect_rename_default;
static int diff_rename_limit_default = 400;
static int diff_suppress_blank_empty;
static int diff_use_color_default = -1;
+static int diff_context_default = 3;
static const char *diff_word_regex_cfg;
static const char *external_diff_cmd_cfg;
int diff_auto_refresh_index = 1;
@@ -141,6 +142,12 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
diff_use_color_default = git_config_colorbool(var, value);
return 0;
}
+ if (!strcmp(var, "diff.context")) {
+ diff_context_default = git_config_int(var, value);
+ if (diff_context_default < 0)
+ return -1;
+ return 0;
+ }
if (!strcmp(var, "diff.renames")) {
diff_detect_rename_default = git_config_rename(var, value);
return 0;
@@ -3170,7 +3177,7 @@ void diff_setup(struct diff_options *options)
options->break_opt = -1;
options->rename_limit = -1;
options->dirstat_permille = diff_dirstat_permille_default;
- options->context = 3;
+ options->context = diff_context_default;
DIFF_OPT_SET(options, RENAME_EMPTY);
options->change = diff_change;
diff --git a/t/t4055-diff-context.sh b/t/t4055-diff-context.sh
new file mode 100755
index 0000000..60348b7
--- /dev/null
+++ b/t/t4055-diff-context.sh
@@ -0,0 +1,94 @@
+#!/bin/sh
+#
+# Copyright (c) 2012 Mozilla Foundation
+#
+
+test_description='diff.context configuration'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ cat >x <<-\EOF &&
+ firstline
+ b
+ c
+ d
+ e
+ f
+ preline
+ postline
+ i
+ j
+ k
+ l
+ m
+ n
+ EOF
+ git update-index --add x &&
+ git commit -m initial &&
+
+ git cat-file blob HEAD:x |
+ sed "s/preline/preline\\
+ADDED/" >x &&
+ git update-index --add x &&
+ git commit -m next &&
+
+ git cat-file blob HEAD:x |
+ sed s/ADDED/MODIFIED/ >x
+'
+
+test_expect_success 'the default number of context lines is 3' '
+ git diff >output &&
+ ! grep "^ d" output &&
+ grep "^ e" output &&
+ grep "^ j" output &&
+ ! grep "^ k" output
+'
+
+test_expect_success 'diff.context honored by "show"' '
+ git show >output &&
+ ! grep firstline output &&
+ git config diff.context 8 &&
+ git show >output &&
+ grep "^ firstline" output
+'
+
+test_expect_success 'The -U option overrides diff.context' '
+ git config diff.context 8 &&
+ git log -U4 -1 >output &&
+ ! grep "^ firstline" output
+'
+
+test_expect_success 'diff.context honored by "diff"' '
+ git config diff.context 8 &&
+ git diff >output &&
+ grep "^ firstline" output
+'
+
+test_expect_success 'plumbing not affected' '
+ git config diff.context 8 &&
+ git diff-files -p >output &&
+ ! grep "^ firstline" output
+'
+
+test_expect_success 'non-integer config parsing' '
+ git config diff.context no &&
+ test_must_fail git diff 2>output &&
+ test_i18ngrep "bad config value" output
+'
+
+test_expect_success 'negative integer config parsing' '
+ git config diff.context -1 &&
+ test_must_fail git diff 2>output &&
+ test_i18ngrep "bad config file" output
+'
+
+test_expect_success '-U0 is valid, so is diff.context=0' '
+ git config diff.context 0 &&
+ git diff >output &&
+ grep "^-ADDED" output &&
+ grep "^+MODIFIED" output &&
+ ! grep "^ postline" output
+'
+
+test_done
--
1.7.4.4
^ permalink raw reply related
* Re: Fix potential hang in https handshake.
From: Junio C Hamano @ 2012-10-19 20:40 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, szager, git, sop
In-Reply-To: <20121019202723.GA24184@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Oct 19, 2012 at 07:10:46AM -0700, Shawn O. Pearce wrote:
>
>> > IOW, it seems like we are _already_ following the advice referenced in
>> > curl's manpage. Is there some case I am missing? Confused...
>>
>> The issue with the current code is sometimes when libcurl is opening a
>> CONNECT style connection through an HTTP proxy it returns a crazy high
>> timeout (>240 seconds) and no fds. In this case Git waits forever.
>> Stefan observed that using a timeout of 50 ms in this situation to
>> poll libcurl is better, as it figures out a lot more quickly that it
>> is connected to the proxy and can issue the request.
>
> Ah. That sounds like a bug in curl to me. But either way, if we want to
> work around it, wouldn't the right thing be to override curl's timeout
> in that instance? Like:
Yeah, that sounds like a more targetted workaround (read: better).
>
> diff --git a/http.c b/http.c
> index df9bb71..cd07cdf 100644
> --- a/http.c
> +++ b/http.c
> @@ -631,6 +631,19 @@ void run_active_slot(struct active_request_slot *slot)
> FD_ZERO(&excfds);
> curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
>
> + /*
> + * Sometimes curl will give a really long timeout for a
> + * CONNECT when there are no fds to read, but we can
> + * get better results by running curl_multi_perform
> + * more frequently.
> + */
> + if (maxfd < 0 &&
> + (select_timeout.tv_sec > 0 ||
> + select_timeout.tv_usec > 50000)) {
> + select_timeout.tv_sec = 0;
> + select_timeout.tv_usec = 50000;
> + }
> +
> select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
> }
> }
>
> -Peff
^ permalink raw reply
* Re: Fix potential hang in https handshake.
From: Jeff King @ 2012-10-19 20:40 UTC (permalink / raw)
To: Stefan Zager; +Cc: Shawn Pearce, Junio C Hamano, git, Shawn Pearce
In-Reply-To: <CAHOQ7J8D-8++vgMh=c0rcTtAKrhWUCQx2nSd_spBzFe=QdXwBw@mail.gmail.com>
On Fri, Oct 19, 2012 at 01:37:06PM -0700, Stefan Zager wrote:
> > diff --git a/http.c b/http.c
> > index df9bb71..cd07cdf 100644
> > --- a/http.c
> > +++ b/http.c
> > @@ -631,6 +631,19 @@ void run_active_slot(struct active_request_slot *slot)
> > FD_ZERO(&excfds);
> > curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
> >
> > + /*
> > + * Sometimes curl will give a really long timeout for a
> > + * CONNECT when there are no fds to read, but we can
> > + * get better results by running curl_multi_perform
> > + * more frequently.
> > + */
> > + if (maxfd < 0 &&
> > + (select_timeout.tv_sec > 0 ||
> > + select_timeout.tv_usec > 50000)) {
> > + select_timeout.tv_sec = 0;
> > + select_timeout.tv_usec = 50000;
> > + }
> > +
> > select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
> > }
> > }
> >
> I have no objection to this; any one else?
If you wouldn't mind, I was hoping you could flesh out the comment a bit
more with real details of when this happens (and/or put them in the
commit message). If this is indeed a bug to be worked around, it will be
a huge help to somebody reading this code in a year who can confirm that
modern curl does not need it anymore.
-Peff
^ permalink raw reply
* Re: Fix potential hang in https handshake.
From: Stefan Zager @ 2012-10-19 20:37 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Junio C Hamano, git, Shawn Pearce
In-Reply-To: <20121019202723.GA24184@sigill.intra.peff.net>
On Fri, Oct 19, 2012 at 1:27 PM, Jeff King <peff@peff.net> wrote:
>
> On Fri, Oct 19, 2012 at 07:10:46AM -0700, Shawn O. Pearce wrote:
>
> > > IOW, it seems like we are _already_ following the advice referenced in
> > > curl's manpage. Is there some case I am missing? Confused...
> >
> > The issue with the current code is sometimes when libcurl is opening a
> > CONNECT style connection through an HTTP proxy it returns a crazy high
> > timeout (>240 seconds) and no fds. In this case Git waits forever.
> > Stefan observed that using a timeout of 50 ms in this situation to
> > poll libcurl is better, as it figures out a lot more quickly that it
> > is connected to the proxy and can issue the request.
>
> Ah. That sounds like a bug in curl to me. But either way, if we want to
> work around it, wouldn't the right thing be to override curl's timeout
> in that instance? Like:
>
> diff --git a/http.c b/http.c
> index df9bb71..cd07cdf 100644
> --- a/http.c
> +++ b/http.c
> @@ -631,6 +631,19 @@ void run_active_slot(struct active_request_slot *slot)
> FD_ZERO(&excfds);
> curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
>
> + /*
> + * Sometimes curl will give a really long timeout for a
> + * CONNECT when there are no fds to read, but we can
> + * get better results by running curl_multi_perform
> + * more frequently.
> + */
> + if (maxfd < 0 &&
> + (select_timeout.tv_sec > 0 ||
> + select_timeout.tv_usec > 50000)) {
> + select_timeout.tv_sec = 0;
> + select_timeout.tv_usec = 50000;
> + }
> +
> select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
> }
> }
>
> -Peff
I have no objection to this; any one else?
Stefan
^ permalink raw reply
* Re: Fix potential hang in https handshake.
From: Jeff King @ 2012-10-19 20:27 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, szager, git, sop
In-Reply-To: <CAJo=hJvWV0WPN5rCYK-JxfaEPWp7syUM1H0w4=Eb27=50+pXjg@mail.gmail.com>
On Fri, Oct 19, 2012 at 07:10:46AM -0700, Shawn O. Pearce wrote:
> > IOW, it seems like we are _already_ following the advice referenced in
> > curl's manpage. Is there some case I am missing? Confused...
>
> The issue with the current code is sometimes when libcurl is opening a
> CONNECT style connection through an HTTP proxy it returns a crazy high
> timeout (>240 seconds) and no fds. In this case Git waits forever.
> Stefan observed that using a timeout of 50 ms in this situation to
> poll libcurl is better, as it figures out a lot more quickly that it
> is connected to the proxy and can issue the request.
Ah. That sounds like a bug in curl to me. But either way, if we want to
work around it, wouldn't the right thing be to override curl's timeout
in that instance? Like:
diff --git a/http.c b/http.c
index df9bb71..cd07cdf 100644
--- a/http.c
+++ b/http.c
@@ -631,6 +631,19 @@ void run_active_slot(struct active_request_slot *slot)
FD_ZERO(&excfds);
curl_multi_fdset(curlm, &readfds, &writefds, &excfds, &max_fd);
+ /*
+ * Sometimes curl will give a really long timeout for a
+ * CONNECT when there are no fds to read, but we can
+ * get better results by running curl_multi_perform
+ * more frequently.
+ */
+ if (maxfd < 0 &&
+ (select_timeout.tv_sec > 0 ||
+ select_timeout.tv_usec > 50000)) {
+ select_timeout.tv_sec = 0;
+ select_timeout.tv_usec = 50000;
+ }
+
select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
}
}
-Peff
^ permalink raw reply related
* Re: libgit2 status
From: Junio C Hamano @ 2012-10-19 20:13 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Thiago Farina, git, dag, Nicolas Sebrecht, Andreas Ericsson,
greened
In-Reply-To: <CALkWK0=P7THaJduYFS1Sr6mxtNqAWQsDgwQyr_KEX4NA4kmVSA@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Thiago Farina wrote:
>> [...]
>> With some structure like:
>>
>> include/git.h
>> src/git.c
>>
>> ...
>>
>> whatever.
>> [...]
>
> Junio- is it reasonable to expect the directory-restructuring by 2.0?
I actually hate "include/git.h vs src/git.c"; you have distinction
between .c and .h already.
^ permalink raw reply
* Re: A design for distributed submodules
From: Jens Lehmann @ 2012-10-19 20:09 UTC (permalink / raw)
To: Lauri Alanko; +Cc: git
In-Reply-To: <20121019033158.93403x1gcanyjo8u.lealanko@webmail.helsinki.fi>
Am 19.10.2012 02:31, schrieb Lauri Alanko:
> I think I finally agree that it's best to develop submodules further
> rather than introduce a new tool for the functionality I require. Here
> are some explicit proposals for submodules so we can at least establish
> agreement on what should be done. These are in order of decreasing
> importance (to me).
Good to hear that!
> * Upstreamless submodules
>
> If there is no 'url' key defined for a submodule in .gitconfig, there is
> no "authoritative upstream" for it. When a recursive
> fetch/pull/clone/push is performed on a remote superproject, its
> upstreamless submodules are also fetched/pulled/cloned/pushed directly
> from/to the submodule repositories under the superproject .git/modules.
> If this is the first time that remote's submodules are accessed, that
> remote is initialized for the local submodules: the submodule of the
> remote superproject becomes a remote of the local submodule, and is
> given the same name as the remote of the superproject.
>
> So, suppose we have a superproject with .gitmodules:
>
> [submodule "sub"]
> path = sub
>
> which is hosted at repositories at URL1 and URL2. Then we do:
>
> git clone --recursive URL1 super
> cd super
> git remote add other URL2
> git fetch --recursive URL2
>
> Now .git/modules/sub/config has:
>
> [remote "origin"]
> url = URL1/.git/modules/sub
> [remote "other"]
> url = URL2/.git/modules/sub
So you want to automatically propagate the new superproject remote
"other" into the submodules?
> So the effect is similar to just setting the submodule's url as
> ".git/modules/sub", except that:
>
> - it hides the implementation detail of the exact location of the
> submodule repository from the publicly visible configuration file
>
> - it also works with bare remotes (where the actual remote submodule
> location would be URL/modules/sub)
>
> - it allows multiple simultaneous superproject remotes (where
> git-submodule currently always resolves relative urls against
> branch.$branch.remote with no option to fetch from a different
> remote).
Maybe it's too late on a Friday evening in my timezone, but currently
I can't wrap my mind around what you have in mind here ... will try
again later.
> * Submodule discovery across all refs
>
> This is what Jens already mentioned. If we fetch multiple refs of a
> remote superproject, we also need to fetch _all_ of the submodules
> referenced by _any_ of the refs, not just the ones in the currently
> active branch.
That is how things already work now (and it is done in an optimized
way because we only do a fetch in a submodule when the referenced
commit isn't already present locally). But the current limitation
is that only populated submodules are updated (we do a "git fetch"
inside the submodules work tree), so e.g. currently we can't follow
renames. We should also do a fetch for submodules which aren't
checked out but whose repo is found in .git/modules/<name>.
> Finding the complete list of submodules probably has to
> be implemented by reading .gitmodules in all of the (updated) refs,
> which is a bit ugly, but not too bad.
Yes, this will be necessary to get the correct path -> name mapping
for submodules which aren't found in the work tree (e.g. because
they are renamed). (I will also need to peek into another commit's
.gitmodules file to make the recursive checkout work for appearing
submodules for the same reason)
> * Recording the active branch of a submodule
>
> When a submodule is added, its active branch should be stored in
> .gitmodules as submodule.$sub.branch. Then, when the submodule is
> checked out, and the head of that branch is the same as the commit in
> the gitlink (i.e. the superproject tree is "current"), then that branch
> is set as the active branch in the checked-out submodule working tree.
> Otherwise, a detached head is used.
We had some discussions about a "floating" submodule model where the
submodules follow the tip of a branch configured in .gitmodules. That
looked similar to what you have in mind, except that the tip of that
branch is always used.
> * Multiple working trees for a submodule
>
> A superproject may have multiple paths for the same submodule,
> presumably for different commits. This is for cases where the
> superproject is a snapshot of a developer's directory hierarchy, and the
> developer is simultaneously working on multiple branches of a submodule
> and it is convenient to have separate working trees for each of them.
>
> This is a bit hard to express with the current .gitconfig format, since
> paths are attributes of repository ids instead of vice versa. I'd
> introduce an alternative section format where you can say:
>
> [mount "path1"]
> module = sub
> branch = master
>
> [mount "path2"]
> module = sub
> branch = topic
>
> Implementing this is a bit intricate, since we need to use the
> git-new-workdir method to create multiple working directories that share
> the same refs, config, and object store, but have separate HEAD and
> index. I think this is a problem with the repository layout: the
> non-workdir-specific bits should all be in a single directory so that a
> single symlink would be enough.
I'm not sure how good that'll work. E.g. what happens if the user
configures the URL of "path1" to something else? It looks to me like
having the same repo copied under different .git/modules/<name> would
be a more robust approach, even though it wastes some disk space.
> Obviously, I'm willing to implement the above functionalities since I
> need them. However, I think I'm going to work in Dulwich (which doesn't
> currently have any submodule support): a Python API is currently more
> important to me than a command-line tool, and the git.git codebase
> doesn't look like a very attractive place to contribute anyway. No
> offense, it's just not to my tastes.
>
> So the main reason I'd like to reach some tentative agreement about the
> details of the proposal is to ensure that _once_ someone finally
> implements this kind of functionality in git.git, it will use the same
> configuration format and same conventions, so that it will be compatible
> with my code. The compatibility between different tools is after all the
> main reason for doing this stuff as an extension to submodules instead
> of something completely different.
Fair enough. But I fear unless we code the same functionality in both
worlds at about the same time the assumption that it will be done in
the future in the git core in the same way you expect may fail.
Having said that: I expect to implement peeking into another commit's
.gitmodules to read the config next after I finished the rm and mv for
submodules (and intend to use it for doing a fetch first), so maybe we
can start with that?
^ permalink raw reply
* Re: [PATCH 6/6] format-patch --notes: show notes after three-dashes
From: Junio C Hamano @ 2012-10-19 20:06 UTC (permalink / raw)
To: Philip Oakley; +Cc: git
In-Reply-To: <7vlif3l9fw.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> As long as what it does is explained in format-patch, that is fine.
>
> I do not think this deserves to be in the SubmittingPatches. We do
> tell people to hide "here is the context of the change" additional
> explanation after three dashes, but how the submitters prepare that
> text is entirely up to them (and I personally do not think notes is
> not necessarily the right tool to do so).
Just in case, here is what I'll queue as a placeholder on 'pu'.
-- >8 --
Subject: [PATCH] Documentation: decribe format-patch --notes
Even though I coded this, I am not sure what use scenarios would benefit
from this option, so the description is unnecessarily negative at this
moment. People who do want to use this feature need to come up with a
more plausible use case and replace it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-format-patch.txt | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 6d43f56..066dc8b 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -20,7 +20,7 @@ SYNOPSIS
[--ignore-if-in-upstream]
[--subject-prefix=Subject-Prefix]
[--to=<email>] [--cc=<email>]
- [--cover-letter] [--quiet]
+ [--cover-letter] [--quiet] [--notes[=<ref>]]
[<common diff options>]
[ <since> | <revision range> ]
@@ -191,6 +191,19 @@ will want to ensure that threading is disabled for `git send-email`.
containing the shortlog and the overall diffstat. You can
fill in a description in the file before sending it out.
+--notes[=<ref>]::
+ Append the notes (see linkgit:git-notes[1]) for the commit
+ after the three-dash line.
++
+The expected use case of this is to write supporting explanation for
+the commit that does not belong to the commit log message proper
+when (or after) you create the commit, and include it in your patch
+submission. But if you can plan ahead and write it down, there may
+not be a good reason not to write it in your commit message, and if
+you can't, you can always edit the output of format-patch before
+sending it out, so the practical value of this option is somewhat
+dubious, unless your workflow is broken.
+
--[no]-signature=<signature>::
Add a signature to each message produced. Per RFC 3676 the signature
is separated from the body by a line with '-- ' on it. If the
--
1.8.0.rc3.162.g1f53438
^ permalink raw reply related
* Re: [PATCH] Cache stat_tracking_info() for faster status and branch -v
From: Junio C Hamano @ 2012-10-19 19:50 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1350408967-13919-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> stat_tracking_info() is used to calculated how many commits ahead or
> behind for a branch. Rev walking can be slow especially when the
> branch is way behind its remote end. By caching the results, we won't
> have to rev walk every time we need these information.
> stat_tracking_info() cost can be greatly reduced this way.
>
> This makes sure "git status" instant no matter how far behind HEAD
> is, except the first time after HEAD changes. This also makes
> "branch -v" usable (for me) as it's now also instant versus 3.5
> seconds in non-cache case on my machine.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> I wanted guaranteed-fast status for another reason, but it turns out
> "branch -v" benefits even more. Recent commit walking is not
> efficiently optimized even with Shawn's pack bitmaps. This may be
> useful some people, I guess.
Not particularly interested in the cause, but not so strongly
against it to veto it.
The design looks questionable.
You can fork one or more branches off of a single branch. You may
fork your 'frotz' branch off of remotes/origin/master but also
another 'xyzzy' branch may be forked from the same.
I understand that you are trying to optimize, given two commit
object names X and Y, the cost to learn the symmetric distances
between them.
Doesn't it make more sense to use a notes-cache that is keyed off of
the commit object name X of the remote? You will have a single note
that stores a blob for the commit object remotes/origin/master, and
the blob tells you how far the commit at the tip of 'frotz' is from
it, and the same for 'xyzzy'.
You would obviouly need to run "gc" on such a notes-cache tree from
time to time, removing notes for commits that are not tip of any
branch that could be a fork point, and from the remaining notes
blobs, entries that describe commits that are not tip of any branch,
if you go that route.
>
> remote.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/remote.c b/remote.c
> index 04fd9ea..db825b8 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1549,6 +1549,7 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
> struct rev_info revs;
> const char *rev_argv[10], *base;
> int rev_argc;
> + int fd;
>
> /*
> * Nothing to report unless we are marked to build on top of
> @@ -1579,6 +1580,33 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
> if (theirs == ours)
> return 0;
>
> + if (!access(git_path("stat_tracking_cache/%s",
> + branch->refname), R_OK)) {
> + struct strbuf sb = STRBUF_INIT;
> + unsigned char sha1_ours[20], sha1_theirs[20];
> + int n1, n2;
> + if ((fd = open(git_path("stat_tracking_cache/%s",
> + branch->refname),
> + O_RDONLY)) != -1 &&
> + strbuf_read(&sb, fd, 0) != -1 &&
> + sb.len > (40 + 1) * 2 &&
> + !get_sha1_hex(sb.buf, sha1_ours) &&
> + sb.buf[40] == '\n' &&
> + !get_sha1_hex(sb.buf + 41, sha1_theirs) &&
> + sb.buf[81] == '\n' &&
> + !hashcmp(sha1_ours, ours->object.sha1) &&
> + !hashcmp(sha1_theirs, theirs->object.sha1) &&
> + sscanf(sb.buf + 82, "%d\n%d\n", &n1, &n2) == 2) {
> + *num_ours = n1;
> + *num_theirs = n2;
> + close(fd);
> + strbuf_release(&sb);
> + return 1;
> + }
> + close(fd);
> + strbuf_release(&sb);
> + }
> +
> /* Run "rev-list --left-right ours...theirs" internally... */
> rev_argc = 0;
> rev_argv[rev_argc++] = NULL;
> @@ -1608,6 +1636,20 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
> (*num_theirs)++;
> }
>
> + if (!safe_create_leading_directories(git_path("stat_tracking_cache/%s",
> + branch->refname)) &&
> + (fd = open(git_path("stat_tracking_cache/%s",
> + branch->refname),
> + O_CREAT | O_TRUNC | O_RDWR, 0644)) != -1) {
> + struct strbuf sb = STRBUF_INIT;
> + strbuf_addf(&sb, "%s\n", sha1_to_hex(ours->object.sha1));
> + strbuf_addf(&sb, "%s\n", sha1_to_hex(theirs->object.sha1));
> + strbuf_addf(&sb, "%d\n%d\n", *num_ours, *num_theirs);
> + write(fd, sb.buf, sb.len);
> + strbuf_release(&sb);
> + close(fd);
> + }
> +
> /* clear object flags smudged by the above traversal */
> clear_commit_marks(ours, ALL_REV_FLAGS);
> clear_commit_marks(theirs, ALL_REV_FLAGS);
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox