Sorry for the delay. Life... ;-) On 10 May 2016 at 20:16, Mattia Rizzolo <mat...@debian.org> wrote: > On Tue, May 10, 2016 at 06:03:18PM -0400, Nicholas D Steeves wrote: >> > Now, umh, with `push debian/%(bpo_tag)s would be what I usually do >> > without a branch. >> >> Ohhh, I think I'm starting to understand now. So what happens that >> the local master branch gets ahead of the remote without --detach, but >> that's ok. It's ok because git pushes a snapshot of the local changed >> state to a remote state is only referenced by the tag. If for some >> reason there was a bug in the debian/%(bpo_tag)s version, that's not >> in the debian/version-revision...well, that's where it feels strange >> to me. So then one would make further changes to the local repo, >> local master would get further out of sync from remote master, but >> that wouldn't matter because the local state of master is only ever >> reflected as a tag on the remote? > > Well, you are not supposed to have your local master out of sync with > the remote one. doing `git checkout debian/version-revision` detaches > your head from a branch, and the stuff you do that are only referenced > by the tag, yep. But if you do a `git checkout master` you ought to go > back to the very place the remote master is, and doing stuff that means > pushing to the remote master, and stuff pushed there is going to be on > the next unstable upload.
Ahh, so that's how you do it! Git checkout tag detaches from a branch and updates to that state; subsequent git checkouts will not checkout anything, unless the tag is forcefully updated (bad!). Git checkout branch attaches to that branch and updates; subsequent git checkouts bring the local repo up-to-date with that branch. >> > given that now a branch is used instead the workflow is: >> >> This makes sense to me, but I'm still unclear why "git checkout >> jessie-backports && git merge debian/version-revision" is preferred >> over "git rebase debian/version-revision", when version-bumping the >> bpo. I guess the question is: For a version bump of a bpo, should the >> changelog of a new-version bpo mention the previous bpo, or should it >> only contain a single "Rebuild for $stable-backports" entry? > > The "jessie-backports branch workflow" I keep as a reference is the one > used by devscripts, that actually keeps the old backports entry in the > changelog during the merge. Is the "jessie-backports branch workflow" what you provided in a previous email? Used by which devscript? Dch? If the workflow is different than what was shared, could you please tell me where I can read it? I'm guessing that this will be what happens over time, to debian/changelog: Tagged bpo changelogs will only have one "Rebuild for jessie-backports" entry. All these entries will somehow be prepended to the changelog in the jessie-backports branch? Or will the debian/changelog on the jessie-backports branch be identical to the latest tagged bpo? >> The >> semantics of checkout+merge seem to favour a bpo changelog that >> mentions prior versions (independent parallel branch with coherent >> history and imported updates), while the semantics of git rebase seem >> to favour a series of bpo forks (branch is a history of forks). > > my idea of bpo is a series of separated forks, and here detached tags > work better than a branch. But I think this is really a matter of how > you see it and how you work better, the actual thing doesn't really > change much. I've been (locally) experimenting with both approaches. I still think I'm doing something wrong with detached tags! For example, suppose I fix spelling errors in some package of v4.5.3, and want to backport those changes to v4.5.2: git checkout v4.5.3 (make changes. eg: update changelog with an obvious marker) git add -u git commit git checkout v4.5.2 (warning) git stash git checkout v4.5.2 git stash pop (resolve conflicts) git tag -a v4.5.2.1 -m "Backport trivial spelling fixes from v4.5.3" git add -u git commit -- At this point, what I found was that if I do a checkout master, and then do a checkout v4.5.2.1, then my changes are lost. The only way I can get back to them is by doing a checkout cce2f0d. Git tag -l --contains commit cce2f0d prints nothing. git tag -f v4.5.2.1 cce2f0d prints Updated tag 'v4.5.2.1' (was 09846dc) Now I can get back to the intended detached state using the tag. My concern is that with the following instructions: On 10 May 2016 at 11:17, Mattia Rizzolo <mat...@debian.org> wrote: > dch --bpo # update changelog > gbp buildpackage --git-tag # build+tag > git status > git add # same as above > git push # push the current branch > git push --tags # push the tag The tag happens before git add, thus necessarily before the commit. >From my experiments, it seems like when I git push --tags, the tag I push will point to the wrong commit. Am I doing something wrong? It doesn't seem like manually forcing a retag->correct_commit before pushing is part of a normal workflow. Or is it? >> Mattia, thank you for taking the time to help me understand, >> I appreciate it a lot, >> Nicholas > > Sorry for making this actually simple backport look like a huge > complicated deal :) :-) Arguably, the most important thing learned by joining a team is how to work "as a team"! A simple case like a backport is perfect for this. If there's a checklist of things in which one needs to demonstrate proficiency before someone will grant DD privileges, I'm sure this is on it! And competency with the team's DVC/DRC is integral to this. Kind regards, Nicholas _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers