git add -A fails in empty repository since 1.8.5

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]

Re: git add -A fails in empty repository since 1.8.5

FWIW, git-bisect points to 84b8b5d (that is $gmane/230349). On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen tfn...@gmail.com 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

Re: git add -A fails in empty repository since 1.8.5

On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse apeli...@gmail.com wrote: FWIW, git-bisect points to 84b8b5d (that is $gmane/230349). On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen tfn...@gmail.com wrote: This was discussed on the Git user list recently [1]. #in a repo with no

Re: [PATCH v3 07/10] builtin/replace: teach listing using short, medium or full formats

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

Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)

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 hash; };

Re: [PATCH v5 02/14] add a hashtable implementation that supports O(1) removal

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). Thanks,

[PATCH] hashmap.h: Use 'unsigned int' for hash-codes everywhere

Signed-off-by: Karsten Blees bl...@dcon.de --- Am 09.12.2013 18:48, schrieb Junio C Hamano: Karsten Blees karsten.bl...@gmail.com 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

Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)

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), +

[no subject]

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

Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)

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 __next;

[PATCH 07/12] connect.c: replace some use of starts_with() with skip_prefix()

name will be reset unconditionally soon after skip_prefix() returns NULL. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- 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 +++

[PATCH 01/12] Make starts_with() a wrapper of skip_prefix()

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 pclo...@gmail.com --- git-compat-util.h | 6 +- strbuf.c | 9 -

[PATCH 05/12] Convert a lot of starts_with() to skip_prefix()

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 pclo...@gmail.com --- builtin/for-each-ref.c | 9 + builtin/mailinfo.c | 6 +++---

[PATCH 03/12] Add and use skip_prefix_defval()

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 pclo...@gmail.com ---

[PATCH 11/12] diff.c: convert diff_scoreopt_parse to use skip_prefix()

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 pclo...@gmail.com --- diff.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff

[PATCH 12/12] refs.c: use skip_prefix() in prune_ref()

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 pclo...@gmail.com --- refs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/refs.c b/refs.c index

[PATCH 09/12] diff.c: reduce code duplication in --stat-xxx parsing

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- 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 @@

[PATCH 10/12] environment.c: replace starts_with() in strip_namespace() with skip_prefix()

Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- 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

Re: I have end-of-lifed cvsps

On Wed, Dec 18, 2013 at 1:21 AM, Eric S. Raymond e...@thyrsus.com wrote: Jakub Narębski jna...@gmail.com: 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

[PATCHv2] gitk: Replace next and prev buttons with down and up arrows.

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

incremental fast-import and marks (Re: I have end-of-lifed cvsps)

Jakub Narebski wrote: It is a bit strange that markfile has explicitly SHA-1 (:markid SHA-1), 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

Re: I have end-of-lifed cvsps

Jakub Narębski jna...@gmail.com: It is a bit strange that markfile has explicitly SHA-1 (:markid SHA-1), 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

Re: [PATCH 03/12] Add and use skip_prefix_defval()

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(foo, bar,

Re: [PATCH v3 07/10] builtin/replace: teach listing using short, medium or full formats

On Wed, Dec 18, 2013 at 1:37 PM, Karsten Blees karsten.bl...@gmail.com 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,

Re: I have end-of-lifed cvsps

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:

Re: [PATCH] hashmap.h: Use 'unsigned int' for hash-codes everywhere

Karsten Blees karsten.bl...@gmail.com 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

Re: [PATCH 01/12] Make starts_with() a wrapper of skip_prefix()

Nguyễn Thái Ngọc Duy pclo...@gmail.com 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 pclo...@gmail.com --- Sure, but

Re: [PATCH 03/12] Add and use skip_prefix_defval()

Kent R. Spillner kspill...@acm.org 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;

Re: RLIMIT_NOFILE fallback

Joey Hess j...@kitenet.net 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

Re: [PATCH 00/12] Hard coded string length cleanup

Nguyễn Thái Ngọc Duy pclo...@gmail.com 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

Re: [PATCH 01/12] Make starts_with() a wrapper of skip_prefix()

Junio C Hamano gits...@pobox.com writes: Nguyễn Thái Ngọc Duy pclo...@gmail.com 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

Re: RLIMIT_NOFILE fallback

Junio C Hamano wrote: Hmph, perhaps you are right. Like this? Works for me. -- see shy jo signature.asc Description: Digital signature

Re: git add -A fails in empty repository since 1.8.5

Duy Nguyen pclo...@gmail.com writes: On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse apeli...@gmail.com wrote: FWIW, git-bisect points to 84b8b5d (that is $gmane/230349). On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen tfn...@gmail.com wrote: This was discussed on the Git user

Re: I have end-of-lifed cvsps

Jeff King p...@peff.net: 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

Re: [PATCH 2/3] prune_object_dir(): verify that path fits in the temporary buffer

Jeff King p...@peff.net 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()

Re: RLIMIT_NOFILE fallback

Jeff King p...@peff.net 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

Re: I have end-of-lifed cvsps

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 e...@thyrsus.com 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

Re: git add -A fails in empty repository since 1.8.5

Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: It could be argued that a git add [any option] ., 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

Re: [PATCH 2/3] prune_object_dir(): verify that path fits in the temporary buffer

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 with

Re: RLIMIT_NOFILE fallback

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 it

Re: [PATCH 2/3] prune_object_dir(): verify that path fits in the temporary buffer

Jeff King p...@peff.net 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 not

Re: [PATCH 2/3] prune_object_dir(): verify that path fits in the temporary buffer

On Wed, Dec 18, 2013 at 12:07:02PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net 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

Re: [PATCH 2/3] prune_object_dir(): verify that path fits in the temporary buffer

Jeff King p...@peff.net writes: On Wed, Dec 18, 2013 at 12:07:02PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: + prune_object(path-buf, sha1); + path-len = baselen; This is minor, but I prefer using strbuf_setlen() for

Re: RLIMIT_NOFILE fallback

Junio C Hamano gits...@pobox.com writes: Jeff King p...@peff.net 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

Re: I have end-of-lifed cvsps

John Keeping j...@keeping.me.uk: 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

Re: [PATCH 2/3] prune_object_dir(): verify that path fits in the temporary buffer

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 p...@peff.net Date: Tue, 17 Dec 2013

Re: I have end-of-lifed cvsps

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 and

Re: git add -A fails in empty repository since 1.8.5

Duy Nguyen pclo...@gmail.com writes: On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse apeli...@gmail.com wrote: FWIW, git-bisect points to 84b8b5d (that is $gmane/230349). On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris Nicolaisen tfn...@gmail.com wrote: This was discussed on the Git user

[PATCH 1/3] builtin/fetch.c: Add pretty_url() and print_url()

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

[PATCH 3/3] fetch --prune: Repair branchname DF conflicts

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

[PATCH 2/3] fetch --prune: Always print header url

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

Re: RLIMIT_NOFILE fallback

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)) return

Re: RLIMIT_NOFILE fallback

Jeff King p...@peff.net 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;

Re: RLIMIT_NOFILE fallback

On Wed, Dec 18, 2013 at 01:37:24PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net 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);

Re: [PATCH 1/3] builtin/fetch.c: Add pretty_url() and print_url()

Tom Miller jacker...@gmail.com 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

Re: git fsck fails on malloc of 80 G

From: Jeff King p...@peff.net 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

Re: [PATCH 1/3] prune-packed: fix a possible buffer overflow

On 12/17/2013 07:43 PM, Junio C Hamano wrote: Duy Nguyen pclo...@gmail.com 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

Re: RLIMIT_NOFILE fallback

Jeff King p...@peff.net writes: On Wed, Dec 18, 2013 at 01:37:24PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: According to the POSIX quote above, it sounds like we could do: #if defined (_SC_OPEN_MAX) { long max; errno = 0;

Bug when moving submodules (I think?)

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

Re: I have end-of-lifed cvsps

On 12/17/2013 07:47 PM, Eric S. Raymond wrote: Johan Herland jo...@herland.net: 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

Re: [PATCH 1/3] prune-packed: fix a possible buffer overflow

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

Re: RLIMIT_NOFILE fallback

On Wed, Dec 18, 2013 at 02:59:12PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net 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

[PATCH v5 1/3] diff: Tests for git diff -O

Heavily adapted from Anders' patch: diff: Add diff.orderfile configuration variable Signed-off-by: Anders Waldenborg and...@0x63.nu Signed-off-by: Samuel Bronson naes...@gmail.com --- t/t4056-diff-order.sh | 70 +++ 1 file changed, 70 insertions(+)

[PATCH v5 3/3] diff: Add diff.orderfile configuration variable

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 and...@0x63.nu Signed-off-by: Samuel Bronson naes...@gmail.com --- Documentation/diff-config.txt | 5 +

[PATCH v5 2/3] diff: Let git diff -O read orderfile from any file, fail properly

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),

[PATCH v5 0/3] diff: Add diff.orderfile configuration variable

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:

Re: [PATCH 1/3] prune-packed: fix a possible buffer overflow

On Wed, Dec 18, 2013 at 1:43 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com 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.

Re: [PATCH v5 0/3] diff: Add diff.orderfile configuration variable

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

Re: git add -A fails in empty repository since 1.8.5

On Thu, Dec 19, 2013 at 3:57 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: On Wed, Dec 18, 2013 at 3:44 PM, Antoine Pelisse apeli...@gmail.com wrote: FWIW, git-bisect points to 84b8b5d (that is $gmane/230349). On Wed, Dec 18, 2013 at 9:06 AM, Thomas Ferris

Re: I have end-of-lifed cvsps

On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty mhag...@alum.mit.edu 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

Re: [PATCH 1/3] builtin/fetch.c: Add pretty_url() and print_url()

On Wed, Dec 18, 2013 at 3:47 PM, Junio C Hamano gits...@pobox.com wrote: Tom Miller jacker...@gmail.com 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

Re: [PATCH 3/3] fetch --prune: Repair branchname DF conflicts

On Wed, Dec 18, 2013 at 3:54 PM, Junio C Hamano gits...@pobox.com wrote: Tom Miller jacker...@gmail.com 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

Re: [PATCH] log: properly handle decorations with chained tags

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 I

Re: I have end-of-lifed cvsps

Michael Haggerty mhag...@alum.mit.edu: 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

Re: [PATCH 3/3] fetch --prune: Repair branchname DF conflicts

Tom Miller jacker...@gmail.com 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

[PATCH] gitk: Fix typo in proc blobdiffmaybeseehere

From: Johannes Sixt j...@kdbg.org 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