Add some documentation.
Text taken from the the commit messages and the command sources.
Signed-off-by: <gitzilla@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added a new test case for the scanning forwards and backwards for the
correct location to apply a patch fragment.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added a test case for patches with multiple fragments.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Stop processing and return NULL if we encounter a '\n' character
before we have two matching names in the git header.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When there is non-empty $GIT_DIR/info/exclude file, use it along
with .gitignore per-directory exclude pattern files (which was
a convention agreed on the list while ago and is compatible with
Cogito) to generate a list of ignored files as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from d330948a5ff0df55c2f12627c0583b4e16f1ea4d commit)
When not working on "master" branch, remind the user at the beginning
of the status message, not at the end.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Inspired by a report by Kalle Valo, this changes git-sh-setup-script and
the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a
symlink, since a number of core git features depend on that these days.
We used to allow a regular file there, but git-fsck-cache has been
complaining about that for a while, and anything that uses branches
depends on the HEAD file being a symlink, so let's just encode that as a
fundamental requirement.
Before, a non-symlink HEAD file would appear to work, but have subtle bugs
like not having the HEAD show up as a valid reference (because it wasn't
under "refs"). Now, we will complain loudly, and the user can fix it up
trivially instead of getting strange behaviour.
This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY"
being directories, since the other tests will implicitly test for that
anyway (ie the tests for HEAD, refs and 00 would fail).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the "git pull" command updates the branch head you are
currently on, before doing anything else, first update your
index file and the working tree contents to that of the new
branch head. Otherwise, the later resolving steps would think
your index file is attempting to revert the change between the
original head commit and the updated head commit.
It uses two-tree fast-forward form of "read-tree -m -u" to
prevent losing whatever local changes you may have in the
working tree to do this update. I think this would at least
make things safer (a lot safer), and prevent mistakes.
Also "git fetch" command is forbidden from fetching and fast
forwarding the current branch head unless --update-head-ok flag
is given. "git pull" passes the flag when it internally calls
"git fetch".
Signed-off-by: Junio C Hamano <junkio@cox.net>
You can define WITH_SEND_EMAIL to include the send-email command as
part of the installation. Since Debian, unlike RPM/Fedora, has the
two necessary Perl modules available as part of the mainline
distribution, there is no reason for us to shy away from shipping
send-email.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Gitzilla updated bunch of undocumented command pages, so move the
entries in the main documentation index around to put them in proper
category. Ordering within category will be fixed later.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Generate docs for gitk. Install them in the right deb package.
Signed-off-by: Tommi Virtanen <tv@debian.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make the git deb conflict with cogito versions prior to 0.13, as those
versions used to contain git. Suggest cogito.
Signed-off-by: Tommi Virtanen <tv@debian.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix syntax error in debian Build-Depends-Indep, dpkg-checkbuilddeps used
to give false ok results.
Signed-off-by: Tommi Virtanen <tv@debian.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Describe a DAG and octopus, and change wording of tree object.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Various updates and cleanups for my howto on using branches in GIT
as a Linux subsystem maintainer. Three categories of changes:
1) Updates for new features in GIT 0.99.5
2) Changes to use "git fetch" rather than "git pull" to update
local linus branch.
3) Cleanups suggested by Len Brown
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The "verify_pathspec()" function doesn't test for ending NUL character in
the pathspec, causing some really funky and unexpected behaviour. It just
happened to work in the cases I had tested.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes the git-read-tree in git-checkout-script fails for me.
Make sure that the failed status is passed up to caller.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this we could say:
Pull: master:ko-master +pu:ko-pu
to mean "fast forward ko-master with master, overwrite ko-pu with pu",
and the latter one does not require the remote "pu" to be descendant
of local "ko-pu".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Just like "git push" can forcibly update a ref to a value that is not
a fast-forward, teach "git fetch" to do so as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now multi-head fetch is complete, let's migrate the
default configuration for new repositories created with
the "git clone" command.
The original $GIT_DIR/branches is not deprecated yet, but create
remotes directory by default from the templates as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Amos Waterland sent in a patch for the pre-multi-head aware
version of "git pull" to do this, but the code changed quite a
bit since then. If there is no argument given to pull from, and
if "origin" makes sense, default to fetch/pull from "origin"
instead of barfing.
[jc: besides, the patch by Amos broke the non-default case where
explicit refspecs are specified, and did not make sure we know
what "origin" means before defaulting to it.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
This script uses the list of heads and their origin multi-head "git
fetch" left in the $GIT_DIR/FETCH_HEAD file, and makes an octopus
merge on top of the current HEAD using them.
The implementation tries to be strict for the sake of safety. It
insists that your working tree is clean (no local changes) and matches
the HEAD, and when any of the merged heads does not automerge, the
whole process is aborted and tries to rewind your working tree is to
the original state.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update git-pull to match updated git-fetch and allow pull to
fetch from multiple remote references. There is no support for
resolving more than two heads, which will be done with "git
octopus".
Update "git ls-remote" to use git-parse-remote-script.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Traditionally, fetch takes these forms:
$ git fetch <remote>
$ git fetch <remote> <head>
$ git fetch <remote> tag <tag>
This patch updates it to take
$ git fetch <remote> <refspec>...
where:
- A <refspec> of form "<src>:<dst>" is to fetch the objects
needed for the remote ref that matches <src>, and if <dst>
is not empty, store it as a local <dst>.
- "tag" followed by <next> is just an old way of saying
"refs/tags/<next>:refs/tags/<next>"; this mimics the
current behaviour of the third form above and means "fetch
that tag and store it under the same name".
- A single token <refspec> without colon is a shorthand for
"<refspec>:" That is, "fetch that ref but do not store
anywhere".
- when there is no <refspec> specified
- if <remote> is the name of a file under $GIT_DIR/remotes/
(i.e. a new-style shorthand), then it is the same as giving
the <refspec>s listed on Pull: line in that file.
- if <remote> is the name of a file under $GIT_DIR/branches/
(i.e. an old-style shorthand, without trailing path), then it
is the same as giving a single <refspec>
"<remote-name>:refs/heads/<remote>" on the command line, where
<remote-name> is the remote branch name (defaults to HEAD, but
can be overridden by .git/branches/<remote> file having the
URL fragment notation). That is, "fetch that branch head and
store it in refs/heads/<remote>".
- otherwise, it is the same as giving a single <refspec>
that is "HEAD:".
The SHA1 object names of fetched refs are stored in FETCH_HEAD,
one name per line, with a comment to describe where it came from.
This is later used by "git resolve" and "git octopus".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recent changes in git have broken cg-log. git-rev-list no longer
prints "commit" in front of commit hashes. It turn out a local
"prefix" variable in main() shadows a file-scoped "prefix" variable.
The patch removed the local "prefix" variable since its value is never
used (in the intended way, that is). The call to
setup_git_directory() is kept since it has useful side effects.
The file-scoped "prefix" variable is renamed to "commit_prefix" just
in case someone reintroduces "prefix" to hold the return value of
setup_git_directory().
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier rounds broke 'whatchanged -p'. In attempting to fix this,
make two axis of output selection in rev-parse orthogonal:
--revs-only tells it not to output things that are not revisions nor
flags that rev-list would take.
--no-revs tells it not to output things that are revisions or
flags that rev-list would take.
--flags tells it not to output parameters that do not start with
a '-'.
--no-flags tells it not to output parameters that starts with a '-'.
So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386',
while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'.
Also the meaning of --verify has been made stronger. It now rejects
anything but a single valid rev argument. Earlier it passed some flags
through without complaining.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Pulling from a packed repository over dumb transport without the
server info file fails, so run update-server-info automatically
after a repack by default. This can be disabled with the '-n'
flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
