I realize that a lot of people use the "git-xyzzy" format, and we have
various historical reasons for it, but I also think that most people have
long since started thinking of the git command as a single command with
various subcommands, and we've long had the documentation talk about it
that way.
Slowly migrating away from the git-xyzzy format would allow us to
eventually no longer install hundreds of binaries (even if most of them
are symlinks or hardlinks) in users $PATH, and the _original_ reasons for
it (implementation issues and bash completion) are really long long gone.
Using "git xyzzy" also has some fundamental advantages, like the ability
to specify things like paging ("git -p xyzzy") and making the whole notion
of aliases act like other git commands (which they already do, but they do
*not* have a "git-xyzzy" form!)
Anyway, while actually removing the "git-xyzzy" things is not practical
right now, we can certainly start slowly to deprecate it internally inside
git itself - in the shell scripts we use, and the test vectors.
This patch adds a "remove-dashes" makefile target, which does that. It
isn't particularly efficient or smart, but it *does* successfully rewrite
a lot of our shell scripts to use the "git xyzzy" form for all built-in
commands.
(For non-builtins, the "git xyzzy" format implies an extra execve(), so
this script leaves those alone).
So apply this patch, and then run
make remove-dashes
make test
git commit -a
to generate a much larger patch that actually starts this transformation.
(The only half-way subtle thing about this is that it also fixes up
git-filter-branch.sh for the new world order by adding quoting around
the use of "git-commit-tree" as an argument. It doesn't need it in that
format, but when changed into "git commit-tree" it is no longer a single
word, and the quoting maintains the old behaviour).
NOTE! This does not yet mean that you can actually stop installing the
"git-xyzzy" binaries for the builtins. There are some remaining places
that want to use the old form, this just removes the most obvious ones
that can easily be done automatically.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this option, dangling objects are not only reported, but also
written to .git/lost-found/commit/ or .git/lost-found/other/. This
option implies '--full' and '--no-reflogs'.
'git fsck --lost-found' is meant as a replacement for git-lost-found.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change lets you use the format.subjectprefix config option to override the
default subject prefix.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 2031427167 git add was fixed if unmerged
entries are in the index and core.filemode=false. core.symlinks=false is
a similar case, which touches the same code path. Here is a test that
makes sure that the symlink property in the index is preserved, too.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git push" is run without any refspec (neither on the
command line nor in the config), we used to push "matching refs"
in the sense that anything under refs/ hierarchy that exist on
both ends were updated. This used to be a sane default for
publishing your repository to another back when we did not have
refs/remotes/ hierarchy, but it does not make much sense these
days.
This changes the semantics to push only "matching branches".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I ran git-prune on a repository and got this:
$ git-prune
error: Object 228f8065b930120e35fc0c154c237487ab02d64a is a blob, not a commit
Segmentation fault (core dumped)
This repository was a strange one in that it was being used to provide
its own submodule. That is, the repository was cloned into a
subdirectory, an independent branch checked out in that subdirectory,
and then it was marked as a submodule. git-prune then failed in the
above manner.
The problem was that git-prune was not submodule aware in two areas.
Linus said:
> So what happens is that something traverses a tree object, looks at each
> entry, sees that it's not a tree, and tries to look it up as a blob. But
> subprojects are commits, not blobs, and then when you look at the object
> more closely, you get the above kind of object type confusion.
and included a patch to add an S_ISGITLINK() test to reachable.c's
process_tree() function. That fixed the first git-prune error, and
stopped it from trying to process the gitlink entries in trees as if
they were pointers to other trees (and of course failing, because
gitlinks _aren't_ trees). That part of this patch is his.
The second area is add_cache_refs(). This is called before starting the
reachability analysis, and was calling lookup_blob() on every object
hash found in the index. However, it is no longer true that every hash
in the index is a pointer to a blob, some of them are gitlinks, and are
not backed by any object at all, they are commits in another repository.
Normally this bug was not causing any problems, but in the case of the
self-referencing repository described above, it meant that the gitlink
hash was being marked as being of type OBJ_BLOB by add_cache_refs() call
to lookup_blob(). Then later, because that hash was also pointed to by
a ref, add_one_ref() would treat it as a commit; lookup_commit() would
return a NULL because that object was already noted as being an
OBJ_BLOB, not an OBJ_COMMIT; and parse_commit_buffer() would SEGFAULT on
that NULL pointer.
The fix made by this patch is to not blindly call lookup_blob() in
reachable.c's add_cache_refs(), and instead skip any index entries that
are S_ISGITLINK().
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ns/stash:
Documentation: quote {non-attributes} for asciidoc
git-stash: don't complain when listing in a repo with no stash
git-stash: fix "can't shift that many" with no arguments
git-stash: fix "no arguments" case in documentation
git-stash: require "save" to be explicit and update documentation
Document git-stash
Add git-stash script
* js/rebase:
Teach rebase -i about --preserve-merges
rebase -i: provide reasonable reflog for the rebased branch
rebase -i: several cleanups
ignore git-rebase--interactive
Teach rebase an interactive mode
Move the pick_author code to git-sh-setup
* jc/diffcore:
diffcore-delta.c: Ignore CR in CRLF for text files
diffcore-delta.c: update the comment on the algorithm.
diffcore_filespec: add is_binary
diffcore_count_changes: pass diffcore_filespec
Change "to made" to "made to", which is a typo. Use "reflog"
instead of "ref log", which is used elsewhere throughout the
documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Asciidoc treats {foo} as an attribute to be substituted; if
'foo' doesn't exist as an attribute, then the entire line
gets dropped. When the literal {foo} is desired, \{foo} is
required.
The exceptions to this rule are:
- inside literal blocks
- if the 'foo' contains non-alphanumeric characters (e.g.,
{foo|bar} is assumed not to be an attribute)
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an alias starts with an exclamation mark, the rest is interpreted
as a shell command. However, all arguments passed to git used to be
ignored.
Now you can have an alias like
$ git config alias.e '!echo'
and
$ git e Hello World
does what you expect it to do.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were places using "GIT_DIR" instead of GIT_DIR_ENVIRONMENT and
"GIT_CONFIG" instead of CONFIG_ENVIRONMENT. This makes it easier to
find all places touching an environment variable using git grep or
similar tools.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-clone supports cloning from a repo with detached HEAD,
but if this HEAD is not behind any branch tip then it
would not have been fetched over dumb http, resulting in a
fatal: Not a valid object name HEAD
Since 928c210a, this would also happen on a http repo
with a HEAD that is a symbolic link where someone has
forgotton to run update-server-info.
Signed-off-by: Sven Verdoolaege <skimo@liacs.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some repositories might not use/have annotated tags (for example the
ones created with git-cvsimport) and git-submodule status might fail
because git-describe might fail to find a tag. This change allows the
status of a submodule to be described/displayed relative to lightweight
tags as well.
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To make a submodule effectively usable, the path and
a URL where the submodule can be cloned need to be stored
in .gitmodules. This subcommand takes care of setting
this information after cloning the new submodule.
Only the index is updated, so, if needed, the user may still
change the URL or switch to a different branch of the submodule
before committing.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Asciidoc treats {foo} as an attribute to be substituted; if
'foo' doesn't exist as an attribute, then the entire line
gets dropped. When the literal {foo} is desired, \{foo} is
required.
The exceptions to this rule are:
- inside literal blocks
- if the 'foo' contains non-alphanumeric characters (e.g.,
{foo|bar} is assumed not to be an attribute)
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, the git-log invocation would complain if a repo
had not had any stashes created in it yet:
$ git-init
$ git-stash
fatal: ambiguous argument 'refs/stash': unknown revision or
path not in the working tree.
Use '--' to separate paths from revisions
Instead, we only call git-log if we actually have a
refs/stash. We could alternatively create the ref when any
stash command is called, but it's better for the 'list'
command to not require write access to the repo.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 9488e875 changed this from 'save' to 'list', but
missed this spot in the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When wc outputs whitespace, the test "$(command | wc -l)" = 1 is
broken because " 1" != "1". Let the shell eat the whitespace by
using test 1 = $(command | wc -l) instead.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a merge left unmerged entries, git add failed to pick up the
file mode from the index, when core.filemode == 0. If more than one
unmerged entry is there, the order of stage preference is 2, 1, 3.
Noticed by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This avoids warning messages from gpg while verifying the tags; without it,
the program complains that the key is not certified with a trusted signature.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ei/worktree+filter:
filter-branch: always export GIT_DIR if it is set
setup_git_directory: fix segfault if repository is found in cwd
test GIT_WORK_TREE
extend rev-parse test for --is-inside-work-tree
Use new semantics of is_bare/inside_git_dir/inside_work_tree
introduce GIT_WORK_TREE to specify the work tree
test git rev-parse
rev-parse: introduce --is-bare-repository
rev-parse: document --is-inside-git-dir
This describes the git-stash command.
I borrowed a few paragraphs from Johannes's version, and added a few
examples.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cache the maximum revision for each rev_db URL rather than looking it
up each time. This saves a lot of time when rebuilding indexes on a
freshly cloned repository.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This saves a bit of time when rebuilding the git-svn index.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, whenever svn repository http server requests client
certificate, prompt provider is invoked, ignoring any
ssl-client-cert-file settings in ~/.subversion/servers.
Moreover, it happens more than once per session, which is quite
irritating.
Signed-off-by: Michael Krelin <hacker@klever.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This ignores CR byte in CRLF sequence in text file when
computing similarity of two blobs.
Usually this should not matter as nobody sane would be checking
in a file with CRLF line endings to the repository (they would
use autocrlf so that the repository copy would have LF line
endings).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The comment at the top of the file described an old algorithm
that was neutral to text/binary differences (it hashed sliding
window of N-byte sequences and counted overlaps), but long time
ago we switched to a new heuristics that are more suitable for
line oriented (read: text) files that are much faster.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diffcore-break and diffcore-rename would want to behave slightly
differently depending on the binary-ness of the data, so add one
bit to the filespec, as the structure is now passed down to
diffcore_count_changes() function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We may want to use richer information on the data we are dealing
with in this function, so instead of passing a buffer address
and length, just pass the diffcore_filespec structure. Existing
callers always call this function with parameters taken from a
filespec anyway, so there is no functionality changes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When my boss has something to show me and I have to update, for some
reason I am always in the middle of doing something else, and git pull
command refuses to work in such a case.
I wrote this little script to save the changes I made, perform the
update, and then come back to where I was, but on top of the updated
commit.
This is how you would use the script:
$ git stash
$ git pull
$ git stash apply
[jc: with a few fixlets from the list]
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano