[RFC/PATCH] transport-helper: initialize debug flag before starting threads

The transport_debug() function uses a static variable to lazily cache the boolean value of $TRANSPORT_DEBUG. If a program uses transport-helper's bidirectional_transfer_loop (as remote-ext and remote-fd do), then two threads may both try to write the variable at the same time. We can fix this by i

Re: [PATCH 07/23] expire_reflog(): use a lock_file for rewriting the reflog file

On 12/05/2014 03:19 AM, Stefan Beller wrote: > On Thu, Dec 04, 2014 at 04:23:31PM -0800, Jonathan Nieder wrote: >> Michael Haggerty wrote: >> >>> We don't actually need the locking functionality, because we already >>> hold the lock on the reference itself, which is how the reflog file is >>> locke

Re: [RFC/PATCH] transport-helper: initialize debug flag before starting threads

On Mon, Dec 08, 2014 at 03:22:06AM -0500, Jeff King wrote: > /* Print bidirectional transfer loop debug message. */ > __attribute__((format (printf, 1, 2))) > static void transfer_debug(const char *fmt, ...) > { > va_list args; > char msgbuf[PBUFFERSIZE]; > - static int debug_e

Re: [PATCH 07/23] expire_reflog(): use a lock_file for rewriting the reflog file

On 12/05/2014 03:59 AM, ronnie sahlberg wrote: > On Thu, Dec 4, 2014 at 3:08 PM, Michael Haggerty wrote: >> We don't actually need the locking functionality, because we already >> hold the lock on the reference itself, > > No. You do need the lock. > The ref is locked only during transaction_comm

Re: [PATCH] fsck: properly bound "invalid tag name" error message

Hi Peff, On Mon, 8 Dec 2014, Jeff King wrote: > When we detect an invalid tag-name header in a tag object, > like, "tag foo bar\n", we feed the pointer starting at "foo > bar" to a printf "%s" formatter. This shows the name, as we > want, but then it keeps printing the rest of the tag buffer, > r

Re: [PATCH] fsck: properly bound "invalid tag name" error message

Hi, On Mon, 8 Dec 2014, Jeff King wrote: > On Mon, Dec 08, 2014 at 12:48:12AM -0500, Jeff King wrote: > > > Note that when fscking tags with "index-pack --strict", this is even > > worse. index-pack does not add a trailing NUL-terminator after the > > object, so we may actually read past the buf

Re: [PATCH] fsck: properly bound "invalid tag name" error message

On Mon, Dec 08, 2014 at 12:57:06AM -0500, Jeff King wrote: > I do admit that I am tempted to teach index-pack to always NUL-terminate > objects in memory that we feed to fsck, just to be on the safe side. It > doesn't cost much, and could prevent a silly mistake (either in the > future, or one that

Re: [PATCH] fsck: properly bound "invalid tag name" error message

On Mon, Dec 08, 2014 at 12:17:10PM +0100, Johannes Schindelin wrote: > > I do admit that I am tempted to teach index-pack to always NUL-terminate > > objects in memory that we feed to fsck, just to be on the safe side. It > > doesn't cost much, and could prevent a silly mistake (either in the > >

Re: [PATCH] fsck: properly bound "invalid tag name" error message

Hi Duy, On Mon, 8 Dec 2014, Duy Nguyen wrote: > On Mon, Dec 08, 2014 at 12:57:06AM -0500, Jeff King wrote: > > I do admit that I am tempted to teach index-pack to always NUL-terminate > > objects in memory that we feed to fsck, just to be on the safe side. It > > doesn't cost much, and could prev

Re: Antw: Re: Enhancement Request: "locale" git option

"Ulrich Windl" writes: Ralf Thielow schrieb am 06.12.2014 um 20:28 in > Nachricht > : >> 2014-12-05 16:45 GMT+01:00 Torsten Bögershausen : >>> >>> I do not know who was first, and who came later, but >>> >> >

Re: [PATCH] fsck: properly bound "invalid tag name" error message

On Mon, Dec 08, 2014 at 12:35:27PM +0100, Johannes Schindelin wrote: > On Mon, 8 Dec 2014, Duy Nguyen wrote: > > > On Mon, Dec 08, 2014 at 12:57:06AM -0500, Jeff King wrote: > > > I do admit that I am tempted to teach index-pack to always NUL-terminate > > > objects in memory that we feed to fsck

Re: [PATCH 1/3] tree.c: update read_tree_recursive callback to pass strbuf as base

On Wed, Dec 3, 2014 at 11:13 PM, Junio C Hamano wrote: > A question during the review, especially on proposed log messages > and documentation changes, is rarely just a request to explain it to > the questioner in the discussion. It is an indication that what is > being commented on needs tweaking

[PATCH] index-format.txt: add a missing closing quote

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/technical/index-format.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index 1250b5c..35112e4 100644 --- a/Documentation/technical/ind

Re: [PATCH] fsck: properly bound "invalid tag name" error message

Hi Peff, On Mon, 8 Dec 2014, Jeff King wrote: > On Mon, Dec 08, 2014 at 12:35:27PM +0100, Johannes Schindelin wrote: > > > On Mon, 8 Dec 2014, Duy Nguyen wrote: > > > > > On Mon, Dec 08, 2014 at 12:57:06AM -0500, Jeff King wrote: > > > > I do admit that I am tempted to teach index-pack to alway

[PATCH v3 01/23] dir.c: optionally compute sha-1 of a .gitignore file

This is not used anywhere yet. But the goal is to compare quickly if a .gitignore file has changed when we have the SHA-1 of both old (cached somewhere) and new (from index or a tree) versions. Helped-by: Junio C Hamano Helped-by: Torsten Bögershausen Signed-off-by: Nguyễn Thái Ngọc Duy --- di

[PATCH] checkout: add --ignore-other-wortrees

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-checkout.txt | 6 ++ builtin/checkout.c | 19 +++ t/t2025-checkout-to.sh | 7 +++ 3 files changed, 24 insertions(+), 8 deletions(-) diff --git a/Documentation/git-checkout.txt b/Documentation/

[PATCH v3 02/23] untracked cache: record .gitignore information and dir hierarchy

The idea is if we can capture all input and (non-rescursive) output of read_directory_recursive(), and can verify later that all the input is the same, then the second r_d_r() should produce the same output as in the first run. The requirement for this to work is stat info of a directory MUST chan

[PATCH v3 00/23] nd/untracked-cache updates

Compare to v1 (the one on 'pu' as v2 never got to 'pu'): - New cleanup patch 09/23 - New patch 17/23 allows to ignore untracked cache without destroying it (for comparison and verification) - New patches 22/23 and 23/23 add some protection against filesystem or operating system changes

[PATCH v3 07/23] untracked cache: mark what dirs should be recursed/saved

If we redo this thing in a functional style, we would have one struct untracked_dir as input tree and another as output. The input is used for verification. The output is a brand new tree, reflecting current worktree. But that means recreate a lot of dir nodes even if a lot could be shared between

[PATCH v3 03/23] untracked cache: initial untracked cache validation

Make sure the starting conditions and all global exclude files are good to go. If not, either disable untracked cache completely, or wipe out the cache and start fresh. Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c | 113 -- dir.h |

[PATCH v3 10/23] untracked cache: save to an index extension

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/technical/index-format.txt | 58 + cache.h | 3 + dir.c| 134 +++ dir.h| 1 + read-cache.c

[PATCH v3 08/23] untracked cache: don't open non-existent .gitignore

This cuts down a signficant number of open(.gitignore) because most directories usually don't have .gitignore files. Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/dir.c b/dir.c index 02cdc26..95a0f0a 1

[PATCH v3 15/23] untracked cache: print stats with $GIT_TRACE_UNTRACKED_STATS

This could be used to verify correct behavior in tests Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c | 12 1 file changed, 12 insertions(+) diff --git a/dir.c b/dir.c index 7fa372e..14dbd7a 100644 --- a/dir.c +++ b/dir.c @@ -1922,6 +1922,18 @@ int read_directory(struct dir_struct *

[PATCH v3 05/23] untracked cache: make a wrapper around {open,read,close}dir()

This allows us to feed different info to read_directory_recursive() based on untracked cache in the next patch. Helped-by: Ramsay Jones Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c | 55 +++ 1 file changed, 47 insertions(+), 8 deletions(-) d

[PATCH v3 17/23] untracked-cache: temporarily disable with $GIT_DISABLE_UNTRACKED_CACHE

This can be used to double check if results with untracked cache are correctly, compared to vanilla version. Untracked cache remains in index, but not used. Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dir.c b/dir.c index 9b0e1

[PATCH v3 12/23] untracked cache: invalidate at index addition or removal

Ideally we should implement untracked_cache_remove_from_index() and untracked_cache_add_to_index() so that they update untracked cache right away instead of invalidating it and wait for read_directory() next time to deal with it. But that may need some more work in unpack-trees.c. So stay simple as

[PATCH v3 11/23] untracked cache: load from UNTR index extension

Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c| 220 +++ dir.h| 2 + read-cache.c | 5 ++ 3 files changed, 227 insertions(+) diff --git a/dir.c b/dir.c index a0a7330..0126a0d 100644 --- a/dir.c +++ b/dir.c @@ -2273,3 +227

[PATCH v3 04/23] untracked cache: invalidate dirs recursively if .gitignore changes

It's easy to see that if an existing .gitignore changes, its SHA-1 would be different and invalidate_gitignore() is called. If .gitignore is removed, add_excludes() will treat it like an empty .gitignore, which again should invalidate the cached directory data. if .gitignore is added, lookup_untr

[PATCH v3 13/23] read-cache.c: split racy stat test to a separate function

Signed-off-by: Nguyễn Thái Ngọc Duy --- read-cache.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/read-cache.c b/read-cache.c index d643a3f..f12a185 100644 --- a/read-cache.c +++ b/read-cache.c @@ -270,20 +270,26 @@ static int ce_match_stat_basic(c

[PATCH v3 06/23] untracked cache: record/validate dir mtime and reuse cached output

The main readdir loop in read_directory_recursive() is replaced with a new one that checks if cached results of a directory is still valid. If a file is added or removed from the index, the containing directory is invalidated (but not its subdirs). If directory's mtime is changed, the same happens

[PATCH v3 18/23] status: enable untracked cache

update_index_if_able() is moved down so that the updated untracked cache could be written out. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/commit.c | 5 +++-- wt-status.c | 2 ++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/builtin/commit.c b/builtin/commit.c index 5ed

[PATCH v3 16/23] untracked cache: mark index dirty if untracked cache is updated

Signed-off-by: Nguyễn Thái Ngọc Duy --- cache.h | 1 + dir.c| 9 + read-cache.c | 2 +- 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/cache.h b/cache.h index f8b3dc5..fca979b 100644 --- a/cache.h +++ b/cache.h @@ -295,6 +295,7 @@ static inline unsigned int ca

[PATCH v3 09/23] ewah: add convenient wrapper ewah_serialize_strbuf()

Signed-off-by: Nguyễn Thái Ngọc Duy --- ewah/ewah_io.c | 13 + ewah/ewok.h| 2 ++ split-index.c | 11 ++- 3 files changed, 17 insertions(+), 9 deletions(-) diff --git a/ewah/ewah_io.c b/ewah/ewah_io.c index 1c2d7af..43481b9 100644 --- a/ewah/ewah_io.c +++ b/ewah/ewah_io

[PATCH v3 19/23] update-index: manually enable or disable untracked cache

Overall time saving on "git status" is about 40% in the best case scenario, removing ..collect_untracked() as the most time consuming function. read and refresh index operations are now at the top (which should drop when index-helper and/or watchman support is added). More numbers and analysis belo

[PATCH v3 14/23] untracked cache: avoid racy timestamps

When a directory is updated within the same second that its timestamp is last saved, we cannot realize the directory has been updated by checking timestamps. Assume the worst (something is update). See 29e4d36 (Racy GIT - 2005-12-20) for more information. Signed-off-by: Nguyễn Thái Ngọc Duy ---

[PATCH v3 23/23] untracked cache: guard and disable on system changes

If the user enables untracked cache, then - move worktree to an unsupported filesystem - or simply upgrade OS - or move the whole (portable) disk from one machine to another - or access a shared fs from another machine there's no guarantee that untracked cache can still function properly. Rec

[PATCH v3 21/23] t7063: tests for untracked cache

Signed-off-by: Nguyễn Thái Ngọc Duy --- .gitignore | 1 + Makefile | 1 + t/t7063-status-untracked-cache.sh (new +x) | 353 + test-dump-untracked-cache.c (new) | 61 + 4 files changed,

[PATCH v3 22/23] mingw32: add uname()

Helped-by: Eric Sunshine Signed-off-by: Nguyễn Thái Ngọc Duy --- compat/mingw.c | 11 +++ compat/mingw.h | 9 + 2 files changed, 20 insertions(+) diff --git a/compat/mingw.c b/compat/mingw.c index c5c37e5..88140e4 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -2128,3 +212

[PATCH v3 20/23] update-index: test the system before enabling untracked cache

Helped-by: Eric Sunshine Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-update-index.txt | 6 ++ builtin/update-index.c | 148 + 2 files changed, 154 insertions(+) diff --git a/Documentation/git-update-index.txt b/Documentation/git-u

Re: [PATCH] checkout: add --ignore-other-wortrees

Oops. This one does not belong to the series. I cleaned up `pwd`, then jumped to another one for testing and forgot to clean up patches again :( -- Duy -- 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 ht

Re: [PATCH 07/23] expire_reflog(): use a lock_file for rewriting the reflog file

On 12/05/2014 01:23 AM, Jonathan Nieder wrote: > Michael Haggerty wrote: > >> We don't actually need the locking functionality, because we already >> hold the lock on the reference itself, which is how the reflog file is >> locked. But the lock_file code still does some of the bookkeeping for >> u

[PATCH v2] index-pack: terminate object buffers with NUL

From: Duy Nguyen We have some tricky checks in fsck that rely on a side effect of require_end_of_header(), and would otherwise easily run outside non-NUL-terminated buffers. This is a bit brittle, so let's make sure that only NUL-terminated buffers are passed around to begin with. Jeff "Peff" Ki

[RFC/PATCH 3/5] glossary: man page

Signed-off-by: Michael J Gruber --- This also means you have to use "git help gitglossary" if you want to have the glossary only. But it's included in "git help glossary" for convenience. Documentation/git-glossary.txt | 48 ++ 1 file changed, 48 insertion

[RFC/PATCH 0/5] git-glossary

More and more people use Git in localised setups, which usually means mixed localisation setups - not only, but also because of our English man pages. Here's an attempt at leveraging our current infrastructure for helping those poor mixed localisation folks. The idea is to keep the most important

[RFC/PATCH 1/5] glossary.h: generate a glossary list from the Makefile

Generate a header file which lists all terms defined in the glossary in a way suitable for localisation. This will be used by the new glossary command. Signed-off-by: Michael J Gruber --- I also snuck in a change to the clean target, so that we don't have to update it (its definition) as long as

[RFC/PATCH 4/5] l10n: git-glossary

git.pot update for the new glossary command. Signed-off-by: Michael J Gruber --- po/git.pot | 1362 1 file changed, 829 insertions(+), 533 deletions(-) diff --git a/po/git.pot b/po/git.pot index ee91402..d725a5d 100644 --- a/po/git.po

[RFC/PATCH 2/5] glossary: introduce glossary lookup command

When using a localised git, there are many reasons why a correspondence between English and localised git terms is needed: - connect localised messages with English ones (porcelain vs. plumbing) - connect localised messages with English man pages or online docs - help out someone in a different loc

Re: Accept-language test fails on Mac OS

On Sun, Dec 7, 2014 at 8:18 AM, Jeff King wrote: > On Sat, Dec 06, 2014 at 10:04:06PM +0100, Torsten Bögershausen wrote: > >> I get this: >> >> >> expecting success: >> check_language "ko-KR, *;q=0.1" ko_KR.UTF-8 de_DE.UTF-8 ja_JP.UTF-8 >> en_US.UTF-8 && >> check_language "de-DE,

Re: [RFC/PATCH 0/5] git-glossary

Michael J Gruber schrieb am 08.12.2014 um 16:38: > More and more people use Git in localised setups, which usually means > mixed localisation setups - not only, but also because of our English > man pages. > > Here's an attempt at leveraging our current infrastructure for helping > those poor mixe

Re: [PATCH] check-ignore: clarify treatment of tracked files

Junio C Hamano schrieb am 04.12.2014 um 21:15: > Michael J Gruber writes: > >> By default, check-ignore does not list tracked files at all since >> they are not subject to ignore patterns. >> >> Make this clearer in the man page. >> >> Reported-by: Guilherme >> Signed-off-by: Michael J Gruber >

[PATCH 00/18] Introduce an internal API to interact with the fsck machinery

At the moment, the git-fsck's integrity checks are targeted toward the end user, i.e. the error messages are really just messages, intended for human consumption. Under certain circumstances, some of those errors should be allowed to be turned into mere warnings, though, because the cost of fixing

[PATCH 02/18] Introduce identifiers for fsck messages

Rather than specifying only whether a message by the fsck machinery constitutes an error or a warning, let's specify an identifier relating to the concrete problem that was encountered. This is necessary for upcoming support to be able to demote certain errors to warnings. In the course, simplify

[PATCH 05/18] Allow demoting errors to warnings via receive.fsck. = warn

For example, missing emails in commit and tag objects can be demoted to mere warnings with git config receive.fsck.missing-email warn As git receive-pack does not actually perform the checks, it hands off the setting to index-pack or unpack-objects in the form of an optional argument to t

[PATCH 03/18] Provide a function to parse fsck message IDs

This function will be used in the next commits to allow the user to ask fsck to handle specific problems differently, e.g. demoting certain errors to warnings. It has to handle partial strings because we would like to be able to parse, say, '--strict=missing-email=warn' command lines. To make the

[PATCH 01/18] Introduce fsck options

Just like the diff machinery, we are about to introduce more settings, therefore it makes sense to carry them around as a (pointer to a) struct containing all of them. Signed-off-by: Johannes Schindelin --- builtin/fsck.c | 20 +-- builtin/index-pack.c | 9 +-- builtin/unpac

[PATCH 07/18] Make fsck_ident() warn-friendly

When fsck_ident() identifies a problem with the ident, it should still advance the pointer to the next line so that fsck can continue in the case of a mere warning. Signed-off-by: Johannes Schindelin --- fsck.c | 49 +++-- 1 file changed, 27 insertions

[PATCH 09/18] fsck: handle multiple authors in commits specially

This problem has been detected in the wild, and is the primary reason to introduce an option to demote certain fsck errors to warnings. Let's offer to ignore this particular problem specifically. Technically, we could handle such repositories by setting missing-committer = warn, but that could hid

[PATCH 10/18] Make fsck_tag() warn-friendly

When fsck_tag() identifies a problem with the commit, it should try to make it possible to continue checking the commit object, in case the user wants to demote the detected errors to mere warnings. Just like fsck_commit(), there are certain problems that could hide other issues with the same tag

[PATCH 04/18] Offer a function to demote fsck errors to warnings

There are legacy repositories out there whose older commits and tags have issues that prevent pushing them when 'receive.fsckObjects' is set. One real-life example is a commit object that has been hand-crafted to list two authors. Often, it is not possible to fix those issues without disrupting th

[PATCH 06/18] fsck: report the ID of the error/warning

Some legacy code has objects with non-fatal fsck issues; To enable the user to ignore those issues, let's print out the ID (e.g. when encountering "missing-email", the user might want to call `git config receive.fsck.missing-email warn`). Signed-off-by: Johannes Schindelin --- fsck.c | 19 ++

[PATCH 11/18] Add a simple test for receive.fsck.*

Signed-off-by: Johannes Schindelin --- t/t5504-fetch-receive-strict.sh | 20 1 file changed, 20 insertions(+) diff --git a/t/t5504-fetch-receive-strict.sh b/t/t5504-fetch-receive-strict.sh index 69ee13c..db79e56 100755 --- a/t/t5504-fetch-receive-strict.sh +++ b/t/t5504-fetc

[PATCH 13/18] Optionally ignore specific fsck issues completely

An fsck issue in a legacy repository might be so common that one would like not to bother the user with mentioning it at all. With this change, that is possible by setting the respective error to "ignore". This change "abuses" the missing-email=warn test to verify that "ignore" is also accepted an

[PATCH 12/18] Disallow demoting grave fsck errors to warnings

Some kinds of errors are intrinsically unrecoverable (e.g. errors while uncompressing objects). It does not make sense to allow demoting them to mere warnings. Signed-off-by: Johannes Schindelin --- fsck.c | 8 ++-- t/t5504-fetch-receive-strict.sh | 9 + 2 fi

[PATCH 18/18] git receive-pack: support excluding objects from fsck'ing

The optional new config option `receive.fsck.skip-list` specifies the path to a file listing the names, i.e. SHA-1s, one per line, of objects that are to be ignored by `git receive-pack` when `receive.fsckObjects = true`. This is extremely handy in case of legacy repositories where it would cause

[PATCH 14/18] fsck: allow upgrading fsck warnings to errors

The 'invalid tag name' and 'missing tagger entry' warnings can now be upgraded to errors by setting receive.fsck.invalid-tag-name and receive.fsck.missing-tagger-entry to 'error'. Incidentally, the missing tagger warning is now really shown as a warning (as opposed to being reported with the "erro

[PATCH 17/18] Introduce `git fsck --quick`

This option avoids unpacking each and all objects, and just verifies the connectivity. In particular with large repositories, this speeds up the operation, at the expense of missing corrupt blobs and ignoring unreachable objects, if any. Signed-off-by: Johannes Schindelin --- Documentation/git-f

[PATCH 16/18] fsck: support demoting errors to warnings

We already have support in `git receive-pack` to deal with some legacy repositories which have non-fatal issues. Let's make `git fsck` itself useful with such repositories, too, by allowing users to ignore known issues, or at least demote those issues to mere warnings. Example: `git -c fsck.missi

[PATCH 08/18] Make fsck_commit() warn-friendly

When fsck_commit() identifies a problem with the commit, it should try to make it possible to continue checking the commit object, in case the user wants to demote the detected errors to mere warnings. Note that some problems are too problematic to simply ignore. For example, when the header lines

[PATCH 15/18] Document the new receive.fsck.* options.

Signed-off-by: Johannes Schindelin --- Documentation/config.txt | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 7deae0b..b3276ee 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2109,6 +2109,20 @

Re: [RFC/PATCH 0/5] git-glossary

On Mon, Dec 8, 2014 at 4:38 PM, Michael J Gruber wrote: > More and more people use Git in localised setups, which usually means > mixed localisation setups - not only, but also because of our English > man pages. > > Here's an attempt at leveraging our current infrastructure for helping > those po

[PATCHv2 2/2] branch: allow -f with -m and -d

-f/--force is the standard way to force an action, and is used by branch for the recreation of existing branches, but not for deleting unmerged branches nor for renaming to an existing branch. Make "-m -f" equivalent to "-M" and "-d -f" equivalent to" -D", i.e. allow -f/--force to be used with -m/

[PATCHv2 1/2] t3200-branch: test -M

Signed-off-by: Michael J Gruber Signed-off-by: Junio C Hamano --- t/t3200-branch.sh | 9 + 1 file changed, 9 insertions(+) diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh index 432921b..0b3b8f5 100755 --- a/t/t3200-branch.sh +++ b/t/t3200-branch.sh @@ -97,6 +97,15 @@ test_expect_succ

[PATCHv2 0/2] Make git branch -f forceful

For many git commands, '-f/--force' is a way to force actions which would otherwise error out. Way more than once, I've been trying this with 'git branch -d' and 'git branch -m'... I've had these two patches sitting in my tree for 3 years now it seems. Here's a rebase. In v2 I rename force_create

Blobs not referenced by file (anymore) are not removed by GC

Hi, after using BFG on a repo given certain directory globs, all of those files(names) are gone from history, but can not be collected by garbage collection anymore. So the blobs of the underlying files are not deleted and only the file names are not associated with the blob anymore. I wonder, if

[PATCH] Avoid gcc compiler warning

At least on this developer's MacOSX (Snow Leopard, gcc-4.2.1), GCC prints a warning that 'hash' may be used uninitialized when compiling test-hashmap that 'hash' may be used uninitialized (but GCC 4.6.3 on this developer's Ubuntu server does not report this problem). Since hash() is called from pe

Re: [RFC/PATCH 0/5] git-glossary

Christian Couder schrieb am 08.12.2014 um 17:16: > On Mon, Dec 8, 2014 at 4:38 PM, Michael J Gruber > wrote: >> More and more people use Git in localised setups, which usually means >> mixed localisation setups - not only, but also because of our English >> man pages. >> >> Here's an attempt at le

Re: Blobs not referenced by file (anymore) are not removed by GC

Hi Martin, I'm the developer of the BFG - I'd guess that there probably isn't a bug for Git developers here, so you might want to open one or more issues at https://github.com/rtyley/bfg-repo-cleaner/issues, where I'd be happy to take a look. best regards, Roberto > On 8 Dec 2014 16:35, "Martin S

Re: [PATCH 0/8] Making reflog modifications part of the transactions API

So I reviewed and examined this series and run into some problems. How do we view an empty reflog, i.e. an empty file at logs/refs/heads/master? I was told this is not a valid state for a reflog. However even the test suite sometimes produces an empty reflog files. Below there is a patch, which hi

Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

Am 07.12.2014 um 07:42 schrieb Max Kirillov: On Sat, Dec 06, 2014 at 02:06:08PM +0100, Jens Lehmann wrote: Am 05.12.2014 um 07:32 schrieb Max Kirillov: Currently I'm estimating approach when submodules which have .git file or directory inside are updated, and those which do not have it are not.

Re: [PATCH] git-svn: Support for git-svn propset

Alfred Perlstein wrote: > Appearing here: > http://marc.info/?l=git&m=125259772625008&w=2 Probably better to use a mid URL here, too http://mid.gmane.org/1927112650.1281253084529659.javamail.r...@klofta.sjsoft.com such a long URL, though... > --- a/perl/Git/SVN/Editor.pm > +++ b/perl/Git/SVN

Re: [PATCH/RFC v2] Squashed changes for multiple worktrees vs. submodules

On Mon, Dec 08, 2014 at 09:40:59PM +0100, Jens Lehmann wrote: > Huh? I think we already have that: If you ignore the url > config it's as if the submodule was never initialized, so > you can just *not* run the "git submodule update" command > at all to get that effect. No new option needed ;-) You

Re: [PATCH 0/8] Making reflog modifications part of the transactions API

Hi, Stefan Beller wrote: > How do we view an empty reflog, i.e. an empty file at logs/refs/heads/master? That's a good question. I'm a little concerned about what 'git reflog expire --updateref' would do in this case. It looks like the longstanding behavior is for 'git reflog expire' to expire

Re: [PATCH 08/23] Extract function should_expire_reflog_ent()

On Fri, Dec 05, 2014 at 12:08:20AM +0100, Michael Haggerty wrote: > Extracted from expire_reflog_ent() a function that is solely > responsible for deciding whether a reflog entry should be expired. By > separating this "business logic" from the mechanics of actually > expiring entries, we are worki

Re: [PATCH 10/23] expire_reflog(): add a "flags" argument

On Fri, Dec 05, 2014 at 12:08:22AM +0100, Michael Haggerty wrote: > We want to separate the options relevant to the expiry machinery from > the options affecting the expiration policy. So add a "flags" argument > to expire_reflog() to hold the former. > > The argument doesn't yet do anything. > >

Re: [PATCH 11/23] expire_reflog(): move dry_run to flags argument

On Fri, Dec 05, 2014 at 12:08:23AM +0100, Michael Haggerty wrote: > The policy objects don't care about "--dry-run". So move it to > expire_reflog()'s flags parameter. > > Signed-off-by: Michael Haggerty Reviewed-by: > --- > builtin/reflog.c | 13 - > 1 file changed, 8 insertions(

Re: [PATCH 12/23] expire_reflog(): move updateref to flags argument

On Fri, Dec 05, 2014 at 12:08:24AM +0100, Michael Haggerty wrote: > The policy objects don't care about "--updateref". So move it to > expire_reflog()'s flags parameter. > > Signed-off-by: Michael Haggerty Reviewed-by: > --- > builtin/reflog.c | 12 ++-- > 1 file changed, 6 insertions

Re: [PATCH 13/23] Rename expire_reflog_cb to expire_reflog_policy_cb

On Fri, Dec 05, 2014 at 12:08:25AM +0100, Michael Haggerty wrote: > This is the first step towards separating the data needed by the > policy code from the data needed by the reflog expiration machinery. > > Signed-off-by: Michael Haggerty Reviewed-by: > --- > builtin/reflog.c | 19 ++-

Re: [PATCH 14/23] struct expire_reflog_cb: a new callback data type

On Fri, Dec 05, 2014 at 12:08:26AM +0100, Michael Haggerty wrote: > Add a new data type, "struct expire_reflog_cb", for holding the data > that expire_reflog() passes to expire_reflog_ent() via > for_each_reflog_ent(). For now it only holds a pointer to "struct > expire_reflog_policy_cb". In future

Re: [PATCH 15/23] expire_reflog(): pass flags through to expire_reflog_ent()

On Fri, Dec 05, 2014 at 12:08:27AM +0100, Michael Haggerty wrote: > Add a flags field to "struct expire_reflog_cb", and pass the flags > argument through to expire_reflog_ent(). In a moment we will start > using it to pass through flags that expire_reflog_ent() needs. > > Signed-off-by: Michael Ha

Re: [PATCH 16/23] expire_reflog(): move verbose to flags argument

On Fri, Dec 05, 2014 at 12:08:28AM +0100, Michael Haggerty wrote: > The policy objects don't care about "--verbose". So move it to > expire_reflog()'s flags parameter. > > Signed-off-by: Michael Haggerty Reviewed-by: Stefan Beller > --- > builtin/reflog.c | 24 > 1 fi

Re: [PATCH 17/23] expire_reflog(): move rewrite to flags argument

On Fri, Dec 05, 2014 at 12:08:29AM +0100, Michael Haggerty wrote: > The policy objects don't care about "--rewrite". So move it to > expire_reflog()'s flags parameter. > > Signed-off-by: Michael Haggerty Reviewed-by: Stefan Beller > --- > builtin/reflog.c | 10 +- > 1 file changed, 5

Re: [PATCH 18/23] Move newlog and last_kept_sha1 to "struct expire_reflog_cb"

On Fri, Dec 05, 2014 at 12:08:30AM +0100, Michael Haggerty wrote: > These members are not needed by the policy functions. > > Signed-off-by: Michael Haggerty Reviewed-by: Stefan Beller > --- > builtin/reflog.c | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) > >

Re: [PATCH 19/23] expire_reflog(): treat the policy callback data as opaque

On Fri, Dec 05, 2014 at 12:08:31AM +0100, Michael Haggerty wrote: > Now that expire_reflog() doesn't actually look in the > expire_reflog_policy_cb data structure, we can make it opaque: > > * Change its callers to pass it a pointer to an entire "struct > expire_reflog_policy_cb". > > * Change

Re: [PATCH 20/23] reflog_expire(): new function in the reference API

On Fri, Dec 05, 2014 at 12:08:32AM +0100, Michael Haggerty wrote: > Move expire_reflog() into refs.c and rename it to reflog_expire(). > Turn the three policy functions into function pointers that are passed > into reflog_expire(). Add function prototypes and documentation to > refs.h. > > Signed-

Re: [PATCH 22/23] lock_any_ref_for_update(): inline function

On Fri, Dec 05, 2014 at 12:08:34AM +0100, Michael Haggerty wrote: > From: Ronnie Sahlberg > > Inline the function at its one remaining caller (which is within > refs.c) and remove it. > > Signed-off-by: Michael Haggerty It's originally from Ronnie, but his sign off is missing? If that sign

Re: [PATCH] git-svn: Support for git-svn propset

> On Dec 8, 2014, at 1:36 PM, Eric Wong wrote: > > Alfred Perlstein wrote: >> Appearing here: >> http://marc.info/?l=git&m=125259772625008&w=2 > > Probably better to use a mid URL here, too > > http://mid.gmane.org/1927112650.1281253084529659.javamail.r...@klofta.sjsoft.com > > such a long

fast-import should not care about core.ignorecase

Hi, As you now know, I'm working on a mercurial remote helper for git. As such, it uses fast-import. In the mercurial history of mozilla-central, there have been various renames of files with only case changes, and it so happens that my remote helper blows things up on case insensitive file syste

Re: fast-import should not care about core.ignorecase

On Tue, Dec 09, 2014 at 09:12:11AM +0900, Mike Hommey wrote: > Hi, > > As you now know, I'm working on a mercurial remote helper for git. As > such, it uses fast-import. > > In the mercurial history of mozilla-central, there have been various > renames of files with only case changes, and it so h

Re: fast-import should not care about core.ignorecase

Mike Hommey wrote on 12/8/2014 5:12 PM: While it makes sense for checkouts and local commits, it doesn't make sense to me that using git fast-import with the same import script would have a different behavior depending on whether the file system is case-sensitive or not. I have used fast-import w

Re: fast-import should not care about core.ignorecase

Joshua Jensen wrote: > I think it has been discussed before, but maybe Git needs a > core.casefold in addition to core.ignorecase.) Would it work for --casefold to be a commandline flag to fast-import, instead of a global option affecting multiple Git commands? Curious, Jonathan -- To unsubscrib

  1   2   >