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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: "Junio C Hamano" <gitster@xxxxxxxxx>
--------------------------------------------------
[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.


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.


--------------------------------------------------
[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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]