On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava <sriva...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/75eaebf4-07c4-4734-b124-f1d0c6a1b...@email.android.com
