* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Mark Wooding @ 2006-03-02 15:18 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0603020618q3b205cdeuabc7e204044cca5b@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> wrote:
> AFAIK, windows has only one argument, returned by GetCommandLine?
This is true, but there's a standard quoting convention which (in
particular) Microsoft's C library uses to split the single argument back
into an argv. The spawn* functions quote; the C library startup stuff
unquotes and splits.
The actual quoting convention is /horrible/. I had to implement the
darned thing once. See
http://sources.redhat.com/ml/cygwin/1999-08/msg00701.html
for the details.
-- [mdw]
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Christopher Faylor @ 2006-03-02 15:00 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0603020610q41d0ec98x80d112b7daa179fa@mail.gmail.com>
On Thu, Mar 02, 2006 at 03:10:30PM +0100, Alex Riesen wrote:
>Christopher, I'm terribly sorry for the long delays,
>but that is something I can't change at this moment.
>
>On 2/26/06, Christopher Faylor <me@cgf.cx> wrote:
>> >>>It's not activestate perl actually. It's only one platform it also
>> >>>_has_ to support. Is it worth supporting Windows?
>> >>
>> >>With or without cygwin? With cygwin, I'd say "yes, unless it makes
>> >>things terribly difficult to maintain and so long as we don't take
>> >>performance hits on unices". Without cygwin, I'd say "What? It runs
>> >>on windows?".
>> >
>> >There not much difference with or without cygwin. The penalties of
>> >doing any kind of support for it will pile up (as they started to do
>> >with pipes). Someday we'll have to start dropping features on Windows
>> >or restrict them beyond their usefullness. The fork emulation in
>> >cygwin isn't perfect,
>>
>> If the speed of cygwin's fork is an issue then I'd previously suggested
>> using spawn*. The spawn family of functions were designed to emulate
>> Windows functions of the same name. They start a new process without
>> the requirement of forking.
>
>The effort of porting git to spawn-like interface has already started,
>so there's no much left to say about the fork's speed...
>
>> >signals do not work reliably (if at all),
>>
>> I'm not sure if you're mixing cygwin with windows here but if signals do
>> not work reliably in Cygwin then that is something that we'd like to
>> know about. Signals *obviously* have to work fairly well for programs
>> like ssh, bash, and X to work, however.
>
>That's not enough.
>Try interrupting busy processes. Like "git pull", "git clone" or make.
Are you saying that typing CTRL-C doesn't work when you use "git pull"?
If so, give me a real bug report that I can look into. I interrupt
"busy" processes on cygwin all of the time so I'm not going to spend a
few hours typing "git pull" on my system only to find out that you are
talking about an environment that uses ActiveState perl on Windows 95
using Netware.
If you are reporting a problem you need to provide details.
>> Native Windows, OTOH, hardly has any signals at all and deals with
>> signals in a way that is only vaguely like linux.
>
>That makes the rest of installed system kind of useless in cygwin
>environment. After interrupting a build process, which uses java
>(don't ask) only make stops. The rest of the process runs happily
>away.
This sounds like a java bug which is entirely unrelated to git.
>Now, I know that windows has no signals at all and nothing which
>even closely resembles them.
Actually, Windows does understand CTRL-C and any native windows console
program should honor CTRL-C in a manner similar to UNIX, i.e., if the
program doesn't trap SIGINT with 'signal()', it will cause the program
to terminate. There are also other mechanisms for a native windows
program to deal with CTRL-C so this really shouldn't be an issue for
any well-written program.
>I wont be pressing anyone to implement them in windows, having the
>knowledge. What I'd actually suggest is to drop their implementation
>entierly, returning ENOSYS,
You're not being clear again, but if you are actually promoting the
notion of cygwin not implementing signals then that is a really daft
idea. Really. Go to the Cygwin web site and look at all of the
packages which have been ported. Now think about how they would work if
Cygwin didn't support signals. bash wouldn't work, openssh, X wouldn't
work.
>so that programs are not fooled into believing that the system will
>work as expected. It never will. "Ctrl-C" in windows console is just
>a shortcut to TerminateProcess, live with that.
Let me say it again since it isn't clear that you are getting it. If
signals in a pure cygwin environment don't work then that is *a bug*.
If you are running pure windows programs in the mix with cygwin programs
then if *they* don't stop when you hit CTRL-C, that is undoubtedly a bug
in that pure windows program.
If you find that a pure windows program terminates when run from a
windows command prompt but keeps running when run by a cygwin program
then that is likely a cygwin problem that can be reported to the cygwin
mailing list.
>>>filesystem is slow and locked down, and exec-attribute is NOT really
>>>useful even on NTFS (it is somehow related to execute permission and
>>>open files. I still cannot figure out how exactly are they related).
>>
>>Again, it's not clear if you're talking about Windows or Cygwin but
>>under Cygwin, in the default configuration, the exec attribute means
>>the same thing to cygwin as it does to linux.
>
>I'm talking about git and native windows interaction:
I'd suggest that using git with native windows programs should probably
be considered "unsupported" since you seem to be having so much trouble
with it.
>I cannot use umask, because I have to use stupid windows programs, and
>they always create "executable" *.c and *.h, and I cannot blindly
>remove it with something like "chmod -R -x", because it'd remove it
>also from executables.
find . -name '*.[ch]' | xargs chmod a-x
>The poor executables lose their _rights_ to be executed (why does
>cygwin use windows permissions? They cannot correlate to unix
>attributes, can they?)
Please read the Cygwin user's guide for a discussion about how file
permissions are implemented. And, then, when you are outraged about how
unclear that documentation is please send comments and improvements to
the cygwin mailing list.
I don't see why it is appropriate to be discussing how Cygwin implements
UNIX permissions in this mailing list unless the implementation affects
git somehow.
cgf
^ permalink raw reply
* windows problems summary
From: Alex Riesen @ 2006-03-02 14:49 UTC (permalink / raw)
To: Git Mailing List
This is just to summarize all the problems which make porting to that
thing so boring. Maybe if we have them all on one page, it'd be easier
to locate the workarounds (it can be one thread, for example).
1. opened and mmaped files can't be removed or renamed
(caused workaround with reading index in memory)
2. command can safely contain only one argument
(breaks and complicates passing things between processes)
3. no fork
(slows down and complicates passing things between processes)
4. non-unix permissions model
(breaks x-attr)
5. real slow filesystems and caching
(makes everything slow. I noticed I'm trying to avoid git status!).
Caused workaround with manual checkout)
6. real slow program startup
(makes everything slow, eventually may cause everything being put
in one super-executable, just to avoid spawning new processes,
with all associated problems. Makes scripting harder)
I hope this message can be a start of a big porting thread,
even though it is only about windows at the moment.
Alex Riesen
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Alex Riesen @ 2006-03-02 14:18 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060226204027.GC30735@trixie.casa.cgf.cx>
On 2/26/06, Christopher Faylor <me@cgf.cx> wrote:
> The cygwin/windows version of spawn is basically like an extended version
> of exec*():
>
> pid = spawnlp (P_NOWAIT, "/bin/ls", "ls", "-l", NULL);
>
By the way, is argv worked around?
AFAIK, windows has only one argument, returned by GetCommandLine?
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Alex Riesen @ 2006-03-02 14:10 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060226195552.GA30735@trixie.casa.cgf.cx>
Christopher, I'm terribly sorry for the long delays,
but that is something I can't change at this moment.
On 2/26/06, Christopher Faylor <me@cgf.cx> wrote:
> >>>It's not activestate perl actually. It's only one platform it also
> >>>_has_ to support. Is it worth supporting Windows?
> >>
> >>With or without cygwin? With cygwin, I'd say "yes, unless it makes
> >>things terribly difficult to maintain and so long as we don't take
> >>performance hits on unices". Without cygwin, I'd say "What? It runs
> >>on windows?".
> >
> >There not much difference with or without cygwin. The penalties of
> >doing any kind of support for it will pile up (as they started to do
> >with pipes). Someday we'll have to start dropping features on Windows
> >or restrict them beyond their usefullness. The fork emulation in
> >cygwin isn't perfect,
>
> If the speed of cygwin's fork is an issue then I'd previously suggested
> using spawn*. The spawn family of functions were designed to emulate
> Windows functions of the same name. They start a new process without
> the requirement of forking.
The effort of porting git to spawn-like interface has already started,
so there's no much left to say about the fork's speed...
> >signals do not work reliably (if at all),
>
> I'm not sure if you're mixing cygwin with windows here but if signals do
> not work reliably in Cygwin then that is something that we'd like to
> know about. Signals *obviously* have to work fairly well for programs
> like ssh, bash, and X to work, however.
That's not enough.
Try interrupting busy processes. Like "git pull", "git clone" or make.
> Native Windows, OTOH, hardly has any signals at all and deals with
> signals in a way that is only vaguely like linux.
That makes the rest of installed system kind of useless in cygwin
environment. After interrupting a build process, which uses java
(don't ask) only make stops. The rest of the process runs happily
away.
Now, I know that windows has no signals at all and nothing which
even closely resembles them. I wont be pressing anyone to
implement them in windows, having the knowledge.
What I'd actually suggest is to drop their implementation entierly,
returning ENOSYS, so that programs are not fooled into believing
that the system will work as expected. It never will.
"Ctrl-C" in windows console is just a shortcut to TerminateProcess,
live with that.
> >filesystem is slow and locked down, and exec-attribute is NOT really
> >useful even on NTFS (it is somehow related to execute permission and
> >open files. I still cannot figure out how exactly are they related).
>
> Again, it's not clear if you're talking about Windows or Cygwin but
> under Cygwin, in the default configuration, the exec attribute means the
> same thing to cygwin as it does to linux.
I'm talking about git and native windows interaction: I cannot use umask,
because I have to use stupid windows programs, and they always create
"executable" *.c and *.h, and I cannot blindly remove it with something
like "chmod -R -x", because it'd remove it also from executables. The
poor executables lose their _rights_ to be executed (why does cygwin use
windows permissions? They cannot correlate to unix attributes, can they?)
An .bat or .cmd without right to execute it is a pain in my build system
(and no, I'm not allowed to change that damn stupid build system).
Is there any way to tell cygwin that the files it hasn't seen or touched yet
are _not_executables_?
^ permalink raw reply
* Re: Problems with using git
From: Andreas Ericsson @ 2006-03-02 13:59 UTC (permalink / raw)
To: Joseph Wakeling; +Cc: git
In-Reply-To: <4406F8B1.9050303@webdrake.net>
Joseph Wakeling wrote:
> Thanks very much to all who offered advice on this. :-)
>
> Unfortunately openSUSE is somewhat out of sync not just with git but in
> libraries necessary to install the latest version (libcrypto.so.4,
> libssl.so.4). The openssl (0.9.7g-2.4) and openssl-devel (0.9.7g-2)
> packages don't contain these but rather contain libcrypto.so.0.9.7 and
> libssl.0.9.7. Just in case it's important to future git development.
>
It might be useful for the openSuSE developers, but for git this is
totally irrelevant. If you build from sources yourself they will be
linked to whatever libraries you have installed.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Problems with using git
From: Joseph Wakeling @ 2006-03-02 13:52 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0603011651240.22647@g5.osdl.org>
Thanks very much to all who offered advice on this. :-)
Unfortunately openSUSE is somewhat out of sync not just with git but in
libraries necessary to install the latest version (libcrypto.so.4,
libssl.so.4). The openssl (0.9.7g-2.4) and openssl-devel (0.9.7g-2)
packages don't contain these but rather contain libcrypto.so.0.9.7 and
libssl.0.9.7. Just in case it's important to future git development.
Best wishes & thanks again,
-- Joe
^ permalink raw reply
* Re: NT directory traversal speed on 25K files on Cygwin
From: Alex Riesen @ 2006-03-02 13:40 UTC (permalink / raw)
To: git; +Cc: Andreas Ericsson, Christopher Faylor, git
In-Reply-To: <20060227184544.GB13195@nospam.com>
On 2/27/06, Rutger Nijlunsing <rutger@nospam.com> wrote:
> I'm not saying Cygwin is bad (actually, I'm installing on every
> Windows PC I get my hand on ;), but using Cygwin for all file IO
> instead of native Windows IO makes git a magnitude slower on Windows
By "slow filesystem" I actually meant the native filesystem access.
Cygwin does make it 6 times slower, that's right, and this can be
considered a disaster of course, but not as big as the windows api.
^ permalink raw reply
* cygwin: push/pull takes very long time
From: Alex Riesen @ 2006-03-02 13:26 UTC (permalink / raw)
To: Git Mailing List
Hi,
I didn't really notice when it happened, but since some time
push and pull takes *very* long. git-pack-objects appears to
be the major offender:
$ git pull ../src march:march
Generating pack...
Done counting 20238 objects.
Result has 12 objects.
Deltifying 12 objects.
8% (1/12) done
It's still working, half an hour since it was started.
It can be seen that it is constantly growing and shrinking
(for about 20k,50k,80k,100k back and forth).
I did a small instrumentation to figure out how much
and how often is allocated, but it's waiting for the
git-pack-objects to finish. "Counting objects" was
slow too, with git-rev-list "pulsating" in a similar
way (most commonly allocated objects in the size
range from 16 to 256).
I continue looking for the problem (I didn't do bisect yet,
want to wait for mem profile first), but any ideas on how
to fix that are very welcome.
^ permalink raw reply
* Re: [PATCH] Teach git-checkout-index to read filenames from stdin.
From: Alex Riesen @ 2006-03-02 13:14 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <81b0412b0603020512i429481f7i4a0dbe4599dbb5a6@mail.gmail.com>
On 3/2/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 3/1/06, Christopher Faylor <me@cgf.cx> wrote:
> >
> > For native Windows programs, the command line length is ~32K but I don't
> > think that git uses any native Windows programs, does it?
> >
>
> Yes, ActiveState Perl is as native as it gets.
>
It does use native windows programs, I mean.
At least for me it does.
^ permalink raw reply
* Re: [PATCH] Teach git-checkout-index to read filenames from stdin.
From: Alex Riesen @ 2006-03-02 13:12 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060301155053.GC1010@trixie.casa.cgf.cx>
On 3/1/06, Christopher Faylor <me@cgf.cx> wrote:
>
> For native Windows programs, the command line length is ~32K but I don't
> think that git uses any native Windows programs, does it?
>
Yes, ActiveState Perl is as native as it gets.
^ permalink raw reply
* Re: git doesn't like big files when pushing
From: Simon Richter @ 2006-03-02 12:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, git
In-Reply-To: <Pine.LNX.4.64.0603011448230.22647@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
Hi,
Linus Torvalds wrote:
> But maybe it's really the case that you can't fit those 8 objects in
> memory. One option (which might also solve some of the performance issues)
> is to make the window be based on object _size_ rather than just be a
> fixed number (ie with an 80MB object, you'd only try a couple of objects
> around it, not the full window).
Well, doesn't the pack process involve keeping objects of similar size
in memory next to each other? My suspicion is that the system is running
out of virtual address space because almost every malloc() will attempt
to get an entirely new block because the one that was just freed is a
few bytes too small.
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* gitview: pass the missing argument _show_clicked_cb
From: Aneesh Kumar K.V @ 2006-03-02 11:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Subject: gitview: pass the missing argument _show_clicked_cb.
In our last update to use the encoding while showing the commit
diff we added a new argument to this function. But we missed
updating all the callers.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
225f953266128b0703fd8d8a20b3167d06503e4a
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index de9f3f3..781badb 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -798,7 +798,7 @@ class GitView:
button.set_relief(gtk.RELIEF_NONE)
button.set_sensitive(True)
button.connect("clicked", self._show_clicked_cb,
- child_id, commit.commit_sha1)
+ child_id, commit.commit_sha1, self.encoding)
hbox.pack_start(button, expand=False, fill=True)
button.show()
--
1.2.3.gc55f-dirty
^ permalink raw reply related
* [PATCH] Fix test case for some sed
From: Johannes Schindelin @ 2006-03-02 11:43 UTC (permalink / raw)
To: git, junkio
Some versions of sed lack the "-i" option.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
t/t8001-annotate.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
7f024821ec45dc6eaf36c24f94931d58deb75201
diff --git a/t/t8001-annotate.sh b/t/t8001-annotate.sh
index cae1794..172908a 100755
--- a/t/t8001-annotate.sh
+++ b/t/t8001-annotate.sh
@@ -50,7 +50,8 @@ test_expect_success \
test_expect_success \
'merge-setup part 2' \
'git checkout -b branch2 master &&
- sed -i -e "s/2A quick brown/4A quick brown lazy dog/" file &&
+ sed -e "s/2A quick brown/4A quick brown lazy dog/" < file > file.new &&
+ mv file.new file &&
GIT_AUTHOR_NAME="B2" git commit -a -m "Branch2-1"'
test_expect_success \
--
1.2.4.g9520
^ permalink raw reply related
* Re: git push issue
From: Aubrey @ 2006-03-02 10:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q2h6ucs.fsf@assigned-by-dhcp.cox.net>
Thanks a lot.
Now git push is OK.
Is it time to try to clone the git repository from the remote machine to my end?
I have started up the git-daemon, but still get the following error:
============================================================
git clone git://10.99.22.20:/home/aubrey/public_html/my-git.git git-test
fatal: unable to connect a socket (Connection refused)
clone-pack from 'git://10.99.22.20:/home/aubrey/public_html/my-git.git' failed.
If I want to clone it by http:// or git://, Could you please give me
some instructions or docs?
Thanks a million.
Regards,
-Aubrey
^ permalink raw reply
* Re: git push issue
From: Junio C Hamano @ 2006-03-02 9:58 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50603020147l450d1cdfp1bc1747dc79189ce@mail.gmail.com>
Aubrey <aubreylee@gmail.com> writes:
> aubrey@linux:~/public_html/u-boot.git> git push
> 10.99.22.20:/home/aubrey/public_html/my-git.git master
> error: src refspec master does not match any.
> error: dst refspec master does not match any existing ref on the
> remote and does not start with refs/.
The error message tells you that
(1) directory you are in (u-boot.git) does not have a ref that
matches "master". Do you have the "master" branch?
(2) remote repository at 10.99.22.20:/home/.../my-git.git does
not have a ref that matches "master".
The problem on your end must be fixed first. Then once you have
the master branch in u-boot.git directory (I presume
~/public_html/u-boot.git/.git/refs/heads/master would be the
file you would need to see), then the problem on the other end
needs to be dealt with.
If you are creating a branch over there afresh, you need to
spell it out, like this:
$ git push 10.99..:.../my-git.git master:refs/heads/master
After you have done that once (hence creating
/home/aubrey/public_html/my-git.git/.git/refs/heads/master file
over there), you can do the command line I quoted at the
beginning of this message.
^ permalink raw reply
* git push issue
From: Aubrey @ 2006-03-02 9:47 UTC (permalink / raw)
To: git
Hi all,
I followed the instruction of here:
http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html
to publish my work.
But I run into a problem when I run the command "git push", see below:
======================================================
aubrey@linux:~/public_html/u-boot.git> git push
10.99.22.20:/home/aubrey/public_html/my-git.git master
Password:
error: src refspec master does not match any.
error: dst refspec master does not match any existing ref on the
remote and does not start with refs/.
fatal: unexpected EOF
======================================================
The remote machine is in the same subnet as mine.
Many thanks to your help.
Regards,
-Aubrey
^ permalink raw reply
* Re: [PATCH 1/2] Let git-svnimport's author file use same syntax as git-cvsimport's
From: Karl Hasselström @ 2006-03-02 9:20 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Git Mailing List
In-Reply-To: <1141247993.12729.42.camel@cashmere.sps.mot.com>
On 2006-03-01 15:19:53 -0600, Jon Loeliger wrote:
> On Mon, 2006-02-27 at 17:08, Karl Hasselström wrote:
>
> > Read a file with lines on the form
> >
> > - username User's Full Name <email@addres.org>
> > + username = User's Full Name <email@addr.es>
> >
> > - and use "User's Full Name <email@addres.org>" as the GIT
> > + and use "User's Full Name <email@addr.es>" as the GIT
> > author and committer for Subversion commits made by
> > "username". If encountering a commit made by a user not in the
> > list, abort.
>
> Actually, I believe that "example.com" was reserved specifically for
> instances such as this.
Yes, I know. But email.address@example.com is much longer then
email@addr.es, and not half as funny. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Teach git-checkout-index to use file suffixes.
From: Junio C Hamano @ 2006-03-02 7:59 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060302065136.GA6377@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Why let the user choose? '/' shouldn't be permitted as that
> (possibly) would try to create a directory also named the same as
> the file (a bad thing). Then its just two formats, depending on
> if you want all stages or just 1 stage:
>
> --stage=all --suffix=#1/#2/#3
>
> or
>
> --stage=1 --suffix=#1
I'll later agree with "why let the user choose" in this message,
but for an entirely different reason.
I am not a great fan of extracting files from stages in the
working tree to begin with. The git-unpack-file command tries
carefully to avoid conflicts, and its use of temporary files is
inherently, eh, temporary, and Porcelains know what names they
get and know how to clean things up afterwards.
I am sympathetic to what you are trying to achieve here. Maybe
your Porcelain would invoke a graphical 3-way merge program in a
windowing environment, and the merge program displays the
filename(s) your Porcelain fed it to the end user, without
giving you a way to override it. In that context, it is not
useful to the end user to show meaningless temporary filename,
and having checkout-index to derive the temporary filename from
real filename may look sensible.
However, --stage=all with --suffix would introduce name clashes
between repeated conflicted merge runs, which requires Porcelain
to be extra careful. Your last merge run might have involved
three conflicting stages (leaving a.c~1, a.c~2, and a.c~3 in
your working tree) and this time it may be "we removed it while
they modified it" situation (needing to extract a.c~1, a.c~3 but
not a.c~2). The Porcelain needs to make sure not to get
confused by leftover a.c~2 file in the working tree from the
previous run.
If what you are trying is to reduce the number of checkout-index
calls by your Porcelain to extract conflicted stages, it _might_
make more sense to do something like this instead (I am thinking
aloud, so take this with a big grain of salt -- it may not make
sense at all):
checkout-index --stage=all checks out higher-order stages in
made-up temporary filenames, just like git-merge-one-file
does using git-unpack-file one-by-one, with a single
invocation.
It reports the following to its standard output, one record
per pathname in the index:
tmp1 <SP> tmp2 <SP> tmp3 <TAB> pathname <RS>
Here, tmp? is the temporary file names for each stage, or a
dot for for a nonexistent stage. pathname is c-quoted as
usual for non -z output and RS is '\n' (under -z flag,
pathname is a literal string and RS is NUL). SP = space
(ASCII 0x20), TAB = tab (ASCII 0x09).
Example:
".tmp1323 . .tmp1232\tfoo/a.c\n"
Notice the dot between the two temporary files -- stage2 is
empty in this example.
Then your Porcelain could run --stage=all and read the output,
and then moving the temporary files around whatever way pleases
it. Since it needs to be careful about not overwriting the
existing working tree files *and* not getting confused by
existing garbage in the working tree anyway, I do not think it
would make your life much easier to have checkout-index derive
the temporary file names after the real working tree files.
BTW, using TAB to split metainformation and pathname and using
SP to separate metainformation pieces are in line with the
design other git tools use. With this, you can separate the LHS
metainformation part and pathname using "cut", and you can have
shell IFS to split the metainformation part apart after that.
But that is a minor detail.
^ permalink raw reply
* Re: [PATCH] Teach git-checkout-index to use file suffixes.
From: Shawn Pearce @ 2006-03-02 6:51 UTC (permalink / raw)
To: git
In-Reply-To: <slrne0bh1p.fr9.mdw@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> wrote:
> Shawn Pearce <spearce@spearce.org> wrote:
>
> > I thought about using instead:
> >
> > --stage=all --suffix1=\#1 --suffix2\=#2 --suffix3=\#3
>
> How about something like
>
> --suffixes=:#1:#2:#3
>
> uses first character as a delimiter to separate the suffixes. A single
> --suffix option could plausibly provide the suffix if only one stage is
> being checked out, and doesn't have the grim delimiter wart.
Why let the user choose? '/' shouldn't be permitted as that
(possibly) would try to create a directory also named the same as
the file (a bad thing). Then its just two formats, depending on
if you want all stages or just 1 stage:
--stage=all --suffix=#1/#2/#3
or
--stage=1 --suffix=#1
?
--
Shawn.
^ permalink raw reply
* [ANNOUNCE] GIT 1.2.4
From: Junio C Hamano @ 2006-03-02 6:24 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.2.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.2.4.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.2.4-1.$arch.rpm (RPM)
Among some fixes, there is one feature item: war on whitespace.
This was done in response to Andrew Morten's request, and
backported from the primary development track.
When you apply an e-mailed patch with git-am (or git-applymbox),
if the patch introduces new trailing whitespaces, you will get
warning messages by default. This behaviour can be tweaked by
setting the configuration item "apply.whitespace" to various
values.
For kernel subsystem maintainers, the earlier Andrew's requests
translate to setting it to either "error" or "strip".
E.g.
$ git repo-config apply.whitespace error
What are the available choices, and which one is for you?
* If you are a busy top echelon person who cares about tree
cleanliness, apply.whitespace=error is a good choice. This
stops after giving a handful error messages, and refuses to
apply a patch that introduces trailing whitespaces. After
the failed patch, you should return the patch to the
submitter; your tree remains clean.
* apply.whitespace=error-all is a better choice for you, if you
are willing to clean up other peoples' mess. You will get
all errors, and the patch is not applied. You can go through
with your editor (e.g. Emacs users can use C-x `; I hope vim
users have similar macros) and fix things in .dotest/patch.
After fixing them up, "git am" without flags (or "-i" for
"interactive" if you want) to apply it. Do not forget to
tell the person who wasted your time doing this to be more
careful next time.
* If you do not care much about new trailing whitespaces, there
is apply.whitespace=warn, which is the default. This shows
warning messages and applies the patch. Make a mental note
to scold the patch submitter to be careful the next time.
* If you care about cleanliness, want to be nice to the
submitters by not forcing them to resubmit solely on
whitespace basis, but not nice enough to educate them,
apply.whitespace=strip is for you. This applies the patch
after stripping the trailing whitespaces it introduces.
* If you do not care about whitespace errors at all,
apply.whitespace=nowarn is for you. No warnings, no errors.
----------------------------------------------------------------
Changes since v1.2.3 are as follows:
Alex Riesen:
fix t5600-clone-fail-cleanup.sh on windows
Josef Weidendorfer:
git-mv: Allow -h without repo & fix error message
git-mv: fixes for path handling
Junio C Hamano:
checkout - eye candy.
Give no terminating LF to error() function.
diffcore-rename: plug memory leak.
git-am: do not allow empty commits by mistake.
sample hooks template.
apply --whitespace fixes and enhancements.
apply: squelch excessive errors and --whitespace=error-all
apply --whitespace: configuration option.
git-apply --whitespace=nowarn
git-apply: war on whitespace -- finishing touches.
git-am: --whitespace=x option.
diffcore-break: micro-optimize by avoiding delta between identical files.
Allow git-mv to accept ./ in paths.
Linus Torvalds:
The war on trailing whitespace
Mark Wooding:
combine-diff: Honour --full-index.
combine-diff: Honour -z option correctly.
^ permalink raw reply
* [PATCH] contrib/git-svn: use refs/remotes/git-svn instead of git-svn-HEAD
From: Eric Wong @ 2006-03-02 5:58 UTC (permalink / raw)
To: git list, Junio C Hamano
After reading a lengthy discussion on the list, I've come to the
conclusion that creating a 'remotes' directory in refs isn't
such a bad idea.
You can still branch from it by specifying remotes/git-svn (not
needing the leading 'refs/'), and the documentation has been
updated to reflect that.
The 'git-svn' part of the ref can of course be set to whatever
you want by using the GIT_SVN_ID environment variable, as
before.
I'm using refs/remotes/git-svn, and not going with something
like refs/remotes/git-svn/HEAD as it's redundant for Subversion
where there's zero distinction between branches and directories.
Run git-svn rebuild --upgrade to upgrade your repository to use
the new head. git-svn-HEAD must be manually deleted for safety
reasons.
Side note: if you ever (and I hope you never) want to run
git-update-refs on a 'remotes/' ref, make sure you have the
'refs/' prefix as you don't want to be clobbering your
'remotes/' in $GIT_DIR (where remote URLs are stored).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 63 +++++++++++++++++++++++-----
contrib/git-svn/git-svn.txt | 18 ++++----
contrib/git-svn/t/t0000-contrib-git-svn.sh | 36 ++++++++--------
3 files changed, 78 insertions(+), 39 deletions(-)
98158fd226f764a4d20a4a66b651f3a154a92bf2
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 0b74165..0e092c5 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -34,13 +34,14 @@ use POSIX qw/strftime/;
my $sha1 = qr/[a-f\d]{40}/;
my $sha1_short = qr/[a-f\d]{6,40}/;
my ($_revision,$_stdin,$_no_ignore_ext,$_no_stop_copy,$_help,$_rmdir,$_edit,
- $_find_copies_harder, $_l, $_version);
+ $_find_copies_harder, $_l, $_version, $_upgrade);
GetOptions( 'revision|r=s' => \$_revision,
'no-ignore-externals' => \$_no_ignore_ext,
'stdin|' => \$_stdin,
'edit|e' => \$_edit,
'rmdir' => \$_rmdir,
+ 'upgrade' => \$_upgrade,
'help|H|h' => \$_help,
'find-copies-harder' => \$_find_copies_harder,
'l=i' => \$_l,
@@ -106,13 +107,18 @@ sub rebuild {
$SVN_URL = shift or undef;
my $repo_uuid;
my $newest_rev = 0;
+ if ($_upgrade) {
+ sys('git-update-ref',"refs/remotes/$GIT_SVN","$GIT_SVN-HEAD");
+ } else {
+ check_upgrade_needed();
+ }
my $pid = open(my $rev_list,'-|');
defined $pid or croak $!;
if ($pid == 0) {
- exec("git-rev-list","$GIT_SVN-HEAD") or croak $!;
+ exec("git-rev-list","refs/remotes/$GIT_SVN") or croak $!;
}
- my $first;
+ my $latest;
while (<$rev_list>) {
chomp;
my $c = $_;
@@ -132,18 +138,20 @@ sub rebuild {
"$c, $id\n";
}
}
+
+ # if we merged or otherwise started elsewhere, this is
+ # how we break out of it
+ next if (defined $repo_uuid && ($uuid ne $repo_uuid));
+ next if (defined $SVN_URL && ($url ne $SVN_URL));
+
print "r$rev = $c\n";
- unless (defined $first) {
+ unless (defined $latest) {
if (!$SVN_URL && !$url) {
croak "SVN repository location required: $url\n";
}
$SVN_URL ||= $url;
- $repo_uuid = setup_git_svn();
- $first = $rev;
- }
- if ($uuid ne $repo_uuid) {
- croak "Repository UUIDs do not match!\ngot: $uuid\n",
- "expected: $repo_uuid\n";
+ $repo_uuid ||= setup_git_svn();
+ $latest = $rev;
}
assert_revision_eq_or_unknown($rev, $c);
sys('git-update-ref',"$GIT_SVN/revs/$rev",$c);
@@ -151,7 +159,7 @@ sub rebuild {
}
close $rev_list or croak $?;
if (!chdir $SVN_WC) {
- my @svn_co = ('svn','co',"-r$first");
+ my @svn_co = ('svn','co',"-r$latest");
push @svn_co, '--ignore-externals' unless $_no_ignore_ext;
sys(@svn_co, $SVN_URL, $SVN_WC);
chdir $SVN_WC or croak $!;
@@ -168,6 +176,13 @@ sub rebuild {
exec('git-write-tree');
}
waitpid $pid, 0;
+
+ if ($_upgrade) {
+ print STDERR <<"";
+Keeping deprecated refs/head/$GIT_SVN-HEAD for now. Please remove it
+when you have upgraded your tools and habits to use refs/remotes/$GIT_SVN
+
+ }
}
sub init {
@@ -180,6 +195,7 @@ sub init {
sub fetch {
my (@parents) = @_;
+ check_upgrade_needed();
$SVN_URL ||= file_to_s("$GIT_DIR/$GIT_SVN/info/url");
my @log_args = -d $SVN_WC ? ($SVN_WC) : ($SVN_URL);
unless ($_revision) {
@@ -222,6 +238,7 @@ sub fetch {
sub commit {
my (@commits) = @_;
+ check_upgrade_needed();
if ($_stdin || !@commits) {
print "Reading from stdin...\n";
@commits = ();
@@ -863,7 +880,7 @@ sub git_commit {
if ($commit !~ /^$sha1$/o) {
croak "Failed to commit, invalid sha1: $commit\n";
}
- my @update_ref = ('git-update-ref',"refs/heads/$GIT_SVN-HEAD",$commit);
+ my @update_ref = ('git-update-ref',"refs/remotes/$GIT_SVN",$commit);
if (my $primary_parent = shift @exec_parents) {
push @update_ref, $primary_parent;
}
@@ -936,6 +953,28 @@ sub svn_check_ignore_externals {
$_no_ignore_ext = 1;
}
}
+
+sub check_upgrade_needed {
+ my $old = eval {
+ my $pid = open my $child, '-|';
+ defined $pid or croak $!;
+ if ($pid == 0) {
+ close STDERR;
+ exec('git-rev-parse',"$GIT_SVN-HEAD") or croak $?;
+ }
+ my @ret = (<$child>);
+ close $child or croak $?;
+ die $? if $?; # just in case close didn't error out
+ return wantarray ? @ret : join('',@ret);
+ };
+ return unless $old;
+ my $head = eval { safe_qx('git-rev-parse',"refs/remotes/$GIT_SVN") };
+ if ($@ || !$head) {
+ print STDERR "Please run: $0 rebuild --upgrade\n";
+ exit 1;
+ }
+}
+
__END__
Data structures:
diff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt
index b290739..4102deb 100644
--- a/contrib/git-svn/git-svn.txt
+++ b/contrib/git-svn/git-svn.txt
@@ -41,12 +41,12 @@ init::
fetch::
Fetch unfetched revisions from the SVN_URL we are tracking.
- refs/heads/git-svn-HEAD will be updated to the latest revision.
+ refs/heads/remotes/git-svn will be updated to the latest revision.
- Note: You should never attempt to modify the git-svn-HEAD branch
- outside of git-svn. Instead, create a branch from git-svn-HEAD
+ Note: You should never attempt to modify the remotes/git-svn branch
+ outside of git-svn. Instead, create a branch from remotes/git-svn
and work on that branch. Use the 'commit' command (see below)
- to write git commits back to git-svn-HEAD.
+ to write git commits back to remotes/git-svn.
commit::
Commit specified commit or tree objects to SVN. This relies on
@@ -155,13 +155,13 @@ Tracking and contributing to an Subversi
# Fetch remote revisions::
git-svn fetch
# Create your own branch to hack on::
- git checkout -b my-branch git-svn-HEAD
+ git checkout -b my-branch remotes/git-svn
# Commit only the git commits you want to SVN::
git-svn commit <tree-ish> [<tree-ish_2> ...]
# Commit all the git commits from my-branch that don't exist in SVN::
- git-svn commit git-svn-HEAD..my-branch
+ git-svn commit remotes/git-svn..my-branch
# Something is committed to SVN, pull the latest into your branch::
- git-svn fetch && git pull . git-svn-HEAD
+ git-svn fetch && git pull . remotes/git-svn
# Append svn:ignore settings to the default git exclude file:
git-svn show-ignore >> .git/info/exclude
@@ -184,8 +184,8 @@ SVN repositories via one git repository.
environment variable to a name other other than "git-svn" (the default)
and git-svn will ignore the contents of the $GIT_DIR/git-svn directory
and instead do all of its work in $GIT_DIR/$GIT_SVN_ID for that
-invocation. The interface branch will be $GIT_SVN_ID-HEAD, instead of
-git-svn-HEAD. Any $GIT_SVN_ID-HEAD branch should never be modified
+invocation. The interface branch will be remotes/$GIT_SVN_ID, instead of
+remotes/git-svn. Any remotes/$GIT_SVN_ID branch should never be modified
by the user outside of git-svn commands.
ADDITIONAL FETCH ARGUMENTS
diff --git a/contrib/git-svn/t/t0000-contrib-git-svn.sh b/contrib/git-svn/t/t0000-contrib-git-svn.sh
index 181dfe0..80ad357 100644
--- a/contrib/git-svn/t/t0000-contrib-git-svn.sh
+++ b/contrib/git-svn/t/t0000-contrib-git-svn.sh
@@ -71,14 +71,14 @@ test_expect_success \
name='try a deep --rmdir with a commit'
-git checkout -b mybranch git-svn-HEAD
+git checkout -b mybranch remotes/git-svn
mv dir/a/b/c/d/e/file dir/file
cp dir/file file
git update-index --add --remove dir/a/b/c/d/e/file dir/file file
git commit -m "$name"
test_expect_success "$name" \
- "git-svn commit --find-copies-harder --rmdir git-svn-HEAD..mybranch &&
+ "git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch &&
test -d $SVN_TREE/dir && test ! -d $SVN_TREE/dir/a"
@@ -91,13 +91,13 @@ git update-index --add dir/file/file
git commit -m "$name"
test_expect_code 1 "$name" \
- 'git-svn commit --find-copies-harder --rmdir git-svn-HEAD..mybranch' \
+ 'git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch' \
|| true
name='detect node change from directory to file #1'
rm -rf dir $GIT_DIR/index
-git checkout -b mybranch2 git-svn-HEAD
+git checkout -b mybranch2 remotes/git-svn
mv bar/zzz zzz
rm -rf bar
mv zzz bar
@@ -106,13 +106,13 @@ git update-index --add -- bar
git commit -m "$name"
test_expect_code 1 "$name" \
- 'git-svn commit --find-copies-harder --rmdir git-svn-HEAD..mybranch2' \
+ 'git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch2' \
|| true
name='detect node change from file to directory #2'
rm -f $GIT_DIR/index
-git checkout -b mybranch3 git-svn-HEAD
+git checkout -b mybranch3 remotes/git-svn
rm bar/zzz
git-update-index --remove bar/zzz
mkdir bar/zzz
@@ -121,13 +121,13 @@ git-update-index --add bar/zzz/yyy
git commit -m "$name"
test_expect_code 1 "$name" \
- 'git-svn commit --find-copies-harder --rmdir git-svn-HEAD..mybranch3' \
+ 'git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch3' \
|| true
name='detect node change from directory to file #2'
rm -f $GIT_DIR/index
-git checkout -b mybranch4 git-svn-HEAD
+git checkout -b mybranch4 remotes/git-svn
rm -rf dir
git update-index --remove -- dir/file
touch dir
@@ -136,19 +136,19 @@ git update-index --add -- dir
git commit -m "$name"
test_expect_code 1 "$name" \
- 'git-svn commit --find-copies-harder --rmdir git-svn-HEAD..mybranch4' \
+ 'git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch4' \
|| true
name='remove executable bit from a file'
rm -f $GIT_DIR/index
-git checkout -b mybranch5 git-svn-HEAD
+git checkout -b mybranch5 remotes/git-svn
chmod -x exec.sh
git update-index exec.sh
git commit -m "$name"
test_expect_success "$name" \
- "git-svn commit --find-copies-harder --rmdir git-svn-HEAD..mybranch5 &&
+ "git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
test ! -x $SVN_TREE/exec.sh"
@@ -158,7 +158,7 @@ git update-index exec.sh
git commit -m "$name"
test_expect_success "$name" \
- "git-svn commit --find-copies-harder --rmdir git-svn-HEAD..mybranch5 &&
+ "git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
test -x $SVN_TREE/exec.sh"
@@ -170,7 +170,7 @@ git update-index exec.sh
git commit -m "$name"
test_expect_success "$name" \
- "git-svn commit --find-copies-harder --rmdir git-svn-HEAD..mybranch5 &&
+ "git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
test -L $SVN_TREE/exec.sh"
@@ -182,7 +182,7 @@ git update-index --add bar/zzz exec-2.sh
git commit -m "$name"
test_expect_success "$name" \
- "git-svn commit --find-copies-harder --rmdir git-svn-HEAD..mybranch5 &&
+ "git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
test -x $SVN_TREE/bar/zzz &&
test -L $SVN_TREE/exec-2.sh"
@@ -196,7 +196,7 @@ git update-index exec-2.sh
git commit -m "$name"
test_expect_success "$name" \
- "git-svn commit --find-copies-harder --rmdir git-svn-HEAD..mybranch5 &&
+ "git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
test -f $SVN_TREE/exec-2.sh &&
test ! -L $SVN_TREE/exec-2.sh &&
diff -u help $SVN_TREE/exec-2.sh"
@@ -207,9 +207,9 @@ name='test fetch functionality (svn => g
GIT_SVN_ID=alt
export GIT_SVN_ID
test_expect_success "$name" \
- "git-svn init $svnrepo && git-svn fetch -v &&
- git-rev-list --pretty=raw git-svn-HEAD | grep ^tree | uniq > a &&
- git-rev-list --pretty=raw alt-HEAD | grep ^tree | uniq > b &&
+ "git-svn init $svnrepo && git-svn fetch &&
+ git-rev-list --pretty=raw remotes/git-svn | grep ^tree | uniq > a &&
+ git-rev-list --pretty=raw remotes/alt | grep ^tree | uniq > b &&
diff -u a b"
test_done
--
1.2.3.g4676
^ permalink raw reply related
* [PATCH] cvsserver: Eclipse compat -- now "compare with latest from HEAD" works
From: Martin Langhoff @ 2006-03-02 5:42 UTC (permalink / raw)
To: git, junkio; +Cc: Martin Langhoff
The Eclipse client uses cvs update when that menu option is triggered.
And doesn't like the standard cvs update response. Give it *exactly* what
it wants.
And hope the other clients don't lose the plot too badly.
---
Or pull from my cvsserver branch
---
git-cvsserver.perl | 27 ++++++++++++++++++++++++---
1 files changed, 24 insertions(+), 3 deletions(-)
3d9afa6824c09083b26c4d371fee54acd1216bba
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index d641c03..7b3ba1b 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -714,8 +714,27 @@ sub req_update
#$log->debug("Target revision is $meta->{revision}, current working revision is $wrev");
- # Files are up to date if the working copy and repo copy have the same revision, and the working copy is unmodified _and_ the user hasn't specified -C
- next if ( defined ( $wrev ) and defined($meta->{revision}) and $wrev == $meta->{revision} and $state->{entries}{$filename}{unchanged} and not exists ( $state->{opt}{C} ) );
+ # Files are up to date if the working copy and repo copy have the same revision,
+ # and the working copy is unmodified _and_ the user hasn't specified -C
+ next if ( defined ( $wrev )
+ and defined($meta->{revision})
+ and $wrev == $meta->{revision}
+ and $state->{entries}{$filename}{unchanged}
+ and not exists ( $state->{opt}{C} ) );
+
+ # If the working copy and repo copy have the same revision,
+ # but the working copy is modified, tell the client it's modified
+ if ( defined ( $wrev )
+ and defined($meta->{revision})
+ and $wrev == $meta->{revision}
+ and not exists ( $state->{opt}{C} ) )
+ {
+ $log->info("Tell the client the file is modified");
+ print "MT text U\n";
+ print "MT fname $filename\n";
+ print "MT newline\n";
+ next;
+ }
if ( $meta->{filehash} eq "deleted" )
{
@@ -727,7 +746,8 @@ sub req_update
print "Removed $dirpart\n";
print "$filepart\n";
}
- elsif ( not defined ( $state->{entries}{$filename}{modified_hash} ) or $state->{entries}{$filename}{modified_hash} eq $oldmeta->{filehash} )
+ elsif ( not defined ( $state->{entries}{$filename}{modified_hash} )
+ or $state->{entries}{$filename}{modified_hash} eq $oldmeta->{filehash} )
{
$log->info("Updating '$filename'");
# normal update, just send the new revision (either U=Update, or A=Add, or R=Remove)
@@ -763,6 +783,7 @@ sub req_update
# transmit file
transmitfile($meta->{filehash});
} else {
+ $log->info("Updating '$filename'");
my ( $filepart, $dirpart ) = filenamesplit($meta->{name});
my $dir = tempdir( DIR => $TEMP_DIR, CLEANUP => 1 ) . "/";
--
1.2.4.g09a27-dirty
^ permalink raw reply related
* [PATCH 1/3] Handle \No newline at end of file.
From: Ryan Anderson @ 2006-03-02 5:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson
In-Reply-To: <114127659642-git-send-email-ryan@michonline.com>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
git-annotate.perl | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
e30d9ddd62cf016124dd9f32e14809d0a38c69e2
diff --git a/git-annotate.perl b/git-annotate.perl
index f9c2c6c..d6028c9 100755
--- a/git-annotate.perl
+++ b/git-annotate.perl
@@ -304,6 +304,12 @@ sub _git_diff_parse {
}
$ri++;
+ } elsif (m/^\\/) {
+ ;
+ # Skip \No newline at end of file.
+ # But this can be internationalized, so only look
+ # for an initial \
+
} else {
if (substr($_,1) ne get_line($slines,$ri) ) {
die sprintf("Line %d (%d) does not match:\n|%s\n|%s\n%s => %s\n",
--
1.2.2.g1070
^ permalink raw reply related
* [PATCH 3/3] annotate: --rev-file (-S) is not a boolean parameter
From: Ryan Anderson @ 2006-03-02 5:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson
In-Reply-To: <11412770172128-git-send-email-ryan@michonline.com>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
git-annotate.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
75846f79f31c9833303ff7d44b87b53c39f4bf9a
diff --git a/git-annotate.perl b/git-annotate.perl
index d6028c9..30f9a71 100755
--- a/git-annotate.perl
+++ b/git-annotate.perl
@@ -31,7 +31,7 @@ our ($help, $longrev, $rename, $starting
my $rc = GetOptions( "long|l" => \$longrev,
"help|h" => \$help,
"rename|r" => \$rename,
- "rev-file|S" => \$rev_file);
+ "rev-file|S=s" => \$rev_file);
if (!$rc or $help) {
usage();
}
--
1.2.2.g1070
^ 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