* [PATCH 1/4] git-am --whitespace: do not lose the command line option
From: Junio C Hamano @ 2008-12-05 2:22 UTC (permalink / raw)
To: git
In-Reply-To: <1228443780-3386-1-git-send-email-gitster@pobox.com>
When you start "git am --whitespace=fix" and the patch application process
is interrupted by an unapplicable patch early in the series, after
fixing the offending patch, the remainder of the patch should be processed
still with --whitespace=fix when restarted with "git am --resolved" (or
dropping the offending patch with "git am --skip").
The breakage was introduced by the commit 67dad68 (add -C[NUM] to git-am,
2007-02-08); this should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-am.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index aa60261..1bf70d4 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -121,7 +121,7 @@ It does not apply to blobs recorded in its index."
prec=4
dotest="$GIT_DIR/rebase-apply"
-sign= utf8=t keep= skip= interactive= resolved= rebasing= abort=
+sign= utf8=t keep= skip= interactive= resolved= rebasing= abort= ws=
resolvemsg= resume=
git_apply_opt=
@@ -156,7 +156,7 @@ do
--resolvemsg)
shift; resolvemsg=$1 ;;
--whitespace)
- git_apply_opt="$git_apply_opt $1=$2"; shift ;;
+ ws="--whitespace=$2"; shift ;;
-C|-p)
git_apply_opt="$git_apply_opt $1$2"; shift ;;
--)
@@ -283,7 +283,7 @@ if test "$(cat "$dotest/keep")" = t
then
keep=-k
fi
-ws=`cat "$dotest/whitespace"`
+ws=$(cat "$dotest/whitespace")
if test "$(cat "$dotest/sign")" = t
then
SIGNOFF=`git var GIT_COMMITTER_IDENT | sed -e '
@@ -454,7 +454,7 @@ do
case "$resolved" in
'')
- git apply $git_apply_opt --index "$dotest/patch"
+ git apply $git_apply_opt $ws --index "$dotest/patch"
apply_status=$?
;;
t)
--
1.6.1.rc1.60.g1d1d7
^ permalink raw reply related
* [PATCH 2/4] git-am: propagate -C<n>, -p<n> options as well
From: Junio C Hamano @ 2008-12-05 2:22 UTC (permalink / raw)
To: git
In-Reply-To: <1228443780-3386-2-git-send-email-gitster@pobox.com>
These options are meant to deal with patches that do not apply cleanly
due to the differences between the version the patch was based on and
the version "git am" is working on.
Because a series of patches applied in the same "git am" run tends to
come from the same source, it is more useful to propagate these options
after the application stops.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-am.sh | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 1bf70d4..ed54e71 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -121,7 +121,7 @@ It does not apply to blobs recorded in its index."
prec=4
dotest="$GIT_DIR/rebase-apply"
-sign= utf8=t keep= skip= interactive= resolved= rebasing= abort= ws=
+sign= utf8=t keep= skip= interactive= resolved= rebasing= abort=
resolvemsg= resume=
git_apply_opt=
@@ -156,7 +156,7 @@ do
--resolvemsg)
shift; resolvemsg=$1 ;;
--whitespace)
- ws="--whitespace=$2"; shift ;;
+ git_apply_opt="$git_apply_opt $1=$2"; shift ;;
-C|-p)
git_apply_opt="$git_apply_opt $1$2"; shift ;;
--)
@@ -247,10 +247,10 @@ else
exit 1
}
- # -s, -u, -k and --whitespace flags are kept for the
- # resuming session after a patch failure.
+ # -s, -u, -k, --whitespace, -C and -p flags are kept
+ # for the resuming session after a patch failure.
# -3 and -i can and must be given when resuming.
- echo " $ws" >"$dotest/whitespace"
+ echo " $git_apply_opt" >"$dotest/apply_opt_extra"
echo "$sign" >"$dotest/sign"
echo "$utf8" >"$dotest/utf8"
echo "$keep" >"$dotest/keep"
@@ -283,7 +283,7 @@ if test "$(cat "$dotest/keep")" = t
then
keep=-k
fi
-ws=$(cat "$dotest/whitespace")
+git_apply_opt=$(cat "$dotest/apply_opt_extra")
if test "$(cat "$dotest/sign")" = t
then
SIGNOFF=`git var GIT_COMMITTER_IDENT | sed -e '
@@ -454,7 +454,7 @@ do
case "$resolved" in
'')
- git apply $git_apply_opt $ws --index "$dotest/patch"
+ git apply $git_apply_opt --index "$dotest/patch"
apply_status=$?
;;
t)
--
1.6.1.rc1.60.g1d1d7
^ permalink raw reply related
* [PATCH 3/4] git-am: propagate --3way options as well
From: Junio C Hamano @ 2008-12-05 2:22 UTC (permalink / raw)
To: git
In-Reply-To: <1228443780-3386-3-git-send-email-gitster@pobox.com>
The reasoning is the same as the previous patch, where we made -C<n>
and -p<n> propagate across a failure.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-am.sh | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index ed54e71..13c02d6 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -247,10 +247,11 @@ else
exit 1
}
- # -s, -u, -k, --whitespace, -C and -p flags are kept
+ # -s, -u, -k, --whitespace, -3, -C and -p flags are kept
# for the resuming session after a patch failure.
- # -3 and -i can and must be given when resuming.
+ # -i can and must be given when resuming.
echo " $git_apply_opt" >"$dotest/apply_opt_extra"
+ echo "$threeway" >"$dotest/threeway"
echo "$sign" >"$dotest/sign"
echo "$utf8" >"$dotest/utf8"
echo "$keep" >"$dotest/keep"
@@ -283,6 +284,10 @@ if test "$(cat "$dotest/keep")" = t
then
keep=-k
fi
+if test "$(cat "$dotest/threeway")" = t
+then
+ threeway=t
+fi
git_apply_opt=$(cat "$dotest/apply_opt_extra")
if test "$(cat "$dotest/sign")" = t
then
--
1.6.1.rc1.60.g1d1d7
^ permalink raw reply related
* [PATCH 4/4] Test that git-am does not lose -C/-p/--whitespace options
From: Junio C Hamano @ 2008-12-05 2:23 UTC (permalink / raw)
To: git
In-Reply-To: <1228443780-3386-4-git-send-email-gitster@pobox.com>
These tests make sure that "git am" does not lose command line options
specified when it was started, after it is interrupted by a patch that
does not apply earlier in the series.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t4252-am-options.sh | 54 +++++++++++++++++++++++++++++++++++++++++++++++++
t/t4252/am-test-1-1 | 19 +++++++++++++++++
t/t4252/am-test-1-2 | 21 +++++++++++++++++++
t/t4252/am-test-2-1 | 19 +++++++++++++++++
t/t4252/am-test-2-2 | 21 +++++++++++++++++++
t/t4252/am-test-3-1 | 19 +++++++++++++++++
t/t4252/am-test-3-2 | 21 +++++++++++++++++++
t/t4252/am-test-4-1 | 19 +++++++++++++++++
t/t4252/am-test-4-2 | 22 ++++++++++++++++++++
t/t4252/file-1-0 | 7 ++++++
t/t4252/file-2-0 | 7 ++++++
11 files changed, 229 insertions(+), 0 deletions(-)
create mode 100755 t/t4252-am-options.sh
create mode 100644 t/t4252/am-test-1-1
create mode 100644 t/t4252/am-test-1-2
create mode 100644 t/t4252/am-test-2-1
create mode 100644 t/t4252/am-test-2-2
create mode 100644 t/t4252/am-test-3-1
create mode 100644 t/t4252/am-test-3-2
create mode 100644 t/t4252/am-test-4-1
create mode 100644 t/t4252/am-test-4-2
create mode 100644 t/t4252/file-1-0
create mode 100644 t/t4252/file-2-0
diff --git a/t/t4252-am-options.sh b/t/t4252-am-options.sh
new file mode 100755
index 0000000..1a1946d
--- /dev/null
+++ b/t/t4252-am-options.sh
@@ -0,0 +1,54 @@
+#!/bin/sh
+
+test_description='git am not losing options'
+. ./test-lib.sh
+
+tm="$TEST_DIRECTORY/t4252"
+
+test_expect_success setup '
+ cp "$tm/file-1-0" file-1 &&
+ cp "$tm/file-2-0" file-2 &&
+ git add file-1 file-2 &&
+ test_tick &&
+ git commit -m initial &&
+ git tag initial
+'
+
+test_expect_success 'interrupted am --whitespace=fix' '
+ rm -rf .git/rebase-apply &&
+ git reset --hard initial &&
+ test_must_fail git am --whitespace=fix "$tm"/am-test-1-? &&
+ git am --skip &&
+ grep 3 file-1 &&
+ grep "^Six$" file-2
+'
+
+test_expect_success 'interrupted am -C1' '
+ rm -rf .git/rebase-apply &&
+ git reset --hard initial &&
+ test_must_fail git am -C1 "$tm"/am-test-2-? &&
+ git am --skip &&
+ grep 3 file-1 &&
+ grep "^Three$" file-2
+'
+
+test_expect_success 'interrupted am -p2' '
+ rm -rf .git/rebase-apply &&
+ git reset --hard initial &&
+ test_must_fail git am -p2 "$tm"/am-test-3-? &&
+ git am --skip &&
+ grep 3 file-1 &&
+ grep "^Three$" file-2
+'
+
+test_expect_success 'interrupted am -C1 -p2' '
+ rm -rf .git/rebase-apply &&
+ git reset --hard initial &&
+ test_must_fail git am -p2 -C1 "$tm"/am-test-4-? &&
+ cat .git/rebase-apply/apply_opt_extra &&
+ git am --skip &&
+ grep 3 file-1 &&
+ grep "^Three$" file-2
+'
+
+test_done
diff --git a/t/t4252/am-test-1-1 b/t/t4252/am-test-1-1
new file mode 100644
index 0000000..b0c09dc
--- /dev/null
+++ b/t/t4252/am-test-1-1
@@ -0,0 +1,19 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Three
+
+Application of this should be rejected because the first line in the
+context does not match.
+
+diff --git i/file-1 w/file-1
+index 06e567b..10f8342 100644
+--- i/file-1
++++ w/file-1
+@@ -1,6 +1,6 @@
+ One
+ 2
+-3
++Three
+ 4
+ 5
+ 6
diff --git a/t/t4252/am-test-1-2 b/t/t4252/am-test-1-2
new file mode 100644
index 0000000..1b874ae
--- /dev/null
+++ b/t/t4252/am-test-1-2
@@ -0,0 +1,21 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Six
+
+Applying this patch with --whitespace=fix should lose
+the trailing whitespace after "Six".
+
+diff --git i/file-2 w/file-2
+index 06e567b..b6f3a16 100644
+--- i/file-2
++++ w/file-2
+@@ -1,7 +1,7 @@
+ 1
+ 2
+-3
++Three
+ 4
+ 5
+-6
++Six
+ 7
diff --git a/t/t4252/am-test-2-1 b/t/t4252/am-test-2-1
new file mode 100644
index 0000000..feda94a
--- /dev/null
+++ b/t/t4252/am-test-2-1
@@ -0,0 +1,19 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Three
+
+Application of this should be rejected even with -C1 because the
+preimage line in the context does not match.
+
+diff --git i/file-1 w/file-1
+index 06e567b..10f8342 100644
+--- i/file-1
++++ w/file-1
+@@ -1,6 +1,6 @@
+ 1
+ 2
+-Tres
++Three
+ 4
+ 5
+ 6
diff --git a/t/t4252/am-test-2-2 b/t/t4252/am-test-2-2
new file mode 100644
index 0000000..2ac6600
--- /dev/null
+++ b/t/t4252/am-test-2-2
@@ -0,0 +1,21 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Six
+
+Applying this patch with -C1 should be successful even though
+the first line in the context does not match.
+
+diff --git i/file-2 w/file-2
+index 06e567b..b6f3a16 100644
+--- i/file-2
++++ w/file-2
+@@ -1,7 +1,7 @@
+ One
+ 2
+-3
++Three
+ 4
+ 5
+-6
++Six
+ 7
diff --git a/t/t4252/am-test-3-1 b/t/t4252/am-test-3-1
new file mode 100644
index 0000000..608e5ab
--- /dev/null
+++ b/t/t4252/am-test-3-1
@@ -0,0 +1,19 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Three
+
+Application of this should be rejected even with -p2 because the
+preimage line in the context does not match.
+
+diff --git i/junk/file-1 w/junk/file-1
+index 06e567b..10f8342 100644
+--- i/junk/file-1
++++ w/junk/file-1
+@@ -1,6 +1,6 @@
+ 1
+ 2
+-Tres
++Three
+ 4
+ 5
+ 6
diff --git a/t/t4252/am-test-3-2 b/t/t4252/am-test-3-2
new file mode 100644
index 0000000..0081b96
--- /dev/null
+++ b/t/t4252/am-test-3-2
@@ -0,0 +1,21 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Six
+
+Applying this patch with -p2 should be successful even though
+the patch is against a wrong level.
+
+diff --git i/junk/file-2 w/junk/file-2
+index 06e567b..b6f3a16 100644
+--- i/junk/file-2
++++ w/junk/file-2
+@@ -1,7 +1,7 @@
+ 1
+ 2
+-3
++Three
+ 4
+ 5
+-6
++Six
+ 7
diff --git a/t/t4252/am-test-4-1 b/t/t4252/am-test-4-1
new file mode 100644
index 0000000..e48cd6c
--- /dev/null
+++ b/t/t4252/am-test-4-1
@@ -0,0 +1,19 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Three
+
+Application of this should be rejected even with -C1 -p2 because
+the preimage line in the context does not match.
+
+diff --git i/junk/file-1 w/junk/file-1
+index 06e567b..10f8342 100644
+--- i/junk/file-1
++++ w/junk/file-1
+@@ -1,6 +1,6 @@
+ 1
+ 2
+-Tres
++Three
+ 4
+ 5
+ 6
diff --git a/t/t4252/am-test-4-2 b/t/t4252/am-test-4-2
new file mode 100644
index 0000000..0e69bfa
--- /dev/null
+++ b/t/t4252/am-test-4-2
@@ -0,0 +1,22 @@
+From: A U Thor <au.thor@example.com>
+Date: Thu Dec 4 16:00:00 2008 -0800
+Subject: Six
+
+Applying this patch with -C1 -p2 should be successful even though
+the patch is against a wrong level and the first context line does
+not match.
+
+diff --git i/junk/file-2 w/junk/file-2
+index 06e567b..b6f3a16 100644
+--- i/junk/file-2
++++ w/junk/file-2
+@@ -1,7 +1,7 @@
+ One
+ 2
+-3
++Three
+ 4
+ 5
+-6
++Six
+ 7
diff --git a/t/t4252/file-1-0 b/t/t4252/file-1-0
new file mode 100644
index 0000000..06e567b
--- /dev/null
+++ b/t/t4252/file-1-0
@@ -0,0 +1,7 @@
+1
+2
+3
+4
+5
+6
+7
diff --git a/t/t4252/file-2-0 b/t/t4252/file-2-0
new file mode 100644
index 0000000..06e567b
--- /dev/null
+++ b/t/t4252/file-2-0
@@ -0,0 +1,7 @@
+1
+2
+3
+4
+5
+6
+7
--
1.6.1.rc1.60.g1d1d7
^ permalink raw reply related
* Re: [PATCH] git-p4: Fix bug in p4Where method.
From: Junio C Hamano @ 2008-12-05 2:23 UTC (permalink / raw)
To: Tor Arvid Lund; +Cc: Simon Hausmann, git
In-Reply-To: <1228397853-15921-1-git-send-email-torarvid@gmail.com>
Thanks. Will apply to 'master' and will be in 1.6.1 final, unless some p4
users object (I do not use p4 myself, so that is the best I could do).
^ permalink raw reply
* Re: summaries in git add --patch[PATCH 1/2]
From: Junio C Hamano @ 2008-12-05 2:23 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <4937B456.7080604@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> Thanks for pointing that out. Settings changed. I do appreciate
> you taking the time to essentially hold my hand through this
> process, and hope that I'm not causing you too much extra work.
Heh, I'll be saving extra work I have to do in the future by training you
how to produce patches line the ones I may write myself. By doing so,
eventually I wouldn't have to code anything myself ;-)
> +# Generate a one line summary of a hunk.
> +sub summarize_hunk {
> + my $rhunk = shift;
> + my $summary = $rhunk->{TEXT}[0];
> +
> + # Keep the line numbers, discard extra context.
> + $summary =~ s/@@(.*?)@@.*/$1 /s;
> + $summary .= " " x (20 - length $summary);
> +
> + # Add some user context.
> + for my $line (@{$rhunk->{TEXT}}) {
> + if ($line =~ m/^[+-].*\w/) {
> + $summary .= $line;
> + last;
> + }
> + }
> +
> + chomp $summary;
> + return substr($summary, 0, 80) . "\n";
> +}
I'll queue the patches in this round as-is in 'pu' and merge to 'next', as
we should stop slushing around at some point and start polishing on a
solid ground. But as you mentioned, these hardcoded 20 and 80 do not look
very nice.
I think the division of labor between the data producer (summarize_hunk)
and presenter (display_hunks) should be shifted somewhat, so that
* summarize_hunk returns a two-tuple:
[ $line_number_hint, $first_change ]
* display_hunks runs summarize_hunk for all 20 hunks and gathers the
return values before producing a single line of output, and then
computes the maximum $line_number_hint to decide how many extra SP to
use to pad it to uniform length (instead of " " x (20 - length)).
After doing so, it loops over the hunks, using the collected return
values and formats.
In later round of polishing, you might find out that some callers of
summarize_hunk may want to read the full line, not just the first 80
(perhaps they feed their output to "less -S"). By splitting the
responsibility between these functions in the way outlined above, you do
not have to modify summarize_hunk when that day comes.
> +
> +
> +# Print a one-line summary of each hunk in the array ref in
> +# the first argument, starting wih the index in the 2nd.
> +sub display_hunks {
> + my ($hunks, $i) = @_;
> + my $ctr = 0;
> + $i ||= 0;
> + for (; $i < @$hunks && $ctr < 20; $i++, $ctr++) {
> + my $status = " ";
> + if (defined $hunks->[$i]{USE}) {
> + $status = $hunks->[$i]{USE} ? "+" : "-";
> + }
> + printf "%s%2d: %s",
> + $status,
> + $i + 1,
> + summarize_hunk($hunks->[$i]);
> + }
By the way, I do not think this will align if you have more than 100
hunks. That is also a reason why I would suggest not to format/substr
inside the summarize_hunk function.
^ permalink raw reply
* Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category
From: Sébastien Cevey @ 2008-12-05 2:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <200812050308.52891.jnareb@gmail.com>
At Fri, 5 Dec 2008 03:08:52 +0100, Jakub Narebski wrote:
> Nice... but perhaps it would be better to simply pass $from / $to to
> build_projlist_by_category function, and have in %categories only
> projects which are shown...
Ah you're right, we could do that, I hadn't thought of it. Sounds
cleaner than the $from/$to dance I did in this patch.
> well, unless filtered out in print_project_rows() by $show_ctags; so
> I think that there is nonzero probability of empty (no project
> shown) categories.
Mh indeed, in fact this could happen any time we reach one of the
'next' statements in the loop in print_project_rows(), when performing
search, tag filtering, etc...
Actually, assuming the project list is split into page, this can also
lead to empty pages (if no project on the page matches the filter).
To avoid empty categories, it's a bit tricky since the header is
printed before we determine whether there are matching projects..
I need to read the code more carefully, but it seems that one solution
would be to add a function that determines whether a project should be
displayed or not (according to tags and search and forks); then we can
map this function on the list of projects.
I could do it if it sounds sane to you.
> I don't think that the games we play with $from / $to would be enough.
> Check what happens (I think that it wouldn't work correctly) if we have
> something like that:
>
> project | category | shown
> --------------------------
> 1 | A |
> 2 | A |
> 3 | B | Y
> 4 | C | Y
> 5 | B | Y
> 6 | C |
> 7 | C |
AFAIK this cannot happen with the current code, since projects are
grouped by category (according to the foreach on categories).
> I'll try to examine the code in more detail later... currently I don't
> know why but I can't git-am the second patch (this patch) correctly...
This is the third patch, are you sure you applied 1 and 2 before?
Thanks for your careful and supportive comments!
--
Sébastien Cevey / inso.cc
^ permalink raw reply
* Re: [PATCH v3 3/3] gitweb: Optional grouping of projects by category
From: Jakub Narebski @ 2008-12-05 10:45 UTC (permalink / raw)
To: Sébastien Cevey
Cc: git, Junio C Hamano, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <87bpvr1hee.wl%seb@cine7.net>
On Fri, 5 Dec 2008 at 03:32, Sébastien Cevey wrote:
> At Fri, 5 Dec 2008 03:08:52 +0100, Jakub Narebski wrote:
>
> > Nice... but perhaps it would be better to simply pass $from / $to to
> > build_projlist_by_category function, and have in %categories only
> > projects which are shown...
>
> Ah you're right, we could do that, I hadn't thought of it. Sounds
> cleaner than the $from/$to dance I did in this patch.
Usually simpler is better. The more complicated code, the more chances
for bugs, and less maintability. I haven't even tried to follow
$from/$to updating logic, but noticed that we can simply pass $from
and $to to build_projlist_by_category(), and use loop $from..$to there.
> > well, unless filtered out in print_project_rows() by $show_ctags; so
> > I think that there is nonzero probability of empty (no project
> > shown) categories.
>
> Mh indeed, in fact this could happen any time we reach one of the
> 'next' statements in the loop in print_project_rows(), when performing
> search, tag filtering, etc...
>
> Actually, assuming the project list is split into page, this can also
> lead to empty pages (if no project on the page matches the filter).
> To avoid empty categories, it's a bit tricky since the header is
> printed before we determine whether there are matching projects..
>
> I need to read the code more carefully, but it seems that one solution
> would be to add a function that determines whether a project should be
> displayed or not (according to tags and search and forks); then we can
> map this function on the list of projects.
>
> I could do it if it sounds sane to you.
Nah, I think it would be best to postpone dealing with this issue, and
keep the code simple at the cost of possibly empty categories. It is
not as empty categories are an actual error...
I guess that correct way to deal with this would be to filter projects
earlier, before grouping by category, and not "at the last minute",
when displaying them. It might be even better solution wrt. dividing
projects list into pages. But that in my opinion is certainly matter
for a separate patch.
> > I'll try to examine the code in more detail later... currently I don't
> > know why but I can't git-am the second patch (this patch) correctly...
>
> This is the third patch, are you sure you applied 1 and 2 before?
Somehow I couldn't apply second patch in series:
$ git am -3 -u "[PATCH v3 2_3] gitweb: Split git_project_list_body in two functions.txt"
Applying: gitweb: Split git_project_list_body in two functions
error: patch failed: gitweb/gitweb.perl:3972
error: gitweb/gitweb.perl: patch does not apply
fatal: sha1 information is lacking or useless (gitweb/gitweb.perl).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.
> Thanks for your careful and supportive comments!
You are welcome. Nice to have another gitweb developer :-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-gui: Warn when username and e-mail address is unconfigured?
From: Alexander Gavrilov @ 2008-12-05 11:01 UTC (permalink / raw)
To: Jeremy Ramer
Cc: Junio C Hamano, spearce, sverre, Peter Krefting, Git Mailing List
In-Reply-To: <b9fd99020812041558w204e5f48gbed73fdbd289ad@mail.gmail.com>
On Fri, Dec 5, 2008 at 2:58 AM, Jeremy Ramer <jdramer@gmail.com> wrote:
> Yes, that does appear to be the message I get, with the following
> environment variables:
> - GIT_AUTHOR_EMAIL
> - GIT_COMMITTER_NAME
> - GIT_COMMITER_EMAIL
> - GIT_AUTHOR_NAME
>
> Now that I look closer I see that I am setting these in my .bashrc
> file. When I first started using git a year ago I was given the
> impression that these were needed. But I see that that is no longer
> the case since I use the config:
>
> git config --global user.name "Your Name"
> git config --global user.email "you@example.com"
>
> Removing them from my .bashrc removes the warning. In hindsight the
> warning should have clued me in, but I've been seeing that message
> since I first started using git on Cygwin so I figured it was a cygwin
> issue that I couldn't do anything about.
>
I wonder if what the warning says is still true. It's 2 years since
it was added, so the issue might have been fixed.
If you run "GIT_AUTHOR_NAME=foobar git gui", and make a commit,
does it set the author name to 'foobar'?
Alexander
^ permalink raw reply
* Using repo to work with multiple GIT repositories
From: kanagesh radhakrishnan @ 2008-12-05 11:20 UTC (permalink / raw)
To: git
Hello All,
My work currently resides in four different source trees, namely:
* bootloaders (git://192.168.10.1/bootloaders)
* kernel (git://192.168.10.1/kernel)
* applications (git://192.168.10.1/apps)
* build (git://192.168.10.1/build)
I maintain them as four different git repositories. They are hosted
on a local server enabling any other developer to be able to clone
from one of the trees, make changes, commit locally and then push to
the git server.
I was browsing through the Android source code and found that they
have a similar situation where code is maintained in a large number of
independent GIT repositories. The tool 'repo' is being used to
initialize and sync each tree.
I have been trying to bring in this approach to maintain my work too.
I have had success to some extent :-) I have created a manifest.git
and repo.git in my local server. The default.xml file being
maintained in manifest.git has a list of the GIT repositories being
hosted by my local GIT server.
In order to clone the four GIT trees from the server, I do the following:
$ repo init -u git://192.168.10.1/manifest.git
$ repo sync
This clones from the four source trees maintained in the GIT server.
I am able to make changes locally in each tree and commit them.
However, when I attempt to push the commits to the main repository on
the GIT server, it always says that 'everything is up to date'
$ git push user@192.168.10.1:/home/git/applications
user@192.168.10.1's password:
Everything up-to-date
Further, when I try to pull in any recent updates with the git-pull
command, I get the following error:
$ git-pull
fatal: 'origin': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
I know pushing to the repository on the GIT server works since I am
able to push local commits when I have cloned the working copy
manually (instead of using repo init and repo sync).
-----------------------------------------------------------------
$ git-clone git://192.168.10.1/applications
Initialized empty Git repository in /home/user/work/applications/.git/
remote: Counting objects: 6857, done.
remote: Compressing objects: 100% (3805/3805), done.
remote: Total 6857 (delta 2943), reused 6853 (delta 2941)
Receiving objects: 100% (6857/6857), 9.51 MiB | 10547 KiB/s, done.
Resolving deltas: 100% (2943/2943), done.
$
<edit, make changes, save, commit changes locally>
$ git-commit -a -m "Changed rule to build with custom tools"
Created commit bd55a06: Changed rule to build with custom tools
1 files changed, 1 insertions(+), 1 deletions(-)
$
<push changes to repository on GIT server>
$ git-push user@192.168.10.1:/home/git/applications
user@192.168.10.1's password:
Counting objects: 8, done.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 611 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
To user@192.168.10.1:/home/git/applications
dce4bea..bd55a06 master -> master
$
-----------------------------------------------------------------
May I know what I have to look at to solve this problem? Has anyone
faced a similar problem? Any pointers would be of help.
Thanks in advance.
Regards,
Kanagesh
^ permalink raw reply
* Re: [PATCH 2/4] git-am: propagate -C<n>, -p<n> options as well
From: Johannes Schindelin @ 2008-12-05 12:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1228443780-3386-3-git-send-email-gitster@pobox.com>
Hi,
On Thu, 4 Dec 2008, Junio C Hamano wrote:
> - echo " $ws" >"$dotest/whitespace"
> + echo " $git_apply_opt" >"$dotest/apply_opt_extra"
>From the other scripts, it appears we have sort of a convention to use
dashes instead of underscores for file names (see e.g.
$dotest/patch-merge-tmp-dir).
Other than that, the whole series looks good to me.
Thanks for the work, especially the tests,
Dscho
^ permalink raw reply
* Re: git alias always chdir to top
From: Pete Wyckoff @ 2008-12-05 14:09 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081204123402.GA23740@coredump.intra.peff.net>
peff@peff.net wrote on Thu, 04 Dec 2008 07:34 -0500:
> On Wed, Dec 03, 2008 at 11:08:52AM -0500, Pete Wyckoff wrote:
>
> > It looks like handle_alias() uses setup_git_directory_gently() to
> > find the .git, which chdir()s up until it gets there. Is there a
> > way to do this without changing the process current working
> > directory instead? I could even handle an environment variable
> > saving the original cwd, but that's ickier.
>
> There has been some discussion of refactoring the setup to _not_ do that
> chdir until later, which should fix your problem. And other problems,
> too, since aliases can get confused about whether or not we're in a
> worktree (try "git config alias.st status && cd .git && git st") as a
> result of the startup sequence. Ideally the _only_ thing to happen
> before running an alias would be to look at the config to see how to run
> the alias, and everything else would be "as if" you had just run the
> alias manually.
>
> So no, there's no way to do it correctly right now. The git commands
> internally do know the original prefix, but I don't think it is exposed
> via the environment.
>
> I hope this will get fixed eventually, but refactoring this code is
> unpleasant enough and I have been busy enough that it hasn't happened
> yet. You are of course welcome to volunteer. ;)
Thanks for these comments. I missed the discussion about
refactoring to move the chdir around.
In my particular case, since the only usage of this particular git
alias is by another script, I can get away with passing the full
path name and making some assumptions about the caller.
Point taken that it would be good to clean up the alias code path
so that this issue doesn't even arise in the first place.
-- Pete
^ permalink raw reply
* ETA for release of gjit 0.4?
From: Farrukh Najmi @ 2008-12-05 14:34 UTC (permalink / raw)
To: git
Dear colleagues,
I am using jgit in my maven project. Since current version is a SNAPSHOT
(0.4-SNAPSHOT) I cannot release my project with a SNAPSHOT dependency
(maven does not allow it). WHat is the time line for releasing version
0.4 of jgit so I can plan accordingly.
Thanks for any info.
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* Re: Git weekly news: 2008-49
From: Jakub Narebski @ 2008-12-05 16:02 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git list
In-Reply-To: <94a0d4530812041643r784ae8b1x242e3b2f9c9f41@mail.gmail.com>
"Felipe Contreras" <felipe.contreras@gmail.com> writes:
> Hi there,
>
> I've been following the git tag at delicious.com[1] and there's quite
> many interesting links, so I thought on gathering them so the git
> community can enjoy them in one pack :)
Nice work, although I think better alternative would be to weed those
links out, and put them in appropriate sections (or subsections) on
Git Wiki; to be more exact on http://git.or.cz/gitwiki/GitLinks
> The blog post is here:
> http://gitlog.wordpress.com/2008/12/05/git-weekely-news-2008-49/
First, "Official git blog"? Official? There is nothing official about
it. "Unofficial git blog", or "A git developer blog" (or "A git
follower blog"; unfortunately names like gitter or gitster for git
power user's, like TeXnician for TeX users, are taken by nicknames on
#git, if I remember correctly). Only git maintainer (Junio Hamano)
and git development community (the git mailing list) can decide that
something is "official" resource.
Second, I am a bit curious about 49 in "Git weekly news: 2008-49"
name of the post.
Third, it is collection of links, not news[1].
[1] It would be nice if somebody resurrected GitTraffic, offshot of
now defunct KernelTraffic, or at least helped to write Git articles
for KernelTrap (which currently is in a bit of hiatus).
>
> But here are the links anyway. The order is rather random.
Moreover the _quality_ of those links is very random.
> Why Git is Better than X
> http://whygitisbetterthanx.com/
Quite good link from what I superficially checked, present in
GitComparison wiki page.
>
> GitTorrent, The Movie
> http://www.advogato.org/article/994.html
This article is so full of bad information, exaggeration and
hyperbole, that it would be better to forget about it, and not put it
in the list.
> Peer-to-peer Protocol for Synchronizing of Git Repositories
> http://code.google.com/p/gittorrent/
Not news.
>
> Codebase - Git repository hosting with source browser, changesets,
> ticketing & deployment tracking.
> http://atechmedia.com/codebase
Not news. Besides it is present in GitHosting wiki page.
>
> Codebase Launches Git-based Project Management Service
> http://www.sitepoint.com/blogs/2008/12/04/codebase-launches-git-based-project-management-service/
Good link, perhaps should be added as 'see also' on GitHosting wiki
page, if it is not there already.
>
> The Git Community Book
> http://book.git-scm.com/index.html
http://book.git-scm.com/
Good link, present in GitDocumentation. But not news link.
>
> GitX: A git GUI specifically for Mac OS X
> http://gitx.frim.nl/index.html
On InterfacesFrontendsAndTools. But not a news link.
>
> Pushing and pulling with Git, part 1
> http://www.gnome.org/~federico/news-2008-11.html#pushing-and-pulling-with-git-1
Very good documentation, with nicely done graphic.
> $ cheat git
> http://cheat.errtheblog.com/s/git/
A bit big for a cheat _sheet_. perhaps it should be added to
GitCheatSheet (see example here for cheat _sheet_) and/or to
GitDocumentation wiki page.
> gh > hg
> http://github.com/blog/218-gh-hg
Seems to be a bit of curio. Not important enough to place it in
GitLinks, IMVHO.
>
> Easy Git External Dependency Management with Giternal
> http://www.rubyinside.com/giternal-easy-git-external-dependency-management-1322.html
Present on BlogPosts. Might be not as important as article about
Gitosis, because 1.) you can do this by hand, 2.) there are alternate
tools, like Piston, Giston -> Braid.
> Work with Git from Emacs
> http://xtalk.msk.su/~ott/en/writings/emacs-vcs/EmacsGit.html
Very good article, presenting various Emacs modules to work with
Git. Currently as far as I know not present on Git Wiki, but present
on 'Git' page on Emacs Wiki.
>
> It's Magit! A Emacs mode for Git.
> http://zagadka.vm.bytemark.co.uk/magit/
Probably should be added (as the rest of Emacs modes) to the
InterfacesFrontendsAndTools git wiki page.
>
> Improving my git workflow
> http://hoth.entp.com/2008/11/10/improving-my-git-workflow
This post is mainly about the same as
http://graysky.org/2008/12/git-branch-auto-tracking/
namely setting tracking information for _pushed_ branch, using single
command.
This could have been added to BlogPosts git wiki page.
>
> git-bz: Bugzilla subcommand for Git
> http://blog.fishsoup.net/2008/11/16/git-bz-bugzilla-subcommand-for-git/
Should be added in addition to git-bugzila to appropriate section at
InterfacesFrontendsAndTools wiki page. Good link.
>
> android.git.kernel.org Git
> http://android.git.kernel.org/
Is at GitProjects, but thanks for reminding about new server (new
URL). Not a news.
>
> GitSvnComparsion
> http://git.or.cz/gitwiki/GitSvnComparsion
No comment.
>
> Guides: Developing with Submodules
> http://github.com/guides/developing-with-submodules
Seems like a good reference. Probably should be added to both
GitSubmodules and BlogPosts pages at git wiki.
>
> A web-focused Git workflow
> http://joemaller.com/2008/11/25/a-web-focused-git-workflow/
I have't read it in detail, so I don't know if the workflow described
there makes sense. I would probably create some rule in Makefile and
use "make publish" or something, which would push the chages _and_
update page, or use post-update hook for that using some 'git-export'
equivalent.
Otherwise from first glance looks like good resource.
>
> Why we chose Git, a rebuttal
> http://www.unethicalblogger.com/posts/2008/11/why_we_chose_git_a_rebuttal
Nice reference I think, either for GitComparison or BlogPosts (in the
"Praise" section), or GitLinks.
> Git'n Your Shared Host On
> http://railstips.org/2008/11/24/gitn-your-shared-host-on
Not something that one cannot find in basic git documentation, but in
"Further Reading" it has nice selection of links.
>
> Git integration with Hudson and Trac
> http://www.unethicalblogger.com/posts/2008/11/git_integration_with_hudson_and_trac
Nice example of post-receive hook. Either for BlogPosts or
InterfacesFrontendsAndTools page.
> Everyday GIT With 20 Commands Or So
> http://www.kernel.org/pub/software/scm/git/docs/everyday.html
No comment.
>
> Hosting Git repositories, The Easy (and Secure) Way
> http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
Seminal reference, can be found at BlogPosts page on git wiki.
Very good link.
>
> 10 Reasons to Use Git for Research
> http://mendicantbug.com/2008/11/30/10-reasons-to-use-git-for-research/
Very nice article.
>
> [1] http://delicious.com/tag/git
I have a host of links to blog posts with git or distributed version
control info bookmarked...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [StGit] what happened to stg diff -r /{bottom|top}?
From: Dan Williams @ 2008-12-05 16:54 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
I noticed that with the latest StGit:
# stg diff -r /bottom
stg diff: /bottom: Unknown patch or revision name
Before I bisect to find where this disappeared, is there a different
syntax I should be using?
Thanks,
Dan
^ permalink raw reply
* Re: Git weekly news: 2008-49
From: Michael J Gruber @ 2008-12-05 17:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Felipe Contreras, git list
In-Reply-To: <m3d4g6ipah.fsf@localhost.localdomain>
Jakub Narebski venit, vidit, dixit 05.12.2008 17:02:
> "Felipe Contreras" <felipe.contreras@gmail.com> writes:
>
>> Hi there,
>>
>> I've been following the git tag at delicious.com[1] and there's quite
>> many interesting links, so I thought on gathering them so the git
>> community can enjoy them in one pack :)
>
> Nice work, although I think better alternative would be to weed those
> links out, and put them in appropriate sections (or subsections) on
> Git Wiki; to be more exact on http://git.or.cz/gitwiki/GitLinks
>
>> The blog post is here:
>> http://gitlog.wordpress.com/2008/12/05/git-weekely-news-2008-49/
>
> First, "Official git blog"? Official? There is nothing official about
> it. "Unofficial git blog", or "A git developer blog" (or "A git
> follower blog"; unfortunately names like gitter or gitster for git
> power user's, like TeXnician for TeX users, are taken by nicknames on
> #git, if I remember correctly). Only git maintainer (Junio Hamano)
> and git development community (the git mailing list) can decide that
> something is "official" resource.
>
> Second, I am a bit curious about 49 in "Git weekly news: 2008-49"
> name of the post.
Since it's "weekly" and this week is week number 49 in this year I have
a certain guess ;)
The blog has 2 entries only: That one and the wordpress welcome thingy...
>> Why Git is Better than X
>> http://whygitisbetterthanx.com/
>
> Quite good link from what I superficially checked, present in
> GitComparison wiki page.
Very nice indeed. Minor nitpick is comparing "hg add" to "git add" and
"hg commit" to "git commit -a", I'm discussing this with Scott already.
But very nice overall.
Cheers,
Michael
P.S.: For the record or in case anyone ?oogles this:
- compare "hg add" to "git add -N" and "hg commit" to "git commit -a",
which compares equivalent commands, or
- compare "hg add" to "git add" and "hg commit" to "git commit" (after
git add, but time "git commit" only), which compares similar sounding
commands; here, the sequence of commands is equivalent, just not the
individual ones
^ permalink raw reply
* Re: Git weekly news: 2008-49
From: Felipe Contreras @ 2008-12-05 17:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git list
In-Reply-To: <m3d4g6ipah.fsf@localhost.localdomain>
On Fri, Dec 5, 2008 at 6:02 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Felipe Contreras" <felipe.contreras@gmail.com> writes:
>
>> Hi there,
>>
>> I've been following the git tag at delicious.com[1] and there's quite
>> many interesting links, so I thought on gathering them so the git
>> community can enjoy them in one pack :)
>
> Nice work, although I think better alternative would be to weed those
> links out, and put them in appropriate sections (or subsections) on
> Git Wiki; to be more exact on http://git.or.cz/gitwiki/GitLinks
Right, but next week the links will be different. This time the links
where not really from this week, but they will be on the next
iterations.
Somebody could pick the relevant links and add them in the wiki.
>> The blog post is here:
>> http://gitlog.wordpress.com/2008/12/05/git-weekely-news-2008-49/
>
> First, "Official git blog"? Official? There is nothing official about
> it. "Unofficial git blog", or "A git developer blog" (or "A git
> follower blog"; unfortunately names like gitter or gitster for git
> power user's, like TeXnician for TeX users, are taken by nicknames on
> #git, if I remember correctly). Only git maintainer (Junio Hamano)
> and git development community (the git mailing list) can decide that
> something is "official" resource.
I asked in the mailing list and the only comment I got was: go ahead.
So yeah, that doesn't look like an "official" blessing, but it's not
bad either.
Anyway, my idea is that many gitsters will participate on this blog,
it's not my personal blog, I already have one.
Who wants an account?
> Second, I am a bit curious about 49 in "Git weekly news: 2008-49"
> name of the post.
It's the week number.
> Third, it is collection of links, not news[1].
True, "Git weekly links" sounds better?
> [1] It would be nice if somebody resurrected GitTraffic, offshot of
> now defunct KernelTraffic, or at least helped to write Git articles
> for KernelTrap (which currently is in a bit of hiatus).
>
>>
>> But here are the links anyway. The order is rather random.
>
> Moreover the _quality_ of those links is very random.
Exactly, I didn't choose them, that's what people have been tagging as
"git" in delicious.com. I'm subscribed to the RSS feed and saving the
ones that appear a lot.
In fact I don't like some of them, but that's what the "public" finds
interesting.
>> Why Git is Better than X
>> http://whygitisbetterthanx.com/
>
> Quite good link from what I superficially checked, present in
> GitComparison wiki page.
>
>>
>> GitTorrent, The Movie
>> http://www.advogato.org/article/994.html
>
> This article is so full of bad information, exaggeration and
> hyperbole, that it would be better to forget about it, and not put it
> in the list.
It's popular, and a lot of people find it interesting. /me shrugs
>> Peer-to-peer Protocol for Synchronizing of Git Repositories
>> http://code.google.com/p/gittorrent/
>
> Not news.
Right, but it is to many people.
<snip/>
Thanks for the comments, but gathering all these links is already
taking me more time that I wished.
> I have a host of links to blog posts with git or distributed version
> control info bookmarked...
My objective is to do this weekly. Maybe I'll put the links in a git
repo so people can see them before I make the post. Would you find
that useful?
As an example of possible links for next week:
My RubyGems development tools and workflow
http://drnicwilliams.com/2008/12/05/my-rubygems-development-tools-and-workflow/
Pushr, or the application will deploy itself
http://www.restafari.org/pushr-or-the-application-will-deploy-itself.html
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 2/4] git-am: propagate -C<n>, -p<n> options as well
From: Junio C Hamano @ 2008-12-05 19:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812051320170.7062@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 4 Dec 2008, Junio C Hamano wrote:
>
>> - echo " $ws" >"$dotest/whitespace"
>> + echo " $git_apply_opt" >"$dotest/apply_opt_extra"
>
>>From the other scripts, it appears we have sort of a convention to use
> dashes instead of underscores for file names (see e.g.
> $dotest/patch-merge-tmp-dir).
You are right. And there is no reason to call it "extra" either.
git-am.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git c/git-am.sh w/git-am.sh
index 13c02d6..4b157fe 100755
--- c/git-am.sh
+++ w/git-am.sh
@@ -250,7 +250,7 @@ else
# -s, -u, -k, --whitespace, -3, -C and -p flags are kept
# for the resuming session after a patch failure.
# -i can and must be given when resuming.
- echo " $git_apply_opt" >"$dotest/apply_opt_extra"
+ echo " $git_apply_opt" >"$dotest/apply-opt"
echo "$threeway" >"$dotest/threeway"
echo "$sign" >"$dotest/sign"
echo "$utf8" >"$dotest/utf8"
@@ -288,7 +288,7 @@ if test "$(cat "$dotest/threeway")" = t
then
threeway=t
fi
-git_apply_opt=$(cat "$dotest/apply_opt_extra")
+git_apply_opt=$(cat "$dotest/apply-opt")
if test "$(cat "$dotest/sign")" = t
then
SIGNOFF=`git var GIT_COMMITTER_IDENT | sed -e '
^ permalink raw reply related
* Re: Git weekly news: 2008-49
From: Jakub Narebski @ 2008-12-05 19:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git list
In-Reply-To: <94a0d4530812050946r5ea7ddb2v1d93d28ba679813b@mail.gmail.com>
On Fri, Dec 5, 2008 at 18:46, Felipe Contreras wrote:
> On Fri, Dec 5, 2008 at 6:02 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Felipe Contreras" <felipe.contreras@gmail.com> writes:
>>
>>> Hi there,
>>>
>>> I've been following the git tag at delicious.com[1]
By the way, from time to time I search blogs using either Technorati
searching for "http://git.or.cz", or Google Blog Search searching
either for "link:git.or.cz" or "Distributed Version Control".
BTW. funny thing that Google _Blog_ Search sometimes returns a host
of links to 'commit' view of gitweb... :-)
>>> and there's quite
>>> many interesting links, so I thought on gathering them so the git
>>> community can enjoy them in one pack :)
>>
>> Nice work, although I think better alternative would be to weed those
>> links out, and put them in appropriate sections (or subsections) on
>> Git Wiki; to be more exact on http://git.or.cz/gitwiki/GitLinks
>
> Right, but next week the links will be different. This time the links
> where not really from this week, but they will be on the next
> iterations.
>
> Somebody could pick the relevant links and add them in the wiki.
Well, if it is mainly as the place for "weekly links", it has some
purpose as it. And finding the links, perhaps with some minimal
reduction (removing duplicates and such), is much easier and takes
much less time than selecting "links of impact" for GitLinks page,
or selecting other page like BlogPosts, GitComparison, GitDocumentation
or InterfacesFrontendsAndTools git wiki page to add link to.
>>> The blog post is here:
>>> http://gitlog.wordpress.com/2008/12/05/git-weekely-news-2008-49/
>>
>> First, "Official git blog"? Official? There is nothing official about
>> it. "Unofficial git blog", or "A git developer blog" (or "A git
>> follower blog"; unfortunately names like gitter or gitster for git
>> power user's, like TeXnician for TeX users, are taken by nicknames on
>> #git, if I remember correctly). Only git maintainer (Junio Hamano)
>> and git development community (the git mailing list) can decide that
>> something is "official" resource.
>
> I asked in the mailing list and the only comment I got was: go ahead.
> So yeah, that doesn't look like an "official" blessing, but it's not
> bad either.
Ah, I didn't remember about it.
>
> Anyway, my idea is that many gitsters will participate on this blog,
> it's not my personal blog, I already have one.
>
> Who wants an account?
Still it looks more like "A git blog" than "Official git blog".
>> Third, it is collection of links, not news[1].
>
> True, "Git weekly links" sounds better?
Yes, IMHO it is better name.
>>>
>>> But here are the links anyway. The order is rather random.
>>
>> Moreover the _quality_ of those links is very random.
>
> Exactly, I didn't choose them, that's what people have been tagging as
> "git" in delicious.com. I'm subscribed to the RSS feed and saving the
> ones that appear a lot.
>
> In fact I don't like some of them, but that's what the "public" finds
> interesting.
Well, I think that people would treat those collection of links as
collection of links to _sensible_ contents. So at least put such links
in the "Controversial" (or something like that) section.
> <snip/>
>
> Thanks for the comments, but gathering all these links is already
> taking me more time that I wished.
>
>> I have a host of links to blog posts with git or distributed version
>> control info bookmarked...
>
> My objective is to do this weekly. Maybe I'll put the links in a git
> repo so people can see them before I make the post. Would you find
> that useful?
I don't think so.
.....................................................................
> As an example of possible links for next week:
> My RubyGems development tools and workflow
> http://drnicwilliams.com/2008/12/05/my-rubygems-development-tools-and-workflow/
How it is about git?
> Pushr, or the application will deploy itself
> http://www.restafari.org/pushr-or-the-application-will-deploy-itself.html
Nice article, extending on article about Git support for Capistrano.
Worth reading, I think, at least for Rubyists (RnR) here...
--
Jakub Narebski
Poland
^ permalink raw reply
* why not preserve file permissions?
From: jidanni @ 2008-12-05 20:08 UTC (permalink / raw)
To: git
Why not preserve permissions the way you find them, instead of just
using 644 and 755? It certainly couldn't be more complicated than what
you are doing now, and that way one could do things like use git to
update system administration files across a sneakernet containing e.g.,
# dlocate -lsconf exim4-config|sed 's/ .*//'|sort -u
-rw-r-----
-rw-r--r--
-rwxr-xr-x
> git was made for tracking source code, not 640 files.
On the sneakernet no public patches would be sent, and the
administrator would remember to make the sensitive .git directories
700. And sure, git should enforce umask or no set-uid or whatever when
doing a checkout etc. The deluxe edition of git could even print a
warning: "you are trying to track a 640 file but your .git permissions
are less restrictive." However I recommend no premium or deluxe
editions for now.
> Patches welcome.
Trust me, you don't want "grandpa who forgot the parking brake"
anywhere near your code.
^ permalink raw reply
* Re: git-gui: Warn when username and e-mail address is unconfigured?
From: Jeremy Ramer @ 2008-12-05 20:18 UTC (permalink / raw)
To: Alexander Gavrilov
Cc: Junio C Hamano, spearce, sverre, Peter Krefting, Git Mailing List
In-Reply-To: <bb6f213e0812050301t2f18061epfeff7bc74ee6f28a@mail.gmail.com>
On Fri, Dec 5, 2008 at 4:01 AM, Alexander Gavrilov <angavrilov@gmail.com> wrote:
> On Fri, Dec 5, 2008 at 2:58 AM, Jeremy Ramer <jdramer@gmail.com> wrote:
>> Yes, that does appear to be the message I get, with the following
>> environment variables:
>> - GIT_AUTHOR_EMAIL
>> - GIT_COMMITTER_NAME
>> - GIT_COMMITER_EMAIL
>> - GIT_AUTHOR_NAME
>>
>> Now that I look closer I see that I am setting these in my .bashrc
>> file. When I first started using git a year ago I was given the
>> impression that these were needed. But I see that that is no longer
>> the case since I use the config:
>>
>> git config --global user.name "Your Name"
>> git config --global user.email "you@example.com"
>>
>> Removing them from my .bashrc removes the warning. In hindsight the
>> warning should have clued me in, but I've been seeing that message
>> since I first started using git on Cygwin so I figured it was a cygwin
>> issue that I couldn't do anything about.
>>
>
> I wonder if what the warning says is still true. It's 2 years since
> it was added, so the issue might have been fixed.
>
> If you run "GIT_AUTHOR_NAME=foobar git gui", and make a commit,
> does it set the author name to 'foobar'?
I ran
export GIT_AUTHOR_NAME="foobar git gui"
and then made a commit with git gui and it did not set the author name
to foobar. It used my global config name.
>
> Alexander
>
^ permalink raw reply
* Re: Git weekly news: 2008-49
From: Junio C Hamano @ 2008-12-05 20:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Felipe Contreras, git list
In-Reply-To: <m3d4g6ipah.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> [1] It would be nice if somebody resurrected GitTraffic, offshot of
> now defunct KernelTraffic, or at least helped to write Git articles
> for KernelTrap (which currently is in a bit of hiatus).
While I 100% agree with you that "Git Traffic" was a terrific attempt, I
do not think expecting or asking Felipe to duplicate it is realistic.
I searched for Felipe's proposal on the list archive, and its title was
"Planet Git". That shows why the focus could be different.
"Git Traffic" was great because it attempted to directly address the issue
that the traffic on the mailing list was simply too high (and still is) to
follow for casual observers. It did so by giving a comprehensive summary
of what important topics were discussed recently on the list from the
viewpoint of one dedicated person who followed many, perhaps not all,
important threads carefully, who very well knew what was going on, and who
had a good taste on what is important and what is not.
But "Planet Git" is quite different from "Git Traffic". For the latter,
somebody needs to do a real work, continuously. But more importantly, I
think they would serve different purposes. A "Planet" could be valuable
to have with or without "Traffic".
I think what was presented as "Official Git blog", however, is also
different from what people expect a "Planet" to be. I do not think it is
unreasonable to expect or ask Felipe to improve on making his service more
"Planet" like.
A "Planet", as I understand it, is an aggregator of (selected) people's
blogs, and even though I am not currently involved in any Planet nor
follow any Planet myself, I can imagine that it could be a valuable
resource to have a "Planet Git" that subscribes to and aggregates what
influential figures write on git in their blogs.
Felipe's page currently is a random collection of links, and other than
their titles, there is no indication for readers to judge which link is
worth clicking and reading. It does not even mention who wrote each
piece, let alone editorial comments (e.g. "This is worth reading") like
you added. When you click one of them in order to read it, you leave the
"list of links". That is not how navigation (the click and thought flow
for the readers) usually works in a "Planet".
If this wants to be a "Planet Git", I do not think there is any need for
Felipe to ask "who wants accounts?" It would go the other way. Instead,
Felipe, as the coordinator of the "Planet", would find people who writes
noteworthy things on git on their own blogs, would ask for permission to
slurp and aggregate what they wrote, and produce the page by aggregating
their writings. That would make a good "Planet Git".
Expecting people to apply for an account and write for that page would not
fly. As Felipe said himself, many people already have their own blog.
Having said all that, I am not sure "Planet" would work for the git
community as well as it would for others. I do not know of many core-ish
people write on git on their blogs (and I know at least two core-ish
people who flatly say "blogging is a waste of time").
^ permalink raw reply
* Re: Git weekly news: 2008-49
From: Nanako Shiraishi @ 2008-12-05 21:12 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jakub Narebski, git list
In-Reply-To: <94a0d4530812050946r5ea7ddb2v1d93d28ba679813b@mail.gmail.com>
Quoting "Felipe Contreras" <felipe.contreras@gmail.com>:
> On Fri, Dec 5, 2008 at 6:02 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Felipe Contreras" <felipe.contreras@gmail.com> writes:
>> ...
>> First, "Official git blog"? Official? There is nothing official about
>> it. "Unofficial git blog", or "A git developer blog" (or "A git
>> follower blog"; unfortunately names like gitter or gitster for git
>> power user's, like TeXnician for TeX users, are taken by nicknames on
>> #git, if I remember correctly). Only git maintainer (Junio Hamano)
>> and git development community (the git mailing list) can decide that
>> something is "official" resource.
>
> I asked in the mailing list and the only comment I got was: go ahead.
> So yeah, that doesn't look like an "official" blessing, but it's not
> bad either.
According to "http://marc.info/?t=121985955200002&r=1&w=2", you mentioned "Planet Git" and only one response other than yours on the topic was somebody offering server hosting space, so no, sorry, I do not see any evidence that your post produced any positive or negative feedback.
But I think this, if done right, is a great idea and everybody will welcome "Planet Git" as the "official weblog aggregator". I think a true "Git News" that is written by somebody to summarize the happenings in the Git land in a coherent voice would be much more preferable, but that takes real work (which you may or may not be interested in), and aggregated blog would be the best thing we can have without too much effort.
^ permalink raw reply
* Re: Git weekly news: 2008-49
From: Santi Béjar @ 2008-12-05 21:44 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jakub Narebski, git list
In-Reply-To: <94a0d4530812050946r5ea7ddb2v1d93d28ba679813b@mail.gmail.com>
2008/12/5 Felipe Contreras <felipe.contreras@gmail.com>:
> On Fri, Dec 5, 2008 at 6:02 PM, Jakub Narebski <jnareb@gmail.com> wrote:
[...]
>>> But here are the links anyway. The order is rather random.
>>
>> Moreover the _quality_ of those links is very random.
>
> Exactly, I didn't choose them, that's what people have been tagging as
> "git" in delicious.com. I'm subscribed to the RSS feed and saving the
> ones that appear a lot.
>
> In fact I don't like some of them, but that's what the "public" finds
> interesting.
So I don't see the value of such a list. You can go to delicious and
get it. Another thing that could be great is filtering this list to
those that pass a certain criteria (mainly quality, up to date, ...)
and present it in an attractive way, with summaries, categorized by
type (trick, tutorial, comparison,...), ...
Just my 2cents
Santi
^ permalink raw reply
* Re: Git weekly news: 2008-49
From: Felipe Contreras @ 2008-12-05 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git list
In-Reply-To: <7v3ah2z6jh.fsf@gitster.siamese.dyndns.org>
On Fri, Dec 5, 2008 at 10:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> [1] It would be nice if somebody resurrected GitTraffic, offshot of
>> now defunct KernelTraffic, or at least helped to write Git articles
>> for KernelTrap (which currently is in a bit of hiatus).
>
> While I 100% agree with you that "Git Traffic" was a terrific attempt, I
> do not think expecting or asking Felipe to duplicate it is realistic.
>
> I searched for Felipe's proposal on the list archive, and its title was
> "Planet Git". That shows why the focus could be different.
>
> "Git Traffic" was great because it attempted to directly address the issue
> that the traffic on the mailing list was simply too high (and still is) to
> follow for casual observers. It did so by giving a comprehensive summary
> of what important topics were discussed recently on the list from the
> viewpoint of one dedicated person who followed many, perhaps not all,
> important threads carefully, who very well knew what was going on, and who
> had a good taste on what is important and what is not.
>
> But "Planet Git" is quite different from "Git Traffic". For the latter,
> somebody needs to do a real work, continuously. But more importantly, I
> think they would serve different purposes. A "Planet" could be valuable
> to have with or without "Traffic".
>
> I think what was presented as "Official Git blog", however, is also
> different from what people expect a "Planet" to be. I do not think it is
> unreasonable to expect or ask Felipe to improve on making his service more
> "Planet" like.
>
> A "Planet", as I understand it, is an aggregator of (selected) people's
> blogs, and even though I am not currently involved in any Planet nor
> follow any Planet myself, I can imagine that it could be a valuable
> resource to have a "Planet Git" that subscribes to and aggregates what
> influential figures write on git in their blogs.
Yes, a planet is an aggregation of blogs. I've been involved in some
planets and they are not exactly great.
One disadvantage of planets is usually there's no control of the topic
of the posts. For example in planet GNOME there's some people that
mostly blog only about GNOME, but other people blog about everything,
including what they did in the morning, ate at lunch, and discussed at
the water cooler. Some people have their blogs properly categorized
and the right feeds go to the right planets, but they are the
minority.
Planets are great if you want people to "get intimate" with the
community, probably a small one. Not for git IMHO.
There's a single "planet" I know that doesn't follow the norm;
beagleboard news[1]. There one guy basically uses Google Reader to
share whatever he thinks is somehow interesting for the beagleboard
community. The advantage is that the feed is much more focused than a
planet, but still there's a lot of bias in the links, which sometimes
have nothing to do with the beagleboard.
> Felipe's page currently is a random collection of links, and other than
> their titles, there is no indication for readers to judge which link is
> worth clicking and reading. It does not even mention who wrote each
> piece, let alone editorial comments (e.g. "This is worth reading") like
> you added. When you click one of them in order to read it, you leave the
> "list of links". That is not how navigation (the click and thought flow
> for the readers) usually works in a "Planet".
Lets remember that this is the first try, and there's many more links
that what would fit in any given week, but I just didn't want to leave
them out.
Maybe for the next weeks I'll do a bit of explanation about each link, lets see.
> If this wants to be a "Planet Git", I do not think there is any need for
> Felipe to ask "who wants accounts?" It would go the other way. Instead,
> Felipe, as the coordinator of the "Planet", would find people who writes
> noteworthy things on git on their own blogs, would ask for permission to
> slurp and aggregate what they wrote, and produce the page by aggregating
> their writings. That would make a good "Planet Git".
>
> Expecting people to apply for an account and write for that page would not
> fly. As Felipe said himself, many people already have their own blog.
>
> Having said all that, I am not sure "Planet" would work for the git
> community as well as it would for others. I do not know of many core-ish
> people write on git on their blogs (and I know at least two core-ish
> people who flatly say "blogging is a waste of time").
I actually propose two things:
a) planet git
This would be a collection of blogs, probably not developers, which
might consider blogging to be a wast of time, but git enthusiasts. I
don't expect the list of dedicated bloggers to be that big, hence my
second proposal:
b) git blog
A blog can be shared by a bunch of people, much line online news
sites. Junio could write a post once for each release, for example,
without having to setup his own blog, maybe somebody else can
copy-paste "What's cooking in git.git", or any kind of semi-official
announcement.
And I'm sure there will be one or two developers who wouldn't mind
sharing their frustrations and/or visions.
These two are not exclusive, of course.
For a) I need a server (there's a few already offered), setup the
planet software, and people to send me their RSS feeds, which
hopefully are categorized for git-specific posts. I don't have much
faith on this, nor interest.
For b) I just need interested people to send me their emails.
[1] http://beagleboard.org/news
--
Felipe Contreras
^ 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