oops, I missed Peter's email, and the following pull request includes
both Peter and Ralf commits.
The following changes since commit f94c3251e1400c3cf349f7f84fea4db66b540113:
Update draft release notes to 1.8.1 (2012-11-29 13:57:09 -0800)
are available in the git repository at:
git://gith
Signed-off-by: Steffen Jaeckel
---
contrib/completion/git-completion.bash | 9 +
1 file changed, 9 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0b77eb1..5b4d2e1 100644
--- a/contrib/completion/git-completion.bash
+++ b/
Like many dev shops, we run a CI server that basically does:
git fetch $some_branch &&
git checkout $some_branch &&
make test
all day long. Sometimes the fetches would get very slow, and the problem
turned out to be a combination of:
1. Never running "git gc". This means you can end up w
We generally try to run "gc --auto" after any commands that
might introduce a large number of new objects. An obvious
place to do so is after running "fetch", which may introduce
new loose objects or packs (depending on the size of the
fetch).
While an active developer repository will probably
eve
When we look up a sha1 object for reading, we first check
packfiles, and then loose objects. If we still haven't found
it, we re-scan the list of packfiles in `objects/pack`. This
final step ensures that we can co-exist with a simultaneous
repack process which creates a new pack and then prunes the
> -Original Message-
> From: Liu Liu
> Sent: Friday, December 07, 2012 2:52 AM
>
> Hi,
>
> I am reaching out because in my personal project (
> https://github.com/liuliu/ccv
> ), I used the block sha1 implementation (
> https://github.com/git/git/blob/master/block-sha1/sha1.c) in git. It
Steffen Jaeckel writes:
> Signed-off-by: Steffen Jaeckel
> ---
> contrib/completion/git-completion.bash | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 0b77eb1..5b4d2e1 100644
> --- a/co
Hi all,
This is with git 1.8.0.1 on all the machines involved.
One of our build machines is having trouble with "git submodule":
$ git submodule init external/openssl
No submodule mapping found in .gitmodules for path ''
(.gitmodules and other aspects of the repo are fine -- the
Marc Branchaud writes:
> This is with git 1.8.0.1 on all the machines involved.
>
> One of our build machines is having trouble with "git submodule":
> ...
> Any ideas?
How and why is the IFS set differently only on one of your build
machines?
--
To unsubscribe from this list: send the line "uns
The linked page has not been showing the promised "more complete
list" for more than 6 months by now, and nobody has resurrected
the list there nor elsewhere since then.
Signed-off-by: Junio C Hamano
---
* If somebody has a working replacement URL, we could use that
instead, of course. Taker
Junio C Hamano writes:
> The linked page has not been showing the promised "more complete
> list" for more than 6 months by now, and nobody has resurrected
> the list there nor elsewhere since then.
>
> Signed-off-by: Junio C Hamano
> ---
> * If somebody has a working replacement URL, we could
On 12-12-07 12:54 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> This is with git 1.8.0.1 on all the machines involved.
>>
>> One of our build machines is having trouble with "git submodule":
>> ...
>> Any ideas?
>
> How and why is the IFS set differently only on one of your build
> mac
Max Horn writes:
> Various remote helper capabilities and commands were not
> documented, in particular 'export', or documented in a misleading
> way (e.g. 'for-push' was listed as a ref attribute understood by
> git, which is not the case). This patch series changes that, and
> also address some
Marc Branchaud writes:
> On 12-12-07 12:54 PM, Junio C Hamano wrote:
>> Marc Branchaud writes:
>>
>>> This is with git 1.8.0.1 on all the machines involved.
>>>
>>> One of our build machines is having trouble with "git submodule":
>>> ...
>>> Any ideas?
>>
>> How and why is the IFS set differe
On 12-12-07 02:11 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> On 12-12-07 12:54 PM, Junio C Hamano wrote:
>>> Marc Branchaud writes:
>>>
This is with git 1.8.0.1 on all the machines involved.
One of our build machines is having trouble with "git submodule":
...
>>
Marc Branchaud writes:
> sh-setup: protect from exported IFS
>
> Many scripted Porcelains rely on being able to split words at the
> default $IFS characters, i.e. SP, HT and LF. If the user exports a
> non-default IFS to the environment, what they read from plumbing
> command
On Fri, Dec 7, 2012 at 11:09 AM, Junio C Hamano wrote:
> A second ping to people who have touched transport-helper.c,
> remote-testsvn.c, git-remote-testgit, and contrib/remote-helpers/ in
> the past 18 months for comments. I've re-read the documentation
> updates myself and didn't find anything
On 12-12-07 03:23 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> sh-setup: protect from exported IFS
>>
>> Many scripted Porcelains rely on being able to split words at the
>> default $IFS characters, i.e. SP, HT and LF. If the user exports a
>> non-default IFS to the en
On 12-12-07 03:23 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> sh-setup: protect from exported IFS
>>
>> Many scripted Porcelains rely on being able to split words at the
>> default $IFS characters, i.e. SP, HT and LF. If the user exports a
>> non-default IFS to the en
Marc Branchaud writes:
> It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to
> upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash.
Finally. Yes, as you suspected, I am perfectly fine to explicitly
set IFS to the default values.
I wanted to have spec
On Fri, Dec 7, 2012 at 9:59 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> The linked page has not been showing the promised "more complete
>> list" for more than 6 months by now, and nobody has resurrected
>> the list there nor elsewhere since then.
>>
>> Signed-off-by: Junio C Hamano
On 07.12.2012, at 20:09, Junio C Hamano wrote:
> Max Horn writes:
>
>> Various remote helper capabilities and commands were not
>> documented, in particular 'export', or documented in a misleading
>> way (e.g. 'for-push' was listed as a ref attribute understood by
>> git, which is not the case)
Max Horn writes:
> On 07.12.2012, at 20:09, Junio C Hamano wrote:
>
>> Except for a minor nit in 6/6; I think "defined options" should be
>> "defined attributes".
>>
>>--- a/Documentation/git-remote-helpers.txt
>>+++ b/Documentation/git-remote-helpers.txt
>>@@ -227,6 +227,8 @@ Suppor
From: Marc Branchaud
Some sh implementations interpret "unset IFS" to mean IFS=''. This was
seen in FreeBSD 7.2's sh.
We need to make sure IFS has its default value: .
Signed-off-by: Marc Branchaud
---
git-sh-setup.sh | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a
With an unset IFS, field splitting is supposed to act as if IFS is
set to the usual SP HT LF, but Marc Branchaud reports that the shell
on FreeBSD 7.2 gets this wrong.
It is easy to set it to the default value manually, so let's do so.
Signed-off-by: Junio C Hamano
---
git-sh-setup.sh | 7 +
I like your patch's subject line better than mine.
M.
On 12-12-07 05:34 PM, Junio C Hamano wrote:
> With an unset IFS, field splitting is supposed to act as if IFS is
> set to the usual SP HT LF, but Marc Branchaud reports that the shell
> on FreeBSD 7.2 gets this wrong.
>
> It
On 07.12.2012, at 22:52, Junio C Hamano wrote:
> Max Horn writes:
>
>> On 07.12.2012, at 20:09, Junio C Hamano wrote:
>>
>>> Except for a minor nit in 6/6; I think "defined options" should be
>>> "defined attributes".
>>>
>>> --- a/Documentation/git-remote-helpers.txt
>>> +++ b/Documentat
Junio C Hamano writes:
> +# Similarly for IFS, but some shells (e.g. FreeBSD 7.2) are buggy and
> +# do not equate an unset IFS with IFS with the default, so here is
> +# an explicit SP HT LF.
> +IFS='
> +'
Trailing whitespace can easily get lost, so it's probably better to
stick a '' in
Andreas Schwab writes:
> Junio C Hamano writes:
>
>> +# Similarly for IFS, but some shells (e.g. FreeBSD 7.2) are buggy and
>> +# do not equate an unset IFS with IFS with the default, so here is
>> +# an explicit SP HT LF.
>> +IFS='
>> +'
>
> Trailing whitespace can easily get lost
The c
The line that happens to begin with indent followed by "3. " was
interpreted as if it were an enumerated list; just wrap the lines
differently to work it around for now.
Signed-off-by: Junio C Hamano
---
* The last section of Documentation/technical/api-command.txt has a
related/similar issue
A release candidate Git v1.8.1-rc1 is now available for testing
at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
4b451bb5b7125349c35cf15118e8f1893569e48f git-1.8.1.rc1.tar.gz
7416b28a0917fef26ca06f22bc49
---
builtin/shortlog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index b316cf3..cb85ede 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static char const * const shortlog_usa
To whom it may concern,
I am not sure if this is the right place to send this, but I couldn't find
anything on the web that seemed official, so here goes.
Imagine this scenario:
1) You have a Git repo with two branches (branchA and branchB), which are
currently identical.
2) Checkout to branch.
Intent-to-add entries used to forbid writing trees so it was not a
problem. After commit 3f6d56d (commit: ignore intent-to-add entries
instead of refusing - 2012-02-07), we can generate trees from an index
with i-t-a entries.
However, the commit forgets to invalidate all paths leading to i-t-a
ent
34 matches
Mail list logo
