On Thu, Sep 11, 2014 at 09:58:45PM -0700, Junio C Hamano wrote:
On Thu, Sep 11, 2014 at 9:29 PM, Jeff King p...@peff.net wrote:
[+cc mhagger for packed-refs wisdom]
If we only have a packed copy of refs/heads/master and it is broken,
then deleting any _other_ unrelated ref will cause
On Fri, Sep 12, 2014 at 04:21:09PM +0200, Michael Haggerty wrote:
But I still wonder how hard it would be to just remove lock_file structs
from the global list when they are committed or rolled back.
[...]
To make that change, we would have to remove entries from the list of
lock_file
On Sat, Sep 13, 2014 at 09:28:01AM +0200, René Scharfe wrote:
Call the functions behind git prune-packed and git update-server-info
directly instead of using run_command(). This is shorter, easier and
quicker.
It can also introduce bugs, since a lot of git code assumes it is
running in a
We form all of our directories in a strbuf, but never release it.
Signed-off-by: Jeff King p...@peff.net
---
builtin/prune-packed.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/prune-packed.c b/builtin/prune-packed.c
index 6879468..d430731 100644
--- a/builtin/prune-packed.c
+++ b
other), this
patch factors out the improved error-checking version into a
helper function.
Signed-off-by: Jeff King p...@peff.net
---
I guess point (b) may not apply on systems that have a really small
PATH_MAX that does not reflect what you can actually create in the
filesystem (Windows?). But I
We allocate pack information in a static global list but
never clean it up. This leaks memory, and means that calling
update_server_info twice will generate a buggy file (it will
have duplicate entries).
Signed-off-by: Jeff King p...@peff.net
---
server-info.c | 9 +
1 file changed, 9
On Sat, Sep 13, 2014 at 08:45:56AM -0700, Greg KH wrote:
On Sat, Sep 13, 2014 at 12:37:46PM +0300, Dan Carpenter wrote:
On Thu, Sep 11, 2014 at 10:59:42PM +0100, Mark Einon wrote:
From struct ce_stats; unicast_pkts_rcvd, unicast_pkts_xmtd,
multicast_pkts_xmtd, broadcast_pkts_rcvd and
on the MUA writing the file. We
cannot know for sure whether to unquote or not, so we leave
the line alone.
Signed-off-by: Jeff King p...@peff.net
---
I admit my arguments that it is not in use are a little flaky, and this
may just be me being lazy. Trying to match arbitrary From lines is
very hard
On Sat, Sep 13, 2014 at 10:57:14PM +, brian m. carlson wrote:
On Sat, Sep 13, 2014 at 05:25:05PM -0400, Jeff King wrote:
Thanks both of you for following up. I did confirm that git-send-email
does not add such quoting. From your findings above, I'd agree that it's
the list-archive
On Sat, Sep 13, 2014 at 05:55:49PM -0700, Junio C Hamano wrote:
On Sat, Sep 13, 2014 at 5:47 PM, Jeff King p...@peff.net wrote:
On Sat, Sep 13, 2014 at 10:57:14PM +, brian m. carlson wrote:
I wonder if git send-email should do what mutt does in this case, which
is use quoted
On Sat, Sep 13, 2014 at 09:01:20PM -0400, Jeff King wrote:
[1] We do use the mbox format in git, and AFAIK do not do any
From-quoting of this nature. I haven't tested, but I suspect that
certain format-patch output would be corrupted when reading back via
git am, let alone other
for specific clients. That's acceptable, as such errors
should be rare (e.g., clients sending buggy requests).
However, we also provide an escape hatch: if you want to see
these later messages, you can provide the --debug option
to keep stderr open.
Signed-off-by: Jeff King p...@peff.net
---
Documentation
On Fri, Sep 12, 2014 at 11:26:43AM -0300, Jonh Wendell wrote:
It will print just a + sign appended to the found tag, if there
are commits between the tag and the supplied commit.
It's useful when you just need a simple output to know if the
supplied commit is an exact match or not.
Seems
On Fri, Sep 12, 2014 at 11:26:44AM -0300, Jonh Wendell wrote:
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -54,6 +54,12 @@ OPTIONS
abbreviated object name, use n digits, or as many digits
as needed to form a unique object name. An n of 0
On Mon, Sep 15, 2014 at 11:39:12AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Since git update-server-info may be called automatically
as part of a push or a gc --auto, we should be robust
against two processes trying to update it simultaneously.
However, we currently
On Mon, Sep 15, 2014 at 11:56:16AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
It looks like we have a reasonably sane is_from_line() function. So at
least _we_ will not generally break on reading our own output, except in
some extreme circumstances (you'd have to come
On Mon, Sep 15, 2014 at 01:15:35PM -0700, Junio C Hamano wrote:
If we only want to skip ?From in pasted format-patch output, we
would want a rule in mailinfo that is tighter than is_from_line() in
mailsplit.
That is, something like this on top of your patch. Or is this a bit
too
On Mon, Sep 15, 2014 at 02:38:11PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+ if (!debug)
+ freopen(/dev/null, w, stderr);
I am getting this:
credential-cache--daemon.c:216:10: error: ignoring return value of
'freopen', declared with attribute
On Mon, Sep 15, 2014 at 07:34:03PM -0400, Dale R. Worley wrote:
I have an 11 GB repository. It passes git-fsck (though with a number
of dangling objects). But when I run git-gc on it, the file
refs/heads/master disappears.
That's the expected behavior. Gc runs git pack-refs, which puts an
. A reroll coming today when I find time.
-- 8 --
From: Jeff King p...@peff.net
Date: Sat, 13 Sep 2014 21:30:38 -0400
Subject: [PATCH] mailinfo: make From in-body header check more robust
[...]
This looks good to me. Thanks.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git
On Tue, Sep 16, 2014 at 10:01:11AM +0200, Christian Couder wrote:
On Mon, Sep 15, 2014 at 10:39 PM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder chrisc...@tuxfamily.org writes:
+/* Get the length of buf from its beginning until its last alphanumeric
character */
That
On Tue, Sep 16, 2014 at 02:43:43PM -0700, Junio C Hamano wrote:
+/* un-ignore and un-block SIGPIPE */
+void sanitize_signals(void)
+{
+ sigset_t unblock;
+
+ sigemptyset(unblock);
+ sigaddset(unblock, SIGPIPE);
+ sigprocmask(SIG_UNBLOCK, unblock, NULL);
+
On Mon, Sep 15, 2014 at 11:24:04AM -0700, Junio C Hamano wrote:
René Scharfe l@web.de writes:
The macro ALLOC_GROW manages several aspects of dynamic memory
allocations for arrays: It performs overprovisioning in order to avoid
reallocations in future calls, updates the allocation
On Tue, Sep 16, 2014 at 03:27:12PM -0700, Junio C Hamano wrote:
Johannes Sixt j...@kdbg.org writes:
I think this is a good move. Hooks are written by users, who sometimes
are not clueful enough.
Thanks for a sanity check. I do not think it is about cluefulness
in this particular case.
On Fri, Sep 19, 2014 at 09:39:45AM +0200, Scott Chacon wrote:
Currently if you try to merge notes, the notes code ensures that the
reference is under the 'refs/notes' namespace. In order to do any sort
of collaborative workflow, this doesn't work well as you can't easily
have local notes refs
On Mon, Sep 22, 2014 at 05:10:08PM -0400, Eric Sunshine wrote:
On Mon, Sep 22, 2014 at 1:41 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
The just-released Apple Xcode 6.0.1 has -Wstring-plus-int enabled by
default which complains about pointer
On Mon, Sep 22, 2014 at 11:26:14PM -0700, Junio C Hamano wrote:
On Mon, Sep 22, 2014 at 11:04 PM, Jeff King p...@peff.net wrote:
I don't mind silencing this one warning (even though I find it a little
ridiculous). I'm slightly concerned that more brain-damage may be coming
our way
On Tue, Sep 23, 2014 at 03:52:21AM -0400, Eric Sunshine wrote:
That is my reading from the warning text, too, but I have to wonder:
wouldn't that mean they should be warning about pointer + pointer, not
pointer + int?
'pointer + pointer' is not legal C, is it? What would the result
On Tue, Sep 23, 2014 at 04:49:55PM +0900, Chris Salzberg wrote:
I've found what looks like a bug wherein if you are using an ssh alias
for a git remote, and that remote has a dash in its name, and you
specify the target path as the name of the url itself, git complains
about refs not being
On Tue, Sep 23, 2014 at 04:20:55AM +1000, Steven Lawler wrote:
Cause:
[remote repo]
url = http://example.com/git/example.com?foo=bar
There is a question mark in the URL of the repo URL.
Is the question mark there because it is separating query parameters
from the path, or is ?foo=bar part
Doing so means that we do not actually get to see bogus
modes; they are converted into one of our known-good modes
by decode_tree_entry. We want to see the raw data so that we
can complain about it.
Signed-off-by: Jeff King p...@peff.net
---
As far as I can tell, fsck's mode-checking has been
On Sat, Sep 20, 2014 at 08:18:59PM +0200, Andreas Schwab wrote:
Stepan Kasal ka...@ucw.cz writes:
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 143a8ea..a911df0 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1423,4 +1423,30 @@ EOF
test_cmp expect actual
'
On Tue, Sep 23, 2014 at 07:47:11AM -0500, Robert Dailey wrote:
But if I type just 'make', I don't see how it will know where my ARM
toolchain is. I'll read the INSTALL file in the meantime.
It won't. If you are cross-compiling you'll have to specify CC and LD
manually, plus a host of other
On Tue, Sep 23, 2014 at 07:52:32AM -0500, Robert Dailey wrote:
On Tue, Sep 23, 2014 at 7:47 AM, Robert Dailey rcdailey.li...@gmail.com
wrote:
But if I type just 'make', I don't see how it will know where my ARM
toolchain is. I'll read the INSTALL file in the meantime.
Sorry for top post
[-cc Kirill, as his address seem out-of-date]
On Tue, Sep 23, 2014 at 04:23:43PM +, Edward Thomson wrote:
On Tue, Sep 23, 2014 at 11:47:51AM -0400, Jeff King wrote:
As far as I can tell, fsck's mode-checking has been totally broken
basically forever. Which makes me a little nervous
On Wed, Sep 24, 2014 at 03:26:22AM +0200, Daniel Brockman wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
Git does not invoke tar(1). It has its own tar (actually, pax)
implementation, so any options would have to be implemented in Git.
We'd probably want to make such a
On Thu, Sep 25, 2014 at 06:10:09PM +0200, Uwe Kleine-König wrote:
Commit logs as shown by git-log are usually indented by four spaces so
here it makes sense to do the same for commit notes.
However when using format-patch to create a patch for submission via
e-mail the commit log isn't
On Thu, Sep 25, 2014 at 08:48:31AM -0700, Joe Perches wrote:
On Thu, 2014-09-25 at 17:03 +0200, Greg Kroah-Hartman wrote:
In the future, please generate a git move diff, which makes it easier
to review, and prove that nothing really changed. It also helps if the
file is a bit different
On Sun, Sep 28, 2014 at 11:21:07PM +0100, Ben Walton wrote:
The askpass script that is created for use by the test suite should
use SHELL_PATH for its hash bang instead of /bin/sh. Commit 5a4352024
introduced the use of idioms not supported in some legacy /bin/sh
implementations.
Sounds
On Mon, Sep 29, 2014 at 08:02:07AM +0100, Ben Walton wrote:
The askpass script that is created for use by the test suite should
use SHELL_PATH for its hash bang instead of /bin/sh. Commit 5a4352024
introduced the use of idioms not supported in some legacy /bin/sh
implementations.
Use
On Tue, Sep 30, 2014 at 03:41:55PM +0200, Michael Haggerty wrote:
I didn't fix it because IMO the correct fix is to add a stdio-oriented
entry point to the lockfile API, and teach the lockfile code to handle
closing the FILE correctly when necessary.
I think so, too, after our discussion[1]
On Wed, Oct 01, 2014 at 11:43:21AM +0200, René Scharfe wrote:
If the first 18 bytes of the SHA1's of all entries are the same then
sha1_pos() dies and reports that the lower and upper limits of the
binary search were the same that this wasn't supposed to happen. This
is wrong because the
On Wed, Oct 01, 2014 at 01:10:12PM +0200, René Scharfe wrote:
I wonder if it is worth adding a test (you test only that not found
produces a negative index, but not which index). Like:
api-sha1-array.txt says about sha1_array_lookup: If not found, returns a
negative integer, and that's what
On Wed, Oct 01, 2014 at 01:14:47PM +0200, Michael Haggerty wrote:
I thought about adding second stdio-oriented entrance points analogous
to hold_lock_file_for_update(), hold_lock_file_for_append(), and
reopen_lock_file(), but it seemed simpler to add just the one new
function instead of three
On Wed, Oct 01, 2014 at 01:14:46PM +0200, Michael Haggerty wrote:
This series applies on top of the series Lockfile correctness and
refactoring (Junio's branch mh/lockfile).
There are already two callers that write to lockfiles using stdio. But
they currently need intimate knowledge of the
On Wed, Oct 01, 2014 at 10:11:04AM -0400, Eric Sunshine wrote:
+echo20() {
+ prefix=$1
+ shift
+ while test $# -gt 0
+ do
+ echo $prefix$1$1$1$1$1$1$1$1$1$1$1$1$1$1$1$1$1$1$1$1
Each caller of echo20() manually includes a space at the end of
On Wed, Oct 01, 2014 at 05:00:33PM +0200, René Scharfe wrote:
Helped-by: Jeff King p...@peff.net
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Rene Scharfe l@web.de
---
Added a test for looking up a non-existing entry in an array that
contains duplicates, as suggested
On Wed, Oct 01, 2014 at 06:15:46PM -0700, Jonathan Nieder wrote:
3) Warn when 'git config' is called with GIT_CONFIG set, explaining
that support will eventually be removed and that callers should
pass --file= instead.
4) Once we're confident there are no scripts in the wild
On Thu, Oct 02, 2014 at 10:22:50AM -0400, Dan Johnson wrote:
git show af00f4c39bcc8dc29ed8f59a47066d5993c279e4
fatal: bad object af00f4c39bcc8dc29ed8f59a47066d5993c279e4
git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4
error: no such remote ref
On Thu, Oct 02, 2014 at 12:29:14PM -0700, Junio C Hamano wrote:
Tanay Abhra tanay...@gmail.com writes:
(just this point quick)
1 The name of the variable, I could not decide between unset.variable
and config.unset, or may be some other name would be more appropriate.
I'd prefer to
, but
that is unlike our other for_each functions).
Signed-off-by: Jeff King p...@peff.net
---
cache.h | 2 +-
sha1_file.c | 12
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index 8206039..cd16e25 100644
--- a/cache.h
+++ b/cache.h
@@ -1143,7
At GitHub we've occasionally run across repos getting corrupted by trees
and blobs near the tip going missing. We do a lot of test merges
between branches and HEAD (this is what feeds the OK to merge button
on the web interface), and the objects are almost always related to
these merges. The
This is not a lot of code, but it's a logical construct that
should not need to be repeated (and we are about to add a
third repetition).
Signed-off-by: Jeff King p...@peff.net
---
object.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/object.c b/object.c
index
(but fails to free the name field of each
entry, potentially leaking memory).
Signed-off-by: Jeff King p...@peff.net
---
list-objects.c | 7 +--
object.c | 10 ++
object.h | 6 ++
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/list-objects.c b/list-objects.c
parsing the hex by using the hexval() helper, which
implicitly casts to unsigned (but note that we cannot
implement isxdigit in terms of hexval(), as it also casts
its return value to unsigned).
Signed-off-by: Jeff King p...@peff.net
---
git-compat-util.h | 2 +-
urlmatch.c| 8
2 files
.
Signed-off-by: Jeff King p...@peff.net
---
revision.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/revision.c b/revision.c
index e498b7c..01cc276 100644
--- a/revision.c
+++ b/revision.c
@@ -300,7 +300,7 @@ static struct commit *handle_commit(struct rev_info
the memory.
Signed-off-by: Jeff King p...@peff.net
---
reachable.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/reachable.c b/reachable.c
index 6f6835b..d99bd31 100644
--- a/reachable.c
+++ b/reachable.c
@@ -131,6 +131,8 @@ static void walk_commit_list(struct rev_info *revs
This is slightly more robust (checking ! test -f would not
notice a directory of the same name, though that is not
likely to happen here). It also makes debugging easier, as
the test script will output a message on failure.
Signed-off-by: Jeff King p...@peff.net
---
This patch is totally optional
For small outputs, we sometimes use:
test $(some_cmd) = something we expect
instead of a full test_cmp. The downside of this is that
when it fails, there is no output at all from the script.
Let's introduce a small helper to make tests easier to
debug.
Signed-off-by: Jeff King p...@peff.net
(but still pruned other directories!). This was
probably a bug; we do not want to process the file as
an object, but we should keep going otherwise.
Signed-off-by: Jeff King p...@peff.net
---
I admit the speedup in (1) almost certainly doesn't matter. It is real,
and I found out about it while
should at least be correct here).
Signed-off-by: Jeff King p...@peff.net
---
I think the on_disk_bytes is a little weird here, too. We count actual
disk-usage blocks for loose objects here, which makes sense. But we do
_not_ do so for packfiles, or for garbage files. Which seems kind of
inconsistent
This drops our line count considerably, and should make
things more readable by keeping the counting logic separate
from the traversal.
Signed-off-by: Jeff King p...@peff.net
---
builtin/count-objects.c | 101 ++--
1 file changed, 30 insertions(+), 71
We typically iterate over the reachable objects in a
repository by starting at the tips and walking the graph.
There's no easy way to iterate over all of the objects,
including unreachable ones. Let's provide a way of doing so.
Signed-off-by: Jeff King p...@peff.net
---
cache.h | 11
not
reflect the new prune code (and this can be seen by running
t6501 with a strategically placed repack).
Let's teach pack-objects similar logic.
Signed-off-by: Jeff King p...@peff.net
---
The test changes look big because of the indentation. View with -w for
a sane diff.
builtin/pack-objects.c | 38
the
optimization. Still, we can easily fix it while we are here.
Signed-off-by: Jeff King p...@peff.net
---
builtin/pack-objects.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index d391934..2fe2ab0 100644
, then follows up with a second traversal for recent
objects, skipping any that have already been marked.
Signed-off-by: Jeff King p...@peff.net
---
I put the mark-recent code into mark_reachable_objects here,
but it does not technically have to be there. It reuses the
same rev_info object (which
to implement freshening and simple checking by tweaking a
single parameter.
Signed-off-by: Jeff King p...@peff.net
---
sha1_file.c| 51 +++---
t/t6501-freshen-objects.sh | 27
2 files changed, 71 insertions(+), 7 deletions
On Fri, Oct 03, 2014 at 02:29:58PM -0700, Junio C Hamano wrote:
We can solve this by freshening objects that we avoid
writing by updating their mtime. The algorithm for doing so
is essentially the same as that of has_sha1_file. Therefore
we provide a new (static) interface
On Fri, Oct 03, 2014 at 02:47:57PM -0700, Junio C Hamano wrote:
Sorry but this part is beyond a simple panda brain.
I probably didn't explain it very well. I found it rather confusing to
reason about. Let's see if we can go through it together.
I can understand this
If we have an
On Fri, Oct 03, 2014 at 03:17:18PM -0700, Junio C Hamano wrote:
That's a bit verbose. We could hide it behind something like test_eq,
too, but it introduces several extra new processes.
What do you mean by extra new processes? Whether open coded in a
verbose way, or wrapped inside a
On Fri, Oct 03, 2014 at 03:19:29PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Prune has to walk $GIT_DIR/objects/?? in order to find the
set of loose objects to prune. Other parts of the code
(e.g., count-objects) want to do the same. Let's factor it
out
On Fri, Oct 03, 2014 at 02:47:57PM -0700, Junio C Hamano wrote:
With this patch applied, the system will not prune unreachable old
objects that are reachable from a recent object (the recent object
itself may or may not be reachable but that does not make any
difference). And that is
On Sat, Oct 04, 2014 at 12:55:13AM +0200, René Scharfe wrote:
-void foreach_alt_odb(alt_odb_fn fn, void *cb)
+int foreach_alt_odb(alt_odb_fn fn, void *cb)
{
struct alternate_object_database *ent;
+int r = 0;
prepare_alt_odb();
-for (ent = alt_odb_list; ent; ent =
On Sun, Oct 05, 2014 at 03:49:19PM -0700, Jonathan Nieder wrote:
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -81,14 +81,16 @@ static int parse_branch_color_slot(const char *var, int
ofs)
static int git_branch_config(const char *var, const char *value, void *cb)
{
+
On Sat, Oct 04, 2014 at 08:54:50PM +0200, René Scharfe wrote:
Continue where ae021d87 (use skip_prefix to avoid magic numbers) left off
and use skip_prefix() in more places for determining the lengths of prefix
strings to avoid using dependent constants and other indirect methods.
Thanks,
On Sat, Oct 04, 2014 at 03:22:10PM -0700, Junio C Hamano wrote:
This applied on top of 'maint' (which does have c40fdd01) makes the
test #9 (prune: do not prune detached HEAD with no reflog) fail.
I'll fix the bone-headed error returns that René noticed and double
check that they were the
On Tue, Oct 07, 2014 at 11:21:58AM -0700, Junio C Hamano wrote:
The fix you proposed below is along the same line, and looks good to me
(and grepping for 'var *+ *ofs' shows only the two sites you found, so
hopefully that is the last of it).
builtin/commit.c::parse_status_slot() has the
.
This is effectively a continuation of 9e1a5eb, which did the
same for parse_diff_color_slot. This patch covers all of the
remaining similar constructs.
Signed-off-by: Jeff King p...@peff.net
---
Actually, parse_decorate_color_config is slightly odd in that it takes
the variable and the slot_name after
On Tue, Oct 07, 2014 at 03:16:56PM -0400, Jeff King wrote:
Actually, parse_decorate_color_config is slightly odd in that it takes
the variable and the slot_name after this patch. That's because it
passes the full variable name to color_parse, which does still die() on
error. Perhaps it should
On Tue, Oct 07, 2014 at 10:29:59AM -0700, Junio C Hamano wrote:
test_eq () {
if test $1 != $2
then
printf %s $1 expect
printf %s $2 actual
test_cmp expect actual
fi
}
[...]
The above superficially looks nice; ! test_eq a b
On Tue, Oct 07, 2014 at 01:35:15PM -0700, Junio C Hamano wrote:
Yeah, if we are going to reduce it down to the above implementation,
intereseting things like test -f $frotz will become possible and
cmp-str stops making sense. It really is about We run test and
expect it to yield true.
On Wed, Oct 08, 2014 at 12:29:37AM +0300, Michael S. Tsirkin wrote:
If I understand it correctly, Michael is envisioning to implement
his git am -s art (I would recommend against reusing -s for this,
though. git am --trailer art is fine) and doing so by using
interpret-trailers as an
On Tue, Oct 07, 2014 at 06:29:00PM +0200, Michael Haggerty wrote:
I haven't read all of the old code, but if I understand correctly this
is your new algorithm:
1. Walk from all references etc., marking reachable objects.
2. Iterate over *all* objects, in no particular order, skipping the
On Tue, Oct 07, 2014 at 04:07:52PM +0200, Michael Haggerty wrote:
On 10/03/2014 10:29 PM, Jeff King wrote:
Prune has to walk $GIT_DIR/objects/?? in order to find the
set of loose objects to prune. Other parts of the code
(e.g., count-objects) want to do the same. Let's factor it
out
On Tue, Oct 07, 2014 at 01:25:54PM +0200, Michael Haggerty wrote:
+static void object_array_release_entry(struct object_array_entry *ent)
+{
+ if (ent-name != object_array_slopbuf)
+ free(ent-name);
+}
+
Would it be a little safer to set ent-name to NULL or to
On Wed, Oct 08, 2014 at 12:17:07AM +0200, Michael Haggerty wrote:
On 10/07/2014 11:53 PM, Junio C Hamano wrote:
Hmph, your 'test' in that name is a generic verb we check that...,
which I think aligns better with the other test_foo functions. When
I suggested 'test_verbose', 'test' in that
On Sun, Oct 05, 2014 at 09:42:49PM -0400, Jeff King wrote:
On Sat, Oct 04, 2014 at 03:22:10PM -0700, Junio C Hamano wrote:
This applied on top of 'maint' (which does have c40fdd01) makes the
test #9 (prune: do not prune detached HEAD with no reflog) fail.
I'll fix the bone-headed error
On Wed, Oct 08, 2014 at 10:40:03AM +0200, Michael Haggerty wrote:
The intent of this function is freeing memory, not clearing it for sane
reuse. I think I'd be more in favor of a comment clarifying that. It is
a static function used only internally by the object-array code.
I guess the
On Wed, Oct 08, 2014 at 12:49:54PM -0500, Derek Moore wrote:
The HTML for the git-log man page is being misrendered on the official site.
See the placehoders list under format:string in the PRETTY FORMATS
section.
Thanks for the report. This renders fine locally with asciidoc, but the
On Wed, Oct 08, 2014 at 08:46:10PM +, brian m. carlson wrote:
Neither the AsciiDoc nor the Asciidoctor documentation specify whether
the same number of delimiter characters must be used to end a block as
to begin it, although both sets of documentation show exactly matching
pairs.
On Wed, Oct 08, 2014 at 02:50:14PM +0530, Tanay Abhra wrote:
I think problem lies with show_stash() which just shows the
diff between working tree and the base tree, it ignores the
untracked files. A quick and dirty fix can be to just show
the diff between the untracked files and a NULL
On Thu, Oct 09, 2014 at 12:42:39PM -0500, Derek Moore wrote:
As far as I've tested it would seem only %N doesn't resolve inside of
$Format:$, until I maybe do unit tests for this to identify any
others.
Yes, %N is somewhat special in that the calling code needs to initialize
the notes tree
On Thu, Oct 09, 2014 at 11:19:36AM -0500, Derek Moore wrote:
PRETTY FORMATS' format:string documentation says, %ad: author date
(format respects --date= option), and similarly for %cd.
But git-archive does not support the --date= option for changing the
date format in $Format:%ad$ or
On Thu, Oct 09, 2014 at 03:24:28PM -0400, Jeff King wrote:
On Thu, Oct 09, 2014 at 11:19:36AM -0500, Derek Moore wrote:
PRETTY FORMATS' format:string documentation says, %ad: author date
(format respects --date= option), and similarly for %cd.
But git-archive does not support
On Thu, Oct 09, 2014 at 12:53:33PM -0500, Derek Moore wrote:
Following the INSTALL doc, I was building git with:
make prefix=/usr/local all doc info
I wonder if it is actually sane to recommend building info for
newcomers in INSTALL. I do not know if many of the list regulars do so
(I
This is slightly more robust (checking ! test -f would not
notice a directory of the same name, though that is not
likely to happen here). It also makes debugging easier, as
the test script will output a message on failure.
Signed-off-by: Jeff King p...@peff.net
---
t/t5304-prune.sh | 46
These patches are pulled out of the prune-mtime series I posted
earlier[1]. The discussion veered off and there's no reason that the two
topics need to be part of the same series.
The first patch is the same cleanup as before.
The second one uses Michael's suggested verbose function, like:
$
For small outputs, we sometimes use:
test $(some_cmd) = something we expect
instead of a full test_cmp. The downside of this is that
when it fails, there is no output at all from the script.
Let's introduce a small helper to make tests easier to
debug.
Signed-off-by: Jeff King p...@peff.net
not use test_cleanup at all), as it creates unnecessary
noise in the set -x output.
Signed-off-by: Jeff King p...@peff.net
---
Having finally figured out how to drop the set +x from the output, I
have noticed that I kind of liked the test_eval_ret=$? part of the
trace (which is now gone, too), because
On Fri, Oct 10, 2014 at 02:13:55AM -0400, Jeff King wrote:
Having finally figured out how to drop the set +x from the output, I
have noticed that I kind of liked the test_eval_ret=$? part of the
trace (which is now gone, too), because it pretty explicitly tells you
that the last traced
901 - 1000 of 13736 matches
Mail list logo
