We have a number of badly checked read() calls. Often we are
expecting read() to read exactly the size we requested or fail, this
fails to handle interrupts or short reads. Add a read_in_full()
providing those semantics. Otherwise we at a minimum need to check
for EINTR and EAGAIN, where this is appropriate use xread().
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We recently introduced a write_in_full() which would either write
the specified object or emit an error message and fail. In order
to fix the read side we now want to introduce a read_in_full()
but without an error emit. This patch cleans up the naming
of this family of calls:
1) convert the existing write_or_whine() to write_or_whine_pipe()
to better indicate its pipe specific nature,
2) convert the existing write_in_full() calls to write_or_whine()
to better indicate its nature,
3) introduce a write_in_full() providing a write or fail semantic,
and
4) convert write_or_whine() and write_or_whine_pipe() to use
write_in_full().
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since we are talking about allowing potentially incompatible UI
changes in v1.5.0 iff the change improves the general situation,
I would say why not.
There is --no-utf8 flag to avoid re-coding from botching the log
message just in case, but we may not even need it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Prevent a client from overrunning the on stack ref buffer.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is bad manners to leave these sizable files
around when we are done with them.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes the earlier "wait for 10 minutes before importing" safety
overridable with "-a(ll)" flag, and adds necessary documentation.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some users apparently create local heads with the same basename
as the remote branch they're tracking.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also, document --{trunk,branches,tags} options while we're
documenting multi-init options.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Clarify definition of "reachable" (what chain?)
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes newly introduced bug when the incremental cycle edge revisions
are imported twice.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this patch, cvsimport will skip commits made
in the last 10 minutes. The recent-ness test is of
5 minutes + cvsps fuzz window (5 minutes default).
When working with a CVS repository that is in use,
importing commits that are too recent can lead to
partially incorrect trees. This is mainly due to
- Commits that are within the cvsps fuzz window may later
be found to have affected more files.
- When performing incremental imports, clock drift between
the systems may lead to skipped commits.
This commit helps keep incremental imports of in-use
CVS repositories sane.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove superfluous trailing "|" separator from difftree part of "commit"
view for new files (created in given commit).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since git-reset has learned restoring the absence of paths git-rm --cached is
no longer necessary. Therefore remove it from the cached content header hint.
Also remove the unfortunate wording 'Cached' from the header itself.
Signed-off-by: Jürgen Rühle <j-r@online.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make "init" the equivalent of "init-db". This should make first GIT
impression a little more friendly.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* sp/mmap: (27 commits)
Spell default packedgitlimit slightly differently
Increase packedGit{Limit,WindowSize} on 64 bit systems.
Update packedGit config option documentation.
mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
pack-objects: fix use of use_pack().
Fix random segfaults in pack-objects.
Cleanup read_cache_from error handling.
Replace mmap with xmmap, better handling MAP_FAILED.
Release pack windows before reporting out of memory.
Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
Test suite for sliding window mmap implementation.
Create pack_report() as a debugging aid.
Support unmapping windows on 'temporary' packfiles.
Improve error message when packfile mmap fails.
Ensure core.packedGitWindowSize cannot be less than 2 pages.
Load core configuration in git-verify-pack.
Fully activate the sliding window pack access.
Unmap individual windows rather than entire files.
Document why header parsing won't exceed a window.
Loop over pack_windows when inflating/accessing data.
...
Conflicts:
cache.h
pack-check.c
This is shorter and easier to read, and also makes sure the
constant expression does not overflow integer range.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jr/status:
Improve cached content header of status output
Support --amend on initial commit in status output
Improve "nothing to commit" part of status output
Clarify syntax and role of git-add in status output
When <path> exists in the index (either merged or unmerged), and
<tree> does not have it, git-reset should be usable to restore
the absense of it from the tree. This implements it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the way diffcore represents an unmerged pair
somewhat. It used to be that entries with mode=0 on both sides
were used to represent an unmerged pair, but now it has an
explicit flag. This is to allow diff-index --cached to report
the entry from the tree when the path is unmerged in the index.
This is used in updating "git reset <tree> -- <path>" to restore
absense of the path in the index from the tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not replace /dev/null in two-line from-file/to-file diff header for
split patches ("split" patch mean more than one patch per one
diff-tree raw line) by a/file or b/file link.
Split patches differ from pair of deletion/creation patch in git diff
header: both a/file and b/file are hyperlinks, in all patches in a
split.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts commit 1ebb948f65,
as that patch quieted warning but was not proper solution.
The previous commit was.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We now do not skip over empty patches in git_patchset_body (where
empty means that they consist only of git diff header, and of extended
diff header, for example "pure rename" patch). This means that after
extended diff header there can be next patch (i.e. /^diff /) or end of
patchset, and not necessary patch body (i.e. /^--- /).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix error in git_patchset_body subroutine, which caused "rename to"/"copy
to" line in extended diff header to be displayed incorrectly.
While at it, fix align.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
$from_id, $to_id variables should be local per PATCH.
Fix error in git_patchset_body for file creation (deletion) patches,
where instead of /dev/null as from-file (to-file) diff header line, it
had link to previous file with current file name. This error occured
only if there was another patch before file creation (deletion) patch.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Edit for conciseness.
Add a "Making changes" section header.
When possible, make sure that stuff in text boxes could be entered literally.
(Don't use "..." unless we want a user to type that.)
Move 'commit -a' example into a literal code section, clarify that it finds
modified files automatically.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Clarify that dcommit creates a revision in SVN for every commit
in git. Also, add 'merge' to the rebase vs pull section because
git-merge is now a first-class UI.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Clean svn path from leading '/' when accessing SVN repo.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds ability to do import "in chunks" (default 1000 revisions),
after each chunk git repo will be repacked. The option -R is used to
change default value of chunk size (or how often repository will
repacked).
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead, reinitialize the keywords after the fact. This avoids
conflicts with other users of log-edit mode, like pcl-cvs.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It doesn't make a difference for git.el, but it helps when interacting
with git-rebase and friends.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'quiet' flag is set by -q, but it's not used anywhere.
Remove it and set the 'echo1' variable instead.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a branch other than "master" is checked out in the origin repository,
git-clone makes a local copy of that branch rather than the origin's
"master"
branch. This patch describes the actual behavior.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In order to make the generated tar files more friendly to users who
extract them as root using GNU tar and its implied -p option, change
the default umask to 002 and change the owner name and group name to
root. This ensures that a) the extracted files and directories are
not world-writable and b) that they belong to user and group root.
Before they would have been assigned to a user and/or group named
git if it existed. This also answers the question in the removed
comment: uid=0, gid=0, uname=root, gname=root is exactly what we
want.
Normal users who let tar apply their umask while extracting are
only affected if their umask allowed the world to change their
files (e.g. a umask of zero). This case is so unlikely and strange
that we don't need to support it.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we have a 64 bit address space we can easily afford to commit
a larger amount of virtual address space to pack file access.
So on these platforms we should increase the default settings of
core.packedGit{Limit,WindowSize} to something that will better
handle very large projects.
Thanks to Andy Whitcroft for pointing out that we can safely
increase these defaults on such systems.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier test timestamp was too old; I forgot that the bare
unixtime integer had to be after Jan 1, 2000. This changes
test_tick to use the git-epoch timestamp.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Somehow we forgot to turn save_commit_buffer off while walking
the reachable objects. Releasing the memory for commit object
data that we do not use matters for large projects (for example,
about 90MB is saved while traversing linux-2.6 history).
Signed-off-by: Junio C Hamano <junkio@cox.net>
It might be handy to have a single command that helps you manage
your configuration that relates to downloading from remote
repositories. This currently does only about 20% of what I want
it to do.
$ git remote
shows the list of 'remotes' you have defined somewhere, and
$ git remote origin
shows the details about the named remote (in this case
"origin"). How the branches are tracked, if you have a
tracking branch that is stale, etc.
$ git add another git://git.kernel.org/pub/...
defines the default remote.another.url and remote.another.fetch
entries just like a clone does; you can say "git fetch another"
afterwards.
For it to be useful, I think it should be enhanced to:
- check overlaps of tracking branches and warn;
- offer to remove stale tracking branches in one go;
- offer ways to remove or rename remote;
- offer ways to update an existing remote, perhaps have an
interactive mode;
Other enhancements might be also possible, but I do not think of
anything that is absolutely necessary other than the above right
now.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Blame currently displays the commit id which introduced a
block of one or more lines, the line numbers wrt the current
listing of the file and the file's line contents.
The commit id displayed is hyperlinked to the commit.
Currently the linenr links are hyperlinked to the same
commit id displayed to the left, which is _no_ different
than the block of lines displayed, since it is the _same
commit_ that is hyperlinked. And thus clicking on it leads
to the same state of the file for that chunk of
lines. I.e. data mining is not currently possible with
gitweb given a chunk of lines introduced by a commit.
This patch makes such data mining possible.
The line numbers are now hyperlinked to the parent of the
commit id of the block of lines. Furthermore they are
linked to the line where that block was introduced.
Thus clicking on a linenr link will show you the file's
line(s) state prior to the commit id you were viewing.
So clicking continually on a linenr link shows you how this
line and its line number changed over time, leading to the
initial commit where it was first introduced.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix "Use of uninitialized value" warning in git_tags_body generated
for lightweight tags of tree and blob object; those don't have age
($tag{'age'}) defined.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since fetch reforks itself at most every 1000 revisions, we
need to update the counter in the parent process to have a
working count if we set our repack interval to be > ~1000
revisions. multi-fetch has always done this correctly
because of an extra process; now fetch uses the extra process;
as well.
While we're at it, only compile the $sha1 regex that checks for
repacking once.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It now requires at least one of the (trunk|branch|tags) arguments
(either from the command-line or in .git/config). Also we make
sure that anything that is passed as a URL ('help') in David's
case is actually a URL.
Thanks to David Kågedal for reporting this issue.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The variable named entry is allocated using malloc() and then
forgotten, it being shadowed by an automatic variable of the
same name. Fixing the array size at 3 worked so far because
the only caller of traverse_trees() needed only as much
entries. Simply remove the shadowing varaible and we're able
to traverse more than three trees and save stack space at the
same time!
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
