22.01.2018, 14:47, "Martin Smith" <martin.sm...@qt.io>: >> You are doing it wrong. In rebase -i menu don't reorder anything, instead >> mark commits for edit > > But then you have to do the editing with the rebase paused and then continue > the rebase. I feel less anxiety reordering the picks and completing the > rebase before beginning the editing.
There is no reason to be anxious. * You can abort rebase at any time and restore previous state via git rebase --abort * You can restore any intermediate states via git reflog Not to mention that it's not always possible to reorder sequential commits without conflicts > > martin > > ________________________________________ > From: Konstantin Tokarev <annu...@yandex.ru> > Sent: Monday, January 22, 2018 12:36:38 PM > To: Martin Smith; Daniel Savi; Samuel Gaist > Cc: development@qt-project.org > Subject: Re: [Development] how to include further changes while previous > commit is still under review? > > 22.01.2018, 14:34, "Martin Smith" <martin.sm...@qt.io>: >> When updating the documentation, I often do 2 or more different commits and >> pushes to a single branch. Then I wait for them to get approved. Often, a >> reviewer will require changes to the first pushed commit after I have pushed >> the second commit. Then I do: >> >> git rebase -i HEAD~2 >> >> ...and I reorder the "pick" lines. This makes the first commit accessible >> with: >> >> git commit --amend >> >> ...so I make the changes, use git add to make them visible to git commit >> --amend > > You are doing it wrong. In rebase -i menu don't reorder anything, instead > mark commits for edit > >> martin >> >> ________________________________________ >> From: Development <development-bounces+martin.smith=qt...@qt-project.org> >> on behalf of Konstantin Tokarev <annu...@yandex.ru> >> Sent: Monday, January 22, 2018 11:31:35 AM >> To: Daniel Savi; Samuel Gaist >> Cc: development@qt-project.org >> Subject: Re: [Development] how to include further changes while previous >> commit is still under review? >> >> 22.01.2018, 09:34, "Daniel Savi" <daniel.s...@gaess.ch>: >>> After reading some of the excellent documentation on git-scm.com, I'm >>> planning to create two branches, one for patch 1 and one for patch 2. So, I >>> would do "git branch fix1", "git checkout fix1", add some changes from >>> review, "git commit --amend", then "git checkout master", "git branch >>> fix2", git checkout fix2", add fix 2 and commit the second patch. I'm >>> writing all commands by heart, may have some mistakes there. >>> Would that work out, or am I running into troubles somewhere? >> >> 1. "git branch fix1", "git checkout fix1" is usually done in one step: git >> checkout -b fix1 >> 2. Yes, this is going to work, and moreover, it's probably the best >> approach from theoretic point of view, also known as "feature branches". >> What I've suggested is a pragmatic shortcut, to avoid switching branches and >> therefore save a bit of time by avoid excessive file rewrites and following >> recompilation. >> >>> Am 20. Januar 2018 23:28:13 MEZ schrieb Konstantin Tokarev >>> <annu...@yandex.ru>: >>>> 21.01.2018, 01:25, "Daniel Savi" <daniel.s...@gaess.ch>: On 19.01.2018 >>>> 18:40, Konstantin Tokarev wrote: 19.01.2018, 01:58, "Samuel Gaist" >>>> <samuel.ga...@edeltech.ch>: On 18 Jan 2018, at 22:42, Daniel Savi >>>> <daniel.s...@gaess.ch> wrote: Hello qt devs I'm back with another newbie >>>> question. I have committed a patch that is still under review on gerrit. >>>> Meanwhile, I've got a local and unrelated patch on the same file, that I >>>> would like to commit, too. Now, how would I include this patch into my >>>> local git repo and how would I commit it as a separate patch to the first? >>>> How could I still work on the first patch, once more comments are coming >>>> in? Would I create separate branches? Sorry for my very basic level of >>>> git-foo. >>>>>>>> ---------------------------------------- >>>>>>>> >>>>>>>> Development mailing list >>>>>>>> Development@qt-project.org >>>>>>>> http://lists.qt-project.org/mailman/listinfo/development >>>>>>> Hi, >>>>>>> >>>>>>> Since the patch is unrelated, use a different topic branch for that >>>>>>> one and submit it like the other one. >>>>>>> >>>>>>> Depending on the impact of your change, you might want to look at >>>>>>> https://git-scm.com/docs/git-worktree and have a separate build for it. >>>>> >>>>> I will read that, thank you for the link. >>>>>> I think it's OK to create it in the same branch with previous one, >>>>>> especially in this case when patches touch same file >>>>>> and there is a non-zero probability of conflict because of order >>>>>> change. >>>>>> >>>>>> While patch #2 will have #1 shown in Gerrit as a "dependency", they >>>>>> still can be integrated separately from each other (if #2 does actually >>>>>> apply to the branch without #1). >>>>> >>>>> Just one question. Patch #1 is still under review and there will >>>>> probably be further changes in the future. If I have patch #2 on the >>>>> same branch and commit changes to patch #1 again later with "git commit >>>>> -a --amend", wouldn't patch #2 be included in patch #1, too? >>>> >>>> git commit --amend edits topmost patch, i.e. #2, instead of #1 >>>> >>>> So if you make changes for #1 you need to create new commit #3, and >>>> squash >>>> #3 and #1 with git rebase -i >>>> >>>>>>> Cheers >>>>>>> >>>>>>> Samuel >>>>>>> , >>>>>>> >>>>>>> ---------------------------------------- >>>>>>> >>>>>>> Development mailing list >>>>>>> Development@qt-project.org >>>>>>> http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Regards, >> Konstantin >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
