* Re: git diff, git mergetool and CRLF conversion
From: Theodore Tso @ 2009-01-21 21:03 UTC (permalink / raw)
To: Charles Bailey; +Cc: Hannu Koivisto, git
In-Reply-To: <20090121172351.GB21727@hashpling.org>
On Wed, Jan 21, 2009 at 05:23:51PM +0000, Charles Bailey wrote:
> > Is this intended behaviour? I'm using 1.6.1 on Cygwin.
>
> Speaking for mergetool, I believe that it's simply because mergetool
> uses git cat-file which just outputs the raw contents of a blob and
> doesn't do any line ending conversion.
>
> IMHO, I think that it should probably perform the 'convert to working
> tree format' change when preparing the temporary files. I'm not sure
> how best to do that, but perhaps it should be using git checkout-index
> with the --temp option instead of cat-file.
Yes, I agree, that would probably be better.
- Ted
^ permalink raw reply
* Re: [PATCH 1/2 v2] Add valgrind support in test scripts
From: Jeff King @ 2009-01-21 21:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901212137130.3586@pacific.mpi-cbg.de>
On Wed, Jan 21, 2009 at 09:49:14PM +0100, Johannes Schindelin wrote:
> > 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.
Hrm, true. I consider running "make" in the middle of tests and
expecting them to work properly to be a bit crazy, so I guess this is
not a problem in practice.
I'll stop bugging you about race conditions for now, 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).
Actually, I am wrong. There is a stripped-down readlink that has
shipped with FreeBSD (since 4.10) and NetBSD (since 1.6). So while
readlink isn't portable, I think it should generally work on platforms
supported by valgrind.
> Or are you insisting that the patch should be reworked _now_ so that
> GIT_EXEC_PATH _always_ points somewhere else?
No, I'm not insisting. It was merely a suggestion that the patch be
split into two parts so non-valgrind invocations can benefit from this
type of bug checking (and by this type I mean general PATH issues -- I
think we had some problems in the past with invoking dashed forms of
commands which were supposed to be available only via exec-path).
> I hope not, because then you break Windows.
Only if you use the same symlink technique.
-Peff
^ permalink raw reply
* Re: What about allowing multiple hooks?
From: Johannes Schindelin @ 2009-01-21 21:50 UTC (permalink / raw)
To: Anders Waldenborg
Cc: git, Alexander Potashev, Marc Weber, Rogan Dawes, martin f krafft
In-Reply-To: <497793E5.7090107@0x63.nu>
Hi,
On Wed, 21 Jan 2009, Anders Waldenborg wrote:
> Johannes Schindelin wrote:
> > > 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:
>
>
> Because I wanted to be able to do things like this:
>
> git config -add hooks.post-receive.hook \
> "sh hooks/buildbot 192.168.99.9:9989"
You are missing a "-".
> So, the thing I initially wanted to solve was "multiple instances" of
> the same hook.
And why not use a shell function for that?
-- snip --
buildbot () {
echo "Who is so evil and puts a bot into a post-receive hook?" >&2
echo "This function would connect to $* if it were building a bot."
}
buildbot www.google.com
buildbot www.kernel.org
-- snap --
> Then when I found this thread I saw that the richer meta information
> needed to implement multiple hooks with sane semantics could be done
> with the config values.
I think this is technically called an "XY" problem. You ask for a
specific technical solution, while your real problem would be better
solved by other means.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Added giteditor script to show diff while editing commit message.
From: Johannes Schindelin @ 2009-01-21 21:46 UTC (permalink / raw)
To: Ted Pavlic; +Cc: gitster, git
In-Reply-To: <1232570841-25641-1-git-send-email-ted@tedpavlic.com>
Hi,
the subject could use some work. For example, I would prefix it with
"contrib:", and -- imitating other commit messages -- use the imperative
form "Add" instead of the frowned-upon past tense.
On Wed, 21 Jan 2009, ted@tedpavlic.com wrote:
> From: Ted Pavlic <ted@tedpavlic.com>
As this is exactly what your email said in its header, it is redundant
information. Worse, it is information that made me look back to know why
it needs to be there. Distracting.
> 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.
What information does the README add that is not in the script itself?
If there is none, please refrain from adding the README to begin with.
> 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.
Maybe "Set GIT_EDITOR to giteditor if you want to see a diff of what will
be committed in the editor"?
> +# Find git
> +[ -z "${GIT}" ] && GIT="git"
Yes, I know it is contrib/, but you may want to adopt Git's coding style
early.
Besides, I find it funny that you want to override git with $GIT.
> +# 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"
Mhm. Should this not be the user's choice? Some like emacs to start up
in a window.
> +# Remove temporary files even if we get interrupted
> +GITTMP=""
GITTMP= would be completely sufficient. Not to mention the consistency
with Git's shell code.
> +# 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
> +}
Umm. Why? Why do you need a temporary .git directory?
> +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
> +# )
--diff-filter=M
> +
> + cat "$1" > "${GITTMP}/${COMMITMSG}"
> +
> +else
> +
> + # Give us a blank COMMITMSG to edit
> + touch "${GITTMP}/${COMMITMSG}"
Why not just touch it, instead of testing if the file exists first?
> +
> + # Generate the diff
> + "${DIFFCMD}" ${DIFFARGS} >> "${GITTMP}/diff"
> + #touch "${GITTMP}/diff"
Commented out code in a submitted patch?
> +
> +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 $?
vi users will hate you, as you do not give them a chance to edit the
message after having seen the diff.
> +else
> + # Empty diff. Only edit msg
> + ${EDITOR} "${GITTMP}/${COMMITMSG}" || exit $?
> +fi
> +[ -x "${MD5}" ] && (echo "${CHECKSUM}" | ${MD5} -c >/dev/null 2>&1 && exit 13)
git commit will abort anyway if the commit message has not changed. Plus,
it does a better job, as it checks only the non-commented-out text.
BTW why on earth do you put every single variable name in curly brackets?
> +
> +# Commit message changed, so dump it on original message from Git
> +mv "${GITTMP}/${COMMITMSG}" "$1"
And why did you not use "$1" all the time?
> +
> +# (recall that GITTMP directory gets cleaned up by trap above)
> +exit $?
Just writing "exit" is the same in effect, but preferred in Git shell
coding.
Besides all that criticism, there is also a fundamental issue. The diff
is in a separate file.
Instead, I suggest having something like this:
-- snip --
#!/bin/sh
# set GIT_EDITOR or core.editor to this script if you want to see a diff
# instead of the output of "git status".
# filter out the "git status" output (keeping the "On branch" line)
mv "$1" "$1".tmp
grep -v "^# [^O]" < "$1".tmp > "$1"
rm "$1".tmp
# append the diff
case "$1" in
*.stgit-edit.txt)
stg show
;;
*)
git diff --cached
;;
esac | sed -e 's/^/# /' >> "$1"
exec ${VISUAL:-${EDITOR:-vi}} "$1"
-- snap --
Hth,
Dscho
^ permalink raw reply
* Re: Short "git commit $file" syntax fails in the face of a resolved conflict
From: Nathan Yergler @ 2009-01-21 21:46 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Asheesh Laroia, git
In-Reply-To: <49779521.9040208@drmicha.warpmail.net>
Can you elaborate on why doing -i automatically is a bad idea in this
case? [It may really be, I don't pretend to have enough knowledge
about git's internals to make a reasoned argument.] This was
unexpected behavior for me as I'd always experienced "git add path &&
git commit" and "git commit path" as being equivalent and so I assumed
they would work equivalently in this situation.
Nathan
On Wed, Jan 21, 2009 at 1:35 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Asheesh Laroia venit, vidit, dixit 01/21/09 22:00:
>> 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.
>>
>
> You want git commit -i:
>
> -i, --include
> Before making a commit out of staged contents so far, stage
> the contents of paths given on the command line as well.
> This is usually not what you want unless you are concluding a
> conflicted merge.
>
> Without -i, git commit path ignores the index, which would be bad in the
> middle of a merge, which is why git refuses to do so. You may argue for
> git commit to use -i automatically here, but I don't think it's a good idea.
>
> So, out of
> 1) git add path && git commit
> 2) git commit path
> 3) git commit -i path
> only 1) and 3) are always equivalent.
>
> Michael
>
^ permalink raw reply
* Re: Short "git commit $file" syntax fails in the face of a resolved conflict
From: Michael J Gruber @ 2009-01-21 21:35 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: git, nathan
In-Reply-To: <alpine.DEB.2.00.0901211549070.15860@vellum.laroia.net>
Asheesh Laroia venit, vidit, dixit 01/21/09 22:00:
> 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.
>
You want git commit -i:
-i, --include
Before making a commit out of staged contents so far, stage
the contents of paths given on the command line as well.
This is usually not what you want unless you are concluding a
conflicted merge.
Without -i, git commit path ignores the index, which would be bad in the
middle of a merge, which is why git refuses to do so. You may argue for
git commit to use -i automatically here, but I don't think it's a good idea.
So, out of
1) git add path && git commit
2) git commit path
3) git commit -i path
only 1) and 3) are always equivalent.
Michael
^ permalink raw reply
* Re: Planet Git
From: Felipe Contreras @ 2009-01-21 21:32 UTC (permalink / raw)
To: Johannes Gilger; +Cc: git
In-Reply-To: <gl83pe$7o6$1@ger.gmane.org>
On Wed, Jan 21, 2009 at 11:23 PM, Johannes Gilger <heipei@hackvalue.de> wrote:
> On 2009-01-21, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Up until the "send an email to the webmaster with your name", I was game.
>
> Hi Dscho,
>
> not sure what you're talking about, but it's common on planets for
> people to be listed with their name (instead of the strange titles some
> blogs have). Just have a look at two different planets I regularly
> visit:
> http://planet.larrythecow.org/
> http://planet.rwth.org/
>
> Besides, I'm sure that if you use your synonym it's fine too ;)
And that it's probably the default theme and content on the "planet" software.
--
Felipe Contreras
^ permalink raw reply
* Re: What about allowing multiple hooks?
From: Anders Waldenborg @ 2009-01-21 21:30 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Alexander Potashev, Marc Weber, Rogan Dawes, martin f krafft
In-Reply-To: <alpine.DEB.1.00.0901212206430.3586@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
>> 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:
Because I wanted to be able to do things like this:
git config -add hooks.post-receive.hook \
"sh hooks/buildbot 192.168.99.9:9989"
git config -add hooks.post-receive.hook \
"sh hooks/buildbot 192.168.99.9:9988"
So, the thing I initially wanted to solve was "multiple instances" of
the same hook.
Then when I found this thread I saw that the richer meta information
needed to implement multiple hooks with sane semantics could be done
with the config values.
anders
^ permalink raw reply
* Re: Planet Git
From: Johannes Gilger @ 2009-01-21 21:23 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0901212156510.3586@pacific.mpi-cbg.de>
On 2009-01-21, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Up until the "send an email to the webmaster with your name", I was game.
Hi Dscho,
not sure what you're talking about, but it's common on planets for
people to be listed with their name (instead of the strange titles some
blogs have). Just have a look at two different planets I regularly
visit:
http://planet.larrythecow.org/
http://planet.rwth.org/
Besides, I'm sure that if you use your synonym it's fine too ;)
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
* Superproject branch tracking?
From: Jon Loeliger @ 2009-01-21 21:22 UTC (permalink / raw)
To: Git Mailing List
Guys,
Can someone tell me what the current best practice
to have a Git supermodule maintain a branch that is
actively tracking a similarly named branch in all of
the submodules?
That is, I want have a scenario where I would like
the master branch of a super-project to always (or on
demand) reflect the current HEAD of the master branch
in each of the submodules.
Does anyone have a script up their sleeve that I can
use as a hook in the super to notice updates to a submodule
and cause it to scurry around the sub-modules and create
a new (updated) commit in the super?
Thanks,
jdl
^ permalink raw reply
* Re: Planet Git
From: Boyd Stephen Smith Jr. @ 2009-01-21 21:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: webmaster, git
In-Reply-To: <alpine.DEB.1.00.0901212156510.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]
On Wednesday 2009 January 21 14:59:23 Johannes Schindelin wrote:
>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.
Generally "planets" just aggregate existing feeds, they don't provide services
to create the feeds. A feed URL is really just a URL to a RSS-formatted
resource. (Most content management systems, e.g. Drupal or Joomla provide a
number of feed URL for [subsets of] the content; there are also free "weblog"
services that also give you a feed URL.) Hackergotchi is stupid slang for a
small image that can be placed beside your feed items, I'm not entirely sure
what the etymology of it is.
If we wanted to, I suppose we could provide weblog services to developers.
Maybe on git-scm.com or something. I'm just thinking out loud here, though.
I don't even know if there's real interest in something like that. And
personally, I'd rather be writing patches than maintaining a Drupal
installation on devblog.git-scm.com or whatever.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: Simplify the user configuration.
From: Felipe Contreras @ 2009-01-21 21:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wp4e5wn.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 21, 2009 at 10:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.
I agree that it's good that people get familiar with the config
format, and that it should appear earlier in the document, perhaps as
a separate section. However, for new users that just want to get
started any extra burden weighs in the misconception that git is not
user friendly.
I read the comments in both threads Jeff pointed out and I have
comments regarding the argument that it's easy to edit a text file.
It's easy to *change* a text file, not so much to write something by
hand. Although the user would probably just copy-paste the text from
the online manual (changing spaces by a tag in the process) there's a
possibility that the manual is printed.
This brings back my previous question: where is the home directory in
a Windows system?
An idea would be to add an --edit option to git config, so the users
don't need to care about the location of the text file and just do
"git config --global --edit" which would bring the editor. Although
I'm not sure how that would work on Windows since the editor is
probably not properly configured at that point.
Now, *nobody* has replied back the comments of providing both the git
config command and .gitconfig snip. It was mentioned in both threads
and ignored.
Anyone against that?
--
Felipe Contreras
^ permalink raw reply
* 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
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