[Development] how to include further changes while previous commit is still under review?

[Konstantin Tokarev]

22.01.2018, 14:47, "Martin Smith" <martin.smith at 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 <annulen at yandex.ru>
> Sent: Monday, January 22, 2018 12:36:38 PM
> To: Martin Smith; Daniel Savi; Samuel Gaist
> Cc: development at 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.smith at 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.io at qt-project.org> on behalf of Konstantin Tokarev <annulen at yandex.ru>
>>  Sent: Monday, January 22, 2018 11:31:35 AM
>>  To: Daniel Savi; Samuel Gaist
>>  Cc: development at 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.savi at 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 <annulen at yandex.ru>:
>>>>   21.01.2018, 01:25, "Daniel Savi" <daniel.savi at gaess.ch>: On 19.01.2018 18:40, Konstantin Tokarev wrote: 19.01.2018, 01:58, "Samuel Gaist" <samuel.gaist at edeltech.ch>: On 18 Jan 2018, at 22:42, Daniel Savi <daniel.savi at 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 at 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 at qt-project.org
>>>>>>>    http://lists.qt-project.org/mailman/listinfo/development
>>
>>  --
>>  Regards,
>>  Konstantin
>>  _______________________________________________
>>  Development mailing list
>>  Development at qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/development
>
> --
> Regards,
> Konstantin


-- 
Regards,
Konstantin