The "-k" option to "git mv" should allow specifying multiple untracked
files. Currently, multiple untracked files raise an assertion if they
appear consecutively as arguments. Fix this by decrementing the loop
index after removing one entry from the array of arguments.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add test cases for ignoring nonexisting and untracked files using the -k
option to "git mv". There is one known breakage related to multiple
untracked files specfied as consecutive arguments.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"S_IFREG | mode" makes only sense for 0644 and 0755.
Even though doing (S_IFREG | mode) may not hurt when mode is any other
supported value, that is only true because S_IFREG mode bit happens to
be already on for S_IFLNK or S_IFGITLINK.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The error message to Error::Simple() must be passed as a single argument.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cb/maint-merge-recursive-fix:
merge-recursive: do not clobber untracked working tree garbage
modify/delete conflict resolution overwrites untracked file
Conflicts:
builtin-merge-recursive.c
Prior to that, if the user chose "squash" as a first action, the stderr
looked like:
grep: /home/madcoder/dev/scm/git/.git/rebase-merge/done: No such file or directory
Cannot 'squash' without a previous commit
Now the first line is gone.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We attempt to give an explanation of the status of the files in this
directory.
Signed-off-by: jidanni <jidanni@jidanni.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without any explicit -o parameter, we correctly avoided putting the
resulting patch output to the toplevel. We should do the same when
the user gave a relative pathname to be consistent with this case.
Noticed by Cesar Eduardo Barros.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even without --root specified, if the range given on the command line
happens to include a root commit, we should include its patch text in the
output.
This fix deliberately ignores log.showroot configuration variable because
"format-patch" and "log -p" can and should behave differently in this
case, as the former is about exporting a part of your history in a form
that is replayable elsewhere and just giving the commit log message
without the patch text does not make any sense for that purpose.
Noticed and fix originally attempted by Nathan W. Panike; credit goes to
Alexander Potashev for injecting sanity to my initial (broken) fix that
used the value from log.showroot configuration, which was misguided.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using "git status -v", the diff output wasn't colored, even though
color.ui was set. Only when setting color.diff it worked.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using "git commit" and there was nothing to commit (the editor
wasn't launched), the status output wasn't colored, even though color.ui
was set. Only when setting color.status it worked.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We forgot to move to the next argument when parsing -q, getting stuck
in an endless loop.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We need to parse options before we can see if --exit-code was
provided.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Accept -- as an "end of options" marker even when using --no-index.
Previously, the -- triggered a "normal" index/tree diff and subsequently
failed because of the unrecognized (in that mode) --no-index.
Note that the second loop can treat '--' as a normal option, because
the preceding checks ensure it is the third-to-last argument.
While at it, fix the parsing of "-q" option in --no-index mode as well.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The commit message parser of git shortlog used to treat only the first
non-empty line of the commit message as the subject. Other log commands
(e.g. --pretty=oneline) show the whole first paragraph instead (unwrapped
into a single line).
For consistency, this patch borrows format_subject() from pretty.c to
make shortlog do the same.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the only caller, verify_absent, relies on the fact that o->pos
points to the next index entry anyways, there is no need to recompute
its position.
Furthermore, if a nondirectory entry were found, this would return too
early, because there could still be an untracked directory in the way.
This is currently not a problem, because verify_absent is only called
if the index does not have this entry.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 0cf73755 (unpack-trees.c: assume submodules are clean during
check-out) changed an argument to verify_absent from 'path' to 'ce',
which is however shadowed by a local variable of the same name.
The bug triggers if verify_absent is used on a tree entry, for which
the index contains one or more subsequent directories of the same
length. The affected subdirectories are removed from the index. The
testcase included in this commit bisects to 55218834 (checkout: do not
lose staged removal), which reveals the bug in this case, but is
otherwise unrelated.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 203a2fe1 (Allow callers of unpack_trees() to handle failure)
changed the "die on error" behavior to "return failure code".
verify_absent did not handle errors returned by
verify_clean_subdirectory, however.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tar handles switches with and witout preceding '-', but the
documentation should be consistent nonetheless.
Signed-off-by: Henrik Austad <henrik@austad.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The Linux kernel and Emacs are both spelled capitalized
Signed-off-by: Henrik Austad <henrik@austad.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Mac OS X and possibly BSDs, /bin/pwd reads PWD from the environment if
available and shows the logical path by default rather than the physical
one.
Unset PWD before running /bin/pwd in both cd_to_toplevel and its test.
Still use the external /bin/pwd because in my Bash on Linux, the builtin
pwd prints the same result whether or not PWD is set.
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
Tested-by: Wincent Colaiuta <win@wincent.com> (on Mac OS X 10.5.5)
Tested-by: Marcel Koeppen <git-dev@marzelpan.de> (on Mac OS X 10.5.6)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It comes quite as a surprise to an unsuspecting Git user that calling
"git add submodule/file" (which is a mistake, alright) _removes_
the submodule in the index, and adds the file. Instead, complain loudly.
While at it, be nice when the user said "git add submodule/" which is
most likely the consequence of tab-completion, and stage the submodule,
instead of trying to add the contents of that directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It seems that Cygwin sets the variable SESSIONNAME when an interactive
desktop session is running, and does not set it when you log in via ssh.
So we can use this variable to determine whether to run gitk or git log
in git bisect view.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git checkout -b newbranch $commit^{tree}" mistakenly created a new branch
rooted at the current HEAD, because in that case, the two structure fields
used to see if the command was invoked without any argument (hence it
needs to default to checking out the HEAD) were populated incorrectly.
Upon seeing a command line argument that we took as a rev, we should store
that string in new.name, even if that does not name a commit. This will
correctly trigger the existing safety logic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
A git patch that does not change the executable bit records the mode bits
on its "index" line. "git apply" used to interpret this mode exactly the
same way as it interprets the mode recorded on "new mode" line, as the
wish by the patch submitter to set the mode to the one recorded on the
line.
The reason the mode does not agree between the submitter and the receiver
in the first place is because there is _another_ commit that only appears
on one side but not the other since their histories diverged, and that
commit changes the mode. The patch has "index" line but not "new mode"
line because its change is about updating the contents without affecting
the mode. The application of such a patch is an explicit wish by the
submitter to only cherry-pick the commit that updates the contents without
cherry-picking the commit that modifies the mode. Viewed this way, the
current behaviour is problematic, even though the command does warn when
the mode of the path being patched does not match this mode, and a careful
user could detect this inconsistencies between the patch submitter and the
patch receiver.
This changes the semantics of the mode recorded on the "index" line;
instead of interpreting it as the submitter's wish to set the mode to the
recorded value, it merely informs what the mode submitter happened to
have, and the presense of the "index" line is taken as submitter's wish to
keep whatever the mode is on the receiving end.
This is based on the patch originally done by Alexander Potashev with a
minor fix; the tests are mine.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The repository constructor mistakenly rewrote a Directory parameter that
Perl happens to evaluate to false (e.g. "0") to ".".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When there is no grace period before pruning unreferenced objects, it is
pointless to push those objects in their loose form just to delete them
right away.
Also be more explicit about the possibility of using "now" in the
gc.pruneexpire config variable (needed for the above behavior to
happen).
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of listing short option (e.g. "-U<n>") as a shorthand for its
longer counterpart (e.g. "--unified=<n>"), list the synonyms together. It
saves one indirection to find what the reader wants.
Signed-off-by: jidanni <jidanni@jidanni.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This variable was added in 5f8b9fc (git-send-email: add a new
sendemail.cc configuration variable, 2008-04-27), but is not yet refered
to by the documentation.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When $filter was empty, the path passed to check_export_ok would
contain an extra '/', which some implementations of export_auth_hook
are sensitive to.
It makes more sense to fix this here than to handle the special case
in each implementation of export_auth_hook.
Signed-off-by: Devin Doucette <devin@doucette.cc>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"Assume unchanged" bit means "please pretend that I have never touched
this file", so if user removes the file, we should not care.
This patch teaches "git grep" to use cache version in such
situations. External grep case has not been fixed yet. But given that
on the platform that CE_VALID bit may be used like Windows, external
grep is not available anyway, I would wait for people to raise their
hands before touching it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
