Earlier, we made --base-path to automatically forbid
user-relative paths, which was probably a mistake. This
introduces --user-path (or --user-path=path) option to control
the use of user-relative paths independently. The latter form
of the option can be used to restrict accesses to a part of each
user's home directory, similar to "public_html" some webservers
supports.
If we're invoked with --user-path=FOO option, then a URL of the
form git://~USER/PATH/... resolves to the path HOME/FOO/PATH/...,
where HOME is USER's home directory.
[jc: This is much reworked by me so bugs are mine, but the
original patch was done by Mark Wooding.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this, you can silently lose the ability to receive IPv4
connections if you stop and restart the daemon.
[jc: tweaked code organization a bit and made this controllable
from a command line option.]
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using base-path to relocate the server public space does not
have anything to do with allowing or forbidding user relative
paths.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It could be made later to show unmerged state nicer than the
default as we did for diff-files later, but this would suffice
for now. We would like to make --cc the default for 'git diff'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It _might_ make sense for certain users like gitk and gitview if
we had a single tool that gives --pretty and its diff even if
the diff is empty. Having said that, the flag --cc -m is too
specific. If some uses want to see the commit log even for an
empty diff, that flag should not be something only --cc honors.
Here's an "--always" flag that does that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since we already depend on zlib, we don't need to define our
own adler32(). Spotted by oprofile.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using "--verify" together with "--no-flags" makes perfect sense, but
git-rev-parse would complain about it when it saw a flag, even though it
would never actually use/output that flag.
This fixes it.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When TERM is set to 'dumb', do not start vi to edit the commit log
message.
Suggested by Amos Waterland.
Signed-off-by: Junio C Hamano <junkio@cox.net>
As far as I can see, create_subdirectories() in apply.c just
duplicates the functionality of safe_create_leading_directories() from
sha1_file.c. The former has a warm, fuzzy const parameter, but that's
not important.
The potential problem with EEXIST and creating directories should
never occur here, but will be removed by future
safe_create_leading_directories() changes. Other uses of EEXIST in
apply.c should be fine barring intentionally malicious behavior.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Could cause a crash if --base-path set. Unlikely to be a security the
concern: message doesn't go to the client, so we can't leak anything
(except by dumping core), and we've already forked, so it's not a denial
of service.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We probably thought anybody who does more than 9 parents in an
Octopus is insane when this was initially done, but there is no
inherent reason to limit the number of independent topic
branches that happen to mature at the same time.
Our commit-tree allows up to 16 already, so at least we should
prepare to handle what we can produce, if only to be consistent.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the output format to make administrative lines more
consistent with the traditional diffs.
The "index" line shows blob object names from each parents
(separated by commas), double dots and the object name of the
resulting blob.
The hunk header line begins with N+1 '@' characters for N-way
diff, the line number L of the first line in the hunk and line
count C from the parent in "-L,C" format for each parents and
then the line number of the first line in the hunk and line
count from the resulting file in "+L,C" format, and finally
N+1 '@' characters (earlier versions had the line numbers from
the resulting file at the beginning).
Signed-off-by: Junio C Hamano <junkio@cox.net>
The flag on the surviving lines meant "this parent is not
different" while the parent_map flag on the lost lines meant
"this parent is different", which was confusing. So swap the
meaning of on-bit in the flag. Also more heavily comment the
code.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-send-email, when used with --compose, provided the user with a mbox-format
file to edit. Some users, however, were confused by the leading, blank, "From
" line, so this change puts the value that will appear on the From: line of the
actual email on this line, along with a note that the line is ignored.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, f2d4227530 commit broke Merge:
lines for unabbreviated case. Do not emit extra dots if we do not
abbreviate.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use __slots__ to speed up construction and decrease memory consumption
of the Commit objects.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes some cases faster as we don't have to build the commit graph.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A misguided attempt to show logs at all time was inserted only to
the documentation of this flag. Worse yet, it was not even implemented,
causing more confusion. Drop it.
We might want to have an option to show --pretty even when there is no
diff output, but that is applicable to all forms of diff, not just --cc.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code misplaced a raw hunk that consists of solely deleted
lines by one line. This showed e.g. Len's 12-way octopus
(9fdb62af in the linux-2.6), kernel/power/disk.c, hunk starting
at line 95, incorrectly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier change implemented "only two version" check but
without checking if the change rewrites from all the parents.
This implements a check to make sure that a change introduced
by the merge from all the parents is caught to be interesting.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier logic was discarding hunks that has difference from only
one parent or the same difference from all but one parent. This
changes it to check if the differences on all lines are from the
same sets of parents. This discards more uninteresting hunks
and seems to match expectations more naturally.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When dealing with an insanely large Octopus, it is possible to
optimize by noticing that more than one parents have the same
blob and avoid running diff between a parent and the merge
result by reusing an earlier result.
Signed-off-by: Junio C Hamano <junkio@cox.net>
So far, e.g. git-update-index --refresh was basically uninterruptable
by ctrl-c, since it hooked the SIGINT handler, but that handler would
only unlink the lockfile but not actually quit. This makes it propagate
the signal to the default handler.
Note that I expected it to work without resetting the signal handler to
SIG_DFL, but without that it ended in an infinite loop of tgkill()s -
is my glibc violating SUS or what?
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Showing the same parent more than once for a commit does not
make much sense downstream, so stop it.
This can happen with an incorrectly made merge commit that
merges the same parent twice, but can happen in an otherwise
sane development history while squishing the history by taking
into account only commits that touch specified paths.
For example,
$ git rev-list --max-count=1 --parents addafaf -- rev-list.c
would have to show this commit ancestry graph:
.---o---.
/ \
.---*---o---.
/ 93b74bc \
---*---o---o-----o---o-----o addafafd8f6b34 \ /
.---o---o---.
\ /
.---*---.
3815f42
where 5 independent development tracks, only two of which have
changes in the specified paths since they forked. The last
change for the other three development tracks was done by the
same commit before they forked, and we were showing that three
times.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Somehow we did not allow stuffing the index with stage 0 entries
through --index-info interface. I do not think of a reason to
forbid it offhand.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes 'arg list too long..' problem with git-ls-files.
Note that second arg list separation loop (with 'git-update-index') is
needed since git-ls-files arguments can be directories.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There's no need for these structures to be static, and it could potentially
cause problems down the road.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This builds on top of the previous one.
Traditionally, head(1) and tail(1) allow their line limits to be
parsed this way.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Both -n<n> and -n <n> are supported. POSIX versions of head(1) and
tail(1) allow their line limits to be parsed this way. I find
--max-count to be a commonly used option, and also similar in spirit to
head/tail, so I decided to make life easier on my worn out (and lazy :)
fingers with this patch.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This only applies to traditional diffs, not to git diffs.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a way to store the results of an HTTP request when a slot finishes
so the results can be processed after the slot has been reused.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have operations to "extract" and "update" a "struct tree_desc", but we
only used them in tree-diff.c and they were static to that file.
But other tree traversal functions can use them to their advantage
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was open-coding getting the commit date from a commit.
Signed-off-by: Daniel Barkalow <barkalow@iabervon>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was using an open-coded tree parser; use a struct tree instead.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Here's some changes to the cvs-migration.txt. As usual, in my attempt
to make things clearer someone may have found I've made them less so, or
I may have just gotten something wrong; so any review is welcomed.
I can break up this sort of thing into smaller steps if preferred, the
monolothic patch is just a bit simpler for me for this sort of
thing.
I moved the material describing shared repository management from
core-tutorial.txt to cvs-migration.txt, where it seems more appropriate,
and combined two sections to eliminate some redundancy.
I also revised the earlier sections of cvs-migration.txt, mainly trying
to make it more concise.
I've left the last section of cvs-migration.txt (on CVS annotate
alternatives) alone for now.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Replaced backticks with potentially troublesome unescaped input with
safe_pipe_capture().
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A couple of things that seem to help importing broken CVS repos...
-S '<slash-delimited-regex>' skips files with a matching path
-v prints file name and version before fetching from cvs
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
