Recent change to make sure we get commit, not tag, accidentally
removed its feature of giving a usage help message when it died.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use the common error message format, "filename:lineno: body";
this way, problematic lines can be jumped to from the Emacs
compilation buffer by C-x `.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This teachs git-applypatch, which is used from git-applymbox, three
hooks, similar to what git-commit-script uses.
Signed-off-by: Junio C Hamano <junkio@cox.net>
There are three hooks:
- 'pre-commit' is given an opportunity to inspect what is
being committed, before we invoke the EDITOR for the
commit message;
- 'commit-msg' is invoked on the commit log message after
the user prepares it;
- 'post-commit' is run after a successful commit is made.
The first two can interfere to stop the commit. The last one is
for after-the-fact notification.
The earlier built-in commit checker is now moved to pre-commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
After you deleted files from your working tree, automatic
git-update-cache used when the "--all" flag is given to "git
commit" barfs because it lacks the --remove flag.
It can be argued that this is a feature; people should be
careful and something with a grave consequence like removing
files should be done manually, in which case the current
behaviour may be OK.
The patch is for people who thinks the user who uses the "--all"
flag deserves the danger that comes with the convenience.
Comments?
Signed-off-by: Junio C Hamano <junkio@cox.net>
When following tags, check for parse_object() success and error out
properly instead of segfaulting.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In case of a commit with an empty message there is no
mandatory empty line between headers and body
[jc: This makes --mbox output valid even when the commit message does
not have anything but its first line, which the one I wrote botched.
One side-effect is that it adds an extra blank line at the end even if
it has more than one lines, which will be eaten by the receiving end.
As Marco says, this is a stop-gap measure. This script needs to be
split into two, one that gets the format specifier and a commit ID to
write to its standard output, and another that drives that one reading
from rev-list. I'll fix things properly when that happens by
rewriting the former part in Perl or something more reasonable than
the current shell, sed and grep mishmash.]
Signed-off-by: Marco Costalba <mcostalba@yahoo.it>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This just displays the result of git-cat-file on the tag in the
details pane. If the tag is a "direct" tag (the tag file contains
the SHA1 ID of a commit rather than a tag), we show the tag name
and SHA1 ID.
These are features requested by Junio. Any plain file under .git/refs
whose contents start with 40 hex characters is taken as a reference
and displayed like a head but with a light blue background (unless it
is in .git/refs/tags or .git/refs/heads, in which case it is displayed
as before). There is now a "Reread references" menu item in the File
menu which re-reads all the plain files under .git/refs and redisplays
any references that have changed.
It cannot be checked with #ifndef, if you really think about what it
does which cannot be done only with the preprocessor. My thinko.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise the first commit rebase makes could include whatever
dirty state the original working tree had.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes git-applymbox verify that the index matches the current HEAD
before it starts applying patches.
Otherwise, you might have updated the index with unrelated changes, and
the first patch will commit not just the patch from the mbox, but also any
changes you had in your index.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Changes to the descriptions of tree and tag objects, a link for ent, and
descriptions for rewind, rebase and core git were added.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Small fix (use "git branch" to make branches, rather than "git checkout -b").
Optimization for trivial patches (apply to release and merge to test).
Three sample scripts appended.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This also includes a script which does the sorting, and introduces
hyperlinks for every described term.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
From http://blogs.law.harvard.edu/tech/rss
author - Email address of the author of the item.
guid - A string that uniquely identifies the item.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
With --parents, git-rev-list gives us the list of parents on the
first line of each commit. We use that rather than looking for
the parent: lines in the commit body, since this way we get to
know about the grafts for free.
Based on the discussion on the git list, here are some important changes
to the glossary. (There is no cache, but an index. Use "object name"
rather than "SHA1". Reorder. Clarify.)
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the graph gets too wide (as defined by the maxwidth variable,
which can be set in ~/.gitk), we can now terminate graph lines with
an arrow pointing downwards, and reintroduce them later with an
arrow pointing upwards when we need them. This makes the graph much
less cluttered on large repositories such as the linux kernel.
Unfortunately this has made it slower; it takes about 10 seconds
user time on the linux-2.6 repository on my machine now, compared
to 6 seconds before. I'll have to work on optimizing that. Also
on the todo list are making the arrow heads active (so if you click
on them you jump to the other end) and improving the placement of
the null entry.
It did not check to see if the working tree was clean and matched
the commit we were starting out as, resulting in the initial rebased
commit including whatever dirty state the working tree has had.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we create a cheap local clone by pointing at the object databse
of the original repository, we forgot to take the alternates the original
repository might have had into account.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier one to grab output from diff-files --name-only has a grave
bug that when no paths are given it ended up doing the equivalent of
"git-commit --all", which was not what I intended.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This also makes "./filename" acceptable as a side effect, since the
pathname normalization handles that too.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not all programs necessarily have a pathspec array of pathnames, some of
them (like git-update-cache) want to do things one file at a time. So
export the single-path interface too.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... in the newly introduced merge detection code.
Signed-off-by: Martin Langhoff <martin.langhoff@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added -m and -M flags for git-cvsimport to detect merge commits in cvs.
While this trusts the commit message, in repositories where merge commits
indicate 'merged from FOOBRANCH' the import works surprisingly well.
Even if some merges from CVS are bogus or incomplete, the resulting
branches are in better state to go forward (and merge) than without any
merge detection.
Signed-off-by: Martin Langhoff <martin.langhoff@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
[jc: This is the version without asciidoc cross references;
Johannes says that the cross referenced one is generated from
this file using a Perl script, so I am placing this as the
source, and expecting to later receive the script and a Makefile
entry or two to massage this file into the final HTML or
whatever form.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Avoid that git-format-patch writes out patch series
information on stderr when there are no errors
Signed-off-by: Marco Costalba <mcostalba@yahoo.it>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The _remote_name variable used for messages does not need the
refs/heads/ prefix included.
Signed-off-by: Kris Shannon <kris.shannon@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
At one place in Documentation/tutorial.txt and several in the base
README, its was wrongly used in place of it's or vice versa. One
instance remains somewhere in Documentation/howto/, which I didn't
correct because it's in a quotation.
Signed-off-by: Greg Louis <glouis@dynamicro.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I track a CVS project which has a branch with a '/' in the branch name.
Since git wants the branch name to be a file name at the same time,
substitute that character to a '-' by default (override with "-s <subst>").
This should work well, despite the fact that a division and a difference
are completely different :-)
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this patch, git-apply does not retain the mode when renaming or
copying files.
[jc: Good catch, Johannes. I added a test case to demonstrate the
breackage in the original.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
