* Re: The behaviour of git bisect skip
From: Christian Couder @ 2008-10-15 6:54 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <48F3DCEB.1060803@zytor.com>
Le mardi 14 octobre 2008, H. Peter Anvin a écrit :
> I recently had the unhappy experience of trying to bisect a tree with a
> large region of the history obscured by auxilliary bugs. "git bisect
> skip" will stay in the central region, thus being largely useless.
Yeah, it tries to find the first non skipped commit among the best possible
bisection points. And if you have a linear history the best bisection
points are in the middle of the good and bad commits.
> I was thinking about how to possibly do it better. This is something I
> came up with, and thought it might be interesing.
>
> a. we obviously cannot move the start and end (good and bad) markers,
> since they have not been shown one way or the other.
>
> b. however, the practice of testing the centermost point is merely the
> *optimal*, corresponding to 1 bit of information per iteration. An
> off-center test is also possible (as long as the value depends on both
> endpoints, and isn't fixed from one of the endpoints; in that case we
> have a linear search), corresponding to a smaller amount of information
> - for example, sampling at the one-quarter point corresponds to
> 3/4*log2(3/4) + 1/4*log2(1/4) =~ 0.811 bits of information.
>
> I would suggest something based on the following algorithm:
>
> Given an interval with a certain number of skip points, subdivide the
> interval into subintervals each separated by a skip point. Pick the
> centermost point of the *largest* of these intervals. If there is more
> than one largest interval, choose the one centermost point that ends up
> being centermost in the overall interval.
>
> This algorithm obviously needs some adjustment (as does plain binary
> search) in order to deal with a branched history, but I thought it might
> be an interesting starting point. It has the desirable property that it
> can make forward progress even in the presence of skip points, and that
> it avoids needlessly searching close to skip points.
It looks like a great alternative algorithm but as the current bisect skip
is implemented in shell, I think that it might be too difficult or
inefficient to implement something like that in shell.
I think it might be better to try a more simple alternative algorithm first
like removing all skipped commits from the sorted list of possible
bisection point (the list is sorted because best commits from a bisection
point are first) and trying the commit at one third (or another fixed
ration) of the best commit.
Regards,
Christian.
> -hpa
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] git pull: Support --preserve-merges as a flag to rebase
From: Stephen Haberman @ 2008-10-15 6:59 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <48D9586C.4010102@op5.se>
> Now that "git rebase" supports non-interactive rebases
> preserving merges, this patch is the next logical step
> for those who wish to use such a workflow.
>
> Since this patch makes the last test marked as expecting
> failure in t3409-rebase-preserve-merges, we now alter it
> to expect success.
Does anyone know the current status of this?
The first 1/3 and 2/3 of this series is in next now (which grant
non-interactive merge-preserving rebasing), but this additional
--preserve-merges flag to git pull didn't seem to make it.
(Correct me if I'm wrong, I cannot pin point exactly where 1/2
and 2/3 got merged in, I'm just cheating and looking at the files
as they exist in next's tip.)
My grandeur plan is to have this 3/3 go in as well and then follow it
up with my patch to add a branch.name.preservemerges config variable.
This will make our internal workflow of "always rebase local
changes/always preserve local merges" just work with "git pull".
Does this seem reasonable?
Thanks,
Stephen
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #03; Tue, 14)
From: Stephen Haberman @ 2008-10-15 7:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wsq7rt5.fsf@gitster.siamese.dyndns.org>
> * sh/maint-rebase3 (Sun Oct 5 23:26:52 2008 -0500) 1 commit
> . rebase--interactive: fix parent rewriting for dropped commits
>
> Tentatively dropped from everwhere, waiting for a reroll together with
> sh/rebase-i-p.
Assuming sh/maint-rebase3 goes before sh/rebase-i-p, there are no
changes to it. I rebased it on top of sp/maint and the tests passed.
> * sh/rebase-i-p (Wed Oct 8 01:41:57 2008 -0500) 7 commits
> - rebase-i-p: if todo was reordered use HEAD as the rewritten parent
> - rebase-i-p: do not include non-first-parent commits touching
> UPSTREAM
> - rebase-i-p: only list commits that require rewriting in todo
> - rebase-i-p: fix 'no squashing merges' tripping up non-merges
> - rebase-i-p: delay saving current-commit to REWRITTEN if squashing
> - rebase-i-p: use HEAD for updating the ref instead of mapping
> OLDHEAD
> - rebase-i-p: test to exclude commits from todo based on its parents
>
> Changes the `rebase -i -p` behavior to behave like git sequencer's
> rewrite of `rebase -i` would behave.
Attempting to follow your previous advice, I merged sp/master onto my
local sh/maint-rebase3, and rebased sh/rebase-i-p on top that resulting
merge, and got the changes fixed to play nicely with sh/maint-rebase3
+master, and integrated your feedback.
I'll be sending the new sh/rebase-i-p series soon.
Let me know if I did the wrong thing--your comment of maint-rebase3
"waiting for a reroll" makes me think you wanted that one rebased on
top of rebase-i-p, when I just got done doing the opposite (I hadn't
checked the git list before hacking on it).
Thanks,
Stephen
^ permalink raw reply
* [PATCH 1/2] git-check-attr(1): add output and example sections
From: Jonas Fonseca @ 2008-10-15 7:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabd6686n.fsf@gitster.siamese.dyndns.org>
Plumbing tools should document what output can be expected.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-check-attr.txt | 50 ++++++++++++++++++++++++++++++++++++++
1 files changed, 50 insertions(+), 0 deletions(-)
Junio C Hamano <gitster@pobox.com> wrote Tue, Oct 14, 2008:
> Should this really have to depend on next?
This is just topgit listing the patch dependencies.
> Could you split this into two patches, one for 'maint' to describe the
> output format, and another for 'next' (or 'dp/checkattr') to update the
> SYNOPSIS part?
Done. The example has been updated to also show '!' in action.
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
index 2b821f2..8460a87 100644
--- a/Documentation/git-check-attr.txt
+++ b/Documentation/git-check-attr.txt
@@ -22,6 +22,56 @@ OPTIONS
arguments as path names. If not supplied, only the first argument will
be treated as an attribute.
+OUTPUT
+------
+
+The output is of the form:
+<path> COLON SP <attribute> COLON SP <info> LF
+
+Where <path> is the path of a file being queried, <attribute> is an attribute
+being queried and <info> can be either:
+
+'unspecified';; when the attribute is not defined for the path.
+'unset';; when the attribute is defined to false.
+'set';; when the attribute is defined to true.
+<value>;; when a value has been assigned to the attribute.
+
+EXAMPLES
+--------
+
+In the examples, the following '.gitattributes' file is used:
+---------------
+*.java diff=java -crlf myAttr
+NoMyAttr.java !myAttr
+README caveat=unspecified
+---------------
+
+* Listing a single attribute:
+---------------
+$ git check-attr diff org/example/MyClass.java
+org/example/MyClass.java: diff: java
+---------------
+
+* Listing multiple attributes for a file:
+---------------
+$ git check-attr crlf diff myAttr -- org/example/MyClass.java
+org/example/MyClass.java: crlf: unset
+org/example/MyClass.java: diff: java
+org/example/MyClass.java: myAttr: set
+---------------
+
+* Listing attribute for multiple files:
+---------------
+$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java
+org/example/MyClass.java: myAttr: set
+org/example/NoMyAttr.java: myAttr: unspecified
+---------------
+
+* Not all values are equally unambiguous:
+---------------
+$ git check-attr caveat README
+README: caveat: unspecified
+---------------
SEE ALSO
--------
--
tg: (6c16792..) jf/man-git-check-attr-output (depends on: maint)
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH 2/2] git-check-attr(1): use 'verse' for multi-line synopsis sections
From: Jonas Fonseca @ 2008-10-15 7:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabd6686n.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-check-attr.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
index 59d5cd2..dcf7650 100644
--- a/Documentation/git-check-attr.txt
+++ b/Documentation/git-check-attr.txt
@@ -8,8 +8,9 @@ git-check-attr - Display gitattributes information.
SYNOPSIS
--------
+[verse]
'git check-attr' attr... [--] pathname...
-'git check-attr' --stdin [-z] attr... < <list-of-paths
+'git check-attr' --stdin [-z] attr... < <list-of-paths>
DESCRIPTION
-----------
--
tg: (34458dd..) jf/man-git-check-attr-synopsis (depends on: jf/man-git-check-attr-output next)
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Johannes Sixt @ 2008-10-15 7:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matt McCutchen, git
In-Reply-To: <7vmyh64bgy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Junio C Hamano schrieb:
>> ...
>>>> +# Remove a default ACL from the test dir if possible.
>>>> +setfacl -k . 2>/dev/null
>>>> +
>>> Makes me wonder why this is _not_ inside test-lib.sh where it creates the
>>> test (trash) directory. That way, you would cover future tests that wants
>>> to see a saner/simpler POSIX permission behaviour, wouldn't you?
>> But that would also paper over unanticipated bad interactions with strange
>> ACLs that people might set, wouldn't it? By not placing this into
>> test-lib.sh there is a higher chance that such an interaction is revealed,
>> and we can react on it (educate users or fix the code).
>
> What do you exactly mean by "educate users or fix the code"? For example,
> by not putting this setfacl in test-lib.sh, t1301 revealed that with a
> default ACL higher up, "git init --shared" would not work as expected.
>
> Then what?
>
> - Do you mean, by "educate users", that we teach users not to play fun
> games with ACL in a git controled working tree?
Correct. In the case of a shared repository we can educate users not to
play with ACLs.
> - Do you mean, by "fix the code", that we teach adjust_shared_perm() to
> deal with ACL?
Correct in principle, but we need not go this route in the case of shared
repositories because we better educate users.
-- Hannes
^ permalink raw reply
* [PATCH] rebase-i-p: squashing and limiting todo
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
This is v3, rebased on top of sp/maint with sp/master and sh/maint-rebase3.
So, it should apply cleanly to that. Junio's feedback aside, the only change
from v2 is that maint-rebase3's dropped commit check needs to be done before
Johannes's recent addition of:
test -s "$TODO" || echo noop >> "$TODO"
Because now the todo may temporarily have picks in it while probing for parents
that could later be removed by the dropped/cherry-picked commit check.
Previously todo never had temporary entries, so it didn't matter when the
dropped commit check was done.
(Apologies for not seeing Junio's what's cooking first and using his
maint/master instead of Shawn's. Let me know if I need to redo this and I will
get even more practice at rebasing.)
(Gah, resending with the list cc'd this time. Dammit, sorry about that.)
Thanks,
Stephen
Stephen Haberman (7):
rebase-i-p: test to exclude commits from todo based on its parents
rebase-i-p: use HEAD for updating the ref instead of mapping OLDHEAD
rebase-i-p: delay saving current-commit to REWRITTEN if squashing
rebase-i-p: fix 'no squashing merges' tripping up non-merges
rebase-i-p: only list commits that require rewriting in todo
rebase-i-p: do not include non-first-parent commits touching UPSTREAM
rebase-i-p: if todo was reordered use HEAD as the rewritten parent
git-rebase--interactive.sh | 131 ++++++++++++++++++-----------
t/t3411-rebase-preserve-around-merges.sh | 136 ++++++++++++++++++++++++++++++
2 files changed, 218 insertions(+), 49 deletions(-)
create mode 100644 t/t3411-rebase-preserve-around-merges.sh
^ permalink raw reply
* [PATCH] rebase-i-p: test to exclude commits from todo based on its parents
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
The first case was based off a script from Avi Kivity <avi@redhat.com>.
The second case includes a merge-of-a-merge to ensure both are included in todo.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
t/t3411-rebase-preserve-around-merges.sh | 136 ++++++++++++++++++++++++++++++
1 files changed, 136 insertions(+), 0 deletions(-)
create mode 100644 t/t3411-rebase-preserve-around-merges.sh
diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
new file mode 100644
index 0000000..b3973c9
--- /dev/null
+++ b/t/t3411-rebase-preserve-around-merges.sh
@@ -0,0 +1,136 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Stephen Haberman
+#
+
+test_description='git rebase preserve merges
+
+This test runs git rebase with and tries to squash a commit from after a merge
+to before the merge.
+'
+. ./test-lib.sh
+
+# Copy/paste from t3404-rebase-interactive.sh
+echo "#!$SHELL_PATH" >fake-editor.sh
+cat >> fake-editor.sh <<\EOF
+case "$1" in
+*/COMMIT_EDITMSG)
+ test -z "$FAKE_COMMIT_MESSAGE" || echo "$FAKE_COMMIT_MESSAGE" > "$1"
+ test -z "$FAKE_COMMIT_AMEND" || echo "$FAKE_COMMIT_AMEND" >> "$1"
+ exit
+ ;;
+esac
+test -z "$EXPECT_COUNT" ||
+ test "$EXPECT_COUNT" = $(sed -e '/^#/d' -e '/^$/d' < "$1" | wc -l) ||
+ exit
+test -z "$FAKE_LINES" && exit
+grep -v '^#' < "$1" > "$1".tmp
+rm -f "$1"
+cat "$1".tmp
+action=pick
+for line in $FAKE_LINES; do
+ case $line in
+ squash|edit)
+ action="$line";;
+ *)
+ echo sed -n "${line}s/^pick/$action/p"
+ sed -n "${line}p" < "$1".tmp
+ sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
+ action=pick;;
+ esac
+done
+EOF
+
+test_set_editor "$(pwd)/fake-editor.sh"
+chmod a+x fake-editor.sh
+
+# set up two branches like this:
+#
+# A1 - B1 - D1 - E1 - F1
+# \ /
+# -- C1 --
+
+test_expect_success 'setup' '
+ touch a &&
+ touch b &&
+ git add a &&
+ git commit -m A1 &&
+ git tag A1
+ git add b &&
+ git commit -m B1 &&
+ git tag B1 &&
+ git checkout -b branch &&
+ touch c &&
+ git add c &&
+ git commit -m C1 &&
+ git checkout master &&
+ touch d &&
+ git add d &&
+ git commit -m D1 &&
+ git merge branch &&
+ touch f &&
+ git add f &&
+ git commit -m F1 &&
+ git tag F1
+'
+
+# Should result in:
+#
+# A1 - B1 - D2 - E2
+# \ /
+# -- C1 --
+#
+test_expect_failure 'squash F1 into D1' '
+ FAKE_LINES="1 squash 3 2" git rebase -i -p B1 &&
+ test "$(git rev-parse HEAD^2)" = "$(git rev-parse branch)" &&
+ test "$(git rev-parse HEAD~2)" = "$(git rev-parse B1)" &&
+ git tag E2
+'
+
+# Start with:
+#
+# A1 - B1 - D2 - E2
+# \
+# G1 ---- L1 ---- M1
+# \ /
+# H1 -- J1 -- K1
+# \ /
+# -- I1 --
+#
+# And rebase G1..M1 onto E2
+
+test_expect_failure 'rebase two levels of merge' '
+ git checkout -b branch2 A1 &&
+ touch g &&
+ git add g &&
+ git commit -m G1 &&
+ git checkout -b branch3 &&
+ touch h
+ git add h &&
+ git commit -m H1 &&
+ git checkout -b branch4 &&
+ touch i &&
+ git add i &&
+ git commit -m I1 &&
+ git tag I1 &&
+ git checkout branch3 &&
+ touch j &&
+ git add j &&
+ git commit -m J1 &&
+ git merge I1 --no-commit &&
+ git commit -m K1 &&
+ git tag K1 &&
+ git checkout branch2 &&
+ touch l &&
+ git add l &&
+ git commit -m L1 &&
+ git merge K1 --no-commit &&
+ git commit -m M1 &&
+ GIT_EDITOR=: git rebase -i -p E2 &&
+ test "$(git rev-parse HEAD~3)" = "$(git rev-parse E2)" &&
+ test "$(git rev-parse HEAD~2)" = "$(git rev-parse HEAD^2^2~2)" &&
+ test "$(git rev-parse HEAD^2^1^1)" = "$(git rev-parse HEAD^2^2^1)"
+'
+
+test_done
+
--
1.6.0.2
^ permalink raw reply related
* [PATCH] rebase-i-p: delay saving current-commit to REWRITTEN if squashing
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
If the current-commit was dumped to REWRITTEN, but then we squash the next
commit in to it, we have invalidated the HEAD was just written to REWRITTEN.
Instead, append the squash hash to current-commit and save both of them the next
time around.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
git-rebase--interactive.sh | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c968117..23cf7a5 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -170,13 +170,18 @@ pick_one_preserving_merges () {
if test -f "$DOTEST"/current-commit
then
- current_commit=$(cat "$DOTEST"/current-commit) &&
- git rev-parse HEAD > "$REWRITTEN"/$current_commit &&
- rm "$DOTEST"/current-commit ||
- die "Cannot write current commit's replacement sha1"
+ if [ "$fast_forward" == "t" ]
+ then
+ cat "$DOTEST"/current-commit | while read current_commit
+ do
+ git rev-parse HEAD > "$REWRITTEN"/$current_commit
+ done
+ rm "$DOTEST"/current-commit ||
+ die "Cannot write current commit's replacement sha1"
+ fi
fi
- echo $sha1 > "$DOTEST"/current-commit
+ echo $sha1 >> "$DOTEST"/current-commit
# rewrite parents; if none were rewritten, we can fast-forward.
new_parents=
--
1.6.0.2
^ permalink raw reply related
* [PATCH] rebase-i-p: use HEAD for updating the ref instead of mapping OLDHEAD
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
If OLDHEAD was reordered in the todo, and its mapped NEWHEAD was used to set the
ref, commits reordered after OLDHEAD in the todo would should up as un-committed
changes.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
git-rebase--interactive.sh | 15 +--------------
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 30e4523..c968117 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -376,20 +376,7 @@ do_next () {
HEADNAME=$(cat "$DOTEST"/head-name) &&
OLDHEAD=$(cat "$DOTEST"/head) &&
SHORTONTO=$(git rev-parse --short $(cat "$DOTEST"/onto)) &&
- if test -d "$REWRITTEN"
- then
- test -f "$DOTEST"/current-commit &&
- current_commit=$(cat "$DOTEST"/current-commit) &&
- git rev-parse HEAD > "$REWRITTEN"/$current_commit
- if test -f "$REWRITTEN"/$OLDHEAD
- then
- NEWHEAD=$(cat "$REWRITTEN"/$OLDHEAD)
- else
- NEWHEAD=$OLDHEAD
- fi
- else
- NEWHEAD=$(git rev-parse HEAD)
- fi &&
+ NEWHEAD=$(git rev-parse HEAD) &&
case $HEADNAME in
refs/*)
message="$GIT_REFLOG_ACTION: $HEADNAME onto $SHORTONTO)" &&
--
1.6.0.2
^ permalink raw reply related
* [PATCH] rebase-i-p: fix 'no squashing merges' tripping up non-merges
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
Also only check out the first parent if this commit if not a squash--if it is a
squash, we want to explicitly ignore the parent and leave the wc as is, as
cherry-pick will apply the squash on top of it.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
git-rebase--interactive.sh | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 23cf7a5..274251f 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -219,15 +219,19 @@ pick_one_preserving_merges () {
die "Cannot fast forward to $sha1"
;;
f)
- test "a$1" = a-n && die "Refusing to squash a merge: $sha1"
-
first_parent=$(expr "$new_parents" : ' \([^ ]*\)')
- # detach HEAD to current parent
- output git checkout $first_parent 2> /dev/null ||
- die "Cannot move HEAD to $first_parent"
+
+ if [ "$1" != "-n" ]
+ then
+ # detach HEAD to current parent
+ output git checkout $first_parent 2> /dev/null ||
+ die "Cannot move HEAD to $first_parent"
+ fi
case "$new_parents" in
' '*' '*)
+ test "a$1" = a-n && die "Refusing to squash a merge: $sha1"
+
# redo merge
author_script=$(get_author_ident_from_commit $sha1)
eval "$author_script"
--
1.6.0.2
^ permalink raw reply related
* [PATCH] rebase-i-p: only list commits that require rewriting in todo
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
This is heavily based on Stephan Beyer's git sequencer rewrite of rebase-i-p.
Each commit is still found by rev-list UPSTREAM..HEAD, but a commit is only
included in todo if at least one its parents has been marked for rewriting.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
git-rebase--interactive.sh | 77 +++++++++++++++++++++++++++++--------------
1 files changed, 52 insertions(+), 25 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 274251f..331cb18 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -579,18 +579,67 @@ first and then run 'git rebase --continue' again."
echo $ONTO > "$REWRITTEN"/$c ||
die "Could not init rewritten commits"
done
+ # No cherry-pick because our first pass is to determine
+ # parents to rewrite and skipping dropped commits would
+ # prematurely end our probe
MERGES_OPTION=
else
- MERGES_OPTION=--no-merges
+ MERGES_OPTION="--no-merges --cherry-pick"
fi
SHORTUPSTREAM=$(git rev-parse --short $UPSTREAM)
SHORTHEAD=$(git rev-parse --short $HEAD)
SHORTONTO=$(git rev-parse --short $ONTO)
git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
- --abbrev=7 --reverse --left-right --cherry-pick \
+ --abbrev=7 --reverse --left-right --topo-order \
$UPSTREAM...$HEAD | \
- sed -n "s/^>/pick /p" > "$TODO"
+ sed -n "s/^>//p" | while read shortsha1 rest
+ do
+ if test t != "$PRESERVE_MERGES"
+ then
+ echo "pick $shortsha1 $rest" >> "$TODO"
+ else
+ sha1=$(git rev-parse $shortsha1)
+ preserve=t
+ for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -f2-)
+ do
+ if test -f "$REWRITTEN"/$p
+ then
+ preserve=f
+ fi
+ done
+ if test f = "$preserve"
+ then
+ touch "$REWRITTEN"/$sha1
+ echo "pick $shortsha1 $rest" >> "$TODO"
+ fi
+ fi
+ done
+
+ # Watch for commits that been dropped by --cherry-pick
+ if test t = "$PRESERVE_MERGES"
+ then
+ mkdir "$DROPPED"
+ # Save all non-cherry-picked changes
+ git rev-list $UPSTREAM...$HEAD --left-right --cherry-pick | \
+ sed -n "s/^>//p" > "$DOTEST"/not-cherry-picks
+ # Now all commits and note which ones are missing in
+ # not-cherry-picks and hence being dropped
+ git rev-list $UPSTREAM...$HEAD --left-right | \
+ sed -n "s/^>//p" | while read rev
+ do
+ if test -f "$REWRITTEN"/$rev -a "$(grep "$rev" "$DOTEST"/not-cherry-picks)" = ""
+ then
+ # Use -f2 because if rev-list is telling us this commit is
+ # not worthwhile, we don't want to track its multiple heads,
+ # just the history of its first-parent for others that will
+ # be rebasing on top of it
+ git rev-list --parents -1 $rev | cut -d' ' -f2 > "$DROPPED"/$rev
+ cat "$TODO" | grep -v "${rev:0:7}" > "${TODO}2" ; mv "${TODO}2" "$TODO"
+ rm "$REWRITTEN"/$rev
+ fi
+ done
+ fi
test -s "$TODO" || echo noop >> "$TODO"
cat >> "$TODO" << EOF
@@ -606,28 +655,6 @@ first and then run 'git rebase --continue' again."
#
EOF
- # Watch for commits that been dropped by --cherry-pick
- if test t = "$PRESERVE_MERGES"
- then
- mkdir "$DROPPED"
- # drop the --cherry-pick parameter this time
- git rev-list $MERGES_OPTION --abbrev-commit \
- --abbrev=7 $UPSTREAM...$HEAD --left-right | \
- sed -n "s/^>//p" | while read rev
- do
- grep --quiet "$rev" "$TODO"
- if [ $? -ne 0 ]
- then
- # Use -f2 because if rev-list is telling this commit is not
- # worthwhile, we don't want to track its multiple heads,
- # just the history of its first-parent for others that will
- # be rebasing on top of us
- full=$(git rev-parse $rev)
- git rev-list --parents -1 $rev | cut -d' ' -f2 > "$DROPPED"/$full
- fi
- done
- fi
-
has_action "$TODO" ||
die_abort "Nothing to do"
--
1.6.0.2
^ permalink raw reply related
* [PATCH] git-mergetool: properly handle "git mergetool -- filename"
From: David Aguilar @ 2008-10-15 7:39 UTC (permalink / raw)
To: gitster; +Cc: git, tytso, David Aguilar
git-mergetool has an entry for "--" in its command-line parsing code
to designate the end of option processing. It was not calling shift,
though, which caused git-mergetool to incorrectly use "--" as the
merge filename.
This patch fixes this bug and updates the usage and documentation
to include [--] in the options spec.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Documentation/git-mergetool.txt | 2 +-
git-mergetool.sh | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index e0b2703..475db72 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -7,7 +7,7 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
SYNOPSIS
--------
-'git mergetool' [--tool=<tool>] [<file>]...
+'git mergetool' [--tool=<tool>] [--] [<file>]...
DESCRIPTION
-----------
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 94187c3..1b0dfec 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -8,7 +8,7 @@
# at the discretion of Junio C Hamano.
#
-USAGE='[--tool=tool] [file to merge] ...'
+USAGE='[--tool=tool] [--] [file to merge] ...'
SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
. git-sh-setup
@@ -296,6 +296,7 @@ do
esac
;;
--)
+ shift
break
;;
-*)
--
1.6.0.2.532.g84ed4c
^ permalink raw reply related
* [PATCH] rebase-i-p: if todo was reordered use HEAD as the rewritten parent
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
This seems like the best guess we can make until git sequencer marks are
available. That being said, within the context of re-ordering a commit before
its parent in todo, I think applying it on top of the current commit seems like
a reasonable assumption of what the user intended.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
git-rebase--interactive.sh | 9 +++++++++
t/t3411-rebase-preserve-around-merges.sh | 4 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 3821692..1fc4f44 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -194,6 +194,15 @@ pick_one_preserving_merges () {
if test -f "$REWRITTEN"/$p
then
new_p=$(cat "$REWRITTEN"/$p)
+
+ # If the todo reordered commits, and our parent is marked for
+ # rewriting, but hasn't been gotten to yet, assume the user meant to
+ # drop it on top of the current HEAD
+ if test -z "$new_p"
+ then
+ new_p=$(git rev-parse HEAD)
+ fi
+
test $p != $new_p && fast_forward=f
case "$new_parents" in
*$new_p*)
diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
index b3973c9..dfad5dd 100644
--- a/t/t3411-rebase-preserve-around-merges.sh
+++ b/t/t3411-rebase-preserve-around-merges.sh
@@ -80,7 +80,7 @@ test_expect_success 'setup' '
# \ /
# -- C1 --
#
-test_expect_failure 'squash F1 into D1' '
+test_expect_success 'squash F1 into D1' '
FAKE_LINES="1 squash 3 2" git rebase -i -p B1 &&
test "$(git rev-parse HEAD^2)" = "$(git rev-parse branch)" &&
test "$(git rev-parse HEAD~2)" = "$(git rev-parse B1)" &&
@@ -99,7 +99,7 @@ test_expect_failure 'squash F1 into D1' '
#
# And rebase G1..M1 onto E2
-test_expect_failure 'rebase two levels of merge' '
+test_expect_success 'rebase two levels of merge' '
git checkout -b branch2 A1 &&
touch g &&
git add g &&
--
1.6.0.2
^ permalink raw reply related
* [PATCH] rebase-i-p: do not include non-first-parent commits touching UPSTREAM
From: Stephen Haberman @ 2008-10-15 7:44 UTC (permalink / raw)
To: gitster; +Cc: git, Stephen Haberman
In-Reply-To: <cover.1224055978.git.stephen@exigencecorp.com>
This covers an odd boundary case found by Avi Kivity's script where a branch
coming off of UPSTREAM is merged into HEAD. Initially it show up in
UPSTREAM..HEAD, but technically UPSTREAM is not moving, the rest of head is, so
we should not need to rewrite the merge.
This adds a check saying we can keep `preserve=t` if `p=UPSTREAM`...unless this
is the first first-parent commit in our UPSTREAM..HEAD rev-list, which could
very well point to UPSTREAM, but we still need to consider it as rewritten so we
start pulling in the rest of the UPSTREAM..HEAD commits that point to it.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
---
git-rebase--interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 331cb18..3821692 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -583,6 +583,7 @@ first and then run 'git rebase --continue' again."
# parents to rewrite and skipping dropped commits would
# prematurely end our probe
MERGES_OPTION=
+ first_after_upstream="$(git rev-list --reverse --first-parent $UPSTREAM..$HEAD | head -n 1)"
else
MERGES_OPTION="--no-merges --cherry-pick"
fi
@@ -603,7 +604,7 @@ first and then run 'git rebase --continue' again."
preserve=t
for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -f2-)
do
- if test -f "$REWRITTEN"/$p
+ if test -f "$REWRITTEN"/$p -a \( $p != $UPSTREAM -o $sha1 = $first_after_upstream \)
then
preserve=f
fi
--
1.6.0.2
^ permalink raw reply related
* Git graph on GitHub
From: Tom Werner @ 2008-10-15 7:47 UTC (permalink / raw)
To: git
We've just pushed out an update to the Network Graph on GitHub this
evening that finally allows us to draw very large repositories
(including Git). We're mirroring the Git repo on the site and I
thought it might be interesting for people to see this visualization.
Enjoy!
http://github.com/git/git/network
Let me know if you have any ideas for improvements on the graph. I'm
always looking for ways to enhance it.
Tom Preston-Werner
github.com/mojombo
^ permalink raw reply
* [Q] "status" of files in (a part of) the working tree
From: Brian Foster @ 2008-10-15 7:53 UTC (permalink / raw)
To: Git Mailing List
Hello,
For every file in a directory of my working tree,
I want to obtain a quick "status" summary (ideally,
recursively, i.e. descending into each sub-directory):
E.g., not-tracked, latest modification is not in
the index, latest modification is in the index,
not-modified, and so on. As a hypothetical example
(`# comments' added to explain what the line means):
$ git some-cmd
? foo # not-tracked
- bar # tracked, not-modified
M xyzzy # tracked, last modification not-in-index
I plover # tracked, last modification in-the-index
...
$
The `git ls-files' command sort-of seems to almost do
what I want, but not exactly. For instance (this is
written by hand but based on actual results):
$ git version
git version 1.6.0.2
$ git ls-files --exclude-standard --others --modified --cached -t
? foo
H bar
H xyzzy
C xyzzy
...
$
However, note that some files are listed twice (which
is confusing for my purposes), and I'm uncertain I've
specified all the magic to see all non-excluded files
regardless of their "status". Obviously, once I know
the appropriate set of magic I should be able to write
a filter to process the output and remove the unwanted
duplicates, but I'm wondering if someone has a better
suggestion? Generalissimo Goggle didn't find any clews.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Junio C Hamano @ 2008-10-15 7:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Matt McCutchen, git
In-Reply-To: <48F59928.5040502@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>>> But that would also paper over unanticipated bad interactions with strange
>>> ACLs that people might set, wouldn't it? By not placing this into
>>> test-lib.sh there is a higher chance that such an interaction is revealed,
>>> and we can react on it (educate users or fix the code).
>>
>> What do you exactly mean by "educate users or fix the code"? For example,
>> by not putting this setfacl in test-lib.sh, t1301 revealed that with a
>> default ACL higher up, "git init --shared" would not work as expected.
>>
>> Then what?
>>
>> - Do you mean, by "educate users", that we teach users not to play fun
>> games with ACL in a git controled working tree?
>
> Correct. In the case of a shared repository we can educate users not to
> play with ACLs.
>
>> - Do you mean, by "fix the code", that we teach adjust_shared_perm() to
>> deal with ACL?
>
> Correct in principle, but we need not go this route in the case of shared
> repositories because we better educate users.
If that is the case what difference does your suggestion of not putting it
in test-lib.sh make? We discourage users from playing ACL games, and we
protect ourselves from such by making sure the trash directory used for
running tests are not contaminated with ACL. Wouldn't it make more sense
to do so for all the tests, so that future test writers do not have to
worry about it?
^ permalink raw reply
* Re: [PATCH 1/3] Prepare for non-interactive merge-preserving rebase
From: Stephen Haberman @ 2008-10-15 8:07 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Git Mailing List
In-Reply-To: <20080924001027.GA19264@neumann>
> The following DAG is created by the commands below:
>
> -A---B master
> \
> C---M topic
> \ /
> D
>
> git init
> echo 1 >foo
> git add foo
> git commit -m 'first on master' # A
> echo 2 >>foo
> git commit -m 'second on master' foo # B
> git checkout -b topic HEAD^
> echo 1 >bar
> git add bar
> git commit -m 'first on topic' # C
> git checkout -b subtopic
> echo 1 >baz
> git add baz
> git commit -m 'first on subtopic' # D
> git checkout topic
> git merge --no-ff subtopic # M
>
> If I now execute 'git rebase -p master topic', I get the following:
>
> -A---B master
> \ \
> \ C'---M' topic
> \ /
> C----D
Following up on this old thread, I can't get M' to have the old parent
D. I always see D change to D' and then topic is fast fowarded to D'
instead of an M' showing up. (I've tried 1.6.0.2, my rebase-i-p changes,
and sp/maint.)
> But I would rather like to have the following:
>
> -A---B master
> \
> C'---M' topic
> \ /
> D'
>
> Would such a behaviour possible at all?
Yes, I think it just takes the following patch:
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -251,7 +251,7 @@ pick_one_preserving_merges () {
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
output git merge $STRATEGY -m "$msg" \
- $new_parents
+ --no-ff $new_parents
Applying this to either sp/maint or my rebase-i-p changes gets your
desired output.
With the only caveat being that the subtopic branch stays pointing at
the old D--since you are rebasing topic, it does not change where
subtopic points when rewriting D -> D'.
Musing, I could see moving subtopic being possible, definitely with git
sequencer, but also with a --other-branches-follow-rewrites flag of some
sort that, after rewriting hash1->hash2, just finds any local branches
pointing at hash1 and updates their refs to be hash2. Not that I'm
really suggesting it, but I don't think it would be that hard.
Anyway, subtopic still pointing at D aside, I think your desired output
makes sense, given you've explicitly told rebase to preserve merges. If
you wanted a non-ff M in the first place, I think passing along a
--no-ff to keep M' around is reasonable. And would otherwise be harmless.
I can write a test/patch for this unless you beat me to it or other
think it is unreasonable.
- Stephen
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Johannes Sixt @ 2008-10-15 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matt McCutchen, git
In-Reply-To: <7v7i8a47f6.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>>> - Do you mean, by "educate users", that we teach users not to play fun
>>> games with ACL in a git controled working tree?
>> Correct. In the case of a shared repository we can educate users not to
>> play with ACLs.
>>
>>> - Do you mean, by "fix the code", that we teach adjust_shared_perm() to
>>> deal with ACL?
>> Correct in principle, but we need not go this route in the case of shared
>> repositories because we better educate users.
>
> If that is the case what difference does your suggestion of not putting it
> in test-lib.sh make? We discourage users from playing ACL games, and we
> protect ourselves from such by making sure the trash directory used for
> running tests are not contaminated with ACL. Wouldn't it make more sense
> to do so for all the tests, so that future test writers do not have to
> worry about it?
We have to decide case by case. In the case of shared directories it makes
sense to suggest "do not play ACL games". In other cases, however, this
suggestion could not work out that well, and a workaround in the code is
the better solutions. But we do not know what those other cases are, and
the test suite may be a tool to uncover them.
Perhaps I'm worrying too much because a case that warrants a change in the
code would either have to happen frequently or be backed with very strong
arguments that ACLs are required in that particular way. (And in both
cases there would still have be conflicts in the way how git handles
permissions - we wouldn't care otherwise.) But no such case has turned up
so far.
-- Hannes
^ permalink raw reply
* Re: Git graph on GitHub
From: Michael J Gruber @ 2008-10-15 8:24 UTC (permalink / raw)
To: Tom Werner; +Cc: git
In-Reply-To: <530345950810150047v75bfbf9clebbb8a406b172c4c@mail.gmail.com>
Tom Werner venit, vidit, dixit 15.10.2008 09:47:
> We've just pushed out an update to the Network Graph on GitHub this
> evening that finally allows us to draw very large repositories
> (including Git). We're mirroring the Git repo on the site and I
> thought it might be interesting for people to see this visualization.
> Enjoy!
>
> http://github.com/git/git/network
>
> Let me know if you have any ideas for improvements on the graph. I'm
> always looking for ways to enhance it.
Nice graph. The numbers in the grey bar are cut off around the middle,
though (FF 3 on Kubuntu Linux). Is there a way to display branch labels
other than master? Maybe the commit overlays could list all branches a
commit belongs to (like gitk does).
One nitpick regarding your git.git mirror: I doubt that people here
("the community") consider git-scm.com to be "the git homepage". I don't
want to go into the reasons and start a pointless thread, but since
git-scm.com is a fork of git.or.cz pointing to the latter (the root)
should make everyone happy.
Michael
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #03; Tue, 14)
From: Johannes Sixt @ 2008-10-15 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <7v8wsq7rt5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> * pb/rename-rowin32 (Sun Oct 12 21:01:23 2008 -0700) 2 commits
> - (squash): index-pack: do not unconditionally make packfile read-
> only
> - Do not rename read-only files during a push
>
> Supposedly fixes pack file renames on Windows. The (squash) patch is my
> attempt to fix its breakage.
I'm afraid I can't reproduce the problem that the commit message
describes. (But then I don't know whether I understand it correctly
because it talks about "push to local repository", and I'm not sure how to
read this).
Googling around indicates that this is a Samba bug:
http://lists.samba.org/archive/samba/2005-July/108941.html
OTOH, svn has considered a workaround for a similar problem just last week:
http://www.nabble.com/-PATCH--Fix-for-renaming-errors-on-Samba-working-copies.-td19854585.html
I cannot tell what the situation with current Samba versions is. Pasky?
-- Hannes
^ permalink raw reply
* Re: [PATCH] Introduce core.keepHardLinks
From: Johannes Schindelin @ 2008-10-15 9:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63nw9xor.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 13 Oct 2008, Junio C Hamano wrote:
> You could have said something like "The users may want to have a
> checkout, and keep the same contents always appear elsewhere i.e.
> 'installing by hardlinking'. In such a setup, editing the source with
> an editor configured not to break hardlinks would still work fine, but
> git-checkout will unconditionally break such links, which is
> undesirable. Such a setup would want a configuration variable like
> this."
Sounds very nice. Sorry for being grumpy, and not being able to come up
with such a beautiful description.
> The documentation update needs to warn about the Shawn's scenario. I also
> do not know what this should do when you have two tracked paths with
> identical contents hardlinked to each other.
When the user does that, it's the user's wish. I'd not let Git play cute
games with that.
> It also raises another question. Don't you want this to be an attribute
> for paths, not all-or-nothing configuration per repository?
I'd rather not have it as an attribute, because it is not so much about
file types that should show this behavior. It is more like an option that
I fully expect to be set in $HOME/.gitconfig.
Ciao,
Dscho
^ permalink raw reply
* git-scm.com (was Re: Git graph on GitHub)
From: PJ Hyett @ 2008-10-15 10:18 UTC (permalink / raw)
To: git
In-Reply-To: <bab6a2ab0810150315l273d4ef3k95cda8f43a4745ca@mail.gmail.com>
> One nitpick regarding your git.git mirror: I doubt that people here
> ("the community") consider git-scm.com to be "the git homepage". I don't
> want to go into the reasons and start a pointless thread, but since
> git-scm.com is a fork of git.or.cz pointing to the latter (the root)
> should make everyone happy.
Hi Michael,
I'll go ahead and start a pointless thread along with the reasons
provided via answers to the 2008 Git Survey[1]:
43) What could be improved on the Git homepage(s)?
* Use git-scm.com instead of git.or.cz as the default homepage
* Learn from git-scm.com. Make it more newbie-friendly. More focus on
documentation
* Better graphical design/organization - new(?) git-scm.com looks better
* Look at git-scm.com :)
* Cleaner design, better organization (http://git-scm.com/ is a good start).
* Design - git-scm.com is superior compared to git.or.cz. Also the
first one is more user-friendly having exposed more important things
for users rather for experienced veterans who want to download most
current git release.
* I like what Scott Chacon has done with http://git-scm.com
* I prefer Scot Chacons rewrite, but mostly just it's look and feel.
The original site is perfectly functional; though it could do with
better documentation.
* git-scm.com
* git-scm.com is a great example of some light improvement. I do think
that the online man-page navigation is a little annoying, having to
revert to find in the browser to get to the right spot on the page. An
alternate alphabetical listing might help.
* Don't put everything on the first page, it is a little confusing.
Create categories, like download, documentation, About git and at
least a dedicated page for each of these categories. I think the
"design" could also be improved. I saw a proposition not long ago
aboutr a new git homepage on the mailing list: www.git-scm.com. I
think this site is easier to navigate and thus makes it easier to find
informations.
* I like the new git-scm site (with the blob committed to storing trees)
* Merge with Git-scm page?
* I like <http://www.git-scm.com> very much. I'd vote for it to be the
official Git homepage.
* git.or.cz?? I prefer http://git-scm.com/, it's better for beginners,
and the information is nicely presented (doc, tips, videos..).
* promote git-scm.com instead of git.or.cz
* See http://git-scm.com/
* I think git-scm.com is starting to get things right. Making
documentation readily available especially.
* Complete re-design by somebody actually the least bit proficient in
design? Oh wait, that's already been done at http://git-scm.com/.
* Rather ugly design. git-scm.com looks much better.
* I like Scott Chacon's site a lot and use it often: http://git-scm.com/
* Compare #1 and #2 1) http://git-scm.com 2) http://git.or.cz
* http://git.or.cz and http://git-scm.com should be merged
* http://git-scm.com/ is a worderfull project, making the homepage
look and feel much better and "user friendly". The source code is at
http://github.com/schacon/gitscm. What about using this as the Git
official homepage (not the domain, but the interface and images).
* git-scm.com should be the official page :)
* Organization and flow particularly for new users. I think Scott
Chacon's git-scm.com site does a much better job. Organization and
navigation of the content are the things that make it a winner.
* The www.git-scm.com homepage is great.
* Which one? http://git.or.cz/ or http://git-scm.com/ I tend to use
git-scm.com just because it looks nicer, is written in Rails and has
more user friendly information. Rather than browsing what feels like
"A manual online" that is git.or.cz
* I think the homepage (http://git-scm.com/) however work should be
done to have that come ahead of http://git.or.cz/ which currently tops
all the queries. I would try to strike a deal with that domain to
http-redirect to the new url. I can only imagine that this duplication
leads to confusion and a bad experience.
* It should look more like http://git-scm.com
* http://git-scm.com/ > git.or.cz -scm has all the info I might want
up front in one page, while my eyes gloss over just looking at or.cz.
Cheers,
PJ Hyett
http://github.com/pjhyett
1. http://www.survs.com/app/4/wo/IQ2m9AwQ2qFAVwuZrRLF4w/0.0.9.3.3.0.1.3.42.1.7.1
^ permalink raw reply
* Re: retrieving a diff from git
From: Christian Jaeger @ 2008-10-15 10:12 UTC (permalink / raw)
To: Folkert van Heusden; +Cc: Alex Riesen, git
In-Reply-To: <20081014172048.GW22427@vanheusden.com>
Folkert van Heusden wrote:
>> Well, you can of course just click on "commitdiff" (and "raw" afterwords)
>> for every commit,
>>
>
> Hmmm the outcome does not apply cleanly to 2.6.27.
>
>
>> but ... Have you considered using Git for that?
>>
>
> and check out the whole tree using Git? I did consider but then I would
> not have all bells and whistles to generate a Debian kernel package.
>
I'm tempted to think that you should move (merge / cherry-pick or
rebase) the relevant changes onto 2.6.27 using Git, and then take the
diff from there (on the theory that Git could reduce the number of
conflicts that you would have to resolve manually, although I'm not sure
how much this is the case); the resulting diff will then apply cleanly
to a 2.6.27 tarball without using Git.
Christian.
^ 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