When 'FILE *fp' is assigned to child_process.out and then start_command or run_command is run, the standard output of the child process is expected to be outputed to fp. However, sometimes fp is not expected to be closed since further IO may be still performmed on fp. --- run-command.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/run-command.c b/run-command.c index 476d00c..4e5f58d 100644 --- a/run-command.c +++ b/run-command.c @@ -115,13 +115,9 @@ int start_comma...

status.color shouldn't be honored when committing since the run-status output is fed to the editor. --- builtin-commit.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/builtin-commit.c b/builtin-commit.c index 8db74ed..4396e7d 100644 --- a/builtin-commit.c +++ b/builtin-commit.c @@ -45,6 +45,7 @@ static int quiet, verbose, untracked_files, no_verify; static int no_edit, initial_commit, in_merge; const char *only_include_assumed; struct strbuf message; +extern int...

It should run with $GIT_DIR/COMMIT_EDITMSG, not just COMMIT_EDITMSG. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- * Other things I noticed that are still broken: - "git commit -v" does not give you the diff in the message template for your final review; - message_is_empty() is bogus. It does run stripspace() but does not strip out the diff "git commit -v" would produce before doing its comparison; builtin-commit.c | 2 +- 1 files changed, 1 inser...

What's causing this? I'm using stgit on the master branch. I'm fixing it each time on the remote server by deleting the ref to master. jonsmirl@terra:~/ds$ git push digispeaker To ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git ! [rejected] master -> master (non-fast forward) error: failed to push to 'ssh://jonsmirl1@git.digispeaker.com/~/projects/digispeaker-kernel.git' jonsmirl@terra:~/ds$ On the server I have: [core] repositoryformatversion = 0 ...

stgit must be doing this when I rebase. It pops all of it's patches, moves to head of linus/master and then rebases them. What is the right way to share repositories using stgit? I have a set of patches which I am working on for kernel inclusion. I have them applied as a stgit stack on top of linus/master. I need to share this patch stack with other developers. These developers may want to change one of my patches. Right now they are emailing me deltas and I apply them to the appropriate stgit ...

I run the daemon against a base directory with all my repos. /repositories + /blingon + /config + /thepia + /config The config directories are git repositories, and the repos are made available with the following command: henrik-computer:~ x$ git daemon --export-all --verbose --base-path=/repositories [337] Connection from 192.168.9.130:56583 [337] Extended attributes (20 bytes) exist <host=192.168.9.165> [337] Request upload-pack for '/blingon/all' [337] Disconnected ...

As you know, repo.or.cz uses alternates in order to reduce the space that the repositories of forked projects require. Recently, it happened that a fork (4msysgit.git) became broken because it was using an object that was pruned away from the repository that it was borrowing from (mingw.git). This happened even though 4msysgit did not use the branch of mingw.git that was rebased and whose objects were pruned. The reason is that a merge in 4msysgit.git resulted in a blob that was also in the r...

Well, I think in many situations pack and prune can be controlled. To be precise, if alternates are used pack and prune *must* be controlled. Currently, the control is very simple: "don't prune" (and I don't recall ATM what you must not do when you repack). Anyway, judging from the responses so far it seems that people can live with "don't prune" (or not using alternates) ;-) Repositories getting broken this way isn't exactly my itch, either, so... I spelled out a possible solution if someo...

This function is used to see if a path given by the user does exist on the filesystem. A symbolic link that does not point anywhere does exist but running stat() on it would yield an error, and it incorrectly said it does not exist. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- dir.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/dir.c b/dir.c index 01790ab..87e5dec 100644 --- a/dir.c +++ b/dir.c @@ -688,11 +688,10 @@ int read_directory(struct d...

This separates the logic to limit the extent of change to the index by where you are (controlled by "prefix") and what you specify from the command line (controlled by "pathspec"). Signed-off-by: Junio C Hamano <gitster@pobox.com> --- builtin-add.c | 8 +++++--- cache.h | 4 +++- commit.h | 1 - 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/builtin-add.c b/builtin-add.c index 45b14e8..16f8557 100644 --- a/builtin-add.c +++ b/builtin-add.c @@ -111,1...

- read the index file after pre-commit hook returns, as the This ", but keep the addition" is no longer necessary; the set of paths discovered in step (0) _will_ include the added paths -

The above four are to be applied on top of kh/commit series, (without the WIP I sent out last night) on top of Dscho's "Replace "runstatus" with "status" in the tests" patch. With these, all tests in t/ finally passes for me ;-) But I am not a heavy user of partial commits nor commits from subdirectories, so there may still be breakages. -

Because this function is static and used only by the http-walker, when NO_CURL is defined, gcc emits a "defined but not used" warning. Signed-off-by: Jeff King <peff@peff.net> --- On master. I like to compile with -Werror to make sure I don't miss warnings as the compile scrolls by. This fix feels a little wrong, since the function isn't specific to http support, but hopefully the comment should be obvious if we ever add another similar commit walker that needs it. transport.c | 2 ...

This has always been slightly inaccurate, since it used the new_refs counter, which really meant "did we send any objects," so deletions were not counted. It has gotten even worse with recent patches, since we no longer look at the 'ret' value, meaning we would say "up to date" if non-ff pushes were rejected. Instead, we now claim up to date iff every ref is either unmatched or up to date. Any other case should already have generated a status line. Signed-off-by: Jeff King <peff@peff.net&g...

Previously, we set all ref pushes to 'OK', and then marked them as errors if the remote reported so. This has the problem that if the remote dies or fails to report a ref, we just assume it was OK. Instead, we use a new non-OK state to indicate that we are expecting status (if the remote doesn't support the report-status feature, we fall back on the old behavior). Thus we can flag refs for which we expected a status, but got none (conversely, we now also print a warning for refs for which we get ...

This turned out to be pretty easy, given the other recent changes, and I think it actually makes the code a bit clearer. Please scrap the patch to which I am replying, and I will post a replacement series in a second. -Peff -

When building command line to invoke external grep, the arguments to -A/-B/-C options were placd in randarg[] buffer, but the code forgot that snprintf() does not count terminating NUL in its return value. This caused "git grep -A1 -B2" to invoke external grep with "-B21 -A1". Signed-off-by: Junio C Hamano <gitster@pobox.com> --- * This bug was present since mid May, 2006. builtin-grep.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/builtin-grep.c b/...

If the rationale was "running in a thread is more natural on the platform", I would understand it. But "_must_ run because there is no fork(2)" solicits a "Huh? How does Cygwin does it then?" from me. -

Wholeheartedly agree, and I feel dirty after looking at that thing. Nothing against Cygwin folks, of course. The reason I wanted to close pipes as early as possible was because I did not want to get bitten by "read() waiting forever for EOF due to an extra unclosed fd on the writer end of the pipe() without the writer not writing anything to it" problem, which is an often-seen mistake. As long as you did not introduce that problem the change is fine by me. -

You wont believe it: they start the currently running program again and copy parents memory over into the child. Sometimes it fails. If you want something scary: http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fork.cc?rev=1.193&content-t... -

Not necessarily. The policy is completely up to the superproject (which is git.git). Currently, the policy is "make all" and "make install" in git.git builds and installs what are considered core parts of the system which includes git-gui and gitk. gitk nor git-gui should not become useless without being in git.git (iow, their build procedure better not depend on things outside their subtree), but I do not think that is a hard requirement either. Shawn *chose* to keep git-gui buildable and ...

It is actually _just_ prefixcmp. Or do you mean the strlen we call in prefixcmp? If so, I think the right solution is to make prefixcmp Nothing else sets the string, so the latter is not possible (perhaps it should be "remote_error" for clarity). It is less clear that we are not overwriting another status; however, if you look at do_send_pack, we only actually send the remote refs that are getting REF_STATUS_OK. A broken or malicious remote could change the push status of an arbitrary ref t...

I don't see such a strlen, except in the implementation of prefixcmp, because we continue most of the time based on its result. If you have a false match on the prefixcmp (i.e., a prefix of another ref), you do an extra strlen. But I don't think this is worth micro-optimizing. -Peff -

I see you fixed up the off-by-one buffer, too. Thanks. -Peff -

I think Daniel is referring to "Put 'else' on the same line as the brace that closes the corresponding 'if' opened", iow: if (...) { ... } else { ... } -