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
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 |