Am 10/24/2013 7:25, schrieb Duy Nguyen:
On Thu, Oct 24, 2013 at 11:11 AM, Nasser Grainawi nas...@codeaurora.org
wrote:
It is not clear to me how you envision to make it work.
I don't have the source code.
Now you do:
On 10/23/2013 08:36 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
git fetch was being used with contrived refspecs to create tags and
remote-tracking branches in test repositories in preparation for the
actual tests. This is obscure and also makes one wonder
On 10/23/2013 08:43 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Subject: Re: [PATCH 04/15] api-remote.txt: correct section struct refspect
refspect???
Thanks for catching the typo.
* Replace reference to function parse_ref_spec() with references to
On 10/23/2013 08:45 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Rename refs - refspecs and ref_count - refspec_count to
reduce confusion, because they describe an array of struct refspec,
as opposed to the struct ref objects that are also used in this
function.
Duy Nguyen pclo...@gmail.com wrote:
... it's not easy to determine ambiguity here, especially when the
repo finding code does not know anything about bar/barz.c (is it
a pathname or an argument to an option?).
IOW, the code that finds the repository is called too early?
One way to solve that
On Thu, 24 Oct 2013 02:57:15 +, Karsten Blees wrote:
...
The latter. I don't know about 'broader', but I'll try to summarize _my_
world view:
(1) Audience matters
For actual users, we need an accurate model that supports a variety of use
cases without falling apart. IMO, a working
The extra semi-colon is harmless, since we really do want
the while loop to do nothing. But it does trigger a warning
from clang.
Signed-off-by: Jeff King p...@peff.net
---
date.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/date.c b/date.c
index 29f1540..83b4166 100644
In shorten_unambiguous_ref, we build and cache a reverse-map of the
rev-parse rules like this:
static char **scanf_fmts;
static int nr_rules;
if (!nr_rules) {
for (; ref_rev_parse_rules[nr_rules]; nr_rules++)
... generate scanf_fmts ...
}
where
If you ask for-each-ref to print each ref and its object,
like:
git for-each-ref --format='%(objectname) %(refname)'
this should involve little more work than looking at the ref
files (and packed-refs) themselves. However, for-each-ref
will actually load each object from disk just to print its
This is a repost of the series here:
http://thread.gmane.org/gmane.comp.version-control.git/235735/focus=235826
(the original was a single patch, followed by a 5-patch series, which
I've combined here). It's mostly a cleanup, since parse_commit will only
fail in corrupted repos, but I did run
The parse_commit function will check whether it was passed a
NULL commit pointer, and if so, return an error. There is no
need for callers to check this separately.
Signed-off-by: Jeff King p...@peff.net
---
builtin/branch.c | 2 +-
builtin/commit.c | 4 ++--
commit.c | 2 +-
We currently call parse_commit and then assume we can
dereference the resulting tree struct field. If parsing
failed, however, that field is NULL and we end up
segfaulting.
Instead of a segfault, let's print an error message and die
a little more gracefully.
Note that this should never happen in
The parse_commit function will check the parsed flag of
the object and do nothing if it is set. There is no need
for callers to check the flag themselves, and doing so only
clutters the code.
Signed-off-by: Jeff King p...@peff.net
---
builtin/blame.c | 3 +--
builtin/name-rev.c| 3 +--
Many calls to parse_commit detect errors and die. In some
cases, the custom error messages are more useful than what
parse_commit_or_die could produce, because they give some
context, like which ref the commit came from. Some, however,
just say invalid commit. Let's convert the latter to use
Some unchecked calls to parse_commit should obviously die on
error, because their next step is to start looking at the
parsed fields, which will cause a segfault. These are
obvious candidates for parse_commit_or_die, which will be a
strict improvement in behavior.
Signed-off-by: Jeff King
If we move away from a detached HEAD that has broken or
corrupted commits, we might die in two places:
1. Printing the old HEAD was... message.
2. Printing the list of orphaned commits.
In both cases, we ignore the return value of parse_commit
and feed the resulting commit to the
That said, I don't think that --change-id option that the user must not
forget to use is any better than a hook that the user must not forget to
install.
Having a --change-id option, to my mind, simplifies use of the patch
workflow as it does not require downloading, copying and setting
I believe I've stumbled across an inconsistency in how git commit-tree
reads messages from stdin. I would expect the behavior of these two
commands to be identical, and that neither would actually change any
commits:
git filter-branch --commit-filter 'git commit-tree $@'
git
On Thursday, October 24, 2013 02:11:05 PM james.mo...@gitblit.com wrote:
That said, I don't think that --change-id option that the user must not
forget to use is any better than a hook that the user must not forget to
install.
I'm a bit paranoid. (e.g. I do all my development in a virtual
On Thu, Oct 24, 2013 at 7:11 PM, james.mo...@gitblit.com wrote:
That said, I don't think that --change-id option that the user must not
forget to use is any better than a hook that the user must not forget to
install.
Having a --change-id option, to my mind, simplifies use of the patch
On Thu, Oct 24, 2013 at 2:49 PM, Perry Hutchison per...@pluto.rain.com wrote:
Duy Nguyen pclo...@gmail.com wrote:
... it's not easy to determine ambiguity here, especially when the
repo finding code does not know anything about bar/barz.c (is it
a pathname or an argument to an option?).
We are passed a void * and write it out without ever
touching it; let's indicate that by using const.
Signed-off-by: Jeff King p...@peff.net
---
csum-file.c | 6 +++---
csum-file.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/csum-file.c b/csum-file.c
index
This series implements JGit-style pack bitmaps to speed up fetching and
cloning. For example, here is a simulation of the server side of a clone
of a fully-packed kernel repo (measuring actual clones is harder,
because the client does a lot of work on resolving deltas):
[before]
$ time git
From: Vicent Marti tan...@gmail.com
Allow users to efficiently lookup consecutive entries that are expected
to be found on the same revindex by exporting `find_revindex_position`:
this function takes a pointer to revindex itself, instead of looking up
the proper revindex for a given packfile on
From: Vicent Marti tan...@gmail.com
The hash table that stores the packing list for a given `pack-objects`
run was tightly coupled to the pack-objects code.
In this commit, we refactor the hash table and the underlying storage
array into a `packing_data` struct. The functionality for accessing
From: Vicent Marti tan...@gmail.com
As the pack-objects system grows beyond the single
pack-objects.c file, more parts (like the soon-to-exist
bitmap code) will need to compute hashes for matching
deltas. Factor out name_hash to make it available to other
files.
Signed-off-by: Vicent Marti
From: Vicent Marti tan...@gmail.com
This commit enables users of `struct rev_info` to peform custom limiting
during a revision walk (i.e. `get_revision`).
If the field `include_check` has been set to a callback, this callback
will be issued once for each commit before it is added to the pending
From: Vicent Marti tan...@gmail.com
The `git_open_noatime` helper can be of general interest for other
consumers of git's different on-disk formats.
Signed-off-by: Vicent Marti tan...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
cache.h | 1 +
sha1_file.c | 4 +---
2 files changed,
From: Vicent Marti tan...@gmail.com
The POSIX standard doesn't currently define a `nothll`/`htonll`
function pair to perform network-to-host and host-to-network
swaps of 64-bit data. These 64-bit swaps are necessary for the on-disk
storage of EWAH bitmaps if they are not in native byte order.
From: Vicent Marti tan...@gmail.com
EWAH is a word-aligned compressed variant of a bitset (i.e. a data
structure that acts as a 0-indexed boolean array for many entries).
It uses a 64-bit run-length encoding (RLE) compression scheme,
trading some compression for better processing speed.
The
From: Vicent Marti tan...@gmail.com
In this patch, we use the bitmap API to perform the `Counting Objects`
phase in pack-objects, rather than a traditional walk through the object
graph. For a reasonably-packed large repo, the time to fetch and clone
is often dominated by the full-object revision
From: Vicent Marti tan...@gmail.com
This is the technical documentation for the JGit-compatible Bitmap v1
on-disk format.
Signed-off-by: Vicent Marti tan...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
Documentation/technical/bitmap-format.txt | 131 ++
1
From: Vicent Marti tan...@gmail.com
This commit extends more the functionality of `pack-objects` by allowing
it to write out a `.bitmap` index next to any written packs, together
with the `.idx` index that currently gets written.
If bitmap writing is enabled for a given repository (either by
Hi!
I added an arbitrary upstream remote thinking that I could just
git diff the upstream remote's master. Turns out I needed to run git
pull --all in order to be able to diff the file (I forgot that step).
Could this error message be improved for interactive commands by
first checking to
We have a static array of extensions, but hardcode the size
of the array in our loops. Let's pull out this magic number,
which will make it easier to change.
Signed-off-by: Jeff King p...@peff.net
---
builtin/repack.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
This is slightly more verbose, but will let us annotate the
extensions with further options in future commits.
Signed-off-by: Jeff King p...@peff.net
---
builtin/repack.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
We ask pack-objects to pack to a set of temporary files, and
then rename them into place. Some files that pack-objects
creates may be optional (like a .bitmap file), in which case
we would not want to call rename(). We already call stat()
and make the chmod optional if the file cannot be accessed.
Now that we can read and write bitmaps, we can exercise them
with some basic functionality tests. These tests aren't
particularly useful for seeing the benefit, as the test
repo is too small for it to make a difference. However, we
can at least check that using bitmaps does not break anything.
From: Vicent Marti tan...@gmail.com
Since `pack-objects` will write a `.bitmap` file next to the `.pack` and
`.idx` files, this commit teaches `git-repack` to consider the new
bitmap indexes (if they exist) when performing repack operations.
This implies moving old bitmap indexes out of the way
From: Vicent Marti tan...@gmail.com
When we use pack bitmaps rather than walking the object
graph, we end up with the list of objects to include in the
packfile, but we do not know the path at which any tree or
blob objects would be found.
In a recently packed repository, this is fine. A fetch
From: Vicent Marti tan...@gmail.com
The bitmap reachability index used to speed up the counting objects
phase during `pack-objects` can also be used to optimize a normal
rev-list if the only thing required are the SHA1s of the objects during
the list (i.e., not the path names at which trees and
From: Vicent Marti tan...@gmail.com
A bitmap index is a `.bitmap` file that can be found inside
`$GIT_DIR/objects/pack/`, next to its corresponding packfile, and
contains precalculated reachability information for selected commits.
The full specification of the format for these bitmap indexes can
Martin von Zweigbergk martinv...@gmail.com writes:
I think
git merge-base HEAD $(git rev-list -g $upstream_name)
is roughly correct and hopefully fast enough. That can lead to too
long a command line, so I was planning on teaching merge-base a
--stdin option, but never got around to it.
The first one is a clean-up of the code to parse command line
options to git merge-base. Options such as --independent,
--is-ancestor and --octopus are mutually exclusive and it is
better expressed in terms of the recently introduced OPT_CMDMODE.
The second one implements the entire logic of the
The --octopus, --independent and --is-ancestor are mutually
exclusive command modes (in addition to not giving any of these
options), so represent them as such using the recent OPT_CMDMODE
facility available since 11588263 (parse-options: add OPT_CMDMODE(),
2013-07-30), which is in
The git pull --rebase command computes the fork point of the
branch being rebased using the reflog entries of the base branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the base branch has been
rewound and rebuilt. For example, if
Jeff King p...@peff.net writes:
That would also provide people who do not like the change of default an
escape hatch to keep the current behavior. And I do not think scripted
use will be inconvenienced; they will already have to use . or :/ to
be explicit (if they care) since the behavior is
Duy Nguyen pclo...@gmail.com writes:
On Thu, Oct 24, 2013 at 12:52 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
The strcpy call in open_output_fd() implies that the output buffer
must be at least 25 chars long.
Hmph, where does that 25 come
Michael Haggerty mhag...@alum.mit.edu writes:
As long as you have checked that our local 'master' should be at the
same commit as the origin's 'master' at this point, I think this
change is OK.
It doesn't matter what the reference points at; the only point of these
tests is to check whether
Johannes Sixt j.s...@viscovery.net writes:
Am 10/24/2013 7:25, schrieb Duy Nguyen:
On Thu, Oct 24, 2013 at 11:11 AM, Nasser Grainawi nas...@codeaurora.org
wrote:
It is not clear to me how you envision to make it work.
I don't have the source code.
Now you do:
Commit 1bbcc224 (http: refactor options to http_get_*, 28-09-2013)
changed the type of final 'options' argument of the http_get_file()
function from an int to an 'struct http_get_options' pointer.
However, it neglected to update the (single) call site. Since this
call was passing '0' to that
Jeff King p...@peff.net writes:
A similar series has been running on github.com for the past couple of
months, though not every repository has had bitmaps turned on (but some
very busy ones have). We've hopefully squeezed out all of the bugs and
corner cases over that time. However, I did
On Mon, Oct 21, 2013 at 10:40:22PM -0700, Martin von Zweigbergk wrote:
On Wed, Oct 16, 2013 at 11:53 AM, John Keeping j...@keeping.me.uk wrote:
Commit 15a147e (rebase: use @{upstream} if no upstream specified,
2011-02-09) says:
Make it default to 'git rebase @{upstream}'. That is
Michael Haggerty mhag...@alum.mit.edu writes:
Previously, fetch's --tags option was considered equivalent to
specifying the refspec refs/tags/*:refs/tags/* on the command line;
in particular, it caused the remote.name.refspec configuration to be
ignored.
But it is not very useful to fetch
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
The first one is a clean-up of the code to parse command line
options to git merge-base. Options such as --independent,
--is-ancestor and --octopus are mutually exclusive and it is
better expressed in terms of the recently
Ramsay Jones wrote:
Commit 1bbcc224 (http: refactor options to http_get_*, 28-09-2013)
changed the type of final 'options' argument of the http_get_file()
function from an int to an 'struct http_get_options' pointer.
However, it neglected to update the (single) call site. Since this
call was
On Thu, Oct 24, 2013 at 3:11 PM, Junio C Hamano gits...@pobox.com wrote:
diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
index f80bba8..3a1abee 100755
--- a/t/t6010-merge-base.sh
+++ b/t/t6010-merge-base.sh
@@ -230,4 +230,31 @@ test_expect_success 'criss-cross merge-base for
Michael Haggerty mhag...@alum.mit.edu writes:
...
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Everything in the proposed log message made sense to me.
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d4d93c9..83c1700 100644
--- a/Documentation/config.txt
+++
John Keeping j...@keeping.me.uk writes:
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
The first one is a clean-up of the code to parse command line
options to git merge-base. Options such as --independent,
--is-ancestor and --octopus are mutually exclusive and it is
better
I finished reading thru the remainder and all looked good (again
except minor nits I sent reviews for separately).
Thanks, will queue.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Oct 24, 2013 at 3:11 PM, Junio C Hamano gits...@pobox.com wrote:
diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
index f80bba8..3a1abee 100755
--- a/t/t6010-merge-base.sh
+++ b/t/t6010-merge-base.sh
@@ -230,4 +230,31 @@
On Thu, Oct 24, 2013 at 02:20:29PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
The first one is a clean-up of the code to parse command line
options to git merge-base. Options such as --independent,
Hello,
I think file permissions are really important for source code as well.
For example, in web development, you want configuration files to be
read only; specially if you're deploying with git.
Also, you would want some executable file to not be writable ; but
executable by world.
On Thu, Oct 24, 2013 at 10:31:35PM +0100, John Keeping wrote:
On Thu, Oct 24, 2013 at 02:20:29PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano wrote:
The first one is a clean-up of the code to parse command
On Thu, Oct 24, 2013 at 5:26 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Oct 24, 2013 at 3:11 PM, Junio C Hamano gits...@pobox.com wrote:
diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
index f80bba8..3a1abee 100755
---
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 24, 2013 at 10:40:07PM +0100, John Keeping wrote:
On Thu, Oct 24, 2013 at 10:31:35PM +0100, John Keeping wrote:
On Thu, Oct 24, 2013 at 02:20:29PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Thu, Oct 24, 2013 at 12:11:22PM -0700, Junio C Hamano
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Oct 24, 2013 at 5:26 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Oct 24, 2013 at 3:11 PM, Junio C Hamano gits...@pobox.com wrote:
diff --git a/t/t6010-merge-base.sh
The git pull --rebase command computes the fork point of the
branch being rebased using the reflog entries of the base branch
(typically a remote-tracking branch) the branch's work was based on,
in order to cope with the case in which the base branch has been
rewound and rebuilt. For example, if
Renich Bon Ciric ren...@woralelandia.com writes:
I think file permissions are really important for source code as well.
For example, in web development, you want configuration files to be
read only; specially if you're deploying with git.
That is not _source code_; you are talking about
Hi,
I noticed that reset -p HEAD is inconsistent with checkout -p HEAD.
When running checkout -p you are asked to discard hunks from the index
and worktree, but when running reset -p you are asked to apply hunks
to the index. It would make more sense if reset -p asked to discard
(reversed) hunks
Some more info: It used to work as intended. Using a bisect shows it
has been broken by commit 166ec2e9.
Kinds regards,
Maarten de Vries
On 25 October 2013 01:05, Maarten de Vries maar...@de-vri.es wrote:
Hi,
I noticed that reset -p HEAD is inconsistent with checkout -p HEAD.
When running
Jeff King p...@peff.net writes:
From: Vicent Marti tan...@gmail.com
EWAH is a word-aligned compressed variant of a bitset (i.e. a data
structure that acts as a 0-indexed boolean array for many entries).
I think I've already pointed out some when the original series was
posted, but this does
On Fri, Oct 25, 2013 at 2:49 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Thu, Oct 24, 2013 at 12:52 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
The strcpy call in open_output_fd() implies that the output
On Fri, Oct 25, 2013 at 1:03 AM, Jeff King p...@peff.net wrote:
diff --git a/Documentation/technical/bitmap-format.txt
b/Documentation/technical/bitmap-format.txt
new file mode 100644
index 000..c686dd1
--- /dev/null
+++ b/Documentation/technical/bitmap-format.txt
@@ -0,0 +1,131 @@
On Fri, Oct 25, 2013 at 1:06 AM, Jeff King p...@peff.net wrote:
From: Vicent Marti tan...@gmail.com
This commit extends more the functionality of `pack-objects` by allowing
it to write out a `.bitmap` index next to any written packs, together
with the `.idx` index that currently gets written.
On Thu, Oct 24, 2013 at 12:40 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
That would also provide people who do not like the change of default an
escape hatch to keep the current behavior. And I do not think scripted
use will be inconvenienced; they will
John Keeping j...@keeping.me.uk writes:
To clarify: the particular commit in the calls above happens to be the
oldest entry in the reflog, if I pick a newer entry then it works.
It seems that for_each_reflog_ent isn't returning the oldest entry;
revs.nr is 62 whereas git rev-list -g
This is only to tentatively work-around the compilation breakages;
the fixes need to be split into the respective patches that
introduce breakages when the series is rerolled (the one I sent for
pack-bitmap.c separately is also included in this message).
Thanks.
ewah/ewah_bitmap.c | 22
On Thu, Oct 24, 2013 at 9:46 AM, Duy Nguyen pclo...@gmail.com wrote:
On Thu, Oct 24, 2013 at 2:49 PM, Perry Hutchison per...@pluto.rain.com
wrote:
Duy Nguyen pclo...@gmail.com wrote:
... it's not easy to determine ambiguity here, especially when the
repo finding code does not know anything
On Thu, Oct 24, 2013 at 04:34:48PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
From: Vicent Marti tan...@gmail.com
EWAH is a word-aligned compressed variant of a bitset (i.e. a data
structure that acts as a 0-indexed boolean array for many entries).
I think I've
[+cc spearce; sorry, I really should have cc'd the whole series to you
in the first place]
On Fri, Oct 25, 2013 at 08:16:18AM +0700, Nguyen Thai Ngoc Duy wrote:
+ - A header appears at the beginning:
+
+ 4-byte signature: {'B', 'I', 'T', 'M'}
+
+
On Fri, Oct 25, 2013 at 08:21:12AM +0700, Nguyen Thai Ngoc Duy wrote:
If bitmap writing is enabled for a given repository (either by calling
`pack-objects` with the `--write-bitmap-index` flag or by having
`pack.writebitmaps` set to `true` in the config) and pack-objects is
writing a
On Fri, Oct 25, 2013 at 10:21 AM, Jeff King p...@peff.net wrote:
But if you want to simply add extra
data that would be ignored by an existing implementation, it would be OK
to add the data and mark it with a flag:
+ 2-byte flags (network byte order)
+
+
Maarten de Vries maar...@de-vri.es writes:
Some more info: It used to work as intended. Using a bisect shows it
has been broken by commit 166ec2e9.
Thanks.
A knee-jerk change without thinking what side-effect it has for you
to try out.
builtin/reset.c | 5 -
1 file changed, 4
There seems to be a bad interaction with --literal-pathspecs and the
pathspec magic that is in master. Here's an example:
[setup]
$ git init
$ echo content ':(foo)bar'
$ git add . git commit -m foo
[with git v1.8.4]
$ git blame ':(foo)bar'
^6b07eb4 (Jeff King 2013-10-24 22:59:02
On Thu, Oct 24, 2013 at 11:49:47PM -0400, Jeff King wrote:
We get another change with a16bf9d (pathspec: make --literal-pathspecs
disable pathspec magic, 2013-07-14), which I would think would fix
things, but doesn't.
$ git blame ':(foo)bar'
fatal: Invalid pathspec magic 'foo' in
On Fri, Oct 25, 2013 at 10:49 AM, Jeff King p...@peff.net wrote:
$ git --literal-pathspecs blame ':(foo)bar'
fatal: :(foo)bar: pathspec magic not supported by this command: 'literal'
The first one remains good, but the second one is still broken. I
haven't dug further yet, but I thought
On Fri, Oct 25, 2013 at 11:16:08AM +0700, Nguyen Thai Ngoc Duy wrote:
All of the GUARD_PATHSPEC calls indicate that everybody understands
PATHSPEC_LITERAL. It is not technically true that git-blame understands
the literal pathspec magic:
$ git blame -- ':(literal)revision.c'
On Thu, Oct 24, 2013 at 08:40:13PM -0700, Junio C Hamano wrote:
Maarten de Vries maar...@de-vri.es writes:
Some more info: It used to work as intended. Using a bisect shows it
has been broken by commit 166ec2e9.
Thanks.
A knee-jerk change without thinking what side-effect it has for
Karsten Blees wrote:
(2) Index
An index, as in a library, maps almost perfectly to what the git index is
_and_ what we do with it.
Not really. An index in the context of a library, and in any other context, is
a tool that indicates where something is, in order to find it quickly.
That is
On Thu, Oct 24, 2013 at 12:40:44PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
That would also provide people who do not like the change of default an
escape hatch to keep the current behavior. And I do not think scripted
use will be inconvenienced; they will already
On Fri, Oct 25, 2013 at 11:37 AM, Jeff King p...@peff.net wrote:
On Thu, Oct 24, 2013 at 12:40:44PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
That would also provide people who do not like the change of default an
escape hatch to keep the current behavior. And I do not
Sorry about the regression and thanks for report and fixes.
On Thu, Oct 24, 2013 at 9:24 PM, Jeff King p...@peff.net wrote:
On Thu, Oct 24, 2013 at 08:40:13PM -0700, Junio C Hamano wrote:
Maarten de Vries maar...@de-vri.es writes:
Some more info: It used to work as intended. Using a bisect
On Thu, Oct 24, 2013 at 01:59:15PM -0400, Jeff King wrote:
This series implements JGit-style pack bitmaps to speed up fetching and
cloning.
Here is a re-roll fixing the comments so far. I know that nobody is
likely to have had a chance to read through it carefully yet, but given
the compiler
We are passed a void * and write it out without ever
touching it; let's indicate that by using const.
Signed-off-by: Jeff King p...@peff.net
---
csum-file.c | 6 +++---
csum-file.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/csum-file.c b/csum-file.c
index
96 matches
Mail list logo
