On Fri, 15 Jul 2005 20:56:12 -0700 Junio C Hamano wrote:
> Clarify that the hierarchy implied by the recommended workflow
> is only informal.
>
> Refer readers to nice illustration by Rundy Dunlap.
Randy(please)
>
> Separate out the step to "p
Clarify that the hierarchy implied by the recommended workflow
is only informal.
Refer readers to nice illustration by Rundy Dunlap.
Separate out the step to "push" to own public repository in the
workflow.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Documentation/tutorial.txt | 65
The cvsimport example in the cvs migration document was still
using the old syntax for target repository after new and
improved cvsimport-script was merged.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Documentation/cvs-migration.txt |2 +-
1 files changed, 1 insertions(+), 1 deleti
On Fri, 15 Jul 2005, H. Peter Anvin wrote:
>
> Since it can be run as a sequestered user, and we now have plenty of CPU
> horsepower on the download servers, it seems like it should be an
> entirely sane thing to do.
Goodie.
> Is this thing meant to be run from inetd, or is it a "listen and
Linus Torvalds wrote:
What I'd ask people to check is how comfortable for example kernel.org
would be to have one machine that runs this kind of service? I've tried
very hard to set it up so that it doesn't have any security issues: the
daemon can be run as "nobody", and it shouldn't ever eve
Linus Torvalds <[EMAIL PROTECTED]> writes:
> - I actually prefer code and documentation to be separated. ...
>first the actual change, then the docs updates.
Understood.
> - I'd much rather have a generic "address rewriting layer" than a "-b"
>flag.
>
>I don't mind the shorthand a
Hmm..
This patch actually brings up two different issues
- I actually prefer code and documentation to be separated. Finding the
actual changes to code in this patch is made much harder by the fact
that most of the changes are documentation updates. In many ways it
would have been n
Since pull and fetch are done often against the same remote
repository, keeping the URL to pull from along with the name of
the head in $GIT_DIR/branches/$name like Cogito does makes a lot
of sense. Adopt that and be compatible with Cogito for usability.
Signed-off-by: Junio C Hamano <[EMAIL PROT
Describe where you can pull from with a bit more detail.
Clarify description of pushing.
Add a section on packing repositories.
Add a section on recommended workflow for the project lead,
subsystem maintainers and individual developers.
Move "Tag" section around to make the flow of example simpl
I've updated my git quickstart guide at
http://linux.yyz.us/git-howto.html
It now points to DaveJ's daily snapshots for the initial bootstrap
tarball, is reorganized for better navigation, and other things.
Also, a bonus recipe: how to import Linus's pack files (it's easy).
This r
On Thu, Jul 14, 2005 at 05:29:09PM -0700, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Linus Torvalds wrote:
> > I'll look into making diff-cache be more efficient. I normally don't use
> > it myself, so I didn't bother (I use git-diff-files, which is way more
> > efficient, but doesn't show the di
Talk about publishing to a public repository. Also fixes a
couple of typos.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
*** To be consistent with the rest of the text, I said "I" push
*** to master.kernel.org, but obviously I am lying there ;-). I
*** do not know if your changes enters
12 matches
Mail list logo
