There should be a colon in this git-show example.
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I used "git pull ." instead of "git merge" here without any explanation.
Stick instead to "git merge" for now (the equivalent pull syntax is
still covered in a later chapter).
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The configuration file fragment here is inconsistent with the text
above. Thanks to Ramsay Jones for the correction.
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
* maint:
GIT 1.5.0.3
glossary: Add definitions for dangling and unreachable objects
user-manual: more detailed merge discussion
user-manual: how to replace commits older than most recent
user-manual: insert earlier of mention content-addressable architecture
user-manual: ensure generated manual references stylesheet
user-manual: reset to ORIG_HEAD not HEAD to undo merge
Documentation: mention module option to git-cvsimport
Add more details on conflict, including brief discussion of file stages.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"Modifying" an old commit by checking it out, --amend'ing it, then
rebasing on top of it, is a slightly cumbersome technique, but I've
found it useful frequently enough to make it seem worth documenting.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The content-addressable design is too important not to be worth at least
a brief mention a little earlier on.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As Linus pointed out recently on the mailing list,
git reset --hard HEAD^
doesn't undo a merge in the case where the merge did a fast-forward. So
the rcommendation here is a little dangerous.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
builtin-fmt-merge-msg: fix bugs in --file option
index-pack: Loop over pread until data loading is complete.
blameview: Fix the browse behavior in blameview
Fix minor typos/grammar in user-manual.txt
Correct ordering in git-cvsimport's option documentation
git-show: Reject native ref
Fix git-show man page formatting in the EXAMPLES section
I'd like complete gitweb setup instructions some day, but for now just
refer to the gitweb README.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Document Junio's show-branch trick for finding out which tags are
descendents of a given comit.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I still really want a section on interoperability with CVS, subversion,
etc., but I'm not getting around to it very fast, so just add this to
the TODO section for now. And a few other minor todo updates.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Add a brief discussion of reflogs. Also recovery of dangling commits
seems to fit in here, so move some of the discussion out of Linus's
email to here.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Direct editing of config files may be more natural for users than using
the git-config commandline; but we should still reference the
git-config man page when we describe such editing, so people know where
to go for details on the config file syntax and meanings of the
variables.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Looks like we're going to allow git-config as the preferred alias to
git-repo-config, so let's document that instead.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Initial import of fsck and dangling objects discussion, mostly lifted from
an email from Linus.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Keep git remote discussion in the first chapter, but postpone
lower-level git fetch usage (to fetch individual branches) till later.
Import a bunch of slightly modified text from the readme to give an
architectural overview at the end.
Add more discussion of history rewriting.
And a bunch of other miscellaneous changes....
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
It appears git-gc will no longer prune automatically, so we don't
need to tell people not to do other stuff while running it.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Since references may be packed, it's no longer as helpful to
introduce references as paths relative to .git.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Correct command line examples of repo-config, format-patch and am.
A full object name is 40-hexdigit; it may be 20-byte but
20-digit is misleading.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add discussion of git-rebase, patch series, history rewriting.
Mention "pull ." as a synonym for "merge".
Remind myself of another case I want to cover in the other-vcs's chapter.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Add a brief description of the organization to the preface, expand the
final notes/todo's section, in hopes maybe some others will want to
contribute.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The goals are:
- Readable from beginning to end in order without having read
any other git documentation beforehand.
- Helpful section names and cross-references, so it's not too
hard to skip around some if you need to.
- Organized to allow it to grow much larger (unlike the
tutorials)
It's more liesurely than tutorial.txt, but tries to stay focused on
practical how-to stuff. It adds a discussion of how to resolve merge
conflicts, and partial instructions on setting up and dealing with a
public repository.
I've lifted a little bit from "branching and merging" (e.g., some of the
discussion of history diagrams), and could probably steal more if that's
OK. (Similarly anyone should of course feel free to reuse bits of this
if any parts seem more useful than the whole.)
There's a lot of detail on managing branches and using git-fetch, just
because those are essential even to people needing read-only access
(e.g., kernel testers). I think those sections will be much shorter
once the new "git remote" command and the disconnected checkouts are
taken into account.
I do feel bad about adding yet another piece of documentation, but I we
need something that goes through all the basics in a logical order, and
I wasn't seeing how to grow the tutorials into that.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
