gitk: Work around Tcl's non-standard names for encodings
This uses a table of encoding names and aliases distilled from
http://www.iana.org/assignments/character-sets plus some heuristics
to convert standard encoding names to ones that Tcl recognizes.
update-index: allow --index-info to add higher stages.
The new merge world order tells the merge strategies to leave
the cache unmerged and store the automerge result in the working
tree if automerge is not clean. This was done for the resolve
strategy and recursive strategy when no rename is involved, but
recording a conflicting merge in the rename case could not
easily be done by the recursive strategy.
This commit adds a new input format, in addition to the exsting
two, to "update-index --index-info".
(1) mode SP sha1 TAB path
The first format is what "git-apply --index-info"
reports, and used to reconstruct a partial tree
that is used for phony merge base tree when falling
back on 3-way merge.
(2) mode SP type SP sha1 TAB path
The second format is to stuff git-ls-tree output
into the index file.
(3) mode SP sha1 SP stage TAB path
This format is to put higher order stages into the
index file and matches git-ls-files --stage output.
To place a higher stage entry to the index, the path should
first be removed by feeding a mode=0 entry for the path, and
then feeding necessary input lines in the (3) format.
The first line of the input feeds 0 as the mode to remove the
path; the SHA1 does not matter as long as it is well formatted.
Then the second and third line feeds stage 1 and stage 2 entries
for that path. After the above, we would end up with this:
On AIX, there is no -n option to the system's echo. Instead,
it needs the '\c' control character. We could replace
echo -n "foo"
with
echo -e "foo\c"
but printf is recommended by most man pages. Tested on AIX
5.3, Solaris 8, and Debian.
[jc: futureproofed two instances that uses variable with '%s'
so later feeding different messages would not break things too
easily; others are emitting literal so whoever changes the
literal ought to notice more easily so they are safe.]
Signed-off-by: E. Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
> The code looks wrong. It assumes that pointers are no larger than ints.
> If pointers are larger than ints, the code does not necessarily compute
> a consistent ordering and qsort is allowed to do whatever it wants.
>
> Morten
>
> static int compare_object_pointers(const void *a, const void *b)
> {
> const struct object * const *pa = a;
> const struct object * const *pb = b;
> return *pa - *pb;
> }
Added an AIX clause in the Makefile; that clause likely
will be wrong for any AIX pre-5.2, but I can only test
on 5.3. mailinfo.c was missing the compat header file,
and convert-objects.c needs to define a specific
_XOPEN_SOURCE as well as _XOPEN_SOURCE_EXTENDED.
Signed-off-by: E. Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-merge-one-file: resurrect leading path creation.
Since we do not use git-update-index followed by
git-checkout-index -u to create the half-merged file on
conflicting case anymore, we need to make sure the leading
directories are created here.
Maybe a better solution would be to allow update-index to add to
higher stage, and checkout-index to extract from such, but that
is a change slightly bigger than I would like to have so close
to 1.0, so this should do for now.
Documentaiton (read-tree): update description of 3-way
The merge-one-file used to leave the working tree intact, but
it has long been changed to leave the merge result there since 2a68a8659f7dc55fd285d235ae2d19e7a8116c30 commit.
It was cumbersome to feed hash-object the file '-t' (you could
have said "./-t", though). Teach it '--' that terminates the
option list, like everybody else. There is no way to extract
usage string from the command either, so teach it "--help" as
well.
Not everybody can rely on /bin/sh to be sane, and we support
SHELL_PATH for that. Use it.
mktemp(1) is not used anywhere else in the core git. Do not
introduce dependency on it.
Not everybody's "which" gives a sane return value. For example,
on Solaris 'which XXX' says "no XXX in /usr/bin /bin ..." and
exits with zero status. The lesson here is to never use 'which'
in your scripts.
Signed-off-by: Junio C Hamano <junkio@twinsun.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
This attempts to clean up the way various compatibility
functions are defined and used.
- A new header file, git-compat-util.h, is introduced. This
looks at various NO_XXX and does necessary function name
replacements, equivalent of -Dstrcasestr=gitstrcasestr in the
Makefile.
- Those function name replacements are removed from the Makefile.
- Common features such as usage(), die(), xmalloc() are moved
from cache.h to git-compat-util.h; cache.h includes
git-compat-util.h itself.
gitk: Some improvements for the code for updating the display
This should be more robust in the case that some does "Update" before
the initial drawing is finished. It also avoids having to reset the
list of children for each commit and reconstruct it.
The existing config.mak should satisfy almost everyone... You
can change the prefix and other vars catch the new setting
anyways. I had forgotten that ?= acts as = (lazy value binding)
and as not := (immediate value binding).
Signed-off-by: E. Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation: shared repository management in tutorial.
The branch policy script I outlined was improved and polished by
Carl and posted on the list twice since then. It is a shame not
to pick it up, so replace the original outline in
howto/update-hook-example.txt with the latest from Carl.
Also talk about setting up git-shell to allow git-push/git-fetch
only SSH access to a shared repository host in the tutorial.
Mention documentation pages that talk about update and
post-update hooks from git-push, because a frequently asked
question is "I want X to happen when I push" and people would
not know to look at git-receive-pack documentation until they
understand that is what runs on the other end.
Again, dumb transport clients are too dumb to make use of the
top objects information to make a choice among multiple packs,
so computing these lines are useless for now. We could
resurrect them if needed later. Also dumb transport clients
presumably can do their own approximation by downloading idx
files to see how relevant each pack is for their fetch.
We tried to compute pack interdependency information in
$GIT_DIR/objects/info/packs, hoping that dumb transports would
make use of it when choosing from multiple choice, but that has
never materialized, so stop computing D lines for now.
sha1_file.c: make sure packs in an alternate odb is named properly.
We somehow ended up registering packs in alternate object
directories as "dir/object//pack/pack-*", which confusd the
update-server-info code very badly. Also we did not attempt to
detect a mistake of listing the object directory itself as one
of the alternates. This does not lead to incorrect behaviour,
but is simply wasteful, so try to do so when we are trivially
able to.
git.c: remove excess output for debugging when command is too long.
When the given command name was too long, we exited with a
message with the number of bytes of the final command name
inside parentheses, without saying what that number is. It was
only meant as a debugging aid while development, so remove it.
Document the --(no-)edit switch of git-revert and git-cherry-pick
This switch was not documented properly. I decided not to mention
the --no-edit switch in the git-cherry-pick documentation since
we always default to no editing.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
show-branch: allow glob pattern to name branches to show.
With this, you can say "git-show-branch topic/* master" to show
all the topic branches you have under .git/refs/heads/topic/ and
your master branch. Another example is "git-show-branch --list
v1.0*" to show all the v1.0 tags. You can disambiguate by
saying "heads/topic/*" to show only topic branches if you have
tags under .git/refs/tags/topic/ as well.
This patch aims to freshen up a bit the git-ls-tree documentation. It hints
that the list of paths are in fact patterns to be matched, explains the new
-t, --name-only and --name-status options, corrects the original autorship
information to refer to yours sincerely, corrects several grammar mistakes,
etc.
Since the documentation still deserves some significant work (at least
proper description of the pattern matching), I also added the stub notice.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
git.c: two fixes, gitsetenv type and off-by-one error.
gitsetenv as implemented in compat/setenv.c takes two const char*
and int; match that.
Also fix an incorrect attempt in prepend_to_path() to
NUL-terminate the string which stuffed the NUL character at one
past the end of allocation, and was not needed to begin with (we
copy the old_path string including the NUL which terminates it).
If you try to push into an empty repository with no ref arguments to
git push, it doesn't do anything and doesn't say anything. This adds a
warning when send-pack isn't going to push anything, so you don't
assume that it silently did what you wanted.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
[PATCH] daemon.c and path.enter_repo(): revamp path validation.
The whitelist of git-daemon is checked against return value from
enter_repo(), and enter_repo() used to return the value obtained
from getcwd() to avoid directory aliasing issues as discussed
earier (mid October 2005).
Unfortunately, it did not go well as we hoped.
For example, /pub on a kernel.org public machine is a symlink to
its real mountpoint, and it is understandable that the
administrator does not want to adjust the whitelist every time
/pub needs to point at a different partition for storage
allcation or whatever reasons. Being able to keep using
/pub/scm as the whitelist is a desirable property.
So this version of enter_repo() reports what it used to chdir()
and validate, but does not use getcwd() to canonicalize the
directory name. When it sees a user relative path ~user/path,
it internally resolves it to try chdir() there, but it still
reports ~user/path (possibly after appending .git if allowed to
do so, in which case it would report ~user/path.git).
What this means is that if a whitelist wants to allow a user
relative path, it needs to say "~" (for all users) or list user
home directories like "~alice" "~bob". And no, you cannot say
/home if the advertised way to access user home directories are
~alice,~bob, etc. The whole point of this is to avoid
unnecessary aliasing issues.
Anyway, because of this, daemon needs to do a bit more work to
guard itself. Namely, it needs to make sure that the accessor
does not try to exploit its leading path match rule by inserting
/../ in the middle or hanging /.. at the end. I resurrected the
belts and suspender paranoia code HPA did for this purpose.
This check cannot be done in the enter_repo() unconditionally,
because there are valid callers of enter_repo() that want to
honor /../; authorized users coming over ssh to run send-pack
and fetch-pack should be allowed to do so.
There is no setenv() in Solaris 5.8. The trivial calls to
setenv() were replaced by putenv() in a much earlier patch,
but setenv() was used again in git.c. This patch just adds
a compat/setenv.c.
The rule for building git$(X) also needs to include compat.
objects and compiler flags. Those are now in makefile vars
COMPAT_OBJS and COMPAT_CFLAGS.
Signed-off-by: E. Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
Use the same trick Josef used to introduce line breaks for
git-mv documentation for now, to help HTML rendering. This
breaks manpages and we need to come up with a better solution.
git-merge documentation: conflicting merge leaves higher stages in index
This hopefully concludes the latest updates that changes the
behaviour of the merge on an unsuccessful automerge. Instead of
collapsing the conflicted path in the index to show HEAD, we
leave it unmerged, now that diff-files can compare working tree
files with higher stages.
merge-one-file: make sure we create the merged file.
The "update-index followed by checkout-index" chain served two
purposes -- to collapse the index to "our" version, and make
sure that file exists in the working tree. In the recent update
to leave the index unmerged on conflicting path, we wanted to
stop doing the former, but we still need to do the latter (we
allow merging to work in an un-checked-out working tree).
merge-recursive: adjust git-ls-tree use for the latest.
You need to pass -t flag if you want to see tree objects in
"git-ls-tree -r" output these days. This change broke the tree
structure reading code in git-merge-recursive used to detect D/F
conflicts.
- Use stderr for error output
- Build git_command more careful
- ENOENT is good enough for check of failed exec to show usage, no
access() check needed
[jc: Originally from Alex Riesen with inputs from Sven
Verdoolaege mixed in.]
Fingers of some "git diff" users are trained to do --name-only
which git-ls-tree unfortunately does not take. With this,
cd sub/directory && git-ls-tree -r --name-only ..
would show only the names not object names nor modes. I threw
in another synonym --name-status only for usability, but
obviously ls-tree does not do any comparison so what it does is
the same as --name-only.
git-ls-tree: add "-t" option to always show the tree entries
The old (new) behaviour was that it only shows trees if the object is
specified exactly, and recursive is not set. That makes sense, because
there is obviously nothing else it can show for that case.
However, with the new "-t" option, it will show the tree even with "-r",
as it traverses down into it.
NOTE! This also means that it will show all trees leading up to that tree.
For example, if you do a
git-ls-tree -t HEAD -- drivers/char/this/file/does/not/exist
it will show the trees that lead up to the files that do not exist:
and note how this is true even though I didn't specify "-r": the fact that
I supplied a pathspec automatically implies "enough recursion" for that
particular pathspec.
I think the code is cleaner and easier to understand too: the patch looks
bigger, but it's really just splitting up the "should we recurse into this
tree" into a function of its own.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Alex Riesen wants to keep extra makefile targets in config.mak, but
the file is included before any of our real targets. Having this
at the beginning allows you to do so.
Tutorial: adjust merge example to recursive strategy.
Current default, merge-recursive, gives slightly different
message while working from merge-resolve which was used to
prepare the illustration in the tutorial.
merge-recursive: match the unmerged index entry behaviour with merge-resolve
This minimally changes merge-recursive to match what happens
when O->A, O->B, A!=B 3-way filelevel merge leaves conflicts to
the new merge-resolve behaviour.
diff-files: show diffs with stage0 and unmerged stage at the same time.
After thinking about it more, I realized that much of the change
I did on top of Linus' version does not make much sense. This
commit reverts it so that it by default shows diffs with stage0
paths or stage2 paths with working tree; the unmerged stage to
use can be overridden with -1/-2/-3 option (-2 is the default so
essentially is a no-op).
When the index file is unmerged, we are by definition in the
middle of a conflicting merge, and we should show the diff with
stage 2 by default. More importantly, paths without conflicts
are updated in the working tree and collapsed to stage0 in the
index, so showing diff with stage0 at the same time does not
hurt. In normal cases, stage0 entries should be in sync with
the working tree files and does not clutter the output. It even
helps the user to realize that the working tree has local
changes unrelated to the merge and remember to be careful not to
do a "git-commit -a" after resolving the conflicts.
When there is no unmerged entries, giving diff_unmerged_stage a
default value of 2 does not cause any harm, because it would not
be used anyway. So in all, always showing diff between stage0
paths and unmerged entries from a stage (defaulting to 2) is the
right thing to do, as Linus originally did.
merge-one-file: leave unmerged index entries upon automerge failure.
When automerge fails, we used to collapse the path to stage0
from "our" branch, to help "diff-files" users to view the
half-merged state against the current HEAD. Now diff-files has
been taught how to compare with unmerged stage2,leaving them
unmerged is a better thing to do, especially this prevents the
unresolved conflicts to be committed by mistake.
diff-files: -1/-2/-3 to diff against unmerged stage.
While resolving conflicted merge, it was not easy to compare the
working tree file with unmerged index entries. This commit
introduces new options -1/-2/-3 (with synonyms --base, --ours,
and --theirs) to compare working tree files with specified
stages.
When none of these options are given, the command defaults to -2
if the index file is unmerged, otherwise it acts as before.
[jc: majorly butchered from the version Linus originally posted.]
git-diff: do not turn off -p/-M with any diff options.
When the user gives a diff option (e.g. --cached) to "git diff",
we turned off the built-in default option -p, which is usually
not what user wants to see.
This commit makes lack of --name-status, --name-only nor -r to
add -p, and lack of -B*, -C* nor -M* to add -M to the flags
given to the underlying diff.
Before GIT version at the end of output we used a 3-dash marker;
but 3-dash marker is special and should not be overused.
Instead, use "-- " which is a standard practice in e-mails to
signal the beginning of trailing garbage.
The attempt to help 3-way fallback by recording the tree object
id for the entire pre-image was unnecessary, and we already have
an better alternative in the form of per-blob "index" lines.
One "svn log" (or its equivalent) per revision adds delay and server load.
Instead, open two SVN connections -- one for the log, and one for the files.
Positive side effect: Only those log entries which actually contain data
are committed => no more empty commits.
Also, change the "-l" option to set the maximum revision to be pulled,
not the number of revisions.
The malloc patch from Jan Andres fixed the problem that was causing a
segfault when freeing the lock token, and Johannes Schindelin found
and fixed a problem when no URL is specified on the command line.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
The "--shared" option to git-clone is silently ignored if "--local" is
not specified. The manual doesn't mention such dependency. Make
"--shared" imply "--local".
Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
As a fallout from not using git-sh-setup in scripts that can
operate from a subdirectory, we lost definition of die() from
them. It might make sense to do some cleanup to consolidate
them back again, but this should suffice for now.
ls-remote: define die() now we do not use git-sh-setup
Another interesting "property" is that from inside a git managed
tree, "git-ls-remote ." names the current repository no matter
how deep a subdirectory you are in.
Make networking commands to work from a subdirectory.
These are whole-tree operations and there is not much point
making them operable from within a subdirectory, but it is easy
to do so, and using setup_git_directory() upfront helps git://
proxy specification picked up from the correct place.
This makes ls-tree to work from subdirectory. It defaults to
show the paths under the current subdirectory, and interprets
user-supplied paths as relative to the current subdirectory.