Documentation: merge: add a section about fast-forward
Novices sometimes find the behavior of 'git merge' in the
fast-forward case surprising. Describe it thoroughly.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Novices sometimes find the behavior of 'git merge' in the
fast-forward case surprising. Describe it thoroughly.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Documentation: emphasize when git merge terminates early
A merge-based operation in git can fail in two ways: one that
stops before touching anything, or one that goes ahead and
results in conflicts.
As the 'git merge' manual explains:
| A merge is always between the current `HEAD` and one or more
| commits (usually, branch head or tag), and the index file must
| match the tree of `HEAD` commit (i.e. the contents of the last commit)
| when it starts out.
Unfortunately, the placement of this sentence makes it easy to
skip over, and its formulation leaves the important point, that
any other attempted merge will be gracefully aborted, unspoken.
So give this point its own section and expand upon it.
Probably this could be simplified somewhat: after all, a change
registered in the index is just a special kind of local
uncommited change, so the second added paragraph is only a
special case of the first. It seemed more helpful to be explicit
here.
Inspired by <http://gitster.livejournal.com/25801.html>.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
A merge-based operation in git can fail in two ways: one that
stops before touching anything, or one that goes ahead and
results in conflicts.
As the 'git merge' manual explains:
| A merge is always between the current `HEAD` and one or more
| commits (usually, branch head or tag), and the index file must
| match the tree of `HEAD` commit (i.e. the contents of the last commit)
| when it starts out.
Unfortunately, the placement of this sentence makes it easy to
skip over, and its formulation leaves the important point, that
any other attempted merge will be gracefully aborted, unspoken.
So give this point its own section and expand upon it.
Probably this could be simplified somewhat: after all, a change
registered in the index is just a special kind of local
uncommited change, so the second added paragraph is only a
special case of the first. It seemed more helpful to be explicit
here.
Inspired by <http://gitster.livejournal.com/25801.html>.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Documentation: merge: add an overview
The reader unfamiliar with the concepts of branching and merging
would have been completely lost. Try to help him with a diagram.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
The reader unfamiliar with the concepts of branching and merging
would have been completely lost. Try to help him with a diagram.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Documentation: merge: move merge strategy list to end
So the section layout changes as follows:
NAME
SYNOPSIS
DESCRIPTION
OPTIONS
-MERGE STRATEGIES
HOW MERGE WORKS
HOW CONFLICTS ARE PRESENTED
HOW TO RESOLVE CONFLICTS
EXAMPLES
+MERGE STRATEGIES
CONFIGURATION
SEE ALSO
AUTHOR
DOCUMENTATION
GIT
NOTES
The first-time user will care more about conflicts than about
strategies other than 'recursive'.
One of the examples uses -s ours, but I do not think this hinders
readability.
Suggested-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
So the section layout changes as follows:
NAME
SYNOPSIS
DESCRIPTION
OPTIONS
-MERGE STRATEGIES
HOW MERGE WORKS
HOW CONFLICTS ARE PRESENTED
HOW TO RESOLVE CONFLICTS
EXAMPLES
+MERGE STRATEGIES
CONFIGURATION
SEE ALSO
AUTHOR
DOCUMENTATION
GIT
NOTES
The first-time user will care more about conflicts than about
strategies other than 'recursive'.
One of the examples uses -s ours, but I do not think this hinders
readability.
Suggested-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Documentation: suggest `reset --merge` in How Merge Works section
The 'merge' manual suggests 'reset' to cancel a merge at the end
of the Merge Strategies list. It is more logical to explain this
right before explaining how merge conflicts work, so the daunted
reader can have a way out when he or she needs it most.
While at it, make the advice more dependable and self-contained
by providing the --merge option.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
The 'merge' manual suggests 'reset' to cancel a merge at the end
of the Merge Strategies list. It is more logical to explain this
right before explaining how merge conflicts work, so the daunted
reader can have a way out when he or she needs it most.
While at it, make the advice more dependable and self-contained
by providing the --merge option.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Documentation: merge: move configuration section to end
Configuration and environment variables belong to the back matter
of a manual page.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Configuration and environment variables belong to the back matter
of a manual page.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Documentation: emphasise 'git shortlog' in its synopsis
The accepted style in the SYNOPSIS section is for a command to be
'emphasised'. Do so for the git-shortlog(1) manpage.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
The accepted style in the SYNOPSIS section is for a command to be
'emphasised'. Do so for the git-shortlog(1) manpage.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Documentation: show-files is now called git-ls-files
Amazingly, a reference to 'show files' survived from the core command
documentation introduced in c64b9b8 (Reference documentation for the
core git commands., 2005-05-05)!
However, the tool is now called git-ls-files.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Amazingly, a reference to 'show files' survived from the core command
documentation introduced in c64b9b8 (Reference documentation for the
core git commands., 2005-05-05)!
However, the tool is now called git-ls-files.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Documentation: tiny git config manual tweaks
As a verb, 'setup' is spelled 'set up'. “diff commands such as
diff-files” scans better without a comma. Clarify that shallow
and deep are special non-boolean values for format.thread rather
than boolean values with some other name.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
As a verb, 'setup' is spelled 'set up'. “diff commands such as
diff-files” scans better without a comma. Clarify that shallow
and deep are special non-boolean values for format.thread rather
than boolean values with some other name.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Documentation: git gc packs refs by default now
In commit 56752391 (Make "git gc" pack all refs by default,
2007-05-24), 'git gc' was changed to run pack-refs by default
Versions before v1.5.1.2 cannot clone repos with packed refs over
http, and versions before v1.4.4 cannot handled packed refs at
all, but more recent git should have no problems. Try to make
this more clear in the git-config manual.
The analagous passage in git-gc.txt was updated already with
commit fe2128a (Change git-gc documentation to reflect
gc.packrefs implementation., 2008-01-09).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
In commit 56752391 (Make "git gc" pack all refs by default,
2007-05-24), 'git gc' was changed to run pack-refs by default
Versions before v1.5.1.2 cannot clone repos with packed refs over
http, and versions before v1.4.4 cannot handled packed refs at
all, but more recent git should have no problems. Try to make
this more clear in the git-config manual.
The analagous passage in git-gc.txt was updated already with
commit fe2128a (Change git-gc documentation to reflect
gc.packrefs implementation., 2008-01-09).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Documentation: spell 'git cmd' without dash throughout
The documentation was quite inconsistent when spelling 'git cmd' if it
only refers to the program, not to some specific invocation syntax:
both 'git-cmd' and 'git cmd' spellings exist.
The current trend goes towards dashless forms, and there is precedent
in 647ac70 (git-svn.txt: stop using dash-form of commands.,
2009-07-07) to actively eliminate the dashed variants.
Replace 'git-cmd' with 'git cmd' throughout, except where git-shell,
git-cvsserver, git-upload-pack, git-receive-pack, and
git-upload-archive are concerned, because those really live in the
$PATH.
The documentation was quite inconsistent when spelling 'git cmd' if it
only refers to the program, not to some specific invocation syntax:
both 'git-cmd' and 'git cmd' spellings exist.
The current trend goes towards dashless forms, and there is precedent
in 647ac70 (git-svn.txt: stop using dash-form of commands.,
2009-07-07) to actively eliminate the dashed variants.
Replace 'git-cmd' with 'git cmd' throughout, except where git-shell,
git-cvsserver, git-upload-pack, git-receive-pack, and
git-upload-archive are concerned, because those really live in the
$PATH.
Documentation: format full commands in typewriter font
Use `code snippet` style instead of 'emphasis' for `git cmd ...`
according to the following rules:
* The SYNOPSIS sections are left untouched.
* If the intent is that the user type the command exactly as given, it
is `code`.
If the user is only loosely referred to a command and/or option, it
remains 'emphasised'.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Use `code snippet` style instead of 'emphasis' for `git cmd ...`
according to the following rules:
* The SYNOPSIS sections are left untouched.
* If the intent is that the user type the command exactly as given, it
is `code`.
If the user is only loosely referred to a command and/or option, it
remains 'emphasised'.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Documentation: warn prominently against merging with dirty trees
We do this for both git-merge and git-pull, so as to hopefully alert
(over)users of git-pull to the issue.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
We do this for both git-merge and git-pull, so as to hopefully alert
(over)users of git-pull to the issue.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Documentation/git-merge: reword references to "remote" and "pull"
The git-merge manpage was written in terms of merging a "remote",
which is no longer the case: you merge local or remote-tracking
branches; pull is for actual remotes.
Adjust the manpage accordingly. We refer to the arguments as
"commits", and change instances of "remote" to "other" (where branches
are concerned) or "theirs" (where conflict sides are concerned).
Remove the single reference to "pulling".
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
The git-merge manpage was written in terms of merging a "remote",
which is no longer the case: you merge local or remote-tracking
branches; pull is for actual remotes.
Adjust the manpage accordingly. We refer to the arguments as
"commits", and change instances of "remote" to "other" (where branches
are concerned) or "theirs" (where conflict sides are concerned).
Remove the single reference to "pulling".
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Describe second batch for 1.7.0 in draft release notes
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'js/filter-branch-prime'
* js/filter-branch-prime:
filter-branch: remove an unnecessary use of 'git read-tree'
* js/filter-branch-prime:
filter-branch: remove an unnecessary use of 'git read-tree'
Merge branch 'sb/maint-octopus'
* sb/maint-octopus:
octopus: remove dead code
octopus: reenable fast-forward merges
octopus: make merge process simpler to follow
Conflicts:
git-merge-octopus.sh
* sb/maint-octopus:
octopus: remove dead code
octopus: reenable fast-forward merges
octopus: make merge process simpler to follow
Conflicts:
git-merge-octopus.sh
Merge branch 'mg/tag-d-show'
* mg/tag-d-show:
tag -d: print sha1 of deleted tag
* mg/tag-d-show:
tag -d: print sha1 of deleted tag
Merge branch 'so/cvsserver-update'
* so/cvsserver-update:
cvsserver: make the output of 'update' more compatible with cvs.
* so/cvsserver-update:
cvsserver: make the output of 'update' more compatible with cvs.
Merge branch 'bg/maint-add-all-doc'
* bg/maint-add-all-doc:
git-rm doc: Describe how to sync index & work tree
git-add/rm doc: Consistently back-quote
Documentation: 'git add -A' can remove files
* bg/maint-add-all-doc:
git-rm doc: Describe how to sync index & work tree
git-add/rm doc: Consistently back-quote
Documentation: 'git add -A' can remove files
git-rm doc: Describe how to sync index & work tree
Newcomers to git that want to remove from the index only the
files that have disappeared from the working tree will probably
look for a way to do that in the documentation for 'git rm'.
Therefore, describe how that can be done (even though it involves
other commands than 'git rm'). Based on a suggestion by Junio,
but re-arranged and rewritten to better fit into the style of
command reference.
While at it, change a single occurrence of "work tree" to "working
tree" for consistency.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Newcomers to git that want to remove from the index only the
files that have disappeared from the working tree will probably
look for a way to do that in the documentation for 'git rm'.
Therefore, describe how that can be done (even though it involves
other commands than 'git rm'). Based on a suggestion by Junio,
but re-arranged and rewritten to better fit into the style of
command reference.
While at it, change a single occurrence of "work tree" to "working
tree" for consistency.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'mv/commit-date'
* mv/commit-date:
Document date formats accepted by parse_date()
builtin-commit: add --date option
* mv/commit-date:
Document date formats accepted by parse_date()
builtin-commit: add --date option
Merge branch 'mo/bin-wrappers'
* mo/bin-wrappers:
INSTALL: document a simpler way to run uninstalled builds
run test suite without dashed git-commands in PATH
build dashless "bin-wrappers" directory similar to installed bindir
* mo/bin-wrappers:
INSTALL: document a simpler way to run uninstalled builds
run test suite without dashed git-commands in PATH
build dashless "bin-wrappers" directory similar to installed bindir
.gitattributes: detect 8-space indent in shell scripts
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile: make ppc/sha1ppc.o depend on GIT-CFLAGS
The %.o: %.S pattern rule should depend on GIT-CFLAGS to avoid
trouble when ALL_CFLAGS changes.
The pattern only applies to one file (ppc/sha1ppc.S) and that
file does not use any #ifdefs, so leaving the dependency out is
probably harmless. Nevertheless, it is safer to include the
dependency in case future code's behavior does depend on the
build flags.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The %.o: %.S pattern rule should depend on GIT-CFLAGS to avoid
trouble when ALL_CFLAGS changes.
The pattern only applies to one file (ppc/sha1ppc.S) and that
file does not use any #ifdefs, so leaving the dependency out is
probably harmless. Nevertheless, it is safer to include the
dependency in case future code's behavior does depend on the
build flags.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use warning function instead of fprintf(stderr, "Warning: ...").
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'
* maint:
stash: mention --patch in usage string.
* maint:
stash: mention --patch in usage string.
stash: mention --patch in usage string.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'
* maint:
branch: die explicitly why when calling "git branch [-a|-r] branchname".
fast-import: Document author/committer/tagger name is optional
SubmittingPatches: hints to know the status of a submitted patch.
* maint:
branch: die explicitly why when calling "git branch [-a|-r] branchname".
fast-import: Document author/committer/tagger name is optional
SubmittingPatches: hints to know the status of a submitted patch.
Merge branch 'maint-1.6.0' into maint
* maint-1.6.0:
branch: die explicitly why when calling "git branch [-a|-r] branchname".
* maint-1.6.0:
branch: die explicitly why when calling "git branch [-a|-r] branchname".
branch: die explicitly why when calling "git branch [-a|-r] branchname".
The -a and -r options used to be silently ignored in such a command.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The -a and -r options used to be silently ignored in such a command.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fast-import: Document author/committer/tagger name is optional
The fast-import parser does not validate that the author, committer
or tagger name component contains both a name and an email address.
Therefore the name component has always been optional. Correct the
documentation to match the implementation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fast-import parser does not validate that the author, committer
or tagger name component contains both a name and an email address.
Therefore the name component has always been optional. Correct the
documentation to match the implementation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SubmittingPatches: hints to know the status of a submitted patch.
"What happened to my patch" is pretty much a FAQ on the Git mailing list,
it deserves a few paragraphs in SubmittingPatches...
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"What happened to my patch" is pretty much a FAQ on the Git mailing list,
it deserves a few paragraphs in SubmittingPatches...
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cvsserver: make the output of 'update' more compatible with cvs.
Native cvs update outputs the string "cvs update: Updating <DIR>" for
every directory it processes (to stderr) unless -q or -Q is given on
comman-line. This is used, e.g., by emacs pcl-cvs to split files by
directory. This commit implements this feature in cvsserver.
Signed-off-by: Sergei Organov <osv@javad.com>
Acked-by: Martin Langhoff <martin.langhoff@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Native cvs update outputs the string "cvs update: Updating <DIR>" for
every directory it processes (to stderr) unless -q or -Q is given on
comman-line. This is used, e.g., by emacs pcl-cvs to split files by
directory. This commit implements this feature in cvsserver.
Signed-off-by: Sergei Organov <osv@javad.com>
Acked-by: Martin Langhoff <martin.langhoff@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bash completion: add space between branch name and status flags
Improve the readability of the bash prompt by adding a space between
the branch name and the status flags (dirty, stash, untracked).
While we are cleaning up this section of code, the two cases for
formatting the prompt are identical except for the format string,
so make them the same.
Suggested-by: Roman Fietze <roman.fietze@telemotive.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Improve the readability of the bash prompt by adding a space between
the branch name and the status flags (dirty, stash, untracked).
While we are cleaning up this section of code, the two cases for
formatting the prompt are identical except for the format string,
so make them the same.
Suggested-by: Roman Fietze <roman.fietze@telemotive.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add completion for git-svn mkdirs,reset,and gc
Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'
* maint:
textconv: stop leaking file descriptors
commit: --cleanup is a message option
git count-objects: handle packs bigger than 4G
t7102: make the test fail if one of its check fails
Documentation: always respect core.worktree if set
* maint:
textconv: stop leaking file descriptors
commit: --cleanup is a message option
git count-objects: handle packs bigger than 4G
t7102: make the test fail if one of its check fails
Documentation: always respect core.worktree if set
Merge branch 'maint-1.6.1' into maint
* maint-1.6.1:
textconv: stop leaking file descriptors
commit: --cleanup is a message option
git count-objects: handle packs bigger than 4G
t7102: make the test fail if one of its check fails
Conflicts:
builtin-commit.c
diff.c
* maint-1.6.1:
textconv: stop leaking file descriptors
commit: --cleanup is a message option
git count-objects: handle packs bigger than 4G
t7102: make the test fail if one of its check fails
Conflicts:
builtin-commit.c
diff.c
textconv: stop leaking file descriptors
We read the output from textconv helpers over a pipe, but we
never actually closed our end of the pipe after using it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We read the output from textconv helpers over a pipe, but we
never actually closed our end of the pipe after using it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint-1.6.0' into maint-1.6.1
* maint-1.6.0:
commit: --cleanup is a message option
t7102: make the test fail if one of its check fails
* maint-1.6.0:
commit: --cleanup is a message option
t7102: make the test fail if one of its check fails
commit: --cleanup is a message option
In the usage message for "git commit", the --cleanup option appeared
at the end, as one of the "contents options":
usage: git commit [options] [--] <filepattern>...
...
Commit message options
...
Commit contents options
...
--allow-empty ok to record an empty change
--cleanup <default> how to strip spaces and #comments from message
This is confusing, in part because it makes it ambiguous whether
--allow-empty, just above, refers to an empty diff or an empty message.
Move --cleanup into the 'message options' group. Also add a pair of
comments to prevent similar oversights in the future.
Signed-off-by: Greg Price <price@ksplice.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the usage message for "git commit", the --cleanup option appeared
at the end, as one of the "contents options":
usage: git commit [options] [--] <filepattern>...
...
Commit message options
...
Commit contents options
...
--allow-empty ok to record an empty change
--cleanup <default> how to strip spaces and #comments from message
This is confusing, in part because it makes it ambiguous whether
--allow-empty, just above, refers to an empty diff or an empty message.
Move --cleanup into the 'message options' group. Also add a pair of
comments to prevent similar oversights in the future.
Signed-off-by: Greg Price <price@ksplice.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git count-objects: handle packs bigger than 4G
Use off_t to count sizes of packs and objects to avoid overflow after
4Gb.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use off_t to count sizes of packs and objects to avoid overflow after
4Gb.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t7102: make the test fail if one of its check fails
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: always respect core.worktree if set
The value of core.worktree in a ".git/config" is honored even when it
differs from the directory that has the ".git" directory as its
subdirectory. This is likely to be a misconfiguration, so warn users
about it. Also, drop the part of the documentation that incorrectly
claimed that we ignore such a misconfigured value.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The value of core.worktree in a ".git/config" is honored even when it
differs from the directory that has the ".git" directory as its
subdirectory. This is likely to be a misconfiguration, so warn users
about it. Also, drop the part of the documentation that incorrectly
claimed that we ignore such a misconfigured value.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jk/1.7.0-status'
* jk/1.7.0-status:
status/commit: do not suggest "reset HEAD <path>" while merging
commit/status: "git add <path>" is not necessarily how to resolve
commit/status: check $GIT_DIR/MERGE_HEAD only once
t7508-status: test all modes with color
t7508-status: status --porcelain ignores relative paths setting
status: reduce duplicated setup code
status: disable color for porcelain format
status -s: obey color.status
builtin-commit: refactor short-status code into wt-status.c
t7508-status.sh: Add tests for status -s
status -s: respect the status.relativePaths option
docs: note that status configuration affects only long format
commit: support alternate status formats
status: add --porcelain output format
status: refactor format option parsing
status: refactor short-mode printing to its own function
status: typo fix in usage
git status: not "commit --dry-run" anymore
git stat -s: short status output
git stat: the beginning of "status that is not a dry-run of commit"
Conflicts:
t/t4034-diff-words.sh
wt-status.c
* jk/1.7.0-status:
status/commit: do not suggest "reset HEAD <path>" while merging
commit/status: "git add <path>" is not necessarily how to resolve
commit/status: check $GIT_DIR/MERGE_HEAD only once
t7508-status: test all modes with color
t7508-status: status --porcelain ignores relative paths setting
status: reduce duplicated setup code
status: disable color for porcelain format
status -s: obey color.status
builtin-commit: refactor short-status code into wt-status.c
t7508-status.sh: Add tests for status -s
status -s: respect the status.relativePaths option
docs: note that status configuration affects only long format
commit: support alternate status formats
status: add --porcelain output format
status: refactor format option parsing
status: refactor short-mode printing to its own function
status: typo fix in usage
git status: not "commit --dry-run" anymore
git stat -s: short status output
git stat: the beginning of "status that is not a dry-run of commit"
Conflicts:
t/t4034-diff-words.sh
wt-status.c
Merge branch 'maint'
* maint:
read_index(): fix reading extension size on BE 64-bit archs
* maint:
read_index(): fix reading extension size on BE 64-bit archs
Merge branch 'nf/maint-fix-index-ext-len-on-be64' into maint
* nf/maint-fix-index-ext-len-on-be64:
read_index(): fix reading extension size on BE 64-bit archs
* nf/maint-fix-index-ext-len-on-be64:
read_index(): fix reading extension size on BE 64-bit archs
read_index(): fix reading extension size on BE 64-bit archs
On big endian platforms with 8-byte unsigned long, the code reads the
size of the index extension section (which is a 4-byte network byte
order integer) incorrectly.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On big endian platforms with 8-byte unsigned long, the code reads the
size of the index extension section (which is a 4-byte network byte
order integer) incorrectly.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'
* maint:
Makefile: FreeBSD (both 7 and 8) needs OLD_ICONV
Start 1.6.6.X maintenance track
Add git-http-backend to command-list.
t4019 "grep" portability fix
t1200: work around a bug in some implementations of "find"
Conflicts:
RelNotes
* maint:
Makefile: FreeBSD (both 7 and 8) needs OLD_ICONV
Start 1.6.6.X maintenance track
Add git-http-backend to command-list.
t4019 "grep" portability fix
t1200: work around a bug in some implementations of "find"
Conflicts:
RelNotes
Makefile: FreeBSD (both 7 and 8) needs OLD_ICONV
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Start 1.6.6.X maintenance track
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jc/maint-obsd46' into maint
* jc/maint-obsd46:
t4019 "grep" portability fix
t1200: work around a bug in some implementations of "find"
* jc/maint-obsd46:
t4019 "grep" portability fix
t1200: work around a bug in some implementations of "find"
Add git-http-backend to command-list.
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Kick off 1.7.0 cycle
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'gb/1.7.0-diff-whitespace-only-output'
* gb/1.7.0-diff-whitespace-only-output:
No diff -b/-w output for all-whitespace changes
* gb/1.7.0-diff-whitespace-only-output:
No diff -b/-w output for all-whitespace changes
Merge branch 'jc/1.7.0-diff-whitespace-only-status'
* jc/1.7.0-diff-whitespace-only-status:
diff.c: fix typoes in comments
Make test case number unique
diff: Rename QUIET internal option to QUICK
diff: change semantics of "ignore whitespace" options
Conflicts:
diff.h
* jc/1.7.0-diff-whitespace-only-status:
diff.c: fix typoes in comments
Make test case number unique
diff: Rename QUIET internal option to QUICK
diff: change semantics of "ignore whitespace" options
Conflicts:
diff.h
Merge branch 'jc/1.7.0-push-safety'
* jc/1.7.0-push-safety:
Refuse deleting the current branch via push
Refuse updating the current branch in a non-bare repository via push
* jc/1.7.0-push-safety:
Refuse deleting the current branch via push
Refuse updating the current branch in a non-bare repository via push
Merge branch 'jc/1.7.0-send-email-no-thread-default'
* jc/1.7.0-send-email-no-thread-default:
send-email: make --no-chain-reply-to the default
Conflicts:
git-send-email.perl
* jc/1.7.0-send-email-no-thread-default:
send-email: make --no-chain-reply-to the default
Conflicts:
git-send-email.perl
Merge branch 'sr/vcs-helper'
* sr/vcs-helper:
tests: handle NO_PYTHON setting
builtin-push: don't access freed transport->url
Add Python support library for remote helpers
Basic build infrastructure for Python scripts
Allow helpers to report in "list" command that the ref is unchanged
Fix various memory leaks in transport-helper.c
Allow helper to map private ref names into normal names
Add support for "import" helper command
Allow specifying the remote helper in the url
Add a config option for remotes to specify a foreign vcs
Allow fetch to modify refs
Use a function to determine whether a remote is valid
Allow programs to not depend on remotes having urls
Fix memory leak in helper method for disconnect
Conflicts:
Documentation/git-remote-helpers.txt
Makefile
builtin-ls-remote.c
builtin-push.c
transport-helper.c
* sr/vcs-helper:
tests: handle NO_PYTHON setting
builtin-push: don't access freed transport->url
Add Python support library for remote helpers
Basic build infrastructure for Python scripts
Allow helpers to report in "list" command that the ref is unchanged
Fix various memory leaks in transport-helper.c
Allow helper to map private ref names into normal names
Add support for "import" helper command
Allow specifying the remote helper in the url
Add a config option for remotes to specify a foreign vcs
Allow fetch to modify refs
Use a function to determine whether a remote is valid
Allow programs to not depend on remotes having urls
Fix memory leak in helper method for disconnect
Conflicts:
Documentation/git-remote-helpers.txt
Makefile
builtin-ls-remote.c
builtin-push.c
transport-helper.c
t4019 "grep" portability fix
Input to "grep" is supposed to be "text", but we deliberately feed output
from "git diff --color" to sift it into two sets of lines (ones with
errors, the other without). Some implementations of "grep" only report
matches with the exit status, without showing the matched lines in their
output (e.g. OpenBSD 4.6, which says "Binary file .. matches").
Fortunately, "grep -a" is often a way to force the command to treat its
input as text.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Input to "grep" is supposed to be "text", but we deliberately feed output
from "git diff --color" to sift it into two sets of lines (ones with
errors, the other without). Some implementations of "grep" only report
matches with the exit status, without showing the matched lines in their
output (e.g. OpenBSD 4.6, which says "Binary file .. matches").
Fortunately, "grep -a" is often a way to force the command to treat its
input as text.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t1200: work around a bug in some implementations of "find"
"find path ..." command should exit with zero status only when all path
operands were traversed successfully. When a non-existent path is given,
however, some implementations of "find" (e.g. OpenBSD 4.6) exit with zero
status and break the last test in t1200.
Rewrite the test to check that there is no regular files in the objects
fan-out directories to work around this bug; it is closer to what we are
testing anyway.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"find path ..." command should exit with zero status only when all path
operands were traversed successfully. When a non-existent path is given,
however, some implementations of "find" (e.g. OpenBSD 4.6) exit with zero
status and break the last test in t1200.
Rewrite the test to check that there is no regular files in the objects
fan-out directories to work around this bug; it is closer to what we are
testing anyway.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git 1.6.6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git svn: add test for a git svn gc followed by a git svn mkdirs
git svn gc will compress the unhandled.log files that git svn mkdirs reads,
causing git svn mkdirs to skip directory creation.
[ew: trivial whitespace cleanups]
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>
git svn gc will compress the unhandled.log files that git svn mkdirs reads,
causing git svn mkdirs to skip directory creation.
[ew: trivial whitespace cleanups]
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>
git svn: branch/tag commands detect username in URLs
svn+ssh:// repositories often have userinfo embedded in the URL
which were stripped out of the "git-svn-id:" trailers. Since
the SVN::Client::copy function takes userinfo into account when
matching URLs for SVN repositories, we need to retrieve the full
URL with embedded userinfo in it to avoid mismatched URLs.
Tested-by: Florian Köberle <florian@fkoeberle.de>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
svn+ssh:// repositories often have userinfo embedded in the URL
which were stripped out of the "git-svn-id:" trailers. Since
the SVN::Client::copy function takes userinfo into account when
matching URLs for SVN repositories, we need to retrieve the full
URL with embedded userinfo in it to avoid mismatched URLs.
Tested-by: Florian Köberle <florian@fkoeberle.de>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Merge branch 'maint'
* maint:
Prevent git blame from segfaulting on a missing author name
* maint:
Prevent git blame from segfaulting on a missing author name
git svn: lookup new parents correctly from svn:mergeinfo
This appears to be a trivial case where array indices were being
passed to git rev-list, instead of the contents stored in the
array itself.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This appears to be a trivial case where array indices were being
passed to git rev-list, instead of the contents stored in the
array itself.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Prevent git blame from segfaulting on a missing author name
The human-readable author and committer name can be missing from
commits imported from foreign SCM interfaces. Make sure we parse
the "author" and "committer" line a bit more leniently and avoid
segfaulting by assuming the name always exists.
Signed-off-by: David Reiss <dreiss@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The human-readable author and committer name can be missing from
commits imported from foreign SCM interfaces. Make sure we parse
the "author" and "committer" line a bit more leniently and avoid
segfaulting by assuming the name always exists.
Signed-off-by: David Reiss <dreiss@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: Remove obsolete MAXPARENT check
Change git-svn not to impose a limit of 16 parents on a merge.
This limit in git-svn artificially prevents cloning svn repositories
that contain commits with more than 16 merge parents.
The limit was removed from builtin-commit-tree.c for git v1.6.0 in commit
ef98c5cafb3e799b1568bb843fcd45920dc62f16, so there is no need to check for it
it in git-svn.
Signed-off-by: Andrew Myrick <amyrick@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Change git-svn not to impose a limit of 16 parents on a merge.
This limit in git-svn artificially prevents cloning svn repositories
that contain commits with more than 16 merge parents.
The limit was removed from builtin-commit-tree.c for git v1.6.0 in commit
ef98c5cafb3e799b1568bb843fcd45920dc62f16, so there is no need to check for it
it in git-svn.
Signed-off-by: Andrew Myrick <amyrick@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn: detect cherry-picks correctly.
The old function was incorrect; in some instances it marks a cherry picked
range as a merged branch (because of an incorrect assumption that
'rev-list COMMIT --not RANGE' would work). This is replaced with a
function which should detect them correctly, memoized to limit the expense
of dealing with branches with many cherry picks to one 'merge-base' call
per merge, per branch which used cherry picking.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
The old function was incorrect; in some instances it marks a cherry picked
range as a merged branch (because of an incorrect assumption that
'rev-list COMMIT --not RANGE' would work). This is replaced with a
function which should detect them correctly, memoized to limit the expense
of dealing with branches with many cherry picks to one 'merge-base' call
per merge, per branch which used cherry picking.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn: exclude already merged tips using one rev-list call
The old function would have to check all mentioned merge tips, every time
that the mergeinfo ticket changed. This involved 1-2 rev-list operation
for each listed mergeinfo line. If there are a lot of feature branches
being merged into a trunk, this makes for a very expensive operation for
detecting the new parents on every merge.
This new version first uses a single 'rev-list' to figure out which commit
ranges are already reachable from the parents. This is used to eliminate
the already merged branches from the list.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
The old function would have to check all mentioned merge tips, every time
that the mergeinfo ticket changed. This involved 1-2 rev-list operation
for each listed mergeinfo line. If there are a lot of feature branches
being merged into a trunk, this makes for a very expensive operation for
detecting the new parents on every merge.
This new version first uses a single 'rev-list' to figure out which commit
ranges are already reachable from the parents. This is used to eliminate
the already merged branches from the list.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn: fix some mistakes with interpreting SVN mergeinfo commit ranges
SVN's list of commit ranges in mergeinfo tickets is inclusive, whereas
git commit ranges are exclusive on the left hand side. Also, the end
points of the commit ranges may not exist; they simply delineate
ranges of commits which may or may not exist. Fix these two mistakes.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
SVN's list of commit ranges in mergeinfo tickets is inclusive, whereas
git commit ranges are exclusive on the left hand side. Also, the end
points of the commit ranges may not exist; they simply delineate
ranges of commits which may or may not exist. Fix these two mistakes.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn: memoize conversion of SVN merge ticket info to git commit ranges
Each time the svn mergeinfo ticket changes, we look it up in the rev_map;
when there are a lot of merged branches, this will result in many repeated
lookups of the same information for subsequent commits. Arrange the slow
part of the function so that it may be memoized, and memoize it. The more
expensive revision walking operation can be memoized separately.
[ew: changed "next" to "return" for function exit]
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Each time the svn mergeinfo ticket changes, we look it up in the rev_map;
when there are a lot of merged branches, this will result in many repeated
lookups of the same information for subsequent commits. Arrange the slow
part of the function so that it may be memoized, and memoize it. The more
expensive revision walking operation can be memoized separately.
[ew: changed "next" to "return" for function exit]
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn: expand the svn mergeinfo test suite, highlighting some failures
As shown, git-svn has some problems; not all svn merges are correctly
detected, and cherry picks may incorrectly be detected as real merges.
These test cases will be marked as _success once the relevant fixes are in.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
As shown, git-svn has some problems; not all svn merges are correctly
detected, and cherry picks may incorrectly be detected as real merges.
These test cases will be marked as _success once the relevant fixes are in.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
update release notes for git svn in 1.6.6
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git svn: fix --revision when fetching deleted paths
When using the -r/--revision argument to fetch deleted history,
calling SVN::Ra::get_log() from an SVN::Ra object initialized
to track the deleted URL will fail.
This regression was introduced in:
commit 4aacaeb3dc82bb6479e70e120053dc27a399460e
"fix shallow clone when upstream revision is too new"
We now ignore errors from SVN::Ra::get_log() here because using
--revision will always override the value of $head here if
(and only if) we're tracking deleted directories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
When using the -r/--revision argument to fetch deleted history,
calling SVN::Ra::get_log() from an SVN::Ra object initialized
to track the deleted URL will fail.
This regression was introduced in:
commit 4aacaeb3dc82bb6479e70e120053dc27a399460e
"fix shallow clone when upstream revision is too new"
We now ignore errors from SVN::Ra::get_log() here because using
--revision will always override the value of $head here if
(and only if) we're tracking deleted directories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Git 1.6.6-rc4
Hopefully the last rc before the final one.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Hopefully the last rc before the final one.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'
* maint:
rebase -i: abort cleanly if the editor fails to launch
technical-docs: document hash API
api-strbuf.txt: fix typos and document launch_editor()
* maint:
rebase -i: abort cleanly if the editor fails to launch
technical-docs: document hash API
api-strbuf.txt: fix typos and document launch_editor()
rebase -i: abort cleanly if the editor fails to launch
If the user's configured editor is emacsclient, the editor
will fail to launch if emacs is not running and the git
command that tried to lanuch the editor will abort. For most
commands, all you have to do is to start emacs and repeat
the command.
The "git rebase -i" command, however, aborts without cleaning
the "$GIT_DIR/rebase-merge" directory if it fails to launch the
editor, so you'll need to do "git rebase --abort" before
repeating the rebase command.
Change "git rebase -i" to terminate using "die_abort" (instead of
with "die") if the initial launch of the editor fails.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the user's configured editor is emacsclient, the editor
will fail to launch if emacs is not running and the git
command that tried to lanuch the editor will abort. For most
commands, all you have to do is to start emacs and repeat
the command.
The "git rebase -i" command, however, aborts without cleaning
the "$GIT_DIR/rebase-merge" directory if it fails to launch the
editor, so you'll need to do "git rebase --abort" before
repeating the rebase command.
Change "git rebase -i" to terminate using "die_abort" (instead of
with "die") if the initial launch of the editor fails.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t9146: use 'svn_cmd' wrapper
Using 'svn' directly may not work for all users.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Using 'svn' directly may not work for all users.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git svn: make empty directory creation gc-aware
The "git svn gc" command creates and appends to unhandled.log.gz
files which should be parsed before the uncompressed
unhandled.log files.
Reported-by: Robert Zeh
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The "git svn gc" command creates and appends to unhandled.log.gz
files which should be parsed before the uncompressed
unhandled.log files.
Reported-by: Robert Zeh
Signed-off-by: Eric Wong <normalperson@yhbt.net>
technical-docs: document hash API
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
api-strbuf.txt: fix typos and document launch_editor()
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git 1.6.6-rc3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint' to sync with 1.6.5.7
* maint:
Git 1.6.5.7
worktree: don't segfault with an absolute pathspec without a work tree
ignore unknown color configuration
help.autocorrect: do not run a command if the command given is junk
Illustrate "filter" attribute with an example
* maint:
Git 1.6.5.7
worktree: don't segfault with an absolute pathspec without a work tree
ignore unknown color configuration
help.autocorrect: do not run a command if the command given is junk
Illustrate "filter" attribute with an example
Git 1.6.5.7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
worktree: don't segfault with an absolute pathspec without a work tree
If a command is run with an absolute path as a pathspec inside a bare
repository, e.g. "rev-list HEAD -- /home", the code tried to run strlen()
on NULL, which is the result of get_git_work_tree(), and segfaulted. It
should just fail instead.
Currently the function returns NULL even inside .git/ in a repository
with a work tree, but that is a separate issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a command is run with an absolute path as a pathspec inside a bare
repository, e.g. "rev-list HEAD -- /home", the code tried to run strlen()
on NULL, which is the result of get_git_work_tree(), and segfaulted. It
should just fail instead.
Currently the function returns NULL even inside .git/ in a repository
with a work tree, but that is a separate issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ignore unknown color configuration
When parsing the config file, if there is a value that is
syntactically correct but unused, we generally ignore it.
This lets non-core porcelains store arbitrary information in
the config file, and it means that configuration files can
be shared between new and old versions of git (the old
versions might simply ignore certain configuration).
The one exception to this is color configuration; if we
encounter a color.{diff,branch,status}.$slot variable, we
die if it is not one of the recognized slots (presumably as
a safety valve for user misconfiguration). This behavior
has existed since 801235c (diff --color: use
$GIT_DIR/config, 2006-06-24), but hasn't yet caused a
problem. No porcelain has wanted to store extra colors, and
we once a color area (like color.diff) has been introduced,
we've never changed the set of color slots.
However, that changed recently with the addition of
color.diff.func. Now a user with color.diff.func in their
config can no longer freely switch between v1.6.6 and older
versions; the old versions will complain about the existence
of the variable.
This patch loosens the check to match the rest of
git-config; unknown color slots are simply ignored. This
doesn't fix this particular problem, as the older version
(without this patch) is the problem, but it at least
prevents it from happening again in the future.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When parsing the config file, if there is a value that is
syntactically correct but unused, we generally ignore it.
This lets non-core porcelains store arbitrary information in
the config file, and it means that configuration files can
be shared between new and old versions of git (the old
versions might simply ignore certain configuration).
The one exception to this is color configuration; if we
encounter a color.{diff,branch,status}.$slot variable, we
die if it is not one of the recognized slots (presumably as
a safety valve for user misconfiguration). This behavior
has existed since 801235c (diff --color: use
$GIT_DIR/config, 2006-06-24), but hasn't yet caused a
problem. No porcelain has wanted to store extra colors, and
we once a color area (like color.diff) has been introduced,
we've never changed the set of color slots.
However, that changed recently with the addition of
color.diff.func. Now a user with color.diff.func in their
config can no longer freely switch between v1.6.6 and older
versions; the old versions will complain about the existence
of the variable.
This patch loosens the check to match the rest of
git-config; unknown color slots are simply ignored. This
doesn't fix this particular problem, as the older version
(without this patch) is the problem, but it at least
prevents it from happening again in the future.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
help.autocorrect: do not run a command if the command given is junk
If a given command is not found, then help.c tries to guess which one the
user could have meant. If help.autocorrect is 0 or unset, then a list of
suggestions is given as long as the dissimilarity between the given command
and the candidates is not excessively high. But if help.autocorrect was
non-zero (i.e., a delay after which the command is run automatically), the
latter restriction on dissimilarity was not obeyed.
In my case, this happened:
$ git ..daab02
WARNING: You called a Git command named '..daab02', which does not exist.
Continuing under the assumption that you meant 'read-tree'
in 4.0 seconds automatically...
The patch reuses the similarity limit that is also applied when the list of
suggested commands is printed.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a given command is not found, then help.c tries to guess which one the
user could have meant. If help.autocorrect is 0 or unset, then a list of
suggestions is given as long as the dissimilarity between the given command
and the candidates is not excessively high. But if help.autocorrect was
non-zero (i.e., a delay after which the command is run automatically), the
latter restriction on dissimilarity was not obeyed.
In my case, this happened:
$ git ..daab02
WARNING: You called a Git command named '..daab02', which does not exist.
Continuing under the assumption that you meant 'read-tree'
in 4.0 seconds automatically...
The patch reuses the similarity limit that is also applied when the list of
suggested commands is printed.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
filter-branch: remove an unnecessary use of 'git read-tree'
The intent of this particular call to 'git read-tree' was to fill an
index. But in fact, it only allocated an empty index. Later in the
program, the index is filled anyway by calling read-tree with specific
commits, and considering that elsewhere the index is even removed (i.e.,
it is not relied upon that the index file exists), this first call of
read-tree is completely redundant.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The intent of this particular call to 'git read-tree' was to fill an
index. But in fact, it only allocated an empty index. Later in the
program, the index is filled anyway by calling read-tree with specific
commits, and considering that elsewhere the index is even removed (i.e.,
it is not relied upon that the index file exists), this first call of
read-tree is completely redundant.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Illustrate "filter" attribute with an example
The example was taken from aa4ed402c9721170fde2e9e43c3825562070e65e
(Add 'filter' attribute and external filter driver definition).
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The example was taken from aa4ed402c9721170fde2e9e43c3825562070e65e
(Add 'filter' attribute and external filter driver definition).
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
octopus: remove dead code
MSG, PARENT, and CNT are never used, just assigned to.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
MSG, PARENT, and CNT are never used, just assigned to.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
octopus: reenable fast-forward merges
The fast-forward logic is never being triggered because $common and
$MRC are never equivalent. $common is initialized to a commit id by
merge-base and MRC is initialized to HEAD. Fix this by initializing
$MRC to the commit id for HEAD so that its possible for $MRC and
$common to be equal.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fast-forward logic is never being triggered because $common and
$MRC are never equivalent. $common is initialized to a commit id by
merge-base and MRC is initialized to HEAD. Fix this by initializing
$MRC to the commit id for HEAD so that its possible for $MRC and
$common to be equal.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
octopus: make merge process simpler to follow
Its not very easy to understand what heads are being merged given
the current output of an octopus merge. Fix this by replacing the
sha1 with the (usually) better description in GITHEAD_<SHA1>.
Suggested-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Its not very easy to understand what heads are being merged given
the current output of an octopus merge. Fix this by replacing the
sha1 with the (usually) better description in GITHEAD_<SHA1>.
Suggested-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bash: Support new 'git fetch' options
Support the new options --all, --prune, and --dry-run for
'git fetch'.
As the --multiple option was primarily introduced to enable
'git remote update' to be re-implemented in terms of 'git fetch'
(16679e37) and is not likely to be used much from the command
line, it does not seems worthwhile to complicate the code
(to support completion of multiple remotes) to handle it.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support the new options --all, --prune, and --dry-run for
'git fetch'.
As the --multiple option was primarily introduced to enable
'git remote update' to be re-implemented in terms of 'git fetch'
(16679e37) and is not likely to be used much from the command
line, it does not seems worthwhile to complicate the code
(to support completion of multiple remotes) to handle it.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
status/commit: do not suggest "reset HEAD <path>" while merging
Suggesting "'reset HEAD <path>' to unstage" is dead wrong if we are about
to record a merge commit. For either an unmerged path (i.e. with
unresolved conflicts), or an updated path, it would result in discarding
what the other branch did.
Note that we do not do anything special in a case where we are amending a
merge. The user is making an evil merge starting from an already
committed merge, and running "reset HEAD <path>" is the right way to get
rid of the local edit that has been added to the index.
Once "reset --unresolve <path>" becomes available, we might want to
suggest it for a merged path that has unresolve information, but until
then, just remove the incorrect advice.
We might also want to suggest "checkout --conflict <path>" to revert the
file in the work tree to the state of failed automerge for an unmerged
path, but we never did that, and this commit does not change that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Suggesting "'reset HEAD <path>' to unstage" is dead wrong if we are about
to record a merge commit. For either an unmerged path (i.e. with
unresolved conflicts), or an updated path, it would result in discarding
what the other branch did.
Note that we do not do anything special in a case where we are amending a
merge. The user is making an evil merge starting from an already
committed merge, and running "reset HEAD <path>" is the right way to get
rid of the local edit that has been added to the index.
Once "reset --unresolve <path>" becomes available, we might want to
suggest it for a merged path that has unresolve information, but until
then, just remove the incorrect advice.
We might also want to suggest "checkout --conflict <path>" to revert the
file in the work tree to the state of failed automerge for an unmerged
path, but we never did that, and this commit does not change that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit/status: "git add <path>" is not necessarily how to resolve
When the desired resolution is to remove the path, "git rm <path>" is the
command the user needs to use. Just like in "Changed but not updated"
section, suggest to use "git add/rm" as appropriate.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the desired resolution is to remove the path, "git rm <path>" is the
command the user needs to use. Just like in "Changed but not updated"
section, suggest to use "git add/rm" as appropriate.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit/status: check $GIT_DIR/MERGE_HEAD only once
The code checked for the MERGE_HEAD file to see if we were about
to commit a merge twice in the codepath; also one of them used a
variable merge_head_sha1[] which was set but was never used.
Just check it once, but do so also in "git status", too, as
we will be using this for status generation in the next patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code checked for the MERGE_HEAD file to see if we were about
to commit a merge twice in the codepath; also one of them used a
variable merge_head_sha1[] which was set but was never used.
Just check it once, but do so also in "git status", too, as
we will be using this for status generation in the next patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tag -d: print sha1 of deleted tag
Print the sha1 of the deleted tag (in addition to the tag name) so that
one can easily recreate a mistakenly deleted tag:
git tag -d tagname
Deleted tag 'tagname' (was DEADBEEF)
git tag 'tagname' DEADBEEF
We output the previous ref also in the case of forcefully overwriting
tags.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Suggested-by: Jari Aalto <jari.aalto@cante.net>
Helped-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Helped-by: Jeff King <peff@peff.net>
Helped-by: Zoltán Füzesi <zfuzesi@eaglet.hu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Print the sha1 of the deleted tag (in addition to the tag name) so that
one can easily recreate a mistakenly deleted tag:
git tag -d tagname
Deleted tag 'tagname' (was DEADBEEF)
git tag 'tagname' DEADBEEF
We output the previous ref also in the case of forcefully overwriting
tags.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Suggested-by: Jari Aalto <jari.aalto@cante.net>
Helped-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Helped-by: Jeff King <peff@peff.net>
Helped-by: Zoltán Füzesi <zfuzesi@eaglet.hu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update Release Notes for 1.6.6 to remove old bugfixes
These three have already been backported to 1.6.5.5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These three have already been backported to 1.6.5.5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with 1.6.5.6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>