On Wed, Dec 10, 2014 at 2:34 AM, Jeff King wrote:
> Below is a another iteration on the patch. The actual code changes are
> the same as the strbuf one, but the tests take care to avoid assuming
> the filesystem can handle such a long path. Testing on Windows and OS X
> is appreciated.
All three
On Tue, Dec 09, 2014 at 02:23:37PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Elsewhere I mentioned a tool to extract comments and format them. But do
> > people actually care about the formatting step?
>
> If formatting means "convert to a straightforward text document that I
> can
On Tue, Dec 09, 2014 at 03:18:28PM -0800, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > Jeff King wrote:
> >
> >> Elsewhere I mentioned a tool to extract comments and format them. But do
> >> people actually care about the formatting step?
> >
> > If formatting means "convert to a straig
On Tue, Dec 9, 2014 at 7:17 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> But the one place I do not agree is:
>>
>>> I think "sequence.editor" and "core.editor" are better because:
>>>
>>> - they use the same syntax as the config variables, so they are easier
>>> to remember and to discover
On Wed, Dec 10, 2014 at 7:37 AM, brian m. carlson
wrote:
> I have a repository that's just under 2 GiB in size and contains over
> 2 refs, with a copy of it on a server. Both sides are using Git
> 2.1.2. If I push a branch that contains a single commit, it takes about
> 15 seconds to push.
Jeff King wrote:
>> Jeff King wrote:
> We could probably do a better job of keeping our header files neat and
> well-ordered. And perhaps would so if they had a coherent narrative in
> the first place.
The example I was looking at before was refs.h. It is still a mess.
Hopefully strbuf.h will wo
On Wed, Dec 10, 2014 at 3:36 AM, Eric Sunshine wrote:
> On Wed, Dec 10, 2014 at 2:34 AM, Jeff King wrote:
>> Below is a another iteration on the patch. The actual code changes are
>> the same as the strbuf one, but the tests take care to avoid assuming
>> the filesystem can handle such a long pat
On Wed, Dec 10, 2014 at 03:36:31AM -0500, Eric Sunshine wrote:
> On Wed, Dec 10, 2014 at 2:34 AM, Jeff King wrote:
> > Below is a another iteration on the patch. The actual code changes are
> > the same as the strbuf one, but the tests take care to avoid assuming
> > the filesystem can handle suc
On Wed, Dec 10, 2014 at 4:42 AM, Eric Sunshine wrote:
> On Wed, Dec 10, 2014 at 3:36 AM, Eric Sunshine
> wrote:
>> On Wed, Dec 10, 2014 at 2:34 AM, Jeff King wrote:
>>> Below is a another iteration on the patch. The actual code changes are
>>> the same as the strbuf one, but the tests take care
On Wed, Dec 10, 2014 at 04:49:38AM -0500, Eric Sunshine wrote:
> On Wed, Dec 10, 2014 at 4:42 AM, Eric Sunshine
> wrote:
> > On Wed, Dec 10, 2014 at 3:36 AM, Eric Sunshine
> > wrote:
> >> On Wed, Dec 10, 2014 at 2:34 AM, Jeff King wrote:
> >>> Below is a another iteration on the patch. The ac
On Wed, Dec 10, 2014 at 4:47 AM, Jeff King wrote:
> On Wed, Dec 10, 2014 at 03:36:31AM -0500, Eric Sunshine wrote:
>
>> On Wed, Dec 10, 2014 at 2:34 AM, Jeff King wrote:
>> > Below is a another iteration on the patch. The actual code changes are
>> > the same as the strbuf one, but the tests take
We want to recognize the packed-refs header and skip to the
"traits" part of the line. We currently do it by feeding
sizeof() a static const array to strncmp. However, it's a
bit simpler to just skip_prefix, which expresses the
intention more directly, and without remembering to account
for the NUL
Now that we have a strbuf in read_packed_refs, we can pass
it straight to the line parser, which saves us an extra
strlen.
Signed-off-by: Jeff King
---
refs.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/refs.c b/refs.c
index 6f31935..10f8247
On Wed, Dec 10, 2014 at 04:53:19AM -0500, Jeff King wrote:
> > Clarification: for-each-ref ignores the ref when the full line read
> > from packed-refs hits length 1024 (not when the refname itself hits
> > length 1024).
>
> Yes, the problem is in read_packed_refs:
>
> char refline[PATH_MAX]
We currently used a fixed PATH_MAX-sized buffer for reading
packed-refs lines. This is a reasonable guess, in the sense
that git generally cannot work with refs larger than
PATH_MAX. However, there are a few cases where it is not
great:
1. Some systems may have a low value of PATH_MAX, but can
Hello,
I'm using git 2.0.4 and 1.7.10.4 and have discovered an issue with quiet
option on fetch.
Scenario:
I am fetching from one bare repo into another bare repo and fetching
from branch A to branch B.
In the case that the branches have deviated from one another, --quiet
surpresses all out
On Wed, Dec 10, 2014 at 12:08 PM, Torsten Bögershausen wrote:
> That opens another question:
> How flexible/extensible/self-describing is the format of the UNTR extension
> ?
> If we drop the OS name & root dir check because it disallows network use,
> but later add a better method to verify that
Git is having empty email problems I think, I'm on git v2.1.3.
Steps to reproduce:
$ git init
Initialized empty Git repository in /tmp/test_git/.git/
$ echo 'test' > abc
$ git add --all 1 ↵
$ git commit --message 'test'
[master (root-commit) 3cc2793] test
1 file chan
On 9 December 2014 at 18:59, Jeff King wrote:
> On Tue, Dec 09, 2014 at 07:52:33PM +0100, Henning Moll wrote:
>> I assume that there is a lot of process forking going on. Could that be the
>> cause?
>
> Yes. filter-branch is a shell scripts, and it is probably running
> multiple git commands per c
On Wed, Dec 10, 2014 at 02:18:24PM +, Roberto Tyley wrote:
> Depending on how much time you can sink into improving the performance
> (versus just allowing the process to run to completion), you could
> also look into a non-forking solution, as well as not bothering to
> load the commit trees.
Junio C Hamano schrieb am 09.12.2014 um 21:26:
> Michael J Gruber writes:
>
>> Rather than changing git-foo.txt, we could do the substitution magic
>> from Documentation/Makefile, of course, to keep man pages and command-list
>> in sync. Although this would keep me from submitting the final serie
On 10 December 2014 at 14:37, Jeff King wrote:
> On Wed, Dec 10, 2014 at 02:18:24PM +, Roberto Tyley wrote:
>> object SetCommitterToAuthor extends CommitNodeCleaner {
>> override def fixer(kit: CommitNodeCleaner.Kit) = c =>
>> c.copy(committer = c.author) // PersonIdent class holds name, ema
Johannes Schindelin writes:
THis is not limited to this step, but
> Subject: Re: [PATCH 01/18] Introduce fsck options
please make it easier to cluster and spot the series in the eventual
shortlog by giving a common prefix to the patches, e.g.
fsck: introduce fsck_options struct
> +sta
On Thu, Dec 11, 2014 at 12:17:35AM +1100, Simon wrote:
> Git is having empty email problems I think, I'm on git v2.1.3.
>
> Steps to reproduce:
>
> $ git init
> Initialized empty Git repository in /tmp/test_git/.git/
> $ echo 'test' > abc
> $ git add --all 1 ↵
> $ git commit
When we generate the commit-message template, we try to
report an author or committer ident that will be of interest
to the user: an author that does not match the committer, or
a committer that was auto-configured.
When doing so, if we encounter what we consider to be a
bogus ident, we immediatel
To figure out the author ident for a commit, we call
determine_author_info(). This function collects information
from the environment, other commits (in the case of
"--amend" or "-c/-C"), and the "--author" option. It then
uses fmt_ident to generate the final ident string that goes
into the commit
Roberto Tyley writes:
> The BFG is generally faster than filter-branch for 3 reasons:
>
> 1. No forking - everything stays in the JVM process
> 2. Embarrassingly parallel algorithm makes good use of multi-core machines
> 3. Memoization means no Git object (file or folder) is cleaned more than onc
Jeff King writes:
>> ... I'd be happy to
>> contribute a patch that gives 'gc' a flag to do the equivalent of:
>>
>> git reflog expire --expire=now --all && git gc --prune=now --aggressive
>>
>> Maybe:
>>
>> git gc --purge
>
> Yeah, that is common enough that it might be worthwhile (you probab
On 12/04/2014 08:59 AM, Jeff King wrote:
> On Wed, Dec 03, 2014 at 01:38:58PM -0800, Jonathan Nieder wrote:
>> The allocation of a variable-sized buffer is a small overhead that I
>> don't mind incurring on error. In the non-error case, the caller
>> doesn't actually have to free the buffer, and i
Hello,
I'm trying to recursively update submodules in a repo on a server that
requires a proxy to access the internet.
I typically pass http.proxy with -c to tell git about the proxy, but
with `submodule update`, it seems the argument isn't propagated and thus
results in the process sitting
On Wed, 2014-11-26 at 15:16 -0800, Junio C Hamano wrote:
> Paul Smith writes:
>
> > This is what happens for a file:
> >
> > $ rm -f foo
> >
> > $ touch foo
> >
> > $ ./src/git/contrib/workdir/git-new-workdir src/git foo master
> > mkdir: cannot create directory ‘foo’: Not a directory
> > unable
Jeff King writes:
> Here's a patch to do that. It still doesn't let you create long refs on
> OS X, as we get caught up in the PATH_MAX found in git_path() and
> friends. Still, I think it's a step in the right direction, and it fixes
> the shearing issue.
>
> Patches 2 and 3 are just follow-on c
Johannes Schindelin writes:
> For example, missing emails in commit and tag objects can be demoted to
> mere warnings with
>
> git config receive.fsck.missing-email warn
No punctuations in the first and the last level of configuration
variable names, please. I.e. s/missing-email/missingEm
Johannes Schindelin writes:
> This function will be used in the next commits to allow the user to
> ask fsck to handle specific problems differently, e.g. demoting certain
> errors to warnings. It has to handle partial strings because we would
> like to be able to parse, say, '--strict=missing-em
Johannes Schindelin writes:
> There are legacy repositories out there whose older commits and tags
> have issues that prevent pushing them when 'receive.fsckObjects' is set.
> One real-life example is a commit object that has been hand-crafted to
> list two authors.
>
> Often, it is not possible
Johannes Schindelin writes:
> This problem has been detected in the wild, and is the primary reason
> to introduce an option to demote certain fsck errors to warnings. Let's
> offer to ignore this particular problem specifically.
> ...
> + while (skip_prefix(buffer, "author ", &buffer)) {
> +
Johannes Schindelin writes:
> Some kinds of errors are intrinsically unrecoverable (e.g. errors while
> uncompressing objects). It does not make sense to allow demoting them to
> mere warnings.
Makes sense, but the patch makes it look as if this is an "oops, we
should have done the list in patch
Johannes Schindelin writes:
> An fsck issue in a legacy repository might be so common that one would
> like not to bother the user with mentioning it at all. With this change,
> that is possible by setting the respective error to "ignore".
Makes sense.
--
To unsubscribe from this list: send the
Johannes Schindelin writes:
> The 'invalid tag name' and 'missing tagger entry' warnings can now be
> upgraded to errors by setting receive.fsck.invalid-tag-name and
> receive.fsck.missing-tagger-entry to 'error'.
Hmm, why can't all warnings promotable to errors, or are the above
two mentioned o
Johannes Schindelin writes:
> We already have support in `git receive-pack` to deal with some legacy
> repositories which have non-fatal issues.
>
> Let's make `git fsck` itself useful with such repositories, too, by
> allowing users to ignore known issues, or at least demote those issues
> to me
Hi,
>> In the case of having 'exec' lines interspersed, the $commitcount
>> becomes a lot less useful (no comparison to editor line numbers),
>> though.
>
> Hmph, interesting. Then perhaps not filtering at all and instead
> labelling this new piece of information not "commit(s)" a better
> soluti
Johannes Schindelin writes:
> The optional new config option `receive.fsck.skip-list` specifies the path
> to a file listing the names, i.e. SHA-1s, one per line, of objects that
> are to be ignored by `git receive-pack` when `receive.fsckObjects = true`.
>
> This is extremely handy in case of le
Johannes Schindelin writes:
> At the moment, the git-fsck's integrity checks are targeted toward the
> end user, i.e. the error messages are really just messages, intended for
> human consumption.
>
> Under certain circumstances, some of those errors should be allowed to
> be turned into mere war
Jeff King writes:
> However, there's something else going on. I am surprised that we allow
> empty emails at all and the code here is quite strange. The first check
> on the ident format is when we feed the data to fmt_ident to generate
> the string that goes into the commit object. We disallow
Michael Haggerty writes:
> What if we go in the direction not of less infrastructure, but a little
> bit more? Like
>
> struct result {
> int code;
> struct strbuf msg;
> };
>
> int report_errors(struct result *result)
> {
> int co
On Wed, Dec 10, 2014 at 11:00:18AM -0800, Junio C Hamano wrote:
> Two potential issues are:
>
> - Callers that ignore errors need to actively ignore errors with
>strbuf_release(&result.msg);
That was my first thought, too. If you want to do anything besides
report_error, you have to deal wi
On Fri, Dec 05, 2014 at 04:36:20AM -0500, Jeff King wrote:
> On Thu, Dec 04, 2014 at 04:25:32PM -0700, Stephen Fisher wrote:
>
> > I'm installing Git 2.2.0 from source distribution on NetBSD 6.1.5
> > (amd64) and when I specify --mandir=/usr/local/man, it still
> > installs man pages in the defa
On Wed, Dec 10, 2014 at 10:46:16AM -0800, Junio C Hamano wrote:
> > So we now notice the empty email in this code path, but the only thing
> > we do is avoid writing out the environment variables and continue. Which
> > means that the actual string generated by fmt_ident (complete with empty
> > e
On Wed, Dec 10, 2014 at 12:41:50PM -0700, Stephen Fisher wrote:
> I'm executing ./configure --mandir=/usr/local/man --disable-pthreads
> then gmake and gmake install. I'm using gmake (GNU make) because I get
> Makefile errors with the regular BSD make, but that's another issue.
You have to bui
My vote is for putting the API docs in the header files:
* Functions are documented right next to their declarations (which the
compiler guarantees are up-to-date), removing ambiguity and avoiding
some redundancy.
* It is obvious at a glance which functions are documented and which
still need doc
On Tue, Dec 09, 2014 at 10:17:13AM -0800, Junio C Hamano wrote:
> It is a tangent, the current definition of "git_editor" helper reads
> like this:
>
> git_editor() {
> if test -z "${GIT_EDITOR:+set}"
> then
> GIT_EDITOR="$(git var G
On Wed, Dec 10, 2014 at 4:47 AM, Jeff King wrote:
> Subject: pkt-line: allow writing of LARGE_PACKET_MAX buffers
>
> When we send out pkt-lines with refnames, we use a static
> 1000-byte buffer. This means that the maximum size of a ref
> over the git protocol is around 950 bytes (the exact size
>
Say I have a local repository with several submodules that point at
remote repositories. All submodules are up-to-date.
I want to clone everything to another location on disk, *without
hitting the network to fetch the submodules*. Obviously a simple "git
clone" will work for the superproject, but
On Wed, Dec 10, 2014 at 03:14:17PM -0500, Eric Sunshine wrote:
> > +test_expect_success 'try to create repo with absurdly long refname' '
> > + ref240=$_z40/$_z40/$_z40/$_z40/$_z40/$_z40
>
> Maybe you want to keep the &&-chain intact here?
Thanks, yeah. It doesn't matter in practice, but w
Jeff King writes:
> On Tue, Dec 09, 2014 at 10:17:13AM -0800, Junio C Hamano wrote:
>
>> This is another tangent that comes back to the original "how to name
>> them?" question, but I wonder if a convention like this would work.
>>
>> * When asking for a feature (e.g. "what editor to use"), if
Michael Haggerty wrote:
> I would find it a pity for that work to be
> squashed into Documentation/technical/api-*.txt, where in my opinion it
> is less discoverable and more likely to fall into disrepair.
I think we're in violent agreement and keep repeating ourselve
From: "Роман Донченко"
Sent: Sunday, December 07, 2014 6:17 PM
Would that be worth a terse comment in the documentation change part
of the patch?
"Multiple (RFC2047) encodings are not supported.",
or would that be bike shed noise.
I didn't change any documentation... and in either case, the
Jonathan Nieder writes:
> Michael Haggerty wrote:
>
>> I would find it a pity for that work to be
>> squashed into Documentation/technical/api-*.txt, where in my opinion it
>> is less discoverable and more likely to fall into disrepair.
>
> I think we're in violent ag
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Michael Haggerty wrote:
>>> I would find it a pity for that work to be
>>> squashed into Documentation/technical/api-*.txt, where in my opinion it
>>> is less discoverable and more likely to fall into disrepair.
>>
>>
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
Michael J Gruber writes:
> When using a localised git, there are many reasons why a correspondence
> between English and localised git terms is needed:
> - connect localised messages with English ones (porcelain vs. plumbing)
> - connect localised messages with English man pages or online docs
>
Jonathan Nieder writes:
> Some possibilities, in order of my preference (earlier items are better):
>
> 1. Move documentation to header and provide a program to generate a nice
> standalone document.
>
> 2. Move documentation to header, being careful enough that the header
> sort of wor
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> 2. Move documentation to header, being careful enough that the header
>> sort of works as a standalone document.
>>
>> 3. Move documentation to Documentation/technical/ and keep the header
>> bare-bones.
[...]
> I am not sure if (2) and
On Tue, Dec 09, 2014 at 09:41:28PM -0800, Shawn Pearce wrote:
> On Tue, Dec 9, 2014 at 4:37 PM, brian m. carlson
> wrote:
> > Most of the time is spent between the "Pushing to remote machine" and
> > "Counting objects", running git pack-objects:
> >
> > git pack-objects --all-progress-implied --
On 10 December 2014 at 16:07, Junio C Hamano wrote:
> Jeff King writes:
>>> git reflog expire --expire=now --all && git gc --prune=now --aggressive
>>>
>>> Maybe:
>>>
>>> git gc --purge
>>
>> Yeah, that is common enough that it might be worthwhile (you probably
>> want --expire-unreachable in the
On 10 December 2014 at 16:05, Junio C Hamano wrote:
> Roberto Tyley writes:
>
>> The BFG is generally faster than filter-branch for 3 reasons:
>>
>> 1. No forking - everything stays in the JVM process
>> 2. Embarrassingly parallel algorithm makes good use of multi-core machines
>> 3. Memoization
Two of the tests fail because
verify refs/heads/foo
with no argument (not even zeros) actually *deletes* refs/heads/foo.
This problem will be fixed in the next commit.
Signed-off-by: Michael Haggerty
---
The two failing tests have to restore the $m reference when they're
done because otherw
Ever since the --stdin option was added to "git update-ref" in
c750ba9519 update-ref: support multiple simultaneous updates (2013-09-09)
the "verify" command has been broken. If no is specified,
the documentation says that the "verify" command will verify that the
reference doesn't currently
If "git update-ref --stdin" was given a "verify" command with no
"" at all (not even zeros), the code was mistakenly setting
have_old=0 (and leaving old_sha1 uninitialized). But this is
incorrect: this command is supposed to verify that the reference
doesn't exist. So in this case we really need ol
From: "brian m. carlson"
Thin packs are enabled when pushing by default, but with a large number
of refs and a fast network, git may spend more time trying to find a
good delta than it would spend simply sending data over the network.
Add a per-remote option, pushThin, that controls the default f
On Thu, Dec 11, 2014 at 12:47:51AM +0100, Michael Haggerty wrote:
> Two of the tests fail because
>
> verify refs/heads/foo
>
> with no argument (not even zeros) actually *deletes* refs/heads/foo.
> This problem will be fixed in the next commit.
>
> Signed-off-by: Michael Haggerty
> ---
Re
On 12/09/2014 12:34 AM, Stefan Beller wrote:
> On Fri, Dec 05, 2014 at 12:08:34AM +0100, Michael Haggerty wrote:
>> From: Ronnie Sahlberg
>>
>> Inline the function at its one remaining caller (which is within
>> refs.c) and remove it.
>>
>
>
>> Signed-off-by: Michael Haggerty
>
> It's original
On Thu, Dec 11, 2014 at 12:47:52AM +0100, Michael Haggerty wrote:
> If "git update-ref --stdin" was given a "verify" command with no
> "" at all (not even zeros), the code was mistakenly setting
> have_old=0 (and leaving old_sha1 uninitialized). But this is
> incorrect: this command is supposed to
On Wed, Dec 10, 2014 at 11:49:49PM +, brian m. carlson wrote:
> From: "brian m. carlson"
>
> Thin packs are enabled when pushing by default, but with a large number
> of refs and a fast network, git may spend more time trying to find a
> good delta than it would spend simply sending data over
On Thu, Dec 11, 2014 at 6:34 AM, brian m. carlson
wrote:
> I looked at this more in depth today and I found that the bottleneck is
> --thin. I tried git send-pack, which does not use --thin by default,
> which led me to further testing. A particular push went from 24 seconds
> with --thin to 4 s
On Thu, Dec 11, 2014 at 08:41:07AM +0700, Duy Nguyen wrote:
> It could be a regression by fbd4a70 (list-objects: mark more commits
> as edges in mark_edges_uninteresting - 2013-08-16). That commit makes
> --thin a lot more agressive (reading lots of trees). You can try to
> revert that commit (or u
In commit fbd4a70 (list-objects: mark more commits as edges in
mark_edges_uninteresting - 2013-08-16), we made --thin much more
aggressive by reading lots more trees. This produces much smaller packs
for shallow clones; however, it causes a significant performance
regression for non-shallow clones
By default, git-diff shows changes and pathnames relative to the
repository root.
Setting the diff.relative config option to "true" shows pathnames
relative to
the current directory and excludes changes outside this directory.
---
Documentation/diff-config.txt | 6 ++
diff.c
Hello, all.
H. Merijn Brand runs a few HP-UX boxes to help perl5 and other open
source communities, wants help porting more recent Git on these
boxes, running HP-UX 10.20, 11.00, and 11.23, and looking for a
volunteer. Please contact him directly if you are interested.
Thanks.
--
To unsubscrib
79 matches
Mail list logo
