* Re: [PATCH 03/14] Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
From: Junio C Hamano @ 2009-08-21 22:11 UTC (permalink / raw)
To: Johannes Sixt
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <200908212341.37531.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Not quite. The parameter *is* the size of the buffer and vsnprintf does not
> write beyond the buffer. However, it has the awkward behavior that if the
> buffer is too short by exactly one byte...
Thanks; I was fooled by the leading comment. How about ...
compat/snprintf.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/compat/snprintf.c b/compat/snprintf.c
index 6c0fb05..4d07087 100644
--- a/compat/snprintf.c
+++ b/compat/snprintf.c
@@ -3,7 +3,8 @@
/*
* The size parameter specifies the available space, i.e. includes
* the trailing NUL byte; but Windows's vsnprintf expects the
- * number of characters to write without the trailing NUL.
+ * number of characters to write, and does not necessarily write the
+ * trailing NUL.
*/
#ifndef SNPRINTF_SIZE_CORR
#if defined(__MINGW32__) && defined(__GNUC__) && __GNUC__ < 4
^ permalink raw reply related
* Re: What's cooking in git.git (Aug 2009, #03; Thu, 20)
From: Junio C Hamano @ 2009-08-21 21:43 UTC (permalink / raw)
To: Mark A Rada; +Cc: Jakub Narebski, git
In-Reply-To: <F4C7A2F3-B030-449A-87AC-B54CA2B647B4@mailservices.uwaterloo.ca>
Mark A Rada <marada@uwaterloo.ca> writes:
> Unless I missed a case, the tests show that the extra condition check
> that was added in the &git_snapshot routine is never actually executed,
> because a disabled snapshot format is not added to @snapshot_fmts, which
> is checked first.
>
> snippet:
> 5178 } elsif (!grep($_ eq $format, @snapshot_fmts)) {
> 5179 die_error(403, "Unsupported snapshot format");
> 5180 } elsif ($known_snapshot_formats{$format}{'disabled'}) {
> 5181 die_error(403, "Snapshot format not allowed");
> 5182 }
> 5183
True; filter_snapshot_fmts looks at 'disabled' first.
I do not mind keeping these two lines as belt-and-suspender, though.
^ permalink raw reply
* Re: Continue git clone after interruption
From: Jakub Narebski @ 2009-08-21 21:41 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Tomasz Kontusz, git, Johannes Schindelin, Scott Chacon
In-Reply-To: <alpine.LFD.2.00.0908211614220.6044@xanadu.home>
On Fri, 21 Aug 2009, Nicolas Pitre wrote:
> On Fri, 21 Aug 2009, Jakub Narebski wrote:
>> On Thu, 20 Aug 2009, Nicolas Pitre wrote:
>>> On Thu, 20 Aug 2009, Jakub Narebski wrote:
>>>> It is however only 2.5 MB out of 37 MB that are resumable, which is 7%
>>>> (well, that of course depends on repository). Not that much that is
>>>> resumable.
>>>
>>> Take the Linux kernel then. It is more like 75 MB.
>>
>> Ah... good example.
>>
>> On the other hand Linux is fairly large project in terms of LoC, but
>> it had its history cut when moving to Git, so the ratio of git-archive
>> of HEAD to the size of packfile is overemphasized here.
>
> That doesn't matter. You still need that amount of data up front to do
> anything. And I doubt people with slow links will want the full history
> anyway, regardless if it goes backward 4 years or 18 years back.
On the other hand unreliable link doesn't need to mean unreasonably
slow link.
Hopefully GitTorrent / git-mirror-sync would finally come out of
vapourware and wouldn't share the fate of Duke Nukem Forever ;-),
and we would have this as an alternative to clone large repositories.
Well, supposedly there is some code, and last year GSoC project at
least shook the dust out of initial design and made it simplier, IIUC.
>> You make use here of a few facts:
[...]
>> 2. There is support in git pack format to do 'deepening' of shallow
>> clone, which means that git can generate incrementals in top-down
>> order, _similar to how objects are ordered in packfile_.
>
> Well... the pack format was not meant for that "support". The fact that
> the typical object order used by pack-objects when serving fetch request
> is amenable to incremental top-down updates is rather coincidental and
> not really planned.
Ooops. I meant "git pack PROTOCOL" here, not "git pack _format_".
the one about want/have/shallow/deepen exchange.
[...]
>>> A special
>>> mode to pack-object could place commit objects only after all the
>>> objects needed to create that revision. So once you get a commit object
>>> on the receiving end, you could assume that all objects reachable from
>>> that commit are already received, or you had them locally already.
>>
>> Yes, with such mode (which I think wouldn't reduce / interfere with
>> ability for upload-pack to pack more tightly by reordering objects
>> and choosing different deltas) it would be easy to do a salvage of
>> a partially completed / transferred packfile. Even if there is no
>> extension to tell git server which objects we have ("have" is only
>> about commits), if there is at least one commit object in received
>> part of packfile, we can try to continue from later (from more);
>> there is less left to download.
>
> Exact. Suffice to set the last received commit(s) (after validation) as
> one of the shallow points.
Assuming that received commit is full (has all prerequisites), and
is connected to the rest of body of partially [shallow] cloned
repository.
>>>> Documentation/technical/shallow.txt doesn't cover "shallow", "unshallow"
>>>> and "deepen" commands from 'shallow' capability extension to git pack
>>>> protocol (http://git-scm.com/gitserver.txt).
>>>
>>> 404 Not Found
>>>
>>> Maybe that should be committed to git in Documentation/technical/ as
>>> well?
>>
>> This was plain text RFC for the Git Packfile Protocol, generated from
>> rfc2629 XML sources at http://github.com/schacon/gitserver-rfc
>
> I suggest you track it down and prod/propose a version for merging in
> the git repository.
Scott Chacon was (and is) CC-ed.
I don't know if you remember mentioned discussion about pack protocol,
stemming from the fact that some of git (re)implementations (Dulwich,
JGit) failed to implement it properly, where properly = same as
git-core, i.e. the original implementation in C... because there were
not enough documentation.
>>>> P.S. As you can see implementing resumable clone isn't easy...
>>>
>>> I've been saying that all along for quite a while now. ;-)
>>
>> Well, on the other hand side we have example of how long it took to
>> come to current implementation of git submodules. But if finally
>> got done.
>
> In this case there is still no new line of code what so ever. Thinking
> it through is what takes time.
Measure twice, cut once :-)
In this case I think design upfront is a good solution.
>> The git-archive + deepening approach you proposed can be split into
>> smaller individual improvements. You don't need to implement it all
>> at once.
[...]
>> 3. Create new git-archive pseudoformat, used to transfer single commit
>> (with commit object and original branch name in some extended header,
>> similar to how commit ID is stored in extended pax header or ZIP
>> comment). It would imply not using export-* gitattributes.
>
> The format I was envisioning is really simple:
>
> First the size of the raw commit object data content in decimal,
> followed by a 0 byte, followed by the actual content of the commit
> object, followed by a 0 byte. (Note: this could be the exact same
> content as the canonical commit object data with the "commit" prefix,
> but as all the rest are all blob content this would be redundant.)
>
> Then, for each file:
>
> - The file mode in octal notation just as in tree objects
> - a space
> - the size of the file in decimal
> - a tab
> - the full path of the file
> - a 0 byte
> - the file content as found in the corresponding blob
> - a 0 byte
>
> And finally some kind of marker to indicate the end of the stream.
>
> Put the lot through zlib and you're done.
So you don't want to just tack commit object (as extended pax header,
or a comment - if it is at all possible) to the existing 'tar' and
'zip' archive formats. Probably better to design format from scratch.
>> 4. Implement alternate ordering of objects in packfile, so commit object
>> is put immediately after all its prerequisites.
>
> That would require some changes in the object enumeration code which is
> an area of the code I don't know well.
Oh.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 03/14] Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
From: Johannes Sixt @ 2009-08-21 21:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <7vr5v4dgz0.fsf@alter.siamese.dyndns.org>
On Freitag, 21. August 2009, Junio C Hamano wrote:
> Marius Storm-Olsen <mstormo@gmail.com> writes:
> > From: Frank Li <lznuaa@gmail.com>
> >
> > The Microsoft C runtime's vsnprintf function does not add NUL at
> > the end of the buffer.
>
> This contradicts the way I read the comment in compat/snprintf.c from
> f4626df (Add target architecture MinGW., 2007-12-01).
>
> As far as I can see, the correction is about the meaning of the size
> parameter to the function, namely, that a broken implementation may
> mistakenly think that it was told the maximum length of the meat of the
> string to write, and it is allowed to append a NUL beyond the limit, when
> the caller actually is telling it the size of the buffer.
Not quite. The parameter *is* the size of the buffer and vsnprintf does not
write beyond the buffer. However, it has the awkward behavior that if the
buffer is too short by exactly one byte, i.e. there is room for the complete
string, but not for the terminating NUL, then vsnprintf does not report an
error!
Therefore, we tell vsnprintf that the buffer is shorter by one byte and always
write NUL in the last position so that we get a correctly terminated string
even in this case.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add tests for rev-list --graph with options that simplify history
From: Adam Simpkins @ 2009-08-21 21:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vbpm8exeo.fsf@alter.siamese.dyndns.org>
On Fri, Aug 21, 2009 at 01:15:27PM -0700, Junio C Hamano wrote:
> Adam Simpkins <simpkins@facebook.com> writes:
>
> > +# There's more than one "correct" way to represent the history graphically.
> > +# These tests depend on the current behavior of the graphing code. If the
> > +# graphing code is ever changed to draw the output differently, these tests
> > +# cases will need to be updated to know about the new layout.
>
> An ideal solution to such a problem would be not to write the tests that
> way to require _the exact layout_ of the output.
Yeah. In the past I've been hesitant to submit tests for the graph
behavior for precisely this reason. However, having tests that check
the exact layout seems better than not having tests at all.
> What was the bug you were trying to fix? Was it that in a simplified
> history some arcs are not connected whey they should be?
It was an issue with a missing arc between two commits that should
have been connected. In the past, other bugs (e.g., the one fixed in
2ecbd0a0) have caused arcs to appear connected to the wrong commit.
> Can you test that without relying on other aspect (say, commits are marked
> with '*' right now but a patch might change it to '^' for some commits) of
> the output?
>
> I am just wondering how feasible it is the problem you are trying to
> solve, not demanding you to solve it.
In general, it seems like its not worthwhile trying to solve this
problem. I don't expect changes to the graph layout to occur often.
Modifying this test case if and when they do occur seems simpler and
less error-prone than trying to write code that attempts to anticipate
changes we might make in the future.
When I wrote this comment, I was thinking more about potential changes
in the way arcs are drawn in the output, or in the amount of padding.
The problem you mentioned (accepting other characters other than '*'
for commits) is easier, but I'm still not convinced we should try to
solve it. For example, it's nice that the current code also tests
that boundary commits are represented differently than non-boundary
commits. Being too permissive in what we accept could also
potentially hide bugs in the future.
--
Adam Simpkins
simpkins@facebook.com
^ permalink raw reply
* Re: git rebase --interactive problem
From: Alex Riesen @ 2009-08-21 21:18 UTC (permalink / raw)
To: Lenka Dubcova; +Cc: git
In-Reply-To: <1250889145942-3492625.post@n2.nabble.com>
On Fri, Aug 21, 2009 at 23:12, Lenka Dubcova<dubcova@gmail.com> wrote:
> Unknown command: sqaush 43ce3ae my commit message
> Please fix this in the file
> /home/lenka/hermes2d/.git/.dotest-merge/git-rebase-todo.
>
> Moreover it jumped from my branch to (no branch).
>
> So I corrected it in "git-rebase-todo" and saved, but I don't know what to
> do next.
Try "git rebase --continue"
^ permalink raw reply
* Re: [PATCH 03/14] Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
From: Johan 't Hart @ 2009-08-21 21:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <7vr5v4dgz0.fsf@alter.siamese.dyndns.org>
Junio C Hamano schreef:
> Marius Storm-Olsen <mstormo@gmail.com> writes:
>
>> From: Frank Li <lznuaa@gmail.com>
>>
>> The Microsoft C runtime's vsnprintf function does not add NUL at
>> the end of the buffer.
> So if my reading is correct, it is not about "does not add NUL at the end"
> at all; it is "adds NUL beyond the end of given output buffer."
>
As far as I know, the windows implementation does not add a terminating
NUL when the string to write is greater or equal to the given buffer
size. Otherwise it does add the NUL.
Same as for strncpy() on windows.
In my experience the windows implementation does never write behind the
given buffer, not even a terminating zero.
^ permalink raw reply
* Re: [PATCH 09/14] Avoid including windows.h in winansi.c for MSVC build
From: Reece Dunn @ 2009-08-21 21:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <7vmy5sdgoc.fsf@alter.siamese.dyndns.org>
2009/8/21 Junio C Hamano <gitster@pobox.com>:
> Marius Storm-Olsen <mstormo@gmail.com> writes:
>
>> From: Frank Li <lznuaa@gmail.com>
>>
>> compat/msvc.h includes winsock2.h which conflicts with windows.h.
>> msvc.h also defines the oldest Windows API version required.
>
> The first sentence sort-of makes sense; compat/msvc.h will be included by
> git-compat-util.h and including <windows.h> here will bring conflicting
> definitions, so we avoid doing so when on MSC.
>
> The second sentence does not make any sense to me. It may be correctly
> stating a fact (i.e. "defines required WAPI version"), but it is unclear
> what relevance it has to this change to stop including <windows.h>.
The way things are configured, windows.h is pulling in winsock.h. In
git-compat-util.h, winsock2.h is included which has conflicting
definitions of various functions and data structures.
> Having said that, the first sentence hints me that perhaps you guys should
> include (conditionally only on windows but not with MSC) <windows.h> not
> from this file, but from git-compat-util.h?
It would make sense for windows.h to be included in git-compat-util.h.
According to http://social.msdn.microsoft.com/Forums/en-US/windowssdk/thread/4a90b143-1fb8-43e9-a54c-956127e0c579,
the following will work:
#define _WINSOCKAPI_ // stops windows.h including winsock.h
#include <winsock2.h>
#include <windows.h>
Also, if you define WIN32_LEAN_AND_MEAN, windows.h will pull in a
subset of the Windows header files (which also improves compilation
times). Adding this may prevent it from pulling in winsock.h. This
would be a better approach (and would make sense to go into
git-compat-util.h).
I don't have access to a Windows dev box at the moment, so can't
verify that this does indeed work.
- Reece
^ permalink raw reply
* git rebase --interactive problem
From: Lenka Dubcova @ 2009-08-21 21:12 UTC (permalink / raw)
To: git
Hi,
I wanted to squash one commit to another using git rebase --interactive
HEAD~2, but I made a typo, instead of squash I wrote sqaush, so it stopped
and left this message
Unknown command: sqaush 43ce3ae my commit message
Please fix this in the file
/home/lenka/hermes2d/.git/.dotest-merge/git-rebase-todo.
Moreover it jumped from my branch to (no branch).
So I corrected it in "git-rebase-todo" and saved, but I don't know what to
do next.
Thanks,
Lenka
--
View this message in context: http://n2.nabble.com/git-rebase-interactive-problem-tp3492625p3492625.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Continue git clone after interruption
From: Nicolas Pitre @ 2009-08-21 21:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tomasz Kontusz, git, Johannes Schindelin, Scott Chacon
In-Reply-To: <200908211207.38555.jnareb@gmail.com>
On Fri, 21 Aug 2009, Jakub Narebski wrote:
> On Thu, 20 Aug 2009, Nicolas Pitre wrote:
> > On Thu, 20 Aug 2009, Jakub Narebski wrote:
> >> It is however only 2.5 MB out of 37 MB that are resumable, which is 7%
> >> (well, that of course depends on repository). Not that much that is
> >> resumable.
> >
> > Take the Linux kernel then. It is more like 75 MB.
>
> Ah... good example.
>
> On the other hand Linux is fairly large project in terms of LoC, but
> it had its history cut when moving to Git, so the ratio of git-archive
> of HEAD to the size of packfile is overemphasized here.
That doesn't matter. You still need that amount of data up front to do
anything. And I doubt people with slow links will want the full history
anyway, regardless if it goes backward 4 years or 18 years back.
> You make use here of a few facts:
>
> 1. Objects in packfile are _usually_ sorted in recency order, with most
> recent commits, and most recent versions of trees and tags being in
> the front of pack file, and being base objects for a large set of
> objects. Note the "usually" part; it is not set in stone as for RCS
> (and CVS) reverse delta based repository format.
Exact. In theory the object order could be totally random and the pack
would still be valid. The only restriction at the moment has to do with
OFS_DELTA objects as the reference to the base object is encoded as a
downward offset from the beginning of that OFS_DELTA object. Hence the
base object has to appear first. In the case of REF_DELTA objects, the
base can be located anywhere in the pack (or anywhere else outside of
the pack in the thin pack case).
> 2. There is support in git pack format to do 'deepening' of shallow
> clone, which means that git can generate incrementals in top-down
> order, _similar to how objects are ordered in packfile_.
Well... the pack format was not meant for that "support". The fact that
the typical object order used by pack-objects when serving fetch request
is amenable to incremental top-down updates is rather coincidental and
not really planned.
> 3. git-archive output is stable. _git-archive can be made resumable_
> (with range/partial requests), and can be made so it can create
> single-head depth 0 shallow clone.
>
> Also, with top-down deepening order even if you don't use
> 'git clone --continue' but 'git clone --skip' (or something), you
> would have got usable shallow clone. In the most extreme case when
> you are able to get only the fully resumable part, i.e. git-archive
> part (with top commit), you would have single-branch depth 0
> shallow clone (not very usable, but still better than nothing).
Right.
> > A special
> > mode to pack-object could place commit objects only after all the
> > objects needed to create that revision. So once you get a commit object
> > on the receiving end, you could assume that all objects reachable from
> > that commit are already received, or you had them locally already.
>
> Yes, with such mode (which I think wouldn't reduce / interfere with
> ability for upload-pack to pack more tightly by reordering objects
> and choosing different deltas) it would be easy to do a salvage of
> a partially completed / transferred packfile. Even if there is no
> extension to tell git server which objects we have ("have" is only
> about commits), if there is at least one commit object in received
> part of packfile, we can try to continue from later (from more);
> there is less left to download.
Exact. Suffice to set the last received commit(s) (after validation) as
one of the shallow points.
> >> Documentation/technical/shallow.txt doesn't cover "shallow", "unshallow"
> >> and "deepen" commands from 'shallow' capability extension to git pack
> >> protocol (http://git-scm.com/gitserver.txt).
> >
> > 404 Not Found
> >
> > Maybe that should be committed to git in Documentation/technical/ as
> > well?
>
> This was plain text RFC for the Git Packfile Protocol, generated from
> rfc2629 XML sources at http://github.com/schacon/gitserver-rfc
I suggest you track it down and prod/propose a version for merging in
the git repository.
> The description in Documentation/technical/pack-protocol.txt is very
> brief, and Documentation/technical/shallow.txt doesn't cover 'shallow'
> capability of git pack protocol.
Yeah. I finally had a look directly at the code to understand how it
works.
> >> P.S. As you can see implementing resumable clone isn't easy...
> >
> > I've been saying that all along for quite a while now. ;-)
>
> Well, on the other hand side we have example of how long it took to
> come to current implementation of git submodules. But if finally
> got done.
In this case there is still no new line of code what so ever. Thinking
it through is what takes time.
> The git-archive + deepening approach you proposed can be split into
> smaller individual improvements. You don't need to implement it all
> at once.
>
> 1. Improve deepening of shallow clone. This means sending only required
> objects, and being able to use as a base objects that other side has
> and send thin pack.
Yes. And now that I understand how shallow clones are implemented, I
Probably will fix that flaw soon. Won't be hard at all.
> 2. Add support for resuming (range request) of git-archive. It is up
> to client to translate size of partial transfer of compressed file
> into range request of original (uncompressed) archive.
>
> 3. Create new git-archive pseudoformat, used to transfer single commit
> (with commit object and original branch name in some extended header,
> similar to how commit ID is stored in extended pax header or ZIP
> comment). It would imply not using export-* gitattributes.
The format I was envisioning is really simple:
First the size of the raw commit object data content in decimal,
followed by a 0 byte, followed by the actual content of the commit
object, followed by a 0 byte. (Note: this could be the exact same
content as the canonical commit object data with the "commit" prefix,
but as all the rest are all blob content this would be redundant.)
Then, for each file:
- The file mode in octal notation just as in tree objects
- a space
- the size of the file in decimal
- a tab
- the full path of the file
- a 0 byte
- the file content as found in the corresponding blob
- a 0 byte
And finally some kind of marker to indicate the end of the stream.
Put the lot through zlib and you're done.
> 4. Implement alternate ordering of objects in packfile, so commit object
> is put immediately after all its prerequisites.
That would require some changes in the object enumeration code which is
an area of the code I don't know well.
> 5. Implement 'salvage' operation, which given partially transferred
> packfile would deepen shallow clone, or advance tracking branches,
> ensuring that repository would pass fsck after this operation.
>
> Probably requires 4; might be not possible or much harder to salvage
> anything with current ordering of objects in packfile.
>
> 6. Implement resumable clone ("git clone --keep <URL> [<directory>]",
> "git clone --resume" / "git clone --continue", "git clone --abort",
> "git clone --make-shallow" / "git clone --salvage").
Right. This is all doable fairly easily.
Nicolas
^ permalink raw reply
* Re: [PATCH 01/14] Fix non-constant array creation
From: Junio C Hamano @ 2009-08-21 21:04 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <40aa078e0908210641m660b003do6f637535293672ae@mail.gmail.com>
Erik Faye-Lund <kusmabite@googlemail.com> writes:
> How about using alloca instead?
I tend to avoid it; historically, alloca has been a worse portability
nightmare.
^ permalink raw reply
* Re: [PATCH 09/14] Avoid including windows.h in winansi.c for MSVC build
From: Junio C Hamano @ 2009-08-21 21:02 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <74ca14c3a691cc9844a0dd806f5db47977317bdb.1250860247.git.mstormo@gmail.com>
Marius Storm-Olsen <mstormo@gmail.com> writes:
> From: Frank Li <lznuaa@gmail.com>
>
> compat/msvc.h includes winsock2.h which conflicts with windows.h.
> msvc.h also defines the oldest Windows API version required.
The first sentence sort-of makes sense; compat/msvc.h will be included by
git-compat-util.h and including <windows.h> here will bring conflicting
definitions, so we avoid doing so when on MSC.
The second sentence does not make any sense to me. It may be correctly
stating a fact (i.e. "defines required WAPI version"), but it is unclear
what relevance it has to this change to stop including <windows.h>.
Having said that, the first sentence hints me that perhaps you guys should
include (conditionally only on windows but not with MSC) <windows.h> not
from this file, but from git-compat-util.h?
> Signed-off-by: Frank Li <lznuaa@gmail.com>
> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
> ---
> compat/winansi.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/compat/winansi.c b/compat/winansi.c
> index 9217c24..0d79845 100644
> --- a/compat/winansi.c
> +++ b/compat/winansi.c
> @@ -2,7 +2,9 @@
> * Copyright 2008 Peter Harris <git@peter.is-a-geek.org>
> */
>
> +#ifndef _MSC_VER
> #include <windows.h>
> +#endif
> #include "../git-compat-util.h"
>
> /*
> --
> 1.6.3.msysgit.0.18.gef407
^ permalink raw reply
* Re: [PATCH 03/14] Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
From: Junio C Hamano @ 2009-08-21 20:55 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <c899c41fdccfdc94ae294f1a50895ba0290a1ec3.1250860247.git.mstormo@gmail.com>
Marius Storm-Olsen <mstormo@gmail.com> writes:
> From: Frank Li <lznuaa@gmail.com>
>
> The Microsoft C runtime's vsnprintf function does not add NUL at
> the end of the buffer.
This contradicts the way I read the comment in compat/snprintf.c from
f4626df (Add target architecture MinGW., 2007-12-01).
As far as I can see, the correction is about the meaning of the size
parameter to the function, namely, that a broken implementation may
mistakenly think that it was told the maximum length of the meat of the
string to write, and it is allowed to append a NUL beyond the limit, when
the caller actually is telling it the size of the buffer.
So if my reading is correct, it is not about "does not add NUL at the end"
at all; it is "adds NUL beyond the end of given output buffer."
^ permalink raw reply
* Re: [PATCH 01/14] Fix non-constant array creation
From: Junio C Hamano @ 2009-08-21 20:39 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <6283b3e1775f43c6fc07e5047f9c99acdc27bc8f.1250860247.git.mstormo@gmail.com>
Marius Storm-Olsen <mstormo@gmail.com> writes:
> MSVC doesn't munge the non-constant expression, so use xmalloc instead.
Thanks.
These things are called variable length array, and MSVC is not the only
one that do not glok vla.
Subject: Avoid use of variable length array
Some compilers unfortunately do not understand these constructs.
In codepaths that are not performance critical, use xmalloc()
and free() instead.
There is another use of vla; I would suggest squashing the following patch
in.
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index c433748..5065abd 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1599,7 +1599,7 @@ static void *threaded_find_deltas(void *arg)
static void ll_find_deltas(struct object_entry **list, unsigned list_size,
int window, int depth, unsigned *processed)
{
- struct thread_params p[delta_search_threads];
+ struct thread_params *p;
int i, ret, active_threads = 0;
if (delta_search_threads <= 1) {
@@ -1610,6 +1610,8 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
fprintf(stderr, "Delta compression using up to %d threads.\n",
delta_search_threads);
+ p = xcalloc(delta_search_threads, sizeof(*p));
+
/* Partition the work amongst work threads. */
for (i = 0; i < delta_search_threads; i++) {
unsigned sub_size = list_size / (delta_search_threads - i);
@@ -1717,6 +1719,8 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
active_threads--;
}
}
+
+ free(p);
}
#else
^ permalink raw reply related
* hitting home directory's parent
From: Daniel Convissor @ 2009-08-21 20:05 UTC (permalink / raw)
To: Git Mailing List
Hi:
I just installed git in my Cygwin installation for the first time. The
git version is 1.6.1.2, which is the latest version they have. When I
enter one of the following commands:
git --help
git config --global user.name "Daniel Convissor"
I get this error:
fatal: Cannot change to /home/danielc/..: Permission denied
Though "git --version" executes fine.
I've been using Cygwin for many years and no other program has ever
produced this issue for me. For example, svn --help, ls --help, etc work
just fine.
Why is git venturing into to the home directory's parent directory? Is
this a bug? If not, is this really necessary?
Thanks,
--Dan
PS: I'm not subscribed to the list.
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
^ permalink raw reply
* Re: git-daemon via launchd
From: Alex Riesen @ 2009-08-21 20:24 UTC (permalink / raw)
To: Andrew Keller; +Cc: Git List
In-Reply-To: <D49DB51B-4D25-44CC-B09C-2598EC7FCEE9@kellerfarm.com>
On Fri, Aug 21, 2009 at 19:40, Andrew Keller<andrew@kellerfarm.com> wrote:
> Is it possible to configure launchd to run git-daemon based on an incoming
> connection, rather than having git-daemon listen for connections?
Yes, see inetd and xinetd examples in Documentation/everyday.txt
^ permalink raw reply
* Re: [PATCH] Add tests for rev-list --graph with options that simplify history
From: Junio C Hamano @ 2009-08-21 20:15 UTC (permalink / raw)
To: Adam Simpkins; +Cc: Git Mailing List
In-Reply-To: <20090821182034.GW8147@facebook.com>
Adam Simpkins <simpkins@facebook.com> writes:
> These tests help make sure graph_is_interesting() is doing the right
> thing.
>
> Signed-off-by: Adam Simpkins <simpkins@facebook.com>
> ---
> t/t6016-rev-list-graph-simplify-history.sh | 276 ++++++++++++++++++++++++++++
> 1 files changed, 276 insertions(+), 0 deletions(-)
> create mode 100755 t/t6016-rev-list-graph-simplify-history.sh
>
> diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh
> new file mode 100755
> index 0000000..5ac8fc9
> --- /dev/null
> +++ b/t/t6016-rev-list-graph-simplify-history.sh
> @@ -0,0 +1,276 @@
> +#!/bin/sh
> +
> +# There's more than one "correct" way to represent the history graphically.
> +# These tests depend on the current behavior of the graphing code. If the
> +# graphing code is ever changed to draw the output differently, these tests
> +# cases will need to be updated to know about the new layout.
An ideal solution to such a problem would be not to write the tests that
way to require _the exact layout_ of the output.
What was the bug you were trying to fix? Was it that in a simplified
history some arcs are not connected whey they should be?
Can you test that without relying on other aspect (say, commits are marked
with '*' right now but a patch might change it to '^' for some commits) of
the output?
I am just wondering how feasible it is the problem you are trying to
solve, not demanding you to solve it.
^ permalink raw reply
* [PATCH v2 05/14] Change regerror() definition from K&R style to ANSI C (C89)
From: Marius Storm-Olsen @ 2009-08-21 20:10 UTC (permalink / raw)
To: lznuaa; +Cc: msysgit, git, Marius Storm-Olsen
In-Reply-To: <07846e22f50dfd5e1b483a02cf550e5373125f1d.1250860247.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
The MSVC headers typedef errcode as int, and thus confused the
compiler in the K&R style definition. ANSI style deconfuses it.
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
Frank, like this one better?
compat/regex/regex.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/compat/regex/regex.c b/compat/regex/regex.c
index 5ea0075..67d5c37 100644
--- a/compat/regex/regex.c
+++ b/compat/regex/regex.c
@@ -4852,11 +4852,8 @@ regexec (preg, string, nmatch, pmatch, eflags)
from either regcomp or regexec. We don't use PREG here. */
size_t
-regerror (errcode, preg, errbuf, errbuf_size)
- int errcode;
- const regex_t *preg;
- char *errbuf;
- size_t errbuf_size;
+regerror(int errcode, const regex_t *preg,
+ char *errbuf, size_t errbuf_size)
{
const char *msg;
size_t msg_size;
--
1.6.3.msysgit.0.18.gef407
^ permalink raw reply related
* Re: What's cooking in git.git (Aug 2009, #03; Thu, 20)
From: Junio C Hamano @ 2009-08-21 20:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Mark A Rada, git
In-Reply-To: <200908212006.16333.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>> +cat >>gitweb_config.perl <<EOF
>> +
>> +\$feature{'snapshot'}{'override'} = 0;
>> +EOF
>
> A trick: use '\EOF' and you don't need to escape $ against variable
> expansion by shell.
>
> +cat >>gitweb_config.perl <<\EOF
> +
> +$feature{'snapshot'}{'override'} = 0;
> +EOF
It is not a "trick" but is a basic courtesy for reviewers. Even if you do
not have any $ to worry about, _unless_ you actively know you would want
variable substitution to happen, it is easier for readers if you signal
the fact that the here-doc is verbatim by quoting the \EOF marker upfront.
Same thing for use of single quotes vs double quotes when writing strings,
even though they tend to be small and much less of an issue.
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 01/14] Fix non-constant array creation
From: Johan 't Hart @ 2009-08-21 20:06 UTC (permalink / raw)
To: Janos Laube
Cc: Marius Storm-Olsen, Erik Faye-Lund, Johannes.Schindelin, msysgit,
git, lznuaa
In-Reply-To: <9d6091530908210926p61aa5ea6ya6a7b71f940fdf5a@mail.gmail.com>
Janos Laube schreef:
>> MSVC compiles regex.c, so it must handle it. I'm fine with that.
>
> msvc supports alloca, but regex.c doesn't make use of it per default
> (you must define HAVE_ALLOCA_H in order to use it). basically _alloca
> is fine for that task, but be aware that error handling on windows is
> a bit compilicated. when _alloca fails it throws a structured
> exception, you must reset the stack and use traditional memory
> allocation as fallback. see
> http://msdn.microsoft.com/en-us/library/wb1s57t5.aspx. :-)
>
alloca() throws an exception when out of stack memory. But what would
the dynamically alloced array do when it runs out of memory? (Supposing
that those arrays are also created on the stack, which I don't know...)
Is that realy more complicated?
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 01/14] Fix non-constant array creation
From: Marius Storm-Olsen @ 2009-08-21 19:49 UTC (permalink / raw)
To: Janos Laube; +Cc: Erik Faye-Lund, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <9d6091530908210926p61aa5ea6ya6a7b71f940fdf5a@mail.gmail.com>
Janos Laube said the following on 21.08.2009 18:26:
>> MSVC compiles regex.c, so it must handle it. I'm fine with that.
>
> msvc supports alloca, but regex.c doesn't make use of it per default
> (you must define HAVE_ALLOCA_H in order to use it). basically _alloca
> is fine for that task, but be aware that error handling on windows
> is a bit compilicated. when _alloca fails it throws a structured
> exception, you must reset the stack and use traditional memory
> allocation as fallback. see
> http://msdn.microsoft.com/en-us/library/wb1s57t5.aspx. :-)
I must admit that I didn't look much at the surrounding code to know how
large preimage->nr can get. But assuming variable-length array is
handled the same way by the compiler as alloca(), and this code seems to
be performing fine, I guess it's safe to say that this code won't be
triggering any SEH, and thus we won't need to handle it?
So, given my assumptions I think we can just replace that one line with
alloca(), nuke the free(), and everything is ok.
--
.marius
^ permalink raw reply
* git-daemon via launchd
From: Andrew Keller @ 2009-08-21 17:40 UTC (permalink / raw)
To: Git List
Is it possible to configure launchd to run git-daemon based on an
incoming connection, rather than having git-daemon listen for
connections?
Thanks,
Andrew Keller
^ permalink raw reply
* Re: [msysGit] [PATCH 07/14] Fix __stdcall/WINAPI placement and function prototype
From: Marius Storm-Olsen @ 2009-08-21 19:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, Johannes.Schindelin, git, lznuaa
In-Reply-To: <200908211937.18296.j6t@kdbg.org>
Johannes Sixt said the following on 21.08.2009 19:37:
> On Freitag, 21. August 2009, Marius Storm-Olsen wrote:
>> -static __stdcall unsigned ticktack(void *dummy)
>> +static unsigned WINAPI ticktack(void *dummy)
>
>> -static __stdcall unsigned run_thread(void *data)
>> +static unsigned WINAPI run_thread(void *data)
>
> These two are not nice. As I said in an earlier mail: The
> documentation says that the thread function pointer that is passed to
> _beginthreadex must have __stdcall calling convention. Therefore, you
> should not change these to WINAPI.
WINAPI is just a define for __stdcall (since _MSC_VER >= 800 anyways; VC
6.0 being _MSC_VER == 1200), and won't change.
So, IMO the change is not bad, and makes things less convoluted by using
the same convention all over.
(And _beginthreadex actually accepts both __stdcall and __clrcall
calling conventions.)
--
.marius
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #03; Thu, 20)
From: Junio C Hamano @ 2009-08-21 19:36 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git
In-Reply-To: <4A8E6485.7040006@gnu.org>
Paolo Bonzini <bonzini@gnu.org> writes:
> On 08/21/2009 04:48 AM, Junio C Hamano wrote:
>> Has been ejected from 'pu' for some time, expecting a reroll.
>
> I've been trying for a while to have push refspecs and tracking
> working together, but haven't come with anything that I like.
>
> I'll let it sleep for a while so that I can look at the problem again
> with a fresh mind when I come back to it.
Thanks.
^ permalink raw reply
* [PATCH] Add tests for rev-list --graph with options that simplify history
From: Adam Simpkins @ 2009-08-21 18:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v7hwzt94p.fsf@alter.siamese.dyndns.org>
These tests help make sure graph_is_interesting() is doing the right
thing.
---
t/t6016-rev-list-graph-simplify-history.sh | 276 ++++++++++++++++++++++++++++
1 files changed, 276 insertions(+), 0 deletions(-)
create mode 100755 t/t6016-rev-list-graph-simplify-history.sh
diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh
new file mode 100755
index 0000000..5ac8fc9
--- /dev/null
+++ b/t/t6016-rev-list-graph-simplify-history.sh
@@ -0,0 +1,276 @@
+#!/bin/sh
+
+# There's more than one "correct" way to represent the history graphically.
+# These tests depend on the current behavior of the graphing code. If the
+# graphing code is ever changed to draw the output differently, these tests
+# cases will need to be updated to know about the new layout.
+
+test_description='--graph and simplified history'
+
+. ./test-lib.sh
+
+test_expect_success 'set up rev-list --graph test' '
+ # 3 commits on branch A
+ test_commit A1 foo.txt &&
+ test_commit A2 bar.txt &&
+ test_commit A3 bar.txt &&
+ git branch -m master A &&
+
+ # 2 commits on branch B, started from A1
+ git checkout -b B A1 &&
+ test_commit B1 foo.txt &&
+ test_commit B2 abc.txt &&
+
+ # 2 commits on branch C, started from A2
+ git checkout -b C A2 &&
+ test_commit C1 xyz.txt &&
+ test_commit C2 xyz.txt &&
+
+ # Octopus merge B and C into branch A
+ git checkout A &&
+ git merge B C &&
+ git tag A4
+
+ test_commit A5 bar.txt &&
+
+ # More commits on C, then merge C into A
+ git checkout C &&
+ test_commit C3 foo.txt &&
+ test_commit C4 bar.txt &&
+ git checkout A &&
+ git merge -s ours C &&
+ git tag A6
+
+ test_commit A7 bar.txt &&
+
+ # Store commit names in variables for later use
+ A1=`git rev-list -1 A1` &&
+ A2=`git rev-list -1 A2` &&
+ A3=`git rev-list -1 A3` &&
+ A4=`git rev-list -1 A4` &&
+ A5=`git rev-list -1 A5` &&
+ A6=`git rev-list -1 A6` &&
+ A7=`git rev-list -1 A7` &&
+ B1=`git rev-list -1 B1` &&
+ B2=`git rev-list -1 B2` &&
+ C1=`git rev-list -1 C1` &&
+ C2=`git rev-list -1 C2` &&
+ C3=`git rev-list -1 C3` &&
+ C4=`git rev-list -1 C4`
+ '
+
+test_expect_success '--graph --all' '
+ rm -f expected &&
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "| * $C3" >> expected &&
+ echo "* | $A5" >> expected &&
+ echo "| | " >> expected &&
+ echo "| \\ " >> expected &&
+ echo "*-. \\ $A4" >> expected &&
+ echo "|\\ \\ \\ " >> expected &&
+ echo "| | |/ " >> expected &&
+ echo "| | * $C2" >> expected &&
+ echo "| | * $C1" >> expected &&
+ echo "| * | $B2" >> expected &&
+ echo "| * | $B1" >> expected &&
+ echo "* | | $A3" >> expected &&
+ echo "| |/ " >> expected &&
+ echo "|/| " >> expected &&
+ echo "* | $A2" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A1" >> expected &&
+ git rev-list --graph --all > actual &&
+ test_cmp expected actual
+ '
+
+# Make sure the graph_is_interesting() code still realizes
+# that undecorated merges are interesting, even with --simplify-by-decoration
+test_expect_success '--graph --simplify-by-decoration' '
+ rm -f expected &&
+ git tag -d A4
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "| * $C3" >> expected &&
+ echo "* | $A5" >> expected &&
+ echo "| | " >> expected &&
+ echo "| \\ " >> expected &&
+ echo "*-. \\ $A4" >> expected &&
+ echo "|\\ \\ \\ " >> expected &&
+ echo "| | |/ " >> expected &&
+ echo "| | * $C2" >> expected &&
+ echo "| | * $C1" >> expected &&
+ echo "| * | $B2" >> expected &&
+ echo "| * | $B1" >> expected &&
+ echo "* | | $A3" >> expected &&
+ echo "| |/ " >> expected &&
+ echo "|/| " >> expected &&
+ echo "* | $A2" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A1" >> expected &&
+ git rev-list --graph --all --simplify-by-decoration > actual &&
+ test_cmp expected actual
+ '
+
+# Get rid of all decorations on branch B, and graph with it simplified away
+test_expect_success '--graph --simplify-by-decoration prune branch B' '
+ rm -f expected &&
+ git tag -d B2
+ git tag -d B1
+ git branch -d B
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "| * $C3" >> expected &&
+ echo "* | $A5" >> expected &&
+ echo "* | $A4" >> expected &&
+ echo "|\\ \\ " >> expected &&
+ echo "| |/ " >> expected &&
+ echo "| * $C2" >> expected &&
+ echo "| * $C1" >> expected &&
+ echo "* | $A3" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A2" >> expected &&
+ echo "* $A1" >> expected &&
+ git rev-list --graph --simplify-by-decoration --all > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--graph --full-history -- bar.txt' '
+ rm -f expected &&
+ git tag -d B2
+ git tag -d B1
+ git branch -d B
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "* | $A5" >> expected &&
+ echo "* | $A4" >> expected &&
+ echo "|\\ \\ " >> expected &&
+ echo "| |/ " >> expected &&
+ echo "* | $A3" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A2" >> expected &&
+ git rev-list --graph --full-history --all -- bar.txt > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--graph --full-history --simplify-merges -- bar.txt' '
+ rm -f expected &&
+ git tag -d B2
+ git tag -d B1
+ git branch -d B
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "* | $A5" >> expected &&
+ echo "* | $A3" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A2" >> expected &&
+ git rev-list --graph --full-history --simplify-merges --all \
+ -- bar.txt > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--graph -- bar.txt' '
+ rm -f expected &&
+ git tag -d B2
+ git tag -d B1
+ git branch -d B
+ echo "* $A7" >> expected &&
+ echo "* $A5" >> expected &&
+ echo "* $A3" >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A2" >> expected &&
+ git rev-list --graph --all -- bar.txt > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--graph --sparse -- bar.txt' '
+ rm -f expected &&
+ git tag -d B2
+ git tag -d B1
+ git branch -d B
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "* $A5" >> expected &&
+ echo "* $A4" >> expected &&
+ echo "* $A3" >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "| * $C3" >> expected &&
+ echo "| * $C2" >> expected &&
+ echo "| * $C1" >> expected &&
+ echo "|/ " >> expected &&
+ echo "* $A2" >> expected &&
+ echo "* $A1" >> expected &&
+ git rev-list --graph --sparse --all -- bar.txt > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--graph ^C4' '
+ rm -f expected &&
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "* $A5" >> expected &&
+ echo "* $A4" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $B2" >> expected &&
+ echo "| * $B1" >> expected &&
+ echo "* $A3" >> expected &&
+ git rev-list --graph --all ^C4 > actual &&
+ test_cmp expected actual
+ '
+
+test_expect_success '--graph ^C3' '
+ rm -f expected &&
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "* $A5" >> expected &&
+ echo "* $A4" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $B2" >> expected &&
+ echo "| * $B1" >> expected &&
+ echo "* $A3" >> expected &&
+ git rev-list --graph --all ^C3 > actual &&
+ test_cmp expected actual
+ '
+
+# I don't think the ordering of the boundary commits is really
+# that important, but this test depends on it. If the ordering ever changes
+# in the code, we'll need to update this test.
+test_expect_success '--graph --boundary ^C3' '
+ rm -f expected &&
+ echo "* $A7" >> expected &&
+ echo "* $A6" >> expected &&
+ echo "|\\ " >> expected &&
+ echo "| * $C4" >> expected &&
+ echo "* | $A5" >> expected &&
+ echo "| | " >> expected &&
+ echo "| \\ " >> expected &&
+ echo "*-. \\ $A4" >> expected &&
+ echo "|\\ \\ \\ " >> expected &&
+ echo "| * | | $B2" >> expected &&
+ echo "| * | | $B1" >> expected &&
+ echo "* | | | $A3" >> expected &&
+ echo "o | | | $A2" >> expected &&
+ echo "|/ / / " >> expected &&
+ echo "o | | $A1" >> expected &&
+ echo " / / " >> expected &&
+ echo "| o $C3" >> expected &&
+ echo "|/ " >> expected &&
+ echo "o $C2" >> expected &&
+ git rev-list --graph --boundary --all ^C3 > actual &&
+ test_cmp expected actual
+ '
+
+test_done
--
1.6.0.4
^ 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