* [PATCH] bash: add '--merge' to 'git reset'
From: SZEDER Gábor @ 2008-12-29 15:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 3491fd0..f6c3755 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1408,7 +1408,7 @@ _git_reset ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--*)
- __gitcomp "--mixed --hard --soft"
+ __gitcomp "--merge --mixed --hard --soft"
return
;;
esac
--
1.6.1.57.gdceb8
^ permalink raw reply related
* turn off "LF will be replaced by CRLF" thingy
From: Zorba @ 2008-12-29 15:38 UTC (permalink / raw)
To: git
Dear All,
I was just in the process of creating our first live version on git (5k+
files), when I noticed this in the output of
$ git add .
being "Warning: LF will be replaced by CRLF in <filename>"
about 500 times !!
I'd rather not let git change any files, many of which are PHP that run on
Apache
I think I remember reading that this is a config option that gets swithced
on by default on windows (which we are running git on)
how do I switch it off ?
thanks
^ permalink raw reply
* Re: turn off "LF will be replaced by CRLF" thingy
From: Zorba @ 2008-12-29 15:55 UTC (permalink / raw)
To: git
In-Reply-To: <gjaqta$tg7$4@ger.gmane.org>
OK, lets be brave and see if I can work this out:
Tutorial says:
"The git configuration file contains a number of variables that affect the
git command's behavior. .git/config file for each repository is used to
store the information for that repository, and $HOME/.gitconfig is used to
store per user information to give fallback values for .git/config file. The
file /etc/gitconfig can be used to store system-wide defaults."
.git/config
======
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = false
ignorecase = true
$ echo $HOME
gives:
c\docs and settings\<my name>
$HOME\.gitconfig
=============
[gui]
recentrepo = C:/Documents and Settings/conorr/Desktop/TEMP
recentrepo = C:/Documents and Settings/conorr/Desktop/TEMP/swproj
[user]
email = cr@altmore.co.uk
name = Conor Rafferty
/etc/gitconfig (under Git installation)
===============================
[core]
symlinks = false
autocrlf = true
[color]
diff = auto
[pack]
packSizeLimit = 2g
[help]
format = html
Then tuturial -> the two settings are
core.autocrlf
and
core.safecrlf
So I should set the autocrlf=false in the etc/config file I'm guessing?
lets try that
"Zorba" <cr@altmore.co.uk> wrote in message
news:gjaqta$tg7$4@ger.gmane.org...
> Dear All,
>
> I was just in the process of creating our first live version on git (5k+
> files), when I noticed this in the output of
>
> $ git add .
>
> being "Warning: LF will be replaced by CRLF in <filename>"
> about 500 times !!
>
> I'd rather not let git change any files, many of which are PHP that run on
> Apache
> I think I remember reading that this is a config option that gets swithced
> on by default on windows (which we are running git on)
>
> how do I switch it off ?
>
> thanks
>
>
^ permalink raw reply
* Re: turn off "LF will be replaced by CRLF" thingy
From: Dmitry Potapov @ 2008-12-29 15:58 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjaqta$tg7$4@ger.gmane.org>
> I'd rather not let git change any files, many of which are PHP that run on
> Apache
> I think I remember reading that this is a config option that gets swithced
> on by default on windows (which we are running git on)
>
> how do I switch it off ?
git config core.autocrlf false
or if you want to ensure that all your text files have only LF then
git config core.autocrlf input
or if you want to disable conversion for some specific files then you can
use 'crlf' attribute. See 'gitattributes' for more information.
http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
Dmitry
^ permalink raw reply
* Re: turn off "LF will be replaced by CRLF" thingy
From: Zorba @ 2008-12-29 16:18 UTC (permalink / raw)
To: git
In-Reply-To: <37fcd2780812290758q3ef989c0w5156da3098d06068@mail.gmail.com>
Thanks Dmitry,
So I have two options to do this - edit the files direct or issue a command,
thank you !
Now, my next problem is taking all my changes ($ git add . -> puts 5k files
into index, with LF in place of CRLF) out of the index.
Because I haven't committed anything in this repo yet...
$ git reset --hard
....falls over, as it has no HEAD to reset to
I think I read how to do this in a tutorial somewhere, maybe with
git-checkout, but I'm searching and can't find it.
Any kind soul can point me in the right direction ?
thanks !
"Dmitry Potapov" <dpotapov@gmail.com> wrote in message
news:37fcd2780812290758q3ef989c0w5156da3098d06068@mail.gmail.com...
>> I'd rather not let git change any files, many of which are PHP that run
>> on
>> Apache
>> I think I remember reading that this is a config option that gets
>> swithced
>> on by default on windows (which we are running git on)
>>
>> how do I switch it off ?
>
> git config core.autocrlf false
>
> or if you want to ensure that all your text files have only LF then
>
> git config core.autocrlf input
>
> or if you want to disable conversion for some specific files then you can
> use 'crlf' attribute. See 'gitattributes' for more information.
> http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
>
> Dmitry
^ permalink raw reply
* Re: turn off "LF will be replaced by CRLF" thingy
From: david @ 2008-12-29 17:29 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjat90$5la$4@ger.gmane.org>
On Mon, 29 Dec 2008, Zorba wrote:
> Thanks Dmitry,
>
> So I have two options to do this - edit the files direct or issue a command,
> thank you !
>
> Now, my next problem is taking all my changes ($ git add . -> puts 5k files
> into index, with LF in place of CRLF) out of the index.
>
> Because I haven't committed anything in this repo yet...
I think if you just do a git add . again it will put the files into the
index without doing the conversion.
David Lang
> $ git reset --hard
>
> ....falls over, as it has no HEAD to reset to
>
> I think I read how to do this in a tutorial somewhere, maybe with
> git-checkout, but I'm searching and can't find it.
> Any kind soul can point me in the right direction ?
>
> thanks !
> "Dmitry Potapov" <dpotapov@gmail.com> wrote in message
> news:37fcd2780812290758q3ef989c0w5156da3098d06068@mail.gmail.com...
>>> I'd rather not let git change any files, many of which are PHP that run
>>> on
>>> Apache
>>> I think I remember reading that this is a config option that gets
>>> swithced
>>> on by default on windows (which we are running git on)
>>>
>>> how do I switch it off ?
>>
>> git config core.autocrlf false
>>
>> or if you want to ensure that all your text files have only LF then
>>
>> git config core.autocrlf input
>>
>> or if you want to disable conversion for some specific files then you can
>> use 'crlf' attribute. See 'gitattributes' for more information.
>> http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
>>
>> Dmitry
>
>
>
> --
> 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: user manual question
From: Zorba @ 2008-12-29 16:38 UTC (permalink / raw)
To: git
In-Reply-To: <slrnglg90m.olt.sitaramc@sitaramc.homelinux.net>
so a detached HEAD is just a HEAD that is not sitting on a tip ?
i.e. if I do $ git reset --hard HEAD^
...pointing HEAD to the previous committ
this is a detached HEAD
(I thought a detached HEAD was maybe a head somewhere on another branch not
"reachable", i.e. a sibling, not a ancestor...
or something like that)
thanks guys
"Sitaram Chamarty" <sitaramc@gmail.com> wrote in message
news:slrnglg90m.olt.sitaramc@sitaramc.homelinux.net...
> On 2008-12-29, Zorba <cr@altmore.co.uk> wrote:
>> Hi Sitaram!
>>
>> Thanks for clearing that one up.
>
> you're welcome; we've all done a bit of struggling I guess!
>
>> Also, I did wonder about HEAD and head. One can move, the other doesn't!
>> (well, acually it does - head moves "forward", as the tip of the branch
>> grows)
>
> Here's an extract from my notes/internal talks on this:
>
> === basic concepts
> * a branch is "an active line of development"
> * //master//: default branch in a project, by convention
> * //head//: tip of a branch
> * a repo can track many branches, but the working tree is associated
> with
> only one branch at a time
> * //HEAD//: tip of the branch associated with the working tree; this
> is
> where commits go
> ** except when it's "detached"
>
>> Thanks for your other post/reply too - I will be getting back to you on
>> that
>> one
>
> Glad to be of help. I don't consider myself a guru, and am
> constantly waiting for one of the real gurus to strike me
> down with a thunderbolt for saying something stupid :-)
>
^ permalink raw reply
* [PATCH 0/3] rebase --root
From: Thomas Rast @ 2008-12-29 16:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Inspired by f95ebf7 (Allow cherry-picking root commits, 2008-07-04),
this teaches git rebase to rebase everything up to the root commit(s).
The main use-case for this is if you hack on new history, then later
notice that you want to unroll the commits "on" a git-svn branch to
dcommit them separately. (If you just want to squash them, a merge
will do fine.)
Note that --root (in both modes) requires --onto; you cannot rebase
"onto nothing" to edit the root commit. Such an option --onto-nothing
might be a worthwile feature however, since it would also allow
"detaching" a set of commits from their parent history.
BTW, while hacking this I noticed that there are two different tests
t3409:
t3409-rebase-hook.sh
t3409-rebase-preserve-merges.sh
Is this okay, or should one of them be renamed?
Thomas Rast (3):
rebase: learn to rebase root commit
rebase -i: learn to rebase root commit
rebase: update documentation for --root
Documentation/git-rebase.txt | 17 +++++++---
git-rebase--interactive.sh | 53 +++++++++++++++++++++++++--------
git-rebase.sh | 51 ++++++++++++++++++++++----------
t/t3412-rebase-root.sh | 66 ++++++++++++++++++++++++++++++++++++++++++
4 files changed, 153 insertions(+), 34 deletions(-)
create mode 100755 t/t3412-rebase-root.sh
^ permalink raw reply
* rebase -i: learn to rebase root commit
From: Thomas Rast @ 2008-12-29 16:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <cover.1230569041.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).
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-rebase--interactive.sh | 53 +++++++++++++++++++++++++++++++++----------
t/t3412-rebase-root.sh | 14 +++++++++++
2 files changed, 54 insertions(+), 13 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c8b0861..f29b5ee 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)
@@ -443,6 +450,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 +555,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 +566,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 +577,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?"
@@ -613,12 +631,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"
@@ -647,11 +674,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)" = ""
@@ -670,7 +697,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..bb44a52 100755
--- a/t/t3412-rebase-root.sh
+++ b/t/t3412-rebase-root.sh
@@ -49,4 +49,18 @@ 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_done
--
1.6.1.1.g4c1d9.dirty
^ permalink raw reply related
* rebase: learn to rebase root commit
From: Thomas Rast @ 2008-12-29 16:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <cover.1230569041.git.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>
---
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.1.g4c1d9.dirty
^ permalink raw reply related
* rebase: update documentation for --root
From: Thomas Rast @ 2008-12-29 16:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <cover.1230569041.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>
---
Documentation/git-rebase.txt | 17 ++++++++++++-----
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index c8ad86a..3268cd2 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,11 @@ 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.
+
include::merge-strategies.txt[]
NOTES
--
1.6.1.1.g4c1d9.dirty
^ permalink raw reply related
* Re: user manual question
From: Björn Steinbrink @ 2008-12-29 17:18 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjauel$94s$4@ger.gmane.org>
On 2008.12.29 16:38:30 -0000, Zorba wrote:
> so a detached HEAD is just a HEAD that is not sitting on a tip ?
>
> i.e. if I do $ git reset --hard HEAD^
>
> ...pointing HEAD to the previous committ
>
> this is a detached HEAD
No. At least that won't turn an "attached" HEAD into a detached HEAD.
Attached HEAD: HEAD is a symbolic ref to another ref.
Detached HEAD: HEAD is a non-symbolic ref to a commit.
So you can have:
HEAD -> refs/heads/master -> commitA --> attached HEAD
Or:
HEAD -> commitA --> detached HEAD
Note how the commit object is the same in both cases.
What you "git reset [--hard] HEAD^" does, depends on the kind of HEAD
you have.
"git reset HEAD^" will (conceptually, implementation might differ):
Resolve HEAD^ to find a commit.
and
Resolve HEAD until it finds a non-symbolic ref, and update that ref to
reference the commit it found.
Looking at the cases from above:
Attached case:
HEAD -> refs/heads/master -> commitA
Resolve HEAD^:
HEAD^ ==> refs/heads/master^ ==> commitA^ ==> commitA_parent
Find non-symbolic ref:
HEAD (symbolic) ==> refs/heads/master (non-symbolic)
So refs/heads/master gets updated to reference commitA_parent.
Now the detached case:
HEAD -> commitA
Resolve HEAD^:
HEAD^ ==> commitA^ ==> commitA_parent
Find non-symbolic ref:
HEAD (non-symbolic)
So HEAD gets updated to reference commitA_parent.
In other words, HEAD is what tells git what you have checked out. And
that's either a branch head (attached HEAD, symbolic ref) or a commit
(detached HEAD, non-symbolic ref).
In the symbolic ref case, operations like "commit" or "reset" work on
the branch you have checked out (found through the symbolic ref), in the
non-symbolic ref case (detached HEAD), those operations work on HEAD
itself.
Björn
^ permalink raw reply
* Re: user manual question
From: Markus Heidelberg @ 2008-12-29 17:20 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjauel$94s$4@ger.gmane.org>
Zorba, 29.12.2008:
> so a detached HEAD is just a HEAD that is not sitting on a tip ?
You can also get a detached HEAD with "git checkout origin/master",
although your HEAD points to a tip. But it's a remote tip and since you
can't work on remote branches, you now are on a detached HEAD (no
branch).
> i.e. if I do $ git reset --hard HEAD^
>
> ...pointing HEAD to the previous committ
>
> this is a detached HEAD
No, this isn't. "git reset <commit>" modifies your current head (local
branch), now HEAD still points to the tip, but the tip is one commit
older. A detached HEAD you can get with "git checkout HEAD^".
^ permalink raw reply
* Re: user manual question
From: Sitaram Chamarty @ 2008-12-29 17:27 UTC (permalink / raw)
To: git
In-Reply-To: <gjauel$94s$4@ger.gmane.org>
On 2008-12-29, Zorba <cr@altmore.co.uk> wrote:
> so a detached HEAD is just a HEAD that is not sitting on a tip ?
yes...
> i.e. if I do $ git reset --hard HEAD^
>
> ...pointing HEAD to the previous committ
>
> this is a detached HEAD
...but no. This is because git reset moves the tip of the
branch also (in this case, backward by one commit from the
previous). In effect, you're saying "discard my latest
commit and roll back by one".
"git checkout HEAD^" would get you a detached head though.
In this case you're saying "let the branch be where it is,
but let HEAD move up one level". So HEAD is now NOT at a
tip, and it'a a detached head.
It's instructive to run "gitk --all" when you're doing these
experiments sometimes.
> (I thought a detached HEAD was maybe a head somewhere on another branch not
> "reachable", i.e. a sibling, not a ancestor...
> or something like that)
no no that's just another branch that's all.
All this is pretty confusing in the beginning, but if you
don't lose your head, it'll all become clear eventually.
[What's that they say? Oh yeah "thank you ladies and
gentlemen I'll be here all night"!]
^ permalink raw reply
* [PATCH] git-cherry: make <upstream> parameter optional
From: Markus Heidelberg @ 2008-12-29 17:45 UTC (permalink / raw)
To: git
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>
---
I'm not sure, whether the usage output would be still necessary.
Documentation/git-cherry.txt | 3 ++-
builtin-log.c | 16 ++++++++++++++--
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt
index 74d14c4..556ea23 100644
--- a/Documentation/git-cherry.txt
+++ b/Documentation/git-cherry.txt
@@ -7,7 +7,7 @@ git-cherry - Find commits not merged upstream
SYNOPSIS
--------
-'git cherry' [-v] <upstream> [<head>] [<limit>]
+'git cherry' [-v] [<upstream>] [<head>] [<limit>]
DESCRIPTION
-----------
@@ -51,6 +51,7 @@ OPTIONS
<upstream>::
Upstream branch to compare against.
+ Defaults to the first tracked remote branch, if available.
<head>::
Working branch; defaults to HEAD.
diff --git a/builtin-log.c b/builtin-log.c
index 99d1137..243f857 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -16,6 +16,7 @@
#include "patch-ids.h"
#include "run-command.h"
#include "shortlog.h"
+#include "remote.h"
/* Set a default date-time format for git log ("log.date" config variable) */
static const char *default_date_mode = NULL;
@@ -1070,13 +1071,14 @@ static int add_pending_commit(const char *arg, struct rev_info *revs, int flags)
}
static const char cherry_usage[] =
-"git cherry [-v] <upstream> [<head>] [<limit>]";
+"git cherry [-v] [<upstream>] [<head>] [<limit>]";
int cmd_cherry(int argc, const char **argv, const char *prefix)
{
struct rev_info revs;
struct patch_ids ids;
struct commit *commit;
struct commit_list *list = NULL;
+ struct branch *current_branch;
const char *upstream;
const char *head = "HEAD";
const char *limit = NULL;
@@ -1099,7 +1101,17 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
upstream = argv[1];
break;
default:
- usage(cherry_usage);
+ current_branch = branch_get(NULL);
+ if (!current_branch || !current_branch->merge
+ || !current_branch->merge[0]
+ || !current_branch->merge[0]->dst) {
+ fprintf(stderr, "Could not find a tracked"
+ " remote branch, please"
+ " specify <upstream> manually.\n");
+ usage(cherry_usage);
+ }
+
+ upstream = current_branch->merge[0]->dst;
}
init_revisions(&revs, prefix);
--
1.6.1.35.ge4490
^ permalink raw reply related
* -pthread should be removed on MacOS builds?
From: Ted Pavlic @ 2008-12-29 17:46 UTC (permalink / raw)
To: git
I notice that every time I build git on my OS X 10.4.11 (PowerBook G4)
system, I get a bunch of:
powerpc-apple-darwin8-gcc-4.0.1: unrecognized option '-pthread'
Doing a little search, I see:
http://lists.apple.com/archives/Unix-porting/2005/Mar/msg00019.html
====
The C library on Mac OS X is always thread safe (well the ones which
can be thread safe and are defined to be thread safe by the POSIX
standard) and always include the pthread library.
====
So I get the feeling that -pthread can be removed from the MacOS build
line without any impact (except for removing those warnings).
Just something cosmetic.
--
Ted Pavlic <ted@tedpavlic.com>
^ permalink raw reply
* shallow clone, shallow fetch?
From: jidanni @ 2008-12-29 18:07 UTC (permalink / raw)
To: git
man git-clone at --depth could also mention if updating procedures are
for shallow clones just like for plain git-clones, or is there a diet
way of updating too? (Not git-fetch --depth apparently.)
(The diet way would give results like one did
$ rm -r .git *; git-clone --depth 1 ...
all over again, but only cause a small download this time.)
^ permalink raw reply
* git-ls-files -l
From: jidanni @ 2008-12-29 17:07 UTC (permalink / raw)
To: git
Beginners, finding git-ls-files acts like ls,
are baffled as to why they can't go on to ls -l.
The git-ls-files man page should reveal the secret of how also to see
file sizes. Perhaps the closest one can get is
$ git-ls-tree -l --abbrev ...
^ permalink raw reply
* Re: user manual question
From: Daniel Barkalow @ 2008-12-29 19:30 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjauel$94s$4@ger.gmane.org>
On Mon, 29 Dec 2008, Zorba wrote:
> so a detached HEAD is just a HEAD that is not sitting on a tip ?
If you used CVS (extensively) back in the day, a detached HEAD is like
what you get if you do something like "cvs checkout -D yesterday" (CVS
called it "sticky tags"); you have a working directory that contains some
revision that isn't your latest revision. If you make changes, they can't
go into the history in the normal fashion, but you can build the project
and figure out how it worked back then.
With git, of course, you can do things you couldn't do from that state
with CVS. Because git supports forking history, you can make commits and
create a new branch to be on. Because git can handle having visibility
into other people's branches, you can get a detached HEAD by checking out
somebody else's branch (something like origin/next, for example).
The normal "attached HEAD" state is that there's some branch that you
update when you make a commit; the "detached HEAD" state means that, when
you make a commit, no branch is affected.
> i.e. if I do $ git reset --hard HEAD^
>
> ...pointing HEAD to the previous committ
>
> this is a detached HEAD
Nope, it's "git checkout (something that isn't one of your branches)",
just like CVS.
Git is like knitting. Commits are loops of yarn that hold other loops
(their parents) in place; branches are knitting needles that keep new
loops from falling out before other loops are holding them, and which hold
different loops at different times as you work; HEAD is the tip of a
needle that you use to make new loops. You usually use the tip of one of
your regular needles to make new loops, and then the body of the needle
holds the loop, but you could also use your fingers or something that will
just make the loop temporarily; that's a detached HEAD, because it doesn't
have the body of a needle behind it to hold loops when you use it for
something else.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* "git-whatever" the new style vs. "git whatever"?
From: jidanni @ 2008-12-29 19:37 UTC (permalink / raw)
To: gitster; +Cc: nanako3, git
In-Reply-To: <7vfxk7cnmw.fsf@gitster.siamese.dyndns.org>
JCH> I think he is comparing "git am" and "git-am" the latter of which is now
JCH> deprecated and largely removed from the end user.
By the way, we here at the end user end have a hard time detecting if
"git-whatever" the new style vs. "git whatever"...
Idea: right at top of "man git" say: You might have noticed sometimes
people write "git-whatever" and sometimes write "git whatever", well ...
JCH> IOW, the seeming inconsistency is not an issue anymore in practice in the
JCH> post 1.6.0 era.
(I was just hoping everything is consistent, one way or the other.)
^ permalink raw reply
* Re: [STGIT][PATCH] new: translate non word characters in patch name to '-'
From: Hannes Eder @ 2008-12-29 20:15 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20081228204938.GA13143@diana.vm.bytemark.co.uk>
On 12/28/08, Karl Hasselström <kha@treskal.com> wrote:
> On 2008-12-27 13:37:20 +0100, Hannes Eder wrote:
>
> > This allows following usage:
> >
> > $ stg new full/path/file-fix-foobar
> > Now at patch "full-path-file-fix-foobar"
> >
> > Signed-off-by: Hannes Eder <hannes@hanneseder.net>
> > ---
> >
> > I ran into as a '/' in a patch messed up stgit.
> >
> > I find this useful as 'stg uncommit' does the same translation.
>
>
> Clearly, bad path names shouldn't mess anything up -- see
>
> https://gna.org/bugs/?10919
>
> But I would prefer "stg new" to quit with an error message when given
> an illegal patch name, not silently mangle it. (Of course, the
> commands that generate patch names from commit messages -- such as
> "stg new" when not given an explicit patch name -- should mangle the
> commit message as much as necessary. But when the user gives us a
> patch name, we should either use that as is or fail with an
> informative message.)
>
> I think the right thing to do would be to construct a function that
> validates patch names (I don't think we have one right now), and then
> call it whenever we need to check if a patch name is OK. Such as when
> the user gives us the name of a new patch. And when we've
> auto-generated a patch name from a commit message, we should probably
> assert that that the check function is OK with the name.
What about instead of 'fail with an informative message', just issue a
warning that
the name has been mangled. I use pathnames in patch names frequently,
so this would be very handy.
I guess some with with more python skills needs to clean that up, this
is the first stuff I do in python ;).
---
diff --git a/stgit/commands/new.py b/stgit/commands/new.py
index 151cfe9..ed5c9ce 100644
--- a/stgit/commands/new.py
+++ b/stgit/commands/new.py
@@ -58,7 +58,7 @@ def func(parser, options, args):
if len(args) == 0:
name = None
elif len(args) == 1:
- name = args[0]
+ name = utils.sanitize_patch_name(args[0])
if stack.patches.exists(name):
raise common.CmdException('%s: patch already exists' % name)
else:
diff --git a/stgit/commands/rename.py b/stgit/commands/rename.py
index 8a593ac..455b67e 100644
--- a/stgit/commands/rename.py
+++ b/stgit/commands/rename.py
@@ -50,6 +50,8 @@ def func(parser, options, args):
old, [new] = crt, args
else:
parser.error('incorrect number of arguments')
+
+ new = utils.sanitize_patch_name(new)
out.start('Renaming patch "%s" to "%s"' % (old, new))
crt_series.rename_patch(old, new)
diff --git a/stgit/utils.py b/stgit/utils.py
index 81035a5..8ffe5a3 100644
--- a/stgit/utils.py
+++ b/stgit/utils.py
@@ -231,6 +231,31 @@ def make_patch_name(msg, unacceptable,
default_name = 'patch'):
patchname = default_name
return find_patch_name(patchname, unacceptable)
+class PatchNameException(StgException):
+ pass
+
+def sanitize_patch_name(patchname):
+ # '..' is for patch ranges only, so it is not allowed here
+ if patchname.find('..') != -1:
+ raise PatchNameException('Patch name must not contain "..".')
+
+ # if patch name contains non word characters, replace them but warn user
+ # about that
+ if re.search('\W', patchname):
+ out.warn('replacing non word characters in patch name');
+ patchname = re.sub('[\W]+', '-', patchname).strip('-')
+
+ # limit patch name length
+ name_len = config.get('stgit.namelength')
+ if not name_len:
+ name_len = 30
+
+ if len(patchname) > name_len:
+ out.warn('truncating the patch name to %d characters' % name_len)
+ patchname = patchname[:name_len]
+
+ return patchname
+
# any and all functions are builtin in Python 2.5 and higher, but not
# in 2.4.
if not 'any' in dir(__builtins__):
^ permalink raw reply related
* gitweb $export_ok question
From: Thomas Amsler @ 2008-12-29 20:26 UTC (permalink / raw)
To: git@vger.kernel.org
Hello,
I am trying to get the gitweb $export_ok to work. According the installation instructions:
Alternatively, you can configure gitweb to only list and allow
viewing of the explicitly exported repositories, via the
GITWEB_EXPORT_OK build configuration variable (or the $export_ok
variable in gitweb config file). If it evaluates to true, gitweb
shows repositories only if this file exists in its object database
(if directory has the magic file named $export_ok).
... I set $export_ok = "true" in my /etc/gitweb.conf file. I don't know what "file" needs to be added to a repository in order for it to show up again in gitweb. I have tried several things, like specifying the file name in /etc/gitweb.con:
$export_ok ="magic-file-name"
etc. but that doesn't seem to work.
What am I doing wrong here?
^ permalink raw reply
* Re: "git-whatever" the new style vs. "git whatever"?
From: Boyd Stephen Smith Jr. @ 2008-12-29 20:47 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87sko6lqmo.fsf_-_@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 811 bytes --]
On Monday 2008 December 29 13:37:19 jidanni@jidanni.org wrote:
> JCH> I think he is comparing "git am" and "git-am" the latter of which is
> JCH> now deprecated and largely removed from the end user.
>
> By the way, we here at the end user end have a hard time detecting if
> "git-whatever" the new style vs. "git whatever"...
That shouldn't be a problem for much longer because "git-whatever" will stop
working. From what I understand, "git whatever" has always been the
preferred form, and the fact that "git-whatever" worked was just a
implementation detail.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [STGIT][PATCH] new: translate non word characters in patch name to '-'
From: Karl Hasselström @ 2008-12-29 21:21 UTC (permalink / raw)
To: Hannes Eder; +Cc: Catalin Marinas, git
In-Reply-To: <154e089b0812291215h72dfe04aod080f665eb7f5592@mail.gmail.com>
On 2008-12-29 21:15:44 +0100, Hannes Eder wrote:
> What about instead of 'fail with an informative message', just issue
> a warning that the name has been mangled. I use pathnames in patch
> names frequently, so this would be very handy.
Hmm, I'm still skeptical. Programs that try to be too clever all too
often end up just being annoying and unpredictable.
> I guess some with with more python skills needs to clean that up,
> this is the first stuff I do in python ;).
The code looks OK -- but as I said, I don't agree with what it's
trying to do.
There's a small inconsistency: you fail if the name contains "..", but
correct single bad characters.
And as I recall, stgit.namelength is about the automatically generated
patch names -- there's no limit for the names provided by the user.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: "git-whatever" the new style vs. "git whatever"?
From: A Large Angry SCM @ 2008-12-29 21:27 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: jidanni, git
In-Reply-To: <200812291447.01713.bss@iguanasuicide.net>
Boyd Stephen Smith Jr. wrote:
> On Monday 2008 December 29 13:37:19 jidanni@jidanni.org wrote:
>> JCH> I think he is comparing "git am" and "git-am" the latter of which is
>> JCH> now deprecated and largely removed from the end user.
>>
>> By the way, we here at the end user end have a hard time detecting if
>> "git-whatever" the new style vs. "git whatever"...
>
> That shouldn't be a problem for much longer because "git-whatever" will stop
> working. From what I understand, "git whatever" has always been the
> preferred form, and the fact that "git-whatever" worked was just a
> implementation detail.
This is a revisionist history. Check the history of the git command to
find out when it was created and then check the ML archives for related
discussions.
^ 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