schacon / gitbook Goto Github PK

All the links to GIT user manual:
http://www.kernel.org/pub/software/scm/git/docs/...
are no longer working. Probably it is moved here:
http://schacon.github.com/git/...

There are (at least) two different cases where you might use git-svn. One is if you have a project currently stored in an svn repository, and you want to stop using that one, and switch to a git repository (e.g. You decided you hate sourceforge and love github). If you're trying to do this, the gitbook already does a pretty good job of telling you what you need to know.

The second is where you are going to continue hosting the project in an svn repository (for example, because it's for work, and your company is committed* to sticking with svn), but you want to use git locally. This second case is not covered well by the gitbook right now.

The following are some pages that I've found useful in this second case, so maybe, if we get the authors' permission, the information there could be brought into the gitbook.

• http://andy.delcambre.com/2008/03/04/git-svn-workflow.html
• http://flavio.castelli.name/howto_use_git_with_svn
• https://git.wiki.kernel.org/index.php/GitSvnCrashCourse (this last one I don't like so much because it tries to draw parallels between git commands and the "equivalent" svn commands, when in fact they are often not really equivalent)

* pun intended

Hi,

The pdf export version doesn't contain table of content, very useful once printed.

I am brand new to git, and was pleased to find that the documentation explains concepts instead of only giving examples. I am confident that I can become much less of a newbie quickly.

One thing confused me -- the diagram on http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository shows that "add" moves something to an "unmodified" state. But it is clear from the text (and the add detailed documentation) that "add", whether of a new file or a modified file, moves a file to the "staged" state. I think the diagram might be changed to reflect this.

Based on my reading so far, I gather that, if I create a file in the working directory, it would start out as "untracked"; if I then use the "add" command on that file, it becomes "staged".

I might make an attempt at a new diagram, but I'm not confident enough that I am correct about this. Can someone confirm?

I was going to use git-subtree and found no docs in git-scm.com.

Do we need update the docs? Or something wrong with content pulling of git manuals?

There is a typo in http://book.git-scm.com/3_distributed_workflows.html
Instead of:
"Note that exporting via http or git allow other maintainers to fetch your latest changes, but they do not allow write access."
better would be:
"Note that exporting via http or git allows other maintainers to fetch your latest changes, but it does not allow write access."

On the chapter about rebasing, the name origin is confusing because the default remote name is also origin.

When mentioning The Objects here http://book.git-scm.com/1_the_git_object_model.html, you might consider mentioning something about Branch, and how it's represented, since apparently it's not an object.

The screencast at the bottom of the submodules page does not appear to be loading.

Looks like the link has moved and the screencast is now at: http://blip.tv/play/AY2qe4zxOg

In the chapter "The PackFile", the first figure for version 2 index files introduces the variable 'size' as amount of entries. When describing the blocks for sha and crc values, the last entry in the block is referred to as sha1[size] and crc[size] respectively.
I believe it would be better to call it sha1[size-1] and crc[size-1] as the array indices start counting at 0.
The same issue can be found when the variable 'N' refers to the amount of objects at a pack offset larger than 2^32 -1 bits, where the last entry of 64 bit offsets is referred to as 64b_offset[N], which should be 64b_offset[N-1] as the array indices start at 0.

Hey Scott,

It'd be nice if you or someone took a weekend to clean up the Git Network. I was going to fork this repo, but I like to look at the network tab (https://github.com/schacon/gitbook/network) before doing that... and didn't know which repo to fork. It's pretty hairy.

It'd be nice if you could merge all the other branches into your own and then make a commit (if necessary to make some other tweaks to that person's contributions) after each merge. That way, all the other branches disappear (because your branch now has all their commits), and it becomes more clear that I should just fork your repo.

The general strategy I've adopted is just to merge all pull-requests ASAP (even if there's things I would change about them and don't have time to make an extra "enhancement" commit after the merge) so that everyone's working on the same code base. Not sure if that's good practice... but yeah...

Matt