On Fri, Apr 22, 2016 at 9:03 PM, Steve Schow <st...@bstage.com> wrote:
>
> Right well I’m just trying to figure out a way to automate thing so the
> dev never has to worry about copy and pasting any kind of ticket or checkin
> numbers from one place to another. I want it to just happen automatically
> through wrapper scripts and workflow control.
>
My team's wrapper for Fossil does the following (from memory, so might not
be exactly right):
On "branch new":
fossil commit --allow-empty --branch $bname -m "$comment (Issue
[$issue])"
fossil tag add --propagate issue $bname $issue
On "commit":
$issue=`fossil tag ls $revision|perl -n -e 'if /issue=(\w+)/ { print $1;
}`
fossil commit -m "$comment (Issue [$issue])" $args
Again, this is from memory. Please forgive any thing I might have forgotten
in the years since we made this.
> In Fossil we can’t squash, but we need to make it easy for the gatekeeper
> to see a squashed view of the requested changes for the ticket across
> multiple commits.
When you merge the final commit of a branch to trunk (or another branch),
the resulting commit will be as though you first squashed the branch, then
merged it to trunk (or other branch).
The note I forgot in my previous post is: While making a series of changes
on a branch, it is recommended to regularly merge changes FROM trunk to
your branch. This way, any changes introduced in trunk that might affect
your branch can be delt with before your branch is merged to trunk.
>
> >
> > The equivalent to squashing commits is to do the work on a branch,
> > then merge the branch when it is done. The merge take the place of
> > the squash, but preserves the history.
> >
>
> In the past on other systems I’ve used like clear case, we always did work
> on another branch and the merge did squash the commits arriving on the dest
> branch in the process. Im not sure if you’re saying a merge here would
> merge multiple commits from one branch into a single commit on the dest
> branch? You said it preserves the history, but that would infer that the
> merge would not squash the commits in the process.
>
> As I described above, the branch itself is left "as is".
In the simplest case, if you branch from commit "T1", committing "B1",
"B2", and "B3", then merge to trunk, creating "T2", then the diff from "T1"
to "T2" will look like all of the changes in "B1", "B2", and "B3" were made
to "T1", creating "T2".
In a more common case, you might have other changes going into trunk,
creating "T2" and "T3". So, when you merge in your branch, the new commit
will be "T4". Then the diff from "T3" to "T4" will look like all of the
changes in "B1", "B2", and "B3" were made to "T3", creating "T4".
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
