using git-init as directory name confused 'make remove-dashes', so just
drop the 'git-' prefix.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
06cbe85 (Make core.sharedRepository more generic, 2008-04-16) broke the
traditional setting of core.sharedRepository to true, which was to make
the repository group writable: with umask 022, it would clear the
permission bits for 'other'. (umask 002 did not exhibit this behaviour
since pre-chmod() check in adjust_shared_perm() fails in that case.)
The call to adjust_shared_perm() should only loosen the permission.
If the user has umask like 022 or 002 that allow others to read, the
resulting files should be made readable and writable by group, without
restricting the readability by others.
This patch fixes the adjust_shared_perm() mode tweak based on Junio's
suggestion and adds the appropriate tests to t/t1301-shared-repo.sh.
Cc: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch moves rerere()-related functions into a newly created
rerere.c file.
The setup_rerere() function is needed by both rerere() and cmd_rerere(),
so this function is moved to rerere.c and declared non-static (and "extern")
in newly created rerere.h file.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a conflicting file contains a line that begin with "=======", rerere
failed to parse conflict markers. This result to a wrong preimage file and
an unexpected error for the user. The boundary between ours and theirs
not just begin with 7 equals, but is followed by either a SP or a LF.
This patch enforces parsing rules so that markers match in the right order,
and when ambiguous, the command does not autoresolve the conflicted file.
Especially because we are introducing rerere.autoupdate configuration
(which is off by default for safety) that automatically stages the
resolution made by rerere, it is necessary to make sure that we do not
autoresolve when there is any ambiguity.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
7ebd52a (Merge branch 'dz/apply-again', 2008-07-01) taught "git-apply" to
grok a (non-git) patch that is a concatenation of separate patches that
touch the same file number of times, by recording the postimage of patch
application of previous round and using it as the preimage for later
rounds.
This "incremental" mode of patch application fundamentally contradicts
with the way git rename/copy patches are designed. When a git patch talks
about a file A getting modified, and a new file B created out of A, like
this:
diff --git a/A b/A
--- a/A
+++ b/A
... change text here ...
diff --git a/A b/B
copy from A
copy to B
--- a/A
+++ b/B
... change text here ...
the second change to produce B does not depend on what is done to A with
the first change in any way. This is explicitly done so for reviewability
of individual patches.
With this commit, we do not look at 'fn_table' that records the postimage
of previous round when applying a patch to produce a new file out of an
existing file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/apply-root:
git-apply --directory: make --root more similar to GNU diff
apply --root: thinkofix.
Teach "git apply" to prepend a prefix with "--root=<root>"
Send HELO again after a successful STARTTLS command to refresh the list of
extensions. These may be different to what is returned over a clear
connection (for example the AUTH command may be accepted over a secure
connection, but not over a clear connection).
Furthermore, this behaviour is recommended by RFC 2487
(http://www.ietf.org/rfc/rfc2487.txt).
Signed-off-by: Robert Shearman <robertshearman@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It seems we're using handle_revision_opt the same way each time, have a
wrapper around it that does the 9-liner we copy each time instead.
handle_revision_opt can be static in the module for now, it's always
possible to make it public again if needed.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 6e1c23442 we make use of these C99 constructs, but this commit did
not provide fallbacks for non-C99 systems.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When setting the GIT_SVN_LC_ALL variable, default to the $LANG
environment variable, when the $LC_ALL override is not set.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently this test simply exits without providing any
feedback at all. Tell user if the test is being skipped
and provide a hint as to how the test may be enabled.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When recursing to unpack a delta base we must unuse_pack() so that
the pack window for the current object does not remain pinned in
memory while the delta base is itself being unpacked and materialized
for our use.
On a long delta chain of 50 objects we may need to access 6 different
windows from a very large (>3G) pack file in order to obtain all
of the delta base content. If the process ulimit permits us to
map/allocate only 1.5G we must release windows during this recursion
to ensure we stay within the ulimit and transition memory from pack
cache to standard malloc, or other mmap needs.
Inserting an unuse_pack() call prior to the recursion allows us to
avoid pinning the current window, making it available for garbage
collection if memory runs low.
This has been broken since at least before 1.5.1-rc1, and very
likely earlier than that. Its fixed now. :)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git-branch --merged" is a handy way to list all the branches that have
already been merged to the current branch, but it did not allow checking
against anything but the current branch. Having to switch branches only
to list the branches that are merged with another branch made the feature
practically useless.
This updates the option parser so that "git branch --merged next" is
accepted when you are on 'master' branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to require the name of the commit to limit the branches shown to
the --contains option, but more recent --merged/--no-meregd defaults to
HEAD (and they do not allow arbitrary commit, which is a separate issue).
This teaches --contains to default to HEAD when no parameter is given.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you set this for a given option, and the optoin appears without an
argument on the command line, then the `defval' is used as its argument.
Note that this flag is meaningless in presence of OPTARG or NOARG flags.
(in the current implementation it will be ignored, but don't rely on it).
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Start preparing release notes for 1.5.6.3
git-submodule - Fix bugs in adding an existing repo as a module
bash: offer only paths after '--'
Remove unnecessary pack-*.keep file after successful git-clone
make deleting a missing ref more quiet
Various *_HEAD pseudo refs were not documented in any central place.
Especially since we may be teaching rebase and am to record ORIG_HEAD,
it would be a good time to do so.
While at it, reword the explanation on r1..r2 notation to reduce
confusion.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The mention of 1997 was correct when it was made, and it still is true
to some extent (http://savannah.gnu.org/forum/forum.php?forum_id=5189
says it has not been actively maintained for quite some time). However,
because its name changed not to conflict with us, it is no longer
relevant whether many users use gnuit or have moved away to graphical
file managers.
The only people possibly affected are people who have older version of
gnuit installed as "git".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On some setups, apache will say:
apache2: Could not reliably determine the server's fully qualified
domain name, using $(IP_address) for ServerName
Avoid this message polluting tests output by setting a ServerName in
apache configuration.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When USE_CURL_MULTI is undefined, git http-push doesn't work, so it's
useless to test it.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
http-push test has been broken by 4a7aaccd adding a space character
in the place where the test is being run.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git http-push doesn't handle packed-refs, and now the new builtin-clone
created packed refs, the http-push test fails.
Mark the current failure as such, and also catch third test's failure
that went unreported because git push doesn't return an error code when
it says:
No refs in common and none specified; doing nothing.
Which it does when http-push can't get a list of refs recursively from
$URL/refs/.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch also converts the good ole' git-remote.perl to use it.
It is otherwise used in the repo.or.cz machinery and I guess other
scripts might find it useful too.
Unfortunately,
git-ls-remote --heads .
is subtly different from
git-ls-remote . refs/heads/
(since the second matches anywhere in the string, not just at the
beginning) so we have to provide interface for both.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unpacked objects should receive the timestamp of the pack they were
unpacked from. Check.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-submodule add would trip if path to the submodule included a space,
or if its .git was a gitdir: link to a GIT_DIR kept elsewhere. Fix both.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is needed as git-sh-setup is no longer in the path.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many git commands use '--' to separate subcommands, options, and refs
from paths. However, the programmable completion for several of these
commands does not respect the '--', and offer subcommands, options, or
refs after a '--', although only paths are permitted. e.g. 'git bisect
-- <TAB>' offers subcommands, 'git log -- --<TAB>' offers options and
'git log -- git<TAB>' offers all gitgui tags.
The completion for the following commands share this wrong behaviour:
am add bisect commit diff log reset shortlog submodule gitk.
To avoid this, we check the presence of a '--' on the command line first
and let the shell do filename completion, if one is found.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now use handle_revision_args instead of parse_revisions, and simplify the
handling of old-style arguments a lot thanks to the filtering.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This step merely moves the parser to an incremental version, still using
parse_revisions.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add two fields to struct rev_info:
- .def to store --default argument; and
- .show_merge 1-bit field.
handle_revision_opt() is able to deal with any revision option, and
consumes them, and leaves revision arguments or pseudo arguments
(like --all, --not, ...) in place.
For now setup_revisions() does a pass of handle_revision_opt() again
so that code not using it in a parse-opt parser still work the same.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Once a clone is successful we no longer need to hold onto the
.keep file created by the transport. Delete the file so we
can later repack the complete repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation suggests using "git stash apply" in the
--keep-index workflow even though doing so will lead to clutter
in the stash. And given that the changes are about to be
committed anyway "git stash pop" is more sensible.
Additionally the text preceeding the example claims that it
works for "two or more commits", but the example itself is
really tailored for just two. Expanding it just a little
makes it clear how the procedure generalizes to N commits.
Finally the example is annotated with some commentary to
explain things on a line-by-line basis.
When the user specifies a ref by a reflog entry older than
one we have (e.g., "HEAD@{20 years ago"}), we issue a
warning and give them the "from" value of the oldest reflog
entry. That is, we say "we don't know what happened before
this entry, but before this we know we had some particular
SHA1".
However, the oldest reflog entry is often a creation event
such as clone or branch creation. In this case, the entry
claims that the ref went from "00000..." (the null sha1) to
the new value, and the reflog lookup returns the null sha1.
While this is technically correct (the entry tells us that
the ref didn't exist at the specified time) it is not
terribly useful to the end user. What they probably want
instead is "the oldest useful sha1 that this ref ever had".
This patch changes the behavior such that if the oldest ref
would return the null sha1, it instead returns the first
value the ref ever had.
We never discovered this problem in the test scripts because
we created "fake" reflogs that had only a specified segment
of history. This patch updates the tests with a creation
event at the beginning of history.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge has always set ORIG_HEAD but never mentioned it, while we
recently added it to am and rebase. These facts should be reflected
in the documentation.
git-reset also sets ORIG_HEAD, but that fact is already mentioned in
the very first example so no changes were needed there.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If git attempts to delete a ref, but the unlink of the ref
file fails, we print a message to stderr. This is usually a
good thing, but if the error is ENOENT, then it indicates
that the ref has _already_ been deleted. And since that's
our goal, it doesn't make sense to complain to the user.
This harmonizes the error reporting behavior for the
unpacked and packed cases; the packed case already printed
nothing on ENOENT, but the unpacked printed unconditionally.
Additionally, send-pack would, when deleting the tracking
ref corresponding to a remote delete, print "Failed to
delete" on any failure. This can be a misleading
message, since we actually _did_ delete at the remote side,
but we failed to delete locally. Rather than make the
message more precise, let's just eliminate it entirely; the
delete_ref routine already takes care of printing out a much
more specific message about what went wrong.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
