* Re: Creating something like increasing revision numbers
From: Daniel Barkalow @ 2009-10-19 1:16 UTC (permalink / raw)
To: Norbert Preining; +Cc: git
In-Reply-To: <20091019004447.GC11739@gamma.logic.tuwien.ac.at>
On Mon, 19 Oct 2009, Norbert Preining wrote:
> Hi all,
>
> thanks everyone for the nice feedback!
>
> On So, 18 Okt 2009, Daniel Barkalow wrote:
> > It's possible as long as you don't think of the "version number" as a
> > property of the commit, but rather a property that some commits get by
> > virtue of having been at some time the commit that's what would be found
> > on that particular server at that particular time. Even though the history
>
> Right! That is a good point. In fact I don't care about (local) commits,
> but about the pushes to the central server.
>
> > of the *content* is non-linear, the sequence of values stored in
> > refs/heads/master on your central server is linear, local, and easy to
> > enumerate.
>
> That is exactely what I need.
>
> > Of course, when someone does a bunch of development in parallel with other
> > people, does a final merge, and pushes it back to the server, this only
> > increases the version by one, and only the final merge actually has a
>
> As it is now with svn, we have to live with that. The point is that we
> still would see many different commits pushed to the server, so
> git log would show the single items, but the "versioning sequence number"
> is only increased by one. That would be *absolutely*perfect* for me!
>
> > because the intermediate commits don't ever get packages created of them
> > to need to be compared to other packages.
>
> Right!
>
> Now my follow-up questions:
> - how would one access this "sequence" number on the server
There isn't currently anything built in that counts up like that; however,
it shouldn't be too hard to add something, because the reflog gets an
entry at the same times the sequence number would increase. In fact, you
could disable pruning the reflog, and use its length (in lines), except
that would get slow and git doesn't expect you to care about the complete
history there (in fact, you only care about the amount of history past
some point).
> - is there a way to determine at which of this "sequence" numbers a specific
> file has been changed last?
There isn't a built-in way, but you can find the current hash for a
filename with "git ls-tree -r <branch> <filename>", and find the hash as
of N changes ago with "git ls-tree -r <branch>@{<N>} <filename>". You're
looking for the smallest N where they don't match. (And you probably
don't want to be a binary search or the like, because that might miss that
a file was most recently affected by having a change reverted; you'd want
to be sure to report the version that reverted the change, not the version
that introduced the content the later one returned to.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Norbert Preining @ 2009-10-19 1:33 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0910182045580.14365@iabervon.org>
Hi Daniel,
On So, 18 Okt 2009, Daniel Barkalow wrote:
> > - how would one access this "sequence" number on the server
>
> There isn't currently anything built in that counts up like that; however,
> it shouldn't be too hard to add something, because the reflog gets an
> entry at the same times the sequence number would increase. In fact, you
Ok.
> > - is there a way to determine at which of this "sequence" numbers a specific
> > file has been changed last?
>
> There isn't a built-in way, but you can find the current hash for a
> filename with "git ls-tree -r <branch> <filename>", and find the hash as
> of N changes ago with "git ls-tree -r <branch>@{<N>} <filename>". You're
> looking for the smallest N where they don't match. (And you probably
> don't want to be a binary search or the like, because that might miss that
That sounds like we cannot use that, because we have to do that for about
80k files and that on each (at least daily) rebuilt. That is not feasable.
Again thanks for your helpful comments!
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining Associate Professor
JAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp
Vienna University of Technology preining@logic.at
Debian Developer (Debian TeX Task Force) preining@debian.org
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
BRUMBY
The fake antique plastic seal on a pretentious whisky bottle.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Nicolas Pitre @ 2009-10-19 1:34 UTC (permalink / raw)
To: Norbert Preining; +Cc: Daniel Barkalow, git
In-Reply-To: <20091019004447.GC11739@gamma.logic.tuwien.ac.at>
On Mon, 19 Oct 2009, Norbert Preining wrote:
> Now my follow-up questions:
> - how would one access this "sequence" number on the server
you can count how many commits the server has: git rev-list HEAD | wc -l
> - is there a way to determine at which of this "sequence" numbers a specific
> file has been changed last?
You can do: git log <path/filename>. That would give you a list of
commits that touched that file. But to find out which commit "number"
it is you could do:
git rev-list $(git rev-list -1 HEAD <path/file>) | wc -l
Again, that is true for a particular repository only and may give a
different result in another repository with a different state even for
the same commit.
However, given what you want to do is really to stick to the SVN way of
doing things, then why don't you simply stay with SVN? Git works in a
fundamentally different way than SVN, and if you aren't willing/able to
change your workflow away from the SVN way then there is really not much
for you to gain by switching to Git.
Nicolas
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Norbert Preining @ 2009-10-19 1:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Daniel Barkalow, git
In-Reply-To: <alpine.LFD.2.00.0910182122100.21739@xanadu.home>
On So, 18 Okt 2009, Nicolas Pitre wrote:
> However, given what you want to do is really to stick to the SVN way of
> doing things, then why don't you simply stay with SVN? Git works in a
I fear so.
> fundamentally different way than SVN, and if you aren't willing/able to
> change your workflow away from the SVN way then there is really not much
> for you to gain by switching to Git.
Well, as I said in the beginning, the metadata handling of svn is a pain
in huge repositories like ours with thousands of subdirectories of subdirs
of subdirs and 80k+ files. That was the reason I thought about git.
But I am coming to the conclusion that I will use git for my other projects,
but not for that one.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining Associate Professor
JAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp
Vienna University of Technology preining@logic.at
Debian Developer (Debian TeX Task Force) preining@debian.org
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
GLASSEL (n.)
A seaside pebble which was shiny and interesting when wet, and which
is now a lump of rock, which children nevertheless insist on filing
their suitcases with after the holiday.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Daniel Barkalow @ 2009-10-19 2:41 UTC (permalink / raw)
To: Norbert Preining; +Cc: git
In-Reply-To: <20091019013320.GD17397@gamma.logic.tuwien.ac.at>
On Mon, 19 Oct 2009, Norbert Preining wrote:
> Hi Daniel,
>
> On So, 18 Okt 2009, Daniel Barkalow wrote:
> > > - how would one access this "sequence" number on the server
> >
> > There isn't currently anything built in that counts up like that; however,
> > it shouldn't be too hard to add something, because the reflog gets an
> > entry at the same times the sequence number would increase. In fact, you
>
> Ok.
>
> > > - is there a way to determine at which of this "sequence" numbers a specific
> > > file has been changed last?
> >
> > There isn't a built-in way, but you can find the current hash for a
> > filename with "git ls-tree -r <branch> <filename>", and find the hash as
> > of N changes ago with "git ls-tree -r <branch>@{<N>} <filename>". You're
> > looking for the smallest N where they don't match. (And you probably
> > don't want to be a binary search or the like, because that might miss that
>
> That sounds like we cannot use that, because we have to do that for about
> 80k files and that on each (at least daily) rebuilt. That is not feasable.
It's likely to be much more efficient (and maybe sufficiently efficient)
to do them all in a single pass. In fact, it should be easy enough to keep
a cache of the latest numbers for the files, and update that to change the
value for those files that differ between the old commit and the new
commit in the post-update hook.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] git push: remove incomplete options list from help text
From: Nanako Shiraishi @ 2009-10-19 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Sebastian Pipping, Jeff King, git
In-Reply-To: <20091018235240.GU6115@genesis.frugalware.org>
'git push -h' shows usage text with incomplete list of options and then
has a separate list of options that are supported. Imitate the way other
commands (I looked at 'git diff' for an example) show their options.
Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
---
Quoting Miklos Vajna <vmiklos@frugalware.org>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Sun, Oct 18, 2009 at 07:05:44PM +0200, Sebastian Pipping <webmaster@hartwork.org> wrote:
>> If I'm not mistaken --quiet is not documented in the git-push man page.
>> This includes release 1.6.5.1.
>
> Here is a patch to document it.
% git push -h
usage: git push [--all | --mirror] [-n | --dry-run] [--porcelain] [--tags]
[--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force]
[-v] [<repository> <refspec>...]
-q, --quiet be quiet
-v, --verbose be verbose
--repo <repository> repository
--all push all refs
--mirror mirror all refs
--tags push tags
-n, --dry-run dry run
--porcelain machine-readable output
-f, --force force updates
--thin use thin pack
--receive-pack <receive-pack>
receive pack program
--exec <receive-pack>
receive pack program
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 3cb1ee4..6686b79 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git push [--all | --mirror] [-n | --dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git push <options> [<repository> <refspec>...]",
NULL,
};
--
1.6.5.rc1.18.g53a9a
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [RFC PATCH v3 10/17] Move WebDAV HTTP push under remote-curl
From: Tay Ray Chuan @ 2009-10-19 2:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Daniel Barkalow, Mike Hommey
In-Reply-To: <1255577814-14745-11-git-send-email-spearce@spearce.org>
Hi,
On Thu, Oct 15, 2009 at 11:36 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> @@ -34,6 +34,10 @@ Commands are given by the caller on the helper's standard input, one per line.
> value of the ref. A space-separated list of attributes follows
> the name; unrecognized attributes are ignored. After the
> complete list, outputs a blank line.
> ++
> +If 'push' is supported this may be called as 'list for-push'
> +to obtain the current refs prior to sending one or more 'push'
> +commands to the helper.
The new paragraph should have the same indentation as 'list'.
It would have been great if you implemented this as a filter, such that
'list <attr>' lists the refs with the specified attribute <attr>,
rather than hardcoding it.
> @@ -59,6 +63,22 @@ suitably updated.
> +When the push is complete, outputs one or more 'ok <dst>' or
> +'error <dst> <why>?' lines to indicate success or failure of
> +each pushed ref. The status report output is terminated by
> +a blank line. The option field <why> may be quoted in a C
> +style string if it contains an LF.
You should mention that this behaviour only occurs when the
--helper-status option is used.
> @@ -106,6 +132,11 @@ OPTIONS
> +'option dry-run' \{'true'|'false'\}:
> + If true, pretend like the operation completed successfully,
> + but don't actually change any repository data. For most
> + helpers this only applies to the 'push', if supported.
> +
The 'like' after 'pretend' can be, like, removed. :)
> diff --git a/http-push.c b/http-push.c
> @@ -1941,9 +1946,14 @@ int main(int argc, char **argv)
>
> if (is_null_sha1(ref->peer_ref->new_sha1)) {
> if (delete_remote_branch(ref->name, 1) == -1) {
> - error("Could not remove %s", ref->name);
> + if (helper_status)
> + printf("error %s cannot remove\n", ref->name);
> + else
> + error("Could not remove %s", ref->name);
> rc = -4;
> }
I think error() calls should be left intact (as indicators to the
user), even when --helper-status is specified. It wouldn't affect
transport-helper.c's parsing of '(ok|error) <ref>' lines, since it
reads stdout only.
In other words, the above would read:
> error("Could not remove %s", ref->name);
> + if (helper_status)
> + printf("error %s cannot remove\n", ref->name);
> rc = -4;
> }
> @@ -1968,12 +1980,15 @@ int main(int argc, char **argv)
> * commits at the remote end and likely
> * we were not up to date to begin with.
> */
> - error("remote '%s' is not an ancestor of\n"
> - "local '%s'.\n"
> - "Maybe you are not up-to-date and "
> - "need to pull first?",
> - ref->name,
> - ref->peer_ref->name);
> + if (helper_status)
> + printf("error %s non-fast forward\n", ref->name);
> + else
> + error("remote '%s' is not an ancestor of\n"
> + "local '%s'.\n"
> + "Maybe you are not up-to-date and "
> + "need to pull first?",
> + ref->name,
> + ref->peer_ref->name);
> rc = -2;
> continue;
> }
Same here.
> @@ -1987,14 +2002,20 @@ int main(int argc, char **argv)
> /* Lock remote branch ref */
> ref_lock = lock_remote(ref->name, LOCK_TIME);
> if (ref_lock == NULL) {
> - fprintf(stderr, "Unable to lock remote branch %s\n",
> - ref->name);
> + if (helper_status)
> + printf("error %s lock error\n", ref->name);
> + else
> + fprintf(stderr, "Unable to lock remote branch %s\n",
> + ref->name);
> rc = 1;
> continue;
> }
Same here.
Two more areas in http-push.c that should have status messages
(generated on top of pu):
(I'm not sure what ref should read when there's no match, but
transport-helper.c should have no problems parsing it with 'null'.)
-->8--
diff --git a/http-push.c b/http-push.c
index 9010ccc..e979feb 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1916,9 +1916,12 @@ int main(int argc, char **argv)
/* Remove a remote branch if -d or -D was specified */
if (delete_branch) {
- if (delete_remote_branch(refspec[0], force_delete) == -1)
+ if (delete_remote_branch(refspec[0], force_delete) == -1) {
fprintf(stderr, "Unable to delete remote branch %s\n",
refspec[0]);
+ if (helper_status)
+ printf("error %s cannot remove\n", refspec[0]);
+ }
goto cleanup;
}
@@ -1930,6 +1933,8 @@ int main(int argc, char **argv)
}
if (!remote_refs) {
fprintf(stderr, "No refs in common and none specified; doing nothing.\n");
+ if (helper_status)
+ printf("error null no match\n");
rc = 0;
goto cleanup;
}
--
Cheers,
Ray Chuan
^ permalink raw reply related
* Re: [PATCH] Add the --submodule option to the diff option family
From: Junio C Hamano @ 2009-10-19 3:02 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <4ADA10FC.40708@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> When you use the option --submodule=left-right-log you can see the submodule
> summaries inlined in the diff, instead of not-quite-helpful SHA-1 pairs.
>
> The format imitates what "git submodule summary" shows.
>
> To do that, <path>/.git/objects/ is added to the alternate object
> databases (if that directory exists).
>
> This option was requested by Jens Lehmann at the GitTogether in Berlin.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
Thanks.
I have four patches queued on js/diff-verbose-submodule topic and I think
this corresponds to the first three, correct?
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 9276fae..99cb517 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -87,6 +87,13 @@ endif::git-format-patch[]
> Show only names and status of changed files. See the description
> of the `--diff-filter` option on what the status letters mean.
>
> +--submodule[=<format>]::
> + Chose the output format for submodule differences. <format> can be one of
> + 'short' and 'left-right-log'. 'short' is the default value for this
> + option and and shows pairs of commit names. 'left-right-log' lists the
> + commits in that commit range like the 'summary' option of
> + linkgit:git-submodule[1] does.
> +
Well, while left-right-log may be logically the most correct name for this
option, I think it is too long to be practical. Because it is not like we
would want to have an option to have full log there when we are showing
"diff", I think it would make sense to making left-right-log the default
when "--submodule" (without format specification) is given, and possibly
give "--submodule=log" as the synonym for this format.
After all, if you do not give --submodule, we will give the traditional
short format, no?
> diff --git a/diff.c b/diff.c
> index c719ce2..8af1ae2 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -2771,6 +2783,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
> DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
> else if (!strcmp(arg, "--ignore-submodules"))
> DIFF_OPT_SET(options, IGNORE_SUBMODULES);
> + else if (!prefixcmp(arg, "--submodule=")) {
> + if (!strcmp(arg + 12, "left-right-log"))
> + DIFF_OPT_SET(options, SUBMODULE_LEFT_RIGHT_LOG);
> + }
I do not see --submodule (without "=<format>") supported here as the
documentation claims, but this is the logical place to do so.
> diff --git a/submodule.c b/submodule.c
> new file mode 100644
> index 0000000..206386f
> --- /dev/null
> +++ b/submodule.c
> @@ -0,0 +1,112 @@
> +...
> +void show_submodule_summary(FILE *f, const char *path,
> + unsigned char one[20], unsigned char two[20],
> + const char *del, const char *add, const char *reset)
> +{
> ...
> + fwrite(sb.buf, sb.len, 1, f);
> +
> + if (!message) {
> + while ((commit = get_revision(&rev))) {
> + ...
> + }
> + clear_commit_marks(left, ~0);
> + clear_commit_marks(right, ~0);
> + }
> +}
I thought we had strbuf_release(&sb) here... Where did it go?
^ permalink raw reply
* Re: [PATCH] git push: remove incomplete options list from help text
From: Junio C Hamano @ 2009-10-19 3:13 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Miklos Vajna, Sebastian Pipping, Jeff King, git
In-Reply-To: <20091019115412.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> 'git push -h' shows usage text with incomplete list of options and then
> has a separate list of options that are supported. Imitate the way other
> commands (I looked at 'git diff' for an example) show their options.
>
> Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
> ---
> ...
> diff --git a/builtin-push.c b/builtin-push.c
> index 3cb1ee4..6686b79 100644
> --- a/builtin-push.c
> +++ b/builtin-push.c
> @@ -10,7 +10,7 @@
> #include "parse-options.h"
>
> static const char * const push_usage[] = {
> - "git push [--all | --mirror] [-n | --dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
> + "git push <options> [<repository> <refspec>...]",
> NULL,
> };
>
> --
> 1.6.5.rc1.18.g53a9a
Sounds like a sane thing to do, but I am sort of surprised that you are
still on 1.6.5-rc1 ;-)
How does this interact with one of the "unapplied patch" you reminded me
of, namely, this one:
From: Björn Gustavsson <bgustavsson@gmail.com>
Subject: [PATCH] push: fix usage: --tags is incompatible with --all and --mirror
Date: Thu, 15 Oct 2009 18:39:05 +0200
Message-ID: <4AD75029.1010109@gmail.com>
Correct the usage text to make it clear that --tags cannot
be combined with --all or --mirror.
The option description that comes from parse-options may need to be
updated as well, no?
> -q, --quiet be quiet
> -v, --verbose be verbose
> --repo <repository> repository
> --all push all refs
> --mirror mirror all refs
> --tags push tags
> -n, --dry-run dry run
> --porcelain machine-readable output
> -f, --force force updates
> --thin use thin pack
> --receive-pack <receive-pack>
> receive pack program
> --exec <receive-pack>
> receive pack program
^ permalink raw reply
* [PATCH] git push: say that --tag can't be used with --all or --mirror in help text
From: Nanako Shiraishi @ 2009-10-19 3:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Miklos Vajna, Sebastian Pipping, Jeff King, git,
Bjorn Gustavsson
In-Reply-To: <7vpr8kcc00.fsf@alter.siamese.dyndns.org>
This replaces an earlier patch by Björn Gustavsson,
Message-ID: <4AD75029.1010109@gmail.com>
Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
---
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 6686b79..d7248f2 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -181,7 +181,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
- OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
+ OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all nor --mirror"),
OPT_BIT('n' , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
OPT_BIT( 0, "porcelain", &flags, "machine-readable output", TRANSPORT_PUSH_PORCELAIN),
OPT_BIT('f', "force", &flags, "force updates", TRANSPORT_PUSH_FORCE),
--
1.6.5.rc1.18.g53a9a
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: git push should automatically push to remote tracking branch
From: Mohit Aron @ 2009-10-19 3:50 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <1B59440B-5929-4AB9-82C7-05188DC4F959@dbservice.com>
Thanks - I suppose this is a new config option. I'm running Git
version 1.6.0.4 (the latest with Ubuntu Jaunty) and that doesn't seem
to have this option.
- Mohit
>
> $ git config push.default tracking
>
> tom
>
>
^ permalink raw reply
* Re: [PATCH] Document git push -q
From: Jeff King @ 2009-10-19 4:01 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Sebastian Pipping, git
In-Reply-To: <20091018235240.GU6115@genesis.frugalware.org>
On Mon, Oct 19, 2009 at 01:52:40AM +0200, Miklos Vajna wrote:
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index ba6a8a2..beb3422 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -138,6 +138,12 @@ useful if you write an alias or script around 'git-push'.
> --verbose::
> Run verbosely.
>
> +-q::
> +--quiet::
> + Some transports produce output even without `--verbose` turned
> + on. This provides a way to tell them to be more quiet (whereas
> + simply redirecting might lose error messages).
> +
Thanks, though two complaints:
1. This is not just about "some transports". Some of the quieted code
is in transport_push, so hopefully it applies to all transports
once they follow that code path (though we also pass the quiet flag
on to pack-objects, so that part is about "some transports".
2. Maybe it would be more helpful to the user to describe what is
shown and what is not. I think we want to claim to suppress all
non-error output (since that was the intent of the recent patches).
If that is not true for some transport, then we need to fix passing
--quiet to that transport.
...Ah, I see your confusion. You read the log for afdeeb00, but there
were some follow-on patches that impacted others part of push. :)
So maybe this instead:
-- >8 --
Subject: [PATCH] document push's new quiet option
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-push.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index ba6a8a2..37c8895 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -138,6 +138,11 @@ useful if you write an alias or script around 'git-push'.
--verbose::
Run verbosely.
+-q::
+--quiet::
+ Suppress all output, including the listing of updated refs,
+ unless an error occurs.
+
include::urls-remotes.txt[]
OUTPUT
--
1.6.5.1.121.g65c47
^ permalink raw reply related
* Re: [PATCH] git push: remove incomplete options list from help text
From: Jeff King @ 2009-10-19 4:10 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Miklos Vajna, Sebastian Pipping, git
In-Reply-To: <20091019115412.6117@nanako3.lavabit.com>
On Mon, Oct 19, 2009 at 11:54:12AM +0900, Nanako Shiraishi wrote:
> static const char * const push_usage[] = {
> - "git push [--all | --mirror] [-n | --dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
> + "git push <options> [<repository> <refspec>...]",
This is a big improvement, IMO. We should probably standardize on when
to show options, and when to simply say <options>, and make sure every
program does the right thing. I am in favor of a short synopsis followed
by a list (as you do here) for both usage and for manpages. However, I
raised the question a few weeks ago and the response was slightly
negative:
http://thread.gmane.org/gmane.comp.version-control.git/129399/focus=129424
Probably few people read it, as it was buried deep in a thread. But
maybe we should settle on a rule like "short synopsis for usage, long
synopsis for manpage" or whatever people think is best.
Also, minor nit with your patch: should it be "[<options>]"?
-Peff
^ permalink raw reply
* Re: [PATCH] git push: say that --tag can't be used with --all or --mirror in help text
From: Jeff King @ 2009-10-19 4:14 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Junio C Hamano, Miklos Vajna, Sebastian Pipping, git,
Bjorn Gustavsson
In-Reply-To: <20091019125701.6117@nanako3.lavabit.com>
On Mon, Oct 19, 2009 at 12:57:01PM +0900, Nanako Shiraishi wrote:
> - OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
> + OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all nor --mirror"),
Grammar nit: I believe it should be "or" and not "nor".
There is an implicit "either", as in "can't be used with either --all or
--mirror". Saying "can't be used with neither --all nor --mirror" would
be a double-negative. The alternative correct single-negation would be
"can be used with neither --all nor --mirror".
-Peff
^ permalink raw reply
* Re: [PATCH] git add -e documentation: rephrase note
From: Jeff King @ 2009-10-19 4:34 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20091019000900.GV6115@genesis.frugalware.org>
On Mon, Oct 19, 2009 at 02:09:00AM +0200, Miklos Vajna wrote:
> Add a quick overview about what is OK and what is not to cover all
> cases.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> Signed-off-by: Jeff King <peff@peff.net>
Please be careful with sign-offs. While your patch text is an adaptation
of what I said, and while it is true that I personally would never say
anything on the list that was not free for use in git, I did not in fact
do such a sign-off, which is what that line is supposed to be
documenting.
In this case, I think you probably just wanted to say "text from Jeff
King" or even "From: Jeff King <peff@peff.net>".
That being said,
Signed-off-by: Jeff King <peff@peff.net>
:)
I still have a few comments, though.
> +The intent of this option is to pick and choose lines of the diff to
> +apply, or even to munge the lines. So it is safe to:
> ++
> +* remove lines with a "+" (don't stage the addition)
> +* munge any lines with a "+" (stage modified contents)
Do we want to use "munge" here? Maybe something a little more specific
like "modify the content of" is more appropriate for documentation.
> +* add lines with a "+" (stage an addition)
> +* convert lines with a " " to "-" (stage removal)
> +* convert lines with a "-" to " " (don't stage removal)
Is " " going to render in an obvious-to-read way? I checked the html
version and the manpage version in my terminal, and they looked OK, but
I would not be surprised if somebody has a font setup that makes it a
little hard to read.
> ++
> +It is a bad idea to:
> ++
Annoyingly, this renders for me as:
· convert lines with a "-" to " " (don’t stage removal)
It is a bad idea to:
· delete "-" lines
(the spacing of which will hopefully not be destroyed in transit). In
other words, the "+" list continuation makes the "it is a bad idea" text
part of the "good idea" list, instead of continuing the definition of
the "-e" option. I think we can fix it with an open block marker. I'll
see what I can do.
-Peff
^ permalink raw reply
* Re: [PATCH] git add -e documentation: rephrase note
From: Jeff King @ 2009-10-19 5:04 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20091019043418.GD7170@coredump.intra.peff.net>
On Mon, Oct 19, 2009 at 12:34:18AM -0400, Jeff King wrote:
> I still have a few comments, though.
> [...]
> (the spacing of which will hopefully not be destroyed in transit). In
> other words, the "+" list continuation makes the "it is a bad idea" text
> part of the "good idea" list, instead of continuing the definition of
> the "-e" option. I think we can fix it with an open block marker. I'll
> see what I can do.
Hmph. Here is my attempt. The text is (I hope) more clear, but I am
still having trouble with the formatting. It looks fine in the HTML
version, and if I am reading the XML right, the XML is correct. But
docbook seems to screw up converting the XML to roff, giving this:
· convert removal lines to context lines (don’t stage removal)
Similarly, your patch will likely not apply if you:
· add context or removal lines
Am I missing something, or is it really a docbook bug? Does it render
better for anybody else?
-- >8 --
Subject: [PATCH] docs: give more hints about how "add -e" works
The original text was not very descriptive about what you
can and can't do; let's try to enumerate all cases.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-add.txt | 22 +++++++++++++++++++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 45ebf87..b0a8420 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -86,9 +86,25 @@ OPTIONS
edit it. After the editor was closed, adjust the hunk headers
and apply the patch to the index.
+
-*NOTE*: Obviously, if you change anything else than the first character
-on lines beginning with a space or a minus, the patch will no longer
-apply.
+The intent of this option is to pick and choose lines of the diff to
+apply, or even to modify the contents of lines to be staged. There are
+three line types in a diff: addition lines (beginning with a plus),
+removal lines (beginning with a minus), and context lines (beginning
+with a space). In general, it should be safe to:
++
+--
+* remove addition lines (don't stage the line)
+* modify the content of any addition lines (stage modified contents)
+* add new addition lines (stage the new line)
+* convert context lines to removal lines (stage removal of line)
+* convert removal lines to context lines (don't stage removal)
+--
++
+Similarly, your patch will likely not apply if you:
++
+* add context or removal lines
+* delete removal or context lines
+* modify the contents of context or removal lines
-u::
--update::
--
1.6.5.1.123.gcaaf
^ permalink raw reply related
* Re: git push should automatically push to remote tracking branch
From: Jeff King @ 2009-10-19 5:06 UTC (permalink / raw)
To: Mohit Aron; +Cc: Tomas Carnecky, git
In-Reply-To: <ee22b09e0910182050k55efac83v6799285d992fcbb0@mail.gmail.com>
On Sun, Oct 18, 2009 at 08:50:57PM -0700, Mohit Aron wrote:
> Thanks - I suppose this is a new config option. I'm running Git
> version 1.6.0.4 (the latest with Ubuntu Jaunty) and that doesn't seem
> to have this option.
Yes, it was added in v1.6.3.
-Peff
^ permalink raw reply
* Re: [PATCH] git add -e documentation: rephrase note
From: Junio C Hamano @ 2009-10-19 5:38 UTC (permalink / raw)
To: Jeff King; +Cc: Miklos Vajna, Junio C Hamano, git
In-Reply-To: <20091019050456.GA15706@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Hmph. Here is my attempt. The text is (I hope) more clear, but I am
> still having trouble with the formatting. It looks fine in the HTML
> version, and if I am reading the XML right, the XML is correct. But
> docbook seems to screw up converting the XML to roff, giving this:
>
> · convert removal lines to context lines (don’t stage removal)
> Similarly, your patch will likely not apply if you:
>
> · add context or removal lines
>
> Am I missing something, or is it really a docbook bug? Does it render
> better for anybody else?
Not for me, and I have seen manpages lacking a blank line like the above
where I expect one in other places, so it is not very surprising.
> -- >8 --
> Subject: [PATCH] docs: give more hints about how "add -e" works
>
> The original text was not very descriptive about what you
> can and can't do; let's try to enumerate all cases.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Documentation/git-add.txt | 22 +++++++++++++++++++---
> 1 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index 45ebf87..b0a8420 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -86,9 +86,25 @@ OPTIONS
> edit it. After the editor was closed, adjust the hunk headers
> and apply the patch to the index.
> +
> -*NOTE*: Obviously, if you change anything else than the first character
> -on lines beginning with a space or a minus, the patch will no longer
> -apply.
> +The intent of this option is to pick and choose lines of the diff to
I'd slightly prefer "patch" over "diff" in this context.
> +apply, or even to modify the contents of lines to be staged. There are
> +three line types in a diff: addition lines (beginning with a plus),
> +removal lines (beginning with a minus), and context lines (beginning
> +with a space). In general, it should be safe to:
> ++
> +--
> +* remove addition lines (don't stage the line)
This is more like "don't add the line", isn't it? Also if this "+" line
has corresponding "-" line (i.e. it is a "rewrite to this" line), removal
of such a line would mean "instead of rewriting, remove it".
> +* modify the content of any addition lines (stage modified contents)
Would be "add differently".
> +* add new addition lines (stage the new line)
"Add more than what you have in the work tree"
While kibitzing like the above, I noticed that there is another thing that
may deserve warning even more. Suppose you added lines and the patch
between HEAD and the work tree looks like this:
diff --git a/t-f b/t-f
index e69de29..d68dd40 100644
--- a/t-f
+++ b/t-f
@@ -0,0 +1,4 @@
+a
+b
+c
+d
And you do "add -e" and edit the patch to:
diff --git a/t-f b/t-f
index e69de29..17c3f0b 100644
--- a/t-f
+++ b/t-f
@@ -0,0 +1,3 @@
+a
+e
+d
Obviously, the above patch is what "diff --cached" would show after such
an "add -e", but this does _not_ touch anything in the work tree (which is
correct; add is about moving changed contents to the index and it should
fundamentally not affect work tree). As a result, "diff" between the
index and the work tree now would read like this:
diff --git a/t-f b/t-f
index 17c3f0b..d68dd40 100644
--- a/t-f
+++ b/t-f
@@ -1,3 +1,4 @@
a
-e
+b
+c
d
IOW, your request to "add -e" was "I do not want to put the addition of
'c' in the index at this point (that is why you removed '+c')" and "I do
not want to put the addition of 'b' in the index; I want 'e' instead (that
is why you changed '+b' to '+e')". After "add -e" granted both requests,
what is left in the work tree can confuse the user. The "not at this
point" part of the first request is clearly visible that the leftover diff
has an addition of '+c'. But the user may expect that the second request,
"I don't want 'b', I want 'e'", would carry over to the work tree and not
see the apparent reversion of the wish (i.e. you changed it to add 'e'
instead of 'b' in "add -e" session, but it is reverted and "commit -a"
would record the version with 'b' instead).
^ permalink raw reply
* Re: [PATCH] git push: remove incomplete options list from help text
From: Junio C Hamano @ 2009-10-19 5:41 UTC (permalink / raw)
To: Jeff King
Cc: Nanako Shiraishi, Junio C Hamano, Miklos Vajna, Sebastian Pipping,
git
In-Reply-To: <20091019041033.GB7170@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Probably few people read it, as it was buried deep in a thread. But
> maybe we should settle on a rule like "short synopsis for usage, long
> synopsis for manpage" or whatever people think is best.
>
> Also, minor nit with your patch: should it be "[<options>]"?
Thanks, I agree with you on both counts.
^ permalink raw reply
* Re: [PATCH 2/3] DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
From: Björn Steinbrink @ 2009-10-19 5:58 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git, Johannes Schindelin, Jay Soffian
In-Reply-To: <20091019052043.6117@nanako3.lavabit.com>
On 2009.10.19 05:20:43 +0900, Nanako Shiraishi wrote:
> A user who always wants tracking can set the config option and use
> the new "git checkout frotz" shortcut, but a user who usually
> doesn't want tracking doesn't have the config option and when he
> wants tracking only for this new branch he can explicitly say "git
> checkout -t origin/frotz", right?
Well, branch.autosetupmerge has three possible values.
- true: Do the upstream setup when starting from remote tracking
branches
- always: Also do the upstream setup when starting from a local branch
head
- false: Don't do any upstream setup
The default is "true", which should catch the "git checkout frotz"
shortcut, as that selects a remote tracking branch as the starting
point. So the user doesn't have to change any config setting to have
that act as if -t was given.
Only if we doesn't want "git checkout frotz" to not do the upstream
setup, he needs to set branch.autosetupmerge to false.
And falling back to "git checkout --track/--no-track origin/frotz" he
can override whatever config setting he has.
Björn
^ permalink raw reply
* Re: [PATCH] Makefile: clean block-sha1/ directory instead of mozilla-sha1/
From: Junio C Hamano @ 2009-10-19 5:58 UTC (permalink / raw)
To: Carlos R. Mafra; +Cc: git
In-Reply-To: <20091011133219.GA28070@Pilar.aei.mpg.de>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH] Document git push -q
From: Junio C Hamano @ 2009-10-19 5:58 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Sebastian Pipping, Jeff King, git
In-Reply-To: <20091018235240.GU6115@genesis.frugalware.org>
Thanks; applied.
^ permalink raw reply
* Re: [PATCH] Use "--no-" prefix to switch off some of checkout dwimmery
From: Alex Riesen @ 2009-10-19 6:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Jay Soffian
In-Reply-To: <7vzl7omi5z.fsf@alter.siamese.dyndns.org>
On Mon, Oct 19, 2009 at 00:49, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>> + OPT_SET_INT(0, "dwim", &dwim_new_local_branch,
>> + "Guess local branch from remote reference (default)", 0),
>
> Humph, how does SET_INT know to set it to 1 with --dwim and set it to 0
> with --no-dwim?
It seems to do, though (I checked before sending).
^ permalink raw reply
* Re: [PATCH] Use "--no-" prefix to switch off some of checkout dwimmery
From: Alex Riesen @ 2009-10-19 6:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Jay Soffian
In-Reply-To: <81b0412b0910182307n53b4a51cvaa14829ea8b40207@mail.gmail.com>
On Mon, Oct 19, 2009 at 08:07, Alex Riesen <raa.lkml@gmail.com> wrote:
> On Mon, Oct 19, 2009 at 00:49, Junio C Hamano <gitster@pobox.com> wrote:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>>> + OPT_SET_INT(0, "dwim", &dwim_new_local_branch,
>>> + "Guess local branch from remote reference (default)", 0),
>>
>> Humph, how does SET_INT know to set it to 1 with --dwim and set it to 0
>> with --no-dwim?
>
> It seems to do, though (I checked before sending).
>
Right, just looked at the parse-options: it is defined for all types.
parse-options.c +/get_value
const int unset = flags & OPT_UNSET;
...
case OPTION_SET_INT:
*(int *)opt->value = unset ? 0 : opt->defval;
return 0;
Very useful.
^ permalink raw reply
* Re: [PATCH] Use "--no-" prefix to switch off some of checkout dwimmery
From: Junio C Hamano @ 2009-10-19 6:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Johannes Schindelin, Jay Soffian
In-Reply-To: <81b0412b0910182312h583e74e4v2678eb4375164c34@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> On Mon, Oct 19, 2009 at 08:07, Alex Riesen <raa.lkml@gmail.com> wrote:
>> On Mon, Oct 19, 2009 at 00:49, Junio C Hamano <gitster@pobox.com> wrote:
>>> Alex Riesen <raa.lkml@gmail.com> writes:
>>>> + OPT_SET_INT(0, "dwim", &dwim_new_local_branch,
>>>> + "Guess local branch from remote reference (default)", 0),
>>>
>>> Humph, how does SET_INT know to set it to 1 with --dwim and set it to 0
>>> with --no-dwim?
>>
>> It seems to do, though (I checked before sending).
>>
>
> Right, just looked at the parse-options: it is defined for all types.
>
> parse-options.c +/get_value
>
> const int unset = flags & OPT_UNSET;
> ...
> case OPTION_SET_INT:
> *(int *)opt->value = unset ? 0 : opt->defval;
> return 0;
>
> Very useful.
Ah, did you mean to change the default value to 1 as well?
^ permalink raw reply
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