From: Junio C Hamano <junkio@cox.net>
To: "David S. Miller" <davem@davemloft.net>
Cc: git@vger.kernel.org
Subject: Re: kernel.org and GIT tree rebuilding
Date: Fri, 24 Jun 2005 22:04:11 -0700 [thread overview]
Message-ID: <7vslz758ok.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20050624.212009.92584730.davem@davemloft.net> (David S. Miller's message of "Fri, 24 Jun 2005 21:20:09 -0700 (PDT)")
>>>>> "DSM" == David S Miller <davem@davemloft.net> writes:
DSM> To get a clean history to push to Linus, I typically blow
DSM> away my trees and make fresh ones to stick patches into
DSM> which I want to merge.
DSM> Should I:
DSM> 1) Do a git pull from Linus's tree once he takes my changes, then
DSM> ask GIT to prune the tree? How do I do that and how does it work?
DSM> 2) Should I use .git/object/ database symlinking?
DSM> Are there any scripts out there which do this automatically?
DSM> Something as simple to run as "git-pull-script" and it takes
DSM> care of using links when possible on a local filesystem.
git-pull-script internally uses git-fetch-script which knows how
to do the local tree using hardlinks. Presumably, the following
workflow would work:
(1) You hack away in your private tree, while you keep a "to be
published" clean tree, both on your local machine.
(2) Do a GIT pull, merge in your private tree, to come up with
a clean set of changes in your private tree. This is the
tree you "typically blow away". Reordering the commits to
come up with a clean history since you last pulled from
Linus would also happen in this tree.
(3) Once you have a commit that you want to publish (i.e. the
commit chain between that commit and the point you last
pulled from Linus is the "clean history to push to Linus"),
you go to your "to be published" clean tree, and run
git-fetch-script to fetch the commit you want to publish
from your private tree. When you give an absolute path as
the "remote repo", git-local-pull with linking behaviour is
used by git-fetch-script; otherwise rsync backend is used
so you end up polluted object database. This way you copy
only the clean stuff from your private tree. Your HEAD in
this tree should be set to the commit you wanted to
publish. Running git-prune would be nicer but if your
history is truly clean it should not be necessary.
(4) Garbage collecting with git-prune your private tree is your
business.
next prev parent reply other threads:[~2005-06-25 5:00 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-25 4:20 kernel.org and GIT tree rebuilding David S. Miller
2005-06-25 4:40 ` Jeff Garzik
2005-06-25 5:23 ` Linus Torvalds
2005-06-25 5:48 ` Jeff Garzik
2005-06-25 6:16 ` Linus Torvalds
2005-06-26 16:41 ` Linus Torvalds
2005-06-26 18:39 ` Junio C Hamano
2005-06-26 19:19 ` Linus Torvalds
2005-06-26 19:45 ` Junio C Hamano
[not found] ` <7v1x6om6o5.fsf@assigned-by-dhcp.cox.net>
[not found] ` <Pine.LNX.4.58.0506271227160.19755@ppc970.osdl.org>
[not found] ` <7v64vzyqyw.fsf_-_@assigned-by-dhcp.cox.net>
2005-06-28 6:56 ` [PATCH] Obtain sha1_file_info() for deltified pack entry properly Junio C Hamano
2005-06-28 6:58 ` Junio C Hamano
2005-06-28 6:58 ` [PATCH 2/3] git-cat-file: use sha1_object_info() on '-t' Junio C Hamano
2005-06-28 6:59 ` [PATCH 3/3] git-cat-file: '-s' to find out object size Junio C Hamano
2005-06-26 20:52 ` kernel.org and GIT tree rebuilding Chris Mason
2005-06-26 21:03 ` Chris Mason
2005-06-26 21:40 ` Linus Torvalds
2005-06-26 22:34 ` Linus Torvalds
2005-06-28 18:06 ` Nicolas Pitre
2005-06-28 19:28 ` Linus Torvalds
2005-06-28 21:08 ` Nicolas Pitre
2005-06-28 21:27 ` Linus Torvalds
2005-06-28 21:55 ` [PATCH] Bugfix: initialize pack_base to NULL Junio C Hamano
2005-06-29 3:55 ` kernel.org and GIT tree rebuilding Nicolas Pitre
2005-06-29 5:16 ` Nicolas Pitre
2005-06-29 5:43 ` Linus Torvalds
2005-06-29 5:54 ` Linus Torvalds
2005-06-29 7:16 ` Last mile for 1.0 again Junio C Hamano
2005-06-29 9:51 ` [PATCH] Add git-verify-pack command Junio C Hamano
2005-06-29 16:15 ` Linus Torvalds
2005-07-04 21:40 ` Last mile for 1.0 again Daniel Barkalow
2005-07-04 21:45 ` Junio C Hamano
2005-07-04 21:59 ` Linus Torvalds
2005-07-04 22:41 ` Daniel Barkalow
2005-07-04 23:06 ` Junio C Hamano
2005-07-05 1:54 ` Daniel Barkalow
2005-07-05 6:24 ` Junio C Hamano
2005-07-05 13:34 ` Marco Costalba
2005-06-25 5:04 ` Junio C Hamano [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-07-03 2:51 kernel.org and GIT tree rebuilding linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vslz758ok.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=davem@davemloft.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).