Suppose you have changes in new1 to the original lines 10-20,
and changes in new2 to the original lines 15-25, then the
changes to 10-25 conflict. But it is possible that the next
changes in new1 still overlap with this change to new2.
So, in the next iteration we have to look at the same change
to new2 again.
The old code tried to be a bit too clever. The new code is
shorter and more to the point: do not fiddle with the ranges
at all.
Also, xdl_append_merge() tries harder to combine conflicts.
This is necessary, because with the above simplification,
some conflicts would not be recognized as conflicts otherwise:
In the above scenario, it is possible that there is no other
change to new1. Absent the combine logic, the change in new2
would be recorded _again_, but as a non-conflict.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
make 'git add' a first class user friendly interface to the index
This brings the power of the index up front using a proper mental model
without talking about the index at all. See for example how all the
technical discussion has been evacuated from the git-add man page.
Any content to be committed must be added together. Whether that
content comes from new files or modified files doesn't matter. You
just need to "add" it, either with git-add, or by providing
git-commit with -a (for already known files only of course).
No need for a separate command to distinguish new vs modified files
please. That would only screw the mental model everybody should have
when using GIT.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Document git diff options -b / --ignore-space-change and
-w / --ignore-all-space, introduced by Johannes Schindelin
in commit 0d21efa5, "Teach diff about -b and -w flags".
The description of options is taken from GNU diff man page and
GNU Diffutils info documentation.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
unpack-trees: make sure "df_conflict_entry.name" is NUL terminated.
The structure that ends with a flexible array member (or 0
length array with older GCC) "char name[FLEX_ARRAY]" is
allocated on the stack and we use it after clearing its entire
size with memset. That does not guarantee that "name" is
properly NUL terminated as we intended on platforms with more
forgiving structure alignment requirements.
git-fetch: ignore dereferenced tags in expand_refs_wildcard
There was a little bug in the brace expansion which should remove
the ^{} from the tagname. It used ${name#'^{}'} instead of $(name%'^{}'},
the difference is that '#' will remove the given pattern only from the
beginning of a string and '%' only from the end of a string.
Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-clone: Rename --use-immingled-remote option to --no-separate-remote
With making --use-separate-remote default when creating non-bare
clone, there was need for the flag which would turn off this behavior.
It was called --use-immingled-remote.
Immingle means to blend, to combine into one, to intermingle, but it
is a bit obscure word. I think it would be better to use simply
--no-separate-remote as the opposite to --use-separate-remote
option to git clone.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Linus recommended this, otherwise any renames cause the
diffstat output to be ridiculous in some circumstances.
Because the corresponding "git-pull" done when the requestee
actually makes pull shows the stat with rename detection
enabled, it makes sense to match what the request message
includes to that output, to make the result easier to verify.
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-mv: search more precisely for source directory in index
A move of a directory should find the entries in the index by
searching for the name _including_ the slash. Otherwise, the
directory can be shadowed by a file when it matches the prefix
and is lexicographically smaller, e.g. "ab.c" shadows "ab/".
Noticed by Sergey Vlasov.
[jc: added Sergey's original reproduction recipe as a test case
at the end of t7001.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
If one side's block (of changed lines) ends later than the other
side's block, the former should be tested against the next block
of the other side, not vice versa.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn: avoid fetching files twice in the same revision
SVN is not entirely consistent in returning log information and
sometimes returns file information when adding subdirectories,
and sometimes it does not (only returning information about the
directory that was added). This caused git-svn to occasionally
add a file to the list of files to be fetched twice. Now we
change the data structure to be hash to avoid repeated fetches.
As of now (in master), this only affects repositories fetched
without deltas enabled (file://, and when manually overriden
with GIT_SVN_DELTA_FETCH=0); so this bug mainly affects users of
1.4.4.1 and maint.
Thanks to Florian Weimer for reporting this bug.
[jc: backported for maint]
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
The fact that git has previously used symbolic links for representing
symbolic refs doesn't seem relevant to the current function of
git-symbolic-ref. This patch makes less of a big deal about the
symbolic link history and instead focuses on what git does now.
Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-diff: Introduce --index and deprecate --cached.
'git diff --cached' still works, but its use is discouraged
in the documentation. 'git diff --index' does the same thing
and is consistent with how 'git apply --index' works.
Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this patch "git commit file.c file2.c" produces the not
so stellar output:
error: pathspec 'file.c' did not match any.
error: pathspec 'file2.c' did not match any.
With this patch, the output is changed to:
error: pathspec 'file.c' did not match any file(s) known to git.
error: pathspec 'file2.c' did not match any file(s) known to git.
Did you forget to 'git add'?
Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
* branch 'maint':
Document git-repo-config --bool/--int options.
tutorial: talk about user.name early and don't start with commit -a
git-blame: fix rev parameter handling.
tutorial: talk about user.name early and don't start with commit -a
Introducing yourself to git early would be a good idea; otherwise
the user may not find the mistake until much later when "git log"
is learned.
Teaching "commit -a" without saying that it is a shortcut for
listing the paths to commit leaves the user puzzled. Teach the
form with explicit paths first.
We lacked "--" termination in the underlying init_revisions() call
which made it impossible to specify a revision that happens to
have the same name as an existing file.
* jc/globfetch:
fetch-pack: do not barf when duplicate re patterns are given
git-fetch: allow forcing glob pattern in refspec
git-fetch: allow glob pattern in refspec
git-fetch: fix dumb protocol transport to fetch from pack-pruned ref
git-fetch: reuse ls-remote result.
git blame -C: fix output format tweaks when crossing file boundary.
We used to get the case that more than two paths came from the
same commit wrong when computing the output width and deciding
to turn on --show-name option automatically. When we find that
lines that came from a path that is different from what we
started digging from, we should always turn --show-name on, and
we should count the name length for all files involved.
After the bugfix to connect to repositories where the user has
limited read permissions, multi-init was broken due to our
SVN::Ra connection being limited to working in a subdirectory;
so we now create a new Ra connection for init-ing branches
and another for tags
Along with that fix, allow the user to use the command-line
option flags for multi-init (--revision being the most notable;
but also --no-auth-cache, --config-dir, --username (for passing
to SVN), and --shared/--template for passing to git-init-db
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* match LESS environment settings to those in pager.c
* parse diff.color and pager.color settings in the
config file, and pass --color to git-log
* --color and --pager= settings are supported
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 35e65ecc broke completion of local refs, e.g. "git pull . fo<tab>"
no longer would complete to "foo". Instead it printed out an internal
git error ("fatal: Not a git repository: '.'").
The break occurred when I tried to improve performance by switching from
git-peek-remote to git-for-each-ref. Apparently git-peek-remote will
drop into directory "$1/.git" (where $1 is its first parameter) if it
is given a repository with a working directory. This allowed the bash
completion code to work properly even though it was not handing over
the true repository directory.
So now we do a stat in bash to see if we need to add "/.git" to the
path string before running any command with --git-dir.
I also tried to optimize away two "git rev-parse --git-dir" invocations
in common cases like "git log fo<tab>" as typically the user is in the
top level directory of their project and therefore the .git subdirectory
is in the current working directory. This should make a difference on
systems where fork+exec might take a little while.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn: fix output reporting from the delta fetcher
There was nothing printed in the code originally because I left
out a pair of parentheses. Nevertheless, the affected code has
been replaced with a more efficient version that respects the -q
flag as well as requiring less bandwidth.
We save some bandwidth by not requesting changed paths
information when calling get_log() since we're using the delta
fetcher.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn: error out when the SVN connection fails during a fetch
finish_report does seem to return a useful value indicating success
or failure, so we'll just set a flag when close_edit is called
(it is not called on failures, nor is abort_edit) and check
the flag before proceeding.
Thanks to Pazu for pointing this out.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't force the user to specify more than one revision parameter,
thus making git-shortlog behave more like git-log.
'git-shortlog master' will now produce the expected results; the
other end of the range simply is the (oldest) root commit.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn: enable delta transfers during fetches when using SVN:: libs
This should drastically reduce bandwidth used for network
transfers. This is not enabled for file:// repositories by
default because of the increased CPU usage and I/O needed.
GIT_SVN_DELTA_FETCH may be set to a true value to enable or
false (0) to disable delta transfers regardless of the
repository type.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Use .git/config for storing "origin" shortcut repository
Rather than use a separate config .git/remotes/ for remote shortcuts, this
patch adds the analagous definitions to .git/config using git-repo-config
calls.
For example what was previously .git/remotes/origin
URL: proto://host/path
Pull: refs/heads/master:refs/heads/origin
Is now added to .git/config as
[remote "origin"]
url = proto://host/path
fetch = refs/heads/master:refs/heads/origin
Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
sha1_object_info(): be consistent with read_sha1_file()
We used to try loose objects first with sha1_object_info(), but packed
objects first with read_sha1_file(). Now, prefer packed objects over loose
ones with sha1_object_info(), too.
Usually the old behaviour would pose no problem, but when you tried to fix
a fscked up repository by inserting a known-good pack,
git cat-file $(git cat-file -t <sha1>) <sha1>
could fail, even when
git cat-file blob <sha1>
would _not_ fail. Worse, a repack would fail, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
This should not change any functionality, but just makes it readable by
having a space between syntactic construct keyword and open parenthesis
(e.g. "if (expr", not "if(expr") and between close parenthesis and open
brace (e.g. "if (expr) {" not "if (expr){").
Cache the list of merge strategies and available commands during load.
Since the user's git installation is not likely to grow a new command
or merge strategy in the lifespan of the current shell process we can
save time during completion operations by caching these lists during
sourcing of the completion support.
If the git executable is not available or we run into errors while
caching at load time then we defer these to runtime and generate
the list on the fly. This might happen if the user doesn't put git
into their PATH until after the completion script gets sourced.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Support --strategy=x completion in addition to --strategy x.
Because git-merge and git-rebase both accept -s, --strategy or --strategy=
we should recognize all three formats in the bash completion functions and
issue back all merge strategies on demand.
I also moved the prior word testing to be before the current word testing,
as the current word cannot be completed with -- if the prior word was an
option which requires a parameter, such as -s or --strategy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a really ugly completion script for git-repo-config, but it has
some nice properties. I've added all of the documented configuration
parameters from Documentation/config.txt to the script, allowing the
user to complete any standard configuration parameter name.
We also have some intelligence for the remote.*.* and branch.*.* keys
by completing not only the key name (e.g. remote.origin) but also the
values (e.g. remote.*.fetch completes to the branches available on the
corresponding remote).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that people are really likely to start using separate remotes
(due to the default in git-clone changing) we should support ref
completion for these refs in as many commands as possible.
While we are working on this routine we should use for-each-ref
to obtain a list of local refs, as this should run faster than
peek-remote as it does not need to dereference tag objects in
order to produce the list of refs back to us. It should also
be more friendly to users of StGIT as we won't generate a list
of the StGIT metadata refs.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Teach bash about git log/show/whatchanged options.
Typing out options to git log/show/whatchanged can take a while, but
we can easily complete them with bash. So list the most common ones,
especially --pretty=online|short|medium|... so that users don't need
to type everything out.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
As git-rebase is a popular command bash should know how to complete
reference names and its long options. We only support completions
which make sense given the current state of the repository, that
way users don't get shown --continue/--skip/--abort on the first
execution.
Also added support for long option --strategy to git-merge, as I
missed that option earlier and just noticed it while implementing
git-rebase.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Provide completion for currently known long options supported by
git-format-patch as well as the revision list specification argument,
which is generally either a refname or in the form a..b.
Since _git_log was the only code that knew how to complete a..b, but
we want to start adding option support to _git_log also refactor the
a..b completion logic out into its own function.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Add current branch in PS1 support to git-completion.bash.
Many users want to display the current branch name of the current git
repository as part of their PS1 prompt, much as their PS1 prompt might
also display the current working directory name.
We don't force our own PS1 onto the user. Instead we let them craft
their own PS1 string and offer them the function __git_ps1 which they
can invoke to obtain either "" (when not in a git repository) or
"(%s)" where %s is the name of the current branch, as read from HEAD,
with the leading refs/heads/ removed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Hide plumbing/transport commands from bash completion.
Users generally are not going to need to invoke plumbing-level commands
from within one line shell commands. If they are invoking these commands
then it is likely that they are glueing them together into a shell script
to perform an action, in which case bash completion for these commands is
of relatively little use.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Teach git-completion.bash how to complete git-merge.
Now that git-merge is high-level Porcelain users are going to expect
to be able to use it from the command line, in which case we really
should also be able to complete ref names as parameters.
I'm also including completion support for the merge strategies
that are supported by git-merge.sh, should the user wish to use a
different strategy than their default.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Update documentation to remove incorrect GIT_DIFF_OPTS example.
Git no longer calls an external diff program to generate patches.
Remove the documentation which suggests that you can pass
arbitrary diff options via the GIT_DIFF_OPTS environment variable.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
* js/shortlog:
git-shortlog: make common repository prefix configurable with .mailmap
git-shortlog: fix common repository prefix abbreviation.
builtin git-shortlog is broken
shortlog: fix "-n"
shortlog: handle email addresses case-insensitively
shortlog: read mailmap from ./.mailmap again
shortlog: do not crash on parsing "[PATCH"
Build in shortlog
* branch 'jc/merge':
git-merge: do not leak rev-parse output used for checking internally.
git-merge: tighten error checking.
merge: allow merging into a yet-to-be-born branch.
git-merge: make it usable as the first class UI
remove merge-recursive-old
If a branch name to be merged is misspelled, the command leaked error
messages from underlying plumbing commands, which were helpful only
to people who know how the command are implemented to diagnose the
breakage, but simply puzzling and unhelpful for the end users.
* jn/web:
gitweb: Make project description in projects list link to summary view
gitweb: Use author_epoch for pubdate in gitweb feeds
gitweb: Add author and contributor email to Atom feed
gitweb: Add author and committer email extraction to parse_commit
gitweb: Use git-show-ref instead of git-peek-remote
gitweb: Do not use esc_html in esc_path
Attempt to clarify somewhat the difference between pull and merge,
and give a little more details on the pull syntax.
I'm still not happy with this section: the explanation of the origin
branch isn't great, but maybe that should be left alone pending the
use-separate-remotes change; and we need to explain how to set up a
public repository and push to it.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Make project description in projects list link to summary view
Make (shortened) project description in the "projects list" view
hyperlink to the "summary" view of the project. Project names are
sometimes short; having project description be hyperling gives larger
are to click. While at it, display full description on mouseover via
'title' attribute to introduced link.
Additionally, fix whitespace usage in modified git_project_list_body
subroutine: tabs are for indent, spaces are for align.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb: Use git-show-ref instead of git-peek-remote
Use "git show-ref --dereference" instead of "git peek-remote
$projectroot/project" in git_get_references. git-show-ref is faster
than git-peek-remote (40ms vs 56ms user+sys for git.git repository);
even faster is reading info/refs file (if it exists), but the
information in info/refs can be stale; that and the fact that
info/refs is meant for dumb protocol transports, not for gitweb.
git-show-ref is available since v1.4.4; the output format is slightly
different than git-peek-remote output format, but we accept both.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Building on top of the earlier refspec glob pattern enhancement,
this allows a glob pattern to say the updates should be forced
by prefixing it with '+' as usual, like this:
git-fetch: exit with non-zero status when fast-forward check fails
When update_local_ref() refuses to update a branch head due to
fast-forward check, it was not propagated properly in the call
chain and the command did not exit with non-zero status as a
result.
git-commit: show --summary after successful commit.
Sometimes people accidentally commit files in wrong mode bits.
Show --summary output for the HEAD commit after successful commit
as a final sanity check.
Some versions of the SVN libraries cause die() to exit with 255,
and 40cf043389ef4cdf3e56e7c4268d6f302e387fa0 tightened up
test_expect_failure to reject return values >128.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn: correctly access repos when only given partial read permissions
Sometimes users are given only read access to a subtree inside a
repository, and git-svn could not read log information (and thus
fetch commits) when connecting a session to the root of the
repository. We now start an SVN::Ra session with the full URL
of what we're tracking, and not the repository root as before.
This change was made much easier with a cleanup of
repo_path_split() usage as well as improving the accounting of
authentication batons.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-branch -D: make it work even when on a yet-to-be-born branch
This makes "git branch -D other_branch" work even when HEAD
points at a yet-to-be-born branch.
Earlier, we checked the HEAD ref for the purpose of "subset"
check even when the deletion was forced (i.e. not -d but -D).
Because of this, you cannot delete a branch even with -D while
on a yet-to-be-born branch.
With this change, the following sequence that now works:
git-clone: stop dumb protocol from copying refs outside heads/ and tags/.
Most notably, the original code first copied refs/remotes/ that
remote side had to local, and overwrote them by mapping refs/heads/
from the remote when a dumb protocol transport was used.
This makes the clone behaviour by dumb protocol in line with the
git native and rsync transports.
to delete the named remote branch. The refspec $src:$dst means
replace the destination ref with the object known as $src on the
local side, so this is a natural extension to make an empty $src
mean "No object" to delete the target.
* jn/web:
gitweb: Finish restoring "blob" links in git_difftree_body
gitweb: Refactor feed generation, make output prettier, add Atom feed
gitweb: Add an option to href() to return full URL
gitweb: New improved formatting of chunk header in diff
gitweb: Default to $hash_base or HEAD for $hash in "commit" and "commitdiff"
gitweb: Buffer diff header to deal with split patches + git_patchset_body refactoring
gitweb: Protect against possible warning in git_commitdiff