* Re: [PATCH 3/6] Fix grammar
From: Junio C Hamano @ 2012-11-27 20:39 UTC (permalink / raw)
To: Max Horn; +Cc: git
In-Reply-To: <1354038279-76475-4-git-send-email-max@quendi.de>
Max Horn <max@quendi.de> writes:
> Subject: Re: [PATCH 3/6] Fix grammar
Please run "git shortlog -200 --no-merges" from the tip of your
topic branch before sending a series out, and see if you can
immediately identify what area each of your patches affects.
> Signed-off-by: Max Horn <max@quendi.de>
> ---
> Documentation/git-remote-helpers.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> index db63541..7eb43d7 100644
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/git-remote-helpers.txt
> @@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard input, one per line.
> 'capabilities'::
> Lists the capabilities of the helper, one per line, ending
> with a blank line. Each capability may be preceded with '*',
> - which marks them mandatory for git version using the remote
> - helper to understand (unknown mandatory capability is fatal
> - error).
> + which marks them mandatory for git versions using the remote
> + helper to understand. Any unknown mandatory capability is a
> + fatal error.
>
> 'list'::
> Lists the refs, one per line, in the format "<value> <name>
^ permalink raw reply
* Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-27 20:48 UTC (permalink / raw)
To: git
Because I do a lot of work on repository conversion tools, I've had
to learn a lot of detail about ontological mismatches between
version-control systems - especially places where you lose metadata
moving between them.
In general, git metadata can carry forward almost all the metadata in
a Subversion repository. Among the handful of minor exceptions (empty
directories, flow structure, certain kinds of mergeinfos) there is one
that stands out because it seems to be an implementation detail rather
than a consequence of fundamentally different design decisions.
I refer to the one-second precision of git timestamps. Subversion
stores its commit and property-change timestamps to microsecond
precision; conversion tools have to throw the subsecond part of
this information away.
Has going to timestamps with the full precision of the system clock
been considered and rejected, or am I the first to bring this up?
If I were to write refactoring patches that treated "timestamp" as
an ADT, with a view towards hiding the difference between int and
float timestamps and eventually experimenting with float ones,
would they be accepted?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Every Communist must grasp the truth, 'Political power grows out of
the barrel of a gun.'
-- Mao Tse-tung, 1938, inadvertently endorsing the Second Amendment.
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Sitaram Chamarty @ 2012-11-27 21:08 UTC (permalink / raw)
To: esr; +Cc: Magnus Bäck, Felipe Contreras, Michael Haggerty, git
In-Reply-To: <20121127183530.GB11845@thyrsus.com>
On Wed, Nov 28, 2012 at 12:05 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Magnus Bäck <baeck@google.com>:
>> While "constant traffic" probably overstates the issue, these are not
>> theoretical problems. I recall at least three cases in the last year
>> or so where Git has seen breakage with Solaris or Mac OS X because
>> of sed or tr incompatibilities, and I don't even read this list that
>> thoroughly.
>
> This is exactly the sort of of pain experience would lead me to
> expect.
>
> OK, this is where I assume the full Old Fart position (30-year
> old-school Unix guy, author of "The Art of Unix Programming", can
> remember the years before Perl and still has sh idioms in his
> fingertips) and say "Get with the 21st century, people! Or at least
> 1990..."
>
> As a general scripting language shell sucks *really badly* compared to
> anything new-school. Performance, portability, you name it, it's a
> mess. It's not so much the shell interpreters itself that are the
> portabilty problem, but (as Magnus implicitly points out) all those
> userland dependencies on sed and tr and awk and even variants of
> expr(!) that get dragged in the second you try to get any actual work
> done.
Not always. There are several situations where a shell script that
makes good use of grep, cut, etc., is definitely much cleaner and more
elegant than anything you can do in a "propah" programming language.
If the price of doing that is sticking to a base set of primitives,
it's a small price to pay, not much different from sticking to python
2.7 or perl 5.8 or whatever.
Shell *is* the universal scripting language, not perl (even though we
all know it is what God himself used to create the world -- see xkcd
224 if you don't believe me!), not python, not Ruby.
--
sitaram
^ permalink raw reply
* Re: difftool -d symlinks, under what conditions
From: Matt McClure @ 2012-11-27 21:10 UTC (permalink / raw)
To: David Aguilar; +Cc: git@vger.kernel.org, Tim Henigan
In-Reply-To: <CAJDDKr4mTc8-FX7--pd7j0vUbdk_1+KU0YniKEhRdee6SaS-8Q@mail.gmail.com>
On Tuesday, November 27, 2012, David Aguilar wrote:
> It seems that there is an edge case here that we are not
> accounting for: unmodified worktree paths, when checked out
> into the temporary directory, can be edited by the tool when
> comparing against older commits. These edits will be lost.
Yes. That is exactly my desired use case. I want to make edits while
I'm reviewing the diff.
>
> When we can do that then we avoid needing to have a temporary
> directory altogether for any dir-diffs that involve the worktree.
I think the temporary directory is still a good thing. Without it, the
directory diff tool would have no way to distinguish a file added in
the diff from a file that was preexisting and unmodified.
--
Matt McClure
http://www.matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
^ permalink raw reply
* Re: [PATCH v4 4/4] Hack fix for 'submodule update does not fetch already present commits'
From: W. Trevor King @ 2012-11-27 21:18 UTC (permalink / raw)
To: Heiko Voigt, Git
Cc: Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce, Jens Lehmann,
Nahor
In-Reply-To: <20121127190105.GQ10656@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]
On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:
> On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> > On Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote:
> > > Because you need to recurse through submodules for `update --branch`
> > > even if "$subsha1" == "$sha1", I had to amend the conditional
> > > controlling that block. This broke one of the existing tests, which I
> > > "fixed" in patch 4. I think a proper fix would involve rewriting
> > >
> > > (clear_local_git_env; cd "$sm_path" &&
> > > ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> > > test -z "$rev") || git-fetch)) ||
> > > die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
> > >
> > > but I'm not familiar enough with rev-list to want to dig into that
> > > yet. If feedback for the earlier three patches is positive, I'll work
> > > up a clean fix and resubmit.
> >
> > You probably need to separate your handling here. The comparison of the
> > currently checked out sha1 and the recorded sha1 is an optimization
> > which skips unnecessary fetching in case the submodules commits are
> > already correct. This code snippet checks whether the to be checked out
> > sha1 is already local and also skips the fetch if it is. We should not
> > break that.
>
> Agreed. However, determining if the target $sha1 is local should have
> nothing to do with the current checked out $subsha1.
Erm, I clearly wasn't getting enough sleep heading into yesterday,
because when I drop the hack patch #4, reinstall, and retest, I no
longer get the bad-fetch error. I'm not quite sure what was going on,
but please pretend I never mentioned it ;).
--
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 0/5] "diff --stat" counting fixes
From: Junio C Hamano @ 2012-11-27 21:21 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
It turns out that there are at least two bugs in the diffstat
counting code. This series comes on top of the earlier 74faaa1 (Fix
"git diff --stat" for interesting - but empty - file changes,
2012-10-17) to fix them.
Junio C Hamano (5):
test: add failing tests for "diff --stat" to t4049
diff --stat: status of unmodified pair in diff-q is not zero
diff --stat: use "file" temporary variable to refer to data->files[i]
diff --stat: move the "total count" logic to the last loop
diff --stat: do not count "unmerged" entries
diff.c | 49 +++++++++++++++++++++++++---------------------
t/t4049-diff-stat-count.sh | 46 ++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 72 insertions(+), 23 deletions(-)
--
1.8.0.1.331.g808d2af
^ permalink raw reply
* [PATCH 1/5] test: add failing tests for "diff --stat" to t4049
From: Junio C Hamano @ 2012-11-27 21:21 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1354051310-29093-1-git-send-email-gitster@pobox.com>
There are a few problems in diff.c around --stat area, partially
caused by the recent 74faaa1 (Fix "git diff --stat" for interesting
- but empty - file changes, 2012-10-17), and largely caused by the
earlier change that introduced when --stat-count was added.
Add a few test pieces to t4049 to expose the issues.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t4049-diff-stat-count.sh | 46 +++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh
index 7b3ef00..e212b11 100755
--- a/t/t4049-diff-stat-count.sh
+++ b/t/t4049-diff-stat-count.sh
@@ -4,12 +4,17 @@
test_description='diff --stat-count'
. ./test-lib.sh
-test_expect_success setup '
+test_expect_success 'setup' '
>a &&
>b &&
>c &&
>d &&
git add a b c d &&
+ git commit -m initial
+'
+
+test_expect_success 'limit output to 2 (simple)' '
+ git reset --hard &&
chmod +x c d &&
echo a >a &&
echo b >b &&
@@ -23,4 +28,43 @@ test_expect_success setup '
test_i18ncmp expect actual
'
+test_expect_failure 'binary changes do not count in lines' '
+ git reset --hard &&
+ chmod +x c d &&
+ echo a >a &&
+ echo b >b &&
+ cat "$TEST_DIRECTORY"/test-binary-1.png >d &&
+ cat >expect <<-\EOF
+ a | 1 +
+ b | 1 +
+ ...
+ 4 files changed, 2 insertions(+)
+ EOF
+ git diff --stat --stat-count=2 >actual &&
+ test_i18ncmp expect actual
+'
+
+test_expect_failure 'exclude unmerged entries from total file count' '
+ git reset --hard &&
+ echo a >a &&
+ echo b >b &&
+ git ls-files -s a >x &&
+ git rm -f d &&
+ for stage in 1 2 3
+ do
+ sed -e "s/ 0 a/ $stage d/" x
+ done |
+ git update-index --index-info &&
+ echo d >d &&
+ chmod +x c d &&
+ cat >expect <<-\EOF
+ a | 1 +
+ b | 1 +
+ ...
+ 4 files changed, 3 insertions(+)
+ EOF
+ git diff --stat --stat-count=2 >actual &&
+ test_i18ncmp expect actual
+'
+
test_done
--
1.8.0.1.331.g808d2af
^ permalink raw reply related
* [PATCH 2/5] diff --stat: status of unmodified pair in diff-q is not zero
From: Junio C Hamano @ 2012-11-27 21:21 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1354051310-29093-1-git-send-email-gitster@pobox.com>
It is spelled DIFF_STATUS_UNKNOWN these days, and is different from zero.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/diff.c b/diff.c
index 95bbad6..ce6baa4 100644
--- a/diff.c
+++ b/diff.c
@@ -2411,7 +2411,7 @@ static void builtin_diffstat(const char *name_a, const char *name_b,
}
data = diffstat_add(diffstat, name_a, name_b);
- data->is_interesting = p->status != 0;
+ data->is_interesting = p->status != DIFF_STATUS_UNKNOWN;
if (!one || !two) {
data->is_unmerged = 1;
--
1.8.0.1.331.g808d2af
^ permalink raw reply related
* [PATCH 5/5] diff --stat: do not count "unmerged" entries
From: Junio C Hamano @ 2012-11-27 21:21 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1354051310-29093-1-git-send-email-gitster@pobox.com>
Even though we show a separate *UNMERGED* entry in the patch and
diffstat output (or in the --raw format, for that matter) in
addition to and separately from the diff against the specified stage
(defaulting to #2) for unmerged paths, they should not be counted in
the total number of files affected---that would lead to counting the
same path twice.
The separation done by the previous step makes this fix simple and
straightforward. Among the filepairs in diff_queue, paths that
weren't modified, and the extra "unmerged" entries do not count as
total number of files.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 6 ++++--
t/t4049-diff-stat-count.sh | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 4105260..26ede82 100644
--- a/diff.c
+++ b/diff.c
@@ -1669,12 +1669,14 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
struct diffstat_file *file = data->files[i];
uintmax_t added = file->added;
uintmax_t deleted = file->deleted;
- if (!file->is_interesting && (added + deleted == 0)) {
+
+ if (file->is_unmerged ||
+ (!file->is_interesting && (added + deleted == 0))) {
total_files--;
continue;
}
- if (!file->is_binary && !file->is_unmerged) {
+ if (!file->is_binary) {
adds += added;
dels += deleted;
}
diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh
index 70ee073..37f50cd 100755
--- a/t/t4049-diff-stat-count.sh
+++ b/t/t4049-diff-stat-count.sh
@@ -44,7 +44,7 @@ test_expect_success 'binary changes do not count in lines' '
test_i18ncmp expect actual
'
-test_expect_failure 'exclude unmerged entries from total file count' '
+test_expect_success 'exclude unmerged entries from total file count' '
git reset --hard &&
echo a >a &&
echo b >b &&
--
1.8.0.1.331.g808d2af
^ permalink raw reply related
* [PATCH 3/5] diff --stat: use "file" temporary variable to refer to data->files[i]
From: Junio C Hamano @ 2012-11-27 21:21 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1354051310-29093-1-git-send-email-gitster@pobox.com>
The generated code shouldn't change but it is easier to read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/diff.c b/diff.c
index ce6baa4..e4e70e5 100644
--- a/diff.c
+++ b/diff.c
@@ -1470,8 +1470,8 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
for (i = 0; (i < count) && (i < data->nr); i++) {
struct diffstat_file *file = data->files[i];
uintmax_t change = file->added + file->deleted;
- if (!data->files[i]->is_interesting &&
- (change == 0)) {
+
+ if (!file->is_interesting && (change == 0)) {
count++; /* not shown == room for one more */
continue;
}
@@ -1586,13 +1586,13 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
*/
for (i = 0; i < count; i++) {
const char *prefix = "";
- char *name = data->files[i]->print_name;
- uintmax_t added = data->files[i]->added;
- uintmax_t deleted = data->files[i]->deleted;
+ struct diffstat_file *file = data->files[i];
+ char *name = file->print_name;
+ uintmax_t added = file->added;
+ uintmax_t deleted = file->deleted;
int name_len;
- if (!data->files[i]->is_interesting &&
- (added + deleted == 0)) {
+ if (!file->is_interesting && (added + deleted == 0)) {
total_files--;
continue;
}
@@ -1611,7 +1611,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
name = slash;
}
- if (data->files[i]->is_binary) {
+ if (file->is_binary) {
fprintf(options->file, "%s", line_prefix);
show_name(options->file, prefix, name, len);
fprintf(options->file, " %*s", number_width, "Bin");
@@ -1628,7 +1628,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
fprintf(options->file, "\n");
continue;
}
- else if (data->files[i]->is_unmerged) {
+ else if (file->is_unmerged) {
fprintf(options->file, "%s", line_prefix);
show_name(options->file, prefix, name, len);
fprintf(options->file, " Unmerged\n");
@@ -1668,10 +1668,10 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
fprintf(options->file, "\n");
}
for (i = count; i < data->nr; i++) {
- uintmax_t added = data->files[i]->added;
- uintmax_t deleted = data->files[i]->deleted;
- if (!data->files[i]->is_interesting &&
- (added + deleted == 0)) {
+ struct diffstat_file *file = data->files[i];
+ uintmax_t added = file->added;
+ uintmax_t deleted = file->deleted;
+ if (!file->is_interesting && (added + deleted == 0)) {
total_files--;
continue;
}
--
1.8.0.1.331.g808d2af
^ permalink raw reply related
* [PATCH 4/5] diff --stat: move the "total count" logic to the last loop
From: Junio C Hamano @ 2012-11-27 21:21 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1354051310-29093-1-git-send-email-gitster@pobox.com>
The diffstat generation logic, with --stat-count limit, is
implemented as three loops.
- The first counts the width necessary to show stats up to
specified number of entries, and notes up to how many entries in
the data we need to iterate to show the graph;
- The second iterates that many times to draw the graph, adjusts
the number of "total modified files", and counts the total
added/deleted lines for the part that was shown in the graph;
- The third iterates over the remainder and only does the part to
count "total added/deleted lines" and to adjust "total modified
files" without drawing anything.
Move the logic to count added/deleted lines and modified files from
the second loop to the third loop.
This incidentally fixes a bug. The third loop was not filtering
binary changes (counted in bytes) from the total added/deleted as it
should. The second loop implemented this correctly, so if a binary
change appeared earlier than the --stat-count cutoff, the code
counted number of added/deleted lines correctly, but if it appeared
beyond the cutoff, the number of lines would have mixed with the
byte count in the buggy third loop.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 21 ++++++++++++---------
t/t4049-diff-stat-count.sh | 2 +-
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/diff.c b/diff.c
index e4e70e5..4105260 100644
--- a/diff.c
+++ b/diff.c
@@ -1498,7 +1498,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
if (max_change < change)
max_change = change;
}
- count = i; /* min(count, data->nr) */
+ count = i; /* where we can stop scanning in data->files[] */
/*
* We have width = stat_width or term_columns() columns total.
@@ -1592,10 +1592,9 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
uintmax_t deleted = file->deleted;
int name_len;
- if (!file->is_interesting && (added + deleted == 0)) {
- total_files--;
+ if (!file->is_interesting && (added + deleted == 0))
continue;
- }
+
/*
* "scale" the filename
*/
@@ -1640,8 +1639,6 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
*/
add = added;
del = deleted;
- adds += add;
- dels += del;
if (graph_width <= max_change) {
int total = add + del;
@@ -1667,7 +1664,8 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
show_graph(options->file, '-', del, del_c, reset);
fprintf(options->file, "\n");
}
- for (i = count; i < data->nr; i++) {
+
+ for (i = 0; i < data->nr; i++) {
struct diffstat_file *file = data->files[i];
uintmax_t added = file->added;
uintmax_t deleted = file->deleted;
@@ -1675,8 +1673,13 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
total_files--;
continue;
}
- adds += added;
- dels += deleted;
+
+ if (!file->is_binary && !file->is_unmerged) {
+ adds += added;
+ dels += deleted;
+ }
+ if (i < count)
+ continue;
if (!extra_shown)
fprintf(options->file, "%s ...\n", line_prefix);
extra_shown = 1;
diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh
index e212b11..70ee073 100755
--- a/t/t4049-diff-stat-count.sh
+++ b/t/t4049-diff-stat-count.sh
@@ -28,7 +28,7 @@ test_expect_success 'limit output to 2 (simple)' '
test_i18ncmp expect actual
'
-test_expect_failure 'binary changes do not count in lines' '
+test_expect_success 'binary changes do not count in lines' '
git reset --hard &&
chmod +x c d &&
echo a >a &&
--
1.8.0.1.331.g808d2af
^ permalink raw reply related
* Re: [PATCH 3/6] Fix grammar
From: Max Horn @ 2012-11-27 21:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8v9mn5k6.fsf@alter.siamese.dyndns.org>
On 27.11.2012, at 21:39, Junio C Hamano wrote:
> Max Horn <max@quendi.de> writes:
>
>> Subject: Re: [PATCH 3/6] Fix grammar
>
> Please run "git shortlog -200 --no-merges" from the tip of your
> topic branch before sending a series out, and see if you can
> immediately identify what area each of your patches affects.
First off: I apologize for the inconvenience my stumbling causes :-(, and I'll try to learn and do better next time I send this or another series.
In this particular case, I am not 100% sure if I understood you correctly, i.e. what exactly you are trying to tell me. Is it (in a nutshell) that the subject lines of my commits suck, as they don't identify which area of code they touch? At least that's the thing I notice when looking at that shortlog... Bad, of course...
If this is indeed it, would a commit message like
git-remote-helper.txt: minor grammar fix
be OK? If this is indeed it, I'll be happy to reroll and resubmit the series accordingly. If I am mistaken and something else / more is wrong, please be so kind and let me know, too.
Sorry once more and thank you very much for your feedback,
Max
>
>> Signed-off-by: Max Horn <max@quendi.de>
>> ---
>> Documentation/git-remote-helpers.txt | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
>> index db63541..7eb43d7 100644
>> --- a/Documentation/git-remote-helpers.txt
>> +++ b/Documentation/git-remote-helpers.txt
>> @@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard input, one per line.
>> 'capabilities'::
>> Lists the capabilities of the helper, one per line, ending
>> with a blank line. Each capability may be preceded with '*',
>> - which marks them mandatory for git version using the remote
>> - helper to understand (unknown mandatory capability is fatal
>> - error).
>> + which marks them mandatory for git versions using the remote
>> + helper to understand. Any unknown mandatory capability is a
>> + fatal error.
>>
>> 'list'::
>> Lists the refs, one per line, in the format "<value> <name>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Shawn Pearce @ 2012-11-27 21:41 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121127204828.577264065F@snark.thyrsus.com>
On Tue, Nov 27, 2012 at 12:48 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Because I do a lot of work on repository conversion tools, I've had
> to learn a lot of detail about ontological mismatches between
> version-control systems - especially places where you lose metadata
> moving between them.
>
> In general, git metadata can carry forward almost all the metadata in
> a Subversion repository. Among the handful of minor exceptions (empty
> directories, flow structure, certain kinds of mergeinfos) there is one
> that stands out because it seems to be an implementation detail rather
> than a consequence of fundamentally different design decisions.
>
> I refer to the one-second precision of git timestamps. Subversion
> stores its commit and property-change timestamps to microsecond
> precision; conversion tools have to throw the subsecond part of
> this information away.
>
> Has going to timestamps with the full precision of the system clock
> been considered and rejected, or am I the first to bring this up?
>
> If I were to write refactoring patches that treated "timestamp" as
> an ADT, with a view towards hiding the difference between int and
> float timestamps and eventually experimenting with float ones,
> would they be accepted?
JGit would fortunately ignore a floating point timestamp specification
if given in a commit, but I don't know about other Git
implementations... like say git. :-)
^ permalink raw reply
* RE: Millisecond precision in timestamps?
From: Pyeron, Jason J CTR (US) @ 2012-11-27 21:44 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <20121127204828.577264065F@snark.thyrsus.com>
[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]
> -----Original Message-----
> From: Eric S. Raymond
> Sent: Tuesday, November 27, 2012 3:48 PM
>
> Because I do a lot of work on repository conversion tools, I've had
> to learn a lot of detail about ontological mismatches between
> version-control systems - especially places where you lose metadata
> moving between them.
>
> In general, git metadata can carry forward almost all the metadata in
> a Subversion repository. Among the handful of minor exceptions (empty
> directories, flow structure, certain kinds of mergeinfos) there is one
> that stands out because it seems to be an implementation detail rather
> than a consequence of fundamentally different design decisions.
>
> I refer to the one-second precision of git timestamps. Subversion
> stores its commit and property-change timestamps to microsecond
> precision; conversion tools have to throw the subsecond part of
> this information away.
>
> Has going to timestamps with the full precision of the system clock
> been considered and rejected, or am I the first to bring this up?
>
> If I were to write refactoring patches that treated "timestamp" as
> an ADT, with a view towards hiding the difference between int and
> float timestamps and eventually experimenting with float ones,
Do you really mean floating point numbers with approximate imprecise values?
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Guillaume DE BURE @ 2012-11-27 22:01 UTC (permalink / raw)
To: David Aguilar
Cc: Sitaram Chamarty, Felipe Contreras, esr, Nguyen Thai Ngoc Duy,
git, msysGit
In-Reply-To: <CAJDDKr7r5iP_LpXAT9Xz35GOfbDuDxSAKUvx=4dxa2LE_GLgrA@mail.gmail.com>
Le mardi 27 novembre 2012 02:51:04 David Aguilar a écrit :
> On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty <sitaramc@gmail.com>
wrote:
> > On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar <davvid@gmail.com> wrote:
> >> *cough* git-cola *cough*
> >>
> >> it runs everywhere. Yes, windows too. It's written in python.
> >> It's been actively maintained since 2007.
> >>
> >> It's "modern" and has features that don't exist anywhere else.
> >>
> >> It even has tests. It even comes with a building full of willing
> >> guinea-pigs^Wtesters that let me know right away when
> >> anything goes wrong.
> >>
> >> It uses Qt but that's really the whole point of Qt -> cross-platform.
> >> (not sure how that wiki page ended up saying Gnome/GTK?)
> >>
> >> The DAG aka git-dag (in its master branch, about to be released)
> >> is nicer looking then gitk IMO. gitk still has some features
> >> that are better too--there's no silver bullet, but the delta
> >> is pretty small.
> >
> > Gitk does a lot of things that people don't realise, since they're not
> > really documented and you have to scrounge around on the UI. The
> > thing is, it's just about the most awesome tool for code archeology I
> > have seen.
> >
> > I realise (from looking at the doc page) that git-cola helps you do
> > all sorts of things, but those are all things I am happier doing at
> > the command line.
>
> Ditto. There's actually a few small things I use it for,
> mainly for teasing apart commits. These days you can use git-gui
> for that, but in the old days it was the only way to interactively
> select individual lines and stage/unstage/revert them, etc.
> I don't think we can line-by-line revert in git-gui yet, though.
>
> Some other small things that I use: ctrl-g, type something
> for grep, hit enter twice and I'm in my editor on that
> (or any other selected) line. 'spacebar' does xdg-open,
> and 'enter' launches the editor in the status widget;
> small things. I, too, do most stuff on the command line.
>
> The grep thing is a good example. You have tons of output,
> you see the one line that you care about, and you want to jump
> there. Clicking on that line and hitting enter is the minimal
> effort to do that. You don't have to click because we also
> have keyboard navigation. I have a feeling that there's probably
> something I'm missing, though.. another way of working (emacs?)
> that would render all of this custom GUI stuff pointless.
>
> What I learned about users:
>
> The commit editor is the #1 thing that got my coworkers finally
> writing better commit messages. It forces the subject/description
> separation and shows yellow, red when the subject gets too long.
> It also auto-wraps. IMO it makes sense for git-gui to do
> the same these days.
>
> > Gitk does precisely those things which *require* a GUI, where the
> > amount of information presented overwhelms a text interface. The
> > display is concisely designed to give you the maximum information at a
> > minimum space use. For example, a little black square when a commit
> > has a note attached. Even hovering over the arrow-heads, on complex
> > trees where the line gets broken, does something meaningful.
> >
> > if I had to pin it down, the feature I use most often is "Show origin
> > of this line". Other features I use often are
> >
> > - review a commit file by file (f and b keys, also spacebar and 'd')
> > - search by SHA1 (4 digits appear to be enough, regardless of how
> >
> > big your repo is),
> >
> > - search for commits changing path/dir (while still showing all the
> >
> > commits; i.e., this is not 'git-dag -- README.txt' but within gitk you
> > search up and down for commits touching README.txt
> >
> > - and navigating the commit tree looking for stuff
> >
> > http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to
> > document some of the stuff I have found and use.
>
> Wow, this is awesome.
>
> > One final point: the DAG on the right wastes enormous amounts of
> > space. Purely subjectively, it is almost jarring on the senses. (If
> > you reduce it, it becomes unreadable).
> >
> > With all due respect, git-cola/dag isn't anywhere near what gitk does,
> > at least for people who are not afraid of the command line and only
> > need the GUI to visualise a truly complex tree.
>
> This is really great feedback.
> cc:ing Guillaume since he had similar ideas.
>
> thx,
Thanks David for cc:ing me. I'm sorry I was quite below the radar lately, had
too much work to get back on the dag. What I would really like for the dag is
to become as useful as the treeview in git extensions
(http://code.google.com/p/gitextensions/), where it is the central place for
checkout, merge, cherry picks...
My only complaint with git extensions is that it is poorly integrated on my
linux desktop, due to framework choice (let's not start a flame war here, it's
not the point). On the other hand, git-cola is quite easy to hack on thanks to
its python roots, well integrated on all OS thanks to Qt, so I thought it
would be great to make it at least on par.
Had an opportunity to rework the visuals on the dag, but not yet its
functionalities... As soon as I'm back on normal life, I'll pickup the subject
again :)
Cheers,
Guillaume
--
Skrooge, a free, Open Source, personal finances software for linux, Mac OS,
Windows
http://skrooge.org
^ permalink raw reply
* Re: [PATCH 3/6] Fix grammar
From: Junio C Hamano @ 2012-11-27 22:02 UTC (permalink / raw)
To: Max Horn; +Cc: git
In-Reply-To: <5F2BC41E-6F77-44B8-B05E-8FB07E82EFA3@quendi.de>
Max Horn <max@quendi.de> writes:
> If this is indeed it, would a commit message like
>
> git-remote-helper.txt: minor grammar fix
Perfect. Thanks.
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Junio C Hamano @ 2012-11-27 22:06 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Eric S. Raymond, git
In-Reply-To: <CAJo=hJtZ+n+D4pOmeNApDeLNyZYeqnEDDYJWwSj_wLauQ+w4hQ@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> JGit would fortunately ignore a floating point timestamp specification
> if given in a commit, but I don't know about other Git
> implementations... like say git. :-)
fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
the author and committer ident (i.e. the timestamp has to be
integral number of seconds since the epoch, not before it, nor
with fractional seconds).
^ permalink raw reply
* [PATCH 6/5] diff --shortstat: do not count "unmerged" entries
From: Junio C Hamano @ 2012-11-27 22:21 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1354051310-29093-1-git-send-email-gitster@pobox.com>
Fix the same issue as the previous one for "git diff --stat";
unmerged entries was doubly-counted.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 26ede82..374b235 100644
--- a/diff.c
+++ b/diff.c
@@ -1701,9 +1701,8 @@ static void show_shortstats(struct diffstat_t *data, struct diff_options *option
int added = data->files[i]->added;
int deleted= data->files[i]->deleted;
- if (data->files[i]->is_unmerged)
- continue;
- if (!data->files[i]->is_interesting && (added + deleted == 0)) {
+ if (data->files[i]->is_unmerged ||
+ (!data->files[i]->is_interesting && (added + deleted == 0))) {
total_files--;
} else if (!data->files[i]->is_binary) { /* don't count bytes */
adds += added;
--
1.8.0.1.337.gd2c5e06
^ permalink raw reply related
* [PATCH v2 1/6] git-remote-helpers.txt: document invocation before input format
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
In the distant past, the order things were documented was
'Invocation', 'Commands', 'Capabilities', ...
Then it was decided that before giving a list of Commands, there
should be an overall description of the 'Input format', which was
a wise decision. However, this description was put as the very
first thing, with the rationale that any implementor would want
to know that first.
However, it seems an implementor would actually first need to
know how the remote helper will be invoked, so moving
'Invocation' to the front again seems logical. Moreover, we now
don't switch from discussing the input format to the invocation
style and then back to input related stuff.
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 62 ++++++++++++++++++------------------
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 5ce4cda..9a7e583 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', 'git-remote-https',
'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
'fetch', 'option', and 'push'.
+INVOCATION
+----------
+
+Remote helper programs are invoked with one or (optionally) two
+arguments. The first argument specifies a remote repository as in git;
+it is either the name of a configured remote or a URL. The second
+argument specifies a URL; it is usually of the form
+'<transport>://<address>', but any arbitrary string is possible.
+The 'GIT_DIR' environment variable is set up for the remote helper
+and can be used to determine where to store additional data or from
+which directory to invoke auxiliary git commands.
+
+When git encounters a URL of the form '<transport>://<address>', where
+'<transport>' is a protocol that it cannot handle natively, it
+automatically invokes 'git remote-<transport>' with the full URL as
+the second argument. If such a URL is encountered directly on the
+command line, the first argument is the same as the second, and if it
+is encountered in a configured remote, the first argument is the name
+of that remote.
+
+A URL of the form '<transport>::<address>' explicitly instructs git to
+invoke 'git remote-<transport>' with '<address>' as the second
+argument. If such a URL is encountered directly on the command line,
+the first argument is '<address>', and if it is encountered in a
+configured remote, the first argument is the name of that remote.
+
+Additionally, when a configured remote has 'remote.<name>.vcs' set to
+'<transport>', git explicitly invokes 'git remote-<transport>' with
+'<name>' as the first argument. If set, the second argument is
+'remote.<name>.url'; otherwise, the second argument is omitted.
+
INPUT FORMAT
------------
@@ -173,37 +204,6 @@ advertised with this capability must cover all refs reported by
the list command. If no 'refspec' capability is advertised,
there is an implied `refspec *:*`.
-INVOCATION
-----------
-
-Remote helper programs are invoked with one or (optionally) two
-arguments. The first argument specifies a remote repository as in git;
-it is either the name of a configured remote or a URL. The second
-argument specifies a URL; it is usually of the form
-'<transport>://<address>', but any arbitrary string is possible.
-The 'GIT_DIR' environment variable is set up for the remote helper
-and can be used to determine where to store additional data or from
-which directory to invoke auxiliary git commands.
-
-When git encounters a URL of the form '<transport>://<address>', where
-'<transport>' is a protocol that it cannot handle natively, it
-automatically invokes 'git remote-<transport>' with the full URL as
-the second argument. If such a URL is encountered directly on the
-command line, the first argument is the same as the second, and if it
-is encountered in a configured remote, the first argument is the name
-of that remote.
-
-A URL of the form '<transport>::<address>' explicitly instructs git to
-invoke 'git remote-<transport>' with '<address>' as the second
-argument. If such a URL is encountered directly on the command line,
-the first argument is '<address>', and if it is encountered in a
-configured remote, the first argument is the name of that remote.
-
-Additionally, when a configured remote has 'remote.<name>.vcs' set to
-'<transport>', git explicitly invokes 'git remote-<transport>' with
-'<name>' as the first argument. If set, the second argument is
-'remote.<name>.url'; otherwise, the second argument is omitted.
-
COMMANDS
--------
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH v2 2/6] git-remote-helpers.txt: document missing capabilities
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
Specifically, document the 'export' and '(im|ex)port-marks'
capabilities as well as the export command, which were
undocumented (but in active use).
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 45 +++++++++++++++++++++++++++++++++---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 9a7e583..db63541 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -106,6 +106,10 @@ to the `capabilities` command (see COMMANDS, below).
For listing remote refs and fetching the associated history to
the local object store.
+'export'::
+ For listing remote refs and pushing specified objects from a
+ fast-import stream to remote refs.
+
'import'::
For listing remote refs and fetching the associated history as
a fast-import stream.
@@ -143,6 +147,16 @@ there is an implied `refspec *:*`.
This is to prevent mixing commands and fast-import responses on the
helper's stdin.
+'export-marks' <file>::
+ This modifies the 'export' capability, instructing git to dump the
+ internal marks table to <file> when complete. For details,
+ read up on '--export-marks=<file>' in linkgit:git-fast-export[1].
+
+'import-marks' <file>::
+ This modifies the 'export' capability, instructing git to load the
+ marks specified in <file> before processing any input. For details,
+ read up on '--import-marks=<file>' in linkgit:git-fast-export[1].
+
Capabilities for Pushing
~~~~~~~~~~~~~~~~~~~~~~~~
'connect'::
@@ -158,9 +172,18 @@ Supported commands: 'connect'.
+
Supported commands: 'list for-push', 'push'.
-If a helper advertises both 'connect' and 'push', git will use
-'connect' if possible and fall back to 'push' if the helper requests
-so when connecting (see the 'connect' command under COMMANDS).
+'export'::
+ Can discover remote refs and push specified objects from a
+ fast-import stream to remote refs.
++
+Supported commands: 'list for-push', 'export'.
+
+If a helper advertises 'connect', git will use it if possible and
+fall back to another capability if the helper requests so when
+connecting (see the 'connect' command under COMMANDS).
+When choosing between 'push' and 'export', git prefers 'push'.
+Other frontends may have some other order of preference.
+
Capabilities for Fetching
~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -307,6 +330,22 @@ stdin.
+
Supported if the helper has the 'import' capability.
+'export'::
+ Instructs the remote helper that any subsequent input is
+ part of a fast-import stream (generated by 'git fast-export')
+ containing objects which should be pushed to the remote.
++
+Especially useful for interoperability with a foreign versioning
+system.
++
+The 'export-marks' and 'import-marks' capabilities, if specified,
+affect this command in so far as they are passed on to 'git
+fast-export', which then will load/store a table of marks for
+local objects. This can be used to implement for incremental
+operations.
++
+Supported if the helper has the 'export' capability.
+
'connect' <service>::
Connects to given service. Standard input and standard output
of helper are connected to specified service (git prefix is
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH v2 5/6] git-remote-helpers.txt: clarify command <-> capability correspondences
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
In particular, document 'list for-push' separately from 'list', as
the former needs only be supported for the push/export
capabilities, and the latter only for fetch/import. Indeed, a
hypothetically 'push-only' helper would only need to support the
former, not the latter.
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 21 ++++++++++++++++-----
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 7ac1461..023dcca 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -216,6 +216,8 @@ Commands are given by the caller on the helper's standard input, one per line.
which marks them mandatory for git versions using the remote
helper to understand. Any unknown mandatory capability is a
fatal error.
++
+Support for this command is mandatory.
'list'::
Lists the refs, one per line, in the format "<value> <name>
@@ -225,9 +227,18 @@ Commands are given by the caller on the helper's standard input, one per line.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
+
-If 'push' is supported this may be called as 'list for-push'
-to obtain the current refs prior to sending one or more 'push'
-commands to the helper.
+Supported if the helper has the "fetch" or "import" capability.
+
+'list for-push'::
+ Similar to 'list', except that it is used if and only if
+ the caller wants to the resulting ref list to prepare
+ push commands.
+ A helper supporting both push and fetch can use this
+ to distinguish for which operation the output of 'list'
+ is going to be used, possibly reducing the amount
+ of work that needs to be performed.
++
+Supported if the helper has the "push" or "export" capability.
'option' <name> <value>::
Sets the transport helper option <name> to <value>. Outputs a
@@ -306,7 +317,7 @@ sequence has to be buffered before starting to send data to fast-import
to prevent mixing of commands and fast-import responses on the helper's
stdin.
+
-Supported if the helper has the 'import' capability.
+Supported if the helper has the "import" capability.
'export'::
Instructs the remote helper that any subsequent input is
@@ -322,7 +333,7 @@ fast-export', which then will load/store a table of marks for
local objects. This can be used to implement for incremental
operations.
+
-Supported if the helper has the 'export' capability.
+Supported if the helper has the "export" capability.
'connect' <service>::
Connects to given service. Standard input and standard output
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH v2 0/6] Improve remote helper documentation
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
Various remote helper capabilities and commands were not
documented, in particular 'export', or documented in a misleading
way (e.g. 'for-push' was listed as a ref attribute understood by
git, which is not the case). This patch series changes that, and
also address some other things in the remote helper documentation
that I found jarring when reading through it.
Note that the description of export and (im|ex)port-marks probably can be
improved, and I hope that somebody who knows more about them
than me and/or is better at writing documentation will do just that.
But I felt it was better to provide something than to do nothing
and only complain, as I did previously on this subject ;-).
Max Horn (6):
git-remote-helpers.txt: document invocation before input format
git-remote-helpers.txt: document missing capabilities
git-remote-helpers.txt: minor grammar fix
git-remote-helpers.txt: rearrange description of capabilities
git-remote-helpers.txt: clarify command <-> capability correspondences
git-remote-helpers.txt: clarify options & ref list attributes
Documentation/git-remote-helpers.txt | 245 ++++++++++++++++++++---------------
1 file changed, 140 insertions(+), 105 deletions(-)
--
1.8.0.393.gcc9701d
^ permalink raw reply
* [PATCH 6/6] git-remote-helpers.txt: clarify ref list attributes, link to subsections
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
The documentation was misleading in that it gave the impression that
'for-push' could be used as a ref attribute in the output of the
'list' command. That is wrong.
Also, explicitly point out the connection between the commands
'list' and 'options' on the one hand, and the sections
'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 023dcca..e1df01d 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -227,6 +227,8 @@ Support for this command is mandatory.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
+
+See REF LIST ATTRIBUTES for a list of currently defined options.
++
Supported if the helper has the "fetch" or "import" capability.
'list for-push'::
@@ -248,6 +250,8 @@ Supported if the helper has the "push" or "export" capability.
for it). Options should be set before other commands,
and may influence the behavior of those commands.
+
+See OPTIONS for a list of currently defined options.
++
Supported if the helper has the "option" capability.
'fetch' <sha1> <name>::
@@ -256,7 +260,7 @@ Supported if the helper has the "option" capability.
per line, terminated with a blank line.
Outputs a single blank line when all fetch commands in the
same batch are complete. Only objects which were reported
- in the ref list with a sha1 may be fetched this way.
+ in the output of 'list' with a sha1 may be fetched this way.
+
Optionally may output a 'lock <file>' line indicating a file under
GIT_DIR/objects/pack which is keeping a pack until refs can be
@@ -360,10 +364,9 @@ capabilities reported by the helper.
REF LIST ATTRIBUTES
-------------------
-'for-push'::
- The caller wants to use the ref list to prepare push
- commands. A helper might chose to acquire the ref list by
- opening a different type of connection to the destination.
+The 'list' command produces a list of refs in which each ref
+may be followed by a list of attributes. The following ref list
+attributes are defined.
'unchanged'::
This ref is unchanged since the last import or fetch, although
@@ -371,6 +374,10 @@ REF LIST ATTRIBUTES
OPTIONS
-------
+
+The following options are defined and (under suitable circumstances)
+set by git if the remote helper has the 'option' capability.
+
'option verbosity' <n>::
Changes the verbosity of messages displayed by the helper.
A value of 0 for <n> means that processes operate
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH v2 4/6] git-remote-helpers.txt: rearrange description of capabilities
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
This also remove some duplication in the descriptions
(e.g. refspec was explained twice with similar level of detail).
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 134 +++++++++++++++--------------------
1 file changed, 56 insertions(+), 78 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 7eb43d7..7ac1461 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -88,81 +88,17 @@ Each remote helper is expected to support only a subset of commands.
The operations a helper supports are declared to git in the response
to the `capabilities` command (see COMMANDS, below).
-'option'::
- For specifying settings like `verbosity` (how much output to
- write to stderr) and `depth` (how much history is wanted in the
- case of a shallow clone) that affect how other commands are
- carried out.
-
-'connect'::
- For fetching and pushing using git's native packfile protocol
- that requires a bidirectional, full-duplex connection.
-
-'push'::
- For listing remote refs and pushing specified objects from the
- local object store to remote refs.
-
-'fetch'::
- For listing remote refs and fetching the associated history to
- the local object store.
-
-'export'::
- For listing remote refs and pushing specified objects from a
- fast-import stream to remote refs.
-
-'import'::
- For listing remote refs and fetching the associated history as
- a fast-import stream.
-
-'refspec' <refspec>::
- This modifies the 'import' capability, allowing the produced
- fast-import stream to modify refs in a private namespace
- instead of writing to refs/heads or refs/remotes directly.
- It is recommended that all importers providing the 'import'
- capability use this.
-+
-A helper advertising the capability
-`refspec refs/heads/*:refs/svn/origin/branches/*`
-is saying that, when it is asked to `import refs/heads/topic`, the
-stream it outputs will update the `refs/svn/origin/branches/topic`
-ref.
-+
-This capability can be advertised multiple times. The first
-applicable refspec takes precedence. The left-hand of refspecs
-advertised with this capability must cover all refs reported by
-the list command. If no 'refspec' capability is advertised,
-there is an implied `refspec *:*`.
-
-'bidi-import'::
- The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers
- to retrieve information about blobs and trees that already exist in
- fast-import's memory. This requires a channel from fast-import to the
- remote-helper.
- If it is advertised in addition to "import", git establishes a pipe from
- fast-import to the remote-helper's stdin.
- It follows that git and fast-import are both connected to the
- remote-helper's stdin. Because git can send multiple commands to
- the remote-helper it is required that helpers that use 'bidi-import'
- buffer all 'import' commands of a batch before sending data to fast-import.
- This is to prevent mixing commands and fast-import responses on the
- helper's stdin.
-
-'export-marks' <file>::
- This modifies the 'export' capability, instructing git to dump the
- internal marks table to <file> when complete. For details,
- read up on '--export-marks=<file>' in linkgit:git-fast-export[1].
-
-'import-marks' <file>::
- This modifies the 'export' capability, instructing git to load the
- marks specified in <file> before processing any input. For details,
- read up on '--import-marks=<file>' in linkgit:git-fast-export[1].
+In the following, we list all defined capabilities and for
+each we list which commands a helper with that capability
+must provide.
Capabilities for Pushing
-~~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^^
'connect'::
Can attempt to connect to 'git receive-pack' (for pushing),
- 'git upload-pack', etc for communication using the
- packfile protocol.
+ 'git upload-pack', etc for communication using
+ git's native packfile protocol. This
+ requires a bidirectional, full-duplex connection.
+
Supported commands: 'connect'.
@@ -186,11 +122,12 @@ Other frontends may have some other order of preference.
Capabilities for Fetching
-~~~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^^^
'connect'::
Can try to connect to 'git upload-pack' (for fetching),
'git receive-pack', etc for communication using the
- packfile protocol.
+ git's native packfile protocol. This
+ requires a bidirectional, full-duplex connection.
+
Supported commands: 'connect'.
@@ -212,14 +149,27 @@ connecting (see the 'connect' command under COMMANDS).
When choosing between 'fetch' and 'import', git prefers 'fetch'.
Other frontends may have some other order of preference.
+Miscellaneous capabilities
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+'option'::
+ For specifying settings like `verbosity` (how much output to
+ write to stderr) and `depth` (how much history is wanted in the
+ case of a shallow clone) that affect how other commands are
+ carried out.
+
'refspec' <refspec>::
- This modifies the 'import' capability.
+ This modifies the 'import' capability, allowing the produced
+ fast-import stream to modify refs in a private namespace
+ instead of writing to refs/heads or refs/remotes directly.
+ It is recommended that all importers providing the 'import'
+ capability use this.
+
-A helper advertising
+A helper advertising the capability
`refspec refs/heads/*:refs/svn/origin/branches/*`
-in its capabilities is saying that, when it handles
-`import refs/heads/topic`, the stream it outputs will update the
-`refs/svn/origin/branches/topic` ref.
+is saying that, when it is asked to `import refs/heads/topic`, the
+stream it outputs will update the `refs/svn/origin/branches/topic`
+ref.
+
This capability can be advertised multiple times. The first
applicable refspec takes precedence. The left-hand of refspecs
@@ -227,6 +177,34 @@ advertised with this capability must cover all refs reported by
the list command. If no 'refspec' capability is advertised,
there is an implied `refspec *:*`.
+'bidi-import'::
+ This modifies the 'import' capability.
+ The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers
+ to retrieve information about blobs and trees that already exist in
+ fast-import's memory. This requires a channel from fast-import to the
+ remote-helper.
+ If it is advertised in addition to "import", git establishes a pipe from
+ fast-import to the remote-helper's stdin.
+ It follows that git and fast-import are both connected to the
+ remote-helper's stdin. Because git can send multiple commands to
+ the remote-helper it is required that helpers that use 'bidi-import'
+ buffer all 'import' commands of a batch before sending data to fast-import.
+ This is to prevent mixing commands and fast-import responses on the
+ helper's stdin.
+
+'export-marks' <file>::
+ This modifies the 'export' capability, instructing git to dump the
+ internal marks table to <file> when complete. For details,
+ read up on '--export-marks=<file>' in linkgit:git-fast-export[1].
+
+'import-marks' <file>::
+ This modifies the 'export' capability, instructing git to load the
+ marks specified in <file> before processing any input. For details,
+ read up on '--import-marks=<file>' in linkgit:git-fast-export[1].
+
+
+
+
COMMANDS
--------
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH v2 6/6] git-remote-helpers.txt: clarify options & ref list attributes
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
The documentation was misleading in that it gave the impression that
'for-push' could be used as a ref attribute in the output of the
'list' command. That is wrong.
Also, explicitly point out the connection between the commands
'list' and 'options' on the one hand, and the sections
'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 023dcca..e1df01d 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -227,6 +227,8 @@ Support for this command is mandatory.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
+
+See REF LIST ATTRIBUTES for a list of currently defined options.
++
Supported if the helper has the "fetch" or "import" capability.
'list for-push'::
@@ -248,6 +250,8 @@ Supported if the helper has the "push" or "export" capability.
for it). Options should be set before other commands,
and may influence the behavior of those commands.
+
+See OPTIONS for a list of currently defined options.
++
Supported if the helper has the "option" capability.
'fetch' <sha1> <name>::
@@ -256,7 +260,7 @@ Supported if the helper has the "option" capability.
per line, terminated with a blank line.
Outputs a single blank line when all fetch commands in the
same batch are complete. Only objects which were reported
- in the ref list with a sha1 may be fetched this way.
+ in the output of 'list' with a sha1 may be fetched this way.
+
Optionally may output a 'lock <file>' line indicating a file under
GIT_DIR/objects/pack which is keeping a pack until refs can be
@@ -360,10 +364,9 @@ capabilities reported by the helper.
REF LIST ATTRIBUTES
-------------------
-'for-push'::
- The caller wants to use the ref list to prepare push
- commands. A helper might chose to acquire the ref list by
- opening a different type of connection to the destination.
+The 'list' command produces a list of refs in which each ref
+may be followed by a list of attributes. The following ref list
+attributes are defined.
'unchanged'::
This ref is unchanged since the last import or fetch, although
@@ -371,6 +374,10 @@ REF LIST ATTRIBUTES
OPTIONS
-------
+
+The following options are defined and (under suitable circumstances)
+set by git if the remote helper has the 'option' capability.
+
'option verbosity' <n>::
Changes the verbosity of messages displayed by the helper.
A value of 0 for <n> means that processes operate
--
1.8.0.393.gcc9701d
^ permalink raw reply related
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