* Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Junio C Hamano @ 2005-08-08 20:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508081257190.3258@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> It may not have the nicest error messages: if you try to revert a merge
>> (which won't have a diff), git-apply will say something like
>>
>> fatal: No changes
>>
>> which isn't exactly being helpful. And the revert message could be made
>> more interesting (like putting the first line of the description of what
>> we reverted into the message instead of just the revision number).
> Comments?
>
> Linus
I like the general idea, and if we had a commit pretty format
"oneline", then something like this would make it look nicer.
Totally untested. I acquired your habit of coding in my e-mail
client ;-).
#!/bin/sh
. git-sh-setup-script || die "Not a git archive"
rev=$(git-rev-parse --verify --revs-only "$@") &&
commit=$(git-rev-parse --verify --revs-only "$commit^0") || exit
if git-diff-tree -R -p $commit | git-apply --index &&
msg=$(git-rev-list --pretty=oneline --max-count=1 $commit)
then
{
echo "Revert $msg"
echo
echo "This reverts $commit commit."
test "$rev" = "$commit" ||
echo "(original 'git revert' arguments: $@)"
} | git commit
else
# Now why did it fail?
parents=`git-cat-file commit "$commit" 2>/dev/null |
sed -ne '/^$/q;/^parent /p' |
wc -l`
case $parents in
0) die "Cannot revert the root commit nor non commit-ish" ;;
1) die "The patch does not apply" ;;
*) die "Cannot revert a merge commit" ;;
esac
fi
^ permalink raw reply
* Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Junio C Hamano @ 2005-08-08 20:53 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1123306575.7588.17.camel@dv.roinet.com>
Pavel Roskin <proski@gnu.org> writes:
> Quoting GNU Coding Standards ("info standards"):
>
> "If there are C compiler options that _must_ be used for proper
> compilation of certain files, do not include them in `CFLAGS'. Users
> expect to be able to specify `CFLAGS' freely themselves."
Quoting Documentation/CodingStyle:
This is a short document describing the preferred coding style for the
linux kernel. Coding style is very personal, and I won't _force_ my
views on anybody, but this is what goes for anything that I have to be
able to maintain, and I'd prefer it for most other things too. Please
at least consider the points made here.
First off, I'd suggest printing out a copy of the GNU coding
standards, and NOT read it. Burn them, it's a great symbolic
gesture.
This was only a tongue-in-cheek comment ;-).
Seriously, I do not intend to discarded this patch, but I am
currently not taking Makefile patches unless they fix real
breakage.
I do want to revisit Makefile issues after 0.99.4, along with
the changes Pasky sent several days ago. Please remind me about
them after Wednesday.
^ permalink raw reply
* Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Linus Torvalds @ 2005-08-08 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5oo40mq.fsf@assigned-by-dhcp.cox.net>
On Mon, 8 Aug 2005, Junio C Hamano wrote:
>
> Totally untested. I acquired your habit of coding in my e-mail
> client ;-).
Looks good. Although I also have this advanced testing habit of just
reading the email and if it looks sane it tested out ok ;)
But it strikes me that we could use the "-M" flag to git-diff-tree, which
makes it a lot more likely that we can revert renames, even if the file
has been slightly changed afterwards.
Linus
^ permalink raw reply
* Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Junio C Hamano @ 2005-08-08 21:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508081357020.3258@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 8 Aug 2005, Junio C Hamano wrote:
>>
>> Totally untested. I acquired your habit of coding in my e-mail
>> client ;-).
>
> Looks good. Although I also have this advanced testing habit of just
> reading the email and if it looks sane it tested out ok ;)
Heh, I immediately spotted two bugs after I sent it out, one
mine, another yours.
* dereferencing potential tag to get to the underlying commit
was a good idea of mine, poorly executed. It should
rev-parse $rev^0, not $commit^0.
* git commit does not take commit message from stdin. I think
we should do something like this:
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -92,11 +92,13 @@ then
rm .editmsg
exit 1
fi
-case "$use_commit" in
-'')
+if test -t 0 && "$use_commit" = ""
+then
${VISUAL:-${EDITOR:-vi}} .editmsg
- ;;
-esac
+else
+ echo >&2 "(reading commit message from standard input)"
+ cat >.editmsg
+fi
grep -v '^#' < .editmsg | git-stripspace > .cmitmsg
[ -s .cmitmsg ] &&
tree=$(git-write-tree) &&
^ permalink raw reply
* A simple script to do the reverse of git-push
From: Johannes Schindelin @ 2005-08-08 21:25 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 912 bytes --]
Hi list,
I mentioned in another mail that I needed the opposite of git-push, namely
getting all heads, and if they are strict parents of the local refs, just
update them.
Well, Junio pointed out that it's easy using the available tools, and he
was right. The result is attached (and tested...).
This script makes it easy to work with a central repository, multiple
heads and users, in a CVS style: to start your day, you call the attached
script, and after you have committed something, you can do a push on the
repository. Sometimes, the push fails, then you have to pull that branch
in order to merge it before trying a push again.
BTW, if you are lazy, like me, you just pull from Junio once in a while
and do a "make test". Turns out there is a missing dependency though:
peek-remote.o: cache.h
which in my case lead to a git-peek-remote program which was unable to
peek any ref.
Ciao,
Dscho
[-- Attachment #2: Type: TEXT/PLAIN, Size: 930 bytes --]
#!/bin/sh
. git-sh-setup-script || die "Not a git archive"
. git-parse-remote "$@"
repo="$_remote_repo"
git-ls-remote-script --heads "$repo" | while read sha1 refname; do
shortname=$(basename $refname)
if [ -e $GIT_DIR/$refname ]; then
if [ $sha1 = $(cat $GIT_DIR/$refname) ]; then
echo $shortname up to date. 1>&2
continue
fi
fi
git-cat-file commit $sha1 >/dev/null 2>&1 ||
git-fetch-script $repo $shortname
if [ ! -e $GIT_DIR/$refname ]; then
echo Got new head $shortname 1>&2
echo $sha1 > $GIT_DIR/$refname
else
origsha1=$(cat $GIT_DIR/$refname)
if [ -z "$(git-rev-list $origsha1 ^$sha1)" ]; then
echo Updated head $shortname 1>&2
echo $sha1 > $GIT_DIR/$refname
else
saveref=$GIT_DIR/FETCH_HEAD_$shortname
echo Error: $shortname not a child of remote head 1>&2
echo " Saved remote head to $saveref" 1>&2
echo $sha1 > $saveref
fi
fi
done
^ permalink raw reply
* git-commit-script, was Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Johannes Schindelin @ 2005-08-08 21:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7voe882kds.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 8 Aug 2005, Junio C Hamano wrote:
> * git commit does not take commit message from stdin. I think
> we should do something like this:
>
> [...]
And could we rename the *-m* flag at the same time? Because I often catch
myself typing
git commit -m "Some_commit_message"
Ciao,
Dscho
^ permalink raw reply
* Re: git-commit-script, was Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Junio C Hamano @ 2005-08-08 21:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508082329170.2934@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> And could we rename the *-m* flag at the same time? Because I often catch
> myself typing
>
> git commit -m "Some_commit_message"
Sure, what's the alternative spelling for the current -m,
though? Would -c be OK for commit?
^ permalink raw reply
* Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Linus Torvalds @ 2005-08-08 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe882kds.fsf@assigned-by-dhcp.cox.net>
On Mon, 8 Aug 2005, Junio C Hamano wrote:
>
> * git commit does not take commit message from stdin. I think
> we should do something like this:
Yes. Alteratively (or additionally), we should add a command line option
to set the commit message.
CVS uses "-m", but you already took that. I forget what BK used, but I
think it was "-Y" (with lowercase "-y" being "take message from file". Or
maybe the other way around).
Or if you want to be more CVS-like, use "-F", and accept "-" for stdin?
But I like "test -t 0" regardless. Very few editors are ok with non-tty
stdin, although I could imagine some disturbed individual having "ed" as
their editor and expecting to be able to pipe commands into it or
something.
Linus
^ permalink raw reply
* Re: git-commit-script, was Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Linus Torvalds @ 2005-08-08 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vhde02jab.fsf@assigned-by-dhcp.cox.net>
On Mon, 8 Aug 2005, Junio C Hamano wrote:
>
> Sure, what's the alternative spelling for the current -m,
> though? Would -c be OK for commit?
How about using long names?
git commit --reuse-message <sha1>
looks a lot more intuitively understandable to me than something like "-c"
Most of us don't use 300bps terminals any more, so typing a few extra
characters is probably ok.
Now, to make things be backwards-compatible, it should be easy enough to
notice
"Oh, the argument to '-m' is just a single SHA1, let's see if it's a
commit, and turn '-m' into '--reuse-message' automatically"
If anybody cares. Does cogito already use "-m"?
Linus
^ permalink raw reply
* Re: Request for help from binary packaging people.
From: Junio C Hamano @ 2005-08-08 22:02 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20050808185858.GC8041@shell0.pdx.osdl.net>
Chris Wright <chrisw@osdl.org> writes:
> ... Also, rpm is able to determine the perl dependencies
> automatically (of course, ditto for shared libraries).
I take it to mean that we do not have to explicitly list perl
module dependencies. If that is the case then I presume that
the current dependency list is fine.
^ permalink raw reply
* Re: Request for help from binary packaging people.
From: Chris Wright @ 2005-08-08 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Wright, git
In-Reply-To: <7vbr482ik5.fsf@assigned-by-dhcp.cox.net>
* Junio C Hamano (junkio@cox.net) wrote:
> Chris Wright <chrisw@osdl.org> writes:
>
> > ... Also, rpm is able to determine the perl dependencies
> > automatically (of course, ditto for shared libraries).
>
> I take it to mean that we do not have to explicitly list perl
> module dependencies. If that is the case then I presume that
> the current dependency list is fine.
That's correct. The only benefit to itemzing the package level dependency in
this case is just for an error message that tells you which package
you're missing rather than the low-level perl module.
thanks,
-chris
^ permalink raw reply
* Re: A simple script to do the reverse of git-push
From: Junio C Hamano @ 2005-08-08 22:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508082318400.2911@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> BTW, if you are lazy, like me, you just pull from Junio once in a while
> and do a "make test". Turns out there is a missing dependency though:
>
> peek-remote.o: cache.h
>
> which in my case lead to a git-peek-remote program which was unable to
> peek any ref.
You are right. Thanks for noticing.
$ (make clean ; make ) >/dev/null 2>/dev/null
$ touch cache.h
$ make 2>&1 | grep peek-remote
cc -g -O2 -Wall '-DSHA1_HEADER=<openssl/sha.h>' -o git-peek-remote peek-remote.o libgit.a -lz -lcrypto
I think recent "depend on object files" Makefile patch broke
some things.
We would need something like this.
---
# - pu: ls-remote: drop storing operation and add documentation.
# + (working tree)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -172,6 +172,7 @@ init-db.o: init-db.c
$(CC) -c $(CFLAGS) -DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir)"' $*.c
$(LIB_OBJS): $(LIB_H)
+$(patsubst git-%,%.o,$(PROG)): $(LIB_H)
$(DIFF_OBJS): diffcore.h
$(LIB_FILE): $(LIB_OBJS)
^ permalink raw reply
* Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Junio C Hamano @ 2005-08-08 22:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508081444040.3258@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Or if you want to be more CVS-like, use "-F", and accept "-" for stdin?
Yes my vote goes:
-m "message"
-c "from this commit, literally."
-C "from this commit, but let me edit the log further."
-F "from this file."
-F - <stdin
> But I like "test -t 0" regardless. Very few editors are ok with non-tty
> stdin, although I could imagine some disturbed individual having "ed" as
> their editor and expecting to be able to pipe commands into it or
> something.
I am a disturbed individual who always works in Emacs and run
"git commit" in the compilation buffer, setting EDITOR to
emacsclient. Admittably the compilation buffer uses pty, so
"test -t 0" would succeed, though.
^ permalink raw reply
* Re: Request for help from binary packaging people.
From: Junio C Hamano @ 2005-08-08 22:49 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20050808222119.GE7762@shell0.pdx.osdl.net>
Chris Wright <chrisw@osdl.org> writes:
>> I take it to mean that we do not have to explicitly list perl
>> module dependencies. If that is the case then I presume that
>> the current dependency list is fine.
>
> That's correct. The only benefit to itemzing the package level dependency in
> this case is just for an error message that tells you which package
> you're missing rather than the low-level perl module.
Again, thanks.
^ permalink raw reply
* Re: git-commit-script, was Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Junio C Hamano @ 2005-08-08 22:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.58.0508081458550.3258@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Most of us don't use 300bps terminals any more, so typing a few extra
> characters is probably ok.
Again you are right.
^ permalink raw reply
* Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Ryan Anderson @ 2005-08-08 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vy87c2lrv.fsf@assigned-by-dhcp.cox.net>
On Mon, Aug 08, 2005 at 01:53:24PM -0700, Junio C Hamano wrote:
> I do want to revisit Makefile issues after 0.99.4, along with
> the changes Pasky sent several days ago. Please remind me about
> them after Wednesday.
We should discuss (or just do) a reorganization of how we lay out the
source tree.
There's probably a few too many files in the top directory, from all the
porcelain we've built on the plumbing. (heh)
I haven't really given a lot of thought to this yet, but I was thinking
of something along these lines:
Rename tools/ to mail-tools/, push git-send-email-script into that.
Create a "porcelain" directory for things like git-bisect-script
Create a "core" directory for things like "git-commit-script"
Create a "src" (?) directory for *.[ch]
Maybe move documentation into the same directory as the scripts they
belong to.
Then we can argue over where the leftover things fall.
If we can get the directory structure to make sense and start putting
new things into the right spots, the exact location of where *current*
things end up is probably not so important.
I consider this post 1.0 material, personally.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: A simple script to do the reverse of git-push
From: Johannes Schindelin @ 2005-08-08 23:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslxk125f.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 8 Aug 2005, Junio C Hamano wrote:
> We would need something like this.
>
> [...]
>
> +$(patsubst git-%,%.o,$(PROG)): $(LIB_H)
A short
for i in git-*; do \
c=$(echo $i|sed "s/git-\(.*\)/\1.c/g")
if [ -e $c ]; then \
if ! grep cache\\.h $c; then \
echo $c does not depend on cache.h \
fi \
fi \
done
(actually tested) reveals that only get-tar-commit-id.c and stripspace.c
do not depend on cache.h or rev-cache.h. Thus, your patch is the most
elegant solution to my problem :-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Johannes Schindelin @ 2005-08-08 23:42 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, Pavel Roskin, git
In-Reply-To: <20050808231036.GA22778@mythryan2.michonline.com>
Hi,
On Mon, 8 Aug 2005, Ryan Anderson wrote:
> [...]
>
> We should discuss (or just do) a reorganization of how we lay out the
> source tree.
>
> [...]
I, for one, like the layout. There are not yet enough files to merit a
hierarchy, and what's more: I can add the source-directory to my PATH and
be done by compiling every time I pull.
But you're right in any case, it is post 1.0 discussion material.
Ciao,
Dscho
^ permalink raw reply
* Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Johannes Schindelin @ 2005-08-09 0:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vd5oo11wj.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 8 Aug 2005, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > Or if you want to be more CVS-like, use "-F", and accept "-" for stdin?
>
> Yes my vote goes:
>
> -m "message"
> -c "from this commit, literally."
> -C "from this commit, but let me edit the log further."
> -F "from this file."
> -F - <stdin
The royal penguin speaketh, and the little blue penguin gets a fish:
[PATCH] git commit usage is more like cvs's
Teach git-commit-script about different ways to provide a commit message,
including the famous -m flag from CVS.
---
git-commit-script | 48 ++++++++++++++++++++++++++++++++++--------------
1 files changed, 34 insertions(+), 14 deletions(-)
457d879496cb5f742ed6bccc9a435f414b0fd2a7
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -6,20 +6,41 @@
. git-sh-setup-script || die "Not a git archive"
usage () {
- die 'git commit [--all] [-m existing-commit] [<path>...]'
+ die 'git commit [options] [<path>...]
+Options:
+ --all automatically do a git-update-cache on all modified
+ files
+ -m <message> use this message in the commit
+ -c <commit> use the same message as in the given commit
+ -C <commit> as -c, but let me edit it
+ -F <file> take the message from file
+ -F - take the message from stdin'
}
files=()
+call_editor=true
+rm -f .editmsg || die "Could not write edit message"
while case "$#" in 0) break ;; esac
do
case "$1" in
+ -m|-c|-C|-F)
+ [ "$#" -ne 1 ] || usage;;
+ esac
+
+ case "$1" in
-m) shift
- case "$#" in
- 0) usage ;;
- *) use_commit=`git-rev-parse --verify "$1"` ||
- exit ;;
- esac
- ;;
+ call_editor=""
+ echo "$1" >> .editmsg;;
+ -c) shift
+ call_editor=""
+ use_commit=`git-rev-parse --verify "$1"` ||
+ exit ;;
+ -C) shift
+ use_commit=`git-rev-parse --verify "$1"` ||
+ exit ;;
+ -F) shift
+ call_editor=""
+ cat "$1" >> .editmsg;;
--all)
files=($(git-diff-files --name-only))\
;;
@@ -42,7 +63,7 @@ if [ ! -r "$GIT_DIR/HEAD" ]; then
echo "#"
git-ls-files | sed 's/^/# New file: /'
echo "#"
- ) > .editmsg
+ ) >> .editmsg
PARENTS=""
else
if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
@@ -83,7 +104,7 @@ else
export GIT_AUTHOR_DATE
git-cat-file commit "$use_commit" |
sed -e '1,/^$/d'
- fi >.editmsg
+ fi >> .editmsg
git-status-script >>.editmsg
fi
if [ "$?" != "0" -a ! -f $GIT_DIR/MERGE_HEAD ]
@@ -92,11 +113,10 @@ then
rm .editmsg
exit 1
fi
-case "$use_commit" in
-'')
- ${VISUAL:-${EDITOR:-vi}} .editmsg
- ;;
-esac
+
+[ -z "$use_commit" -o "$call_editor" = true ] &&
+${VISUAL:-${EDITOR:-vi}} .editmsg
+
grep -v '^#' < .editmsg | git-stripspace > .cmitmsg
[ -s .cmitmsg ] &&
tree=$(git-write-tree) &&
^ permalink raw reply
* git tag can't take piped input?
From: Chris Wright @ 2005-08-09 0:04 UTC (permalink / raw)
To: git
Apparently I was under a rock sleeping when git-tag-script changed to no
longer take input from stdin. So my script which did:
TAG=$(echo "$TAG_MSG" | git-tag-script $RELEASE)
echo $TAG > .git/refs/tags/$RELEASE
Is broken in two ways. First it's no longer building an annotated tag,
second it creaets a zero length file .git/refs/tags/$RELEASE. Second
issue is trivial to fix in my script. First one needs some change in the
tag script. Below is a simple patch for a stab at fixing.
thanks,
-chris
--
Allow users to create a tag message by passing message on command line
instead of requiring an $EDITOR session.
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
diff --git a/git-tag-script b/git-tag-script
--- a/git-tag-script
+++ b/git-tag-script
@@ -4,13 +4,14 @@
. git-sh-setup-script || die "Not a git archive"
usage () {
- echo >&2 "Usage: git-tag-script [-a | -s] [-f] tagname"
+ echo >&2 "Usage: git-tag-script [-a | -s] [-f] [-m "tag message"] tagname"
exit 1
}
annotate=
signed=
force=
+message=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -24,6 +25,11 @@ do
-f)
force=1
;;
+ -m)
+ annotate=1
+ shift
+ message="$1"
+ ;;
-*)
usage
;;
@@ -48,10 +54,14 @@ tagger=$(git-var GIT_COMMITTER_IDENT) ||
trap 'rm -f .tmp-tag* .tagmsg .editmsg' 0
if [ "$annotate" ]; then
- ( echo "#"
- echo "# Write a tag message"
- echo "#" ) > .editmsg
- ${VISUAL:-${EDITOR:-vi}} .editmsg || exit
+ if [ -z "$message" ]; then
+ ( echo "#"
+ echo "# Write a tag message"
+ echo "#" ) > .editmsg
+ ${VISUAL:-${EDITOR:-vi}} .editmsg || exit
+ else
+ echo "$message" > .editmsg
+ fi
grep -v '^#' < .editmsg | git-stripspace > .tagmsg
^ permalink raw reply
* Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Johannes Schindelin @ 2005-08-09 0:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0508090202140.3860@wgmdd8.biozentrum.uni-wuerzburg.de>
[PATCH] Adapt git-cherry and git-rebase-script to latest changes of git commit
Teach git-cherry and git-rebase-script to use the "-c" option, since
"-m" means something different to git-commit-script now.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-cherry | 2 +-
git-rebase-script | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
34d6840882e65109a17fa02bf2cefec269fd7637
diff --git a/git-cherry b/git-cherry
--- a/git-cherry
+++ b/git-cherry
@@ -23,7 +23,7 @@ The output is intended to be used as:
while read commit
do
GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p "$commit" &&
- git-commit-script -m "$commit"
+ git-commit-script -c "$commit"
done
'
diff --git a/git-rebase-script b/git-rebase-script
--- a/git-rebase-script
+++ b/git-rebase-script
@@ -37,7 +37,7 @@ do
esac
S=`cat "$GIT_DIR/HEAD"` &&
GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p $commit &&
- git-commit-script -m "$commit" || {
+ git-commit-script -c "$commit" || {
echo $commit >>$fail
git-read-tree --reset -u $S
}
^ permalink raw reply
* Make git-rev-tree obsolete
From: Johannes Schindelin @ 2005-08-09 0:23 UTC (permalink / raw)
To: git
Hi,
Junio remarked that Jeff's git-changes-script still uses git-rev-tree, and
therefore it should not be removed. This patch changes git-changes-script
over to git-rev-list:
--- git-changes-script.orig Tue Aug 9 02:21:36 2005
+++ git-changes-script Tue Aug 9 02:20:53 2005
@@ -85,14 +85,14 @@
base=$(cat .git/HEAD) || exit 1
fi
-git-rev-tree $base | sort -rn > ${tmpfile}.base
+git-rev-list $base > ${tmpfile}.base
if [ -n "$remote" ]; then
[ -d $remote/.git ] || exit 1
if [ -z "$tobase" ]; then
tobase=$(cat $remote/.git/HEAD) || exit 1
fi
pushd $remote > /dev/null
- git-rev-tree $tobase | sort -rn > ${tmpfile}.remote
+ git-rev-list $tobase > ${tmpfile}.remote
diff -u ${tmpfile}.base ${tmpfile}.remote | grep "^${diffsearch}[^${diffsearch}]" | cut -c 1- > ${tmpfile}.diff
rm -f ${tmpfile}.base ${tmpfile}.remote
mv ${tmpfile}.diff ${tmpfile}.base
@@ -103,7 +103,7 @@
[ -s "${tmpfile}.base" ] || exit 0
-cat ${tmpfile}.base | while read time commit parents; do
+cat ${tmpfile}.base | while read commit; do
showcommit $commit
echo -e "\n--------------------------"
^ permalink raw reply
* Re: Make git-rev-tree obsolete
From: Linus Torvalds @ 2005-08-09 2:09 UTC (permalink / raw)
To: Johannes Schindelin, Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0508090222190.4076@wgmdd8.biozentrum.uni-wuerzburg.de>
On Tue, 9 Aug 2005, Johannes Schindelin wrote:
>
> Junio remarked that Jeff's git-changes-script still uses git-rev-tree, and
> therefore it should not be removed. This patch changes git-changes-script
> over to git-rev-list:
It really should be totally rewritten, to take advantage of git-rev-list
being able to terminate early. As it is, your conversion may work, and it
may give the right results, but it will suck performance-wise for all the
same reasons that git-rev-tree sucked: it will walk all the way down to
the root of the tree(s).
> --- git-changes-script.orig Tue Aug 9 02:21:36 2005
> +++ git-changes-script Tue Aug 9 02:20:53 2005
> @@ -85,14 +85,14 @@
> base=$(cat .git/HEAD) || exit 1
> fi
>
> -git-rev-tree $base | sort -rn > ${tmpfile}.base
> +git-rev-list $base > ${tmpfile}.base
> if [ -n "$remote" ]; then
> [ -d $remote/.git ] || exit 1
> if [ -z "$tobase" ]; then
> tobase=$(cat $remote/.git/HEAD) || exit 1
> fi
> pushd $remote > /dev/null
> - git-rev-tree $tobase | sort -rn > ${tmpfile}.remote
> + git-rev-list $tobase > ${tmpfile}.remote
> diff -u ${tmpfile}.base ${tmpfile}.remote | grep "^${diffsearch}[^${diffsearch}]" | cut -c 1- > ${tmpfile}.diff
> rm -f ${tmpfile}.base ${tmpfile}.remote
> mv ${tmpfile}.diff ${tmpfile}.base
It really should do something like
#
# Make sure we see objects in the remote directory
#
export GIT_ALTERNATE_OBJECT_DIRECTORIES=$remote/.git/objects
#
# Get the local SHA1
#
local_ref=$(git-rev-parse --verify $base^0) || exit
#
# Get the remote SHA1
#
remote_ref=$(GIT_DIR="$remote/.git" git-rev-parse --verify $tobase^0) || exit
#
# Ok, let it rip..
#
git log $remote_ref..$local_ref
to do a proper search of objects that are in $local but not in $remote,
without having to traverse all the way down to the root for both.
Linus
^ permalink raw reply
* Re: [PATCH] Teach git push .git/branches shorthand
From: Junio C Hamano @ 2005-08-09 2:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508081106580.26210@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I'd prefer $GIT_DIR/remotes/. And I propose another extension: Since the
> files stored therein right now contain only one <remote> string, it should
> be possible to add the default head(s) to the file.
That makes sense. Currently my arrangement is:
$ cd .git/branches && grep . public-*
public-master:http://www.kernel.org/pub/scm/git/git.git/
public-pu:http://www.kernel.org/pub/scm/git/git.git/#pu
public-rc:http://www.kernel.org/pub/scm/git/git.git/#rc
and in order to get the references on the public server to make
sure people are seeing what I want them to see, I say:
$ for h in master pu rc
do
echo $h
git fetch public-$h
git-rev-parse $h public-$h
done
Instead, I should be able to say:
$ cat .git/remotes/public
http://www.kernel.org/pub/scm/git/git.git/#pu:public-pu,rc:public-rc
to mean that the following two are equivalent:
$ git fetch public
$ git fetch public pu:public-pu rc:public-rc
that is, fetch pu there and store it in refs/heads/public-pu
(same for rc). When I want to fetch only pu from there:
$ git fetch public pu:public-pu
or even
$ git fetch public pu
should work. If I happen to want to fetch pu one-shot but not
want to update my local refs/heads/public-pu, then I should be
able to say
$ git fetch public pu:
Another thing I need to worry about is that I would want to use
this remotes information for pushing as well, but probably the
reference mappings are different when fetching and pushing.
With something like this:
$ cat .git/remotes/ko
kernel.org:/pub/scm/git/git.git/#master:ko-master,pu:ko-pu,rc:ko-rc
$ git fetch ko rc
I would fetch the remote ref "rc" and store it in
refs/heads/ko-rc, which is fine, but after that I would do my
work in the local repository, merge things up and update my
local "rc" (not ko-rc, which to me is a "reference only"
branch), and eventually when pushing I would want to store my
"rc" (again not ko-rc) in "rc" over there.
This means the reference mapping in these two shorthand
notations should be flexible enough to allow me to do:
$ git fetch ko rc ;# get rc from there store it under ko-rc here
which is equivalent to
$ git fetch ko rc:ko-rc
and
$ git push ko rc ;# push rc here to rc there
which is equivalent to
$ git push ko rc:rc
Maybe its time to do a file format that is a bit more flexible.
For example:
$ cat .git/remotes/ko
URL: kernel.org:/pub/scm/git/git.git/
Fetch-Reference: master:ko-master pu:ko-pu rc:ko-rc
Push-Reference: master pu rc
Note that I do not mean "Push-Reference" can not do the rename.
I could have written "master:master" but I did not because I do
_not_ want renaming push in this example.
People who do not need different mappings for fetch/push should
be able to say:
$ cat .git/remotes/public
URL: http://www.kernel.org/pub/scm/git/git.git/
Reference: pu:public-pu rc:public-rc
Another thing I should mention is that Fetch-Reference mapping
is <remote>:<local>, while Push-Reference is <local>:<remote>.
This is only because I feel always using <src>:<dst> is easy to
remember, is the way it works for the command line refs for git
push already, and is the way I plan to enhance fetch to grok.
My current thinking is Reference should take <remote>:<local>
because fetching/pulling is probably more common than pushing,
but I need to think a bit more about it.
Johannes, sorry for doing my design work in an e-mail buffer
to you ;-).
^ permalink raw reply
* Re: [PATCH] Stash away the original head in ORIG_HEAD when resetting.
From: Junio C Hamano @ 2005-08-09 2:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, torvalds
In-Reply-To: <Pine.LNX.4.63.0508081111020.26210@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Since there are not many users of git-commit's *-m* flag right now: Is it
> necessary to confuse CVS people, who expect to be able to write
>
> git commit -m "I did this and that"
>
> I do not want to be too intrusive, but I think up to now there is just the
> mailbox tools which use this feature, and users of git-reset. Thoughts?
I could be talked into renaming the option to something else and
using -m in a way that is CVS compatible.
That flag originally came from JIT, which uses:
-M <commit> literally take the commit message, no editing necessary;
-m <commit> start with commit message in this one but have user edit;
-l <file> use the log message in this file;
-l - read the log message from stdin.
^ 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