* Re: [PATCH] gitk - work around stderr redirection on Cygwin
From: Eric Blake @ 2008-07-17 3:55 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Junio C Hamano, paulus, git
In-Reply-To: <487A7949.9050800@gmail.com>
According to Mark Levedahl on 7/13/2008 3:53 PM:
>>>
>>>> Cygwin is *still* shipping with antiquated Tcl 8.4.1
>>>>
>>> Ping. This bug is in 1.5.6.x, and thus also in the current Cygwin git
>>> release: as a result, several gitk context menu items cause
>>> errors. (Let me know if I should resend the patch).
> I certainly have this patch in my tree so the folks I supply git to who
> use Cygwin have this patch. The question of whether to maintain this out
> of tree for the official Cygwin release is up to Eric.
Could you point me to the patch? I need to roll the Cygwin git release of
1.5.6.3 anyway (in part because cygwin has upgraded from perl 5.8 to
5.10). This sounds like something worth me including as a vendor patch,
if it does not get folded into the main repo.
--
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: Let test_must_fail fail on signals only
From: Jeff King @ 2008-07-17 5:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephan Beyer, git
In-Reply-To: <7v4p6qwezy.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 15, 2008 at 10:54:25PM -0700, Junio C Hamano wrote:
> Anything that returns error() from its cmd_xxx() routine, for example,
> would end up exiting with (-1). Is it "such bogus" error codes, though?
I think it is bogus, because it is being implicitly truncated to an
unsigned 8-bit value (at least on Linux -- I have no idea what other
platforms do). So your -1 is actually 255. Portably speaking, C defines
only the macros EXIT_SUCCESS and EXIT_FAILURE; in practice, I don't know
what is most common.
Bad side effects of not treating your exit codes as unsigned 8-bit
integers:
- the exit values are easily confused with other things, like signal
death. As in this case. We have modified our checking code in the
test scripts, but there may be other, less robust code out there.
- other exit values can be mistaken as success. Obviously 256, -256,
512, -512, etc all produce an erroneous "success". Now we aren't
doing this, as we are using "-1", but it just seems a bit cleaner to
be up front about what is happening (and the 255 we end up with is
unnecessarily confusing; some documents, like this one:
http://tldp.org/LDP/abs/html/exitcodes.html
claim 255 as "out of range").
So what we are doing now isn't terrible, but since it was noted (and did
in fact cause a problem!), I just expected a "let's stop doing that"
patch in the original series.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: Let test_must_fail fail on signals only
From: Junio C Hamano @ 2008-07-17 5:38 UTC (permalink / raw)
To: Jeff King; +Cc: Stephan Beyer, git
In-Reply-To: <20080717051833.GA3100@sigio.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Jul 15, 2008 at 10:54:25PM -0700, Junio C Hamano wrote:
>
>> Anything that returns error() from its cmd_xxx() routine, for example,
>> would end up exiting with (-1). Is it "such bogus" error codes, though?
>
> I think it is bogus, because it is being implicitly truncated to an
> unsigned 8-bit value (at least on Linux -- I have no idea what other
> platforms do).
"Only the least significant 8 bits (that is, status & 0377) shall be
available to a waiting parent process". So it is not just "at least on
Linux" but is a well defined behaviour.
http://www.opengroup.org/onlinepubs/000095399/functions/exit.html
I would however agree that when we do mean 255 we should probably write
255, not (-1). It is easier to document things that way.
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: Let test_must_fail fail on signals only
From: Jeff King @ 2008-07-17 6:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephan Beyer, Johannes Sixt, git
In-Reply-To: <7v3am9m5ne.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 16, 2008 at 10:38:45PM -0700, Junio C Hamano wrote:
> "Only the least significant 8 bits (that is, status & 0377) shall be
> available to a waiting parent process". So it is not just "at least on
> Linux" but is a well defined behaviour.
>
> http://www.opengroup.org/onlinepubs/000095399/functions/exit.html
Ah, thanks. I read that same text in the Linux manpage but didn't think
to check that it was POSIX. However, some of our systems aren't quite
POSIX...check out 2488df84 (builtin run_command: do not exit with -1) by
Johannes Sixt [who is now cc'd]. I assume that was a Windows fallout.
> I would however agree that when we do mean 255 we should probably write
> 255, not (-1). It is easier to document things that way.
I started to fix the callsites that Stephan mentioned, but it really is
convenient to be able to 'return error("foo")' (or even return
func_that_calls_error(), and tracking down deep calls is time consuming
and error prone). So maybe we should just enhance the change from
2488df84 and special case "-1" into "1"?
diff --git a/git.c b/git.c
index 6b600b5..4f28e8c 100644
--- a/git.c
+++ b/git.c
@@ -240,7 +240,7 @@ static int run_command(struct cmd_struct *p, int argc, const char **argv)
status = p->fn(argc, argv, prefix);
if (status)
- return status & 0xff;
+ return status == -1 ? 1 : status & 0xff;
/* Somebody closed stdout? */
if (fstat(fileno(stdout), &st))
-Peff
^ permalink raw reply related
* Re: [PATCH 1/2] t/test-lib.sh: Let test_must_fail fail on signals only
From: Junio C Hamano @ 2008-07-17 6:31 UTC (permalink / raw)
To: Jeff King; +Cc: Stephan Beyer, Johannes Sixt, git
In-Reply-To: <20080717060143.GA3338@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> I would however agree that when we do mean 255 we should probably write
>> 255, not (-1). It is easier to document things that way.
>
> I started to fix the callsites that Stephan mentioned, but it really is
> convenient to be able to 'return error("foo")' (or even return
> func_that_calls_error(), and tracking down deep calls is time consuming
> and error prone). So maybe we should just enhance the change from
> 2488df84 and special case "-1" into "1"?
Didn't the patch to testsuite that triggered this thread talk about "small
negative integer" not "-1"? I suspect there might be other negative
return values from cmd_foo(), although I haven't checked.
Is it that somebody do not want 255 exit value, or anything that has 7th
bit set? 2488df8 (builtin run_command: do not exit with -1., 2007-11-13)
suggests otherwise at least for Windows runtime, so what we currently have
that does extra truncation ourselves might be sufficient.
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: Let test_must_fail fail on signals only
From: Jeff King @ 2008-07-17 6:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephan Beyer, Johannes Sixt, git
In-Reply-To: <7vlk01komq.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 16, 2008 at 11:31:41PM -0700, Junio C Hamano wrote:
> > I started to fix the callsites that Stephan mentioned, but it really is
> > convenient to be able to 'return error("foo")' (or even return
> > func_that_calls_error(), and tracking down deep calls is time consuming
> > and error prone). So maybe we should just enhance the change from
> > 2488df84 and special case "-1" into "1"?
>
> Didn't the patch to testsuite that triggered this thread talk about "small
> negative integer" not "-1"? I suspect there might be other negative
> return values from cmd_foo(), although I haven't checked.
It did say that, but I never saw anything in the code except explicit
"return -1" and "return error()". However, some of the diff code may end
up with different values, as I didn't trace it all the way down.
Stephan?
> Is it that somebody do not want 255 exit value, or anything that has 7th
> bit set? 2488df8 (builtin run_command: do not exit with -1., 2007-11-13)
> suggests otherwise at least for Windows runtime, so what we currently have
> that does extra truncation ourselves might be sufficient.
Johannes will have to answer that; however, the truncation there does
leave the extra 7th bit. Maybe & 0x7f would be more appropriate?
-Peff
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Junio C Hamano @ 2008-07-17 6:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807170152190.4318@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > However, my point was about telling users, especially new ones.
>>
>> Perhaps you did not read my first paragraph?
>
> Well, I did.
Then perhaps I wasn't being clear, and I think we are saying the same
thing.
> Sure, advanced usage is nice, and often involves plumbing, especially for
> scripting.
That is not what I am saying. What I am saying actually is that these
usage that _need_ to involve plumbing is not "advanced", but merely
showing weakness of the current Porcelain. Fixing that would allow us
move further away from having to resort to plumbing in our daily
workflow.
Perhaps our Porcelains already passed that point, in which case you do not
have to touch the plumbing commands 99% of time during the day and you do
not have to teach new people plumbing at all. I am agreeing that it would
be a worthy goal to aim for -- I do not however think we are there yet.
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: Let test_must_fail fail on signals only
From: Johannes Sixt @ 2008-07-17 7:22 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Stephan Beyer, git
In-Reply-To: <20080717063856.GA10450@sigill.intra.peff.net>
Jeff King schrieb:
> On Wed, Jul 16, 2008 at 11:31:41PM -0700, Junio C Hamano wrote:
>> Is it that somebody do not want 255 exit value, or anything that has 7th
>> bit set? 2488df8 (builtin run_command: do not exit with -1., 2007-11-13)
>> suggests otherwise at least for Windows runtime, so what we currently have
>> that does extra truncation ourselves might be sufficient.
>
> Johannes will have to answer that; however, the truncation there does
> leave the extra 7th bit. Maybe & 0x7f would be more appropriate?
I never found out the real reason why -1 would not be recognized as
"failure"; the conclusion of my debugging session was that MSYS bash has
an issue, and I chose to append '& 0xff' because the documentation of
WEXITSTATUS() says that it can receive only 8 bits of the exit() code. The
intention of 2488df8 was to keep as much information as possible. But if
that extra information hurts, we should better truncate to 7 bits.
The source code of Windows's C runtime suggests that any value that fits
in 4 bytes can be supplied to exit() and can be received by cwait()
(Windows's version of waitpid()); but I haven't looked at how MSYS
implements waitpit() and whether it can receive that much information.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: Let test_must_fail fail on signals only
From: Junio C Hamano @ 2008-07-17 7:25 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jeff King, Stephan Beyer, git
In-Reply-To: <487EF31D.8090007@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Jeff King schrieb:
>> On Wed, Jul 16, 2008 at 11:31:41PM -0700, Junio C Hamano wrote:
>>> Is it that somebody do not want 255 exit value, or anything that has 7th
>>> bit set? 2488df8 (builtin run_command: do not exit with -1., 2007-11-13)
>>> suggests otherwise at least for Windows runtime, so what we currently have
>>> that does extra truncation ourselves might be sufficient.
>>
>> Johannes will have to answer that; however, the truncation there does
>> leave the extra 7th bit. Maybe & 0x7f would be more appropriate?
>
> I never found out the real reason why -1 would not be recognized as
> "failure"; the conclusion of my debugging session was that MSYS bash has
> an issue, and I chose to append '& 0xff' because the documentation of
> WEXITSTATUS() says that it can receive only 8 bits of the exit() code. The
> intention of 2488df8 was to keep as much information as possible. But if
> that extra information hurts, we should better truncate to 7 bits.
>
> The source code of Windows's C runtime suggests that any value that fits
> in 4 bytes can be supplied to exit() and can be received by cwait()
> (Windows's version of waitpid()); but I haven't looked at how MSYS
> implements waitpit() and whether it can receive that much information.
Well, POSIX cannot do that much anyway, but does allow 8-bit, so I'd say
the current code is fine.
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-17 7:30 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807161804400.8950@racer>
Johannes Schindelin Johannes.Schindelin-at-gmx.de |Lists| wrote:
> there have been a number of occasions where I came across people trying to
> be helpful and teaching Git newbies a few tricks.
>
> However, in quite a number of cases, which seem to surge over the last
> weeks, I see people suggesting the use of rev-parse, ls-tree, rev-list
> etc.
As a total git newbie (5 days) coming from svn, I *am* bewildered. Even
sticking to porcelain, it is a feature-rich new tool I have in my hands!
I'm missing clarity about what is porcelain and what is plumbing. `git
help` shows
"The most commonly used git commands are:" add .. tag.
Is this list exactly the list of porcelain commands? Then say so there.
Neither `git help diff` nor `git help ls-tree` say whether they are
porcelain or plumbing commands. `git help diff` mentions git-diff-index,
which i suspect is plumbing. When I read a man page, it would be nice to
know whether a command (either the topic of the page or another
mentioned command) is intended as porcelain or not.
Also, I'm guessing that some switches for some porcelain commands have
plumbing purposes and vice versa. I hope not, but if so that would be
nice to have documented in 'git help *'
All of this of course assumes that there is consensus and a clear
distinction between what is porcelain and what is plumbing which I'm
don't even know if there is.
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* Re: gitk: Author/Committer name with special characters
From: Torsten Paul @ 2008-07-17 7:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18558.35423.933860.915622@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Something like that, I think, but to be sure I'd like to see the
> actual author and committer lines that are causing the problem. Could
> you send me the output of "git cat-file commit" on one of the
> problematic commits?
>
The header of the commits look like this:
tree 2eaf317290917660c03dc977d5eae180b39420e0
parent e99bf1c38540300c501dbe776de28eed6a2250cd
author DOM\paul <DOM\paul@28e39a90-19ad-e645-8baa-5c9ab2323746> 1216216768 +0000
committer DOM\paul <DOM\paul@28e39a90-19ad-e645-8baa-5c9ab2323746> 1216216768 +0000
With my name it's just not displaying the backslash, but with names
starting with a 't' or even better 'n' it get's more interresting
as they are shown as tab or newline. And that looks very funny in
the commit list view.
ciao,
Torsten.
^ permalink raw reply
* Patterns work unexpectedly with "git log" commit limiting
From: Teemu Likonen @ 2008-07-17 7:47 UTC (permalink / raw)
To: git
It looks to me that some commit limiting options used with "git log"
work a bit buggyish or unexpectedly. Please don't take this as a rant;
I only mean to express some unexpected behaviour in the user interface.
You can be sure that I don't understand the plumbing stuff and
implementation details.
1. Option order changes the behaviour. "git log" with
-E --author=pattern
interprets "pattern" as _basic_ regexp. To have it interpreted as
extended regexp the order must be
--author=pattern -E
BUT the "pattern" in
--author=non-matching-nonsense -E --author=pattern
is interpreted as extended regexp. So -E's behaviour depens on the
preceding options.
2. Internally --author= and --committer= fields contain more stuff than
just person's name and email address. I mean user might expect
--author='@iki.fi>$'
to match all authors with this email host/domain. It took quite some
time for me to realise that the (usually hidden) raw author field
contains also date information, such as "1216023662 +0300". Well,
not a big deal but certainly unexpected in the context of commit
limiting by author.
3. What is the supposed behaviour of -F (--fixed-strings) when combined
with --author= ?
--author=pattern -F
doesn't seem to match anything. I also tried putting the entire raw
author field (i.e. including the raw date) but no match. With -F
before the --author= it behaves like no -F at all.
"--grep=fixedstring -F" seems to work, though.
4. Logical AND/OR operation. I realised that several commit limiting
options combined together do not limit commits more but the
opposite. So it seems like a logical OR operation between the
limiting options. It's fine. It's just that I'd have expected that
more limiting options means limiting more (i.e. the AND operation,
just like in the "find" command normally).
Well, unexpected but I'll survive. Shouldn't this be mentioned under
the title "Commit Limiting" in the man page? (My English is not
really manual-writing quality but I could try to come up with
a patch.)
^ permalink raw reply
* Re: [PATCH 0/5] add pack index v2 reading capability to git v1.4.4.4
From: Junio C Hamano @ 2008-07-17 8:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, git
In-Reply-To: <alpine.LFD.1.10.0807161033170.2835@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 16 Jul 2008, Junio C Hamano wrote:
>>
>> I do not think it should SEGV. The pack-idx signature was chosen rather
>> carefully to allow older ones to die gracefully.
>
> Well, Pasky reported differently.
>
>> error: non-monotonic index
>> error: Could not read 4a588075c54cd5902e5f4d43b9d6b0c31d0f9769
>
> Pasky's report was
>
> error: non-monotonic index
> /usr/bin/git-fetch: line 297: 30402 Segmentation fault git-http-fetch -v -a "$head" "$remote/"
>
> but maybe that was something specific to his case.
It is caused by the http walker not being careful. In v1.4.4.5
http-fetch.c, this code appears unmodified since v1.4.4.4, and an
equivalent code is still in http-walker.c in more recent versions:
static int setup_index(struct alt_base *repo, unsigned char *sha1)
{
struct packed_git *new_pack;
if (has_pack_file(sha1))
return 0; /* don't list this as something we can get */
if (fetch_index(repo, sha1))
return -1;
new_pack = parse_pack_index(sha1);
new_pack->next = repo->packs;
repo->packs = new_pack;
return 0;
}
Nico taught parse_pack_index() what v2 pack idx file looks like, but when
the code hits unknown idx file (or a corrupt one), the function signals
error by returning NULL; assigning to new_pack->next without checking
would segfault.
We would need this fix to futureproof ourselves for pack idx v3 and later,
and also for protecting from a corrupt idx file coming over the wire.
---
http-walker.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/http-walker.c b/http-walker.c
index 51c18f2..9dc6b27 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -442,6 +442,8 @@ static int setup_index(struct walker *walker, struct alt_base *repo, unsigned ch
return -1;
new_pack = parse_pack_index(sha1);
+ if (!new_pack)
+ return -1; /* parse_pack_index() already issued an error message */
new_pack->next = repo->packs;
repo->packs = new_pack;
return 0;
^ permalink raw reply related
* (Remaining) problems with the http backend ?
From: Mike Hommey @ 2008-07-17 8:04 UTC (permalink / raw)
To: git
Hi list,
Except for the typical known stuff such as bad error reporting, people
forgetting to run git update-server-info and lack of support for
packed-refs, are there any other known issues with the http backend ?
Mike
PS: Answers to this post will be used to fill my GIT-HTTP-TODO list.
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-17 8:08 UTC (permalink / raw)
To: git
In-Reply-To: <7vfxqawlja.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
Right now 'next' is very thin. After today's new topics, perhaps except
for the submodule stuff by Pasky, are merged to 'master', we will have the
1.6.0-rc0, and from there the usual pre-release freeze begins.
Due to increased activity level from people including GSoC students, I
expect 'next' to stay somewhat more active than previous rounds during the
1.6.0-rc cycle. The request for people who usually follow 'next' is the
same as usual, though. After -rc1 is tagged, please run 'master' for your
daily git use instead, in order to make sure 'master' does what it claims
to do without regression.
Tentative schedule, my wishful thinking:
- 1.6.0-rc0 (Jul 20)
- 1.6.0-rc1 (Jul 23)
- 1.6.0-rc2 (Jul 30)
- 1.6.0-rc3 (Aug 6)
- 1.6.0 (Aug 10)
----------------------------------------------------------------
[New Topics]
* jc/rerere-auto-more (Wed Jul 16 20:25:18 2008 -0700) 1 commit
- rerere.autoupdate: change the message when autoupdate is in effect
This one is for Ingo.
This changes the message rerere issues after reusing previous conflict
resolution from "Resolved" to "Staged" when autoupdate option is in
effect.
It is envisioned that in practice, some auto resolutions are trickier and
iffier than others, and we would want to add a feature to mark individual
resolutions as "this is ok to autoupdate" or "do not autoupdate the result
using this resolution even when rerere.autoupdate is in effect" in the
future. When that happens, these messages will make the distinction
clearer.
* ap/trackinfo (Wed Jul 16 15:19:27 2008 -0400) 1 commit
- Reword "your branch has diverged..." lines to reduce line length
You saw the exchange on the list. Queued is my "make it shorter and make
sure variable parts are closer to left edge of the screen" version but
better alternatives are welcome. I suspect not many people would care too
much about details, as long as the message fits and does not waste screen
real estate.
* ns/am-abort (Wed Jul 16 19:39:10 2008 +0900) 1 commit
- git am --abort
This one is for Ted; builds on top of the recent "am and rebase leaves
ORIG_HEAD just like reset, merge and pull does" rather nicely.
* pb/submodule (Wed Jul 16 21:11:40 2008 +0200) 7 commits
- t7403: Submodule git mv, git rm testsuite
- git rm: Support for removing submodules
- git mv: Support moving submodules
- submodule.*: Introduce simple C interface for submodule lookup by
path
- git submodule add: Fix naming clash handling
- t7400: Add short "git submodule add" testsuite
- git-mv: Remove dead code branch
Long overdue usability improvement series for submodule. Very much
welcomed. It would be nice to have some submodule improvements in 1.6.0.
Realistically speaking, however, I predict that it would take us a few
more rounds to hit 'next' with this, and it will not be in 'master' when
1.6.0 ships.
----------------------------------------------------------------
[Graduated to "master"]
* sp/maint-index-pack (Tue Jul 15 04:45:34 2008 +0000) 4 commits
+ index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
+ index-pack: Track the object_entry that creates each base_data
+ index-pack: Chain the struct base_data on the stack for traversal
+ index-pack: Refactor base arguments of resolve_delta into a struct
* rs/rebase-checkout-not-so-quiet (Mon Jul 14 14:05:35 2008 -0700) 1 commit
+ git-rebase: report checkout failure
* ag/blame (Wed Jul 16 02:00:58 2008 +0400) 2 commits
+ Do not try to detect move/copy for entries below threshold.
+ Avoid rescanning unchanged entries in search for copies.
This gives a drastic performance improvement to "git-blame -C -C" with
quite straightforward and obvious code change.
* rs/archive (Mon Jul 14 21:22:05 2008 +0200) 6 commits
+ archive: remove extra arguments parsing code
+ archive: unify file attribute handling
+ archive: centralize archive entry writing
+ archive: add baselen member to struct archiver_args
+ add context pointer to read_tree_recursive()
+ archive: remove args member from struct archiver
* sb/dashless (Sun Jul 13 15:36:15 2008 +0200) 3 commits
+ Make usage strings dash-less
+ t/: Use "test_must_fail git" instead of "! git"
+ t/test-lib.sh: exit with small negagive int is ok with
test_must_fail
* mv/dashless (Fri Jul 11 02:12:06 2008 +0200) 4 commits
+ make remove-dashes: apply to scripts and programs as well, not
just to builtins
+ git-bisect: use dash-less form on git bisect log
+ t1007-hash-object.sh: use quotes for the test description
+ t0001-init.sh: change confusing directory name
* ls/mailinfo (Sun Jul 13 20:30:12 2008 +0200) 3 commits
+ git-mailinfo: use strbuf's instead of fixed buffers
+ Add some useful functions for strbuf manipulation.
+ Make some strbuf_*() struct strbuf arguments const.
This actually had a tiny regression I did not discover until I merged it
to 'master', where a fixup has already been applied.
----------------------------------------------------------------
[On Hold]
* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
- Documentation: Improve documentation for git-imap-send(1)
- imap-send.c: more style fixes
- imap-send.c: style fixes
- git-imap-send: Support SSL
- git-imap-send: Allow the program to be run from subdirectories of
a git tree
I said: "Some people seem to prefer having this feature available also
with gnutls. If such a patch materializes soon, that would be good, but
otherwise I'll merge this as-is to 'next'. Such an enhancement can be
done in-tree on top of this series." Anybody?
* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
+ Teach git-merge -X<option> again.
+ Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
+ builtin-merge.c: use parse_options_step() "incremental parsing"
machinery
+ Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
This needs to be merged to master iff/when merge-theirs gets merged,
but I do not think this series is widely supported, so both are on hold.
* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
+ Make "subtree" part more orthogonal to the rest of merge-
recursive.
+ Teach git-pull to pass -X<option> to git-merge
+ Teach git-merge to pass -X<option> to the backend strategy module
+ git-merge-recursive-{ours,theirs}
+ git-merge-file --ours, --theirs
Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged. It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are. The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet. Perhaps
in 1.7.0.
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
+ Revert "Make clients ask for "git program" over ssh and local
transport"
+ Make clients ask for "git program" over ssh and local transport
This is the "botched" one. Will be resurrected during 1.7.0 or 1.8.0
timeframe.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
----------------------------------------------------------------
[Stalled/Needs more work]
* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
. cherry: cache patch-ids to avoid repeating work
The discussion suggested that the value of having the cache itself is
iffy, but I should pick up the updated one and look at it.
* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
. gitweb: use new Git::Repo API, and add optional caching
. Add new Git::Repo API
. gitweb: add test suite with Test::WWW::Mechanize::CGI
* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
. Migrate git-am to use git-sequencer
. Add git-sequencer test suite (t3350)
. Add git-sequencer prototype documentation
. Add git-sequencer shell prototype
I haven't looked at the updated series yet. I should, but nobody else
seems to be looking at these patches, which is somewhat depressing but
understandable. Summer is slower ;-)
* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
- [BROKEN wrt shallow clones] Ignore graft during object transfer
Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck. This fixes object transfer to ignore grafts.
Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
This is for peeling the line from the blamed version to see what's behind
it, which may or may not help applications like gitweb.
^ permalink raw reply
* Re: Patterns work unexpectedly with "git log" commit limiting
From: Junio C Hamano @ 2008-07-17 8:17 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <20080717074706.GA5392@mithlond.arda.local>
Teemu Likonen <tlikonen@iki.fi> writes:
> 1. Option order changes the behaviour. "git log" with
> ...
> 2. Internally --author= and --committer= fields contain more stuff than
> ...
> 3. What is the supposed behaviour of -F (--fixed-strings) when combined
I won't have time right now to comment on the previous three, because they
are not my code (meaning, I need to dig around before I can intelligently
answer -- maybe when I have free time). What you expected does sound very
sensible, though.
> 4. Logical AND/OR operation.
The --grep and --author search of "log" family shares git-grep logical
expression engine, so if you somehow can come up with a way to pass --and
(or even better, --all-match) from the command line just like we can give
them to git-grep, searching with combinations of and/or/not should be doable.
^ permalink raw reply
* Contributors, please check your names
From: Junio C Hamano @ 2008-07-17 8:22 UTC (permalink / raw)
To: git
A handy way to look at the list of contributors is:
$ git shortlog -s --since=6.month
This shows the number of patches in our history for each contributor. The
patch author name (excluding e-mail part) is used for summarizing, and
this allows the same person to send patches under more than one e-mail
address and still count these patches as authored by one person.
Your name however can appear more than once in different spellings, if you
sent patches using different human-readable names on From: line of your
patch submission from the same (or different) e-mail address. E.g. these
two patches are counted under different authors:
Author: A. U. Thor <author@example.xz>
Date: Wed Jul 09:23:06 2008 -0700
The first patch...
Author: A U Thor <author@example.xz>
Date: Wed Jul 09:23:07 2008 -0700
The second patch...
There is a "mailmap" mechanism to consolidate them; it allows us to
specify what human-readable name should be used for given e-mail address.
The hypothetical Mr. Thor might want to say "I am A. U. Thor; some commits
from me, <author@example.xz>, are marked without abbreviating periods in
my name", and we can add this entry to the toplevel .mailmap file to fix
it:
A. U. Thor <author@example.xz>
It tells the shortlog (and --pretty=format:%aN in recent enough git)
mechanism to give huma readable name "A. U. Thor" anytime it sees
<author@example.xz> e-mail address, regardless of what the Author:
header in the commit object says.
If your name appears more than once in the output from the "shortlog"
command at the beginning of this message, you may want to tell me to fix
it.
Thanks.
^ permalink raw reply
* Re: git-svn: Trouble after project has moved in svn
From: Michael J Gruber @ 2008-07-17 8:55 UTC (permalink / raw)
To: git
In-Reply-To: <510143ac0807161512w44a612bcndc53713639b0b70a@mail.gmail.com>
Jukka Zitting venit, vidit, dixit 17.07.2008 00:12:
> Hi,
>
> Somewhat related to the recent thread about Apache Synapse, I'm having
> trouble making a git-svn clone of a project that has been moved around
> in a Subversion repository.
>
> See the script at the end of this message for a simple test case that
> does the following svn commits:
>
> PREPARE: creates projectA with the standard trunk,branches,tags structure
> VERSION1: first version of README.txt in projectA/trunk
> TAG1: tags projectA/trunk to projectA/tags/v1
> MOVE: moves projectA to projectB
> VERSION2: second version of README.txt in projectB/trunk
> TAG2: tags projectB/trunk to projectB/tags/v2
>
> The resulting repository structure is:
>
> /projectB/
> trunk/
> README.txt # version 2
> branches/
> tags/
> v1/
> README.txt # version 1
> v2/
> README.txt # version 2
>
> Here's the git commit graph created by the test case:
>
> * TAG2 <- refs/remotes/tags/v2
> | * VERSION2 <- refs/remotes/trunk
> |/
> * MOVE
> * VERSION1 <- refs/remotes/trunk@3
> | * MOVE <- refs/remotes/tags/v1
> | * TAG1 <- refs/remotes/tags/v1@3
> |/
> * PREPARE <- refs/remotes/tags/v1@1
>
> The most pressing issue is that the refs/remotes/tags/v1 branch starts
> directly from the first PREPARE commit instead of VERSION1. Also, the
> branch point of refs/remotes/tags/v2 seems to be incorrect, it should
> be based on the VERSION2 commit instead of MOVE.
In the script below, you use copies inside your svn working copy for
tagging, which is generally a bad idea: it stores the exact state of
your wc as a "tag". Use this for creating "mixed states", but not for
ordinary tagging (or make sure you svn up). See the detailed comments below.
If you want to create an svn tag (as far as svn has tags at all) use
repo urls, or make sure your wc is up to date.
> =====
> #!/bin/sh
>
> REPO=`pwd`/repo
> svnadmin create $REPO
>
> svn checkout file://$REPO checkout
> cd checkout
>
> svn mkdir projectA
> svn mkdir projectA/trunk
> svn mkdir projectA/branches
> svn mkdir projectA/tags
> svn commit -m PREPARE
>
> echo VERSION1 > projectA/trunk/README.txt
> svn add projectA/trunk/README.txt
> svn commit -m VERSION1
Now, README.txt is at r2, but trunk is still at r1.
Use "svn update" here to get trunk to r2!
> svn copy projectA/trunk projectA/tags/v1
This copies r1 of trunk to the tags dir (unless you've inserted svn up
above)!
> svn commit -m TAG1
> svn update
>
> svn move projectA projectB
> svn commit -m MOVE
>
> echo VERSION2 > projectB/trunk/README.txt
> svn commit -m VERSION2
Now, README.txt is at r5, but trunk is at r4.
"svn update"!
> svn copy projectB/trunk projectB/tags/v2
This tags (copies to tags/) r4 of trunk
> svn commit -m TAG2
> svn update
This produces r6: the tagging.
>
> mkdir ../git
> cd ../git
>
> git svn init -s file://$REPO/projectB
> git svn fetch
The results perfectly as expected. Compare "svn log -v" with git-svn's
results, and you'll see that git (tag) branches fork off exactly at the
revisions which you tagged in svn. Because the last commit occurs on
tags/v2, git-svn checks out that branch as master, the supposedly
"active" branch.
If you insert the two missing "svn update" commands which bring your wc
up to date before tagging your git-svn results will be what you expected.
Cheers,
Michael
^ permalink raw reply
* Re: Patterns work unexpectedly with "git log" commit limiting
From: Petr Baudis @ 2008-07-17 8:59 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <20080717074706.GA5392@mithlond.arda.local>
Hi,
On Thu, Jul 17, 2008 at 10:47:06AM +0300, Teemu Likonen wrote:
> 3. What is the supposed behaviour of -F (--fixed-strings) when combined
> with --author= ?
>
> --author=pattern -F
>
> doesn't seem to match anything. I also tried putting the entire raw
> author field (i.e. including the raw date) but no match. With -F
> before the --author= it behaves like no -F at all.
>
> "--grep=fixedstring -F" seems to work, though.
this is actually very high on my TODO list, since it makes
author/committer search in gitweb disfunctional. I plan to post a patch
fixing this in a few days, unless someone beats me to it as usual. ;-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: (Remaining) problems with the http backend ?
From: Petr Baudis @ 2008-07-17 9:08 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20080717080419.GA23489@glandium.org>
Hi,
On Thu, Jul 17, 2008 at 10:04:20AM +0200, Mike Hommey wrote:
> PS: Answers to this post will be used to fill my GIT-HTTP-TODO list.
could you please post the final todo list, possibly as a patch for the
todo branch? (I wonder how Junio would feel about that.) I have actually
been pondering to do the same, with some of my more interesting TODO
lists.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: git submodules and commit
From: Nigel Magnay @ 2008-07-17 9:47 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Git Mailing List
In-Reply-To: <32541b130807160843k25f1d7d3u8bfecd6c1c6eab91@mail.gmail.com>
On Wed, Jul 16, 2008 at 4:43 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> On 7/16/08, Nigel Magnay <nigel.magnay@gmail.com> wrote:
>> I wonder if this is a fairly common pattern. We tend to have modules
>> as git repositories, and projects that tie together those git
>> repositories as submodules. [and submodules are necessary because they're
>> shared between multiple supermodules].
>
> I have exactly the same problem as you, and have been working on
> improving my own workflow so that someday I can offer patches that
> might be generally applicable.
>
> In the meantime, my solution is... some shell scripts checked in at
> the top level of my project. :)
>
> In one of my applications, I have a /wv submodule, which provides a
> cross-platform build environment. That environment respectively
> contains a /wv/wvstreams submodule, which is a library that we use.
>
> When I make a change to wvstreams that's needed for my application, I
> need to check into wvstreams, then check that link into wv, then check
> that link into the application. Then, when I push, I have to make
> sure to always push wvstreams first, then wv, then application, or
> else other users can end up with "commit id xxxxxx not found" type
> errors.
>
> So basically, committing is always harmless, since I can do anything I
> want in my own repo (and I want to be able to update wvstreams
> *without* always updating wv, and so on). The tricky part is pushing.
> Here's the script I wrote to make sure I don't screw up when pushing:
>
>
> ~/src/vx-lin $ cat push-git-modules
> #!/bin/sh -x
> set -e
> test -e wv/wvstreams/Makefile
> (cd wv/wvstreams && git push origin HEAD:master) &&
> (cd wv && git push origin HEAD:master) &&
> git push origin HEAD:master ||
> echo "Failed!"
>
>
> Now, this script is pretty flawed. Notably, it always pushes to the
> 'master' branch, which is stupid. However, it works in our particular
> workflow, because wvstreams isn't being modified by too many
> developers and it's okay if we all commit to master. This is also
> aided by the fact that people are trained to push only after they've
> made all the unit tests pass, etc. And further, individual apps don't
> have to update their wvstreams to the latest anyway unless they really
> need the latest changes, which is a wonderful feature of git
> submodules.
>
Yes - I use something rather similar on my desktop. The unfortunate
thing is that I know how submodules work, and am happy with the
scripts. My users are sometimes in the 'git gui' types - not as
technically literate, and likely on Windows.
> Now, sometimes the above push script will fail. In my experience,
> this is only when someone else has pushed in something before you,
> which means a fast-forward is not possible on at least one of the
> repos. When that happens, you have to pull first, using this script:
>
> ~/src/vx-lin $ cat newest-git-modules
> #!/bin/sh -x
> set -e
> test -e wv/wvstreams/Makefile
> git pull origin master &&
> (cd wv && git pull origin master) &&
> (cd wv/wvstreams && git pull origin master) ||
> echo "Failed!"
>
> This pulls in the latest version of application, wv, and wvstreams, in
> that order, and stops in case of any merge conflicts so that you can
> resolve them by hand. It's safe to run the above script more than
> once in case you're not sure if it's done or not.
>
> After pulling the new modules, you may need to make new commits to
> update to the latest submodule commits - if that's indeed what you
> want. And then you can run push-git-modules, and be reasonably
> assured that it will work (unless someone made another push while you
> were fixing conflicts).
>
Yeah - this happens a lot. If someone else commits to the
super-project before you, it's always a conflict. What's annoying is
there's no way around it (though resolution is easy - force to current
- but it this is a big bit of what confuses my users. They say 'but I
already resolved the merges in the submodule itself'. I'm not sure
there's an easy way around it though - and this is part of my worry
that there's hidden complexity with trying to make it 'look like 1 big
repo').
> Finally, I have another script that retrieves the *currently linked*
> version of the git modules. I wish git-checkout would do this
> automatically, but it doesn't, for apparently-difficult-to-resolve
> safety reasons. Anyway, note that this script uses the existence of
> submodule/Makefile as "proof" that the submodule was checked out
> correctly.
>
>
> ~/src/vx-lin $ cat get-git-modules
> #!/bin/sh -x
> set -e
> git submodule init
> git submodule update
> test -e wv/Makefile
> (cd wv && git submodule init && git submodule update)
> test -e wv/wvstreams/Makefile
>
>
>> I guess it probably gets sticky when there are merge conflicts. Is
>> anyone working on this kind of thing; I might be able to give some
>> time to help work on it?
>
> So as you can see, my scripts are crappy. However, they have already
> drastically reduced the number of mistakes made by developers in my
> group (especially commits lost due to 'git submodule update' at the
> wrong time, and pushes of the supermodule before the submodule).
>
Yeah. I have an additional usecase, which is around pulling from
another user. If they've made changes in their tree(s) that they want
to get reviewed, normally I could do something like
git fetch ssh://joebloggs.computer/blah +refs/heads/*:refs/remotes/joebloggs/*
But if they've made cross-module changes, I'm SOL, as fetching their
super-project will have references to commits that aren't in the repo
mentioned in .gitmodules (only in joebloggs's tree) - so doing git
submodule update doesn't help. I have to go into each submodule and
explicitly fetch. It feels wierdly centralised for this otherwise
distributed tool.
> If you want to work with me on my new submodule workflow (and I'd
> certainly appreciate it!) then I'd suggest one or more of the
> following starting points:
>
> - Take the recursive push, pull, and update operations described
> above, make them general (ie. not referring to my submodules by name
> :)), and add them as commands in the real git-submodule script. The
> trickiest part here will be figuring out which remote branch to
> push/pull.
>
What's bugging me is I'm not sure that it's the right place. It seems
(to me) that having the only place that knows about submodules being
the 'git submodules' script isn't right. What users want is 'git fetch
<blah>' to do the lot - that, for the most, it ought to do the
submodule init, update and clever stuff automatically. That if 'git
fetch' is porcelain, then the porcelain needs to call the
git-submodule stuff.
But - perhaps it's best to approach it as scripts for now :)
> - Perhaps add a "recursive commit" operation that recursively
> auto-commits submodule refs, for use after running the
> newest-git-modules script. The commit message could be auto-generated
> using something like "git-whatchanged" on the submodule.
>
Hm - I'd be happy with the same commt message in all modules. What I
want is to be able to do (from the top) 'git commit -a' or the same
with the GUI, and see all the files to be committed regardless of
whether they're in a submodule or not.
I'm guessing you probably need to build a tree of submodules, and
commit from the tips backwards towards the top level superproject.
This is what the users want - something that mirrors 'svn ci' at the
top level - "Please Check All My stuff in".
> - See what can be done about making git-checkout automatically
> git-submodule-update *if and only if* the currently checked-out commit
> of the submodule exactly matches the one that was checked out last
> time, *and* the desired commit is already available in the submodule
> repo (which is not necessarily the case, if you haven't fetched it
> yet). That is, as with any file in git, if it hasn't changed from the
> one in the repo, you know you won't lose any information if you just
> auto-replace it with the new version.
>
> - Fix git-submodule-update to not just switch submodule branches if
> you've made checkins in that submodule. Right now, commits to a
> submodule by default don't go to any branch, so if you subsequently
> run git-submodule-update, your commits are lost (except for the
> reflog). This is very un-git-like in general, and
> git-submodule-update should be much more polite.
We always move back onto a branch immediately after submodule update,
which is another thing to forget!
>
> Note that git-submodule is only about 800 lines of shell. It's
> remarkably straightforward to make it do whatever you want. The hard
> part is figuring out what you want, and making sure you don't stomp on
> *other* people's workflows while you're there.
>
Totally.
> Also note that even if you don't contribute any of the above, I'm
> planning to someday make time to do it myself :) But don't hold your
> breath. I've been busy.
>
Ditto.
> Have fun,
>
> Avery
>
^ permalink raw reply
* Re: [PATCH] guilt(1): fix path to git-sh-setup
From: Petr Baudis @ 2008-07-17 10:02 UTC (permalink / raw)
To: Alex Chiang, jeffpc, git
In-Reply-To: <20080716232339.GC22919@ldl.fc.hp.com>
On Wed, Jul 16, 2008 at 05:23:39PM -0600, Alex Chiang wrote:
> diff --git a/guilt b/guilt
> index 50414a4..ba4593a 100755
> --- a/guilt
> +++ b/guilt
> @@ -23,7 +23,7 @@ esac
> # we change directories ourselves
> SUBDIRECTORY_OK=1
>
> -. git-sh-setup
> +. `git --exec-path`/git-sh-setup
Beware of the proverbial "/Program Files/Git" location, however.
Petr "Pasky" Baudis
^ permalink raw reply
* [PATCH] testsuite for cvs co -c
From: Lars Noschinski @ 2008-07-17 10:01 UTC (permalink / raw)
To: git; +Cc: fabian.emmes, Lars Noschinski
In-Reply-To: <1216288877-12140-5-git-send-email-lars@public.noschinski.de>
From: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Check that all branches are displayed.
Signed-off-by: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
t/t9400-git-cvsserver-server.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index d181b5b..3a59b9f 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -484,4 +484,15 @@ test_expect_success 'cvs status (no subdirs in header)' '
! grep / <../out
'
+#------------
+# CVS CHECKOUT
+#------------
+
+cd "$WORKDIR"
+test_expect_success 'cvs co -c (shows module database)' '
+ GIT_CONFIG="$git_config" cvs co -c > out &&
+ grep "^master[ ]\+master$" < out &&
+ ! grep -v "^master[ ]\+master$" < out
+'
+
test_done
--
1.5.6.2
^ permalink raw reply related
* [PATCH] cvsserver: Add testsuite for packed refs
From: Lars Noschinski @ 2008-07-17 10:01 UTC (permalink / raw)
To: git; +Cc: fabian.emmes, Lars Noschinski
In-Reply-To: <1216288877-12140-3-git-send-email-lars@public.noschinski.de>
From: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Check that req_update shows refs, even if all refs are packed.
Signed-off-by: Fabian Emmes <fabian.emmes@rwth-aachen.de>
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
t/t9400-git-cvsserver-server.sh | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index e97aaa6..d181b5b 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -438,6 +438,20 @@ test_expect_success 'cvs update (-p)' '
test -z "$(cat failures)"
'
+cd "$WORKDIR"
+cat > get_update_modules <<EOF
+Root $SERVERDIR
+Directory .
+$SERVERDIR
+update
+EOF
+
+test_expect_success 'cvs update (module list supports packed refs)' '
+ git pack-refs --all &&
+ git cvsserver server < get_update_modules > out &&
+ grep "^M master[ ]\+master$" < out
+'
+
#------------
# CVS STATUS
#------------
--
1.5.6.2
^ permalink raw reply related
* [PATCH] cvsserver: Add cvs co -c support
From: Lars Noschinski @ 2008-07-17 10:01 UTC (permalink / raw)
To: git; +Cc: fabian.emmes, Lars Noschinski
In-Reply-To: <1216288877-12140-4-git-send-email-lars@public.noschinski.de>
Implement cvs checkout's -c option by returning a list of all "modules".
This is more useful than displaying a perl warning if -c is given.
Signed-off-by: Lars Noschinski <lars@public.noschinski.de>
---
git-cvsserver.perl | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 0e4f5f9..afd9789 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -801,6 +801,19 @@ sub req_co
argsplit("co");
+ # Provide list of modules, if -c was used.
+ if (exists $state->{opt}{c}) {
+ my $showref = `git show-ref --heads`;
+ for my $line (split '\n', $showref) {
+ if ( $line =~ m% refs/heads/(.*)$% ) {
+ print "M $1\t$1\n";
+ }
+ }
+ closedir HEADS;
+ print "ok\n";
+ return 1;
+ }
+
my $module = $state->{args}[0];
$state->{module} = $module;
my $checkout_path = $module;
--
1.5.6.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox