* Re: [PATCH] Teach remote machinery about remotes.default config variable
From: Mark Levedahl @ 2008-01-12 17:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LSU.1.00.0801121748290.8333@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>
> No, that was not _at all_ my argument.
>
> I said that hiding it under a different name _that you have to look up,
> too_ does _not_ make things easier.
>
>
Granted, *IF* we had to look it up, but we don't. In fact, we use the
convention
servername.foo.bar
has nickname
servername
So, we need to know the server name we are using, and that server name
is the nickname. So, no confusion and no extra lookup step. (Our server
names are unique without the domain suffixes, so this works well for us).
Mark
^ permalink raw reply
* Re: valgrind test script integration
From: Johannes Schindelin @ 2008-01-12 17:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080112113608.GB24589@coredump.intra.peff.net>
Hi,
On Sat, 12 Jan 2008, Jeff King wrote:
> On Sat, Jan 12, 2008 at 06:10:44AM -0500, Jeff King wrote:
>
> > - We only catch calls to 'git', not 'git-foo' (and in fact for that
> > reason this doesn't catch the t7300 bug by itself, since that uses
> > git-clean). A follow-on patch will deal with this.
>
> And here it is.
>
> [...]
>
> Obviously another route would be intercepting git-* calls, as well, but
> my impression is that we are ultimately heading towards a "git foo is
> the right way" situation, in which case this cleanup is eventually
> necessary anyway.
Nevertheless, I think that would be better.
BTW does your first patch cope with scripts properly? (I.e. also valgrind
the git programs called by the script)
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.4-rc3
From: Johannes Schindelin @ 2008-01-12 16:57 UTC (permalink / raw)
To: Jeff King; +Cc: Ismail Dönmez, Junio C Hamano, git
In-Reply-To: <20080112090432.GA6134@coredump.intra.peff.net>
Hi,
On Sat, 12 Jan 2008, Jeff King wrote:
> diff --git a/builtin-clean.c b/builtin-clean.c
> index 6cad8ea..eb853a3 100644
> --- a/builtin-clean.c
> +++ b/builtin-clean.c
> @@ -90,7 +90,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
> strbuf_init(&directory, 0);
>
> if (pathspec)
> - seen = xmalloc(argc);
> + seen = xmalloc(argc > 0 ? argc : 1);
>
> for (i = 0; i < dir.nr; i++) {
> struct dir_entry *ent = dir.entries[i];
> @@ -125,7 +125,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
> continue;
>
> if (pathspec) {
> - memset(seen, 0, argc);
> + memset(seen, 0, argc > 0 ? argc : 1);
> matches = match_pathspec(pathspec, ent->name, ent->len,
> baselen, seen);
> } else {
Would it not be better to guard the memset by an "if (argc)", and set
"seen" to NULL by default?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach remote machinery about remotes.default config variable
From: Johannes Schindelin @ 2008-01-12 16:50 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Junio C Hamano, git
In-Reply-To: <478855B5.9070600@gmail.com>
Hi,
On Sat, 12 Jan 2008, Mark Levedahl wrote:
> The argument against my approach of explicitly naming the server rests
> upon the premise that hiding a half-dozen servers, all different and
> with those differences being important, under the single universal name
> "origin", makes things easier.
No, that was not _at all_ my argument.
I said that hiding it under a different name _that you have to look up,
too_ does _not_ make things easier.
I might even add that it makes misconfigurations even worse.
Ciao,
Dscho
^ permalink raw reply
* Re: Project Hosting with git ?
From: Stephen Sinclair @ 2008-01-12 16:45 UTC (permalink / raw)
To: Neshama Parhoti; +Cc: git
In-Reply-To: <912ec82a0801120553u3621c991u7c4cb4793960159c@mail.gmail.com>
> I mean, if I open a SourceForge project, I have to use cvs/subversion right ?
>
> Is there any way to use git ?
There is currently an open feature request on sourceforge for git support.
Please feel free to add a comment to the thread, hopefully if enough
people do so they'll do something about it.
(Though I wouldn't be surprised if they're working on it.)
https://sourceforge.net/tracker/?func=detail&atid=350001&aid=1828327&group_id=1
However, git works fine over http. I have a project on SF which I was
using with subversion, but I recently switched the project over to
git.
I simply posted a bare git repo on the project website, and bang it's
"hosted" on sourceforge. In order to automate things a bit, I set up
a local repo which, when I push to it, runs git-update-server-info and
then uses rsync to upload the repo changes to the SF web server.
It seems to work fine. I do occasionally git-clone the http-hosted
repo just to make sure things are still working, and so far no
problems.
The downside is that SF will not collect statistics on the git repo.
However, I've been using ohloh.net to track it instead, which works
wonderfully.
Steve
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Johannes Schindelin @ 2008-01-12 16:44 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sam Vilain, Linus Torvalds, Pierre Habouzit, Git Mailing List,
Marco Costalba, Junio C Hamano
In-Reply-To: <alpine.LFD.1.00.0801121053080.3054@xanadu.home>
Hi,
On Sat, 12 Jan 2008, Nicolas Pitre wrote:
> On Sat, 12 Jan 2008, Sam Vilain wrote:
>
> > Going as much as twice as fast for many history operations for 10%
> > added space sounds like a clear win to me.
I have to agree with Nicolas. A full history log is such a rare occasion
that it is not worth optimising for.
When I call "git log", it typically shows me the first commit
_instantaneously_, which is plenty fast enough for me, especially given
that I quit it right away or after a few pages more often than not.
Ciao,
Dscho
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Johannes Schindelin @ 2008-01-12 16:33 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Junio C Hamano, Linus Torvalds, Kevin Ballard, git
In-Reply-To: <200801120157.47854.robin.rosenberg@dewire.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 486 bytes --]
Hi,
On Sat, 12 Jan 2008, Robin Rosenberg wrote:
> lördagen den 12 januari 2008 skrev Junio C Hamano:
>
> > And where should the configuration be stored? If a project wants to
> > be interoperable across Linux and vfat, for example,
>
> In the brand new ".gitconfig". It could in principle contain any config
> option, but that would not be safe so I guess one should only allow
> "safe" options there.
Funny: I had the same idea (.gitconfig) for the crlf issues...
Ciao,
Dscho
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Nicolas Pitre @ 2008-01-12 16:09 UTC (permalink / raw)
To: Sam Vilain
Cc: Linus Torvalds, Pierre Habouzit, Git Mailing List,
Johannes Schindelin, Marco Costalba, Junio C Hamano
In-Reply-To: <47882EC5.2080406@vilain.net>
On Sat, 12 Jan 2008, Sam Vilain wrote:
> Nicolas Pitre wrote:
> > Sorry to rain on your parade, but to me 6-10% time saving is not a clear
> > win at all, given the equal increase in repository size. This is simply
> > not worth it.
>
> Agree.
>
> > And a 50% time saving on an operation, such a git log, which takes less
> > than 2 seconds in absolute time, is not worth the repo size increase
> > either.
>
> Disagree. Going as much as twice as fast for many history operations
> for 10% added space sounds like a clear win to me.
If you can come with a real life scenario, and not simply a simple test
having little relevance with typical usage, that shows a clear reduction
in execution time which is human perceptible, then I'll agree with you.
But doing a full history log taking one second instead of two isn't a
good enough argument to me for making the repository many megabytes
larger. Again if it was 'git blame' using 5 seconds instead of 10 then
I would agree that this is a clear win, even if this is also a 50%
execution time reduction. But human perception is way more important
when it is 10 secs down to 5 compared to 2 secs down to 1.
This proposed change isn't free, because you have to introduce a
regression in one place in order to make a gain somewhere else. The pack
v4 format that I developed with Shawn, though, was showing _both_ a
speed gain and a repository size reduction, hence there is no regression
for the added improvements. *That* is a clear win.
> We can easily agree
> to disagree though
I suppose we do.
Nicolas
^ permalink raw reply
* Re: [EGIT PATCH] Showing abbreviated commit hash of the versions in Compare editor.
From: Robin Rosenberg @ 2008-01-12 15:44 UTC (permalink / raw)
To: Roger C. Soares; +Cc: git, Shawn O. Pearce
In-Reply-To: <47883600.20307@intelinet.com.br>
lördagen den 12 januari 2008 skrev Roger C. Soares:
>
> Robin Rosenberg escreveu:
> > I pushed my doc-branch as pu, you can look at it. My intention is take a look again
> > and then push it as master if there are no objections. Is it ok and good to flags
> > public stuff without javadoc as an error (tip pu commit)?
> >
> Got some errors, when trying to export to a deployable plugin:
> "/home/roger/eclipse/workspace/egit/org.spearce.jgit/tst" does not exist!
>
> And on "team -> share project... -> Git", it goes to the CVS wizard.
Due to my lack of testing @_@. I pushed a new pu branch with these two errors fixed.
Thanks
-- robin
^ permalink raw reply
* Re: Project Hosting with git ?
From: Neshama Parhoti @ 2008-01-12 15:28 UTC (permalink / raw)
To: Pascal Obry; +Cc: git
In-Reply-To: <4788CBAC.9050804@obry.net>
On Jan 12, 2008 4:16 PM, Pascal Obry <pascal@obry.net> wrote:
> Neshama Parhoti a écrit :
> > Hello,
> >
> > I mean, if I open a SourceForge project, I have to use cvs/subversion right ?
>
> That's right.
>
> > Is there any way to use git ?
>
> Using Savannah:http://savannah.gnu.org/
>
> Or http://repo.or.cz
>
> The former require approval to create the project but has more features
> (bug tracker...) and is somewhat faster (larger bandwidth), the later is
> simpler but do not require approval. I'm using both, and both are
> working fine.
thanks a lot
>
> There is probably others.
>
> 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: Project Hosting with git ?
From: Neshama Parhoti @ 2008-01-12 15:27 UTC (permalink / raw)
To: Grégoire Barbier; +Cc: git
In-Reply-To: <4788CA0A.9020503@gbarbier.org>
On Jan 12, 2008 4:09 PM, Grégoire Barbier <devel@gbarbier.org> wrote:
> Neshama Parhoti a écrit :
> > I was wondering how is it possible with current hosting
> > solutions ?
>
> Hi.
>
> There is a list of git projects and hosting here:
> http://git.or.cz/gitwiki/GitProjects
thank you
>
> --
> Grégoire Barbier - gb à gbarbier.org - +33 6 21 35 73 49
>
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Dmitry Potapov @ 2008-01-12 15:26 UTC (permalink / raw)
To: Gregory Jefferis
Cc: Steffen Prohaska, Linus Torvalds, Junio C Hamano,
Git Mailing List
In-Reply-To: <C3AD6D58.10E02%jefferis@gmail.com>
On Fri, Jan 11, 2008 at 07:00:40PM +0000, Gregory Jefferis wrote:
>
> LF only repositories are model that everyone is tending towards but I feel
> that there are (sane) people out there who would sometimes like to have CRLF
> files in the repository and do cross-platform development (I would
> developing on a Mac for a Windows originated Win/Mac project or if I were
> keeping vendor source code in a tree). In spite of the plethora of autocrlf
> variants so far there is still none that on unix would give you LF->CRLF on
> check in and CRLF->LF on checkout! This should be perfectly compatible with
> git's internals
Git internally considers only LF as the EOL marker. I think there are
more three hundreds places in Git where the decision about end-of-line
is made based on that. Though CRLF may appear to work, but it is more
an artifact caused by its LF ending, so what it actually works is LF and
nothing else. IOW, CRLF from the Git's point of view is no better EOL
than let's say SPACE+LF.
> and I think it should be possible to allow this without
> breaking anything for other situations. One solution, which would have
> other uses, would be to allow checkin conversion to a specified line ending
> and checkout conversion to platform line ending as separately configurable
> options.
>
> If this seems outrageous then it should be made perfectly clear that the git
> project strongly discourages CRLF text files in cross-platform repositories,
Because LF is the only true EOL marker, and CRLF is not and never will be.
In fact, Git is written in C, and the decision of what is EOL in C is made
many years ago. So, it is the only sane choice to use LF for _internal_
representation. It can be said that *nix users are lucky in that their
OS uses the same symbol, but it is similar to big-endian platforms being
lucky with byte order when it comes to TCP/IP. That is not because TCP/IP
wants to discourage little-endian platforms, but having the single encoding
is the only sane choice if you care about interoperability, and any other
decision will end up being much worse.
Dmitry
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Dmitry Potapov @ 2008-01-12 15:08 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Linus Torvalds, Steffen Prohaska, Gregory Jefferis,
Junio C Hamano, Git Mailing List
In-Reply-To: <20080111195022.GC29189@uranus.ravnborg.org>
On Fri, Jan 11, 2008 at 08:50:22PM +0100, Sam Ravnborg wrote:
> On Fri, Jan 11, 2008 at 11:16:02AM -0800, Linus Torvalds wrote:
> >
> > (Every place I've ever been at, people who had a choice would never ever
> > develop under Windows, so I've never seen any real mixing - even when some
> > parts of the project were DOS/Windows stuff, there was a clear boundary
> > between the stuff that was actually done under Windows)
>
> The reality I see is the other way around as common practice.
> For people that has never tried a Linux box the barrier
> is quite high and they prefer to stick with Windows.
And for those who have never tried Windows, it would be a great learning
barrier as well, and it is far for obvious what would be easy to learn
for someone has never had any experience with either of them before...
Of course, most people who has used computers for some time could not
escape having at least some experience with Windows, and, naturally
people prefer to stick to what they know, especially those who do not
like or find difficult to learn new stuff. Based on my observation, I
would say that those found learning Linux difficult would also find
difficult to learn other new things (like a new programming language),
and usually had more troubles in dealing with novel situations or doing
anything that required out-of-the-box thinking... Usually, they are
good only on one thing -- doing what they were told. There are some
exceptions, of course, but take a look at the number of open source
projects (where people write for fun of programming) and compare how
many of them are done by *nix users and Windows users. Isn't obvious
what most people who like programing prefer to use?
Dmitry
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Dmitry Potapov @ 2008-01-12 15:03 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Junio C Hamano, git
In-Reply-To: <08E42D03-7AAA-4ADD-9F5B-215AB30E34E1@sb.org>
On Fri, Jan 11, 2008 at 08:43:35PM -0500, Kevin Ballard wrote:
>
> Fair enough, though I believe OS X has a good reason, namely it's an
> OS designed for regular users rather than servers or programmers. Case-
> sensitivity would confuse my mother.
Many of *nix servers are running web-services and samba servers, yet most
users are even not aware of whether they dealing with case-sensitive file
system or not, let alone being confused by that. This is because most
regular users will type the name only once when they create a new file
and then just click on this name. So case-sensitive file systems can
really confuse only some badly written applications...
Dmitry
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: Dmitry Potapov @ 2008-01-12 14:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kevin Ballard, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.1.00.0801111356000.3148@woody.linux-foundation.org>
On Fri, Jan 11, 2008 at 02:08:35PM -0800, Linus Torvalds wrote:
>
> However, it's not like there is even a simple solution. The right place to
> do that check would probably be in "add_index_entry()", but doing a check
> whether the same file already exists (in a different case) is simply
> *extremely* expensive for a very critical piece of code, unless we were to
> change that index data structure a lot (ie add a separate hash for the
> filenames).
After cursory look at the source code, I wonder if converting name1
and name2 to upper case before memcmp in cache_name_compare() can
help case-insensitive systems. This change will change the order of
file names in the index, but I suppose that it should not be a problem,
because the index is host specific. Though, this fix is too simple, so
I guess, I missed something.
> (And that's totally ignoring the fact that case-insensitivity then also
> has tons of i18n issues and can get *really* messy
The proper support of i18n is not simple even without case-insensitivity.
For instance, there are four different encodings widely used for Russian
letters. On Windows alone, you have two simulteniously in the default
settings -- Windows-1251 for Windows applications and CP866 for Console
applications... Actually, some console applications can change its default
encoding, and it seems Cygwin programs do that. So, based on whether you
use gcc from Cygwin or Visual C to compile your console program, you can
get a different encoding. On *nix in Russia, koi8-r and utf-8 are most
popular... So, if you have a repository shared between different systems,
you cannot think about a file name just as a sequence of bytes anymore.
OTOH, I doubt that many people are really interested in using non-ASCII
file names with Git right now.
Dmitry
^ permalink raw reply
* Re: Project Hosting with git ?
From: Grégoire Barbier @ 2008-01-12 14:09 UTC (permalink / raw)
To: Neshama Parhoti; +Cc: git
In-Reply-To: <912ec82a0801120553u3621c991u7c4cb4793960159c@mail.gmail.com>
Neshama Parhoti a écrit :
> I was wondering how is it possible with current hosting
> solutions ?
Hi.
There is a list of git projects and hosting here:
http://git.or.cz/gitwiki/GitProjects
--
Grégoire Barbier - gb à gbarbier.org - +33 6 21 35 73 49
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.4-rc3
From: Roger C. Soares @ 2008-01-12 14:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl13wmas.fsf@gitster.siamese.dyndns.org>
Junio C Hamano escreveu:
> The third rc for the next feature release GIT 1.5.4 is available
> at the usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.5.4.rc3.tar.{gz,bz2} (tarball)
> git-htmldocs-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
> git-manpages-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
> testing/git-*-1.5.4.rc3-1.$arch.rpm (RPM)
>
Don't know if you already have some recomendation for RHEL5 users, so
just reporting what I had to do to install the rpms.
To start, I already had git installed from EPEL.
Downloaded perl-Error from
http://dag.wieers.com/rpm/packages/perl-Error/ to satisfy dependencies.
There was another dependacy for git-arch I think, but as I don't need it
I just deleted this one.
When trying to install perl-Error it conflicted with perl-Git from EPEL.
I think they included perl-Error files inside their perl-Git rpm.
So, after uninstalling all git rpms from EPEL, installing perl-Error
from dag.wieers, the rc3 git rpms installed successfully.
[]s,
Roger.
^ permalink raw reply
* Re: Project Hosting with git ?
From: Pascal Obry @ 2008-01-12 14:16 UTC (permalink / raw)
To: Neshama Parhoti; +Cc: git
In-Reply-To: <912ec82a0801120553u3621c991u7c4cb4793960159c@mail.gmail.com>
Neshama Parhoti a écrit :
> Hello,
>
> I am beginning a new Open Source project which I would
> like to manage with git.
>
> I was wondering how is it possible with current hosting
> solutions ?
>
> I mean, if I open a SourceForge project, I have to use cvs/subversion right ?
That's right.
> Is there any way to use git ?
Using Savannah:http://savannah.gnu.org/
Or http://repo.or.cz
The former require approval to create the project but has more features
(bug tracker...) and is somewhat faster (larger bandwidth), the later is
simpler but do not require approval. I'm using both, and both are
working fine.
There is probably others.
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
* Project Hosting with git ?
From: Neshama Parhoti @ 2008-01-12 13:53 UTC (permalink / raw)
To: git
Hello,
I am beginning a new Open Source project which I would
like to manage with git.
I was wondering how is it possible with current hosting
solutions ?
I mean, if I open a SourceForge project, I have to use cvs/subversion right ?
Is there any way to use git ?
Of course I can pay for a VPS and install my own git server
but that would be a bit expensive.
Any ideas ?
How are the current git-using projects hosted (besides kernel.org...) ?
thank you very much
neshama
^ permalink raw reply
* Re: [PATCH] Teach remote machinery about remotes.default config variable
From: Mark Levedahl @ 2008-01-12 13:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iify2wm.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Sorry, I may be missing something.
>
> Even if you have a submodule, you can go there and that will be
> a valid freestanding repository. You can always be explicit,
> bypassing any behaviour that defaults to 'origin' to avoid
> ambiguity.
>
"git-submodule update" *requires* that origin is defined in all
sub-modules. There is no way to avoid this behavior.
Mark
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.4-rc3
From: Ismail Dönmez @ 2008-01-12 13:10 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20080112090432.GA6134@coredump.intra.peff.net>
Saturday 12 January 2008 11:04:32 tarihinde Jeff King şunları yazmıştı:
> On Sat, Jan 12, 2008 at 09:47:48AM +0200, Ismail Dönmez wrote:
> > So looks like tests no longer work as root, so I run make test as normal
> > user and I now see t7300-clean.sh fail, this time a real failure:
> >
> > Removing part3.c
> > ./test-lib.sh: line 193: 19413 Aborted git-clean
> > * FAIL 5: git-clean with prefix
>
> I couldn't reproduce this just running the test, but running it under
> valgrind showed a memory access error. Fix is below.
>
> Junio, can you please sanity check this fix (it stops the valgrind
> error, but I want to make sure my assumptions about match_pathspec are
> right).
>
> -- >8 --
> git-clean: fix off-by-one memory access when given no arguments
>
> The "seen" variable is used by match_pathspec, and must have
> as many elements as there are in the given pathspec. We
> create the pathspec either from the command line arguments
> _or_ from just the current prefix.
>
> Thus allocating "seen" based upon just argc is wrong, since
> if argc == 0, then we still have one pathspec, the prefix,
> but we don't allocate any space in "seen".
>
> Signed-off-by: Jeff King <peff@peff.net>
Thanks Jefff, this fixes t7300-clean.sh for me.
Tested-by: İsmail Dönmez <ismail@pardus.org.tr>
Regards,
ismail
--
Never learn by your mistakes, if you do you may never dare to try again.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.4-rc3
From: René Scharfe @ 2008-01-12 13:01 UTC (permalink / raw)
To: Jeff King; +Cc: Ismail Dönmez, Junio C Hamano, git
In-Reply-To: <20080112090432.GA6134@coredump.intra.peff.net>
Jeff King schrieb:
> Thus allocating "seen" based upon just argc is wrong, since
> if argc == 0, then we still have one pathspec, the prefix,
> but we don't allocate any space in "seen".
Yes, all the other callers count the number of elements in pathspec
and allocate seen accordingly. We could do that. Or we could
extend match_pathspec() to allow seen to be a NULL pointer, for
those cases where this result isn't needed.
This patch is for discussion, only, because it touches central,
non-buggy code and where in bugfix only mode. And I'm not really
sure git-clean ignoring non-matching pathspecs (as it does now,
even without this patch) is really what we want.
builtin-clean.c | 8 +-------
dir.c | 26 ++++++++++++++++----------
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/builtin-clean.c b/builtin-clean.c
index 6cad8ea..40d976c 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -35,7 +35,6 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
const char *path, *base;
static const char **pathspec;
int prefix_offset = 0;
- char *seen = NULL;
struct option options[] = {
OPT__QUIET(&quiet),
OPT__DRY_RUN(&show_only),
@@ -89,9 +88,6 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
read_directory(&dir, path, base, baselen, pathspec);
strbuf_init(&directory, 0);
- if (pathspec)
- seen = xmalloc(argc);
-
for (i = 0; i < dir.nr; i++) {
struct dir_entry *ent = dir.entries[i];
int len, pos, matches;
@@ -125,9 +121,8 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
continue;
if (pathspec) {
- memset(seen, 0, argc);
matches = match_pathspec(pathspec, ent->name, ent->len,
- baselen, seen);
+ baselen, NULL);
} else {
matches = 0;
}
@@ -165,7 +160,6 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
unlink(ent->name);
}
}
- free(seen);
strbuf_release(&directory);
return 0;
diff --git a/dir.c b/dir.c
index 3e345c2..6af70ac 100644
--- a/dir.c
+++ b/dir.c
@@ -88,32 +88,38 @@ static int match_one(const char *match, const char *name, int namelen)
/*
* Given a name and a list of pathspecs, see if the name matches
- * any of the pathspecs. The caller is also interested in seeing
- * all pathspec matches some names it calls this function with
- * (otherwise the user could have mistyped the unmatched pathspec),
- * and a mark is left in seen[] array for pathspec element that
- * actually matched anything.
+ * any of the pathspecs.
+ * If the caller is interested in which of the pathspecs matched,
+ * seen needs to point to a char array with as many members as there
+ * are pathspecs. A mark is left at the nth element of the nth
+ * pathspec matched the name. The marks are not reset, so the
+ * caller can check, after matching a list of files, if there are
+ * any unmatched pathspecs (which might have been mistyped).
*/
int match_pathspec(const char **pathspec, const char *name, int namelen, int prefix, char *seen)
{
- int retval;
- const char *match;
+ int retval = 0;
name += prefix;
namelen -= prefix;
- for (retval = 0; (match = *pathspec++) != NULL; seen++) {
+ while (*pathspec) {
+ const char *match = *pathspec++;
int how;
- if (retval && *seen == MATCHED_EXACTLY)
+
+ if (retval && seen && *seen == MATCHED_EXACTLY)
continue;
+
match += prefix;
how = match_one(match, name, namelen);
if (how) {
if (retval < how)
retval = how;
- if (*seen < how)
+ if (seen && *seen < how)
*seen = how;
}
+ if (seen)
+ seen++;
}
return retval;
}
^ permalink raw reply related
* Re: [PATCH] git-svn: handle leading/trailing whitespace from svnsync revprops
From: Dennis Schridde @ 2008-01-12 12:34 UTC (permalink / raw)
To: git
In-Reply-To: <20080112071355.GA17021@soma>
[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]
Am Samstag, 12. Januar 2008 08:13:55 schrieben Sie:
> Repositories generated by svnsync cannot be relied on to have
> properly set revprops without newlines in UUIDs and URLs. There
> may be broken versions of svnsync out there that append extra
> newlines to UUIDs, or the revprops could've been changed by
> repository administrators at any time, too.
>
> At least one repository we've come across has an embedded
> newline erroneously set in the svnsync-uuid prop. This is bad
> because the trailing newline is taken as another record by the
> Git.pm library, and the wantarray detection causes tmp_config()
> to return an array with an empty-but-existing second element.
>
> We will now strip leading and trailing whitespace both before
> setting and after reading the uuid and url for svnsync values.
> We will also force tmp_config to return a single scalar when
> reading existing values.
>
> SVN UUIDs should never have whitespace in them, and SVN
> repository URLs should be URI-escaped, so neither of those
> values we ever see in git-svn should actually have whitespace
> in them.
>
> Thanks to Dennis Schridde for the bug report and Junio for
> helping diagnose this.
Thanks! This patch seems to work, at least the "Odd number..." message is
gone. The segfault with a non-debug perl stays, though. But I guess that is a
different problem.
--Dennis
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] git-submodule: New subcommand 'summary' (2) - hard work
From: Ping Yin @ 2008-01-12 12:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <46dff0320801120148r1a760bcdq4b9dcdf31354d9e0@mail.gmail.com>
> >
> > I think you would want to read full 40-char sha1_src and
> > sha1_dst with "while read", and keep that full 40-char in these
> > variables, and use them when calling rev-parse here.
>
> Hmm, precision is really a problem. However, "git diff --raw" will not
> always give full 40-char sha1, instead it will give sha1 with enough
> length. So maybe i can use the sha1 from "git diff --raw" ?
>
Oh, I'm wrong. It seems 'git diff --raw' will always give full 40-char
sha1 for submodule entry and abbreviated sha1 for blob entry.
--
Ping Yin
^ permalink raw reply
* Re: Re-casing directories on case-insensitive systems
From: David Kastrup @ 2008-01-12 12:07 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Junio C Hamano, git
In-Reply-To: <08E42D03-7AAA-4ADD-9F5B-215AB30E34E1@sb.org>
Kevin Ballard <kevin@sb.org> writes:
> On Jan 11, 2008, at 8:30 PM, Junio C Hamano wrote:
>
>>> Apparently so. By Junio's definition, HFS+ is not a sane filesystem,
>>> and as git grows more popular with OS X users, this issue is going to
>>> crop up more frequently.
>>
>> It's not "my" definition, but you asked the reason and I gave
>> the answer. We can close this issue of "is HFS+ sane" now.
>> HFS+ is insane, period. And as Linus said, you cannot forgive
>> its insanity using the historical baggage argument, like MS-DOS.
>
> Fair enough, though I believe OS X has a good reason, namely it's an
> OS designed for regular users rather than servers or
> programmers. Case-sensitivity would confuse my mother.
If case-sensitivity would be the primary cause of confusion in
mother-computer interoperation, you have a remarkable mother.
"Type things the same way and they work the same" is a simple enough
rule.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ 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