Jonathan> Confusingly enough, this stuff is documented in git-pull(1)
Jonathan> but not git-fetch(1)!
> Default values for <repository> and <branch> are read from the
> "remote" and "merge" configuration for the current branch as set by
> git-branch --track.
I have never executed git branch --track. In general, I prefer to edit
the .git/config file for settings of this nature. I think part of the
problem here is that the documentation refuses to acknowledge the
existence of such people.
The file currently looks like this:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = refs/heads/*:refs/remotes/origin/*
url = http://www.red-bean.com/decklin/mnemosyne.git
[remote "myserver"]
url = ssh://myserver.homeip.net/var/local/git/mnemosyne.git
There is a remote tracking branch remotes/origin/master and 2 normal
branches, master and upstream. I am specifically interested in the
behavior by fetch and not pull because after fetching the remote master
branch I want to separately merge it into the upstream local branch
before deciding to put in in my master.
Jonathan> Do you think this wording should be included in the
Jonathan> git-fetch(1) page, too? Where should it go? Could it use any
Jonathan> tweaks for clarity?
Jonathan> Hm, do you mean that the structure of the manpage is
Jonathan> confusing? Suggestions for improving that would be very
Jonathan> welcome, too.
As should be clear from what I say above, I don't think this simple
change would be sufficient. I think at least 2 structural improvements
are needed:
1. Explain the relationship between the configuration files and commands
like git branch --track.
2. Document the default for each option/argument _in the manpage
paragraph for that option_. If the default is to use some setting from
the configuration file, also say what happens if that setting is not
present. This will lead to some duplication for sure, because the
defaults subtly depend on other options provided (one of my main
complaints with git). But that is better than not having the
information at all.
I am currently sick. When back in form I may try to write something up,
but of course that requires I know what it is that git does, which I
still don't.
Jonathan> In my humble opinion, the Git Community Book is a confusing
Jonathan> abomination that should never have been written. Good
Jonathan> diagrams, though. Its source material (the Git User Manual)
Jonathan> and successor (the Pro Git book) are better in pretty much
Jonathan> every way.
Ok, thanks for pointing me to these.
--
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD
http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png
Rule 420: All persons more than eight miles high to leave the court.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
