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
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
locked. But the
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_enabled
On 12/05/2014 03:59 AM, ronnie sahlberg wrote:
On Thu, Dec 4, 2014 at 3:08 PM, Michael Haggerty mhag...@alum.mit.edu 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
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,
rather than
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 buffer and
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 I
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
future,
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 prevent a
Ulrich Windl ulrich.wi...@rz.uni-regensburg.de writes:
Ralf Thielow ralf.thie...@gmail.com schrieb am 06.12.2014 um 20:28 in
Nachricht
CAN0XMO+hn0cYrd=gvpuad_mqcvknwdfzfln0vo7045-m_0g...@mail.gmail.com:
2014-12-05 16:45 GMT+01:00 Torsten Bögershausen tbo...@web.de:
I do not know who was
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, just to
On Wed, Dec 3, 2014 at 11:13 PM, Junio C Hamano gits...@pobox.com 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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
---
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 always
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 gits...@pobox.com
Helped-by: Torsten Bögershausen tbo...@web.de
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-checkout.txt | 6 ++
builtin/checkout.c | 19 +++
t/t2025-checkout-to.sh | 7 +++
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git
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
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
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
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 pclo...@gmail.com
---
dir.c | 113
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/technical/index-format.txt | 58 +
cache.h | 3 +
dir.c| 134 +++
dir.h| 1
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 pclo...@gmail.com
---
dir.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index
This could be used to verify correct behavior in tests
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
This allows us to feed different info to read_directory_recursive()
based on untracked cache in the next patch.
Helped-by: Ramsay Jones ram...@ramsay1.demon.co.uk
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
dir.c | 55 +++
1 file
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 pclo...@gmail.com
---
dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dir.c
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
+++
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,
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
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
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 pclo...@gmail.com
---
builtin/commit.c | 5 +++--
wt-status.c | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin/commit.c
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
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
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
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.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
.gitignore | 1 +
Makefile | 1 +
t/t7063-status-untracked-cache.sh (new +x) | 353 +
test-dump-untracked-cache.c (new) | 61 +
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
---
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-update-index.txt | 6 ++
builtin/update-index.c | 148 +
2 files changed, 154 insertions(+)
diff --git
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
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
us and is
From: Duy Nguyen pclo...@gmail.com
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
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
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
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
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 g...@drmicha.warpmail.net
---
I also snuck in a change to the clean target, so that we don't have to update
it
git.pot update for the new glossary command.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
po/git.pot | 1362
1 file changed, 829 insertions(+), 533 deletions(-)
diff --git a/po/git.pot b/po/git.pot
index
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
On Sun, Dec 7, 2014 at 8:18 AM, Jeff King p...@peff.net 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, *;q=0.1
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 mixed
Junio C Hamano schrieb am 04.12.2014 um 21:15:
Michael J Gruber g...@drmicha.warpmail.net 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 guibuf...@gmail.com
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
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
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
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
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 johannes.schinde...@gmx.de
---
builtin/fsck.c | 20 +--
builtin/index-pack.c
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 johannes.schinde...@gmx.de
---
fsck.c | 49 +++--
1
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
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
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
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
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
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
---
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 and
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 johannes.schinde...@gmx.de
---
fsck.c | 8 ++--
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
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
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
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
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
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
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
+++
On Mon, Dec 8, 2014 at 4:38 PM, Michael J Gruber
g...@drmicha.warpmail.net 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
-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/-d
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
+++
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
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
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
Christian Couder schrieb am 08.12.2014 um 17:16:
On Mon, Dec 8, 2014 at 4:38 PM, Michael J Gruber
g...@drmicha.warpmail.net 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
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
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
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
Alfred Perlstein alf...@freebsd.org wrote:
Appearing here:
http://marc.info/?l=gitm=125259772625008w=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
+++
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 are
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
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 working
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.
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 mhag...@alum.mit.edu
Reviewed-by: sbel...@google.com
---
builtin/reflog.c | 13 -
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 mhag...@alum.mit.edu
Reviewed-by: sbel...@google.com
---
builtin/reflog.c | 12 ++--
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 mhag...@alum.mit.edu
Reviewed-by: sbel...@google.com
---
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
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 Haggerty
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 mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
---
builtin/reflog.c | 24
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 mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
---
builtin/reflog.c | 10
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 mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
---
builtin/reflog.c | 20 ++--
1 file changed, 10
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 it to
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.
On Fri, Dec 05, 2014 at 12:08:34AM +0100, Michael Haggerty wrote:
From: Ronnie Sahlberg sahlb...@google.com
Inline the function at its one remaining caller (which is within
refs.c) and remove it.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
It's originally from Ronnie, but his
On Dec 8, 2014, at 1:36 PM, Eric Wong normalper...@yhbt.net wrote:
Alfred Perlstein alf...@freebsd.org wrote:
Appearing here:
http://marc.info/?l=gitm=125259772625008w=2
Probably better to use a mid URL here, too
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
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 happens
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
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 unsubscribe
1 - 100 of 108 matches
Mail list logo
