* Re: Stitching together two split segments from svn
From: Liam Healy @ 2008-07-25 2:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3ljzqvo6i.fsf@localhost.localdomain>
Jakub,
Thanks for the advice -- this did exactly what I wanted.
For anyone else wanting to do this: one thing that threw me for a
while was that .git/info/grafts does not accept an abbreviated SHA,
the full 40 hex digits is needed. I would see "bad graft data" from
gitk with no other explanation. There is very little documentation
that I could find on the grafts file; the best I could find was in the
man page for git-filter branch,
http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html.
Liam
On Thu, Jul 24, 2008 at 7:48 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Liam Healy" <lnp@healy.washington.dc.us> writes:
>
>> I have a project whose history is stored in two separate svn
>> repositories. The first repository I kept privately during initial
>> development, the second started when I posted it publicly and does not
>> have the history of the first. I am trying to reunite them under git.
>> The development of the first was linear, so after using git svn, the
>> history looks like:
>>
>> a - b - ... - c - d = HEAD (old repository)
>>
>> and the second has one branch "ffa":
>>
>> (new repository)
>> T - d - e - ... - f - g - h - ... - j master
>> \
>> k - l - .... - m ffa
>>
>> Note that T is the "trunk" initial commit on the svn repo that has no
>> files. The second commit d is identical to the HEAD of old, as
>> verified by git diff.
>> However, when I remote add these two into a single repository, they
>> show up as two detached chains, with no connection between them. I
>> thought git rebase would reconnect them. However, when I do that on
>> each branch (master and ffa), I get the following:
>>
>> a - b - ... - c - d - e - ... - f - g - h - ... - j master
>> \
>> e - ... -f - g - k - l - .... - m ffa
>>
>> instead of what I would like
>>
>> a - b - ... - c - d - e - ... - f - g - h - ... - j master
>> \
>> k - l - .... - m ffa
>>
>> That is to say, those commits from the new repository that have a
>> common history for the two branches are duplicated. The commits are
>> listed separately and have different SHA IDs, but they are clearly the
>> same commits (same comments, same svn version number). Is there any
>> way to do what I want? Really, all I want to do is change the parent
>> of "e" to be the HEAD of the old repository.
>
> If this is initial import, and not published anywhere, the simplest (I
> think) solution would be to use grafts file (.git/info/grafts) to
> change parent of 'k' from 'g' in ffa to 'g' in master, by adding the
> line with:
>
> <sha1 of 'k'> <sha1 of 'g' on master>
>
> to .git/info/grafts. Then examine history if everything is now all
> right (for example using gitk), and if everything is O.K. run
> git-filter-branch.
>
> See documentation for details.
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
^ permalink raw reply
* [PATCH 1/2 resend] bisect: test merge base if good rev is not an ancestor of bad rev
From: Christian Couder @ 2008-07-25 3:34 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: Michael Haggerty, Jeff King, git
Before this patch, "git bisect", when it was given some good revs that
are not ancestor of the bad rev, didn't check if the merge bases were
good. "git bisect" just supposed that the user knew what he was doing,
and that, when he said the revs were good, he knew that it meant that
all the revs in the history leading to the good revs were also
considered good.
But in pratice, the user may not know that a good rev is not an
ancestor of the bad rev, or he may not know/remember that all revs
leading to the good rev will be considered good. So he may give a good
rev that is a sibling, instead of an ancestor, of the bad rev, when in
fact there can be one rev becoming good in the branch of the good rev
(because the bug was already fixed there for example) instead of one
rev becoming bad in the branch of the bad rev.
For example, if there is the following history:
A-B-C-D
\E-F
and we launch "git bisect start D F" then only C and D would have been
considered as possible first bad commit before this patch. This may be
wrong because A, B and E may be bad too if the bug exists everywhere
except in F that fixes it.
The purpose of this patch is to detect when "git bisect" is passed
some good revs that are not ancestor of the bad rev, and then to first
ask the user to test the merge bases between the good and bad revs.
If the merge bases are good then all is fine, we can continue
bisecting. Otherwise, if one merge base is bad, it means that the
assumption that all revs leading to the good one are good too is
wrong and we error out. In the case where one merge base is skipped we
issue a warning and then continue bisecting anyway.
These checks will also catch the case where good and bad have been
mistaken. This means that we can remove the check that was done latter
on the output of "git rev-list --bisect-vars".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 134 +++++++++++++++++++++++++++++++++++--------
t/t6030-bisect-porcelain.sh | 90 +++++++++++++++++++++++++++++
2 files changed, 199 insertions(+), 25 deletions(-)
This is a resend series with the following changes since the previous
series:
- "for ...; do" has been replaced with "for" and "do" on 2 different
lines (in patch 1/2)
- a line with "unset GIT_TRACE" has been added to "t/t6030" (in patch
2/2)
diff --git a/git-bisect.sh b/git-bisect.sh
index 3cac20d..dfe36e5 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -242,33 +242,18 @@ bisect_auto_next() {
bisect_next_check && bisect_next || :
}
-eval_rev_list() {
- _eval="$1"
-
- eval $_eval
- res=$?
-
- if [ $res -ne 0 ]; then
- echo >&2 "'git rev-list --bisect-vars' failed:"
- echo >&2 "maybe you mistake good and bad revs?"
- exit $res
- fi
-
- return $res
-}
-
filter_skipped() {
_eval="$1"
_skip="$2"
if [ -z "$_skip" ]; then
- eval_rev_list "$_eval"
+ eval "$_eval"
return
fi
# Let's parse the output of:
# "git rev-list --bisect-vars --bisect-all ..."
- eval_rev_list "$_eval" | while read hash line
+ eval "$_eval" | while read hash line
do
case "$VARS,$FOUND,$TRIED,$hash" in
# We display some vars.
@@ -331,20 +316,120 @@ exit_if_skipped_commits () {
fi
}
+checkout() {
+ _rev="$1"
+ _msg="$2"
+ echo "Bisecting: $_msg"
+ git checkout -q "$_rev" || exit
+ git show-branch "$_rev"
+}
+
+is_among() {
+ _rev="$1"
+ _list="$2"
+ case "$_list" in *$_rev*) return 0 ;; esac
+ return 1
+}
+
+is_merge_base_ok() {
+ grep "^$1 $2 ok$" "$GIT_DIR/BISECT_MERGE_BASES" >/dev/null 2>&1
+}
+
+mark_merge_base_ok() {
+ echo "$1 $2 ok" >> "$GIT_DIR/BISECT_MERGE_BASES"
+}
+
+is_testing_merge_base() {
+ grep "^testing $1$" "$GIT_DIR/BISECT_MERGE_BASES" >/dev/null 2>&1
+}
+
+mark_testing_merge_base() {
+ echo "testing $1" >> "$GIT_DIR/BISECT_MERGE_BASES"
+}
+
+handle_bad_merge_base() {
+ _badmb="$1"
+ _g="$2"
+ if is_testing_merge_base "$_badmb"; then
+ cat >&2 <<EOF
+The merge base $_badmb is bad.
+This means the bug has been fixed between $_badmb and $_g.
+EOF
+ exit 3
+ else
+ cat >&2 <<EOF
+Some good revs are not ancestor of the bad rev.
+git bisect cannot work properly in this case.
+Maybe you mistake good and bad revs?
+EOF
+ exit 1
+ fi
+}
+
+handle_skipped_merge_base() {
+ _bad="$1"
+ _g="$2"
+ _mb="$3"
+ cat >&2 <<EOF
+Warning: the merge base between $_bad and $_g must be skipped.
+So we cannot be sure the first bad commit is between $_mb and $_bad.
+We continue anyway.
+EOF
+}
+
+check_merge_bases() {
+ _bad="$1"
+ _good="$2"
+ _skip="$3"
+ for _g in $_good
+ do
+ is_merge_base_ok "$_bad" "$_g" && continue
+ for _mb in $(git merge-base --all $_g $_bad)
+ do
+ if test "$_mb" = "$_g" || is_among "$_mb" "$_good"; then
+ continue
+ elif test "$_mb" = "$_bad"; then
+ handle_bad_merge_base "$_bad" "$_g"
+ elif is_among "$_mb" "$_skip"; then
+ handle_skipped_merge_base "$_bad" "$_g" "_mb"
+ else
+ mark_testing_merge_base "$_mb"
+ checkout "$_mb" "a merge base must be tested"
+ checkout_done=1
+ return
+ fi
+ done
+ mark_merge_base_ok "$_bad" "$_g"
+ done
+}
+
+check_good_are_ancestors_of_bad() {
+ _bad="$1"
+ _good=$(echo $2 | sed -e 's/\^//g')
+ _skip="$3"
+ _side=$(git rev-list $_good ^$_bad)
+ test -n "$_side" && check_merge_bases "$_bad" "$_good" "$_skip"
+}
+
bisect_next() {
case "$#" in 0) ;; *) usage ;; esac
bisect_autostart
bisect_next_check good
+ # Get bad, good and skipped revs
+ bad=$(git rev-parse --verify refs/bisect/bad) &&
+ good=$(git for-each-ref --format='^%(objectname)' \
+ "refs/bisect/good-*" | tr '\012' ' ') &&
skip=$(git for-each-ref --format='%(objectname)' \
- "refs/bisect/skip-*" | tr '\012' ' ') || exit
+ "refs/bisect/skip-*" | tr '\012' ' ') &&
+ # Maybe some merge bases must be tested first
+ check_good_are_ancestors_of_bad "$bad" "$good" "$skip" || exit
+ test "$checkout_done" -eq "1" && checkout_done='' && return
+
+ # Get bisection information
BISECT_OPT=''
test -n "$skip" && BISECT_OPT='--bisect-all'
-
- bad=$(git rev-parse --verify refs/bisect/bad) &&
- good=$(git for-each-ref --format='^%(objectname)' \
- "refs/bisect/good-*" | tr '\012' ' ') &&
eval="git rev-list --bisect-vars $BISECT_OPT $good $bad --" &&
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
eval=$(filter_skipped "$eval" "$skip") &&
@@ -365,9 +450,7 @@ bisect_next() {
# commit is also a "skip" commit (see above).
exit_if_skipped_commits "$bisect_rev"
- echo "Bisecting: $bisect_nr revisions left to test after this"
- git checkout -q "$bisect_rev" || exit
- git show-branch "$bisect_rev"
+ checkout "$bisect_rev" "$bisect_nr revisions left to test after this"
}
bisect_visualize() {
@@ -414,6 +497,7 @@ bisect_clean_state() {
do
git update-ref -d $ref $hash || exit
done
+ rm -f "$GIT_DIR/BISECT_MERGE_BASES" &&
rm -f "$GIT_DIR/BISECT_LOG" &&
rm -f "$GIT_DIR/BISECT_NAMES" &&
rm -f "$GIT_DIR/BISECT_RUN" &&
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 0626544..503229b 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -350,6 +350,96 @@ test_expect_success 'bisect does not create a "bisect" branch' '
git branch -D bisect
'
+# This creates a "side" branch to test "siblings" cases.
+#
+# H1-H2-H3-H4-H5-H6-H7 <--other
+# \
+# S5-S6-S7 <--side
+#
+test_expect_success 'side branch creation' '
+ git bisect reset &&
+ git checkout -b side $HASH4 &&
+ add_line_into_file "5(side): first line on a side branch" hello2 &&
+ SIDE_HASH5=$(git rev-parse --verify HEAD) &&
+ add_line_into_file "6(side): second line on a side branch" hello2 &&
+ SIDE_HASH6=$(git rev-parse --verify HEAD) &&
+ add_line_into_file "7(side): third line on a side branch" hello2 &&
+ SIDE_HASH7=$(git rev-parse --verify HEAD)
+'
+
+test_expect_success 'good merge base when good and bad are siblings' '
+ git bisect start "$HASH7" "$SIDE_HASH7" > my_bisect_log.txt &&
+ grep "merge base must be tested" my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ git bisect good > my_bisect_log.txt &&
+ test_must_fail grep "merge base must be tested" my_bisect_log.txt &&
+ grep $HASH6 my_bisect_log.txt &&
+ git bisect reset
+'
+test_expect_success 'skipped merge base when good and bad are siblings' '
+ git bisect start "$SIDE_HASH7" "$HASH7" > my_bisect_log.txt &&
+ grep "merge base must be tested" my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ git bisect skip > my_bisect_log.txt 2>&1 &&
+ grep "Warning" my_bisect_log.txt &&
+ grep $SIDE_HASH6 my_bisect_log.txt &&
+ git bisect reset
+'
+
+test_expect_success 'bad merge base when good and bad are siblings' '
+ git bisect start "$HASH7" HEAD > my_bisect_log.txt &&
+ grep "merge base must be tested" my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ test_must_fail git bisect bad > my_bisect_log.txt 2>&1 &&
+ grep "merge base $HASH4 is bad" my_bisect_log.txt &&
+ grep "fixed between $HASH4 and $SIDE_HASH7" my_bisect_log.txt &&
+ git bisect reset
+'
+
+# This creates a few more commits (A and B) to test "siblings" cases
+# when a good and a bad rev have many merge bases.
+#
+# We should have the following:
+#
+# H1-H2-H3-H4-H5-H6-H7
+# \ \ \
+# S5-A \
+# \ \
+# S6-S7----B
+#
+# And there A and B have 2 merge bases (S5 and H5) that should be
+# reported by "git merge-base --all A B".
+#
+test_expect_success 'many merge bases creation' '
+ git checkout "$SIDE_HASH5" &&
+ git merge -m "merge HASH5 and SIDE_HASH5" "$HASH5" &&
+ A_HASH=$(git rev-parse --verify HEAD) &&
+ git checkout side &&
+ git merge -m "merge HASH7 and SIDE_HASH7" "$HASH7" &&
+ B_HASH=$(git rev-parse --verify HEAD) &&
+ git merge-base --all "$A_HASH" "$B_HASH" > merge_bases.txt &&
+ test $(wc -l < merge_bases.txt) = "2" &&
+ grep "$HASH5" merge_bases.txt &&
+ grep "$SIDE_HASH5" merge_bases.txt
+'
+
+test_expect_success 'good merge bases when good and bad are siblings' '
+ git bisect start "$B_HASH" "$A_HASH" > my_bisect_log.txt &&
+ grep "merge base must be tested" my_bisect_log.txt &&
+ git bisect good > my_bisect_log2.txt &&
+ grep "merge base must be tested" my_bisect_log2.txt &&
+ {
+ {
+ grep "$SIDE_HASH5" my_bisect_log.txt &&
+ grep "$HASH5" my_bisect_log2.txt
+ } || {
+ grep "$SIDE_HASH5" my_bisect_log2.txt &&
+ grep "$HASH5" my_bisect_log.txt
+ }
+ } &&
+ git bisect reset
+'
+
#
#
test_done
--
1.6.0.rc0.2.gf038
^ permalink raw reply related
* [PATCH 2/2 resend] bisect: only check merge bases when needed
From: Christian Couder @ 2008-07-25 3:36 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: Michael Haggerty, Jeff King, git
When one good revision is not an ancestor of the bad revision, the
merge bases between the good and the bad revision should be checked
to make sure that they are also good revisions.
Some previous patches take care of that, but they may check the
merge bases more often than really needed. In fact the previous
patches did not try to optimize this as much as possible because
it is not so simple. So this is the purpose of this patch.
One may think that when all the merge bases have been checked then
we can save a flag, so that we don't need to check the merge bases
again during the bisect process.
The problem is that the user may choose to checkout and test
something completely different from what the bisect process
suggested. In this case we have to check the merge bases again,
because there may be new merge bases relevant to the bisect
process.
That's why, in this patch, when we detect that the user tested
something else than what the bisect process suggested, we remove
the flag that says that we don't need to check the merge bases
again.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 47 +++++++++++++++++++++++++++++++-----------
t/t6030-bisect-porcelain.sh | 24 ++++++++++++++++++++++
2 files changed, 58 insertions(+), 13 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index dfe36e5..7093dd3 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -172,6 +172,25 @@ bisect_write() {
test -n "$nolog" || echo "git bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
}
+is_expected_rev() {
+ test -f "$GIT_DIR/BISECT_EXPECTED_REV" &&
+ test "$1" = $(cat "$GIT_DIR/BISECT_EXPECTED_REV")
+}
+
+mark_expected_rev() {
+ echo "$1" > "$GIT_DIR/BISECT_EXPECTED_REV"
+}
+
+check_expected_revs() {
+ for _rev in "$@"; do
+ if ! is_expected_rev "$_rev"; then
+ rm -f "$GIT_DIR/BISECT_ANCESTORS_OK"
+ rm -f "$GIT_DIR/BISECT_EXPECTED_REV"
+ return
+ fi
+ done
+}
+
bisect_state() {
bisect_autostart
state=$1
@@ -181,7 +200,8 @@ bisect_state() {
1,bad|1,good|1,skip)
rev=$(git rev-parse --verify HEAD) ||
die "Bad rev input: HEAD"
- bisect_write "$state" "$rev" ;;
+ bisect_write "$state" "$rev"
+ check_expected_revs "$rev" ;;
2,bad|*,good|*,skip)
shift
eval=''
@@ -191,7 +211,8 @@ bisect_state() {
die "Bad rev input: $rev"
eval="$eval bisect_write '$state' '$sha'; "
done
- eval "$eval" ;;
+ eval "$eval"
+ check_expected_revs "$@" ;;
*,bad)
die "'git bisect bad' can take only one argument." ;;
*)
@@ -320,6 +341,7 @@ checkout() {
_rev="$1"
_msg="$2"
echo "Bisecting: $_msg"
+ mark_expected_rev "$_rev"
git checkout -q "$_rev" || exit
git show-branch "$_rev"
}
@@ -339,18 +361,10 @@ mark_merge_base_ok() {
echo "$1 $2 ok" >> "$GIT_DIR/BISECT_MERGE_BASES"
}
-is_testing_merge_base() {
- grep "^testing $1$" "$GIT_DIR/BISECT_MERGE_BASES" >/dev/null 2>&1
-}
-
-mark_testing_merge_base() {
- echo "testing $1" >> "$GIT_DIR/BISECT_MERGE_BASES"
-}
-
handle_bad_merge_base() {
_badmb="$1"
_g="$2"
- if is_testing_merge_base "$_badmb"; then
+ if is_expected_rev "$_badmb"; then
cat >&2 <<EOF
The merge base $_badmb is bad.
This means the bug has been fixed between $_badmb and $_g.
@@ -393,7 +407,6 @@ check_merge_bases() {
elif is_among "$_mb" "$_skip"; then
handle_skipped_merge_base "$_bad" "$_g" "_mb"
else
- mark_testing_merge_base "$_mb"
checkout "$_mb" "a merge base must be tested"
checkout_done=1
return
@@ -404,11 +417,17 @@ check_merge_bases() {
}
check_good_are_ancestors_of_bad() {
+ test -f "$GIT_DIR/BISECT_ANCESTORS_OK" &&
+ return
_bad="$1"
_good=$(echo $2 | sed -e 's/\^//g')
_skip="$3"
_side=$(git rev-list $_good ^$_bad)
- test -n "$_side" && check_merge_bases "$_bad" "$_good" "$_skip"
+ if test -n "$_side"; then
+ check_merge_bases "$_bad" "$_good" "$_skip" || return
+ test "$checkout_done" -eq "1" && return
+ fi
+ : > "$GIT_DIR/BISECT_ANCESTORS_OK"
}
bisect_next() {
@@ -498,6 +517,8 @@ bisect_clean_state() {
git update-ref -d $ref $hash || exit
done
rm -f "$GIT_DIR/BISECT_MERGE_BASES" &&
+ rm -f "$GIT_DIR/BISECT_EXPECTED_REV" &&
+ rm -f "$GIT_DIR/BISECT_ANCESTORS_OK" &&
rm -f "$GIT_DIR/BISECT_LOG" &&
rm -f "$GIT_DIR/BISECT_NAMES" &&
rm -f "$GIT_DIR/BISECT_RUN" &&
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 503229b..04963b9 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -440,6 +440,30 @@ test_expect_success 'good merge bases when good and bad are siblings' '
git bisect reset
'
+check_trace() {
+ grep "$1" "$GIT_TRACE" | grep "\^$2" | grep "$3" >/dev/null
+}
+
+test_expect_success 'optimized merge base checks' '
+ GIT_TRACE="$(pwd)/trace.log" &&
+ export GIT_TRACE &&
+ git bisect start "$HASH7" "$SIDE_HASH7" > my_bisect_log.txt &&
+ grep "merge base must be tested" my_bisect_log.txt &&
+ grep "$HASH4" my_bisect_log.txt &&
+ check_trace "rev-list" "$HASH7" "$SIDE_HASH7" &&
+ git bisect good > my_bisect_log2.txt &&
+ test -f ".git/BISECT_ANCESTORS_OK" &&
+ test "$HASH6" = $(git rev-parse --verify HEAD) &&
+ : > "$GIT_TRACE" &&
+ git bisect bad > my_bisect_log3.txt &&
+ test_must_fail check_trace "rev-list" "$HASH6" "$SIDE_HASH7" &&
+ git bisect good "$A_HASH" > my_bisect_log4.txt &&
+ grep "merge base must be tested" my_bisect_log4.txt &&
+ test_must_fail test -f ".git/BISECT_ANCESTORS_OK" &&
+ check_trace "rev-list" "$HASH6" "$A_HASH" &&
+ unset GIT_TRACE
+'
+
#
#
test_done
--
1.6.0.rc0.2.gf038
^ permalink raw reply related
* Re: [PATCH 9/9] Windows: Do not compile git-shell
From: Steffen Prohaska @ 2008-07-25 4:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Johannes Sixt
In-Reply-To: <1216667998-8879-10-git-send-email-johannes.sixt@telecom.at>
Junio,
Do you plan to apply this patch anytime soon? Currently,
building on MSYS fails when it comes to compiling git-shell.
I am waiting for this patch to either pop up in your or
Hannes' master. I need this patch before I can push new
4msysgit branches (next, devel). Should I apply it directly
in 4msysgit?
This patch is not related to the rest of the exec-path series.
Steffen
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: Junio C Hamano @ 2008-07-25 4:44 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Peter Valdemar Mørch (Lists), git
In-Reply-To: <20080724172912.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting "Peter Valdemar Mrch (Lists)" <4ux6as402@sneakemail.com>:
>
>> The '-trailing-space' syntax to disable the trailing-space setting is
>> not obvious and not documented as far as I can see. I would have
>> assumed a value of '' would disable it.
>>
>> Is there a documentation bug here? If so, I suggest this patch. I
>> didn't find anywhere else where the '-setting' syntax was used to
>> disable something.
>
> Doesn't gitattributes(5) describe the overall syntax in detail?
Yes, but as Peter says in his reply to you, it only talks about [-!]name
syntax to force the variable to unset (with '-' prefix) and to revert the
variable to the unspecified state (with '!' prefix).
Various "values" given to the whitespace attribute actually act as if they
are sub-variables and obey the similar "[-]name" rule, but (1) that is
left unsaid, and (2) in that context '!' does not make sense so only '-'
has any meaning. We would certainly need to clarify that.
So I think Peter's patch is going in the right direction.
^ permalink raw reply
* Re: [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Junio C Hamano @ 2008-07-25 4:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200807242124.14583.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Donnerstag, 24. Juli 2008, Junio C Hamano wrote:
>> Johannes Sixt <johannes.sixt@telecom.at> writes:
>> > It also fixes 'make install' of git-gui as well (sigh!) by not exporting
>> > gitexecdir - assuming that Shawn applies the git-gui patch.
>>
>> Yeah, this seems to break the install quite badly without git-gui patch.
>
> If you squash this in, we don't need the git-gui patch.
Thanks.
I think this patch makes _more_ sense than the git-gui patch, actually.
Within the context of git.git project, we would want to force the
installation directory of git-gui portion to be consistent with the main
project.
> diff --git a/Makefile b/Makefile
> index aab23a2..904150e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1344,7 +1344,7 @@ install: all
> $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
> ifndef NO_TCLTK
> $(MAKE) -C gitk-git install
> - $(MAKE) -C git-gui install
> + $(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' install
> endif
> ifneq (,$X)
> $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)),
> $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
However, I have to wonder if it is the right thing to do, like your patch
does, for "git --exec-path" to return "../libexec/git-core/" in a relative
form, without saying what it is relative to. Shouldn't we be showing the
full path after resolving that relative path to git executable?
^ permalink raw reply
* Re: [PATCH] index-pack: correctly initialize appended objects
From: Junio C Hamano @ 2008-07-25 5:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, spearce, git
In-Reply-To: <alpine.DEB.1.00.0807241821440.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> From: Björn Steinbrink <B.Steinbrink@gmx.de>
>
> When index-pack completes a thin pack it appends objects to the pack.
> Since the commit 92392b4(index-pack: Honor core.deltaBaseCacheLimit when
> resolving deltas) such an object can be pruned in case of memory
> pressure.
>
> To be able to re-read the object later, a few more fields have to be set.
>
> Noticed by Pierre Habouzit.
>
> Hopefully-signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
> Hopefully-reviewed-and-signed-off-by: Nicolas Pitre <nico@cam.org>,
>
> --
> Nico could you have a quick look? (I would ask Shawn, but I know
> that he is pretty busy with real world issues.)
Reading get_data_from_pack(), it does rely on hdr_size, idx.offset and
idx.offset of the next entry to be set correctly. The function does not
seem to use type (which the patch is also setting) nor real_type (which
the patch does not set).
However, the code checks objects[nth].real_type all over the place in the
code. Doesn't the lack of real_type assignment in append_obj_to_pack()
affect them in any way?
> diff --git a/index-pack.c b/index-pack.c
> index ac20a46..33ba8ef 100644
> --- a/index-pack.c
> +++ b/index-pack.c
> @@ -699,6 +699,9 @@ static struct object_entry *append_obj_to_pack(
> write_or_die(output_fd, header, n);
> obj[0].idx.crc32 = crc32(0, Z_NULL, 0);
> obj[0].idx.crc32 = crc32(obj[0].idx.crc32, header, n);
> + obj[0].hdr_size = n;
> + obj[0].type = type;
> + obj[0].size = size;
> obj[1].idx.offset = obj[0].idx.offset + n;
> obj[1].idx.offset += write_compressed(output_fd, buf, size, &obj[0].idx.crc32);
^ permalink raw reply
* Re: [PATCH 2/2] git-svn: make use of svn auto-props optional
From: Eric Wong @ 2008-07-25 5:50 UTC (permalink / raw)
To: Brad King; +Cc: git
In-Reply-To: <4885024D.2070402@kitware.com>
Brad King <brad.king@kitware.com> wrote:
>
> In order to preserve existing default behavior, dcommit should use svn
> auto-props only if instructed to do so. This commit creates a config
> option 'svn.autoprops' to enable the behavior.
No need for this. auto-props is the correct and expected behavior for
users coming from the `svn' client.
There's no backwards compatibility issue, either, since this only
affects new commits that git-svn makes.
Thanks.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/2] git-svn: teach dcommit about svn auto-props
From: Eric Wong @ 2008-07-25 6:00 UTC (permalink / raw)
To: Brad King; +Cc: git
In-Reply-To: <4885024A.3050200@kitware.com>
Brad King <brad.king@kitware.com> wrote:
>
> Subversion repositories often require files to have properties such as
> svn:mime-type and svn:eol-style set when they are added. Users
> typically set these properties automatically using the SVN auto-props
> feature with 'svn add'. This commit teaches dcommit to look at the user
> SVN configuration and apply matching auto-props entries for files added
> by a diff as it is applied to the SVN remote. A later commit will make
> this feature optional.
>
> Signed-off-by: Brad King <brad.king@kitware.com>
Hi Brad,
I like this patch. Can we get an automated test of this functionality?
We can (and probably should) set $HOME for the test and ignore the
existing ~/.subversion/config of the user.
Also, some minor nitpicks on whitespace/formatting inline below.
Not sure if writing a new unit test will trigger that bug below for you.
It really shouldn't...
> ---
> This change honors the user's enable-auto-props svn config setting.
> The next patch will configure this at the git level and add the
> corresponding documentation.
>
> I've tested this by hand on an real SVN repo that checks for mime type.
> Unfortunately I'm unable to run the git-svn test suite because I get
> the error reported here:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486527
>
> (even without my changes).
I haven't had the chance to look at this. Can anybody else shed more
light on that bug? It's really strange that the tests won't run because
of it. Are you unable to run some git-svn tests or all of them?
<snip>
> +sub apply_autoprops {
> + my ($self, $file, $fbat) = @_;
> + my $conf_t = ${$self->{config}}{'config'};
> + no warnings 'once';
> + # Check [miscellany]/enable-auto-props in svn configuration.
> + if (SVN::_Core::svn_config_get_bool($conf_t,
> + $SVN::_Core::SVN_CONFIG_SECTION_MISCELLANY,
> + $SVN::_Core::SVN_CONFIG_OPTION_ENABLE_AUTO_PROPS,
Long lines here and below. I'd rather just align to the left (tabs are
assumed to be 8 characters wide on screen).
> + 0)) {
> + # Auto-props are enabled. Enumerate them to look for matches.
> + my $callback = sub {
> + $self->check_autoprop($_[0], $_[1], $file, $fbat);
> + };
> + SVN::_Core::svn_config_enumerate($conf_t,
> + $SVN::_Core::SVN_CONFIG_SECTION_AUTO_PROPS,
> + $callback);
> + }
> +}
> +
> sub A {
> my ($self, $m) = @_;
> my ($dir, $file) = split_path($m->{file_b});
> @@ -3535,6 +3581,7 @@ sub A {
> my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
> undef, -1);
> print "\tA\t$m->{file_b}\n" unless $::_q;
> + $self->apply_autoprops($file, $fbat);
Hard tabs are used for indentation.
Thanks!
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Teach fsck and prune about the new location of temporary objects
From: Junio C Hamano @ 2008-07-25 6:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brandon Casey, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807250233031.4140@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 24 Jul 2008, Brandon Casey wrote:
>
>> Since 5723fe7e, temporary objects are now created in their final destination
>> directories, rather than in .git/objects/. Teach fsck to recognize and
>> ignore the temporary objects it encounters,
>
> It somehow feels wrong for fsck to ignore anything that could be used.
Back when we created temporaries in .git/objects/, these tmp_obj files
were not even checked nor looked at, because fsck_object_dir() checked
only those 256 fan-out directories, so this is nothing new.
And these tmp_obj files are something we _expect_ to be in the object
directory. The user can ^C out object creation codepath anytime, and we
do not reference the final destination objects from refs nor the index to
preserve the integrity of the repository when that happens. In other
words, they are crufts, but they are not something unusual nor get alarmed
about.
And it also is the right thing to do to remove them in prune.
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: Peter Valdemar Mørch @ 2008-07-25 6:11 UTC (permalink / raw)
To: git
In-Reply-To: <7vbq0m608w.fsf@gitster.siamese.dyndns.org>
> So I think Peter's patch is going in the right direction.
Thus encouraged, I've created a file with two more patches like I
described in my previous mail: one that fixes up .gitattributes and one
that fixes up t/* to conform to documented syntax of core.whitespace.
(For the future: Is it better to have one file with tree patches like I
have created with git format-patch -M -s --stdout, 3 individual numbered
files, or one single patch created with git-merge --squash?)
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-25 6:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vbq0m608w.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 532 bytes --]
> So I think Peter's patch is going in the right direction.
Thus encouraged, I've created a file with two more patches like I
described in my previous mail: one that fixes up .gitattributes and one
that fixes up t/* to conform to documented syntax of core.whitespace.
(For the future: Is it better to have one file with tree patches like I
have created with "git format-patch -M -s --stdout", 3 individual
numbered files, or one single patch created with git-merge --squash?)
Peter
--
Peter Valdemar Mørch
http://www.morch.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: core.whitespace.patch --]
[-- Type: text/x-patch; name="core.whitespace.patch", Size: 5595 bytes --]
>From 900455ce5a4e8bf771aea2e3dbdbab38e440cdf4 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Peter=20Valdemar=20M=C3=B8rch?= <peter@morch.com>
Date: Thu, 24 Jul 2008 07:18:48 +0200
Subject: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Peter Valdemar Mørch <peter@morch.com>
---
Documentation/config.txt | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e784805..a198b3c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -361,10 +361,12 @@ core.whitespace::
consider them as errors:
+
* `trailing-space` treats trailing whitespaces at the end of the line
- as an error (enabled by default).
+ as an error (enabled by default - disable with 'git config core.whitespace
+ "-trailing-space"').
* `space-before-tab` treats a space character that appears immediately
before a tab character in the initial indent part of the line as an
- error (enabled by default).
+ error (enabled by default - disable with 'git config core.whitespace
+ "-space-before-tab"').
* `indent-with-non-tab` treats a line that is indented with 8 or more
space characters as an error (not enabled by default).
* `cr-at-eol` treats a carriage-return at the end of line as
--
1.5.6
>From c73dd588bef2a56fc44af2ce10cedef1b779a510 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Peter=20Valdemar=20M=C3=B8rch?= <peter@morch.com>
Date: Fri, 25 Jul 2008 07:33:07 +0200
Subject: [PATCH] Fixed up .gitattributes to allign with git-config.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Peter Valdemar Mørch <peter@morch.com>
---
.gitattributes | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/.gitattributes b/.gitattributes
index 6b9c715..1a903b6 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1,2 +1,2 @@
-* whitespace=!indent,trail,space
-*.[ch] whitespace
+* whitespace=-indent-with-non-tab,trailing-space,space-before-tab
+*.[ch] !whitespace
--
1.5.6
>From 45889568fec2b952e10aef2fac78ba6dfda9f46d Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Peter=20Valdemar=20M=C3=B8rch?= <peter@morch.com>
Date: Fri, 25 Jul 2008 07:59:24 +0200
Subject: [PATCH] tests now use git-config's core.whitespace only with documented values
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Peter Valdemar Mørch <peter@morch.com>
---
t/t4019-diff-wserror.sh | 14 +++++++-------
t/t4124-apply-ws-rule.sh | 4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/t/t4019-diff-wserror.sh b/t/t4019-diff-wserror.sh
index 0d9cbb6..ecff30d 100755
--- a/t/t4019-diff-wserror.sh
+++ b/t/t4019-diff-wserror.sh
@@ -33,9 +33,9 @@ test_expect_success default '
'
-test_expect_success 'without -trail' '
+test_expect_success 'without -trailing-space' '
- git config core.whitespace -trail
+ git config core.whitespace -trailing-space
git diff --color >output
grep "$blue_grep" output >error
grep -v "$blue_grep" output >normal
@@ -48,10 +48,10 @@ test_expect_success 'without -trail' '
'
-test_expect_success 'without -trail (attribute)' '
+test_expect_success 'without -trailing-space (attribute)' '
git config --unset core.whitespace
- echo "F whitespace=-trail" >.gitattributes
+ echo "F whitespace=-trailing-space" >.gitattributes
git diff --color >output
grep "$blue_grep" output >error
grep -v "$blue_grep" output >normal
@@ -99,7 +99,7 @@ test_expect_success 'without -space (attribute)' '
test_expect_success 'with indent-non-tab only' '
rm -f .gitattributes
- git config core.whitespace indent,-trailing,-space
+ git config core.whitespace indent-with-non-tab,-trailing-space,-space-before-tab
git diff --color >output
grep "$blue_grep" output >error
grep -v "$blue_grep" output >normal
@@ -115,7 +115,7 @@ test_expect_success 'with indent-non-tab only' '
test_expect_success 'with indent-non-tab only (attribute)' '
git config --unset core.whitespace
- echo "F whitespace=indent,-trailing,-space" >.gitattributes
+ echo "F whitespace=indent-with-non-tab,-trailing-space,-space-before-tab" >.gitattributes
git diff --color >output
grep "$blue_grep" output >error
grep -v "$blue_grep" output >normal
@@ -147,7 +147,7 @@ test_expect_success 'with cr-at-eol' '
test_expect_success 'with cr-at-eol (attribute)' '
git config --unset core.whitespace
- echo "F whitespace=trailing,cr-at-eol" >.gitattributes
+ echo "F whitespace=trailing-space,cr-at-eol" >.gitattributes
git diff --color >output
grep "$blue_grep" output >error
grep -v "$blue_grep" output >normal
diff --git a/t/t4124-apply-ws-rule.sh b/t/t4124-apply-ws-rule.sh
index 85f3da2..644aadc 100755
--- a/t/t4124-apply-ws-rule.sh
+++ b/t/t4124-apply-ws-rule.sh
@@ -106,7 +106,7 @@ test_expect_success 'whitespace=error-all, default rule' '
test_expect_success 'whitespace=error-all, no rule' '
- git config core.whitespace -trailing,-space-before,-indent &&
+ git config core.whitespace -trailing-space,-space-before-tab,-indent-with-non-tab &&
apply_patch --whitespace=error-all &&
diff file target
@@ -130,7 +130,7 @@ do
for i in - ''
do
case "$i" in '') ti='#' ;; *) ti= ;; esac
- rule=${t}trailing,${s}space,${i}indent
+ rule=${t}trailing-space,${s}space-before-tab,${i}indent-with-non-tab
rm -f .gitattributes
test_expect_success "rule=$rule" '
--
1.5.6
^ permalink raw reply related
* Re: Stitching together two split segments from svn
From: Jakub Narebski @ 2008-07-25 7:21 UTC (permalink / raw)
To: Liam Healy; +Cc: git
In-Reply-To: <654935030807241941p620201a2q21bb4513cd21225d@mail.gmail.com>
On Fri, 25 Jul 2008, Liam Healy wrote:
>
> Thanks for the advice -- this did exactly what I wanted.
>
> For anyone else wanting to do this: one thing that threw me for a
> while was that .git/info/grafts does not accept an abbreviated SHA,
> the full 40 hex digits is needed. I would see "bad graft data" from
> gitk with no other explanation. There is very little documentation
> that I could find on the grafts file; the best I could find was in the
> man page for git-filter branch:
>
> http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html.
You can find definition of grafts in `gitglossary', and where you can
find them together with description of grafts file format in
`gitrepository-layout'
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: Junio C Hamano @ 2008-07-25 7:28 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <4888144E.8090300@sneakemail.com>
"Peter Valdemar Mørch (Lists)" <4ux6as402@sneakemail.com> writes:
> This is a multi-part message in MIME format.
> --------------080005060106030305090009
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 8bit
> ...
> --------------080005060106030305090009
> Content-Type: text/x-patch;
> name="0001-Document-disabling-core.whitespace-values-trailing-s.patch"
> Content-Transfer-Encoding: 8bit
Please do not send patch as attachment. It is very cumbersome to handle.
^ permalink raw reply
* Re: gitweb tags feed, Re: New version announcements?
From: Pedro Melo @ 2008-07-25 7:37 UTC (permalink / raw)
To: Julian Phillips; +Cc: Petr Baudis, Jordi Bunster, git, gitster
In-Reply-To: <Pine.LNX.4.64.0807241818520.7970@reaper.quantumfyre.co.uk>
Hi,
On Jul 24, 2008, at 6:25 PM, Julian Phillips wrote:
> On Thu, 24 Jul 2008, Pedro Melo wrote:
>> On Jul 24, 2008, at 4:04 PM, Julian Phillips wrote:
>>> > On Thu, Jul 24, 2008 at 10:38:24AM -0400, Jordi Bunster wrote:
>>> > > > > Any way that a git-announce list could be created for
>>> security fixes > > and
>>> > > new releases? Or maybe an RSS feed on the website?
>>> An RSS feed already exists, have a look at http://gitrss.q42.co.uk/.
>>
>> You might want to look at the script that generates the announces
>> feed. It missed the 1.5.6.4 announcement.
>>
>> http://article.gmane.org/gmane.comp.version-control.git/89148/
>> match=1.5.6.4
>
> Should be there now. Thanks. :)
It's there, fixed.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* [PATCH 6/9 - v2] builtin-init-db.c: use parse_options()
From: Michele Ballabio @ 2008-07-25 8:15 UTC (permalink / raw)
To: Olivier Marin; +Cc: git, gitster
In-Reply-To: <200807242207.02195.barra_cuda@katamail.com>
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
On Thursday 24 July 2008, Michele Ballabio wrote:
> +static int parse_opt_shared_cb(const struct option *opt, const char *arg,
> + int unset)
> +{
> + *(int *)(opt->value) = unset ? PERM_UMASK : git_config_perm("arg", arg);
> + return 0;
> +}
>
Did it this way (and changed help strings).
builtin-init-db.c | 57 +++++++++++++++++++++++++++++++++-------------------
1 files changed, 36 insertions(+), 21 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 38b4fcb..42c2e20 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -6,6 +6,7 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
+#include "parse-options.h"
#ifndef DEFAULT_GIT_TEMPLATE_DIR
#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates"
@@ -353,8 +354,18 @@ static int guess_repository_type(const char *git_dir)
return 1;
}
-static const char init_db_usage[] =
-"git init [-q | --quiet] [--bare] [--template=<template-directory>] [--shared[=<permissions>]]";
+static const char * const init_db_usage[] = {
+ "git init [-q | --quiet] [--bare] [--template=<dir>] [--shared[=<type>]]",
+ NULL
+};
+
+static int parse_opt_shared_cb(const struct option *opt, const char *arg,
+ int unset)
+{
+ *(int *)(opt->value) = unset ? PERM_UMASK :
+ git_config_perm("arg", arg);
+ return 0;
+}
/*
* If you want to, you can share the DB area with any number of branches.
@@ -367,25 +378,29 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
const char *git_dir;
const char *template_dir = NULL;
unsigned int flags = 0;
- int i;
-
- for (i = 1; i < argc; i++, argv++) {
- const char *arg = argv[1];
- if (!prefixcmp(arg, "--template="))
- template_dir = arg+11;
- else if (!strcmp(arg, "--bare")) {
- static char git_dir[PATH_MAX+1];
- is_bare_repository_cfg = 1;
- setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir,
- sizeof(git_dir)), 0);
- } else if (!strcmp(arg, "--shared"))
- shared_repository = PERM_GROUP;
- else if (!prefixcmp(arg, "--shared="))
- shared_repository = git_config_perm("arg", arg+9);
- else if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet"))
- flags |= INIT_DB_QUIET;
- else
- usage(init_db_usage);
+ int bare = 0;
+
+ const struct option options[] = {
+ OPT_STRING(0, "template", &template_dir, "path",
+ "path to the template directory"),
+ OPT_BOOLEAN(0, "bare", &bare, "set up a bare repository"),
+ { OPTION_CALLBACK, 0, "shared", &shared_repository,
+ "permissions", "set up a shared repository",
+ PARSE_OPT_OPTARG, parse_opt_shared_cb, PERM_GROUP },
+ OPT_BIT('q', "quiet", &flags, "be quiet", INIT_DB_QUIET),
+ OPT_END()
+ };
+
+ argc = parse_options(argc, argv, options, init_db_usage, 0);
+
+ if (argc > 0)
+ usage_with_options(init_db_usage, options);
+
+ if (bare) {
+ static char git_dir[PATH_MAX+1];
+ is_bare_repository_cfg = 1;
+ setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir,
+ sizeof(git_dir)), 0);
}
/*
--
1.5.6.3
^ permalink raw reply related
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Sverre Rabbelier @ 2008-07-25 8:14 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Petr Baudis, Jeff King, Nguy?n Thái Ng?c Duy, git
In-Reply-To: <alpine.DEB.1.00.0807250210090.4140@eeepc-johanness>
On Fri, Jul 25, 2008 at 02:12, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Thu, 24 Jul 2008, Sverre Rabbelier wrote:
>> Wouldn't that be as simple as passing a pathspec to git-rev-list? Not a
>> lot of overhead there I reckon.
>
> So the server would _not_ have to deflate the objects to inspect them? I
> thought you knew more about Git's object database.
Nope, I did not know this. I thought that the server already had to do
all that to decide what to send, since not every request asks for the
same pack (someone might not have updated in 2 month, or someone might
might be up to date, or anything in between).
>> Just keep them?
>
> You'd still have to inspect the objects, which is way more work than the
> current code has to do. Remember: in the optimal case, upload-pack does
> not more than just serve the existing deltas/base objects.
Ah, I can see how that would produce overhead then.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Johannes Sixt @ 2008-07-25 8:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3aly5zz3.fsf@gitster.siamese.dyndns.org>
Zitat von Junio C Hamano <gitster@pobox.com>:
> However, I have to wonder if it is the right thing to do, like your patch
> does, for "git --exec-path" to return "../libexec/git-core/" in a relative
> form, without saying what it is relative to. Shouldn't we be showing the
> full path after resolving that relative path to git executable?
Does it? "git --exec-path" calls git_exec_path(), and that now returns
system_path(GIT_EXEC_PATH), and that is an absolute path, although it's
not normalized.
Oh, I see: You tested it on Linux, right? This patch series does not work
correctly on Linux (Unix? bash?), as Dscho has pointed out, since argv[0]
does not have a directory part if "git" is in $PATH. In this case, system_path()
just returns its argument, which is the relative path. :-/
-- Hannes
^ permalink raw reply
* Re: [PATCH] editor.c: Libify launch_editor()
From: Junio C Hamano @ 2008-07-25 8:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephan Beyer, git
In-Reply-To: <alpine.DEB.1.00.0807181405510.3932@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Fri, 18 Jul 2008, Stephan Beyer wrote:
>
>> This patch removes exit()/die() calls and builtin-specific messages from
>> launch_editor(), so that it can be used as a general libgit.a function
>> to launch an editor.
>
> Thanks. Now we have to convince Junio that it is a good idea :-)
Eh, excuse me.
>> diff --git a/editor.c b/editor.c
>> index 483b62d..5d7f5f9 100644
>> --- a/editor.c
>> +++ b/editor.c
>> @@ -17,9 +17,8 @@ void launch_editor(const char *path, struct strbuf *buffer, const char *const *e
> ...
> Why not "return error()"?
>
> Rest looks obviously correct to me!
This is a patch to an existing file editor.c???
^ permalink raw reply
* Re: [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Johannes Sixt @ 2008-07-25 8:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1216974722.48898f82e80d6@webmail.eunet.at>
Johannes Sixt schrieb:
> Oh, I see: You tested it on Linux, right? This patch series does not work
> correctly on Linux (Unix? bash?), as Dscho has pointed out, since argv[0]
does not work correctly on Linux... *iff gitexecdir is relative*
> does not have a directory part if "git" is in $PATH. In this case, system_path()
> just returns its argument, which is the relative path. :-/
-- Hannes
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Junio C Hamano @ 2008-07-25 8:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807241311450.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> At what point in what valid workflow sequence does HEAD become different
>> from dotest/amend?
>
> $ rebase -i HEAD~5
>
> <mark one commit as edit>
>
> <Whoa! While editing, I realize that this contains an unrelated
> bugfix>
>
> $ git reset HEAD^
> $ git add -p
> $ git commit
>
> <Edit a bit here, a bit there>
>
> $ git rebase --continue
>
> Sure it is a pilot error. It hit this pilot, too.
> ...
> In the way that the user certainly did not mean to amend _this_ HEAD.
> Another HEAD was marked with "edit".
Ok; after this "refraining from incorrectly squashing them", how would the
user edit the one the user originally intended to edit (I am not
complaining, but asking for information)?
So in your workflow example, when there is no pilot error, is this the
"ideal" sequence?
$ git rebase -i HEAD~5
.. mark one as edit
.. ah, the one I wanted to just "edit" actually need to be
.. split into two because it has some other thing I need to change
$ git reset HEAD^
$ git add -p
$ git stash --keep-index
.. test to verify the initial part
$ git commit ;# first part of split commit
$ git stash pop
.. test test
$ git add -p
$ git rebase --continue ;# gives you the editor to edit
I wonder if we can make the transcript of the "pilot error" case look like
this:
$ git rebase -i HEAD~5
...
$ git reset HEAD^
.. same as above up to...
.. test to verify the initial part
$ git rebase --continue ;# oops
.. gives you the editor to edit the message.
.. makes a commit, and says:
committed initial part of the change, stopping.
.. ah, the command noticed it and did not escape, thanks!
$ git stash pop
.. test test
$ git add -p
$ git rebase --continue ;# gives you the editor to edit
.. and goes on this time.
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Junio C Hamano @ 2008-07-25 8:46 UTC (permalink / raw)
To: Ingo Molnar; +Cc: SZEDER Gábor, git
In-Reply-To: <20080724152742.GA23585@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> perhaps you need to run tip-create-local-branches.sh to create all the
> local branches? You can find it in:
>
> tip/tip .tip/bin/tip-create-local-branches.sh
>
> (does/should the presence of local branches matter?)
My refs/remotes/mingo/ hierarchy has as many branches as you do in your
repository as local branches, and I presume you do not have these tracking
branches as I do because you are the upstream of this repository, so
overall we have about the same number of refs. In the experiment, I did
"branch -a --no-merged" (notice -a), so I do not think the difference
should have mattered.
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Junio C Hamano @ 2008-07-25 8:47 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20080724182813.GA21186@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Jul 24, 2008 at 06:41:03PM +0100, Johannes Schindelin wrote:
>
>> > As a user, I would expect "sparse clone" to also be sparse on the
>> > fetching. That is, to not even bother fetching tree objects that we are
>> > not going to check out. But that is a whole other can of worms from
>> > local sparseness, so I think it is worth saving for a different series.
>>
>> I think this is not even worth of a series. Sure, it would have benefits
>> for those who want sparse checkouts. But it comes for a high price on
>> everyone else:
>
> I agree there are a lot of issues. I am just thinking of the person who
> said they had a >100G repository. But I am also not volunteering to do
> it, so I will let somebody who really cares about it try to defend the
> idea.
I think sparse fetch is a lot worse than grafts and shallow clones which
are already bad. These are all ways to introduce local inconsistency at
the object level and pretend everything is Ok, but the latter two do so
only at commit boundary and it is somewhat more manageable (but we still
do not handle it very well). With sparse fetch, you cannot even guarantee
the integrity of individual commits with subtrees here and there missing.
I do think shallow checkout that says "I'll have the whole tree in the
index but the work tree will have only these paths checked out" makes
sense. You do not need a fully populated work tree to create commits or
merges -- the only absolute minimum you need is a fully populated index.
In that sense, I think "protect index entries outside of these paths" (I
remember that the first round of this series was done around that notion)
is a wrong mentality to handle this. We should think of this as more like
"you still populate the index with the whole tree, and you are free to
update them in any way you want, but we do not touch work tree outside
these areas".
This has a few ramifications:
- If the user can somehow check out a path outside the "sparse" area, it
is perfectly fine for the user to edit and "git add" it. Such a method
to check out a path outside the "sparse" area is a way to widen the
"sparse" area the user originally set up;
- When the user runs "merge", and it needs to present the user a working
tree file because of conflicts at the file level, the user has to agree
to widen the "sparse" area before being able to do so. One way to do
this is to refuse and fail the merge (and then the user needs to do
that "unspecified way" of widening the "sparse" area first). Another
way would be to automatically widen the "sparse" area to include such
conflicting paths.
- And you would want to narrow it down after you do such a widening.
For many projects that has src/ and doc/ (git.git being one of them), it
is perfectly valid for a code person and a doc person to work in tandem.
In such a project, after the code person makes changes in her sparsely
checked out repository and making changes only to the src/ area and pushes
the results out, the doc person would run "git pull && git log -p
ORIG_HEAD" and updates the documentation in his sparsely checked out
repository that has only doc/ area. The two parts are tied together and
they advance more or less in sync. I think sparse checkout would be a
useful feature to help such a configuration.
Having said that, I however think that this can easily be misused as a CVS
style "one CVSROOT houses millions of totally unrelated projects" layout.
In CVS, the layout is perfectly fine because the system does not track
changes at anything higher than the level of individual files, but when
you naïvely map the layout to a system with tree-wide atomic commits, such
as git, it will defeat the whole point of using such a system. The pace
these millions of unrelated projects advance do not have any relationship
with each other, but by tying them together in the same top-level tree,
the layout is introducing an unnecessary ordering between their commits.
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: Junio C Hamano @ 2008-07-25 8:49 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Peter Valdemar Mørch (Lists), git
In-Reply-To: <7vbq0m608w.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Various "values" given to the whitespace attribute actually act as if they
> are sub-variables and obey the similar "[-]name" rule, but (1) that is
> left unsaid, and (2) in that context '!' does not make sense so only '-'
> has any meaning.
Actually I take it back. "!name to revert to unspecified and -name to unset"
really is about name; values to whitespace do not work like "sub-variables"
at all.
> So I think Peter's patch is going in the right direction.
I've committed a much more simplified version.
-- >8 --
[PATCH] Documentation: clarify how to diable elements in core.whitespace
Noticed by Peter Valdemar Mørch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e784805..798b551 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -358,7 +358,8 @@ core.whitespace::
A comma separated list of common whitespace problems to
notice. 'git-diff' will use `color.diff.whitespace` to
highlight them, and 'git-apply --whitespace=error' will
- consider them as errors:
+ consider them as errors. You can prefix `-` to disable
+ any of them (e.g. `-trailing-space`):
+
* `trailing-space` treats trailing whitespaces at the end of the line
as an error (enabled by default).
^ permalink raw reply related
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Sverre Rabbelier @ 2008-07-25 8:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johannes Schindelin,
Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7v7ibauz94.fsf@gitster.siamese.dyndns.org>
On Fri, Jul 25, 2008 at 10:47, Junio C Hamano <gitster@pobox.com> wrote:
> For many projects that has src/ and doc/ (git.git being one of them), it
We are? That's great, that'd mean I can actually do a 'ls' in the
git.git root! Oh wait...
$ ls | wc -l
693
--
Cheers,
Sverre Rabbelier
^ 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