Instead of calling close_lock_file() and commit_lock_file() directly,
which take a struct lock_file argument, add two new functions:
close_ref() and commit_ref(), which handle calling the previous
lock_file functions and modifying the ref_lock structure.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The lockfile API is a handy way to obtain a file that is cleaned
up if you die(). But sometimes you would need this sequence to
work:
1. hold_lock_file_for_update() to get a file descriptor for
writing;
2. write the contents out, without being able to decide if the
results should be committed or rolled back;
3. do something else that makes the decision --- and this
"something else" needs the lockfile not to have an open file
descriptor for writing (e.g. Windows do not want a open file
to be renamed);
4. call commit_lock_file() or rollback_lock_file() as
appropriately.
This adds close_lock_file() you can call between step 2 and 3 in
the above sequence.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have nice set of placeholders, but nobody stepped in to fill
the gap in the API documentation, so I am doing it myself.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes write_ref_sha1() more careful: it actually checks the SHA1 of
the ref it is updating, and refuses to update a ref with an object that it
cannot find.
Perhaps more importantly, it also refuses to update a branch head with a
non-commit object. I don't quite know *how* the stable series maintainers
were able to corrupt their repository to have a HEAD that pointed to a tag
rather than a commit object, but they did. Which results in a totally
broken repository that cannot be cloned or committed on.
So make it harder for people to shoot themselves in the foot like that.
The test t1400-update-ref.sh is fixed at the same time, as it
assumed that the commands involved in the particular test would
not care about corrupted repositories whose refs point at
nonexistant bogus objects. That assumption does not hold true
anymore.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since having non-commits in branches is a no-no, and just means you cannot
commit on them, let's make fsck tell you when a branch is bad.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When creating the commit object, be a whole lot more careful about making
sure that the parent lines really are valid parent lines. Check things
like MERGE_HEAD having proper SHA1 lines in it, and double-check that all
the parents exist and are actually commits.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are two heuristics in Git to detect whether a file is binary
or text. One in xdiff-interface.c (which is taken from GNU diff)
relies on existence of the NUL byte at the beginning. However,
convert.c used a different heuristic, which relied on the percent
of non-printable symbols (less than 1% for text files).
Due to differences in detection whether a file is binary or not,
it was possible that a file that diff treats as binary could be
treated as text by CRLF conversion. This is very confusing for a
user who sees that 'git diff' shows the file as binary expects it
to be added as binary.
This patch makes is_binary to consider any file that contains at
least one NUL character as binary, to ensure that the heuristics
used for CRLF conversion is tighter than what is used by diff.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we apply a hunk in either direction this may change the file's
status. For example if a file is completely unstaged, and has at
least two hunks in it and the user stages one hunk the file will
change from "Modified, not staged" to "Portions staged for commit".
Resetting the file path causes our trace on this variable to fire;
that trace is used to update the file header in the diff viewer to
the file's current status.
Noticed by Johannes Sixt.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Often users setup a few source files and get a project rolling
before they create a Git repository for it. In such cases the
core Git tools allow users to initialize a new repository by
simply running `git init` at the desired root level directory.
We need to allow the same situation in git-gui; if the user is
trying to make a new repository we should let them do that to any
location they chose. If the directory already exists and already
has files contained within it we still should allow the user to
create a repository there. However we still need to disallow
creating a repository on top of an existing repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Here are some of the choices made to translate Git Gui to french:
- commit -> "commit" (noun) or "commiter" (verb)
- stage (index) -> "pré-commit" (noun) or "pré-commiter" (verb)
- (re)scan -> "(re)synchroniser"
- reset -> "réinitialiser"
- checkout -> "emprunt" (noun) or "emprunter" (verb)
- revision expression -> "expression de révison"
I am not completely happy with these, but it's a start...
[sp: Inserted a missing LF in message on line 466]
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Change translation of "clone" back to "klonen" because "kopieren" is a
much broader term than this particular git action.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I broke this extremely cool feature in 1ac17950,
but it is rather easy to fix this. Sorry for that.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
"revert" translated as "verwerfen".
"hunk" translated as "Kontext".
Several menu items reworded to be shorter.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The codepath to prepare index files for the temporary and next
index file was closing file descriptor it obtained from the
lockfile API by hand, without letting the API know that the fd
should not be doubly closed.
This is not usually a problem (except it may get EBADFD) but if
we opened another fd for an entirely unrelated purpose (say, an
fd used to mmap a packfile) between the time we close the fd to
the index file and the time we commit or rollback the lockfile
(causing it to also try closing the recorded fd), the lockfile
API will close an incorrect file descriptor that is still used
for an entirely unrelated purpose.
There's four close(fd) calls in prepare_index() and they're all
incorrect. The open fd's are cleaned up in rollback_index_files() and
shouldn't be closed manually. The patch below gets rid of the extra
close() calls and should fix the problem.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch improves all of the popen calls in hg-to-git.py by specifying the
template 'hg log' should use instead of calling 'hg log' and grepping for the
desired data.
Signed-off-by: Mark Drago <markdrago@gmail.com>
Acked-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These options are listed in the manpage (aliases for --tags/--heads) but they
were not handled.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some of the stuff that commit 31c0eaa8cc
added to drawvisible isn't appropriate to do when we have no commits,
and this was causing a Tcl error if gitk was invoked in such a fashion
that no commits were selected. This fixes it by bailing out of
drawvisible early if there are no commits displayed.
Bug reported by Johannes Sixt.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This fixes a bug where changing the commit range or file list for an
existing view and then clicking OK would cause gitk to go into an
infinite loop. The problem was that newviewok was invoking reloadcommits
via "run reloadcommits", but reloadcommits wasn't explicitly returning
0, and whatever it was returning was causing dorunq to run it over
and over again. This fixes it by making reloadcommits return 0.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This makes gitk select the new commit when cherry-picking, and select
the new checked-out head when resetting or checking out a branch.
This feels more natural because the user is usually more interested
in that commit now than whatever was selected before.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The command repeats "Rebasing (1/1)" many times even when
there is only one task remaining, because mark_action_done() is
called to skip comment and empty lines in the TODO file.
This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rerere.enabled is _not_ on by default. The command is enabled if rr-cache
exists even when rerere.enabled is missing, and enabled or disabled by
explicitly setting the rerere.enabled variable.
This reverts commit 16335fdd7a.
We are calling overlay_tree_on_cache() which does use CE_UPDATE
flag to mark duplicated entries, which is the same as the
codepath in git-ls-files with its --with-tree option.
Because the pathname ce->name is given to path_list_insert()
which does not allow duplicates, there is no breakage either way
from the correctness point of view in this codepath, unlike the
one in ls-files. But avoiding unnecessary processing with a
single bit check is certainly better.
This hook thought to have found a conflict marker any time it saw
a 7-character combination of any of the characters '<>=' at the
beginning of a line, whereas it should only look for the *same*
character to appear repeatedly.
Also, restrict it to match exactly 7 times, to avoid matching the
underlining with '='-characters often used in documentation.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git cvsimport was the last tool to use repo-config instead of config. Update
it to use plain git config.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Switch all git command calls to use the git (space) command format, and
remove the use of git-repo-config in place of git config.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2888605c64 (builtin-commit: fix
partial-commit support) mindlessly cut and pasted from
builtin-ls-files.c, and included a part that was meant to
exclude redundant path after "ls-files --with-tree" overlayed
the HEAD commit on top of the index. This logic does not apply
to what git-commit does and should not have been copied, even
though it would not hurt.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only Ctrl "=" was bound to increase the font size, probably because
English keyboards have the plus on the same key as the equal sign.
However, not the whole world is English, and at least with some
other keyboard layouts, Ctrl "+" did not work as documented.
Noticed by Stephan Hennig.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When running "git commit paths" to create a partial commit, we
used to carefully build the temporary index so that we do not
lose the cached stat information. The rewrite of the command in
C lost it by carelessly using read_tree().
This resurrects the earlier behaviour to keep the cached stat
information as much as possible by using one-tree merge logic.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of selecting the first commit that appears, this makes gitk
select the currently checked out head, if the user hasn't explicitly
selected some other commit by the time it appears. If the head hasn't
appeared by the time the graph is complete, then we select the first
real commit.
This applies both for graph updates and when the graph is being read
in initially.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The "seen" variable is used by match_pathspec, and must have
as many elements as there are in the given pathspec. We
create the pathspec either from the command line arguments
_or_ from just the current prefix.
Thus allocating "seen" based upon just argc is wrong, since
if argc == 0, then we still have one pathspec, the prefix,
but we don't allocate any space in "seen".
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: İsmail Dönmez <ismail@pardus.org.tr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Repositories generated by svnsync cannot be relied on to have
properly set revprops without newlines in UUIDs and URLs. There
may be broken versions of svnsync out there that append extra
newlines to UUIDs, or the revprops could've been changed by
repository administrators at any time, too.
At least one repository we've come across has an embedded
newline erroneously set in the svnsync-uuid prop. This is bad
because the trailing newline is taken as another record by the
Git.pm library, and the wantarray detection causes tmp_config()
to return an array with an empty-but-existing second element.
We will now strip leading and trailing whitespace both before
setting and after reading the uuid and url for svnsync values.
We will also force tmp_config to return a single scalar when
reading existing values.
SVN UUIDs should never have whitespace in them, and SVN
repository URLs should be URI-escaped, so neither of those
values we ever see in git-svn should actually have whitespace
in them.
Thanks to Dennis Schridde for the bug report and Junio for
helping diagnose this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The make_disporder function has an optimization where it assumed that
if displayorder was already long enough and the first entry in it for
a particular arc was non-null, then the whole arc was present. This
turns out not to be true in some circumstances, since we can add a
commit to an arc (which truncates displayorder to the previous end of
that arc), then call make_disporder for later arcs (which will pad
displayorder with null elements), then call make_disporder for the
first arc - which won't update the null elements.
This fixes it by changing the optimization to check the last element
for the arc instead of the first.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This documents the default values of gc.auto, gc.autopacklimit
fetch.unpacklimit, receive.unpacklimit and transfer.unpacklimit.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The po2msg.sh script and the .gitignore in the po directory have been
shamelessly copied from the current git-gui. This enables the top
level "make NO_MSGFMT" to work consistently for git across the git-gui
and gitk sub-projects.
This is the same effective patch that has previously been posted as a
git.git patch which more succinctly described the copying of
po/.gitignore and po/po2msg.sh from git-gui.
Signed-off-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We somehow called deflateEnd() on a stream that we have called
deflateEnd() on already.
In fact, the second deflateEnd() has always been returning
Z_STREAM_ERROR. We just never checked the error return from
that particular deflateEnd().
The first one returns 0 for success. We might want to tighten
the check even more to check that.
Noticed by Marco.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Despite the name, the --revs-only flag to git rev-parse doesn't make
it output only revision IDs. It makes it output only arguments that
are suitable for giving to git rev-list. So make start_rev_list and
updatecommits cope with arguments output by git rev-parse that aren't
revision IDs. This way we won't get an error when an argument such as
"-300" has been given to gitk and the view is updated.
Signed-off-by: Paul Mackerras <paulus@samba.org>
I noticed some unchecked writes. This fixes them.
* bundle.c (create_bundle): Die upon write failure.
* fast-import.c (keep_pack): Die upon write or close failure.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
