* git tag -s: TAG_EDITMSG should not be deleted upon failures
From: Christian Jaeger @ 2008-12-03 15:53 UTC (permalink / raw)
To: Git Mailing List
Before I've now set my default signing key id in my ~/.gitconfig, I've
run at least half a dozen times into the case where I'm running "git tag
-s $tagname", carefully preparing a tag message, saving the file &
exiting from the editor, only to be greeted with an error message that
no key could be found for my (deliberately host-specific) email address,
and my message gone. If it would keep the TAG_EDITMSG file (like git
commit seems to be doing with COMMIT_EDITMSG anyway), I could rescue the
message from there. I relentlessly assume that this small change would
also make a handful of other people happier.
Christian.
^ permalink raw reply
* Re: Ad: fast-import problem importing dos format files under cygwin
From: Shawn O. Pearce @ 2008-12-03 16:04 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Sixt, git
In-Reply-To: <51143.194.138.12.144.1228311791.squirrel@artax.karlin.mff.cuni.cz>
Jan Hudec <bulb@ucw.cz> wrote:
> Dne 3 Prosinec 2008, 13:18, Johannes Sixt napsal(a):
> > Jan Hudec schrieb:
> >> On 3 December 2008, 08:51, Jan Hudec wrote:
> >>> Hello folks,
> >>>
> >>> I have been playing with fast-import in cygwin and I have problems
> >>> importing files with CR/LF line-endings. The size in data command is
> >>> calculated including the CRs and than the file is copied binary to the
> >>> fast-import input stream. However fast-import skips the CRs when
> >>> reading,
> >>> overreads by that number of bytes and fails when it tries to read the
> >>> next command from the middle.
> >
> > Do you happen to have core.autocrlf set in some way and could it make a
> > difference for fast-import? I have it unset.
>
> I have it set to false explicitly in global config. Tried with not having
> it set at all and gives the same problem. Since the previous version of
> MSys Git worked for me, I suspect it's somehow cygwin-related.
Huh. So fast-import *never* does auto-CRLF conversion, even if the
property is set. It just doesn't make those calls internally.
It blindly copies data from the input stream into the pack.
No exceptions.
fast-import under-reading near CRs and getting misaligned on its
input indicates that the stdio library has given us a FILE* for stdin
which is converting CRLF pairs into LFs, even within an fread() call.
My guess here is fast-import's stdin is set in text mode, but it
really needs to be in binary mode. fast-import.c never attempts
to correct that when it starts, so on DOS based systems we are
probably totally screwed from the beginning...
--
Shawn.
^ permalink raw reply
* git alias always chdir to top
From: Pete Wyckoff @ 2008-12-03 16:08 UTC (permalink / raw)
To: git
I have a git alias that takes a relative file name argument,
and would like to know from where in the tree it was invoked,
especially if inside a subdirectory of the git tree.
Consider .git/config:
[alias]
pwd = !/bin/pwd
Then a git tree:
/home/me
topdir/
.git/
subdir/
subdir-y.c
topdir-x.c
Then inside /home/me/topdir, all is well:
$ pwd
/home/me/topdir
$ git pwd
/home/me/topdir
But inside /home/me/topdir/subdir, the pwd alias is invoked in the wrong
dir:
$ pwd
/home/me/topdir/subdir
$ git pwd
/home/me/topdir
The implication of this is that I call an alias command like:
$ pwd
/home/me/topdir/subdir
$ git myalias subdir-y.c
myalias: No such file subdir-y.c
It looks like handle_alias() uses setup_git_directory_gently() to
find the .git, which chdir()s up until it gets there. Is there a
way to do this without changing the process current working
directory instead? I could even handle an environment variable
saving the original cwd, but that's ickier.
-- Pete
^ permalink raw reply
* Re: Ad: fast-import problem importing dos format files under cygwin
From: Johannes Schindelin @ 2008-12-03 16:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jan Hudec, Johannes Sixt, git
In-Reply-To: <20081203160446.GY23984@spearce.org>
Hi,
On Wed, 3 Dec 2008, Shawn O. Pearce wrote:
> Jan Hudec <bulb@ucw.cz> wrote:
> > Dne 3 Prosinec 2008, 13:18, Johannes Sixt napsal(a):
> > > Jan Hudec schrieb:
> > >> On 3 December 2008, 08:51, Jan Hudec wrote:
> > >>>
> > >>> I have been playing with fast-import in cygwin and I have problems
> > >>> importing files with CR/LF line-endings. The size in data command
> > >>> is calculated including the CRs and than the file is copied binary
> > >>> to the fast-import input stream. However fast-import skips the CRs
> > >>> when reading, overreads by that number of bytes and fails when it
> > >>> tries to read the next command from the middle.
> > >
> > > Do you happen to have core.autocrlf set in some way and could it
> > > make a difference for fast-import? I have it unset.
> >
> > I have it set to false explicitly in global config. Tried with not
> > having it set at all and gives the same problem. Since the previous
> > version of MSys Git worked for me, I suspect it's somehow
> > cygwin-related.
>
> Huh. So fast-import *never* does auto-CRLF conversion, even if the
> property is set. It just doesn't make those calls internally. It
> blindly copies data from the input stream into the pack. No exceptions.
>
> fast-import under-reading near CRs and getting misaligned on its input
> indicates that the stdio library has given us a FILE* for stdin which is
> converting CRLF pairs into LFs, even within an fread() call.
>
> My guess here is fast-import's stdin is set in text mode, but it really
> needs to be in binary mode. fast-import.c never attempts to correct
> that when it starts, so on DOS based systems we are probably totally
> screwed from the beginning...
I think you need to set the environment variable
CYGWIN=binmode
Hth,
Dscho
^ permalink raw reply
* Re: [RFCv2 1/2] gitweb: add patch view
From: Jakub Narebski @ 2008-12-03 17:08 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <cb7bb73a0812030514u11e10bebue5a1451d54fc3f96@mail.gmail.com>
On Wed, Dec 3, 2008 at 14:14, Giuseppe Bilotta wrote:
> On Wed, Dec 3, 2008 at 2:00 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Wed, 3 Dec 2008, Giuseppe Bilotta wrote:
>>> On Wed, Dec 3, 2008 at 12:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>
>>>> Perhaps this configuration should also be a feature defined in %feature,
>>>> overridable by each repository? If you default it to "disabled" (as any
>>>> new feature typically does), you do not have to yank a random number such
>>>> as 100 out of thin air.
>>>
>>> I thought about it, but then I thought it was way too useful for
>>> single patches to disable the feature a priori. I'd rather make the
>>> default limit much smaller (like the original 16 commits I had in
>>> mind, or even less).
>>
>> Perhaps %feature can be used to configure _maximum_ number of patches
>> in 'patch' / 'format_patch' view (gitweb_get_feature... well, sort of
>> as gitweb_check_feature would work too), rather than checking if it
>> is enabled or disabled?
>
> The way it's implemented in v2, you just need to set $patch_max in
> your local or system config file (e.g. /etc/gitweb.conf). I'm not sure
> about the benefit we would gain in going through %feature.
Ah, I haven't read patch in detail yet.
The (doubtful or not) benefit of going through %feature would be ability
to set limits (with perhaps -1 / <0 / undef / '' meaning: unlimited) on
per repository basis, with no limit for small repository, some limit for
the rest, and no 'patch' view or heavily limited for repository with
large size commits.
Just my 2 cents.
--
Jakub Narebski
Poland
^ permalink raw reply
* [BUG Gitk] Resend: git bisect visualize crash
From: Alejandro Riveira Fernández @ 2008-12-03 17:32 UTC (permalink / raw)
To: git; +Cc: paulus
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]
i sent this already through gmane but i do not get responses
sorry if you see this twice
Please cc i'm not suscribed
---
i'm using ubuntu 8.10 and git bisect visualize is crashing.
Noticed when bisecting the kernel but it is easily reproducible
in git repository as of today
$ git bisect bad
$ git bisect good HEAD~20
$ git bisect visualize (03-12 12:16)
Error in startup script: can't read "notflag": no such variable
while executing
"expr {!$notflag}"
("--not" arm line 2)
invoked from within
"switch -glob -- $arg {
"-d" -
"--date-order" {
set vdatemode($n) 1
# remove from origargs in case we hit an unknown option
set origarg..."
(procedure "parseviewargs" line 21)
invoked from within
"parseviewargs $view $args"
(procedure "start_rev_list" line 27)
invoked from within
"start_rev_list $curview"
(procedure "getcommits" line 5)
invoked from within
"getcommits {}"
(file "/usr/local/bin/gitk" line 10897)
$ git --version
git version 1.6.1.rc1
$
[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Buggy (or undocumented) handling of terminal \r in .gitignore patterns
From: Michael J Gruber @ 2008-12-03 17:42 UTC (permalink / raw)
To: Aaron Harnly; +Cc: git
In-Reply-To: <loom.20081203T152511-351@post.gmane.org>
Aaron Harnly venit, vidit, dixit 03.12.2008 16:46:
> This is with git 1.5.6.3 on Ubuntu and Mac OS X.
>
> Overview: .gitignore patterns ending in \r do not work as expected, apparently
> because the terminal \r is assumed to be part of the newline.
>
> Steps to Reproduce:
> (NB ^M is the control-M sequence, not a literal caret-M)
>
> 1. Create an empty repository.
> 2. Create a file named Icon\r (aka Icon^M).
> 3. Add the following pattern to the .gitignore:
>
> Icon^M
>
> Expected behavior:
>
> The file is ignored.
>
> Actual behavior:
>
> The file is not ignored.
>
> Discussion:
>
> It appears that the parsing of .gitignore files tries to be graceful in allowing
> the file to have CRLF endings, or indeed mixed LF / CRLF endings.
>
> This is well and good, but poses a bit of a problem for ignoring files whose
> name ends in \r. In particular, Mac OS X's icon files are named Icon\r. Yes,
> this is sick and annoying on the part of Apple.
>
> I understand the rationale for this behavior, but it probably should be
> documented somewhere. In the meantime, a workaround that does allow the ignoring
> of these files is the pattern:
>
> Icon^M^M
>
> where again, the terminal \r seems to be ignored as part of the newline, but the
> penultimate \r gets picked up as part of the pattern.
>
> Any thoughts on whether:
> 1. this behavior should be left as it is
> 2. there is actually documentation somewhere that I didn't see
> 3. terminal \r in an otherwise all-LF file should be assumed to be part of the
> pattern
> 4. some other alternative?
5. spank Apple
^ permalink raw reply
* Re: Ad: fast-import problem importing dos format files under cygwin
From: Jan Hudec @ 2008-12-03 18:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0812031718350.28112@intel-tinevez-2-302>
Hi,
On Wed, Dec 03, 2008 at 17:20:54 +0100, Johannes Schindelin wrote:
> Hi,
> On Wed, 3 Dec 2008, Shawn O. Pearce wrote:
> > Jan Hudec <bulb@ucw.cz> wrote:
> > > Dne 3 Prosinec 2008, 13:18, Johannes Sixt napsal(a):
> > > > Jan Hudec schrieb:
> > > >> On 3 December 2008, 08:51, Jan Hudec wrote:
> > > >>>
> > > >>> I have been playing with fast-import in cygwin and I have problems
> > > >>> importing files with CR/LF line-endings. The size in data command
> > > >>> is calculated including the CRs and than the file is copied binary
> > > >>> to the fast-import input stream. However fast-import skips the CRs
> > > >>> when reading, overreads by that number of bytes and fails when it
> > > >>> tries to read the next command from the middle.
> >
> > [...]
> > fast-import under-reading near CRs and getting misaligned on its input
> > indicates that the stdio library has given us a FILE* for stdin which is
> > converting CRLF pairs into LFs, even within an fread() call.
> >
> > My guess here is fast-import's stdin is set in text mode, but it really
> > needs to be in binary mode. fast-import.c never attempts to correct
> > that when it starts, so on DOS based systems we are probably totally
> > screwed from the beginning...
Yes, it does indeed sound so. Strange thing is why it would be that way, when
it does not seem to be the case for any other process (eg. the shell will
complain loudly if I feed it a DOS formatted script). The standard input is
simple shell redirect from a file on a binary-mounted filesystem. I'll do
some more cross-checks tomorrow.
> I think you need to set the environment variable
>
> CYGWIN=binmode
Will try. Thanks.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: Is there a way to control the number of revisions will be saved by git
From: Tzury Bar Yochay @ 2008-12-03 18:20 UTC (permalink / raw)
To: git
In-Reply-To: <2f5ea7490812030301p29e944fw5f59943dc352cd09@mail.gmail.com>
> Why would you want that, by the way?
I was thinking of building some experimental application on top of git
^ permalink raw reply
* Re: Is there a way to control the number of revisions will be saved by git
From: Tzury Bar Yochay @ 2008-12-03 18:23 UTC (permalink / raw)
To: git
In-Reply-To: <2f5ea7490812031020l57ec1a04x257c66549f3dac8a@mail.gmail.com>
On Wed, Dec 3, 2008 at 8:20 PM, Tzury Bar Yochay <tzury.by@gmail.com> wrote:
>> Why would you want that, by the way?
> I was thinking of building some experimental application on top of git
>
Looking at the numbers (of bytes). GIT's efficiency seems to redundant
this option which was a result of my concern about disk space usage.
GIT creators are magicians!
^ permalink raw reply
* [StGit PATCH] mail: add some commonly used tags to --auto
From: Dan Williams @ 2008-12-03 18:51 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
stgit/commands/mail.py | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index 72d0133..2dd88c3 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -283,8 +283,17 @@ def __get_signers_list(msg):
acked-by lines in the message.
"""
addr_list = []
-
- r = re.compile('^(signed-off-by|acked-by|cc):\s+(.+)$', re.I)
+ tags = '%s|%s|%s|%s|%s|%s|%s' % (
+ 'signed-off-by',
+ 'acked-by',
+ 'cc',
+ 'reviewed-by',
+ 'reported-by',
+ 'tested-by',
+ 'reported-and-tested-by')
+ regex = '^(%s):\s+(.+)$' % tags
+
+ r = re.compile(regex, re.I)
for line in msg.split('\n'):
m = r.match(line)
if m:
^ permalink raw reply related
* Re: git-p4 submit, Can't clobber writable file
From: Gary Yang @ 2008-12-03 19:06 UTC (permalink / raw)
To: Arafangion; +Cc: Jing Xue, git
In-Reply-To: <1228302466.23167.1.camel@therock.nsw.bigpond.net.au>
Arafangion,
I got email from Jing and I solved the problem. The doc should clearly state that we need a separated P4 working dir in order to make git p4 submit work. Many thanks to Jing.
Gary
--- On Wed, 12/3/08, Arafangion <thestar@fussycoder.id.au> wrote:
> From: Arafangion <thestar@fussycoder.id.au>
> Subject: Re: git-p4 submit, Can't clobber writable file
> To: garyyang6@yahoo.com
> Cc: "Jing Xue" <jingxue@digizenstudio.com>, git@vger.kernel.org
> Date: Wednesday, December 3, 2008, 3:07 AM
> I would argue that's a bug with git-p4, however that is
> a warning given
> by perforce, thus, you should be able to work around it by
> changing the
> clientspec, change the clientspec so that it will clobber
> such files,
> you will need to refer to the perforce docs for info about
> that.
>
> On Tue, 2008-12-02 at 22:04 -0800, Gary Yang wrote:
> > So, I have to keep two copies of source tree at my
> home directory. One is for Perforce build_scripts workspace,
> another is for Git build_scripts.git. I normally work at
> build_scripts.git. But, when I need to submit changes to
> Perforce, I have to copy changed code from build_scripts.git
> to build_scripts. Then, p4 submit code into Perforce. Is
> this the only way of using git-p4?
> > Note: I cannot use git-p4 submit at build_scripts. It
> claims "Cannot clobber writable file". Is it a bug
> of git-p4 or the instruction is not correct?
> >
> >
> > --- On Tue, 12/2/08, Jing Xue
> <jingxue@digizenstudio.com> wrote:
> >
> > > From: Jing Xue <jingxue@digizenstudio.com>
> > > Subject: Re: git-p4 submit, Can't clobber
> writable file
> > > To: "Gary Yang"
> <garyyang6@yahoo.com>
> > > Cc: git@vger.kernel.org
> > > Date: Tuesday, December 2, 2008, 7:07 PM
> > > On Tue, Dec 02, 2008 at 02:30:51PM -0800, Gary
> Yang wrote:
> > > >
> > > > I followed the instructions at
> > >
> http://modular.math.washington.edu/home/mhansen/git-1.5.5.1/contrib/fast-import/git-p4.txt
> > > >
> > > > But, I am not able to git-p4 submit. Any
> idea?
> > > >
> > > > git-p4 clone //build/scripts build_scripts
> > > > cd build_scripts
> > > > vi foo.h
> > > > git commit foo.h
> > > > git-p4 rebase
> > > > git-p4 submit
> > > >
> > > > from sets import Set;
> > > > Perforce checkout for depot path
> //build/scripts/
> > > located at /home/gyang/workspace/build_scripts/
> > > > Syncronizing p4 checkout...
> > > > //build/scripts/foo.h#1 - added as
> > > /home/gyang/workspace/build_scripts/foo.h
> > > > Can't clobber writable file
> > > /home/gyang/workspace/build_scripts/foo.h
> > > > //build/scripts/foo.c#1 - added as
> > > /home/gyang/workspace/build_scripts/foo.c
> > > > Can't clobber writable file
> > > /user/home/gyang/workspace/build_scripts/foo.c
> > > > ......
> > > > command failed: p4 sync ...
> > >
> > > You might want to clone to a git working dir
> different than
> > > the p4
> > > working dir.
> > >
> > > For instance, if your p4 workspace has the
> working dir set
> > > to
> > > build_scripts/, try 'git p4 clone
> //build/scripts
> > > build_scripts.git'.
> > >
> > > You would then normally work under
> build_scripts.git/.
> > > build_scripts/
> > > would only be used by git-p4 at submission time.
> > >
> > > Cheers.
> > > --
> > > Jing Xue
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line
> "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line
> "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [StGit PATCH] fix export -s
From: Dan Williams @ 2008-12-03 19:18 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
Resolves:
stg export -s `stg top`
Traceback (most recent call last):
File "/usr/local/lib/python2.5/site-packages/stgit/main.py", line 152, in _main
ret = command.func(parser, options, args)
File "/usr/local/lib/python2.5/site-packages/stgit/commands/export.py", line 169, in func
f = sys.stdout
NameError: global name 'sys' is not defined
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
stgit/commands/export.py | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/export.py b/stgit/commands/export.py
index dfdcea1..1236b01 100644
--- a/stgit/commands/export.py
+++ b/stgit/commands/export.py
@@ -19,6 +19,7 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
"""
import os
+import sys
from stgit.argparse import opt
from stgit.commands import common
from stgit import argparse, git, templates
^ permalink raw reply related
* Re: Problems with EGit
From: Robin Rosenberg @ 2008-12-03 19:21 UTC (permalink / raw)
To: Bastian Flinspach; +Cc: git
In-Reply-To: <4936689B.1030903@gerina.com>
onsdag 03 december 2008 12:08:11 skrev Bastian Flinspach:
Hi Bastian,
> When i try to commit changes via the command line, everything works fine
> (well, except for me not being able to use my keyboard right for
> entering the commit message, but thats probably not important because i
> want to use EGit anyways).
> Eclipse recognizes the repository and also displays changes i make. When
> trying to commit, however, i get a permission denied error.
>
> So, this is basically where i am stuck. What can be the problem and what
> would be a solution? I assume, that i might have something to do with
> Linux users and privileges, but i am not yet versed enough to identify
> the problem on my own.
If Git does not have permission problems, neither should EGit, I think, In the
workspace there is a file called .metadata/.log that you can inspect. See
if you can find anything interesting, i.e. a seemingly relevant stack trace or
other error message. The file can be quite large so try to cut it down.
> Please keep in mind, that i am a complete beginner with these topics
> when answering.
We all started at the beginning.
-- robin
^ permalink raw reply
* Re: Problems with EGit
From: Robin Rosenberg @ 2008-12-03 19:45 UTC (permalink / raw)
To: Bastian Flinspach; +Cc: git
In-Reply-To: <200812032021.57901.robin.rosenberg.lists@dewire.com>
onsdag 03 december 2008 20:21:57 skrev Robin Rosenberg:
> onsdag 03 december 2008 12:08:11 skrev Bastian Flinspach:
>
> Hi Bastian,
>
> > When i try to commit changes via the command line, everything works fine
> > (well, except for me not being able to use my keyboard right for
> > entering the commit message, but thats probably not important because i
> > want to use EGit anyways).
> > Eclipse recognizes the repository and also displays changes i make. When
> > trying to commit, however, i get a permission denied error.
> >
> > So, this is basically where i am stuck. What can be the problem and what
> > would be a solution? I assume, that i might have something to do with
> > Linux users and privileges, but i am not yet versed enough to identify
> > the problem on my own.
>
> If Git does not have permission problems, neither should EGit, I think, In the
> workspace there is a file called .metadata/.log that you can inspect. See
> if you can find anything interesting, i.e. a seemingly relevant stack trace or
> other error message. The file can be quite large so try to cut it down.
Starting eclipse from a shell, may yield even more information.
-- robin
^ permalink raw reply
* Re: [PATCH] git-svn: Make branch use correct svn-remote
From: Junio C Hamano @ 2008-12-03 20:06 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List, Eric Wong, Deskin Miller
In-Reply-To: <49365259.5090803@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Patch coming. (Sorry I always forget the ccs with send-email.)
Thanks, indeed my environment has svn 1.4.2 installed and Deskin's patch
with your patch squashed in makes everything happy again.
^ permalink raw reply
* Re: summaries in git add --patch[PATCH 1/2]
From: William Pursell @ 2008-12-03 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskp6j95x.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> One thing I will not do after such a discussion, unless I am really really
> interested in having the new feature personally myself, is to go back to
> the discussion thread and assemble the pieces together to make the final
> series of patches for inclusion. The responsibility for doing that lies
> on the original contributor.
>
That is a perfectly reasonable policy, and I did not intend
to suggest that you should do that work. My apologies if
it seemed that way. Here is the first of 2 patches to
implement the 'g' command. I believe it is complete, but
I am not much for user interface. It works for me, but it
could be improved upon. (For example, I took your suggestion
and disallowed 'g' when there is only one hunk, but the
behavior feels clunky, although it is similar to an invalid
k/j entry.)
From de169b0062ae21f085d1309b4dd7da369029ae7d Mon Sep 17 00:00:00 2001
From: William Pursell <bill.pursell@gmail.com>
Date: Wed, 3 Dec 2008 20:25:31 +0000
Subject: [PATCH 1/2] Add subroutine to display one-line summary of hunks.
This commit implements a rather simple-minded mechanism
to display a one-line summary of the hunks in an array ref.
The display consists of the line numbers and the first
changed line, truncated to 80 characters. 20 lines are
displayed at a time, and the index of the first undisplayed
line is returned, allowing the caller to display more if
desired. (The 20 and 80 should be made configurable.)
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 39 +++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..daf8d5d 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -836,6 +836,45 @@ sub patch_update_cmd {
}
}
+# Generate a one line summary of a hunk.
+sub summarize_hunk {
+ my $rhunk = shift;
+ my $summary = $rhunk->{TEXT}[0];
+
+ # Keep the line numbers, discard extra context.
+ $summary =~ s/(@@.*@@).*/$1 /s;
+
+ # Add some user context. (Just take first changed line.)
+ for my $line (@{$rhunk->{TEXT}}) {
+ if ($line =~ m/^[+-]/) {
+ $summary .= $line;
+ last;
+ }
+ }
+
+ return substr ($summary, 0, 80);
+}
+
+
+# Print a one-line summary of each hunk in the array ref in
+# the first argument, starting wih the index in the 2nd.
+sub display_hunks {
+ my ($hunks, $i) = @_;
+ my $ctr = 0;
+ $i = 0 if not $i;
+ for (; $i < @$hunks && $ctr < 20; $i++, $ctr++) {
+ my $status = " ";
+ if (defined $hunks->[$i]{USE}) {
+ $status = $hunks->[$i]{USE} ? "+" : "-";
+ }
+ printf "%s%2d: %s",
+ $status,
+ $i + 1,
+ summarize_hunk ($hunks->[$i]);
+ }
+ return $i;
+}
+
sub patch_update_file {
my ($ix, $num);
my $path = shift;
--
1.6.1.rc1.37.g83daf.dirty
--
William Pursell
^ permalink raw reply related
* Re: summaries in git add --patch[PATCH 2/2]
From: William Pursell @ 2008-12-03 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskp6j95x.fsf@gitster.siamese.dyndns.org>
From 57b5eab3f64a40ebe9aca122b5c6db1ab5c26116 Mon Sep 17 00:00:00 2001
From: William Pursell <bill.pursell@gmail.com>
Date: Wed, 3 Dec 2008 20:26:36 +0000
Subject: [PATCH 2/2] Implemented 'g' command to goto a hunk.
When a minor change is made while the working directory
is in a bit of a mess (and the user should have done a
stash before making the minor edit, but didn't) it is
somewhat difficult to wade through all of the hunks using
git add --patch. This allows one to jump to the hunk
that needs to be staged without having to respond 'n' to
each preceding hunk.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index daf8d5d..98ce8e3 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -800,6 +800,7 @@ y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks in the file
d - do not stage this hunk nor any of the remaining hunks in the file
+g - select a hunk to goto
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
@@ -943,6 +944,9 @@ sub patch_update_file {
if ($ix < $num - 1) {
$other .= '/J';
}
+ if ($num > 1) {
+ $other .= '/g';
+ }
for ($i = 0; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
$undecided = 1;
@@ -976,6 +980,27 @@ sub patch_update_file {
}
next;
}
+ elsif ($other =~ 'g' && $line =~ /^g(.*)/) {
+ my $response = $1;
+ my $i = 0;
+ chomp $response;
+ while (not $response) {
+ my $extra = "";
+ $i = display_hunks (\@hunk, $i);
+ $extra = "(<ret> to see more): " if ($i != $num);
+ print "goto which hunk? $extra";
+ $response = <STDIN>;
+ chomp $response;
+ }
+ if ($response !~ /^\s*\d+$/) {
+ print STDERR "Invalid number: '$response'\n";
+ } elsif (0 < $response && $response <= $num) {
+ $ix = $response - 1;
+ } else {
+ print STDERR "Sorry, only $num hunks available.\n";
+ }
+ next;
+ }
elsif ($line =~ /^d/i) {
while ($ix < $num) {
if (!defined $hunk[$ix]{USE}) {
--
1.6.1.rc1.37.g83daf.dirty
--
William Pursell
^ permalink raw reply related
* Re: [PATCH] git-svn: Make branch use correct svn-remote
From: Deskin Miller @ 2008-12-03 20:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Git Mailing List, Eric Wong
In-Reply-To: <7v1vwpdnwy.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 03, 2008 at 12:06:05PM -0800, Junio C Hamano wrote:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
> > Patch coming. (Sorry I always forget the ccs with send-email.)
>
> Thanks, indeed my environment has svn 1.4.2 installed and Deskin's patch
> with your patch squashed in makes everything happy again.
Ah, curse my trusting svn to work the same between versions, and not
testing on 1.4. Thanks for the quick fix, Michael.
Deskin Miller
^ permalink raw reply
* Re: [RFCv2 1/2] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-03 20:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <200812031808.01916.jnareb@gmail.com>
On Wed, Dec 3, 2008 at 6:08 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Wed, Dec 3, 2008 at 14:14, Giuseppe Bilotta wrote:
>>
>> The way it's implemented in v2, you just need to set $patch_max in
>> your local or system config file (e.g. /etc/gitweb.conf). I'm not sure
>> about the benefit we would gain in going through %feature.
>
> Ah, I haven't read patch in detail yet.
>
> The (doubtful or not) benefit of going through %feature would be ability
> to set limits (with perhaps -1 / <0 / undef / '' meaning: unlimited) on
> per repository basis, with no limit for small repository, some limit for
> the rest, and no 'patch' view or heavily limited for repository with
> large size commits.
Hm. I'm not entirely sure it would be used at all, but I think this
could be done. Something like the following:
* perl false meaning: feature disabled
* > 0 maximum number of patches
* does Perl have an 'infinity' value? if not, we can use <0 to mean unlimited
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* gitk: 'show origin of this line' barfs if gitk run in subdir
From: Mark Burton @ 2008-12-03 20:51 UTC (permalink / raw)
To: Git Mailing List; +Cc: Paul Mackerras
Hi,
I was just trying out the new gitk feature that shows you the origin of a
selected line in the diff pane and found that it doesn't work right if
gitk is not started in the top-level work directory - i.e. if you are
in a subdir it pops up an error message of this form:
Error running git blame: fatal: no such path $path in $sha1
I guess it needs something like subdir-depth number of ../ prepended to
the front of the pathname to make the blame succeed.
I could try and fix this but I am sure that others who understand
the sources of gitk/git-blame/git can do it much quicker than me.
Cheers,
Mark
^ permalink raw reply
* Re: [PATCH] Implement rebase -q to fix pull --rebase -q
From: Junio C Hamano @ 2008-12-03 21:14 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git
In-Reply-To: <4ac8254d0812030035n52fde4b3s29c0f525e175f123@mail.gmail.com>
"Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
> On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Ahh, ok, if this is for cron jobs, then it is understandable that:
>>
>> (1) You may want a successful "git pull" or "git pull --rebase" to be
>> absolutely silent about what it did; and
>>
>> (2) A failed "git pull" and "git pull --rebase" that produces information
>> other than the fact it failed would not help you, the receiver of a
>> cron job report, very much. You would go to the repository when it
>> fails, reset the mess away, and then do the pull or pull-rebase
>> yourself manually anyway.
>>
>> If that is the motivation behind the series, I think you would really want
>> to squelch output from "format-patch | am -3" pipeline.
>
> You mean I should follow this path and produce a patch series instead?
Not necessarily. It is entirely up to you.
An important point at this point is that the patch as submitted, without
such a change, will not be useful to achieve the goal (1) above, because
it will still be chatty.
>> would be driving "git pull" from a cron job. IOW, you probably would want
>> something like "--really-quiet" mode.
>
> Yeah, it gets messy and in the current codebase. I am also not sure whether
> the effort/benefit ratio is good enough.
I doubt "the current codebase" has more downside than upside as you seem
to imply. The way rebase uses layered set of other commands keeps the
door open to spread the benefits around. If you squelch format-patch, you
would help people who would want to drive it from their cron job (perhaps
they are on dial-up and they would rather batch things up than running
format-patch and send-email from their post-receive hook). If you squelch
am, you would help people who use it as a part of their mailing list
scanning software that runs unattended. Of course, you could choose to
squelch the "format-patch | am -3" pipeline in one go by redirecting the
entire pipe to somewhere, instead of giving individual commands --quiet
option. If you did so, obviously the benefits won't be spread to users of
these underlying commands.
But I do not think squelching of these individual commands such as
format-patch, am, and pull are so useful in the larger picture in the
context of scripting; see below.
>> I would write such a cron-job script to capture the log and send it only
>> upon failure from the underlying command if I were doing this myself,
>> though.
>
> This is the way I do it now and I'm surprised I found no other simple way
> than writing a wrapper script for it. At least not with vixie-cron.
Actually I am not so surprised.
A cron job that contains a git pull most likely needs to be a script that
wants to do many other things anyway, such as chdir into the target
repository, make sure nobody (including yourself) did not by mistake went
into the repository and made local changes that may interfere with the
pull and if so abort, perform the pull, noticing its exit status, produce
the error report and exit if pull fails, validate each new commits the
pull brought in against some in-house coding standard, run a build test
(perhaps "make test") if pull succeeded, noticing its exit status, produce
the error report and exit if the build fails, install the build result if
build succeeded, and so on. Individual steps such as "git pull" and "make
install" are only small self-contained building blocks in such a workflow,
and it is not unusual for such a script to redirect output from the
building blocks it uses and produce a summarized report at the very end of
the run using the redirected output, while emitting messages on its own.
In such an arrangement, having "a bit quieter than usual" option in the
underlying command, which would be what we would want for these primarily
interactive commands, is not very useful anyway, because the "quieter"
output mode may drop some information you might want to include in the
fuller report when something goes wrong, and filtering such "a bit
quieter" output takes as much effort as filtering the output from the
normal mode when there is nothing noteworthy to report and your script
wants to squelch the output entirely.
^ permalink raw reply
* Re: [PATCH] gitweb: Fix handling of non-ASCII characters in inserted HTML files
From: Junio C Hamano @ 2008-12-03 21:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Tatsuki Sugiura, Gerrit Pape, Recai Oktas
In-Reply-To: <200812031121.43606.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> With "close $fd" removed the patch is correct (and patches t9500*).
Yeah, it passes that test here, too. Let's unleash it to 'master' and in
an unlikely case where it still has bugs we know which commit to revert
;-).
Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: Optional grouping of projects by category
From: Junio C Hamano @ 2008-12-03 21:14 UTC (permalink / raw)
To: Jakub Narebski
Cc: Sebastien Cevey, git, Petr Baudis, Gustavo Sverzut Barbieri
In-Reply-To: <200812030036.13562.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Tue, 2 Dec 2008, Sebastien Cevey wrote:
> ...
>> I submitted a previous version of this patch on July 27, but was told
>> to wait for the end of the feature freeze. I submitted it again on
>> September 5, but didn't get any reply. Hope to be luckier this time!
>
> Unfortunately it looks like you hit the edge of feature freeze again.
Freeze for 1.6.1 by itself does not have to stop you or anybody to review
the patch and Ack for queuing for 'next' ;-)
^ permalink raw reply
* Re: more merge strategies : feature request
From: Nanako Shiraishi @ 2008-12-03 21:27 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Caleb Cushing, git
In-Reply-To: <ee2a733e0812021707i82049eai866035aef3386264@mail.gmail.com>
Quoting "Leo Razoumov" <slonik.az@gmail.com>:
> On 12/2/08, Caleb Cushing <xenoterracide@gmail.com> wrote:
>> > I guess that "no-overwrite" can be achieved by
>> >
>> > git merge -s ours --no-commit
>>
>> no it doesn't. which is why I called it a bad name. no-overwrite would
>> still add new lines to the file not in ours (and no-commit isn't
>> needed in that case) it just wouldn't overwrite conflicting lines, my
>> understanding of ours is that it will keep the files as is.
Isn't what Caleb wants "-X ours/theirs" per-hunk option for merge strategy backends?
It was discussed several months ago on the list and was rejected. For details you can start here:
http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89021
I still think the patch in the above link was reasonable, but the thread was distracted into discussing minor syntactical details of how the option gets passed to the backend, and the rest of the discussion to decide if it makes sense to add such a feature was unfortunately lost in the noise and never concluded.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ 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