Currently git mergetool is restricted to a set of commands defined
in the script. You can subvert the mergetool.<tool>.path to force
git mergetool to use a different command, but if you have a command
whose invocation syntax does not match one of the current tools then
you would have to write a wrapper script for it.
This patch adds two git config variable patterns which allow a more
flexible choice of merge tool.
If you run git mergetool with -t/--tool or the merge.tool config
variable set to an unrecognized tool then git mergetool will query the
mergetool.<tool>.cmd config variable. If this variable exists, then git
mergetool will treat the specified tool as a custom command and will use
a shell eval to run the command with the documented shell variables set.
mergetool.<tool>.trustExitCode can be used to indicate that the exit
code of the custom command can be used to determine the success of the
merge.
Signed-off-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The variable $path changes to $MERGED so that it is more consistent
with $BASE, $LOCAL and $REMOTE for future custom command lines.
Signed-off-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently a backup pre-merge file with conflict markers is sometimes
kept with a .orig extenstion and sometimes removed depending on the
particular merge tool used.
This patch makes the handling consistent across all merge tools and
configurable via a new mergetool.keepBackup config variable
Signed-off-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running log/show/whatchanged from the command line, the user may
want to use a preferred format without having to pass --pretty=<fmt>
option every time from the command line. This teaches these three
commands to honor a new configuration variable, format.pretty.
The --pretty option given from the command line will override the
configured format.
The earlier patch fixed the in-tree callers that run these commands
for purposes other than showing the output directly to the end user
(the only other in-tree caller is "git bisect visualize", whose output
directly goes to the end user and should be affected by this patch).
Similar fixes will be needed for end-user scripts that parse the
output from these commands and expect them to be in the default pretty
format.
Signed-off-by: Denis Cheng <crquan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The following patch will introduce a new configuration variable,
"format.pretty", from then on the pretty format without specifying
"--pretty" might not be the default "--pretty=medium", it depends on
the user's config. So all kinds of Shell/Perl/Emacs scripts that needs
the default medium pretty format must specify it explicitly.
Signed-off-by: Denis Cheng <crquan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation had its own description for --pretty and did not
include pretty-options/formats as documentation for other commands in
the "log" family did.
Signed-off-by: Denis Cheng <crquan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new option --rebasing is used internally for rebase to tell am that
it is being used for its purpose. This would leave .dotest/rebasing to
help "completion" scripts tell if the ongoing operation is am or rebase.
Also the option at the same time stands for --binary, -3 and -k which
are always given when rebase drives am as its backend.
Using the information "am" leaves, git-completion.bash tells ongoing
rebase and am apart.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It has been supported for a long time, but I do not think this feature has
been in use in the real world at all. We would eventually move this out
of the toplevel of the work tree and to somewhere under $GIT_DIR, so let's
remove the command line option to specify the location now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An earlier commit c149184 (allow git-am to run in a subdirectory) taught
git-am to start from a subdirectory by going up to the root of the work
tree byitself, but it did not adjust the path to read the mbox from when
it did so.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ba002f3 (builtin-fsck: move common object checking code to fsck.c) did
more than what it claimed to. Most notably, it wrongly made an empty tree
object an error by pretending to only move code from fsck_tree() in
builtin-fsck.c to fsck_tree() in fsck.c, but in fact adding a bogus check
to barf on an empty tree.
An empty tree object is _unusual_. Recent porcelains try reasonably hard
not to let the user create a commit that contains such a tree. Perhaps
warning about them in git-fsck may have some merit.
HOWEVER.
Being unusual and being errorneous are two quite different things. This
is especially true now we seem to use the same fsck_$object() code in
places other than git-fsck itself. For example, receive-pack should not
reject unusual objects, even if it would be a good idea to tighten it to
reject incorrect ones.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the remote peer upload-pack process supports the include-tag
protocol extension then we can avoid running a second fetch cycle
on the client side by letting the server send us the annotated tags
along with the objects it is packing for us. In the following graph
we can now fetch both "tag1" and "tag2" on the same connection that
we fetched "master" from the remote when we only have L available
on the local side:
T - tag1 S - tag2
/ /
L - o ------ o ------ B
\ \
\ \
origin/master master
The objects for "tag1" are implicitly downloaded without our direct
knowledge. The existing "quickfetch" optimization within git-fetch
discovers that tag1 is complete after the first connection and does
not open a second connection.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new protocol extension "include-tag" allows the client side
of the connection (fetch-pack) to request that the server side of the
native git protocol (upload-pack / pack-objects) use --include-tag
as it prepares the packfile, thus ensuring that an annotated tag object
will be included in the resulting packfile if the object it refers to
was also included into the packfile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new option "--include-tag" allows the caller to request that
any annotated tag be included into the packfile if the object the tag
references was also included as part of the packfile.
This option can be useful on the server side of a native git transport,
where the server knows what commits it is including into a packfile to
update the client. If new annotated tags have been introduced then we
can also include them in the packfile, saving the client from needing
to request them through a second connection.
This change only introduces the backend option and provides a test.
Protocol extensions to make this useful in fetch-pack/upload-pack
are still necessary to activate the logic during transport.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mac OS X Tiger may have a msgfmt available but it doesn't understand
how to implement --tcl. Falling back to po2msg.sh on such systems
is a reasonable behavior.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
Fix 'git remote show' regression on empty repository in 1.5.4
Fix incorrect wording in git-merge.txt.
git-merge.sh: better handling of combined --squash,--no-ff,--no-commit options
Fix random crashes in http_cleanup()
Back in 18f7c51c we switched git-ls-remote/git-peek-remote to
use the transport backend, rather than do everything itself.
As part of that switch we started to produce a non-zero exit
status if no refs were received from the remote peer, which
happens when the remote peer has no commits pushed to it yet.
(E.g. "git --git-dir=foo.git init; git ls-remote foo.git")
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Removing .dotest should actually not be needed, so just test the directory
don't exist after --abort, but exists after starting the rebase.
Also, execute the same tests with rebase --merge, which uses a different code
path.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 3a70cdfa42 made readP4Files abort quickly
when the changeset only contains files that are marked for deletion with an empty return
value, which caused the commit to not do anything.
This commit changes readP4Files to distinguish between files that need to be passed to p4
print and files that have no content ("deleted") and merge them in the returned
list.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Keep the file open to: the OS does not allow removal of open files.
The saner systems just have a saner permission model and chmod 0
is enough for the test.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Existing test checked --long only for exactly tagged commit. We should
make sure it works sensibly for commits that are not tagged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Back in 212945d4 ("Teach git-describe to verify annotated tag names
before output") I taught git-describe to output the name shown in the
"tag" header of an annotated tag, rather than the name it is actually
stored under in this repository's ref namespace.
This test case verifies this is working correctly by renaming the ref
for an annotated tag to a different name that what is recorded in the
tag body, and verifying that tag is returned. We also verify there is
a message shown on stderr to inform the user that the tag is possibly
stored under the wrong name locally.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In c374b91c ("git-describe: use tags found in packed-refs correctly")
Junio fixed an issue where git-describe did not parse a tag object it
obtained from a packed-refs file, as the peel information was read in
from packed-refs and not the tag object itself.
This new test case verifies the fix listed above is functioning, and
does not have a regression in the future.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If git-describe fails we never execute the test_expect_success,
so we never actually test for failure. This is horribly wrong.
We need to always run the test case, but the test case is only
supposed to succeed if the prior git-describe returned 0.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is implausible for lookup_tag() to return NULL in this particular
codepath but we should protect ourselves against a broken repository
better.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A merge is not necessarily with a remote branch, it can be with any
commit.
Thanks to Paolo Ciarrocchi for pointing out the problem, and to
Nicolas Pitre for pointing out the fact that a merge is not
necessarily with a branch head.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-merge used to use either the --squash,--no-squash, --no-ff,--ff,
--no-commit,--commit option, whichever came last in the command line.
This lead to some un-intuitive behavior, having
git merge --no-commit --no-ff <branch>
actually commit the merge. Now git-merge respects --no-commit together
with --no-ff, as well as other combinations of the options. However,
this broke a selftest in t/t7600-merge.sh which expected to have --no-ff
completely override the --squash option, so that
git merge --squash --no-ff <branch>
fast-forwards, and makes a merge commit; combining --squash with --no-ff
doesn't really make sense though, and is now refused by git-merge. The
test is adapted to test --no-ff without the preceding --squash, and
another test is added to make sure the --squash --no-ff combination is
refused.
The unexpected behavior was reported by John Goerzen through
http://bing.sdebian.org/468568
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For some reason, http_cleanup was running all active slots, which could
lead in situations where a freed slot would be accessed in
fill_active_slots. OTOH, we are cleaning up, which means the caller
doesn't care about pending requests. Just forget about them instead
or running them.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When your refs are packed, "git-describe" can find the tag that is the
best match without ever parsing the tag itself. But lookup_tag() in
display_name() says "I've never seen it", creates an empty shell, and
returns it. We need to make sure that we actually have parsed the tag
data into it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* commit '74359821': (128 commits)
tests: introduce test_must_fail
Fix builtin checkout crashing when given an invalid path
templates/Makefile: don't depend on local umask setting
Correct name of diff_flush() in API documentation
Start preparing for 1.5.4.4
format-patch: remove a leftover debugging message
completion: support format-patch's --cover-letter option
Eliminate confusing "won't bisect on seeked tree" failure
builtin-reflog.c: don't install new reflog on write failure
send-email: fix In-Reply-To regression
git-svn: Don't prompt for client cert password everytime.
git.el: Do not display empty directories.
Fix 'git cvsexportcommit -w $cvsdir ...' when used with relative $GIT_DIR
Add testcase for 'git cvsexportcommit -w $cvsdir ...' with relative $GIT_DIR
Prompt to continue when editing during rebase --interactive
Documentation/git svn log: add a note about timezones.
git-p4: Support usage of perforce client spec
git-p4: git-p4 submit cleanups.
git-p4: Removed git-p4 submit --direct.
git-p4: Clean up git-p4 submit's log message handling.
...
Some callers may find it useful if "git describe" always gave back a
string that can be used as a shorter name for a commit object, rather than
checking its exit status (while squelching its error message, which could
potentially talk about more grave errors that should not be squelched) and
implementing a fallback themselves.
This teaches describe/name-rev a new option, --always, to use an
abbreviated object name when no tags or refs to use is found.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the situation is the following on the remote and L is the common
base between both sides:
T - tag1 S - tag2
/ /
L - A - O - O - B
\ \
origin/master master
and we have decided to fetch "master" to acquire the range L..B we
can also nab tag S at the same time during the first connection,
as we can clearly see from the refs advertised by upload-pack that
S^{} = B and master = B.
Unfortunately we still cannot nab T at the same time as we are not
able to see that T^{} will also be in the range implied by L..B.
Such computations must be performed on the remote side (not yet
supported) or on the client side as post-processing (the current
behavior).
This optimization is an extension of the previous one in that it
helps on projects which tend to publish both a new commit and a
new tag, then lay idle for a while before publishing anything else.
Most followers are able to download both the new commit and the new
tag in one connection, rather than two. git.git tends to follow
such patterns with its roughly once-daily updates from Junio.
A protocol extension and additional server side logic would be
necessary to also ensure T is grabbed on the first connection.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If autofollowing of tags is enabled, we see a new tag on the remote
that we don't have, and we already have the SHA-1 object that the
tag is peeled to, then we can fetch the tag while we are fetching
the other objects on the first connection.
This is a slight optimization for projects that have a habit of
tagging a release commit after most users have already seen and
downloaded that commit object through a prior fetch session. In
such cases the users may still find new objects in branch heads,
but the new tag will now also be part of the first pack transfer
and the subsequent connection to autofollow tags is not required.
Currently git.git does not benefit from this optimization as any
release usually gets a new commit at the same time that it gets a
new release tag, however git-gui.git and many other projects are
in the habit of tagging fairly old commits.
Users who did not already have the tagged commit still require
opening a second connection to autofollow the tag, as we are unable
to determine on the client side if $tag^{} will be sent to the
client during the first transfer or not. Such computation must be
performed on the remote side of the connection and is deferred to
another series of changes.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To facilitate testing and verification of the requests sent by
git-fetch to the remote side we permit logging the received packet
lines to the file descriptor specified in GIT_DEBUG_SEND_PACK has
been set. Special start and end lines are included to indicate
the start and end of each connection.
$ GIT_DEBUG_SEND_PACK=3 git fetch 3>UPLOAD_LOG
$ cat UPLOAD_LOG
#S
want 8e10cf4e007ad7e003463c30c34b1050b039db78 multi_ack side-band-64k thin-pack ofs-delta
want ddfa4a33562179aca1ace2bcc662244a17d0b503
#E
#S
want 3253df4d1cf6fb138b52b1938473bcfec1483223 multi_ack side-band-64k thin-pack ofs-delta
#E
>From the above trace the first connection opened by git-fetch was to
download two refs (with values 8e and dd) and the second connection
was opened to automatically follow an annotated tag (32).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To support calling find_non_local_tags() more than once in a single
git-fetch process we need the existing_refs to be stack-allocated
so it resets on the second call. We also should free the path
lists to avoid unnecessary memory leaking.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By allowing the function to append onto the end of an existing list
we can do more interesting things, like join the list of tags we
want to fetch into the first fetch, rather than the second.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we ever decided to append onto the end of this list the tail
pointer must be looking at the right memory cell at the end of
the HEAD ref_map.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We can free this ref_map as soon as the fetch is complete. It is not
used for the automatic tag following, nor is it used to disconnect the
transport. This avoids some confusion about why we are holding onto
these refs while following tags.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apparently fetch_map is passed through, but is not actually used.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes for 1.5.4.4
revert: actually check for a dirty index
tests: introduce test_must_fail
git-submodule: Fix typo 'url' which should be '$url'
receive-pack: Initialize PATH to include exec-dir.
Conflicts:
builtin-revert.c
The previous code mistakenly used wt_status_prepare to check whether the
index had anything commitable in it; however, that function is just an
init function, and will never report a dirty index.
The correct way with wt_status_* would be to call wt_status_print with the
output pointing to /dev/null or similar. However, that does extra work by
both examining the working tree and spewing status information to nowhere.
Instead, let's just implement the useful subset of wt_status_print as an
"is_index_dirty" function.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Charles Bailey