Junio C Hamano, Sat, Nov 26, 2005 03:45:52 +0100:
> I haven't seriously used git-mv myself, so
> somebody needs to test it, and if it actually works and Ack on
> it, please.
It actually works in subdirs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Turns out, all git programs git-mv uses are capable of operating in
a subdirectory just fine. So don't complain about it.
[jc: I think that sounds sane. You need to grab the exit status from
`git-rev-parse --git-dir`, which I added. Alex Riesen says this
worked fine.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is a lot more that could be put in, such as a selector for
the font family etc., but this is a start.
Signed-off-by: Paul Mackerras <paulus@samba.org>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This matches the 3-way fallback used by applypatch to use
per-blob "index" lines, not "applies-to" tree object name, to
match what git-am does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
These commands are converted to run from a subdirectory.
commit-tree convert-objects merge-base merge-index mktag
pack-objects pack-redundant prune-packed read-tree tar-tree
unpack-file unpack-objects update-server-info write-tree
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When -w is given, it needs to find out where the .git directory
is, so run the setup_git_directory() when we see a -w.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this, git-checkout-index from a subdirectory works as
expected. Note that "git-checkout-index -a" checks out files
only in the current directory and under.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use setup_git_directory_gently() at the beginning of peek-remote
so that git:// proxy can be picked up from the configuration
file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When applying a patch to index file, we need to know where GIT_DIR is;
use setup_git_directory() to find it out. This also allows us to work
from a subdirectory if we wanted to.
When git-apply is run from a subdirectory, it applies the given patch
only to the files under the current directory and below.
Signed-off-by: Junio C Hamano <junkio@cox.net>
- prefix_filename() is like prefix_path() but can be used to
name any file on the filesystem, not the files that might go
into the index file.
- setup_git_directory_gently() tries to find the GIT_DIR, but does
not die() if called outside a git repository.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was surprisingly easy to do.
git bisect start <pathspec>
followed by all the normal "git bisect good/bad" stuff.
Almost totally untested, and I guarantee that if your pathnames have
spaces in them (or your GIT_DIR has spaces in it) this won't work. I don't
know how to fix that, my shell programming isn't good enough.
This involves small changes to make "git-rev-list --bisect" work in the
presense of a pathspec limiter, and then truly trivial (and that's the
broken part) changes to make "git bisect" save away and use the pathspec.
I tried one bisection, and a "git bisect visualize", and it all looked
correct. But hey, don't be surprised if it has problems.
Linus
Signed-off-by: Junio C Hamano <junkio@cox.net>
The diff for this commit is a good illustration of what changed
in ls-tree behaviour.
- With -r, tree nodes themselves are not shown anymore, but
blobs in subtrees are shown.
- The order of paths parameters do not matter, since they are
not like arguments to /bin/ls, but are filter patterns.
- When filter patterns overlap, unintuitive things happen.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The rewrite to match ls-files/diff-tree behaviour accidentally
lost the name quoting. I am not proud about this code, but this
would get the test going.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It modifies the selection a bit, so that a pathspec that is a superset of
a particular tree path will always cause it to recurse into that tree.
As an example, let's say that we do
git-ls-tree HEAD drivers/char
_without_ the "-r". What will happen is that it will start out doing all
the base tree, and for "drivers" it will notice that it's a proper subset
of "drivers/char", so it will always recurse into _that_ tree (but not
into other trees).
Then, it will not match anything else than "char" in that subdirectory,
and because that's not a proper superset (it's an exact match), it will
_not_ recurse into it, so you get:
[torvalds@g5 linux]$ ~/git/git-ls-tree HEAD drivers/char
040000 tree 9568cda453aae205bb58983747fa73b9696d9d51 drivers/char
which is what you got with the old git-ls-tree too.
But interestingly, if you add the slash, it will become a proper superset
and it will recurse into _that_ subdirectory (but no deeper: so if you
want all subdirectories _below_ drivers/char/, you still need to give
"-r"):
[torvalds@g5 linux]$ ~/git/git-ls-tree HEAD drivers/char/
100644 blob 2b6b1d772ed776fff87927fc34adc2e40500218e drivers/char/.gitignore
100644 blob 56b8a2e76ab10a5c21787cb7068a846075cbaffd drivers/char/ChangeLog
100644 blob 970f70d498f4c814e1cf3362e33d7e23ac53c299 drivers/char/Kconfig
...
See? This is on top of the previous two diffs, holler if you want a whole
new "everything combined" version..
It hasn't gotten lots of testing, but it should work.
Linus
To get more a "git-ls-files" approach, this trivial patch (on top of my
previous one) enables recursion, and doesn't show partial trees.
[jc: after further discussion, this version enables recursion by default,
and you can disable it with "-d" flag.
git-ls-tree -d HEAD Documentation/no/such/directory
shows Documentation tree (without -d it shows nothing).
git-ls-tree HEAD
shows everything from the tree. Only to get the single level from the top
git-ls-tree -d HEAD
is needed. But there is no way to get the single level with pathspec.
You need to extract the object name of Documentation tree from the parent
tree and run
git-ls-tree -d $tree_id_of_Documentation_tree
to get something similar to what you can get from the current
git-ls-tree HEAD Documentation
]
git-ls-tree should be rewritten to use a pathspec the same way everybody
else does. Right now it's the odd man out: if you do
git-ls-tree HEAD divers/char drivers/
it will show the same files _twice_, which is not how pathspecs in general
work.
How about this patch? It breaks some of the git-ls-tree tests, but it
makes git-ls-tree work a lot more like other git pathspec commands, and it
removes more than 150 lines by re-using the recursive tree traversal (but
the "-d" flag is gone for good, so I'm not pushing this too hard).
Linus
In git-merge documentation, add a section to describe what happens to
the index and working tree during merge, and what their cleanliness
requirements are before the merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Noticed by linux@horizon.com. The first merge parent (typically
"our branch") is ^1, not ^0, and the first other branch is ^2.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a .dotest from a previously failed rebase or patch
application exists, rebase got confused and tried to apply
mixture of what was already there and what is being rebased.
Check the existence of the directory and barf.
It failed with an mysterious "fatal: cannot read mbox" message
if the branch being rebased is fully in sync with the base.
Also if the branch is a proper descendant of the base, there is
no need to run rebase logic. Prevent these from happening by
checking where the merge-base is.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Hardcoding "utf-8" in the script breaks projects that use local
encoding, so allow setting i18n.commitEncoding.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The change in 8b7e5d76e8, which makes
a couple of git-diff-tree calls supply only one id rather than two,
fixes the display when showing what a single commit did with dense
revlists, but broke the diff this->selected and diff selected->this
right-click menu functions.
Yann Dirson pointed this out and had a patch that fixed the diff
menu functions by passing a "singlecommit" flag around. This fixes
it a bit differently, by making the ids and diffids variables be
either a single id, in the case of showing what a commit did, or
{oldid newid}, in the case of the diff menu functions. That way
we can just pass $ids to git-diff-tree as is. Most of the changes
in fact are just reversing the order of ids in $ids and $diffids,
because they used to be {child parent}, but git-diff-tree requires
old id before new id.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Specifying the value for a single letter, single dash option
parameter with equal sign looked funny, and more importantly
calling the flag to override encoding from utf-8 to something
else "-u" (obviously abbreviated from "utf-8") did not make any
sense. So spell it out.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This uses i18n.commitencoding configuration item to pick up the
default commit encoding for the repository when converting form
e-mail encoding to commit encoding (the default is utf8).
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the message body does not identify what encoding it is in,
-u assumes it is in latin-1 and converts it to utf8, which is
the recommended encoding for git commit log messages.
With -u=<encoding>, the conversion is made into the specified
one, instead of utf8, to allow project-local policies.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is to hold what the project-local rule as to the
charset/encoding for the commit log message is. Lack of it
defaults to utf-8.
Signed-off-by: Junio C Hamano <junkio@cox.net>
