* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Wincent Colaiuta @ 2009-01-21 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, git
In-Reply-To: <7v8wp4e5wn.fsf@gitster.siamese.dyndns.org>
El 21/1/2009, a las 21:54, Junio C Hamano escribió:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> This is shorter, avoids the burder to think about the format of the
>> configuration file, and git config is already used in other places in
>> the manual.
>
> I am moderately against changing this part to use "git config".
>
> We traditionally introduced how to set configuration variables first
> by
> editing it in an editor, and this was quite deliberate, in order to
> show
> how the configuration file looks like, to demonstrate that there is no
> deep magic in the file format, and to explain that it is perfectly
> Ok to
> edit it without using "git config" command.
If that's the goal, why not do both?:
1. Show people how to use "git config" like this patch does (seeing as
it's easier and less error prone)
2. Tell people that they can inspect and even edit the config file by
hand if they want
The actual order of 1 and 2 depends on where you want to place more
emphasis:
Something like either:
> Before creating any commits, you should introduce yourself to git.
> The
> easiest way to do so is to make sure the following lines appear in a
> file named .gitconfig in your home directory:
>
> [user]
> name = Your Name Comes Here
> email = you@yourdomain.example.com
>
> As a convenience you can use linkgit:git-config[1] to modify
> your .gitconfig
> instead of editing it by hand:
>
> $ git config --global user.name "Your Name Comes Here"
> $ git config --global user.email you@yourdomain.example.com
Or:
> Before creating any commits, you should introduce yourself to git.
> The
> easiest way is to use the linkgit:git-config[1] command:
>
> $ git config --global user.name "Your Name Comes Here"
> $ git config --global user.email you@yourdomain.example.com
>
> Your settings are written to a file named .gitconfig in your home
> directory which you can inspect or even edit by hand. Settings look
> like this:
>
> [user]
> name = Your Name Comes Here
> email = you@yourdomain.example.com
Cheers,
Wincent
^ permalink raw reply
* Short "git commit $file" syntax fails in the face of a resolved conflict
From: Asheesh Laroia @ 2009-01-21 21:00 UTC (permalink / raw)
To: git; +Cc: nathan
I have found what seems to be a bug in the short "git commit $file" mode
of interaction with git. To reproduce it, you can:
1. Create a repository with some content.
$ (mkdir a ; cd a ; git init ; echo hi > file ; git add file ; git commit -m 'initial commit')
Initialized empty Git repository in /tmp/playground.2009-01-21.w15613/a/.git/
Created initial commit 276d6eb: initial commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file
2. Clone that repository.
$ git clone a b
Initialized empty Git repository in /tmp/playground.2009-01-21.w15613/b/.git/
3. Create changes in "a" that are not yet cloned into "b".
$ (cd a ; echo ho > file ; git add file ; git commit -m update)
Created commit 91deff9: update
1 files changed, 1 insertions(+), 1 deletions(-)
4. Make changes in "b", the clone.
$ echo lol > file
$ git add file ; git commit -m 'Some changes'
Created commit 5d74b5b: Some changes
1 files changed, 1 insertions(+), 1 deletions(-)
5. Fetch and merge (AKA pull) from the first repo.
$ git pull
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /tmp/playground.2009-01-21.w15613/a/
276d6eb..91deff9 master -> origin/master
Auto-merged file
CONFLICT (content): Merge conflict in file
Automatic merge failed; fix conflicts and then commit the result.
6. Resolve the conflict (in our case, by discarding the changes in the "b"
clone).
$ echo ho > file
7. Commit the resolved conflict.
NOTE: The normal way to do step 6 is to "git add file ; git commit -m
yay". But I will now try to use the "git commit file" shorthand:
$ git commit file -m 'Resolved conflict'
fatal: cannot do a partial commit during a merge.
8. Declare a bug.
I believe that the "git commit file" command issued in step 6 should have
worked as well as the "git add file ; git commit" that us old-time git
users do.
9. Discuss on the git list.
Do y'all agree that the git behavior is strange and unnecessarily
user-impeding here?
Cheers!
-- Asheesh.
P.S. I'm not the one who ran into the bad behavior here; Nathan (CC:d) is
the one who did. You don't have to keep him CC:d, though.
--
Avoid gunfire in the bathroom tonight.
^ permalink raw reply
* Re: What about allowing multiple hooks?
From: Johannes Schindelin @ 2009-01-21 21:10 UTC (permalink / raw)
To: Anders Waldenborg
Cc: git, Alexander Potashev, Marc Weber, Rogan Dawes, martin f krafft
In-Reply-To: <4977872E.70901@0x63.nu>
Hi,
On Wed, 21 Jan 2009, Anders Waldenborg wrote:
> I need multiple hooks, so I've done some thinking about this, so I
> thought it may be a good idea to share this here.
>
> I currently use configvalues to specify which hooks to run. For example
> this is how my post-receive looks:
>
> data=$(cat)
> git config --get-all hooks.post-receive.hook | while read hook; do
> $hook <<__EOF__
> "$data"
> __EOF__
> done
I wonder why you don't do the obvious thing:
data=$(cat)
for hook in .git/hooks/update.d/*
do
test -x "$hook" || continue
echo "$data" | "$hook" | exit
done
and then name the hooks in your .git/hooks/update.d/ with leading
zero-padded numbers so that you guarantee a certain order.
You can even share special hooks between repositories by symlinking, as is
done in /etc/init.d/rc?.d.
Hth,
Dscho
P.S.: If you want to save even more interactive work, you can name the
hooks .git/hooks/update.[0-9]*.
^ permalink raw reply
* Re: Merging adjacent deleted lines?
From: Junio C Hamano @ 2009-01-21 21:08 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <57518fd10901211120n62f8d0e9ya8595fc9baa6476c@mail.gmail.com>
Jonathan del Strother <maillist@steelskies.com> writes:
> Say I have a file that started out with the following content :
>
> line1
> line2
> line3
> line4
>
>
> I create a branch, which deletes line2. Someone else's branch deletes line 3.
>
> When I merge those two branches, the conflict looks like :
>
> line1
> <<<<<<< HEAD:lines
> line3
> =======
> line2
>>>>>>>> SomeoneElse:lines
> line4
>
>
>
> Which in my cursory overview, looked an awful lot like the obvious
> merge resolution ought to be
>
> line1
> line3
> line4
Why? The obvious resolution would be:
line1
line4
as it is obvious that you do not want line2 and the other does not want
line3.
But that is only true if it is obvious to you. When you cannot remember
what each side did since they forked, there are two ways you can use to
understand the history better without resorting to graphical merge tools.
$ git log -p --merge <path>
which shows you the commits involved in the conflict, what they did, and
why they did what they did (of course, this assumes that your project
participant did their commits properly).
$ git checkout --conflict=diff3 <path>
This will add an extra block to the conflicted output to show the common
ancestor's version, after showing yours. The conflicts left in <path>
would look like this:
line1
<<<<<<< ours
line3
|||||||
line2
line3
=======
line2
>>>>>>> theirs
line4
which may make it clearer that you deleted line2 and they deleted line3.
^ permalink raw reply
* Re: [PATCH] Added giteditor script to show diff while editing commit message.
From: Ted Pavlic @ 2009-01-21 21:07 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <0E82F261-2D96-4204-9906-C5E8D47E9A5D@wincent.com>
>> This script also detects when "stg edit" is being called and uses "stg
>> show" instead.
> You do know about "git commit -v", right? (Although that displays
> commit message and diff in a single buffer, not two separate ones like
> your script does.)
Actually, I didn't. I was looking for something like hgeditor for git,
and I found something on vim.org that almost hit the mark but no mention
of "commit -v".
That being said, I like having the diff up in a separate window. Plus,
"git commit -v" doesn't help me when I want to "stg edit".
Thanks --
Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* [PATCH] git mergetool: Don't repeat merge tool candidates
From: Johannes Gilger @ 2009-01-21 20:24 UTC (permalink / raw)
To: git; +Cc: Johannes Gilger
git mergetool listed some candidates for mergetools twice, depending on
the environment.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
---
git-mergetool.sh | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..8f09e4a 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -390,21 +390,18 @@ fi
if test -z "$merge_tool" ; then
if test -n "$DISPLAY"; then
- merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
- merge_tool_candidates="meld $merge_tool_candidates"
- fi
- if test "$KDE_FULL_SESSION" = "true"; then
- merge_tool_candidates="kdiff3 $merge_tool_candidates"
+ merge_tool_candidates="meld kdiff3 tkdiff xxdiff gvimdiff"
+ else
+ merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
fi
fi
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
- merge_tool_candidates="$merge_tool_candidates emerge"
+ merge_tool_candidates="$merge_tool_candidates emerge opendiff vimdiff"
fi
if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
- merge_tool_candidates="$merge_tool_candidates vimdiff"
+ merge_tool_candidates="$merge_tool_candidates vimdiff opendiff emerge"
fi
- merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
init_merge_tool_path $i
--
1.6.1.40.g8ea6a
^ permalink raw reply related
* Re: Planet Git
From: Johannes Schindelin @ 2009-01-21 20:59 UTC (permalink / raw)
To: webmaster; +Cc: git
In-Reply-To: <a2ce9d792bc2f586e2a1408e573db433.squirrel@webmail.planetgit.org>
Hi,
On Wed, 21 Jan 2009, webmaster@planetgit.org wrote:
> Just wanted to let everyone know that I've started a Planet for Git
> users/developers who write about it on their journals/weblogs.
>
> http://planetgit.org
Just went there, because I thought it might be fun to write about my
newest ideas, and progress on old ones.
But then I read this:
If you want to have your journal/weblog aggregated here, please
send an email to the webmaster with your name, full git-related
feed and hackergotchi URL.
Up until the "send an email to the webmaster with your name", I was game.
After that: I am probably too stupid, because I do not understand what is
meant, but even then, I am sure that I no longer want to be part of it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Junio C Hamano @ 2009-01-21 20:54 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1232561365-5919-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> This is shorter, avoids the burder to think about the format of the
> configuration file, and git config is already used in other places in
> the manual.
I am moderately against changing this part to use "git config".
We traditionally introduced how to set configuration variables first by
editing it in an editor, and this was quite deliberate, in order to show
how the configuration file looks like, to demonstrate that there is no
deep magic in the file format, and to explain that it is perfectly Ok to
edit it without using "git config" command.
I actually wish this section appeared a lot earlier in the document, but
that is a separate issue.
^ permalink raw reply
* Re: [PATCH 2/2 v2] valgrind: ignore ldso errors
From: Johannes Schindelin @ 2009-01-21 20:51 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090121190921.GC21686@coredump.intra.peff.net>
Hi,
On Wed, 21 Jan 2009, Jeff King wrote:
> On Wed, Jan 21, 2009 at 02:36:40AM +0100, Johannes Schindelin wrote:
>
> > Only change vs v1: adds Addr4 suppression, so that ld.so "errors"
> > are ignored on 32-bit, too.
>
> I don't think it is wrong to add the extra suppression, but out of
> curiosity, did you actually trigger it?
Yes. I wouldn't have touched the file if I hadn't triggered it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2 v2] Add valgrind support in test scripts
From: Johannes Schindelin @ 2009-01-21 20:49 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090121190201.GA21686@coredump.intra.peff.net>
Hi,
On Wed, 21 Jan 2009, Jeff King wrote:
> On Wed, Jan 21, 2009 at 02:10:17AM +0100, Johannes Schindelin wrote:
>
> > - symbolic links are inspected for correct targets now, and if they
> > point somewhere else than expected, they are removed (this can
> > error out if the file could not be removed) and recreated.
>
> Now you _do_ have a race on this, and triggering it will cause you to
> run a random version of git from your PATH, not using valgrind (instead
> of running the version from the repo using valgrind). Something like:
>
> A: execvp("git-foo")
> B: oops, "git-foo" is out of date
> B: rm $GIT_VALGRIND/git-foo
> A: look for $GIT_VALGRIND/git-foo; not there
> A: look for $PATH[1]/git-foo; ok, there it is
> B: ln -s ../../git-valgrind $GIT_VALGRIND/git-foo
Except that A had to check the link first, and it was out-of-date already
-- except if you changed a script into a builtin _and_ run make while a
valgrinded test is called _and_ you're unlucky.
> > +--valgrind::
> > + Execute all Git binaries with valgrind and stop on errors (the
> > + exit code will be 126).
>
> It doesn't necessarily stop: it just causes the command to fail, which
> causes the test to fail. Which _will_ stop if you have "-i".
>
> Also, you might want to mention that valgrind errors go to stderr, so
> using "-v" is helpful.
Okay.
> > + # override all git executables in PATH and TEST_DIRECTORY/..
> > + GIT_VALGRIND=$TEST_DIRECTORY/valgrind/bin
>
> I think you should leave GIT_VALGRIND pointing to the main valgrind
> directory. That way it is more convenient for people using
> GIT_VALGRIND_OPTIONS to make use of GIT_VALGRIND without having to ".."
> everything (for example, they may want to pick and choose suppressions
> to load for their platform).
Okay.
> > + case "$base" in
> > + *.sh|*.perl)
> > + symlink_target=../unprocessed-script
> > + esac
>
> AFAIK, this triggers an error if I try to call "git-foo.perl" directly.
Yep.
> What does this have to do with valgrind?
Nothing, except that the infrastructure is there now.
> Why does this error checking happen when I run --valgrind, but _not_
> otherwise?
Because we can only check for that kind of mistake in our scripts (which
the author would not realize is a mistake when running on a system where
GIT_SHELL=/bin/sh) when we redirect GIT_EXEC_PATH.
So basically, it would take a tremendous effort otherwise, but here, it is
just easy.
> And yes, I know the answer is "because it's easy to do here, since
> --valgrind is munging the PATH anyway". But my point is that that is an
> _implementation_ detail, and the external behavior to a user is
> nonsensical.
>
> The fact that there are other uses for munging the PATH than valgrind
> implies to me that we should _always_ be munging the PATH like this to
> catch these sorts of errors. And then "--valgrind" can just change the
> way we munge.
Hmm. Maybe.
> > + # create the link, or replace it if it is out of date
> > + if test ! -h "$GIT_VALGRIND"/"$base" ||
> > + test "$symlink_target" != \
> > + "$(readlink "$GIT_VALGRIND"/"$base")"
> > + then
>
> readlink is not portable; it's part of GNU coreutils. Right now valgrind
> basically only runs on Linux, which I think generally means that
> readlink will be available (though I have no idea if there are
> distributions that vary in this). However, there is an experimental
> valgrind port to FreeBSD and NetBSD, which are unlikely to have
> readlink.
As I mentioned earlier: let's bridge this bridge when we face it
(probably it involves making a test-readlink).
Or are you insisting that the patch should be reworked _now_ so that
GIT_EXEC_PATH _always_ points somewhere else?
I hope not, because then you break Windows.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Added giteditor script to show diff while editing commit message.
From: ted @ 2009-01-21 20:47 UTC (permalink / raw)
To: gitster; +Cc: git, Ted Pavlic
From: Ted Pavlic <ted@tedpavlic.com>
This new script (contrib/giteditor/giteditor) is an example GIT_EDITOR
that causes the editor to open the commit message as well as a "git diff
--cached". As a result, a window showing a diff of what is being
committed is opened alongside the commit message.
This script also detects when "stg edit" is being called and uses "stg
show" instead.
This script is highly influenced by the "hgeditor" script distributed
with the Mercurial SCM.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
contrib/giteditor/README | 9 ++++
contrib/giteditor/giteditor | 111 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 contrib/giteditor/README
create mode 100755 contrib/giteditor/giteditor
diff --git a/contrib/giteditor/README b/contrib/giteditor/README
new file mode 100644
index 0000000..b769c3e
--- /dev/null
+++ b/contrib/giteditor/README
@@ -0,0 +1,9 @@
+A GIT_EDITOR to show diff alongside commit message. User can review diff
+within commit edit window. Works with StGit ("stg edit") as well.
+
+To use this script, set it as the value of GIT_EDITOR (or core.editor).
+
+
+Copyright (c) 2009 by Theodore P. Pavlic <ted@tedpavlic.com>
+Highly influenced by hgeditor script distributed with Mercurial SCM.
+Distributed under the GNU General Public License, version 2.0.
diff --git a/contrib/giteditor/giteditor b/contrib/giteditor/giteditor
new file mode 100755
index 0000000..13ca5f6
--- /dev/null
+++ b/contrib/giteditor/giteditor
@@ -0,0 +1,111 @@
+#!/bin/sh
+#
+# A GIT_EDITOR to show diff alongside commit message. User can review
+# diff within commit edit window. Works with StGit ("stg edit") as well.
+#
+# Copyright (c) 2009 by Theodore P. Pavlic <ted@tedpavlic.com>
+# Highly influenced by hgeditor script distributed with Mercurial SCM.
+# Distributed under the GNU General Public License, version 2.0.
+#
+# To use this script, set it as the value of GIT_EDITOR (or
+# core.editor).
+#
+
+# Find git
+[ -z "${GIT}" ] && GIT="git"
+
+# Find stg
+[ -z "${STG}" ] && STG="stg"
+
+# Use an editor. To prevent loops, avoid GIT_EDITOR and core.editor.
+EDITOR=${GIT_EDITOR_EDITOR} || \
+ EDITOR=${VISUAL} || \
+ EDITOR=${EDITOR} || \
+ EDITOR="vi";
+
+# If we recognize a popular editor, add necessary flags
+case "${EDITOR}" in
+ emacs)
+ EDITOR="${EDITOR} -nw"
+ ;;
+ mvim|gvim|vim)
+ EDITOR="${EDITOR} -f -o"
+ ;;
+esac
+
+# Remove temporary files even if we get interrupted
+GITTMP=""
+cleanup_exit() {
+ [ -n "${GITTMP}" ] && rm -rf "${GITTMP}"
+}
+trap "cleanup_exit" 0 # normal exit
+trap "exit 255" 1 2 3 6 15 # HUP INT QUIT ABRT TERM
+
+# End GITTMP in ".git" so that "*.git/" syntax highlighting recognition
+# doesn't break
+GITTMP="${TMPDIR-/tmp}/giteditor.$RANDOM.$RANDOM.$RANDOM.$$.git"
+(umask 077 && mkdir "${GITTMP}") || {
+ echo "Could not create temporary directory! Exiting." 1>&2
+ exit 1
+}
+
+# For git, COMMITMSG=COMMIT_EDITMSG
+# For stg, COMMITMSG=.stgit-edit.txt
+# etc.
+COMMITMSG=$( basename "$1" )
+
+case "${COMMITMSG}" in
+ .stgit-edit.txt)
+ DIFFCMD="${STG}"
+ DIFFARGS="show"
+ ;;
+ *)
+ DIFFCMD="${GIT}"
+ DIFFARGS="diff --cached"
+ ;;
+esac
+
+if [ -f "$1" ]; then
+ # We were passed an existing commit message
+
+ "${DIFFCMD}" ${DIFFARGS} >> "${GITTMP}/diff"
+## Uncomment if you only want to see diff of what changed
+## (note that it only works if DIFFCMD is git)
+# (
+# grep '^#.*modified:' "$1" | cut -b 15- | while read changed; do
+# "${DIFFCMD}" ${DIFFARGS} "${changed}" >> "${GITTMP}/diff"
+# done
+# )
+
+ cat "$1" > "${GITTMP}/${COMMITMSG}"
+
+else
+
+ # Give us a blank COMMITMSG to edit
+ touch "${GITTMP}/${COMMITMSG}"
+
+ # Generate the diff
+ "${DIFFCMD}" ${DIFFARGS} >> "${GITTMP}/diff"
+ #touch "${GITTMP}/diff"
+
+fi
+
+# Use MD5 to see if commit message changed (necessary?)
+MD5=$(which md5sum 2>/dev/null) || \
+ MD5=$(which md5 2>/dev/null)
+
+[ -x "${MD5}" ] && CHECKSUM=$( ${MD5} "${GITTMP}/${COMMITMSG}" )
+if [ -s "${GITTMP}/diff" ]; then
+ # Diff is non-empty, so edit msg and diff
+ ${EDITOR} "${GITTMP}/${COMMITMSG}" "${GITTMP}/diff" || exit $?
+else
+ # Empty diff. Only edit msg
+ ${EDITOR} "${GITTMP}/${COMMITMSG}" || exit $?
+fi
+[ -x "${MD5}" ] && (echo "${CHECKSUM}" | ${MD5} -c >/dev/null 2>&1 && exit 13)
+
+# Commit message changed, so dump it on original message from Git
+mv "${GITTMP}/${COMMITMSG}" "$1"
+
+# (recall that GITTMP directory gets cleaned up by trap above)
+exit $?
--
1.6.1.213.g28da8
^ permalink raw reply related
* Re: Deleting remote branch pointed by remote HEAD
From: Junio C Hamano @ 2009-01-21 20:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Jeff King, Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <alpine.LNX.1.00.0901211237530.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> That is, refs/remotes/origin/HEAD is only there to let the user abbreviate
> the most useful branch of the remote; there's no reason it should reflect
> the remote's HEAD, except that the remote's HEAD is a good guess if the
> user hasn't said anything.
>
> I think it might be more appropriate to just care less about a broken
> symref, explain what's wrong if the user actually tries to use it, and
> otherwise mostly ignore it.
I agree with you in many of the points in your message.
The user used to be able to say "origin" as a shorthand for "origin/frotz"
by having "remotes/origin/HEAD" locally, and somebody (not necessarily the
user himself) broke this arrangement. Silently discarding HEAD will lose
the information on which remote branch was the interesting one for the
user. It may also change the disambiguation rules for "origin" without
telling the user. Neither is desirable.
The tool needs a better explanation of the situation. We also want an
easier way to help the user repoint the HEAD to something else, or remove
the dangling HEAD than telling him to use symbolic-ref.
^ permalink raw reply
* Re: What about allowing multiple hooks?
From: Anders Waldenborg @ 2009-01-21 20:35 UTC (permalink / raw)
To: git; +Cc: Alexander Potashev, Marc Weber, git, Rogan Dawes, martin f krafft
In-Reply-To: <7vd4f3z8xu.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> I deliberately omitted support for multiple scripts in core git Porcelains
> to avoid this exact issue. It is a huge can of worms and it is dubious if
> you can have a coherent and generic enough semantics.
>
> In the meantime, you can have a single .git/hooks/pre-commit script that
> defines your own convention. Maybe it uses .git/hooks/pre-commit.d/
> directory, full of scripts, and implements the semantics you want,
> including:
>
> (1) the execution order and the naming convention of the scripts (e.g.
> they all live in pre-commit.d/ directory, and executed in ASCII byte
> value order of their names);
>
> (2) how their exit status combine together.
I need multiple hooks, so I've done some thinking about this, so I
thought it may be a good idea to share this here.
I currently use configvalues to specify which hooks to run. For example
this is how my post-receive looks:
data=$(cat)
git config --get-all hooks.post-receive.hook | while read hook; do
$hook <<__EOF__
"$data"
__EOF__
done
Now none of my hooks wants to prevent update, so I don't care about
return status. But it could easily be extended, for example by having
some indicator per hook that can have the values (are these enough?):
ignore - pretent that no failure was returned no matter what
sufficient - if this hook suceeds end result is always sucess
required - if this hook fails we fail, no more hooks are run
That could be done with the simple configvalue thing as follows:
git config -add hooks.post-receive.hook \
"sufficient allow-repo-owner-to-do-anything.sh"
git config -add hooks.post-receive.hook \
"required finegrained-access-control.sh"
git config -add hooks.post-receive.hook \
"required allow-repo-owner-to-do-anything.sh"
git config -add hooks.post-receive.hook \
"ignore send-mail.sh"
git config -add hooks.post-receive.hook \
"ignore send-irc-notification.py"
One problem is that to change order one has to resort to manually
editing config. So maybe something richer could be used:
[hooks "allow-repo-owner-to-do-anything"]
cmd = /usr/share/git-hooks/allow-repo-owner-to-do-anything.sh
enabled = 1
type = post-receive
mode = sufficient
priority = 10
[hooks "mail"]
cmd = /usr/share/git-hooks/allow-repo-owner-to-do-anything.sh
enabled = 1
type = post-receive
mode = ignore
priority = 1000
(this would even allow running hooks at same priority simultaneously)
Also then the hook's own config variables fits nicely in same section.
(note that then each [hooks "x"] will be an instance that could use the
same script, but different configvars)
anders
^ permalink raw reply
* Re: Planet Git
From: Johannes Gilger @ 2009-01-21 20:27 UTC (permalink / raw)
To: git
In-Reply-To: <a2ce9d792bc2f586e2a1408e573db433.squirrel@webmail.planetgit.org>
On 2009-01-21, webmaster@planetgit.org <webmaster@planetgit.org> wrote:
> Just wanted to let everyone know that I've started a Planet for Git
> users/developers who write about it on their journals/weblogs.
Funny, I just visited it today and didn't know how long this website has
been idle like that (with only 4 blogs or so). So I was about to write
you to post it right here, but you did that already.
Although right now I can't see any subscriptions at all :(
Greetings,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: John (zzz) Doe <john.doe@xz> (Comment)
From: Kirill Smelkov @ 2009-01-21 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vzlhlic7d.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 20, 2009 at 07:12:54PM -0800, Junio C Hamano wrote:
> Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> > Is it ok?
>
> I think the patch text looks good, but what you have as the proposed
> commit log message does not look anything like log message we usually use.
>
> - If you agree with my comment that "should NOT be included" from the RFC
> you quoted is irrelevant, then I do not think you would even want to
> have anything before "On the other hand,...".
>
> - If you disagree, then why are you bending the patch text to match what
> I say? ;-)
I agree, really :)
It's only me usually tired in the end of the day, like today too.
I'll try to have a rest and will reply with updated patch.
Thanks,
Kirill
^ permalink raw reply
* Re: [PATCH (topgit)] tg-patch: add support for generating patches against worktree and index
From: Kirill Smelkov @ 2009-01-21 20:26 UTC (permalink / raw)
To: martin f krafft; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <20090121032052.GB7422@lapse.rw.madduck.net>
On Wed, Jan 21, 2009 at 02:20:52PM +1100, martin f krafft wrote:
> also sprach Kirill Smelkov <kirr@landau.phys.spbu.ru> [2009.01.21.0456 +1100]:
> > No problem and take your time.
> >
> > It was just me having no idea about what's going on.
>
> I am a little confused about the patches, and git-am does not seem
> to be able to apply two patches from the same email. I use Maildir,
> so I am passing the single message with multiple patches to git-am,
> and it applies all changes into one single commit.
I see.
It seems I need to study how to prepare patches with patchy comments, or
get my hands dirty with `git am` :)
> Anyway, do you have a repo which I can cherry-pick from?
Sure
git://repo.or.cz/topgit/kirr.git for-upstream
Thanks,
Kirill
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Jeff King @ 2009-01-21 19:53 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <alpine.LNX.1.00.0901211443140.19665@iabervon.org>
On Wed, Jan 21, 2009 at 02:50:40PM -0500, Daniel Barkalow wrote:
> I think the ideal thing is to keep the symref as a reminder and just give
> a non-confusing error message instead of a confusing one. E.g.:
>
> """
> $foo is set to mean the tracking branch $foo/bar, which does not exist.
> Use:
>
> git remote set-default $foo <name>
>
> to set a new default branch for $foo.
> """
>
> (And, of course, add that subcommand to remote)
I think that would be reasonable behavior (and probably a special mode
for set-default to just update from the remote's idea of HEAD).
-Peff
^ permalink raw reply
* Re: [PATCH] user-manual: Simplify the user configuration.
From: Jeff King @ 2009-01-21 19:51 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530901211139x6296a48m14aa7ce1d8e65145@mail.gmail.com>
On Wed, Jan 21, 2009 at 09:39:27PM +0200, Felipe Contreras wrote:
> That's over complicating the user with what should probably be one of
> the first things to do. Besides, do Windows users know which is their
> home directory?
Like I said, I don't care one way or the other, personally. But you
should at least address points brought up in the previous iterations:
http://thread.gmane.org/gmane.comp.version-control.git/37921/focus=38007
http://thread.gmane.org/gmane.comp.version-control.git/46903
-Peff
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Daniel Barkalow @ 2009-01-21 19:50 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <20090121191408.GA22958@coredump.intra.peff.net>
On Wed, 21 Jan 2009, Jeff King wrote:
> On Wed, Jan 21, 2009 at 02:12:19PM -0500, Jeff King wrote:
>
> > > I think it might be more appropriate to just care less about a broken
> > > symref, explain what's wrong if the user actually tries to use it, and
> > > otherwise mostly ignore it.
> >
> > I thought about that, but I still wonder if deleting it when the
> > pointed-to ref is deleted might be more convenient. Remember that
> > "refs/remotes/$foo/HEAD" can be accessed by a shorthand "$foo". So that
> > means it can impact ref ambiguity lookup. I guess the chance of that
> > happening is fairly unlikely, though.
>
> Not to mention that even without others refs with matching names, it is
> probably nicer to the user who does try to access it via "$foo" to
> simply say "there is no $foo" rather than a confusing error message
> about a deleted branch that they have to manually fix. And that is
> easily accomplished by deleting such a bogus symref.
I think the ideal thing is to keep the symref as a reminder and just give
a non-confusing error message instead of a confusing one. E.g.:
"""
$foo is set to mean the tracking branch $foo/bar, which does not exist.
Use:
git remote set-default $foo <name>
to set a new default branch for $foo.
"""
(And, of course, add that subcommand to remote)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Merging adjacent deleted lines?
From: Robin Rosenberg @ 2009-01-21 19:49 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <57518fd10901211120n62f8d0e9ya8595fc9baa6476c@mail.gmail.com>
onsdag 21 januari 2009 20:20:50 skrev Jonathan del Strother:
[...]
> So, it looks like I need to be way more careful when merging
> conflicts. Which leads me to - what tools do you use when studying
> conflicts like that? git blame seems the obvious one, for getting the
> context of each deletion, but it seems like I need to run it once as
> git blame HEAD lines, and once as git blame MERGE_HEAD lines. Is
> there something a little more integrated for comparing the origin of
> each change from both merge branches simultaneously?
>
> Would welcome any thoughts on how you guys approach conflict-resolution
I think you've illustrated a case for graphical merge resolution tools, i.e.
run git mergetool to help resolve the conlicts. It will run a graphical tool
for you.
The list seems to be: kdiff3 kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
None of the tools can run blame in the merge tool also. That would be nice.
-- robin
^ permalink raw reply
* Re: [PATCH] user-manual: Simplify the user configuration.
From: Felipe Contreras @ 2009-01-21 19:39 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090121191808.GF21686@coredump.intra.peff.net>
On Wed, Jan 21, 2009 at 9:18 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Jan 21, 2009 at 09:04:10PM +0200, Felipe Contreras wrote:
>
>> This is shorter, avoids the burder to think about the format of the
>> configuration file, and git config is already used in other places in
>> the manual.
>
> I seem to recall this coming up several times before, and there being a
> sentiment that it was _good_ to introduce the user to concept of a
> config file. It lets them know that it exists, approximately what the
> syntax looks like, and demystifies what is going on when you type "git
> config" (i.e., it intentionally shows that there is more than way to do
> it).
>
> I don't have a personal preference, but you may want to grep the
> list archives for other discussion.
That's over complicating the user with what should probably be one of
the first things to do. Besides, do Windows users know which is their
home directory?
Maybe a comment like previous git config commands:
If you examine the file .gitconfig in your home directory, you will see this:
------------------------------------------------
...
[user]
name = Your Name Comes Here
email = you@yourdomain.example.com
...
------------------------------------------------
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Markus Heidelberg @ 2009-01-21 19:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Boyd Stephen Smith Jr., Santi Béjar,
Thomas Rast, git, Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901202202370.3586@pacific.mpi-cbg.de>
Johannes Schindelin, 20.01.2009:
> Hi,
>
> On Tue, 20 Jan 2009, Markus Heidelberg wrote:
>
> > Junio C Hamano, 20.01.2009:
> > > None of the existing configuration variables defined use hyphens in
> > > multi-word variable names.
> >
> > Except for diff.suppress-blank-empty
> > Should it be converted or is it intention to reflect GNU diff's option?
>
> Grumble. It's in v1.6.1-rc1~348, so we cannot just go ahead and fix it.
Did I say change it without keeping backward compatibility?
> Ciao,
> Dscho "who loves consistency, and knows new users appreciate it, too"
Me, too.
Markus
^ permalink raw reply
* Merging adjacent deleted lines?
From: Jonathan del Strother @ 2009-01-21 19:20 UTC (permalink / raw)
To: Git Mailing List
Say I have a file that started out with the following content :
line1
line2
line3
line4
I create a branch, which deletes line2. Someone else's branch deletes line 3.
When I merge those two branches, the conflict looks like :
line1
<<<<<<< HEAD:lines
line3
=======
line2
>>>>>>> SomeoneElse:lines
line4
Which in my cursory overview, looked an awful lot like the obvious
merge resolution ought to be
line1
line3
line4
After all - I know I want to delete line 2, and wasn't aware of the
other person deleting line 3.
It was only later that we discovered that the merge was broken and
both lines should have been deleted. Thinking about it, I guess that
the conflict if the other branch _hadn't_ deleted line 3 would have
looked something like
line1
<<<<<<< HEAD:lines
=======
line2
>>>>>>> SomeoneElse:lines
line3
line4
- which wouldn't have resulted in a conflict anyway.
So, it looks like I need to be way more careful when merging
conflicts. Which leads me to - what tools do you use when studying
conflicts like that? git blame seems the obvious one, for getting the
context of each deletion, but it seems like I need to run it once as
git blame HEAD lines, and once as git blame MERGE_HEAD lines. Is
there something a little more integrated for comparing the origin of
each change from both merge branches simultaneously?
Would welcome any thoughts on how you guys approach conflict-resolution
-Jon
^ permalink raw reply
* Re: Deleting remote branch pointed by remote HEAD
From: Felipe Contreras @ 2009-01-21 19:20 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Marc-André Lureau, git
In-Reply-To: <20090121191619.GE21686@coredump.intra.peff.net>
On Wed, Jan 21, 2009 at 9:16 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Jan 21, 2009 at 08:31:50PM +0200, Felipe Contreras wrote:
>
>> Why should we care about the remote HEAD? Isn't that relevant only
>> when cloning to find out the branch to checkout?
>
> You can use the shorthand $foo to refer to refs/remotes/$foo/HEAD. Which
> means, in the default case, you can refer to just "origin" to talk about
> origin's master branch.
>
> But as Daniel noted, that is really about local preference for "what is
> the most interesting branch on the remote". You might want to track what
> the remote sets to HEAD, or you might want to set it individually.
Ah, good to know. But then the message should appear only when doing
something with the $foo branch.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] user-manual: Simplify the user configuration.
From: Jeff King @ 2009-01-21 19:18 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1232564650-3701-1-git-send-email-felipe.contreras@gmail.com>
On Wed, Jan 21, 2009 at 09:04:10PM +0200, Felipe Contreras wrote:
> This is shorter, avoids the burder to think about the format of the
> configuration file, and git config is already used in other places in
> the manual.
I seem to recall this coming up several times before, and there being a
sentiment that it was _good_ to introduce the user to concept of a
config file. It lets them know that it exists, approximately what the
syntax looks like, and demystifies what is going on when you type "git
config" (i.e., it intentionally shows that there is more than way to do
it).
I don't have a personal preference, but you may want to grep the
list archives for other discussion.
-Peff
^ 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