From: Johannes Sixt
The recent 5de460a2 (Refactor per-line part of getblobdiffline and its
support) introduced blobdiffmaybeseehere, and accidentally forgot the '$'
to access the parameter as a TCL variable. This resulted in a failing
"Back" button with the error
can't use non-numeric string as
Tom Miller writes:
> The commit below should be the same patch he tested. The test was added
> by him, and I made it part of this commit. Did I do this wrong?
No, no, no. All my questions were true questions, not complaints
veiled as rhetorical questions. Thanks for many pointers for
clarifica
Michael Haggerty :
> If you haven't tried cvs2git yet, please start it up somewhere in the
> background. It might take a while but it should have no trouble with
> your repos, and then you can compare the tools based on experience
> rather than speculation.
That would be a good thing.
Michael, i
On Tue, Dec 17, 2013 at 04:36:06PM -0800, Junio C Hamano wrote:
> I think all we need to do, in addition to what the existing code
> does, is to make sure that we _parse_ the object that the tag points
> at, to avoid this problem. Something like this, perhaps, instead?
Yeah, that's the clean fix
On Wed, Dec 18, 2013 at 3:54 PM, Junio C Hamano wrote:
> Tom Miller writes:
>
>> When a branchname DF conflict occurs during a fetch,
>
> You may have started with a specific case in which you want to
> change the behaviour of current Git, so it may be clear what you
> meant by "branchname DF con
On Wed, Dec 18, 2013 at 3:47 PM, Junio C Hamano wrote:
> Tom Miller writes:
>
>> In order to fix branchname DF conflicts during `fetch --prune`, the way
>> the header is output to the screen needs to be refactored. Here is an
>> exmaple of the output with the line in question denoted by '>':
>>
>
On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty wrote:
> A correct incremental converter could be done (as long as the CVS users
> don't literally change history retroactively) but it would be a lot of work.
Although I agree with that sentence as it is stated, I also believe
that the parenthes
On Thu, Dec 19, 2013 at 3:57 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse wrote:
>>> FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).
>>>
>>> On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
>>> wrote:
This was dis
Looks good; will replace and merge to 'next', but not today (I am
already deep into today's integration cycle).
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-i
On Wed, Dec 18, 2013 at 1:43 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> Why don't we take this opportunity to replace that array with a
>> strbuf? The conversion looks simple with this function.
>
> Indeed. Something like this, perhaps?
Yes, looking good.
> void prune_packed_objects(
The -O flag really shouldn't silently fail to do anything when given a
path that it can't read from.
However, it should be able to read from un-mmappable files, such as:
* pipes/fifos
* /dev/null: It's a character device (at least on Linux)
* ANY empty file:
Quoting Linux mmap(2), "SUSv
I expect you've figured out what this patch series is about by now.
In this version, I've applied Junio's suggestions from the last
version, and also the stuff from the FIXUP commit he made after my
stuff in the branch he merged into 'pu'.
Samuel Bronson (3):
diff: Tests for "git diff -O"
diff
Heavily adapted from Anders' patch:
"diff: Add diff.orderfile configuration variable"
Signed-off-by: Anders Waldenborg
Signed-off-by: Samuel Bronson
---
t/t4056-diff-order.sh | 70 +++
1 file changed, 70 insertions(+)
create mode 100755 t/t4056-d
diff.orderfile acts as a default for the -O command line option.
[sb: split up aw's original patch; rework tests and docs, treat option
as pathname]
Signed-off-by: Anders Waldenborg
Signed-off-by: Samuel Bronson
---
Documentation/diff-config.txt | 5 +
Documentation/diff-options.txt | 3
On Wed, Dec 18, 2013 at 02:59:12PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> >> Yes, that is locally OK, but depending on how the caller behaves, we
> >> might need to have an extra saved_errno dance here, which I didn't
> >> want to get into...
> >
> > I think we are fine. The only ca
On Wed, Dec 18, 2013 at 11:44:58PM +0100, Michael Haggerty wrote:
> [While doing so, I got sidetracked by the question: what happens if a
> prune process deletes the "objects/XX" directory just the same moment
> that another process is trying to write an object into that directory?
> I think the r
On 12/17/2013 07:47 PM, Eric S. Raymond wrote:
> Johan Herland :
>> However, I fear that you underestimate the number of users that want
>> to use Git against CVS repos that are orders of magnitude larger (in
>> both dimensions: #commits and #files) than your example repo.
>
> You may be right. Se
I tried to make a script to repro this from scratch but ran into other
issues, which may or may not be a bug. I'll put that at the end.
To repro all you have to do is:
git checkout git://github.com/frioux/dotfiles
git reset --hard 92c85161ceec9e52b0b2d2de893ba11f49c80198
git mv zsh .zsh
(sh
Jeff King writes:
> On Wed, Dec 18, 2013 at 01:37:24PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > According to the POSIX quote above, it sounds like we could do:
>> >
>> > #if defined (_SC_OPEN_MAX)
>> > {
>> > long max;
>> > errno = 0;
>> > ma
On 12/17/2013 07:43 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> Why don't we take this opportunity to replace that array with a
>> strbuf? The conversion looks simple with this function.
>
> Indeed. Something like this, perhaps?
> [...]
Frankly, with my initial patches I was just tryin
> From: Jeff King
> One of the problems I ran into recently is that
> corrupt data can cause it to make a large allocation
One thing I notice is that in unpack_compressed_entry() in
sha1_file.c, there is a mallocz of "size" bytes. It appears that
"size" is the size of the object that is being u
On Wed, Dec 18, 2013 at 04:08:47PM -0500, Dale R. Worley wrote:
> > From: Jeff King
>
> > One of the problems I ran into recently is that
> > corrupt data can cause it to make a large allocation
>
> One thing I notice is that in unpack_compressed_entry() in
> sha1_file.c, there is a mallocz of
On Tue, Dec 17, 2013 at 10:06:20PM -0500, Dale R. Worley wrote:
> Here's the basic backtrace information, and the values of the "size"
> variables, which seem to be the immediate culprits:
> [...]
> #1 0x004f3633 in xmallocz (size=size@entry=80530636800)
> at wrapper.c:73
>
Tom Miller writes:
> When a branchname DF conflict occurs during a fetch,
You may have started with a specific case in which you want to
change the behaviour of current Git, so it may be clear what you
meant by "branchname DF conflict", but that is true for nobody other
than you who will read th
Tom Miller writes:
> In order to fix branchname DF conflicts during `fetch --prune`, the way
> the header is output to the screen needs to be refactored. Here is an
> exmaple of the output with the line in question denoted by '>':
>
> $ git fetch --prune --dry-run upstream
>> From http
On Wed, Dec 18, 2013 at 01:37:24PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > According to the POSIX quote above, it sounds like we could do:
> >
> > #if defined (_SC_OPEN_MAX)
> > {
> > long max;
> > errno = 0;
> > max = sysconf(_SC_OPEN_MAX);
> >
Jeff King writes:
> According to the POSIX quote above, it sounds like we could do:
>
> #if defined (_SC_OPEN_MAX)
> {
> long max;
> errno = 0;
> max = sysconf(_SC_OPEN_MAX);
> if (0 < max) /* got the limit */
> return max;
>
On Wed, Dec 18, 2013 at 11:50:24AM -0800, Junio C Hamano wrote:
> 8< --
>
> static unsigned int get_max_fd_limit(void)
> {
> #ifdef RLIMIT_NOFILE
> struct rlimit lim;
>
> if (!getrlimit(RLIMIT_NOFILE, &lim))
>
In order to fix branchname DF conflicts during `fetch --prune`, the way
the header is output to the screen needs to be refactored. Here is an
exmaple of the output with the line in question denoted by '>':
$ git fetch --prune --dry-run upstream
> From https://github.com/git/git
When a branchname DF conflict occurs during a fetch, --prune should
be able to fix it. When fetching with --prune, the fetching process
happens before pruning causing the branchname DF conflict to persist
and report an error. This patch prunes before fetching, thus
correcting DF conflicts during a
If fetch --prune is run with no new refs to fetch, but it has refs
to prune. Then, the header url is not printed as it would if there were
new refs to fetch. the following is example output showing this
behavior:
$ git fetch --prune --dry-run origin
x [deleted] (none) -> origin/world
Duy Nguyen writes:
> On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse wrote:
>> FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).
>>
>> On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
>> wrote:
>>> This was discussed on the Git user list recently [1].
>>>
>>> #in a repo with
> Which will trash your history - the bugs in that are worse than the bugs
> in 3.0, which are bad enough that I *terminated* it.
Which *might* trash your history.
cvsps v2 and git cvsimport work as advertised with simple, linear CVS
repositories. I maintain a git mirror of an active CVS repo an
On Wed, Dec 18, 2013 at 12:15:19PM -0800, Junio C Hamano wrote:
> > Thanks. Are you picking this up with a commit message, or did you want
> > me to re-send with the usual message/signoff?
>
> I think this should be sufficient ;-)
>
> -- >8 --
> From: Jeff King
> Date: Tue, 17 Dec 2013 18:22:31
John Keeping :
> Which I think sums up the position nicely; if you're doing a one-shot
> import then the standalone tools are going to be a better choice, but if
> you're trying to use Git for your work on top of CVS the only choice is
> cvsps with git-cvsimport.
Which will trash your history - th
Junio C Hamano writes:
> Jeff King writes:
>
>> That is, does sysconf actually work on such a system (or does it need a
>> similar run-time fallback)? And either way, we should try falling back
>> to OPEN_MAX rather than 1 if we have it.
>
> Interesting.
>
>> As far as the warning, I am not sure
Jeff King writes:
> On Wed, Dec 18, 2013 at 12:07:02PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> >> > + prune_object(path->buf, sha1);
>> >> > + path->len = baselen;
>> >>
>> >> This is minor, but I prefer using strbuf_setlen() for th
On Wed, Dec 18, 2013 at 12:07:02PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> >> > +prune_object(path->buf, sha1);
> >> > +path->len = baselen;
> >>
> >> This is minor, but I prefer using strbuf_setlen() for this.
> >
> > Good catch. I d
Jeff King writes:
>> > + prune_object(path->buf, sha1);
>> > + path->len = baselen;
>>
>> This is minor, but I prefer using strbuf_setlen() for this.
>
> Good catch. I do not think it is minor at all; my version is buggy.
> After the loop ends, path->len does no
Jeff King wrote:
> I wish we understood why getrlimit was failing. Returning EFAULT seems
> like an odd choice if it is not implemented for the system. On such a
> system, do the other fallbacks actually work? Would it work to do:
>
> That is, does sysconf actually work on such a system (or does i
On Wed, Dec 18, 2013 at 11:35:34AM -0800, Junio C Hamano wrote:
> This function is called to remove
>
> * Any tmp_* found directly in .git/objects/
> * Any tmp_* found directly in .git/objects/pack/
> * Any tmp_obj_* found directly in .git/objects/??/
>
> and shares the same expiration logic
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> It could be argued that a "git add [] .", with an
>> explicit "." given by the end-user, that is run in an empty
>> directory may be an error worth reporting.
>
> But what we have right now is really weird:
I know. That is why I said "It _coul
On Wed, Dec 18, 2013 at 11:53:47AM -0500, Martin Langhoff wrote:
> On Wed, Dec 18, 2013 at 11:27 AM, Eric S. Raymond wrote:
> >> Anyway I hope that incremental CVS import would be needed less
> >> and less as CVS is replaced by any more modern version control system.
> >
> > I agree. I have never
Jeff King writes:
> That is, does sysconf actually work on such a system (or does it need a
> similar run-time fallback)? And either way, we should try falling back
> to OPEN_MAX rather than 1 if we have it.
Interesting.
> As far as the warning, I am not sure I see a point. The user does not
>
Jeff King writes:
> Converting it to use strbuf looks like it will actually let us drop a
> bunch of copying, too, as we just end up in mkpath at the very lowest
> level. I.e., something like below.
Thanks; I may have a few minor comments, but overall, I like the
placement of mkpath() in the res
Junio C Hamano writes:
> It could be argued that a "git add [] .", with an
> explicit "." given by the end-user, that is run in an empty
> directory may be an error worth reporting.
But what we have right now is really weird:
# setup repo with one empty dir:
$ rm -fr test
$ git init test
Initia
Jeff King :
> In git, it may happen quite a bit during "git am" or "git rebase", in
> which a large number of commits are replayed in a tight loop.
That's a good point - a repeatable real-world case in which we can
expect that behavior.
This case could be solved, though, with a slight tweak to th
On Wed, Dec 18, 2013 at 10:00:35AM -0800, Junio C Hamano wrote:
> Joey Hess writes:
>
> > In sha1_file.c, when git is built on linux, it will use
> > getrlimit(RLIMIT_NOFILE). I've been deploying git binaries to some
> > unusual systems, like embedded NAS devices, and it seems some with older
>
Duy Nguyen writes:
> On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse wrote:
>> FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).
>>
>> On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
>> wrote:
>>> This was discussed on the Git user list recently [1].
>>>
>>> #in a repo with
Junio C Hamano wrote:
> Hmph, perhaps you are right. Like this?
Works for me.
--
see shy jo
signature.asc
Description: Digital signature
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy writes:
>
>> starts_with() started out as a copy of prefixcmp(). But if we don't
>> care about the sorting order, the logic looks closer to
>> skip_prefix(). This looks like a good thing to do.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>
> S
Nguyễn Thái Ngọc Duy writes:
> I reimplemented skip_prefix() again just to realize this function
> already exists. Which reminds me there are a bunch of places that
> could benefit from this function, the same reason that I wanted to
> reimplement it.
>
> So this is series to make it more popula
Joey Hess writes:
> In sha1_file.c, when git is built on linux, it will use
> getrlimit(RLIMIT_NOFILE). I've been deploying git binaries to some
> unusual systems, like embedded NAS devices, and it seems some with older
> kernels like 2.6.33 fail with "fatal: cannot get RLIMIT_NOFILE: Bad addres
"Kent R. Spillner" writes:
> On Wed, Dec 18, 2013 at 09:53:48PM +0700, Nguyễn Thái Ngọc Duy wrote:
>> This is a variant of skip_prefix() that returns a specied pointer
>> instead of NULL if no prefix is found. It's helpful to simplify
>>
>> if (starts_with(foo, "bar"))
>> foo += 3;
>>
>>
Nguyễn Thái Ngọc Duy writes:
> starts_with() started out as a copy of prefixcmp(). But if we don't
> care about the sorting order, the logic looks closer to
> skip_prefix(). This looks like a good thing to do.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
Sure, but the implementation of skip_p
Karsten Blees writes:
> OK, this one's a no-brainer I think. See $gmane/239430 for the
> latest proposal on the struct packing front.
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://vge
On Wed, Dec 18, 2013 at 11:27:10AM -0500, Eric S. Raymond wrote:
> For use in reposurgeon I have defined a generic cross-VCS reference to
> commit I call an "action stamp"; it consists of an RFC3339 date followed by
> a committer email address. Here's an example:
>
>2013-02-06T09:35:10Z!
Christian Couder writes:
> On Wed, Dec 18, 2013 at 1:37 PM, Karsten Blees
> wrote:
>> Am 11.12.2013 08:46, schrieb Christian Couder:
>>> +enum repl_fmt { SHORT, MEDIUM, FULL };
>>
>> SHORT is predefined on Windows, could you choose another name?
>
> Ok, I will change to:
>
> enum repl_fmt { SHO
In sha1_file.c, when git is built on linux, it will use
getrlimit(RLIMIT_NOFILE). I've been deploying git binaries to some
unusual systems, like embedded NAS devices, and it seems some with older
kernels like 2.6.33 fail with "fatal: cannot get RLIMIT_NOFILE: Bad address".
I could work around thi
On Wed, Dec 18, 2013 at 11:27 AM, Eric S. Raymond wrote:
>> Anyway I hope that incremental CVS import would be needed less
>> and less as CVS is replaced by any more modern version control system.
>
> I agree. I have never understood why people on this list are attached to it.
I think I have ans
On Wed, Dec 18, 2013 at 1:37 PM, Karsten Blees wrote:
> Am 11.12.2013 08:46, schrieb Christian Couder:
>> +enum repl_fmt { SHORT, MEDIUM, FULL };
>
> SHORT is predefined on Windows, could you choose another name?
Ok, I will change to:
enum repl_fmt { SHORT_FMT, MEDIUM_FMT, FULL_FMT };
Thanks,
C
On Wed, Dec 18, 2013 at 09:53:48PM +0700, Nguyễn Thái Ngọc Duy wrote:
> This is a variant of skip_prefix() that returns a specied pointer
> instead of NULL if no prefix is found. It's helpful to simplify
>
> if (starts_with(foo, "bar"))
> foo += 3;
>
> into
>
> foo = skip_prefix_gently(f
Jakub Narębski :
> It is a bit strange that markfile has explicitly SHA-1 (":markid "),
> instead of generic reference to commit, in the case of CVS it would be
> commitid (what to do for older repositories, though?), in case of Bazaar
> its revision id (GUID), etc. Can we assume that SCM v1 fast-
Jakub Narebski wrote:
> It is a bit strange that markfile has explicitly SHA-1 (":markid "),
> instead of generic reference to commit, in the case of CVS it would be
> commitid (what to do for older repositories, though?), in case of Bazaar
> its revision id (GUID), etc.
Usually importers use at
Users often find that "next" and "prev" do the opposite of what they
expect. For example, "next" moves to the next match down the list, but
that is almost always backwards in time. Replacing the text with arrows
makes it clear where the buttons will take the user.
Signed-off-by: Marc Branchaud
On Wed, Dec 18, 2013 at 1:21 AM, Eric S. Raymond wrote:
> Jakub Narębski :
>>> No, cvs-fast-export does not have --export-marks. It doesn't generate the
>>> SHA1s that would require. Even if it did, it's not clear how that would
>>> help.
>>
>> I was thinking about how the following part of git-
Signed-off-by: Nguyễn Thái Ngọc Duy
---
environment.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/environment.c b/environment.c
index 3c76905..bc2d916 100644
--- a/environment.c
+++ b/environment.c
@@ -171,9 +171,7 @@ const char *get_git_namespace(void)
const char *s
Signed-off-by: Nguyễn Thái Ngọc Duy
---
diff.c | 67 +-
1 file changed, 25 insertions(+), 42 deletions(-)
diff --git a/diff.c b/diff.c
index d754e2f..4da77fd 100644
--- a/diff.c
+++ b/diff.c
@@ -3405,6 +3405,23 @@ int parse_long_opt
This removes the magic number 5, which is the string length of
"refs/". This comes from get_loose_refs(), called in packed_refs().
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 1fb658f..217093f 100644
--
While at there, partly fix the reporting as well. The reported value
with "arg+2" is only correct with -C/-B/-M, not with long option names.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
diff.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/diff.c b/
This is a variant of skip_prefix() that returns a specied pointer
instead of NULL if no prefix is found. It's helpful to simplify
if (starts_with(foo, "bar"))
foo += 3;
into
foo = skip_prefix_gently(foo, "bar", foo);
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c| 6 +
The purpose is remove hard coded string length. Some could be a few
lines away from the string comparison and easy to be missed when the
string is changed.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/for-each-ref.c | 9 +
builtin/mailinfo.c | 6 +++---
builtin/merge.c|
"name" will be reset unconditionally soon after skip_prefix() returns
NULL.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
connect.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/connect.c b/connect.c
index c763eed..1bb70aa 100644
--- a/connect.c
+++ b/connect.c
@@ -131,7 +1
starts_with() started out as a copy of prefixcmp(). But if we don't
care about the sorting order, the logic looks closer to
skip_prefix(). This looks like a good thing to do.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
git-compat-util.h | 6 +-
strbuf.c | 9 -
2 files changed, 5
All the changes follow the pattern
if (!starts_with(foo, "bar"))
return;
foo += 3;
which is turned into
if ((foo = skip_prefix(foo, "bar")) == NULL)
return;
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/branch.c | 3 +--
pretty.c | 3 +--
setup.c | 3 +--
tag.
Variable "what" is set in an if/else chain. If all fails (and "what"
is set to NULL) it'll be reset in the final "else" block.
in get_remote_group(), "key" is only used once. So changing it does
not harm.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/fetch.c | 16 +---
1 file chan
The code that's not converted to use parse_options() often does
if (!starts_with(arg, "foo=")) {
value = atoi(arg + 4);
}
This patch removes those magic numbers with skip_prefix()
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/fetch-pack.c | 13 +
builtin/index-pack.c
I reimplemented skip_prefix() again just to realize this function
already exists. Which reminds me there are a bunch of places that
could benefit from this function, the same reason that I wanted to
reimplement it.
So this is series to make it more popular (so hopefully I'll see it
used somewhere
It's out of context, but there are neither changes in buffer nor buf
between two chunks.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index 5e378bc..1fb658f 100644
--- a/refs.c
+++ b/refs.c
@@ -1339,7 +133
The BFG is a tool specifically designed for the task of removing
unwanted data from Git repository history - a common use-case for which
git-filter-branch has been the traditional workhorse.
It's beneficial to let users know that filter-branch has an alternative
here:
* speed : The BFG is 10-50x
On 18 December 2013 05:57, Junio C Hamano wrote:
> The first bullet point may be somewhat misleading, though. Nothing
> stops your script you use in filter-branch from processing blobs
> belonging to a single tree in parallel---the user just needs to do a
> bit more work to do so.
Thanks, I've m
Am 09.12.2013 15:03, schrieb Karsten Blees:
> 3.) Inject individual fields via macro
>
> Instead of injecting a struct hashmap_entry, which implies alignment to
> sizeof(struct hashmap_entry), we could inject the individual fields, e.g.
>
> #define HASHMAP_ENTRY_HEADER struct hashmap_entry __ne
subscribe git
--
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
Am 18.12.2013 14:10, schrieb Karsten Blees:
> + printf("sizeof(pointer+int) (%u) is not a "
> +"multiple of sizeof(pointer) (%u)!\n",
> +sizeof(struct pointer_int),
> +
Signed-off-by: Karsten Blees
---
Am 09.12.2013 18:48, schrieb Junio C Hamano:
> Karsten Blees writes:
>
>>> * kb/fast-hashmap (2013-11-18) 14 commits
>>> (merged to 'next' on 2013-12-06 at f90be3d)
>>
>> Damn, a day too late :-) I found these two glitches today...is a
>> fixup patch OK or sh
Am 14.12.2013 03:04, schrieb Jonathan Nieder:
> Hi,
>
> Karsten Blees wrote:
>
>> test-hashmap.c | 340
>>
>
> Here come two small tweaks on top (meant for squashing in or applying
> to the series, whichever is more convenient).
>
> Tha
Am 10.12.2013 00:45, schrieb Jonathan Nieder:
> Karsten Blees wrote:
>
>> Googling some more, I believe the most protable way to achieve this
>> via 'compiler settings' is
>>
>> #pragma pack(push)
>> #pragma pack(4)
>> struct hashmap_entry {
>>struct hashmap_entry *next;
>>unsigned int
Am 11.12.2013 08:46, schrieb Christian Couder:
> +enum repl_fmt { SHORT, MEDIUM, FULL };
SHORT is predefined on Windows, could you choose another name?
MinGW:
builtin/replace.c:23: error: 'SHORT' redeclared as different kind of symbol
c:\git\msysgit\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../..
On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse wrote:
> FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).
>
> On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
> wrote:
>> This was discussed on the Git user list recently [1].
>>
>> #in a repo with no files
>>> git add -A
>> fa
FWIW, git-bisect points to 84b8b5d (that is $gmane/230349).
On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen
wrote:
> This was discussed on the Git user list recently [1].
>
> #in a repo with no files
>> git add -A
> fatal: pathspec '.' did not match any files
>
> The same goes for git a
This was discussed on the Git user list recently [1].
#in a repo with no files
> git add -A
fatal: pathspec '.' did not match any files
The same goes for git add . (and -u).
Whereas I think some warning feedback is useful, we are curious
whether this is an intentional change or not.
[1] https:/
91 matches
Mail list logo
