* Re: [PATCH] whitespace: fix initial-indent checking
From: Jakub Narebski @ 2007-12-16 9:08 UTC (permalink / raw)
To: git
In-Reply-To: <1197776919-16121-5-git-send-email-bfields@citi.umich.edu>
J. Bruce Fields wrote:
> This allows catching initial indents like '\t ' (a tab followed
> by 8 spaces), while previously indent-with-non-tab caught only indents
> that consisted entirely of spaces.
I prefer to use tabs for indent, but _spaces_ for align. While previous,
less strict version of check catches indent using spaces, this one also
catches _align_ using spaces.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Windows binaries for qgit 2.0
From: Abdelrazak Younes @ 2007-12-16 9:10 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550712160105w3817a460v3db1bde15969fcf2@mail.gmail.com>
Marco Costalba wrote:
> On Dec 16, 2007 9:52 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
>> Hum, I can't imagine this is the reason, it might be for another reason,
>> most certainly the static compiling.
>>
>
> Static compiling is indeed a highly suspect. I'm now compiling as
> shared libraries, we will see...
Another suspect is that under Windows, at least with MSVC, it is
strongly advised to not mix debug and release libraries as they have
different memory models. I am not sure to what extend this advice is
valid for mingw compiled libraries.
>
>> Well, for the LyX project we used to use and distribute the patched
>> version of Qt in order to compile it with MSVC. Now, since Qt4.3.2 the
>> MSVC compilation support is enabled in the official release so you don't
>> even have to patch it anymore. I can send you precompiled dll if you
>> want.
>
> Sorry for the stupid question, but, what ddl ??
The MSVC compiled Qt dlls :-)
Sorry too, I guess I was not clear enough.
Abdel.
^ permalink raw reply
* Re: One of my commits is missing
From: Luke Diamand @ 2007-12-16 9:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <cmu-lmtpd-1776-1197757787-0@salieri>
Thanks! That found it.
Shawn O. Pearce wrote:
> Luke Diamand <luke@vidanti.com> wrote:
>> My last commit seems to have vanished, and I wonder if anyone knows
>> where it might have gone.
> ...
>> Looking through my history I don't see any signs of errant git-reset's
>> so I'm baffled.
>
>
> I'm baffled too. Have a look at your HEAD reflog and see if you
> can find it there (`git log -g`) as if you actually did in fact
> create it with git-commit it should appear in that reflog for at
> least the next 90 days (by default config anyway).
>
^ permalink raw reply
* Re: [PATCH] whitespace: fix initial-indent checking
From: Wincent Colaiuta @ 2007-12-16 10:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List, J. Bruce Fields, Junio Hamano
In-Reply-To: <fk2pua$b4p$1@ger.gmane.org>
El 16/12/2007, a las 10:08, Jakub Narebski escribió:
> J. Bruce Fields wrote:
>
>> This allows catching initial indents like '\t ' (a tab
>> followed
>> by 8 spaces), while previously indent-with-non-tab caught only
>> indents
>> that consisted entirely of spaces.
>
> I prefer to use tabs for indent, but _spaces_ for align. While
> previous,
> less strict version of check catches indent using spaces, this one
> also
> catches _align_ using spaces.
I'd say that Jakub's is a fairly common use case (it's used in many
places in the Git codebase too, I think) so it would be a bad thing to
change the behaviour of "indent-with-non-tab".
If you also want to check for "align-with-non-tab" then it really
should be a separate, optional class of whitespace error.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] whitespace: reorganize initial-indent check
From: Wincent Colaiuta @ 2007-12-16 10:02 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Git Mailing List
In-Reply-To: <1197776919-16121-3-git-send-email-bfields@citi.umich.edu>
El 16/12/2007, a las 4:48, J. Bruce Fields escribió:
> Reorganize to emphasize the most complicated part of the code (the tab
> case).
Any chance of either squashing this series into one patch seeing as
its all churning over the same part of the code, or resending it with
numbering? The patches seemed to arrive out of order in my mailbox and
I don't really know what order they're supposed to be applied in and
it's a bit hard to review.
Cheers,
Wincent
^ permalink raw reply
* Problem with git-svn
From: Pascal Obry @ 2007-12-16 10:30 UTC (permalink / raw)
To: git list
I'm trying to use a Subversion repository with Git. I had
great success with many repositories except one. This one
live since long time and as been migrated from CVS to
Subversion.
The current Subversion repository contains multiple projects.
Each project is under /trunk. While trying to import the project
PROJ:
$ git svn clone svn+ssh://myserver/trunk/PROJ
I get:
Initialized empty Git repository in .git/
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 100, path '/trunk/PROJ'
Found possible branch point: svn+ssh://myserver/importfromcvs/trunk =>
svn+ssh://myserver/trunk/PROJ, 48467
Initializing parent: git-svn@48467
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 101, path
'/importfromcvs/trunk'
r9458 = b90789186c85a19a9f32ea6dc8a4259e2eadef67 (git-svn@48467)
A file.el
But file.el is not part of this project, it is part of another one
on the same Subversion repository. It looks like git-svn get confused
at some point. I've been trying to track this down, but since I've
never written a single Perl script that's not easy :(
Note that AFAIK each CVS modules have been imported into
/importfromcvs/trunk then move into /trunk/<MODULE_NAME>.
r48467 seem ok as a branch point:
<<
------------------------------------------------------------------------
r48468 | svn | 2007-05-09 15:10:54 +0200 (Wed, 09 May 2007) | 1 line
Changed paths:
D /importfromcvs/trunk
A /trunk/PROJ (from /importfromcvs/trunk:48467)
Importing module PROJ into SVN.
>>
So I'm looking for hints about the possible problem.
Note that I have tried to reproduce this with a small
script (using the same repository structure) but I was
not able.
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: Windows binaries for qgit 2.0
From: Marco Costalba @ 2007-12-16 10:42 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: git
In-Reply-To: <fk2q1f$bbh$1@ger.gmane.org>
On Dec 16, 2007 10:10 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
> Marco Costalba wrote:
> > On Dec 16, 2007 9:52 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
> >> Hum, I can't imagine this is the reason, it might be for another reason,
> >> most certainly the static compiling.
> >>
> >
> > Static compiling is indeed a highly suspect. I'm now compiling as
> > shared libraries, we will see...
>
Ok. compiled shared libraries release version and qgit release version
-> does not even starts!
After some more test I found that if I compile qgit release adding
flag -O0 it starts, although there is some strange misbehavior
sometime, so the suspect now is a broken O2 optimization for mingw.
To test this I could recompile (sigh!) Qt with shared release + O0
flag, but I'm not sure how to do it.
>
> The MSVC compiled Qt dlls :-)
> Sorry too, I guess I was not clear enough.
>
Yes please!
Thanks
Marco
^ permalink raw reply
* Re: git merge --no-commit <branch>; does commit
From: Alex Riesen @ 2007-12-16 10:53 UTC (permalink / raw)
To: Michael Dressel; +Cc: B.Steinbrink, git
In-Reply-To: <alpine.LSU.0.99999.0712152124220.5151@castor.milkiway.cos>
Michael Dressel, Sat, Dec 15, 2007 21:33:20 +0100:
> On Sat, 15 Dec 2007, Alex Riesen wrote:
>> Michael Dressel, Sat, Dec 15, 2007 19:14:48 +0100:
>>>> Maybe. Or maybe you misunderstood the meaning of --squash, which also
>>>> is not a merge.
>>>
>>> Since "git merge --squash <branch>" does a merge of <branch> into the
>>> working tree why would you not call it a merge?
>>
>> Because merge, in Git language, means connection histories. That one
>> just mixes the text. That's different operation, kind of editing a
>> file.
>
> That's a nice clarification. In my case I wanted that "just mixes the text"
> thing because I did aggressively do commits during development trying out
> slightly different approaches and being able to go back to compare them.
> These different games are not interesting to keep in the history once a
> good solution has been found.
In this case --squash is almost right. "rebase -i" (interactive rebase)
still better: it'll allow you rebuild the development history in a
more fine-grained way. It can reorder commits, "mix" them together,
edit commit messages or just delete them altogether.
Try it, by the look of your situation you'll like it. Actually, it is
exactly why Johannes wrote it.
^ permalink raw reply
* Re: Windows binaries for qgit 2.0
From: Abdelrazak Younes @ 2007-12-16 11:11 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550712160242v54ce284emd31a29964770179c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
Marco Costalba wrote:
> On Dec 16, 2007 10:10 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
>> The MSVC compiled Qt dlls :-)
>> Sorry too, I guess I was not clear enough.
>>
>
> Yes please!
Actually you might prefer to just use the LyX dependencies package that
we provide for Windows developers, it contains Qt. I paste here the
relevant part of our 'INSTALL.Win32':
6 Install the dependencies
Download ftp://ftp.lyx.org/pub/lyx/contrib/lyx-windows-deps-msvc-qt4.zip
and extract in the root directory of your LyX files (so you will get
a directory called lyx-windows-deps-msvc-qt4 next to the other
directories like src, development etc.).
I also attach the complete file, you might find some interesting items
WRT compiling with MSVC.
Abdel.
[-- Attachment #2: INSTALL.Win32 --]
[-- Type: text/plain, Size: 5285 bytes --]
Compiling LyX 1.5 for Win32
===========================
LyX 1.5 can be compiled with Microsoft Visual C++ 2005 (recommended) or MinGW.
Compiling with MSVC 2005
========================
1 Install MSVC 2005 SP1
If you don't have MSVC 2005 installed, download and install the free
Express edition from http://msdn.microsoft.com/vstudio/express/visualc/
From this page you should also download and install Service Pack 1.
A hotfix needs to be installed because of a bug in the compiler.
Search for VS80sp1-KB930859-X86-ENU.exe on Google and install it.
2 Install the Windows Platform SDK
see: http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/
(You don't need to install the IIS, MDAC, and Tablet PC SDK that are
delivered with the Platform SDK.)
3 Configure MSVC
Follow exactly the steps of
http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/
In Step 3 follow also the things noted as alternative.
(If you later get an error message that "windows.h" cannot be found,
create the global Windows environment variables "INCLUDE" and "LIB".
INCLUDE contains the paths to the "include" folders of the installed
platform SDK and of MSVC. LIB contains the corresponding "lib" folders.)
4 Install Python
Get the latest Python 2.5 version at
http://www.python.org/download/releases/2.5/
Install in C:\Python25 and add this directory to the PATH environment
variable (Start > Settings > Control Panel > System > Advanced >
Environment Variables).
5 Install SCons
Download and install SCons 0.96.92 (or newer, but not 0.96.1) from http://www.scons.org/download.php
6 Install the dependencies
Download ftp://ftp.lyx.org/pub/lyx/contrib/lyx-windows-deps-msvc-qt4.zip
and extract in the root directory of your LyX files (so you will get
a directory called lyx-windows-deps-msvc-qt4 next to the other directories
like src, development etc.).
7 Compile
From MS Visual Studio command prompt (not the regular cmd.exe),
run
> cd <lyx root directory>\development\Win32\packaging
> build_msvc.bat
8 First start of LyX
To start the just compiled lyx.exe, it is necessary to copy the following
files to the folder where the just compiled "lyx.exe" is:
Aiksaurus.dll
aspell.dll
iconv.dll
intl.dll
Microsoft.VC80.CRT.manifest
msvcp80.dll
msvcr80.dll
QtCore4.dll
QtGui4.dll
msvcp80.dll and msvcr80.dll are the C Runtime and C++ libraries
supplied with MSVC 2005. They are freely redistributable.
See http://msdn2.microsoft.com/en-us/library/8kche8ah(VS.80).aspx
for details.
All of the other .dlls above and the lyx executable are compiled
from code released under the GPL which states (section 3) that
GPL software may be linked against system files such as msvcp80.dll
and msvcr80.dll.
Compiling with MinGW
====================
These instructions allow you to create a basic LyX build with MinGW.
To be able to use all LyX features, compiling with MSVC 2005 is recommended.
Creating an installer for MinGW builds is no longer supported.
1 Install MinGW, and all the gcc-related stuff, and win32api.
2 download qt-win-opensource-4.x.x-mingw.exe and install to c:\qt\4.2.2.
3 install python and scons as instructed above. Set $path for python
to make your life a bit easier.
4 Check out lyx svn to c:\lyx-devel\lyx-1.5.x
5 Download zlib binaries and developer files (zlib-1.2.3-bin.zip and
zlib-1.2.3-lib.zip) from http://gnuwin32.sourceforge.net/packages/zlib.htm
libiconv from http://gnuwin32.sourceforge.net/packages/libiconv.htm
gettext from http://gnuwin32.sourceforge.net/packages/gettext.htm
unpack all of them to the same directory c:\lyx-devel\mingw_deps.
6 start a command window, run commands:
$ cd c:\lyx-devel\lyx-1.5.x
$ scons -f development\scons\SConstruct \
extra_lib_path=..\mingw_deps\lib \
extra_inc_path=..\mingw_deps\include \
extra_bin_path=..\mingw_deps\bin \
qt_dir=c:\qt\4.2.2 \
DESTDIR=..\lyx-1.5-install \
install
Creating the Installer
======================
To create an installer with LyX and all related components, download
and install the latest NSIS from http://nsis.sourceforge.net
Open development\Win32\packaging\installer\setttings.user.nsh and modify
the settings depending on your build environment.
Finally, go to development\Win32\packaging\installer
(in a normal Windows Explorer), right-click on lyx.nsi and click
"Compile NSIS Script".
You can also use the installer target of scons. Namely, use a command like
$ scons -f development\scons\SConscript installer
This will create $BUILDDIR\lyx-version-timestamp-Installer.exe for a devel version,
and $BUILDDIR\lyx-version-Install.exe for a released version of lyx.
If you also want to generate bundled installer, download
lyx-windows-bundle-deps.zip from http://www.lyx.org/~bpeng, unpack
to lyx-windows-bundle-deps under the top source directory, and run
$ scons -f development\scons\SConstruct installer bundle=1
If you prefer to use another directory, you can use option bundle_dir like
$ scons -f development\scons\SConstruct installer bundle=1 bundle_dir=c:\bundle
^ permalink raw reply
* Re: [PATCH] threaded pack-objects: Use condition variables for thread communication.
From: Peter Baumann @ 2007-12-16 12:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Nicolas Pitre, git, Junio C Hamano
In-Reply-To: <200712160018.54171.johannes.sixt@telecom.at>
On Sun, Dec 16, 2007 at 12:18:53AM +0100, Johannes Sixt wrote:
> In the threaded pack-objects code the main thread and the worker threads
> must mutually signal that they have assigned a new pack of work or have
> completed their work, respectively. Previously, the code used mutexes that
> were locked in one thread and unlocked from a different thread, which is
> bogus (and happens to work on Linux).
>
> Here we rectify the implementation by using condition variables: There is
> one condition variable on which the main thread waits until a thread
> requests new work; and each worker thread has its own condition variable
> on which it waits until it is assigned new work or signaled to terminate.
>
> As a cleanup, the worker threads are spawned only after the initial work
> packages have been assigned.
>
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
> builtin-pack-objects.c | 129 +++++++++++++++++++++++++++++------------------
> 1 files changed, 79 insertions(+), 50 deletions(-)
>
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index 7dd0d7f..451e48e 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -1594,6 +1594,15 @@ static void find_deltas(struct object_entry **list, unsigned *list_size,
>
> #ifdef THREADED_DELTA_SEARCH
>
> +/*
> + * The main thread waits on the condition that (at least) one of the workers
> + * has stopped working (which is indicated in the .working member of
> + * struct thread_params).
> + * When a work thread has completed its work, it sets .working to 0 and
> + * signals the main thread and waits on the condition that .data_ready
> + * becomes 1.
> + */
> +
> struct thread_params {
> pthread_t thread;
> struct object_entry **list;
> @@ -1601,37 +1610,50 @@ struct thread_params {
> unsigned remaining;
> int window;
> int depth;
> + int working;
> + int data_ready;
> + pthread_mutex_t mutex;
> + pthread_cond_t cond;
> unsigned *processed;
> };
>
> -static pthread_mutex_t data_request = PTHREAD_MUTEX_INITIALIZER;
> -static pthread_mutex_t data_ready = PTHREAD_MUTEX_INITIALIZER;
> -static pthread_mutex_t data_provider = PTHREAD_MUTEX_INITIALIZER;
> -static struct thread_params *data_requester;
> +static pthread_cond_t progress_cond = PTHREAD_COND_INITIALIZER;
>
> static void *threaded_find_deltas(void *arg)
> {
> struct thread_params *me = arg;
>
> - for (;;) {
> - pthread_mutex_lock(&data_request);
> - data_requester = me;
> - pthread_mutex_unlock(&data_provider);
> - pthread_mutex_lock(&data_ready);
> - pthread_mutex_unlock(&data_request);
> -
> - if (!me->remaining)
> - return NULL;
> -
> + while (me->remaining) {
> find_deltas(me->list, &me->remaining,
> me->window, me->depth, me->processed);
> +
> + progress_lock();
> + me->working = 0;
> + progress_unlock();
> + pthread_cond_signal(&progress_cond);
Shouldn't the pthread_cond_signal be inside the lock?
e.g. swap progress_unlock() with pthread_cond_signal(&progress_cond)
> +
> + /*
> + * We must not set ->data_ready before we wait on the
> + * condition because the main thread may have set it to 1
> + * before we get here. In order to be sure that new
> + * work is available if we see 1 in ->data_ready, it
> + * was initialized to 0 before this thread was spawned
> + * and we reset it to 0 right away.
> + */
> + pthread_mutex_lock(&me->mutex);
> + while (!me->data_ready)
> + pthread_cond_wait(&me->cond, &me->mutex);
> + me->data_ready = 0;
> + pthread_mutex_unlock(&me->mutex);
> }
> + /* leave ->working 1 so that this doesn't get more work assigned */
> + return NULL;
> }
[...]
-Peter
^ permalink raw reply
* Re: Problem with git-svn
From: Peter Baumann @ 2007-12-16 13:56 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <4764FE2C.1010103@obry.net>
On Sun, Dec 16, 2007 at 11:30:04AM +0100, Pascal Obry wrote:
>
> I'm trying to use a Subversion repository with Git. I had
> great success with many repositories except one. This one
> live since long time and as been migrated from CVS to
> Subversion.
>
> The current Subversion repository contains multiple projects.
> Each project is under /trunk. While trying to import the project
> PROJ:
>
> $ git svn clone svn+ssh://myserver/trunk/PROJ
>
> I get:
>
> Initialized empty Git repository in .git/
> W: Ignoring error from SVN, path probably does not exist: (160013):
> Filesystem has no item: File not found: revision 100, path '/trunk/PROJ'
> Found possible branch point: svn+ssh://myserver/importfromcvs/trunk =>
> svn+ssh://myserver/trunk/PROJ, 48467
> Initializing parent: git-svn@48467
> W: Ignoring error from SVN, path probably does not exist: (160013):
> Filesystem has no item: File not found: revision 101, path
> '/importfromcvs/trunk'
> r9458 = b90789186c85a19a9f32ea6dc8a4259e2eadef67 (git-svn@48467)
> A file.el
>
> But file.el is not part of this project, it is part of another one
> on the same Subversion repository. It looks like git-svn get confused
> at some point. I've been trying to track this down, but since I've
> never written a single Perl script that's not easy :(
>
> Note that AFAIK each CVS modules have been imported into
> /importfromcvs/trunk then move into /trunk/<MODULE_NAME>.
>
> r48467 seem ok as a branch point:
>
> <<
> ------------------------------------------------------------------------
> r48468 | svn | 2007-05-09 15:10:54 +0200 (Wed, 09 May 2007) | 1 line
> Changed paths:
> D /importfromcvs/trunk
> A /trunk/PROJ (from /importfromcvs/trunk:48467)
>
> Importing module PROJ into SVN.
> >>
>
> So I'm looking for hints about the possible problem.
>
> Note that I have tried to reproduce this with a small
> script (using the same repository structure) but I was
> not able.
>
> Thanks,
> Pascal.
>
Eric made a fix[1] this week so git-svn won't get confused if e.g. trunk
gets deleted and later created (or e.g. moved). Could you check if it
also fixes your problem? At least there is some familiarity, because your
trunk/PROJ also get moved from outside a path git-svn isn't tracking.
-Peter
[1]: See this thread for more details
http://thread.gmane.org/gmane.comp.version-control.git/67665
^ permalink raw reply
* Re: [PATCH v2] Allow commit (and tag) messages to be edited when $EDITOR has arguments
From: Johannes Schindelin @ 2007-12-16 15:36 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20071216073408.GA5343@midwinter.com>
Hi,
On Sat, 15 Dec 2007, Steven Grimm wrote:
> @@ -238,7 +186,7 @@ struct cmd_struct {
> int option;
> };
>
> -static int run_command(struct cmd_struct *p, int argc, const char **argv)
> +static int run_git_command(struct cmd_struct *p, int argc, const char **argv)
> {
> int status;
> struct stat st;
Funny ;-) I have a similar change in my (now-inactive until 1.5.4) tree,
but I renamed it to execv_git_builtin (because it is not supposed to
return in case of success).
> diff --git a/run-command.c b/run-command.c
> index 476d00c..3ae55ec 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -237,3 +237,68 @@ int finish_async(struct async *async)
> ret = error("waitpid (async) failed");
> return ret;
> }
> +
> +/*
> + * Parses a command line into an array of char* representing the tokens
> + * on the command line. Pass in a count to reserve some number of additional
> + * slots in the allocated array, e.g., so the caller can add a filename
> + * argument without having to reallocate the array.
In the editor call, you said "2" for this, but I suspect that you counted
the NULL extra. However, in git.c you said "0", thus not counting the
NULL. IMHO it makes sense _not_ to count the NULL (and NULL-terminate
the list _always_).
> +int split_cmdline(char *cmdline, const char ***argv, int extra_slots)
> +{
> + int src, dst, count = 0, size = extra_slots + 16;
> + char quoted = 0;
> +
> + *argv = xmalloc(sizeof(char*) * size);
> +
> + /* split alias_string */
s/alias_string/the command line/
> + (*argv)[count++] = cmdline;
> + for (src = dst = 0; cmdline[src];) {
> + char c = cmdline[src];
> + if (!quoted && isspace(c)) {
> + cmdline[dst++] = 0;
> + while (cmdline[++src]
> + && isspace(cmdline[src]))
> + ; /* skip */
> + if (count >= size) {
s/count/count + extra_slots/
> + size += 16;
> + *argv = xrealloc(*argv, sizeof(char*) * size);
This seems a nice candidate for ALLOC_GROW() in any case:
ALLOC_GROW(*argv, count + extra_slots + 1, size);
> + }
> + (*argv)[count++] = cmdline + dst;
> + } else if(!quoted && (c == '\'' || c == '"')) {
> + quoted = c;
> + src++;
> + } else if (c == quoted) {
> + quoted = 0;
> + src++;
> + } else {
> + if (c == '\\' && quoted != '\'') {
> + src++;
> + c = cmdline[src];
> + if (!c) {
> + free(*argv);
> + *argv = NULL;
> + return error("cmdline ends with \\");
> + }
> + }
> + cmdline[dst++] = c;
> + src++;
> + }
> + }
> +
> + cmdline[dst] = 0;
> +
> + if (quoted) {
> + free(*argv);
> + *argv = NULL;
> + return error("unclosed quote");
> + }
AFAICT the argv were not NULL terminated before. But now that the
function is public, it is safer to do so:
(*argv)[count] = NULL;
> +
> + return count;
> +}
> +
Thanks,
Dscho
^ permalink raw reply
* Re: One of my commits is missing
From: Johannes Schindelin @ 2007-12-16 15:37 UTC (permalink / raw)
To: Luke Diamand; +Cc: Shawn O. Pearce, git
In-Reply-To: <4764EBC3.4090800@vidanti.com>
Dscho
Ciao,
it?
was
what
so,
Hi,
On Sun, 16 Dec 2007, Luke Diamand wrote:
> Thanks! That found it.
>
> Shawn O. Pearce wrote:
> > Luke Diamand <luke@vidanti.com> wrote:
> > > My last commit seems to have vanished, and I wonder if anyone knows where
> > > it might have gone.
> > ...
> > > Looking through my history I don't see any signs of errant git-reset's so
> > > I'm baffled.
> >
> >
> > I'm baffled too. Have a look at your HEAD reflog and see if you
> > can find it there (`git log -g`) as if you actually did in fact
> > create it with git-commit it should appear in that reflog for at
> > least the next 90 days (by default config anyway).
> >
>
> -
> 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
* Re: Problem with git-svn
From: Pascal Obry @ 2007-12-16 15:40 UTC (permalink / raw)
To: Peter Baumann; +Cc: git list
In-Reply-To: <20071216135625.GB4999@xp.machine.xx>
Pete,
> Eric made a fix[1] this week so git-svn won't get confused if e.g. trunk
> gets deleted and later created (or e.g. moved). Could you check if it
> also fixes your problem? At least there is some familiarity, because your
> trunk/PROJ also get moved from outside a path git-svn isn't tracking.
>
> -Peter
>
> [1]: See this thread for more details
> http://thread.gmane.org/gmane.comp.version-control.git/67665
This fix is already installed into the Git version I'm using which is:
git version 1.5.4.rc0.36.g7680
So there is something else...
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [PATCH] whitespace: fix initial-indent checking
From: J. Bruce Fields @ 2007-12-16 16:26 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Jakub Narebski, Git Mailing List, Junio Hamano
In-Reply-To: <25FDB05F-3E85-4E08-90BE-1BE468C07805@wincent.com>
On Sun, Dec 16, 2007 at 11:00:55AM +0100, Wincent Colaiuta wrote:
> El 16/12/2007, a las 10:08, Jakub Narebski escribió:
>
>> J. Bruce Fields wrote:
>>
>>> This allows catching initial indents like '\t ' (a tab followed
>>> by 8 spaces), while previously indent-with-non-tab caught only indents
>>> that consisted entirely of spaces.
>>
>> I prefer to use tabs for indent, but _spaces_ for align. While previous,
>> less strict version of check catches indent using spaces, this one also
>> catches _align_ using spaces.
No, the previous version didn't work for the align-with-spaces case
either. Consider, for example,
struct widget *find_widget_by_color(struct color *color,
int nth_match, unsigned long flags)
If following a "indent-with-tabs, align-with-spaces" policy, then the
initial whitespaace on the second line should be purely spaces
(otherwise adjusting the tab stops would ruin the alignment). But
indent-with-non-tab would flag this as incorrect even before my fix.
> I'd say that Jakub's is a fairly common use case (it's used in many places
> in the Git codebase too, I think) so it would be a bad thing to change the
> behaviour of "indent-with-non-tab".
>
> If you also want to check for "align-with-non-tab" then it really should be
> a separate, optional class of whitespace error.
I would agree with you if it were not for the fact that if you're using
an "indent-with-tabs, align-with-spaces" policy then the only indent
whitespace problems that you can flag automatically are space-before-tab
problems; anything else requires knowledge of the language syntax.
So indent-with-non-tab has only ever been useful for projects that
insist on tabs for all sequences of 8 spaces in the initial whitespace.
--b.
^ permalink raw reply
* [PATCH 1/6] whitespace: fix off-by-one error in non-space-in-indent checking
From: J. Bruce Fields @ 2007-12-16 16:31 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, J. Bruce Fields
In-Reply-To: <1197822702-5262-1-git-send-email-bfields@citi.umich.edu>
If there were no tabs, and the last space was at position 7, then
positions 0..7 had spaces, so there were 8 spaces.
Update test to check exactly this case.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
t/t4015-diff-whitespace.sh | 4 ++--
ws.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index 9bff8f5..0f16bca 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -298,7 +298,7 @@ test_expect_success 'check space before tab in indent (space-before-tab: on)' '
test_expect_success 'check spaces as indentation (indent-with-non-tab: off)' '
git config core.whitespace "-indent-with-non-tab"
- echo " foo ();" > x &&
+ echo " foo ();" > x &&
git diff --check
'
@@ -306,7 +306,7 @@ test_expect_success 'check spaces as indentation (indent-with-non-tab: off)' '
test_expect_success 'check spaces as indentation (indent-with-non-tab: on)' '
git config core.whitespace "indent-with-non-tab" &&
- echo " foo ();" > x &&
+ echo " foo ();" > x &&
! git diff --check
'
diff --git a/ws.c b/ws.c
index 46cbdd6..5ebd109 100644
--- a/ws.c
+++ b/ws.c
@@ -159,5 +159,5 @@ unsigned check_and_emit_line(const char *line, int len, unsigned ws_rule,
}
/* Check for indent using non-tab. */
- if ((ws_rule & WS_INDENT_WITH_NON_TAB) && leading_space >= 8)
+ if ((ws_rule & WS_INDENT_WITH_NON_TAB) && leading_space >= 7)
result |= WS_INDENT_WITH_NON_TAB;
\ No newline at end of file
--
1.5.4.rc0.41.gf723
^ permalink raw reply related
* Re: [PATCH] whitespace: reorganize initial-indent check
From: J. Bruce Fields @ 2007-12-16 16:31 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <B54C9483-90BE-4B45-A3B7-39FACF0E9F62@wincent.com>
Wincent Colaiuta wrote:
> Any chance of either squashing this series into one patch seeing as
> its all churning over the same part of the code, or resending it with
> numbering? The patches seemed to arrive out of order in my mailbox
> and I don't really know what order they're supposed to be applied in
> and it's a bit hard to review.
Apologies--I forgot the -n on format-patch.... Here you go. Thanks for
the review.
--b.
^ permalink raw reply
* [PATCH 2/6] whitespace: reorganize initial-indent check
From: J. Bruce Fields @ 2007-12-16 16:31 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, J. Bruce Fields
In-Reply-To: <1197822702-5262-2-git-send-email-bfields@citi.umich.edu>
Reorganize to emphasize the most complicated part of the code (the tab
case).
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
ws.c | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/ws.c b/ws.c
index 5ebd109..7165874 100644
--- a/ws.c
+++ b/ws.c
@@ -146,16 +146,15 @@ unsigned check_and_emit_line(const char *line, int len, unsigned ws_rule,
/* Check for space before tab in initial indent. */
for (i = 0; i < len; i++) {
- if (line[i] == '\t') {
- if ((ws_rule & WS_SPACE_BEFORE_TAB) &&
- (leading_space != -1))
- result |= WS_SPACE_BEFORE_TAB;
- break;
- }
- else if (line[i] == ' ')
+ if (line[i] == ' ') {
leading_space = i;
- else
+ continue;
+ }
+ if (line[i] != '\t')
break;
+ if ((ws_rule & WS_SPACE_BEFORE_TAB) && (leading_space != -1))
+ result |= WS_SPACE_BEFORE_TAB;
+ break;
}
/* Check for indent using non-tab. */
--
1.5.4.rc0.41.gf723
^ permalink raw reply related
* [PATCH 4/6] whitespace: fix initial-indent checking
From: J. Bruce Fields @ 2007-12-16 16:31 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, J. Bruce Fields
In-Reply-To: <1197822702-5262-4-git-send-email-bfields@citi.umich.edu>
After this patch, "written" counts the number of bytes up to and
including the most recently seen tab. This allows us to detect (and
count) spaces by comparing to "i".
This allows catching initial indents like '\t ' (a tab followed
by 8 spaces), while previously indent-with-non-tab caught only indents
that consisted entirely of spaces.
This also allows fixing an indent-with-non-tab regression, so we can
again detect indents like '\t \t'.
Also update tests to catch these cases.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
t/t4015-diff-whitespace.sh | 15 +++++++++++++++
ws.c | 10 ++++------
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index 0f16bca..d30169f 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -125,6 +125,14 @@ test_expect_success 'check mixed spaces and tabs in indent' '
'
+test_expect_success 'check mixed tabs and spaces in indent' '
+
+ # This is indented with HT SP HT.
+ echo " foo();" > x &&
+ git diff --check | grep "space before tab in indent"
+
+'
+
test_expect_success 'check with no whitespace errors' '
git commit -m "snapshot" &&
@@ -311,4 +319,11 @@ test_expect_success 'check spaces as indentation (indent-with-non-tab: on)' '
'
+test_expect_success 'check tabs and spaces as indentation (indent-with-non-tab: on)' '
+
+ git config core.whitespace "indent-with-non-tab" &&
+ echo " foo ();" > x &&
+ ! git diff --check
+
+'
test_done
diff --git a/ws.c b/ws.c
index 1b32e45..aabd509 100644
--- a/ws.c
+++ b/ws.c
@@ -146,19 +146,17 @@ unsigned check_and_emit_line(const char *line, int len, unsigned ws_rule,
/* Check for space before tab in initial indent. */
for (i = 0; i < len; i++) {
- if (line[i] == ' ') {
- written = i + 1;
+ if (line[i] == ' ')
continue;
- }
if (line[i] != '\t')
break;
- if ((ws_rule & WS_SPACE_BEFORE_TAB) && (written != 0))
+ if ((ws_rule & WS_SPACE_BEFORE_TAB) && written < i)
result |= WS_SPACE_BEFORE_TAB;
- break;
+ written = i + 1;
}
/* Check for indent using non-tab. */
- if ((ws_rule & WS_INDENT_WITH_NON_TAB) && written >= 8)
+ if ((ws_rule & WS_INDENT_WITH_NON_TAB) && i - written >= 8)
result |= WS_INDENT_WITH_NON_TAB;
if (stream) {
--
1.5.4.rc0.41.gf723
^ permalink raw reply related
* [PATCH 3/6] whitespace: minor cleanup
From: J. Bruce Fields @ 2007-12-16 16:31 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, J. Bruce Fields
In-Reply-To: <1197822702-5262-3-git-send-email-bfields@citi.umich.edu>
The variable leading_space is initially used to represent the index of
the last space seen before a non-space. Then later it represents the
index of the first non-indent character.
It will prove simpler to replace it by a variable representing a number
of bytes. Eventually it will represent the number of bytes written so
far (in the stream != NULL case).
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
ws.c | 21 +++++++++------------
1 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/ws.c b/ws.c
index 7165874..1b32e45 100644
--- a/ws.c
+++ b/ws.c
@@ -121,7 +121,7 @@ unsigned check_and_emit_line(const char *line, int len, unsigned ws_rule,
const char *reset, const char *ws)
{
unsigned result = 0;
- int leading_space = -1;
+ int written = 0;
int trailing_whitespace = -1;
int trailing_newline = 0;
int i;
@@ -147,18 +147,18 @@ unsigned check_and_emit_line(const char *line, int len, unsigned ws_rule,
/* Check for space before tab in initial indent. */
for (i = 0; i < len; i++) {
if (line[i] == ' ') {
- leading_space = i;
+ written = i + 1;
continue;
}
if (line[i] != '\t')
break;
- if ((ws_rule & WS_SPACE_BEFORE_TAB) && (leading_space != -1))
+ if ((ws_rule & WS_SPACE_BEFORE_TAB) && (written != 0))
result |= WS_SPACE_BEFORE_TAB;
break;
}
/* Check for indent using non-tab. */
- if ((ws_rule & WS_INDENT_WITH_NON_TAB) && leading_space >= 7)
+ if ((ws_rule & WS_INDENT_WITH_NON_TAB) && written >= 8)
result |= WS_INDENT_WITH_NON_TAB;
if (stream) {
@@ -166,23 +166,20 @@ unsigned check_and_emit_line(const char *line, int len, unsigned ws_rule,
if ((result & WS_SPACE_BEFORE_TAB) ||
(result & WS_INDENT_WITH_NON_TAB)) {
fputs(ws, stream);
- fwrite(line, leading_space + 1, 1, stream);
+ fwrite(line, written, 1, stream);
fputs(reset, stream);
- leading_space++;
}
- else
- leading_space = 0;
- /* Now the rest of the line starts at leading_space.
+ /* Now the rest of the line starts at written.
* The non-highlighted part ends at trailing_whitespace. */
if (trailing_whitespace == -1)
trailing_whitespace = len;
/* Emit non-highlighted (middle) segment. */
- if (trailing_whitespace - leading_space > 0) {
+ if (trailing_whitespace - written > 0) {
fputs(set, stream);
- fwrite(line + leading_space,
- trailing_whitespace - leading_space, 1, stream);
+ fwrite(line + written,
+ trailing_whitespace - written, 1, stream);
fputs(reset, stream);
}
--
1.5.4.rc0.41.gf723
^ permalink raw reply related
* [PATCH 6/6] whitespace: fix config.txt description of indent-with-non-tab
From: J. Bruce Fields @ 2007-12-16 16:31 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, J. Bruce Fields
In-Reply-To: <1197822702-5262-6-git-send-email-bfields@citi.umich.edu>
Fix garbled description.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/config.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index fabe7f8..ce16fc7 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -307,7 +307,7 @@ core.whitespace::
before a tab character in the initial indent part of the line as an
error (enabled by default).
* `indent-with-non-tab` treats a line that is indented with 8 or more
- space characters that can be replaced with tab characters.
+ space characters as an error (not enabled by default).
alias.*::
Command aliases for the gitlink:git[1] command wrapper - e.g.
--
1.5.4.rc0.41.gf723
^ permalink raw reply related
* [PATCH 5/6] whitespace: more accurate initial-indent highlighting
From: J. Bruce Fields @ 2007-12-16 16:31 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, J. Bruce Fields
In-Reply-To: <1197822702-5262-5-git-send-email-bfields@citi.umich.edu>
Instead of highlighting the entire initial indent, highlight only the
problematic spaces.
In the case of an indent like ' \t \t' there may be multiple problematic
ranges, so it's easiest to emit the highlighting as we go instead of
trying rember disjoint ranges and do it all at the end.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
ws.c | 24 ++++++++++++++++--------
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/ws.c b/ws.c
index aabd509..d09b9df 100644
--- a/ws.c
+++ b/ws.c
@@ -150,24 +150,32 @@ unsigned check_and_emit_line(const char *line, int len, unsigned ws_rule,
continue;
if (line[i] != '\t')
break;
- if ((ws_rule & WS_SPACE_BEFORE_TAB) && written < i)
+ if ((ws_rule & WS_SPACE_BEFORE_TAB) && written < i) {
result |= WS_SPACE_BEFORE_TAB;
+ if (stream) {
+ fputs(ws, stream);
+ fwrite(line + written, i - written, 1, stream);
+ fputs(reset, stream);
+ }
+ } else if (stream)
+ fwrite(line + written, i - written, 1, stream);
+ if (stream)
+ fwrite(line + i, 1, 1, stream);
written = i + 1;
}
/* Check for indent using non-tab. */
- if ((ws_rule & WS_INDENT_WITH_NON_TAB) && i - written >= 8)
+ if ((ws_rule & WS_INDENT_WITH_NON_TAB) && i - written >= 8) {
result |= WS_INDENT_WITH_NON_TAB;
-
- if (stream) {
- /* Highlight errors in leading whitespace. */
- if ((result & WS_SPACE_BEFORE_TAB) ||
- (result & WS_INDENT_WITH_NON_TAB)) {
+ if (stream) {
fputs(ws, stream);
- fwrite(line, written, 1, stream);
+ fwrite(line + written, i - written, 1, stream);
fputs(reset, stream);
}
+ written = i;
+ }
+ if (stream) {
/* Now the rest of the line starts at written.
* The non-highlighted part ends at trailing_whitespace. */
if (trailing_whitespace == -1)
--
1.5.4.rc0.41.gf723
^ permalink raw reply related
* [PATCH 2/2] builtin-apply: stronger indent-with-on-tab fixing
From: J. Bruce Fields @ 2007-12-16 17:58 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, Junio C Hamano, J. Bruce Fields
In-Reply-To: <1197827882-11710-2-git-send-email-bfields@citi.umich.edu>
Fix any sequence of 8 spaces in initial indent, not just the case where
the 8 spaces are the first thing on the line.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
builtin-apply.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index bd94a4b..5e3b4a1 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1587,8 +1587,7 @@ static int apply_line(char *output, const char *patch, int plen,
} else if (ch == ' ') {
last_space_in_indent = i;
if ((ws_rule & WS_INDENT_WITH_NON_TAB) &&
- last_tab_in_indent <= 0 &&
- 8 <= i)
+ 8 <= i - last_tab_in_indent)
need_fix_leading_space = 1;
}
else
--
1.5.4.rc0.44.g21147
^ permalink raw reply related
* [PATCH 1/2] builtin-apply: minor cleanup of whitespace detection
From: J. Bruce Fields @ 2007-12-16 17:58 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, Junio C Hamano, J. Bruce Fields
In-Reply-To: <1197827882-11710-1-git-send-email-bfields@citi.umich.edu>
Use 0 instead of -1 for the case where not tabs or spaces are found; it
will make some later math slightly simpler.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
builtin-apply.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 2edd83b..bd94a4b 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1550,8 +1550,8 @@ static int apply_line(char *output, const char *patch, int plen,
int i;
int add_nl_to_tail = 0;
int fixed = 0;
- int last_tab_in_indent = -1;
- int last_space_in_indent = -1;
+ int last_tab_in_indent = 0;
+ int last_space_in_indent = 0;
int need_fix_leading_space = 0;
char *buf;
@@ -1582,12 +1582,12 @@ static int apply_line(char *output, const char *patch, int plen,
if (ch == '\t') {
last_tab_in_indent = i;
if ((ws_rule & WS_SPACE_BEFORE_TAB) &&
- 0 <= last_space_in_indent)
+ 0 < last_space_in_indent)
need_fix_leading_space = 1;
} else if (ch == ' ') {
last_space_in_indent = i;
if ((ws_rule & WS_INDENT_WITH_NON_TAB) &&
- last_tab_in_indent < 0 &&
+ last_tab_in_indent <= 0 &&
8 <= i)
need_fix_leading_space = 1;
}
--
1.5.4.rc0.44.g21147
^ permalink raw reply related
* builtin-apply whitespace
From: J. Bruce Fields @ 2007-12-16 17:58 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, Junio C Hamano
In-Reply-To: <1197822702-5262-7-git-send-email-bfields@citi.umich.edu>
Apologies, I just realized I also forgot to do the corresponding fix on
the apply side. Here they are. These are also available at
git://linux-nfs.org/~bfields/git.git master
--b.
^ 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