This message was deleted.
# how-do-i
s
This message was deleted.
✅ 1
a
gt merge
is to merge the PRs (same as pressing merge button on UI).
gt restack
rebases your stack correctly.
b
Ohhh lol
That makes much more sense.
Similar question, is there anything written around the pitfalls of using git merge with Graphite? I've had a few PRs from colleagues that were done the merge route, and I'm wondering if I can pull those into the Graphite world and collaborate with them... and if so, what to be careful of.
a
@Jacob Gold can probably answer this canonically, but I have noticed a few people hit footguns when using Graphite +
git merge
, so I'll caution for now until someone has a more well thought out answer.
b
totally! I want to know what the footguns are 😛
j
I would recommend not using
merge
at all by default, but I would ask what sorts of merges you are curious about. There are probably a lot of cases where it would be fine, as
rebase
is pretty smart about handling merges, but the rare case where it would break something would likely be quite annoying to deal with...
b
@Jacob Gold The situation is that I'm running prettier across the entire codebase, and it's touching every file, which means everybody will have conflicts on every branch. For users who don't use Graphite, I'm having them:
Copy code
`git checkout <branchname>` checkout your branch
`git merge <hash>` pull the branch forward (resolve conflicts if needed)
`yarn ts-node -T ./server/src/scripts/one-offs/prettierTo80CharPrintWidth.ts`
`git commit -am "run prettier script"`
`git merge main` (resolve conflicts if needed)
For users who use Graphite, the steps are:
Copy code
`gt checkout <branchname>` checkout your branch
`git cherry-pick <hash>` to get the codemod script
`gt squash` (it'll prompt you for a commit name, or you can pass `-m "new commit message goes here"`)
`yarn ts-node -T ./server/src/scripts/one-offs/prettierTo80CharPrintWidth.ts`
`gt modify -a` to add the prettier changes to your
`gt restack` (resolve conflicts if needed)
But I think this won't work for stacks, since it won't know which change was "first" when running the script on each branch and trying to restack. I'm trying to think of ways to handle this with stacks working too...
Codemods are pretty common, so there's gotta be a way with Graphite... I'm just not sure what it is.
j
I think that should be fine with stacks
not sure what you mean about "which change was first"?
b
if I'm cherry-picking the script and running it on each branch, independently............. it should be smart enough to know that identical changes don't have to be resolved. But what if I make changes to some lines, then I make changes to those same lines in the next PR... and then I run the codemod on each? Wouldn't it see those changes at not having a shared ancestor so it'd not know which to choose?
like, to contrive an example
Copy code
if (a === 'original value' && bar) {
change A
Copy code
if (a === 'new value' && bar && foo && c === anotherValue) {
change B
Copy code
if (b === someOtherValue && foo && bar) {
change C
Copy code
if (foo && bar) {
original prettified
Copy code
if (
  a === 'original value' && 
  bar
) {
change A prettified
Copy code
if (
  a === 'new value' &&
  bar &&
  foo &&
  c === anotherValue
) {
change B prettified
Copy code
if (
  b === someOtherValue &&
  foo &&
  bar
) {
change C prettified
Copy code
if (foo && bar) {
would that restack actually work? I could imagine it not knowing which lines to pick since it's not super clear what happened to each of the changes with the codemodding.
j
if you had conflicts while restacking, you would rerun the script while resolving restack conflicts, just like any other codemod
b
hmm... the codemod wouldn't actually know how to resolve the conflicts I think
maybe prettier on its own does, but I have a bit of custom logic in there too that would probably get confused by the
<<<<<<
=======
>>>>>>>
Maybe it'll work though... I'll test again and see if maybe my puter was having a bad day the other day 🙂
j
oh, i meant after selecting the right option
b
oh yeah, that's true
but in this case, there are no conflicts before doing the codemod and restacking dance
they aren't actual conflicts... they're conflicts because of git not knowing which to resolve during the rebase