Disable USE_SYMLINK_HEAD by default. Recommend using it only for
compatibility with older software.
Treat USE_SYMLINK_HEAD like other optional defines - check whether it's
defined, not its value.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If git-fetch-pack was called with out any refspec, it would ask the server
for funny refs. That cannot work, since the funny refs are not marked
as OUR_REF by upload-pack, which just exits with an error.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts c5ced64578a82b9d172aceb2f67c6fb9e639f6d9 commit.
It turns out that doing this check every time we map the idx file
is quite expensive. A corrupt idx file is caught by git-fsck-objects,
so this check is not strictly necessary.
In one unscientific test, 0.99.9m spent 10 seconds usertime for
the same task 1.1.3 takes 37 seconds usertime. Reverting this gives
us the performance of 0.99.9 back.
By popular demand. If you build and install such binary RPMs,
the version numbering will lose monotonicity, so you may have to
later override downgrade warnings from your packaging manager,
but as long as you are aware of that and know how to deal with it,
there is no reason for us to forbid it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previously 'git-push --tags dst', used information from
remotes/dst to determine which refs to push; this patch corrects
it, and also documents the --tags option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When describing more than one, we need to clear the commit marks
before handling the next one, but most of the time we are
running it for only one commit, and in such a case this clearing
phase is totally unnecessary.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes a minor bug, which caused the author email to be
doubly enclosed in a <> pair (the code gave enclosing <> to
GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL environment variable).
The read_author_info() subroutine is taught to also understand
the user list in CVSROOT/users format. This is primarily done
to ease migration for CVS users, who can use the -A option
to read from existing CVSROOT/users file. write_author_info()
always writes in the git-cvsimport's native format ('='
delimited and value without quotes).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds the option to specify an author name/email conversion
file in the format
exon=Andreas Ericsson <ae@op5.se>
spawn=Simon Pawn <spawn@frog-pond.org>
which will translate the ugly cvs authornames to the more informative
git style.
The info is saved in $GIT_DIR/cvs-authors, so that subsequent
incremental imports will use the same author-info even if no -A
option is specified. If an -A option *is* specified, the info in
$GIT_DIR/cvs-authors is appended/updated appropriately.
Docs updated accordingly.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While reviewing the end user tutorial rewrite by J. Bruce
Fields, I noticed that "git-diff-tree -B -C" did not correctly
break the total rewrite of Documentation/tutorial.txt. It turns
out that we had integer overflow during the break score
computations.
Cop out by using floating point. This is not a kernel.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this, the command includes the current branch to the list
of revs to be shown when it is not given on the command line.
This is handy to use in the configuration file like this:
[showbranch]
default = --current
default = heads/* ; primary branches, not topics under
; subdirectories
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the character used to mark the commits that is on the
branch from '+' to '*' for the current branch, to make it stand out.
Also we show '-' for merge commits.
When you have a handful branches with relatively long diversion, it
is easier to see which one is the current branch this way.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make --mbox, --author, and --date options a no-op, and always
use --mbox output, and rewrite the commit log formatting in
Perl. This makes it easier to output Date: header in RFC 2822
format, so do that as well.
Inspiration for this patch came from Andreas Ericsson's earlier
patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new option --naked is to help creating a naked repository
for public consumption.
$ git clone -l -s --naked \
/pub/scm/.../torvalds/linux-2.6.git subproj-2.6.git
is equivalent to this sequence:
$ git clone -l -s -n /pub/scm/.../torvalds/linux-2.6.git temp
$ mv temp/.git subproj-2.6.git
$ rmdir temp
Signed-off-by: Junio C Hamano <junkio@cox.net>
This shows your working file state when you switch branches. As
a side effect, "git checkout" without any branch name (i.e. stay
on the current branch) becomes a more concise shorthand for the
"git status" command.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The underlying "git send-pack remote.host:path" pushes all the
matching refs that both local and remote have, and "git push"
blindly inherits this property. Which probably was a mistake.
A typical cloned repository (e.g. a subsystem repository cloned
from Linus repository) has at least two branches, "master" to
keep the subsystem and "origin" that records tip of Linus
"master" when the repository was cloned. If this is the public
repository for the subsystem, then subsystem developers would
clone it, and then cloned ones have "master" and "origin". When
developers use this public subsystem repository as a shared
repository, pushing into it via "git push subsys:/path/name"
would try to push the matching refs, "master" and "origin", from
the developers' repositories. The "origin" in the public shared
repository does not have much relevance, yet pushing into
"origin" would cause "not a fast forward" checks to be
triggered. Arguably "git push subsys:/path/name master" would
work it around, but having them to say it explicitly to avoid
pushing into "origin" as well is bad.
This commit requires you to give at least one refspec to
git-push. You could "give" by either:
(1) Listing the refspec(s) explicitly on the command line.
E.g. "git push subsys:/path/name master".
(2) Using --all or --tags on the command line.
E.g. "git push --tags subsys:/path/name".
(3) Using a $GIT_DIR/remotes shorthand with 'Push: refspec'
line in it.
Unlike pull that can happen pretty much promiscuously, people
will push into the same set of a limited number of remote
repositories repeatedly over the life of the project, so it is
reasonable to assume they would want to keep a $GIT_DIR/remotes/
entry for those repositories even only to save typing the URL,
so keeping the default 'Push: refspec' line in such is a
sensible thing to do.
It was suggested to further fall back on pushing the current
branch, but this commit does not implement it. If developers
adopt topic branch workflow, pushing to public while on a topic
branch by mistake would expose the topic branch to the public
repository. Not falling back to the current branch prevents
that mistake from happening.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* Instead of going interactive, introduce a command line switch
'-m' to allow merging changes when normal two-way merge by
read-tree prevents branch switching.
* Leave the unmerged stages intact if automerge fails, but
reset index entries of cleanly merged paths to that of the
new branch, so that "git diff" (not "git diff HEAD") would
show the local modifications.
* Swap the order of trees in read-tree three-way merge used in
the fallback, so that `git diff` to show the conflicts become
more natural.
* Describe the new option and give more examples in the documentation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When switching branches, if the working tree has a local
modification at paths that are different between current and new
branches, we refused the operation saying "cannot merge." This
attempts to do an automerge for such paths.
This is still experimental.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier change to separate $(gitexecdir) from $(bindir) had
the installation location of the git wrapper and the rest of the
commands the wrong way (right now, both of them point at the
same location so there is no real harm).
Also gitk needs to be installed in $(bindir).
Signed-off-by: Junio C Hamano <junkio@cox.net>
The git suite may not be in PATH (and thus programs such as
git-send-pack could not exec git-rev-list). Thus there is a need for
logic that will locate these programs. Modifying PATH is not
desirable as it result in behavior differing from the user's
intentions, as we may end up prepending "/usr/bin" to PATH.
- git C programs will use exec*_git_cmd() APIs to exec sub-commands.
- exec*_git_cmd() will execute a git program by searching for it in
the following directories:
1. --exec-path (as used by "git")
2. The GIT_EXEC_PATH environment variable.
3. $(gitexecdir) as set in Makefile (default value $(bindir)).
- git wrapper will modify PATH as before to enable shell scripts to
invoke "git-foo" commands.
Ideally, shell scripts should use the git wrapper to become independent
of PATH, and then modifying PATH will not be necessary.
[jc: with minor updates after a brief review.]
Signed-off-by: Michal Ostrowski <mostrows@watson.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We rejected multi-base merge situations even though we used the
same underlying multi-base git-read-tree as the resolve strategy
uses. This was unneeded and did not add much to ensure the
merge to be truly trivial, so remove this restriction and be
more similar to what resolve does.
Also when the merge did not trivially resolve, we rejected
without stating that octopus strategy does not handle the
situation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is not invoked by any other target (most notably, "make
install" does not), but is provided as a convenience for people
who are building from the source.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier only '?' and '*' signalled the command that what the
user has given is a glob pattern. This prevented us to say:
$ git show-branch 'v0.99.[0-3]'
Now we notice '[' as well, so the above would work.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In a repository with mainto/1.0 (to keep maintaining the 1.0.X
series) and fixo/1.0 (to keep fixes that apply to both 1.0.X
series and upwards) branches, "git-name-rev mainto/1.0" answered
just "1.0" making things ambiguous. Show refnames unambiguously
like show-branch does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is based on the patch by Andreas Ericsson, but done slightly
differently, preferring to have separate loops -- one for options
and then arguments.
Signed-off-by: Junio C Hamano <junkio@cox.net>
update-index --stdin did not work with c-style quoted names even though
update-index --index-info did. This fixes the inconsistency.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you are a long time git user/developer, you forget that to a new git
user, these words have not the same meaning as to you.
[jc: with updates from J. Bruce Fields.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This lets showbranch.default multivalued configuration item to
be used as the default set of parameters to git-show-branch when
none is given on the command line.
I keep many topic branches (e.g. zzz/pack, net/misc) and
branches used only as a reference under subdirectories
(e.g. hold/{html,man,todo} track the same from git.git, but
clutters the show-branch output when shown along with the main
development; ko/master tracks what I have pushed out already and
refetched from the kernel.org server), and often run:
$ git show-branch ko/master heads/*
to view only the ko/master head and branches I keep immediately
under $GIT_DIR/refs/heads. With this change, I can have this in
my $GIT_DIR/config file:
[showbranch]
default = ko/master
default = heads/*
and say
$ git show-branch
Signed-off-by: Junio C Hamano <junkio@cox.net>
