On Mar 2, 2021, at 10:09 PM, Jacob Faibussowitsch <[email protected]> wrote:
I do not get this. I thought that rebasing with main put all the main changes in before your commits. I have never seen any interspersed, so I do not understand this.
Mark, do you rebase your branch over main first or do you merge main intro your branch to update it? If you rebase, you can pick an N such that you only get your commits from the branch.
I just do git rebase main (from my branch) I don't need to provide an N, it automatically puts all the new changes in main BEFORE my commits in my branch. I would never merge my branch with main. I put the N in when I am rebasing my branch "against itself" and trying to organize the commits within my branch. By having the N be within the range of my commits it means I am just reorganizing my commits and not messing with any previous commits that came before my branch.
Best regards,
Jacob Faibussowitsch (Jacob Fai - booss - oh - vitch) Cell: (312) 694-3391
On Mar 2, 2021, at 22:02, Barry Smith <[email protected] <mailto:[email protected]>> wrote:
On Mar 2, 2021, at 9:24 PM, Mark Adams <[email protected] <mailto:[email protected]>> wrote:
Ah, 'git graph' I will try that next time.
I use 'git rebase -i HEAD~N', but you need an N.
After you 'git rebase origin/main' you get other commits interspersed in with yours,
I do not get this. I thought that rebasing with main put all the main changes in before your commits. I have never seen any interspersed, so I do not understand this.
Barry
so I try to rebase -i before rebasing over main. Then rebase over main and you have a clean and updated branch.
Pick N to be large enough to cover the commits that you want to clean up. Don't touch the ones that are not yours from main, the last time you rebased over main.
On Tue, Mar 2, 2021 at 10:02 PM Junchao Zhang <[email protected] <mailto:[email protected]>> wrote: I am a naive git user, so I use interactive git rebase. Suppose I am on the branch I want to modify,
1) Use git graph to locate an upstream commit to be used as the base $ git graph * 0d5433e9 (HEAD -> jczhang/sf-change-api) SF: rename SFCreateEmbeddedSF to SFCreateEmbeddedRootSF * e7314fbb SF: add an MPI_Op argument to SFBcast * 83df288d Replace MPIU_REPLACE with MPI_REPLACE * b434c516 Merge branch 'barry/2021-02-02/petscsf-communication-specific' into 'main' |\ | * 62152ded (barry/2021-02-02/petscsf-communication-specific) PetscSFView() never called viewer for the specific type (bug), hence many output files were incorrect. * | a4f5d9b4 Merge branch 'jose/upgrade-magma' into 'main'
2) Suppose we choose b434c516 as the base. All commits we want to squash are after it. Do interactive git rebase. It shows a screen for you to edit. Read the help, which is helpful for new users $ git rebase -i b434c516 pick 83df288d Replace MPIU_REPLACE with MPI_REPLACE pick e7314fbb SF: add an MPI_Op argument to SFBcast pick 0d5433e9 SF: rename SFCreateEmbeddedSF to SFCreateEmbeddedRootSF
# Rebase b434c516..0d5433e9 onto b434c516 (3 commands) # # Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # b, break = stop here (continue rebase later with 'git rebase --continue') # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # . create a merge commit using the original merge commit's # . message (or the oneline, if no original merge commit was # . specified). Use -c <commit> to reword the commit message. # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out
3) Suppose we want to squash the last two commits to 83df288d, replace their pick with s (or f, see the help for difference), save and exit the screen pick 83df288d Replace MPIU_REPLACE with MPI_REPLACE s e7314fbb SF: add an MPI_Op argument to SFBcast s 0d5433e9 SF: rename SFCreateEmbeddedSF to SFCreateEmbeddedRootSF
A new screen shows up
# This is a combination of 3 commits. # This is the 1st commit message:
Replace MPIU_REPLACE with MPI_REPLACE
Since we believe all MPI implementations support MPI_REPLACE
# This is the commit message #2:
SF: add an MPI_Op argument to SFBcast
# This is the commit message #3:
SF: rename SFCreateEmbeddedSF to SFCreateEmbeddedRootSF
# Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit.
4) Edit the commit message as you want, save and exit, done!
--Junchao Zhang
On Tue, Mar 2, 2021 at 6:19 PM Blaise A Bourdin <[email protected] <mailto:[email protected]>> wrote: Hi,
This is not technically a petsc question. It would be great to have a short section in the PETSc integration workflow document explaining how to squash commits in a MR for git-impaired developers like me.
Anybody wants to pitch in, or explain me how to do this?
Regards, Blaise
-- A.K. & Shirley Barton Professor of Mathematics Adjunct Professor of Mechanical Engineering Adjunct of the Center for Computation & Technology Louisiana State University, Lockett Hall Room 344, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 Web http://www.math.lsu.edu/~bourdin <http://www.math.lsu.edu/~bourdin>