* Re: How can I tell if a file has been updated upstream?
From: Timur Tabi @ 2010-02-05 16:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20100205164407.GA27498@spearce.org>
On Fri, Feb 5, 2010 at 10:44 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> You can't tell a particular file, but you could use something like
> `git ls-remote refs/heads/master` to see what the branch is at,
$ git ls-remote refs/heads/master
fatal: 'refs/heads/master' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
So maybe you meant this:
$ git ls-remote ssh://git.am.freescale.net/git/timur/bin refs/heads/master
20fbe12069038057cbd0d66c5a673956f7792c7d refs/heads/master
I can use this to compare with the local HEAD. However, this only
tells me that the repository as a whole has changed. I was hoping
there would be a way to see if just the one file has change. I.e. how
can I get the HEAD of a *file* in a remote repository.
> I do this in repo, only I run `git fetch` once per day for the
> end-user. That way the objects are local, and I can use a local
> check to see if there are updates that need to be pulled into the
> executable working directory.
Yeah, I'm not keen on performing an actual download, even if it's just a fetch.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: How can I tell if a file has been updated upstream?
From: Timur Tabi @ 2010-02-05 16:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk4urbp9u.fsf@alter.siamese.dyndns.org>
On Fri, Feb 5, 2010 at 10:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> So whenever I run your script it calls home, spend a roundtrip time, and
> nags me to update?
Yes. Fortunately, it's all on an internal network, so the overhead is low.
> I don't want to be working with you unless I can go
> without running that script less often than once a week ;-)
That's about how often most people will run the script.
> You need to teach it how to call home. How do your users "clone"?
git clone git://....
Only I have ssh access to my repository.
> Also how do they run the script? Directly out of the
> repository work tree, or is there a "make install" step involved?
Directly out of the repository. It's just a Python script.
> If your users are running from the work tree copy unmodified, then you
> would need to look at sys.argv[0] to find out where it is, use that to
> find the repository, and using its .git/config learn how the user pulls
> from your repository (i.e. git config remote.origin.url), and at the same
> time which version it is (i.e. git rev-parse HEAD).
Ok.
> At runtime, you would run "ls-remote HEAD" and compare with the version
> you are running. It may be stale, or it may not be.
Ok.
> How big is the script? It _might_ be faster to distribute a launcher that
> downloads the real script every time it runs and runs that fresh copy that
> is guaranteed to be the latest than doing all the hassle of the above.
I don't want to force an update, and I don't want to have to email
everyone whenever there is an update. This seems to be the least
intrusive approach.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: notes TODOs (was: Re: [PATCH 1/4] gitweb: notes feature)
From: Giuseppe Bilotta @ 2010-02-05 16:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johan Herland, Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <201002051627.05182.jnareb@gmail.com>
On Fri, Feb 5, 2010 at 4:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Fri, 5 Feb 2010, Johan Herland wrote:
>> On Friday 05 February 2010, Giuseppe Bilotta wrote:
>
>> > If I may be allowed to add a suggestion to put in the list, I would
>> > like to see notes attachable to named refs (branch heads in
>> > particular). From a cursory reading of your patches currently in pu
>> > it would seem that you explicitly prohibit this case currently.
>> > However, this has many possible uses, ranging from longer branch
>> > descriptions to tracking information to improve survival in case of
>> > remote rebases.
>>
>> Nope. There is no explicit prohibition on anything. On a fundamental
>> level, Git-notes simply maps a given SHA1 (the annotated object) to
>> another SHA1 (the object holding the annotation itself). In principle
>> you can annotate _any_ SHA1, it doesn't even have to exist as a git
>> object!
>
> I guess that it isn't currently possible to map _path_ (here: fully
> qualified name of ref, i.e. "refs/heads/master" in example) to SHA1
> rather than SHA1 to SHA1, as fan-outs assumes mapping of SHA1 (to
> object).
>
>>
>> In fact, something like the following abomination should solve
>> your "problem" quite easily:
>>
>> git notes add $(echo "refs/heads/master" | git hash-object --stdin)
>>
>> (...washing my hands...)
>
> This actually annotates (existing or not) _blob_ object with
> "refs/heads/master" as contents (git-hash-object defaults to -t blob).
Well, it still might work assuming the git tools know that they have
to look for these notes too when looking notes up. If we tolerate the
funky failure in the unlikely case of a file whose content matches a
ref name, it could be used to implement the feature without having to
remove the assumption that notes pretargets are SHA1. I do believe
that removing that assumption would be a smoother way to go, although
I have no idea how hard it would be to implement.
>> > And one last comment: how do notes behave wrt to cloning and remote
>> > handling? Am I correct in my understanding that notes are
>> > (presently) local only? Would it make sense to have them cloned to
>> > something like the refs/notes/remotes/* namespace?
>>
>> They are no more local than any other ref, except that they are
>> outside the refspecs that are "usually" pushed/fetched (refs/heads/
>> and refs/tags/).
>>
>> git push <remote> refs/notes/<foo>
>> git fetch <remote> refs/notes/<foo>[:refs/notes/<foo>]
>> etc.
>>
>> should all work as expected.
>
> It would be nice, but I guess not possible, to have notes autofollowed
> on fetch, like tags are autofollowed...
Tags have the idiosincracy of living in the same namespace regardless
of where they come from, and I believe there a little too high a risk
of conflicts to do this with notes too. It might make sense to add a
default fetch of +refs/notes/*:refs/notes/remotes/<remote>/*, but the
real question is what would pushing do, in case of conflicting notes.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] Remove .git auto detection from setup_git_env()
From: Junio C Hamano @ 2010-02-05 17:22 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git, René Scharfe
In-Reply-To: <20100205151239.GC14116@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It has been a while since I looked at this code, but I think this is a
> good direction forward. I remember trying something like this and
> getting discouraged at all of the ensuing breakage. So if you can track
> down all of the fallouts and fix them, I think we will be better off in
> the long run.
I agree.
This topic started from "We broke 'git grep' in .git directory" and I
think it is the sanest to revert 3081623 (grep --no-index: allow use of
"git grep" outside a git repository, 2010-01-15) which nobody has used so
far in any released version of git, until we sort this out at least.
Every time we touch work-tree related codepath (like René's patch does) we
seem to inadvertently break something else. It's too late for that kind
of fixes for this cycle and "grep --no-index" should go.
-- >8 --
Subject: [PATCH] Revert 308162372d0aa202ff45743e02253e20a4fac4d7
It seems that we have bad interaction with the code related to
GIT_WORK_TREE and "grep --no-index", and broke running grep inside
the .git directory. For now, just revert it and resurrect it after
1.7.0 ships.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/RelNotes-1.7.0.txt | 3 --
builtin-grep.c | 33 ------------------------
t/t7002-grep.sh | 52 --------------------------------------
3 files changed, 0 insertions(+), 88 deletions(-)
diff --git a/Documentation/RelNotes-1.7.0.txt b/Documentation/RelNotes-1.7.0.txt
index 255666f..f632662 100644
--- a/Documentation/RelNotes-1.7.0.txt
+++ b/Documentation/RelNotes-1.7.0.txt
@@ -133,9 +133,6 @@ Updates since v1.6.6
* "git grep" does not rely on external grep anymore. It can use more than
one threads to accelerate the operation.
- * "git grep" learned "--no-index" option, to search inside contents that
- are not managed by git.
-
* "git grep" learned "--quiet" option.
* "git log" and friends learned "--glob=heads/*" syntax that is a more
diff --git a/builtin-grep.c b/builtin-grep.c
index 0ef849c..bff1e68 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -14,7 +14,6 @@
#include "userdiff.h"
#include "grep.h"
#include "quote.h"
-#include "dir.h"
#ifndef NO_PTHREADS
#include "thread-utils.h"
@@ -646,24 +645,6 @@ static int grep_object(struct grep_opt *opt, const char **paths,
die("unable to grep from object of type %s", typename(obj->type));
}
-static int grep_directory(struct grep_opt *opt, const char **paths)
-{
- struct dir_struct dir;
- int i, hit = 0;
-
- memset(&dir, 0, sizeof(dir));
- setup_standard_excludes(&dir);
-
- fill_directory(&dir, paths);
- for (i = 0; i < dir.nr; i++) {
- hit |= grep_file(opt, dir.entries[i]->name);
- if (hit && opt->status_only)
- break;
- }
- free_grep_patterns(opt);
- return hit;
-}
-
static int context_callback(const struct option *opt, const char *arg,
int unset)
{
@@ -762,8 +743,6 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
struct option options[] = {
OPT_BOOLEAN(0, "cached", &cached,
"search in index instead of in the work tree"),
- OPT_BOOLEAN(0, "index", &use_index,
- "--no-index finds in contents not managed by git"),
OPT_GROUP(""),
OPT_BOOLEAN('v', "invert-match", &opt.invert,
"show non-matching lines"),
@@ -950,18 +929,6 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
paths[1] = NULL;
}
- if (!use_index) {
- int hit;
- if (cached)
- die("--cached cannot be used with --no-index.");
- if (list.nr)
- die("--no-index cannot be used with revs.");
- hit = grep_directory(&opt, paths);
- if (use_threads)
- hit |= wait_all();
- return !hit;
- }
-
if (!list.nr) {
int hit;
if (!cached)
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index bf4d4dc..7144f81 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -434,56 +434,4 @@ test_expect_success 'grep -Fi' '
test_cmp expected actual
'
-test_expect_success 'outside of git repository' '
- rm -fr non &&
- mkdir -p non/git/sub &&
- echo hello >non/git/file1 &&
- echo world >non/git/sub/file2 &&
- echo ".*o*" >non/git/.gitignore &&
- {
- echo file1:hello &&
- echo sub/file2:world
- } >non/expect.full &&
- echo file2:world >non/expect.sub
- (
- GIT_CEILING_DIRECTORIES="$(pwd)/non/git" &&
- export GIT_CEILING_DIRECTORIES &&
- cd non/git &&
- test_must_fail git grep o &&
- git grep --no-index o >../actual.full &&
- test_cmp ../expect.full ../actual.full
- cd sub &&
- test_must_fail git grep o &&
- git grep --no-index o >../../actual.sub &&
- test_cmp ../../expect.sub ../../actual.sub
- )
-'
-
-test_expect_success 'inside git repository but with --no-index' '
- rm -fr is &&
- mkdir -p is/git/sub &&
- echo hello >is/git/file1 &&
- echo world >is/git/sub/file2 &&
- echo ".*o*" >is/git/.gitignore &&
- {
- echo file1:hello &&
- echo sub/file2:world
- } >is/expect.full &&
- : >is/expect.empty &&
- echo file2:world >is/expect.sub
- (
- cd is/git &&
- git init &&
- test_must_fail git grep o >../actual.full &&
- test_cmp ../expect.empty ../actual.full &&
- git grep --no-index o >../actual.full &&
- test_cmp ../expect.full ../actual.full &&
- cd sub &&
- test_must_fail git grep o >../../actual.sub &&
- test_cmp ../../expect.empty ../../actual.sub &&
- git grep --no-index o >../../actual.sub &&
- test_cmp ../../expect.sub ../../actual.sub
- )
-'
-
test_done
--
1.7.0.rc1.204.gb96e5
^ permalink raw reply related
* Re: [PATCH] Remove .git auto detection from setup_git_env()
From: Junio C Hamano @ 2010-02-05 17:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Nguyễn Thái Ngọc Duy, git,
René Scharfe
In-Reply-To: <7vy6j7a98f.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> This topic started from "We broke 'git grep' in .git directory" and I
> think it is the sanest to revert 3081623 (grep --no-index: allow use of
> "git grep" outside a git repository, 2010-01-15) which nobody has used so
> far in any released version of git, until we sort this out at least.
Sorry; spoke too fast. We'd also need to revert the one to git.c (7e62265
(grep: prepare to run outside of a work tree, 2010-01-15) as well.
diff --git a/builtin-grep.c b/builtin-grep.c
index bff1e68..26d4deb 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -739,7 +739,6 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
const char **paths = NULL;
int i;
int dummy;
- int nongit = 0, use_index = 1;
struct option options[] = {
OPT_BOOLEAN(0, "cached", &cached,
"search in index instead of in the work tree"),
@@ -825,8 +824,6 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
OPT_END()
};
- prefix = setup_git_directory_gently(&nongit);
-
/*
* 'git grep -h', unlike 'git grep -h <pattern>', is a request
* to show usage information and exit.
@@ -864,10 +861,6 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
PARSE_OPT_STOP_AT_NON_OPTION |
PARSE_OPT_NO_INTERNAL_HELP);
- if (use_index && nongit)
- /* die the same way as if we did it at the beginning */
- setup_git_directory();
-
/* First unrecognized non-option token */
if (argc > 0 && !opt.pattern_list) {
append_grep_pattern(&opt, argv[0], "command line", 0,
diff --git a/git.c b/git.c
index b3e23f1..4c3028c 100644
--- a/git.c
+++ b/git.c
@@ -317,7 +317,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "fsck-objects", cmd_fsck, RUN_SETUP },
{ "gc", cmd_gc, RUN_SETUP },
{ "get-tar-commit-id", cmd_get_tar_commit_id },
- { "grep", cmd_grep, USE_PAGER },
+ { "grep", cmd_grep, RUN_SETUP | USE_PAGER },
{ "hash-object", cmd_hash_object },
{ "help", cmd_help },
{ "index-pack", cmd_index_pack },
^ permalink raw reply related
* Re: [PATCH] push: Use sideband channel for hook messages
From: Shawn O. Pearce @ 2010-02-05 17:29 UTC (permalink / raw)
To: kusmabite; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <40aa078e1002050814m1edb90f8lf3d8d138fa65c332@mail.gmail.com>
Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> On Fri, Feb 5, 2010 at 4:51 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > I do agree about the over-engineering aspect. I mentioned it because in
> > one patch in the past Erik Faye-Lund also extended the async
> > infrastructure for bidirectional communication to use it in git-daemon
> > (Windows port).
>
> Just for reference, here's the latest version I wrote of that patch,
> in case it's useful to have a peak at or something:
>
> http://repo.or.cz/w/git/kusma.git/commit/682d90a174fc128910c1c8a4f81edb3cf9f0d9e2
Thanks Erik. This is actually somewhat close to what I need.
I'm going to take your patch and include it in my series, with
some fixups. I'll CC you on it when I send it out later.
--
Shawn.
^ permalink raw reply
* Re: How can I tell if a file has been updated upstream?
From: Nicolas Pitre @ 2010-02-05 17:39 UTC (permalink / raw)
To: Timur Tabi; +Cc: Shawn O. Pearce, git
In-Reply-To: <ed82fe3e1002050856v68d4d02bnbe18394bebac2f4d@mail.gmail.com>
On Fri, 5 Feb 2010, Timur Tabi wrote:
> So maybe you meant this:
>
> $ git ls-remote ssh://git.am.freescale.net/git/timur/bin refs/heads/master
> 20fbe12069038057cbd0d66c5a673956f7792c7d refs/heads/master
>
> I can use this to compare with the local HEAD. However, this only
> tells me that the repository as a whole has changed. I was hoping
> there would be a way to see if just the one file has change. I.e. how
> can I get the HEAD of a *file* in a remote repository.
You can't.
You must perform a fetch and then use whatever method to compare with
origin/master:foobar.py which is the file you're looking for.
> Yeah, I'm not keen on performing an actual download, even if it's just a fetch.
Why? It is not like if a fetch was terribly more costly than any method
that could get the version of a file on the remote.
Nicolas
^ permalink raw reply
* Re: creating a new branch without an ancestor
From: Wesley J. Landaker @ 2010-02-05 18:38 UTC (permalink / raw)
To: Michael Wookey; +Cc: Git Mailing List
In-Reply-To: <d2e97e801002041919r2043d05cjfb114a466605d9a1@mail.gmail.com>
On Thu, February 4, 2010 20:19, Michael Wookey wrote:
> Maybe I'm missing something from reading the docs, but I couldn't see
> how to create a new branch in an existing repo that has no ancestor. I
> would like to do something like what git.git does with some of the
> other ancillary branches like "man", "html", and "todo".
>
> I was hoping to do something like "git branch --no-ancestor
> new-branch-name" but didn't see anything in the documentation that
> describes the necessary branch options.
>
> Or, am I looking in the wrong place?
I do this all the time for various reasons, so I made myself a
"git-emptybranch" command and stuck it in my path. Besides the error
checking, this just creates a new ref and clears the index so you can
start from a clean slate. No actual files are deleted from the work-tree.
$ cat ~/bin/git-emptybranch
#!/bin/sh
if [ $# -ne 1 ]; then
2<&1
echo "usage: git emptybranch <new_branch>"
exit 1
fi
if ! git check-ref-format refs/heads/"$1"; then
2<&1
echo "fatal: '$1' is not a valid branch name."
exit 1
fi
git symbolic-ref -m "git emptybranch $1" HEAD refs/heads/"$1"
git rm --cached -r -q --ignore-unmatch -- '*'
^ permalink raw reply
* [PATCH 3/3] make git push --dry-run --porcelain exit with status 0 even if updates will be rejected
From: Larry D'Anna @ 2010-02-05 19:34 UTC (permalink / raw)
To: git; +Cc: Larry D'Anna
In-Reply-To: <20100205150638.GB14116@coredump.intra.peff.net>
The script calling git push --dry-run --porcelain can see clearly from the
output that the updates will be rejected. However, it will probably need to
distinguish this condition from the push failing for other reasons, such as the
remote not being reachable.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
---
builtin-send-pack.c | 5 +++++
send-pack.h | 1 +
transport.c | 11 +++++++++--
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 76c7206..dfd7470 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -478,6 +478,11 @@ int send_pack(struct send_pack_args *args,
return ret;
for (ref = remote_refs; ref; ref = ref->next) {
switch (ref->status) {
+ case REF_STATUS_REJECT_NONFASTFORWARD:
+ case REF_STATUS_REJECT_NODELETE:
+ if (args->porcelain && args->dry_run)
+ break;
+ return -1;
case REF_STATUS_NONE:
case REF_STATUS_UPTODATE:
case REF_STATUS_OK:
diff --git a/send-pack.h b/send-pack.h
index 28141ac..60b4ba6 100644
--- a/send-pack.h
+++ b/send-pack.h
@@ -4,6 +4,7 @@
struct send_pack_args {
unsigned verbose:1,
quiet:1,
+ porcelain:1,
send_mirror:1,
force_update:1,
use_thin_pack:1,
diff --git a/transport.c b/transport.c
index f707c7b..e61d288 100644
--- a/transport.c
+++ b/transport.c
@@ -558,10 +558,16 @@ static int fetch_refs_via_pack(struct transport *transport,
return (refs ? 0 : -1);
}
-static int push_had_errors(struct ref *ref)
+static int push_had_errors(struct ref *ref, int flags)
{
for (; ref; ref = ref->next) {
switch (ref->status) {
+ case REF_STATUS_REJECT_NONFASTFORWARD:
+ case REF_STATUS_REJECT_NODELETE:
+ if (flags & TRANSPORT_PUSH_DRY_RUN && flags & TRANSPORT_PUSH_PORCELAIN)
+ break;
+ else
+ return 1;
case REF_STATUS_NONE:
case REF_STATUS_UPTODATE:
case REF_STATUS_OK:
@@ -791,6 +797,7 @@ static int git_transport_push(struct transport *transport, struct ref *remote_re
args.verbose = !!(flags & TRANSPORT_PUSH_VERBOSE);
args.quiet = !!(flags & TRANSPORT_PUSH_QUIET);
args.dry_run = !!(flags & TRANSPORT_PUSH_DRY_RUN);
+ args.porcelain = !!(flags & TRANSPORT_PUSH_PORCELAIN);
ret = send_pack(&args, data->fd, data->conn, remote_refs,
&data->extra_have);
@@ -1052,7 +1059,7 @@ int transport_push(struct transport *transport,
flags & TRANSPORT_PUSH_FORCE);
ret = transport->push_refs(transport, remote_refs, flags);
- err = push_had_errors(remote_refs);
+ err = push_had_errors(remote_refs, flags);
ret |= err;
--
1.7.0.rc1.33.g07cf0f.dirty
^ permalink raw reply related
* [PATCH 1/3] fix an error message in git-push so it goes to stderr
From: Larry D'Anna @ 2010-02-05 19:34 UTC (permalink / raw)
To: git; +Cc: Larry D'Anna
In-Reply-To: <20100205150638.GB14116@coredump.intra.peff.net>
Having it go to standard output interferes with git-push --porcelain.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
---
builtin-push.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 5633f0a..0a27072 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -124,9 +124,9 @@ static int push_with_options(struct transport *transport, int flags)
return 0;
if (nonfastforward && advice_push_nonfastforward) {
- printf("To prevent you from losing history, non-fast-forward updates were rejected\n"
- "Merge the remote changes before pushing again. See the 'Note about\n"
- "fast-forwards' section of 'git push --help' for details.\n");
+ fprintf(stderr, "To prevent you from losing history, non-fast-forward updates were rejected\n"
+ "Merge the remote changes before pushing again. See the 'Note about\n"
+ "fast-forwards' section of 'git push --help' for details.\n");
}
return 1;
--
1.7.0.rc1.33.g07cf0f.dirty
^ permalink raw reply related
* [PATCH 2/3] silence human readable info messages going to stderr from git push --porcelain
From: Larry D'Anna @ 2010-02-05 19:34 UTC (permalink / raw)
To: git; +Cc: Larry D'Anna
In-Reply-To: <20100205150638.GB14116@coredump.intra.peff.net>
These messages are redundant information to a script that's calling git-push.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
---
builtin-push.c | 4 ++--
transport.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 0a27072..3fa4516 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -111,7 +111,7 @@ static int push_with_options(struct transport *transport, int flags)
if (thin)
transport_set_option(transport, TRANS_OPT_THIN, "yes");
- if (flags & TRANSPORT_PUSH_VERBOSE)
+ if (flags & TRANSPORT_PUSH_VERBOSE && !(flags & TRANSPORT_PUSH_PORCELAIN))
fprintf(stderr, "Pushing to %s\n", transport->url);
err = transport_push(transport, refspec_nr, refspec, flags,
&nonfastforward);
@@ -123,7 +123,7 @@ static int push_with_options(struct transport *transport, int flags)
if (!err)
return 0;
- if (nonfastforward && advice_push_nonfastforward) {
+ if (!(flags & TRANSPORT_PUSH_PORCELAIN) && nonfastforward && advice_push_nonfastforward) {
fprintf(stderr, "To prevent you from losing history, non-fast-forward updates were rejected\n"
"Merge the remote changes before pushing again. See the 'Note about\n"
"fast-forwards' section of 'git push --help' for details.\n");
diff --git a/transport.c b/transport.c
index 3846aac..f707c7b 100644
--- a/transport.c
+++ b/transport.c
@@ -674,7 +674,7 @@ static void print_ok_ref_status(struct ref *ref, int porcelain)
static int print_one_push_status(struct ref *ref, const char *dest, int count, int porcelain)
{
- if (!count)
+ if (!count && !porcelain)
fprintf(stderr, "To %s\n", dest);
switch(ref->status) {
@@ -1067,10 +1067,10 @@ int transport_push(struct transport *transport,
if (!(flags & TRANSPORT_PUSH_DRY_RUN)) {
struct ref *ref;
for (ref = remote_refs; ref; ref = ref->next)
- update_tracking_ref(transport->remote, ref, verbose);
+ update_tracking_ref(transport->remote, ref, verbose && !porcelain);
}
- if (!quiet && !ret && !refs_pushed(remote_refs))
+ if (!quiet && !porcelain && !ret && !refs_pushed(remote_refs))
fprintf(stderr, "Everything up-to-date\n");
return ret;
}
--
1.7.0.rc1.33.g07cf0f.dirty
^ permalink raw reply related
* Re: [PATCH] fix an error message in git-push so it goes to stderr
From: Larry D'Anna @ 2010-02-05 19:39 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20100205150638.GB14116@coredump.intra.peff.net>
* Jeff King (peff@peff.net) [100205 10:06]:
> On Thu, Feb 04, 2010 at 07:41:40PM -0500, Larry D'Anna wrote:
>
> > Having it go to standard output interferes with git-push --porcelain.
> > ---
> > builtin-push.c | 6 +++---
> > 1 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/builtin-push.c b/builtin-push.c
> > index 5633f0a..0a27072 100644
> > --- a/builtin-push.c
> > +++ b/builtin-push.c
> > @@ -124,9 +124,9 @@ static int push_with_options(struct transport *transport, int flags)
> > return 0;
> >
> > if (nonfastforward && advice_push_nonfastforward) {
> > - printf("To prevent you from losing history, non-fast-forward updates were rejected\n"
> > - "Merge the remote changes before pushing again. See the 'Note about\n"
> > - "fast-forwards' section of 'git push --help' for details.\n");
> > + fprintf(stderr, "To prevent you from losing history, non-fast-forward updates were rejected\n"
> > + "Merge the remote changes before pushing again. See the 'Note about\n"
> > + "fast-forwards' section of 'git push --help' for details.\n");
>
> I agree that stderr is a more sensible place for such a message to go,
> but shouldn't the porcelain output format just suppress it entirely?
I think you're right. There are some other messages that are similar that
should probably also be suppressed.
Also it seems to me that git push --dry-run --porcelain should exit successfully
even if it knows some refs will be rejected. The calling script can see just
fine for itself that they will be rejected, and it probably still wants to know
whether or not the dry-run succeeded, which has nothing to do with whether or
not the same push would succeed as a not-dry-run.
--larry
^ permalink raw reply
* git gc / git repack not removing unused objects?
From: Jon Nelson @ 2010-02-05 19:45 UTC (permalink / raw)
To: git
[Using git 1.6.4.2]
In one repo I have (136G objects directory, fully packed) I'm having
some trouble.
I've run git-gc --prune=now, git repack -Adf, and so on a half-dozen
times and each time I do so it gets bigger, not smaller.
Setting that aside for the moment, however, I've run into a stranger problem.
So I use "git verify-pack -v > gvp.out" and "sort -k3nr < gvp.out |
head -n 20" to find the top 20 largest blobs.
So I have a blob, b32c3d8e8e24d8d3035cf52f606c2873315fe2b8, and now I
want to know what tree (or trees) it is in, so I try this:
for i in $( git branch -a | sed -e 's/\*//g' | grep -v branch ); do if
git ls-tree -l -r -t $i | grep
b32c3d8e8e24d8d3035cf52f606c2873315fe2b8 > /dev/null; then echo $i;
fi; done
The results: no branch or tree appears to contain that blob.
So I tried a different approach:
for i in $( grep tree gvp.out | awk '{ print $1 }' ); do if git
ls-tree $i | grep b32c3d8e8e24d8d3035cf52f606c2873315fe2b8 >
/dev/null; then echo $i; fi ; done
This time, I find (at least) one tree
(d813af1537358496ca34958bbff08b87590607bf) with the blob.
But which branches might that tree appear in? None.
For each branch, I ran "git ls-tree -l -r -t" and saved the output in
a file (one per branch).
Then I grepped each file for the tree (
(d813af1537358496ca34958bbff08b87590607bf) - no luck.
I grepped each file for the blob (b32...) - no luck.
The results seem to suggest that I have packed trees which reference
blobs, but that the trees themselves are not referenced in any branch
and therefore I would expect that they would be pruned.
--
Jon
^ permalink raw reply
* Re: [PATCH] fix an error message in git-push so it goes to stderr
From: Larry D'Anna @ 2010-02-05 19:50 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20100205194824.GD24474@coredump.intra.peff.net>
* Jeff King (jrk@wrek.org) [100205 14:48]:
> On Fri, Feb 05, 2010 at 02:39:50PM -0500, Larry D'Anna wrote:
>
> > Also it seems to me that git push --dry-run --porcelain should exit successfully
> > even if it knows some refs will be rejected. The calling script can see just
> > fine for itself that they will be rejected, and it probably still wants to know
> > whether or not the dry-run succeeded, which has nothing to do with whether or
> > not the same push would succeed as a not-dry-run.
>
> I think that is OK, but only if "git push --dry-run" still exits with an
> error case, since people may be using it for "will this push work?" and
> not simply "did an error occur?".
Yup. That's exactly what the patch I just posted does.
--larry
^ permalink raw reply
* Re: [PATCH] fix an error message in git-push so it goes to stderr
From: Jeff King @ 2010-02-05 19:50 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <20100205194824.GD24474@coredump.intra.peff.net>
On Fri, Feb 05, 2010 at 02:48:24PM -0500, Jeff King wrote:
> From: Jeff King <jrk@wrek.org>
Argh, stupid email configuration failure. Please address any followups
to my usual peff@peff.net.
-Peff
^ permalink raw reply
* Re: [PATCH] fix an error message in git-push so it goes to stderr
From: Jeff King @ 2010-02-05 19:48 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <20100205193950.GA18108@cthulhu>
On Fri, Feb 05, 2010 at 02:39:50PM -0500, Larry D'Anna wrote:
> Also it seems to me that git push --dry-run --porcelain should exit successfully
> even if it knows some refs will be rejected. The calling script can see just
> fine for itself that they will be rejected, and it probably still wants to know
> whether or not the dry-run succeeded, which has nothing to do with whether or
> not the same push would succeed as a not-dry-run.
I think that is OK, but only if "git push --dry-run" still exits with an
error case, since people may be using it for "will this push work?" and
not simply "did an error occur?".
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] make git push --dry-run --porcelain exit with status 0 even if updates will be rejected
From: Jeff King @ 2010-02-05 19:56 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <1265398462-17316-3-git-send-email-larry@elder-gods.org>
On Fri, Feb 05, 2010 at 02:34:22PM -0500, Larry D'Anna wrote:
> diff --git a/builtin-send-pack.c b/builtin-send-pack.c
> index 76c7206..dfd7470 100644
> --- a/builtin-send-pack.c
> +++ b/builtin-send-pack.c
> @@ -478,6 +478,11 @@ int send_pack(struct send_pack_args *args,
> return ret;
> for (ref = remote_refs; ref; ref = ref->next) {
> switch (ref->status) {
> + case REF_STATUS_REJECT_NONFASTFORWARD:
> + case REF_STATUS_REJECT_NODELETE:
> + if (args->porcelain && args->dry_run)
> + break;
> + return -1;
> case REF_STATUS_NONE:
> case REF_STATUS_UPTODATE:
> case REF_STATUS_OK:
Why just these two status flags? Based on your reasoning elsewhere, I
would assume the logic should be:
- if we had some transport-related error, return failure
- if not, then return success, as any ref's failure is already
indicated in the porcelain output
So shouldn't it just be:
if (args->porcelain && args->dry_run)
return 0;
after we check for transport errors but before the loop that you are
modifying.
> -static int push_had_errors(struct ref *ref)
> +static int push_had_errors(struct ref *ref, int flags)
> {
> for (; ref; ref = ref->next) {
> switch (ref->status) {
> + case REF_STATUS_REJECT_NONFASTFORWARD:
> + case REF_STATUS_REJECT_NODELETE:
> + if (flags & TRANSPORT_PUSH_DRY_RUN && flags & TRANSPORT_PUSH_PORCELAIN)
> + break;
> + else
> + return 1;
Ditto here.
-Peff
^ permalink raw reply
* [PATCH (resend)] Update git fsck --full short description to mention packs
From: Wesley J. Landaker @ 2010-02-05 19:58 UTC (permalink / raw)
To: git, gitster
The '--full' option to git fsck does two things:
1) Check objects in packs
2) Check alternate objects
This is documented in the git fsck manual; this patch reflects that in
the short git fsck option help message as well.
Signed-off-by: Wesley J. Landaker <wjl@icecavern.net>
---
builtin-fsck.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
I sent this patch a while back, and after the resulting discussion, the --full
option was made the default. However, the short option help was still not
updated to reflect the full documentation (and behavior) of git fsck.
(This is a resend. My apologies if you get this twice.)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 0e5faae..0929c7f 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -578,7 +578,7 @@ static struct option fsck_opts[] = {
OPT_BOOLEAN(0, "root", &show_root, "report root nodes"),
OPT_BOOLEAN(0, "cache", &keep_cache_objects, "make index objects head nodes"),
OPT_BOOLEAN(0, "reflogs", &include_reflogs, "make reflogs head nodes (default)"),
- OPT_BOOLEAN(0, "full", &check_full, "also consider alternate objects"),
+ OPT_BOOLEAN(0, "full", &check_full, "also consider packs and alternate objects"),
OPT_BOOLEAN(0, "strict", &check_strict, "enable more strict checking"),
OPT_BOOLEAN(0, "lost-found", &write_lost_and_found,
"write dangling objects in .git/lost-found"),
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH 3/3] make git push --dry-run --porcelain exit with status 0 even if updates will be rejected
From: Larry D'Anna @ 2010-02-05 20:05 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20100205195644.GE24474@coredump.intra.peff.net>
* Jeff King (peff@peff.net) [100205 14:56]:
> On Fri, Feb 05, 2010 at 02:34:22PM -0500, Larry D'Anna wrote:
>
> > diff --git a/builtin-send-pack.c b/builtin-send-pack.c
> > index 76c7206..dfd7470 100644
> > --- a/builtin-send-pack.c
> > +++ b/builtin-send-pack.c
> > @@ -478,6 +478,11 @@ int send_pack(struct send_pack_args *args,
> > return ret;
> > for (ref = remote_refs; ref; ref = ref->next) {
> > switch (ref->status) {
> > + case REF_STATUS_REJECT_NONFASTFORWARD:
> > + case REF_STATUS_REJECT_NODELETE:
> > + if (args->porcelain && args->dry_run)
> > + break;
> > + return -1;
> > case REF_STATUS_NONE:
> > case REF_STATUS_UPTODATE:
> > case REF_STATUS_OK:
>
> Why just these two status flags? Based on your reasoning elsewhere, I
> would assume the logic should be:
>
> - if we had some transport-related error, return failure
>
> - if not, then return success, as any ref's failure is already
> indicated in the porcelain output
>
> So shouldn't it just be:
>
> if (args->porcelain && args->dry_run)
> return 0;
>
> after we check for transport errors but before the loop that you are
> modifying.
I don't know what the deal is with REF_STATUS_EXPECTING_REPORT, so I didn't want
to modify the behavior in the case that ref->status was that. What does
expecting report mean?
--larry
^ permalink raw reply
* Re: [PATCH 3/3] make git push --dry-run --porcelain exit with status 0 even if updates will be rejected
From: Jeff King @ 2010-02-05 20:13 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <20100205200524.GA24027@cthulhu>
On Fri, Feb 05, 2010 at 03:05:24PM -0500, Larry D'Anna wrote:
> > So shouldn't it just be:
> >
> > if (args->porcelain && args->dry_run)
> > return 0;
> >
> > after we check for transport errors but before the loop that you are
> > modifying.
>
> I don't know what the deal is with REF_STATUS_EXPECTING_REPORT, so I
> didn't want to modify the behavior in the case that ref->status was
> that. What does expecting report mean?
It means we told the other side we wanted to push that ref, and we
expect it to give us a status report. Most refs are in that state for a
short period, and then moved to their final state in
builtin-send-pack.c:receive_status. But if we never get a status for
that ref for some reason, then that could be the final state.
But more to the point, I don't think this bit of code should _have_ to
care what it means. If there is a per-ref error with "push --dry-run
--porcelain", it will be shown on that ref's output line. So I think
your proposal should simply be "if dry-run and porcelain, don't bother
looking at per-ref errors at all". You don't care what the per-ref
error is; they are all in the same class from the perspective of this
change.
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] silence human readable info messages going to stderr from git push --porcelain
From: Junio C Hamano @ 2010-02-05 20:20 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <1265398462-17316-2-git-send-email-larry@elder-gods.org>
Larry D'Anna <larry@elder-gods.org> writes:
> These messages are redundant information to a script that's calling git-push.
Redundant is not a reason for a change; unwanted would be. And some of
the messages you are trying to squelch indeed look like unwanted ones, but
not all of them.
> - if (flags & TRANSPORT_PUSH_VERBOSE)
> + if (flags & TRANSPORT_PUSH_VERBOSE && !(flags & TRANSPORT_PUSH_PORCELAIN))
> fprintf(stderr, "Pushing to %s\n", transport->url);
Why should you be forbidden to expect "--porcelain -v" to give you this
message?
> @@ -123,7 +123,7 @@ static int push_with_options(struct transport *transport, int flags)
> if (!err)
> return 0;
>
> - if (nonfastforward && advice_push_nonfastforward) {
> + if (!(flags & TRANSPORT_PUSH_PORCELAIN) && nonfastforward && advice_push_nonfastforward) {
> fprintf(stderr, "To prevent you from losing history, non-fast-forward updates were rejected\n"
> "Merge the remote changes before pushing again. See the 'Note about\n"
> "fast-forwards' section of 'git push --help' for details.\n");
This probably is a good change; the long lines are unsightly but that is a
separate topic.
> diff --git a/transport.c b/transport.c
> index 3846aac..f707c7b 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -674,7 +674,7 @@ static void print_ok_ref_status(struct ref *ref, int porcelain)
>
> static int print_one_push_status(struct ref *ref, const char *dest, int count, int porcelain)
> {
> - if (!count)
> + if (!count && !porcelain)
> fprintf(stderr, "To %s\n", dest);
I don't think this is correct.
If you have more than one remote.there.pushURL, the calling Porcelain
script of "git push --porcelain there" should be able to tell which
destination the following report is about, and without this line you
cannot tell.
I would understand if this change were to make the message go to the
standard output when operating with --porcelain option, though.
> @@ -1067,10 +1067,10 @@ int transport_push(struct transport *transport,
> if (!(flags & TRANSPORT_PUSH_DRY_RUN)) {
> struct ref *ref;
> for (ref = remote_refs; ref; ref = ref->next)
> - update_tracking_ref(transport->remote, ref, verbose);
> + update_tracking_ref(transport->remote, ref, verbose && !porcelain);
Again, why should you be forbidden to expect "--porcelain -v" to work?
> - if (!quiet && !ret && !refs_pushed(remote_refs))
> + if (!quiet && !porcelain && !ret && !refs_pushed(remote_refs))
> fprintf(stderr, "Everything up-to-date\n");
This is a borderline. If you are truly up-to-date, the calling script
won't get anything. It may be easier for Porcelain scripts to see this
message on the standard output as an explicit succeses report instead.
^ permalink raw reply
* Re: [PATCH] Remove .git auto detection from setup_git_env()
From: René Scharfe @ 2010-02-05 20:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vljf7a901.fsf@alter.siamese.dyndns.org>
Am 05.02.2010 18:27, schrieb Junio C Hamano:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> This topic started from "We broke 'git grep' in .git directory" and I
>> think it is the sanest to revert 3081623 (grep --no-index: allow use of
>> "git grep" outside a git repository, 2010-01-15) which nobody has used so
>> far in any released version of git, until we sort this out at least.
>
> Sorry; spoke too fast. We'd also need to revert the one to git.c (7e62265
> (grep: prepare to run outside of a work tree, 2010-01-15) as well.
> { "fsck-objects", cmd_fsck, RUN_SETUP },
> { "gc", cmd_gc, RUN_SETUP },
> { "get-tar-commit-id", cmd_get_tar_commit_id },
> - { "grep", cmd_grep, USE_PAGER },
> + { "grep", cmd_grep, RUN_SETUP | USE_PAGER },
> { "hash-object", cmd_hash_object },
> { "help", cmd_help },
> { "index-pack", cmd_index_pack },
There is one other command with only the USE_PAGER flag turned on, which
also seems to have been broken by the change to remove the RUN_SETUP
flag: shortlog. But that was done in March 2008 (abe549e1, "shortlog:
do not require to run from inside a git repository"), so it's no regression.
René
^ permalink raw reply
* Re: [PATCH 2/3] silence human readable info messages going to stderr from git push --porcelain
From: Larry D'Anna @ 2010-02-05 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vgz5ta7.fsf@alter.siamese.dyndns.org>
* Junio C Hamano (gitster@pobox.com) [100205 15:20]:
> > - if (!quiet && !ret && !refs_pushed(remote_refs))
> > + if (!quiet && !porcelain && !ret && !refs_pushed(remote_refs))
> > fprintf(stderr, "Everything up-to-date\n");
>
> This is a borderline. If you are truly up-to-date, the calling script
> won't get anything. It may be easier for Porcelain scripts to see this
> message on the standard output as an explicit succeses report instead.
how about this?
if (!quiet && (!porcelain || verbose) && !ret && !refs_pushed(remote_refs))
fprintf(stderr, "Everything up-to-date\n");
--larry
^ permalink raw reply
* [PATCH v2 1/3] fix an error message in git-push so it goes to stderr
From: Larry D'Anna @ 2010-02-05 20:49 UTC (permalink / raw)
To: git; +Cc: Larry D'Anna
In-Reply-To: <cover.1265402797.git.larry@elder-gods.org>
Having it go to standard output interferes with git-push --porcelain.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
---
builtin-push.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 5633f0a..0a27072 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -124,9 +124,9 @@ static int push_with_options(struct transport *transport, int flags)
return 0;
if (nonfastforward && advice_push_nonfastforward) {
- printf("To prevent you from losing history, non-fast-forward updates were rejected\n"
- "Merge the remote changes before pushing again. See the 'Note about\n"
- "fast-forwards' section of 'git push --help' for details.\n");
+ fprintf(stderr, "To prevent you from losing history, non-fast-forward updates were rejected\n"
+ "Merge the remote changes before pushing again. See the 'Note about\n"
+ "fast-forwards' section of 'git push --help' for details.\n");
}
return 1;
--
1.7.0.rc1.33.g07cf0f.dirty
^ permalink raw reply related
* [PATCH v2 2/3] clean up some of the output from git push --porcelain
From: Larry D'Anna @ 2010-02-05 20:49 UTC (permalink / raw)
To: git; +Cc: Larry D'Anna
In-Reply-To: <cover.1265402797.git.larry@elder-gods.org>
* don't emit long explanatory message about non-fast-forward updates.
* send "To dest" lines to standard out so whoever is reading standard out knows
which ref updates went to which remotes.
* only send the "Everything up-to-date" line if verbose.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
---
builtin-push.c | 2 +-
transport.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 0a27072..ff0b1c6 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -123,7 +123,7 @@ static int push_with_options(struct transport *transport, int flags)
if (!err)
return 0;
- if (nonfastforward && advice_push_nonfastforward) {
+ if (!(flags & TRANSPORT_PUSH_PORCELAIN) && nonfastforward && advice_push_nonfastforward) {
fprintf(stderr, "To prevent you from losing history, non-fast-forward updates were rejected\n"
"Merge the remote changes before pushing again. See the 'Note about\n"
"fast-forwards' section of 'git push --help' for details.\n");
diff --git a/transport.c b/transport.c
index 3846aac..00d986c 100644
--- a/transport.c
+++ b/transport.c
@@ -675,7 +675,7 @@ static void print_ok_ref_status(struct ref *ref, int porcelain)
static int print_one_push_status(struct ref *ref, const char *dest, int count, int porcelain)
{
if (!count)
- fprintf(stderr, "To %s\n", dest);
+ fprintf(porcelain ? stdout : stderr, "To %s\n", dest);
switch(ref->status) {
case REF_STATUS_NONE:
@@ -1070,7 +1070,7 @@ int transport_push(struct transport *transport,
update_tracking_ref(transport->remote, ref, verbose);
}
- if (!quiet && !ret && !refs_pushed(remote_refs))
+ if (!quiet && (!porcelain || verbose) && !ret && !refs_pushed(remote_refs))
fprintf(stderr, "Everything up-to-date\n");
return ret;
}
--
1.7.0.rc1.33.g07cf0f.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox