Skip site navigation (1) Skip section navigation (2)

Re: Managing multiple branches in git

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Mark Mielke <mark(at)mark(dot)mielke(dot)cc>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Managing multiple branches in git
Date: 2009-06-02 23:44:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 06/03/2009 12:56 AM, Tom Lane wrote:
> "David E. Wheeler"<david(at)kineticode(dot)com>  writes:
>> I should think that it'd be pretty damned easy to generate such a
>> report from a Git repository's log. `git log` is extremely powerful,
>> and provides a lot of interfaces for hooking things in and sorting.
>> It's eminently do-able.
> Well, it's not like CVS makes it easy ... cvs2cl is about 50K of perl,
> and is not very speedy or without bugs :-(.  So maybe we are setting
> the goalposts in the wrong place by supposing that the lowest-level git
> history needs to be exactly what's wanted for human consumption.
> As long as it can be postprocessed into the form I do want to look at,
> and someone will volunteer to write that postprocessor, the question
> doesn't seem like a showstopper.
If the merging would be done from "latest backbranch -> ... -> HEAD" 
(editing the commits included) that should be relatively easy. (My 
guess: Minor scripting < 100 lines)...

> Meanwhile, there seem to have been ten different solutions proposed to
> the problem of working with multiple branches/checkouts, and I plead
> confusion.  Anyone want to try to sort out the pluses and minuses?
I can try:

+ easy
+ small
+ safe
-+ repositories not completely independent (common commits, i.e. no 
- not included in default install (/contrib directory in the git install)
- no windows support


git clone --local
+ safe
+ at least initially small
+- push/fetch needed
- repositories potentially get bigger with time (each repository gets 
hardlinked object from other repositories. When packing history they get 
duplicated in all repositories)
- no windows support


git clone --reference common_repo
+ small
+ staying small
+ fast
+ windows supported
+- push/fetch needed
- possibly unsecure if you delete from the master repository - which one 
can easily prevent


git clone --shared
Essentially the same as the last above

In all of those solutions you dont need the .git directory to be in the 
local checkout. All are initially 77MB big which is the pure file size 
minus around 400kb of metadata in the .git directory.

Is this at least some guidance?


In response to


pgsql-hackers by date

Next:From: David E. WheelerDate: 2009-06-02 23:44:49
Subject: Re: Managing multiple branches in git
Previous:From: Tom LaneDate: 2009-06-02 23:39:42
Subject: Re: Managing multiple branches in git

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group