Fredrik Gustafsson <iv...@iveqy.com> writes:
> On Mon, Jun 24, 2013 at 11:11:02PM +0530, Ramkumar Ramachandra wrote:
>> There are many configuration variables that determine exactly what a
>> push does. Give the user early feedback so that she has a chance to
>> abort if she doesn't mean to push those refspecs to that destination
>> $ git push
>> # pushing refspecs 'master next' to ram (^C to abort)
>> Signed-off-by: Ramkumar Ramachandra <artag...@gmail.com>
>> Goes without saying: this is an early preview.
>> builtin/push.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>> diff --git a/builtin/push.c b/builtin/push.c
>> index 2d84d10..085d5ab 100644
>> --- a/builtin/push.c
>> +++ b/builtin/push.c
>> @@ -330,6 +330,7 @@ static int do_push(const char *repo, int flags)
>> int i, errs;
>> struct remote *remote = pushremote_get(repo);
>> + struct strbuf sb = STRBUF_INIT;
>> const char **url;
>> int url_nr;
>> @@ -375,6 +376,11 @@ static int do_push(const char *repo, int flags)
>> errs = 0;
>> url_nr = push_url_of_remote(remote, &url);
>> + for (i = 0; i < refspec_nr; i++)
>> + strbuf_addf(&sb, "%s%s", refspec[i], i == refspec_nr - 1 ? "":
>> " ");
>> + printf("# pushing refspecs '%s' to %s (^C to abort)\n", sb.buf,
> How about a strbuf_release here?
> Can you really be sure that refspec_nr is set here?
Doing this unconditionally when the user says "git push there this"
would be mildly annoying.
I think this belongs to either --verbose or even --debug, for people
who are trying to make sure an underspecified "git push" (or "git
push there") does what they want, but for those use cases, it
probably is better to tie this to --dry-run.
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 http://vger.kernel.org/majordomo-info.html