Jump to content


Merging can make history hard to understand on the destination stream


  • Please log in to reply
2 replies to this topic

#1 HateDread

HateDread

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 30 March 2020 - 12:50 AM

We've started using streams a whole bunch now, with a main stream, as well as release streams from main, and some dev streams off main as well.

One issue we're having is that when you merge down / copy up changes from those other streams into main, it's really hard to tell what's happening for the larger changes. It's like squashing a range of useful and readable git commits down into a single commit.

It seems antithetical to how p4 works, but is there a way to better manage this? Can we somehow express a range of commits when merging/copying? I would prefer main not just be "Merging x to main" with a huge dump of every change in a single CL. It doesn't communicate that much when browsing main's history and trying to understand the journey and changes.

Advice appreciated.

Brody

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1193 posts

Posted 30 March 2020 - 03:31 PM

You can specify a range of changelists when you merge.  For example, suppose in your dev stream you've done three features one after the other without merging down; feature A was done as of change 123, feature B was done as of change 154, and feature C was done as of change 168.  You could do:

p4 switch main
p4 merge --from my-dev @123
p4 resolve -am
p4 submit -d "Merge down feature A"
p4 merge --from my-dev @154
p4 resolve -am
p4 submit -d "Merge down feature B"
p4 merge --from my-dev @168
p4 resolve -am
p4 submit -d "Merge down feature C"


Now you have three changelists on main, one for each feature.  The "@123" can also be a range of changes, e.g. "@110,@123".  If the changes for feature A aren't sequential, you can also do things like:

p4 merge --from my-dev @110,112
p4 resolve -am
p4 merge --from my-dev @120,123
p4 resolve -am
p4 submit -d "Merge down feature A (changes 110-112 and 120-123 from my-dev)"

You can merge/resolve any number of times to get your pending change into the exact state you want it so that it encompasses whatever specific set of changes you want from the source stream; when you submit, it all becomes one change on the target stream.

When you copy, you can specify an ending revision (as in the first example), but not a range (because a copy by its nature is an exact copy as of a single point in time; you can't "cherry pick" and still have it be a copy).

#3 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1193 posts

Posted 30 March 2020 - 04:54 PM

Another thing to keep in mind: when you're inspecting history across multiple branches, take advantage of commands like:
  • p4 annotate -I (explodes integration diffs into their individual source diffs)
  • p4 changes -i (explodes integration changelists into their individual source changelists)
  • p4 filelog -h (switches file paths whenever there's a "copy")





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users