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: 4A25B953.7040309@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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:

----
git-new-workdir
+ easy
+ small
+ safe
-+ repositories not completely independent (common commits, i.e. no
pushing/pulling/etc)
- 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?

Andres

In response to

Responses

Browse pgsql-hackers by date

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