On Wed, Feb 26, 2014 at 09:54:39AM -0600, Robert Dailey wrote:
That _should_ turn on the pager, but I think it does not due to a bug
with setup_pager and aliases. Something like the patch below would make
it work (but if you are having to use -p manually, there is something
to fix in your
On Thu, Feb 27, 2014 at 02:13:03PM +0700, Nguyễn Thái Ngọc Duy wrote:
Before cdab485 (upload-pack: delegate rev walking in shallow fetch to
pack-objects - 2013-08-16) upload-pack does not write to the source
repository. cdab485 starts to write $GIT_DIR/shallow_XX if it's a
shallow fetch,
no update.
3. Process A commits the lockfile.
4. Process B takes the lock, then overwrite's process A's
changes.
We can fix this by doing our check while we hold the lock.
Signed-off-by: Jeff King p...@peff.net
---
On Thu, Feb 27, 2014 at 04:04:26AM -0500, Jeff King wrote:
by the way
On Thu, Feb 27, 2014 at 04:10:12AM -0500, Jeff King wrote:
I also notice that check_shallow_file_for_update returns early if
!is_shallow. Is that safe? Is it possible for another process to have
made us shallow since the program began? In that case, we would have to
stat() the file always
On Thu, Feb 27, 2014 at 05:18:58PM +0700, Duy Nguyen wrote:
On Thu, Feb 27, 2014 at 4:22 PM, Jeff King p...@peff.net wrote:
On Thu, Feb 27, 2014 at 04:10:12AM -0500, Jeff King wrote:
I also notice that check_shallow_file_for_update returns early if
!is_shallow. Is that safe
.
Note that we keep things simple and maintain only a single
filename to be cleaned. This is sufficient for the current
caller, but we future-proof it with a die(BUG).
Signed-off-by: Jeff King p...@peff.net
---
builtin/receive-pack.c | 16
commit.h | 2 +-
fetch-pack.c
On Wed, Feb 26, 2014 at 12:30:36PM -0800, Junio C Hamano wrote:
pack-kept-objects then?
Hmm. That does address my point above, but somehow the word kept feels
awkward to me. I'm ambivalent between the two.
That word does make my backside somewhat itchy ;-)
Would it help to take a
On Thu, Feb 27, 2014 at 07:56:52PM +0700, Nguyễn Thái Ngọc Duy wrote:
--sort=version:refname (or --sort=v:refname for short) sorts tags as
if they are versions. --sort=-refname reverses the order (with or
without :version).
versioncmp() is copied from string/strverscmp.c in glibc commit
On Fri, Feb 28, 2014 at 12:04:18PM +0900, Brian Gesiak wrote:
No test asserts that git branch -u refs/heads/my-branch my-branch
emits a warning. Add a test that does so.
For an operation like git branch foo origin where setting up the
tracking is a side effect, a warning makes sense. But the
On Fri, Feb 28, 2014 at 12:04:19PM +0900, Brian Gesiak wrote:
From: modocache modoca...@gmail.com
Both your emailed patches have this, which is due to your author name
not matching your sending identity. You probably want to set user.name,
or if you already have (which it looks like you might
. Maybe:
-- 8 --
Subject: [PATCH] CodingGuidelines: mention C whitespace rules
We are fairly consistent about these, so most are covered by
follow existing style, but it doesn't hurt to be explicit.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/CodingGuidelines | 11 +++
1
On Fri, Feb 28, 2014 at 03:17:28PM +0900, Brian Gesiak wrote:
For an operation like git branch foo origin where setting up the
tracking is a side effect, a warning makes sense. But the sole purpose
of the command above is to set the upstream, and we didn't do it; should
this warning
On Thu, Feb 27, 2014 at 08:01:18PM +0700, Nguyễn Thái Ngọc Duy wrote:
I find myself often do git rebase -i xxx and replace one pick line
with edit to amend just one commit when I see something I don't like
in that commit. This happens often while cleaning up a series. This
automates the
On Fri, Feb 28, 2014 at 07:55:25AM +0100, Johannes Sixt wrote:
This should use test_i18ncmp, as the string you are matching is
internationalized.
More generally, stderr output shouldn't be tested with test_cmp or
test_i18ncmp at all, but with grep and test_i18ngrep. The reason is that
On Fri, Feb 28, 2014 at 02:14:01AM -0500, Jeff King wrote:
I didn't think we bothered to make sh -x work robustly. I don't mind
if we do, but git grep -E 'test_(i18n)?cmp .*err shows many potential
problem spots.
Just for fun:
cd t
make SHELL_PATH=sh -x prove
causes 326 test failures
On Fri, Feb 28, 2014 at 02:34:16PM +0700, Duy Nguyen wrote:
Yeah, I do this a lot, too. The interface you propose makes sense to
me, though I'm not sure how much I would use it, as I often do not know
the specifier of the commit I want to change (was it HEAD~3 or
HEAD~4?). I guess using
On Fri, Feb 28, 2014 at 04:28:38PM +0900, Brian Gesiak wrote:
I would be in favor of using test_i18ngrep, but it seems like this
test file overwhelmingly uses test_(i18n)cmp, even when inspecting
stderr output.
We generally prefer cmp checks to grep checks, because they are more
rigorous.
On Thu, Feb 27, 2014 at 10:04:44AM -0800, Junio C Hamano wrote:
I wonder if it makes sense to link it with pack.writebitmaps more
tightly, without even exposing it as a seemingly orthogonal knob
that can be tweaked, though.
I think that is because I do not fully understand the , because ...
On Thu, Feb 27, 2014 at 10:37:30AM -0800, Junio C Hamano wrote:
Signed-off-by: Jeff King p...@peff.net
Thanks.
Do GitHub people have general aversion against signing off (or
sending out, for that matter) their own patches, unless they were
already active here before they joined GitHub
On Fri, Feb 28, 2014 at 04:07:09AM -0500, Jeff King wrote:
As this does not affect local use of git archive, requested by
refnames may need to be clarified further. Perhaps remote
archives can be requested only for published refnames or something.
I was hoping to be vague. If we really
Commits ee27ca4 and 0f544ee introduced rules by which
git-upload-archive would restrict clients from accessing
unreachable objects. However, we never documented those
rules anywhere, nor their reason for being. Let's do so now.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/git
dumb
walker access), or the site admin may simply decide the
security/convenience tradeoff is not worth it.
This patch adds a new config option to disable the
restrictions added in ee27ca4. It defaults to off, meaning
there is no change in behavior by default.
Signed-off-by: Jeff King p...@peff.net
On Fri, Feb 28, 2014 at 07:44:10PM +0900, Brian Gesiak wrote:
I notice that the warning comes from install_branch_config, which gets
used both for branch -u, but also in the side effect case I
mentioned above. Is it possible to trigger this as part of such a case?
I think maybe git branch
On Thu, Feb 27, 2014 at 01:10:30PM -0500, Brandon McCaig wrote:
On Wed, Feb 26, 2014 at 5:52 AM, Jeff King p...@peff.net wrote:
This seems like a reasonable feature to me. All of your examples are
possible with an edit and another git command, but the convenience may
be worth it (though
On Fri, Feb 28, 2014 at 08:16:13PM +0900, Brian Gesiak wrote:
I just don't want to regress somebody else's workflow due
to my lack of imagination.
This makes a lot of sense to me, although as-is the function emits a
warning and returns immediately (although with a successful status
On Fri, Feb 28, 2014 at 10:45:39AM -0800, Junio C Hamano wrote:
Exactly. The two features (bitmaps and .keep) are not compatible with
each other, so you have to prioritize one. If you are using static .keep
files, you might want them to continue being respected at the expense of
using
On Fri, Feb 28, 2014 at 10:09:08AM -0700, Nasser Grainawi wrote:
Exactly. The two features (bitmaps and .keep) are not compatible with
each other, so you have to prioritize one. If you are using static .keep
files, you might want them to continue being respected at the expense of
using
On Fri, Feb 28, 2014 at 03:26:28PM -0800, Conley Owens wrote:
test.sh
#!/bin/bash
rungit() {
mkdir $1
GIT_DIR=$1 git init --bare
echo '[remote aosp]' $1/config
echo 'url =
https://android.googlesource.com/platform/external/tinyxml2'
$1/config
GIT_DIR=$1 git
On Fri, Feb 28, 2014 at 07:45:07PM +0100, Fabio D'Alfonso wrote:
I get 12 of 15 tests faling.
Any idea? the same build works fine on 11.04 where I have a desktop version.
No clue. It works fine for me here (Debian sid). Perhaps try running the
script like:
./t9200-git-cvsexportcommit.sh
On Fri, Feb 28, 2014 at 11:03:19AM -0800, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
So my vote is that the patches are OK the way Dmitry wrote them (mind, I
have only read through 05/11 so far).
Seconded ;-)
By the way, I do not like these long subjects.
On Sat, Mar 01, 2014 at 01:19:32AM +0100, Michael Haggerty wrote:
I absolutely understand that changing all of the config parsers is not
feasible. But I had imagined a third route:
(3) parse the config once, storing the raw values to records in
memory. When an unset is seen, delete
On Mon, Mar 03, 2014 at 10:37:11AM +0100, Matthieu Moy wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Or perhaps -NUM should fail with an error message if any of the last
NUM commits are merges. In that restricted scenario (which probably
accounts for 99% of rebases), -NUM is
On Mon, Mar 03, 2014 at 10:13:47AM -0800, Junio C Hamano wrote:
Or the flip side: if the user wants to use .keep, we should drop
bitmaps. My point is that we do not know which way the user wants to
go, so we should not tie the options together.
Hmph. I think the short of your later
that we have duplicated all of their
objects.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/config.txt | 7 +++
Documentation/git-repack.txt | 8
builtin/repack.c | 13 -
t/t7700-repack.sh| 18 +-
4 files changed, 44
On Sun, Mar 02, 2014 at 06:04:39AM +0900, Brian Gesiak wrote:
My name is Brian Gesiak. I'm a research student at the University of
Tokyo, and I'm hoping to participate in this year's Google Summer of
Code by contributing to Git. I'm a longtime user, first-time
contributor--some of you may
grafts in some
instances, as evidenced by --keep-true-parents.
Signed-off-by: Jeff King p...@peff.net
---
This is motivated by a real-world case of somebody trying to push to
GitHub with a graft on their local end.
I suspect many other spots that use read_replace_refs = 0 probably
want
, so this attempts to add
a few obvious cases (including the one we are fixing here).
Signed-off-by: Jeff King p...@peff.net
---
I tried accommodating this one case in the current regex, but it just
kept getting more complicated and unreadable. Maybe I am being naive to
think that this much simpler
On Tue, Mar 04, 2014 at 06:36:07PM -0500, Eric Sunshine wrote:
On Tue, Mar 4, 2014 at 12:48 PM, Jeff King p...@peff.net wrote:
diff --git a/commit.c b/commit.c
index 6bf4fe0..886dbfe 100644
--- a/commit.c
+++ b/commit.c
@@ -114,6 +114,11 @@ static unsigned long parse_commit_date(const
On Tue, Mar 04, 2014 at 12:52:18PM -0800, Junio C Hamano wrote:
We already make an attempt to do the right thing in several
places by turning off read_replace_refs. However, we missed
at least one case (during bundle creation), and we do
nothing anywhere to handle grafts.
Doing nothing
On Tue, Mar 04, 2014 at 08:00:44PM -0500, Eric Sunshine wrote:
+int commit_grafts_loaded(void)
+{
+ return !!commit_graft_nr;
+}
Did you mean !!commit_graft ?
Shouldn't they produce the same results?
Yes they should, but the use of !! seemed to imply that you wanted
On Wed, Mar 05, 2014 at 09:26:43AM -0500, Phillip Susi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/5/2014 3:10 AM, Chris Packham wrote:
My example is creating a commit on the temp branch then applying
it to the master branch using git am.
Do a reset HEAD~1 --hard, and
On Wed, Mar 05, 2014 at 11:47:12AM -0500, Phillip Susi wrote:
I can't get Chris's script to fail on any version of git. Can you
show us an example of a patch that does not behave (or better yet,
a reproduction recipe to generate the patch with format-patch)?
AHA! It requires a conflict.
On Wed, Mar 05, 2014 at 01:36:12PM +0400, Dmitry wrote:
Here's my usecase. I have created a BranchWithVeryLongName and I want
to have it pushed to origin. So I use this command with version
1.8.1.2:
git push origin BranchMistypedLongName
(note that I mistyped the branch name). The
In preparation for being able to check the left-hand side of
our push refspecs separately, this pulls the examination of
them out into its own function. There should be no behavior
change.
Signed-off-by: Jeff King p...@peff.net
---
remote.c | 49
also have to refactor the
try_explicit_object_name sub-function; it indicates success by
allocating and returning a new ref. Instead, we give it an
out parameter for the match and return a numeric status.
Signed-off-by: Jeff King p...@peff.net
---
remote.c | 38
cannot catch all refspec problems, since fully evaluating
the refspecs requires knowing what the remote side has. But
we can do a quick sanity check of the local side and catch a
few simple error cases.
Signed-off-by: Jeff King p...@peff.net
---
remote.c | 25
On Wed, Mar 05, 2014 at 10:06:26AM -0800, Mickey Killianey wrote:
Is there any syntax to support partial negations of refspecs, such as:
+refs/heads/*:refs/remotes/origin/*
!refs/heads/dont-pull:
!:refs/remotes/origin/dont-push
If not now, is negation something that might be
On Wed, Mar 05, 2014 at 11:18:17AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Wed, Mar 05, 2014 at 10:49:24AM -0800, Junio C Hamano wrote:
... the plan, at least in my mind, has always been exactly that: grafts
were a nice little attempt but is broken---if you
On Wed, Mar 05, 2014 at 12:51:06PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
We can't fully process the refspecs until we have talked to the other
side, because they may involve matching refs from the remote; I don't
think git even really looks at them until after
On Wed, Mar 05, 2014 at 08:55:30PM -0600, Robert Dailey wrote:
What I'd like to do is somehow hunt down the largest commit (*not*
blob) in the entire history of the repository to hopefully find out
where huge directories have been checked in.
I can't do a search for largest file (which most
On Thu, Mar 06, 2014 at 09:42:46AM +0100, Michael Haggerty wrote:
Replace objects are better than grafts in *almost* every dimension. The
exception is that it is dead simple to create grafts, whereas I always
have to break open the man pages to remember how to create a replace
object that
On Thu, Mar 06, 2014 at 05:41:27PM +0100, Michael Haggerty wrote:
We can wrap that in git replace --convert-grafts, but I do not think
grafts are so common that there would be a big demand for it.
It's probably easier to wrap it than to explain to Windows users what
they have to do.
How
-off-by: Jeff King p...@peff.net
---
builtin/replace.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index 2336325..6a0e8bd 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -182,12 +182,16 @@ int cmd_replace(int
in code size, but the win will be
much bigger when we start adding more modes.
Signed-off-by: Jeff King p...@peff.net
---
builtin/replace.c | 49 +
1 file changed, 25 insertions(+), 24 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
As we add new options that operate on objects before
replacing them, we'll want to be able to feed raw sha1s
straight into replace_object. Split replace_object into the
object-resolution part and the actual replacement.
Signed-off-by: Jeff King p...@peff.net
---
builtin/replace.c | 26
.
Missing documentation and tests.
Signed-off-by: Jeff King p...@peff.net
---
Besides missing docs and tests, we might find that we want to factor the
code a little differently when we start adding other helpers (like
--graft). I will probably push this forward at some point, but I'm not
planning
On Thu, Mar 06, 2014 at 07:35:19PM +0100, Christian Couder wrote:
+ if (!cmdmode)
+ cmdmode = argc ? MODE_REPLACE : MODE_DELETE;
Shouldn't it be MODE_LIST instead of MODE_DELETE?
Argh, yes, thank you for catching. My original iteration used chars like
'd' and 'l'
On Thu, Mar 06, 2014 at 11:00:08AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I also noticed that the diff engine does not play well with replacements
of blobs. When we are diffing the trees, we see that the sha1 for path
foo is the same on either side, and do not look
On Thu, Mar 06, 2014 at 11:24:18AM -0800, Junio C Hamano wrote:
* Add new API calls that allow the cache to be inquired easily and
efficiently. Rewrite other functions like `git_config_int()` to be
cache-aware.
Are you sure about the second sentence of this item is what you
want?
On Thu, Mar 06, 2014 at 12:17:34PM -0500, Martin Langhoff wrote:
I have a shell script that trims old history on a cronjob. This is for
a repo that is used to track reports that have limited life (like
logs). Old history is trimmed with grafts pointing to an empty root
commit.
Right now,
On Wed, Mar 05, 2014 at 04:31:55PM +0900, Brian Gesiak wrote:
No test asserts that git branch -u refs/heads/my-branch my-branch
emits a warning. Add a test that does so.
Signed-off-by: Brian Gesiak modoca...@gmail.com
Thanks, this looks good. Two minor points that may or may not be worth
On Thu, Mar 06, 2014 at 10:24:49AM -0800, Junio C Hamano wrote:
OK, I've tried using my own build from master, and I still get the same
results.
I've done a little more investigation and discovered it always hangs at:
`atexit(notify_parent);` in `run-command.c:start_command`
when
On Wed, Mar 05, 2014 at 08:58:26AM +0100, Johannes Sixt wrote:
Here is a patch that I'm carrying around since... a while.
What do you think?
The pattern I chose also catches variable definition, not just
functions. That is what I need, but it hurts grep --function-context
That's the reason
, and also overflow when we pass the result as an
int to show_date.
Reported-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Jeff King p...@peff.net
---
pretty.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pretty.c b/pretty.c
index 3b811ed..6e266dd 100644
On Thu, Mar 06, 2014 at 08:57:58PM -0500, Eric Sunshine wrote:
+ if (strbuf_read(result, cmd.out, 41) 0)
+ die_errno(unable to read from mktree);
+ close(cmd.out);
+
+ if (finish_command(cmd))
+
On Fri, Mar 07, 2014 at 08:08:37AM +0100, Christian Couder wrote:
Be it graft or replace, I do not think we want to invite people to
use these mechansims too lightly to locally rewrite their history
willy-nilly without fixing their mistakes at the object layer with
commit --amend, rebase,
On Thu, Mar 06, 2014 at 10:47:43PM +0100, Julian Brost wrote:
I've noticed some behavior of git that might lead to some security
issues if the user is not aware of this.
Assume we have an evil user on a system, let's call him eve. He
prepares a repository where he allows other user to push
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapper, which makes JGit significantly less
portable. I know
.
This regression was introduced in 113f10f (Make git-clean a
builtin, 2007-11-11).
Signed-off-by: Jeff King p...@peff.net
---
On Mon, Mar 10, 2014 at 11:31:37AM +0100, Robin Pedersen wrote:
I accidentially deleted a directory using git clean. I would think
this is a bug, but I'm not sure
On Mon, Mar 10, 2014 at 01:20:02PM -0400, Jeff King wrote:
On Mon, Mar 10, 2014 at 11:31:37AM +0100, Robin Pedersen wrote:
I accidentially deleted a directory using git clean. I would think
this is a bug, but I'm not sure. Was using 1.8.1, but upgraded to
1.9.0 just to see
On Mon, Mar 10, 2014 at 01:20:02PM -0400, Jeff King wrote:
git-clean uses read_directory to fill in a `struct dir` with
potential hits. However, read_directory does not actually
check against our pathspec. It uses a simplified version
that may turn up false positives. As a result, we need
On Mon, Mar 10, 2014 at 10:46:01AM -0700, Junio C Hamano wrote:
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapper, which makes JGit significantly less
portable. I know SQLLite is pretty amazing, but implementing
compatibility with it from JGit will
On Mon, Mar 10, 2014 at 05:14:02PM +0100, David Kastrup wrote:
[storing refs in sqlite]
Of course, the basic premise for this feature is let's assume that our
file and/or operating system suck at providing file system functionality
at file name granularity. There have been two historically
On Mon, Mar 10, 2014 at 08:27:25PM +0100, Benoit Pierre wrote:
Those happens with gcc -Wformat-zero-length. Since passing NULL does not
generate a warning (as __attribute__((printf())) does not imply nonull),
modify
status_printf/status_printf_ln to allow a NULL format and update calls with
On Mon, Mar 10, 2014 at 07:49:34PM +0100, Benoit Pierre wrote:
Don't change git environment: move the GIT_EDITOR=: override to the
hook command subprocess, like it's already done for GIT_INDEX_FILE.
Signed-off-by: Benoit Pierre benoit.pie...@gmail.com
---
builtin/checkout.c
On Mon, Mar 10, 2014 at 09:02:35PM +0100, Simon Ruderich wrote:
On Mon, Mar 10, 2014 at 01:22:15PM -0400, Jeff King wrote:
+test_expect_success 'git clean -d respects pathspecs' '
+ mkdir foo
+ mkdir foobar
+ git clean -df foobar
+ test_path_is_dir foo
On Sun, Mar 09, 2014 at 02:04:16AM +0900, Brian Gesiak wrote:
Once the logic is extracted into a nice API, there are
several other places that can use it, too: ...
I've found the following four areas so far:
1. lockfile.lock_file
2. git-compat-util.odb_mkstemp
3.
On Fri, Feb 28, 2014 at 03:03:52PM +0100, Michael Haggerty wrote:
I'm not sure whether it is a good idea or not. But I think it is looking
decreasingly like a good GSoC project.
I guess I misread the sentiment of the mailing list, because I merged
this idea into the list about two hours
On Sun, Feb 23, 2014 at 09:44:14AM +0700, Duy Nguyen wrote:
(Digging up an old thread about initial refs listing in git protocol)
And now I am responding to it slowly. :)
For that to work, the new server needs to wait for the client to
speak first. How would that server handle old clients
On Sat, Mar 08, 2014 at 07:21:39PM +, brian m. carlson wrote:
We shrink the source and destination arrays, but not the modes or
submodule_gitfile arrays, resulting in potentially mismatched data. Shrink
all the arrays at the same time to prevent this.
Signed-off-by: brian m. carlson
On Tue, Mar 11, 2014 at 06:56:02PM +0100, Benoit Pierre wrote:
According to the original commit, the change to GIT_EDITOR is only
here for hooks:
commit 406400ce4f69e79b544dd3539a71b85d99331820
Author: Paolo Bonzini bonz...@gnu.org
Date: Tue Feb 5 11:01:45 2008 +0100
git-commit:
On Tue, Mar 11, 2014 at 05:27:05PM +0100, Michael Haggerty wrote:
Thanks for your proposal. I have a technical point that I think your
proposal should address:
Currently the linked list of lockfiles only grows, never shrinks. Once
an object has been linked into the list, there is no way
On Tue, Mar 11, 2014 at 12:32:37PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I think the main flag of interest is giving an fnmatch pattern to limit
the advertised refs. There could potentially be others, but I do not
know of any offhand.
One thing that comes
On Tue, Mar 11, 2014 at 01:25:23PM -0700, Junio C Hamano wrote:
Yeah, good idea. I might be misremembering some complications, but we
can probably do it with:
1. Teach the client to send an advertise-symrefs flag before the ref
advertisement.
2. Teach the server to include
On Mon, Mar 10, 2014 at 10:24:12PM +0100, Heiko Voigt wrote:
I have also moved all functions into the new submodule-config-cache
module. I am not completely satisfied with the naming since it is quite
long. If someone comes up with some different naming I am open for it.
Maybe simply
On Wed, Mar 12, 2014 at 10:43:54AM -0400, Quint Guvernator wrote:
memcmp() is replaced with negated starts_with() when comparing strings
from the beginning. starts_with() looks nicer and it saves the extra
argument of the length of the comparing string.
Thanks, I think this is a real
On Wed, Mar 12, 2014 at 06:22:24PM +0100, Jens Lehmann wrote:
Let me know if you still think the hunk should be dropped there.
Yes, I think so. That spot uses memcmp() because ce-name may
not be 0-terminated. If that assumption isn't correct, it should
be replaced with a plain strcmp()
On Wed, Mar 12, 2014 at 08:16:53PM +0100, David Kastrup wrote:
Junio C Hamano gits...@pobox.com writes:
Here is another, as I seem to have managed to kill another one ;-)
-- 8 --
VAR=VAL command is sufficient to run 'command' with environment
variable VAR set to value VAL without
On Tue, Mar 11, 2014 at 03:12:11PM -0700, Junio C Hamano wrote:
* jk/warn-on-object-refname-ambiguity (2014-01-09) 6 commits
- get_sha1: drop object/refname ambiguity flag
- get_sha1: speed up ambiguous 40-hex test
- FIXUP: teach DO_FOR_EACH_NO_RECURSE to prime_ref_dir()
- refs: teach
On Wed, Mar 12, 2014 at 12:39:01PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
static inline int standard_header_field(const char *field, size_t len)
{
- return ((len == 4 !memcmp(field, tree , 5)) ||
- (len == 6 !memcmp(field, parent , 7
On Thu, Mar 13, 2014 at 02:51:29AM +0800, Yuxuan Shui wrote:
Since fsck_ident doesn't change the content of **ident, the type of
ident could be const char **.
Unfortunately, const double-pointers in C are a bit tricky, and a
pointer to char * cannot automatically be passed as a pointer to
On Wed, Mar 12, 2014 at 09:37:41PM +0100, David Kastrup wrote:
Try:
zippo() {
echo $XXX
}
XXX=8 zippo
zippo
XXX remains set after the first call under dash (but not bash). I
believe ash has the same behavior.
Yes. I would lean towards considering this a bug.
On Wed, Mar 12, 2014 at 01:08:03PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Blindly replacing starts_with() with !memcmp() in the above part is
a readability regression otherwise.
I actually think the right solution is:
static inline int standard_header_field
On Wed, Mar 12, 2014 at 05:14:15PM -0400, Jeff King wrote:
I also think that eof = next (which I retained here) is off-by-one.
next here is not the newline, but the start of the next line. And I'm
guessing the code actually wanted the newline (otherwise it-key ends
up with the newline
On Wed, Mar 12, 2014 at 05:14:15PM -0400, Jeff King wrote:
One thing that bugs me about the current code is that the sub-function
looks one past the end of the length given to it by the caller.
Switching it to pass eof - line + 1 resolves that, but is it right?
The character pointed
On Thu, Mar 13, 2014 at 10:19:06AM +0100, Michael Haggerty wrote:
These patches are proposed for maint (but also apply cleanly to
master).
I presume that this is exploitable via Git commands, though I haven't
verified it explicitly [1].
It's possible to overflow this buffer, like:
git
On Thu, Mar 13, 2014 at 10:47:28AM -0700, Junio C Hamano wrote:
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -82,7 +82,7 @@ static int cat_one_file(int opt, const char *exp_type,
const char *obj_name)
enum object_type type;
On Wed, Mar 12, 2014 at 05:21:21PM -0700, Shawn Pearce wrote:
Today I tried pushing a copy of linux.git from a client that had
bitmaps into a JGit server. The client stalled for a long time with no
progress, because it reused the existing pack. No progress appeared
while it was sending the
On Thu, Mar 13, 2014 at 03:01:09PM -0700, Shawn Pearce wrote:
It would definitely be good to have throughput measurements while
writing out the pack. However, I'm not sure we have anything useful to
count. We know the total number of objects we're reusing, but we're not
actually parsing
On Thu, Mar 13, 2014 at 06:07:54PM -0400, Jeff King wrote:
3. Use the regular Writing objects progress, but fake the object
count. We know we are writing M bytes with N objects. Bump the
counter by 1 for every M/N bytes we write.
Here is that strategy. I think it looks pretty nice
301 - 400 of 13736 matches
Mail list logo
