On Sun, Aug 24, 2014 at 08:22:41PM +0700, Gábor Szeder wrote:
On Aug 23, 2014 12:26 PM, Jeff King p...@peff.net wrote:
Since dd0b72c (bash prompt: use bash builtins to check stash
state, 2011-04-01), git-prompt checks whether we have a
stash by looking for $GIT_DIR/refs/stash. Generally
On Sun, Aug 24, 2014 at 04:39:37PM -0700, Junio C Hamano wrote:
On Sun, Aug 24, 2014 at 8:10 AM, Stefan Beller stefanbel...@gmail.com wrote:
for (p = list, i = 0; i cnt; i++) {
- struct name_decoration *r = xmalloc(sizeof(*r) + 100);
+ char name[100];
On Sun, Aug 24, 2014 at 07:47:24PM +0530, Arjun Sreedharan wrote:
diff --git a/bisect.c b/bisect.c
index d6e851d..c96aab0 100644
--- a/bisect.c
+++ b/bisect.c
@@ -215,10 +215,13 @@ static struct commit_list *best_bisection_sorted(struct
commit_list *list, int n
}
qsort(array,
On Mon, Aug 25, 2014 at 04:06:52PM +0200, Christian Couder wrote:
This allocation should be name_len + 1 for the NUL-terminator, no?
I wondered about that too, but as struct name_decoration is defined like this:
struct name_decoration {
struct name_decoration *next;
int
On Mon, Aug 25, 2014 at 05:06:22PM +0200, Steffen Prohaska wrote:
I think it's reasonable that GIT_ALLOC_LIMIT=0 means no limit, so that
the limit can easily be disabled temporarily.
IMHO, GIT_ALLOC_LIMIT= (i.e., the empty string) would be a good way to
say that (and I guess that even works
On Mon, Aug 25, 2014 at 10:16:52AM -0700, Ronnie Sahlberg wrote:
Print an error before returning when pack_data is NULL ?
I don't think so. We call end_packfile in some code paths (like the die
handler) as close if it's open. So I think it makes sense for it to be
a noop if nothing is open.
On Mon, Aug 25, 2014 at 10:38:56AM -0700, Ronnie Sahlberg wrote:
[1/5]: git-prompt: do not look for refs/stash in $GIT_DIR
[2/5]: pack-refs: prune top-level refs like refs/foo
[3/5]: fast-import: clean up pack_data pointer in end_packfile
[4/5]: fast-import: fix buffer overflow in
and
FETCH_HEAD, which are known to be transient).
Signed-off-by: Jeff King p...@peff.net
---
Looking over the code, I am not sure that it actually works as
advertised with respect to ORIG_HEAD, etc. That would be easy enough to
fix, though.
Documentation/config.txt | 8 +---
branch.c
On Mon, Aug 25, 2014 at 12:30:51PM -0700, Junio C Hamano wrote:
Also interestingly, I notice that it is very clear that it is not
LIB_H but ANY_H ;-)
Yeah, it has been that way for quite a while. I don't know if it is that
big a deal, but it would not be unreasonable to do a patch to rename on
On Mon, Aug 25, 2014 at 11:26:39AM -0700, Junio C Hamano wrote:
Good digging, and I agree that it should use the FLEX_ARRAY for
consistency.
I can produce a patch, but I did not want to steal Arjun's thunder.
Arjun, did my proposal make sense? Do you want to try implementing that?
-Peff
--
On Mon, Aug 25, 2014 at 10:21:58AM -0700, Junio C Hamano wrote:
+ if (ce_stage(ce) = ce_stage(next_ce))
+ die(Unordered stage entries for '%s',
+ ce-name);
Not quite. We do allow multiple higher stage entries; having two or
more
On Mon, Aug 25, 2014 at 12:46:41PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
-LOCALIZED_C := $(C_OBJ:o=c) $(LIB_H) $(GENERATED_H)
+LOCALIZED_C = $(C_OBJ:o=c) $(GENERATED_H)
Why is LIB_H dropped here? This would mean that po/git.pot stops
including strings from macros and static
On Mon, Aug 25, 2014 at 04:00:42PM -0400, Jeff King wrote:
On Mon, Aug 25, 2014 at 12:46:41PM -0700, Jonathan Nieder wrote:
Jeff King wrote:
-LOCALIZED_C := $(C_OBJ:o=c) $(LIB_H) $(GENERATED_H)
+LOCALIZED_C = $(C_OBJ:o=c) $(GENERATED_H)
Why is LIB_H dropped here? This would
On Mon, Aug 25, 2014 at 02:11:09PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Mon, Aug 25, 2014 at 11:26:39AM -0700, Junio C Hamano wrote:
Good digging, and I agree that it should use the FLEX_ARRAY for
consistency.
I can produce a patch, but I did not want
one byte for the NUL terminator
of the string we putting into the flex-array (it did not
need to before, because the struct itself was over-allocated
by one byte).
Signed-off-by: Jeff King p...@peff.net
---
This could come first in the series, but doing it last means we only
have to update one spot
not supply enough information).
As a bonus, this also means that the decoration hashes
created by the bisect code will use less memory (previously
we over-allocated space for the distance integer, but not we
format it into a temporary buffer and copy it to the final
flex-array).
Signed-off-by: Jeff
to log-tree, as well.
However, it's unlikely to cause any maintainability harm
making the actual data public, and this interface is more
flexible if we need to look at decorations from other parts
of the code in the future.
Signed-off-by: Jeff King p...@peff.net
---
commit.h | 2 +-
log-tree.c | 11
On Mon, Aug 25, 2014 at 02:36:02PM -0700, Junio C Hamano wrote:
I think you are right, and the patch is the right direction (assuming we
want to do this; I question whether there are enough elements in the
list for us to care about the size, and if there are, we are probably
better off
On Tue, Aug 26, 2014 at 12:57:21PM +0100, Ramsay Jones wrote:
+ ret = xcalloc(1, base + extra);
+ va_start(ap, fmt);
+ vsnprintf(ret + offset, extra, fmt, ap);
What is the relationship between 'base' and 'offset'?
Let me assume that base is always, depending on your compiler,
On Tue, Aug 26, 2014 at 12:48:24PM +0100, Ramsay Jones wrote:
We can fix this by making name_decoration's adding function
public. If all callers use it, then any changes to structi
s/structi/struct/
I blame vi finger-cruft.
initialization only need to happen in one place (and because
On Tue, Aug 26, 2014 at 02:08:35PM +0200, Jaime Soriano Pastor wrote:
That is how we natively (read: not with the funky virtual stuff
merge-recursive does) express a merge with multiple merge bases.
You also should be able to read this in the way how git merge invokes
merge strategies
On Mon, Aug 25, 2014 at 03:08:50PM -0700, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Wouldn't it be sufficient to start digging not from * but from
??*?
Gah, the * was supposed to be . in my examples (though it doesn't
hurt).
find ??* \( -name
On Tue, Aug 26, 2014 at 11:29:32AM +0200, Rémy Hubscher wrote:
I'd like to add a list parameter to the `git remote` command.
We already have:
- `git remote add`
- `git remote rename`
- `git remote delete`
I often write `git remote list` before finaly using `git remote -v` but
it
On Tue, Aug 26, 2014 at 01:37:44PM +0100, Ramsay Jones wrote:
On my 64-bit system using gcc, sizeof() returns 16; it has to pad the
whole thing to 64-bit alignment in case I put two of them in an array.
But offsetof(name) is 12, since the array of char does not need the same
alignment; it
On Tue, Aug 26, 2014 at 09:29:44AM +0200, Oliver Busch wrote:
I encountered the following problem: When using the date formatting option
ISO (either by setting --date=iso or using format:%ci for the committer
date), the output is formatted like this:
2014-08-25 17:49:43 +0200
But
On Tue, Aug 26, 2014 at 03:19:11PM +0200, Oliver Busch wrote:
PS: As far as I understand it, there is no optionality of the T as an
indicator for the start of the time part.
The standard says (and I am quoting from Wikipedia here, as I do not
have it myself):
4.3.2 NOTE: By mutual agreement
On Tue, Aug 26, 2014 at 10:10:33AM -0400, Jason Pyeron wrote:
But I am not sure that omitted means can be replaced with a space.
And while you can define by mutual agreement as git defines the
format, so any consumers agree to it that is not necessarily
useful to
somebody who wants to
On Tue, Aug 26, 2014 at 06:19:20PM +0200, Philippe Vaucher wrote:
Perhaps -v should have been the default all along. I do not use git
remote myself, so I don't know if -v is what most people use. But
changing the output of git remote now is probably a bad thing (I
expect some people may
On Tue, Aug 26, 2014 at 09:54:19AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Actually as you are not excluding CVS, RCS, etc., and using ??* as
the starting point will exclude .git, .hg, etc. at the top, I think
we can shorten it even further and say
find
On Tue, Aug 26, 2014 at 10:24:35AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
... But we are left with three options:
1. Add git remote list with verbose output. This is bad because it
differs gratuitously from git remote.
2. Add git remote list with non
On Tue, Aug 26, 2014 at 10:40:10AM -0700, Junio C Hamano wrote:
I may have called it lookup_name_decoration() to match, though, if I
were doing this patch ;-)
Hmph. I called it get because that was the opposite of add to me,
and I was matching add_name_decoration. Of course, in the regular
On Mon, Aug 25, 2014 at 06:55:51PM +0200, Steffen Prohaska wrote:
It could be handled that way, but we would be back to the original problem
that 32-bit git fails for large files. The convert code path currently
assumes that all data is available in a single buffer at some point to apply
On Mon, Aug 25, 2014 at 11:35:45AM -0700, Junio C Hamano wrote:
Steffen Prohaska proha...@zib.de writes:
Couldn't we do that with an lseek (or even an mmap with offset 0)? That
obviously would not work for non-file inputs, but I think we address
that already in index_fd: we push
,
this is a good time to make the switch (before any other
variables are added).
Signed-off-by: Jeff King p...@peff.net
---
config.c| 2 +-
t/t5551-http-fetch-smart.sh | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/config.c b/config.c
index 058505c
On Tue, Aug 26, 2014 at 05:23:24PM +0200, Steffen Prohaska wrote:
The caller opened the fd, so it should be responsible for closing it.
Signed-off-by: Steffen Prohaska proha...@zib.de
---
copy.c | 5 +
lockfile.c | 3 +++
2 files changed, 4 insertions(+), 4 deletions(-)
diff
On Tue, Aug 26, 2014 at 01:20:53PM -0700, Junio C Hamano wrote:
I think different people have different confusion criteria.
To me, these two are very different operations:
$ VAR=
$ unset VAR
I think it boils down to that I see that the distance between unset
vs set to empty is
On Tue, Aug 26, 2014 at 02:54:11PM -0700, Junio C Hamano wrote:
A worse position is to have git_env_bool() that says empty is
false and add a new git_env_ulong() that says empty is unset.
We should pick one or the other and use it for both.
Yeah, I agree they should probably behave the
On Wed, Aug 27, 2014 at 12:41:57AM -0400, David Turner wrote:
git mktree seems to allow the creation of a tree object with multiple
objects of the same name but different SHAs.
Yeah, I don't think we do many quality checks there. Ditto for git
hash-object.
The latter goes through index_mem,
commits, but that's
OK. This shouldn't happen in practice, and even if it does,
there's no particular reason that this function needs to
complain about it. It either finds the header it was asked
for, or it doesn't (and in the latter case, the caller will
typically complain).
Signed-off-by: Jeff King p
If we hit the end-of-header without finding an author
line, we just return from the function. We should jump to
the fail_exit path to clean up the buffer that we may have
allocated.
Signed-off-by: Jeff King p...@peff.net
---
commit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
).
Signed-off-by: Jeff King p...@peff.net
---
builtin/commit.c | 51 ++-
1 file changed, 22 insertions(+), 29 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 8da0a9f..57b046b 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
that the return value from getenv
remains valid across multiple calls.
2. We do not know whether to free the values at the end,
so we just leak them.
We can solve both by duplicating the string returned by
getenv().
Signed-off-by: Jeff King p...@peff.net
---
builtin/commit.c | 40
is not performance
critical (and where the use of a strbuf will help later
refactoring).
Signed-off-by: Jeff King p...@peff.net
---
builtin/commit.c | 20 ++--
cache.h | 4 ++--
date.c | 13 +++--
fast-import.c| 20 +---
ident.c
This saves us some manual parsing and makes the code more
readable.
Signed-off-by: Jeff King p...@peff.net
---
commit.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/commit.c b/commit.c
index 4ff8c66..9416d84 100644
--- a/commit.c
+++ b/commit.c
On Tue, Aug 26, 2014 at 03:09:34PM -0700, Junio C Hamano wrote:
--
[New Topics]
There are a few misc topics of mine that I'd like to ping on:
- jk/contrib-subtree-make-all; you picked up the topic, but it's not
in pu or what's cooking.
On Wed, Aug 27, 2014 at 05:18:21PM +0300, Max Kirillov wrote:
Could HEAD be added to list of heads while using --all switch?
To which command?
If you mean git branch, I think the detached HEAD is already
mentioned:
$ git branch
* (detached from 1290ebd)
master
If you mean git log, I
On Wed, Aug 27, 2014 at 01:42:45PM +, 李祐棠 wrote:
Here is the manual test script I use is manualscript.py:
I use git bisect manually, search from 1.2.9(bad) to 1.2.8(good), I
locate the commit that fixes this issue. The running log is attached
in this file(manual).
However if I use
On Wed, Aug 27, 2014 at 11:06:27AM +0200, Christian Couder wrote:
On Wed, Aug 27, 2014 at 9:55 AM, Jeff King p...@peff.net wrote:
[2/6]: record_author_info: fix memory leak on malformed commit
[3/6]: record_author_info: use find_commit_header
s/record_author_info/record_author_date
On Wed, Aug 27, 2014 at 08:17:15AM -0700, Junio C Hamano wrote:
I am somewhat against outright removing the capability to write out
invalid objects deliberately from these low level tools, because we
would need a way to easily reproduce bugs in end-user facing tools
by other people who claim
On Wed, Aug 27, 2014 at 08:31:51AM -0700, Junio C Hamano wrote:
- jk/send-pack-many-refspecs; this is in pu, but I didn't see it in
what's cooking. I'm concerned that the ulimit test gave you
trouble and you punted on it. :)
It was picked up after the day's edition of What's
On Wed, Aug 27, 2014 at 09:38:09AM -0700, Junio C Hamano wrote:
Makes sense. I think the v2 I sent[1] is OK, and as far as I was
planning to take it for now (there were some other possible enhancements
discussed, but I think those can happen in-tree if somebody feels like
working on it).
On Wed, Aug 27, 2014 at 09:01:02AM -0700, Junio C Hamano wrote:
+# this also covers commit messages
+test_expect_success 'stream omits path names' '
+ ! fgrep base stream
+ ! fgrep foo stream
+ ! fgrep subdir stream
+ ! fgrep bar stream
+ ! fgrep xyzzy stream
+'
I
are
numbers for git.git:
$ time git fast-export --anonymize --all \
--tag-of-filtered-object=drop output
real0m2.883s
user0m2.828s
sys 0m0.052s
$ gzip output
$ ls -lh output.gz | awk '{print $5}'
2.9M
Signed-off-by: Jeff King p...@peff.net
---
This has all
On Wed, Aug 27, 2014 at 10:30:22AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+const char *find_commit_header(const char *msg, const char *key, size_t
*out_len)
[...]
Hmph. Does this have to worry about continuation lines in the
header part e.g. mergetag
On Wed, Aug 27, 2014 at 02:00:16PM -0400, Jeff King wrote:
That may be something some callers want, but they should build it
separately around this find_commit_header, so that callers that want a
single line (like encoding or author) do not have to pay the price.
I didn't bother building
On Wed, Aug 27, 2014 at 10:46:42AM -0400, Peter Eisentraut wrote:
The log.decorate=auto value, which is mentioned in the release notes of
Git 2.1, is not documented in either git-config.txt or git-log.txt.
It should also be documented that auto corresponds to short.
Yes, you're right. Care
On Wed, Aug 27, 2014 at 12:05:06PM -0700, Junio C Hamano wrote:
If you mean including continuation lines in the output, I don't think
that's a good idea here. It would mean the function would have to copy
the value out (to get rid of the continuation whitespace) rather than
point directly
On Wed, Aug 27, 2014 at 11:23:08AM -0700, Junio C Hamano wrote:
When there are unmerged paths, you would often get something like
this:
[git.git (pu|MERGING]$ git commit
U copy.c
U wrapper.c
error: commit is not possible because you have unmerged files.
On Wed, Aug 27, 2014 at 03:15:05PM -0400, dev wrote:
This causes a problem on things like Solaris :
* new build flags
CC credential-store.o
git-compat-util.h, line 516: error: identifier redeclared: inet_ntop
current : function(int, pointer to const void, pointer to char,
On Wed, Aug 27, 2014 at 12:26:56PM -0700, Junio C Hamano wrote:
I don't mind returning -1 in out_len and have the callers check.
That way will allow callers to easily diagnose this
tree $T
author $GIT_AUTHOR_IDENT
committer $GIT_COMMITTER_IDENT
encoding encoding
On Wed, Aug 27, 2014 at 03:36:53PM -0400, Dale R. Worley wrote:
And it appears from an experiment that this is what happens. I have a
repository with pack.packSizeLimit = 99m, and there are 104 pack
files, and even when git gc is done, if I do git gc --auto, it
will do git-repack again.
I
On Wed, Aug 27, 2014 at 03:48:40PM -0400, dev wrote:
$ gzip -dc $SRC/git-2.0.4.tar.gz | tar -xf -
$ mv git-2.0.4 git-2.0.4_SunOS5.10_sparcv9.002
$
$ cd git-2.0.4_SunOS5.10_sparcv9.002
$
$ echo $CFLAGS
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64
-xmemalign=8s
On Thu, Aug 28, 2014 at 05:30:44PM +0700, Duy Nguyen wrote:
On Thu, Aug 28, 2014 at 12:01 AM, Jeff King p...@peff.net wrote:
You can get an overview of what will be shared
by running a command like:
git fast-export --anonymize --all |
perl -pe 's/\d+/X/g' |
sort -u |
less
On Thu, Aug 28, 2014 at 10:16:48AM -0400, dev wrote:
# gmake CFLAGS=$CFLAGS LDFLAGS=$LD_OPTIONS NEEDS_LIBICONV=Yes \
SHELL_PATH=/usr/local/bin/bash \
SANE_TOOL_PATH=/usr/local/bin \
USE_LIBPCRE=1 LIBPCREDIR=/usr/local CURLDIR=/usr/local \
EXPATDIR=/usr/local
On Thu, Aug 28, 2014 at 05:46:15PM +0100, Ramsay Jones wrote:
Dumb question (I have not even read the patch, so please just ignore me
if this is indeed dumb!): Is the map of original-name, anonymized-name
available to the user while he attempts to confirm that the bug is still
present?
No,
On Thu, Aug 28, 2014 at 11:11:47AM -0700, Junio C Hamano wrote:
+ Anonymize the contents of the repository while still retaining
+ the shape of the history and stored tree. See the section on
+ `ANONYMIZING` below.
Technically s/tree/trees/, I would think. For a repository with
On Mon, Aug 25, 2014 at 06:39:45PM +0200, René Scharfe wrote:
Thanks, that looks good. But while preparing the patch I noticed that
the added test sometimes fails. Helgrind pointed outet a race
condition. It is not caused by the patch to turn the asserts into
regular ifs, however -- here's
On Thu, Aug 28, 2014 at 06:08:21PM -0400, Jeff King wrote:
So we need some kind of mutual exclusion so that only one thread
proceeds with resolving the delta. The real_type check sort-of
functions in that way (except of course it is not actually thread safe).
Here's a patch which implements
On Thu, Aug 28, 2014 at 06:08:21PM -0400, Jeff King wrote:
Interesting. I couldn't convince Helgrind to catch such a case...
Ugh. It helps if you actually helgrind the git binary, and not the
shell-script from bin-wrappers. I can easily replicate the problem now.
The patch I just posted seems
On Thu, Aug 28, 2014 at 06:15:18PM -0400, Jeff King wrote:
As I implemented, I realized that even with the mutex, I really was just
implementing compare_and_swap (and I wrote it that way to make it more
obvious). So if we wanted to, it would be trivial to replace the
claim_delta function
On Wed, Aug 27, 2014 at 06:10:12PM -0400, David Turner wrote:
It looks like git fsck exits with 0 status even if there are some
errors. The only case where there's a non-zero exit code is if
verify_pack reports errors -- but not e.g. fsck_object_dir.
It will also bail non-zero with _certain_
On Sat, Aug 30, 2014 at 06:00:59PM +0200, René Scharfe wrote:
My only nit with patch 2: Petr Stodulka pstod...@redhat.com and Martin von
Gagern martin.vgag...@gmx.net should be mentioned as bug reporters.
Yeah, I agree with that. And actually, you should get a Reported-by:
on the first patch.
On Sat, Aug 30, 2014 at 11:58:35PM +0300, Max Kirillov wrote:
HEAD is not explicitly used as a starting commit for
calculating reachability, so if it's detached and reflogs
are disabled it may be pruned.
Eek, you're right. I think nobody noticed because the HEAD reflog
usually picks it up
On Fri, Sep 05, 2014 at 11:55:06AM +0200, Stefan Beller wrote:
struct remote {
+ struct hashmap_entry ent; /* must be first */
+
I stumbled about this comment /* must be first */
when reading the changelog.
Why does it need to be first?
Is it a common reason I'm just not aware
On Sat, Sep 06, 2014 at 03:57:39PM -0700, David Aguilar wrote:
This checks all .h files in the top directory. Would it be better
to check all files in LIB_H instead? Or even all .h files in the
tree (using git ls-files '*.h')? The latter might be difficult
because some of the files in
On Sun, Sep 07, 2014 at 06:05:13PM -0500, xmeng wrote:
The problem with git-blame is that it only reports the last author/commit
that changed the line, regardless of the magnitude of the change. Sometimes,
the last author may only change a tiny part of the code and should not be
blamed. I
On Tue, Sep 09, 2014 at 12:37:48PM -0700, Junio C Hamano wrote:
Harry Jeffery ha...@exec64.co.uk writes:
On 09/09/14 20:15, Junio C Hamano wrote:
Is this different from %n%-d?
Yes. %n%-d will place the newline before the expansion, not after.
Maybe %[-+ ] needs to be rethought,
On Tue, Sep 09, 2014 at 03:03:33PM -0700, Junio C Hamano wrote:
From: Jeff King p...@peff.net
Date: Fri, 29 Aug 2014 16:31:46 -0400
Upon finding a corrupt loose object, we forgot to note the error to
signal it with the exit status of the entire process.
[jc: adjusted t1450 and added
On Mon, Sep 01, 2014 at 02:17:43PM -0400, David Turner wrote:
I don't think git fsck should return !0 in this case. Yes, it's an
inconsistency in the repo, but it's sometimes due to erroneous
conversions from another SCM or some other (non-standard) implementation
of the git client. I've
On Tue, Sep 09, 2014 at 02:26:22PM -0700, Junio C Hamano wrote:
* jk/command-line-config-empty-string (2014-08-05) 1 commit
(merged to 'next' on 2014-08-29 at 74f04af)
+ config: teach git -c to recognize an empty string
git -c section.var command and git -c section.var= command
should
On Tue, Sep 09, 2014 at 11:17:20PM +0100, Harry Jeffery wrote:
I definitely prefer your more general solution to my
bare-minimum-to-scratch-itch patch. I'd certainly be willing to take your
patch and expand upon it (pun unintended) once Junio has weighed in on your
suggestions.
Thanks. I am
On Tue, Sep 09, 2014 at 04:34:02PM -0400, Gerry Reno wrote:
Downloaded the git-2.1.0.tar.gz tarball.
Cannot build git 2.1.0:
Weird. It works fine for me on Debian unstable. What platform are you on?
cc -g -O2 -Wall -I. -DHAVE_ALLOCA_H -DHAVE_PATHS_H -DHAVE_DEV_TTY
On Sat, Sep 06, 2014 at 09:50:33AM +0200, Michael Haggerty wrote:
If rename() fails, call rollback_lock_file() to delete the lock file
(in case it is still present) and reset the filename field to the
empty string so that the lockfile object is left in a valid state.
Unlike the previous
On Sat, Sep 06, 2014 at 09:50:14AM +0200, Michael Haggerty wrote:
Sorry for the long delay since v3. This version mostly cleans up a
couple more places where the lockfile object was left in an
ill-defined state. Thanks to Johannes Sixt and Torsten Bögershausen
for their review of v3.
I
-off-by: Jeff King p...@peff.net
---
Obviously that repo is ridiculous (but a sad reality for me).
However, I think the benefits extend to smaller files, too. And it's
pretty easy to do (and I actually think the resulting write_packed_entry
is a lot easier to read, as well as lifting some arbitrary
the reflogs will hit D/F conflicts in the
filesystem. To get a true test, we must turn off reflogs
(but we don't want to do so for the entire script, because
the point of turning them on was to cover some other cases).
Signed-off-by: Jeff King p...@peff.net
---
The diff's a bit hard to read, because
On Wed, Sep 10, 2014 at 05:25:36PM +0700, Duy Nguyen wrote:
On Wed, Sep 10, 2014 at 3:13 PM, Jeff King p...@peff.net wrote:
I was running pack-refs on a repository with a very large number of
loose refs (about 1.8 million). Needless to say, this ran very slowly
and thrashed the disk
the reflogs will hit D/F conflicts in the
filesystem. To get a true test, we must turn off reflogs
(but we don't want to do so for the entire script, because
the point of turning them on was to cover some other cases).
Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Jeff King p
On Wed, Sep 10, 2014 at 01:21:27PM +0200, Michael Haggerty wrote:
+ if (fclose(out))
+ die_errno(write error);
+ packed_ref_cache-lock-fd = -1;
It might be a minuscule bit safer to set `lock-fd = -1` *before*
calling `fclose()`.
Yeah, I considered that. The worst case is
On Wed, Sep 10, 2014 at 09:51:03AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Yes, we don't let normal fetchers see these repos. They're only for
holding shared objects and the ref tips to keep them reachable.
Are these individual refs have relations to the real world
On Wed, Sep 10, 2014 at 07:32:17AM -0700, Ronnie Sahlberg wrote:
Even better could be to build an iovec for all the data and use writev() ?
(now without gmail adding formatting)
I'm not sure that would make anything easier. We're literally
sprintf-ing (and calling sha1_to_hex) into a buffer so
On Tue, Sep 09, 2014 at 05:49:06PM +0200, Christian Couder wrote:
Christian mentioned that he talked to some GitHub folks at LinuxCon.
Those folks have also started thinking about things. :)
Things are still very tentative at this point, but I think they are
considering something like
On Wed, Sep 10, 2014 at 03:21:39PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
...
Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Jeff King p...@peff.net
---
Sorry for the quick v2; Michael and I crossed emails off-list, and I
missed some of his
On Thu, Sep 11, 2014 at 10:07:28AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
This has a fairly straightforward conflict with the ref-transaction
stuff in pu. The oldrefname parameter to is_refname_available became a
list of items;
Hmph, the trouble I had while
On Fri, Sep 12, 2014 at 07:16:26AM +0530, Stephen Smith wrote:
Is there a way to get a log of first parent commits and with each
commit a entry a list of the files that were changed?
How about:
git log --first-parent -m --name-only
The --first-parent restricts the traversal. The -m tells
On Thu, Sep 11, 2014 at 04:35:33PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Here is the patch I wrote, for reference (I also think breaking the
matches function into a series of conditionals, as you showed, is way
more readable):
OK, while reviewing the today's
this by using for_each_rawref and noting the error ourselves.
In addition to adding tests for this case, we add tests for
all types of missing-object links (all of which worked, but
which we were not testing).
Signed-off-by: Jeff King p...@peff.net
---
Just below here we check that refs/heads
[+cc mhagger for packed-refs wisdom]
On Thu, Sep 11, 2014 at 11:38:30PM -0400, Jeff King wrote:
Fsck tries hard to detect missing objects, and will complain
(and exit non-zero) about any inter-object links that are
missing. However, it will not exit non-zero for any missing
ref tips, meaning
On Fri, Sep 12, 2014 at 12:29:39AM -0400, Jeff King wrote:
Dropping curate_packed_ref_fn (as below) fixes the test above. And
miraculously does not even seem to conflict with ref patches in pu. :)
Of course I spoke too soon. The patch I sent is actually based on pu. It
is easy to make
On Wed, Sep 10, 2014 at 10:19:21AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Something like the patch below might work, but I didn't test it very
thoroughly (and note the comments, which might need dealing with). Maybe
it would make a sensible base for Harry to build
801 - 900 of 13736 matches
Mail list logo
