Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)

From: Philip Oakley <philipoakley@iee.org>
Date: Mar 16, 2014, 07:40 UTC
Message-ID: <EA1EF5746EA7414CAE1320AA61100178@PhilipOakley>
In-Reply-To: <xmqqlhwcfn4a.fsf@gitster.dls.corp.google.com>

From: "Junio C Hamano" <gitster@pobox.com>

Show 11 quoted lines

> --------------------------------------------------
> [Stalled]
>  ...
> * po/everyday-doc (2014-01-27) 1 commit
> - Make 'git help everyday' work
>
> This may make the said command to emit something, but the source is
> not meant to be formatted into a manual pages to begin with, and
> also its contents are a bit stale.  It may be a good first step in
> the right direction, but needs more work to at least get the
> mark-up right before public consumption.

I'm not sure what elements you feel need adjustment. At the moment the markup formats quite reasonably to my eyes, both as an HTML page and as a man page.

That said, the (lack of) introduction could do with a paragraph to introduce the "guide". I have something in draft..

I had a thought that it may be worth a slight rearrangement to add a section covering the setting up of one's remotes, depending whether it was forked, corporate, or independent, but the lack of resolution on the next {publish/push} topic makes such a re-write awkward at this stage. (Ram cc'd)

Some guidance would be a help.

Show 16 quoted lines

>
> Will hold.
>
>
> * jk/branch-at-publish-rebased (2014-01-17) 5 commits
> - t1507 (rev-parse-upstream): fix typo in test title
> - implement @{publish} shorthand
> - branch_get: provide per-branch pushremote pointers
> - branch_get: return early on error
> - sha1_name: refactor upstream_mark
>
> Give an easier access to the tracking branches from "other" side in
> a triangular workflow by introducing B@{publish} that works in a
> similar way to how B@{upstream} does.
>
> Meant to be used as a basis for whatever Ram wants to build on.

To me 'publish' didn't fel right, though the later 'push' suggestion felt honest. (http://git.661346.n2.nabble.com/RFC-PATCH-format-patch-introduce-branch-forkedFrom-tp7601682p7603725.html)

>
> Will hold.
>

Show 8 quoted lines

> --------------------------------------------------
> [Cooking]
>
>
> * po/git-help-user-manual (2014-02-18) 1 commit
> - Provide a 'git help user-manual' route to the docbook
>
> I am not sure if this is even needed.

My rhetorical question would be "what should 'git help user-manual' do?" for the beginner, and do we have a sort of policy on ensuring that the majority of user documentation should be available (or at least referenced) via the 'git help' mechanism?

It feels odd to make the user-manual the one manual that can't be served via the git man pages.

>
> Will discard.
>

-- Philip