managing git disk space usage
in [PgSql]
|
From: Abhijit Menon-Sen on 21 Jul 2010 07:53 At 2010-07-21 06:57:53 -0400, robertmhaas(a)gmail.com wrote: > > Post 'em here or drop them on the wiki and post a link. 1. Clone the remote repository as usual: git clone git://git.postgresql.org/git/postgresql.git 2. Create as many local clones as you want: git clone postgresql foobar 3. In each clone (supposing you care about branch xyzzy): 3.1. git remote origin set-url ssh://whatever/postgresql.git 3.2. git remote update && git remote prune 3.2. git checkout -t origin/xyzzy 3.4. git branch -d master 3.5. Edit .git/config and set origin.fetch thus: [remote "origin"] fetch = +refs/heads/xyzzy:refs/remotes/origin/xyzzy (You can git config remote.origin.fetch '+refs/...' if you're squeamish about editing the config file.) 3.6. That's it. git pull and git push will work correctly. (This will replace the "origin" remote that pointed at your local postgresql.git clone with one that points to the real remote; but you could also add a remote definition named something other than "origin", in which case you'd need to "git push thatname" etc.) -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 21 Jul 2010 15:00 Aidan Van Dyk <aidan(a)highrise.ca> writes: > * Robert Haas <robertmhaas(a)gmail.com> [100720 13:04]: > >> 3. Clone the origin once. Apply patches to multiple branches by >> switching branches. Playing around with it, this is probably a >> tolerable way to work when you're only going back one or two branches >> but it's certainly a big nuisance when you're going back 5-7 branches. > > This is what I do when I'm working on a project that has completely > proper dependancies, and you don't need to always re-run configure > between different branches. I use ccache heavily, so configure takes > longer than a complete build with a couple-dozen > actually-not-previously-seen changes... > > But *all* dependancies need to be proper in the build system, or you end > up needing a git-clean-type-cleanup between branch switches, forcing a > new configure run too, which takes too much time... > > Maybe this will cause make dependancies to be refined in PG ;-) Well, there's also the VPATH possibility, where all your build objects are stored out of the way of the repo. So you could checkout the branch you're interrested in, change to the associated build directory and build there. And automate that of course. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 21 Jul 2010 15:29 Excerpts from Dimitri Fontaine's message of mié jul 21 15:00:48 -0400 2010: > Well, there's also the VPATH possibility, where all your build objects > are stored out of the way of the repo. So you could checkout the branch > you're interrested in, change to the associated build directory and > build there. And automate that of course. This does not work as cleanly as you suppose, because some "build objects" are stored in the source tree. configure being one of them. So if you switch branches, configure is rerun even in a VPATH build, which is undesirable. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 21 Jul 2010 17:06 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > This does not work as cleanly as you suppose, because some "build > objects" are stored in the source tree. configure being one of them. > So if you switch branches, configure is rerun even in a VPATH build, > which is undesirable. Ouch. Reading -hackers led me to thinking this had received a cleaning effort in the Makefiles, so that any generated file appears in the build directory. Sorry to learn that's not (yet?) the case. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 22 Jul 2010 05:34 On ons, 2010-07-21 at 23:06 +0200, Dimitri Fontaine wrote: > Alvaro Herrera <alvherre(a)commandprompt.com> writes: > > This does not work as cleanly as you suppose, because some "build > > objects" are stored in the source tree. configure being one of them. > > So if you switch branches, configure is rerun even in a VPATH build, > > which is undesirable. > > Ouch. Reading -hackers led me to thinking this had received a cleaning > effort in the Makefiles, so that any generated file appears in the build > directory. Sorry to learn that's not (yet?) the case. It is, but not in the back branches. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Pages: 1 2 3 Prev: [HACKERS] managing git disk space usage Next: dynamically allocating chunks from shared memory |