* master:
Documentation: Transplanting branch with git-rebase --onto
Document git-pack-refs and link it to git(7).
merge-recursive implicitely depends on trust_executable_bit
adjust_shared_perm: chmod() only when needed.
Fix git-runstatus for repositories containing a file named HEAD
* maint:
Documentation: Transplanting branch with git-rebase --onto
merge-recursive implicitely depends on trust_executable_bit
adjust_shared_perm: chmod() only when needed.
Fix git-runstatus for repositories containing a file named HEAD
With this change, you can specify the beginning and the ending
line of the range you wish to inspect with pattern matching.
For example, these are equivalent with the git.git sources:
git pickaxe -L 7,21 v1.4.0 -- commit.c
git pickaxe -L '/^struct sort_node/,/^}/' v1.4.0 -- commit.c
git pickaxe -L '7,/^}/' v1.4.0 -- commit.c
git pickaxe -L '/^struct sort_node/,21' v1.4.0 -- commit.c
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added example of transplantig feature branch from one development
branch (for example "next") into the other development branch (for
example "master").
[jc: talking Carl's advice this contains both examples sent to
the list by Jakub in his original message.]
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Read the configuration in to get core.filemode value for this
particular repository.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When widening permission for files and directories in a 'shared'
repository for a user with inappropriate umask() setting for
shared work, make sure we call chmod() only when we actually
need to.
The primary idea owes credit to Johannes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The wt_status_print_updated() and wt_status_print_untracked() routines
call setup_revisions() with 'HEAD' being the reference to the tip of the
current branch. However, setup_revisions() gets confused if the branch
also contains a file named 'HEAD' resulting in a fatal error.
Instead, don't pass an argv to setup_revisions() at all; simply give it no
arguments, and make 'HEAD' the default revision.
Bug noticed by Rocco Rutte <pdmef@gmx.net>.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/pickaxe:
git-pickaxe: optimize by avoiding repeated read_sha1_file().
git-blame: add internal statistics to count read blobs.
git-pickaxe: fix origin refcounting
git-pickaxe: re-scan the blob after making progress with -C
git-pickaxe: re-scan the blob after making progress with -M
git-pickaxe: simplify Octopus merges further
git-pickaxe: rename detection optimization
* master:
Remove more sed invocations from within bash completion.
Support bash completion on symmetric difference operator.
Take --git-dir into consideration during bash completion.
Bash completion support for remotes in .git/config.
Only load .exe suffix'd completions on Cygwin.
Added missing completions for show-branch and merge-base.
cherry is built-in, do not ship git-cherry.sh
This change removes between 1 and 4 sed invocations per completion
entered by the user. In the case of cat-file the 4 invocations per
completion can take a while on Cygwin; running these replacements
directly within bash saves some time for the end user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that log, whatchanged, rev-list, etc. support the symmetric
difference operator '...' we should provide bash completion for it
just like we do for '..'.
While we are at it we can remove two sed invocations during the
interactive prompt and replace them with internal bash operations.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user has setup a command line of "git --git-dir=baz" then
anything we complete must be performed within the scope of "baz"
and not the current working directory.
This is useful with commands such as "git --git-dir=git.git log m"
to complete out "master" and view the log for the master branch of
the git.git repository. As a nice side effect this also works for
aliases within the target repository, just as git would honor them.
Unfortunately because we still examine arguments by absolute position
in most of the more complex commands (e.g. git push) using --git-dir
with those commands will probably still cause completion to fail.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that Git natively supports remote specifications within the
config file such as:
[remote "origin"]
url = ...
we should provide bash completion support "out of the box" for
these remotes, just like we do for the .git/remotes directory.
Also cleaned up the __git_aliases expansion to use the same form
of querying and filtering repo-config as this saves two fork/execs
in the middle of a user prompted completion. Finally also forced
the variable 'word' to be local within __git_aliased_command.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The only platform which actually needs to define .exe suffixes as
part of its completion set is Cygwin. So don't define them on any
other platform.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The show-branch and merge-base commands were partially supported
when it came to bash completions as they were only specified in
one form another. Now we specify them in both forms.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It turns out that pickaxe reads the same blob repeatedly while
blame can reuse the blob already read for the parent when
handling a child commit when it's parent's turn to pass its
blame to the grandparent. Have a cache in the origin structure
to keep the blob there, which will be garbage collected when the
origin loses the last reference to it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* js/modfix:
adjust_shared_perm: chmod() only when needed.
Remove unsupported C99 style struct initializers in git-archive.
Remove SIMPLE_PROGRAMS and make git-daemon a normal program.
Use ULONG_MAX rather than implicit cast of -1.
git-svn: don't die on rebuild when --upgrade is specified
git-svn: avoid printing filenames of files we're not tracking
Added bash completion support for git-reset.
Added completion support for git-branch.exe.
When widening permission for files and directories in a 'shared'
repository for a user with inappropriate umask() setting for
shared work, make sure we call chmod() only when we actually
need to.
The primary idea owes credit to Johannes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Remove unsupported C99 style struct initializers in git-archive.
Remove SIMPLE_PROGRAMS and make git-daemon a normal program.
Use ULONG_MAX rather than implicit cast of -1.
At least one older version of the Solaris C compiler doesn't support
the newer C99 style struct initializers. To allow Git to compile
on those systems use an archive description struct which is easier
to initialize without the C99 struct initializer syntax.
Also since the archives array is not used by anyone other than
archive.c we can make it static.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some platforms (Solaris in particular) appear to require -lz as
part of the link line for git-daemon, due to it linking against
sha1_file.o and that module requiring inflate/deflate support.
So its time to retire SIMPLE_PROGRAMS and move its last remaining
member into the standard PROGRAMS list, allowing it to link against
all libraries used by the rest of Git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
At least one (older) version of the Solaris C compiler won't allow
'unsigned long x = -1' without explicitly casting -1 to a type of
unsigned long. So instead use ULONG_MAX, which is really the
correct constant anyway.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
--copy-remote and --upgrade are rarely (never?) used together,
so if --copy-remote is specified, that means the user really
wanted to copy the remote ref, and we should fail if that fails.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is purely an aesthetic change, we already skip importing of
files that don't affect the subdirectory we import.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we introduced the cached origin per commit, we gave up proper
garbage collecting because it meant that commits hold onto their
cached copy. There is no need to do so.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Completion for the --hard/--soft/--mixed modes of operation as
well as a ref name for <commit-ish> can be very useful and save
some fingers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
On Cygwin a user might complete the new git-branch builtin as
git-branch.exe, at which point bash requires a new completion
registration for the command.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The reason to do this is the same as in the previous change for
line copy detection within the same file (-M).
Also this fixes -C and -C -C (aka find-copies-harder) logic; in
this application we are not interested in the similarity
matching diffcore-rename makes, because we are only interested
in scanning files that were modified, or in the case of -C -C,
scanning all files in the parent and we want to do that
ourselves.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise we would miss copied lines that are contained in the
parts before or after the part that we find after splitting the
blame_entry (i.e. split[0] and split[2]).
Signed-off-by: Junio C Hamano <junkio@cox.net>
If more than one parents in an Octopus merge have the same
origin, ignore later ones because it would not make any
difference in the outcome.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The idea is that we are interested in renaming into only one path, so
we do not care about renames that happen elsewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master:
apply: handle "traditional" creation/deletion diff correctly.
gitweb: Remove extra "/" in path names for git_get_project_list
git.el: Include MERGE_MSG in the log-edit buffer even when not committing a merge.
git.el: Move point after the log message header when entering log-edit mode.
git.el: Added a function to open the current file in another window.
git.el: Added functions for moving to the next/prev unmerged file.
We deduced a GNU diff output that does not use /dev/null convention
as creation (deletion) diff correctly by looking at the lack of context
and deleted lines (added lines), but forgot to reset the new (old) name
field properly.
This was a regression when we added a workaround for --unified=0 insanity.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this change we get a wrong $pfxlen value and the check_export_ok()
checks with with a wrong directory name. Without this patch the below
$projects_list fails with gitweb
$projects_list = "/tmp/a/b/";
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This lets us take advantage of the fact that git-cherry-pick now saves
the message in MERGE_MSG too.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Bound to 'o' by default, compatible with pcl-cvs and
buffer-mode. Suggested by Han-Wen Nienhuys.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is useful when doing a merge that changes many files with only a
few conflicts here and there.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* np/index-pack:
remove .keep pack lock files when done with refs update
have index-pack create .keep file more carefully
improve fetch-pack's handling of kept packs
git-fetch can use both --thin and --keep with fetch-pack now
Teach receive-pack how to keep pack files based on object count.
Allow pack header preprocessing before unpack-objects/index-pack.
gitweb: Better support for non-CSS aware web browsers
gitweb: Output also empty patches in "commitdiff" view
gitweb: Use git-for-each-ref to generate list of heads and/or tags
for-each-ref: "creator" and "creatordate" fields
Add --global option to git-repo-config.
pack-refs: Store the full name of the ref even when packing only tags.
git-clone documentation didn't mention --origin as equivalent of -o
Minor grammar fixes for git-diff-index.txt
link_temp_to_file: call adjust_shared_perm() only when we created the directory
Remove uneccessarily similar printf() from print_ref_list() in builtin-branch
This makes both git-fetch and git-push (fetch-pack and receive-pack)
safe against a possible race with aparallel git-repack -a -d that could
prune the new pack while it is not yet referenced, and remove the .keep
file after refs have been updated.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If by chance we receive a pack which content (list of objects) matches
another pack that we already have, and if that pack is marked with a
.keep file, then we should not overwrite it.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
