When checkout sees that HEAD points to a non-existent ref,
it currently acts as if "-f" was given; this behavior dates
back to 5a03e7f, which enabled checkout from unborn branches
in the shell version of "git-checkout". The reasoning given
is to avoid the code path which tries to merge the tree
contents. When checkout was converted to C, this code
remained intact.
The unfortunate side effect of this strategy is that the
"force" code path will overwrite working tree and index
state that may be precious to the user. Instead of enabling
"force", this patch uses the normal "merge" codepath for an
unborn branch, but substitutes the empty tree for the "old"
commit.
This means that in the absence of an index, any files in the
working tree will be treated as untracked files, and a
checkout which would overwrite them is aborted. Similarly,
any paths in the index will be merged with an empty entry
as the base, meaning that unless the new branch's content is
identical to what's in the index, there will be a conflict
and the checkout will be aborted.
The user is then free to correct the situation or proceed
with "-f" as appropriate.
This patch also removes the "warning: you are on a branch
yet to be born" message. Its function was to warn the user
that we were enabling the "-f" option. Since we are no
longer doing that, there is no reason for the user to care
whether we are switching away from an unborn branch.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thell Fowler noticed that various "ignore whitespace" options to git diff
do not work well on an incomplete line.
The loop control of the function responsible for these bugs was extremely
difficult to follow. This patch restructures the loops for three variants
of "ignore whitespace" logic.
The basic idea of the re-written logic is:
- A loop runs while the characters from both strings we are looking at
match. We declare unmatch immediately when we find something that does
not match and return false from the function. We break out of the loop
if we ran out of either side of the string.
The way we skip spaces inside this loop varies depending on the style
of ignoring whitespaces.
- After the above loop breaks, we know that the parts of the strings we
inspected so far match, ignoring the whitespaces. The lines can match
only if the remainder consists of nothing but whitespaces. This part
of the logic is shared across all three styles.
The new code is more obvious and should be much easier to follow.
Tested-by: Thell Fowler <git@tbfowler.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Upon seeing a whitespace, xdl_hash_record_with_whitespace() first skipped
the run of whitespaces (excluding LF) that begins there, ensuring that the
pointer points at the last whitespace character in the run, and assumed
that the next character must be LF at the end of the line. This does not
work when hashing an incomplete line, which lacks the LF at the end.
Introduce "at_eol" variable that is true when either we are at the end of
line (looking at LF) or at the end of an incomplete line, and use that
instead throughout the code.
Noticed by Thell Fowler.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make append_remote_object_url() (and by implication,
get_remote_object_url) use end_url_with_slash() to ensure that the url
ends with a slash.
Previously, they assumed that the url did not end with a slash and
as a result appended a slash, sometimes errorneously.
This fixes an issue introduced in 5424bc5 ("http*: add helper methods
for fetching objects (loose)"), where the append_remote_object_url()
implementation in http-push.c, which assumed that urls end with a
slash, was replaced by another one in http.c, which assumed urls did
not end with a slash.
The above issue was raised by Thomas Schlichter:
http://marc.info/?l=git&m=125043105231327
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Tested-by: Thomas Schlichter <thomas.schlichter@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It used to be a single, huge line, badly wrapped by xterm.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have to add certain lines like ACKs (or for that matter,
Signed-off-by:s) to a range of commits starting with HEAD, you might
be tempted to use 'git rebase -i -10', but that is a waste of your
time.
It is better to use 'git filter-branch' with an appropriate message
filter, and this commit adds an example how to do so to
filter-branch's man page.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merlyn noticed that Documentation/install-doc-quick.sh no longer correctly
removes old installed documents when the target directory has a leading
path that is a symlink. It turns out that "checkout-index --prefix" was
broken by recent b6986d8 (git-checkout: be careful about untracked
symlinks, 2009-07-29).
I suspect has_symlink_leading_path() could learn the third parameter
(prefix that is allowed to be symlinked directories) to allow us to retire
a similar function has_dirs_only_path().
Another avenue of fixing this I considered was to get rid of base_dir and
base_dir_len from "struct checkout", and instead make "git checkout-index"
when run with --prefix mkdir the leading path and chdir in there. It
might be the best longer term solution to this issue, as the base_dir
feature is used only by that rather obscure codepath as far as I know.
But at least this patch should fix this breakage.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The effects of repacking on a repository with alternates are a bit
subtle. The two main things users will want are:
1. Not to waste disk space by accidentally copying objects which could
be shared.
2. Copying all objects explicitly to break the dependency on the source
repo.
This patch describes both under the "clone -s" documentation. It makes
sense to put it there rather than in git-repack.txt for both cases.
For (1), we are warning the user who is using "clone -s" about what _not_
to do, so we need to get their attention when reading about "clone -s".
For (2), we are telling them how git-repack can be used to accomplish a
task, but until they know that git-repack is the right tool, they have no
reason to look at the repack documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 0392513 (add-interactive: refactor mode hunk handling, 2009-04-16),
we merged the interaction loops for mode changes and hunk staging.
This was fine at the time, because 0beee4c (git-add--interactive:
remove hunk coalescing, 2008-07-02) removed hunk coalescing.
However, in 7a26e65 (Revert "git-add--interactive: remove hunk
coalescing", 2009-05-16), we resurrected it. Since then, the code
would attempt in vain to merge mode changes with diff hunks,
corrupting both in the process.
We add a check to the coalescing loop to ensure it only looks at diff
hunks, thus skipping mode changes.
Noticed-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When trying to stage changes to file which has also pending `chmod +x`,
`git add -p` produces lots of 'Use of uninitialized value ...' warnings
and fails to do the job:
$ echo content >> file
$ chmod +x file
$ git add -p
diff --git a/file b/file
index e69de29..d95f3ad
--- a/file
+++ b/file
old mode 100644
new mode 100755
Stage mode change [y,n,q,a,d,/,j,J,g,?]? y
@@ -0,0 +1 @@
+content
Stage this hunk [y,n,q,a,d,/,K,g,e,?]? y
Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
Use of uninitialized value $ofs in numeric le (<=) at .../git-add--interactive line 806.
Use of uninitialized value $o0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
Use of uninitialized value $n0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
fatal: corrupt patch at line 5
diff --git a/file b/file
index e69de29..d95f3ad
--- a/file
+++ b/file
@@ -,0 + @@
+content
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When unpack-objects is run under the --strict option, objects that have
pointers to other objects are verified for the reachability at the end, by
calling check_object() on each of them, and letting check_object to walk
the reachable objects from them using fsck_walk() recursively.
The function however misunderstands the semantics of fsck_walk() function
when it makes a call to it, setting itself as the callback. fsck_walk()
expects the callback function to return a non-zero value to signal an
error (negative value causes an immediate abort, positive value is still
an error but allows further checks on sibling objects) and return zero to
signal a success. The function however returned 1 on some non error
cases, and to cover up this mistake, complained only when fsck_walk() did
not detect any error.
To fix this double-bug, make the function return zero on all success
cases, and also check for non-zero return from fsck_walk() for an error.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.3:
Change mentions of "git programs" to "git commands"
Documentation: merge: one <remote> is required
help.c: give correct structure's size to memset()
'git push' failing because of non-fast forward is a very common situation,
and a beginner does not necessarily understand "fast forward" immediately.
Add a new section to the git-push documentation and refer them to it.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
<filepattern>... is optional (e.g. when the --all or --update
options are used) so use square brackets in the synopsis.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of the docs and printouts refer to "commands" when discussing what
the end users call via the "git" top-level program. We should refer them
as "git programs" when we discuss the fact that the commands are
implemented as separate programs, but in other contexts, it is better to
use the term "git commands" consistently.
Signed-off-by: Ori Avtalion <ori@avtalion.name>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge only requires one <remote>, so "<remote>..." should be used in the
synopsis (and not "<remote> <remote>...").
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These two structures are of the same type, but we'd better be consistent.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Avoid git ending with this message:
"Patch format is not supported."
With improved error message in the format detection failure case by
Giuseppe Bilotta.
Signed-off-by: Nicolas Sebrecht <ni.s@laposte.net>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We traditionally allowed a mbox file or a directory name of a maildir (but
never an individual file inside a maildir) to be given to "git am". Even
though an individual file in a maildir (or more generally, a piece of
RFC2822 e-mail) is not a mbox file, it contains enough information to
create a commit out of it, so there is no reason to reject one. Running
mailsplit on such a file feels stupid, but it does not hurt.
This builds on top of a5a6755 (git-am foreign patch support: introduce
patch_format, 2009-05-27) that introduced mailbox format detection. The
codepath to deal with a mbox requires it to begin with "From " line and
also allows it to begin with "From: ", but a random piece of e-mail can
and often do begin with any valid RFC2822 header lines.
Instead of checking the first line, we extract all the lines up to the
first empty line, and make sure they look like e-mail headers.
A test is added to t4150 to demonstrate this feature.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If your name is, say, Üwë, you want your cover letters to appear
correctly. Convince format-patch to mark it as 8-bit.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function is useful outside of log-tree.c, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The script was looking for something that matched the '^our $gitbin'
regex, which no longer exists in gitweb.cgi.
Now it looks for 'MOD_PERL', which should be on the line that checks
to see if the script is running in a mod_perl environment.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously when merging directly from a local tracking
branch like:
git merge origin/master
The merge message said:
Merge commit 'origin/master'
* commit 'origin/master':
...
Instead, let's be more explicit about what we are merging:
Merge remote branch 'origin/master'
* origin/master:
...
We accomplish this by recognizing remote tracking branches
in git-merge when we build the simulated FETCH_HEAD output
that we feed to fmt-merge-msg.
In addition to a new test in t7608, we have to tweak the
expected output of t3409, which does such a merge.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we have both a tag and a branch named "foo", then calling
"git merge foo" will warn about the ambiguous ref, but merge
the tag.
When generating the commit message, though, we simply
checked whether "refs/heads/foo" existed, and if it did,
assumed it was a branch. This led to the statement "Merge
branch 'foo'" in the commit message, which is quite wrong.
Instead, we should use dwim_ref to find the actual ref used,
and describe it appropriately.
In addition to the test in t7608, we must also tweak the
expected output of t4202, which was accidentally triggering
this bug.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calling "git merge $X", we automatically generate a
commit message containing something like "Merge branch
'$X'". This test script checks that those messages say what
they should, and exposes a failure when merging a refname
that is ambiguous between a tag and a branch.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When making a histogram of delta chain length in the pack, the program
collects number of objects whose delta depth exceeds the MAX_CHAIN limit
in histogram[0], and showed it as the number of items that exceeds the
limit correctly. HOWEVER, it also showed the same number labeled as
"chain length = 0".
In fact, we are not showing the number of objects whose chain length is
zero, i.e. the base objects. Correct this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test ignored the exit status from verify pack command, and also relied
on not seeing any delta chain statistics.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I have 4GB of RAM on my system which should, in theory, be quite enough
to repack a 600 MB repository. However the unbounded delta cache size
always pushes it into swap, at which point everything virtually comes to
a halt. So unbounded caches are never a good idea.
A default of 256MB should be a good compromize between memory usage and
speed where medium sized repositories are still likely to fit in the
cache with a reasonable memory usage, and larger repositories are going
to take quite some time to repack already anyway.
While at it, clarify the associated config variable documentation
entries a bit.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Call to_utf8 when parsing author and committer names, otherwise they will appear
with bad encoding if they written by using chop_and_escape_str.
Signed-off-by: Zoltán Füzesi <zfuzesi@eaglet.hu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option --merge was missing for submodule update and --cached for
submodule summary.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Importing the popen2 module in Python-2.6 results in the
"DeprecationWarning: The popen2 module is deprecated. Use the
subprocess module." message. The module itself isn't used in fact, so
just removing it solves the problem.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Configuration values are expected to be quoted when they have leading or
trailing whitespace, but inner whitespace should be kept verbatim even if
the value is not quoted. This is already documented in git-config(1), but
the code caused inner whitespace to be collapsed to a single space,
breaking, for example, clones from a path that has two consecutive spaces
in it, as future fetches would only see a single space.
Reported-by: John te Bokkel <tanj.tanj@gmail.com>
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
