2005-09-08 02:26:23 +02:00
|
|
|
git-sh-setup(1)
|
|
|
|
===============
|
2005-08-23 10:49:47 +02:00
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
2013-01-21 20:17:53 +01:00
|
|
|
git-sh-setup - Common Git shell script setup code
|
2005-08-23 10:49:47 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
2011-07-02 04:38:26 +02:00
|
|
|
[verse]
|
2008-06-29 18:10:20 +02:00
|
|
|
'. "$(git --exec-path)/git-sh-setup"'
|
2005-08-23 10:49:47 +02:00
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
|
|
|
|
2007-01-17 10:13:05 +01:00
|
|
|
This is not a command the end user would want to run. Ever.
|
|
|
|
This documentation is meant for people who are studying the
|
|
|
|
Porcelain-ish scripts and/or are writing new ones.
|
|
|
|
|
2010-01-10 00:33:00 +01:00
|
|
|
The 'git sh-setup' scriptlet is designed to be sourced (using
|
2007-01-17 10:13:05 +01:00
|
|
|
`.`) by other shell scripts to set up some variables pointing at
|
2013-01-21 20:17:53 +01:00
|
|
|
the normal Git directories and a few helper shell functions.
|
2007-01-17 10:13:05 +01:00
|
|
|
|
|
|
|
Before sourcing it, your script should set up a few variables;
|
|
|
|
`USAGE` (and `LONG_USAGE`, if any) is used to define message
|
|
|
|
given by `usage()` shell function. `SUBDIRECTORY_OK` can be set
|
|
|
|
if the script can run from a subdirectory of the working tree
|
|
|
|
(some commands do not).
|
|
|
|
|
|
|
|
The scriptlet sets `GIT_DIR` and `GIT_OBJECT_DIRECTORY` shell
|
|
|
|
variables, but does *not* export them to the environment.
|
|
|
|
|
|
|
|
FUNCTIONS
|
|
|
|
---------
|
|
|
|
|
|
|
|
die::
|
|
|
|
exit after emitting the supplied error message to the
|
|
|
|
standard error stream.
|
|
|
|
|
|
|
|
usage::
|
|
|
|
die with the usage message.
|
|
|
|
|
|
|
|
set_reflog_action::
|
|
|
|
set the message that will be recorded to describe the
|
|
|
|
end-user action in the reflog, when the script updates a
|
|
|
|
ref.
|
|
|
|
|
2007-12-28 23:25:39 +01:00
|
|
|
git_editor::
|
|
|
|
runs an editor of user's choice (GIT_EDITOR, core.editor, VISUAL or
|
|
|
|
EDITOR) on a given file, but error out if no editor is specified
|
|
|
|
and the terminal is dumb.
|
|
|
|
|
2007-01-17 10:13:05 +01:00
|
|
|
is_bare_repository::
|
|
|
|
outputs `true` or `false` to the standard output stream
|
|
|
|
to indicate if the repository is a bare repository
|
|
|
|
(i.e. without an associated working tree).
|
|
|
|
|
|
|
|
cd_to_toplevel::
|
|
|
|
runs chdir to the toplevel of the working tree.
|
|
|
|
|
|
|
|
require_work_tree::
|
require-work-tree wants more than what its name says
Somebody tried "git pull" from a random place completely outside the work
tree, while exporting GIT_DIR and GIT_WORK_TREE that are set to correct
places, e.g.
GIT_WORK_TREE=$HOME/git.git
GIT_DIR=$GIT_WORK_TREE/.git
export GIT_WORK_TREE GIT_DIR
cd /tmp
git pull
At the beginning of git-pull, we check "require-work-tree" and then
"cd-to-toplevel". I _think_ the original intention when I wrote the
command was "we MUST have a work tree, our $(cwd) might not be at the
top-level directory of it", and no stronger than that. That check is a
very sensible thing to do before doing cd-to-toplevel. We check that the
place we would want to go exists, and then go there.
But the implementation of require_work_tree we have today is quite
different. I don't have energy to dig the history, but currently it says:
test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = true ||
die "fatal: $0 cannot be used without a working tree."
Which is completely bogus. Even though we may happen to be just outside
of it right now, we may have a working tree that we can cd_to_toplevel
back to.
Add a function "require_work_tree_exists" that implements the check
this function originally intended (this is so that third-party scripts
that rely on the current behaviour do not have to get broken).
For now, update _no_ in-tree scripts, not even "git pull", as nobody on
the list seems to really care about the above corner case workflow that
triggered this. Scripts can be updated after vetting that they do want the
"we want to make sure the place we are going to go actually exists"
semantics.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-05 04:11:18 +02:00
|
|
|
checks if the current directory is within the working tree
|
|
|
|
of the repository, and otherwise dies.
|
|
|
|
|
|
|
|
require_work_tree_exists::
|
|
|
|
checks if the working tree associated with the repository
|
|
|
|
exists, and otherwise dies. Often done before calling
|
|
|
|
cd_to_toplevel, which is impossible to do if there is no
|
|
|
|
working tree.
|
2007-01-17 10:13:05 +01:00
|
|
|
|
2011-12-20 22:42:39 +01:00
|
|
|
require_clean_work_tree <action> [<hint>]::
|
|
|
|
checks that the working tree and index associated with the
|
|
|
|
repository have no uncommitted changes to tracked files.
|
|
|
|
Otherwise it emits an error message of the form `Cannot
|
|
|
|
<action>: <reason>. <hint>`, and dies. Example:
|
|
|
|
+
|
|
|
|
----------------
|
|
|
|
require_clean_work_tree rebase "Please commit or stash them."
|
|
|
|
----------------
|
|
|
|
|
2007-12-28 23:25:39 +01:00
|
|
|
get_author_ident_from_commit::
|
|
|
|
outputs code for use with eval to set the GIT_AUTHOR_NAME,
|
|
|
|
GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
|
|
|
|
|
mergetools/p4merge: create a base if none available
Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:
p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"
Commit 0a0ec7bd changed this to:
p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED"
to avoid the problem of being unable to save in some circumstances with
similar inputs.
Unfortunately this approach produces much worse results on differing
inputs. P4Merge really regards the blank file as the base, and once you
have just a couple of differences between the two branches you end up
with one a massive full-file conflict. The 3-way diff is not readable,
and you have to invoke "difftool MERGE_HEAD HEAD" manually to get a
useful view.
The original approach appears to have invoked special 2-way merge
behaviour in P4Merge that occurs only if the base filename is "" or
equal to the left input. You get a good visual comparison, and it does
not auto-resolve differences. (Normally if one branch matched the base,
it would autoresolve to the other branch).
But there appears to be no way of getting this 2-way behaviour and being
able to reliably save. Having base==left appears to be triggering other
assumptions. There are tricks the user can use to force the save icon
on, but it's not intuitive.
So we now follow a suggestion given in the original patch's discussion:
generate a virtual base, consisting of the lines common to the two
branches. This is the same as the technique used in resolve and octopus
merges, so we relocate that code to a shared function.
Note that if there are no differences at the same location, this
technique can lead to automatic resolution without conflict, combining
everything from the 2 files. As with the other merges using this
technique, we assume the user will inspect the result before saving.
Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Reviewed-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-13 02:12:21 +01:00
|
|
|
create_virtual_base::
|
|
|
|
modifies the first file so only lines in common with the
|
|
|
|
second file remain. If there is insufficient common material,
|
|
|
|
then the first file is left empty. The result is suitable
|
|
|
|
as a virtual base input for a 3-way merge.
|
|
|
|
|
2005-08-23 10:49:47 +02:00
|
|
|
GIT
|
|
|
|
---
|
2008-06-06 09:07:32 +02:00
|
|
|
Part of the linkgit:git[1] suite
|