Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)

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

 



Scott Chacon <schacon@xxxxxxxxx> writes:

> It appears that you're no longer pushing the 'html' branch to the
> GitHub repo,...

It is not even "no longer".

Unlike the other public mirrors that are designed to mimic what my
repository at k.org looks like, https://github.com/gitster/git is
primarily meant to mirror my internal development repository, with the
full set of topic branches.

As I do not have 'html' as a branch in my development repository, the
result "git push --mirror" there never had refs/heads/html, either.

My workflow used to be:

 - push 4 integration branches from the development repository to k.org,
   and have its update hook update html and man branches there;
 - optionally push todo from a different private repository to k.org;
 - fetch back refs/heads/* from k.org to refs/remotes/ko/*;
 - verify that my refs/heads/* and refs/remotes/ko/* match for 4 integration
   branches;
 - push stuff under refs/remotes/ko/* to public mirrors (sourceforge does
   not get next and pu);
 - push --mirror to https://github.com/gitster/git.

Now the interim workflow, until k.org comes back, is tentatively:

 - in a separate local "formatting" repository, pull 'master' from my
   development repository, build html and man there, and push them back
   to refs/docs/{html,man} to my development repository;
 - push refs/heads/{master,maint,next,pu} and refs/docs/{html,man} to
   public mirrors (sourceforge does not get next and pu);
 - push --mirror to https://github.com/gitster/git.

I am hoping that I do not have to keep doing this and refs/docs/ can
eventually go away. I specifically do _not_ want the administrative
non-source branches html/man/todo to be my local branches.

> Since the k.org hosting of the man pages is down, I was working on
> putting them on git-scm.com, where you could select which version of
> the docs you want to see and could search through them and whatnot.

What is the expected the end-user page-flow?

Would people come to https://github.com/gitster/git first, find "doc" link
there, and start browsing the html version of the documentation?

Or do people come to http://github.com/, find a link "documentation for
the scm this site supports", your machinery kicks in and serves the blobs
from https://github.com/gitster/git under the hood, without letting users
know where the pages they are looking at really come from?

What I am getting at is that if these users do not need to know about my
repository, then you do not _need_ to see html branch in my repository,
either. You only need to find it _somewhere_, and that somewhere does not
have to be https://github.com/gitster/git repository.

You may think you could use refs/docs/html but I would rather want to
avoid letting you guys rely on refs/docs/ I started using just a few days
ago as an interim measure. I may later change my mind and get rid of that
from my development repository, but that would break your machinery to
show preformatted documentation pages.

I could add a _separate_ repository at github, and treat it just like
other public mirrors like repo.or.cz, so that you can find html branch
there. That would be consistent with my wish to use "push --mirror" to at
least one place (https://github.com/gitster/git), and would be easier to
manage for me.

Would that work?
--
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]