Login or Register to Ask a Question and Join Our Community

Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

stg-publish(1) [debian man page]

STG-PUBLISH(1)							   StGit Manual 						    STG-PUBLISH(1)

NAME

       stg-publish - Push the stack changes to a merge-friendly branch

SYNOPSIS

       stg publish [options] [branch]

DESCRIPTION

       This command commits a set of changes on a separate (called public) branch based on the modifications of the given or current stack. The
       history of the public branch is not re-written, making it merge-friendly and feasible for publishing. The heads of the stack and public
       branch may be different but the corresponding tree objects are always the same.

       If the trees of the stack and public branch are different (otherwise the command has no effect), StGit first checks for a rebase of the
       stack since the last publishing. If a rebase is detected, StGit creates a commit on the public branch corresponding to a merge between the
       new stack base and the latest public head.

       If no rebasing was detected, StGit checks for new patches that may have been created on top of the stack since the last publishing. If new
       patches are found and are not empty, they are checked into the public branch keeping the same commit information (e.g. log message, author,
       committer, date).

       If the above tests fail (e.g. patches modified or removed), StGit creates a new commit on the public branch having the same tree as the
       stack but the public head as its parent. The editor will be invoked if no "--message" option is given.

       It is recommended that stack modifications falling in different categories as described above are separated by a publish command in order
       to keep the public branch history cleaner (otherwise StGit would generate a big commit including several stack modifications).

       The public branch name can be set via the branch.<branch>.public configuration variable (defaulting to "<branch>.public").

OPTIONS

       -b BRANCH, --branch BRANCH
	   Use BRANCH instead of the default branch.

       --author "NAME <EMAIL>"
	   Set the author details.

       --authname NAME
	   Set the author name.

       --authemail EMAIL
	   Set the author email.

       --authdate DATE
	   Set the author date.

       -m MESSAGE, --message MESSAGE
	   Use MESSAGE instead of invoking the editor.

       -f FILE, --file FILE
	   Use the contents of FILE instead of invoking the editor. (If FILE is "-", write to stdout.)

       --sign
	   Add a "Signed-off-by:" to the end of the patch.

       --ack
	   Add an "Acked-by:" line to the end of the patch.

STGIT

       Part of the StGit suite - see linkman:stg[1]

StGit								    03/13/2012							    STG-PUBLISH(1)

Check Out this Related Man Page

STG-REPAIR(1)							   StGit Manual 						     STG-REPAIR(1)

NAME

       stg-repair - Fix StGit metadata if branch was modified with git commands

SYNOPSIS

       stg repair

DESCRIPTION

       If you modify an StGit stack (branch) with some git commands -- such as commit, pull, merge, and rebase -- you will leave the StGit
       metadata in an inconsistent state. In that situation, you have two options:

	1. Use "stg undo" to undo the effect of the git commands. (If you know what you are doing and want more control, "git reset" or similar
	   will work too.)

	2. Use "stg repair". This will fix up the StGit metadata to accomodate the modifications to the branch. Specifically, it will do the
	   following:

	   o   If you have made regular git commits on top of your stack of StGit patches, "stg repair" makes new StGit patches out of them,
	       preserving their contents.

	   o   However, merge commits cannot become patches; if you have committed a merge on top of your stack, "repair" will simply mark all
	       patches below the merge unapplied, since they are no longer reachable. If this is not what you want, use "stg undo" to get rid of
	       the merge and run "stg repair" again.

	   o   The applied patches are supposed to be precisely those that are reachable from the branch head. If you have used e.g. "git reset"
	       to move the head, some applied patches may no longer be reachable, and some unapplied patches may have become reachable. "stg
	       repair" will correct the appliedness of such patches.

		   "stg repair" will fix these inconsistencies reliably, so as long
		   as you like what it does, you have no reason to avoid causing
		   them in the first place. For example, you might find it
		   convenient to make commits with a graphical tool and then have
		   "stg repair" make proper patches of the commits.

	   Note
	   If using git commands on the stack was a mistake, running "stg repair" is not what you want. In that case, what you want is option (1)
	   above.

STGIT

       Part of the StGit suite - see linkman:stg[1]

StGit								    03/13/2012							     STG-REPAIR(1)
Man Page