In set_work_tree(), variable rel needs to be reinitialized to
NULL on every call (it should not be static).
Make sure the incoming dir variable is not too long before
copying to the temporary buffer, and make sure chdir to the
resulting directory succeeds.
This was spotted and fixed by Alex and Johannes in a handful
patch exchanges. Here is the final version.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
The current implementation of core.gitproxy only operates on
git:// URLs, so the ssh:// examples and custom protocol examples
have been removed or edited.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
read-tree is already marked with RUN_SETUP in git.c, so there is
no need to call setup_git_directory() a second time.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
processing
P4 change outputs the changes sorted for each directory separately. We
want the global ordering on the changes, hence we sort.
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Signed-off-by: Simon Hausmann <simon@lst.de>
This changes the behaviour of cloning from a repository on the
local machine, by defaulting to "-l" (use hardlinks to share
files under .git/objects) and making "-l" a no-op. A new
option, --no-hardlinks, is also added to cause file-level copy
of files under .git/objects while still avoiding the normal
"pack to pipe, then receive and index pack" network transfer
overhead. The old behaviour of local cloning without -l nor -s
is availble by specifying the source repository with the newly
introduced file:///path/to/repo.git/ syntax (i.e. "same as
network" cloning).
* With --no-hardlinks (i.e. have all .git/objects/ copied via
cpio) would not catch the source repository corruption, and
also risks corrupted recipient repository if an
alpha-particle hits memory cell while indexing and resolving
deltas. As long as the recipient is created uncorrupted, you
have a good back-up.
* same-as-network is expensive, but it would catch the breakage
of the source repository. It still risks corrupted recipient
repository due to hardware failure. As long as the recipient
is created uncorrupted, you have a good back-up.
* The new default on the same filesystem, as long as the source
repository is healthy, it is very likely that the recipient
would be, too. Also it is very cheap. You do not get any
back-up benefit, though.
None of the method is resilient against the source repository
corruption, so let's discount that from the comparison. Then
the difference with and without --no-hardlinks matters primarily
if you value the back-up benefit or not. If you want to use the
cloned repository as a back-up, then it is cheaper to do a clone
with --no-hardlinks and two git-fsck (source before clone,
recipient after clone) than same-as-network clone, especially as
you are likely to do a git-fsck on the recipient if you are so
paranoid anyway.
Which leads me to believe that being able to use file:/// is
probably a good idea, if only for testability, but probably of
little practical value. We default to hardlinked clone for
everyday use, and paranoids can use --no-hardlinks as a way to
make a back-up.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We might make it something like: "if you use an url, we don't default to
local", so the difference would be that
git clone file:///directory/to/repo
would work the way it does now, but
git clone /directory/to/repo
would default to "-l" behaviour. That kind of would make sense (and should
be easy to implement.
This adds support for "file://" URL to underlying connect
codepath to make it happen.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes "make doc" work even if you made "sudo make doc" previously
by mistake. Apparently an oversight: the other targets did this already.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calling "git rebase -i <upstream> <branch>", git should switch
to <branch> first. This worked before, but I broke it by my
"Shut git rebase -i up" patch.
Fix that, and add a test to make sure that it does not break again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
[jc: adjusted t/t7501 as this makes -F and --amend compatible]
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous code only allowed specifying a single executable rather
than a complete command like "emacsclient --alternate-editor vi" in
those variables. Since VISUAL/EDITOR appear to be traditionally
passed to a shell for interpretation (as corroborated with "less",
"mail" and "mailx", while the really ancient "more" indeed allows only
an executable name), the shell function git_editor has been amended
appropriately.
"eval" is employed to have quotes and similar interpreted _after_
expansion, so that specifying
EDITOR='"/home/dak/My Commands/notepad.exe"'
can be used for actually using commands with blanks.
Instead of passing just the first argument of git_editor on, we pass
all of them (so that +lineno might be employed at a later point of
time, or so that multiple files may be edited when appropriate).
Strictly speaking, there is a change in behavior: when
git config core.editor
returns a valid but empty string, the fallbacks are still searched.
This is more consistent, and the old code was problematic with regard
to multiple blanks. Putting in additional quotes might have worked,
but quotes inside of command substitution inside of quotes is nasty
enough to not reliably work the same across "Bourne shells".
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It wont work for arguments with special characters (like ", : or *).
It is generally not possible on Windows, so I didn't even try.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Non-interactive rebase had this from the beginning -- match it by
using --cherry-pick option to rev-list.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The comment did not make a good case why it makes sense.
Clarify, and remove stale comment about the caller being lazy.
The behaviour on NULL input is pretty much intentional.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the function set_git_dir() you can reset the path that will
be used for git_path(), git_dir() and friends.
The responsibility to close files and throw away information from the
old git_dir lies with the caller.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function get_relative_cwd() works just as getcwd(), only that it
takes an absolute path as additional parameter, returning the prefix
of the current working directory relative to the given path. If the
cwd is no subdirectory of the given path, it returns NULL.
is_inside_dir() is just a trivial wrapper over get_relative_cwd().
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds convenience functions to work with absolute paths.
The function is_absolute_path() should help the efforts to integrate
the MinGW fork.
Note that make_absolute_path() returns a pointer to a static buffer.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I switched git.kernel.dk to --base-path a few minutes ago, to get rid of
a /data/git postfix in the posted urls. But transitioning is tricky,
since now all old paths will fail miserably.
So I added this --base-path-relaxed option, that will make git-daemon
try the absolute path without prefixing --base-path before giving up.
With this in place and --base-path-relaxed added, both my new url of
git://git.kernel.dk/linux-2.6-block.git
and the old
git://git.kernel.dk/data/git/linux-2.6-block.git
work fine.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also don't require .git/info/exclude to exist in order to list unknown
files.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Acked-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check for non-0 exit code if the confiog file does not exist and
if it works exactly like when setting GIT_CONFIG.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are (really!) systems where using environment variables is very
cumbersome (yes, Windows, it has problems unsetting them). Besides this
form is shorter.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce new makefile variable lib to hold the name of the lib
directory ("lib" by default). Also introduce a switch for configure
to specify this name with --with-lib=ARG. This is useful for systems
that use a different name than "lib" (like "lib64" on some 64 bit
Linux architectures).
Signed-off-by: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some systems do not provide zlib development headers and libraries in
default search path of the compiler. For these systems we should allow
specifying the location by --with-zlib=PATH or by setting ZLIB_PATH in
the makefile.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An earlier commit 366bfcb6 broke git-add by moving read_cache()
call down, because it wanted the directory walking code to grab
paths that are already in the index. The change serves its
purpose, but introduces a regression because the responsibility
of avoiding unnecessary reindexing by matching the cached stat
is shifted nowhere.
This makes it the job of add_file_to_index() function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In git some characters are invalid as documented
in git-check-ref-format. In subversion these characters might
be valid, so a translation is required.
This patch does this translation by url escaping characters, that
are not allowed.
Credit goes to Eric Wong, martin f. krafft and Jan Hudec
Signed-off-by: Robert Ewald <robewald@gmx.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some lines were not indented by tabs but by spaces.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The file used for per-repository attribute setting is not
$GIT_DIR/info/gitattributes, but $GIT_DIR/info/attributes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes rebase/am keep the original commit log message
better, even when it does not conform to "single line paragraph
to say what it does, then explain and defend why it is a good
change in later paragraphs" convention.
This change is a two-edged sword. While the earlier behaviour
would make such commit log messages more friendly to readers who
expect to get the birds-eye view with oneline summary formats,
users who primarily use git as a way to interact with foreign
SCM systems would not care much about the convenience of oneline
git log tools, but care more about preserving their own
convention. This changes their commits less useful to readers
who read them with git tools while keeping them more consistent
with the foreign SCM systems they interact with.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier these tools refused to create a reflog entry when the
message given by the calling Porcelain had a LF in it, partially
to keep the file format integrity of reflog file, which is
one-entry-per-line. These tools should not be dictating such a
policy.
Instead, let the codepath to write out the reflog entry worry
about the format integrity and allow messages with LF in them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A reflog file is organized as one-line-per-entry records, and we
enforced the file format integrity by chomping the given message
at the first LF. This changes it to convert them to SP, which
is more in line with the --pretty=oneline format.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* bs/lock:
Add test for symlinked configuration file updates.
use lockfile.c routines in git_commit_set_multivar()
fully resolve symlinks when creating lockfiles
* 'master' of git://repo.or.cz/git-gui: (50 commits)
git-gui: Minor refactoring of merge command line in merge support
git-gui: Use more modern looking icons in the tree browser
git-gui: Don't offer to stage hunks from untracked files
git-gui: Make sure remotes are loaded when picking revisions
git-gui: Use progress bar while resetting/aborting files
git-gui: Honor core.excludesfile when listing extra files
git-gui: Unify wording to say "to stage" instead of "to add"
git-gui: Don't kill modified commit message buffer with merge templates
git-gui: Remove usernames from absolute SSH urls during merging
git-gui: Format tracking branch merges as though they were pulls
git-gui: Cleanup bindings within merge dialog
git-gui: Replace merge dialog with our revision picker widget
git-gui: Show ref last update times in revision chooser tooltips
git-gui: Display commit/tag/remote info in tooltip of revision picker
git-gui: Save remote urls obtained from config/remotes setup
git-gui: Avoid unnecessary symbolic-ref call during checkout
git-gui: Refactor current branch menu items to make i18n easier
git-gui: Refactor diff popup into a procedure to ease i18n work
git-gui: Paper bag fix quitting crash after commit
git-gui: Clarify meaning of add tracked menu option
...
This is just a small code movement to cleanup how we generate
the command line for a merge. I'm only doing it to make the
next series of changes slightly more readable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a replacement of all of the icons in our tree browser
window, as the prior icons just looked too 1980s Tk-ish. The
icons used here are actually from a KDE themed look, so they
might actually be familiar to some users of git-gui.
Aside from using more modern looking icons we now have a special
icon for executable blobs, to make them stand out from the normal
non-executable blobs. We also denote symlinks now with a different
icon, so they stand out from the other types of objects in the tree.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user looks at an untracked file in our diff pane we used
to offer "Stage Hunk For Commit" in the context menu when they
right-clicked in that pane. The problem is we don't actually
have any diff hunks in untracked files, so there is nothing to
really select for staging. So we now grey out the menu item,
so the user cannot invoke it and think its broken when it does
not perform any useful action.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are started for only a blame/browser/citool run we don't
usually initialize the list of remotes, or determine which refs
are tracking branches and which are local branch heads. This is
because some of that work is relatively expensive and is usually
not going to be needed if we are started only for a blame, or to
make a single commit.
However by not loading the remote configuration we were crashing
if the user tried to open a browser for another branch through
the Repository menu, as our load_all_heads procedure was unable
to decide which refs/heads/ items were actually local heads. We
now force all remote configuration data to be loaded if we have
not done so already and we are trying to create a revision mega
widget.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some people might prefer to be able to specify the find utility to
use.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tree recursion behavior of git-diff may appear
inconsistent to the user because it depends on the format of
the patch as well as whether one is diffing between trees or
against the index.
Since git-diff is a porcelain wrapper for low-level diff
commands, it makes sense for its behavior to be consistent
no matter what is being diffed. This patch turns on
recursion in all cases.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Resetting a large number of files on a slow filesystem can take
considerable time, just as switching branches in such a case can
take more than two seconds. We now take advantage of the progress
meter output by read-tree and show it in the main window status
bar, just like we do during checkout (branch switch).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
