Previously the exit status of git submodule was zero for various
subcommands even though the user specified an unknown path.
The reason behind that was that they all pipe the output of module_list
into the while loop which then does the action on the paths specified by
the commandline. Since the e
Martin von Zweigbergk writes:
> On Fri, Aug 10, 2012 at 2:38 PM, Junio C Hamano wrote:
>> Martin von Zweigbergk writes:
>>
>>> There is also cherry-pick/revert, which I _think_ does not really want
>>> the revisions sorted.
>>
>> Yes, I think sequencer.c::prepare_revs() is wrong to unconditoina
On Fri, Aug 10, 2012 at 2:38 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> There is also cherry-pick/revert, which I _think_ does not really want
>> the revisions sorted.
>
> Yes, I think sequencer.c::prepare_revs() is wrong to unconditoinally
> call prepare_revision_walk().
>
>
Am 11.08.2012 00:47 schrieb Junio C Hamano:
> Do you know in what encoding the pathnames are _expected_ to be
> stored in zip archives?
re-encoding to latin1 does not always work and may break double byte
totally (e.g. chinese or japanese).
PKZIP APPNOTE seems to be the zip standard and it specif
Sven Strickroth writes:
> when I create a git repository, add a file containing utf-8 characters
> or umlauts (like öäü.txt), commit and then export the HEAD revision to a
> zip archive using "git archive --format zip -o 1.zip HEAD", the zip file
> contains incorrect filenames:
My reading of arc
Shawn Pearce writes:
> On Fri, Aug 10, 2012 at 2:50 PM, Jeff King wrote:
>> On Fri, Aug 10, 2012 at 11:52:28AM -0700, Junio C Hamano wrote:
>>
>>> When evaluating a change in the interoperability area, it does not
>>> add much more confidence to the correctness that the change has been
>>> in us
On Fri, Aug 10, 2012 at 2:50 PM, Jeff King wrote:
> On Fri, Aug 10, 2012 at 11:52:28AM -0700, Junio C Hamano wrote:
>
>> When evaluating a change in the interoperability area, it does not
>> add much more confidence to the correctness that the change has been
>> in use for months with the same par
Hi,
when I create a git repository, add a file containing utf-8 characters
or umlauts (like öäü.txt), commit and then export the HEAD revision to a
zip archive using "git archive --format zip -o 1.zip HEAD", the zip file
contains incorrect filenames:
$ unzip -l 1.zip
Archive: 1.zip
4490a6dab1df5
Jeff King writes:
> I would think the extra memory allocation would dwarf it, anyway.
>> ...
>> and a new caller can do something like
>>
>> agent = server_supports("agent");
>> if (!agent || !agent[5])
>> ... no agent ...
>> else {
>> int span = strcs
On Fri, Aug 10, 2012 at 11:52:28AM -0700, Junio C Hamano wrote:
> When evaluating a change in the interoperability area, it does not
> add much more confidence to the correctness that the change has been
> in use for months with the same partner than that it has been used
> to talk to many differe
Torsten Bögershausen writes:
> After cloning, I set "git config core.precomposeunicode true".
>
> git is v1.7.12.rc2,
> git_git/git is with your patch.
>
> git v1.7.12.rc2:
> tb@birne:~/projects/git/linux-2.6> for f in 1 2 3 4 5; do time git status ;
> done 2>&1 | egrep "^user|^real|^sys"
> re
Jeff King writes:
> Yes, I think that is all that is necessary to fix the immediate issue.
> The protocol-capabilities document talks about what to do when
> include-tag is not available ("SHOULD issue a subsequent fetch to
> acquire the tags that include-tag would have otherwise given the
> clie
Martin von Zweigbergk writes:
> There is also cherry-pick/revert, which I _think_ does not really want
> the revisions sorted.
Yes, I think sequencer.c::prepare_revs() is wrong to unconditoinally
call prepare_revision_walk().
It instead should first check the revs->pending.objects list to see
i
On Fri, Aug 10, 2012 at 02:25:51PM -0700, Junio C Hamano wrote:
> > I don't think there's any bug here. They are all of a class of features
> > where the client can handle the case where the server simply ignores the
> > request. However it is certainly food for thought if we are considering
> > t
Junio C Hamano wrote:
> Eric Wong writes:
> > Peter Baumann (1):
> > git svn: reset invalidates the memoized mergeinfo caches
> >
> > Robert Luberda (1):
> > git svn: handle errors and concurrent commits in dcommit
>
> OK, so these two are fit for 1.7.12-rc3 and later?
Yes.
--
To un
Eric Wong writes:
> Peter Baumann wrote:
>> First, let me thank you for your review and your detailed explanation.
>> I really appreciate it.
>
> You're welcome, Peter. Thanks again for the patch. I've signed-off and
> pushed for Junio.
>
> The following changes since commit 034161a94e827ef057
Jeff King writes:
> On Fri, Aug 10, 2012 at 11:13:30AM -0700, Dave Borowitz wrote:
>
>> > Thanks for the data point. I knew you guys ran some custom code, so I
>> > wasn't sure how widespread this is. The fact that other dulwich-based
>> > servers would see the same issue makes me doubly sure tha
On Fri, Aug 10, 2012 at 01:01:11PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > +/*
> > + * Parse features of the form "feature=value". Returns NULL if the feature
> > + * does not exist, the empty string if it exists but does not have an "=",
> > or
> > + * the content to the right
On 10.08.12 20:18, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> On 31.07.12 20:37, Junio C Hamano wrote:
>>> In practice, the majority of paths do not have utf8 that needs
>>> the canonicalization. Lazily call iconv_open()/iconv_close() to
>>> avoid unnecessary overhead.
>>>
>>> Signe
On Fri, Aug 10, 2012 at 12:45:19PM -0700, Junio C Hamano wrote:
> > diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
> > index fe56596..bc7a0f9 100644
> > --- a/builtin/fetch-pack.c
> > +++ b/builtin/fetch-pack.c
> > @@ -19,6 +19,7 @@ static int prefer_ofs_delta = 1;
> > static int no_don
A while ago when I was looking at revision.c, I was surprised to see
that commits are sorted even when --no-walk is passed, but as 8e64006
(Teach revision machinery about --no-walk, 2007-07-24) points out,
this can be useful for doing
$ git log --abbrev-commit --pretty=oneline --decorate --all --
Peter Baumann wrote:
> First, let me thank you for your review and your detailed explanation.
> I really appreciate it.
You're welcome, Peter. Thanks again for the patch. I've signed-off and
pushed for Junio.
The following changes since commit 034161a94e827ef05790b1c7ce5a6e3e740c864e:
Merge
Phil Hord writes:
> I agree that 'git reset --hard' should be mentioned in the hint for
> newbies, but this conflicts with my desire to avoid giving chainsaws
> to toddlers.
Exactly. So what are you suggesting?
Perhaps force the user to go through a series of quiz when "git
merge" was run by t
Felix Natter writes:
> I have a few questions about this:
>
>> As I am coming from "large depth is harmful" school, I would
>> recommend
>>
>> - "git repack -a -d -f" with large "--window" with reasonably short
>>"--depth" once,
>
> So something like --depth=250 and --window=500?
I would
> From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
> Sent: Friday, August 10, 2012 7:33 PM
> To: 'Shawn Pearce'
> Cc: 'git@vger.kernel.org'; 'rsbec...@nexbridge.com'
> Subject: RE: Porting git to HP NonStop
>
> > From: Shawn Pearce [mailto:spea...@spearce.org]
> > Sent: Friday, August 10, 20
Jeff King writes:
> +/*
> + * Parse features of the form "feature=value". Returns NULL if the feature
> + * does not exist, the empty string if it exists but does not have an "=", or
> + * the content to the right of the "=" until the first space (or end of
> + * string). The cannot contain lit
Junio C Hamano wrote:
> I should have asked this yesterday, but do you mean you want to have
> your "maint" in the upcoming 1.7.12? This does look like a useful
> thing to do, but does not seem like a regression fix to me.
Yeah, I wasn't sure what to name it since my master is still carrying
Mic
Jeff King writes:
> Instead, each client must record whether we saw an agent
> string from the server, and respond with its agent only if
> the server mentioned it first.
Just a couple of minor comments.
> diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
> index fe56596..bc7a0f9 100644
On Tue, Aug 7, 2012 at 9:43 PM, Junio C Hamano wrote:
> Rich Pixley writes:
>
>> I'm confused.
>>
>> What is the intended work flow here? Ie, aside from trashing my
>> repository and starting over, what does one do to recover?
>>
>> rich@cobra> git clone /home/rich/repos/webos webos
>> Cloning i
Using git p4 on git version 1.7.12.rc2 has path issues. Standard
clone/sync ops apparently place detected master and branches on
independent and parallel directory structures instead of git branches.
See http://stackoverflow.com/q/11893688/1588831 for a full demo of the problem.
Thanks,
-Matt Koric
Junio C Hamano writes:
> Jeff King writes:
>
>> So the packing parameters are the same these days for either method.
>> Note that "git gc --aggressive" will also use "-f" to recompute all
>> deltas. This is more expensive, but gives git more flexibility if the
>> old deltas were sub-optimal (typ
Dave Borowitz writes:
> You may also notice in that code a set of innocuous_capabilities,
> which IIRC is the complete set of capabilities, at the time of
> writing, that the C git client may send without the server advertising
> them. Such a set (painstakingly assembled, I assure you :) may be
>
Jeff King writes:
> Thanks for confirming the push side. I have been running with the patch
> for months, but only recently happened to try cloning something from
> code.google.com.
Note that I didn't "confirm" the fix. I only confirmed the
existence of the breakage (not that I have any reason
Thanks Drew, I will look into this.
Neeraj Mathawan
610-213-0673
On Aug 10, 2012, at 1:57 PM, Drew Northup wrote:
> On Fri, Aug 10, 2012 at 11:17 AM, Neeraj Mathawan wrote:
>> Hi,
>> We have decided to use GIT for a huge government implementation, I am
>> looking for some help with installati
On Fri, Aug 10, 2012 at 11:13:30AM -0700, Dave Borowitz wrote:
> > Thanks for the data point. I knew you guys ran some custom code, so I
> > wasn't sure how widespread this is. The fact that other dulwich-based
> > servers would see the same issue makes me doubly sure that my fix is the
> > right
Torsten Bögershausen writes:
> On 31.07.12 20:37, Junio C Hamano wrote:
>> In practice, the majority of paths do not have utf8 that needs
>> the canonicalization. Lazily call iconv_open()/iconv_close() to
>> avoid unnecessary overhead.
>>
>> Signed-off-by: Junio C Hamano
>> Helped-by: Ralf Thiel
On Fri, Aug 10, 2012 at 11:08 AM, Jeff King wrote:
> On Fri, Aug 10, 2012 at 11:06:08AM -0700, Dave Borowitz wrote:
>
>> > I asked the folks who run code.google.com and they are indeed seeing
>> > something like these in their logs:
>> >
>> > >> Client asked for capability agent=git/1.7.12.rc2.79
On Fri, Aug 10, 2012 at 11:06:08AM -0700, Dave Borowitz wrote:
> > I asked the folks who run code.google.com and they are indeed seeing
> > something like these in their logs:
> >
> > >> Client asked for capability agent=git/1.7.12.rc2.79.g86c1702 that was
> > not advertised.
>
> FWIW, this err
On Fri, Aug 10, 2012 at 8:37 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> Ugh, the jk/version-string topic breaks fetching from Google Code. With
>> my patch, the client unconditionally sends an "agent=foo" capability,
>> but the server does not like seeing the unknown capability and ends t
On Fri, Aug 10, 2012 at 11:17 AM, Neeraj Mathawan wrote:
> Hi,
> We have decided to use GIT for a huge government implementation, I am looking
> for some help with installation of GIT SERVER.
>
> Few questions:-
>
> 1. What platform to choose - UNIX, MAC or Windows? We have lot of windows
> 2008
On Fri, Aug 10, 2012 at 08:34:45AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Ugh, the jk/version-string topic breaks fetching from Google Code. With
> > my patch, the client unconditionally sends an "agent=foo" capability,
> > but the server does not like seeing the unknown capabili
On Fri, Aug 10, 2012 at 10:32 AM, Joachim Schmitz
wrote:
>> then use `git init --bare` in a new directory to copy in the templates,
> and see if
>> its the template copying code that is making an incorrect copy.
>
> "git init --bare" gives the same error. It isn't copying any of the
> subdirectori
On Aug 10, 2012, at 11:17 AM, Neeraj Mathawan wrote:
> We have decided to use GIT for a huge government implementation, I am looking
> for some help with installation of GIT SERVER.
>
> Few questions:-
>
> 1. What platform to choose - UNIX, MAC or Windows? We have lot of windows
> 2008 instal
> From: Shawn Pearce [mailto:spea...@spearce.org]
> Sent: Friday, August 10, 2012 6:28 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org; rsbec...@nexbridge.com
> Subject: Re: Porting git to HP NonStop
>
> On Fri, Aug 10, 2012 at 8:04 AM, Joachim Schmitz
> wrote:
> >>
> >> - HP NonStop is lackin
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Friday, August 10, 2012 6:21 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org; rsbec...@nexbridge.com
> Subject: Porting to a new platform
>
> "Joachim Schmitz" writes:
>
> > - HP NonStop is lacking poll(),...
> > - HP NonStop is lackin
On 31.07.12 20:37, Junio C Hamano wrote:
> In practice, the majority of paths do not have utf8 that needs
> the canonicalization. Lazily call iconv_open()/iconv_close() to
> avoid unnecessary overhead.
>
> Signed-off-by: Junio C Hamano
> Helped-by: Ralf Thielow
> Helped-by: Linus Torvalds
> ---
On 08/10/2012 09:15 AM, Junio C Hamano wrote:
> "H. Peter Anvin" writes:
>
>> The users I am referring to generally have a --- line, rather than
>> a scissor, between the cover text and commit. Also, there is
>> (almost) always a From: line and subject at the top of the patch
>> proper.
>
> Oh,
Patrick Renaud writes:
> I am not sure to understand why having two physically disconnected
> events, in time and in place. Personally I'd rather see one event,
> maybe longer than the previous occurrences to accommodate for the user
> and developer centric topics.
I think a separate event at a
On Fri, Aug 10, 2012 at 8:04 AM, Joachim Schmitz
wrote:
>>
>> - HP NonStop is lacking poll(), git is making quite some use of it.
>> My Solution: I 'stole' the implementation from GNUlib, which implements
>> poll() using select().
>> Git should either provide its own poll(), not use it at all or r
"Joachim Schmitz" writes:
> - HP NonStop is lacking poll(),...
> - HP NonStop is lacking getrlimit(), fsync(), setitimer()...
I would check compat/win32 and friends and see what other platforms
that lack this and that do, if I were you.
> so telling configure to search for c99 should help here
"H. Peter Anvin" writes:
> The users I am referring to generally have a --- line, rather than
> a scissor, between the cover text and commit. Also, there is
> (almost) always a From: line and subject at the top of the patch
> proper.
Oh, so it is more like this?
From: author name
Date
On 08/10, Junio C Hamano wrote:
> Thomas Rast writes:
>
> > But I think the idea always was that any write that changes the basic
> > layout of the file (so that you would read something wrong) will need a
> > full rewrite. Otherwise we're too far in DB land.
> >
> > Most updates will be
> > of
Jeff King writes:
> Ugh, the jk/version-string topic breaks fetching from Google Code. With
> my patch, the client unconditionally sends an "agent=foo" capability,
> but the server does not like seeing the unknown capability and ends the
> connection (I'm guessing with some kind of internal excep
Jeff King writes:
> Ugh, the jk/version-string topic breaks fetching from Google Code. With
> my patch, the client unconditionally sends an "agent=foo" capability,
> but the server does not like seeing the unknown capability and ends the
> connection (I'm guessing with some kind of internal excep
Hi,
We have decided to use GIT for a huge government implementation, I am looking
for some help with installation of GIT SERVER.
Few questions:-
1. What platform to choose - UNIX, MAC or Windows? We have lot of windows 2008
installations, and if there are no trade off's we would love to use Wi
Sebastian Schuberth writes:
> On Fri, Aug 10, 2012 at 6:52 AM, David Aguilar wrote:
>
>> Add an entry for --tool-help to the mergetool documentation.
>>
>> Move --tool-help in the difftool documentation so that it is
>> listed immediately after --tool so that it is easier to find.
>>
>> Signed-o
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
> Behalf Of Joachim Schmitz
> Sent: Friday, August 10, 2012 5:01 PM
> To: git@vger.kernel.org
> Cc: rsbec...@nexbridge.com
> Subject: RE: [PATCH v2] add tests for 'git rebase --keep-empty'
>
> Hi folks
>
> I'm a brand new sub
Hi folks
I'm a brand new subscriper of this mailing list, so please forgive if I
violate some protocol or talk about things that had been discussed to death
earlier.
I'm currently in the process of porting git (1.7.11.4 for now) to the HP
NonStop platform and found several issues:
- HP NonStop i
Thomas Rast writes:
> But I think the idea always was that any write that changes the basic
> layout of the file (so that you would read something wrong) will need a
> full rewrite. Otherwise we're too far in DB land.
>
> Most updates will be
> of the "update the stat and/or sha1 of a file" kind
The users I am referring to generally have a --- line, rather than a scissor,
between the cover text and commit. Also, there is (almost) always a From: line
and subject at the top of the patch proper.
Junio C Hamano wrote:
>Jeff King writes:
>
>> If I understand your issue, somebody is writi
Jeff King writes:
> If I understand your issue, somebody is writing:
>
>
> From: them
> To: you
> Date: ...
> Subject: [PATCH] subject line
>
> commit message body
>
>
> some cover letter material that should go below the "---"
> ---
> [diffstat + diff]
Hi,
I am not sure to understand why having two physically disconnected
events, in time and in place. Personally I'd rather see one event,
maybe longer than the previous occurrences to accommodate for the user
and developer centric topics. Along this line, maybe it would be best
to begin the event
Junio C Hamano writes:
> If you found that an entry you read halfway has an inconsistent crc,
> and if you suspect that is because somebody else was writing to the
> same index, it is a _sure_ sign that you are not alone, and all the
> entries you read so far to the core, even if they weren't tou
On Thu, Aug 09, 2012 at 08:39:51AM -0700, Martin von Zweigbergk wrote:
> Add test cases for 'git rebase --keep-empty' with and without an
> "empty" commit already in upstream. The empty commit that is about to
> be rebased should be kept in both cases.
>
> Signed-off-by: Martin von Zweigbergk
Ack
On 08/10/2012 12:36 PM, Jeff King wrote:
> On Thu, Aug 09, 2012 at 05:13:51PM -0700, H. Peter Anvin wrote:
>
>> I have some contributors who consistently put their commentary
>> *before* the "---" line rather than *after* it, presumably with the
>> notion that it is some kind of "cover text". Thi
On Thu, Aug 09, 2012 at 05:13:51PM -0700, H. Peter Anvin wrote:
> I have some contributors who consistently put their commentary
> *before* the "---" line rather than *after* it, presumably with the
> notion that it is some kind of "cover text". This messes with "git
> am", and so I end up having
On 08/09, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > On 08/09, Junio C Hamano wrote:
> >> Thomas Gummerer writes:
> >>
> >> > Make git read the resolve-undo data from the index.
> >> >
> >> > Since the resolve-undo data is joined with the conflicts in
> >> > the ondisk format of the
Code Compare is a commercial file comparison tool for Windows, see
http://www.devart.com/codecompare/
Version 2.80.4 added support for command line arguments preceded by a
dash instead of a slash. This is required for Git for Windows because
slashes in command line arguments get mangled with
On Fri, Aug 10, 2012 at 3:58 AM, Jeff King wrote:
> + * Parse features of the form "feature=value". Returns NULL if the feature
> + * does not exist, the empty string if it exists but does not have an "=", or
> + * the content to the right of the "=" until the first space (or end of
> + * string)
Fetch-pack's verbose mode is more of a debugging mode (and
in fact takes two "-v" arguments to trigger via the
porcelain layer). Let's mention the server version as
another possible item of interest.
Signed-off-by: Jeff King
---
Like I mentioned before, I'm lukewarm on this one, because I doubt
a
We already take care to parse a capability like "foo=bar"
properly, but the code does not provide a good way of
actually finding out what is on the right-hand side of the
"=".
Signed-off-by: Jeff King
---
cache.h | 2 ++
connect.c | 32
2 files changed, 34 ins
Commit ff5effdf taught both clients and servers of the git
protocol to send an "agent" capability that just advertises
their version for statistics and debugging purposes.
However, the protocol-capabilities.txt document indicates
that the client's advertisement is actually a response, and
should ne
If we have capabilities to send to the server, we send the
regular "want" line followed by a NUL, then the
capabilities; otherwise, we do not even send the NUL.
However, when checking whether we want to send the "quiet"
capability, we check args->quiet, which is wrong. That flag
only tells us whet
On Fri, Aug 03, 2012 at 12:19:16PM -0400, Jeff King wrote:
> Instead of having the client advertise a particular version
> number in the git protocol, we have managed extensions and
> backwards compatibility by having clients and servers
> advertise capabilities that they support. This is far more
Remove the entry for --tool-help in the documentation as it is
already mentioned in the documentation for --tool.
Signed-off-by: David Aguilar
---
Incompatible with the previous patch, but if you prefer to
mention --tool-help in the docs for --tool only, then choose
this one.
Documentation/git-
Add an entry for --tool-help to the mergetool documentation.
Move --tool-help in the difftool documentation so that it is
listed immediately after --tool so that it is easier to find.
Signed-off-by: David Aguilar
---
If you want to have --tool-help mentioned, use this patch.
Documentation/git-
On Fri, Aug 10, 2012 at 6:52 AM, David Aguilar wrote:
> Add an entry for --tool-help to the mergetool documentation.
>
> Move --tool-help in the difftool documentation so that it is
> listed immediately after --tool so that it is easier to find.
>
> Signed-off-by: David Aguilar
Funny, I was doi
77 matches
Mail list logo
