* 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
* 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: 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
* 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: 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
* 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: 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: 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: 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: [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: 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 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: 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
* post-receive-email - does not handle creating a new branch with same HEAD as other branch
From: Jake Goulding @ 2009-01-21 22:12 UTC (permalink / raw)
To: git
Given the simple case of two commits:
A--B
with branches setup like:
master: A
b1: B
If I create a new branch b2 at the same point as b1 from a remote server:
$ git push origin B:b2
The following code will be run in post-receive-email:
git rev-parse --not --branches |
grep -v $(git rev-parse $refname) |
git rev-list --pretty --stdin $newrev
(refname = refs/heads/b2, newrev=B)
The problem occurs because the first rev-parse reports:
^A
^B
^B
And the grep removes lines matching B, leaving:
^A
which causes the eventual rev-list command to be:
git rev-list --pretty ^A B
This problem could be exaggerated if there were a lot of commits between
A and B, which would cause each commit A..B to be reported.
Is there any alternate way to write this command to cause these false
positives to not be reported? I tried to write a version that uses the
ref name instead of the hash, but it did not end up very pretty (and I
don't think it worked...).
Thanks!
-Jake
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Schindelin @ 2009-01-21 22:17 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090121190757.GB21686@coredump.intra.peff.net>
Hi,
On Wed, 21 Jan 2009, Jeff King wrote:
> On Wed, Jan 21, 2009 at 02:26:56AM +0100, Johannes Schindelin wrote:
>
> > Well, in this case, you will find that the "bug" is _at most_ some
> > binaries not being found.
> > [...]
> > (Actually, with my new patch, the may be replaced, but _only_ if
> > necessary, and the same thing would apply as I said earlier: the binary
> > would not be found, or a binary from the PATH would be run without
> > valgrind; but the next runs will not have the problem.)
>
> You can run a random binary from the PATH.
No. You seem to assume that a test script can run all kinds of Git
commands while another, is replacing the symlinks in $GIT_VALGRIND/bin/ at
the same time.
Fact is: every test script will check $GIT_VALGRIND/bin/ for
up-to-dateness first. Before running any Git command.
During that time, races are possible, but non-fatal, because they all try
to do the same thing.
Except, of course, if you replace a script by a builtin _while your test
is running the up-to-date check of $GIT_VALGRIND/bin/_! But I would have
no word of consolation for you in that case.
So, can we agree that every test script tries to keep $GIT_VALGRIND/bin/
up-to-date before the first Git command is called?
Now, you might assume that it is possible that one test-script symlinked
the Git command while another removed it.
But the script that removed the symlink will recreate it right away.
Granted, during that time, the other script could have gone off to call a
Git command in that very brief time span, but keep in mind: it does not
take a long time from rm to ln -s, _and_ the other script would have to go
on to call a Git command _right through that time_.
And you know which command that might be?
Exactly. git init. Which takes a long, long, long time, and where I
really could not care less if it is called from the PATH or not.
Note: this would be only possible if both scripts checked the same name at
the very same time, coming to the very same result that the name needs
symlinking. Unlikely.
Note, too: such a replacing/creating could only take place the very first
time you run valgrind, or when a script was replaced by a builtin. IOW
very, very rarely to begin with.
Now the big question: is this highly, highly unlikely issue relevant?
And I say: no. Because even in that highly, highly, highly unlikely
event, all that will happen is that a git init (which is tested later,
anyway) is not valgrinded.
Besides, if that race would happen _and_ you would see any issues, you'd
run the test again, without parallelization, because you would not be able
to discern what messages belong together from the output of "make -j50
test" anyway.
And the whole issue goes away, because that call will again try to
make GIT_VALGRIND/bin up-to-date, and there will be no chance for a race
this time.
Phew. A lot of time, a lot of braincycles, and a lot of keystrokes wasted
on that subject, don't you think?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] valgrind tests: be super-super paranoid when creating symlinks
From: Johannes Schindelin @ 2009-01-21 22:31 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901212137130.3586@pacific.mpi-cbg.de>
Even if there is only a faint, almost neglible chance that two parallel
tests create the symlinks needed for the valgrind test at the same time,
Peff wrote more than just a couple mails about the issue.
To get rid of that threat^Wthread, use a locking mechanism to make
sure a symlink is only created by one test invocation, and the other
has to wait.
Peff, do you see how much I like you?
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/test-lib.sh | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 6acc6e0..07e657e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -490,8 +490,19 @@ else
make_symlink () {
test -h "$2" &&
test "$1" = "$(readlink "$2")" || {
- rm -f "$2" &&
- ln -s "$1" "$2"
+ # be super paranoid
+ if mkdir "$2".lock
+ then
+ rm -f "$2" &&
+ ln -s "$1" "$2" &&
+ rm -r "$2".lock
+ else
+ while test -d "$2".lock
+ do
+ say "Waiting for lock on $2."
+ sleep 1
+ done
+ fi
}
}
--
1.6.1.442.g112f5
^ permalink raw reply related
* Re: [PATCH] Added giteditor script to show diff while editing commit message.
From: Ted Pavlic @ 2009-01-21 22:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <alpine.DEB.1.00.0901212216310.3586@pacific.mpi-cbg.de>
Thanks for your comments. I've responded below. I just want to
top-respond to your comment that the fundamental problem is that the
diff is in a separate file. In fact, this is the point of the script. I
want to be able to scroll through the diff output independent of the
commit message.
(alternatively, I realize I could do "git commit -v" and then use my
editor's "split window" support, but that wouldn't help me with "stg edit")
> the subject could use some work. For example, I would prefix it with
...
>> 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.
I add --from to my gitsend alias to prevent git send-email from
prompting me for a "From". Is there a way to have git send-email simply
not prompt me for "From"?
> 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.
OK. I noticed plenty of other not-very-useful READMEs in contrib/, and
so I figured it was a pro forma file.
>> +# Find git
>> +[ -z "${GIT}" ]&& GIT="git"
> Yes, I know it is contrib/, but you may want to adopt Git's coding style
> early.
Ok. Switching to test.
> Besides, I find it funny that you want to override git with $GIT.
Isn't it possible that someone has git somewhere else?
>> +# 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.
I don't use emacs, but it was my impression that the "no window" flag
was added to make sure that emacs doesn't fork. That's why "-f" is used
in the vim line.
>> +# 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?
The script generates a new "diff" file that I would rather drop
elsewhere (e.g., in a /tmp directory) rather than here in the current
directory.
However, maybe you're right. After all, stg drops ".stgit-edit.txt" in
the working directory. I suppose I could use gitdir, but I wasn't sure
if it was safe to pollute gitdir.
In the next version, I'll get rid of the temp directory and put the file
here.
>> + # 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.
I don't see what you mean. I am a vi user (exclusively), and this script
works very well for me.
The "-f -o" flags above ensure that gvim will not fork. I'll add "vi" to
the search string that automatically add "-f -o". Will that satisfy you?
At the moment, giteditor works exactly like EDITOR (or VISUAL) for me,
but it opens up a second buffer (split in the bottom window in my case)
with the diff in it. I'm given the opportunity to save.
> 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.
Okay. Using $1 exclusively.
> BTW why on earth do you put every single variable name in curly brackets?
I always thought that was good practice. It prevents ambiguity, and *I*
don't think it's an eyesore.
> Besides all that criticism, there is also a fundamental issue. The diff
> is in a separate file.
That's the point. If I wanted to put the diff in the commit buffer, I
would have used "git commit -v". I think many would like to be able to
scroll through the diff without having to scroll through the commit.
Is there no value in having the diff in a separate file?
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
* Re: [PATCH 1/2] handle color.ui at a central place
From: Markus Heidelberg @ 2009-01-21 22:35 UTC (permalink / raw)
To: Jeff King; +Cc: René Scharfe, Junio C Hamano, git
In-Reply-To: <20090120040448.GA30714@sigill.intra.peff.net>
Jeff King, 20.01.2009:
> On Sun, Jan 18, 2009 at 09:37:15PM +0100, Markus Heidelberg wrote:
>
> > Not sure, if you it has something to do with the following, but I had
> > this in my tree for some days now, waiting for the 2 commits mentioned
> > in the log message to graduate to master, which happend just an hour or
> > so ago.
>
> I think this is probably an improvement, but I had in mind something a
> little more drastic. Right now we keep munging one variable that is our
> current idea of "should we do color" based on multiple config values.
> Then you end up with (best case) this "finalize color config", which is
> a bit ugly, or (worst case) bugs where the value hasn't always been
Yes, I didn't find it to be that great either.
> properly initialized (or finalized).
>
> So I think it makes more sense to record each config value, and then
> check a _function_ that does the right thing. I.e., you end up with
> something like:
>
> [example code snipped]
That would probably be better.
Markus
^ permalink raw reply
* Re: [PATCH 1/2 v2] Add valgrind support in test scripts
From: Johannes Schindelin @ 2009-01-21 22:38 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090121215318.GA9107@sigill.intra.peff.net>
Hi,
On Wed, 21 Jan 2009, Jeff King wrote:
> 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.
A pity. I was already working on this patch:
-- snipsnap --
[PATCH] valgrind tests: provide a "readlink" function for systems which lack it
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/test-lib.sh | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 07e657e..c2199e7 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -487,7 +487,24 @@ then
PATH=$TEST_DIRECTORY/..:$PATH
GIT_EXEC_PATH=$TEST_DIRECTORY/..
else
+ readlink -h 2> /dev/null
+ if test $? = 127
+ then
+ readlink () {
+ ls -l "$1" |
+ sed -e "s/-> \(.*\)$/\1/g"
+ # cannot use s/.* -> //, because of
+ # ln -s "a -> b" "c -> d"
+ }
+ fi
+
make_symlink () {
+ case "$1" in
+ *" -> "*)
+ die "You must be kidding me ($1)."
+ ;;
+ esac
+
test -h "$2" &&
test "$1" = "$(readlink "$2")" || {
# be super paranoid
--
1.6.1.442.g112f5
^ permalink raw reply related
* [EGIT PATCH] Circumvent situations where Eclipse tries to decorate externally linked resources
From: Charles O'Farrell @ 2009-01-21 22:33 UTC (permalink / raw)
To: git
This occurs in one our projects which has an externally linked folder, which
causes the decorator to die on a NPE. Alternatively rsrc.isLinked() could
have been used, but we allow for linked resources to repository files.
Signed-off-by: Charles O'Farrell <charleso@charleso.org>
---
.../internal/decorators/GitResourceDecorator.java | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java
index c3ae52d..f24b1eb 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitResourceDecorator.java
@@ -296,6 +296,12 @@ public void decorate(final Object element, final IDecoration decoration) {
Repository repository = mapped.getRepository();
GitIndex index = repository.getIndex();
String repoRelativePath = mapped.getRepoRelativePath(rsrc);
+
+ if (repoRelativePath == null) {
+ Activator.trace("Cannot decorate linked resource " + rsrc);
+ return;
+ }
+
Tree headTree = repository.mapTree(Constants.HEAD);
TreeEntry blob = headTree!=null ? headTree.findBlobMember(repoRelativePath) : null;
Entry entry = index.getEntry(repoRelativePath);
--
1.6.1.9.g97c34
^ permalink raw reply related
* [PATCH] contrib: A script to show diff in new window while editing commit message.
From: Ted Pavlic @ 2009-01-21 22:45 UTC (permalink / raw)
To: gitster; +Cc: git, Ted Pavlic
In-Reply-To: <4977A2C9.1070502@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" in a separate window. This behavior differs from "git commit
-v" in that the diff can be browsed independently of the commit message
without having to invoke a split window view in an editor.
This script also detects when "stg edit" is being called and uses "stg
show" instead. Hence, it implements a kind of "stg show -v".
This script is highly influenced by the "hgeditor" script distributed
with the Mercurial SCM.
It could be improved by supporting a command-line flag that would mimic
the "git commit -v"-type behavior of opening the diff in the same window
as the commit message. This would extend existing commands like "stg
edit" that do not already have a "-v"-type option.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
This version attempts to answer the concerns brought up by Johannes
Schindlin.
contrib/giteditor/giteditor | 68 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 68 insertions(+), 0 deletions(-)
create mode 100755 contrib/giteditor/giteditor
diff --git a/contrib/giteditor/giteditor b/contrib/giteditor/giteditor
new file mode 100755
index 0000000..501a11c
--- /dev/null
+++ b/contrib/giteditor/giteditor
@@ -0,0 +1,68 @@
+#!/bin/sh
+#
+# Set GIT_EDITOR (or core.editor) to this script to see a diff alongside
+# commit message. This script differs from "git commit -v" in that the
+# diff shows up in a separate buffer. Additionally, this script works
+# with "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.
+
+# Find git
+test -z "${GIT}" && GIT="git"
+
+# Find stg
+test -z "${STG}" && STG="stg"
+
+# Use an editor. To prevent loops, avoid GIT_EDITOR and core.editor.
+EDITOR=${GIT_EDITOR_EDITOR-${VISUAL-${EDITOR-vi}}}
+
+# If we recognize a popular editor, add necessary flags (e.g., to
+# prevent forking)
+case "${EDITOR}" in
+ emacs)
+ EDITOR="${EDITOR} -nw"
+ ;;
+ mvim|gvim|vim|vi)
+ EDITOR="${EDITOR} -f -o"
+ ;;
+esac
+
+# Remove temporary files even if we get interrupted
+DIFFOUTPUT="giteditor.${RANDOM}.${RANDOM}.${RANDOM}.$$.diff"
+cleanup_exit() {
+ rm -f "${DIFFOUTPUT}"
+}
+trap "cleanup_exit" 0 # normal exit
+trap "exit 255" 1 2 3 6 15 # HUP INT QUIT ABRT TERM
+
+# For git, COMMITMSG=COMMIT_EDITMSG
+# For stg, COMMITMSG=.stgit-edit.txt
+# etc.
+COMMITMSG=$(basename "$1")
+case "${COMMITMSG}" in
+ .stgit-edit.txt) # From "stg edit"
+ DIFFCMD="${STG}"
+ DIFFARGS="show"
+ ;;
+ *) # Fall through to "git commit" case
+ DIFFCMD="${GIT}"
+ DIFFARGS="diff --cached"
+ # To focus on files that changed, use:
+ #DIFFARGS="diff --cached --diff-filter=M"
+ ;;
+esac
+
+"${DIFFCMD}" ${DIFFARGS} > ${DIFFOUTPUT}
+
+if test -s "${DIFFOUTPUT}"; then
+ # Diff is non-empty, so edit msg and diff
+ ${EDITOR} "$1" "${DIFFOUTPUT}" || exit $?
+else
+ # Empty diff. Only edit msg
+ ${EDITOR} "$1" || exit $?
+fi
+
+# (recall that DIFFOUTPUT file gets cleaned up by trap above)
+exit
--
1.6.1.213.g28da8
^ permalink raw reply related
* Re: [PATCH] Added giteditor script to show diff while editing commit message.
From: Johannes Schindelin @ 2009-01-21 22:52 UTC (permalink / raw)
To: Ted Pavlic; +Cc: gitster, git
In-Reply-To: <4977A2C9.1070502@tedpavlic.com>
Hi,
On Wed, 21 Jan 2009, Ted Pavlic wrote:
> Thanks for your comments. I've responded below. I just want to
> top-respond to your comment that the fundamental problem is that the
> diff is in a separate file. In fact, this is the point of the script. I
> want to be able to scroll through the diff output independent of the
> commit message.
Once again, note that e.g. vi will not cope with the way you try to
achieve that.
> > > From: Ted Pavlic<ted@tedpavlic.com>
> >
> > From: me
>
> > Besides, I find it funny that you want to override git with $GIT.
>
> Isn't it possible that someone has git somewhere else?
The script is called from within Git. So you can rest assured that "git"
is in the PATH, I guess. Except in configurations where you have a
properly installed GIT_EXEC_PATH, and run Git using an absolute path.
If you want to cater for such a case, sure go ahead :-)
> > > +# 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?
>
> The script generates a new "diff" file that I would rather drop elsewhere
> (e.g., in a /tmp directory) rather than here in the current directory.
Why not .git/? That would be the _natural_ place to put it.
> > > + # 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.
>
> I don't see what you mean. I am a vi user (exclusively), and this script
> works very well for me.
I cannot go back to the commit message when I said ":n" to get to the
diff.
> > Besides all that criticism, there is also a fundamental issue. The
> > diff is in a separate file.
>
> That's the point. If I wanted to put the diff in the commit buffer, I
> would have used "git commit -v". I think many would like to be able to
> scroll through the diff without having to scroll through the commit.
>
> Is there no value in having the diff in a separate file?
In my case, no, for 2 reasons:
- I can always open a new shell (in ssh connections, I use screen) to get
the diff, and even better: I can restrict it to certain files, and I can
use the nice bookmarks "less" provides; dunno if vi would have them.
- My preference is definitely to look at the diff before committing, to be
certain that I did not fsck up. And nothing would annoy me more than to
be in the middle of editing a commit message while I am looking at the
diff and telling myself "that is a stupid mistake, let's fix it" knowing
that the commit will not pick up the fix.
So seeing the diff while composing the commit message is definitely too
late for me.
Ciao,
Dscho
^ permalink raw reply
* GUI and detatched HEAD (was Re: Deleting remote branch pointed by remote HEAD)
From: Daniel Barkalow @ 2009-01-21 22:56 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngnedkm.apk.sitaramc@sitaramc.homelinux.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1564 bytes --]
On Wed, 21 Jan 2009, Sitaram Chamarty wrote:
> On 2009-01-21, Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
>
> > I deleted a remote branch which was pointed by HEAD, this way: "git
> > push origin :master"
> >
> > Then for almost every git command, I get this error: "error:
> > refs/remotes/origin/HEAD points nowhere!".
> >
> > I found this situation non-friendly. Fortunately, I could understand
> > what's going on. But a new user might be confused.
>
> That's a pretty advanced command for a beginner. I have
> people who're only using the GUI (in the presumption that it
> will be less confusing or less powerful or whatever) and
> have managed to right click on a remote branch, choose
> "checkout this branch" and have made commits on it without
> knowing they're not on any branch!
I wonder if the GUI could handle this in a way that users would
understand. This is qualitively like following a link to a spreadsheet in
your web browser, having the browser launch your office suite and load the
spreadsheet off the web; now you're interacting with a spreadsheet where
you obviously can't save to the original location (which is some web site)
and haven't provided a local filename to save as.
I think the right thing would be to show it as "(Untitled)" and have a
prominant button to make a real saved branch out of it. There's nothing
all that strange about having a current "document" that has no filename
yet; the strange thing is that a version control system has this
capability.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] mergetool: respect autocrlf by using checkout-index
From: Charles Bailey @ 2009-01-21 22:57 UTC (permalink / raw)
To: git; +Cc: Hannu Koivisto, Theodore Tso, Charles Bailey
In-Reply-To: <20090121210348.GD9088@mit.edu>
Previously, git mergetool used cat-file which does not perform git to
worktree conversion. This changes mergetool to use git checkout-index
instead which means that the temporary files used for mergetool use the
correct line endings for the platform.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
git-mergetool.sh | 14 +++++++++++---
t/t7610-mergetool.sh | 15 +++++++++++++--
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..a4855d9 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -127,6 +127,14 @@ check_unchanged () {
fi
}
+checkout_staged_file () {
+ tmpfile=$(expr "$(git checkout-index --temp --stage="$1" "$2")" : '\([^ ]*\) ')
+
+ if test $? -eq 0 -a -n "$tmpfile" ; then
+ mv -- "$tmpfile" "$3"
+ fi
+}
+
merge_file () {
MERGED="$1"
@@ -153,9 +161,9 @@ merge_file () {
local_mode=`git ls-files -u -- "$MERGED" | awk '{if ($3==2) print $1;}'`
remote_mode=`git ls-files -u -- "$MERGED" | awk '{if ($3==3) print $1;}'`
- base_present && git cat-file blob ":1:$prefix$MERGED" >"$BASE" 2>/dev/null
- local_present && git cat-file blob ":2:$prefix$MERGED" >"$LOCAL" 2>/dev/null
- remote_present && git cat-file blob ":3:$prefix$MERGED" >"$REMOTE" 2>/dev/null
+ base_present && checkout_staged_file 1 "$prefix$MERGED" "$BASE"
+ local_present && checkout_staged_file 2 "$prefix$MERGED" "$LOCAL"
+ remote_present && checkout_staged_file 3 "$prefix$MERGED" "$REMOTE"
if test -z "$local_mode" -o -z "$remote_mode"; then
echo "Deleted merge conflict for '$MERGED':"
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 09fa5f1..edb6a57 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -34,13 +34,24 @@ test_expect_success 'custom mergetool' '
git config merge.tool mytool &&
git config mergetool.mytool.cmd "cat \"\$REMOTE\" >\"\$MERGED\"" &&
git config mergetool.mytool.trustExitCode true &&
- git checkout branch1 &&
+ git checkout branch1 &&
test_must_fail git merge master >/dev/null 2>&1 &&
( yes "" | git mergetool file1>/dev/null 2>&1 ) &&
( yes "" | git mergetool file2>/dev/null 2>&1 ) &&
test "$(cat file1)" = "master updated" &&
test "$(cat file2)" = "master new" &&
- git commit -m "branch1 resolved with mergetool"
+ git commit -m "branch1 resolved with mergetool"
+'
+
+test_expect_success 'mergetool crlf' '
+ git config core.autocrlf true &&
+ git reset --hard HEAD^
+ test_must_fail git merge master >/dev/null 2>&1 &&
+ ( yes "" | git mergetool file1>/dev/null 2>&1 ) &&
+ ( yes "" | git mergetool file2>/dev/null 2>&1 ) &&
+ test "$(printf x | cat file1 -)" = "$(printf "master updated\r\nx")" &&
+ test "$(printf x | cat file2 -)" = "$(printf "master new\r\nx")" &&
+ git commit -m "branch1 resolved with mergetool - autocrlf"
'
test_done
--
1.6.1.235.gc9d403
^ permalink raw reply related
* Re: [PATCH resend] bash completion: add 'rename' subcommand to git-remote
From: Markus Heidelberg @ 2009-01-21 22:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7veiyxeyzr.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
---
> > I really don't like to bother you again, but compared to the inclusion
> > of the other patches, I guess you have forgotten the third try of this
> > patch.
> >
> > Thus this fourth try :)
>
> I did not mean that I forgot by the above "I seem to have missed".
> Literally none of your three attempts seem to have reached me.
Ah, OK. With "missed" I thought you have just overlooked them.
> I can
> guess what you wrote from the _included_ text in Shawn's response, but
> that is not a good/right place for me to pick up a patch from, is it?
No, it isn't.
next mail:
I just don't get it. The previous mail, I sent three a half hours ago,
didn't reach the list either. Am I doing anything wrong? I looked at
the archives: the first two got to the list, the 3rd (with the Acked-by
from Shawn) and 4th didn't. Now this is the 5th. I can't remember any
such problems with mail delivery.
contrib/completion/git-completion.bash | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 3ce6de2..f2d6cad 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1391,7 +1391,7 @@ _git_config ()
_git_remote ()
{
- local subcommands="add rm show prune update"
+ local subcommands="add rename rm show prune update"
local subcommand="$(__git_find_subcommand "$subcommands")"
if [ -z "$subcommand" ]; then
__gitcomp "$subcommands"
@@ -1399,7 +1399,7 @@ _git_remote ()
fi
case "$subcommand" in
- rm|show|prune)
+ rename|rm|show|prune)
__gitcomp "$(__git_remotes)"
;;
update)
--
1.6.1.227.gad9c0
^ permalink raw reply related
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