* 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
* Re: Planet Git
From: Nanako Shiraishi @ 2009-01-21 23:03 UTC (permalink / raw)
To: webmaster; +Cc: git
In-Reply-To: <a2ce9d792bc2f586e2a1408e573db433.squirrel@webmail.planetgit.org>
Quoting webmaster@planetgit.org:
> Hi everyone,
>
> 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
>
> Regards,
>
> Tiago
When you want to start a new Planet and make it successful, it may not be a bad idea to prime it by adding feeds from well known people near the center of the git universe, and it would have been better if it was done even before going public like this announcement.
You may have to research whose writings are worth including (http://git.or.cz/gitwiki/GitLinks has a few pointers), and you need to probably go to them and ask permission for including their feeds. In other words, I think you should spend some effort on your own, not just setting up a site and throwing a URL to the wild, to make your Planet successful.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Superproject branch tracking?
From: David Aguilar @ 2009-01-21 23:25 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Git Mailing List
In-Reply-To: <49779220.5000900@freescale.com>
On Wed, Jan 21, 2009 at 1:22 PM, Jon Loeliger <jdl@freescale.com> wrote:
> 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
>
Hello
Have you seen Shawn's repo tool?
http://kerneltrap.org/mailarchive/git/2008/10/22/3763214
It might not do *exactly* what you're looking for, but it is magical.
There's also a repo-discuss google group where repo-specific questions
can be addressed.
--
David
^ permalink raw reply
* Re: Planet Git
From: Nanako Shiraishi @ 2009-01-21 23:33 UTC (permalink / raw)
To: Johannes Gilger; +Cc: git
In-Reply-To: <gl80g5$evp$1@ger.gmane.org>
Quoting Johannes Gilger <heipei@hackvalue.de> writes:
> On 2009-01-21, webmaster@planetgit.org <webmaster@planetgit.org> wrote:
>> Just wanted to let everyone know that I've started a Planet for Git
>> users/developers who write about it on their journals/weblogs.
>
> Funny, I just visited it today and didn't know how long this website has
> been idle like that (with only 4 blogs or so). So I was about to write
> you to post it right here, but you did that already.
>
> Although right now I can't see any subscriptions at all :(
There was somebody who used to post a weekly summary of git-related writings from people's blogs to this list. What happened to it? There was not enough interest?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Planet Git
From: Felipe Contreras @ 2009-01-21 23:41 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johannes Gilger, git
In-Reply-To: <20090122083312.6117@nanako3.lavabit.com>
On Thu, Jan 22, 2009 at 1:33 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Johannes Gilger <heipei@hackvalue.de> writes:
>
>> On 2009-01-21, webmaster@planetgit.org <webmaster@planetgit.org> wrote:
>>> Just wanted to let everyone know that I've started a Planet for Git
>>> users/developers who write about it on their journals/weblogs.
>>
>> Funny, I just visited it today and didn't know how long this website has
>> been idle like that (with only 4 blogs or so). So I was about to write
>> you to post it right here, but you did that already.
>>
>> Although right now I can't see any subscriptions at all :(
>
> There was somebody who used to post a weekly summary of git-related writings from people's blogs to this list. What happened to it? There was not enough interest?
You mean the git weekly links, or the editorial kind of thing?
--
Felipe Contreras
^ permalink raw reply
* YourHealth provided here
From: Vivian Covington @ 2009-01-22 0:38 UTC (permalink / raw)
To: git
How To be Healthy Using Safe Products? see there http://umo.happinessspot.com/
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-21 23:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901212259420.3586@pacific.mpi-cbg.de>
On Wed, Jan 21, 2009 at 11:17:35PM +0100, Johannes Schindelin wrote:
> Phew. A lot of time, a lot of braincycles, and a lot of keystrokes wasted
> on that subject, don't you think?
Yes, especially considering my other email that said I had dropped the
subject. ;P
But thank you for discussing it. There is still some part of me that
says "if you have no races, you don't have to worry about analyzing
them." But I think your analysis is correct, and I am willing to let it
go in the name of practicality.
As for braincycles, I don't think they were necessarily wasted. The
point of review is to double-check, and the discussion is how we resolve
(even if we resolve that it is OK as-is). Of course there is such a
thing as useless, annoying pedantry, but I hope this didn't count... :)
-Peff
^ permalink raw reply
* Re: [PATCH] contrib: A script to show diff in new window while editing commit message.
From: Junio C Hamano @ 2009-01-21 23:59 UTC (permalink / raw)
To: Ted Pavlic; +Cc: git
In-Reply-To: <1232577906-868-1-git-send-email-ted@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
> 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.
If a single-buffer operation is an improvement, then I do not see the
point of this script.
* Some people would like two-buffer operation and they may use this
script as their core.editor.
* Other people (including me) would find it very natural to use "\C-x 2"
if they need to look at two places of the same buffer, because that is
what they are used to do when editing a long file every day. They just
use "commit -v" without bothering with this script.
* Yet other people (like Dscho) would find it too late to have a chance
for final review when writing a commit log message anyway, and won't
use either.
And I think choice is good.
Having said that, if the lack of "final chance to review the diff" in some
StGIT subcommand is the real problem you are trying to solve, I think it
is better solved by fixing StGIT. If this script can be used as a
substitute for the real solution, that may be a welcome unintended side
effect, but I do not think you should make it the main selling point of
the script. After all people may not want to use this script when they
are working directly with git, but still would want StGIT fixed.
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Jeff King @ 2009-01-22 0:00 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: René Scharfe, Junio C Hamano, git
In-Reply-To: <200901212335.24727.markus.heidelberg@web.de>
On Wed, Jan 21, 2009 at 11:35:24PM +0100, Markus Heidelberg wrote:
> > 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.
Do you want to work on it, or should it go into the "yeah, right, one
day" section of my todo list?
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Markus Heidelberg @ 2009-01-22 0:13 UTC (permalink / raw)
To: Jeff King; +Cc: René Scharfe, Junio C Hamano, git
In-Reply-To: <20090122000026.GB9668@sigill.intra.peff.net>
Jeff King, 22.01.2009:
> On Wed, Jan 21, 2009 at 11:35:24PM +0100, Markus Heidelberg wrote:
>
> > > 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.
>
> Do you want to work on it, or should it go into the "yeah, right, one
> day" section of my todo list?
Yes, feel free to enlarge your todo list :)
There are some other things that I want to work on before, so better
don't count on me for this. But maybe I'll come up to it, before your
todo list pointer reaches this item, who knows.
Markus
^ permalink raw reply
* Re: [PATCH] [TOPGIT] make creating a commit from a topgit branch a function
From: martin f krafft @ 2009-01-22 0:13 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git, Petr Baudis
In-Reply-To: <20090121101644.GA19052@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.01.21.2116 +1100]:
> > What's the "next commit"?
> oh, sorry. I intended to post my patch that implements `tg export
> --linearize`, but then found a bug and so didn't send it.
>
> You can find it in my pu branch at
>
> git://git.pengutronix.de/git/ukl/topgit.git pu
>
> . It's not yet ready for general use, but I look forward to any
> constructive feedback.
It'll be a while until I can look into this. Until I do, I will only
pull in f4fa614, and we'll pull ae3fe45 when your linearizing patch
is ready.
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"you grabbed my hand and we fell into it,
like a daydream - or a fever."
-- godspeed you black emperor!
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH (topgit)] tg-patch: add support for generating patches against worktree and index
From: martin f krafft @ 2009-01-22 0:28 UTC (permalink / raw)
To: Kirill Smelkov, Git Mailing List
In-Reply-To: <20090121202613.GA5400@roro3.zxlink>
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
also sprach Kirill Smelkov <kirr@landau.phys.spbu.ru> [2009.01.22.0726 +1100]:
> It seems I need to study how to prepare patches with patchy
> comments, or get my hands dirty with `git am` :)
I believe git-send-email --editor can be used to create a lead-in
mail to describe what follows, and send patches in separate messages
in reply to that lead-in.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"welcome to american airlines, sir. here's your avocado - remember to
keep it turned on and with you at all times. please turn your luggage
over to the armadillos for rootling."
-- http://azure.humbug.org.au/~aj/armadillos.txt
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Junio C Hamano @ 2009-01-22 0:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0901212259420.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Fact is: every test script will check $GIT_VALGRIND/bin/ for
> up-to-dateness first. Before running any Git command.
Hmm, is that a good thing in general? Can't makefile rules be arranged in
such a way that one "valgrind-prep" target runs before all the potentially
parallel executions of actual tests begin?
Independent from the above, I suspect that some of the existing tests
cannot run in parallel; I haven't really looked at any of them, but a
server-ish tests to open a local port and test interaction with client
obviously need to either use different ports or serialize. Perhaps we
need a way to mark some tests that cannot be run in parallel even under
"make -j"?
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-22 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vr62wb28h.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 21, 2009 at 04:42:22PM -0800, Junio C Hamano wrote:
> > Fact is: every test script will check $GIT_VALGRIND/bin/ for
> > up-to-dateness first. Before running any Git command.
>
> Hmm, is that a good thing in general? Can't makefile rules be arranged in
> such a way that one "valgrind-prep" target runs before all the potentially
> parallel executions of actual tests begin?
You have to choose either "everybody does this setup, whether they want
--valgrind or not" which is what my original patch did, or doing it
inside test-lib.sh. Because we don't know we want --valgrind until we
get into the individual scripts.
I suppose one could try parsing GIT_TEST_OPTS in the Makefile, but that
seems a bit hack-ish.
But I like putting it into test-lib.sh; yes, it is a little more CPU
time for each script, but it is negligible compared to running the
actual tests (especially since you only pay when running with
--valgrind, which makes the actual tests very expensive). But it is much
easier to be sure it is _correct_ when you run the test, especially if
you tend to run the test script directly.
> Independent from the above, I suspect that some of the existing tests
> cannot run in parallel; I haven't really looked at any of them, but a
> server-ish tests to open a local port and test interaction with client
> obviously need to either use different ports or serialize. Perhaps we
> need a way to mark some tests that cannot be run in parallel even under
> "make -j"?
I think the only culprits are http-push and a few SVN tests. The
http-push test starts a server on a specific port, but because it is the
only script which uses that port, it is fine. It looks like a few
different SVN tests start an httpd server (9115, 9118, and 9120), which
could potentially interact badly. I've never had a problem running with
"-j4", but I don't have svn installed, so I always end up skipping those
tests.
It looks like both the http-push and svn tests are set up to take an
arbitrary port as input. Perhaps the simplest thing would be for each of
the svn tests to pick a different port so that they can be run
simultaneously.
-Peff
^ permalink raw reply
* Re: [PATCH] Added giteditor script to show diff while editing commit message.
From: Ted Pavlic @ 2009-01-22 1:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <alpine.DEB.1.00.0901212343100.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.
> Once again, note that e.g. vi will not cope with the way you try to
> achieve that.
It does for me just fine. In vi, I hit ^W^W and move from commit message
to diff and back. What's the problem with that? In gvim I'm able to
click back and forth.
I have been using this method for a long time with hg, and now I've been
using it with git. This isn't theory --- it's been working in practice
for me. Am I missing something?
> Why not .git/? That would be the _natural_ place to put it.
Why doesn't stg do that? I figured stg would be a well-established
program to pattern behavior off of.
I'll rev-parse the git dir and place the file there.
>>> 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.
vi opens for me and I see two windows. The top window shows the commit
message and the bottom window shows the diff.
I hit ^W^W (or ^W<Down>) and I find myself scrolling around in the diff.
I hit ^W^W again (or ^W<Up>) and I find myself scrolling around in the
commit.
Similarly, gvim lets me mouse around both --- clicking from window to
window.
If you must use ":n", I don't know why you can't use ":prev" to go back. <?>
>> 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.
vi does.
> - 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.
When giving a detailed message bulletting out everything that goes into
a commit, sometimes it's nice to have a very nearby look at the diff.
> So seeing the diff while composing the commit message is definitely too
> late for me.
Nevertheless, the secondary purpose of the contributed script is to show
how GIT_EDITOR can be used to wrap around other editors. (that's the
purpose of Mercurial's distributed "hgeditor" script as well)
--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] contrib: A script to show diff in new window while editing commit message.
From: Ted Pavlic @ 2009-01-22 3:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6x4b48e.fsf@gitster.siamese.dyndns.org>
> * Some people would like two-buffer operation and they may use this
> script as their core.editor.
That's what I do, and evidently that's what enough Mercurial users do to
warrant them putting "hgeditor" in their main distro (not even in the
"contrib" directory). I just figured there must be at least a few other
people out there like me, but maybe I'm wrong. <?>
> * Other people (including me) would find it very natural to use "\C-x 2"
> if they need to look at two places of the same buffer, because that is
> what they are used to do when editing a long file every day. They just
> use "commit -v" without bothering with this script.
As I mention in the script, splitting windows (which is easy to do in
Vim) is another very natural way to go. That being said, not all editors
have terrific split window support. Plus, if you're going to do it
often, it makes sense to wire up your editor to do it for you each time.
> * Yet other people (like Dscho) would find it too late to have a chance
> for final review when writing a commit log message anyway, and won't
> use either.
I'm not using the diff as a code review. I'm using it to help me make
sure my commit message is complete.
> Having said that, if the lack of "final chance to review the diff" in some
> StGIT subcommand is the real problem you are trying to solve, I think it
...
Having the "stg edit" support is just a bonus (for me). The main point
was showing how to use GIT_EDITOR to bring up a split window. As with
Mercurial's hgeditor, part of the point of the script is to demonstrate
how to customize the commit process.
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] contrib: A script to show diff in new window while editing commit message.
From: Ted Pavlic @ 2009-01-22 3:50 UTC (permalink / raw)
To: gitster; +Cc: git, Ted Pavlic
In-Reply-To: <7vy6x4b48e.fsf@gitster.siamese.dyndns.org>
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 edit -v".
This script is highly influenced by the "hgeditor" script distributed
with the Mercurial SCM.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
This new commit responds to some of the issues brought up by Junio C
Hemano (and Johannes Schindelin). In particular, it removes the
paragraph from the commit message discussing how it could be "improved."
Also, this new version uses a "DIFFPIPE" to strip the old commit message
from the top of the "stg show" output so that the "stg edit" behavior
matches the "git commit" behavior.
Finally, this version adds a comment giving an idea for personalizing by
adding the temporary directory creation back in (as a way to prevent
editor backup files from piling up inside .git).
contrib/giteditor/giteditor | 86 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 86 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..5369732
--- /dev/null
+++ b/contrib/giteditor/giteditor
@@ -0,0 +1,86 @@
+#!/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.
+#
+# Possible personalizations:
+#
+# * If your GIT_DIR gets polluted with backup files created by your
+# editor when COMMIT_EDITMSG is saved, then have this script copy
+# COMMIT_EDITMSG (i.e., $1) to a temporary directory and then back to
+# COMMIT_EDITMSG when done. When the script cleans up after itself, it
+# can delete the temporary directory and any leftover backup files.
+# Note that the vim setting 'nobackup' disables saving backup files,
+# and this setting can be set automatically on gitcommit-type files
+# and files matching .stgit-*.txt with an appropriate ftdetect entry.
+
+# Find git
+test -z "${GIT}" && GIT="git"
+
+# Find stg
+test -z "${STG}" && STG="stg"
+
+# Find the nearest git-dir
+GITDIR=$(git rev-parse --git-dir) || exit
+
+# 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="${GITDIR}/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")
+DIFFPIPE="cat"
+case "${COMMITMSG}" in
+ .stgit-edit.txt) # From "stg edit"
+ DIFFCMD="${STG}"
+ DIFFARGS="show"
+ DIFFPIPE="tail +$(wc -l "$1"|awk '{print $1+3}')"
+ ;;
+ *) # 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
+
+# Do the diff and save the result in DIFFOUTPUT
+"${DIFFCMD}" ${DIFFARGS} | ${DIFFPIPE} > ${DIFFOUTPUT}
+
+# If DIFFOUTPUT is nonempty, open it alongside commit message
+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
* What's cooking in git.git (Jan 2009, #05; Wed, 21)
From: Junio C Hamano @ 2009-01-22 3:55 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* js/valgrind (Wed Jan 21 02:36:40 2009 +0100) 2 commits
- valgrind: ignore ldso errors
- Add valgrind support in test scripts
Dscho seems to have some updates out of discussion with Peff.
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
The "spec" did not seem quite well cooked yet, but in the longer term I
think something like this to allow interoperating with other SCMs as if
the other end is a native git repository is a very worthy goal.
----------------------------------------------------------------
[Actively cooking]
* sp/runtime-prefix (Sun Jan 18 13:00:15 2009 +0100) 7 commits
- Windows: Revert to default paths and convert them by
RUNTIME_PREFIX
- Compute prefix at runtime if RUNTIME_PREFIX is set
- Modify setup_path() to only add git_exec_path() to PATH
- Add calls to git_extract_argv0_path() in programs that call
git_config_*
- git_extract_argv0_path(): Move check for valid argv0 from caller
to callee
- Refactor git_set_argv0_path() to git_extract_argv0_path()
- Move computation of absolute paths from Makefile to runtime (in
preparation for RUNTIME_PREFIX)
We should move this to 'next' soon with J6t's blessing.
* lh/submodule-tree-traversal (Mon Jan 12 00:45:55 2009 +0100) 3 commits
+ builtin-ls-tree: enable traversal of submodules
+ archive.c: enable traversal of submodules
+ tree.c: add support for traversal of submodules
I think choosing the submodules to descend into by seeing if the commit
happens to be available is a horribly broken semantics; it needs to be
fixed before this can move to 'master'.
* jk/signal-cleanup (Sun Jan 11 06:36:49 2009 -0500) 3 commits
- pager: do wait_for_pager on signal death
- refactor signal handling for cleanup functions
- chain kill signals for cleanup functions
I think this can move to 'next', as Peff and J6t agreed on how to fix
things up as needed for Windows.
* ks/maint-mailinfo-folded (Tue Jan 13 01:21:04 2009 +0300) 5 commits
- mailinfo: tests for RFC2047 examples
- mailinfo: add explicit test for mails like '<a.u.thor@example.com>
(A U Thor)'
- mailinfo: more smarter removal of rfc822 comments from 'From'
+ mailinfo: 'From:' header should be unfold as well
+ mailinfo: correctly handle multiline 'Subject:' header
As far as I can see, the only remaining thing is a minor fix-up in the
"comment removal" one before we can move this fully to 'next'.
* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
+ git-notes: fix printing of multi-line notes
+ notes: fix core.notesRef documentation
+ Add an expensive test for git-notes
+ Speed up git notes lookup
+ Add a script to edit/inspect notes
+ Introduce commit notes
It would be nice to hear a real world success story using the notes
mechanism before casting this design in stone.
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
Design discussion between Jakub and Sebastien continues.
----------------------------------------------------------------
[Graduated to "master"]
* jk/color-parse (Sat Jan 17 10:38:46 2009 -0500) 2 commits
+ expand --pretty=format color options
+ color: make it easier for non-config to parse color specs
* sb/hook-cleanup (Sat Jan 17 04:02:55 2009 +0100) 5 commits
+ run_hook(): allow more than 9 hook arguments
+ run_hook(): check the executability of the hook before filling
argv
+ api-run-command.txt: talk about run_hook()
+ Move run_hook() from builtin-commit.c into run-command.c (libgit)
+ checkout: don't crash on file checkout before running post-
checkout hook
* rs/ctype (Sat Jan 17 16:50:37 2009 +0100) 4 commits
+ Add is_regex_special()
+ Change NUL char handling of isspecial()
+ Reformat ctype.c
+ Add ctype test
* jf/am-failure-report (Sun Jan 18 19:34:31 2009 -0800) 2 commits
+ git-am: re-fix the diag message printing
+ git-am: Make it easier to see which patch failed
* sg/maint-gitdir-in-subdir (Fri Jan 16 16:37:33 2009 +0100) 1 commit
+ Fix gitdir detection when in subdir of gitdir
This has my "don't do the fullpath if you are directly inside .git"
squashed in, so it should be much safer.
* am/maint-push-doc (Sun Jan 18 15:36:58 2009 +0100) 4 commits
+ Documentation: avoid using undefined parameters
+ Documentation: mention branches rather than heads
+ Documentation: remove a redundant elaboration
+ Documentation: git push repository can also be a remote
* lt/maint-wrap-zlib (Wed Jan 7 19:54:47 2009 -0800) 1 commit
+ Wrap inflate and other zlib routines for better error reporting
Needs the "free our memory upon seeing Z_MEM_ERROR and try again" bits
extracted from Shawn's patch on top of this one.
* kb/am-directory (Wed Jan 14 16:29:59 2009 -0800) 2 commits
+ git-am: fix shell quoting
+ git-am: add --directory=<dir> option
This is "third-time-lucky, perhaps?" resurrection. I do not think I'd be
using this very often, but it originated from a real user request.
* jc/maint-format-patch-o-relative (Mon Jan 12 15:18:02 2009 -0800) 1 commit
+ Teach format-patch to handle output directory relative to cwd
----------------------------------------------------------------
[Will merge to "master" soon]
* kb/lstat-cache (Sun Jan 18 16:14:54 2009 +0100) 5 commits
+ lstat_cache(): introduce clear_lstat_cache() function
+ lstat_cache(): introduce invalidate_lstat_cache() function
+ lstat_cache(): introduce has_dirs_only_path() function
+ lstat_cache(): introduce has_symlink_or_noent_leading_path()
function
+ lstat_cache(): more cache effective symlink/directory detection
* tr/previous-branch (Wed Jan 21 00:37:38 2009 -0800) 10 commits
+ Simplify parsing branch switching events in reflog
+ Introduce for_each_recent_reflog_ent().
+ interpret_nth_last_branch(): plug small memleak
+ Fix reflog parsing for a malformed branch switching entry
+ Fix parsing of @{-1}@{1}
+ interpret_nth_last_branch(): avoid traversing the reflog twice
+ checkout: implement "-" abbreviation, add docs and tests
+ sha1_name: support @{-N} syntax in get_sha1()
+ sha1_name: tweak @{-N} lookup
+ checkout: implement "@{-N}" shortcut name for N-th last branch
* js/maint-all-implies-HEAD (Sat Jan 17 22:27:08 2009 -0800) 2 commits
+ bundle: allow the same ref to be given more than once
+ revision walker: include a detached HEAD in --all
* mh/unify-color (Sun Jan 18 21:39:12 2009 +0100) 2 commits
+ move the color variables to color.c
+ handle color.ui at a central place
* cb/add-pathspec (Wed Jan 14 15:54:35 2009 +0100) 2 commits
+ remove pathspec_match, use match_pathspec instead
+ clean up pathspec matching
* js/diff-color-words (Tue Jan 20 21:46:57 2009 -0600) 8 commits
+ color-words: Support diff.wordregex config option
+ color-words: make regex configurable via attributes
+ color-words: expand docs with precise semantics
+ color-words: enable REG_NEWLINE to help user
+ color-words: take an optional regular expression describing words
+ color-words: change algorithm to allow for 0-character word
boundaries
+ color-words: refactor word splitting and use ALLOC_GROW()
+ Add color_fwrite_lines(), a function coloring each line
individually
* js/patience-diff (Thu Jan 1 17:39:37 2009 +0100) 3 commits
+ bash completions: Add the --patience option
+ Introduce the diff option '--patience'
+ Implement the patience diff algorithm
----------------------------------------------------------------
[On Hold]
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
. revision --simplify-merges: incremental simplification
. revision --simplify-merges: prepare for incremental simplification
* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits
. In add --patch, Handle K,k,J,j slightly more gracefully.
. Add / command in add --patch
. git-add -i/-p: Change prompt separater from slash to comma
* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
. [BROKEN wrt shallow clones] Ignore graft during object transfer
* jc/replace (Fri Oct 31 09:21:39 2008 -0700) 1 commit
. WIP
^ permalink raw reply
* Re: CR codes from git commands
From: Brent Goodrick @ 2009-01-22 4:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901211636340.3586@pacific.mpi-cbg.de>
On Wed, Jan 21, 2009 at 7:38 AM, Johannes Schindelin
> In my test I performed one minute ago, "git pull | cat" did not show any
> CR. Maybe it is the "git" instead of "get" :-)
<snip>
> > Thanks. The fix should be to arrange it so that I can set something so
> > that a bare call such as (but just "git pull"):
> >
> > git pull
> >
> > will emit no CR codes at all, ever, regardless of if there is a tty.
> > Even if it is an env var, but a config setting would be ok too.
>
> I would actually think that it should not be an env var or config setting
> if piping it to "cat" does what you want: if the output is a tty, I think
> it is safe to assume that you want to see the progress, and if you don't,
> "| cat" is not an unreasonable thing to ask for.
You might not be able to see those CR codes from your terminal,
because ... well ... its a terminal which will process them. And if
you can't reproduce it in your environment, you'll have to duplicate
my environment, and at that is well beyond what I would ask anyone to
do. Thanks for your effort in looking into it. If I get annoyed
enough with it, I'll debug the code myself and propose a patch (but
don't hold your breath because I'm still learning this complex tool).
Thanks!
Brent
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #05; Wed, 21)
From: Jeff King @ 2009-01-22 4:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vab9kataf.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 21, 2009 at 07:55:36PM -0800, Junio C Hamano wrote:
> * jk/signal-cleanup (Sun Jan 11 06:36:49 2009 -0500) 3 commits
> - pager: do wait_for_pager on signal death
> - refactor signal handling for cleanup functions
> - chain kill signals for cleanup functions
>
> I think this can move to 'next', as Peff and J6t agreed on how to fix
> things up as needed for Windows.
Please wait for my re-roll, which I'll send in a few minutes.
-Peff
^ permalink raw reply
* Re: CR codes from git commands
From: Daniel Barkalow @ 2009-01-22 4:47 UTC (permalink / raw)
To: Brent Goodrick; +Cc: git
In-Reply-To: <18805.64312.289059.660023@hungover.brentg.com>
On Tue, 20 Jan 2009, Brent Goodrick wrote:
>
> Hi,
>
> I am considering converting from CVS over to using git. I'm currently
> using git version 1.5.6.5 on Debian Linux "testing". One of the first
> things I ran into was having to set PAGER to "cat" to avoid the
> problems when running git from anything other than a terminal. The
> second thing is that "git pull" (and possibly other commands) are
> emitting ^M (octal 013) codes on output, possibly caused by the same
> assumption as causes the problem that is fixed by setting PAGER to
> "cat". This is not a big deal on small repos, but on larger ones I
> actually do want to see status line output (or be given some option to
> see them), so that I can then run "tail -1lf" on the log file that is
> written during a long "git pull" operation.
It's kind of unclear what you're trying to do here. I'm guessing that
you're trying to run git with stdio directed to a /dev/tty device, where
isatty() is true, but which doesn't interpret ASCII control characters as
such. We're not detecting that you can't use a pager on this, and so you
have to use PAGER=cat (which might not be a bad idea for things like
"man", either). With some clues about the environment, we should be able
to do something about this.
You're also trying to send the progress output to a log file that you can
look at the end of (presumably in a more capable terminal). It should be
possible (with an option) to get git to output progress info to a non-tty,
and not use the CRs if the output isn't a tty.
Or do you want to use a tty that can't handle CRs, and get newlines
instead of CRs? (If I'd git on the first computer I used, it would have
printed the progress bar over and over in place and probably torn a hole
in the paper, but I haven't used that one in over 20 years.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Schindelin @ 2009-01-22 5:02 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090122005901.GA10826@sigill.intra.peff.net>
Hi,
On Wed, 21 Jan 2009, Jeff King wrote:
> On Wed, Jan 21, 2009 at 04:42:22PM -0800, Junio C Hamano wrote:
>
> > Independent from the above, I suspect that some of the existing tests
> > cannot run in parallel; I haven't really looked at any of them, but a
> > server-ish tests to open a local port and test interaction with client
> > obviously need to either use different ports or serialize. Perhaps we
> > need a way to mark some tests that cannot be run in parallel even
> > under "make -j"?
>
> I think the only culprits are http-push and a few SVN tests. The
> http-push test starts a server on a specific port, but because it is the
> only script which uses that port, it is fine. It looks like a few
> different SVN tests start an httpd server (9115, 9118, and 9120), which
> could potentially interact badly. I've never had a problem running with
> "-j4", but I don't have svn installed, so I always end up skipping those
> tests.
>
> It looks like both the http-push and svn tests are set up to take an
> arbitrary port as input. Perhaps the simplest thing would be for each of
> the svn tests to pick a different port so that they can be run
> simultaneously.
I _suspect_ that the svn tests already use different ports (or can work
with the same httpd), as I have subversion installed and run with -j50
regularly.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Caleb Cushing @ 2009-01-22 5:07 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200901211949.53432.markus.heidelberg@web.de>
> This looks to me like no merge will happen if --no-prompt/-y or
> mergetool.prompt is set to false. Have you tested with this option or
> have I misread?
sorry haven't tested as I don't use that. will test in the morning...
if it doesn't work will try to get it working.
> Also, I think you've lost some tabs. Mergetool does have some
> inconsistent tabbing but they way I've been aiming towards (which
> matches most, but not all of git-mergetool.sh) is to use tabs == 8
> spaces for indents but to indent each level by 4 spaces. e.g. three
> levels of indent is one tab plus four spaces.
thanks wasn't sure on the indentation, I set tabstop to 4 spaces in
vim so my tabs look like your spaces. I'll correct in the next case.
> It might be quite nice to offer the option of directly using an 'ours'
> or 'theirs' as an alternative to skip for binary files. A bit like
> symlinks are handled in mergetool.
I could look into it... at the same time I don't have a good test case
so I'd rather leave it to someone else.
> I'd like to keep (additionally) the behaviour, that the merge starts
> with just pressing <Enter>. Because what you mostly want to do, when
> using git-mergetool, is actually merging.
I'd thought of that... and I'll see what I can do, although to me it
doesn't matter much.
> This doesn't seem right.
erm.. yeah... I'll fix it
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #05; Wed, 21)
From: Johannes Schindelin @ 2009-01-22 5:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vab9kataf.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 21 Jan 2009, Junio C Hamano wrote:
> * js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
> + git-notes: fix printing of multi-line notes
> + notes: fix core.notesRef documentation
> + Add an expensive test for git-notes
> + Speed up git notes lookup
> + Add a script to edit/inspect notes
> + Introduce commit notes
>
> It would be nice to hear a real world success story using the notes
> mechanism before casting this design in stone.
I'd like to have some profiling done before that. For example, I am still
a bit unsure how the things would perform with a 50-deep delta chain for
a notes tree having 50,000+ notes in it (which I think will not be all
that unreasonable for a medium-sized project that stores bug-tracking
information in the notes).
I have a gut feeling that the performance dip I saw is a direct result of
doing away with the fan-out "subdirectories": remember, originally, I had
a tree structure much like the loose objects in .git/objects/??/, while
Peff convinced me that a flat tree object should be enough.
I could be wrong on that, though.
> * js/patience-diff (Thu Jan 1 17:39:37 2009 +0100) 3 commits
> + bash completions: Add the --patience option
> + Introduce the diff option '--patience'
> + Implement the patience diff algorithm
There is this one issue that my patience's output differs from bzr's.
Since the patience diff algorithm is so lousily documented, I do not know
if it is due to my misunderstanding the algorithm, or due to bzr doing
something clever in addition.
I'd be thankful if somebody could clarify that issue.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #05; Wed, 21)
From: Boyd Stephen Smith Jr. @ 2009-01-22 5:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vab9kataf.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
On Wednesday 21 January 2009, Junio C Hamano <gitster@pobox.com> wrote
about 'What's cooking in git.git (Jan 2009, #05; Wed, 21)':
>* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
> + git-notes: fix printing of multi-line notes
> + notes: fix core.notesRef documentation
> + Add an expensive test for git-notes
> + Speed up git notes lookup
> + Add a script to edit/inspect notes
> + Introduce commit notes
>
>It would be nice to hear a real world success story using the notes
>mechanism before casting this design in stone.
I'll see if I can't try to put this through some paces over the week.
Also, I'd like to see some support for notes in push/fetch, but it could
certainly be added afterwards.
>* js/diff-color-words (Tue Jan 20 21:46:57 2009 -0600) 8 commits
> + color-words: Support diff.wordregex config option
> + color-words: make regex configurable via attributes
> + color-words: expand docs with precise semantics
> + color-words: enable REG_NEWLINE to help user
> + color-words: take an optional regular expression describing words
> + color-words: change algorithm to allow for 0-character word
> boundaries
> + color-words: refactor word splitting and use ALLOC_GROW()
> + Add color_fwrite_lines(), a function coloring each line
> individually
I think my patch in
http://thread.gmane.org/gmane.comp.version-control.git/106567 should be
applied to the top of this. It respells "wordregex" to match existing
uses throughout the repo. Dscho had issues with one hunk, but I think I
addressed them in my follow-up. It looks like 98a4d87b (color-words:
Support diff.wordregex config option) still has the internally-consistent
runtogether spelling that doesn't match other configuration variables etc.
--
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
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