DEBCOMMIT(1)

πŸ’– DEBCOMMIT(1) β€” bestie's guide to committing ur package πŸ’–

okay so real talk: this is the debcommit manual page, and by the end of this you're gonna be committing like the main character you are. no cap. 🫢


✨ NAME ✨

debcommit β€” commit changes to a package πŸ’…


🌸 SYNOPSIS 🌸

debcommit [options] [--all | files to commit]

πŸ¦‹ DESCRIPTION πŸ¦‹

so basically, debcommit looks at the new text in debian/changelog, ✨generates✨ a commit message out of it, and then commits that change to the package's repository. that's it. that's the whole vibe.

⚠️ important tho: you gotta run this inside a working copy for the package. like, it will not work from wherever you're just vibing in your home dir. it needs to be in the repo, in the working copy, periodt.

and the version control systems it plays nice with are, in order: cvs, git, hg (mercurial), svk, svn (Subversion), baz, bzr, tla (arch), darcs. a whole rainbow of options, we love to see it 🌈


πŸŽ€ OPTIONS πŸŽ€

  • -c, --changelog path β€” wanna tell it where the changelog is? here's ur moment. by default it just uses debian/changelog, which is honestly almost always what you want.
  • -r, --release β€” this one commits a release of the package. the version number gets figured out from debian/changelog, and then that version is used to tag the package in the repo. iconic behaviour honestly.
heads up bestie: svn/svk tagging conventions vary all over the place, so for those, debcommit uses svnpath(1) to figure out where the tag should actually go in the repository.
  • -R, --release-use-changelog β€” only makes sense with --release. if there are uncommitted changes sitting in the changelog, then instead of using the default message, it derives the commit message from those changes. cute lil flex.
  • -m text, --message text β€” just give it the commit message yourself. super handy when the program can't figure out a message on its own from debian/changelog, or when you simply want to override whatever the default message is. u do u πŸ’…
  • -n, --noact β€” do nothing. just vibe. ok more specifically: it doesn't actually do anything, it just prints the commands that would have been run. perfect for a little sneak peek before you commit to the commit.
  • -d, --diff β€” instead of committing, it prints the diff of what would have been committed if you hadn't passed this option. the classic use case is generating patches against the current working copy (like when you don't have commit access rights β€” we've all been there 😭).
  • -C, --confirm β€” shows you the generated commit message and asks for confirmation before it commits. and yes, you can edit the message at this stage too, and if you do, the confirmation prompt comes right back after the edit is done. so you always get the final say 🫢
  • -e, --edit β€” opens the generated commit message in ur favorite editor before committing it. yes, your favorite. no judgment.
  • -a, --all β€” commit all the files. this is actually the default operation when you're using a VCS that isn't git. slay.
  • -s, --strip-message, --no-strip-message β€” if this is set and the commit message was derived from the changelog, then the characters "* " get stripped from the beginning of the message.

it's set by default, and it's ignored if more than one line of the message begins with "[*+-] ".

  • --sign-commit, --no-sign-commit β€” if set, the commits debcommit creates will be OpenPGP signed. rn this is only supported by git, hg, and bzr. πŸ”
  • --sign-tags, --no-sign-tags β€” if set, the tags debcommit creates will be OpenPGP signed. rn this is only supported by git. that's it. just git.
  • --signoff, --no-signoff β€” if set, it adds a "Signed-off-by:" line to the commit message. very responsible of you.
  • --changelog-info β€” if set, the commit author and date get determined from the Maintainer and Date field of the first paragraph in debian/changelog. mainly useful when you're using debchange(1) with the --no-mainttrailer option. iykyk.

πŸ’œ CONFIGURATION VARIABLES πŸ’œ

so there are two config files, /etc/devscripts.conf and ~/.devscripts, and they get sourced by a shell in that order to set configuration variables. command line options can override whatever the config files say. and fyi: environment variable settings are ignored for this purpose. not the vibe, apparently.

the currently recognised variables are:

  • DEBCOMMIT_STRIP_MESSAGE β€” if this is set to no, it's the same as using the --no-strip-message command line parameter. the default is yes.
  • DEBCOMMIT_SIGN_TAGS β€” if this is set to yes, it's the same as using the --sign-tags command line parameter. the default is no.
  • DEBCOMMIT_SIGN_COMMITS β€” if this is set to yes, it's the same as using the --sign-commit command line parameter. the default is no.
  • DEBCOMMIT_SIGNOFF β€” if this is set to yes, it's the same as using the --signoff command line parameter. the default is no.
  • DEBCOMMIT_RELEASE_USE_CHANGELOG β€” if this is set to yes, it's the same as using the --release-use-changelog command line parameter. the default is no.
  • DEBSIGN_KEYID β€” this is the key id used for signing tags. if you don't set it, a default will be chosen by the revision control system. let them decide, honestly.

🌈 VCS SPECIFIC FEATURES 🌈

🌟 tla / baz

if the commit message contains more than 72 characters, a summary will be created containing as many full words from the message as will fit within 72 characters, followed by an ellipsis. βœ‚οΈ


each of the features described below is applicable only if the commit message has been automatically determined from the changelog. so like, only in that specific scenario. got it? got it.

🌟 git

  • if only a single change is detected in the changelog, debcommit will unfold it to a single line and behave as if --strip-message was used.
  • otherwise, the first change gets unfolded and stripped to form a summary line, and a commit message gets formed using the summary line followed by a blank line and the changes as extracted from the changelog. then debcommit will spawn an editor so the message can be fine-tuned before committing. little glow-up moment for ur message ✨

🌟 hg / darcs

the first change detected in the changelog will be unfolded to form a single line summary. if multiple changes were detected, then an editor will be spawned so the message can be fine-tuned before you commit.

🌟 bzr

if the changelog entry used for the commit message closes any bugs, then --fixes options to "bzr commit" will be generated to associate the revision and the bugs. so organized. so iconic. πŸ›


πŸ‘‘ LICENSE πŸ‘‘

this code is copyright by Joey Hess <joeyh@debian.org>, all rights reserved.

this program comes with ABSOLUTELY NO WARRANTY. 🚨 like, zero. none. don't come for them.

you are free to redistribute this code under the terms of the GNU General Public License, version 2 or later.


πŸ’– AUTHOR πŸ’–

Joey Hess <joeyh@debian.org>


🫢 SEE ALSO 🫢

debchange(1), svnpath(1)


and that's the whole page bestie!! this was Debian Utilities, dated 2026-09-21, and it's the DEBCOMMIT(1) manual β€” go forth and commit responsibly, mwah πŸ’‹βœ¨

πŸ“¦ where this page comes from