* cloning empty repo
From: Marijn Schouten (hkBst) @ 2007-06-24 15:04 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi list,
is there any reason why cloning an empty repository should result in an error
instead of a succesfully cloned empty repo?
Marijn
PS Please CC me
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGfogIp/VmCx0OL2wRAnYXAJ9cJAO4WsQihr6iEsEIawA9cpycQACglI8G
lofEKfuidJ1OOv12A9QPK8w=
=p344
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH][RESEND] git-submodule: provide easy way of adding new submodules
From: Sven Verdoolaege @ 2007-06-24 15:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Lars Hjemli
In-Reply-To: <7v8xaa4f5g.fsf@assigned-by-dhcp.pobox.com>
On Sat, Jun 23, 2007 at 12:58:03PM -0700, Junio C Hamano wrote:
> Somehow "git submodule add $URL $my_subdirectory" feels
> unnatural, although it certainly is simpler to write the command
The order of the arguments is the same as those of git-clone and
you can read it as "git: add submodule $URL (at) $my_subdirectory"
> usage string. Wouldn't a commit on the maintenance branch of
> cgit.git want to say "Add the 'maint' branch of git.git as my
> submodule", for example?
Sounds plausible
> The alternatives I can come up with do not feel right either, though.
>
> git submodule $my_subdirectory $URL [$branch]
> git submodule $URL [--branch $branch] $my_subdirectory
I'll add the latter, although it's not clear if you actually
want me to.
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index 89a3885..3df7121 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -1,13 +1,14 @@
> > #!/bin/sh
> > #
> > -# git-submodules.sh: init, update or list git submodules
> > +# git-submodules.sh: add, init, update or list git submodules
> > #
> > # Copyright (c) 2007 Lars Hjemli
> >
> > -USAGE='[--quiet] [--cached] [status|init|update] [--] [<path>...]'
> > +USAGE='[--quiet] [--cached] [add <repo>|status|init|update] [--] [<path>...]'
>
> Can a single repo added at more than one path with this syntax?
No. I was trying to be brief. The more correct syntax would be the one
in the documentation, but I thought that would be a bit lengthy for
USAGE.
> I've seen this code before elsewhere. We do not need to
> refactor right now with this patch, but please mark this copy
> with something like:
>
> # NEEDSWORK: identical function exists in get_repo_base
> # in clone.sh
> get_repo_base () {
> ...
OK
> > + test -e "$path" &&
> > + die "'$path' already exists"
> > +
> > + module_clone "$path" "$repo" || exit
>
> - module_clone catches the "$path already exists" case; but the
> test is done differently. One particular case of "an empty
> directory exists" is allowed there, but you are dying early
> to forbid it. Is that warranted? My gut feeling is that
> they should share the same check, iow, don't check yourself
> but have module_clone take care of the error case.
They're different because submodule update (which also calls module_clone)
is performed on a module that already exists in the repo and
was therefore checked out by git as an empty directory. If you
add a new submodule, then there is no reason for the subdirectory
to exist already.
> - If $path does not exist in the worktree (because it hasn't
> been checked out), but does exist in the index, what should
> happen? Should it be flagged as an error (in module_clone,
> not here)?
Good question. It should fail. However, I think this new check
does belong here, because when module_clone is called from
modules_update, the path _should_ exist in the index.
skimo
^ permalink raw reply
* Re: [PATCH 2/2] Teach rebase an interactive mode
From: Johannes Schindelin @ 2007-06-24 14:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pkxydim.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 24 Jun 2007, Junio C Hamano wrote:
> This is just an idea, but I have been wondering if it would be useful if
> we teach rebase (interactive or not) to handle a merge from an unrelated
> (wrt the rebase that is being performed) branch. That is, if you had
> this development on top of the origin 'O':
>
> X
> \
> A---M---B
> /
> ---o---O
>
> that you committed A, merged X and then committed B, you should
> be able to rebase on top of an updated upstream 'Q':
>
> X
> \
> A---M---B
> /
> ---o---O---P---Q
>
> by 'pick A/merge M/pick B', which would do:
>
> X
> \
> A'--M'--B'
> /
> ---o---O---P---Q
>
> Note that A', M' and B' are different commit objects (rebase
> rewrites the history) from the original picture, but X is the
> same commit from the original picture.
Yes, I think that would be useful. But at the same time, I think it should
not be the default. Why? Because I will use rebase to beautify my history,
and that looks mostly like this:
--- A - B - C - D - E - junio/master
\ \ \
M - N - O - P - my
So what I want is really clean up my side branch.
Therefore I would like to have this --preserve-merges (short option -p?)
_after_ rebase -i.
It will get a little tricky with different merge strategies, and saying
which commits have to be rebased (A in your example), and which will be
preserved (X in your example), and evil merges (merges which have fix ups
in addition to the merge), but doable.
Ciao,
Dscho
^ permalink raw reply
* Re: Stupid quoting...
From: Jeff King @ 2007-06-24 12:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Kastrup, Robin Rosenberg, Jan Hudec, Johannes Schindelin,
git
In-Reply-To: <7vsl8htuin.fsf@assigned-by-dhcp.cox.net>
On Sun, Jun 24, 2007 at 05:19:12AM -0700, Junio C Hamano wrote:
> > ASCII-armoring of what amounts to binary files is the task of the mail
> > software. Also working with encodings. Escaping characters in the
> > diff headers but not in the file contents is not going to achieve
> > anything useful, anyway.
>
> You misunderstood me. The issue is not about transmitting
> without corruption. Armoring would make it impossible to
> COMMENTING on the patch INLINE.
>
> And that is where the pathname quoting git diff does originally
> comes from.
Then how about quoted-printable?
The point is that you're _already_ screwed by the fact that there can be
up to three different encodings in a patch (commit message, pathnames,
and file contents) but we only know one of them (the commit message).
With the other two, trying to convert encodings is pointless, since we
don't know the starting point. So we can either output them as-is as
binary, or use some sort of quoting mechanism.
The quoting that happens now is:
- sometimes unnecessary, and hurts people who are _not_ sending the
diff through the mail
- not recognized by any widely-used un-quoter. I can't comment on your
diff very well if it changes the file "\a/f\303\263\303\266", and
there's no viewer that will let me read that in a sane way.
I think David's point is that by doing the quoting at the MIME
level (using 8bit, or 7bit with QP), the recipient's MUA can at
least show the binary characters. Sure, that will totally break if
you are using a bad mismatch of encodings, but there's nothing we
can do to fix that, not knowing what the encodings are. At least it
_will_ work in the case that your encodings are the same.
The only argument I see _for_ the current quoting is for parsing by
non-mail programs (like patch or git-apply); in that case, it would seem
only necessary only to quote tab, newline, backslash, and double quote.
But at least those retain their human-readability.
-Peff
^ permalink raw reply
* Re: Stupid quoting...
From: Junio C Hamano @ 2007-06-24 12:19 UTC (permalink / raw)
To: David Kastrup; +Cc: Robin Rosenberg, Jan Hudec, Johannes Schindelin, git
In-Reply-To: <85myypef7p.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> If I were to create a patch between two versions of such a file, the
>> diff header would show the pathname encoded in one, and the changed
>> contents would ben shown in another. As long as you treat "git
>> diff" output as binary blob, that would work just fine, but when you
>> have to transmit such a diff in e-mail as an in-line patch, you
>> would have troubles.
>
> ASCII-armoring of what amounts to binary files is the task of the mail
> software. Also working with encodings. Escaping characters in the
> diff headers but not in the file contents is not going to achieve
> anything useful, anyway.
You misunderstood me. The issue is not about transmitting
without corruption. Armoring would make it impossible to
COMMENTING on the patch INLINE.
And that is where the pathname quoting git diff does originally
comes from.
^ permalink raw reply
* Re: Stupid quoting...
From: David Kastrup @ 2007-06-24 11:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, Jan Hudec, Johannes Schindelin, git
In-Reply-To: <7vzm2ptw04.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> If I were to create a patch between two versions of such a file, the
> diff header would show the pathname encoded in one, and the changed
> contents would ben shown in another. As long as you treat "git
> diff" output as binary blob, that would work just fine, but when you
> have to transmit such a diff in e-mail as an in-line patch, you
> would have troubles.
ASCII-armoring of what amounts to binary files is the task of the mail
software. Also working with encodings. Escaping characters in the
diff headers but not in the file contents is not going to achieve
anything useful, anyway.
With the proper mailing software, you can get your diff across the
line in a manner where the other side can make use of it. This is not
the case for unarmored mail with ^ escapes in them, since the
receiving side can't distinguish them from "real" ^ characters.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Stupid quoting...
From: Junio C Hamano @ 2007-06-24 11:47 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jan Hudec, Johannes Schindelin, David Kastrup, git
In-Reply-To: <200706241314.46238.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> I can't talk about "most" here, only local conditions, i.e. northern Europe
> where both the legacy ISO encodings are very common with a steady increase in
> UTF-8 usage, in the Linux community. People using OSS in windows almost
> exclusively get the windows-1252 (for most practical purposes the same as
> ISO-8859-1).
>
> Even a *very* small set of random people you will wind up with people having
> different locales.
More problematic is the case where pathnames and contents are in
different encodings, even for the same language.
For example, my mbox files that store messages I receive from
people in Japan have contents in ISO-2022 as that is the
longstanding standard encoding used for e-mail over there, but
the pathname encoding used by the system I have that mbox file
on is EUC-JP.
If I were to create a patch between two versions of such a file,
the diff header would show the pathname encoded in one, and the
changed contents would ben shown in another. As long as you
treat "git diff" output as binary blob, that would work just
fine, but when you have to transmit such a diff in e-mail as an
in-line patch, you would have troubles.
^ permalink raw reply
* Re: [PATCH 1/2] Move the pick_author code to git-sh-setup
From: Junio C Hamano @ 2007-06-24 11:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706241118250.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> That is well possible. Quoting in shell is such a hassle, and I never seem
> to get it right.
>
> Therefore I did a minimal test,...
>
> So I thought that it was okay.
Try the small test script in the message you are responding to.
It gives me:
$ sh ./1.sh
A= d e
B= d e
A quick rule of thumb is that the only place that you can get
away by not quoting is straight assignment to another variable,
like so:
var='a b c '
another=$var ;# another="$var" is fine but unnecessary.
Similarly for
another=$(some command)
which is Ok not to dquote.
^ permalink raw reply
* Re: Stupid quoting...
From: Robin Rosenberg @ 2007-06-24 11:14 UTC (permalink / raw)
To: Jan Hudec; +Cc: Junio C Hamano, Johannes Schindelin, David Kastrup, git
In-Reply-To: <20070624065008.GA6979@efreet.light.src>
söndag 24 juni 2007 skrev Jan Hudec:
> IMHO it should be the default even for email format. Most projects that use
> non-ascii filenames probably have all members using same locale. And for
> such group, it will just work. Also usually the file names, content and
> commit messages will usually be in the same (though project-specific)
> encoding, so if charset in content-type is set to that, people with
different
> locale able to represent the same characters will still see the names
> correctly. For other people, the MUA will probably print some escape anyway
> (it will not screw up the terminal -- it usually knows what it can safely
> pass to it).
I can't talk about "most" here, only local conditions, i.e. northern Europe
where both the legacy ISO encodings are very common with a steady increase in
UTF-8 usage, in the Linux community. People using OSS in windows almost
exclusively get the windows-1252 (for most practical purposes the same as
ISO-8859-1).
Even a *very* small set of random people you will wind up with people having
different locales.
-- robin
^ permalink raw reply
* Re: [PATCH 2/2] Teach rebase an interactive mode
From: Johannes Schindelin @ 2007-06-24 11:09 UTC (permalink / raw)
To: Junio C Hamano, Brian Gernhardt; +Cc: git
In-Reply-To: <7v4pkxydim.fsf@assigned-by-dhcp.cox.net>
Hi,
thanks to both of you, for your comments. I am a little pressed on time,
so I will only be able to fix all this up this evening, but I thought I
let you know what the state is.
I am not answering point by point, because I agree with all of the nits.
The four missing points are:
- fix up the commit message so that it is clear from where the list of
commits comes,
- put a sensible reflog message at the last update,
- move the usage section into the man page, and
- fix the quoting in patch 1/2.
Will resend (after using rebase -i myself, yeah!) tonight.
---
Documentation/git-rebase.txt | 12 ++---
git-rebase--interactive.sh | 90 ++++++++++++++++++++++++------------------
2 files changed, 56 insertions(+), 46 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2e474e8..e96d72e 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -235,7 +235,7 @@ Interactive mode
----------------
Rebasing interactively means that you have a chance to edit the commits
-which are rebased. You can not only reorder the commits, but also
+which are rebased. You can reorder the commits, and you can
remove them (weeding out bad or otherwise unwanted patches).
The list will look like this:
@@ -247,18 +247,16 @@ pick fa1afe1 The oneline of the next commit
-------------------------------------------
The oneline descriptions are purely for your pleasure; `git-rebase` will
-not look at them but at the commit names, so do not delete or edit the
-names.
+not look at them but at the commit names ("deadbee" and "fa1afe1" in this
+example), so do not delete or edit the names.
By replacing the command "pick" with the command "edit", you can tell
`git-rebase` to stop after applying that commit, so that you can edit
the files and/or the commit message, amend the commit and continue
rebasing.
-If you want to fold two commits into one, just replace the command "pick"
-with "squash" for the second commit. After squashing the commits,
-`git-rebase` will start an editor with both commit messages, so you
-can compose the commit message for the squashed commit.
+If you want to fold two or more commits into one, replace the command
+"pick" with "squash" for the second and subsequent commit.
A common use case for the interactive mode is when you want to reorder
the last 5 commits, such that what was HEAD~4 becomes the new HEAD. To
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 6a960b4..1d1e927 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -78,30 +78,31 @@ STRATEGY=
VERBOSE=
warn () {
- echo "$@" >&2
+ echo "$*" >&2
}
require_clean_work_tree () {
# test if working tree is dirty
git rev-parse --verify HEAD > /dev/null &&
git update-index --refresh &&
- test -z "`git diff-files --name-only`" &&
- test -z "`git diff-index --cached --name-only HEAD`" ||
+ git diff-files --quiet &&
+ git diff-index --cached --quiet HEAD ||
die "Working tree is dirty"
}
ORIG_REFLOG_ACTION="$GIT_REFLOG_ACTION"
comment_for_reflog () {
- if test -z "$ORIG_REFLOG_ACTION"; then
- GIT_REFLOG_ACTION="rebase --interactive ($1)"
+ case "$ORIG_REFLOG_ACTION" in
+ ''|rebase*)
+ GIT_REFLOG_ACTION="rebase -i ($1)"
export GIT_REFLOG_ACTION
- fi
+ esac
}
mark_action_done () {
- sed -n 1p < "$TODO" >> "$DONE"
- sed -n '2,$p' < "$TODO" >> "$TODO".new
+ sed -e 1q < "$TODO" >> "$DONE"
+ sed -e 1d < "$TODO" >> "$TODO".new
mv -f "$TODO".new "$TODO"
}
@@ -117,6 +118,7 @@ die_with_patch () {
pick_one () {
case "$1" in -n) sha1=$2 ;; *) sha1=$1 ;; esac
+ git rev-parse --verify $sha1 || die "Invalid commit name: $sha1"
parent_sha1=$(git rev-parse --verify $sha1^ 2>/dev/null)
current_sha1=$(git rev-parse --verify HEAD)
if [ $current_sha1 = $parent_sha1 ]; then
@@ -131,17 +133,17 @@ pick_one () {
do_next () {
read command sha1 rest < "$TODO"
case "$command" in
- \#)
+ \#|'')
mark_action_done
continue
- ;;
+ ;;
pick)
comment_for_reflog pick
mark_action_done
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
- ;;
+ ;;
edit)
comment_for_reflog edit
@@ -155,11 +157,11 @@ do_next () {
warn " git commit --amend"
warn
exit 0
- ;;
+ ;;
squash)
comment_for_reflog squash
- test -s "$DONE" ||
+ test -z "$(grep -ve '^$' -e '^#' < $DONE)" &&
die "Cannot 'squash' without a previous commit"
mark_action_done
@@ -168,20 +170,21 @@ do_next () {
MSG="$DOTEST"/message
echo "# This is a combination of two commits." > "$MSG"
echo "# The first commit's message is:" >> "$MSG"
- git cat-file commit HEAD | sed -n '/^$/,$p' >> "$MSG"
+ echo >> "$MSG"
+ git cat-file commit HEAD | sed -e '1,/^$/d' >> "$MSG"
echo >> "$MSG"
echo "# And this is the 2nd commit message:" >> "$MSG"
echo >> "$MSG"
- git cat-file commit $sha1 | sed -n '/^$/,$p' >> "$MSG"
+ git cat-file commit $sha1 | sed -e '1,/^$/d' >> "$MSG"
git reset --soft HEAD^
author_script=$(get_author_ident_from_commit $sha1)
case $failed in
f)
# This is like --amend, but with a different message
- eval $author_script
+ eval "$author_script"
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
git commit -F "$MSG" -e
- ;;
+ ;;
t)
cp "$MSG" "$GIT_DIR"/MERGE_MSG
warn
@@ -192,21 +195,22 @@ do_next () {
warn " git commit -F \"$GIT_DIR\"/MERGE_MSG -e"
die_with_patch $sha1 ""
esac
- ;;
+ ;;
*)
warn "Unknown command: $command $sha1 $rest"
die_with_patch $sha1 "Please fix this in the file $TODO."
esac
- test -s "$TODO" && continue
+ test -s "$TODO" && return
HEAD=$(git rev-parse HEAD)
HEADNAME=$(cat "$DOTEST"/head-name)
+# TODO: reflog?
git update-ref $HEADNAME $HEAD &&
git symbolic-ref HEAD $HEADNAME || exit
rm -rf "$DOTEST" &&
warn "Successfully rebased and updated $HEADNAME."
- exit $?
+ exit
}
do_rest () {
@@ -214,12 +218,12 @@ do_rest () {
do
do_next
done
- test $? = 0 -a -f "$DOTEST"/verbose &&
+ test -f "$DOTEST"/verbose &&
git diff --stat $(cat "$DOTEST"/head)..HEAD
exit
}
-while case "$#" in 0) break ;; esac
+while case $# in 0) break ;; esac
do
case "$1" in
--continue)
@@ -229,7 +233,7 @@ do
require_clean_work_tree
do_rest
- ;;
+ ;;
--abort)
comment_for_reflog abort
@@ -241,15 +245,16 @@ do
git reset --hard $HEAD &&
rm -rf "$DOTEST"
exit
- ;;
+ ;;
--skip)
comment_for_reflog skip
test -d "$DOTEST" || die "No interactive rebase running"
git reset --hard && do_rest
- ;;
+ ;;
-s|--strategy)
+ shift
case "$#,$1" in
*,*=*)
STRATEGY="-s `expr "z$1" : 'z-[^=]*=\(.*\)'`" ;;
@@ -259,22 +264,22 @@ do
STRATEGY="-s $2"
shift ;;
esac
- ;;
+ ;;
--merge)
# we use merge anyway
- ;;
+ ;;
-C*)
die "Interactive rebase uses merge, so $1 does not make sense"
- ;;
+ ;;
-v)
VERBOSE=t
- ;;
+ ;;
-i|--interactive)
# yeah, we know
- ;;
+ ;;
''|-h)
usage
- ;;
+ ;;
*)
test -d "$DOTEST" &&
die "Interactive rebase already started"
@@ -295,8 +300,13 @@ do
require_clean_work_tree
- test -z "$2" || git checkout "$2" ||
- die "Could not checkout $2"
+ if [ ! -z "$2"]
+ then
+ git show-ref --verify --quiet "refs/heads/$2" ||
+ die "Invalid branchname: $2"
+ git checkout "$2" ||
+ die "Could not checkout $2"
+ fi
HEAD=$(git rev-parse --verify HEAD) || die "No HEAD?"
UPSTREAM=$(git rev-parse --verify "$1") || die "Invalid base"
@@ -314,23 +324,25 @@ do
test t = "$VERBOSE" && : > "$DOTEST"/verbose
cat > "$TODO" << EOF
-# Reorder by exchanging lines. Skip by removing lines. If you want to
-# edit a commit, replace the "pick" command with "edit". If you want to
-# squash the changes of a commit A into a commit B, place A directly
-# after B, and replace the "pick" command with "squash".
+# Rebasing $UPSTREAM..$HEAD onto $ONTO
+#
+# Commands:
+# pick = use commit
+# edit = use commit, but stop for amending
+# squash = use commit, but meld into previous commit
EOF
git rev-list --no-merges --pretty=oneline --abbrev-commit \
--abbrev=7 --reverse $UPSTREAM..$HEAD | \
sed "s/^/pick /" >> "$TODO"
- test -s "$TODO" || die "Nothing to do"
+ test -z "$(grep -ve '^$' -e '^#' < $TODO)" &&
+ die "Nothing to do"
cp "$TODO" "$TODO".backup
${VISUAL:-${EDITOR:-vi}} "$TODO" ||
die "Could not execute editor"
git reset --hard $ONTO && do_rest
- ;;
esac
shift
done
--
1.5.2.2.279.g9b198-dirty
^ permalink raw reply related
* Re: [PATCH] Add git-save script
From: Nanako Shiraishi @ 2007-06-24 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT
In-Reply-To: <7vmyyq2zrz.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> writes:
> Nanako Shiraishi <nanako3@bluebottle.com> writes:
>
>> +function save_work () {
>
> No noiseword "function" for portability.
>
> When you say "#!/bin/sh", you are writing for the family of
> generic Bourne shells, not specifically for korn nor bash. For
> example, dash is a fine POSIX shell, but does not grok function
> noiseword. When in doubt, please stay away from things not in
> POSIX (e.g. function, [[, ]], ${parameter//pattern/string/}).
Is there a good reference you can point me?
> - $GIT_DIR could contain shell metachararcters / whitespace, so
> could $TMP as well. Always quote such variables, or you risk
> a surprise from "rm".
>
> - You probably would not want to create a new "save" if your
> working tree and the index are clean. To test for the
> condition, you can do something like:
>
> git-diff --quiet --cached && git-diff --quiet
I did not think of these problems, but I understand now.
> - Although you keep a separate tree for the index (before the
> "git add -u" to grab the working tree changes) in the saved
> data, it does not seem to be used. It _might_ make sense to
> replace "git add -u" with "git add ." so that work/ tree
> contains even untracked (but not ignored) files, and on the
> restore side unstage the paths that appear in work/ but not
> in indx/. I dunno.
At first I wanted to do git-add . instead of git-add -u, but then I
became worried that will add files that are not interesting such as
temporary files.
>> +
>> + head=$(git-log --abbrev-commit --pretty=oneline -n 1 HEAD)
>> + if branch=$(git symbolic-ref -q HEAD); then
>> + branch=${branch#refs/heads/}
>> + else
>> + branch='(no branch)'
>> + fi &&
>
> Minor style. Please don't write "; then\n". Line-up "then",
> "elif", "else", and "fi"; it is much easier to read that way.
I see.
> Nice, but after trying this myself a bit, I seriously wished for
> "git save show -p", so I did it myself, like this:
>
> show_save () {
> flags=$(git rev-parse --no-revs --flags "$@")
> if test -z "$flags"
> then
> flags=--stat
> fi
> save=$(git rev-parse --revs-only --no-flags --default saved "$@")
> git diff-tree $flags $save:base $save:work
> }
>
> It's a dense (and ancient style) plumbing code so needs a bit of
> explanation:
>
> - The first git-rev-parse looks at "$@", discards everything
> that are not options and discards object names. So 'git save
> show -p some' will give you "-p" in flags.
>
> - The second one discards flags, and grabs 'some' out of '-p
> some', or defaults to "saved".
I did not know about these commands. I will study the manual pages
and I will re-submit my patch after adding these.
--
しらいし ななこ http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com
^ permalink raw reply
* Re: [PATCH] transplant: move a series of commits to a different parent
From: Steffen Prohaska @ 2007-06-24 10:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706241123170.4059@racer.site>
On Jun 24, 2007, at 12:26 PM, Johannes Schindelin wrote:
>
> Oh! But the commit messages do no longer correspond to their
> patches, do
> they?
>
> Example:
>
> In "onto", you have a sorely needed bugfix in main.c. In "from",
> you have
> not. Then you do your transplant, and all of a sudden, the
> first transplanted commit _undoes_ that bugfix (because you take the
> contents at face value), but the commit message _cannot_ say so, or
> even
> why.
>
> IMHO this makes no sense (and that is why I misunderstood it as
> being a
> rebase).
It doesn't make sense on a sane repository.
I need the script to fix an insane, broken repository that was generated
by git-cvsimport [1]. cvsimport created commits attached to the wrong
parent
in the first place. So the patches derived from this history are wrong.
They are different from the patches that you'd expect from the cvs
repository.
The commit messages and the patches did never correspond. My script
fixes
this relationship. Only after I transplanted the branch the commits and
their messages match.
The following is a different illustration of the same problem.
Suppose you copy
a file and modify its contents somewhere else. Now you checkout the
_wrong_
branch, but do not recognize, copy the file back and commit it. You'd be
writing a message as if the right branch would have been checked out.
This
message describes what you believe you did. But because of the wrong
branch
you may have done something completely different to the repository.
You may
for example have reverted earlier changes. Your commit doesn't make
any sense
before you transplanted it to the right branch. You don't want to
apply a
patch to the right branch but transplant the content of your file.
Steffen
[1] http://article.gmane.org/gmane.comp.version-control.git/50736
^ permalink raw reply
* Re: [PATCH] transplant: move a series of commits to a different parent
From: Johannes Schindelin @ 2007-06-24 10:26 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <9C4338DC-0C4A-4981-9EC9-2417513F629D@zib.de>
Hi,
On Sun, 24 Jun 2007, Steffen Prohaska wrote:
> On Jun 23, 2007, at 11:04 PM, Alex Riesen wrote:
>
> > # detached head
> > git checkout $(git rev-parse onto) && git format-patch --stdout
> > --full-index from..to|git am -3
>
> No. This one tries to apply the _changes_ between from..to. What I need
> is the resulting _content_ of files modified between from..to.
Oh! But the commit messages do no longer correspond to their patches, do
they?
Example:
In "onto", you have a sorely needed bugfix in main.c. In "from", you have
not. Then you do your transplant, and all of a sudden, the
first transplanted commit _undoes_ that bugfix (because you take the
contents at face value), but the commit message _cannot_ say so, or even
why.
IMHO this makes no sense (and that is why I misunderstood it as being a
rebase).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] Move the pick_author code to git-sh-setup
From: Johannes Schindelin @ 2007-06-24 10:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ipt3lh6.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 23 Jun 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > - set_author_env=`git show -s --pretty=raw --encoding="$encoding" "$use_commit" |
> > - LANG=C LC_ALL=C sed -ne "$pick_author_script"`
> > - eval "$set_author_env"
> > ...
> > + eval $(get_author_ident_from_commit "$use_commit")
>
> Are you sure about this part of the change?
No, I am not.
> I suspect that you are losing IFS by not dq'ing the argument you give to
> the eval.
That is well possible. Quoting in shell is such a hassle, and I never seem
to get it right.
Therefore I did a minimal test, namely committing with another
GIT_AUTHOR_NAME (which has spaces in it), and then commiting again, with
"-c HEAD". Which did what I expected: the second commit had the same
author name as the first one.
So I thought that it was okay.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] Teach rebase an interactive mode
From: Johannes Schindelin @ 2007-06-24 10:12 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git, gitster
In-Reply-To: <31A266F6-775E-41AE-B757-BF0DDAC6CAA5@silverinsanity.com>
Hi,
On Sat, 23 Jun 2007, Brian Gernhardt wrote:
> On Jun 23, 2007, at 7:01 PM, Johannes Schindelin wrote:
>
> > With "--interactive", git-rebase now lets you edit the list of patches
> > to be reapplied, so that you can reorder and/or delete patches.
> >
> > Such a list will typically look like this:
> >
> > pick deadbee The oneline of this commit
> > pick fa1afe1 The oneline of the next commit
> > ...
> >
>
> It's not at all obvious from your commit message or the documentation
> where this list comes from.
Oh, okay. I thought that this being just a mode for git-rebase, it would
be obvious where that list comes from... Any idea how to state that more
clearly?
> Is there a way to say "Oops, that's the wrong list. Don't do
> anything."?
It is not at all documented, but yes. Just delete the complete list.
> Perhaps starting the list with a header like the following would make it
> more user-friendly (Obviously requires s/#.*$//):
All lines with "#" are ignored, yes.
> # Rebasing $from..$to onto $commit
> #
> # Commands:
> # pick = use commit
> # squash = meld commit into previous
> # <<More useful information here>>
That's a very good idea! (I completely suck at descriptive texts.) Will
fix.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH][RESEND] Escape some tilde characters causing spurious subscripts in documentation
From: Junio C Hamano @ 2007-06-24 10:07 UTC (permalink / raw)
To: Jason Sewall; +Cc: Johannes Schindelin, git
In-Reply-To: <31e9dd080706231722v760b5a0cnc31e24b83deafb90@mail.gmail.com>
"Jason Sewall" <jasonsewall@gmail.com> writes:
> On 6/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
>> I just checked with my copy of asciidoc, though, and there is no mangling
>> going on, at least in git-bundle.html (which is the only file I checked).
>> My asciidoc is version 8.2.1. What is yours?
>
> I've got 8.1.0; perhaps that's the problem. I wasn't so surprised to
> hear the asciidoc 7 and 8 don't get along, but I'm surprised to see
> that 8.1 and 8.2 are so different.
>
> Anyway, 8.1.0 is apparently what's in Fedora 7 (the distro I'm using
> right now) so it might be worth hanging on to the patch.
FWIW, 7.1.2, 8.2.1 and 7.0.2 all seem to be Ok (the last one is
used to format the pages in html and man branches of git.git).
It is a bit annoying having to use name\~num at some places and
no backslash all others.
Two requests:
- Documentation/git-rev-parse.txt has '{tilde}<n>'. If you
replace that {tilde} with a "~", how does your AsciiDoc
format it? Do you see the same breakage?
- If it breaks, does it fix the breakage if you prefix the "~"
with a backslash, instead of using {tilde}?
If the answer to both questions are "yes", then perhaps we
should get rid of the {tilde} macro we define in
Documentation/asciidoc.conf file, and use your "\~" solution
everywhere.
Also do you see any pattern? It does not seem that all the
"master~3" are broken for you but only some. If your commit
message can describe when quoting is needed, that would help
people who would modify the documentation in the future.
^ permalink raw reply
* Re: help with cvsimport
From: Raimund Bauer @ 2007-06-24 9:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706231213020.4059@racer.site>
Hi,
* Johannes Schindelin wrote, On 23.06.2007 13:27:
> Hi,
>
> On Sat, 23 Jun 2007, Raimund Bauer wrote:
>
>
>> I unfortunately have to work with several cvs-repositories and was
>> wondering if there was a way to have the files processed on import:
>> - strip trailing whitespace
>> - convert to newline-only line endings
>>
>
> If you want to use cvsimport incrementally, I'd rather not process the
> "origin" branch like this, but rather use git-filter-branch (with a simple
> index filter) to do that.
>
> Even if you do not want to use it incrementally, it seems easier and
> cleaner (if somewhat slower) to me.
>
> So, something like
>
> git filter-branch --index-filter 'git ls-files |
> while read name; do
> perl -pi -e "s/[ \009\015]*$//" "$name"
> done
> git add -u' cleaned-up-origin
>
> should do.
>
Thanks, will try that out.
Tough I'm not very happy about having to create an extra branch for
every branch I want to work with.
And a git-solution would also respect git-attributes ...
> Hth,
> Dscho
>
--
best regards
Ray
^ permalink raw reply
* Re: [PATCH] git-svnimport: added explicit merge graph option -G
From: Alex Riesen @ 2007-06-24 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Stas Maximov
In-Reply-To: <7vk5tt25n7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sun, Jun 24, 2007 09:06:20 +0200:
> I received a format-patch output as attachment from Stas. As
> I cannot comment on the patch in that format, I am making a
> verbatim forward to the list.
...
> diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
> old mode 100644
> new mode 100755
executable .txt?
^ permalink raw reply
* Re: [PATCH] transplant: move a series of commits to a different parent
From: Alex Riesen @ 2007-06-24 9:30 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <4D530871-0CBE-4F9A-99B7-ECF0F4656D85@zib.de>
Steffen Prohaska, Sun, Jun 24, 2007 11:05:29 +0200:
> >Steffen Prohaska, Sat, Jun 23, 2007 21:27:57 +0200:
> >>+for commit in $(git-rev-list --reverse $from..$to)
> >>+do
> >>+ echo "rewriting commit $commit..."
> >>+ git-diff-tree -r $commit | grep ^: | cut -b 9-15,57-97,100- |
> >>+ while read mode sha path
> >>+ do
> >>+ echo " $mode $sha $path"
> >>+ git-update-index --add --cacheinfo $mode $sha $path
> >>+ done
> >
> >Why not just read-tree for every commit? It is not like you're
> >modifying the repository in any way, just changing parenthood. That'd
> >solve the problem with deletions.
> >So it should be enough to read-tree the repo state for each and every
> >source commit into the index (and you can just use a temporary index
> >file for that, see GIT_INDEX_FILE). Than just commit the index.
>
> I am changing the repository.
>
No, you don't.
> I only modify the index for files that have changes in $commit. Their
> content gets replaced by the content from the commit. I'm leaving
> all other files untouched.
No, you don't modify anything. Ever tried to run git-status after your
script finished? Tried to understand what the output means?
> This creates a new series of commits that starts from the repository
> state of <onto> and has mixed in files only if they are changed in
> the series of commits from..to. These files are just replaced. I'm not
> trying to merge changes but just replace the whole file.
>
> Opposed to that, read-tree would modify the content of _all_ files.
No, it wouldn't (unless you run git-read-tree -u, and I fail to see
why would you want that). You probably confuse git-read-tree with
git-checkout-index.
> This is exactly what I want to achieve. The content of the files on
> branch 3 is correct for all files that were committed after 2. But
> because 2 is the wrong branching point all the content originating
> from commits between 1 and 2 is wrong. Files committed between
> 2 and 3 have the right content but the branch needs to be attached
> at 1.
This misses merges (see git-rev-list --parents), but does the job for
linear history:
export GIT_INDEX_FILE="$(git rev-parse --git-dir)/tr.idx"
parent=$(git rev-parse "$onto")
git rev-list --reverse "$from..$to" | while read c
do
rm -f "$GIT_INDEX_FILE"
git read-tree $c || break;
# Authorship information here
parent=$(git cat-file commit $c | \
sed -e '1,/^$/d' | \
git commit-tree $(git write-tree) -p "$parent")
echo "Commit $parent"
done
^ permalink raw reply
* Re: [PATCH] transplant: move a series of commits to a different parent
From: Steffen Prohaska @ 2007-06-24 9:05 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070624082906.GB2467@steel.home>
On Jun 24, 2007, at 10:29 AM, Alex Riesen wrote:
> Steffen Prohaska, Sat, Jun 23, 2007 21:27:57 +0200:
>> +for commit in $(git-rev-list --reverse $from..$to)
>> +do
>> + echo "rewriting commit $commit..."
>> + git-diff-tree -r $commit | grep ^: | cut -b 9-15,57-97,100- |
>> + while read mode sha path
>> + do
>> + echo " $mode $sha $path"
>> + git-update-index --add --cacheinfo $mode $sha $path
>> + done
>
> Why not just read-tree for every commit? It is not like you're
> modifying the repository in any way, just changing parenthood. That'd
> solve the problem with deletions.
> So it should be enough to read-tree the repo state for each and every
> source commit into the index (and you can just use a temporary index
> file for that, see GIT_INDEX_FILE). Than just commit the index.
I am changing the repository.
I only modify the index for files that have changes in $commit. Their
content gets replaced by the content from the commit. I'm leaving
all other files untouched.
This creates a new series of commits that starts from the repository
state of <onto> and has mixed in files only if they are changed in
the series of commits from..to. These files are just replaced. I'm not
trying to merge changes but just replace the whole file.
Opposed to that, read-tree would modify the content of _all_ files.
Here's the situation before transplant
o--Y--3
/
1--X--2--o--o--o
Say at X the file x.txt got modified. At Y the file y.txt got modified.
3 has both modifications.
Now I do transplant 1 2 3, which yields
o--Y--4
/
1--X--2--o--o--o
y.txt is identical in 3 and 4 but x.txt is identical in 1 (!) and 4.
Hence 3 and 4 are different. The changes to x.txt in commit X got
eliminated from the history. 4 is a mixture of 1 and the repository
state of files at 3 that got modified between 2 and 3. Changes between
1 and 2 got eliminated from the history.
This is exactly what I want to achieve. The content of the files on
branch 3 is correct for all files that were committed after 2. But
because 2 is the wrong branching point all the content originating
from commits between 1 and 2 is wrong. Files committed between
2 and 3 have the right content but the branch needs to be attached
at 1.
Steffen
^ permalink raw reply
* Re: (resend) [PATCH] Don't ignore write failure from git-diff, git-log, etc.
From: Junio C Hamano @ 2007-06-24 9:01 UTC (permalink / raw)
To: Jim Meyering; +Cc: git, torvalds
In-Reply-To: <87abuq1z6f.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> From: Jim Meyering <jim@meyering.net>
> Date: Sat, 26 May 2007 13:43:07 +0200
> Subject: [PATCH] Don't ignore write failure from git-diff, git-log, etc.
>
> Currently, when git-diff writes to a full device or gets an I/O error,
> it fails to detect the write error:
> ...
> Also, to be consistent with e.g., write_or_die, do not
> diagnose EPIPE write failures.
I still do not like the fact that this patch makes an error from
the final stdout flushing override the return value from p->fn()
even when the function already diagnosed an error, but otherwise
I think it is a good change, as it allows us to catch one error
case that we currently don't, without introducing an annoying
EPIPE diagnosis.
Naks, or vetoes?
^ permalink raw reply
* Re: [PATCH] git-svnimport: added explicit merge graph option -G
From: Peter Baumann @ 2007-06-24 8:44 UTC (permalink / raw)
To: Stas Maximov; +Cc: git, Junio C Hamano
In-Reply-To: <7vk5tt25n7.fsf@assigned-by-dhcp.cox.net>
On Sun, Jun 24, 2007 at 12:06:20AM -0700, Junio C Hamano wrote:
> From: Stas Maximov <smaximov@yahoo.com>
> Date: Sat, 23 Jun 2007 09:06:30 -0700
>
> Allows explicit merge graph information to be provided. Each line
> of merge graph file must contain a pair of SVN revision numbers
> separated by space. The first number is child (merged to) SVN rev
> number and the second is the parent (merged from) SVN rev number.
> Comments can be started with '#' and continue to the end of line.
> Empty and space-only lines are allowed and will be ignored.
> ---
>
> * Stas, please give a "Signed-off-by" line, and get in the
> habit of always CC the list.
>
> I received a format-patch output as attachment from Stas. As
> I cannot comment on the patch in that format, I am making a
> verbatim forward to the list.
>
> I'll comment on the patch separately when I am through it,
> but would appreciate comments from people who were involved
> in git-svnimport in the past, and still use it.
>
> "You should use git-svn instead" people can repeat that as
> usual, but at the same time it might be worth realizing that
> there are people who maintain git-svnimport being better for
> one-short importing.
>
[exchanging To:/Cc: as Junio just forwarded the message from Stas]
Not commenting on the patch per se, but wouldn't it make more
sense to have such functionality in a history rewriting tool like
e.g. git-branch-filter?
I had an svn import (git-svn) where I wanted to give correct
branch/merge points, too, and so I manually created a grafts file
annotating all the svn merges. Having such a thing as a _generic_ tool
which operates on grafts would be much more usefull because you get one
implementation which could be used for each and every importer out
there. Sure, you have to transform the native revision specifieres into
the GIT commit id's if you only have e.g. "merged r4711:4720 into trunk",
but these functionality is much more common to have in importers
than whats implemented in the above mentioned patch.
Another bonus point of using the grafts mechanism you'll get for free is
that you could _look_ at the commit graph in gitk *before* doing the
often expensive reimport of your project, so could be sure you haven't
forgotten to mark a merge.
-Peter Baumann
^ permalink raw reply
* Re: [PATCH] transplant: move a series of commits to a different parent
From: Alex Riesen @ 2007-06-24 8:29 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11826268772950-git-send-email-prohaska@zib.de>
Steffen Prohaska, Sat, Jun 23, 2007 21:27:57 +0200:
> +for commit in $(git-rev-list --reverse $from..$to)
> +do
> + echo "rewriting commit $commit..."
> + git-diff-tree -r $commit | grep ^: | cut -b 9-15,57-97,100- |
> + while read mode sha path
> + do
> + echo " $mode $sha $path"
> + git-update-index --add --cacheinfo $mode $sha $path
> + done
Why not just read-tree for every commit? It is not like you're
modifying the repository in any way, just changing parenthood. That'd
solve the problem with deletions.
So it should be enough to read-tree the repo state for each and every
source commit into the index (and you can just use a temporary index
file for that, see GIT_INDEX_FILE). Than just commit the index.
^ permalink raw reply
* Re: [PATCH] transplant: move a series of commits to a different parent
From: Alex Riesen @ 2007-06-24 8:20 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <9C4338DC-0C4A-4981-9EC9-2417513F629D@zib.de>
Steffen Prohaska, Sun, Jun 24, 2007 09:08:16 +0200:
>
> On Jun 23, 2007, at 11:04 PM, Alex Riesen wrote:
>
> >>git-transplant.sh <onto> <from> <to>
> >>
> >>transplant starts with the contents of <onto> and puts on top of
> >>it the contents of files if they are touched by the series of
> >>commits <from>..<to>. If a commit touches a file the content of
> >>this file is taken as it is in the commit. No merging is
> >>performed. Original authors, commiters, and commit messages are
> >>preserved.
> >>
> >[...]
> ># detached head
> >git checkout $(git rev-parse onto) && git format-patch --stdout
> >--full-index from..to|git am -3
>
> No. This one tries to apply the _changes_ between from..to. What I
> need is the resulting _content_ of files modified between from..to.
>
Ach, yes. I should have read your message a bit more closely. There is
a term for that "contents of files", BTW: "repository state".
> I believe it's more like git-filter-branch, but I wasn't yet abel to
> tell git-filter-branch how to do the job.
I suspect git-filter-branch can be both.
^ permalink raw reply
* Re: [PATCH 2/2] Teach rebase an interactive mode
From: Junio C Hamano @ 2007-06-24 8:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706240001150.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 0c00090..2e474e8 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> ...
> +Interactive mode
> +----------------
> +
> +Rebasing interactively means that you have a chance to edit the commits
> +which are rebased. You can not only reorder the commits, but also
> +remove them (weeding out bad or otherwise unwanted patches).
Maybe it's just my bad English comprehension skill, but I needed
to read "You can not only ... but also" twice. "You can reorder
and also remove" would mean the same thing and would be much
easier for non natives to understand.
> +
> +The list will look like this:
> +
> +-------------------------------------------
> +pick deadbee The oneline of this commit
> +pick fa1afe1 The oneline of the next commit
> +...
> +-------------------------------------------
> +
> +The oneline descriptions are purely for your pleasure; `git-rebase` will
> +not look at them but at the commit names, so do not delete or edit the
> +names.
By "commit name", do you mean deadbee? After reading the full
patch I know that is what you meant, but it was a bit unclear
during my initial pass.
> +By replacing the command "pick" with the command "edit", you can tell
> +`git-rebase` to stop after applying that commit, so that you can edit
> +the files and/or the commit message, amend the commit and continue
> +rebasing.
> +
> +If you want to fold two commits into one, just replace the command "pick"
> +with "squash" for the second commit. After squashing the commits,
> +`git-rebase` will start an editor with both commit messages, so you
> +can compose the commit message for the squashed commit.
There was a question about squashing more than two on the list,
and you explained it as "one would get the idea", but I am not
sure I got it right. Would this be what you meant?
If you want to fold two or more commits into one,
replace the command "pick" with "squash" for the second
and subsequent commit.
> diff --git a/Makefile b/Makefile
> index 0d904a9..edb421b 100644
> --- a/Makefile
> +++ b/Makefile
> ...
> +# MOTIVATION
> +#
> +# Consider this type of workflow:
> ...
> +# Sometimes the thing fixed in B.2. cannot be amended to the not-quite
> +# perfect commit it fixes, because that commit is buried deeply in a
> +# patch series.
> +#
> +# Use this script after plenty of "A"s and "B"s, by rearranging, and
> +# possibly editing and merging commits.
This part is missing from Documentation/git-rebase.txt and
should move there, and the USAGE: part of the documentation
should be removed from here; otherwise you need to maintain the
two in sync.
> +USAGE='(--continue | --abort | --skip | [--onto <branch>] <upstream> [<branch>])'
> +
> +. git-sh-setup
> +require_work_tree
> +
> +DOTEST="$GIT_DIR/.dotest-merge"
> +TODO="$DOTEST"/todo
> +DONE="$DOTEST"/done
> +STRATEGY=
> +VERBOSE=
> +
> +warn () {
> + echo "$@" >&2
> +}
I would have used "$*" instead.
> +require_clean_work_tree () {
> + # test if working tree is dirty
> + git rev-parse --verify HEAD > /dev/null &&
> + git update-index --refresh &&
> + test -z "`git diff-files --name-only`" &&
> + test -z "`git diff-index --cached --name-only HEAD`" ||
> + die "Working tree is dirty"
> +}
Heh, I think I showed
git diff-files --quiet && git diff-index --cached --quiet
to somebody else today. Let's be modern ;-).
Is today my "nitpick shell scripts day"? ;-)
> +ORIG_REFLOG_ACTION="$GIT_REFLOG_ACTION"
> +
> +comment_for_reflog () {
> + if test -z "$ORIG_REFLOG_ACTION"; then
> + GIT_REFLOG_ACTION="rebase --interactive ($1)"
> + export GIT_REFLOG_ACTION
Please use shorter prefix, "rebase -i". "git reflog" output is
easer to read that way.
> + fi
> +}
> +
> +mark_action_done () {
> + sed -n 1p < "$TODO" >> "$DONE"
> + sed -n '2,$p' < "$TODO" >> "$TODO".new
> + mv -f "$TODO".new "$TODO"
> +}
I would have written "sed -e 1q" and "sed -e 1d".
> +make_patch () {
> + parent_sha1=$(git rev-parse --verify "$1"^ 2> /dev/null)
> + git diff "$parent_sha1".."$1" > "$DOTEST"/patch
> +}
> +
> +die_with_patch () {
> + make_patch "$1"
> + die "$2"
> +}
> +
> +pick_one () {
> + case "$1" in -n) sha1=$2 ;; *) sha1=$1 ;; esac
> + parent_sha1=$(git rev-parse --verify $sha1^ 2>/dev/null)
> + current_sha1=$(git rev-parse --verify HEAD)
> + if [ $current_sha1 = $parent_sha1 ]; then
> + git reset --hard $sha1
> + sha1=$(git rev-parse --short $sha1)
> + warn Fast forward to $sha1
> + else
> + git cherry-pick $STRATEGY "$@"
> + fi
> +}
I wonder what happens when the user mistakenly breaks the commit
object name on the 'pick' command line and the above --verify
fails. A bit better error checking is needed here.
> +
> +do_next () {
> + read command sha1 rest < "$TODO"
> + case "$command" in
> + \#)
Hmph. Don't you allow a blank line also as a comment (for readability)?
> + mark_action_done
> + continue
> + ;;
Style. Indent ';;' one more level, that is:
case "$to_test" in
arm1)
action
;;
...
esac
> + squash)
> + comment_for_reflog squash
> +
> + test -s "$DONE" ||
> + die "Cannot 'squash' without a previous commit"
As '#' comment line is sent to DONE file with mark_action_done,
non empty DONE file does not necessarily mean you have a
previous commit --- am I mistaken?
> +
> + mark_action_done
> + failed=f
> + pick_one -n $sha1 || failed=t
> + MSG="$DOTEST"/message
> + echo "# This is a combination of two commits." > "$MSG"
> + echo "# The first commit's message is:" >> "$MSG"
> + git cat-file commit HEAD | sed -n '/^$/,$p' >> "$MSG"
> + echo >> "$MSG"
> + echo "# And this is the 2nd commit message:" >> "$MSG"
> + echo >> "$MSG"
> + git cat-file commit $sha1 | sed -n '/^$/,$p' >> "$MSG"
So you have one blank line after "# The first commit's message is:"
but have two blank lines after "# And this is the 2nd"?
Style. Always prefix sed scripts with "-e", like so:
git cat-file commit HEAD | sed -e '1,/^$/d'
> + git reset --soft HEAD^
> + author_script=$(get_author_ident_from_commit $sha1)
> + case $failed in
> + f)
> + # This is like --amend, but with a different message
> + eval $author_script
Missing dq, like the other patch to git-commit?
> + export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
> + git commit -F "$MSG" -e
> + ;;
> + t)
> + cp "$MSG" "$GIT_DIR"/MERGE_MSG
> + warn
> + warn "Could not apply $sha1... $rest"
> + warn "After you fixed that, commit the result with"
> + warn
> + warn " $(echo $author_script | tr '\012' ' ') \\"
> + warn " git commit -F \"$GIT_DIR\"/MERGE_MSG -e"
> + die_with_patch $sha1 ""
> + esac
> + ;;
> + *)
> + warn "Unknown command: $command $sha1 $rest"
> + die_with_patch $sha1 "Please fix this in the file $TODO."
> + esac
> + test -s "$TODO" && continue
It is not clear to me from reading the POSIX that this
"continue" is allowed, although both bash and dash seem to work
as you expect. continue "shall return to the top of the
smallest enclosing for, while or until loop" and the enclosing
while loop you are continuing is actually the one in do_rest
function, which is the caller of this. If POSIX meant dynamic
scoping rules, that is fine, but lexically that 'while' does not
enclose this 'continue'.
I think this one can safely be changed to "return" and there
won't be any need for such an worry.
> +
> + HEAD=$(git rev-parse HEAD)
> + HEADNAME=$(cat "$DOTEST"/head-name)
> + git update-ref $HEADNAME $HEAD &&
> + git symbolic-ref HEAD $HEADNAME || exit
Don't we want reflog entries for these two operations?
> + rm -rf "$DOTEST" &&
> + warn "Successfully rebased and updated $HEADNAME."
> +
> + exit $?
> +}
> +
> +do_rest () {
> + while :
> + do
> + do_next
> + done
>
> + test $? = 0 -a -f "$DOTEST"/verbose &&
> + git diff --stat $(cat "$DOTEST"/head)..HEAD
I am not sure what command's exit status $? refers to at this
point. do_next is not run in a subshell, so when it exits, you
would not reach here, would you?
> + exit
> +}
One says "exit $?" the other says "exit" -- they mean the same
;-).
> +while case "$#" in 0) break ;; esac
> +do
No need to quote $#.
> + case "$1" in
> + --continue)
> + comment_for_reflog continue
> +
> + test -d "$DOTEST" || die "No interactive rebase running"
> +
> + require_clean_work_tree
> + do_rest
> + ;;
Indent ;; one more level please.
> + --abort)
> + comment_for_reflog abort
> +
> + test -d "$DOTEST" || die "No interactive rebase running"
> +
> + HEADNAME=$(cat "$DOTEST"/head-name)
> + HEAD=$(cat "$DOTEST"/head)
> + git symbolic-ref HEAD $HEADNAME &&
> + git reset --hard $HEAD &&
> + rm -rf "$DOTEST"
> + exit
> + ;;
> + --skip)
> + comment_for_reflog skip
> +
> + test -d "$DOTEST" || die "No interactive rebase running"
> +
> + git reset --hard && do_rest
> + ;;
> + -s|--strategy)
> + case "$#,$1" in
> + *,*=*)
> + STRATEGY="-s `expr "z$1" : 'z-[^=]*=\(.*\)'`" ;;
> + 1,*)
> + usage ;;
> + *)
> + STRATEGY="-s $2"
> + shift ;;
> + esac
Are we missing a shift before the above "case"?
> + ;;
> + --merge)
> + # we use merge anyway
> + ;;
> + -C*)
> + die "Interactive rebase uses merge, so $1 does not make sense"
> + ;;
> + -v)
> + VERBOSE=t
> + ;;
> + -i|--interactive)
> + # yeah, we know
> + ;;
> + ''|-h)
> + usage
> + ;;
> + *)
> + test -d "$DOTEST" &&
> + die "Interactive rebase already started"
> +
> + git var GIT_COMMITTER_IDENT >/dev/null ||
> + die "You need to set your committer info first"
> +
> + comment_for_reflog start
> +
> + ONTO=
> + case "$1" in
> + --onto)
> + ONTO=$(git rev-parse --verify "$2") ||
> + die "Does not point to a valid commit: $2"
> + shift; shift
> + ;;
> + esac
> +
> + require_clean_work_tree
> +
> + test -z "$2" || git checkout "$2" ||
> + die "Could not checkout $2"
Can you afford to detach HEAD here? Later you check with
symbolic-ref so I think not, which means "$2" must be a valid
branch name, so it should be tested like:
git show-ref --verify --quiet "refs/heads/$2"
> + HEAD=$(git rev-parse --verify HEAD) || die "No HEAD?"
> + UPSTREAM=$(git rev-parse --verify "$1") || die "Invalid base"
> +
> + test -z "$ONTO" && ONTO=$UPSTREAM
> +
> + mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
> + : > "$DOTEST"/interactive || die "Could not mark as interactive"
> + git symbolic-ref HEAD > "$DOTEST"/head-name ||
> + die "Could not get HEAD"
> +
> + echo $HEAD > "$DOTEST"/head
> + echo $UPSTREAM > "$DOTEST"/upstream
> + echo $ONTO > "$DOTEST"/onto
> + test t = "$VERBOSE" && : > "$DOTEST"/verbose
> +
> + cat > "$TODO" << EOF
> +# Reorder by exchanging lines. Skip by removing lines. If you want to
> +# edit a commit, replace the "pick" command with "edit". If you want to
> +# squash the changes of a commit A into a commit B, place A directly
> +# after B, and replace the "pick" command with "squash".
> +EOF
> + git rev-list --no-merges --pretty=oneline --abbrev-commit \
> + --abbrev=7 --reverse $UPSTREAM..$HEAD | \
> + sed "s/^/pick /" >> "$TODO"
> +
> + test -s "$TODO" || die "Nothing to do"
> +
> + cp "$TODO" "$TODO".backup
> + ${VISUAL:-${EDITOR:-vi}} "$TODO" ||
> + die "Could not execute editor"
> +
> + git reset --hard $ONTO && do_rest
> + ;;
> + esac
> + shift
> +done
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 2aa3a01..9e25158 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -3,7 +3,7 @@
> # Copyright (c) 2005 Junio C Hamano.
> #
>
> -USAGE='[-v] [--onto <newbase>] <upstream> [<branch>]'
> +USAGE='[--interactive | -i] [-v] [--onto <newbase>] <upstream> [<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>
> @@ -120,6 +120,16 @@ finish_rb_merge () {
> echo "All done."
> }
>
> +is_interactive () {
> + test -f "$dotest"/interactive ||
> + while case "$1" in ''|-i|--interactive) break ;; esac
> + do
> + shift
> + done && test -n "$1"
> +}
I think by case "$1" in '') you meant "we ran out", but that is
not a good pattern. Check $# at the same time, otherwise you
would stop at an empty argument that is followed by other
arguments.
This is just an idea, but I have been wondering if it would be
useful if we teach rebase (interactive or not) to handle a merge
from an unrelated (wrt the rebase that is being performed)
branch. That is, if you had this development on top of the
origin 'O':
X
\
A---M---B
/
---o---O
that you committed A, merged X and then committed B, you should
be able to rebase on top of an updated upstream 'Q':
X
\
A---M---B
/
---o---O---P---Q
by 'pick A/merge M/pick B', which would do:
X
\
A'--M'--B'
/
---o---O---P---Q
Note that A', M' and B' are different commit objects (rebase
rewrites the history) from the original picture, but X is the
same commit from the original picture.
^ 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