* Re: why still no empty directory support in git
From: Johannes Schindelin @ 2008-12-30 12:09 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320812291942y6aeec941k9394586621e9151b@mail.gmail.com>
Hi,
On Tue, 30 Dec 2008, Ping Yin wrote:
> Yes, i know this topic has been discussed for many times.
We have empty directory support in Git. It works like this: for
directories that you do want to keep, you add an empty .gitignore file.
No problem at all,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-shortlog.c: use string_list_append() instead of duplicating its code
From: Johannes Schindelin @ 2008-12-30 12:20 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git, gitster
In-Reply-To: <1230136476-11081-1-git-send-email-dato@net.com.org.es>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 557 bytes --]
Hi,
On Wed, 24 Dec 2008, Adeodato Simó wrote:
> Also, when clearing the "onelines" string lists, do not free the "util"
> member: with string_list_append() is not initialized to any value (and
> was being initialized to NULL previously anyway).
>
> NB: The duplicated code in builtin-shortlog.c predated the appearance of
> string_list_append().
>
> Signed-off-by: Adeodato Simó <dato@net.com.org.es>
FWIW I like the patch, but would like it even more if the strdup() removal
was squashed in (with an explanation in the commit message).
Ciao,
Dscho
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 12:19 UTC (permalink / raw)
To: git
In-Reply-To: <3ab397d0812292133r7955e892g6c19ca46629e7103@mail.gmail.com>
> I have been using $ git reset --hard <version> as an escalator to ascend /
> descend the versions up and down
you should probably be using git checkout for this
> Surely it doesn't alter the history, as I can commit versionA, versionB,
> versionC, and then reset to A, then reset to C, then reset to B.
i does alter the history. i think this works because git isnt'
deleting the actual blob objects in the git dir until you use the git
prune, or gc or whatever (i never use it anyway). but, you are
altering history, and just happen to be recovering.
** Ok!, so after commit B1, versionA doesn't store a link to versionB
natively on and of its own accord. In other words BA and C are now written
OUT of the history, as you say. I'm relying on some cached meta data that
allows me to go back up the version tree again (ie downstream) and write B
and/or C back into the history, which I should not rely on having access to
all the time. Now I'm understanding more about differences between git-reset
and git-checkout
> so when I reset to A, I've still got the ability to get to B or C again
with an uneasy conscience ;)
** yes, if the metadata cache failed or got wiped, I'd be screwed for
getting back to later commits
I see !
I'm relying on something that isn't part of the intrinsic design... hmmm
> Now I appreciate that if I commit a new change from versionA (lets call it
> B1), then HEAD is now at B1, and B, C etc are lost, correct ?
yes! but this is not true if you had done a git checkout (there are
measures to recover B and C, provided you haven't done a prune. i
think git reflog has some answers here, but i'm still a newbie).
> Its pertinent to where I am right now, as I've goofed a commit, and want
> to
> reset, and commit again but I'm worried about leaveing garbage lying
> around
> (the commits for version B and C in the example above).
you've goofed what commit (a1?, c?, d3?)? where are you now and what
do you want to do now? reset to what version? if you're just worried
about space used by B and C, i think git prune will purge these (look
at man page, don't guess at the syntax).
** I goofed B, so I reset to A, and redid the edits correctly this time
(using your tip from other post $ git add -A = thanks again!), so now am on
B1.
Having read your notes, I am now comfortable about letting B and C hang
around, as I realise now they are out of the official picture. Sitaram's
comparison of a linked list helps since there is no branch/merge: B1 can
only have one parent, which is A, so A can only have one child which is B1
(and B and C are relying on the cached stuff to survive, so let 'em freeze
!)
i half suspect that you want to git branch at some point, but if
yo'ure just recretaing the other code bases' history form other files,
you shouldn't be able to break too much by git reset --hard, or git
prune.
** yes I might well want to at some point, but don't want to run before
walking. I'm the only one on this project currently, and still archiving old
versions into git. When I get the latest one in, I may branch so I can work
away without affecting a stable master branch.
^ permalink raw reply
* Re: rebase -i: learn to rebase root commit
From: Thomas Rast @ 2008-12-30 12:23 UTC (permalink / raw)
To: git; +Cc: Boyd Stephen Smith Jr.
In-Reply-To: <200812291621.35732.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]
Boyd Stephen Smith Jr. wrote:
> Here's the interpretation that *I* come up with for -p --root used together:
> The commit with no parents (OLD_ROOT) is rebased as if -p were not given, call
> the resulting commit NEW_ROOT. Then, the rebase continues as if "--onto
> NEW_ROOT OLD_ROOT <branch>" was specified instead of "--onto=NEW_ROOT^ --root
> <branch>".
I like this logic, but it feels inconsistent as soon as there are
several root commits. (This may be somewhat academic, since any repo
with several roots should also be able to cope with a merge...)
Some digging into the -p code shows that it knows which commits were
rewritten, and which were untouched. It rewrites such that _all_
commits in $(git merge-base --all $branch $upstream) are rewritten to
look like $onto instead, i.e., all their occurrences in parent lists
of commits are rewritten to $onto. All other commits are only
rewritten if they have a parent that was rewritten.
So I think one sane way is to define a virtual parent 'root', and
think of parentless commits as having the (sole) parent 'root'. Then
we can rewrite such that 'root' becomes $onto, i.e., all occurrences
of 'root' in parent lists become $onto, consistent with the normal
operation. (For the other commits, the same rule as above is
applied.)
Of course this just boils down to saying that _all_ root commits
reachable from $branch are rewritten to have $onto as their parent.
Subsequently, all other commits will also be rewritten because they
all must have at least one rewritten parent.
> Basically, --root only changes how the first commit is handled, which I think
> is consistent with other uses of --root. It's also similar to cherry-picking
> the first commit, follwed by a non-root rebase, which I think is also
> consistent with the intention of --root.
I believe this remark still holds if there is only a single root
commit on $branch.
I will reroll with an updated 2/3 shortly.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH v2 2/3] rebase -i: learn to rebase root commit
From: Thomas Rast @ 2008-12-30 12:29 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7b2902d36a4790670f20f786d4ea2e26052a6e71.1230639970.git.trast@student.ethz.ch>
Teach git-rebase -i a new option --root, which instructs it to rebase
the entire history leading up to <branch>. This is mainly for
symmetry with ordinary git-rebase; it cannot be used to edit the root
commit in-place (it requires --onto).
In the normal mode of operation, this is fairly straightforward. We
run cherry-pick in a loop, and cherry-pick has supported picking the
root commit since f95ebf7 (Allow cherry-picking root commits,
2008-07-04).
In --preserve-merges mode, we track the mapping from old to rewritten
commits and use it to update the parent list of each commit. In this
case, we define 'rebase -i -p --root --onto $onto $branch' to rewrite
the parent list of all root commit(s) on $branch to contain $onto
instead.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Changes since v1: also supports -p --root, with tests.
git-rebase--interactive.sh | 99 +++++++++++++++++++++++++++++++------------
t/t3412-rebase-root.sh | 82 ++++++++++++++++++++++++++++++++++++
2 files changed, 153 insertions(+), 28 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c8b0861..d6f54eb 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -27,6 +27,7 @@ continue continue rebasing process
abort abort rebasing process and restore original branch
skip skip current patch and continue rebasing process
no-verify override pre-rebase hook from stopping the operation
+root rebase all reachable commmits up to the root(s)
"
. git-sh-setup
@@ -44,6 +45,7 @@ STRATEGY=
ONTO=
VERBOSE=
OK_TO_SKIP_PRE_REBASE=
+REBASE_ROOT=
GIT_CHERRY_PICK_HELP=" After resolving the conflicts,
mark the corrected paths with 'git add <paths>', and
@@ -154,6 +156,11 @@ pick_one () {
output git rev-parse --verify $sha1 || die "Invalid commit name: $sha1"
test -d "$REWRITTEN" &&
pick_one_preserving_merges "$@" && return
+ if test ! -z "$REBASE_ROOT"
+ then
+ output git cherry-pick "$@"
+ return
+ fi
parent_sha1=$(git rev-parse --verify $sha1^) ||
die "Could not get the parent of $sha1"
current_sha1=$(git rev-parse --verify HEAD)
@@ -197,7 +204,11 @@ pick_one_preserving_merges () {
# rewrite parents; if none were rewritten, we can fast-forward.
new_parents=
- pend=" $(git rev-list --parents -1 $sha1 | cut -d' ' -f2-)"
+ pend=" $(git rev-list --parents -1 $sha1 | cut -d' ' -s -f2-)"
+ if test "$pend" = " "
+ then
+ pend=" root"
+ fi
while [ "$pend" != "" ]
do
p=$(expr "$pend" : ' \([^ ]*\)')
@@ -443,6 +454,7 @@ get_saved_options () {
test -d "$REWRITTEN" && PRESERVE_MERGES=t
test -f "$DOTEST"/strategy && STRATEGY="$(cat "$DOTEST"/strategy)"
test -f "$DOTEST"/verbose && VERBOSE=t
+ test ! -s "$DOTEST"/upstream && REBASE_ROOT=t
}
while test $# != 0
@@ -547,6 +559,9 @@ first and then run 'git rebase --continue' again."
-i)
# yeah, we know
;;
+ --root)
+ REBASE_ROOT=t
+ ;;
--onto)
shift
ONTO=$(git rev-parse --verify "$1") ||
@@ -555,7 +570,7 @@ first and then run 'git rebase --continue' again."
--)
shift
run_pre_rebase_hook ${1+"$@"}
- test $# -eq 1 -o $# -eq 2 || usage
+ test ! -z "$REBASE_ROOT" -o $# -eq 1 -o $# -eq 2 || usage
test -d "$DOTEST" &&
die "Interactive rebase already started"
@@ -566,15 +581,22 @@ first and then run 'git rebase --continue' again."
require_clean_work_tree
- UPSTREAM=$(git rev-parse --verify "$1") || die "Invalid base"
- test -z "$ONTO" && ONTO=$UPSTREAM
+ if test -z "$REBASE_ROOT"
+ then
+ UPSTREAM=$(git rev-parse --verify "$1") || die "Invalid base"
+ test -z "$ONTO" && ONTO=$UPSTREAM
+ shift
+ else
+ test -z "$ONTO" &&
+ die "You must specify --onto when using --root"
+ fi
- if test ! -z "$2"
+ if test ! -z "$1"
then
- output git show-ref --verify --quiet "refs/heads/$2" ||
- die "Invalid branchname: $2"
- output git checkout "$2" ||
- die "Could not checkout $2"
+ output git show-ref --verify --quiet "refs/heads/$1" ||
+ die "Invalid branchname: $1"
+ output git checkout "$1" ||
+ die "Could not checkout $1"
fi
HEAD=$(git rev-parse --verify HEAD) || die "No HEAD?"
@@ -598,12 +620,19 @@ first and then run 'git rebase --continue' again."
# This ensures that commits on merged, but otherwise
# unrelated side branches are left alone. (Think "X"
# in the man page's example.)
- mkdir "$REWRITTEN" &&
- for c in $(git merge-base --all $HEAD $UPSTREAM)
- do
- echo $ONTO > "$REWRITTEN"/$c ||
+ if test -z "$REBASE_ROOT"
+ then
+ mkdir "$REWRITTEN" &&
+ for c in $(git merge-base --all $HEAD $UPSTREAM)
+ do
+ echo $ONTO > "$REWRITTEN"/$c ||
+ die "Could not init rewritten commits"
+ done
+ else
+ mkdir "$REWRITTEN" &&
+ echo $ONTO > "$REWRITTEN"/root ||
die "Could not init rewritten commits"
- done
+ fi
# No cherry-pick because our first pass is to determine
# parents to rewrite and skipping dropped commits would
# prematurely end our probe
@@ -613,12 +642,21 @@ first and then run 'git rebase --continue' again."
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)
+ if test -z "$REBASE_ROOT"
+ # this is now equivalent to ! -z "$UPSTREAM"
+ then
+ SHORTUPSTREAM=$(git rev-parse --short $UPSTREAM)
+ REVISIONS=$UPSTREAM...$HEAD
+ SHORTREVISIONS=$SHORTUPSTREAM..$SHORTHEAD
+ else
+ REVISIONS=$HEAD
+ SHORTREVISIONS=$SHORTHEAD
+ fi
git rev-list $MERGES_OPTION --pretty=oneline --abbrev-commit \
--abbrev=7 --reverse --left-right --topo-order \
- $UPSTREAM...$HEAD | \
+ $REVISIONS | \
sed -n "s/^>//p" | while read shortsha1 rest
do
if test t != "$PRESERVE_MERGES"
@@ -626,14 +664,19 @@ first and then run 'git rebase --continue' again."
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 -a \( $p != $UPSTREAM -o $sha1 = $first_after_upstream \)
- then
- preserve=f
- fi
- done
+ if test -z "$REBASE_ROOT"
+ then
+ preserve=t
+ for p in $(git rev-list --parents -1 $sha1 | cut -d' ' -s -f2-)
+ do
+ if test -f "$REWRITTEN"/$p -a \( $p != $UPSTREAM -o $sha1 = $first_after_upstream \)
+ then
+ preserve=f
+ fi
+ done
+ else
+ preserve=f
+ fi
if test f = "$preserve"
then
touch "$REWRITTEN"/$sha1
@@ -647,11 +690,11 @@ first and then run 'git rebase --continue' again."
then
mkdir "$DROPPED"
# Save all non-cherry-picked changes
- git rev-list $UPSTREAM...$HEAD --left-right --cherry-pick | \
+ git rev-list $REVISIONS --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 |
+ git rev-list $REVISIONS |
while read rev
do
if test -f "$REWRITTEN"/$rev -a "$(grep "$rev" "$DOTEST"/not-cherry-picks)" = ""
@@ -660,7 +703,7 @@ first and then run 'git rebase --continue' again."
# 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
+ git rev-list --parents -1 $rev | cut -d' ' -s -f2 > "$DROPPED"/$rev
short=$(git rev-list -1 --abbrev-commit --abbrev=7 $rev)
grep -v "^[a-z][a-z]* $short" <"$TODO" > "${TODO}2" ; mv "${TODO}2" "$TODO"
rm "$REWRITTEN"/$rev
@@ -670,7 +713,7 @@ first and then run 'git rebase --continue' again."
test -s "$TODO" || echo noop >> "$TODO"
cat >> "$TODO" << EOF
-# Rebase $SHORTUPSTREAM..$SHORTHEAD onto $SHORTONTO
+# Rebase $SHORTREVISIONS onto $SHORTONTO
#
# Commands:
# p, pick = use commit
diff --git a/t/t3412-rebase-root.sh b/t/t3412-rebase-root.sh
index 63ec5e6..c845dfc 100755
--- a/t/t3412-rebase-root.sh
+++ b/t/t3412-rebase-root.sh
@@ -49,4 +49,86 @@ test_expect_success 'rebase --root --onto <newbase> <branch>' '
test_cmp expect rebased2
'
+test_expect_success 'rebase -i --root --onto <newbase>' '
+ git checkout -b work3 other &&
+ GIT_EDITOR=: git rebase -i --root --onto master &&
+ git log --pretty=tformat:"%s" > rebased3 &&
+ test_cmp expect rebased3
+'
+
+test_expect_success 'rebase -i --root --onto <newbase> <branch>' '
+ git branch work4 other &&
+ GIT_EDITOR=: git rebase -i --root --onto master work4 &&
+ git log --pretty=tformat:"%s" > rebased4 &&
+ test_cmp expect rebased4
+'
+
+test_expect_success 'rebase -i -p with linear history' '
+ git checkout -b work5 other &&
+ GIT_EDITOR=: git rebase -i -p --root --onto master &&
+ git log --pretty=tformat:"%s" > rebased5 &&
+ test_cmp expect rebased5
+'
+
+test_expect_success 'set up merge history' '
+ git checkout other^ &&
+ git checkout -b side &&
+ echo 5 > C &&
+ git add C &&
+ git commit -m 5 &&
+ git checkout other &&
+ git merge side
+'
+
+sed 's/#/ /g' > expect-side <<'EOF'
+* Merge branch 'side' into other
+|\##
+| * 5
+* | 4
+|/##
+* 3
+* 2
+* 1
+EOF
+
+test_expect_success 'rebase -i -p with merge' '
+ git checkout -b work6 other &&
+ GIT_EDITOR=: git rebase -i -p --root --onto master &&
+ git log --graph --topo-order --pretty=tformat:"%s" > rebased6 &&
+ test_cmp expect-side rebased6
+'
+
+test_expect_success 'set up second root and merge' '
+ git symbolic-ref HEAD refs/heads/third &&
+ rm .git/index &&
+ rm A B C &&
+ echo 6 > D &&
+ git add D &&
+ git commit -m 6 &&
+ git checkout other &&
+ git merge third
+'
+
+sed 's/#/ /g' > expect-third <<'EOF'
+* Merge branch 'third' into other
+|\##
+| * 6
+* | Merge branch 'side' into other
+|\ \##
+| * | 5
+* | | 4
+|/ /##
+* | 3
+|/##
+* 2
+* 1
+EOF
+
+test_expect_success 'rebase -i -p with two roots' '
+ git checkout -b work7 other &&
+ GIT_EDITOR=: git rebase -i -p --root --onto master &&
+ git log --graph --topo-order --pretty=tformat:"%s" > rebased7 &&
+ test_cmp expect-third rebased7
+'
+
test_done
--
1.6.1.20.g7f5c5.dirty
^ permalink raw reply related
* [PATCH v2 1/3] rebase: learn to rebase root commit
From: Thomas Rast @ 2008-12-30 12:29 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <200812301323.30550.trast@student.ethz.ch>
Teach git-rebase a new option --root, which instructs it to rebase the
entire history leading up to <branch>.
The main use-case is with git-svn: suppose you start hacking (perhaps
offline) on a new project, but later notice you want to commit this
work to SVN. You will have to rebase the entire history, including
the root commit, on a (possibly empty) commit coming from git-svn, to
establish a history connection. This previously had to be done by
cherry-picking the root commit manually.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
No changes since v1.
git-rebase.sh | 51 ++++++++++++++++++++++++++++++++--------------
t/t3412-rebase-root.sh | 52 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 87 insertions(+), 16 deletions(-)
create mode 100755 t/t3412-rebase-root.sh
diff --git a/git-rebase.sh b/git-rebase.sh
index ebd4df3..89de3c4 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Junio C Hamano.
#
-USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]'
+USAGE='[--interactive | -i] [-v] [--onto <newbase>] [<upstream>|--root] [<branch>]'
LONG_USAGE='git-rebase replaces <branch> with a new branch of the
same name. When the --onto option is provided the new branch starts
out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>
@@ -47,6 +47,7 @@ dotest="$GIT_DIR"/rebase-merge
prec=4
verbose=
git_am_opt=
+rebase_root=
continue_merge () {
test -n "$prev_head" || die "prev_head must be defined"
@@ -297,6 +298,9 @@ do
-C*)
git_am_opt="$git_am_opt $1"
;;
+ --root)
+ rebase_root=t
+ ;;
-*)
usage
;;
@@ -344,17 +348,23 @@ case "$diff" in
;;
esac
+if test -z "$rebase_root"; then
# The upstream head must be given. Make sure it is valid.
-upstream_name="$1"
-upstream=`git rev-parse --verify "${upstream_name}^0"` ||
- die "invalid upstream $upstream_name"
+ upstream_name="$1"
+ shift
+ upstream=`git rev-parse --verify "${upstream_name}^0"` ||
+ die "invalid upstream $upstream_name"
+fi
+
+test ! -z "$rebase_root" -a -z "$newbase" &&
+ die "--root must be used with --onto"
# Make sure the branch to rebase onto is valid.
onto_name=${newbase-"$upstream_name"}
onto=$(git rev-parse --verify "${onto_name}^0") || exit
# If a hook exists, give it a chance to interrupt
-run_pre_rebase_hook ${1+"$@"}
+run_pre_rebase_hook ${upstream_name+"$upstream_name"} "$@"
# If the branch to rebase is given, that is the branch we will rebase
# $branch_name -- branch being rebased, or HEAD (already detached)
@@ -362,16 +372,16 @@ run_pre_rebase_hook ${1+"$@"}
# $head_name -- refs/heads/<that-branch> or "detached HEAD"
switch_to=
case "$#" in
-2)
+1)
# Is it "rebase other $branchname" or "rebase other $commit"?
- branch_name="$2"
- switch_to="$2"
+ branch_name="$1"
+ switch_to="$1"
- if git show-ref --verify --quiet -- "refs/heads/$2" &&
- branch=$(git rev-parse -q --verify "refs/heads/$2")
+ if git show-ref --verify --quiet -- "refs/heads/$1" &&
+ branch=$(git rev-parse -q --verify "refs/heads/$1")
then
- head_name="refs/heads/$2"
- elif branch=$(git rev-parse -q --verify "$2")
+ head_name="refs/heads/$1"
+ elif branch=$(git rev-parse -q --verify "$1")
then
head_name="detached HEAD"
else
@@ -393,7 +403,8 @@ case "$#" in
esac
orig_head=$branch
-# Now we are rebasing commits $upstream..$branch on top of $onto
+# Now we are rebasing commits $upstream..$branch (or simply $branch
+# with --root) on top of $onto
# Check if we are already based on $onto with linear history,
# but this should be done only when upstream and onto are the same.
@@ -429,10 +440,18 @@ then
exit 0
fi
+if test ! -z "$rebase_root"; then
+ revisions="$orig_head"
+ fp_flag="--root"
+else
+ revisions="$upstream..$orig_head"
+ fp_flag="--ignore-if-in-upstream"
+fi
+
if test -z "$do_merge"
then
- git format-patch -k --stdout --full-index --ignore-if-in-upstream \
- "$upstream..$orig_head" |
+ git format-patch -k --stdout --full-index "$fp_flag" \
+ "$revisions" |
git am $git_am_opt --rebasing --resolvemsg="$RESOLVEMSG" &&
move_to_original_branch
ret=$?
@@ -455,7 +474,7 @@ echo "$orig_head" > "$dotest/orig-head"
echo "$head_name" > "$dotest/head-name"
msgnum=0
-for cmt in `git rev-list --reverse --no-merges "$upstream..$orig_head"`
+for cmt in `git rev-list --reverse --no-merges "$revisions"`
do
msgnum=$(($msgnum + 1))
echo "$cmt" > "$dotest/cmt.$msgnum"
diff --git a/t/t3412-rebase-root.sh b/t/t3412-rebase-root.sh
new file mode 100755
index 0000000..63ec5e6
--- /dev/null
+++ b/t/t3412-rebase-root.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+test_description='git rebase --root
+
+Tests if git rebase --root --onto <newparent> can rebase the root commit.
+'
+. ./test-lib.sh
+
+test_expect_success 'prepare repository' '
+ echo 1 > A &&
+ git add A &&
+ git commit -m 1 &&
+ echo 2 > A &&
+ git add A &&
+ git commit -m 2 &&
+ git symbolic-ref HEAD refs/heads/other &&
+ rm .git/index &&
+ rm A &&
+ echo 3 > B &&
+ git add B &&
+ git commit -m 3 &&
+ echo 4 > B &&
+ git add B &&
+ git commit -m 4
+'
+
+test_expect_success 'rebase --root expects --onto' '
+ test_must_fail git rebase --root
+'
+
+cat > expect <<EOF
+4
+3
+2
+1
+EOF
+
+test_expect_success 'rebase --root --onto <newbase>' '
+ git checkout -b work &&
+ git rebase --root --onto master &&
+ git log --pretty=tformat:"%s" > rebased &&
+ test_cmp expect rebased
+'
+
+test_expect_success 'rebase --root --onto <newbase> <branch>' '
+ git branch work2 other &&
+ git rebase --root --onto master work2 &&
+ git log --pretty=tformat:"%s" > rebased2 &&
+ test_cmp expect rebased2
+'
+
+test_done
--
1.6.1.20.g7f5c5.dirty
^ permalink raw reply related
* [PATCH v2 3/3] rebase: update documentation for --root
From: Thomas Rast @ 2008-12-30 12:29 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7b2902d36a4790670f20f786d4ea2e26052a6e71.1230639970.git.trast@student.ethz.ch>
Since the new option depends on --onto and omission of <upstream>, use
a separate invocation style, and omit most options to save space.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Changed since v1: remark about the effect of --root --preserve-merges.
Documentation/git-rebase.txt | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index c8ad86a..e3b4b83 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -8,10 +8,11 @@ git-rebase - Forward-port local commits to the updated upstream head
SYNOPSIS
--------
[verse]
-'git rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
- [-s <strategy> | --strategy=<strategy>] [--no-verify]
- [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
- [--onto <newbase>] <upstream> [<branch>]
+'git rebase' [-i | --interactive] [options] [--onto <newbase>]
+ <upstream> [<branch>]
+'git rebase' [-i | --interactive] [options] --onto <newbase>
+ --root [<branch>]
+
'git rebase' --continue | --skip | --abort
DESCRIPTION
@@ -22,7 +23,8 @@ it remains on the current branch.
All changes made by commits in the current branch but that are not
in <upstream> are saved to a temporary area. This is the same set
-of commits that would be shown by `git log <upstream>..HEAD`.
+of commits that would be shown by `git log <upstream>..HEAD` (or
+`git log HEAD`, if --root is specified).
The current branch is reset to <upstream>, or <newbase> if the
--onto option was supplied. This has the exact same effect as
@@ -255,6 +257,13 @@ OPTIONS
--preserve-merges::
Instead of ignoring merges, try to recreate them.
+--root::
+ Rebase all commits reachable from <branch>, instead of
+ limiting them with an <upstream>. This allows you to rebase
+ the root commit(s) on a branch. Must be used with --onto.
+ When used together with --preserve-merges, 'all' root commits
+ will be rewritten to have <newbase> as parent instead.
+
include::merge-strategies.txt[]
NOTES
--
1.6.1.20.g7f5c5.dirty
^ permalink raw reply related
* Re: [PATCH] git-cherry: make <upstream> parameter optional
From: Johannes Schindelin @ 2008-12-30 13:13 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: git
In-Reply-To: <200812291845.20500.markus.heidelberg@web.de>
Hi,
On Mon, 29 Dec 2008, Markus Heidelberg wrote:
> The upstream branch <upstream> now defaults to the first tracked
> remote branch, which is set by the configuration variables
> branch.<name>.remote and branch.<name>.merge of the current branch.
>
> Without such a remote branch, the command "git cherry [-v]" fails with
> usage output as before and an additional message.
>
> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
This would be a massively visible user interface change. At the moment,
it does this (which I like):
$ git cherry-pick
usage: git cherry-pick [options] <commit-ish>
-n, --no-commit don't automatically commit
-e, --edit edit the commit message
-x append commit name when cherry-picking
-r no-op (backward compatibility)
-s, --signoff add Signed-off-by:
-m, --mainline <n> parent number
Opposed,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cherry: make <upstream> parameter optional
From: Markus Heidelberg @ 2008-12-30 13:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812301411480.30769@pacific.mpi-cbg.de>
Johannes Schindelin, 30.12.2008:
> Hi,
>
> On Mon, 29 Dec 2008, Markus Heidelberg wrote:
>
> > The upstream branch <upstream> now defaults to the first tracked
> > remote branch, which is set by the configuration variables
> > branch.<name>.remote and branch.<name>.merge of the current branch.
> >
> > Without such a remote branch, the command "git cherry [-v]" fails with
> > usage output as before and an additional message.
> >
> > Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
>
> This would be a massively visible user interface change. At the moment,
> it does this (which I like):
>
> $ git cherry-pick
> usage: git cherry-pick [options] <commit-ish>
>
> -n, --no-commit don't automatically commit
> -e, --edit edit the commit message
> -x append commit name when cherry-picking
> -r no-op (backward compatibility)
> -s, --signoff add Signed-off-by:
> -m, --mainline <n> parent number
>
> Opposed,
> Dscho
The patch was about git-cherry, not git-cherry-pick.
Markus
^ permalink raw reply
* Re: [PATCH] git-cherry: make <upstream> parameter optional
From: Johannes Schindelin @ 2008-12-30 13:44 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: git
In-Reply-To: <200812301437.06726.markus.heidelberg@web.de>
Hi,
On Tue, 30 Dec 2008, Markus Heidelberg wrote:
> Johannes Schindelin, 30.12.2008:
>
> > On Mon, 29 Dec 2008, Markus Heidelberg wrote:
> >
> > > The upstream branch <upstream> now defaults to the first tracked
> > > remote branch, which is set by the configuration variables
> > > branch.<name>.remote and branch.<name>.merge of the current branch.
> > >
> > > Without such a remote branch, the command "git cherry [-v]" fails
> > > with usage output as before and an additional message.
> > >
> > > Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
> >
> > This would be a massively visible user interface change. At the moment,
> > it does this (which I like):
> >
> > $ git cherry-pick
> > usage: git cherry-pick [options] <commit-ish>
> >
> > -n, --no-commit don't automatically commit
> > -e, --edit edit the commit message
> > -x append commit name when cherry-picking
> > -r no-op (backward compatibility)
> > -s, --signoff add Signed-off-by:
> > -m, --mainline <n> parent number
>
> The patch was about git-cherry, not git-cherry-pick.
Oops.
Sorry,
Dscho
P.S.: This certainly will not be the last time that I am bitten by the
closeness of the names "cherry" (which I _never_ use) and "cherry-pick",
which I use frequently. Even worse: the rev-list option that could make
that stand-alone plumbing command "cherry" obsolete is called
_--cherry-pick_, of all things...
^ permalink raw reply
* Re: [PATCH] git-cherry: make <upstream> parameter optional
From: demerphq @ 2008-12-30 14:02 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200812291845.20500.markus.heidelberg@web.de>
2008/12/29 Markus Heidelberg <markus.heidelberg@web.de>:
> The upstream branch <upstream> now defaults to the first tracked
> remote branch, which is set by the configuration variables
> branch.<name>.remote and branch.<name>.merge of the current branch.
>
> Without such a remote branch, the command "git cherry [-v]" fails with
> usage output as before and an additional message.
>
> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
FWIW: I would find this useful. Thanks for writing it.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: why still no empty directory support in git
From: Michael Gaber @ 2008-12-30 14:21 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812301308530.30769@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
Johannes Schindelin schrieb:
> Hi,
>
> On Tue, 30 Dec 2008, Ping Yin wrote:
>
>> Yes, i know this topic has been discussed for many times.
>
> We have empty directory support in Git. It works like this: for
> directories that you do want to keep, you add an empty .gitignore file.
>
> No problem at all,
> Dscho
well if i understood him correctly his use-case would soon remove that
.whatever-file so it doesn't solve the problem
Michael
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3656 bytes --]
^ permalink raw reply
* [PATCH] Pass --upload-pack and --receive-pack through submodules.
From: Jason Riedy @ 2008-12-30 15:09 UTC (permalink / raw)
To: git; +Cc: Jason Riedy
In-Reply-To: <1230605055-30723-1-git-send-email-jason@acm.org>
While I no longer have to worry about a zillion ancient OS versions,
I now have to worry about a remote site where I cannot control the
path for non-interactive shells. Thus, submodules need to handle
explicitly specified git-upload-pack and git-receive-pack programs.
There may be a fun shell quoting dance to avoid the extra conditionals.
Any such dance would be even more confusing to read.
Signed-off-by: Jason Riedy <jason@acm.org>
---
Sorry; I forgot the documentation patch last time. And it might be
better just to copy the entire submodule config directly to the remote
section...
Documentation/git-submodule.txt | 15 +++++++-
Documentation/gitmodules.txt | 13 ++++++-
git-submodule.sh | 81 +++++++++++++++++++++++++++++++++++++--
t/t7404-submodule-packbin.sh | 53 +++++++++++++++++++++++++
4 files changed, 156 insertions(+), 6 deletions(-)
create mode 100755 t/t7404-submodule-packbin.sh
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 2f207fb..9e2de16 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
[verse]
-'git submodule' [--quiet] add [-b branch] [--] <repository> <path>
+'git submodule' [--quiet] add [-b branch] [-u <git-upload-pack>] [--receive-pack <git-receive-pack>] [--] <repository> <path>
'git submodule' [--quiet] status [--cached] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [--] [<path>...]
@@ -159,6 +159,19 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
+--upload-pack <upload-pack>::
+-u <upload-pack>::
+ When given, and the repository to clone from is accessed
+ via ssh, this specifies a non-default path for the
+ 'git-upload-pack' program on the remote end. See
+ linkgit:git-fetch-pack[1].
+
+--receive-pack <receive-pack>::
+ When given, and the repository to clone from is accessed
+ via ssh, this specifies a non-default path for the
+ 'git-receive-pack' program on the remote end. See
+ linkgit:git-push[1].
+
--cached::
This option is only valid for status and summary commands. These
commands typically use the commit found in the submodule HEAD, but
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index d1a17e2..3387951 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -30,6 +30,13 @@ submodule.<name>.path::
submodule.<name>.url::
Defines an url from where the submodule repository can be cloned.
+submodule.<name>.receivepack::
+ The default program to execute on the remote side when pushing. See
+ option \--receive-pack of linkgit:git-push[1].
+
+submodule.<name>.uploadpack::
+ The default program to execute on the remote side when fetching. See
+ option \--upload-pack of linkgit:git-fetch-pack[1].
EXAMPLES
--------
@@ -42,12 +49,16 @@ Consider the following .gitmodules file:
[submodule "libbar"]
path = include/bar
- url = git://bar.com/git/lib.git
+ url = ssh://bar.com/~/git/lib.git
+ uploadpack = /home/you/bin/git-upload-pack-wrapper
+ receivepack = /home/you/bin/git-receive-pack-wrapper
This defines two submodules, `libfoo` and `libbar`. These are expected to
be checked out in the paths 'include/foo' and 'include/bar', and for both
submodules an url is specified which can be used for cloning the submodules.
+For `libbar`, packs are retrieved and stored via the upload and receive
+wrappers, respectively.
SEE ALSO
--------
diff --git a/git-submodule.sh b/git-submodule.sh
index 2f47e06..1a8a968 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -90,6 +90,8 @@ module_clone()
{
path=$1
url=$2
+ uploadpack=$3
+ receivepack=$4
# If there already is a directory at the submodule path,
# expect it to be empty (since that is the default checkout
@@ -105,8 +107,23 @@ module_clone()
test -e "$path" &&
die "A file already exist at path '$path'"
- git-clone -n "$url" "$path" ||
+ if test "$uploadpack"
+ then
+ git-clone --upload-pack $uploadpack -n "$url" "$path"
+ else
+ git-clone -n "$url" "$path"
+ fi ||
die "Clone of '$url' into submodule path '$path' failed"
+ if test "$uploadpack"
+ then
+ git config -f "${path}/.git/config" remote.origin.uploadpack "$uploadpack" ||
+ echo " Warn: Failed to set uploadpack for '$url' in submodule path '$path'."
+ fi
+ if test "$receivepack"
+ then
+ git config -f "${path}/.git/config" remote.origin.receivepack "$receivepack" ||
+ echo " Warn: Failed to set receivepack for '$url' in submodule path '$path'."
+ fi
}
#
@@ -130,6 +147,16 @@ cmd_add()
-q|--quiet)
quiet=1
;;
+ -u|--upload-pack)
+ case "$2" in '') usage ;; esac
+ uploadpack=$2
+ shift
+ ;;
+ --receive-pack)
+ case "$2" in '') usage ;; esac
+ receivepack=$2
+ shift
+ ;;
--)
shift
break
@@ -191,9 +218,17 @@ cmd_add()
;;
esac
git config submodule."$path".url "$url"
+ if test "$uploadpack"
+ then
+ git config submodule."$path".uploadpack "$uploadpack"
+ fi
+ if test "$receivepack"
+ then
+ git config submodule."$path".receivepack "$receivepack"
+ fi
else
- module_clone "$path" "$realrepo" || exit
+ module_clone "$path" "$realrepo" "$uploadpack" "$receivepack" || exit
(unset GIT_DIR; cd "$path" && git checkout -f -q ${branch:+-b "$branch" "origin/$branch"}) ||
die "Unable to checkout submodule '$path'"
fi
@@ -202,7 +237,19 @@ cmd_add()
die "Failed to add submodule '$path'"
git config -f .gitmodules submodule."$path".path "$path" &&
- git config -f .gitmodules submodule."$path".url "$repo" &&
+ git config -f .gitmodules submodule."$path".url "$repo" ||
+ die "Failed to register submodule '$path'"
+
+ if test "$uploadpack"
+ then
+ git config -f .gitmodules submodule."$path".uploadpack "$uploadpack" ||
+ die "Failed to register submodule '$path'"
+ fi
+ if test "$receivepack"
+ then
+ git config -f .gitmodules submodule."$path".receivepack "$receivepack" ||
+ die "Failed to register submodule '$path'"
+ fi
git add .gitmodules ||
die "Failed to register submodule '$path'"
}
@@ -277,6 +324,19 @@ cmd_init()
git config submodule."$name".url "$url" ||
die "Failed to register url for submodule path '$path'"
+ uploadpack=$(git config -f .gitmodules submodule."$name".uploadpack)
+ receivepack=$(git config -f .gitmodules submodule."$name".receivepack)
+ if test "$uploadpack"
+ then
+ git config submodule."$name".uploadpack "$uploadpack" ||
+ echo " Warn: Failed to set uploadpack for '$url' in submodule path '$path'."
+ fi
+ if test "$receivepack"
+ then
+ git config submodule."$name".receivepack "$receivepack" ||
+ echo " Warn: Failed to set receivepack for '$url' in submodule path '$path'."
+ fi
+
say "Submodule '$name' ($url) registered for path '$path'"
done
}
@@ -330,7 +390,8 @@ cmd_update()
if ! test -d "$path"/.git -o -f "$path"/.git
then
- module_clone "$path" "$url" || exit
+ module_clone "$path" "$url" "$(git config submodule."$name".uploadpack)" \
+ "$(git config submodule."$name".receivepack)" || exit
subsha1=
else
subsha1=$(unset GIT_DIR; cd "$path" &&
@@ -655,6 +716,18 @@ cmd_sync()
remote=$(get_default_remote)
say "Synchronizing submodule url for '$name'"
git config remote."$remote".url "$url"
+ uploadpack=$(git config -f .gitmodules submodule."$name".uploadpack)
+ receivepack=$(git config -f .gitmodules submodule."$name".receivepack)
+ if test "$uploadpack"
+ then
+ git config submodule."$name".uploadpack "$uploadpack" ||
+ echo " Warn: Failed to set uploadpack for '$url' in submodule path '$name'."
+ fi
+ if test "$receivepack"
+ then
+ git config submodule."$name".receivepack "$receivepack" ||
+ echo " Warn: Failed to set receivepack for '$url' in submodule path '$name'."
+ fi
)
fi
done
diff --git a/t/t7404-submodule-packbin.sh b/t/t7404-submodule-packbin.sh
new file mode 100755
index 0000000..d46b3e6
--- /dev/null
+++ b/t/t7404-submodule-packbin.sh
@@ -0,0 +1,53 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 E. Jason Riedy
+#
+
+test_description='git submodule with explicit pack programs
+
+These tests exercise git submodule with --upload-pack and --receive-pack arguments.
+'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo file > file &&
+ git add file &&
+ test_tick &&
+ git commit -m upstream
+ git clone . super &&
+ git clone super submodule &&
+ (cd super &&
+ git submodule add --upload-pack "${GIT_EXEC_PATH}/git-upload-pack" --receive-pack "${GIT_EXEC_PATH}/git-receive-pack" ../submodule submodule &&
+ test_tick &&
+ git commit -m "submodule"
+ ) &&
+ git clone super super-clone &&
+ (cd super-clone && git submodule update --init)
+'
+
+test_expect_success 'push submodule change' '
+ (cd super &&
+ cd submodule &&
+ git checkout master &&
+ echo second line >> file &&
+ test_tick &&
+ git commit -a -m "change submodule inside" &&
+ git push origin +master:pushed
+ )
+'
+
+test_expect_success 'pull submodule change' '
+ (cd submodule &&
+ git pull . pushed &&
+ echo second line >> file &&
+ test_tick &&
+ git commit -a -m "change submodule outside"
+ ) &&
+ (cd super &&
+ cd submodule &&
+ git pull origin master
+ )
+'
+
+test_done
--
1.6.1.60.g1f086.dirty
^ permalink raw reply related
* [PATCH rfc v2] git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X
From: Marcel M. Cary @ 2008-12-30 15:10 UTC (permalink / raw)
To: git; +Cc: gitster, jnareb, ae, j.sixt, Marcel M. Cary
In-Reply-To: <CC0158BE-219B-4E09-9B3B-A2D1B66132AC@silverinsanity.com>
On Mac OS X and possibly BSDs, /bin/pwd reads PWD from the environment
if available and shows the logical path by default rather than the
physical one.
Unset PWD before running /bin/pwd in both cd_to_toplevel and its
test.
Still use the external /bin/pwd because in my Bash on Linux,
the builtin pwd prints the same result whether or not PWD is set.
---
Brian Gernhardt wrote:
> I didn't pay attention to this at the time, but I just tried to build a
> new version of git and noticed this...
>
>> + ..|../*|*/..|*/../*)
>> + # Interpret $cdup relative to the physical, not logical,
>> cwd.
>> + # Probably /bin/pwd is more portable than passing -P to
>> cd or pwd.
>> + phys="$(/bin/pwd)/$cdup"
>> + ;;
>
> This is a non-portable construct. Notably, on OS X (and possibly some
> BSDs) /bin/pwd does not give the physical path, but $(/bin/pwd -P)
> does.
Ouch!
Junio C Hamano wrote:
> Having said that, I think it would probably be better to bite the
> bullet and start using "cd -P" soon after 1.6.1 goes final, and at the
> same time existing places that use "cd `pwd`" as a workaround if there
> are some.
Perhaps it's time to start using "cd -P" with the recent release of
1.6.1. But maybe it's also worth finding a fix that doesn't rely on it
for any maintenance release of 1.6 that might happen?
Brian Gernhardt wrote:
> We may have to build this string ourselves with a --show-cd-absolute
> for portability.
Some options I considered:
(1) We could implement --show-cd-absolute in the short term, with the
expectation of removing it we switch to "cd -P". Not sure it would
really work to try to remove a switch, even if it were undocumented, or
documented as deprecated.
(2) We could check the output of /bin/pwd for ".." and if they are still
present, add the "-P". But I suppose there's no guarantee "-P" would
work, and I shy away from additional analysis of the path because I
don't want to miss an edge case.
(3) We could unset PWD before running /bin/pwd. (Note that in my Bash,
the pwd *builtin* prints the same result whether or not I unset PWD
first.) I suppose it's possible some /bin/pwd dies when PWD is unset or
something, but that seems unlikely.
From
http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man1/pwd.1.html
> The -L option does not work unless the PWD environment variable is
> exported by the shell.
I like option 3 best. Any thoughts?
I sent the first rev of this patch to just Brian. It didn't have
either of the unit test changes. He said it fixed all but t2300.3,
where cd_to_toplevel doesn't actually "cd", so I made the same change
to the unit test itself. Can someone with OS X try running the test
suite with v2 of this patch? I don't have OS X readily available.
Marcel
git-sh-setup.sh | 2 +-
t/t2300-cd-to-toplevel.sh | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index f07d96b..2142308 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -96,7 +96,7 @@ cd_to_toplevel () {
..|../*|*/..|*/../*)
# Interpret $cdup relative to the physical, not logical, cwd.
# Probably /bin/pwd is more portable than passing -P to cd or pwd.
- phys="$(/bin/pwd)/$cdup"
+ phys="$(unset PWD; /bin/pwd)/$cdup"
;;
*)
# There's no "..", so no need to make things absolute.
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
index beddb4e..e42cbfe 100755
--- a/t/t2300-cd-to-toplevel.sh
+++ b/t/t2300-cd-to-toplevel.sh
@@ -10,12 +10,12 @@ test_cd_to_toplevel () {
cd '"'$1'"' &&
. git-sh-setup &&
cd_to_toplevel &&
- [ "$(/bin/pwd)" = "$TOPLEVEL" ]
+ [ "$(unset PWD; /bin/pwd)" = "$TOPLEVEL" ]
)
'
}
-TOPLEVEL="$(/bin/pwd)/repo"
+TOPLEVEL="$(unset PWD; /bin/pwd)/repo"
mkdir -p repo/sub/dir
mv .git repo/
SUBDIRECTORY_OK=1
--
1.6.0.3
^ permalink raw reply related
* Re: why still no empty directory support in git
From: Ping Yin @ 2008-12-30 15:36 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jeff Whiteside, Asheesh Laroia, Git Mailing List
In-Reply-To: <200812300758.41988.robin.rosenberg.lists@dewire.com>
On Tue, Dec 30, 2008 at 2:58 PM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> You can have an empty tree, but the index doesn't store them,
> so they would be lost on checkout/commit. Linus sketched a solution,
> but nobody took the bait. Seems doable if anyone really wants it, but
> I'm certain it adds a lot of special cases.
>
> Look for a discussion [RFC PATCH] Re: Empty directories... posted on 2007-07-19.
> It's in the middle of a long thread.
>
Thanks for pointing me to that thread. For other's convenience, the
begin of the thread is
http://article.gmane.org/gmane.comp.version-control.git/52813
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 16:07 UTC (permalink / raw)
To: git
In-Reply-To: <3ab397d0812291505v77824e6fvdecebc80f38a5f89@mail.gmail.com>
"Jeff Whiteside" <jeff.m.whiteside@gmail.com> wrote in message
news:3ab397d0812291505v77824e6fvdecebc80f38a5f89@mail.gmail.com...
hi zorb,
you have done a great justice here to inadvertently explaining the
learning curve of git, through a few mistakes, especially for ppl
behind in their scm use. i enjoyed reading your blog posts though, as
they remind me of myself, not long ago.
you have a couple of mistakes i think you should correct.
-"Imagine a project with 4 versions, made up of various configurations
of the three files."
this line implies that you have branches (the word configurations).
you should be focusing, at first, on a project that has a set number
of files, and the content merely changes. ideally, you don't often
add and rm files across versions. also, the project doesn't really
have 4 versions, like windows has 4 different versions of vista, the
project has 3 old versions and 1 new version.
** ok, I've changed "configurations" as its overloaded in the context of
older SCMs.
Point taken about changing content not containers. However changing content
is easier, and therefore less need for a tutorial
Also this write-up is basically a "note to self", that I've cleaned up in
case someone else can find it useful, and the problem I was solving was a
problem that involved containers changing.
I've explained the context for going the way of containers now in the
write-up.
I've covered off your concern for ppl thinking we have 4x current versions
(ie. branches) with "4 progressively more recent versions"
"Setup a git index in the project directory"
-this implies you're talking about the index. you're not. you're
talking about the repository. either make it clear that the index is
an intermediary staging area, or ignore its existence and change all
git-add && git-commit references to git-commit -a references. this
will ease the user of older scms into git.
** Don't forget they'll have read the tutorial and/or user-guide, and the
concepts of an index and staging are fairly easy to pick up.
I'll keep it in, and make sure I refer to it as you suggest.
-"Rollback to each of the versions, starting with version A"
this is bad. you're saying rollback. to others that have used scms,
this will mean, "retrieve an older copy", but in git, this is DELETING
all the versions after the version that you "rollback" to. your blog
post shouldn't discuss the git-reset --hard command at all, since
you're rewriting history, which is dangerous. afaik, most scms don't
allow you to rewrite history. to "rollback" to an older version you
should use checkout the git-checkout command. maybe the git reset
-–hard HEAD is okay to include... but it won't be immediately obvious
to new users why it does what it does... this nomenclature was likely
not the best choice whenever it was made.
** have now promoted git-checkout as the way to review older versions
I've left git-reset in there, for my own notes as much as anything, but not
suggesting it be used as some sort of cursor to move the HEAD up and down
the branch
NB getting some funny results with git-checkout near the head of the branch
- will investigatge and report
u're talking sdf
On Sat, Dec 27, 2008 at 5:29 PM, Zorba <cr@altmore.co.uk> wrote:
>
> tidied up the formatting, added a few more comments where needed, fixed
> errors/lack of clarity
>
> "Zorba" <cr@altmore.co.uk> wrote in message
> news:gj68a0$u56$3@ger.gmane.org...
> > Here is a little exercise / tutorial / warm-up for someone starting out
> > with Git. If you're anyting like me you may find the tutorials etc. on
> > git.or.cz a bit daunting. I recommend you try this after reading the
> > user
> > manual but before tearing your hair out trying to follow all the
> > examples
> > in the user manual. After you've followed this simple workflow, then go
> > back to the more advanced stuff in the tutorials and user manuals (like
> > cloning repositories and creating and merging branches).
> >
> > I created this exercise to try and model our workflow and what we wanted
> > to use git for = tracking a project with multiple files where the
> > filebase
> > might change frequently from one version to the next.
> >
> > http://siliconmouth.wordpress.com/category/nerdy/
> >
> > look for December 27, 2008 or "git warmup"
> >
> >
>
>
>
> --
> 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: many git sites homepages megabytes big
From: jidanni @ 2008-12-30 15:57 UTC (permalink / raw)
To: mail; +Cc: git, jnareb, pasky
In-Reply-To: <4959FFA2.4050403@cup.kalibalik.dk>
>>>>> "AM" == Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
AM> For the specific case of repo.or.cz, I guess that turning on HTTP
AM> compression might help a lot.
It's the billion bytes to the innocents' browser that huts the most.
Bad to put such large homepages into browsers.
^ permalink raw reply
* Re: git clone - failing on cygwin with git:// but not with ssh://
From: Joe Casadonte @ 2008-12-30 16:40 UTC (permalink / raw)
To: git
Joe Casadonte <jcasadonte <at> northbound-train.com> writes:
> D:\temp>git clone git://foobar/otminfmyproj.git
> Initialized empty Git repository in /cygdrive/d/temp/foobar/.git/
> fatal: read error (Socket operation on non-socket)
> fatal: early EOF
> fatal: index-pack failed
>
> I've turned on verbose logging in the daemon and I see the following
> messages:
>
> Dec 27 17:31:53 foobar git-daemon: [30327] Connection from 192.168.1.102:2598
> Dec 27 17:31:53 foobar git-daemon: [30327] Extended attributes (16 bytes) exist <host=foobar>
> Dec 27 17:31:53 foobar git-daemon: [30327] Request upload-pack for '/myproj.git'
> Dec 27 17:31:55 foobar git-daemon: [30327] Disconnected (with error)
>
> Running the clone via ssh protocol from test client #2 works, though:
>
> D:\temp>git clone ssh://root <at> foobar/nfs02/git/myproj
> Initialized empty Git repository in /cygdrive/d/temp/myproj/.git/
> remote: Counting objects: 104, done.
> remote: Compressing objects: 100% (72/72), done.
> remote: Total 104 (delta 22), reused 104 (delta 22)
> Receiving objects: 100% (104/104), 76.97 KiB | 9 KiB/s, done.
> Resolving deltas: 100% (22/22), done.
>
> The same test machine has cloned from a different linux server via the
> git protocol just fine.
Looking for a little help, please. Is this not a legitimate git issue? Can
anyone at least help me diagnose the issue? Please?
--
Regards,
joe
Joe Casadonte
jcasadonte@northbound-train.com
------------------------------------------------------------------------------
Llama Fresh Farms => http://www.northbound-train.com
Ramblings of a Gay Man => http://www.northbound-train.com/ramblings
Emacs Stuff => http://www.northbound-train.com/emacs.html
Music CD Trading => http://www.northbound-train.com/cdr.html
------------------------------------------------------------------------------
Live Free, that's the message!
------------------------------------------------------------------------------
^ permalink raw reply
* new home for libgit2 project
From: Shawn O. Pearce @ 2008-12-30 17:04 UTC (permalink / raw)
To: git
I've (mostly) moved libgit2 to repo.or.cz (thanks Pieter for
releasing the mirror, thanks Pasky for the free hosting!):
http://repo.or.cz/w/libgit2.git
git://repo.or.cz/libgit2.git
Thus far its able to format and parse SHA-1 strings, and read
loose objects from a repository. It also doesn't compile on
Mac OS X as the Mach-O file format doesn't support the use of
__thread declarations on variables...
--
Shawn.
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 17:22 UTC (permalink / raw)
To: git
In-Reply-To: <gjdh0r$n3c$4@ger.gmane.org>
Ok, when I do
$ rm *.*
$ git checkout versionA .
I'm getting ABC.txt, AC.txt, BC.txt
which is wrong as only the first two files went into version A
Paradoxically
$ rm *.*
$ git reset --hard versionA
produces the desired result!
I picked up a few cases like this with git-checkout today. Usually a file or
two gets copied into the working tree that shouldn't have been (and I'm
clearing the working tree before each checkout, so its not "leftovers", its
defo git-checkout doing it)
Its coming back to me now - when I was writing my "warm-up" I tried both
git-checkout and git-reset, to do my "rollbacks" and git-checkout produced a
few inconsistent results like above, so I decided to stick with git-reset
(this was before I knew the dangers of git-reset of course!) for "safety".
Could it be that all the "vandalism" I've perpetrated to the history by
resetting in a FORWARD direction could have corrupted the history somehow ?
Even so, you'd expect something vanilla like $ git checkout not to be
affected.
I'm gonna try the checkouts without doing any resetting beforehand (i.e. no
messing with the history) to see if I can reproduce this.
"Zorba" <cr@altmore.co.uk> wrote in message
news:gjdh0r$n3c$4@ger.gmane.org...
** have now promoted git-checkout as the way to review older versions
I've left git-reset in there, for my own notes as much as anything, but not
suggesting it be used as some sort of cursor to move the HEAD up and down
the branch
NB getting some funny results with git-checkout near the head of the branch
- will investigatge and report
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 17:44 UTC (permalink / raw)
To: git
In-Reply-To: <gjdlcl$5no$4@ger.gmane.org>
So I deleted the repo and the working tree, restarted the git bash (i.e.
wiped the slate clean) and started my little warm up workflow again, getting
as far as just created and tagged versionD.
So lets do some checking out
$ rm *.*
$ git checkout versionA .
gives ABC.txt, AC.txt = correct
however...
$ rm *.*
$ git checkout versionB .
gives ABC.txt, AC.txt, BC.txt
which is wrong
running gitk confirms that AC.txt should not be in versionB
!!!!
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Jeff Whiteside @ 2008-12-30 18:35 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjdmm6$9oj$4@ger.gmane.org>
> commit -a detects that files have been deleted, and takes them out of the index !
> could also have used $ git rm <specific files> and then $ git commit ..
hey! i like your changes! the post is pretty polished now. the only
thing else i would change (srysry), is the above. "-a detects that
files have been deleted" -> heh, not true. you don't need -a here;
it does something else.
okay i just recreated your repo and did the same thing. with your
syntax "git checkout versionA ." i got the same result, and i'm not
sure why, but i think it was because of the detached head.
good news, use "git checkout versionA", not "git checkout versionA ."
(so, use it wihtout the dot), and you should be back in working order.
the other (good?) news is that you probably _do_ want to be using git
reset --hard in your case, because you're trying to build up a history
from some project, so you do want to erase some faulty commits after
you bodge something or miss some files.
the bad news is that my opinion is that you should probably move on
with your life, because my own past tells me that you'll never
actually use those old project versions, hahah :p
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Daniel Barkalow @ 2008-12-30 19:42 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gj68a0$u56$3@ger.gmane.org>
On Sat, 27 Dec 2008, Zorba wrote:
> Here is a little exercise / tutorial / warm-up for someone starting out with
> Git. If you're anyting like me you may find the tutorials etc. on git.or.cz
> a bit daunting. I recommend you try this after reading the user manual but
> before tearing your hair out trying to follow all the examples in the user
> manual. After you've followed this simple workflow, then go back to the more
> advanced stuff in the tutorials and user manuals (like cloning repositories
> and creating and merging branches).
>
> I created this exercise to try and model our workflow and what we wanted to
> use git for = tracking a project with multiple files where the filebase
> might change frequently from one version to the next.
One thing I find unrealistic about this example is that you've got BC.txt
and C.txt when you're creating version A, and you've even copied them to
the working directory. In real life, you'd almost certainly not create the
files until you're preparing the version that includes them, at least if
your history is version A, version B, version C. (Now, it's possible that
your history is "create a bunch of files", "create version A without
BC.txt and C.txt"; in parallel to version A, create version B without
AC.txt and C.txt; but that's a different process entirely.)
I think the exercise would come out much more easily if you only created
ABC.txt and AC.txt at the beginning, made version A, added BC.txt and
removed AC.txt, made version B, created C.txt and recovered AC.txt, and
made version C; this is, I believe, what would actually happen.
If you're having trouble with "git commit" putting you in a lousy editor,
somebody probably needs to do better packaging. "git commit" (without the
-m) should open up the best editor available on your computer, but it
doesn't seem to have a good idea about your preferences for editors. Of
course, part of the problem is people who don't like that editor rarely
use the command line on Windows. Do you have a good editor for Windows?
How have you specified it, if so?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH,RESEND] objects to be pruned immediately don't have to be loosened
From: Nicolas Pitre @ 2008-12-30 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When there is no grace period before pruning unreferenced objects, it is
pointless to push those objects in their loose form just to delete them
right away.
Also be more explicit about the possibility of using "now" in the
gc.pruneexpire config variable (needed for the above behavior to
happen).
Signed-off-by: Nicolas Pitre <nico@cam.org>
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7408bb2..ea0cd97 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -702,7 +702,9 @@ gc.packrefs::
gc.pruneexpire::
When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.
- Override the grace period with this config variable.
+ Override the grace period with this config variable. The value
+ "now" may be used to disable this grace period and always prune
+ unreachable objects immediately.
gc.reflogexpire::
'git-reflog expire' removes reflog entries older than
diff --git a/builtin-gc.c b/builtin-gc.c
index 781df60..f8eae4a 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -188,7 +188,9 @@ static int need_to_gc(void)
* there is no need.
*/
if (too_many_packs())
- append_option(argv_repack, "-A", MAX_ADD);
+ append_option(argv_repack,
+ !strcmp(prune_expire, "now") ? "-a" : "-A",
+ MAX_ADD);
else if (!too_many_loose_objects())
return 0;
@@ -243,7 +245,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
"run \"git gc\" manually. See "
"\"git help gc\" for more information.\n");
} else
- append_option(argv_repack, "-A", MAX_ADD);
+ append_option(argv_repack,
+ !strcmp(prune_expire, "now") ? "-a" : "-A",
+ MAX_ADD);
if (pack_refs && run_command_v_opt(argv_pack_refs, RUN_GIT_CMD))
return error(FAILED_RUN, argv_pack_refs[0]);
^ permalink raw reply related
* Re: git clone - failing on cygwin with git:// but not with ssh://
From: Junio C Hamano @ 2008-12-30 19:54 UTC (permalink / raw)
To: Joe Casadonte; +Cc: git
In-Reply-To: <u7i5hy5ti.fsf@terrapin.northbound-train.com>
"Joe Casadonte" <jcasadonte@northbound-train.com> writes:
> Looking for a little help, please. Is this not a legitimate git issue? Can
> anyone at least help me diagnose the issue? Please?
I think "git on Cygwin" is as legitimate as git on anything else, but at
the same time my guess is that it is a combination of the fact that
everybody is busy with other things around the end of year , and that
probably there are not many "git on Cygwin" experts monitoring the list to
begin with.
Sorry, I do not work on Cygwin (nor Windows in general). "fatal: read
error (Socket operation on non-socket)" sounds like it is coming from
pkt-line.c::safe_read() on the downloading side (i.e. git-clone).
Googling for that error message seems to indicate that it seems to a
rather common error message on wide variety of programs running on Cygwin.
C.f.
http://www.google.com/search?&q=%22Socket+operation+on+non-socket%22+site%3Acygwin.com
^ 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