Here's a documentation stub. Please fix and finish it and place in some manual.
==Using git in read-only mode==
Let's say you just want to examine things. There is a fine line
between commands and options that just examine things vs. those that
change things. One might worry that they can't remember that fine line.
Therefore the safest way to ensure you are using git in 'read-only mode' is to
* su nobody, or
* chmod -R u-w . (and remember to chmod -R u+w when you are finished), or
* ???
On Thu, Dec 04, 2008 at 06:44:24AM +0800, jidanni@jidanni.org wrote:
Here's a documentation stub. Please fix and finish it and place in some manual.
Please read and follow Documentation/SubmittingPatches if you want this
to be included.
Thanks.
jidanni@jidanni.org venit, vidit, dixit 03.12.2008 23:44:
Here's a documentation stub. Please fix and finish it and place in some manual.
[Warning: irony ahead] Yes master, at your service!
[I'm aware he tone in the quote above may be due to translation issues.]
==Using git in read-only mode==
Let's say you just want to examine things. There is a fine line
between commands and options that just examine things vs. those that
change things. One might worry that they can't remember that fine line.
Therefore the safest way to ensure you are using git in 'read-only mode' is to
* su nobody, or
* chmod -R u-w . (and remember to chmod -R u+w when you are finished), or
This does change things (time stamps).
I'd say the two above are no git-specific suggestions at all, and "cp -a
.git .git-orig" is the best safety-net for the cautious (assuming a
clean working tree) when doing heavy work but overkill for inspection.
* ???
* clone and inspect the clone instead
* use obvious read-only commands (status, log, diff, show, ls-files,
tag&branch without argument) and avoid obvious write commands (commit,
checkout, apply, ...)
Without specifying "things" any further (repo, objects, index, working
tree) I don't really understand what the problem is.
Michael