* Re: The merge from hell...
From: Linus Torvalds @ 2006-02-05 19:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marco Costalba, Git Mailing List, Paul Mackerras, Marco Costalba
In-Reply-To: <7v7j8erqjr.fsf@assigned-by-dhcp.cox.net>
On Thu, 2 Feb 2006, Junio C Hamano wrote:
>
> Linus Torvalds <torvalds@osdl.org> writes:
> >
> > Ahh. You're mis-using git-diff-tree.
> >
> > git-diff-tree will _never_ show the commit log if the diff ends up being
> > empty.
>
> True, I should fix the documentation.
>
> It _might_ make sense for certain users like gitk and gitview if
> we had a single tool that gives --pretty and its diff even if
> the diff is empty. Having said that, the flag --cc -m is too
> specific. If some uses want to see the commit log even for an
> empty diff, that flag should not be something only --cc honors.
Here's an "--always" flag that does that.
Linus
---
diff --git a/diff-tree.c b/diff-tree.c
index 6593a69..2df23c6 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -10,6 +10,7 @@ static int show_empty_combined = 0;
static int combine_merges = 0;
static int dense_combined_merges = 0;
static int read_stdin = 0;
+static int always_show_header = 0;
static const char *header = NULL;
static const char *header_prefix = "";
@@ -93,6 +94,10 @@ static const char *generate_header(const
offset += pretty_print_commit(commit_format, commit, len,
this_header + offset,
sizeof(this_header) - offset, abbrev);
+ if (always_show_header) {
+ puts(this_header);
+ return NULL;
+ }
return this_header;
}
@@ -262,6 +267,10 @@ int main(int argc, const char **argv)
no_commit_id = 1;
continue;
}
+ if (!strcmp(arg, "--always")) {
+ always_show_header = 1;
+ continue;
+ }
usage(diff_tree_usage);
}
if (diff_options.output_format == DIFF_FORMAT_PATCH)
^ permalink raw reply related
* Re: [PATCH] do not open editor in dumb terminal
From: Petr Baudis @ 2006-02-05 17:44 UTC (permalink / raw)
To: Amos Waterland; +Cc: junkio, git, boutcher
In-Reply-To: <20060203114133.GA11499@kvasir.watson.ibm.com>
Dear diary, on Fri, Feb 03, 2006 at 12:41:33PM CET, I got a letter
where Amos Waterland <apw@us.ibm.com> said that...
> Many people run git from a shell in emacs (obtained by M-x shell). When
> they try to do a commit without specifying a log message on the command
> line with -m, git opens vi inside emacs, with unpleasant results. I
> think the right answer is to just refuse to open an editor in any dumb
> terminal.
>
> Signed-off-by: Amos Waterland <apw@us.ibm.com>
> Cc: Dave C Boutcher <boutcher@cs.umn.edu>
Cogito solves this by [ -t ] and just doing cat instead of $EDITOR if
the input is not a terminal. Couldn't Junio just do
emacsclient | cg^H^Hgit commit
in that case? (Note that I'm totally clueless about what emacsclient's
usage actually is.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [PATCH] git-commit: revamp the git-commit semantics.
From: Marco Costalba @ 2006-02-05 13:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsm2hzng.fsf@assigned-by-dhcp.cox.net>
On 2/5/06, Junio C Hamano <junkio@cox.net> wrote:
> I am addressing people who participated with their valuable
> inputs to the earlier "git commit" discussion.
>
> Here is my first cut. I'd appreciate to hear from both
> git-experienced people and git newcomers how comfortable this
> new implementation is. Improvement patches on top of this are
> certainly appreciated.
>
I think the new semantics is clear and better then old one, especially
for people coming from different scm systems.
Unfortunately it breaks qgit commit functionality. So I would like to
ask _how_ do you plan to update main line.
I would like to update qgit also today, but it is impossible because
"git-commit -i" _currently_ raises an error. So I am just wondering
if adding a temporary -i "no op" option to _current_ git-commit, until
semantics change is released could be done.
Adding a -i "place holder" option to _current_ git-commit has the
following advantages:
1) No functionality change and 100% compatibility with current git-commit use.
2) Give people time to update tools/script in the mean time
3) When the real patch will be released all the (modified) tools will
be automatically compatible.
What do you think?
Marco
^ permalink raw reply
* Re: What is the working directory for post-update hook?
From: Alan Chandler @ 2006-02-05 10:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vd5i2kuqi.fsf@assigned-by-dhcp.cox.net>
On Sunday 05 February 2006 09:41, Junio C Hamano wrote:
> Alan Chandler <alan@chandlerfamily.org.uk> writes:
> > The document root of my website has a git repository under it (in the
> > standard .git subdirectory) and want a post update hook to checkout the
> > contents (so the web server sees it!)
> >
> > I will be pushing to it via ssh.
> >
> > Does this mean that the post-update hook with be run with a working
> > directory of the web site's document root? or something relative (such as
> > GIT_DIR) so that I don't have to do a specific cd to an absolute path.
>
> The current implementation happens to chdir to GIT_DIR and sets
> GIT_DIR=. in the environment, so if you have something like
> this:
>
> /var/www/myproject/
> /var/www/myproject/.git/
> /var/www/myproject/.git/HEAD
> /var/www/myproject/.git/...
> /var/www/myproject/README
>
> Then $(pwd) would be /var/www/myproject/.git/. Your hook would
> probably be able to do "cd .." to get to the project top.
>
I did get it to work doing a cd .. - although you also have to unset GIT_DIR,
because its is literally "." and not the directory that was "." at the time
of setting, so a cd .. ; checkout -f then fails with an invalid repository.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* [PATCH] git-commit: revamp the git-commit semantics.
From: Junio C Hamano @ 2006-02-05 10:24 UTC (permalink / raw)
To: Alan Chandler, Andreas Ericsson, Carl Worth, Daniel Barkalow,
Keith Packard, Linus Torvalds, Michael Fischer, Nicolas Pitre
Cc: git
I am addressing people who participated with their valuable
inputs to the earlier "git commit" discussion.
Here is my first cut. I'd appreciate to hear from both
git-experienced people and git newcomers how comfortable this
new implementation is. Improvement patches on top of this are
certainly appreciated.
The main focus of this patch is to reduce the confusion factor
while not disrupting experienced git users with trained fingers,
but it unfortunately does introduce two incompatible changes:
- When the command decides not to create a commit for whatever
reason, the updates made to the index file, either because of
--all option or "-i paths..." option, are forgotten.
- Traditional "git commit paths..." _must_ be spelled as "git
commit -i paths...". "git commit paths..." means a
completely different thing now.
I think the first incompatibility would not break anybody's work
habit and I am hoping that everybody considers this to be purely
an improvement. It reduces major confusion factor in the
current implementation when you do:
$ edit foo
$ git commit -a
and cause the commit to abort by giving it an empty log
message. In the current implementation, "git diff" would not
show anything after that, but with this you would see the edit
of foo.
The second one is not something I am too happy about, but many
people seem to have been confused that running "git update-index
foo" and then "git commit bar" commits both foo and bar. To
prevent this change from burning index-aware people too much,
this form refuses to run during a merge. Also to reduce
confusion for people who forget differences between "git diff" and
"git diff HEAD", it refuses to run when the paths involved do
not match between the index and HEAD.
-- >8 --
[PATCH] git-commit: revamp the git-commit semantics.
- "git commit" without _any_ parameter keeps the traditional
behaviour. It commits the current index.
We commit the whole index even when this form is run from a
subdirectory.
- "git commit --include paths..." (or "git commit -i paths...")
is equivalent to:
git update-index --remove paths...
git commit
- "git commit paths..." acquires a new semantics. This is an
incompatible change that needs user training, which I am
still a bit reluctant to swallow, but enough people seem to
have complained that it is confusing to them. It
1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds
trained git users that the traditional semantics now needs
-i flag.
2. refuses to run if named paths... are different in HEAD and
the index (ditto about reminding). Added paths are OK.
3. reads HEAD commit into a temporary index file.
4. updates named paths... from the working tree in this
temporary index.
5. does the same updates of the paths... from the working
tree to the real index.
6. makes a commit using the temporary index that has the
current HEAD as the parent, and updates the HEAD with this
new commit.
- "git commit --all" can run from a subdirectory, but it updates
the index with all the modified files and does a whole tree
commit.
- In all cases, when the command decides not to create a new
commit, the index is left as it was before the command is
run. This means that the two "git diff" in the following
sequence:
$ git diff
$ git commit -a
$ git diff
would show the same diff if you abort the commit process by
making the commit log message empty.
This commit also introduces much requested --author option.
$ git commit --author 'A U Thor <author@example.com>'
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/core-tutorial.txt | 6 -
Documentation/git-commit.txt | 61 ++++++
git-commit.sh | 403 ++++++++++++++++++++++++++++-----------
t/t1200-tutorial.sh | 6 -
4 files changed, 354 insertions(+), 122 deletions(-)
551045c2a2eefdc85307de5f4b72ba720d095106
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 4513ad6..4e6ec0e 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -858,7 +858,7 @@ that branch, and do some work there.
------------------------------------------------
$ git checkout mybranch
$ echo "Work, work, work" >>hello
-$ git commit -m 'Some work.' hello
+$ git commit -m 'Some work.' -i hello
------------------------------------------------
Here, we just added another line to `hello`, and we used a shorthand for
@@ -881,7 +881,7 @@ hasn't happened in the `master` branch a
------------
$ echo "Play, play, play" >>hello
$ echo "Lots of fun" >>example
-$ git commit -m 'Some fun.' hello example
+$ git commit -m 'Some fun.' -i hello example
------------
since the master branch is obviously in a much better mood.
@@ -946,7 +946,7 @@ Work, work, work
and once you're happy with your manual merge, just do a
------------
-$ git commit hello
+$ git commit -i hello
------------
which will very loudly warn you that you're now committing a merge
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 72f96fc..53b64fa 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -8,8 +8,8 @@ git-commit - Record your changes
SYNOPSIS
--------
[verse]
-'git-commit' [-a] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
- [-e] [--] <file>...
+'git-commit' [-a] [-i] [-s] [-v] [(-c | -C) <commit> | -F <file> | -m <msg>]
+ [-e] [--author <author>] [--] <file>...
DESCRIPTION
-----------
@@ -40,6 +40,10 @@ OPTIONS
Take the commit message from the given file. Use '-' to
read the message from the standard input.
+--author <author>::
+ Override the author name used in the commit. Use
+ `A U Thor <author@example.com>` format.
+
-m <msg>::
Use the given <msg> as the commit message.
@@ -63,17 +67,66 @@ OPTIONS
commit log message unmodified. This option lets you
further edit the message taken from these sources.
+-i|--include::
+ Instead of committing only the files specified on the
+ command line, update them in the index file and then
+ commit the whole index. This is the traditional
+ behaviour.
+
--::
Do not interpret any more arguments as options.
<file>...::
- Update specified paths in the index file before committing.
-
+ Commit only the files specified on the command line.
+ This format cannot be used during a merge, nor when the
+ index and the latest commit does not match on the
+ specified paths to avoid confusion.
If you make a commit and then found a mistake immediately after
that, you can recover from it with gitlink:git-reset[1].
+Discussion
+----------
+
+`git commit` without _any_ parameter commits the tree structure
+recorded by the current index file. This is a whole-tree commit
+even the command is invoked from a subdirectory.
+
+`git commit --include paths...` is equivalent to
+
+ git update-index --remove paths...
+ git commit
+
+That is, update the specified paths to the index and then commit
+the whole tree.
+
+`git commit paths...` largely bypasses the index file and
+commits only the changes made to the specified paths. It has
+however several safety valves to prevent confusion.
+
+. It refuses to run during a merge (i.e. when
+ `$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users
+ that the traditional semantics now needs -i flag.
+
+. It refuses to run if named `paths...` are different in HEAD
+ and the index (ditto about reminding). Added paths are OK.
+ This is because an earlier `git diff` (not `git diff HEAD`)
+ would have shown the differences since the last `git
+ update-index paths...` to the user, and an inexperienced user
+ may mistakenly think that the changes between the index and
+ the HEAD (i.e. earlier changes made before the last `git
+ update-index paths...` was done) are not being committed.
+
+. It reads HEAD commit into a temporary index file, updates the
+ specified `paths...` and makes a commit. At the same time,
+ the real index file is also updated with the same `paths...`.
+
+`git commit --all` updates the index file with _all_ changes to
+the working tree, and makes a whole-tree commit, regardless of
+which subdirectory the command is invoked in.
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and
diff --git a/git-commit.sh b/git-commit.sh
index 10946ed..d3325bc 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -1,85 +1,170 @@
#!/bin/sh
#
# Copyright (c) 2005 Linus Torvalds
-#
+# Copyright (c) 2006 Junio C Hamano
+
+USAGE='[-a] [-i] [-s] [-v | --no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-e] [--author <author>] [<path>...]'
-USAGE='[-a] [-s] [-v | --no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-e] [<path>...]'
+SUBDIRECTORY_OK=Yes
. git-sh-setup
-all= logfile= use_commit= no_edit= log_given= log_message= verify=t signoff=
+git-rev-parse --verify HEAD >/dev/null 2>&1 ||
+initial_commit=t
+
+refuse_partial () {
+ echo >&2 "$1"
+ echo >&2 "Experienced git users:"
+ echo >&2 "You might have meant to say 'git commit -i paths...', perhaps?"
+ exit 1
+}
+
+all=
+also=
+logfile=
+use_commit=
+no_edit=
+log_given=
+log_message=
+verify=t
+signoff=
+force_author=
while case "$#" in 0) break;; esac
do
case "$1" in
+ -F|--F|-f|--f|--fi|--fil|--file)
+ case "$#" in 1) usage ;; esac
+ shift
+ no_edit=t
+ log_given=t$log_given
+ logfile="$1"
+ shift
+ ;;
+ -F*|-f*)
+ no_edit=t
+ log_given=t$log_given
+ logfile=`expr "$1" : '-[Ff]\(.*\)'`
+ shift
+ ;;
+ --F=*|--f=*|--fi=*|--fil=*|--file=*)
+ no_edit=t
+ log_given=t$log_given
+ logfile=`expr "$1" : '-[^=]*=\(.*\)'`
+ shift
+ ;;
-a|--a|--al|--all)
- all=t
- shift ;;
- -F=*|--f=*|--fi=*|--fil=*|--file=*)
- log_given=t$log_given
- logfile=`expr "$1" : '-[^=]*=\(.*\)'`
- no_edit=t
- shift ;;
- -F|--f|--fi|--fil|--file)
- case "$#" in 1) usage ;; esac; shift
- log_given=t$log_given
- logfile="$1"
- no_edit=t
- shift ;;
- -m=*|--m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*)
- log_given=t$log_given
- log_message=`expr "$1" : '-[^=]*=\(.*\)'`
- no_edit=t
- shift ;;
+ all=t
+ shift
+ ;;
+ --au=*|--aut=*|--auth=*|--autho=*|--author=*)
+ force_author=`expr "$1" : '-[^=]*=\(.*\)'`
+ shift
+ ;;
+ --au|--aut|--auth|--autho|--author)
+ case "$#" in 1) usage ;; esac
+ shift
+ force_author="$1"
+ shift
+ ;;
+ -e|--e|--ed|--edi|--edit)
+ no_edit=
+ shift
+ ;;
+ -i|--i|--in|--inc|--incl|--inclu|--includ|--include)
+ also=t
+ shift
+ ;;
-m|--m|--me|--mes|--mess|--messa|--messag|--message)
- case "$#" in 1) usage ;; esac; shift
- log_given=t$log_given
- log_message="$1"
- no_edit=t
- shift ;;
- -c=*|--ree=*|--reed=*|--reedi=*|--reedit=*|--reedit-=*|--reedit-m=*|\
+ case "$#" in 1) usage ;; esac
+ shift
+ log_given=t$log_given
+ log_message="$1"
+ no_edit=t
+ shift
+ ;;
+ -m*)
+ log_given=t$log_given
+ log_message=`expr "$1" : '-m\(.*\)'`
+ no_edit=t
+ shift
+ ;;
+ --m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*)
+ log_given=t$log_given
+ log_message=`expr "$1" : '-[^=]*=\(.*\)'`
+ no_edit=t
+ shift
+ ;;
+ -n|--n|--no|--no-|--no-v|--no-ve|--no-ver|--no-veri|--no-verif|--no-verify)
+ verify=
+ shift
+ ;;
+ -c)
+ case "$#" in 1) usage ;; esac
+ shift
+ log_given=t$log_given
+ use_commit="$1"
+ no_edit=
+ shift
+ ;;
+ --ree=*|--reed=*|--reedi=*|--reedit=*|--reedit-=*|--reedit-m=*|\
--reedit-me=*|--reedit-mes=*|--reedit-mess=*|--reedit-messa=*|\
--reedit-messag=*|--reedit-message=*)
- log_given=t$log_given
- use_commit=`expr "$1" : '-[^=]*=\(.*\)'`
- shift ;;
- -c|--ree|--reed|--reedi|--reedit|--reedit-|--reedit-m|--reedit-me|\
+ log_given=t$log_given
+ use_commit=`expr "$1" : '-[^=]*=\(.*\)'`
+ no_edit=
+ shift
+ ;;
+ --ree|--reed|--reedi|--reedit|--reedit-|--reedit-m|--reedit-me|\
--reedit-mes|--reedit-mess|--reedit-messa|--reedit-messag|--reedit-message)
- case "$#" in 1) usage ;; esac; shift
- log_given=t$log_given
- use_commit="$1"
- shift ;;
- -C=*|--reu=*|--reus=*|--reuse=*|--reuse-=*|--reuse-m=*|--reuse-me=*|\
+ case "$#" in 1) usage ;; esac
+ shift
+ log_given=t$log_given
+ use_commit="$1"
+ no_edit=
+ shift
+ ;;
+ -C)
+ case "$#" in 1) usage ;; esac
+ shift
+ log_given=t$log_given
+ use_commit="$1"
+ no_edit=t
+ shift
+ ;;
+ --reu=*|--reus=*|--reuse=*|--reuse-=*|--reuse-m=*|--reuse-me=*|\
--reuse-mes=*|--reuse-mess=*|--reuse-messa=*|--reuse-messag=*|\
--reuse-message=*)
- log_given=t$log_given
- use_commit=`expr "$1" : '-[^=]*=\(.*\)'`
- no_edit=t
- shift ;;
- -C|--reu|--reus|--reuse|--reuse-|--reuse-m|--reuse-me|--reuse-mes|\
+ log_given=t$log_given
+ use_commit=`expr "$1" : '-[^=]*=\(.*\)'`
+ no_edit=t
+ shift
+ ;;
+ --reu|--reus|--reuse|--reuse-|--reuse-m|--reuse-me|--reuse-mes|\
--reuse-mess|--reuse-messa|--reuse-messag|--reuse-message)
- case "$#" in 1) usage ;; esac; shift
- log_given=t$log_given
- use_commit="$1"
- no_edit=t
- shift ;;
- -e|--e|--ed|--edi|--edit)
- no_edit=
- shift ;;
+ case "$#" in 1) usage ;; esac
+ shift
+ log_given=t$log_given
+ use_commit="$1"
+ no_edit=t
+ shift
+ ;;
-s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
- signoff=t
- shift ;;
- -n|--n|--no|--no-|--no-v|--no-ve|--no-ver|--no-veri|--no-verif|--no-verify)
- verify=
- shift ;;
+ signoff=t
+ shift
+ ;;
-v|--v|--ve|--ver|--veri|--verif|--verify)
- verify=t
- shift ;;
+ verify=t
+ shift
+ ;;
--)
- shift
- break ;;
+ shift
+ break
+ ;;
-*)
- usage ;;
+ usage
+ ;;
*)
- break ;;
+ break
+ ;;
esac
done
@@ -88,30 +173,92 @@ tt*)
die "Only one of -c/-C/-F/-m can be used." ;;
esac
-case "$all,$#" in
-t,0)
- git-diff-files --name-only -z |
- git-update-index --remove -z --stdin
- ;;
-t,*)
- die "Cannot use -a and explicit files at the same time."
- ;;
-,0)
+TOP=`git-rev-parse --show-cdup`
+
+case "$all,$also" in
+t,t)
+ die "Cannot use -a and -i at the same time." ;;
+t,)
+ SAVE_INDEX="$GIT_DIR/save-index$$" &&
+ cp "$GIT_DIR/index" "$SAVE_INDEX" &&
+ (
+ if test '' != "$TOP"
+ then
+ cd "$TOP"
+ fi &&
+ git-diff-files --name-only -z |
+ git-update-index --remove -z --stdin
+ )
;;
-*)
- git-diff-files --name-only -z -- "$@" |
+,t)
+ case "$#" in
+ 0) die "No paths with -i does not make sense." ;;
+ esac
+ SAVE_INDEX="$GIT_DIR/save-index$$" &&
+ cp "$GIT_DIR/index" "$SAVE_INDEX" &&
+ git-diff-files --name-only -z -- "$@" |
git-update-index --remove -z --stdin
;;
-esac || exit 1
+,)
+ case "$#" in
+ 0)
+ ;; # commit as-is
+ *)
+ if test -f "$GIT_DIR/MERGE_HEAD"
+ then
+ refuse_partial "Cannot do a partial commit during a merge."
+ fi
+ TMP_INDEX="$GIT_DIR/tmp-index$$"
+ if test -z "$initial_commit"
+ then
+ # make sure index is clean at the specified paths, or
+ # they are additions.
+ dirty_in_index=`git-diff-index --cached --name-status \
+ --diff-filter=DMTXU HEAD -- "$@"`
+ test -z "$dirty_in_index" ||
+ refuse_partial "Cannot do a partial commit of paths dirty in index:
+
+$dirty_in_index"
+ fi
+ commit_only=`git-ls-files -- "$@"` ;;
+ esac
+ ;;
+esac
+
git-update-index -q --refresh || exit 1
-case "$verify" in
-t)
- if test -x "$GIT_DIR"/hooks/pre-commit
+trap '
+ test -f "$TMP_INDEX" && rm -f "$TMP_INDEX"
+ test -f "$SAVE_INDEX" && mv -f "$SAVE_INDEX" "$GIT_DIR/index"
+' 0
+
+if test "$TMP_INDEX"
+then
+ if test -z "$initial_commit"
then
- "$GIT_DIR"/hooks/pre-commit || exit
- fi
-esac
+ GIT_INDEX_FILE="$TMP_INDEX" git-read-tree HEAD
+ else
+ rm -f "$TMP_INDEX"
+ fi || exit
+ echo "$commit_only" |
+ GIT_INDEX_FILE="$TMP_INDEX" git-update-index --add --remove --stdin &&
+ echo "$commit_only" |
+ git-update-index --remove --stdin ||
+ exit
+else
+ #
+ :
+fi
+
+if test t = "$verify" && test -x "$GIT_DIR"/hooks/pre-commit
+then
+ if test "$TMP_INDEX"
+ then
+ GIT_INDEX_FILE="$TMP_INDEX" "$GIT_DIR"/hooks/pre-commit
+ else
+ "$GIT_DIR"/hooks/pre-commit
+ fi || exit
+fi
if test "$log_message" != ''
then
@@ -155,42 +302,52 @@ if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
echo "#"
fi >>"$GIT_DIR"/COMMIT_EDITMSG
+# Author
+if test '' != "$use_commit"
+then
+ pick_author_script='
+ /^author /{
+ s/'\''/'\''\\'\'\''/g
+ h
+ s/^author \([^<]*\) <[^>]*> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_NAME='\''&'\''/p
+
+ g
+ s/^author [^<]* <\([^>]*\)> .*$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_EMAIL='\''&'\''/p
+
+ g
+ s/^author [^<]* <[^>]*> \(.*\)$/\1/
+ s/'\''/'\''\'\'\''/g
+ s/.*/GIT_AUTHOR_DATE='\''&'\''/p
+
+ q
+ }
+ '
+ set_author_env=`git-cat-file commit "$use_commit" |
+ LANG=C LC_ALL=C sed -ne "$pick_author_script"`
+ eval "$set_author_env"
+ export GIT_AUTHOR_NAME
+ export GIT_AUTHOR_EMAIL
+ export GIT_AUTHOR_DATE
+elif test '' != "$force_author"
+then
+ GIT_AUTHOR_NAME=`expr "$force_author" : '\(.*[^ ]\) *<.*'` &&
+ GIT_AUTHOR_EMAIL=`expr "$force_author" : '.*\(<.*\)'` &&
+ test '' != "$GIT_AUTHOR_NAME" &&
+ test '' != "$GIT_AUTHOR_EMAIL" ||
+ die "malformatted --author parameter"
+ export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
+fi
+
PARENTS="-p HEAD"
-if GIT_DIR="$GIT_DIR" git-rev-parse --verify HEAD >/dev/null 2>&1
+if test -z "$initial_commit"
then
if [ -f "$GIT_DIR/MERGE_HEAD" ]; then
PARENTS="-p HEAD "`sed -e 's/^/-p /' "$GIT_DIR/MERGE_HEAD"`
fi
- if test "$use_commit" != ""
- then
- pick_author_script='
- /^author /{
- s/'\''/'\''\\'\'\''/g
- h
- s/^author \([^<]*\) <[^>]*> .*$/\1/
- s/'\''/'\''\'\'\''/g
- s/.*/GIT_AUTHOR_NAME='\''&'\''/p
-
- g
- s/^author [^<]* <\([^>]*\)> .*$/\1/
- s/'\''/'\''\'\'\''/g
- s/.*/GIT_AUTHOR_EMAIL='\''&'\''/p
-
- g
- s/^author [^<]* <[^>]*> \(.*\)$/\1/
- s/'\''/'\''\'\'\''/g
- s/.*/GIT_AUTHOR_DATE='\''&'\''/p
-
- q
- }
- '
- set_author_env=`git-cat-file commit "$use_commit" |
- LANG=C LC_ALL=C sed -ne "$pick_author_script"`
- eval "$set_author_env"
- export GIT_AUTHOR_NAME
- export GIT_AUTHOR_EMAIL
- export GIT_AUTHOR_DATE
- fi
else
if [ -z "$(git-ls-files)" ]; then
echo Nothing to commit 1>&2
@@ -198,10 +355,21 @@ else
fi
PARENTS=""
fi
-git-status >>"$GIT_DIR"/COMMIT_EDITMSG
+
+(
+ if test '' != "$TOP"
+ then
+ cd "$TOP"
+ fi &&
+ git-status >>"$GIT_DIR"/COMMIT_EDITMSG
+)
if [ "$?" != "0" -a ! -f "$GIT_DIR/MERGE_HEAD" ]
then
rm -f "$GIT_DIR/COMMIT_EDITMSG"
+ if test '' != "$TOP"
+ then
+ cd "$TOP"
+ fi &&
git-status
exit 1
fi
@@ -213,7 +381,8 @@ case "$no_edit" in
echo >&2 "Please supply the commit log message using either"
echo >&2 "-m or -F option. A boilerplate log message has"
echo >&2 "been prepared in $GIT_DIR/COMMIT_EDITMSG"
- exit 1 ;;
+ exit 1
+ ;;
esac
${VISUAL:-${EDITOR:-vi}} "$GIT_DIR/COMMIT_EDITMSG"
;;
@@ -235,7 +404,13 @@ if cnt=`grep -v -i '^Signed-off-by' "$GI
wc -l` &&
test 0 -lt $cnt
then
- tree=$(git-write-tree) &&
+ if test -z "$TMP_INDEX"
+ then
+ tree=$(git-write-tree)
+ else
+ tree=$(GIT_INDEX_FILE="$TMP_INDEX" git-write-tree) &&
+ rm -f "$TMP_INDEX"
+ fi &&
commit=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&
git-update-ref HEAD $commit $current &&
rm -f -- "$GIT_DIR/MERGE_HEAD"
@@ -250,4 +425,8 @@ if test -x "$GIT_DIR"/hooks/post-commit
then
"$GIT_DIR"/hooks/post-commit
fi
+if test 0 -eq "$ret"
+then
+ rm -f "$SAVE_INDEX"
+fi
exit "$ret"
diff --git a/t/t1200-tutorial.sh b/t/t1200-tutorial.sh
index 8ff5dd9..c8a85f9 100755
--- a/t/t1200-tutorial.sh
+++ b/t/t1200-tutorial.sh
@@ -95,13 +95,13 @@ test_expect_success 'git branch' 'cmp br
git checkout mybranch
echo "Work, work, work" >>hello
-git commit -m 'Some work.' hello
+git commit -m 'Some work.' -i hello
git checkout master
echo "Play, play, play" >>hello
echo "Lots of fun" >>example
-git commit -m 'Some fun.' hello example
+git commit -m 'Some fun.' -i hello example
test_expect_failure 'git resolve now fails' 'git resolve HEAD mybranch "Merge work in mybranch"'
@@ -112,7 +112,7 @@ Play, play, play
Work, work, work
EOF
-git commit -m 'Merged "mybranch" changes.' hello
+git commit -m 'Merged "mybranch" changes.' -i hello
cat > show-branch.expect << EOF
* [master] Merged "mybranch" changes.
--
1.1.6.g9e4e
^ permalink raw reply related
* Re: What is the working directory for post-update hook?
From: Junio C Hamano @ 2006-02-05 9:41 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200602050906.52016.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> writes:
> The document root of my website has a git repository under it (in the
> standard .git subdirectory) and want a post update hook to checkout the
> contents (so the web server sees it!)
>
> I will be pushing to it via ssh.
>
> Does this mean that the post-update hook with be run with a working directory
> of the web site's document root? or something relative (such as GIT_DIR) so
> that I don't have to do a specific cd to an absolute path.
The current implementation happens to chdir to GIT_DIR and sets
GIT_DIR=. in the environment, so if you have something like
this:
/var/www/myproject/
/var/www/myproject/.git/
/var/www/myproject/.git/HEAD
/var/www/myproject/.git/...
/var/www/myproject/README
Then $(pwd) would be /var/www/myproject/.git/. Your hook would
probably be able to do "cd .." to get to the project top.
However, there is no guarantee for future implementations.
^ permalink raw reply
* Re: What is the working directory for post-update hook?
From: Alan Chandler @ 2006-02-05 9:37 UTC (permalink / raw)
To: git
In-Reply-To: <200602050906.52016.alan@chandlerfamily.org.uk>
On Sunday 05 February 2006 09:06, Alan Chandler wrote:
> The document root of my website has a git repository under it (in the
> standard .git subdirectory) and want a post update hook to checkout the
> contents (so the web server sees it!)
>
> I will be pushing to it via ssh.
>
> Does this mean that the post-update hook with be run with a working
> directory of the web site's document root? or something relative (such as
> GIT_DIR) so that I don't have to do a specific cd to an absolute path.
I found it out, by getting the post update hook to e-mail me the value:-)
its in the repository (ie document_root/.git)
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* What is the working directory for post-update hook?
From: Alan Chandler @ 2006-02-05 9:06 UTC (permalink / raw)
To: git
The document root of my website has a git repository under it (in the
standard .git subdirectory) and want a post update hook to checkout the
contents (so the web server sees it!)
I will be pushing to it via ssh.
Does this mean that the post-update hook with be run with a working directory
of the web site's document root? or something relative (such as GIT_DIR) so
that I don't have to do a specific cd to an absolute path.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: [ANNOUNCE] qgit-1.1rc3
From: Marco Costalba @ 2006-02-05 6:55 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550602041534k4ffa1fcarfd12b347bdbc0902@mail.gmail.com>
On 2/5/06, Marco Costalba <mcostalba@gmail.com> wrote:
> This release is mainly about the new build system, based on auto tools
> instead of scons (courtesy of Pavel Roskin).
>
> To install now use ./configure + make + make install-strip
> Or check the README for detailed information.
>
When downloading from git repository you may need to run _before_
autoreconf -i
to crete the configure file.
Marco
^ permalink raw reply
* Re: 2 questions/nits about commit and config
From: Daniel Barkalow @ 2006-02-05 6:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Keith Packard, git
In-Reply-To: <7vu0bemkce.fsf@assigned-by-dhcp.cox.net>
On Sat, 4 Feb 2006, Junio C Hamano wrote:
> Here is me thinking aloud again.
>
> - "git commit" without _any_ parameter would keep the current
> behaviour. It commits the current index.
>
> We have two choices. (1) we disallow this form to be run in
> a subdirectory, or (2) we do the whole index even when this
> form was run from a subdirectory. I am inclined to say the
> latter.
I'd guess this would primarily happen when the user goes into a
subdirectory to look at related files when resolving a conflicted merge.
If you're committing the prepared index, the working tree isn't
particularly important, so the pwd isn't, either.
> - "git commit paths..." acquires a new semantics. This is an
> incompatible change that needs user training, which I am
> still a bit reluctant to swallow, but enough people seem to
> have complained. It
>
> 1. refuses to run if $GIT_DIR/MERGE_HEAD exists (maybe
> remind trained git users that the traditional semantics
> now needs -i flag).
> 2. refuses to run if named paths... are different in HEAD and
> the index (ditto about reminding).
> 3. reads HEAD commit into a temporary index file.
> 4. updates named paths... from the working tree in this
> temporary index (similar to -i form, we never --add).
I think the following sequence should be permitted:
% git add foo
% git commit foo
I think this means we want --add in step 4, but want to check that the
named paths exist in the index in step 3, although they're allowed to not
exist in HEAD.
> 5. does the same updates of the paths... from the working
> tree to the real index.
> 6. makes a commit using the temporary index that has the
> current HEAD as the parent, and updates the HEAD with this
> new commit.
>
> The first check is needed because otherwise during a merge
> you would end up inserting an unrelated commit between the
> original HEAD and the eventual merge result. The second
> check is to prevent "skewed commit" from confusing people.
> If you updated index, modified the file further and then used
> "git commit paths..." to make a commit, next "git commit"
> without paths would record a partial revert otherwise.
>
> For this one, I think running from subdirectory is a natural
> thing to allow.
>
> - "git commit --all". Now what should we do about this? As
> you reminded me, it is equivalent to "git commit -i ." if run
> from the toplevel (because of the "index must match HEAD on
> named paths" requirements for the partial commits with named
> paths, it is equivalent to "git commit ." only if your index
> is clean). I am inclined to say that this should commit all
> changes in the whole working tree, regardless of where it is
> run.
Agreed.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: 2 questions/nits about commit and config
From: Junio C Hamano @ 2006-02-05 5:58 UTC (permalink / raw)
To: git
In-Reply-To: <7vu0bemkce.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Here is me thinking aloud again.
Before I started writing this message, I meant to address an
excellent point Carl Worth raised in an earlier thread. "What
would I do for final sanity check before committing?". So here
is a follow-up.
> - "git commit"
"git diff --cached HEAD".
> - "git commit --include paths..." (or "git commit -i paths...")
This is for people who work by taking advantage of the power of
the index file, i.e. perform "checking in without committing" by
running update-index whenever the changes so-far look good.
Combined use of "git diff --cached HEAD" (to look at diffs for
paths other than paths...) and "git diff HEAD paths..." would be
the _full_ "final sanity check", but in practice "git diff HEAD
paths..." or even "git diff paths..." would be more useful for
these people. They've verified the changes so-far were sane
when they did update-index already.
> - "git commit paths..." acquires a new semantics. This is an
> incompatible change that needs user training, which I am
> still a bit reluctant to swallow, but enough people seem to
> have complained.
"git diff HEAD paths...".
^ permalink raw reply
* Re: [PATCH] do not open editor in dumb terminal
From: Junio C Hamano @ 2006-02-05 5:48 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Amos Waterland, git, boutcher
In-Reply-To: <Pine.LNX.4.64.0602042346380.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I think that "ed" is a bit too obscure as something for people to use
> interactively, and emacsclient is obviously not a sane default (since
> people might not be using emacs in server mode). Probably the right thing
> is to have it supply a default if the terminal isn't dumb, and abort with
> an error if there is no editor set after defaults are supplied.
I tend to agree (I am a minority who used ed for a long time,
but I am well aware that I _am_ a minority). If somebody wants
to send in a tested patch to be applied, I would suggest to
replace EDITOR=ed in the one I sent out with an error message
and exit(1).
^ permalink raw reply
* Re: 2 questions/nits about commit and config
From: Junio C Hamano @ 2006-02-05 5:43 UTC (permalink / raw)
To: Keith Packard; +Cc: git
In-Reply-To: <1139094055.4200.6.camel@evo.keithp.com>
Keith Packard <keithp@keithp.com> writes:
> making '-a' equivalent to '.' then? Seems like '.' is a whole lot more
> understandable than '-a', but maybe that's just my naïvité showing
> again. I expected the '-a' flag to commit the whole tree from wherever
> you were inside it...
Good point.
Because I _never_ use 'git commit paths...' form myself, I
admit that I did not even know that "git commit ." meant
"commit all the changed files in this directory and under".
But it apparently does ;-).
I would not personally be confused if "cd foo/ && git commit -a"
committed things outside foo/ directory, but I am not sure about
others.
We have had enough discussion on what the "git commit paths.."
semantics should be, and I think we settled most of the issues.
Until this latest "committing from subdirectory" monkey wrench
was thrown into it, that is X-<.
Here is me thinking aloud again.
- "git commit" without _any_ parameter would keep the current
behaviour. It commits the current index.
We have two choices. (1) we disallow this form to be run in
a subdirectory, or (2) we do the whole index even when this
form was run from a subdirectory. I am inclined to say the
latter.
- "git commit --include paths..." (or "git commit -i paths...")
is equivalent to:
git update-index --remove paths...
git commit
So subdirectory semantics depends entirely on what we do for
the parameterless form. Also note that we allow --remove but
never --add; this is what we do for "git commit paths.."
currently.
- "git commit paths..." acquires a new semantics. This is an
incompatible change that needs user training, which I am
still a bit reluctant to swallow, but enough people seem to
have complained. It
1. refuses to run if $GIT_DIR/MERGE_HEAD exists (maybe
remind trained git users that the traditional semantics
now needs -i flag).
2. refuses to run if named paths... are different in HEAD and
the index (ditto about reminding).
3. reads HEAD commit into a temporary index file.
4. updates named paths... from the working tree in this
temporary index (similar to -i form, we never --add).
5. does the same updates of the paths... from the working
tree to the real index.
6. makes a commit using the temporary index that has the
current HEAD as the parent, and updates the HEAD with this
new commit.
The first check is needed because otherwise during a merge
you would end up inserting an unrelated commit between the
original HEAD and the eventual merge result. The second
check is to prevent "skewed commit" from confusing people.
If you updated index, modified the file further and then used
"git commit paths..." to make a commit, next "git commit"
without paths would record a partial revert otherwise.
For this one, I think running from subdirectory is a natural
thing to allow.
- "git commit --all". Now what should we do about this? As
you reminded me, it is equivalent to "git commit -i ." if run
from the toplevel (because of the "index must match HEAD on
named paths" requirements for the partial commits with named
paths, it is equivalent to "git commit ." only if your index
is clean). I am inclined to say that this should commit all
changes in the whole working tree, regardless of where it is
run.
^ permalink raw reply
* Re: [PATCH] do not open editor in dumb terminal
From: Daniel Barkalow @ 2006-02-05 5:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Amos Waterland, git, boutcher
In-Reply-To: <7voe1msef0.fsf@assigned-by-dhcp.cox.net>
On Sat, 4 Feb 2006, Junio C Hamano wrote:
> I know of an editor that works fine even when invoked with
> TERM=dumb, and I explicitly told programs to use it by exporting
> EDITOR environment variable with the name of that editor. I am
> entitled to expect that programs honor that wish, instead of
> insulting me by saying "Hey dummy, you cannot run any editor on
> a dumb terminal". Be the editor "emacsclient" or "ed", they
> both work fine for me, thank you ;-).
I think that "ed" is a bit too obscure as something for people to use
interactively, and emacsclient is obviously not a sane default (since
people might not be using emacs in server mode). Probably the right thing
is to have it supply a default if the terminal isn't dumb, and abort with
an error if there is no editor set after defaults are supplied.
(I think the only editors people use in dumb terminals these days are ones
that do the editing somewhere else, although I'm not sure of that.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git 1.1.6?
From: Junio C Hamano @ 2006-02-05 4:50 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43E55B69.1070601@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> I see git-1.1.6 is out, but I haven't seen an announcement? What's up?
Not much.
I was planning to do a 1.2.0 soon enough for 1.1.6 to matter in
practice, but that has plan been slipping for various reasons.
Changes between 1.1.5 and 1.1.6 are primarily docs and do not
affect functionality.
---
Fredrik Kuivinen:
merge-recursive: Improve the error message printed when merge(1) isn't found.
git-branch: Documentation fixes
J. Bruce Fields:
git push -f documentation
Junio C Hamano:
pre-commit sample hook: do not barf on the initial import
GIT 1.1.6
^ permalink raw reply
* Re: [PATCH] do not open editor in dumb terminal
From: Junio C Hamano @ 2006-02-05 2:54 UTC (permalink / raw)
To: Amos Waterland; +Cc: git, boutcher
In-Reply-To: <20060205003741.GB29021@kvasir.watson.ibm.com>
Amos Waterland <apw@us.ibm.com> writes:
> If your TERM is set to `emacs' then that is fine. If it is set to
> `dumb' however, that seems a bit strange. A dumb terminal is usually
> understood to be one that does not have the ability to interpret control
> sequences.
I am not talking about M-x terminal that uses TERM=emacs-*. I
am talking about M-x shell and M-x compile. In those modes, the
default TERM is "dumb".
I could live with something like this (untested) patch, though.
Instead of falling back on ed (or ex), you could error out and
give the error message if you want.
I know of an editor that works fine even when invoked with
TERM=dumb, and I explicitly told programs to use it by exporting
EDITOR environment variable with the name of that editor. I am
entitled to expect that programs honor that wish, instead of
insulting me by saying "Hey dummy, you cannot run any editor on
a dumb terminal". Be the editor "emacsclient" or "ed", they
both work fine for me, thank you ;-).
The user, at least the ones who understand what your program
does, always knows a lot better about his enviornment and his
needs than your program will ever do. You can try to be helpful
(e.g. refuse to spawn the editor when you feel it is not
appropriate), but you can never be perfect. Just in case your
helpfulness turns out to be misguided inconvenience, you should
leave a way for the user to override it. I was unhappy about
your patch because it errored out only after checking TERM
without checking EDITOR or VISUAL.
Although you did not bring this up, there is a same issue for
${PAGER:-less} elsewhere. Inside Emacs I usually set it to
"cat". I do not want the program to be helpful by just checking
TERM=dumb to error that out, either.
> The reason I sent the patch is that people get a rather
> unpleasant introduction to git when vi splatters control
> characters all over their emacs session when they do their
> first commit.
It's been quite a while since I used the real "vi" the last
time, but I think the real vi was not _that_ dumb as you
described. If the termcap said that the $TERM cannot do a
reasonable visual mode, it sensibly fell back to a line editor
mode ex, if I recall correctly. Maybe popular vi clones these
days are poorly emulated in that respect. I dunno.
---
diff --git a/git-commit.sh b/git-commit.sh
index 193feeb..c4a9dc3 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -207,6 +207,10 @@ then
fi
case "$no_edit" in
'')
+ case "$VISUAL$EDITOR,$TERM" in
+ ',dumb')
+ EDITOR=ed ;;
+ esac
${VISUAL:-${EDITOR:-vi}} "$GIT_DIR/COMMIT_EDITMSG"
;;
esac
^ permalink raw reply related
* Re: [PATCH] do not open editor in dumb terminal
From: H. Peter Anvin @ 2006-02-05 1:58 UTC (permalink / raw)
To: Amos Waterland; +Cc: Junio C Hamano, git, boutcher
In-Reply-To: <20060205003741.GB29021@kvasir.watson.ibm.com>
Amos Waterland wrote:
>
> If your TERM is set to `emacs' then that is fine. If it is set to
> `dumb' however, that seems a bit strange. A dumb terminal is usually
> understood to be one that does not have the ability to interpret control
> sequences.
>
> The reason I sent the patch is that people get a rather unpleasant
> introduction to git when vi splatters control characters all over their
> emacs session when they do their first commit. I agree that people
> probably should have their EDITOR set to emacsclient though, so if you
> want to just leave the code as is that's cool with me.
>
Sounds more like an unpleasant introduction to emacs.
-hpa
^ permalink raw reply
* Git 1.1.6?
From: H. Peter Anvin @ 2006-02-05 1:56 UTC (permalink / raw)
To: git
I see git-1.1.6 is out, but I haven't seen an announcement? What's up?
-hpa
^ permalink raw reply
* Re: [PATCH] do not open editor in dumb terminal
From: Amos Waterland @ 2006-02-05 0:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, boutcher
In-Reply-To: <7vu0bgdxmh.fsf@assigned-by-dhcp.cox.net>
On Fri, Feb 03, 2006 at 11:56:54AM -0800, Junio C Hamano wrote:
> Amos Waterland <apw@us.ibm.com> writes:
> > Many people run git from a shell in emacs (obtained by M-x shell). When
> > they try to do a commit without specifying a log message on the command
> > line with -m, git opens vi inside emacs, with unpleasant results. I
> > think the right answer is to just refuse to open an editor in any dumb
> > terminal.
>
> No, please don't.
>
> I run 'git commit' from M-x shell or M-x compile. My EDITOR is
> set to 'emacsclient' while inside Emacs.
If your TERM is set to `emacs' then that is fine. If it is set to
`dumb' however, that seems a bit strange. A dumb terminal is usually
understood to be one that does not have the ability to interpret control
sequences.
The reason I sent the patch is that people get a rather unpleasant
introduction to git when vi splatters control characters all over their
emacs session when they do their first commit. I agree that people
probably should have their EDITOR set to emacsclient though, so if you
want to just leave the code as is that's cool with me.
^ permalink raw reply
* Re: Merge problems.
From: Linus Torvalds @ 2006-02-05 0:13 UTC (permalink / raw)
To: Ian Molton; +Cc: git
In-Reply-To: <43E52FD3.20202@f2s.com>
On Sat, 4 Feb 2006, Ian Molton wrote:
>
> Doing the following:
>
> git checkout -b mywork v2.6.12
> # work, work, work
> git commit -a
> git merge "Merging happily." mywork v2.6.15
>
> At theat point I get a merge failure - I assume that means I've
> got conflicts. I forgot to not the exact error.
It would be interesting to hear what the error is, but yes, it sounds like
file-level conflicts. However, the fact that you get them for files you
haven't even touched:
> so I can see unmerged files using git ls-files --unmerged which lists a
> lot of SHA1 hashes and paths. but most of the files in the list I havent
> touched! why would they have any conflicts? surely they would simply
> update 2.6.12->2.6.15 ?
You really shouldn't get any conflicts for anything you haven't touched,
since your starting point and the thing you are mergeing to are related,
so they shouldn't have any issues.
One common error people have is that the "merge" binary isn't in their
path, and the actual error is that the first path you _did_ touch failed
to do a three-way merge, and the merge simply has never happened.
If you do _just_ "merge" (no "git", no aguments, no _nothing_), do you get
a message like
merge: not enough arguments
merge: usage: merge [-AeEpqxX3] [-L lab [-L lab [-L lab]]] file1 file2 file3
merge aborted
(which is ok) or do you get a message like
bash: merge: command not found
(which means that you don't have a three-way merge at all)?
If you don't have the merge command, install the rcs package.
> The SHA1 hashes are all listed at least twice per file too, eg.
>
> 100644 d058e65daf19f4bb8c257e2273f4c935ccee5121 1 Documentation/DocBook/scsidrivers.tmpl
> 100644 d058e65daf19f4bb8c257e2273f4c935ccee5121 2 Documentation/DocBook/scsidrivers.tmpl
That's the "stage1" and "stage2" results. The SHA1's are identical, so it
should merge beautifully, and it does sound like the merge was never even
really attempted.
So
- do a "git reset --hard" to undo the partial (undone) merge
- do "yum install rcs" (or apt get, or whatever) to make sure that you
have the three-way merge binary.
- if it still doesn't work, please make sure to save all the error
messages so that we can see them..
Thanks,
Linus
^ permalink raw reply
* [ANNOUNCE] qgit-1.1rc3
From: Marco Costalba @ 2006-02-04 23:34 UTC (permalink / raw)
To: git; +Cc: proski
This release is mainly about the new build system, based on auto tools
instead of scons (courtesy of Pavel Roskin).
To install now use ./configure + make + make install-strip
Or check the README for detailed information.
To note is also the use of git-diff-tree -c option to prune
uninteresting files in merges and to show merge diffs patch.
See http://digilander.libero.it/mcostalba/ for download information.
Changes:
- new build environment based on auto-tools instead of scons (by Pavel Roskin)
- SunOS make cannot chain implicit rules - avoid them (by Pavel Roskin)
- make sure wrong version of Qt is not used (by Pavel Roskin)
- support patch files with spaces in name
- fixes for using srcdir in src/Makefile.am (by Pavel Roskin)
- future-proof configure.ac (by Pavel Roskin)
- use git-diff-tree -c (combined) option to retrieve merge's file list
- fix disabled 'show file viewer' action when no file selected from tree
- use --remove-empty option to retrieve file history
- fix jump to parent/childs lanes pop-up menu
- allow to copy an annotation header sub part in file viewer
- fix handling of command line arguments with single quotes
- widget sizes tweaks and small fixes
Marco
^ permalink raw reply
* Re: [PATCH] Use adler32() from zlib instead of defining our own.
From: Peter Eriksen @ 2006-02-04 23:20 UTC (permalink / raw)
To: git
In-Reply-To: <20060204225401.GA24725@ebar091.ebar.dtu.dk>
On Sat, Feb 04, 2006 at 11:54:01PM +0100, Peter Eriksen wrote:
>
> Since we already depend on zlib, we don't need to define our
> own adler32(). Spotted by oprofile.
Sorry for the bad formatting, I don't use git-format-patch often enough
to be comfortable with it yet.
The patch shows no regression on my machine and at least doesn't slow
down the 2.6.15 merge with 2.6.12+change, but I don't know, if it's
correct. It just seemed like an easy cleanup.
It was only spotted indirectly, while I was playing with OProfile
(thanks Linus), trying to find the bottlenecks in the afore mentioned
merge.
Regards,
Peter
^ permalink raw reply
* [PATCH] Use adler32() from zlib instead of defining our own.
From: Peter Eriksen @ 2006-02-04 22:54 UTC (permalink / raw)
To: git
Since we already depend on zlib, we don't need to define our
own adler32(). Spotted by oprofile.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
---
diff-delta.c | 39 +--------------------------------------
1 files changed, 1 insertions(+), 38 deletions(-)
86557e168f581f27b6869a751a56386bbc9e5059
diff --git a/diff-delta.c b/diff-delta.c
index 890986e..c2f656a 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -20,6 +20,7 @@
#include <stdlib.h>
#include "delta.h"
+#include "zlib.h"
/* block size: min = 16, max = 64k, power of 2 */
@@ -30,44 +31,6 @@
#define GR_PRIME 0x9e370001
#define HASH(v, b) (((unsigned int)(v) * GR_PRIME) >> (32 - (b)))
-/* largest prime smaller than 65536 */
-#define BASE 65521
-
-/* NMAX is the largest n such that 255n(n+1)/2 + (n+1)(BASE-1) <= 2^32-1 */
-#define NMAX 5552
-
-#define DO1(buf, i) { s1 += buf[i]; s2 += s1; }
-#define DO2(buf, i) DO1(buf, i); DO1(buf, i + 1);
-#define DO4(buf, i) DO2(buf, i); DO2(buf, i + 2);
-#define DO8(buf, i) DO4(buf, i); DO4(buf, i + 4);
-#define DO16(buf) DO8(buf, 0); DO8(buf, 8);
-
-static unsigned int adler32(unsigned int adler, const unsigned char *buf, int len)
-{
- int k;
- unsigned int s1 = adler & 0xffff;
- unsigned int s2 = adler >> 16;
-
- while (len > 0) {
- k = MIN(len, NMAX);
- len -= k;
- while (k >= 16) {
- DO16(buf);
- buf += 16;
- k -= 16;
- }
- if (k != 0)
- do {
- s1 += *buf++;
- s2 += s1;
- } while (--k);
- s1 %= BASE;
- s2 %= BASE;
- }
-
- return (s2 << 16) | s1;
-}
-
static unsigned int hashbits(unsigned int size)
{
unsigned int val = 1, bits = 0;
--
1.1.6.g8655
^ permalink raw reply related
* Re: 2 questions/nits about commit and config
From: Keith Packard @ 2006-02-04 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: keithp, git
In-Reply-To: <7vhd7evk38.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
On Sat, 2006-02-04 at 14:24 -0800, Junio C Hamano wrote:
> Before people start complaining about it, I take this part
> back. "git commit -a" inside a subdirectory "foo" is not much
> different from "git commit foo/a foo/b foo/c" from the toplevel
> directory
making '-a' equivalent to '.' then? Seems like '.' is a whole lot more
understandable than '-a', but maybe that's just my naïvité showing
again. I expected the '-a' flag to commit the whole tree from wherever
you were inside it...
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2 questions/nits about commit and config
From: Alan Chandler @ 2006-02-04 22:59 UTC (permalink / raw)
To: git
In-Reply-To: <7vhd7evk38.fsf@assigned-by-dhcp.cox.net>
On Saturday 04 February 2006 22:24, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> > An example of such semantic change would be: if I am in
> > subdirecotry foo/, commit changes to files in that subdirectory
> > and subdirectory alone. But that is actively _encouraging_
> > partial commits (commits that records a state that never existed
> > in your working tree as a whole) so I personally am not so
> > enthused to buy such a _feature_.
>
> Before people start complaining about it, I take this part
> back. "git commit -a" inside a subdirectory "foo" is not much
> different from "git commit foo/a foo/b foo/c" from the toplevel
> directory to explicitly say "Don't worry about what I told the
> index so far; I want to check in changes only to these paths",
> and making a partial commit out of the current HEAD and the
> specified working tree files using a temporary index (while
> updating the main index at the same time), so I am inclined to
> say we should support it that way, since during the previous
> discussion we have pretty much settled how we would want "git
> commit paths..." and "git commit --include paths..." commands to
> behave.
And I did describe a use case this morning in another thread for this very
thing. For convenience I repeat it here
[Incidentally there is a use case that doesn't seem to have been discussed in
this thread which I use cg-commit all the time for and will now have to see
if there is a use index file equivalence for. That is, I am developing a web
application and in the running version the database framework (iBatis) is
using Tomcats connection pooling. In order to run my JUnit test harness, I
don't have tomcat, so I need to define a different version of iBatis
configuration file to used its own database connection. So I have created a
test branch and edited the configuration file in that branch, and I update
both code and tests in a edit/compile/fix and text loop until I have written
or changed both code and tests. I then do a cg-commit which lists the files
I have changed. I ONLY commit those in the test harness - by deleting the
others from cogito's list of files to commit - and then repeat the commit
commiting the rest]. I then switch back to my master branch and cherry pick
commit that is the code changes - not the text harness]
In this case the tests, and the code that it was testing were in different
subdirectories, so the ability to go into one directory and commit all in
that directory, followed by the ability to go into the other and do the same
would be extremely useful.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ 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