This error message is very confusing---it doesn't tell the user
anything about how to fix the situation. And the actual fix
for the situation ("git bisect reset") does a checkout of a
potentially random branch, (compared to what the user wants to
be on for the bisect she is starting).
The simplest way to eliminate the confusion is to just make
"git bisect start" do the cleanup itself. There's no significant
loss of safety here since we already have a general safety in
the form of the reflog.
Note: We preserve the warning for any cogito users. We do this
by switching from .git/head-name to .git/BISECT_START for the
extra state, (which is a more descriptive name anyway).
Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When expiring reflog entries, a new temporary log is written which contains
only the entries to retain. After it is written, it is renamed to replace
the existing reflog. Currently, we check that writing of the new log is
successful and print a message on failure, but the original reflog is still
replaced with the new reflog even on failure. This patch causes the
original reflog to be retained if we fail when writing the new reflog.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix a regression introduced by
1ca3d6e (send-email: squelch warning due to comparing undefined $_ to "")
where if the user was prompted for an initial In-Reply-To and didn't
provide one, messages would be sent out with an invalid In-Reply-To of
"<>"
Also add test cases for the regression and the fix. A small modification
was needed to allow send-email to take its replies from stdin if the
environment variable GIT_SEND_EMAIL_NOTTY is set.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using the '-w $cvsdir' option to cvsexportcommit, it will chdir into
$cvsdir before executing several other git commands. If $GIT_DIR is set to
a relative path (e.g. '.'), the git commands executed by cvsexportcommit
will naturally fail.
Therefore, ensure that $GIT_DIR is absolute before the chdir to $cvsdir.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The testcase verifies that 'git cvsexportcommit' functions correctly when
the '-w' option is used, and GIT_DIR is set to a relative path (e.g. '.').
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On hitting an edit point in an interactive rebase, git should prompt
the user to run "git rebase --continue"
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git svn log mimics the timezone converting behaviour of svn log, but
this was undocumented.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For some reason, t5505-remote was setting GIT_CONFIG to .git/config
and exporting it. This should have been no-op, as test framework did
the same for a long time anyway.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit 8c1ce0f46b filter-branch fails
when a <command> has a non-zero exit status. This commit makes it clear
in the documentation and also fixes the parent-filter example, that was
incorrectly returning non-zero when the commit being tested wasn't the
one to be rewritten.
Signed-off-by: Caio Marcelo de Oliveira Filho <cmarcelo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A non-empty line containing no spaces should be treated by --parseopt as
an option group header, but was causing a bus error. Also added a test
script for rev-parse --parseopt.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally by Kristian Hï¿œgsberg; I fixed the conversion of rerere, which
had a different API.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were no example on how to edit commit messages, so add an msg-filter
example.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fast-import file format does not expect leading '0' in front
of a file mode; that is we want '100644' and '0100644'.
Thanks to Ian Clatworthy of the Bazaar project for noticing the
difference in output/input.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the SHA-1 we are requesting the object for does not exist in
the object database we get a NULL back. Accessing the type from
that is not likely to succeed on any system.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Cygwin we have to use git-archive.exe as the target, otherwise
running 'make dist' does not compile git-archive in the current
directory. That may cause 'make dist' to fail on a clean source
tree that has never been built before.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Focus insertion point at end of strings in repository chooser
git-gui: Avoid hardcoded Windows paths in Cygwin package files
git-gui: Default TCL_PATH to same location as TCLTK_PATH
git-gui: Paper bag fix error dialogs opening over the main window
git-gui: Ensure error dialogs always appear over all other windows
git-gui: relax "dirty" version detection
git-gui: support Git Gui.app under OS X 10.5
We were returning the _address of_ the stored item (or NULL)
instead of the item itself. While this sort of indirection
is useful for insertion (since you can lookup and then
modify), it is unnecessary for read-only lookup. Since the
hash code splits these functions between the internal
lookup_hash_entry function and the public lookup_hash
function, it makes sense for the latter to provide what
users of the library expect.
The result of this was that the index caching returned bogus
results on lookup. We unfortunately didn't catch this
because we were returning a "struct cache_entry **" as a
"void *", and accidentally assigning it to a "struct
cache_entry *".
As it happens, this actually _worked_ most of the time,
because the entries were defined as:
struct cache_entry {
struct cache_entry *next;
...
};
meaning that interpreting a "struct cache_entry **" as a
"struct cache_entry *" would yield an entry where all fields
were totally bogus _except_ for the next pointer, which
pointed to the actual cache entry. When walking the list, we
would look at the bogus "name" field, which was unlikely to
match our lookup, and then proceed to the "real" entry.
The reading of bogus data was silently ignored most of the
time, but could cause a segfault for some data (which seems
to be more common on OS X).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When selecting a local working directory for a new repository or a
location to clone an existing repository into we now set the insert
point at the end of the selected path, allowing the user to type in
any additional parts of the path if they so desire.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we are being built by the Cygwin package maintainers we need to
embed the POSIX path to our library files and not the Windows path.
Embedding the Windows path means all end-users who install our Cygwin
package would be required to install Cygwin at the same Windows path
as the package maintainer had Cygwin installed to. This requirement
is simply not user-friendly and may be infeasible for a large number
of our users.
We now try to auto-detect if the Tcl/Tk binary we will use at runtime
is capable of translating POSIX paths into Windows paths the same way
that cygpath does the translations. If the Tcl/Tk binary gives us the
same results then it understands the Cygwin path translation process
and should be able to read our library files from a POSIX path name.
If it does not give us the same answer as cygpath then the Tcl/Tk
binary might actually be a native Win32 build (one that is not
linked against Cygwin) and thus requires the native Windows path
to our library files. We can assume this is not a Cygwin package
as the Cygwin maintainers do not currently ship a pure Win32 build
of Tcl/Tk.
Reported on the git mailing list by Jurko Gospodnetić.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most users set TCLTK_PATH to tell git-gui where to find wish, but they
fail to set TCL_PATH to the same Tcl installation. We use the non-GUI
tclsh during builds so headless systems are still able to create an
index file and create message files without GNU msgfmt. So it matters
to us that we find a working TCL_PATH at build time.
If TCL_PATH hasn't been set yet we can take a better guess about what
tclsh executable to use by replacing 'wish' in the executable path with
'tclsh'. We only do this replacement on the filename part of the path,
just in case the string "wish" appears in the directory paths. Most of
the time the tclsh will be installed alongside wish so this replacement
is a sensible and safe default.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the main window is the only toplevel we have open then we
don't have a valid grab right now, so we need to assume the
best toplevel to use for the parent is ".".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are opening an error dialog we want it to appear above all of
the other windows, even those that we may have opened with a grab
to make the window modal. Failure to do so may allow an error
dialog to open up (and grab focus!) under an existing toplevel,
making the user think git-gui has frozen up and is unresponsive,
as they cannot get to the dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The git-add documentation did not state clearly that the -u switch
updates only the tracked files that are in the current directory and
its subdirectories.
Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When cloning a remote repository which's HEAD refers to a nonexistent
ref, git-clone cloned all existing refs, but failed to write the
configuration for 'remote'. Now it detects the dangling remote HEAD,
refuses to checkout any local branch since HEAD refers to nowhere, but
properly writes the configuration for 'remote', so that subsequent
'git fetch's don't fail.
The problem was reported by Daniel Jacobowitz through
http://bugs.debian.org/466581
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The check to see if initial_reply_to is defined was also comparing $_ to
"" for a reason I cannot ascertain (looking at the commit which made the
change didn't provide enlightenment), but if $_ is undefined, perl
generates a warning.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes my favorite annoyance with the git rpm packaging: don't pull
in tla when I say yum install git! You wouldn't expect yum install gcc
to pull in gcc-gfortran, right?
With this change, and blanket 'yum update' will automatically pull in the
new 'git' package and push out the old 'git-core', and if the old 'git'
package was installed 'git-all' will be pulled in instead. A couple of
things do break though: 'yum update git-core', because yum behaves
differently when given a specific package name - it doesn't follow obsoletes.
Instead, 'yum install git' will pull in the new git rpm, which will then
push out the old 'git-core'. Similarly, to get the newest version of
the meta package, 'yum install git-all' will install git-all, which then
pushes out the old 'git' meta package.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The output was meant to be a balance of self-explanatory and
terse. In case we have erred too far on the terse side, it
doesn't hurt to explain in more detail what each line means.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous text was correct, but it was easy to miss the
fact that we are talking about "matching" refs. That is, the
text can be parsed as "we push the union of the sets
of remote and local heads" and not "we push the intersection
of the sets of remote and local heads". (The former actually
doesn't make sense if you think about it, since we don't
even _have_ some of those heads). A careful reading would
reveal the correct meaning, but it makes sense to be as
explicit as possible in documentation.
We also explicitly use and introduce the term "matching";
this is a term discussed on the list, and it seems useful
to for users to be able to refer to this behavior by name.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing message indicates that an error occured during
push, but it is unclear whether _any_ refs were actually
pushed (even though the status table above shows which were
pushed successfully and which were not, the message "failed
to push" implies a total failure). By indicating that "some
refs" failed, we hopefully indicate to the user that the
table above contains the details.
We could also put in an explicit "see above for details"
message, but it seemed to clutter the output quite a bit
(both on a line of its own, or at the end of the error line,
which inevitably wraps).
This could also be made more fancy if the transport
mechanism passed back more details on how many refs
succeeded and failed:
error: failed to push %d out of %d refs to '%s'
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git gui" would complain at launch if the local version of Git was
"1.5.4.2.dirty". Loosen the regular expression to look for either
"-dirty" or ".dirty", thus eliminating spurious warnings.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The option is accepted, but that is the only form selected-paths
variant of the reset command takes, so there is no point mentioning it.
And while we're at it, use the dashless git call.
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 3368d11 (Remove unnecessary git-rm --cached reference from
status output), the status output marks the "Added but not yet
committed" section as "Changes to be committed".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There may still be some entries from the original index that
should be discarded before we show the status. In
particular, if a file was added in the index but not
included in the partial commit, it would still show up in
the status listing as staged for commit.
Ultimately the correct fix is to keep the two states in
separate index_state variables. Then we can avoid having
to reload the cache from the temporary file altogether, and
just point wt_status_print at the correct index.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command used a very old fashioned construct to extract
filenames out of diff-index and ended up corrupting the output.
We can simply use --name-only and pipe into --stdin mode of
update-index. It's been like that for the past 2 years or so
since a94d994 (update-index: work with c-quoted name).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There was a goto, and while it is not half as harmful as some people
believe, it was unnecessary here. So remove it for readability.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When encountering submodules in a tree, http-push should not try sending
the respective object. Instead, it should ignore it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before objects are sent, the respective ref is locked. However,
without this patch, the lock is lifted before the last object for
that ref was sent. As a consequence, the lock data was accessed
after the lock structure was free()d.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
c1795bb (Unify whitespace checking) incorrectly made the
checking function return without incrementing the line numbers
when there is no whitespace problem is found on a '+' line.
This resurrects the earlier behaviour.
Noticed and reported by Jay Soffian. The test script was stolen
from Jay's independent fix.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix a bug in the hg-to-git convertor introduced by commit
1bc7c13af9: when searching the changeset
parents, 'hg log' returns an extra space at the end of the line, which
confuses the .split(' ') based tokenizer:
Traceback (most recent call last):
File "hg-to-git.py", line 123, in <module>
hgchildren[mparent] += ( str(cset), )
KeyError: ''
Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function is intended to be fed one logical line at a time to
inspect, but a QP encoded raw input line can have more than one
lines, just like BASE64 encoded one.
Quoting LF as =0A may be unusual but RFC2045 allows it.
The issue was noticed and fixed by Jay Soffian. JC added a test
to protect the fix from regressing later.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also use "git_config_string" to simplify code where "cmd" is set.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
