Instead of silently allowing to create a bogus commit that lacks
information by mistake, complain loudly and die.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In fetch_object, there's a call to release an object request if the
object mysteriously arrived, say in a pack. Unfortunately, the fetch
attempt for this object might already be in progress, and we'll leak the
descriptor. Instead, try to tidy away the request.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't mention it in docs or --help output.
Remove mbox, date and author variables from git-format-patch.sh.
Use DESCRIPTION text from man-page to update LONG_USAGE output. It's
a bit silly to have two texts saying the same thing in different words,
and I'm too lazy to update both.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Introduce --only flag to allow the new "partial commit"
semantics when paths are specified. The default is still the
traditional --include semantics. Once peoples' fingers and
scripts that want the traditional behaviour are updated to
explicitly say --include, we could change it to either default
to --only, or refuse to operate without either --only/--include
when paths are specified.
This also fixes a couple of bugs in the previous round. Namely:
- forgot to save/restore index in some cases.
- forgot to use the temporary index to show status when '--only
paths...' semantics was used.
- --author did not take precedence when reusing an existing
commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
- "git commit" without _any_ parameter keeps the traditional
behaviour. It commits the current index.
We commit the whole index even when this form is run from a
subdirectory.
- "git commit --include paths..." (or "git commit -i paths...")
is equivalent to:
git update-index --remove paths...
git commit
- "git commit paths..." acquires a new semantics. This is an
incompatible change that needs user training, which I am
still a bit reluctant to swallow, but enough people seem to
have complained that it is confusing to them. It
1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds
trained git users that the traditional semantics now needs
-i flag.
2. refuses to run if named paths... are different in HEAD and
the index (ditto about reminding). Added paths are OK.
3. reads HEAD commit into a temporary index file.
4. updates named paths... from the working tree in this
temporary index.
5. does the same updates of the paths... from the working
tree to the real index.
6. makes a commit using the temporary index that has the
current HEAD as the parent, and updates the HEAD with this
new commit.
- "git commit --all" can run from a subdirectory, but it updates
the index with all the modified files and does a whole tree
commit.
- In all cases, when the command decides not to create a new
commit, the index is left as it was before the command is
run. This means that the two "git diff" in the following
sequence:
$ git diff
$ git commit -a
$ git diff
would show the same diff if you abort the commit process by
making the commit log message empty.
This commit also introduces much requested --author option.
$ git commit --author 'A U Thor <author@example.com>'
Signed-off-by: Junio C Hamano <junkio@cox.net>
In a workflow that employs relatively long lived topic branches,
the developer sometimes needs to resolve the same conflict over
and over again until the topic branches are done (either merged
to the "release" branch, or sent out and accepted upstream).
This commit introduces a new command, "git rerere", to help this
process by recording the conflicted automerge results and
corresponding hand-resolve results on the initial manual merge,
and later by noticing the same conflicted automerge and applying
the previously recorded hand resolution using three-way merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In addition to the branch names, populate the log message with
one-line description from actual commits that are being merged.
This was prompted by Len's 12-way octopus. You need to have
'merge.summary' in the configuration file to enable it:
$ git repo-config merge.summary yes
Signed-off-by: Junio C Hamano <junkio@cox.net>
A new flag --aggressive resolves what we traditionally resolved
with external git-merge-one-file inside index while read-tree
3-way merge works.
git-merge-octopus and git-merge-resolve use this flag before
running git-merge-index with git-merge-one-file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the first part uses quoted-printable to protect iso8859-1
name in the commit log, and the second part was plain ascii text
patchfile without even Content-Transfer-Encoding subheader, we
incorrectly tried to decode the patch as quoted printable.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The sections on git urls and remotes files in the git-fetch,
git-pull, and git-push manpages seem long enough to be worth a
manpage section of their own.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The push and pull man pages include a bunch of shared text from
pull-fetch-param.txt. This simplifies maintenance somewhat, but
there's actually quite a bit of text that applies only to one or the
other.
So, separate out the push- and pull/fetch-specific text into
pull-fetch-param.txt and git-push.txt, then include the largest chunk
of common stuff (the description of protocols and url's) from
urls.txt. That cuts some irrelevant stuff from the man pages without
making us duplicate too much.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we remove a file, the parents' contents are all removed so
it is not that interesting to show all of them, but the fact it
was removed when all parents had it *is* unusual. When we add a
file, similarly the fact it was added when no parent wanted it
*is* unusual, and in addition the result matters, so show it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This replaces a lot of code that used the result from several 2-way
diffs to generate a combined diff for a merge. Now we just use
git-diff-tree --cc and colorize the output a bit, which is a lot
simpler, and has the enormous advantage that if the diff doesn't
show quite what someone thinks it should show, I can deflect the
blame to someone else. :)
Signed-off-by: Paul Mackerras <paulus@samba.org>
Apparently this simplifies things for the parser/compiler and makes
it go slightly faster (since without the braces, it potentially has
to do two levels of substitutions rather than one).
Signed-off-by: Paul Mackerras <paulus@samba.org>
When we run combined diff from working tree (diff-files --cc),
we sent NULL to printf that is returned by find_unique_abbrev().
Signed-off-by: Junio C Hamano <junkio@cox.net>
We still talked about HEAD symlinks but these days we use
symrefs by default.
Also 'failed/prevented' message is now gone from the merge
output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
These flags ask diff with a specific unmerged stage, so it
should fall back on -p instead. Also when -c is given, we
should not do --cc.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/daemon:
daemon: extend user-relative path notation.
daemon: Set SO_REUSEADDR on listening sockets.
daemon: do not forbid user relative paths unconditionally under --base-path
* mw/http:
http-fetch: Tidy control flow in process_alternate_response
http: Turn on verbose Curl messages if GIT_CURL_VERBOSE set in environment
http-fetch: Fix message reporting rename of object file.
http-fetch: Fix object list corruption in fill_active_slots().
git-diff-tree --stdin ignored second and subsequent parents when
fed git-rev-list --parents output. Update diff_tree_commit()
function to take a commit object, and pass a fabricated commit
object after grafting the fake parents from diff_tree_stdin().
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier we had a workaround to avoid misspelled revision name to
be taken as a filename when "--no-revs --no-flags" are in
effect. This cleans up the logic.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also reorganizes the man page to list options alphabetically.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, we made --base-path to automatically forbid
user-relative paths, which was probably a mistake. This
introduces --user-path (or --user-path=path) option to control
the use of user-relative paths independently. The latter form
of the option can be used to restrict accesses to a part of each
user's home directory, similar to "public_html" some webservers
supports.
If we're invoked with --user-path=FOO option, then a URL of the
form git://~USER/PATH/... resolves to the path HOME/FOO/PATH/...,
where HOME is USER's home directory.
[jc: This is much reworked by me so bugs are mine, but the
original patch was done by Mark Wooding.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this, you can silently lose the ability to receive IPv4
connections if you stop and restart the daemon.
[jc: tweaked code organization a bit and made this controllable
from a command line option.]
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using base-path to relocate the server public space does not
have anything to do with allowing or forbidding user relative
paths.
Signed-off-by: Junio C Hamano <junkio@cox.net>
move_temp_to_file returns 0 or -1. This is not a good thing to pass to
strerror(3). Fortunately, someone already reported the error, so don't
worry too much.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In fill_active_slots() -- if we find an object which has already arrived,
say as part of a pack, /don't/ remove it from the list. It's already been
prefetched and someone will ask for it later. Just label it as done and
carry blithely on. (As it was, the code would dereference a freed object
to continue through the list anyway.)
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is essentially 'git whatchanged -n1 --always --cc "$@"'.
Just like whatchanged takes default flags from
whatchanged.difftree configuration, this uses show.difftree
configuration.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It could be made later to show unmerged state nicer than the
default as we did for diff-files later, but this would suffice
for now. We would like to make --cc the default for 'git diff'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It _might_ make sense for certain users like gitk and gitview if
we had a single tool that gives --pretty and its diff even if
the diff is empty. Having said that, the flag --cc -m is too
specific. If some uses want to see the commit log even for an
empty diff, that flag should not be something only --cc honors.
Here's an "--always" flag that does that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since we already depend on zlib, we don't need to define our
own adler32(). Spotted by oprofile.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using "--verify" together with "--no-flags" makes perfect sense, but
git-rev-parse would complain about it when it saw a flag, even though it
would never actually use/output that flag.
This fixes it.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When TERM is set to 'dumb', do not start vi to edit the commit log
message.
Suggested by Amos Waterland.
Signed-off-by: Junio C Hamano <junkio@cox.net>
As far as I can see, create_subdirectories() in apply.c just
duplicates the functionality of safe_create_leading_directories() from
sha1_file.c. The former has a warm, fuzzy const parameter, but that's
not important.
The potential problem with EEXIST and creating directories should
never occur here, but will be removed by future
safe_create_leading_directories() changes. Other uses of EEXIST in
apply.c should be fine barring intentionally malicious behavior.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Could cause a crash if --base-path set. Unlikely to be a security the
concern: message doesn't go to the client, so we can't leak anything
(except by dumping core), and we've already forked, so it's not a denial
of service.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We probably thought anybody who does more than 9 parents in an
Octopus is insane when this was initially done, but there is no
inherent reason to limit the number of independent topic
branches that happen to mature at the same time.
Our commit-tree allows up to 16 already, so at least we should
prepare to handle what we can produce, if only to be consistent.
Signed-off-by: Junio C Hamano <junkio@cox.net>
