On Wed, Dec 10, 2014 at 2:34 AM, Jeff King p...@peff.net 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.
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 read
On Tue, Dec 09, 2014 at 03:18:28PM -0800, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
On Tue, Dec 9, 2014 at 7:17 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net 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
On Wed, Dec 10, 2014 at 7:37 AM, brian m. carlson
sand...@crustytoothpaste.net 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
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 work
On Wed, Dec 10, 2014 at 3:36 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, Dec 10, 2014 at 2:34 AM, Jeff King p...@peff.net 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
On Wed, Dec 10, 2014 at 03:36:31AM -0500, Eric Sunshine wrote:
On Wed, Dec 10, 2014 at 2:34 AM, Jeff King p...@peff.net 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
On Wed, Dec 10, 2014 at 4:42 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, Dec 10, 2014 at 3:36 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Wed, Dec 10, 2014 at 2:34 AM, Jeff King p...@peff.net wrote:
Below is a another iteration on the patch. The actual code changes are
On Wed, Dec 10, 2014 at 04:49:38AM -0500, Eric Sunshine wrote:
On Wed, Dec 10, 2014 at 4:42 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Wed, Dec 10, 2014 at 3:36 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Wed, Dec 10, 2014 at 2:34 AM, Jeff King p...@peff.net wrote:
On Wed, Dec 10, 2014 at 4:47 AM, Jeff King p...@peff.net 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 p...@peff.net wrote:
Below is a another iteration on the patch. The actual code changes are
the same as the strbuf one,
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
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 p...@peff.net
---
refs.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/refs.c b/refs.c
index
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
On Wed, Dec 10, 2014 at 12:08 PM, Torsten Bögershausen tbo...@web.de 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
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
On 9 December 2014 at 18:59, Jeff King p...@peff.net 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
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. To
Junio C Hamano schrieb am 09.12.2014 um 21:26:
Michael J Gruber g...@drmicha.warpmail.net 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
On 10 December 2014 at 14:37, Jeff King p...@peff.net 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
Johannes Schindelin johannes.schinde...@gmx.de 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
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 --message
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
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 roberto.ty...@gmail.com 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
Jeff King p...@peff.net 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 probably
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 if they
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 p...@mad-scientist.net 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
Jeff King p...@peff.net 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
Johannes Schindelin johannes.schinde...@gmx.de 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.
Johannes Schindelin johannes.schinde...@gmx.de 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,
Johannes Schindelin johannes.schinde...@gmx.de 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.
Johannes Schindelin johannes.schinde...@gmx.de 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,
Johannes Schindelin johannes.schinde...@gmx.de 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
Johannes Schindelin johannes.schinde...@gmx.de 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
Johannes Schindelin johannes.schinde...@gmx.de 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
Johannes Schindelin johannes.schinde...@gmx.de 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
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
solution? You
Johannes Schindelin johannes.schinde...@gmx.de 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
Johannes Schindelin johannes.schinde...@gmx.de 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
Jeff King p...@peff.net 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
Michael Haggerty mhag...@alum.mit.edu 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)
{
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 with
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 default
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
email)
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 build
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
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 GIT_EDITOR)
On Wed, Dec 10, 2014 at 4:47 AM, Jeff King p...@peff.net 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
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 we do
Jeff King p...@peff.net 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 ourselves.
From: Роман Донченко d...@corrigendum.ru
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
Jonathan Nieder jrnie...@gmail.com 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
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
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
Michael J Gruber g...@drmicha.warpmail.net 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
Jonathan Nieder jrnie...@gmail.com 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
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
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
sand...@crustytoothpaste.net wrote:
Most of the time is spent between the Pushing to remote machine and
Counting objects, running git pack-objects:
git pack-objects
On 10 December 2014 at 16:07, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net 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
On 10 December 2014 at 16:05, Junio C Hamano gits...@pobox.com wrote:
Roberto Tyley roberto.ty...@gmail.com 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
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 mhag...@alum.mit.edu
---
The two failing tests have to restore the $m reference when
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 oldvalue is specified,
the documentation says that the verify command will verify that the
reference doesn't
If git update-ref --stdin was given a verify command with no
newvalue 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
From: brian m. carlson brian.carl...@cpanel.net
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
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
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 sahlb...@google.com
Inline the function at its one remaining caller (which is within
refs.c) and remove it.
Signed-off-by: Michael Haggerty
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
newvalue 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 brian.carl...@cpanel.net
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
On Thu, Dec 11, 2014 at 6:34 AM, brian m. carlson
sand...@crustytoothpaste.net 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
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 use
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
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
79 matches
Mail list logo
