Re: [RFC] git commit --branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Martin Waitz <tali@xxxxxxxxxxxxxx> wrote:
> Allow to commit to another branch and creating a merge in the current branch.

Interesting.  I have been kicking around doing the very same
thing myself but just have not gotten around to it.  Its complex,
especially if the current HEAD isn't strictly the merge commit
between the topic branch and the previous value of HEAD; in that
case you may want to replay the commits which are on HEAD but are
post the merge commit using a form of git-rebase.  Except you would
want to preserve any merges which happened by remerging them rather
than simply exporting a massive patch and reapplying it.
 
> +		test $(git merge-base "$onto_branch" HEAD^) != $onto_branch_commit &&
> +		test $(git merge-base "$onto_branch"^ HEAD^) = $(git rev-parse --verify "$onto_branch"^) ||
> +			die "commits on $onto_branch and HEAD differ, cannot amend."
> +		onto_branch_commit=$(git rev-parse --verify "$onto_branch"^)

Shouldn't these be 'git-merge-base' and 'git-rev-parse' ?

> +		git update-ref "$onto_branch" $commit2 &&

If this is going into next perhaps you would like to considering adding
the -m flag to your git-update-ref calls and include a log message
in the reflog (if the user has it enabled for the current branch and
the topic branch)?

Also shouldn't this be 'git-update-ref'?

-- 
Shawn.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]