chore(3p/git): Unvendor git and track patches instead r/2903

This was vendored a long time ago under the expectation that keeping
it in sync with cgit would be easier this way, but it has proven not
to be a big issue.

On the other hand, a vendored copy of git is an annoying maintenance
burden. It is much easier to rebase the single (dottime) patch that we
have.

This removes the vendored copy of git and instead passes the git
source code to cgit via `pkgs.srcOnly`, which includes the applied
patch so that cgit can continue rendering dottime.

Change-Id: If31f62dea7ce688fd1b9050204e9378019775f2b

1 files changed, 0 insertions, 164 deletions

diff --git a/third_party/git/Documentation/howto/rebase-from-internal-branch.txt b/third_party/git/Documentation/howto/rebase-from-internal-branch.txt
deleted file mode 100644
index f2e10a7ec8..0000000000
--- a/third_party/git/Documentation/howto/rebase-from-internal-branch.txt
+++ /dev/null
@@ -1,164 +0,0 @@
-From:	Junio C Hamano <gitster@pobox.com>
-To:	git@vger.kernel.org
-Cc:	Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
-Subject: Re: sending changesets from the middle of a git tree
-Date:	Sun, 14 Aug 2005 18:37:39 -0700
-Abstract: In this article, JC talks about how he rebases the
- public "seen" branch using the core Git tools when he updates
- the "master" branch, and how "rebase" works.  Also discussed
- is how this applies to individual developers who sends patches
- upstream.
-Content-type: text/asciidoc
-
-How to rebase from an internal branch
-=====================================
-
---------------------------------------
-Petr Baudis <pasky@suse.cz> writes:
-
-> Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter
-> where Junio C Hamano <junkio@cox.net> told me that...
->> Linus Torvalds <torvalds@osdl.org> writes:
->>
->> > Junio, maybe you want to talk about how you move patches from your
->> > "seen" branch to the real branches.
->>
-> Actually, wouldn't this be also precisely for what StGIT is intended to?
---------------------------------------
-
-Exactly my feeling.  I was sort of waiting for Catalin to speak
-up.  With its basing philosophical ancestry on quilt, this is
-the kind of task StGIT is designed to do.
-
-I just have done a simpler one, this time using only the core
-Git tools.
-
-I had a handful of commits that were ahead of master in 'seen', and I
-wanted to add some documentation bypassing my usual habit of
-placing new things in 'seen' first.  At the beginning, the commit
-ancestry graph looked like this:
-
-			     *"seen" head
-    master --> #1 --> #2 --> #3
-
-So I started from master, made a bunch of edits, and committed:
-
-    $ git checkout master
-    $ cd Documentation; ed git.txt ...
-    $ cd ..; git add Documentation/*.txt
-    $ git commit -s
-
-After the commit, the ancestry graph would look like this:
-
-			      *"seen" head
-    master^ --> #1 --> #2 --> #3
-          \
-            \---> master
-
-The old master is now master^ (the first parent of the master).
-The new master commit holds my documentation updates.
-
-Now I have to deal with "seen" branch.
-
-This is the kind of situation I used to have all the time when
-Linus was the maintainer and I was a contributor, when you look
-at "master" branch being the "maintainer" branch, and "seen"
-branch being the "contributor" branch.  Your work started at the
-tip of the "maintainer" branch some time ago, you made a lot of
-progress in the meantime, and now the maintainer branch has some
-other commits you do not have yet.  And "git rebase" was written
-with the explicit purpose of helping to maintain branches like
-"seen".  You _could_ merge master to 'seen' and keep going, but if you
-eventually want to cherrypick and merge some but not necessarily
-all changes back to the master branch, it often makes later
-operations for _you_ easier if you rebase (i.e. carry forward
-your changes) "seen" rather than merge.  So I ran "git rebase":
-
-    $ git checkout seen
-    $ git rebase master seen
-
-What this does is to pick all the commits since the current
-branch (note that I now am on "seen" branch) forked from the
-master branch, and forward port these changes.
-
-    master^ --> #1 --> #2 --> #3
-	  \                                  *"seen" head
-            \---> master --> #1' --> #2' --> #3'
-
-The diff between master^ and #1 is applied to master and
-committed to create #1' commit with the commit information (log,
-author and date) taken from commit #1.  On top of that #2' and #3'
-commits are made similarly out of #2 and #3 commits.
-
-Old #3 is not recorded in any of the .git/refs/heads/ file
-anymore, so after doing this you will have dangling commit if
-you ran fsck-cache, which is normal.  After testing "seen", you
-can run "git prune" to get rid of those original three commits.
-
-While I am talking about "git rebase", I should talk about how
-to do cherrypicking using only the core Git tools.
-
-Let's go back to the earlier picture, with different labels.
-
-You, as an individual developer, cloned upstream repository and
-made a couple of commits on top of it.
-
-                              *your "master" head
-   upstream --> #1 --> #2 --> #3
-
-You would want changes #2 and #3 incorporated in the upstream,
-while you feel that #1 may need further improvements.  So you
-prepare #2 and #3 for e-mail submission.
-
-    $ git format-patch master^^ master
-
-This creates two files, 0001-XXXX.patch and 0002-XXXX.patch.  Send
-them out "To: " your project maintainer and "Cc: " your mailing
-list.  You could use contributed script git-send-email if
-your host has necessary perl modules for this, but your usual
-MUA would do as long as it does not corrupt whitespaces in the
-patch.
-
-Then you would wait, and you find out that the upstream picked
-up your changes, along with other changes.
-
-   where                      *your "master" head
-  upstream --> #1 --> #2 --> #3
-    used   \
-   to be     \--> #A --> #2' --> #3' --> #B --> #C
-                                                *upstream head
-
-The two commits #2' and #3' in the above picture record the same
-changes your e-mail submission for #2 and #3 contained, but
-probably with the new sign-off line added by the upstream
-maintainer and definitely with different committer and ancestry
-information, they are different objects from #2 and #3 commits.
-
-You fetch from upstream, but not merge.
-
-    $ git fetch upstream
-
-This leaves the updated upstream head in .git/FETCH_HEAD but
-does not touch your .git/HEAD or .git/refs/heads/master.
-You run "git rebase" now.
-
-    $ git rebase FETCH_HEAD master
-
-Earlier, I said that rebase applies all the commits from your
-branch on top of the upstream head.  Well, I lied.  "git rebase"
-is a bit smarter than that and notices that #2 and #3 need not
-be applied, so it only applies #1.  The commit ancestry graph
-becomes something like this:
-
-   where                     *your old "master" head
-  upstream --> #1 --> #2 --> #3
-    used   \                      your new "master" head*
-   to be     \--> #A --> #2' --> #3' --> #B --> #C --> #1'
-                                                *upstream
-                                                head
-
-Again, "git prune" would discard the disused commits #1-#3 and
-you continue on starting from the new "master" head, which is
-the #1' commit.
-
--jc