Because we do not use --no-separate-remote anymore, there is no
reason to create that directory from the template.
t5510 test is updated to test both $GIT_DIR/remotes/ based
configuration and $GIT_DIR/config variable (credits to
Johannes).
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/test-clone: (35 commits)
Introduce GIT_TEMPLATE_DIR
Revert "fix testsuite: make sure they use templates freshly built from the source"
fix testsuite: make sure they use templates freshly built from the source
rerere: fix breakage of resolving.
Add config example with respect to branch
Add documentation for show-branch --topics
make git a bit less cryptic on fetch errors
make patch_delta() error cases a bit more verbose
racy-git: documentation updates.
show-ref: fix --exclude-existing
parse-remote::expand_refs_wildcard()
vim syntax: follow recent changes to commit template
show-ref: fix --verify --hash=length
show-ref: fix --quiet --verify
avoid accessing _all_ loose refs in git-show-ref --verify
git-fetch: Avoid reading packed refs over and over again
Teach show-branch how to show ref-log data.
markup fix in svnimport documentation.
Documentation: new option -P for git-svnimport
Fix mis-mark-up in git-merge-file.txt documentation
...
Instead of passing --template explicitely to init-db and clone, you can
just set the environment variable GIT_TEMPLATE_DIR.
Also make use of it in the tests, to make sure that the templates are
copied.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts commit 74d20040ca.
Version from Johannes to introduce GIT_TEMPLATE_DIR is simpler,
although I unconsciously stayed away from introducing yet another
environment variable.
The initial t/trash repository for testing was created properly
but over time we gained many tests that create secondary test
repositories with init-db or clone and they were not careful
enough.
This fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit e2b70087 botched the RCS merge to git-merge-file conversion.
There is no command called "git merge-file" (yes, we are using safer
variant of Perl's system(3)).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update config.txt with example with respect to branch
config variable. This give a better idea regarding
how branch names are expected.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a quick paragraph explaining the --topics option for show-branch.
The explanation is an abbreviated version of the commit message from
d320a5437f.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The remote server might not want to tell why it doesn't like us for
security reasons, but let's make the client report such error in a bit
less confusing way. The remote failure remains a mystery, but the local
message might be a bit less so.
[jc: with a gentle wording updates from Andy Parkins]
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is especially important to distinguish between a malloc() failure
from all the other cases. An out of memory condition is much less
worrisome than a compatibility/corruption problem.
Also make test-delta compilable again.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We've removed the workaround for runtime penalty that did not
exist in practice some time ago, but the technical paper that
proposed that change still said "we probably should do so".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not falsely document --filter-invalid which does not even exist.
Also make sure the line is long enough to have ^{} suffix before
checking for it.
Pointed out by Dscho.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Work around dash incompatibility by not using "${name%'^{}'}".
Noticed by Jeff King; dash seems to mistake the closing brace
inside the single quote as the terminating brace for parameter
expansion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch changes the syntax highlighting to correctly match the new
text of the commit message introduced by
82dca84871
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier optimization for --verify broke a lot of stuff
because it did not take interaction with other flags into
account.
This also fixes an unrelated argument parsing error; --hash=8
should mean the same as "--hash --abbrev=8".
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'jn/web' (early part):
gitweb: Add "next" link to commit view
gitweb: Add title attribute to ref marker with full ref name
gitweb: Do not show difftree for merges in "commit" view
gitweb: SHA-1 in commit log message links to "object" view
gitweb: Hyperlink target of symbolic link in "tree" view (if possible)
gitweb: Add generic git_object subroutine to display object of any type
gitweb: Show target of symbolic link in "tree" view
gitweb: Don't use Content-Encoding: header in git_snapshot
If you want to verify a ref, it is overkill to first read all loose refs
into a linked list, and then check if the desired ref is there.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
When checking which tags to fetch, the old code used to call
git-show-ref --verify for each remote tag. Since reading even
packed refs is not a cheap operation when there are a lot of
local refs, the code became quite slow.
This fixes it by teaching git-show-ref to filter out existing
refs using a new mode of operation of git-show-ref.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If GIT_COMMITTER_NAME is not available in receive-pack but reflogs
are enabled we would normally die out with an error message asking
the user to correct their environment settings.
Now that reflogs are enabled by default in (what we guessed to be)
non-bare Git repositories this may cause problems for some users
who don't have their full name in the gecos field and who don't
have access to the remote system to correct the problem.
So rather than die()'ing out in receive-pack when we try to log a
ref change and have no committer name we default to the username,
as obtained from the host's password database.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When replacing an existing file A with a directory A that has a
file A/B in it in the index, 'update-index --replace --add A/B'
did not properly remove the file to make room for the new
directory.
There was a trivial logic error, most likely a cut & paste one,
dating back to quite early days of git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When replacing an existing file A with a directory A that has a
file A/B in it in the index, 'git add' did not succeed because
it forgot to pass the allow-replace flag to add_cache_entry().
It might be safer to leave this as an error and require the user
to explicitly remove the existing A first before adding A/B
since it is an unusual case, but doing that automatically is
much easier to use.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When you remove a directory D that has a tracked file D/F out of the
way to create a file D and try to "git update-index --add D", it used
to say "cannot add" which was not very helpful. This issues an extra
error message to explain the situation before the final "fatal" message.
Since D/F conflicts are relatively rare event, extra verbosity would
not make things too noisy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When renaming a branch, the corresponding config section should
be renamed, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Given a config like this:
# A config
[very.interesting.section]
not
The command
$ git repo-config --rename-section very.interesting.section bla.1
will lead to this config:
# A config
[bla "1"]
not
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Finally.
The separate-remote layout is so much more organized than
traditional and easier to work with especially when you need to
deal with remote repositories with multiple branches and/or you
need to deal with more than one remote repositories, and using
traditional layout for new repositories simply does not make
much sense.
Internally we still have code for 1:1 mappings to create a bare
clone; that is a good thing and will not go away.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now we lost the "first refspec is the one that is merged by default"
rule, there is no reason for clone to list the remote primary branch
in the config file explicitly anymore.
We still need it for the traditional layout for other reasons,
though.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Everybody hated the pull behaviour of merging the first branch
listed on remotes/* file (or remote.*.fetch config) into the
current branch. This finally corrects that UI wart by
forbidding "git pull" without an explicit branch name on the
command line or branch.$current.merge for the current branch.
The matching change to git-clone was made to prepare the default
branch.*.merge entry for the primary branch some time ago.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This stops enumerating the set of branches found on the remote
side when a clone was made in the configuration file. Instead,
a single entry that maps each remote branch to the local
tracking branch for the remote under the same name is created.
Doing it this way not only shortens the configuration file, but
automatically adjusts to a new branch added on the remote side
after the clone is made.
Unfortunately this cannot be done for the traditional layout,
where we always need to special case the 'master' to 'origin'
mapping within the local branch namespace. But that is Ok; it
will be going away before v1.5.0.
We could also lose the "primary branch" mapping at the
beginning, but that has to wait until we implement the "forbid
'git pull' when we do not have branch.$current.merge for the
current branch" policy we earlier discussed. That should also
be in v1.5.0
Signed-off-by: Junio C Hamano <junkio@cox.net>
This hacks the input to fmt-merge-msg to make the message for
merging early part of a branch a little easier to read.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a kind of "next" view in the bottom part of navigation bar for
"commit" view, similar to what was added for "commitdiff" view in
commit 151602df00
'gitweb: Add "next" link to commitdiff view'
For "commit" view for single parent commit:
(parent: _commit_)
For "commit" view for merge (multi-parent) commit:
(merge: _commit_ _commit_ ...)
For "commit" view for root (parentless) commit
(initial)
where _link_ denotes hyperlink. SHA1 of commit is shortened
to 7 characters on display.
While at it, remove leftovers from commit cae1862a by Petr Baudis:
'gitweb: More per-view navigation bar links'
namely the "blame" link if there exist $file_name and commit has a
parent; it was added in git_commit probably by mistake. The rest
of what mentioned commit added for git_commit was removed in
commit 6e0e92fda8 by Luben Tuikov:
'gitweb: Do not print "log" and "shortlog" redundantly in commit view'
(which should have probably removed also this "blame" link removed now).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add title attribute, which will be shown as popup on mouseover in
graphical web browsers, with full name of ref, including part (type)
removed from the name of ref itself. This is useful to see that this
strange ref is StGIT ref, or it is remote branch, or it is lightweigh
tag (with branch-like name).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not show difftree against first parent for merges (commits with
more than one parent) in "commit" view, because it usually is
misleading. git-show and git-whatchanged doesn't show diff for merges
either.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most of this is derived from the documentation of RCS merge.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When --use-separate-remote is used on git-clone, the remote
heads are saved under $GIT_DIR/refs/remotes/origin/, not
"$GIT_DIR/remotes/origin/"
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the current branch was "master" then git-status wouldn't say
# On branch XXXX
In its output. This patch makes it so that this message is always
output; regardless of branch name.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that 'git add' is considered a first-class UI for 'update-index'
and that the 'git add' documentation states "Even modified files
must be added to the set of changes about to be committed" we should
make the output of 'git status' align with that documentation and
common usage.
So now we see a status output such as:
# Added but not yet committed:
# (will commit)
#
# new file: x
#
# Changed but not added:
# (use "git add file1 file2" to include for commit)
#
# modified: x
#
# Untracked files:
# (use "git add" on files to include for commit)
#
# y
which just reads better in the context of using 'git add' to
manipulate a commit (and not a checkin, whatever the heck that is).
We also now support 'color.status.added' as an alias for the existing
'color.status.updated', as this alias more closely aligns with the
current output and documentation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a user modifies files and runs 'git commit' (without the very
useful -a option) and they have not yet updated the index they
are probably coming from another SCM-like tool which would perform
the same as 'git commit -a' in this case. Showing the user their
current status and a final line of "nothing to commit" is not very
reassuring, as the user might believe that Git did not recognize
their files were modified.
Instead we can suggest as part of the 'nothing to commit' message
that the user invoke 'git add' to add files to their next commit.
Suggested by Andy Parkins' 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>
Two of the cases has "[--] [<path>...]" and two had "-- [<path>...]".
Not terribly consistent and potentially confusing. Also add "[--]" to
the synopsis so that it's obvious you can use it from the very
beginning.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
For multivars, the "git-repo-config name value ^$" is useful but
nonintuitive and troublesome to do repeatedly (since the value is not
at the end of the command line). This commit simply adds an --add
option that adds a new value to a multivar. Particularly useful for
tracking a new branch on a remote:
git-repo-config --add remote.origin.fetch +next:origin/next
Includes documentation and test.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that 'git show' accepts ref:path as an argument to specify a
tree or blob we should use the same completion logic as we support
for cat-file's object identifier.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
New and experienced Git users alike are finding out too late that
they forgot to enable reflogs in the current repository, and cannot
use the information stored within it to recover from an incorrectly
entered command such as `git reset --hard HEAD^^^` when they really
meant HEAD^^ (aka HEAD~2).
So enable reflogs by default in all future versions of Git, unless
the user specifically disables it with:
[core]
logAllRefUpdates = false
in their .git/config or ~/.gitconfig.
We only enable reflogs in repositories that have a working directory
associated with them, as shared/bare repositories do not have
an easy means to prune away old log entries, or may fail logging
entirely if the user's gecos information is not valid during a push.
This heuristic was suggested on the mailing list by Junio.
Documentation was also updated to indicate the new default behavior.
We probably should start to teach usuing the reflog to recover
from mistakes in some of the tutorial material, as new users are
likely to make a few along the way and will feel better knowing
they can recover from them quickly and easily, without fsck-objects'
lost+found features.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano