We earlier removed a link to list of contributors that pointed to a
defunct page; let's use a working one from Ohloh.net to replace it
instead.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sl/maint-git-svn-docs:
git-svn: Note about tags.
git-svn: Expand documentation for --follow-parent
git-svn: Recommend use of structure options.
git-svn: Document branches with at-sign(@).
Document that 'git svn' will import SVN tags as branches.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Describe what the option --follow-parent does, and what happens if it is
set or unset.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document that when using git svn, one should usually either use the
directory structure options to import branches as branches, or only
import one subdirectory. The default behaviour of cloning all branches
and tags as subdirectories in the working copy is usually not what the
user wants.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git svn sometimes creates branches with an at-sign in the name
(branchname@revision). These branches confuse many users and it is a FAQ
why they are created. Document when git svn creates them.
Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the distant past, the order things were documented was
'Invocation', 'Commands', 'Capabilities', ...
Then it was decided that before giving a list of Commands, there
should be an overall description of the 'Input format', which was
a wise decision. However, this description was put as the very
first thing, with the rationale that any implementor would want
to know that first.
However, it seems an implementor would actually first need to
know how the remote helper will be invoked, so moving
'Invocation' to the front again seems logical. Moreover, we now
don't switch from discussing the input format to the invocation
style and then back to input related stuff.
Signed-off-by: Max Horn <max@quendi.de>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
19299a8 (Documentation: Move diff.<driver>.* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt. Fix this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This file is rather outdated and IMHO shouldn't be there in the first place.
(If there are translations of the Git documentation they are better be kept
separate from the original documentation.)
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use $TMPDIR when creating the /dev/null placeholder for p4merge.
This prevents users from finding a seemingly random untracked file
in their worktree.
This is different than what mergetool does with $LOCAL and
$REMOTE because those files exist to aid users when resolving
merges. p4merge's /dev/null placeholder is not helpful in that
situation so it is sensible to keep it out of the worktree.
Reported-by: Jeremy Morton <admin@game-point.net>
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous commit documented two known breakages revolving around
a case where one side flips a tree into a blob (or vice versa),
where the original code simply gets confused and feeds a mixture of
trees and blobs into either the recursive merge-tree (and recursing
into the blob will fail) or three-way merge (and merging tree contents
together with blobs will fail).
Fix it by feeding trees (and only trees) into the recursive
merge-tree machinery and blobs (and only blobs) into the three-way
content level merge machinery separately; when this happens, the
entire merge has to be marked as conflicting at the structure level.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rename the "branch1" parameter given to resolve() to "ours", to
clarify what is going on. Also, annotate the unresolved_directory()
function with some comments to show what decisions are made in each
step, and highlight two bugs that need to be fixed.
Add two tests to t4300 to illustrate these bugs.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The optional third parameter when __git_ps1 is used in
PROMPT_COMMAND mode as format string for printf to further
customize the way the git status string is embedded in the
user's PS1 prompt.
Signed-off-by: Simon Oosthoek <s.oosthoek@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some platforms (e.g. NetBSD 6.0) seem to configure their CVS to
allow "cvs init" in an existing directory only to members of
"cvsadmin".
Instead of preparing an empty directory and then running "cvs init"
on it, let's run "cvs init" and let it create the necessary
directory.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cherry-picking into an unborn branch should work, so make it work,
with or without --ff.
Cherry-picking anything other than a commit that only adds files, will
naturally result in conflicts. Similarly, revert also works, but will
result in conflicts unless the specified revision only deletes files.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/mailmap-cleanup:
contrib: update stats/mailmap script
.mailmap: normalize emails for Linus Torvalds
.mailmap: normalize emails for Jeff King
.mailmap: fix broken entry for Martin Langhoff
.mailmap: match up some obvious names/emails
* ta/doc-cleanup:
Documentation: build html for all files in technical and howto
Documentation/howto: convert plain text files to asciidoc
Documentation/technical: convert plain text files to asciidoc
Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
Split over-long synopsis in git-fetch-pack.txt into several lines
Howto documents in howto-index.txt were listed in a rather
random order. So better sort them.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A function for checking that two given parameters refer to the same
revision was defined in several places, so move the definition to
test-lib-functions.sh instead.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff <blob> <blob>" was not documented and was only hinted as
an extension to "git diff <commit> <commit> -- <pathspec>", but
comparison between two blobs are more special than that. It does
not take any pathspec to begin with.
* jc/doc-diff-blobs:
Documentation: Describe "git diff <blob> <blob>" separately
Document the magic "git checkout <no-such-branch>" hack to create
local branch out of a remote tracking branch that hasn't been
documented so far.
* cr/doc-checkout-branch:
Documentation/git-checkout.txt: document 70c9ac2 behavior
Documentation/git-checkout.txt: clarify usage
Avoids invalid sample e-mail addresses from becoming mailto links
in the formatted output.
* jk/avoid-mailto-invalid-in-doc:
Documentation: don't link to example mail addresses
It might be a better idea to move the text the bottom one adds to
the extended description from the quick checklist part.
* as/doc-for-devs:
Documentation: move support for old compilers to CodingGuidelines
SubmittingPatches: add convention of prefixing commit messages
Clarify that the project as a whole is GPLv2 only, with some parts
borrowed under different licenses that are compatible with GPLv2.
* sl/readme-gplv2:
README: it does not matter who the current maintainer is
README: Git is released under the GPLv2, not just "the GPL"
"git fetch --tags" was explained as if it were "git fetch
--no-no-tags", which is not the case, causing confusion.
* jc/fetch-tags-doc:
fetch --tags: clarify documentation
* sl/git-svn-docs:
git-svn: Note about tags.
git-svn: Expand documentation for --follow-parent
git-svn: Recommend use of structure options.
git-svn: Document branches with at-sign(@).
Update various entries in our .mailmap file.
* jk/mailmap-cleanup:
contrib: update stats/mailmap script
.mailmap: normalize emails for Linus Torvalds
.mailmap: normalize emails for Jeff King
.mailmap: fix broken entry for Martin Langhoff
.mailmap: match up some obvious names/emails
The contents of this document does not describe any particular API, but
is more about the way to add a new command, which belongs to the "How To"
section of the documentation suite.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If sslCertPasswordProtected is set to true do not ask for username to decrypt rsa key. This question is pointless, the key is only protected by a password. Internaly the username is simply set to "".
Signed-off-by: Rene Bredlau <git@unrelated.de>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we delete a ref that is packed, we rewrite the whole
packed-refs file and simply omit the ref that no longer
exists. However, we base the rewrite on whatever happens to
be in our refs cache, not what is necessarily on disk. That
opens us up to a race condition if another process is
simultaneously packing the refs, as we will overwrite their
newly-made pack-refs file with our potentially stale data,
losing commits.
You can demonstrate the race like this:
# setup some repositories
git init --bare parent &&
(cd parent && git config core.logallrefupdates true) &&
git clone parent child &&
(cd child && git commit --allow-empty -m base)
# in one terminal, repack the refs repeatedly
cd parent &&
while true; do
git pack-refs --all
done
# in another terminal, simultaneously push updates to
# master, and create and delete an unrelated ref
cd child &&
while true; do
git push origin HEAD:newbranch &&
git commit --allow-empty -m foo
us=`git rev-parse master` &&
git push origin master &&
git push origin :newbranch &&
them=`git --git-dir=../parent rev-parse master` &&
if test "$them" != "$us"; then
echo >&2 "$them" != "$us"
exit 1
fi
done
In many cases the two processes will conflict over locking
the packed-refs file, and the deletion of newbranch will
simply fail. But eventually you will hit the race, which
happens like this:
1. We push a new commit to master. It is already packed
(from the looping pack-refs call). We write the new
value (let us call it B) to $GIT_DIR/refs/heads/master,
but the old value (call it A) remains in the
packed-refs file.
2. We push the deletion of newbranch, spawning a
receive-pack process. Receive-pack advertises all refs
to the client, causing it to iterate over each ref; it
caches the packed refs in memory, which points at the
stale value A.
3. Meanwhile, a separate pack-refs process is running. It
runs to completion, updating the packed-refs file to
point master at B, and deleting $GIT_DIR/refs/heads/master
which also pointed at B.
4. Back in the receive-pack process, we get the
instruction to delete :newbranch. We take a lock on
packed-refs (which works, as the other pack-refs
process has already finished). We then rewrite the
contents using the cached refs, which contain the stale
value A.
The resulting packed-refs file points master once again at
A. The loose ref which would override it to point at B was
deleted (rightfully) in step 3. As a result, master now
points at A. The only trace that B ever existed in the
parent is in the reflog: the final entry will show master
moving from A to B, even though the ref still points at A
(so you can detect this race after the fact, because the
next reflog entry will move from A to C).
We can fix this by invalidating the packed-refs cache after
we have taken the lock. This means that we will re-read the
packed-refs file, and since we have the lock, we will be
sure that what we read will be atomically up-to-date when we
write (it may be out of date with respect to loose refs, but
that is OK, as loose refs take precedence).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
