[Git-dpm-user] workflow for teams?

[Bernhard R. Link]

> I am curious about git-dpm, but much of the packaging I do for debian
> involves teams.  In this context, I'm not sure how well it will work to
> be constantly rebasing the patches branch.  Have you thought about this?
> Is this just outside the scope of git-dpm?  Maybe I overestimate the
> difficulties.

No, it is exactly the scope of git-dpm.

As the manpage says in the description of the patched branch:
        "As this branch is regulary rebased, you should not publish it."

The idea is that the patched branch is no branch visible as remote
branch for people, but only part of the history (with a tag for released
versions[1]).

This has the disadvantage that you either need git-dpm installed so you
can run "git-dpm checkout-patched" to have that branch created in your
local repository, or look with gitk or git-log where it is and create
it manualy with 'git checkout -b patched <commitid>'.

It also has the disadvantage that is you do multiple small changes to
the patches, you will likely have a larger number of "merged patched
into master" commits in your debian history (as they are created every
time git-dpm update-patches (or only git-dpm merge-patched-into-debian)
is called and only after that you can push the new master branch[2]).

But it has the advantage that there is only one branch to be shared
between team members, and that is usually[3] just an descendant of
previous states of that branch, so it can be happily pushed and pulled
as it will always be a fast-forward.

Hope that exaplains,
	Bernhard R. Link

[1] So upstream or other distributions/developers can easily find the
patches in gitweb or in the git repository.

[2] That's also why update-patches (or the merge-patched-into-debian
called by it) will remove your patched branch. This way it is only there
between checkout-patched and update-patches and can only get out of sync
if you do an pull in between).

[3] Nothing prevents you doing non-forward changes, or resets to previous
commits, but it is not needed for anything (unless you want to
hide "do" - "revert" histories or embarrassing commits).