mirror of
https://github.com/git/git
synced 2024-08-24 18:26:02 +00:00
Sync with GIT 1.5.3.3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
commit
d7da5597a8
37
Documentation/RelNotes-1.5.3.3.txt
Normal file
37
Documentation/RelNotes-1.5.3.3.txt
Normal file
|
@ -0,0 +1,37 @@
|
|||
GIT v1.5.3.3 Release Notes
|
||||
==========================
|
||||
|
||||
Fixes since v1.5.3.2
|
||||
--------------------
|
||||
|
||||
* git-quiltimport did not like it when a patch described in the
|
||||
series file does not exist.
|
||||
|
||||
* p4 importer missed executable bit in some cases.
|
||||
|
||||
* The default shell on some FreeBSD did not execute the
|
||||
argument parsing code correctly and made git unusable.
|
||||
|
||||
* git-svn incorrectly spawned pager even when the user user
|
||||
explicitly asked not to.
|
||||
|
||||
* sample post-receive hook overquoted the envelope sender
|
||||
value.
|
||||
|
||||
* git-am got confused when the patch contained a change that is
|
||||
only about type and not contents.
|
||||
|
||||
* git-mergetool did not show our and their version of the
|
||||
conflicted file when started from a subdirectory of the
|
||||
project.
|
||||
|
||||
* git-mergetool did not pass correct options when invoking diff3.
|
||||
|
||||
* git-log sometimes invoked underlying "diff" machinery
|
||||
unnecessarily.
|
||||
|
||||
--
|
||||
exec >/var/tmp/1
|
||||
O=v1.5.3.2-29-gb7bb760
|
||||
echo O=`git describe refs/heads/maint`
|
||||
git shortlog --no-merges $O..refs/heads/maint
|
|
@ -1459,7 +1459,8 @@ Although git is a truly distributed system, it is often
|
|||
convenient to organize your project with an informal hierarchy
|
||||
of developers. Linux kernel development is run this way. There
|
||||
is a nice illustration (page 17, "Merges to Mainline") in
|
||||
link:http://tinyurl.com/a2jdg[Randy Dunlap's presentation].
|
||||
link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf
|
||||
[Randy Dunlap's presentation].
|
||||
|
||||
It should be stressed that this hierarchy is purely *informal*.
|
||||
There is nothing fundamental in git that enforces the "chain of
|
||||
|
|
|
@ -103,14 +103,20 @@ We set a tag in R1 (lastR2bundle) after the previous such transport,
|
|||
and move it afterwards to help build the bundle.
|
||||
|
||||
in R1 on A:
|
||||
|
||||
------------
|
||||
$ git-bundle create mybundle master ^lastR2bundle
|
||||
$ git tag -f lastR2bundle master
|
||||
------------
|
||||
|
||||
(move mybundle from A to B by some mechanism)
|
||||
|
||||
in R2 on B:
|
||||
|
||||
------------
|
||||
$ git-bundle verify mybundle
|
||||
$ git-fetch mybundle refspec
|
||||
------------
|
||||
|
||||
where refspec is refInBundle:localRef
|
||||
|
||||
|
@ -124,9 +130,11 @@ Also, with something like this in your config:
|
|||
You can first sneakernet the bundle file to ~/tmp/file.bdl and
|
||||
then these commands:
|
||||
|
||||
------------
|
||||
$ git ls-remote bundle
|
||||
$ git fetch bundle
|
||||
$ git pull bundle
|
||||
------------
|
||||
|
||||
would treat it as if it is talking with a remote side over the
|
||||
network.
|
||||
|
|
|
@ -56,7 +56,7 @@ merge.verbosity::
|
|||
message if conflicts were detected. Level 1 outputs only
|
||||
conflicts, 2 outputs conflicts and file changes. Level 5 and
|
||||
above outputs debugging information. The default is level 2.
|
||||
Can be overriden by 'GIT_MERGE_VERBOSITY' environment variable.
|
||||
Can be overridden by 'GIT_MERGE_VERBOSITY' environment variable.
|
||||
|
||||
|
||||
HOW MERGE WORKS
|
||||
|
|
|
@ -145,17 +145,6 @@ sign `$` upon checkout. Any byte sequence that begins with
|
|||
with `$Id$` upon check-in.
|
||||
|
||||
|
||||
Interaction between checkin/checkout attributes
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In the check-in codepath, the worktree file is first converted
|
||||
with `ident` (if specified), and then with `crlf` (again, if
|
||||
specified and applicable).
|
||||
|
||||
In the check-out codepath, the blob content is first converted
|
||||
with `crlf`, and then `ident`.
|
||||
|
||||
|
||||
`filter`
|
||||
^^^^^^^^
|
||||
|
||||
|
@ -175,11 +164,10 @@ but makes the filter a no-op passthru.
|
|||
The content filtering is done to massage the content into a
|
||||
shape that is more convenient for the platform, filesystem, and
|
||||
the user to use. The keyword here is "more convenient" and not
|
||||
"turning something unusable into usable". In other words, it is
|
||||
"hanging yourself because we gave you a long rope" if your
|
||||
project uses filtering mechanism in such a way that it makes
|
||||
your project unusable unless the checkout is done with a
|
||||
specific filter in effect.
|
||||
"turning something unusable into usable". In other words, the
|
||||
intent is that if someone unsets the filter driver definition,
|
||||
or does not have the appropriate filter program, the project
|
||||
should still be usable.
|
||||
|
||||
|
||||
Interaction between checkin/checkout attributes
|
||||
|
|
|
@ -26,7 +26,7 @@ precedence, the last matching pattern decides the outcome):
|
|||
|
||||
* Patterns read from a `.gitignore` file in the same directory
|
||||
as the path, or in any parent directory, with patterns in the
|
||||
higher level files (up to the root) being overriden by those in
|
||||
higher level files (up to the root) being overridden by those in
|
||||
lower level files down to the directory containing the file.
|
||||
These patterns match relative to the location of the
|
||||
`.gitignore` file. A project normally includes such
|
||||
|
|
|
@ -2856,8 +2856,7 @@ between two related tree objects, since it can ignore any entries with
|
|||
identical object names.
|
||||
|
||||
(Note: in the presence of submodules, trees may also have commits as
|
||||
entries. See gitlink:git-submodule[1] and gitlink:gitmodules.txt[1]
|
||||
for partial documentation.)
|
||||
entries. See <<submodules>> for documentation.)
|
||||
|
||||
Note that the files all have mode 644 or 755: git actually only pays
|
||||
attention to the executable bit.
|
||||
|
@ -3163,12 +3162,45 @@ information as long as you have the name of the tree that it described.
|
|||
Submodules
|
||||
==========
|
||||
|
||||
This tutorial explains how to create and publish a repository with submodules
|
||||
using the gitlink:git-submodule[1] command.
|
||||
Large projects are often composed of smaller, self-contained modules. For
|
||||
example, an embedded Linux distribution's source tree would include every
|
||||
piece of software in the distribution with some local modifications; a movie
|
||||
player might need to build against a specific, known-working version of a
|
||||
decompression library; several independent programs might all share the same
|
||||
build scripts.
|
||||
|
||||
Submodules maintain their own identity; the submodule support just stores the
|
||||
submodule repository location and commit ID, so other developers who clone the
|
||||
superproject can easily clone all the submodules at the same revision.
|
||||
With centralized revision control systems this is often accomplished by
|
||||
including every module in one single repository. Developers can check out
|
||||
all modules or only the modules they need to work with. They can even modify
|
||||
files across several modules in a single commit while moving things around
|
||||
or updating APIs and translations.
|
||||
|
||||
Git does not allow partial checkouts, so duplicating this approach in Git
|
||||
would force developers to keep a local copy of modules they are not
|
||||
interested in touching. Commits in an enormous checkout would be slower
|
||||
than you'd expect as Git would have to scan every directory for changes.
|
||||
If modules have a lot of local history, clones would take forever.
|
||||
|
||||
On the plus side, distributed revision control systems can much better
|
||||
integrate with external sources. In a centralized model, a single arbitrary
|
||||
snapshot of the external project is exported from its own revision control
|
||||
and then imported into the local revision control on a vendor branch. All
|
||||
the history is hidden. With distributed revision control you can clone the
|
||||
entire external history and much more easily follow development and re-merge
|
||||
local changes.
|
||||
|
||||
Git's submodule support allows a repository to contain, as a subdirectory, a
|
||||
checkout of an external project. Submodules maintain their own identity;
|
||||
the submodule support just stores the submodule repository location and
|
||||
commit ID, so other developers who clone the containing project
|
||||
("superproject") can easily clone all the submodules at the same revision.
|
||||
Partial checkouts of the superproject are possible: you can tell Git to
|
||||
clone none, some or all of the submodules.
|
||||
|
||||
The gitlink:git-submodule[1] command is available since Git 1.5.3. Users
|
||||
with Git 1.5.2 can look up the submodule commits in the repository and
|
||||
manually check them out; earlier versions won't recognize the submodules at
|
||||
all.
|
||||
|
||||
To see how submodule support works, create (for example) four example
|
||||
repositories that can be used later as a submodule:
|
||||
|
@ -3213,8 +3245,8 @@ The `git submodule add` command does a couple of things:
|
|||
|
||||
- It clones the submodule under the current directory and by default checks out
|
||||
the master branch.
|
||||
- It adds the submodule's clone path to the `.gitmodules` file and adds this
|
||||
file to the index, ready to be committed.
|
||||
- It adds the submodule's clone path to the gitlink:gitmodules[5] file and
|
||||
adds this file to the index, ready to be committed.
|
||||
- It adds the submodule's current commit ID to the index, ready to be
|
||||
committed.
|
||||
|
||||
|
@ -4277,5 +4309,3 @@ Write a chapter on using plumbing and writing scripts.
|
|||
Alternates, clone -reference, etc.
|
||||
|
||||
git unpack-objects -r for recovery
|
||||
|
||||
submodules
|
||||
|
|
|
@ -12,6 +12,7 @@ USAGE='[--tool=tool] [file to merge] ...'
|
|||
SUBDIRECTORY_OK=Yes
|
||||
. git-sh-setup
|
||||
require_work_tree
|
||||
prefix=$(git rev-parse --show-prefix)
|
||||
|
||||
# Returns true if the mode reflects a symlink
|
||||
is_symlink () {
|
||||
|
@ -162,9 +163,9 @@ merge_file () {
|
|||
local_mode=`git ls-files -u -- "$path" | awk '{if ($3==2) print $1;}'`
|
||||
remote_mode=`git ls-files -u -- "$path" | awk '{if ($3==3) print $1;}'`
|
||||
|
||||
base_present && git cat-file blob ":1:$path" > "$BASE" 2>/dev/null
|
||||
local_present && git cat-file blob ":2:$path" > "$LOCAL" 2>/dev/null
|
||||
remote_present && git cat-file blob ":3:$path" > "$REMOTE" 2>/dev/null
|
||||
base_present && git cat-file blob ":1:$prefix$path" >"$BASE" 2>/dev/null
|
||||
local_present && git cat-file blob ":2:$prefix$path" >"$LOCAL" 2>/dev/null
|
||||
remote_present && git cat-file blob ":3:$prefix$path" >"$REMOTE" 2>/dev/null
|
||||
|
||||
if test -z "$local_mode" -o -z "$remote_mode"; then
|
||||
echo "Deleted merge conflict for '$path':"
|
||||
|
@ -191,10 +192,10 @@ merge_file () {
|
|||
case "$merge_tool" in
|
||||
kdiff3)
|
||||
if base_present ; then
|
||||
(kdiff3 --auto --L1 "$path (Base)" -L2 "$path (Local)" --L3 "$path (Remote)" \
|
||||
(kdiff3 --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
|
||||
-o "$path" -- "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
|
||||
else
|
||||
(kdiff3 --auto -L1 "$path (Local)" --L2 "$path (Remote)" \
|
||||
(kdiff3 --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
|
||||
-o "$path" -- "$LOCAL" "$REMOTE" > /dev/null 2>&1)
|
||||
fi
|
||||
status=$?
|
||||
|
@ -251,9 +252,9 @@ merge_file () {
|
|||
;;
|
||||
emerge)
|
||||
if base_present ; then
|
||||
emacs -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$path"
|
||||
emacs -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
|
||||
else
|
||||
emacs -f emerge-files-command "$LOCAL" "$REMOTE" "$path"
|
||||
emacs -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
|
||||
fi
|
||||
status=$?
|
||||
save_backup
|
||||
|
|
|
@ -71,6 +71,10 @@ commit=$(git rev-parse HEAD)
|
|||
|
||||
mkdir $tmp_dir || exit 2
|
||||
for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
|
||||
if ! [ -f "$QUILT_PATCHES/$patch_name" ] ; then
|
||||
echo "$patch_name doesn't exist. Skipping."
|
||||
continue
|
||||
fi
|
||||
echo $patch_name
|
||||
git mailinfo "$tmp_msg" "$tmp_patch" \
|
||||
<"$QUILT_PATCHES/$patch_name" >"$tmp_info" || exit 3
|
||||
|
|
10
revision.c
10
revision.c
|
@ -1209,8 +1209,6 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
|
|||
|
||||
opts = diff_opt_parse(&revs->diffopt, argv+i, argc-i);
|
||||
if (opts > 0) {
|
||||
if (strcmp(argv[i], "-z"))
|
||||
revs->diff = 1;
|
||||
i += opts - 1;
|
||||
continue;
|
||||
}
|
||||
|
@ -1254,6 +1252,14 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
|
|||
add_pending_object_with_mode(revs, object, def, mode);
|
||||
}
|
||||
|
||||
/* Did the user ask for any diff output? Run the diff! */
|
||||
if (revs->diffopt.output_format & ~DIFF_FORMAT_NO_OUTPUT)
|
||||
revs->diff = 1;
|
||||
|
||||
/* Pickaxe needs diffs */
|
||||
if (revs->diffopt.pickaxe)
|
||||
revs->diff = 1;
|
||||
|
||||
if (revs->topo_order)
|
||||
revs->limited = 1;
|
||||
|
||||
|
|
Loading…
Reference in a new issue