* Re: Re: Segmentation fault with latest git (070c57df)
From: Jeff King @ 2013-02-01 9:57 UTC (permalink / raw)
To: Jongman Heo; +Cc: Junio C Hamano, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <17285958.791361359710080706.JavaMail.weblogic@epml01>
On Fri, Feb 01, 2013 at 09:14:41AM +0000, Jongman Heo wrote:
> I can reproduce the issue in my machine (RedHat Enterprise 5, x86 PAE) as follows.
Great, thanks for taking the time to reproduce.
> But in my different machine (Fedora 16 x86) I can't reproduce.
That makes me wonder if it is related to the gcc or make version. I
couldn't reproduce the problem on my gcc-4.1 system, though. My make is:
$ make --version
GNU Make 3.81
[...]
> $ git reset --hard v1.8.1 # back to v1.8.1
> $ make clean
> $ make all install # this git works fine
After this step, what does builtin/.depend/fetch.o.d contain? It should
show a dependency of builtin/fetch.o on string-list (among other
things).
> $ git pull # top commit 9a6c84e6, "Merge git://ozlabs.org/~paulus/gitk"
> $ make all install
Can you try running "make -d builtin/fetch.o" here instead of "make all
install"? Can you confirm that it reads builtin/.depend/fetch.o, and
that fetch.o gets rebuilt (you should even be able to see the list of
"newer than" dependencies in the debug output)?
Another thing to double-check: does it work if you instead run
make all install COMPUTE_HEADER_DEPENDENCIES=no
?
-Peff
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Jeff King @ 2013-02-01 9:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git, Duy Nguyen
In-Reply-To: <CAJo=hJv0aqLpitnRJ6WKdPCETT6YgX5Njpv44DAYUg_KALhf=g@mail.gmail.com>
On Thu, Jan 31, 2013 at 09:03:26AM -0800, Shawn O. Pearce wrote:
> > Of course, it is more convenient to store this kind of things in a
> > separate file while experimenting and improving the mechanism, but I
> > do not think we want to see each packfile in a repository comes with
> > 47 auxiliary files with different suffixes 5 years down the road.
>
> Arrrrgggh.
>
> Right now we are in the middle of refactoring the JGit reachability
> bitmap implementation to store it into a separate file and get it out
> of the .idx file. This work is nearly completed. So this thread is
> great timing. :-)
>
> I think Junio is right about not wanting 47 different tiny auxiliary
> files for a single pack. We are unlikely to create that many, but
> right now there are proposals floating around for at least 2 new
> auxiliary files (commit cache and reachability bitmaps). So its not
> impossible that another will be discovered in the future.
Why don't we want 47 files (or even 3)? If it makes the implementation
more flexible or simple without sacrificing performance, I don't see a
problem. The filesystem is there to organize our data; we do not cram
all of our files into one just to save a few inodes.
We _do_ cram our data into packfiles and packed-refs when we can save
O(n) inodes. But if we are talking about a handful of extra files that
we must readdir() over while preparing the objects/pack directory, I
don't think that is the same thing.
The data dependency issues (can the files get out of sync? How common is
it? Can we detect it?) and performance issues are more interesting to
me. With respect to the latter, here's specifically what I'm thinking
of. Let's imagine we have an extension for reachability bitmaps that
takes up an extra 10MB. When we mmap the .idx file, do we always mmap
the extra bytes? What's the performance impact of the extra mmap? I
recall on some non-Linux systems it can be quite expensive. For most git
commands which are not going to do a reachability analysis, this is a
loss.
I don't know if this is an issue big enough to care about or not. But I
think it's worth benchmarking and including in the decision.
> Junio may be right about the hole in the index file for git-core. I
> haven't checked the JGit implementation, but I suspect it does not
> have this hole. IIRC JGit consumes the index sections and then expects
> the pack trailer SHA-1 to be present immediately after the last table.
> This happens because JGit doesn't use mmap() to load the index, it
> streams the file into memory and does some reformatting on the tables
> to make search faster.
Yeah, looking at the PackIndexV2 implementation, it counts the 64-bit
offsets from the first table, calculates the size of the large offset
table, reads past it, and then expects the pack checksum. So let's
assume we would have to bump to v3 to implement it inside the .idx file.
> If we are going to change the index to support extension sections and
> I have to modify JGit to grok this new format, it needs to be index v3
> not index v2. If we are making index v3 we should just put index v3 on
> the end of the pack file.
I'm not sure what you mean by your last sentence here.
-Peff
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Jeff King @ 2013-02-01 9:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Duy Nguyen, Shawn O. Pearce
In-Reply-To: <7vk3qvm962.fsf@alter.siamese.dyndns.org>
On Tue, Jan 29, 2013 at 11:17:41PM -0800, Junio C Hamano wrote:
> > True, but it is even less headache if the file is totally separate and
> > optional.
>
> Once you start thinking about using an offset to some list of SHA-1,
> perhaps? A section inside the same file can never go out of sync.
Yes, having a data dependency is important. It is unavoidable to have a
dependency on the packfile, though (and that is why the index and the
metapacks embed the sha1 of the packfile). If the offsets used are
packfile offsets, then that is sufficient.
If the offsets are from the index, then yes, putting it in the same file
is one way to keep them tied together. Another way is to do the same
sha1 verification, except to embed the sha1 of the index in the
metapack.
So I certainly consider putting the dependency-handling to be a point in
favor of the same file, but I'd weight it against other points (headache
of bumping index version, performance of both types, etc).
> Also a longer-term advantage is that you can teach index-pack to do
> this.
I think that is roughly the same amount of difficulty to do whether they
are in the same file or not.
-Peff
^ permalink raw reply
* Re: Re: Segmentation fault with latest git (070c57df)
From: Jongman Heo @ 2013-02-01 9:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Thomas Rast, git, Antoine Pelisse
Junio C Hamano<gitster@pobox.com> wrote :
> 허종만 writes:
>> But usually when I build upstream Linux kernel, I don't do "make
>> clean" after git pull.. I didn't expect that I needed "make
>> clean" for git build.
>
> We don't expect anybody need "make clean", either. There is
> something wrong in the dependency.
Hi all,
I can reproduce the issue in my machine (RedHat Enterprise 5, x86 PAE) as follows.
But in my different machine (Fedora 16 x86) I can't reproduce.
$ git reset --hard v1.8.1 # back to v1.8.1
$ make clean
$ make all install # this git works fine
$ git pull # top commit 9a6c84e6, "Merge git://ozlabs.org/~paulus/gitk"
$ make all install
$ git fetch # this git segfaults
Segmentation fault
So if there is any patch to test, just let me know (but will not available during weekend).
Regards,
Jongman Heo
^ permalink raw reply
* Re: [PATCH 0/2] optimizing pack access on "read only" fetch repos
From: Jeff King @ 2013-02-01 9:14 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <CAJo=hJuGw8x=VrjWhvZhzakuhWrCWr2FRuEsNt5gQNC=6PPuVw@mail.gmail.com>
On Thu, Jan 31, 2013 at 08:47:37AM -0800, Shawn O. Pearce wrote:
> >> - System resource cost we incur by having to keep 50 file
> >> descriptors open and maintaining 50 mmap windows will reduce by
> >> 50 fold.
> >
> > I wonder how measurable that is (and if it matters on Linux versus less
> > efficient platforms).
>
> It does matter. We know it has a negative impact on JGit even on Linux
> for example. You don't want 300 packs in a repository. 50 might be
> tolerable. 300 is not.
I'd love to see numbers if you have them. It's not that I don't believe
it is slower, but knowing _how much_ is important when thinking about
what kind of performance increase we are looking to get (which in turn
impacts how much effort to put into the repacking).
-Peff
^ permalink raw reply
* Re: [PATCH/RFC 0/6] commit caching
From: Jeff King @ 2013-02-01 9:11 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Duy Nguyen
In-Reply-To: <CAJo=hJtTYZg+1+RZVfEGTgOGzqxQbN1CLYWrvUp+WHKGxGwHMQ@mail.gmail.com>
On Thu, Jan 31, 2013 at 09:14:26AM -0800, Shawn O. Pearce wrote:
> On Tue, Jan 29, 2013 at 1:14 AM, Jeff King <peff@peff.net> wrote:
> > This is the cleaned-up version of the commit caching patches I mentioned
> > here:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/212329
> ...
> > The short of it is that for an extra 31M of disk
> > space (~4%), I get a warm-cache speedup for "git rev-list --all" of
> > ~4.2s to ~0.66s.
>
> I have to admit, this is a nice gain. I don't think users often dig
> through all commits to the root but I can see how this might improve
> git log with a path filter.
It doesn't just help digging to the roots. It should speed up most
traversals. So merge-bases, --contains, etc, would all be better. I
suspect we could also make --topo-order startup a lot faster, too.
It also helps "rev-list --objects --all", though obviously not by as
large a percentage. And since the main use of that is reachability
bitmaps, the improvements aren't as exciting there.
> > Coupled with using compression level 0 for trees (which do not compress
> > well at all, and yield only a 2% increase in size when left
> > uncompressed), my "git rev-list --objects --all" time drops from ~40s to
> > ~25s.
>
> This uhm.... is nice?
>
> But consider reachability bitmaps. ~40s to ~80ms. :-)
Yeah, yeah. I'm working my way up to it. :)
I wanted to see first how good we could get with a more generic
approach. I think this work may still have value even with reachability
bitmaps, as it will help regular traversals as well as tree access for
pathspec limiting.
At this point I'm convinced that my 25s is about the best we will do for
reachability analysis with a graph traversal. The repeated hashcmps to
see that we've visited each node are starting to dominate. So the next
obvious step is to try reachability bitmaps. I was hoping to iron out
the "pack metadata goes here" issues with the commit cache stuff,
though, as the actual cache implementation is quite simple (whereas the
bitmap stuff is more on the complex side, but can build on the same
metadata base).
> Yup. I have also futzed with the one in JGit for quite a while now. I
> pull some tricks there like making it a 2 level directory to reduce
> the need to find a contiguous array of 8M entries when processing the
> Linux kernel, and I try to preallocate the first level table based on
> the number of objects in pack-*.idx files. But the bottleneck is
> basically the cache lookups and hits, these happen like 100M times on
> 2M objects, because its every link in nearly every tree.
Right. I tried some multi-level tricks (and even a radix trie), but I
couldn't get anything to beat the simple-and-stupid single hash table
with linear probing.
> If we modified pack-objects' delta compressor for tree objects to only
> generate delta instructions at tree record boundaries, a delta-encoded
> tree can be processed without inflating the full content of that tree.
> Because of the way deltas are created, "most" tree deltas should have
> their delta base scanned by the object traversal before the delta is
> considered. This means the tree delta just needs to consider the much
> smaller records that are inserted into the base. We know these are
> different SHA-1s than what was there before, so they are more likely
> to be new to the lookup_object table.
So sort of a magic shortcut tree diff you get while accessing the
object. Neat idea.
> So the --objects traversal algorithm can change to get the delta base
> SHA-1 and raw tree delta from the pack storage. Perform a
> lookup_object on the base to see if it has been scanned. If it has,
> just scan the delta insert instructions. If the base has not yet been
> scanned, inflate the tree to its normal format and scan the entire
> tree.
This would not perform well if we hit the deltas before the bases. In
general, though, our "use the larger as the base" heuristic should mean
that our traversal hits the bases first.
> This is an approximation of what Nico and I were talking about doing
> for pack v4. But doesn't require a file format change. :-)
Yeah. It just needs to be very careful that the deltas it is looking at
all fall on record boundaries, since we might get deltas generated by
other versions of git. Can we necessarily identify that case for sure,
though? I imagine a tree delta like that would look something like:
delete bytes 100-120
add 20 bytes at offset 100: \x12\x34\x56...
Without looking at the base object, and without knowing whether the
delta was generated by our particular implementation, how can we be sure
this is a sha1 replacement and not the renaming of part of a file? Or
are you proposing some flag in the packfile to indicate "yes, this tree
really was delta'd only at record boundaries"?
It could be a big win, but it does seem quite complex and error-prone.
And it only helps with reachability, not regular traversals, so it's not
very generic. Which makes me think the bitmap route is a much better way
to go.
-Peff
^ permalink raw reply
* [BUG] git-clone fails due to GnuTLS recv error (-9), then deletes entire local repo
From: TJ @ 2013-02-01 9:00 UTC (permalink / raw)
To: git
Using Ubuntu Precise 12.04 with git version (1.8.0.3) I discovered a bug whereby git-clone deletes the repository
it has just created if there is a GnuTLS error after the final transfer.
I switched to building and using the current git head (1.8.1.2.433.g070c57d.dirty) and found the same issue is still present.
There are two problems here:
1. At the end of the transfer "GnuTLS recv error (-9): A TLS packet with unexpected length was received"
2. git-clone goes on to resolve deltas *then* deletes the entire repository
This is reported as Ubuntu bug #1111882 at https://bugs.launchpad.net/ubuntu/+bug/1111882
The following transcript uses git built with one local patch on top of commit 070c57d which fixes the $(INSTALL) file mode
issue as per my previous list posting "PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA".
GIT_CURL_VERBOSE=1 git clone -v https://git01.codeplex.com/typescript
the operation fails after the final git pack-file has been received and the already-created repository is deleted from the file system.
...
> POST /typescript/git-upload-pack HTTP/1.1
User-Agent: git/1.8.1.2.433.g9808ce0.dirty
Host: git01.codeplex.com
Accept-Encoding: gzip
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Length: 611
* upload completely sent off: 611out of 611 bytes
< HTTP/1.1 200 OK
< Cache-Control: no-cache, max-age=0, must-revalidate
< Pragma: no-cache
< Content-Type: application/x-git-upload-pack-result
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Server: Microsoft-IIS/7.5
< X-Powered-By: ASP.NET
< Date: Thu, 31 Jan 2013 21:43:55 GMT
< Connection: close
<
remote: Counting objects: 149766, done.
remote: Compressing objects: 100% (10580/10580), done.
* GnuTLS recv error (-9): A TLS packet with unexpected length was received.
* Closing connection #0
remote: Total 149766 (delta 138201), reused 149559 (delta 138077)
Receiving objects: 100% (149766/149766), 198.98 MiB | 361 KiB/s, done.
error: RPC failed; result=56, HTTP code = 200
Resolving deltas: 100% (138201/138201), done.
git exits at this point but it deletes the entire cloned ./typescript directory.
So far as I can tell from watching the ./typescript directory from another terminal and also the ethernet interface activity
the transfer is complete but GnuTLS is expecting something more from the HTTPS server which isn't forthcoming, leading to
the error.
The git bug - if this is accepted as a bug - is the deletion of the entire cloned repository.
I tried building the git binary and including an additional debug option in "http.c" that allowed me to set the protocol version using an environment option:
CURLOPT_SSLVERSION=1 git clone ...
where 1 = TLSv1, 2 = SSLv2, 3 = SSLv3.
I tried each protocol but the result was the same.
I did some experimentation using gnutl-cli-debug but was unable to figure out a way to reproduce the SSL/TLS error without
this particular git-clone operation. However, that is a GnuTLS bug, not a git bug.
I did try to build the latest gnutls but it needs a very recent version of libnettle which has the "rsa_decrypt_tr" function. I stopped at that point since I don't want to get into dependency and
library version issues.
Additional research seems to indicate this is a known intentional gnutls behaviour (that has been modified in very recent gnutls that makes use of a very recent libnettle - as mentioned above). The
issue is, apparently, the random size padding of packets to prevent communications compromise for stream ciphers.
I installed stunnel4 (which depends on openssl rather than gnutls) and created a reverse-proxy (client in stunnel terminology):
$ cat /etc/stunnel/rp-codeplex.com.conf
client = yes
[http]
accept = 8888
connect = git01.codeplex.com:443
TIMEOUTclose = 0
$ sudo sed -i 's/\(ENABLED\).*/\1=1/' /etc/default/stunnel4
$ sudo service stunnel4 restart
$ GIT_CURL_VERBOSE=1 git clone -v http://localhost:8888/typescript
...
> POST http://localhost:8888/typescript/git-upload-pack HTTP/1.1
User-Agent: git/1.8.1.2.433.g9808ce0.dirty
Host: localhost:8888
Accept-Encoding: gzip
Proxy-Connection: Keep-Alive
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Length: 611
* upload completely sent off: 611out of 611 bytes
< HTTP/1.1 200 OK
< Cache-Control: no-cache, max-age=0, must-revalidate
< Pragma: no-cache
< Content-Type: application/x-git-upload-pack-result
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Server: Microsoft-IIS/7.5
< X-Powered-By: ASP.NET
< Date: Thu, 31 Jan 2013 23:38:19 GMT
< Connection: close
<
remote: Counting objects: 149798, done.
remote: Compressing objects: 100% (10612/10612), done.
remote: Total 149798 (delta 138221), reused 149558 (delta 138077)
* Closing connection #0
Receiving objects: 100% (149798/149798), 198.99 MiB | 640 KiB/s, done.
Resolving deltas: 100% (138221/138221), done.
Checking out files: 100% (2851/2851), done.
^ permalink raw reply
* Re: [PATCH] Verify Content-Type from smart HTTP servers
From: Jeff King @ 2013-02-01 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7v38xhf1i3.fsf@alter.siamese.dyndns.org>
On Thu, Jan 31, 2013 at 02:09:40PM -0800, Junio C Hamano wrote:
> Before parsing a suspected smart-HTTP response verify the returned
> Content-Type matches the standard. This protects a client from
> attempting to process a payload that smells like a smart-HTTP
> server response.
>
> JGit has been doing this check on all responses since the dawn of
> time. I mistakenly failed to include it in git-core when smart HTTP
> was introduced. At the time I didn't know how to get the Content-Type
> from libcurl. I punted, meant to circle back and fix this, and just
> plain forgot about it.
>
> Signed-off-by: Shawn Pearce <spearce@spearce.org>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Should this be "From:" Shawn? The tone of the message and the S-O-B
order makes it look like it.
> @@ -133,16 +135,19 @@ static struct discovery* discover_refs(const char *service)
> last->buf = last->buf_alloc;
>
> if (maybe_smart && 5 <= last->len && last->buf[4] == '#') {
> - /* smart HTTP response; validate that the service
> + /*
> + * smart HTTP response; validate that the service
> * pkt-line matches our request.
> */
> - struct strbuf exp = STRBUF_INIT;
> -
> + strbuf_addf(&exp, "application/x-%s-advertisement", service);
> + if (strbuf_cmp(&exp, &type))
> + die("invalid content-type %s", type.buf);
Hmm. I wondered if it is possible for a non-smart server to send us down
this code path, which would now complain of the bogus content-type.
Something like an info/refs file with:
# 1
# the comment above is meaningless, but puts a "#" at position 4.
But I note that we would already die in the next line:
> if (packet_get_line(&buffer, &last->buf, &last->len) <= 0)
> die("%s has invalid packet header", refs_url);
so I do not think the patch makes anything worse. However, should we
take this opportunity to make the "did we get a smart response" test
more robust? That is, should we actually be checking the content-type
in the outer conditional, and going down the smart code-path if it is
application/x-%s-advertisement, and otherwise treating the result as
dumb?
It's probably not a big deal, as the false positive example above is
quite specific and unlikely, but it just seems cleaner to me.
As a side note, should we (can we) care about the content-type for dumb
http? It should probably be text/plain or application/octet-stream, but
I would not be surprised if we get a variety of random junk in the real
world, though.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
From: Michael Haggerty @ 2013-02-01 8:39 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <20130130203158.GN1342@serenity.lan>
On 01/30/2013 09:31 PM, John Keeping wrote:
> On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote:
>> [...] maybe we should establish a small Python library of
>> compatibility utilities (like a small "six"). [...]
>> But I haven't had time to think of where to put such a library, how to
>> install it, etc.
>
> If we want to go that route, I think restructuring the
> "git_remote_helpers" directory and re-using its infrastructure for
> installing the "Git Python modules" would be the way to go. The
> directory structure would become something like this:
>
> git/
> `-- python/
> |-- Makefile # existing file pulled out of git_remote_helpers
> |-- < some new utility library >
> |-- git_remote_helpers
> | |-- __init__.py
> | |-- git
> | | |-- __init__.py
> | | |-- exporter.py
> | | |-- git.py
> | | |-- importer.py
> | | |-- non_local.py
> | | `-- repo.py
> | `-- util.py
> |-- setup.cfg # existing file pulled out of git_remote_helpers
> `-- setup.py # existing file pulled out of git_remote_helpers
>
>
> It looks like the GitPython project[1] as already taken the "git" module
> name, so perhaps we should use "git_core" if we do introduce a new
> module.
>
> [1] http://pypi.python.org/pypi/GitPython
This sounds reasonable. But not all Python code will go under the
"python" subdirectory, right? For example, I am working on a Python
script that fits thematically under contrib/hooks.
OTOH (I'm thinking aloud here) it is probably a bad idea for a hook
script to depend on a Python module that is part of git itself. Doing
so would make the hook script depend on a particular version of git (or
at least a version with a compatible Python module). But users might be
reluctant to upgrade git just to install a hook script.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH 2/2] docs: convert "concept" manpages to git-*
From: Jeff King @ 2013-02-01 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201082538.GA25674@sigill.intra.peff.net>
The manpages for commands have always been spelled
"git-cmd". But "concept" manpages, like "gitrevisions" were
spelled without the dash. This is complex, and does not
actually buy anything. You might think it creates a separate
namespace for concepts and commands, but "git help foo" will
prefer the command form, meaning we must avoid such
conflicts anyway.
Let's just call everything git-*, which is simpler. This
patch renames the documentation files, updates the Makefile
to find them, and updates internal linkgit references to the
pages. It updates builtin/help.c so that users of "git help
foo" will not even notice the difference.
Users of external html links, or users who have trained
their fingers to type "man gitfoo" will notice the missing
pages. This patch does not install a "this page has moved"
placeholder, but that can easily be done on top.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/Makefile | 27 +++++++++--------
Documentation/config.txt | 8 ++---
Documentation/diff-options.txt | 4 +--
Documentation/git-cat-file.txt | 2 +-
Documentation/git-check-ref-format.txt | 2 +-
Documentation/git-cherry-pick.txt | 2 +-
Documentation/{gitcli.txt => git-cli.txt} | 8 ++---
Documentation/git-commit.txt | 4 +--
...{gitcore-tutorial.txt => git-core-tutorial.txt} | 20 ++++++-------
Documentation/git-credential-cache.txt | 2 +-
Documentation/git-credential-store.txt | 4 +--
.../{gitcredentials.txt => git-credentials.txt} | 6 ++--
...{gitcvs-migration.txt => git-cvs-migration.txt} | 22 +++++++-------
Documentation/git-cvsimport.txt | 2 +-
Documentation/git-cvsserver.txt | 2 +-
Documentation/git-diff.txt | 6 ++--
.../{gitdiffcore.txt => git-diffcore.txt} | 6 ++--
Documentation/git-fast-import.txt | 2 +-
Documentation/git-format-patch.txt | 2 +-
Documentation/git-gc.txt | 2 +-
.../{gitglossary.txt => git-glossary.txt} | 12 ++++----
Documentation/{githooks.txt => git-hooks.txt} | 6 ++--
Documentation/git-http-backend.txt | 2 +-
Documentation/git-log.txt | 2 +-
.../{gitnamespaces.txt => git-namespaces.txt} | 6 ++--
Documentation/git-push.txt | 2 +-
Documentation/git-rebase.txt | 4 +--
Documentation/git-receive-pack.txt | 2 +-
Documentation/git-reflog.txt | 2 +-
...sitory-layout.txt => git-repository-layout.txt} | 10 +++----
Documentation/git-rev-parse.txt | 2 +-
Documentation/git-revert.txt | 2 +-
.../{gitrevisions.txt => git-revisions.txt} | 6 ++--
Documentation/git-show-branch.txt | 2 +-
Documentation/git-show-ref.txt | 2 +-
Documentation/git-show.txt | 2 +-
.../{gittutorial-2.txt => git-tutorial-2.txt} | 24 +++++++--------
.../{gittutorial.txt => git-tutorial.txt} | 24 +++++++--------
Documentation/git-update-server-info.txt | 2 +-
Documentation/git-upload-pack.txt | 2 +-
.../{gitworkflows.txt => git-workflows.txt} | 8 ++---
Documentation/git.txt | 35 +++++++++++-----------
Documentation/gitignore.txt | 2 +-
Documentation/gitk.txt | 2 +-
Documentation/gitweb.conf.txt | 2 +-
Documentation/technical/api-credentials.txt | 2 +-
Documentation/user-manual.txt | 14 ++++-----
builtin/help.c | 4 +--
48 files changed, 159 insertions(+), 159 deletions(-)
rename Documentation/{gitcli.txt => git-cli.txt} (98%)
rename Documentation/{gitcore-tutorial.txt => git-core-tutorial.txt} (99%)
rename Documentation/{gitcredentials.txt => git-credentials.txt} (98%)
rename Documentation/{gitcvs-migration.txt => git-cvs-migration.txt} (94%)
rename Documentation/{gitdiffcore.txt => git-diffcore.txt} (99%)
rename Documentation/{gitglossary.txt => git-glossary.txt} (61%)
rename Documentation/{githooks.txt => git-hooks.txt} (99%)
rename Documentation/{gitnamespaces.txt => git-namespaces.txt} (97%)
rename Documentation/{gitrepository-layout.txt => git-repository-layout.txt} (97%)
rename Documentation/{gitrevisions.txt => git-revisions.txt} (88%)
rename Documentation/{gittutorial-2.txt => git-tutorial-2.txt} (96%)
rename Documentation/{gittutorial.txt => git-tutorial.txt} (97%)
rename Documentation/{gitworkflows.txt => git-workflows.txt} (99%)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 8e7939f..552cc37 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,28 +1,29 @@ MAN5_TXT += gitweb.conf.txt
MAN1_TXT += $(filter-out \
+ $(MAN5_TXT) $(MAN7_TXT) \
$(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard git-*.txt))
MAN1_TXT += git.txt
MAN1_TXT += gitk.txt
MAN1_TXT += gitweb.txt
+MAN5_TXT += git-hooks.txt
+MAN5_TXT += git-repository-layout.txt
MAN5_TXT += gitattributes.txt
-MAN5_TXT += githooks.txt
MAN5_TXT += gitignore.txt
MAN5_TXT += gitmodules.txt
-MAN5_TXT += gitrepository-layout.txt
MAN5_TXT += gitweb.conf.txt
-MAN7_TXT += gitcli.txt
-MAN7_TXT += gitcore-tutorial.txt
-MAN7_TXT += gitcredentials.txt
-MAN7_TXT += gitcvs-migration.txt
-MAN7_TXT += gitdiffcore.txt
-MAN7_TXT += gitglossary.txt
-MAN7_TXT += gitnamespaces.txt
-MAN7_TXT += gitrevisions.txt
-MAN7_TXT += gittutorial-2.txt
-MAN7_TXT += gittutorial.txt
-MAN7_TXT += gitworkflows.txt
+MAN7_TXT += git-cli.txt
+MAN7_TXT += git-core-tutorial.txt
+MAN7_TXT += git-credentials.txt
+MAN7_TXT += git-cvs-migration.txt
+MAN7_TXT += git-diffcore.txt
+MAN7_TXT += git-glossary.txt
+MAN7_TXT += git-namespaces.txt
+MAN7_TXT += git-revisions.txt
+MAN7_TXT += git-tutorial-2.txt
+MAN7_TXT += git-tutorial.txt
+MAN7_TXT += git-workflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d7ec507..666c6ed 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -952,23 +952,23 @@ credential.<url>.*::
Specify an external helper to be called when a username or
password credential is needed; the helper may consult external
storage to avoid prompting the user for the credentials. See
- linkgit:gitcredentials[7] for details.
+ linkgit:git-credentials[7] for details.
credential.useHttpPath::
When acquiring credentials, consider the "path" component of an http
or https URL to be important. Defaults to false. See
- linkgit:gitcredentials[7] for more information.
+ linkgit:git-credentials[7] for more information.
credential.username::
If no username is set for a network authentication, use this username
by default. See credential.<context>.* below, and
- linkgit:gitcredentials[7].
+ linkgit:git-credentials[7].
credential.<url>.*::
Any of the credential.* options above can be applied selectively to
some credentials. For example "credential.https://example.com.username"
would set the default username only for https connections to
- example.com. See linkgit:gitcredentials[7] for details on how URLs are
+ example.com. See linkgit:git-credentials[7] for details on how URLs are
matched.
include::diff-config.txt[]
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 39f2c50..562b0d4 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -366,7 +366,7 @@ ifndef::git-format-patch[]
Look for differences that introduce or remove an instance of
<string>. Note that this is different than the string simply
appearing in diff output; see the 'pickaxe' entry in
- linkgit:gitdiffcore[7] for more details.
+ linkgit:git-diffcore[7] for more details.
-G<regex>::
Look for differences whose added or removed line matches
@@ -481,4 +481,4 @@ For more detailed explanation on these common options, see also
Do not show any source or destination prefix.
For more detailed explanation on these common options, see also
-linkgit:gitdiffcore[7].
+linkgit:git-diffcore[7].
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index 2fb95bb..0f5b23a 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-file.txt
@@ -27,7 +27,7 @@ OPTIONS
<object>::
The name of the object to show.
For a more complete list of ways to spell object names, see
- the "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
+ the "SPECIFYING REVISIONS" section in linkgit:git-revisions[7].
-t::
Instead of the content, show the object type identified by
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 98009d1..d598044 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -59,7 +59,7 @@ unquoted (by mistake), and also avoids ambiguities in certain
These rules make it easy for shell script based tools to parse
reference names, pathname expansion by the shell when a reference name is used
unquoted (by mistake), and also avoids ambiguities in certain
-reference name expressions (see linkgit:gitrevisions[7]):
+reference name expressions (see linkgit:git-revisions[7]):
. A double-dot `..` is often used as in `ref1..ref2`, and in some
contexts this notation means `^ref1 ref2` (i.e. not in
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index c205d23..c2822b4 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -44,7 +44,7 @@ OPTIONS
<commit>...::
Commits to cherry-pick.
For a more complete list of ways to spell commits, see
- linkgit:gitrevisions[7].
+ linkgit:git-revisions[7].
Sets of commits can be passed but no traversal is done by
default, as if the '--no-walk' option was specified, see
linkgit:git-rev-list[1]. Note that specifying a range will
diff --git a/Documentation/gitcli.txt b/Documentation/git-cli.txt
similarity index 98%
rename from Documentation/gitcli.txt
rename to Documentation/git-cli.txt
index 3bc1500..f59f3b6 100644
--- a/Documentation/gitcli.txt
+++ b/Documentation/git-cli.txt
@@ -1,13 +1,13 @@ SYNOPSIS
-gitcli(7)
-=========
+git-cli(7)
+==========
NAME
----
-gitcli - git command line interface and conventions
+git-cli - git command line interface and conventions
SYNOPSIS
--------
-gitcli
+git *
DESCRIPTION
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 41b27da..d8a5143 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -157,7 +157,7 @@ OPTIONS
-n::
--no-verify::
This option bypasses the pre-commit and commit-msg hooks.
- See also linkgit:githooks[5].
+ See also linkgit:git-hooks[5].
--allow-empty::
Usually recording a commit that has the exact same tree as its
@@ -420,7 +420,7 @@ This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
HOOKS
-----
This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
-and `post-commit` hooks. See linkgit:githooks[5] for more
+and `post-commit` hooks. See linkgit:git-hooks[5] for more
information.
FILES
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/git-core-tutorial.txt
similarity index 99%
rename from Documentation/gitcore-tutorial.txt
rename to Documentation/git-core-tutorial.txt
index 5325c5a..1a07c92 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/git-core-tutorial.txt
@@ -1,9 +1,9 @@ NAME
-gitcore-tutorial(7)
-===================
+git-core-tutorial(7)
+====================
NAME
----
-gitcore-tutorial - A git core tutorial for developers
+git-core-tutorial - A git core tutorial for developers
SYNOPSIS
--------
@@ -16,7 +16,7 @@ If you just need to use git as a revision control system you may prefer
work with a git repository.
If you just need to use git as a revision control system you may prefer
-to start with "A Tutorial Introduction to GIT" (linkgit:gittutorial[7]) or
+to start with "A Tutorial Introduction to GIT" (linkgit:git-tutorial[7]) or
link:user-manual.html[the GIT User Manual].
However, an understanding of these low-level tools can be helpful if
@@ -116,7 +116,7 @@ populating your tree.
populating your tree.
[NOTE]
-An advanced user may want to take a look at linkgit:gitrepository-layout[5]
+An advanced user may want to take a look at linkgit:git-repository-layout[5]
after finishing this tutorial.
You have now created your first git repository. Of course, since it's
@@ -970,7 +970,7 @@ are branch heads. 'master^' is the first parent of 'master'
before the commit log message is a short name you can use to
name the commit. In the above example, 'master' and 'mybranch'
are branch heads. 'master^' is the first parent of 'master'
-branch head. Please see linkgit:gitrevisions[7] if you want to
+branch head. Please see linkgit:git-revisions[7] if you want to
see more complex cases.
[NOTE]
@@ -1595,7 +1595,7 @@ cooperation you are probably more familiar with as well.
have to worry. git supports "shared public repository" style of
cooperation you are probably more familiar with as well.
-See linkgit:gitcvs-migration[7] for the details.
+See linkgit:git-cvs-migration[7] for the details.
Bundling your work together
---------------------------
@@ -1696,9 +1696,9 @@ SEE ALSO
SEE ALSO
--------
-linkgit:gittutorial[7],
-linkgit:gittutorial-2[7],
-linkgit:gitcvs-migration[7],
+linkgit:git-tutorial[7],
+linkgit:git-tutorial-2[7],
+linkgit:git-cvs-migration[7],
linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/git-credential-cache.txt b/Documentation/git-credential-cache.txt
index eeff5fa..4a1c101 100644
--- a/Documentation/git-credential-cache.txt
+++ b/Documentation/git-credential-cache.txt
@@ -21,7 +21,7 @@ be used as a credential helper by other parts of git. See
You probably don't want to invoke this command directly; it is meant to
be used as a credential helper by other parts of git. See
-linkgit:gitcredentials[7] or `EXAMPLES` below.
+linkgit:git-credentials[7] or `EXAMPLES` below.
OPTIONS
-------
diff --git a/Documentation/git-credential-store.txt b/Documentation/git-credential-store.txt
index b27c03c..6761191 100644
--- a/Documentation/git-credential-store.txt
+++ b/Documentation/git-credential-store.txt
@@ -24,7 +24,7 @@ be used as a credential helper by other parts of git. See
You probably don't want to invoke this command directly; it is meant to
be used as a credential helper by other parts of git. See
-linkgit:gitcredentials[7] or `EXAMPLES` below.
+linkgit:git-credentials[7] or `EXAMPLES` below.
OPTIONS
-------
@@ -67,7 +67,7 @@ username (if we already have one) match, then the password is returned
credential-store will consider that context a pattern to match against
each entry in the credentials file. If the protocol, hostname, and
username (if we already have one) match, then the password is returned
-to git. See the discussion of configuration in linkgit:gitcredentials[7]
+to git. See the discussion of configuration in linkgit:git-credentials[7]
for more information.
GIT
diff --git a/Documentation/gitcredentials.txt b/Documentation/git-credentials.txt
similarity index 98%
rename from Documentation/gitcredentials.txt
rename to Documentation/git-credentials.txt
index 7dfffc0..85aa1b6 100644
--- a/Documentation/gitcredentials.txt
+++ b/Documentation/git-credentials.txt
@@ -1,9 +1,9 @@ NAME
-gitcredentials(7)
-=================
+git-credentials(7)
+==================
NAME
----
-gitcredentials - providing usernames and passwords to git
+git-credentials - providing usernames and passwords to git
SYNOPSIS
--------
diff --git a/Documentation/gitcvs-migration.txt b/Documentation/git-cvs-migration.txt
similarity index 94%
rename from Documentation/gitcvs-migration.txt
rename to Documentation/git-cvs-migration.txt
index aeb0cdc..6adc45a 100644
--- a/Documentation/gitcvs-migration.txt
+++ b/Documentation/git-cvs-migration.txt
@@ -1,9 +1,9 @@ NAME
-gitcvs-migration(7)
-===================
+git-cvs-migration(7)
+====================
NAME
----
-gitcvs-migration - git for CVS users
+git-cvs-migration - git for CVS users
SYNOPSIS
--------
@@ -20,8 +20,8 @@ Some basic familiarity with git is required. Having gone through
this document explains how to do that.
Some basic familiarity with git is required. Having gone through
-linkgit:gittutorial[7] and
-linkgit:gitglossary[7] should be sufficient.
+linkgit:git-tutorial[7] and
+linkgit:git-glossary[7] should be sufficient.
Developing against a shared repository
--------------------------------------
@@ -83,7 +83,7 @@ possibly created from scratch or from a tarball (see
We assume you have already created a git repository for your project,
possibly created from scratch or from a tarball (see
-linkgit:gittutorial[7]), or imported from an already existing CVS
+linkgit:git-tutorial[7]), or imported from an already existing CVS
repository (see the next section).
Assume your existing repo is at /home/alice/myproject. Create a new "bare"
@@ -154,7 +154,7 @@ points. You can use these, for example, to send all commits to the shared
Git allows you to specify scripts called "hooks" to be run at certain
points. You can use these, for example, to send all commits to the shared
-repository to a mailing list. See linkgit:githooks[5].
+repository to a mailing list. See linkgit:git-hooks[5].
You can enforce finer grained permissions using update hooks. See
link:howto/update-hook-example.txt[Controlling access to branches using
@@ -190,10 +190,10 @@ SEE ALSO
SEE ALSO
--------
-linkgit:gittutorial[7],
-linkgit:gittutorial-2[7],
-linkgit:gitcore-tutorial[7],
-linkgit:gitglossary[7],
+linkgit:git-tutorial[7],
+linkgit:git-tutorial-2[7],
+linkgit:git-core-tutorial[7],
+linkgit:git-glossary[7],
link:everyday.html[Everyday Git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 9d5353e..ac2cfbf 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -38,7 +38,7 @@ and use the clone as the shared repository.
read/write, or if you want to use linkgit:git-cvsserver[1], then you
probably want to make a bare clone of the imported repository,
and use the clone as the shared repository.
-See linkgit:gitcvs-migration[7].
+See linkgit:git-cvs-migration[7].
OPTIONS
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 940c2ba..895c191 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -163,7 +163,7 @@ You also need to ensure that each repository is "bare" (without a git index
SSH, the users of course also need write access to the git repository itself.
You also need to ensure that each repository is "bare" (without a git index
-file) for `cvs commit` to work. See linkgit:gitcvs-migration[7].
+file) for `cvs commit` to work. See linkgit:git-cvs-migration[7].
[[configaccessmethod]]
All configuration variables can also be overridden for a specific method of
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index f8c0601..7c89f0d 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -81,11 +81,11 @@ and the range notations ("<commit>..<commit>" and
<tree>.
For a more complete list of ways to spell <commit>, see
-"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
+"SPECIFYING REVISIONS" section in linkgit:git-revisions[7].
However, "diff" is about comparing two _endpoints_, not ranges,
and the range notations ("<commit>..<commit>" and
"<commit>\...<commit>") do not mean a range as defined in the
-"SPECIFYING RANGES" section in linkgit:gitrevisions[7].
+"SPECIFYING RANGES" section in linkgit:git-revisions[7].
OPTIONS
-------
@@ -175,7 +175,7 @@ linkgit:git-log[1],
diff(1),
linkgit:git-difftool[1],
linkgit:git-log[1],
-linkgit:gitdiffcore[7],
+linkgit:git-diffcore[7],
linkgit:git-format-patch[1],
linkgit:git-apply[1]
diff --git a/Documentation/gitdiffcore.txt b/Documentation/git-diffcore.txt
similarity index 99%
rename from Documentation/gitdiffcore.txt
rename to Documentation/git-diffcore.txt
index daf1782..9dfdce8 100644
--- a/Documentation/gitdiffcore.txt
+++ b/Documentation/git-diffcore.txt
@@ -1,9 +1,9 @@ NAME
-gitdiffcore(7)
+git-diffcore(7)
==============
NAME
----
-gitdiffcore - Tweaking diff output
+git-diffcore - Tweaking diff output
SYNOPSIS
--------
@@ -274,7 +274,7 @@ linkgit:git-log[1],
linkgit:git-diff-tree[1],
linkgit:git-format-patch[1],
linkgit:git-log[1],
-linkgit:gitglossary[7],
+linkgit:git-glossary[7],
link:user-manual.html[The Git User's Manual]
GIT
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index bf1a02a..6b7d33a 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -481,7 +481,7 @@ Marks must be declared (via `mark`) before they can be used.
* A complete 40 byte or abbreviated commit SHA-1 in hex.
* Any valid Git SHA-1 expression that resolves to a commit. See
- ``SPECIFYING REVISIONS'' in linkgit:gitrevisions[7] for details.
+ ``SPECIFYING REVISIONS'' in linkgit:git-revisions[7] for details.
The special case of restarting an incremental import from the
current branch value should be written as:
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 9a914d0..70d7cbf 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -39,7 +39,7 @@ There are two ways to specify which commits to operate on.
that leads to the <since> to be output.
2. Generic <revision range> expression (see "SPECIFYING
- REVISIONS" section in linkgit:gitrevisions[7]) means the
+ REVISIONS" section in linkgit:git-revisions[7]) means the
commits in the specified range.
The first rule takes precedence in the case of a single <commit>. To
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index b370b02..f54f8c4 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -142,7 +142,7 @@ The 'git gc --auto' command will run the 'pre-auto-gc' hook. See
-----
The 'git gc --auto' command will run the 'pre-auto-gc' hook. See
-linkgit:githooks[5] for more information.
+linkgit:git-hooks[5] for more information.
SEE ALSO
diff --git a/Documentation/gitglossary.txt b/Documentation/git-glossary.txt
similarity index 61%
rename from Documentation/gitglossary.txt
rename to Documentation/git-glossary.txt
index d77a45a..c8157fe 100644
--- a/Documentation/gitglossary.txt
+++ b/Documentation/git-glossary.txt
@@ -1,9 +1,9 @@ NAME
-gitglossary(7)
-==============
+git-glossary(7)
+===============
NAME
----
-gitglossary - A GIT Glossary
+git-glossary - A GIT Glossary
SYNOPSIS
--------
@@ -16,9 +16,9 @@ SEE ALSO
SEE ALSO
--------
-linkgit:gittutorial[7],
-linkgit:gittutorial-2[7],
-linkgit:gitcvs-migration[7],
+linkgit:git-tutorial[7],
+linkgit:git-tutorial-2[7],
+linkgit:git-cvs-migration[7],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/githooks.txt b/Documentation/git-hooks.txt
similarity index 99%
rename from Documentation/githooks.txt
rename to Documentation/git-hooks.txt
index d839233..7a3bc3b 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/git-hooks.txt
@@ -1,9 +1,9 @@ NAME
-githooks(5)
-===========
+git-hooks(5)
+============
NAME
----
-githooks - Hooks used by git
+git-hooks - Hooks used by git
SYNOPSIS
--------
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index f4e0741..a0ffb25 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -120,7 +120,7 @@ ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
----------------------------------------------------------------
+
-To serve multiple repositories from different linkgit:gitnamespaces[7] in a
+To serve multiple repositories from different linkgit:git-namespaces[7] in a
single repository:
+
----------------------------------------------------------------
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 22c0d6e..79000d4 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -29,7 +29,7 @@ OPTIONS
either <since> or <until> is omitted, it defaults to
`HEAD`, i.e. the tip of the current branch.
For a more complete list of ways to spell <since>
- and <until>, see linkgit:gitrevisions[7].
+ and <until>, see linkgit:git-revisions[7].
--follow::
Continue listing the history of a file beyond renames
diff --git a/Documentation/gitnamespaces.txt b/Documentation/git-namespaces.txt
similarity index 97%
rename from Documentation/gitnamespaces.txt
rename to Documentation/git-namespaces.txt
index c6713cf..a031ee7 100644
--- a/Documentation/gitnamespaces.txt
+++ b/Documentation/git-namespaces.txt
@@ -1,9 +1,9 @@ NAME
-gitnamespaces(7)
-================
+git-namespaces(7)
+=================
NAME
----
-gitnamespaces - Git namespaces
+git-namespaces - Git namespaces
SYNOPSIS
--------
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index c964b79..c78469c 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -43,7 +43,7 @@ it can be any arbitrary "SHA-1 expression", such as `master~4` or
+
The <src> is often the name of the branch you would want to push, but
it can be any arbitrary "SHA-1 expression", such as `master~4` or
-`HEAD` (see linkgit:gitrevisions[7]).
+`HEAD` (see linkgit:git-revisions[7]).
+
The <dst> tells which ref on the remote side is updated with this
push. Arbitrary expressions cannot be used here, an actual ref must
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index da067ec..ee5837c 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -295,11 +295,11 @@ which makes little sense.
Do not show a diffstat as part of the rebase process.
--no-verify::
- This option bypasses the pre-rebase hook. See also linkgit:githooks[5].
+ This option bypasses the pre-rebase hook. See also linkgit:git-hooks[5].
--verify::
Allows the pre-rebase hook to run, which is the default. This option can
- be used to override --no-verify. See also linkgit:githooks[5].
+ be used to override --no-verify. See also linkgit:git-hooks[5].
-C<n>::
Ensure at least <n> lines of surrounding context match before
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index b1f7dc6..905a186 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -150,7 +150,7 @@ SEE ALSO
SEE ALSO
--------
-linkgit:git-send-pack[1], linkgit:gitnamespaces[7]
+linkgit:git-send-pack[1], linkgit:git-namespaces[7]
GIT
---
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 7fe2d22..a12f63b 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -41,7 +41,7 @@ two moves ago", `master@{one.week.ago}` means "where master used to
The reflog is useful in various git commands, to specify the old value
of a reference. For example, `HEAD@{2}` means "where HEAD used to be
two moves ago", `master@{one.week.ago}` means "where master used to
-point to one week ago", and so on. See linkgit:gitrevisions[7] for
+point to one week ago", and so on. See linkgit:git-revisions[7] for
more details.
To delete single entries from the reflog, use the subcommand "delete"
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/git-repository-layout.txt
similarity index 97%
rename from Documentation/gitrepository-layout.txt
rename to Documentation/git-repository-layout.txt
index 9f62886..7602980 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/git-repository-layout.txt
@@ -1,9 +1,9 @@ NAME
-gitrepository-layout(5)
-=======================
+git-repository-layout(5)
+========================
NAME
----
-gitrepository-layout - Git Repository Layout
+git-repository-layout - Git Repository Layout
SYNOPSIS
--------
@@ -136,7 +136,7 @@ hooks::
'git init' is run, but all of them are disabled by
default. To enable, the `.sample` suffix has to be
removed from the filename by renaming.
- Read linkgit:githooks[5] for more details about
+ Read linkgit:git-hooks[5] for more details about
each hook.
index::
@@ -203,7 +203,7 @@ linkgit:git-checkout[1],
linkgit:git-pack-refs[1],
linkgit:git-gc[1],
linkgit:git-checkout[1],
-linkgit:gitglossary[7],
+linkgit:git-glossary[7],
link:user-manual.html[The Git User's Manual]
GIT
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 3c63561..ce9cee4 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -236,7 +236,7 @@ Each line of options has this format:
* Use `*` to mean that this option should not be listed in the usage
generated for the `-h` argument. It's shown for `--help-all` as
- documented in linkgit:gitcli[7].
+ documented in linkgit:git-cli[7].
* Use `!` to not make the corresponding negated long option available.
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 70152e8..b6e3a48 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -35,7 +35,7 @@ OPTIONS
<commit>...::
Commits to revert.
For a more complete list of ways to spell commit names, see
- linkgit:gitrevisions[7].
+ linkgit:git-revisions[7].
Sets of commits can also be given but no traversal is done by
default, see linkgit:git-rev-list[1] and its '--no-walk'
option.
diff --git a/Documentation/gitrevisions.txt b/Documentation/git-revisions.txt
similarity index 88%
rename from Documentation/gitrevisions.txt
rename to Documentation/git-revisions.txt
index fc4789f..3bf4531 100644
--- a/Documentation/gitrevisions.txt
+++ b/Documentation/git-revisions.txt
@@ -1,13 +1,13 @@ SYNOPSIS
-gitrevisions(7)
+git-revisions(7)
================
NAME
----
-gitrevisions - specifying revisions and ranges for git
+git-revisions - specifying revisions and ranges for git
SYNOPSIS
--------
-gitrevisions
+git-revisions
DESCRIPTION
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index a8e77b5..d5c27f7 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -31,7 +31,7 @@ OPTIONS
OPTIONS
-------
<rev>::
- Arbitrary extended SHA1 expression (see linkgit:gitrevisions[7])
+ Arbitrary extended SHA1 expression (see linkgit:git-revisions[7])
that typically names a branch head or a tag.
<glob>::
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index 5dbcd47..ca28bc7 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -175,7 +175,7 @@ linkgit:git-update-ref[1],
--------
linkgit:git-ls-remote[1],
linkgit:git-update-ref[1],
-linkgit:gitrepository-layout[5]
+linkgit:git-repository-layout[5]
GIT
---
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index ae4edcc..81bd45e 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -37,7 +37,7 @@ OPTIONS
<object>...::
The names of objects to show.
For a more complete list of ways to spell object names, see
- "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
+ "SPECIFYING REVISIONS" section in linkgit:git-revisions[7].
include::pretty-options.txt[]
diff --git a/Documentation/gittutorial-2.txt b/Documentation/git-tutorial-2.txt
similarity index 96%
rename from Documentation/gittutorial-2.txt
rename to Documentation/git-tutorial-2.txt
index e00a4d2..8ca2912 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/git-tutorial-2.txt
@@ -1,9 +1,9 @@ NAME
-gittutorial-2(7)
-================
+git-tutorial-2(7)
+=================
NAME
----
-gittutorial-2 - A tutorial introduction to git: part two
+git-tutorial-2 - A tutorial introduction to git: part two
SYNOPSIS
--------
@@ -13,7 +13,7 @@ DESCRIPTION
DESCRIPTION
-----------
-You should work through linkgit:gittutorial[7] before reading this tutorial.
+You should work through linkgit:git-tutorial[7] before reading this tutorial.
The goal of this tutorial is to introduce two fundamental pieces of
git's architecture--the object database and the index file--and to
@@ -395,7 +395,7 @@ branch, and is used to hold the trees involved in a merge operation.
In addition to being the staging area for new commits, the index file
is also populated from the object database when checking out a
branch, and is used to hold the trees involved in a merge operation.
-See linkgit:gitcore-tutorial[7] and the relevant man
+See linkgit:git-core-tutorial[7] and the relevant man
pages for details.
What next?
@@ -404,28 +404,28 @@ SEE ALSO
At this point you should know everything necessary to read the man
pages for any of the git commands; one good place to start would be
with the commands mentioned in link:everyday.html[Everyday git]. You
-should be able to find any unknown jargon in linkgit:gitglossary[7].
+should be able to find any unknown jargon in linkgit:git-glossary[7].
The link:user-manual.html[Git User's Manual] provides a more
comprehensive introduction to git.
-linkgit:gitcvs-migration[7] explains how to
+linkgit:git-cvs-migration[7] explains how to
import a CVS repository into git, and shows how to use git in a
CVS-like way.
For some interesting examples of git use, see the
link:howto-index.html[howtos].
-For git developers, linkgit:gitcore-tutorial[7] goes
+For git developers, linkgit:git-core-tutorial[7] goes
into detail on the lower-level git mechanisms involved in, for
example, creating a new commit.
SEE ALSO
--------
-linkgit:gittutorial[7],
-linkgit:gitcvs-migration[7],
-linkgit:gitcore-tutorial[7],
-linkgit:gitglossary[7],
+linkgit:git-tutorial[7],
+linkgit:git-cvs-migration[7],
+linkgit:git-core-tutorial[7],
+linkgit:git-glossary[7],
linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gittutorial.txt b/Documentation/git-tutorial.txt
similarity index 97%
rename from Documentation/gittutorial.txt
rename to Documentation/git-tutorial.txt
index f1cb6f3..189d01f 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/git-tutorial.txt
@@ -1,9 +1,9 @@ NAME
-gittutorial(7)
-==============
+git-tutorial(7)
+===============
NAME
----
-gittutorial - A tutorial introduction to git (for version 1.5.1 or newer)
+git-tutorial - A tutorial introduction to git (for version 1.5.1 or newer)
SYNOPSIS
--------
@@ -455,7 +455,7 @@ that various users push changes to; see linkgit:git-push[1] and
Git can also be used in a CVS-like mode, with a central repository
that various users push changes to; see linkgit:git-push[1] and
-linkgit:gitcvs-migration[7].
+linkgit:git-cvs-migration[7].
Exploring history
-----------------
@@ -636,7 +636,7 @@ database, the index file, and a few other odds and ends that you'll
Part two of this tutorial explains the object
database, the index file, and a few other odds and ends that you'll
-need to make the most of git. You can find it at linkgit:gittutorial-2[7].
+need to make the most of git. You can find it at linkgit:git-tutorial-2[7].
If you don't want to continue with that right away, a few other
digressions that may be interesting at this point are:
@@ -653,21 +653,21 @@ linkgit:git-help[1],
smart enough to perform a close-to-optimal search even in the
case of complex non-linear history with lots of merged branches.
- * linkgit:gitworkflows[7]: Gives an overview of recommended
+ * linkgit:git-workflows[7]: Gives an overview of recommended
workflows.
* link:everyday.html[Everyday GIT with 20 Commands Or So]
- * linkgit:gitcvs-migration[7]: Git for CVS users.
+ * linkgit:git-cvs-migration[7]: Git for CVS users.
SEE ALSO
--------
-linkgit:gittutorial-2[7],
-linkgit:gitcvs-migration[7],
-linkgit:gitcore-tutorial[7],
-linkgit:gitglossary[7],
+linkgit:git-tutorial-2[7],
+linkgit:git-cvs-migration[7],
+linkgit:git-core-tutorial[7],
+linkgit:git-glossary[7],
linkgit:git-help[1],
-linkgit:gitworkflows[7],
+linkgit:git-workflows[7],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/git-update-server-info.txt b/Documentation/git-update-server-info.txt
index bd0e364..800ab5e 100644
--- a/Documentation/git-update-server-info.txt
+++ b/Documentation/git-update-server-info.txt
@@ -32,7 +32,7 @@ Currently the command updates the following files. Please see
------
Currently the command updates the following files. Please see
-linkgit:gitrepository-layout[5] for description of
+linkgit:git-repository-layout[5] for description of
what they are for:
* objects/info/packs
diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt
index 71f1608..44b9219 100644
--- a/Documentation/git-upload-pack.txt
+++ b/Documentation/git-upload-pack.txt
@@ -36,7 +36,7 @@ SEE ALSO
SEE ALSO
--------
-linkgit:gitnamespaces[7]
+linkgit:git-namespaces[7]
GIT
---
diff --git a/Documentation/gitworkflows.txt b/Documentation/git-workflows.txt
similarity index 99%
rename from Documentation/gitworkflows.txt
rename to Documentation/git-workflows.txt
index 8b8c6ae..8fe1c95 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/git-workflows.txt
@@ -1,9 +1,9 @@ NAME
-gitworkflows(7)
-===============
+git-workflows(7)
+================
NAME
----
-gitworkflows - An overview of recommended workflows with git
+git-workflows - An overview of recommended workflows with git
SYNOPSIS
--------
@@ -466,7 +466,7 @@ SEE ALSO
SEE ALSO
--------
-linkgit:gittutorial[7],
+linkgit:git-tutorial[7],
linkgit:git-push[1],
linkgit:git-pull[1],
linkgit:git-merge[1],
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 555250d..d9d7755 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -21,14 +21,14 @@ page to learn what commands git offers. You can learn more about
unusually rich command set that provides both high-level operations
and full access to internals.
-See linkgit:gittutorial[7] to get started, then see
+See linkgit:git-tutorial[7] to get started, then see
link:everyday.html[Everyday Git] for a useful minimum set of
commands. The link:user-manual.html[Git User's Manual] has a more
in-depth introduction.
After you mastered the basic concepts, you can come back to this
page to learn what commands git offers. You can learn more about
-individual git commands with "git help command". linkgit:gitcli[7]
+individual git commands with "git help command". linkgit:git-cli[7]
manual page gives you an overview of the command line command syntax.
Formatted and hyperlinked version of the latest git documentation
@@ -416,7 +416,7 @@ help ...`.
more detailed discussion).
--namespace=<path>::
- Set the git namespace. See linkgit:gitnamespaces[7] for more
+ Set the git namespace. See linkgit:git-namespaces[7] for more
details. Equivalent to setting the `GIT_NAMESPACE` environment
variable.
@@ -611,15 +611,15 @@ Please see the linkgit:gitrepository-layout[5] document.
(i.e. a `refs/heads/<head>` reference).
For a more complete list of ways to spell object names, see
-"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
+"SPECIFYING REVISIONS" section in linkgit:git-revisions[7].
File/Directory Structure
------------------------
-Please see the linkgit:gitrepository-layout[5] document.
+Please see the linkgit:git-repository-layout[5] document.
-Read linkgit:githooks[5] for more details about each hook.
+Read linkgit:git-hooks[5] for more details about each hook.
Higher level SCMs may provide and manage additional information in the
`$GIT_DIR`.
@@ -627,7 +627,7 @@ Terminology
Terminology
-----------
-Please see linkgit:gitglossary[7].
+Please see linkgit:git-glossary[7].
Environment Variables
@@ -672,7 +672,7 @@ git so take care if using Cogito etc.
option and the core.worktree configuration variable.
'GIT_NAMESPACE'::
- Set the git namespace; see linkgit:gitnamespaces[7] for details.
+ Set the git namespace; see linkgit:git-namespaces[7] for details.
The '--namespace' command-line option also sets this value.
'GIT_CEILING_DIRECTORIES'::
@@ -825,7 +825,7 @@ link:user-manual.html#git-concepts[git concepts chapter of the
More detail on the following is available from the
link:user-manual.html#git-concepts[git concepts chapter of the
-user-manual] and linkgit:gitcore-tutorial[7].
+user-manual] and linkgit:git-core-tutorial[7].
A git project normally consists of a working directory with a ".git"
subdirectory at the top level. The .git directory contains, among other
@@ -881,10 +881,10 @@ introductions to the underlying git architecture.
for a first-time user.
The link:user-manual.html#git-concepts[git concepts chapter of the
-user-manual] and linkgit:gitcore-tutorial[7] both provide
+user-manual] and linkgit:git-core-tutorial[7] both provide
introductions to the underlying git architecture.
-See linkgit:gitworkflows[7] for an overview of recommended workflows.
+See linkgit:git-workflows[7] for an overview of recommended workflows.
See also the link:howto-index.html[howto] documents for some useful
examples.
@@ -893,7 +893,7 @@ Users migrating from CVS may also want to
link:technical/api-index.html[GIT API documentation].
Users migrating from CVS may also want to
-read linkgit:gitcvs-migration[7].
+read linkgit:git-cvs-migration[7].
Authors
@@ -916,12 +916,13 @@ Part of the linkgit:git[1] suite
SEE ALSO
--------
-linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-link:everyday.html[Everyday Git], linkgit:gitcvs-migration[7],
-linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
-linkgit:gitcli[7], link:user-manual.html[The Git User's Manual],
-linkgit:gitworkflows[7]
+linkgit:git-tutorial[7], linkgit:git-tutorial-2[7],
+link:everyday.html[Everyday Git], linkgit:git-cvs-migration[7],
+linkgit:git-glossary[7], linkgit:git-core-tutorial[7],
+linkgit:git-cli[7], link:user-manual.html[The Git User's Manual],
+linkgit:git-workflows[7]
GIT
---
Part of the linkgit:git[1] suite
+
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 0da205f..5b6d396 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -186,7 +186,7 @@ linkgit:git-update-index[1],
--------
linkgit:git-rm[1],
linkgit:git-update-index[1],
-linkgit:gitrepository-layout[5],
+linkgit:git-repository-layout[5],
linkgit:git-check-ignore[1]
GIT
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index a17a354..a931cb2 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -70,7 +70,7 @@ frequently used options.
the form "'<from>'..'<to>'" to show all revisions between '<from>' and
back to '<to>'. Note, more advanced revision selection can be applied.
For a more complete list of ways to spell object names, see
- linkgit:gitrevisions[7].
+ linkgit:git-revisions[7].
<path>...::
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index 4947455..05a2384 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -676,7 +676,7 @@ description of `-S<string>` option, which refers to pickaxe entry in
+
The pickaxe search is described in linkgit:git-log[1] (the
description of `-S<string>` option, which refers to pickaxe entry in
-linkgit:gitdiffcore[7] for more details).
+linkgit:git-diffcore[7] for more details).
+
This feature can be configured on a per-repository basis by setting
repository's `gitweb.pickaxe` configuration variable (boolean).
diff --git a/Documentation/technical/api-credentials.txt b/Documentation/technical/api-credentials.txt
index 5977b58..642d570 100644
--- a/Documentation/technical/api-credentials.txt
+++ b/Documentation/technical/api-credentials.txt
@@ -263,6 +263,6 @@ See also
See also
--------
-linkgit:gitcredentials[7]
+linkgit:git-credentials[7]
linkgit:git-config[5] (See configuration variables `credential.*`)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 1b377dc..0bde9b7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -408,7 +408,7 @@ references with the same shorthand name, see the "SPECIFYING
For the complete list of paths which git checks for references, and
the order it uses to decide which to choose when there are multiple
references with the same shorthand name, see the "SPECIFYING
-REVISIONS" section of linkgit:gitrevisions[7].
+REVISIONS" section of linkgit:git-revisions[7].
[[Updating-a-repository-With-git-fetch]]
Updating a repository with git fetch
@@ -579,7 +579,7 @@ There are many more; see the "SPECIFYING REVISIONS" section of the
- HEAD: refers to the head of the current branch
There are many more; see the "SPECIFYING REVISIONS" section of the
-linkgit:gitrevisions[7] man page for the complete list of ways to
+linkgit:git-revisions[7] man page for the complete list of ways to
name revisions. Some examples:
-------------------------------------------------
@@ -920,7 +920,7 @@ $ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
$ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
-------------------------------------------------
-(See linkgit:gitrevisions[7] for explanations of commit-selecting
+(See linkgit:git-revisions[7] for explanations of commit-selecting
syntax such as `--not`.)
[[making-a-release]]
@@ -1651,7 +1651,7 @@ how to control this pruning, and see the "SPECIFYING REVISIONS"
The reflogs are kept by default for 30 days, after which they may be
pruned. See linkgit:git-reflog[1] and linkgit:git-gc[1] to learn
how to control this pruning, and see the "SPECIFYING REVISIONS"
-section of linkgit:gitrevisions[7] for details.
+section of linkgit:git-revisions[7] for details.
Note that the reflog history is very different from normal git history.
While normal history is shared by every repository that works on the
@@ -1949,7 +1949,7 @@ $ mv hooks/post-update.sample hooks/post-update
-------------------------------------------------
(For an explanation of the last two lines, see
-linkgit:git-update-server-info[1] and linkgit:githooks[5].)
+linkgit:git-update-server-info[1] and linkgit:git-hooks[5].)
Advertise the URL of proj.git. Anybody else should then be able to
clone or pull from that URL, for example with a command line like:
@@ -2061,7 +2061,7 @@ pull, or by a fetch followed by a rebase; see the
solution is to retry the push after first updating your work: either by a
pull, or by a fetch followed by a rebase; see the
<<setting-up-a-shared-repository,next section>> and
-linkgit:gitcvs-migration[7] for more.
+linkgit:git-cvs-migration[7] for more.
[[setting-up-a-shared-repository]]
Setting up a shared repository
@@ -2070,7 +2070,7 @@ all push to and pull from a single shared repository. See
Another way to collaborate is by using a model similar to that
commonly used in CVS, where several developers with special rights
all push to and pull from a single shared repository. See
-linkgit:gitcvs-migration[7] for instructions on how to
+linkgit:git-cvs-migration[7] for instructions on how to
set this up.
However, while there is nothing wrong with git's support for shared
diff --git a/builtin/help.c b/builtin/help.c
index 6067a61..1eca4ea 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -308,10 +308,8 @@ static const char *cmd_to_page(const char *git_cmd)
return "git";
else if (!prefixcmp(git_cmd, "git"))
return git_cmd;
- else if (is_git_command(git_cmd))
- return prepend("git-", git_cmd);
else
- return prepend("git", git_cmd);
+ return prepend("git-", git_cmd);
}
static void setup_man_path(void)
--
1.8.1.2.11.g1a2f572
^ permalink raw reply related
* [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
From: Jeff King @ 2013-02-01 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201082538.GA25674@sigill.intra.peff.net>
We keep a list of the various files that end up as man1,
man5, etc. Let's break these single-line lists into sorted
multi-line lists, which makes diffs that touch them much
easier to read.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/Makefile | 33 ++++++++++++++++++++++++---------
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 971977b..8e7939f 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt
-MAN1_TXT= \
- $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
- $(wildcard git-*.txt)) \
- gitk.txt gitweb.txt git.txt
-MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
- gitrepository-layout.txt gitweb.conf.txt
-MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
- gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
- gitdiffcore.txt gitnamespaces.txt gitrevisions.txt gitworkflows.txt
+MAN1_TXT += $(filter-out \
+ $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
+ $(wildcard git-*.txt))
+MAN1_TXT += git.txt
+MAN1_TXT += gitk.txt
+MAN1_TXT += gitweb.txt
+
+MAN5_TXT += gitattributes.txt
+MAN5_TXT += githooks.txt
+MAN5_TXT += gitignore.txt
+MAN5_TXT += gitmodules.txt
+MAN5_TXT += gitrepository-layout.txt
+MAN5_TXT += gitweb.conf.txt
+
+MAN7_TXT += gitcli.txt
+MAN7_TXT += gitcore-tutorial.txt
MAN7_TXT += gitcredentials.txt
+MAN7_TXT += gitcvs-migration.txt
+MAN7_TXT += gitdiffcore.txt
+MAN7_TXT += gitglossary.txt
+MAN7_TXT += gitnamespaces.txt
+MAN7_TXT += gitrevisions.txt
+MAN7_TXT += gittutorial-2.txt
+MAN7_TXT += gittutorial.txt
+MAN7_TXT += gitworkflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
--
1.8.1.2.11.g1a2f572
^ permalink raw reply related
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Jeff King @ 2013-02-01 8:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201073352.GB970@sigill.intra.peff.net>
On Fri, Feb 01, 2013 at 02:33:52AM -0500, Jeff King wrote:
> I am starting to think it has grown in an unnecessarily complex
> direction, and we would be much happier just calling all of the
> "concept" documentation "git-".
>
> The steps I see are:
I am still undecided on whether it is a good idea (in some ways, I like
that "gitrevisions" signals to the user that it is not a command; but I
also recognize that it is more complex for users, and gitremote-helpers
looks silly to me). But here is what the patch looks like, for
reference. The first one is a cleanup we might want to take anyway, and
the second one is the meat.
[1/2]: Documentation/Makefile: clean up MAN*_TXT lists
[2/2]: docs: convert "concept" manpages to git-*
-Peff
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Jeff King @ 2013-02-01 7:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <7v7gmsd26o.fsf@alter.siamese.dyndns.org>
On Thu, Jan 31, 2013 at 09:37:51PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > What was the original rationale for the "gitfoo" form? Was it just to
> > visually distinguish command manpages from non-command manpages? I can't
> > remember the origins now.
>
> b27a23e (Documentation: convert tutorials to man pages, 2008-05-24)
> turns "tutorial.txt" into "gittutorial.txt". Before that, there
> were git{attributes,cli,ignore,hooks,modules}.txt. They were added
> in this order, which reveals the true reason:
>
> hooks.txt
> gitignore.txt
> gitmodules.txt
> gitcli.txt
> hooks.txt => githooks.txt
> gitatributes.txt
>
> Originally, we did not intend to name them as "git$concept.txt";
> instead, we just said "$concept.txt". Hooks are "hooks", and we
> know we are discussing hooks in the context of Git, there was no
> reason to say "githooks".
Yes, but if we are going to install a manpage, we must include "git"
somewhere in the name since that context is lost in the global manpage
database. So we need "githooks.txt" or "git-hooks.txt".
> "gitignore" was about the file format,
> and it would have been insane to call it "ignore.txt". The same
> applies to "gitmodules.txt".
Right. So we have some that must be "gitfoo", and others that do not
care. If we turned "githooks" into "git-hooks" and removed the "is it a
command?" magic from "git help", then "git help hooks" would still find
hooks. And likewise, "git help gitignore" would still find "gitignore".
But you could no longer say "git help ignore" to find "gitignore".
Which personally I am OK with. It is not a sensible thing to ask for;
the concept is not "ignore", but rather "the gitignore file".
> In other way, I think this wasn't designed, but organically grown.
Like many parts of git. :) I am starting to think it has grown in an
unnecessarily complex direction, and we would be much happier just
calling all of the "concept" documentation "git-".
The steps I see are:
1. Modify builtin/help.c, like:
diff --git a/builtin/help.c b/builtin/help.c
index 6067a61..1eca4ea 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -308,10 +308,8 @@ static const char *cmd_to_page(const char *git_cmd)
return "git";
else if (!prefixcmp(git_cmd, "git"))
return git_cmd;
- else if (is_git_command(git_cmd))
- return prepend("git-", git_cmd);
else
- return prepend("git", git_cmd);
+ return prepend("git-", git_cmd);
}
static void setup_man_path(void)
2. Rename the "concept" files like:
Documentation/{gitcli.txt => git-cli.txt} | 0
Documentation/{gitcore-tutorial.txt => git-core-tutorial.txt} | 0
Documentation/{gitcredentials.txt => git-credentials.txt} | 0
Documentation/{gitcvs-migration.txt => git-cvs-migration.txt} | 0
Documentation/{gitdiffcore.txt => git-diffcore.txt} | 0
Documentation/{gitglossary.txt => git-glossary.txt} | 0
Documentation/{githooks.txt => git-hooks.txt} | 0
Documentation/{gitnamespaces.txt => git-namespaces.txt} | 0
Documentation/{gitrepository-layout.txt => git-repository-layout.txt} | 0
Documentation/{gitrevisions.txt => git-revisions.txt} | 0
Documentation/{gittutorial-2.txt => git-tutorial-2.txt} | 0
Documentation/{gittutorial.txt => git-tutorial.txt} | 0
Documentation/{gitworkflows.txt => git-workflows.txt} | 0
3. Teach Documentation/Makefile about the new filenames. MAN1_TXT
includes git-*.txt, which is no longer right. I think we'd need to
just filter out what is in MAN5_TXT and MAN7_TXT.
4. Replace the rename "gitfoo" above with a "see git-foo..." pointer.
Users of "git help foo" would not ever see this, but people who
have trained their fingers to type "man gitfoo" would, along with
anybody following an outdated HTML link.
5. Update internal references to "linkgit:gitfoo" to point to
"git-foo".
Hmm. That really does not seem so bad. The biggest downside is the
people who have to see the redirect made in step 4.
But I have not thought about it too hard, so maybe there is something
else I'm not seeing.
-Peff
^ permalink raw reply related
* Re: Segmentation fault with latest git (070c57df)
From: Jeff King @ 2013-02-01 7:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jongman.heo, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <20130201063638.GD29973@sigill.intra.peff.net>
On Fri, Feb 01, 2013 at 01:36:38AM -0500, Jeff King wrote:
> On Thu, Jan 31, 2013 at 05:40:02PM -0800, Junio C Hamano wrote:
>
> > 허종만 <jongman.heo@samsung.com> writes:
> >
> > > But usually when I build upstream Linux kernel, I don't do "make
> > > clean" after git pull.. I didn't expect that I needed "make
> > > clean" for git build.
> >
> > We don't expect anybody need "make clean", either. There is
> > something wrong in the dependency.
>
> Agreed, but I cannot see what. If auto-header-dependencies is on, gcc
> should find it (it is not even a recursive dependency for
> builtin/fetch.c). And if it is not on, we should rebuild based on LIB_H,
> which includes string-list.h (and always has, as far as I can tell).
By the way, while researching this issue, I noticed this:
-- >8 --
Subject: [PATCH] Makefile: add version.h to LIB_H
This was forgotten when the file was added by 816fb46, and
not noticed because most developers are on modern systems
that support COMPUTE_HEADER_DEPENDENCIES. However, people
still relying on LIB_H for dependencies might have failed to
recompile when this file changed.
Found with "make CHECK_HEADER_DEPENDENCIES=yes".
Signed-off-by: Jeff King <peff@peff.net>
---
I don't see how this could have caused the issue at hand, but it is good
to fix nonetheless. I almost wonder if LIB_H should just be set to
$(wildcard *.h) or similar, since that is what ends up going into it.
And then we would not have to deal with manually keeping it up to date.
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 731b6a8..6b42f66 100644
--- a/Makefile
+++ b/Makefile
@@ -704,6 +704,7 @@ LIB_H += varint.h
LIB_H += userdiff.h
LIB_H += utf8.h
LIB_H += varint.h
+LIB_H += version.h
LIB_H += walker.h
LIB_H += wildmatch.h
LIB_H += wt-status.h
--
1.8.1.2.11.g1a2f572
^ permalink raw reply related
* Re: Segmentation fault with latest git (070c57df)
From: Jeff King @ 2013-02-01 7:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jongman.heo, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <20130201063638.GD29973@sigill.intra.peff.net>
On Fri, Feb 01, 2013 at 01:36:38AM -0500, Jeff King wrote:
> It seems like building each object file should depend on its dependency
> file (but only when COMPUTE_HEADER_DEPENDENCIES is on, of course), since
> otherwise we cannot know if we have the right dependencies or not.
>
> Something like this almost works, I think:
> [...]
> +$(C_OBJ): %.o: %.c GIT-CFLAGS $(missing_dep_dirs) $(call dep_file, %.o)
Actually that would not work, as we do not have a rule to create
.depend/foo.o.d. We can add one, but it gets pretty hairy (and
replicates much of the normal build rule). A much simpler way is to just
find the missing dep files and force compilation of their matching
objects. Like:
diff --git a/Makefile b/Makefile
index 6b42f66..f94e8b9 100644
--- a/Makefile
+++ b/Makefile
@@ -1843,8 +1843,14 @@ dep_args = -MF $(dep_file) -MMD -MP
@mkdir -p $@
missing_dep_dirs := $(filter-out $(wildcard $(dep_dirs)),$(dep_dirs))
+missing_dep_files := $(filter-out $(wildcard $(dep_files)),$(dep_files))
+# we want to rewrite "foo/.depend/bar.o.d" into "foo/bar.o", but
+# make's patsubst is not powerful enough to remove something from the middle of
+# a string. Hack around it by shelling out.
+obj_files_with_missing_deps := $(shell echo $(missing_dep_files:.d=) | tr ' ' '\n' | sed 's,.depend/,,')
dep_file = $(dir $@).depend/$(notdir $@).d
dep_args = -MF $(dep_file) -MMD -MP
+$(obj_files_with_missing_deps): FORCE
ifdef CHECK_HEADER_DEPENDENCIES
$(error cannot compute header dependencies outside a normal build. \
Please unset CHECK_HEADER_DEPENDENCIES and try again)
which does solve the problem, but that shell hack is nasty. It would be
much simpler if we stored the dependency for foo/bar.o as
".depend/foo/bar.o.d", rather than "foo/.depend/bar.o.d", as then we
would patsubst it away. Or maybe there is some clever way to convince
make to do what I want here. Suggestions welcome.
-Peff
^ permalink raw reply related
* Re: Segmentation fault with latest git (070c57df)
From: Jeff King @ 2013-02-01 6:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jongman.heo, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <7vmwvodd71.fsf@alter.siamese.dyndns.org>
On Thu, Jan 31, 2013 at 05:40:02PM -0800, Junio C Hamano wrote:
> 허종만 <jongman.heo@samsung.com> writes:
>
> > But usually when I build upstream Linux kernel, I don't do "make
> > clean" after git pull.. I didn't expect that I needed "make
> > clean" for git build.
>
> We don't expect anybody need "make clean", either. There is
> something wrong in the dependency.
Agreed, but I cannot see what. If auto-header-dependencies is on, gcc
should find it (it is not even a recursive dependency for
builtin/fetch.c). And if it is not on, we should rebuild based on LIB_H,
which includes string-list.h (and always has, as far as I can tell).
Hmm. I do notice one oddity with the computed header dependencies,
though. We build the computed dependency files as a side effect of doing
the actual compilation. So before we have run the compilation once, we
need some way to say "you _must_ build this, because we do even know the
correct dependencies". And to do that, we have each object file depend
on any missing .depend dirs, which bootstraps the whole process: we
build everything the first time because .depend is missing, and from
then on, we use the correct dependencies.
But that is not quite right. The .depend directory might exist, but be
missing the actual dependency file for a particular object. So if I do:
$ make ;# builds all objects and dependency files
$ rm builtin/.depend/fetch.o.d
$ touch string-list.h
$ make
we will fail to rebuild builtin/fetch.o properly. It does not see the
dependency on string-list (because we have no .d file), nor does it
realize that it needs to build the .d file (because it only checks that
builtin/.depend exists).
It seems like building each object file should depend on its dependency
file (but only when COMPUTE_HEADER_DEPENDENCIES is on, of course), since
otherwise we cannot know if we have the right dependencies or not.
Something like this almost works, I think:
diff --git a/Makefile b/Makefile
index 6b42f66..a329736 100644
--- a/Makefile
+++ b/Makefile
@@ -1843,8 +1843,8 @@ missing_dep_dirs := $(filter-out $(wildcard $(dep_dirs)),$(dep_dirs))
@mkdir -p $@
missing_dep_dirs := $(filter-out $(wildcard $(dep_dirs)),$(dep_dirs))
-dep_file = $(dir $@).depend/$(notdir $@).d
-dep_args = -MF $(dep_file) -MMD -MP
+dep_file = $(dir $1).depend/$(notdir $1).d
+dep_args = -MF $(call dep_file, $@) -MMD -MP
ifdef CHECK_HEADER_DEPENDENCIES
$(error cannot compute header dependencies outside a normal build. \
Please unset CHECK_HEADER_DEPENDENCIES and try again)
@@ -1909,9 +1909,9 @@ $(C_OBJ): %.o: %.c GIT-CFLAGS $(missing_dep_dirs)
endif
ifndef CHECK_HEADER_DEPENDENCIES
-$(C_OBJ): %.o: %.c GIT-CFLAGS $(missing_dep_dirs)
+$(C_OBJ): %.o: %.c GIT-CFLAGS $(missing_dep_dirs) $(call dep_file, %.o)
$(QUIET_CC)$(CC) -o $*.o -c $(dep_args) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<
-$(ASM_OBJ): %.o: %.S GIT-CFLAGS $(missing_dep_dirs)
+$(ASM_OBJ): %.o: %.S GIT-CFLAGS $(missing_dep_dirs) $(call dep_file,%.o)
$(QUIET_CC)$(CC) -o $*.o -c $(dep_args) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<
endif
But not quite. The problem is that we put the dep file for foo/bar.o
into foo/.depend/bar.o. But when we call the dep_file function for the
dependency, it sees only "%.o", not "foo/bar.o", so it can't properly
split it apart. I don't think there is a way to force expansion before
calling the function.
And of course I have no idea if this was the problem that we saw,
anyway. I have no idea how one would get into this situation short of
manually removing the dependency file.
-Peff
^ permalink raw reply related
* Re: [PATCH 1/3] git-am: record full index line in the patch used while rebasing
From: Martin von Zweigbergk @ 2013-02-01 6:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Heiko Voigt
In-Reply-To: <1359693125-22357-2-git-send-email-gitster@pobox.com>
On Thu, Jan 31, 2013 at 8:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Earlier, a230949 (am --rebasing: get patch body from commit, not
> from mailbox, 2012-06-26) learned to regenerate patch body from the
> commit object while rebasing, instead of reading from the rebase-am
> front-end. While doing so, it used "git diff-tree" but without
> giving it the "--full-index" option.
>
> This does not matter for in-repository objects; during rebasing, any
> abbreviated object name should uniquely identify them.
>
> But we may be rebasing a commit that contains a change to a gitlink,
> in which case we usually should not have the object (it names a
> commit in the submodule). A full object name is necessary to later
> reconstruct a fake ancestor index for them.
>From what I can understand, this all makes sense. I didn't notice the
emails about the breakage until now, but I wouldn't have known where
to even start looking anyway, so thanks a lot for taking care of it.
^ permalink raw reply
* Re: [PATCH] fix some clang warnings
From: Miles Bader @ 2013-02-01 5:37 UTC (permalink / raw)
To: Jeff King
Cc: Max Horn, John Keeping, Antoine Pelisse, Junio C Hamano, git,
Johannes Sixt
In-Reply-To: <20130116175057.GB27525@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It seems a little weird to me that clang defines __GNUC__, but I
> assume there are good reasons for it.
The thing is that "gcc" is as much a language dialect these days as it
is a compiler implementation, and many other compilers, including
clang, explicitly try to implement that dialect (clang goes even
further by trying to be compatible in other ways, e.g. command-line
syntax, but that's not relevant here).
__GNUC__ is a way many programs try to detect the presence of a
compiler that implements that dialect, they have little choice but to
define it...
-Miles
--
Love, n. A temporary insanity curable by marriage or by removal of the patient
from the influences under which he incurred the disorder. This disease is
prevalent only among civilized races living under artificial conditions;
barbarous nations breathing pure air and eating simple food enjoy immunity
from its ravages. It is sometimes fatal, but more frequently to the physician
than to the patient.
^ permalink raw reply
* Re: [PATCH 1/2] docs: clarify git-branch --list behavior
From: Junio C Hamano @ 2013-02-01 5:42 UTC (permalink / raw)
To: Jeff King; +Cc: Eric Sunshine, Peter Wu, git
In-Reply-To: <20130201050637.GC29973@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Thanks. No matter how many times I proofread a doc change, I always
> manage to slip an error into the final version.
I think everybody shares that trait.
> Hooray for many eyes.
Indeed.
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Junio C Hamano @ 2013-02-01 5:37 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201050343.GA29973@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> What was the original rationale for the "gitfoo" form? Was it just to
> visually distinguish command manpages from non-command manpages? I can't
> remember the origins now.
b27a23e (Documentation: convert tutorials to man pages, 2008-05-24)
turns "tutorial.txt" into "gittutorial.txt". Before that, there
were git{attributes,cli,ignore,hooks,modules}.txt. They were added
in this order, which reveals the true reason:
hooks.txt
gitignore.txt
gitmodules.txt
gitcli.txt
hooks.txt => githooks.txt
gitatributes.txt
Originally, we did not intend to name them as "git$concept.txt";
instead, we just said "$concept.txt". Hooks are "hooks", and we
know we are discussing hooks in the context of Git, there was no
reason to say "githooks". "gitignore" was about the file format,
and it would have been insane to call it "ignore.txt". The same
applies to "gitmodules.txt".
Things start to go in a strange direction when "cli" was added. We
know that is about the command line interface in the context of Git,
and it should have been "cli.txt". To make things worse, later
"hooks.txt" took an example of "gitcli.txt" in the wrong way at
a5af0e2 (Documentation: rename "hooks.txt" to "githooks.txt" and
make it a man page, 2008-05-02).
In other way, I think this wasn't designed, but organically grown.
^ permalink raw reply
* Re: [PATCH 1/2] docs: clarify git-branch --list behavior
From: Jeff King @ 2013-02-01 5:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Sunshine, Peter Wu, git
In-Reply-To: <7v4nhweuoi.fsf@alter.siamese.dyndns.org>
On Thu, Jan 31, 2013 at 04:37:01PM -0800, Junio C Hamano wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
>
> > On Thu, Jan 31, 2013 at 1:45 AM, Jeff King <peff@peff.net> wrote:
> >> +If `--list` is given, or if there are no non-option arguments, existing
> >> +branches are listed; the current branch will be highlighted with an
> >> +asterisk. Option `-r` causes the remote-tracking branches to be listed,
> >> +and option `-a` shows both local and remote branches. If a `<pattern>`
> >> +is given, it is used as a shell wildcard to restrict the output to
> >> +matching branches. If multiple patterns are given, a branch is shown if
> >> +any it is matched by any of the patterns.
> >
> > s/if any it is/if it is/
>
> Thanks; I'll squash this in. Peff, no need to resend.
Thanks. No matter how many times I proofread a doc change, I always
manage to slip an error into the final version. Hooray for many eyes.
-Peff
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Jeff King @ 2013-02-01 5:03 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: John Keeping, git, Junio C Hamano, Matthieu Moy, Max Horn
In-Reply-To: <20130131230455.GN27340@google.com>
On Thu, Jan 31, 2013 at 03:04:55PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > Maybe it is just me, but the fact that accessing the manpage is now:
> >
> > man gitremote-helpers
> >
> > feels weird to me. I know it technically follows our syntactic rules,
> > but having the lack of dash be significant between "git" and "remote",
> > but then having a dash later makes it hard on the eyes.
>
> Yes. I have thought for years that it should be git-remote-helpers,
> that "git help" should be tweaked to look for that, and that the
> existing gitrepository-layout and friends should be replaced with
> redirects.
What was the original rationale for the "gitfoo" form? Was it just to
visually distinguish command manpages from non-command manpages? I can't
remember the origins now. It does seem like it is causing more
hassle than it is worth, but maybe there is something I am forgetting.
-Peff
^ permalink raw reply
* [PATCH 3/3] apply: diagnose incomplete submodule object name better
From: Junio C Hamano @ 2013-02-01 4:32 UTC (permalink / raw)
To: git; +Cc: Heiko Voigt, Martin von Zweigbergk
In-Reply-To: <1359693125-22357-1-git-send-email-gitster@pobox.com>
"git am -3" uses this function to build a tree that records how the
preimage the patch was created from would have looked like. An
abbreviated object name on the index line is ordinarily sufficient
for us to figure out the object name the preimage tree would have
contained, but a change to a submodule by definition shows an object
name of a submodule commit which our repository should not have, and
get_sha1_blob() is not an appropriate way to read it (or get_sha1()
for that matter).
Use get_sha1_hex() and complain if we do not find a full object name
there.
We could read from the payload part of the patch to learn the full
object name of the commit, but the primary user "git rebase" has
been fixed to give us a full object name, so this should suffice
for now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/apply.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index a1db7b4..1f78e2c 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3606,7 +3606,11 @@ static void build_fake_ancestor(struct patch *list, const char *filename)
if (0 < patch->is_new)
continue;
- if (!get_sha1_blob(patch->old_sha1_prefix, sha1)) {
+ if (S_ISGITLINK(patch->old_mode)) {
+ if (get_sha1_hex(patch->old_sha1_prefix, sha1))
+ die("submoule change for %s without full index name",
+ name);
+ } else if (!get_sha1_blob(patch->old_sha1_prefix, sha1)) {
; /* ok */
} else if (!patch->lines_added && !patch->lines_deleted) {
/* mode-only change: update the current */
--
1.8.1.2.612.g09f4be5
^ permalink raw reply related
* [PATCH 2/3] apply: simplify build_fake_ancestor()
From: Junio C Hamano @ 2013-02-01 4:32 UTC (permalink / raw)
To: git; +Cc: Heiko Voigt, Martin von Zweigbergk
In-Reply-To: <1359693125-22357-1-git-send-email-gitster@pobox.com>
The local variable sha1_ptr in the build_fake_ancestor() function
used to either point at the null_sha1[] (if the ancestor did not
have the path) or at sha1[] (if we read the object name into the
local array), but 7a98869 (apply: get rid of --index-info in favor
of --build-fake-ancestor, 2007-09-17) made the "missing in the
ancestor" case unnecessary, hence sha1_ptr, when used, always points
at the local array.
Get rid of the unneeded variable, and restructure the if/else
cascade a bit to make it easier to read. There should be no
behaviour change.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/apply.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 156b3ce..a1db7b4 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3598,7 +3598,6 @@ static void build_fake_ancestor(struct patch *list, const char *filename)
* worth showing the new sha1 prefix, but until then...
*/
for (patch = list; patch; patch = patch->next) {
- const unsigned char *sha1_ptr;
unsigned char sha1[20];
struct cache_entry *ce;
const char *name;
@@ -3606,20 +3605,19 @@ static void build_fake_ancestor(struct patch *list, const char *filename)
name = patch->old_name ? patch->old_name : patch->new_name;
if (0 < patch->is_new)
continue;
- else if (get_sha1_blob(patch->old_sha1_prefix, sha1))
- /* git diff has no index line for mode/type changes */
- if (!patch->lines_added && !patch->lines_deleted) {
- if (get_current_sha1(patch->old_name, sha1))
- die("mode change for %s, which is not "
- "in current HEAD", name);
- sha1_ptr = sha1;
- } else
- die("sha1 information is lacking or useless "
- "(%s).", name);
- else
- sha1_ptr = sha1;
- ce = make_cache_entry(patch->old_mode, sha1_ptr, name, 0, 0);
+ if (!get_sha1_blob(patch->old_sha1_prefix, sha1)) {
+ ; /* ok */
+ } else if (!patch->lines_added && !patch->lines_deleted) {
+ /* mode-only change: update the current */
+ if (get_current_sha1(patch->old_name, sha1))
+ die("mode change for %s, which is not "
+ "in current HEAD", name);
+ } else
+ die("sha1 information is lacking or useless "
+ "(%s).", name);
+
+ ce = make_cache_entry(patch->old_mode, sha1, name, 0, 0);
if (!ce)
die(_("make_cache_entry failed for path '%s'"), name);
if (add_index_entry(&result, ce, ADD_CACHE_OK_TO_ADD))
--
1.8.1.2.612.g09f4be5
^ permalink raw reply related
* [PATCH 1/3] git-am: record full index line in the patch used while rebasing
From: Junio C Hamano @ 2013-02-01 4:32 UTC (permalink / raw)
To: git; +Cc: Heiko Voigt, Martin von Zweigbergk
In-Reply-To: <1359693125-22357-1-git-send-email-gitster@pobox.com>
Earlier, a230949 (am --rebasing: get patch body from commit, not
from mailbox, 2012-06-26) learned to regenerate patch body from the
commit object while rebasing, instead of reading from the rebase-am
front-end. While doing so, it used "git diff-tree" but without
giving it the "--full-index" option.
This does not matter for in-repository objects; during rebasing, any
abbreviated object name should uniquely identify them.
But we may be rebasing a commit that contains a change to a gitlink,
in which case we usually should not have the object (it names a
commit in the submodule). A full object name is necessary to later
reconstruct a fake ancestor index for them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-am.sh | 2 +-
t/t7402-submodule-rebase.sh | 30 ++++++++++++++++++++++++++++--
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index c682d34..0e0a096 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -664,7 +664,7 @@ do
sed -e '1,/^$/d' >"$dotest/msg-clean"
echo "$commit" >"$dotest/original-commit"
get_author_ident_from_commit "$commit" >"$dotest/author-script"
- git diff-tree --root --binary "$commit" >"$dotest/patch"
+ git diff-tree --root --binary --full-index "$commit" >"$dotest/patch"
else
git mailinfo $keep $no_inbody_headers $scissors $utf8 "$dotest/msg" "$dotest/patch" \
<"$dotest/$msgnum" >"$dotest/info" ||
diff --git a/t/t7402-submodule-rebase.sh b/t/t7402-submodule-rebase.sh
index f919c8d..8e32f19 100755
--- a/t/t7402-submodule-rebase.sh
+++ b/t/t7402-submodule-rebase.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2008 Johannes Schindelin
#
-test_description='Test rebasing and stashing with dirty submodules'
+test_description='Test rebasing, stashing, etc. with submodules'
. ./test-lib.sh
@@ -20,7 +20,8 @@ test_expect_success setup '
echo second line >> file &&
(cd submodule && git pull) &&
test_tick &&
- git commit -m file-and-submodule -a
+ git commit -m file-and-submodule -a &&
+ git branch added-submodule
'
@@ -89,4 +90,29 @@ test_expect_success 'stash with a dirty submodule' '
'
+test_expect_success 'rebasing submodule that should conflict' '
+ git reset --hard &&
+ git checkout added-submodule &&
+ git add submodule &&
+ test_tick &&
+ git commit -m third &&
+ (
+ cd submodule &&
+ git commit --allow-empty -m extra
+ ) &&
+ git add submodule &&
+ test_tick &&
+ git commit -m fourth &&
+
+ test_must_fail git rebase --onto HEAD^^ HEAD^ HEAD^0 &&
+ git ls-files -s submodule >actual &&
+ (
+ cd submodule &&
+ echo "160000 $(git rev-parse HEAD^) 1 submodule" &&
+ echo "160000 $(git rev-parse HEAD^^) 2 submodule" &&
+ echo "160000 $(git rev-parse HEAD) 3 submodule"
+ ) >expect &&
+ test_cmp expect actual
+'
+
test_done
--
1.8.1.2.612.g09f4be5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox