The current implementation of shell-style quoted refnames and
SHA-1 expressions within fast-import contains a bad memory leak.
We leak the unquoted strings used by the `from` and `merge`
commands, maybe others. Its also just muddling up the docs.
Since Git refnames cannot contain LF, and that is our delimiter
for the end of the refname, and we accept any other character
as-is, there is no reason for these strings to support quoting,
except to be nice to frontends. But frontends shouldn't be
expecting to use funny refs in Git, and its just as simple to
never quote them as it is to always pass them through the same
quoting filter as pathnames. So frontends should never quote
refs, or ref expressions.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It used to be ls-remote on self was the only easy way to grab
the ref information. Now we have show-ref which does not
involve fork and IPC, so use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The gitk gui layout was completely broken on Cygwin. If gitk was started
without previous geometry in ~/.gitk, the user could drag the window sashes
to get a useable layout. However, if ~/.gitk existed, this was not possible
at all.
The fix was to rewrite makewindow, changing the toplevel containers and
the particular geometry information saved between sessions. Numerous bugs
in both the Cygwin and the Linux Tk versions make this a delicate
balancing act: the version here works in both but many subtle variants
are competely broken in one or the other environment.
Three user visible changes result:
1 - The viewer is fully functional under Cygwin.
2 - The search bar moves from the bottom to the top of the lower left
pane. This was necessary to get around a layout problem on Cygwin.
3 - The window size and position is saved and restored between sessions.
Again, this is necessary to get around a layout problem on Cygwin.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
The earlier commit d7b6c3c0 (Aug 15, 2006) introduced this
mismerge when most of the CFLAGS were renamed to BASIC_CFLAGS.
Not that it matters right now, since we do not compile XS
Perl extensions which wanted non GNU subset of ALL_CFLAGS for
compilation, but we should make things consistent.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you resize the terminal while less is waiting for input, less
will exit entirely without even showing the output. This is very
noticeable if you do something like "git diff" on a big and
cold-cache tree and git takes a few seconds to think, and then
you resize the window while it's preparing. Boom. No output AT
ALL.
The way to reproduce the problem is to do some pager operation
that takes a while in git, and resizing the window while git is
thinking about the output. Try
git diff --stat v2.6.12..
in the kernel tree to do something where it takes a while for git to start
outputting information.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds three options to 'git-remote add'.
* -f (or --fetch) option tells it to also run the initial "git
fetch" using the newly created remote shorthand.
* -t (or --track) option tells it not to use the default
wildcard to track all branches.
* -m (or --master) option tells it to make the
remote/$name/HEAD point at a remote tracking branch other
than master.
For example, with this I can say:
$ git remote add -f -t master -t quick-start -m master \
jbf-um git://linux-nfs.org/~bfields/git.git/
to
(1) create remote.jbf-um.url;
(2) track master and quick-start branches (and no other); the
two -t options create these two lines:
fetch = +refs/heads/master:refs/remotes/jbf-um/master
fetch = +refs/heads/quick-start:refs/remotes/jbf-um/quick-start
(3) set up remotes/jbf-um/HEAD to point at jbf-um/master so
that later I can say "git log jbf-um"
Or I could do
$ git remote add -t 'ap/*' andy /home/andy/git.git
to make Andy's topic branches kept track of under refs/remotes/andy/ap/.
Other possible improvements I considered but haven't implemented
(hint, hint) are:
* reject wildcard letters other than a trailing '*' to the -t
parameter;
* make -m optional and when the first -t parameter does not
have the trailing '*' default to that value (so the above
example does not need to say "-m master");
* if -m is not given, and -t parameter ends with '*' (i.e. the
above defaulting did not tell us where to point HEAD at), and
if we did the fetch with -f, check if 'master' was fetched
and make HEAD point at it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-merge-recursive wants an null tree as the fake merge base
while producing the merge result tree. The null tree does not
have to be written out in the object store as it won't be part
of the result, and it is a prime example for using the new
pretend_sha1_file() function.
git-blame needs to register an arbitrary data to in-core index
while annotating a working tree file (or standard input), but
git-blame is a read-only application and the user of it could
even lack the privilege to write into the object store; it is
another good example for pretend_sha1_file().
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new interface allows an application to temporarily hash a
small number of objects and pretend that they are available in
the object store without actually writing them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Warning: this changes the semantics.
This makes "git blame" without any positive rev to start digging
from the working tree copy, which is made into a fake commit
whose sole parent is the HEAD.
It also adds --contents <file> option to pretend as if the
working tree copy has the contents of the named file. You can
use '-' to make the command read from the standard input.
If you want the command to start annotating from the HEAD
commit, you need to explicitly give HEAD parameter.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Here's another version of git-blame.el that automatically tries to
create a sensible list of colors to use for both light and dark
backgrounds. Plus a few minor fixes.
To use:
1) Load into emacs: M-x load-file RET git-blame.el RET
2) Open a git-controlled file
3) Blame: M-x git-blame-mode
Signed-off-by: Junio C Hamano <junkio@cox.net>
This can be used to compress multiple changesets into one, for example
like
git cvsexportcommit -P cvshead mybranch
without having to do so in git first.
Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch helps when you accidentally run something like git-clean
in the git directory instead of the work tree.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
hg-to-git.py is able to convert a Mercurial repository into a git one,
and preserves the branches in the process (unlike tailor)
hg-to-git.py can probably be greatly improved (it's a rather crude
combination of shell and python) but it does already work quite well for
me. Features:
- supports incremental conversion
(for keeping a git repo in sync with a hg one)
- supports hg branches
- converts hg tags
Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Double clicking on the row execs a new blameview with commit hash
as argument.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the repository directory name is in non-ascii, $project needs to be
converted from perl internal to utf-8 because it will be used as
title, page path, and snapshot filename.
use to_utf8() to do the conversion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We now offer completion support for git-bisect's subcommands,
as well as ref name completion on the good/bad/reset subcommands.
This should make interacting with git-bisect slightly easier on
the fingers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We've recently added --add as an argument to git-config, but I
missed putting it into the earlier round of git-config updates
within the bash completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't offer resolve as a possible subcommand completion. If you
read the top of the script, there is a big warning about how it
will go away soon in the near future. People should not be using it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm lazy. I don't want to type out --prune if bash can do it for
me with --<tab>.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Apparently nobody really makes use of git-diff-stages, as nobody
has complained that it is not supported by the git-diff frontend.
Since its likely this will go away in the future, we should not
offer it as a possible subcommand completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I just realized I did not support ref name completion for git-cherry.
This tool is just too useful to contributors who submit patches
upstream by email; completion support for it is very handy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This particular use of git-rebase to remove a single commit or a
range of commits from the history of a branch recently came up on
the mailing list. Documenting the example should help other users
arrive at the same solution on their own.
It also was not obvious to the newcomer that git-rebase is able to
accept any commit for --onto <newbase> and <upstream>. We should
at least minimally document this, as much of the language in
git-rebase's manpage refers to 'branch' rather than 'committish'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The documentation for git-for-each-ref said that the refname variable
would return "the part after $GIT_DIR/refs/", which isn't true.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We at least know that the test as written has a problem in an
environment where "touch '$p'; ls | fgrep '$p'" fails, and have
a clear understand why it fails.
This tests if the filesystem has that particular issue we know "git
add" has a problem with, and skips the test in such an environment.
This way, we might catch issues "git add" might have in other environments.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some structs are allocated rather frequently, but were using integer
types which were far larger than required to actually store their
full value range.
As packfiles are limited to 4 GiB we don't need more than 32 bits to
store the offset of an object within that packfile, an `unsigned long`
on a 64 bit system is likely a 64 bit unsigned value. Saving 4 bytes
per object on a 64 bit system can add up fast on any sizable import.
As atom strings are strictly single components in a path name these
are probably limited to just 255 bytes by the underlying OS. Going
to that short of a string is probably too restrictive, but certainly
`unsigned int` is far too large for their lengths. `unsigned short`
is a reasonable limit.
Modes within a tree really only need two bytes to store their whole
value; using `unsigned int` here is vast overkill. Saving 4 bytes
per file entry in an active branch can add up quickly on a project
with a large number of files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This command isn't encouraged (as its slow) but it does exist and
is accepted, so it still should be covered in the BNF.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-archimport should better refuse to start an initial import if the
current directory is not empty.
(http://bugs.debian.org/400508)
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts commit 80c797764a.
Back when I committed this, it seemed to be a good idea. People
who always use remote tracking branches can optionally use the
local name they happen to use to specify what to merge, which meant
that I did not have to teach them why we use the name at the remote
side every time they are confused.
But allowing it seems to break other people's scripts. The real
solution is not to allow more ways to express the same thing, but
to educate people to use the right syntax.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* np/dreflog:
show-branch -g: default to the current branch.
Let git-checkout always drop any detached head
Enable HEAD@{...} and make it independent from the current branch
scan reflogs independently from refs
add reflog when moving HEAD to a new branch
create_symref(): do not assume pathname from git_path() persists long enough
add logref support to git-symbolic-ref
move create_symref() past log_ref_write()
add reflog entries for HEAD when detached
enable separate reflog for HEAD
lock_ref_sha1_basic(): remember the original name of a ref when resolving it
make reflog filename independent from struct ref_lock
Mention git-revert as an alternative to git-reset to revert changes.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When using --reference to borrow objects from a neighbouring
repository while cloning, we copy the entire set of refs under
temporary "refs/reference-tmp/refs" space and set up the object
alternates. However, a textual symref copied this way would not
point at the right place, and causes later steps to emit error
messages (which is harmless but still alarming). This is most
visible when using a clone created with the separate-remote
layout as a reference, because such a repository would have
refs/remotes/origin/HEAD with 'ref: refs/remotes/origin/master'
as its contents.
Although we do not create symbolic-link based refs anymore, they
have the same problem because they are always supposed to be
relative to refs/ hierarchy (we dereference by hand, so it only
is good for HEAD and nothing else).
In either case, the solution is simply to remove them after
copying under refs/reference-tmp; if a symref points at a true
ref, that true ref itself is enough to ensure that objects
reachable from it do not needlessly get fetched.
Signed-off-by: Junio C Hamano <junkio@cox.net>
format-patch/log/whatchanged all take --not and --all as options
to the internal revlist process. So these should be supported
as possible completions.
gitk takes anything rev-list/log/whatchanged takes, so we should
use complete_revlist to handle its options.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because our use of -o nospace prevents bash from adding a trailing space
when a completion is unique and has been fully completed, we need to
perform this addition on our own. This (large) change converts all
existing uses of compgen to our wrapper __gitcomp which attempts to
handle this by tacking a trailing space onto the end of each offered
option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In many cases we know a completion will be unique, but we've disabled
bash's automatic space addition (-o nospace) so we need to do it
ourselves when necessary.
This change adds additional support for new configuration options
added in 1.5.0, as well as some extended completion support for
the color.* family of options.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most of these commands are not ones you want to invoke from the
command line on a frequent basis, or have been renamed in 1.5.0 to
more friendly versions, but the old names are being left behind to
support existing scripts in the wild.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because we use the nospace option for our completion function for
the main 'git' wrapper bash won't automatically add a space after a
unique completion has been made by the user. This has been pointed
out in the past by Linus Torvalds as an undesired behavior. I agree.
We have to use the nospace option to ensure path completion for
a command such as `git show` works properly, but that breaks the
common case of getting the space for a unique completion. So now we
set IFS=$'\n' (linefeed) and add a trailing space to every possible
completion option. This causes bash to insert the space when the
completion is unique.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new --interactive mode of git-add can be very useful, so users
will probably want to have completion for it.
Likewise the new git-add--interactive executable is actually a
plumbing command. Its invoked by `git add --interactive` and is
not intended to be invoked directly by the user. Therefore we
should hide it from the list of available Git commands.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that git-show is capable of displaying any file content from any
revision and is the approved Porcelain-ish level method of doing so,
cat-file should no longer be classified as a user-level utility by
the bash completion package.
I'm also classifying the new git-reflog command as plumbing for the
time being as there are no subcommands which are really useful to
the end-user. git-gc already invokes `git reflog expire --all`,
which makes it rather unnecessary for the user to invoke it directly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The short options (-l, -f, -d) for git-branch are rather silly to
include in the completion generation as these options must be fully
typed out by the user and most users already know what the options
are anyway, so including them in the suggested completions does
not offer huge value. (The same goes for git-checkout and git-diff.)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now we have a separate reflog on HEAD, show-branch -g without an explicit
parameter defaults to the current branch, or HEAD when it is detached
from branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to refuse leaving a detached HEAD when it wasn't matching an
existing ref so not to lose any commit that might have been performed
while not on any branch (unless -f was provided).
But this protection was completely bogus since it was still possible
to move to HEAD^ while still remaining detached but losing the last
commit anyway if there was one.
Now that we have a proper reflog for HEAD it is best to simply remove
that bogus (and admitedly annoying) protection and simply display the
last HEAD position instead. If one wants to recover a lost detached
state then it can be retrieved from the HEAD reflog.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is to resolve conflicts early in preparation for possible
inclusion of "reflog on detached HEAD" series by Nico, as having
it in 1.5.0 would really help us remove confusion between
detached and attached states.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Its really nice to be able to run a test with -v and automatically
see the "debugging" dump from merge-recursive, especially if we
are actually trying to debug merge-recursive.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
My earlier fix (8371234e) to delete renamed tracked files from the
working directory also caused merge-recursive to delete untracked
files that were in the working directory.
The problem here is merge-recursive is deleting the working directory
file without regard for which branch it was associated with. What we
really want to do during a merge is to only delete files that were
renamed by the branch we are merging into the current branch,
and that are still tracked by the current branch. These files
definitely don't belong in the working directory anymore.
Anything else is either a merge conflict (already handled in other
parts of the code) or a file that is untracked by the current branch
and thus is not even participating in the merge. Its this latter
class that must be left alone.
For this fix to work we are now assuming that the first non-base
argument passed to git-merge-recursive always corresponds to the
working directory. This is already true for all in-tree callers
of merge-recursive. This assumption is also supported by the
long time usage message of "<base> ... -- <head> <remote>", where
"<head>" is implied to be HEAD, which is generally assumed to be
the current tree-ish.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
