gitk.txt
MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt
MAN7_TXT=git.txt gitcli.txt gittutorial.txt gittutorial-2.txt \
- gitcvs-migration.txt
+ gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
DOC_HTML=$(MAN_HTML)
-ARTICLES = core-tutorial
-ARTICLES += diffcore
+ARTICLES = diffcore
ARTICLES += howto-index
ARTICLES += repository-layout
ARTICLES += everyday
ARTICLES += git-tools
-ARTICLES += glossary
# with their own formatting rules.
SP_ARTICLES = howto/revert-branch-rebase howto/using-merge-subtree user-manual
API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
handling).
core.ignoreStat::
- The working copy files are assumed to stay unchanged until you
- mark them otherwise manually - Git will not detect the file changes
- by lstat() calls. This is useful on systems where those are very
- slow, such as Microsoft Windows. See linkgit:git-update-index[1].
+ If true, commands which modify both the working tree and the index
+ will mark the updated paths with the "assume unchanged" bit in the
+ index. These marked files are then assumed to stay unchanged in the
+ working copy, until you mark them otherwise manually - Git will not
+ detect the file changes by lstat() calls. This is useful on systems
+ where those are very slow, such as Microsoft Windows.
+ See linkgit:git-update-index[1].
False by default.
core.preferSymlinkRefs::
SYNOPSIS
--------
-'git-init' [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]
+'git-init' [-q | --quiet] [--
bare] [--template=<template_directory>] [--shared[=<permissions>]]
OPTIONS
Only print error and warning messages, all other output will be suppressed.
+--bare::
+
+Create a bare repository. If GIT_DIR environment is not set, it is set to the
+current working directory.
+
--template=<template_directory>::
Provide the directory from which templates will be used. The default template
-n::
--dry-run::
-This is only used with the 'dcommit' command.
+This can be used with the 'dcommit' and 'rebase' commands.
-Print out the series of git arguments that would show
+For 'dcommit', print out the series of git arguments that would show
which diffs would be committed to SVN.
+For 'rebase', display the local branch associated with the upstream svn
+repository associated with the current branch and the URL of svn
+repository that will be fetched from.
+
--
ADVANCED OPTIONS
probably more detail than necessary for a first-time user.
The link:user-manual.html#git-concepts[git concepts chapter of the
-user-manual] and the link:core-tutorial.html[Core tutorial] both provide
+user-manual] and the linkgit:gitcore-tutorial[7][Core tutorial] both provide
introductions to the underlying git architecture.
See also the link:howto-index.html[howto] documents for some useful
Terminology
-----------
-Please see the link:glossary.html[glossary] document.
+Please see the linkgit:gitglossary[7][glossary] document.
Environment Variables
More detail on the following is available from the
link:user-manual.html#git-concepts[git concepts chapter of the
-user-manual] and the link:core-tutorial.html[Core tutorial].
+user-manual] and the linkgit:gitcore-tutorial[7][Core tutorial].
A git project normally consists of a working directory with a ".git"
subdirectory at the top level. The .git directory contains, among other
<david@dgreaves.com>, and later enhanced greatly by the
contributors on the git-list <git@vger.kernel.org>.
+SEE ALSO
+--------
+linkgit:gittutorial[7], linkgit:gittutorial-2[7],
+linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
+linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
+link:user-manual.html[The Git User's Manual]
+
GIT
---
Part of the linkgit:git[7] suite
-A git core tutorial for developers
-==================================
+gitcore-tutorial(7)
+===================
-Introduction
-------------
+NAME
+----
+gitcore-tutorial - A git core tutorial for developers
+
+SYNOPSIS
+--------
+git *
+
+DESCRIPTION
+-----------
This tutorial explains how to use the "core" git programs to set up and
work with a git repository.
and the reason why you preferred changes made in one side over
the other. Otherwise it would make the project history harder
to follow, not easier.
+
+SEE ALSO
+--------
+linkgit:gittutorial[7], linkgit:gittutorial-2[7],
+linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[7] suite.
Some basic familiarity with git is required. This
linkgit:gittutorial[7][tutorial introduction to git] and the
-link:glossary.html[git glossary] should be sufficient.
+linkgit:gitglossary[7][git glossary] should be sufficient.
Developing against a shared repository
--------------------------------------
SEE ALSO
--------
-linkgit:gittutorial[7], linkgit:gittutorial-2[7],
+linkgit:gittutorial[7],
+linkgit:gittutorial-2[7],
+linkgit:gitcore-tutorial[7],
+linkgit:gitglossary[7],
link:everyday.html[Everyday Git],
link:user-manual.html[The Git User's Manual]
--- /dev/null
+gitglossary(7)
+==============
+
+NAME
+----
+gitglossary - A GIT Glossary
+
+SYNOPSIS
+--------
+*
+
+DESCRIPTION
+-----------
+
+include::glossary-content.txt[]
+
+SEE ALSO
+--------
+linkgit:gittutorial[7], linkgit:gittutorial-2[7],
+linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
+link:user-manual.html[The Git User's Manual]
+
+GIT
+---
+Part of the linkgit:git[7] suite.
In addition to being the staging area for new commits, the index file
is also populated from the object database when checking out a
branch, and is used to hold the trees involved in a merge operation.
-See the link:core-tutorial.html[core tutorial] and the relevant man
+See the linkgit:gitcore-tutorial[7][core tutorial] and the relevant man
pages for details.
What next?
pages for any of the git commands; one good place to start would be
with the commands mentioned in link:everyday.html[Everyday git]. You
should be able to find any unknown jargon in the
-link:glossary.html[Glossary].
+linkgit:gitglossary[7][Glossary].
The link:user-manual.html[Git User's Manual] provides a more
comprehensive introduction to git.
For some interesting examples of git use, see the
link:howto-index.html[howtos].
-For git developers, the link:core-tutorial.html[Core tutorial] goes
+For git developers, the linkgit:gitcore-tutorial[7][Core tutorial] goes
into detail on the lower-level git mechanisms involved in, for
example, creating a new commit.
--------
linkgit:gittutorial[7],
linkgit:gitcvs-migration[7],
+linkgit:gitcore-tutorial[7],
+linkgit:gitglossary[7],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
--------
linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
+linkgit:gitcore-tutorial[7],
+linkgit:gitglossary[7],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
-GIT Glossary
-============
-
[[def_alternate_object_database]]alternate object database::
Via the alternates mechanism, a <<def_repository,repository>>
can inherit part of its <<def_object_database,object database>>
source code management tools.
[[def_DAG]]DAG::
- Directed acyclic graph. The <<def_commit,commit>> objects form a
+ Directed acyclic graph. The <<def_commit_object,commit objects>> form a
directed acyclic graph, because they have parents (directed), and the
- graph of commit objects is acyclic (there is no
- <<def_chain,chain>> which begins and ends with the same
- <<def_object,object>>).
+ graph of commit objects is acyclic (there is no <<def_chain,chain>>
+ which begins and ends with the same <<def_object,object>>).
[[def_dangling_object]]dangling object::
An <<def_unreachable_object,unreachable object>> which is not
the <<def_hash,hash>> of the object.
[[def_object_type]]object type::
- One of the identifiers
- "<<def_commit,commit>>","<<def_tree,tree>>","<<def_tag,tag>>" or "<<def_blob_object,blob>>"
- describing the type of an <<def_object,object>>.
+ One of the identifiers "<<def_commit_object,commit>>",
+ "<<def_tree_object,tree>>", "<<def_tag_object,tag>>" or
+ "<<def_blob_object,blob>>" describing the type of an
+ <<def_object,object>>.
[[def_octopus]]octopus::
To <<def_merge,merge>> more than two <<def_branch,branches>>. Also denotes an
<repository>::
The "remote" repository that is the source of a fetch
- or pull operation. See the section <<URLS,GIT URLS>> below.
+ or pull operation. This parameter can be either a URL
+ (see the section <<URLS,GIT URLS>> below) or the name
+ of a remote (see the section <<REMOTES,REMOTES>> below).
<refspec>::
The canonical format of a <refspec> parameter is
revision walking API
====================
+The revision walking API offers functions to build a list of revisions
+and then iterate over that list.
+
+Calling sequence
+----------------
+
+The walking API has a given calling sequence: first you need to
+initialize a rev_info structure, then add revisions to control what kind
+of revision list do you want to get, finally you can iterate over the
+revision list.
+
+Functions
+---------
+
+`init_revisions`::
+
+ Initialize a rev_info structure with default values. The second
+ parameter may be NULL or can be prefix path, and then the `.prefix`
+ variable will be set to it. This is typically the first function you
+ want to call when you want to deal with a revision list. After calling
+ this function, you are free to customize options, like set
+ `.ignore_merges` to 0 if you don't want to ignore merges, and so on. See
+ `revision.h` for a complete list of available options.
+
+`add_pending_object`::
+
+ This function can be used if you want to add commit objects as revision
+ information. You can use the `UNINTERESTING` object flag to indicate if
+ you want to include or exclude the given commit (and commits reachable
+ from the given commit) from the revision list.
++
+NOTE: If you have the commits as a string list then you probably want to
+use setup_revisions(), instead of parsing each string and using this
+function.
+
+`setup_revisions`::
+
+ Parse revision information, filling in the `rev_info` structure, and
+ removing the used arguments from the argument list. Returns the number
+ of arguments left that weren't recognized, which are also moved to the
+ head of the argument list. The last parameter is used in case no
+ parameter given by the first two arguments.
+
+`prepare_revision_walk`::
+
+ Prepares the rev_info structure for a walk. You should check if it
+ returns any error (non-zero return code) and if it does not, you can
+ start using get_revision() to do the iteration.
+
+`get_revision`::
+
+ Takes a pointer to a `rev_info` structure and iterates over it,
+ returning a `struct commit *` each time you call it. The end of the
+ revision list is indicated by returning a NULL pointer.
+
+Data structures
+---------------
+
Talk about <revision.h>, things like:
* two diff_options, one for path limiting, another for output;
-* calling sequence: init_revisions(), setup_revsions(), get_revision();
+* remaining functions;
(Linus, JC, Dscho)
include::urls.txt[]
-REMOTES
--------
+REMOTES[[REMOTES]]
+------------------
-In addition to the above, as a short-hand, the name of a
-file in `$GIT_DIR/remotes` directory can be given; the
-named file should be in the following format:
+The name of one of the following can be used instead
+of a URL as `<repository>` argument:
-------------
- URL: one of the above URL format
- Push: <refspec>
- Pull: <refspec>
+* a remote in the git configuration file: `$GIT_DIR/config`,
+* a file in the `$GIT_DIR/remotes` directory, or
+* a file in the `$GIT_DIR/branches` directory.
-------------
+All of these also allow you to omit the refspec from the command line
+because they each contain a refspec which git will use by default.
-Then such a short-hand is specified in place of
-<repository> without <refspec> parameters on the command
-line, <refspec> specified on `Push:` lines or `Pull:`
-lines are used for `git-push` and `git-fetch`/`git-pull`,
-respectively. Multiple `Push:` and `Pull:` lines may
-be specified for additional branch mappings.
+Named remote in configuration file
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Or, equivalently, in the `$GIT_DIR/config` (note the use
-of `fetch` instead of `Pull:`):
+You can choose to provide the name of a remote which you had previously
+configured using linkgit:git-remote[1], linkgit:git-config[1]
+or even by a manual edit to the `$GIT_DIR/config` file. The URL of
+this remote will be used to access the repository. The refspec
+of this remote will be used by default when you do
+not provide a refspec on the command line. The entry in the
+config file would appear like this:
------------
- [remote "<remote>"]
+ [remote "<name>"]
url = <url>
push = <refspec>
fetch = <refspec>
-
------------
-The name of a file in `$GIT_DIR/branches` directory can be
-specified as an older notation short-hand; the named
-file should contain a single line, a URL in one of the
-above formats, optionally followed by a hash `#` and the
-name of remote head (URL fragment notation).
-`$GIT_DIR/branches/<remote>` file that stores a <url>
-without the fragment is equivalent to have this in the
-corresponding file in the `$GIT_DIR/remotes/` directory.
+
+Named file in `$GIT_DIR/remotes`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can choose to provide the name of a
+file in `$GIT_DIR/remotes`. The URL
+in this file will be used to access the repository. The refspec
+in this file will be used as default when you do not
+provide a refspec on the command line. This file should have the
+following format:
+
+------------
+ URL: one of the above URL format
+ Push: <refspec>
+ Pull: <refspec>
------------
- URL: <url>
- Pull: refs/heads/master:<remote>
+`Push:` lines are used by `git-push` and
+`Pull:` lines are used by `git-pull` and `git-fetch`.
+Multiple `Push:` and `Pull:` lines may
+be specified for additional branch mappings.
+
+Named file in `$GIT_DIR/branches`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can choose to provide the name of a
+file in `$GIT_DIR/branches`.
+The URL in this file will be used to access the repository.
+This file should have the following format:
+
+
+------------
+ <url>#<head>
------------
-while having `<url>#<head>` is equivalent to
+`<url>` is required; `#<head>` is optional.
+When you do not provide a refspec on the command line,
+git will use the following refspec, where `<head>` defaults to `master`,
+and `<repository>` is the name of this file
+you provided in the command line.
------------
- URL: <url>
- Pull: refs/heads/<head>:<remote>
+ refs/heads/<head>:<repository>
------------
+
+
+
+
itself!
[[glossary]]
-include::glossary.txt[]
+GIT Glossary
+============
+
+include::glossary-content.txt[]
[[git-quick-start]]
Appendix A: Git Quick Reference
}
static const char init_db_usage[] =
-"git-init [-q | --quiet] [--template=<template-directory>] [--shared]";
+"git-init [-q | --quiet] [--bare] [--template=<template-directory>] [--shared[=<permissions>]]";
/*
* If you want to, you can share the DB area with any number of branches.
const char *arg = argv[1];
if (!prefixcmp(arg, "--template="))
template_dir = arg+11;
- else if (!strcmp(arg, "--shared"))
+ else if (!strcmp(arg, "--bare")) {
+ static char git_dir[PATH_MAX+1];
+ is_bare_repository_cfg = 1;
+ setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir,
+ sizeof(git_dir)), 0);
+ } else if (!strcmp(arg, "--shared"))
shared_repository = PERM_GROUP;
else if (!prefixcmp(arg, "--shared="))
shared_repository = git_config_perm("arg", arg+9);
'strategy|s=s' => \$_strategy,
'local|l' => \$_local,
'fetch-all|all' => \$_fetch_all,
+ 'dry-run|n' => \$_dry_run,
%fc_opts } ],
'commit-diff' => [ \&cmd_commit_diff,
'Commit a diff between two trees',
die "Unable to determine upstream SVN information from ",
"working tree history\n";
}
+ if ($_dry_run) {
+ print "Remote Branch: " . $gs->refname . "\n";
+ print "SVN URL: " . $url . "\n";
+ return;
+ }
if (command(qw/diff-index HEAD --/)) {
print STDERR "Cannot rebase with uncommited changes:\n";
command_noisy('status');
my $usage = "Usage: $0 commit-diff -r<revision> ".
"<tree-ish> <tree-ish> [<URL>]";
fatal($usage) if (!defined $ta || !defined $tb);
- my $svn_path;
+ my $svn_path = '';
if (!defined $url) {
my $gs = eval { Git::SVN->new };
if (!$gs) {
$_message ||= get_commit_entry($tb)->{log};
}
my $ra ||= Git::SVN::Ra->new($url);
- $svn_path ||= $ra->{svn_path};
my $r = $_revision;
if ($r eq 'HEAD') {
$r = $ra->get_latest_revnum;
foreach (sort keys %$dirent) {
next if $dirent->{$_}->{kind} != $SVN::Node::dir;
- $self->prop_walk($p . $_, $rev, $sub);
+ $self->prop_walk($self->{path} . $p . $_, $rev, $sub);
}
}
+++ /dev/null
-Märchen
-Märchen
+++ /dev/null
-This
-filename
-contains
-spaces.
+++ /dev/null
-This
-filename
-contains
-+
-plus
-chars.
* This tells us what kind of line graph_next_line() should output.
*/
enum graph_state state;
+ /*
+ * The output state for the previous line of output.
+ * This is primarily used to determine how the first merge line
+ * should appear, based on the last line of the previous commit.
+ */
+ enum graph_state prev_state;
+ /*
+ * The index of the column that refers to this commit.
+ *
+ * If none of the incoming columns refer to this commit,
+ * this will be equal to num_columns.
+ */
+ int commit_index;
+ /*
+ * The commit_index for the previously displayed commit.
+ *
+ * This is used to determine how the first line of a merge
+ * graph output should appear, based on the last line of the
+ * previous commit.
+ */
+ int prev_commit_index;
/*
* The maximum number of columns that can be stored in the columns
* and new_columns arrays. This is also half the number of entries
graph->num_parents = 0;
graph->expansion_row = 0;
graph->state = GRAPH_PADDING;
+ graph->prev_state = GRAPH_PADDING;
+ graph->commit_index = 0;
+ graph->prev_commit_index = 0;
graph->num_columns = 0;
graph->num_new_columns = 0;
graph->mapping_size = 0;
free(graph);
}
+static void graph_update_state(struct git_graph *graph, enum graph_state s)
+{
+ graph->prev_state = graph->state;
+ graph->state = s;
+}
+
static void graph_ensure_capacity(struct git_graph *graph, int num_columns)
{
if (graph->column_capacity >= num_columns)
if (col_commit == graph->commit) {
int old_mapping_idx = mapping_idx;
seen_this = 1;
+ graph->commit_index = i;
for (parent = graph->commit->parents;
parent;
parent = parent->next) {
graph->num_parents++;
}
+ /*
+ * Store the old commit_index in prev_commit_index.
+ * graph_update_columns() will update graph->commit_index for this
+ * commit.
+ */
+ graph->prev_commit_index = graph->commit_index;
+
/*
* Call graph_update_columns() to update
* columns, new_columns, and mapping.
/*
* Update graph->state.
+ * Note that we don't call graph_update_state() here, since
+ * we don't want to update graph->prev_state. No line for
+ * graph->state was ever printed.
*
* If the previous commit didn't get to the GRAPH_PADDING state,
* it never finished its output. Goto GRAPH_SKIP, to print out
* a line to indicate that portion of the graph is missing.
*
- * Otherwise, if there are 3 or more parents, we need to print
- * extra rows before the commit, to expand the branch lines around
- * it and make room for it.
+ * If there are 3 or more parents, we may need to print extra rows
+ * before the commit, to expand the branch lines around it and make
+ * room for it. We need to do this only if there is a branch row
+ * (or more) to the right of this commit.
*
* If there are less than 3 parents, we can immediately print the
* commit line.
*/
if (graph->state != GRAPH_PADDING)
graph->state = GRAPH_SKIP;
- else if (graph->num_parents >= 3)
+ else if (graph->num_parents >= 3 &&
+ graph->commit_index < (graph->num_columns - 1))
graph->state = GRAPH_PRE_COMMIT;
else
graph->state = GRAPH_COMMIT;
strbuf_addstr(sb, "...");
graph_pad_horizontally(graph, sb);
- if (graph->num_parents >= 3)
- graph->state = GRAPH_PRE_COMMIT;
+ if (graph->num_parents >= 3 &&
+ graph->commit_index < (graph->num_columns - 1))
+ graph_update_state(graph, GRAPH_PRE_COMMIT);
else
- graph->state = GRAPH_COMMIT;
+ graph_update_state(graph, GRAPH_COMMIT);
}
static void graph_output_pre_commit_line(struct git_graph *graph,
if (col->commit == graph->commit) {
seen_this = 1;
strbuf_addf(sb, "| %*s", graph->expansion_row, "");
- } else if (seen_this) {
+ } else if (seen_this && (graph->expansion_row == 0)) {
+ /*
+ * This is the first line of the pre-commit output.
+ * If the previous commit was a merge commit and
+ * ended in the GRAPH_POST_MERGE state, all branch
+ * lines after graph->prev_commit_index were
+ * printed as "\" on the previous line. Continue
+ * to print them as "\" on this line. Otherwise,
+ * print the branch lines as "|".
+ */
+ if (graph->prev_state == GRAPH_POST_MERGE &&
+ graph->prev_commit_index < i)
+ strbuf_addstr(sb, "\\ ");
+ else
+ strbuf_addstr(sb, "| ");
+ } else if (seen_this && (graph->expansion_row > 0)) {
strbuf_addstr(sb, "\\ ");
} else {
strbuf_addstr(sb, "| ");
*/
graph->expansion_row++;
if (graph->expansion_row >= num_expansion_rows)
- graph->state = GRAPH_COMMIT;
+ graph_update_state(graph, GRAPH_COMMIT);
}
static void graph_output_commit_char(struct git_graph *graph, struct strbuf *sb)
seen_this = 1;
graph_output_commit_char(graph, sb);
- if (graph->num_parents < 2)
+ if (graph->num_parents < 3)
strbuf_addch(sb, ' ');
- else if (graph->num_parents == 2)
- strbuf_addstr(sb, " ");
else {
int num_dashes =
((graph->num_parents - 2) * 2) - 1;
strbuf_addch(sb, '-');
strbuf_addstr(sb, ". ");
}
- } else if (seen_this && (graph->num_parents > 1)) {
+ } else if (seen_this && (graph->num_parents > 2)) {
strbuf_addstr(sb, "\\ ");
+ } else if (seen_this && (graph->num_parents == 2)) {
+ /*
+ * This is a 2-way merge commit.
+ * There is no GRAPH_PRE_COMMIT stage for 2-way
+ * merges, so this is the first line of output
+ * for this commit. Check to see what the previous
+ * line of output was.
+ *
+ * If it was GRAPH_POST_MERGE, the branch line
+ * coming into this commit may have been '\',
+ * and not '|' or '/'. If so, output the branch
+ * line as '\' on this line, instead of '|'. This
+ * makes the output look nicer.
+ */
+ if (graph->prev_state == GRAPH_POST_MERGE &&
+ graph->prev_commit_index < i)
+ strbuf_addstr(sb, "\\ ");
+ else
+ strbuf_addstr(sb, "| ");
} else {
strbuf_addstr(sb, "| ");
}
* Update graph->state
*/
if (graph->num_parents > 1)
- graph->state = GRAPH_POST_MERGE;
+ graph_update_state(graph, GRAPH_POST_MERGE);
else if (graph_is_mapping_correct(graph))
- graph->state = GRAPH_PADDING;
+ graph_update_state(graph, GRAPH_PADDING);
else
- graph->state = GRAPH_COLLAPSING;
+ graph_update_state(graph, GRAPH_COLLAPSING);
}
void graph_output_post_merge_line(struct git_graph *graph, struct strbuf *sb)
strbuf_addch(sb, '|');
for (j = 0; j < graph->num_parents - 1; j++)
strbuf_addstr(sb, "\\ ");
- if (graph->num_parents == 2)
- strbuf_addch(sb, ' ');
- } else if (seen_this && (graph->num_parents > 2)) {
+ } else if (seen_this) {
strbuf_addstr(sb, "\\ ");
} else {
strbuf_addstr(sb, "| ");
* Update graph->state
*/
if (graph_is_mapping_correct(graph))
- graph->state = GRAPH_PADDING;
+ graph_update_state(graph, GRAPH_PADDING);
else
- graph->state = GRAPH_COLLAPSING;
+ graph_update_state(graph, GRAPH_COLLAPSING);
}
void graph_output_collapsing_line(struct git_graph *graph, struct strbuf *sb)
* Otherwise, we need to collapse some branch lines together.
*/
if (graph_is_mapping_correct(graph))
- graph->state = GRAPH_PADDING;
+ graph_update_state(graph, GRAPH_PADDING);
}
int graph_next_line(struct git_graph *graph, struct strbuf *sb)
}
graph_pad_horizontally(graph, sb);
+
+ /*
+ * Update graph->prev_state since we have output a padding line
+ */
+ graph->prev_state = GRAPH_PADDING;
}
int graph_is_commit_finished(struct git_graph const *graph)
signal(SIGINT, remove_locks_on_signal);
signal(SIGHUP, remove_locks_on_signal);
signal(SIGQUIT, remove_locks_on_signal);
+ signal(SIGTERM, remove_locks_on_signal);
/* Check whether the remote has server info files */
remote->can_update_info_refs = 0;
if (0 <= lk->fd) {
if (!lock_file_list) {
signal(SIGINT, remove_lock_file_on_signal);
+ signal(SIGHUP, remove_lock_file_on_signal);
+ signal(SIGTERM, remove_lock_file_on_signal);
+ signal(SIGQUIT, remove_lock_file_on_signal);
atexit(remove_lock_file);
}
lk->owner = getpid();
my $E = shift;
if ($E->value() == 1) {
# Key not found.
- return undef;
+ return;
} else {
throw $E;
}
=item hash_object ( TYPE, FILENAME )
-Compute the SHA1 object id of the given C<FILENAME> (or data waiting in
-C<FILEHANDLE>) considering it is of the C<TYPE> object type (C<blob>,
-C<commit>, C<tree>).
+Compute the SHA1 object id of the given C<FILENAME> considering it is
+of the C<TYPE> object type (C<blob>, C<commit>, C<tree>).
The method can be called without any instance or on a specified Git repository,
it makes zero difference.
if (ce_uptodate(ce))
return ce;
+ /*
+ * CE_VALID means the user promised us that the change to
+ * the work tree does not matter and told us not to worry.
+ */
+ if (!ignore_valid && (ce->ce_flags & CE_VALID)) {
+ ce_mark_uptodate(ce);
+ return ce;
+ }
+
if (lstat(ce->name, &st) < 0) {
if (err)
*err = errno;
check_config git-dir-bare.git true unset
'
+test_expect_success 'init --bare' '
+
+ (
+ unset GIT_DIR GIT_WORK_TREE GIT_CONFIG
+ mkdir git-init-bare.git &&
+ cd git-init-bare.git &&
+ git init --bare
+ ) &&
+ check_config git-init-bare.git true unset
+'
+
test_expect_success 'GIT_DIR non-bare' '
(
test "`cat .git/result`" = "editor not started"
'
+pwd=`pwd`
+cat > .git/FAKE_EDITOR << EOF
+#! /bin/sh
+# kill -TERM command added below.
+EOF
+
+test_expect_success 'a SIGTERM should break locks' '
+ echo >>negative &&
+ sh -c '\''
+ echo kill -TERM $$ >> .git/FAKE_EDITOR
+ GIT_EDITOR=.git/FAKE_EDITOR exec git commit -a'\'' && exit 1 # should fail
+ ! test -f .git/index.lock
+'
+
test_done
projects / git.git / commitdiff