summaryrefslogtreecommitdiff
path: root/dgit.1
diff options
context:
space:
mode:
authorIan Jackson <ijackson@chiark.greenend.org.uk>2016-10-30 23:36:24 +0000
committerIan Jackson <ijackson@chiark.greenend.org.uk>2016-10-30 23:36:39 +0000
commitbc1d578bd668ed7010be3ada52482a7c3e2bd7b6 (patch)
treebd80a0d6d945dd023cc94e3f6c1f3f00aec48828 /dgit.1
parent86ac87e912207b272c8159d03359459fc55eefba (diff)
dgit(1): Remove obsolete workflow information.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Diffstat (limited to 'dgit.1')
-rw-r--r--dgit.165
1 files changed, 0 insertions, 65 deletions
diff --git a/dgit.1 b/dgit.1
index 148bb7f..cc4a104 100644
--- a/dgit.1
+++ b/dgit.1
@@ -754,71 +754,6 @@ Force on or off the use of the absurd git-apply emulation
when running gbp pq import
when importing a package from a .dsc.
See Debian bug #841867.
-.SH WORKFLOW - SIMPLE
-It is always possible with dgit to clone or fetch a package, make
-changes in git (using git-commit) on the suite branch
-.RB ( "git checkout dgit/" \fIsuite\fR)
-and then dgit push. You can use whatever gitish techniques you like
-to construct the commits to push;
-the only requirement is that what you push is a
-descendant of the state of the archive, as provided by dgit in the
-remote tracking branch
-.BR remotes/dgit/dgit/ \fIsuite\fR.
-
-If you are using dgit to do an NMU (in Debian),
-and don't know about the
-maintainers' preferred packaging workflows, you should make your
-changes as a linear series of (logicially separated) commits on top of
-what's already in the archive.
-
-If you are lucky the other uploaders have also used dgit and
-integrated the other relevant git history; if not you can fetch it
-into your tree and cherry-pick etc. as you wish.
-.SH WORKFLOW - INTEGRATING BETWEEN DGIT AND OTHER GIT HISTORY
-If you are the maintainer of a package dealing with uploads made
-without dgit, you will probably want to merge the synthetic commits
-(made by dgit to represent the uploads) into your git history.
-Normally you can just merge the dgit branch into your own master, or
-indeed if you do your work on the dgit local suite branch
-.BI dgit/ suite
-you can just use dgit pull.
-
-However the first time dgit is used it will generate a new origin
-commit from the archive which won't be linked into the rest of your
-git history. You will need to merge this.
-
-If last upload was in fact made with git, you should usually proceed
-as follows: identify the commit which was actually used to build the
-package. (Hopefully you have a tag for this.) Check out the dgit
-branch
-.RB ( "git checkout dgit/" \fIsuite\fR)
-and merge that other commit
-.RB ( "git merge debian/" \fIversion\fR).
-Hopefully this merge will be trivial because the two trees should
-be very similar. The resulting branch head can be merged into your
-working branches
-.RB ( "git checkout master && git merge dgit/" \fIsuite\fR).
-
-If last upload was not made with git, a different approach is required
-to start using dgit. First, do
-.B dgit fetch
-(or clone) to obtain a git history representation of what's in the
-archive and record it in the
-.BI remotes/dgit/dgit/ suite
-tracking branch. Then somehow, using your other git history
-plus appropriate diffs and cherry picks from the dgit remote tracking
-branch, construct a git commit whose tree corresponds to the tree to use for the
-next upload.
-
-between what's in the archive and what you intend to upload.
-Then run
-.BR "dgit push"
-to actually upload the result.
-
-If the commit-to-be-uploaded is not a descendant of the
-dgit remote tracking branch, you will need to pass
-.B --overwrite
-to dgit.
.SH CONFIGURATION
dgit can be configured via the git config system.
You may set keys with git-config (either in system-global or per-tree