* [PATCH] user-manual: Update for receive.denyCurrentBranch=refuse
From: W. Trevor King @ 2013-02-08 17:04 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
acd2a45 (Refuse updating the current branch in a non-bare repository
via push, 2009-02-11) changed the default to refuse such a push, but
it forgot to update the docs.
7d182f5 (Documentation: receive.denyCurrentBranch defaults to
'refuse', 2010-03-17) updated Documentation/config.txt, but forgot to
update the user manual.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5077e7c..8e55794 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1994,8 +1994,10 @@ handling this case.
Note that the target of a "push" is normally a
<<def_bare_repository,bare>> repository. You can also push to a
repository that has a checked-out working tree, but the working tree
-will not be updated by the push. This may lead to unexpected results if
-the branch you push to is the currently checked-out branch!
+will not be updated by the push. To protect against this, pushes to
+the currently checked-out branch of a repository are denied by
+default. See the description of the receive.denyCurrentBranch option
+in linkgit:git-config[1] for details.
As with `git fetch`, you may also set up configuration options to
save typing; so, for example, after
--
1.8.1.336.g94702dd
^ permalink raw reply related
* Re: [PATCH 4/4] git-remote-mediawiki: use Git's Makefile to build the script
From: Junio C Hamano @ 2013-02-08 18:13 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20130208174350.GA28266@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 08, 2013 at 06:34:37PM +0100, Matthieu Moy wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > That seems much cleaner to me. If done right, it could also let people
>> > put:
>> >
>> > CONTRIB_PERL += contrib/mw-to-git/git-remote-mediawiki
>>
>> Actually, you can already do this:
>>
>> SCRIPT_PERL += contrib/mw-to-git/git-remote-mediawiki.perl
>>
>> probably not by design, but it works!
>
> So putting:
>
> ROOT=contrib/mw-to-git
> git-remote-mediawiki: FORCE
> @make -C ../.. SCRIPT_PERL=$(ROOT)/$@.perl $(ROOT)/$@
>
> in contrib/mw-to-git/Makefile would already work? Neat.
That essentially is what [v2 2/2] does, no?
^ permalink raw reply
* Re: [PATCH 4/4] git-remote-mediawiki: use Git's Makefile to build the script
From: Jeff King @ 2013-02-08 18:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7v62223c8s.fsf@alter.siamese.dyndns.org>
On Fri, Feb 08, 2013 at 10:13:23AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Fri, Feb 08, 2013 at 06:34:37PM +0100, Matthieu Moy wrote:
> >
> >> Jeff King <peff@peff.net> writes:
> >>
> >> > That seems much cleaner to me. If done right, it could also let people
> >> > put:
> >> >
> >> > CONTRIB_PERL += contrib/mw-to-git/git-remote-mediawiki
> >>
> >> Actually, you can already do this:
> >>
> >> SCRIPT_PERL += contrib/mw-to-git/git-remote-mediawiki.perl
> >>
> >> probably not by design, but it works!
> >
> > So putting:
> >
> > ROOT=contrib/mw-to-git
> > git-remote-mediawiki: FORCE
> > @make -C ../.. SCRIPT_PERL=$(ROOT)/$@.perl $(ROOT)/$@
> >
> > in contrib/mw-to-git/Makefile would already work? Neat.
>
> That essentially is what [v2 2/2] does, no?
Yes (this one was cc'd to me, but the others were not, so I read it in
isolation). I think Matthieu's series is nicer than just that, though,
because it handles the single-file case installation, too, which
requires more support from the parent Makefile.
-Peff
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Ramkumar Ramachandra @ 2013-02-08 18:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael J Gruber, Jonathan Nieder, Michael Schubert, Git List,
Jeff King
In-Reply-To: <7vobfu3ev3.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> [remote "origin"]
> url = ... where Ram fetches and pulls from ...
> pushurl = ... where Ram pushes to ...
> fetch = refs/heads/*:refs/remotes/*
> updateTrackOnPush = no
>
> Then "git fetch" (or "git pull") will update the remote tracking
> branches Ram fetches from, and once his topic is finished, he can
> push to his publishing location, which won't touch the remote
> tracking branches used to keep track of the place he fetches from.
A "push" should never touch remote/refs/origin/* if there is a pushurl
configured. Otherwise, it should. I want my push to affect my
status. The configuration variable makes no sense and should not
exist.
Unfortunately, pushurl doesn't get the same privileges as url even
though they're equal remotes. How is my fork "inferior" to the
upstream project in any way? A lot of us might be working on this
fork, and we will need something corresponding to refs/remotes/* to
inspect its state. Like I said earlier, I think pushurl has a very
limited usecase: when the two URLs are actually mirrors (there is
really no fork; we're back in a centralized environment). In fact, I
think it should be deprecated, because it interferes with my more
general approach.
Let's see what happens if we have two actual remotes.
remote/refs/origin/* will be updated when I fetch from, and push to,
origin. remote/refs/ram/* will be updated when I fetch from, and
push to, ram. It's very simple, and I don't need this complex rule of
when to update refs. We should have a way to pair remotes together as
upstream/ downstream in the future. Maybe even have a hierarchy of
remotes.
^ permalink raw reply
* Re: [PATCH v3] branch: show rebase/bisect info when possible instead of "(no branch)"
From: Junio C Hamano @ 2013-02-08 18:35 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Matthieu Moy, Jonathan Niedier
In-Reply-To: <1360318171-17614-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This prints more helpful info when HEAD is detached: is it detached
> because of bisect or rebase? What is the original branch name in those
> cases?
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Keep "no branch" in all cases. Just append "rebasing/bisecting [%s]"
> when applicable.
>
> builtin/branch.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
> t/t6030-bisect-porcelain.sh | 2 +-
> 2 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 6371bf9..26c0c3d 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -550,6 +550,48 @@ static int calc_maxwidth(struct ref_list *refs)
> return w;
> }
>
> +static char *get_head_description()
> +{
> + struct stat st;
> + struct strbuf sb = STRBUF_INIT;
> + struct strbuf result = STRBUF_INIT;
> + int bisect = 0;
> + int ret;
> + if (!stat(git_path("rebase-merge"), &st) && S_ISDIR(st.st_mode))
> + ret = strbuf_read_file(&sb, git_path("rebase-merge/head-name"), 0);
> + else if (!access(git_path("rebase-apply/rebasing"), F_OK))
> + ret = strbuf_read_file(&sb, git_path("rebase-apply/head-name"), 0);
> + else if (!access(git_path("BISECT_LOG"), F_OK)) {
> + ret = strbuf_read_file(&sb, git_path("BISECT_START"), 0);
> + bisect = 1;
> + } else
> + return xstrdup(_("(no branch)"));
> +
> + if (ret <= 0) {
Doesn't the general "negative signals an error" apply here?
The end result may be the same, as the later part of this function
that uses sb with len==0 ends up showing the same "bisecting" (or
"rebasing") without any other information, but the logic to reach
that outcome looks wrong.
> + if (bisect)
> + return xstrdup(_("(no branch, bisecting)"));
> + else
> + return xstrdup(_("_(no branch, rebasing)"));
> + }
> +
> + while (sb.len && sb.buf[sb.len - 1] == '\n')
> + strbuf_setlen(&sb, sb.len - 1);
> +
> + if (bisect) {
> + unsigned char sha1[20];
> + if (!get_sha1_hex(sb.buf, sha1))
> + strbuf_addstr(&result, _("(no branch, bisecting)"));
> + else
> + strbuf_addf(&result, _("(no branch, bisecting %s)"), sb.buf);
> + } else {
> + if (!prefixcmp(sb.buf, "refs/heads/"))
> + strbuf_addf(&result, _("(no branch, rebasing %s)"), sb.buf + 11);
> + else
> + strbuf_addstr(&result, _("(no branch, rebasing)"));
> + }
> + strbuf_release(&sb);
> + return strbuf_detach(&result, NULL);
> +}
We may want to refactor wt_status_print_state() and its callee a bit
so that it and this part can share the logic without duplication and
risk implementing subtly different decision. wt_status used to have
clean separation between collection phase and presentation phase,
but the wall between the phases seems deteriorated over time as more
"in progress" crufts have been piled on top.
Such a refactoring may look larger than necessary, but on the other
hand, I do not see this feature very useful if it can over time
drift away from what we will see in "git status", so...
>
> static void show_detached(struct ref_list *ref_list)
> {
> @@ -557,7 +599,7 @@ static void show_detached(struct ref_list *ref_list)
>
> if (head_commit && is_descendant_of(head_commit, ref_list->with_commit)) {
> struct ref_item item;
> - item.name = xstrdup(_("(no branch)"));
> + item.name = get_head_description();
> item.width = utf8_strwidth(item.name);
> item.kind = REF_LOCAL_BRANCH;
> item.dest = NULL;
> diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
> index 3e0e15f..9b6f0d0 100755
> --- a/t/t6030-bisect-porcelain.sh
> +++ b/t/t6030-bisect-porcelain.sh
> @@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing ".git/BISECT_START" not modified if
> cp .git/BISECT_START saved &&
> test_must_fail git bisect start $HASH4 foo -- &&
> git branch > branch.output &&
> - test_i18ngrep "* (no branch)" branch.output > /dev/null &&
> + test_i18ngrep "* (no branch, bisecting other)" branch.output > /dev/null &&
> test_cmp saved .git/BISECT_START
> '
> test_expect_success 'bisect start: no ".git/BISECT_START" if mistaken rev' '
^ permalink raw reply
* Re: [PATCH] user-manual: Rewrite git-gc section for automatic packing
From: W. Trevor King @ 2013-02-08 18:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7vd2wa3dxm.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]
On Fri, Feb 08, 2013 at 09:36:53AM -0800, Junio C Hamano wrote:
> I'd rather phrase it like "... may take long, so you would want to
> run it explicitly from time to time to avoid automatic gc kicking in
> when it is not convenient for you".
Works for me.
> Removal of this is a good change, though.
I just read through the manual cover to cover, so I have a number of
other fixes in the pipe (from which I've already submitted the
receive.denyCurrentBranch patch). Should I bundle them all into a
single series to reduce clutter on the list, or will that just lead to
resending boring fixes while we hash out the right handling for more
involved ones?
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Jonathan Nieder @ 2013-02-08 18:36 UTC (permalink / raw)
To: Michael J Gruber
Cc: Junio C Hamano, Ramkumar Ramachandra, Michael Schubert, Git List,
Jeff King
In-Reply-To: <5114D5B0.5080906@drmicha.warpmail.net>
Michael J Gruber wrote:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>> "Wait, why did the remote rewind?"
>>
>> Oh, I am very well aware of that glitch.
>>
>> "git push" has this hack to pretend as if the pusher immediately
>> turned around and fetched from the remote.
>>
>> It shouldn't have been made to do so unconditionally; instead it
>> should have been designed to give the pushee a way to optionally
>> tell you "I acccept this push, but you may not see it to be updated
>> to that exact value you pushed when you fetched from me right now".
Yes, I agree with this.
The "git push" hack does seem to be useful in practice for helping
people just starting to use git. If they have a separate "gitk --all"
window open, they can refresh it and see the remote-tracking branch
corresponding to the branch that has been pushed advancing. It matches
a model in which remote-tracking refs represent "git's idea of where
these branches are in the remote repository".
And in that model, a remote being able to respond to a push with
"ref update queued, but please keep in mind that it may take me a
while to chew through that queue" should be perfectly reasonable.
[...]
> And this seems to be more natural, too. It can keep the internals (the
> auxiliary ref on the server side) hidden from the user.
Just to clarify: this is not an internal ref being exposed. No
auxiliary refs/for/master ref actually exists. The ref Gerrit users
push to is a UI fiction.
That's important because otherwise two developers could not propose
changes for the same branch at the same time.
Jonathan
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Ramkumar Ramachandra @ 2013-02-08 18:42 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Michael Schubert, Git List, Junio C Hamano
In-Reply-To: <20130207233017.GD19397@google.com>
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> And yes, a regular `git push origin refs/for/master` is just retarded.
>
> The usual incantation is "git push gerrit HEAD:refs/for/master". Is
> the code review creation push that uses a different branchname from
> the branch the integrator pulls what seems backward, or is it the need
> to specify a refname at all on the command line?
How else would you design a system to differentiate between a
push-for-review, and push-to-update-ref?
On a slightly unrelated note, it would be nice if we could streamline
the git-format-patch, git-send-email process. Let's say we make it a
push', which has a pre-hook that fires up the $EDITOR for a cover
letter. Wouldn't you love it if this push' would update refs on your
private fork and fire off emails to the Git List? Bonus for contrib/:
fetch the Google address book, and allow me to auto-complete names
when sending emails.
> I agree that a "[branch "master"] pushremote" configuration would be
> handy. pushremote instead of remotepush to be less surprising to
> people who have already seen pushurl.
Thanks for that, by the way (used in RFC patch). My taste in variable
names is a little sour.
^ permalink raw reply
* Re: [PATCH v2 2/3] count-objects: report garbage files in pack directory too
From: Junio C Hamano @ 2013-02-08 18:44 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1360295307-5469-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> prepare_packed_git_one() is modified to allow count-objects to hook a
> report function to so we don't need to duplicate the pack searching
> logic in count-objects.c. When report_pack_garbage is NULL, the
> overhead is insignificant.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Documentation/git-count-objects.txt | 4 +-
> builtin/count-objects.c | 18 ++++++++-
> sha1_file.c | 81 +++++++++++++++++++++++++++++++++++--
> 3 files changed, 97 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
> index e816823..1611d7c 100644
> --- a/Documentation/git-count-objects.txt
> +++ b/Documentation/git-count-objects.txt
> @@ -33,8 +33,8 @@ size-pack: disk space consumed by the packs, in KiB
> prune-packable: the number of loose objects that are also present in
> the packs. These objects could be pruned using `git prune-packed`.
> +
> -garbage: the number of files in loose object database that are not
> -valid loose objects
> +garbage: the number of files in object database that are not valid
> +loose objects nor valid packs
>
> GIT
> ---
> diff --git a/builtin/count-objects.c b/builtin/count-objects.c
> index 9afaa88..118b2ae 100644
> --- a/builtin/count-objects.c
> +++ b/builtin/count-objects.c
> @@ -9,6 +9,20 @@
> #include "builtin.h"
> #include "parse-options.h"
>
> +static unsigned long garbage;
> +
> +extern void (*report_pack_garbage)(const char *path, int len, const char *name);
> +static void real_report_pack_garbage(const char *path, int len, const char *name)
> +{
Don't some callers call this on paths outside objects/pack/
directory? Is it still report-pack-garbage?
> + if (len && name)
> + error("garbage found: %.*s/%s", len, path, name);
> + else if (!len && name)
> + error("garbage found: %s%s", path, name);
> + else
> + error("garbage found: %s", path);
> + garbage++;
> +}
> +
> static void count_objects(DIR *d, char *path, int len, int verbose,
> unsigned long *loose,
> off_t *loose_size,
> @@ -76,7 +90,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
> const char *objdir = get_object_directory();
> int len = strlen(objdir);
> char *path = xmalloc(len + 50);
> - unsigned long loose = 0, packed = 0, packed_loose = 0, garbage = 0;
> + unsigned long loose = 0, packed = 0, packed_loose = 0;
> off_t loose_size = 0;
> struct option opts[] = {
> OPT__VERBOSE(&verbose, N_("be verbose")),
> @@ -87,6 +101,8 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
> /* we do not take arguments other than flags for now */
> if (argc)
> usage_with_options(count_objects_usage, opts);
> + if (verbose)
> + report_pack_garbage = real_report_pack_garbage;
> memcpy(path, objdir, len);
> if (len && objdir[len-1] != '/')
> path[len++] = '/';
> diff --git a/sha1_file.c b/sha1_file.c
> index 40b2329..cc6ef03 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -21,6 +21,7 @@
> #include "sha1-lookup.h"
> #include "bulk-checkin.h"
> #include "streaming.h"
> +#include "dir.h"
>
> #ifndef O_NOATIME
> #if defined(__linux__) && (defined(__i386__) || defined(__PPC__))
> @@ -1000,6 +1001,54 @@ void install_packed_git(struct packed_git *pack)
> packed_git = pack;
> }
>
> +/* A hook for count-objects to report invalid files in pack directory */
> +void (*report_pack_garbage)(const char *path, int len, const char *name);
> +
> +static const char *known_pack_extensions[] = { ".pack", ".keep", NULL };
This sounds wrong. Isn't ".idx" also known?
> +static void report_garbage(struct string_list *list)
> +{
> + struct strbuf sb = STRBUF_INIT;
> + struct packed_git *p;
> + int i;
> +
> + if (!report_pack_garbage)
> + return;
> +
> + sort_string_list(list);
> +
> + for (p = packed_git; p; p = p->next) {
> + struct string_list_item *item;
> + if (!p->pack_local)
> + continue;
> + strbuf_reset(&sb);
> + strbuf_add(&sb, p->pack_name,
> + strlen(p->pack_name) - strlen(".pack"));
> + item = string_list_lookup(list, sb.buf);
> + if (!item)
> + continue;
> + /*
> + * string_list_lookup does not guarantee to return the
> + * first matched string if it's duplicated.
> + */
> + while (item - list->items &&
> + !strcmp(item[-1].string, item->string))
> + item--;
> + while (item - list->items < list->nr &&
> + !strcmp(item->string, sb.buf)) {
> + item->util = NULL; /* non-garbage mark */
> + item++;
> + }
> + }
> + for (i = 0; i < list->nr; i++) {
> + struct string_list_item *item = list->items + i;
> + if (!item->util)
> + continue;
> + report_pack_garbage(item->string, 0, item->util);
> + }
> + strbuf_release(&sb);
> +}
> +
> static void prepare_packed_git_one(char *objdir, int local)
> {
> /* Ensure that this buffer is large enough so that we can
> @@ -1009,6 +1058,7 @@ static void prepare_packed_git_one(char *objdir, int local)
> int len;
> DIR *dir;
> struct dirent *de;
> + struct string_list garbage = STRING_LIST_INIT_DUP;
>
> sprintf(path, "%s/pack", objdir);
> len = strlen(path);
> @@ -1024,14 +1074,37 @@ static void prepare_packed_git_one(char *objdir, int local)
> int namelen = strlen(de->d_name);
> struct packed_git *p;
>
> - if (!has_extension(de->d_name, ".idx"))
> + if (len + namelen + 1 > sizeof(path)) {
> + if (report_pack_garbage)
> + report_pack_garbage(path, len - 1, de->d_name);
A pack/in/a/very/long/path/pack-0000000000000000000000000000000000000000.pack
may pass when fed to "git verify-pack", but this will report it as "garbage",
without reporting what is wrong with it. Wouldn't that confuse users?
> continue;
> + }
> +
> + strcpy(path + len, de->d_name);
>
> - if (len + namelen + 1 > sizeof(path))
> + if (!has_extension(de->d_name, ".idx")) {
> + struct string_list_item *item;
> + int i, n;
> + if (!report_pack_garbage)
> + continue;
> + if (is_dot_or_dotdot(de->d_name))
> + continue;
> + for (i = 0; known_pack_extensions[i]; i++)
> + if (has_extension(de->d_name,
> + known_pack_extensions[i]))
> + break;
> + if (!known_pack_extensions[i]) {
> + report_pack_garbage(path, 0, NULL);
> + continue;
> + }
> + n = strlen(path) - strlen(known_pack_extensions[i]);
> + item = string_list_append_nodup(&garbage,
> + xstrndup(path, n));
> + item->util = (void*)known_pack_extensions[i];
> continue;
> + }
Why isn't this part more like this?
if (dot-or-dotdot) {
continue;
} else if (has_extension(de->d_name, ".idx")) {
do things for the .idx file;
} else if (has_extension(de->d_name, ".pack") {
do things for the .pack file, including
queuing the name if we haven't seen
corresponding .idx for later examination;
} else if (has_extension(de->d_name, ".keep") {
nothing special for now but we may
want to add some other checks later
} else {
everything else is a garbage
report_pack_garbage();
}
>
> /* Don't reopen a pack we already have. */
> - strcpy(path + len, de->d_name);
> for (p = packed_git; p; p = p->next) {
> if (!memcmp(path, p->pack_name, len + namelen - 4))
> break;
> @@ -1047,6 +1120,8 @@ static void prepare_packed_git_one(char *objdir, int local)
> install_packed_git(p);
> }
> closedir(dir);
> + report_garbage(&garbage);
> + string_list_clear(&garbage, 0);
> }
>
> static int sort_pack(const void *a_, const void *b_)
^ permalink raw reply
* Re: [PATCH v2 3/3] count-objects: report how much disk space taken by garbage files
From: Junio C Hamano @ 2013-02-08 18:47 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1360295307-5469-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> We may do some redundant stat() here, but I don't think it can slow
> count-objects down much to worry about.
I don't either. Looks like a good change to me.
It appears that the sb.buf refactoring is better done to the
previous patch, but that is minor.
> Documentation/git-count-objects.txt | 2 ++
> builtin/count-objects.c | 29 ++++++++++++++++++-----------
> 2 files changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
> index 1611d7c..da6e72e 100644
> --- a/Documentation/git-count-objects.txt
> +++ b/Documentation/git-count-objects.txt
> @@ -35,6 +35,8 @@ the packs. These objects could be pruned using `git prune-packed`.
> +
> garbage: the number of files in object database that are not valid
> loose objects nor valid packs
> ++
> +size-garbage: disk space consumed by garbage files, in KiB
>
> GIT
> ---
> diff --git a/builtin/count-objects.c b/builtin/count-objects.c
> index 118b2ae..90d476d 100644
> --- a/builtin/count-objects.c
> +++ b/builtin/count-objects.c
> @@ -10,24 +10,33 @@
> #include "parse-options.h"
>
> static unsigned long garbage;
> +static off_t size_garbage;
>
> extern void (*report_pack_garbage)(const char *path, int len, const char *name);
> static void real_report_pack_garbage(const char *path, int len, const char *name)
> {
> + struct strbuf sb = STRBUF_INIT;
> + struct stat st;
> +
> if (len && name)
> - error("garbage found: %.*s/%s", len, path, name);
> + strbuf_addf(&sb, "%.*s/%s", len, path, name);
> else if (!len && name)
> - error("garbage found: %s%s", path, name);
> + strbuf_addf(&sb, "%s%s", path, name);
> else
> - error("garbage found: %s", path);
> + strbuf_addf(&sb, "%s", path);
> + error(_("garbage found: %s"), sb.buf);
> +
> + if (!stat(sb.buf, &st))
> + size_garbage += st.st_size;
> +
> garbage++;
> + strbuf_release(&sb);
> }
>
> static void count_objects(DIR *d, char *path, int len, int verbose,
> unsigned long *loose,
> off_t *loose_size,
> - unsigned long *packed_loose,
> - unsigned long *garbage)
> + unsigned long *packed_loose)
> {
> struct dirent *ent;
> while ((ent = readdir(d)) != NULL) {
> @@ -59,11 +68,8 @@ static void count_objects(DIR *d, char *path, int len, int verbose,
> (*loose_size) += xsize_t(on_disk_bytes(st));
> }
> if (bad) {
> - if (verbose) {
> - error("garbage found: %.*s/%s",
> - len + 2, path, ent->d_name);
> - (*garbage)++;
> - }
> + if (verbose)
> + report_pack_garbage(path, len + 2, ent->d_name);
> continue;
> }
> (*loose)++;
> @@ -113,7 +119,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
> if (!d)
> continue;
> count_objects(d, path, len, verbose,
> - &loose, &loose_size, &packed_loose, &garbage);
> + &loose, &loose_size, &packed_loose);
> closedir(d);
> }
> if (verbose) {
> @@ -138,6 +144,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
> printf("size-pack: %lu\n", (unsigned long) (size_pack / 1024));
> printf("prune-packable: %lu\n", packed_loose);
> printf("garbage: %lu\n", garbage);
> + printf("size-garbage: %lu\n", (unsigned long) (size_garbage / 1024));
> }
> else
> printf("%lu objects, %lu kilobytes\n",
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 19:13 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Michael J Gruber, Jonathan Nieder, Michael Schubert, Git List,
Jeff King
In-Reply-To: <CALkWK0nYRiPLnBXFarp8UzZgGvA5Y6motvr5HMFy56ANr161HA@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Junio C Hamano wrote:
>> [remote "origin"]
>> url = ... where Ram fetches and pulls from ...
>> pushurl = ... where Ram pushes to ...
>> fetch = refs/heads/*:refs/remotes/*
>> updateTrackOnPush = no
>>
>> Then "git fetch" (or "git pull") will update the remote tracking
>> branches Ram fetches from, and once his topic is finished, he can
>> push to his publishing location, which won't touch the remote
>> tracking branches used to keep track of the place he fetches from.
>
> A "push" should never touch remote/refs/origin/* if there is a pushurl
> configured. Otherwise, it should.
That is a horrible design, no?
Because one of the main use case for pushurl is to use url = git://
for less overhead and pushurl = ssh+git:// for authentication but
otherwise going to the same place. So if "git push" is allowed to
pretend you immediately turned around and fetched, push to that
pushurl will pretend it was followed by a fetch from the
corresponding url.
You need a way to tell if the pushurl/url pair is used for that
purpose to let Git know if that is the case.
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 19:18 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Jonathan Nieder, Michael Schubert, Git List
In-Reply-To: <CALkWK0kR-KWJbG_kWSf7+JMJEQc7vO0Emx=_yogCB0jMBfccAg@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Jonathan Nieder wrote:
>> Ramkumar Ramachandra wrote:
>>
>>> And yes, a regular `git push origin refs/for/master` is just retarded.
>>
>> The usual incantation is "git push gerrit HEAD:refs/for/master". Is
>> the code review creation push that uses a different branchname from
>> the branch the integrator pulls what seems backward, or is it the need
>> to specify a refname at all on the command line?
>
> How else would you design a system to differentiate between a
> push-for-review, and push-to-update-ref?
You don't have to.
If the reviewed result is merged on the server side and appear on
'master', nobody has to push to update refs/heads/master.
^ permalink raw reply
* Re: [PATCH 1/6] graph: output padding for merge subsequent parents
From: John Keeping @ 2013-02-08 19:31 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, Jeff King, Dale R. Worley, git
In-Reply-To: <b98eb2bfe2b022ddf1afbe9f7123accfe068e8c9.1360267849.git.john@keeping.me.uk>
[Moved from the thread where this was initially posted to reply to the
series.]
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> This works, but if we know we're not going to enter the while loop, it
> seams even easier to do this:
>
> --- a/graph.c
> +++ b/graph.c
> @@ -1227,7 +1227,17 @@ void graph_show_commit(struct git_graph *graph)
> if (!graph)
> return;
>
> - while (!shown_commit_line && !graph_is_commit_finished(graph)) {
> + /*
> + * When showing a diff of a merge against each of its parents, we
> + * are called once for each parent without graph_update having been
> + * called. In this case, simply output a single padding line.
> + */
> + if (graph_is_commit_finished(graph)) {
> + graph_show_padding(graph);
> + return;
> + }
> +
> + while (!shown_commit_line) {
This looks good to me. I'll amend locally and re-send in a few days
after giving others a chance to comment.
John
^ permalink raw reply
* Re: [PATCH] graph: output padding for merge subsequent parents
From: Junio C Hamano @ 2013-02-08 19:40 UTC (permalink / raw)
To: Matthieu Moy; +Cc: John Keeping, Dale R. Worley, git
In-Reply-To: <vpqtxpmae1p.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> John Keeping <john@keeping.me.uk> writes:
>
>> diff --git a/graph.c b/graph.c
>> index 391a712..2a3fc5c 100644
>> --- a/graph.c
>> +++ b/graph.c
>> @@ -1227,6 +1227,16 @@ void graph_show_commit(struct git_graph *graph)
>> if (!graph)
>> return;
>>
>> + /*
>> + * When showing a diff of a merge against each of its parents, we
>> + * are called once for each parent without graph_update having been
>> + * called. In this case, simply output a single padding line.
>> + */
>> + if (graph_is_commit_finished(graph)) {
>> + graph_show_padding(graph);
>> + shown_commit_line = 1;
>> + }
>> +
>> while (!shown_commit_line && !graph_is_commit_finished(graph)) {
>
> This works, but if we know we're not going to enter the while loop, it
> seams even easier to do this:
>
> --- a/graph.c
> +++ b/graph.c
> @@ -1227,7 +1227,17 @@ void graph_show_commit(struct git_graph *graph)
> if (!graph)
> return;
>
> - while (!shown_commit_line && !graph_is_commit_finished(graph)) {
> + /*
> + * When showing a diff of a merge against each of its parents, we
> + * are called once for each parent without graph_update having been
> + * called. In this case, simply output a single padding line.
> + */
> + if (graph_is_commit_finished(graph)) {
> + graph_show_padding(graph);
> + return;
> + }
> +
> + while (!shown_commit_line) {
> shown_commit_line = graph_next_line(graph, &msgbuf);
> fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
> if (!shown_commit_line)
In this particular case, with the current state of this function, it
is probably OK, but an early return like this tend to be a source of
future bugs in the longer term, to make the codeflow skip whatever
necessary clean-up that needs to be done after the loop exits.
^ permalink raw reply
* `git checkout --orpan` leaves a dirty worktree
From: Ramkumar Ramachandra @ 2013-02-08 19:50 UTC (permalink / raw)
To: Git List
Hi,
Why should I have to `git rm -rf .` after a `git checkout --orphan`?
What sort of misfeature/ incomplete feature is this?
Ram
^ permalink raw reply
* Re: `git checkout --orpan` leaves a dirty worktree
From: Jonathan Nieder @ 2013-02-08 20:04 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0mjf5vsiHvMW-QyzMHdmZQvdzjw_ORJnMd=mT6RCqB1xg@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Why should I have to `git rm -rf .` after a `git checkout --orphan`?
> What sort of misfeature/ incomplete feature is this?
One designed for the "going open source" use case, where you have
existing code that you want to put into a new branch without history.
When there is no existing code, it seems simpler to do
cd ..
git init code-that-has-nothing-to-do-previous-cwd
cd code-that-*
... hack hack hack ...
git commit
git remote add origin <url>
git push -u origin master
BTW, I suspect a clearer way to say what you meant is "Sounds like a
misfeature" which is gentler and more focused than an implied "What
kind of idiot designed this?" Even if you are thinking the latter. :)
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [RFC/PATCH] Introduce branch.<name>.pushremote
From: Junio C Hamano @ 2013-02-08 20:04 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Jonathan Nieder, Jeff King
In-Reply-To: <1360307982-20027-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 9b11597..0b3b1f8 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -727,6 +727,12 @@ branch.<name>.remote::
> remote to fetch from/push to. It defaults to `origin` if no remote is
> configured. `origin` is also used if you are not on any branch.
>
> +branch.<name>.pushremote::
> + When in branch <name>, it tells 'git push' which remote to
> + push to. It falls back to `branch.<name>.remote`, and
> + defaults to `origin` if no remote is configured. `origin` is
> + also used if you are not on any branch.
Sounds sensible (modulo the missing "default location to push to
that is not per remote" bit, obviously). I think "When _on_ branch"
is more correct, to match "if you are not on any branch" at the end,
though.
> diff --git a/remote.c b/remote.c
> index e53a6eb..d6fcfc0 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -48,6 +48,7 @@ static int branches_nr;
>
> static struct branch *current_branch;
> static const char *default_remote_name;
> +static const char *pushremote_name;
> static int explicit_default_remote_name;
>
> static struct rewrites rewrites;
> @@ -363,6 +364,12 @@ static int handle_config(const char *key, const char *value, void *cb)
> default_remote_name = branch->remote_name;
> explicit_default_remote_name = 1;
> }
> + } else if (!strcmp(subkey, ".pushremote")) {
> + if (!value)
> + return config_error_nonbool(key);
> + branch->pushremote_name = xstrdup(value);
Perhaps use git_config_string()?
I also notice that git_config_string() should free (*dest) if there
already is some value, and that has to be done after auditing all
existing callers.
> + if (branch == current_branch)
> + pushremote_name = branch->pushremote_name;
Why is this global only when current_branch is involved?
In other words, does it make sense to read branch.$name.pushremote
for all the other irrelevant branches?
In yet other words, perhaps adding pushremote_name to the branch
structure is unneeded, and you only need this single global
variable?
(The remainder of the patch unsnipped for others' reference.)
> @@ -700,6 +707,40 @@ struct remote *remote_get(const char *name)
> return ret;
> }
>
> +struct remote *pushremote_get(const char *name)
> +{
> + struct remote *ret;
> + int name_given = 0;
> +
> + read_config();
> + if (name)
> + name_given = 1;
> + else {
> + if (pushremote_name) {
> + name = pushremote_name;
> + name_given = 1;
> + } else {
> + name = default_remote_name;
> + name_given = explicit_default_remote_name;
> + }
> + }
> +
> + ret = make_remote(name, 0);
> + if (valid_remote_nick(name)) {
> + if (!valid_remote(ret))
> + read_remotes_file(ret);
> + if (!valid_remote(ret))
> + read_branches_file(ret);
> + }
> + if (name_given && !valid_remote(ret))
> + add_url_alias(ret, name);
> + if (!valid_remote(ret))
> + return NULL;
> + ret->fetch = parse_fetch_refspec(ret->fetch_refspec_nr, ret->fetch_refspec);
> + ret->push = parse_push_refspec(ret->push_refspec_nr, ret->push_refspec);
> + return ret;
> +}
> +
> int remote_is_configured(const char *name)
> {
> int i;
> diff --git a/remote.h b/remote.h
> index 251d8fd..aa42ff5 100644
> --- a/remote.h
> +++ b/remote.h
> @@ -51,6 +51,7 @@ struct remote {
> };
>
> struct remote *remote_get(const char *name);
> +struct remote *pushremote_get(const char *name);
> int remote_is_configured(const char *name);
>
> typedef int each_remote_fn(struct remote *remote, void *priv);
> @@ -130,6 +131,7 @@ struct branch {
> const char *refname;
>
> const char *remote_name;
> + const char *pushremote_name;
> struct remote *remote;
>
> const char **merge_name;
^ permalink raw reply
* Re: [RFC/PATCH] Introduce remote.pushdefault
From: Junio C Hamano @ 2013-02-08 20:11 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List, Jonathan Nieder, Jeff King
In-Reply-To: <1360314123-1259-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 9b11597..82a4a78 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1884,6 +1884,10 @@ receive.updateserverinfo::
> If set to true, git-receive-pack will run git-update-server-info
> after receiving data from git-push and updating refs.
>
> +remote.pushdefault::
> + The remote to push to by default. Overrides the
> + branch-specific configuration `branch.<name>.remote`.
It feels unexpected to see "I may have said while on this branch I
push there and on that branch I push somewhere else, but no, with
this single configuration I'm invalidating all these previous
statements, and all pushes go to this new place".
Shouldn't the default be the default that is to be overridden by
other configuration that is more specific? That is, "I would
normally push to this remote and unless I say otherwise that is all
I have to say, but for this particular branch, I push to somehwere
else".
> diff --git a/builtin/push.c b/builtin/push.c
> index 42b129d..d447a80 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
> @@ -322,7 +322,7 @@ static int push_with_options(struct transport *transport, int flags)
> static int do_push(const char *repo, int flags)
> {
> int i, errs;
> - struct remote *remote = remote_get(repo);
> + struct remote *remote = pushremote_get(repo);
> const char **url;
> int url_nr;
>
> diff --git a/remote.c b/remote.c
> index e53a6eb..08bb803 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -48,6 +48,7 @@ static int branches_nr;
>
> static struct branch *current_branch;
> static const char *default_remote_name;
> +static const char *pushremote_name;
> static int explicit_default_remote_name;
>
> static struct rewrites rewrites;
> @@ -349,6 +350,14 @@ static int handle_config(const char *key, const char *value, void *cb)
> const char *subkey;
> struct remote *remote;
> struct branch *branch;
> + if (!prefixcmp(key, "remote.")) {
> + name = key + 7;
> + if (!strcmp(name, "pushdefault")) {
> + if (!value)
> + return config_error_nonbool(key);
> + pushremote_name = xstrdup(value);
> + }
> + }
> if (!prefixcmp(key, "branch.")) {
> name = key + 7;
> subkey = strrchr(name, '.');
> @@ -388,8 +397,6 @@ static int handle_config(const char *key, const char *value, void *cb)
> add_instead_of(rewrite, xstrdup(value));
> }
> }
> - if (prefixcmp(key, "remote."))
> - return 0;
Why is this no longer needed?
All the remainder of this function is about "remote.*" config and
this rejects other keys, like "user.name", etc.
I'm a bit confused....
> name = key + 7;
> if (*name == '/') {
> warning("Config remote shorthand cannot begin with '/': %s",
^ permalink raw reply
* Re: `git checkout --orpan` leaves a dirty worktree
From: Ramkumar Ramachandra @ 2013-02-08 20:11 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git List
In-Reply-To: <20130208200402.GB8461@google.com>
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
> One designed for the "going open source" use case, where you have
> existing code that you want to put into a new branch without history.
> BTW, I suspect a clearer way to say what you meant is "Sounds like a
> misfeature" which is gentler and more focused than an implied "What
> kind of idiot designed this?" Even if you are thinking the latter. :)
Yes, I do feel stupid now.
BTW, Is there a better way to clean out the worktree than `git rm -rf
.`, since that fails for submodules? The impulsive `reset --hard`
obviously fails because there is no HEAD.
Thanks.
^ permalink raw reply
* Re: `git checkout --orpan` leaves a dirty worktree
From: Junio C Hamano @ 2013-02-08 20:12 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ramkumar Ramachandra, Git List
In-Reply-To: <20130208200402.GB8461@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Ramkumar Ramachandra wrote:
>
>> Why should I have to `git rm -rf .` after a `git checkout --orphan`?
>> What sort of misfeature/ incomplete feature is this?
>
> One designed for the "going open source" use case, where you have
> existing code that you want to put into a new branch without history.
> When there is no existing code, it seems simpler to do
>
> cd ..
> git init code-that-has-nothing-to-do-previous-cwd
> cd code-that-*
> ... hack hack hack ...
> git commit
> git remote add origin <url>
> git push -u origin master
>
> BTW, I suspect a clearer way to say what you meant is "Sounds like a
> misfeature" which is gentler and more focused than an implied "What
> kind of idiot designed this?" Even if you are thinking the latter. :)
So true ;-).
Especially when you may an answer that may make _you_ look like an
idiot ;-)
^ permalink raw reply
* Re: `git checkout --orpan` leaves a dirty worktree
From: Junio C Hamano @ 2013-02-08 20:17 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Jonathan Nieder, Git List
In-Reply-To: <CALkWK0mdLabT7XyuYsDCROBC5FX+tDgyMnjMRbdkO41PTWd_Ug@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> BTW, Is there a better way to clean out the worktree than `git rm -rf
> .`, since that fails for submodules? The impulsive `reset --hard`
> obviously fails because there is no HEAD.
I _think_ the "git rm" is one of the things on Jens's roadmap. Also
I think "reset --hard" these days does know what to do when you do
not have any history yet.
^ permalink raw reply
* Improve 'git help' with basic user guide linkss
From: Philip Oakley @ 2013-02-08 20:28 UTC (permalink / raw)
To: Git List
I'm looking at extending the 'git help' to include some information for
the basic user who isn't ready for the extensive man page documentation
for the various commands.
If the user doesn't yet know which is the relevant command then they
should also be offered a clue on how to finding the various guides. Many
users are stuck on the 'If I were you I wouldn't start from here' step
(many blog comments on the alleged poor documentation and difficulty of
understanding ...).
I've started on adding a few tweaks to the basic 'git help' message,
adding an end line indicating that there are guides, such as 'tutorial'.
Initial hacks at https://github.com/PhilipOakley/git/commits/morehelp
for thos interested.
My real question is on the right approach to generating a list of guides
and including them into the git help options. I'm planning on extending
the command-list.txt file to include 'guides' and then extending the
generate-cmdlist.sh to generate a guides array in common-cmds.h.
I'm thinking of adding -g --guides and -c --commands options to
complement the existing -a --all (becomes both commands and guides)
option. I'm not yet sure how to determine which other special guides
should be listed (api- etc.) and when.
I was expecting to update the user-manual. to become gituser-manual.txt
so that the existing 'git help user-manual' scheme would discover it.
The Tutorial and the User manual obviously(?) being the first port of
call for the confused user.
Does this appear sensible, and should the Documentation/* directories
also be searched for 'guides', or is that a step too far [and it's less
coding] ?
Philip Oakley
^ permalink raw reply
* Re: `git checkout --orpan` leaves a dirty worktree
From: Martin von Zweigbergk @ 2013-02-08 20:31 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0mjf5vsiHvMW-QyzMHdmZQvdzjw_ORJnMd=mT6RCqB1xg@mail.gmail.com>
I'm curious what your use case is.
The behavior has been inconvenient for me too, but I have only used it
in test cases; I have no real use case where I wanted to create an
unborn/orphan branch.
On Fri, Feb 8, 2013 at 11:50 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Hi,
>
> Why should I have to `git rm -rf .` after a `git checkout --orphan`?
> What sort of misfeature/ incomplete feature is this?
>
> Ram
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: `git checkout --orpan` leaves a dirty worktree
From: Ramkumar Ramachandra @ 2013-02-08 20:38 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Git List
In-Reply-To: <CANiSa6hD=zX5=evziqQpXHdjUDEU80t_Du7L+Hpa11ru=5XVNQ@mail.gmail.com>
Martin von Zweigbergk wrote:
> I'm curious what your use case is.
A couple of them off the top of my head: the gh-pages branch in
GitHub, restarting a project but keeping the old history around for
reference.
^ permalink raw reply
* Re: Improve 'git help' with basic user guide linkss
From: Junio C Hamano @ 2013-02-08 20:53 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List
In-Reply-To: <6D91D31A093D46869F43DD8D1012F0FB@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> I'm looking at extending the 'git help' to include some information
> for the basic user who isn't ready for the extensive man page
> documentation for the various commands.
We have pointers at the beginning of "git(1)" for that exact reason.
I am not saying the documents pointed at from there are perfect, but
shouldn't that approach work?
> My real question is on the right approach to generating a list of
> guides and including them into the git help options. I'm planning on
> extending the command-list.txt file to include 'guides' and then
> extending the generate-cmdlist.sh to generate a guides array in
> common-cmds.h.
Having a catalog of guide documents in help.o sounds like a good way
to go, but I doubt "command-list" is a good place to store it. It
is about git subcommands, "git help -a" uses it to show the list of
them, and the bash completion support uses the list via "git help -a".
The common-cmds.h does not have to be the only avenue to add your
catalog of guide documents to help.o. As a part of the build
procedure, you can list Documentation/guides/ and generate an array
definition into "guides.h", and add #include "guides.h" in help.c,
for example.
> I'm thinking of adding -g --guides and -c --commands options to
> complement the existing -a --all (becomes both commands and guides)
Complement is fine. Contaminating -a with guides is probably not.
> I was expecting to update the user-manual. to become
> gituser-manual.txt so that the existing 'git help user-manual' scheme
> would discover it. The Tutorial and the User manual obviously(?) being
> the first port of call for the confused user.
Again, we do have pointer to tutorial fairly prominently at the
beginning of "git(1)". Perhaps we want index.html that redirects to
git.html or something?
^ 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