Re: Standardizing the layout of git packaging repositories
On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava <srivasta@debian.org> wrote:
>On Sun, Sep 07 2014, Brian May wrote:
>
>
>> In another email by Manoj Srivastava:
>>
>>> That is really a matter of displaying history. The diagram
>> displays Git history, not the patches; when B21 is committed, > there
>is no
>> patch representing B12, however, that commit is still in
><top>/.git/objects
>> since it is a parent of the Node D3. This > is relevant when I am
>trying to
>> trying to bisect and understand history. git-debcherry has fewer
>commits
>> being carried around, > which makes it easier on my aging brain.
>
>> Sorry, I think you have this wrong. (also nitpick: B12 is a parent of
>D5,
>> not D3).
>
> I aplogize, I I have not conveyed what is happening correctly,
> and you are confused by my diagrams. I shall try to do better.
>
>> When you commit B21, you have to replace B12 in the git history (e.g.
>git
>> commit --amend). Otherwise, when the patches are exported, you will
>get
>> both B12 and B21 appearing as separate patches debian/patches in D6.
>dpm
>> has no way of knowing that B12 and B21 are part of the same patch and
>> should be merged.
>
> That is the outcome I want.
>
> I commit B1, and later, B2. git-dpm creates ephemeral branches,
>
>| I commit | Ephemeral gbranch contains | Master contains |
>|----------+----------------------------+-----------------|
>| A1 | A10 | D2 |
>| B1 | A10, B11 | D3 |
>| U2 | A11. B12 | D5 |
>
> At this point B11 ans A10 are gone, apart from living in .git/objects.
>
>| I commit | Ephemeral gbranch contains | Master contains |
>|----------+----------------------------+-----------------|
>| B2 | A11, B12, B21 | D6 |
>
> There are there nodes in the ephemeral branch, and three patches
> are produced -- Corresponding to A1, B1, and B2.
>
>| I commit | Ephemeral gbranch contains | Master contains |
>|----------+----------------------------+-----------------|
>| A2 | A11, A21, B13, B22 | D7 |
>
>
> Four commits on the feature branches, and the ephemeral branch
> contains 4 commits -- the older ephemeral branches continue to live in
> .git/objects, which bothers the purist in me,
>
>> Maybe your point that debcherry is better still stands - it appears
>to work
>> better with your concept of "feature branches", however I find it
>hard to
>> use your document to compare the two when it contains errors like
>this.
>
>
> I think the errors lie in documentation of what the diagram is
> and thus the incorrect interpretation, rather than the underlying
> analysis. I'll try do document better what the diagrams mean. Has this
> helped you understand what the document is trying to say?
I'll confess up front that I'm a neophyte when it comes to git. From what I can tell though we've been using git-dpm for feature branches in pkg-clamav and it seems to me to work fine.
I'd be curious what you'd find if you had a look at the team repository for clamav to see if what we're doing matches your concept of feature branches?
Scott K
Reply to: