* Re: Windows support
From: Jakub Narebski @ 2007-07-26 21:39 UTC (permalink / raw)
To: git
In-Reply-To: <f329bf540707260018u21ad8e16h75cc9c3351fe0fc2@mail.gmail.com>
Han-Wen Nienhuys wrote:
> 2007/7/26, Shawn O. Pearce <spearce@spearce.org>:
>> Han-Wen Nienhuys <hanwenn@gmail.com> wrote:
>>> I would suggest to making a clear
>>> decision of what are recommended languages, and move everything else
>>> to contrib/ .. Currently, C and bash seem the most reasonable choice,
>>> but you could decide for perl, but then the consequence should be that
>>> the bash scripts are translated into perl. Having both bash and perl
>>> serves no purpose, and will lead to duplication of library code to
>>> interact with the git binary.
>>
>> Sure, but there's some stuff that shell is good at, and other stuff
>> that Perl is good at. Forcing everything into one mold while we
>> prototype new features is really limiting.
>
> I'm not contradicting that, but merely suggesting that they go into
> contrib/ and are not recommended as standard git commands, and don't
> need to be packaged for windows.
They can be not packaged for windows, but for example git-send-email
(which is written in Perl) is IMHO important enough to be in git proper
and not delegated to contrib/; but it is packaged in separate RPM,
git-email. Same with git-svn package...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* t9400-git-cvsserver-server (9, 11, 13)
From: Brian Gernhardt @ 2007-07-26 20:43 UTC (permalink / raw)
To: Git Mailing List
I'm still getting failures on t9400-git-cvsserver-server. This
appears to still be due to the fact that git-cvsserver is exiting
with -1, which test_expect_failure doesn't like. I have to assume
this isn't happening on other people's machines. If I can help
someone with tracking down this error, I would be happy to.
~~ Brian Gernhardt
output of ./t9400-git-cvsserver-server.sh -v -d
* ok 8: req_Root (strict paths)
* expecting failure: cat request-anonymous | git-cvsserver --strict-
paths pserver $WORKDIR >log 2>&1
* FAIL 9: req_Root failure (strict-paths)
cat request-anonymous | git-cvsserver --strict-paths pserver
$WORKDIR >log 2>&1
* expecting success: cat request-anonymous | git-cvsserver pserver
$WORKDIR/ >log 2>&1 &&
tail -n1 log | grep -q "^I LOVE YOU$"
* ok 10: req_Root (w/o strict-paths)
* expecting failure: cat request-anonymous | git-cvsserver pserver
$WORKDIR/gitcvs >log 2>&1
* FAIL 11: req_Root failure (w/o strict-paths)
cat request-anonymous | git-cvsserver pserver $WORKDIR/
gitcvs >log 2>&1
* expecting success: cat request-base | git-cvsserver --strict-paths
--base-path $WORKDIR/ pserver $SERVERDIR >log 2>&1 &&
tail -n1 log | grep -q "^I LOVE YOU$"
* ok 12: req_Root (base-path)
* expecting failure: cat request-anonymous | git-cvsserver --strict-
paths --base-path $WORKDIR pserver $SERVERDIR >log 2>&1
* FAIL 13: req_Root failure (base-path)
cat request-anonymous | git-cvsserver --strict-paths --base-
path $WORKDIR pserver $SERVERDIR >log 2>&1
* expecting success: cat request-anonymous | git-cvsserver --export-
all pserver $WORKDIR >log 2>&1 &&
tail -n1 log | grep -q "^I LOVE YOU$"
* ok 14: req_Root (export-all)
^ permalink raw reply
* [PATCH] Document commit.template configuration variable.
From: Brian Gernhardt @ 2007-07-26 20:34 UTC (permalink / raw)
To: git
Add it to the list in config.txt and explicitly say that the
--template option to git-commit overrides the configuration variable.
---
d1cc130a5eb50d5bfe1e8b76cab3d8970fd70ad1 added a config var, but
didn't add it to the full list.
Documentation/config.txt | 3 +++
Documentation/git-commit.txt | 5 ++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index dd98d95..3135cb7 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -393,6 +393,9 @@ color.status.<slot>::
or `untracked` (files which are not tracked by git). The values of
these variables may be specified as in color.branch.<slot>.
+commit.template::
+ Specify a file to use as the template for new commit messages.
+
diff.renameLimit::
The number of files to consider when performing the copy/rename
detection; equivalent to the git diff option '-l'.
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 3f36c67..627994e 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -78,9 +78,8 @@ OPTIONS
Use the contents of the given file as the initial version
of the commit message. The editor is invoked and you can
make subsequent changes. If a message is specified using
- the `-m` or `-F` options, this option has no effect. The
- template file may also be specified using the `commit.template`
- configuration variable.
+ the `-m` or `-F` options, this option has no effect. This
+ overrides the `commit.template` configuration variable.
-s|--signoff::
Add Signed-off-by line at the end of the commit message.
--
1.5.3.rc2.38.g11308
^ permalink raw reply related
* Re: git log and --first-parent
From: Robin Rosenberg @ 2007-07-26 20:30 UTC (permalink / raw)
To: git
In-Reply-To: <200707240105.33729.robin.rosenberg.lists@dewire.com>
tisdag 24 juli 2007 skrev Robin Rosenberg:
>
> I'm puzzled over the behavior of --first-parent. The documentations seems to imply
> that only the first parent is followed, but when a filter is applied it seems (just guessing)
> that the "first" parent is selected *after* filtering, a behaviour that I feel does not match
> the documentation.
>
> Should the first-parent filter be applied first.
>
> Example:
>
> git log --first-parent --pretty=format: --name-only v1.5.2|grep ^var.c|wc -l
>
> counts four commits where var.c was changed, while
>
> git log --first-parent --pretty=format: --name-only v1.5.2 -- var.c |wc -l
>
> gives me 23.
>
> -- robin
Now, I also realize fast-forwards means --first-parent may not be as useful as I first
hoped.
-- robin
^ permalink raw reply
* Re: Windows support
From: David Kastrup @ 2007-07-26 20:04 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0707261239t6479a4f4j6dedfbaef7206535@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 7/26/07, David Kastrup <dak@gnu.org> wrote:
>> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
>> > No it's not. With a couple of ifdefs you can compile it fine. Then
>> > there goes fork(), fcntl(F_DUPFD), /dev/*, job/signal handling...
>> > Fortunately Git does not use lots of features. It only needs
>> > /dev/null (and /dev/zero for tests), SIGEXIT and no job usage.. That
>> > cuts down the effort porting ash.
>>
>> And here I was tempted to multithread builtin-update-index.c: it is
>> actually quite natural to let one process scan directories
>> non-recursively, stat the files, sort them on a per-directory grain
>> and feed a sorted pseudo-index into a pipeline (recursing to scanning
>> whenever hitting a directory), then let another process/thread do a
>> merge-pass of pseudo-index and real index, immediately writing the
>> output to a new index-to-be. When this is finished and another
>> process invalidated the old index already, reuse the index-to-be as
>> pseudo-index and merge it with the new-index-which-got-in-ahead-of-me.
>>
> (snip)
>
> If you are going to do it. I suggest to base on official mingw
> branch.
Why would I do that? I am not using Windows. Since Windows NT was
flaunting threads big style years before Linux, I should not think
this implementation approach really to be a major porting hurdle, at
least if one indeed uses pipes for the IPC.
It should actually be doable with a clone system call or
pthread_create, whatever is easier to translate into Windows
semantics. The latter probably is more portable nowadays.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Windows support
From: Christian MICHON @ 2007-07-26 20:02 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Marius Storm-Olsen, git, Johannes Schindelin
In-Reply-To: <fcaeb9bf0707261243v65f6e9deof8e266590e05d49f@mail.gmail.com>
On 7/26/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> I cross-compile all the time (and test it on Windows when I have one,
> on the buggy Wine when not). I'd absolutely appreciate bug reports
> regarding building it on Windows ;-)
earlier on, when I reported a successful compilation and few problems
while committing, it was on XP. I'll be offline for the next 2 weeks,
but I can dedicate some time to your porting.
I second also what Dscho said. You'd be my hero too if porting
bbox over XP. Imagine "bbox + tcc + make + git"...
:)
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu
^ permalink raw reply
* Re: Windows support
From: Nguyen Thai Ngoc Duy @ 2007-07-26 19:43 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: git, Johannes Schindelin
In-Reply-To: <46A8D2BE.7070309@trolltech.com>
On 7/26/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> Nguyen Thai Ngoc Duy wrote:
> > On 7/26/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >> Thank you for working on this!
> >>
> >> However, I am not completely convinced that having a builtin shell is all
> >> that useful. I for one would like to have MinGW busybox _separate_ from
> >> git...
> >
> > I make MinGW busybox part of git for some reasons:
> >
> > - Making a full MinGW busybox would take lots of time. I don't need
> > busybox for Windows. What I need is a shell and enough POSIX utilities
> > to run git shell scripts without any dependencies. Windows users
> > (including myself when I have to use Windows) hate dependencies.
> > - I don't want MinGW busybox to be used outside of git (if it is
> > installed separated from git), there are cygwin and msys already. I
> > don't want to compete them. And I don't like conflicts (not sure
> > though) because you have multiple UNIX emulations on the same system.
> (..snip..)
>
> Hi Duy,
>
> *drool*
> This was an extremely good idea! Thank you so much for working on it!
> I'll be sure to play around with it, and see if there's any way I can
> help out. Guess I finally have to get that MinGW compile environment set
> up then :-)
>
> Btw, are you compiling with MinGW on Windows, or cross-compiling on Linux?
I cross-compile all the time (and test it on Windows when I have one,
on the buggy Wine when not). I'd absolutely appreciate bug reports
regarding building it on Windows ;-)
--
Duy
^ permalink raw reply
* Re: [PATCH] Fix git_mkstemp to return an error when path is too long.
From: Carlos Rica @ 2007-07-26 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vabtjbxip.fsf@assigned-by-dhcp.cox.net>
I like that new solution. ENAMETOOLONG is fantastic!
Usually, the function is called using the long PATH_MAX constant,
however, the function doesn't force you to supply an insanely long
buffer like that, and therefore is nice to say when the limit is exceeded.
^ permalink raw reply
* Re: Windows support
From: Nguyen Thai Ngoc Duy @ 2007-07-26 19:39 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Schindelin, git
In-Reply-To: <8564478243.fsf@lola.goethe.zz>
On 7/26/07, David Kastrup <dak@gnu.org> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > On 7/26/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >> Hi,
> >>
> >> On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> >>
> >> > I make MinGW busybox part of git for some reasons:
> >> >
> >> > - Making a full MinGW busybox would take lots of time. I don't need
> >> > busybox for Windows. What I need is a shell and enough POSIX utilities
> >> > to run git shell scripts without any dependencies. Windows users
> >> > (including myself when I have to use Windows) hate dependencies.
> >>
> >> I think that if you succeed to compile ash on MinGW, the rest is easy.
> >
> > No it's not. With a couple of ifdefs you can compile it fine. Then
> > there goes fork(), fcntl(F_DUPFD), /dev/*, job/signal handling...
> > Fortunately Git does not use lots of features. It only needs
> > /dev/null (and /dev/zero for tests), SIGEXIT and no job usage.. That
> > cuts down the effort porting ash.
>
> And here I was tempted to multithread builtin-update-index.c: it is
> actually quite natural to let one process scan directories
> non-recursively, stat the files, sort them on a per-directory grain
> and feed a sorted pseudo-index into a pipeline (recursing to scanning
> whenever hitting a directory), then let another process/thread do a
> merge-pass of pseudo-index and real index, immediately writing the
> output to a new index-to-be. When this is finished and another
> process invalidated the old index already, reuse the index-to-be as
> pseudo-index and merge it with the new-index-which-got-in-ahead-of-me.
>
(snip)
If you are going to do it. I suggest to base on official mingw branch.
I haven't looked at builtin-update-index.c (hey, I'm all doing sh
scripts these days) so no comments here.
--
Duy
^ permalink raw reply
* Re: [PATCH] fully resolve symlinks when creating lockfiles
From: Morten Welinder @ 2007-07-26 19:34 UTC (permalink / raw)
To: Bradford C. Smith; +Cc: git
In-Reply-To: <11854712542350-git-send-email-bradford.carl.smith@gmail.com>
Why the lstat and that stat in the beginning? That's just asking for race
condition. readlink will tell you if it wasn't a link, for example.
Morten
^ permalink raw reply
* Re: [PATCH 1/5] Add is_absolute_path(), make_absolute_path() and normalize_path()
From: Johannes Schindelin @ 2007-07-26 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pjr80lr.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 26 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Agree. Maybe a comment above the function, like
> >
> > /*
> > * The function normalize_path() converts ".." and "." names in
> > * the given path so that "foo/../bar/./" will come out as "bar".
> > *
> > * Note: normalize_path() does not follow symlinks, so if "foo" is
> > * a symlink in the example above, the result will not work as
> > * expected.
> > */
> >
> > Hmm?
>
> That comment only states the obvious and does not give a clue to
> the callers when it should not be used, I am afraid.
I am afraid, that it was unobvious enough to yours truly to forget about
that when writing the patch.
> For example, paths taken out of index or recursively reading trees are
> Ok because there will not be ".." and "." in them. Making a path given
> by the user relative to the cwd by prepending what is returned by
> setup_git_directory() may or may not be safe, depending on how
> setup_git_directory() does things (I think the original one is safe; I
> am reasonably sure with the current one when GIT_WORK_TREE is not in
> use; I do not know when that environment variable is there with the
> current code with or without your patch series).
I am afraid that already GIT_DIR can contain symlinks, and is not checked
by setup_git_env().
So I think some concrete comment is needed in _addition_:
get_git_dir() is not safe, and therefore git_path(), too.
Hmm.
Maybe the easiest way _is_ to getcwd(); chdir() getcwd(); chdir(back);
Ugly.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/5] Clean up work-tree handling
From: Junio C Hamano @ 2007-07-26 18:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707261459570.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ... Am I the only one who finds the new version much easier to read,
> much like the pre-work-tree version?
Oh there is (modulo bugs to be worked on further) no question
about that. The changes to environment.c alone would convince
anybody, I would say. ;-).
^ permalink raw reply
* Re: [PATCH] use lockfile.c routines in git_commit_set_multivar()
From: Bradford Smith @ 2007-07-26 18:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707261926590.14781@racer.site>
On 7/26/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 26 Jul 2007, Bradford C. Smith wrote:
>
> > + /* fd is closed, so don't try to close it below. */
> > + fd = -1;
> > + /*
> > + * lock is committed, so don't try to roll it back below.
> > + * NOTE: Since lockfile.c keeps a linked list of all created
> > + * lock_file structures, it isn't safe to free(lock). It's
> > + * better to just leave it hanging around.
> > + */
> > + lock = NULL;
> > ret = 0;
> >
> > out_free:
> > if (0 <= fd)
> > close(fd);
> > + if (lock)
> > + rollback_lock_file(lock);
>
> Wouldn't it be better to put the rollback_lock_file() into the if clause
> when commit failed?
Actually no. There are multiple goto statements that lead to
out_free. It isn't even needed at the point that the commit failed,
because commit_lock_file() sets the lock file name to "" even when it
fails.
> Besides, I think you can safely call rollback_lock_file(lock) on a
> committed lock_file, since the name will be set to "" by the latter, which
> is checked by the former.
Quite right. I really just put in the comment and 'lock= NULL' line
to increase readability. I wanted to make it very clear to the reader
that the commit wouldn't be undone by the rollback.
> But I am fine with the patch as is (have not tested it, though).
Thanks!
FWIW, I have successfully run 'make test' and also verified that it
behaves as I expect with my ~/.gitconfig symlink (in conjunction with
the my other patch for resolving symlinks).
Best Regards,
Bradford
^ permalink raw reply
* Re: [PATCH 1/5] Add is_absolute_path(), make_absolute_path() and normalize_path()
From: Junio C Hamano @ 2007-07-26 18:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707261456040.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Agree. Maybe a comment above the function, like
>
> /*
> * The function normalize_path() converts ".." and "." names in
> * the given path so that "foo/../bar/./" will come out as "bar".
> *
> * Note: normalize_path() does not follow symlinks, so if "foo" is
> * a symlink in the example above, the result will not work as
> * expected.
> */
>
> Hmm?
That comment only states the obvious and does not give a clue to
the callers when it should not be used, I am afraid. For
example, paths taken out of index or recursively reading trees
are Ok because there will not be ".." and "." in them. Making a
path given by the user relative to the cwd by prepending what is
returned by setup_git_directory() may or may not be safe,
depending on how setup_git_directory() does things (I think the
original one is safe; I am reasonably sure with the current one
when GIT_WORK_TREE is not in use; I do not know when that
environment variable is there with the current code with or
without your patch series).
^ permalink raw reply
* Re: [PATCH] fully resolve symlinks when creating lockfiles
From: Johannes Schindelin @ 2007-07-26 18:35 UTC (permalink / raw)
To: Bradford C. Smith; +Cc: git, Junio C Hamano
In-Reply-To: <11854712542350-git-send-email-bradford.carl.smith@gmail.com>
Hi,
On Thu, 26 Jul 2007, Bradford C. Smith wrote:
> Make the code for resolving symlinks in lockfile.c more robust as
> follows:
>
> 1. Handle relative symlinks
> 2. recursively resolve symlink chains up to OS limit
FWIW I like what it does, but how. What is so wrong with just relying on
is_absolute_path() and make_absolute_path()? The code would be much
shorter then, and we need those functions anyway, methinks.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] use lockfile.c routines in git_commit_set_multivar()
From: Johannes Schindelin @ 2007-07-26 18:31 UTC (permalink / raw)
To: Bradford C. Smith; +Cc: Junio C Hamano, git
In-Reply-To: <11854689283208-git-send-email-bradford.carl.smith@gmail.com>
Hi,
I like the general idea. Thanks.
On Thu, 26 Jul 2007, Bradford C. Smith wrote:
> + /* fd is closed, so don't try to close it below. */
> + fd = -1;
> + /*
> + * lock is committed, so don't try to roll it back below.
> + * NOTE: Since lockfile.c keeps a linked list of all created
> + * lock_file structures, it isn't safe to free(lock). It's
> + * better to just leave it hanging around.
> + */
> + lock = NULL;
> ret = 0;
>
> out_free:
> if (0 <= fd)
> close(fd);
> + if (lock)
> + rollback_lock_file(lock);
Wouldn't it be better to put the rollback_lock_file() into the if clause
when commit failed?
Besides, I think you can safely call rollback_lock_file(lock) on a
committed lock_file, since the name will be set to "" by the latter, which
is checked by the former.
But I am fine with the patch as is (have not tested it, though).
Ciao,
Dscho
^ permalink raw reply
* Re: [Bradford C. Smith] [PATCH 2/2] use lockfile.c routines in git_commit_set_multivar()
From: Johannes Schindelin @ 2007-07-26 18:26 UTC (permalink / raw)
To: Bradford Smith; +Cc: Junio C Hamano, git
In-Reply-To: <f158199e0707261040u70ee31d3le2eaf21ab1302909@mail.gmail.com>
Hi,
On Thu, 26 Jul 2007, Bradford Smith wrote:
> Dear Dscho,
>
> I've submitted a slightly modified version of the same patch to the list.
> It fixes a comment format to match the approved style for git code. Please
> review that one instead.
I saw it and am reviewing it!
Ciao,
Dscho
^ permalink raw reply
* Re: Windows support
From: Johannes Schindelin @ 2007-07-26 18:18 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0707260911y4091b525kc6b89beb82ec7dc7@mail.gmail.com>
Hi,
On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> On 7/26/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > Earlier, Nguyen Thai Ngoc Duy wrote:
>
> > > - MinGW busybox (or gitbox as I call it now) utilizes compat/mingw.c
> > > and other stuff like run-command.c... Making it separate (as source
> > > code) duplicates code for nothing.
> >
> > It is not duplication. It is forking. Which is a good thing.
>
> I still don't see why duplicating compat/*, git-compat-util.h,
> run-command.[ch]... and keeping fixing bugs in two places is a good
> thing.
Actually, it would pretty easy to set up a tracking script with Git, I
guess. But I can look into that once you finished your gitbox.
Thanks for doing it BTW...
Ciao,
Dscho
^ permalink raw reply
* Re: Windows support
From: David Kastrup @ 2007-07-26 18:13 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0707260911y4091b525kc6b89beb82ec7dc7@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 7/26/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>> On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:
>>
>> > I make MinGW busybox part of git for some reasons:
>> >
>> > - Making a full MinGW busybox would take lots of time. I don't need
>> > busybox for Windows. What I need is a shell and enough POSIX utilities
>> > to run git shell scripts without any dependencies. Windows users
>> > (including myself when I have to use Windows) hate dependencies.
>>
>> I think that if you succeed to compile ash on MinGW, the rest is easy.
>
> No it's not. With a couple of ifdefs you can compile it fine. Then
> there goes fork(), fcntl(F_DUPFD), /dev/*, job/signal handling...
> Fortunately Git does not use lots of features. It only needs
> /dev/null (and /dev/zero for tests), SIGEXIT and no job usage.. That
> cuts down the effort porting ash.
And here I was tempted to multithread builtin-update-index.c: it is
actually quite natural to let one process scan directories
non-recursively, stat the files, sort them on a per-directory grain
and feed a sorted pseudo-index into a pipeline (recursing to scanning
whenever hitting a directory), then let another process/thread do a
merge-pass of pseudo-index and real index, immediately writing the
output to a new index-to-be. When this is finished and another
process invalidated the old index already, reuse the index-to-be as
pseudo-index and merge it with the new-index-which-got-in-ahead-of-me.
Would be a fun exercise in particular when merely using
(block-buffered!) pipes, and could presumably make a difference on
multiprocessor-capable machines.
Anyway, just something that had been spinning in my head. The
"streaming merge" idea has the advantage of keeping memory usage low
pretty much independently of project size: project memory is pretty
much determined by the reader pass since it has to read in a complete
directory level before it can sort it and output the next element, and
it has to retain the not-yet-output elements of the ancestry.
And it is nice to have some potential for parallel processing. But if
it is a lethal stumbling block for Windows... It is conceivable to do
the same job instead of with pipes and files with buffers and just
switch manually between the directory scanning and merging phases.
But it would be less fun.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: index-pack died on pread
From: Linus Torvalds @ 2007-07-26 18:02 UTC (permalink / raw)
To: Alex Riesen; +Cc: Robin Rosenberg, Michal Rokos, GIT
In-Reply-To: <81b0412b0707260951h57fc91dbsd5a0a126f0e16fee@mail.gmail.com>
On Thu, 26 Jul 2007, Alex Riesen wrote:
> >
> > HP-UX? No pread()? It wouldn't link if it didn't have pread(). So it
> > clearly has pread(), it's just somehow broken.
>
> I remember it didn't and was emulated with lseek.
So? The point is, that *works*. We do it ourselves.
"emulated with lseek" is trivial, and should work. It worries me that two
totally independent systems are showing problems. There's something else
going on here.
Linus
^ permalink raw reply
* Re: git archive ignores .gitignored files?
From: Brian Downing @ 2007-07-26 17:54 UTC (permalink / raw)
To: git
In-Reply-To: <20070726173635.GS21692@lavos.net>
On Thu, Jul 26, 2007 at 12:36:35PM -0500, Brian Downing wrote:
> On Thu, Jul 26, 2007 at 12:32:06PM -0500, Brian Downing wrote:
> > git archive seems to not output files marked in .gitignore.
>
> Never mind; it is "git add" that ignored the file. Oops.
For what it's worth, if I do (in the git tree):
mkdir foo
touch foo/file
mkdir foo/git-daemon
touch foo/git-daemon/file
"git add foo" does not produce any warnings that "foo/git-daemon" was
ignored. If "foo/file" does not exist it warns that "foo" was not
added.
-bcd
^ permalink raw reply
* Re: git archive ignores .gitignored files?
From: Brian Downing @ 2007-07-26 17:36 UTC (permalink / raw)
To: git
In-Reply-To: <20070726173206.GR21692@lavos.net>
On Thu, Jul 26, 2007 at 12:32:06PM -0500, Brian Downing wrote:
> git archive seems to not output files marked in .gitignore.
Never mind; it is "git add" that ignored the file. Oops.
-bcd
^ permalink raw reply
* [PATCH] fully resolve symlinks when creating lockfiles
From: Bradford C. Smith @ 2007-07-26 17:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Bradford C. Smith
In-Reply-To: <7vbqe0cazy.fsf@assigned-by-dhcp.cox.net>
Make the code for resolving symlinks in lockfile.c more robust as
follows:
1. Handle relative symlinks
2. recursively resolve symlink chains up to OS limit
Signed-off-by: Bradford C. Smith <bradford.carl.smith@gmail.com>
---
I have updated this patch as follows based partly on Junio's comments.
1. Made comment and coding style consistent with existing git
code base.
2. improved readability
3. rebased to latest version of master (2007-07-26) and updated
commit message appropriately
4. added warning messages for error conditions
5. resolve symlinks to non-existent files
lockfile.c | 128 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------
1 files changed, 114 insertions(+), 14 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 9202472..864ce73 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -25,23 +25,123 @@ static void remove_lock_file_on_signal(int signo)
raise(signo);
}
+/*
+ * p = absolute or relative path name
+ *
+ * Return a pointer into p showing the beginning of the last path name
+ * element. If p is empty or the root directory ("/"), just return p.
+ */
+static const char *last_path_elm(const char *p)
+{
+ /* r starts pointing to null at the end of the string */
+ const char *r = strchr(p, '\0');
+
+ if (r == p)
+ return p; /* just return empty string */
+
+ r--; /* back up to last non-null character */
+
+ /* back up past trailing slashes, if any */
+ while (r > p && *r == '/') {
+ r--;
+ }
+ /*
+ * then go backwards until I hit a slash, or the beginning of
+ * the string
+ */
+ while (r > p && *(r-1) != '/') {
+ r--;
+ }
+ return r;
+}
+
+
+/*
+ * p = path that may be a symlink
+ * s = full size of p
+ *
+ * If p is a symlink, attempt to overwrite p with a path to the real
+ * file or directory (which may or may not exist), following a chain of
+ * symlinks if necessary. Otherwise, leave p unmodified.
+ *
+ * This is a best-effort routine. If an error occurs, p will either be
+ * left unmodified or will name a different symlink in a symlink chain
+ * that started with p's initial contents.
+ *
+ * Always returns p.
+ */
+static char *resolve_symlink(char * p, size_t s)
+{
+ struct stat stb;
+ char link[PATH_MAX];
+ int link_len;
+
+ /*
+ * leave p unchanged if it doesn't appear to be a valid path to
+ * a symlink.
+ */
+ if (lstat(p, &stb) != 0 || !S_ISLNK(stb.st_mode)) {
+ return p;
+ }
+ /*
+ * don't attempt to resolve a chain or loop of symlinks the OS
+ * cannot resolve.
+ */
+ if (stat(p, &stb) != 0 && ELOOP == errno) {
+ warning("%s: %s", p, strerror(ELOOP));
+ return p;
+ }
+
+ link_len = readlink(p, link, sizeof(link));
+ if (link_len < 0) {
+ warning("%s: %s", p, strerror(errno));
+ return p;
+ } else if (link_len < sizeof(link)) {
+ /* readlink() never null-terminates */
+ link[link_len] = '\0';
+ } else {
+ warning("%s: symlink too long", p);
+ return p;
+ }
+
+ if (link[0] == '/') {
+ /* absolute path simply replaces p */
+ if (link_len < s) {
+ strcpy(p, link);
+ } else {
+ warning("%s: symlink too long", p);
+ return p;
+ }
+ } else {
+ /*
+ * link is a relative path, so I must replace the last
+ * element of p with it.
+ */
+ char *r = (char*)last_path_elm(p);
+ if (r - p + link_len < s) {
+ strcpy(r, link);
+ } else {
+ warning("%s: symlink too long", p);
+ return p;
+ }
+ }
+ /* try again in case we've resolved to another symlink */
+ return resolve_symlink(p, s);
+}
+
+
static int lock_file(struct lock_file *lk, const char *path)
{
int fd;
- struct stat st;
-
- if ((!lstat(path, &st)) && S_ISLNK(st.st_mode)) {
- ssize_t sz;
- static char target[PATH_MAX];
- sz = readlink(path, target, sizeof(target));
- if (sz < 0)
- warning("Cannot readlink %s", path);
- else if (target[0] != '/')
- warning("Cannot lock target of relative symlink %s", path);
- else
- path = target;
- }
- sprintf(lk->filename, "%s.lock", path);
+
+ if (strlen(path) >= sizeof(lk->filename)) return -1;
+ strcpy(lk->filename, path);
+ /*
+ * subtract 5 from size to make sure there's room for adding
+ * ".lock" for the lock file name
+ */
+ resolve_symlink(lk->filename, sizeof(lk->filename)-5);
+ strcat(lk->filename, ".lock");
fd = open(lk->filename, O_RDWR | O_CREAT | O_EXCL, 0666);
if (0 <= fd) {
if (!lock_file_list) {
--
1.5.3.rc3.9.g1b487
^ permalink raw reply related
* git archive ignores .gitignored files?
From: Brian Downing @ 2007-07-26 17:32 UTC (permalink / raw)
To: git
git archive seems to not output files marked in .gitignore. I find
this behavior a little perplexing, since it does not create an archive
from the working directory, and if something is committed, even if it
is marked in .gitignore, it should probably wind up in the archive.
The reason I discovered this is that I'm trying to keep a debian build
branch for Git, and the debain/git-daemon directory was mysteriously
missing from anything generated with git archive, as "git-daemon" is
in Git's /.gitignore.
Is this intended behavior? It seems kind of a misfeature to me.
(Of course it's possible /.gitarchive should have "/git-daemon" rather
than "git-daemon"; that's certainly how I will work around the issue.)
-bcd
^ permalink raw reply
* Re: Windows support
From: Marius Storm-Olsen @ 2007-07-26 16:58 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Johannes Schindelin
In-Reply-To: <fcaeb9bf0707260807u476719e3rec2dcf5f780013c0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]
Nguyen Thai Ngoc Duy wrote:
> On 7/26/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Thank you for working on this!
>>
>> However, I am not completely convinced that having a builtin shell is all
>> that useful. I for one would like to have MinGW busybox _separate_ from
>> git...
>
> I make MinGW busybox part of git for some reasons:
>
> - Making a full MinGW busybox would take lots of time. I don't need
> busybox for Windows. What I need is a shell and enough POSIX utilities
> to run git shell scripts without any dependencies. Windows users
> (including myself when I have to use Windows) hate dependencies.
> - I don't want MinGW busybox to be used outside of git (if it is
> installed separated from git), there are cygwin and msys already. I
> don't want to compete them. And I don't like conflicts (not sure
> though) because you have multiple UNIX emulations on the same system.
(..snip..)
Hi Duy,
*drool*
This was an extremely good idea! Thank you so much for working on it!
I'll be sure to play around with it, and see if there's any way I can
help out. Guess I finally have to get that MinGW compile environment set
up then :-)
Btw, are you compiling with MinGW on Windows, or cross-compiling on Linux?
Neat neat neat!
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox