The embarassing history of this tutorial is that I started it without
really understanding the index well, so I avoided mentioning it.
And we all got the idea that "index" was a word to avoid using around
newbies, but it was reluctantly mentioned that *something* had to be
said. The result is a little awkward: the discussion of the index never
actually uses that word, and isn't well-integrated into the surrounding
material.
Let's just go ahead and use the word "index" from the very start, and
try to demonstrate its use with a minimum of lecturing.
Also, remove discussion of using git-commit with explicit filenames.
We're already a bit slow here to get people to their first commit, and
I'm not convinced this is really so important.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Mention the user manual, especially as an alternative introduction for
user's mainly interested in read-only operations.
And fix a typo while we're there.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Most other documentation will frequently be read from an installation
of git so will naturally be associated with the installed version.
But these two documents in particular are often read from web pages
while users are still exploring git. It's important to mention
version 1.5.1 since these documents provide example commands that
won't work with previous versions of git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In asciidoc 7.1.2 and prior there is no obvious way to get:
'add'ing
to emphasize only the "add", instead it treats the first apostrophe as the
beginning of an emphasis, and the second apostrophe as a regular
apostrophe and makes the rest of the line an emphasis since there is no
closing apostrophe. In the newer asciidoc you can do it pretty easily
with __add__ing but I'm not sure it would be best to make that a prereq
for something as silly as this.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mention git-revert as an alternative to git-reset to revert changes.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I was reading the tutorial and noticed that we say this:
Also, don't use "git reset" on a publicly-visible branch that
other developers pull from, as git will be confused by history
that disappears in this way.
I do not think this is a good explanation. For example, if we
do this:
(1) I build a series and push it out.
---o---o---o---j
(2) Alice clones from me, and builds two commits on top of it.
---o---o---o---j---a---a
(3) I rewind one and build a few, and push them out.
---o---o---o...j
\
h---h---h---h
(4) Alice pulls from me again:
---o---o---o---j---a---a---*
\ /
h---h---h---h
Contrary to the description, git will happily have Alice merge
between the two branches, and never gets confused.
Maybe I did not want to have 'j' because it was an incomplete
solution to some problem, and Alice may have fixed it up with
her changes, while I abandoned that approach I started with 'j',
and worked on something completely unrelated in the four 'h'
commits. In such a case, the merge Alice would make would be
very sensible, and after she makes the merge if I pull from her,
the world will be perfect. I started something with 'j' and
dropped the ball, Alice picked it up and perfected it while I
went on to work on something else with 'h'. This would be a
perfect example of distributed parallel collaboration. There is
nothing confused about it.
The case the rewinding becomes problematic is if the work done
in 'h' tries to solve the same problem as 'j' tried to solve in
a different way. Then the merge forced on Alice would make her
pick between my previous attempt with her fixups (j+a) and my
second attempt (h). If 'a' commits were to fix up what 'j'
started, presumably Alice already studied and knows enough about
the problem so she should be able to make an informed decision
to pick between what 'j+a' and 'h' do.
A lot worse case is if Alice's work is not at all related to
what 'j' wanted to do (she did not mean to pick up from where I
left off -- she just wanted to work on something different).
Then she would not be familiar enough with what 'j' and 'h'
tried to achieve, and I'd be forcing her to pick between the
two. Of course if she can make the right decision, then again
that is a perfect example of distributed collaboration, but that
does not change the fact that I'd be forcing her to clean up my
mess.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* Promiscous pull shows the distributed nature of git better.
* Add a new step after that to teach "remote add".
* Highlight that with the shorthand defined you will get
remote tracking branches for free.
* Fix Alice's workflow.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
1) talk about "git merge" instead of "git pull ."
2) suggest "git repo-config" instead of directly editing config files
3) echo "URL: blah" > .git/remotes/foo is obsolete and should be
"git repo-config remote.foo.url blah"
4) support for partial URL prefix has been removed (see commit
ea560e6d64) so drop mention of it.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make "init" the equivalent of "init-db". This should make first GIT
impression a little more friendly.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Edit for conciseness.
Add a "Making changes" section header.
When possible, make sure that stuff in text boxes could be entered literally.
(Don't use "..." unless we want a user to type that.)
Move 'commit -a' example into a literal code section, clarify that it finds
modified files automatically.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- Teach how to delete a branch with "git branch -d name".
- Usually a commit has one parent; merge has more.
- Teach "git show" instead of "git cat-file -p".
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update tutorial's discussion of origin branch to reflect new defaults,
and include a brief mention of git-repo-config.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Back in the old days of Git when people messed around with their
GIT_DIR environment variable more often it was nice to know whether
or not git-init-db created a .git directory or used GIT_DIR.
As most users at that time were rather technical UNIXy folk the
message "defaulting to local storage area" made sense to some and
seemed reasonable.
But it doesn't really convey any meaning to the new Git user,
as they don't know what a 'local storage area is' nor do they
know enough about Git to care. It also really doesn't tell the
experienced Git user a whole lot about the command they just ran,
especially if they might be reinitializing an existing repository
(e.g. to update hooks).
So now we print out what we did ("Initialized empty" or
"Reinitialized existing"), what type of repository ("" or "shared"),
and what location the repository will be in ("$GIT_DIR").
Suggested in part by Andy Parkins in his Git 'niggles' list
(<200612132237.10051.andyparkins@gmail.com>).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This brings the power of the index up front using a proper mental model
without talking about the index at all. See for example how all the
technical discussion has been evacuated from the git-add man page.
Any content to be committed must be added together. Whether that
content comes from new files or modified files doesn't matter. You
just need to "add" it, either with git-add, or by providing
git-commit with -a (for already known files only of course).
No need for a separate command to distinguish new vs modified files
please. That would only screw the mental model everybody should have
when using GIT.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Introducing yourself to git early would be a good idea; otherwise
the user may not find the mistake until much later when "git log"
is learned.
Teaching "commit -a" without saying that it is a shortcut for
listing the paths to commit leaves the user puzzled. Teach the
form with explicit paths first.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Attempt to clarify somewhat the difference between pull and merge,
and give a little more details on the pull syntax.
I'm still not happy with this section: the explanation of the origin
branch isn't great, but maybe that should be left alone pending the
use-separate-remotes change; and we need to explain how to set up a
public repository and push to it.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rephrased a sentence in order to make more clear the concept of
pull . branch
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
All should be clear enough, except perhaps committish / commitish.
I just kept the more-used one within the current docs.
[jc: with rephrasing of check-ref-format description later discussed
on the list]
Signed-off-by: Francis Daly <francis@daoine.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'd rather avoid git cat-file so early on, but the
git-cat-file -p old-commit:/path/to/file
trick is too useful....
Also fix a nearby typo while we're at it.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Kind of silly, but the font I get by default in gitk makes it mostly
unusable for me, so this is the first thing I'd want to know about.
(But maybe there's a better suggestion than just Ctrl-='ing until
satisfied.)
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a sequel to tutorial.txt which discusses the index file and
the object database.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Expand the history-browsing section of the tutorial a bit, in part to
address Junio's suggestion that we mention "git grep" and Linus's
complaint that people are missing the flexibility of the commandline
interfaces for selecting commits.
This reads a little more like a collection of examples than a
"tutorial", but maybe that's what people need at this point.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio suggested changing references to git-whatchanged to git-log.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We forgot to update the primary link from git.html leading to
the tutorial, and also forgot to build and install the renamed
core-tutorial document.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The current Documentation/tutorial.txt concentrates on the lower-level
git interfaces. So it's useful to people developing alternative
porcelains, to advanced users, etc., but not so much to beginning users.
I think it makes sense for the main tutorial to address those
beginnning users, so with this patch I'm proposing that we move
Documentation/tutorial.txt to Documentation/core-tutorial.txt and
replace it by a new tutorial.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the character used to mark the commits that is on the
branch from '+' to '*' for the current branch, to make it stand out.
Also we show '-' for merge commits.
When you have a handful branches with relatively long diversion, it
is easier to see which one is the current branch this way.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The initial section of tutorial was too heavy on internal
workings for the first-time readers, so rewrite the introductory
section of git(7) to start with "not learning core git commands"
section and refer them to README to grasp the basic concepts,
then Everyday to give overview with task/role oriented examples
for minimum set of commands, and finally the tutorial.
Also add to existing note in the tutorial that many too
technical descriptions can be skipped by a casual reader.
I initially started to review the tutorial, with the objective
of ripping out the detailed technical information altogether,
but I found that the level of details in the initial couple of
sections that talk about refs and the object database in a
hands-on fashion was about rigth, and left all of them there. I
feel that reading about fsck-index and repack is too abstract
without being aware of these directories and files.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The branch policy script I outlined was improved and polished by
Carl and posted on the list twice since then. It is a shame not
to pick it up, so replace the original outline in
howto/update-hook-example.txt with the latest from Carl.
Also talk about setting up git-shell to allow git-push/git-fetch
only SSH access to a shared repository host in the tutorial.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Current default, merge-recursive, gives slightly different
message while working from merge-resolve which was used to
prepare the illustration in the tutorial.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The "copying over packs" step is to prevent the objects
available in upstream repository to get expanted in the
subsystem maintainer tree, and is still valid if the upstream
repository do not live on the same machine. But if they are on
the same machine using objects/info/alternates is cleaner.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch makes the documentation refer to the index
as index instead of cache, but some references still
remain. (e.g. git-update-index.txt)
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While discussing Jon's ASCII art on merge operations with him, I
realized that the tutorial stops talking about the plumbing
details halfway. So fill in the gory details, and update the
examples to use 'git-merge', not 'git-resolve'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The repository to pull from can be a local repository, and as a
special case the current directory can be specified to perform
merges across local branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
J. Bruce Fields