10:00 <PlasmaHH> PaulFertser: I am unsure on how to proceed with my rebased branch... if I were to just push it to review.openocd.org would it not create a new review item?

11:35 <NishanthMenon> PlasmaHH: the changeID ensures that the review is in sync

11:35 <NishanthMenon> PlasmaHH: as long as you have'nt changed the ChangeID, the updates are reflected as a new revision

11:38 <PlasmaHH> NishanthMenon: you mean its mention in the rebased commit(s)? when I add a commit should I put the change id there too?

11:40 <NishanthMenon> PlasmaHH: there is a procedure to work with openocd review - I believe it is here https://openocd.org/doc-release/doxygen/patchguide.html (if the site works)

11:42 <NishanthMenon> https://github.com/openocd-org/openocd/blob/master/HACKING#L172 if it does'nt work..

11:43 <PlasmaHH> NishanthMenon: yeah but it doesnt really talk about the situation I am in

11:45 <NishanthMenon> PlasmaHH: if you have followed the steps, git rebase to master and incorporate all the review comments, you just git push it again to review.openocd.org - not sure what is the challenge there

11:46 <PlasmaHH> NishanthMenon: the "challenge" is that I want to make sure that it gets to the existing change and not a new one will be created

11:48 <PlasmaHH> (plus I do not want to accidentally destroy someones work if that is possible, like for my own git usage when I rebase and (force) push normally the history gets overwritten)

11:48 <NishanthMenon> yes -walk this one by one: https://github.com/openocd-org/openocd/commit/4d4c45cfd25703f39f9e2413b22d91a48c4b4565 for example Change-Id: I5d006aaf990d4ef3a82e622b1e41cd2bfec359f7 in the commit message is used by gerrit to track when new pushes come in and associate it with the already existing review.

11:48 <NishanthMenon> gerrit is smart: https://gerrit-review.googlesource.com/Documentation/user-changeid.html

11:49 <PlasmaHH> yeah I never worked with gerrit...

11:49 <PlasmaHH> well before something with openocd that is ;)

11:49 <NishanthMenon> yep - understood. it looks a bit too hard.. but it is'nt once you get used to it.. it is a completely different flow compared to, say using b4 in linux kernel or patman in u-boot flow

11:50 <NishanthMenon> PlasmaHH: the key is to get the githooks sorted out and make sure new revision uses matching change-Id: tag

11:51 <PlasmaHH> the thing is from my pov it currently seems possible to easily just destroy other peoples pending changes by pushing a new history that just consists of garbage so I want to make sure that I did not overlook something or need to make sure I dont accidentally destroy it ;)

11:52 <NishanthMenon> lol.. if was possible, it would have already happened and we would have evolved into a new process.. the checks and balances are there. worst case, all you end up doing is to put in a duplicate review request..

11:53 <PlasmaHH> yeah thats what I thought so I was wondering whats the thing that allows me to push the rebased branch of someone elses change ;)

11:55 <NishanthMenon> i have picked up others internal patches as well since they were too busy to post upstream.. i have to dig it up.. but if i recollect it right, I have to sign-off as well, since i was posting it for review and i now own the deltas

11:57 <NishanthMenon> i have however not updated an pre-existing review from someone else.. i have'nt tried that.. (I am guessing, i could file a new review with change-ID changed to generate a duplicate review, and to prevent confusion get the other person to abandon the person's change).. this I am not sure.. having never faced it

11:59 <NishanthMenon> https://review.openocd.org/c/openocd/+/7089 is an example where i picked up Jason (my colleague's patches) - i just add a sign-off (corresponding commit https://github.com/openocd-org/openocd/commit/42872d18bf1326294521096b73314e54a31b0b60 )

11:59 <PlasmaHH> NishanthMenon: I tried donig the commit with the commit-msg hook and now the commit log entry has a different Change-ID

12:01 <NishanthMenon> yes it would generate a new sha if change-Id does'nt exist.. if *you* have posted this patch before in review.openocd.org, then you can do a git commit --amend and use the previous change-id before pushing

12:01 <NishanthMenon> sorry, gotta go.. meeting times for me..

12:02 <PlasmaHH> yeah I need to collect my car too, maybe later

12:02 <NishanthMenon> hope you get it sorted out.. ttyl

12:38 <PaulFertser> PlasmaHH: nothing prevents you from pushing a new change of someone else but it's not too dangerous as Gerrit keeps all old revisions too.

12:39 <PaulFertser> PlasmaHH: it's odd, how did you end up with a commit that didn't have message-id at all if you were rebasing a commit you downloaded from Gerrit?

12:54 <PlasmaHH> PaulFertser: change-id you mean? not it has a new one... so what I did was pulling that change into a local branch, then rebasing it to the best of my abilities, then making a change so it compiles again, commit that (with the hooks, that then added a new change-id )

13:03 <PaulFertser> PlasmaHH: so you ended up having two commits on top of current master?

13:03 <PlasmaHH> yes

13:03 <PaulFertser> PlasmaHH: then you just need to squash the last one into the first one and keep the Change-Id from the first I guess?

13:04 <PlasmaHH> ah ok, lets try

13:04 <PaulFertser> Why did you even commit the change to make it compile as a separate commit instead of --amend the previous one? Then you wouldn't need to squash.

13:04 <PlasmaHH> PaulFertser: because thats how I normally do things in other projects, to distinguish my changes from what others did

13:05 <PaulFertser> I usually look at "git log" and "git show" before pushing to Gerrit to make sure I have just the needed commits there. And they should all be buildable in the order you have in "git log", not just the last one.

13:06 <PlasmaHH> there are so many git workflows and philosophies out there... from the "every commit needs to be perfect, build, tests run etc." to on the other end "merged branches into main/master should look good" ;)

13:06 <PaulFertser> PlasmaHH: I see. But upstream isn't interested much in the history of the change, for the upstream history it's best when each individual commit can be built and tested (for bisectability) and should be doing just one thing. And if there's a known bug then it's best when it's not committed to upstream at all and a rewritten commit without that bug is used.

13:07 <PaulFertser> PlasmaHH: OpenOCD normally aims at not having any notion of "merged branches" at all.

13:07 <PlasmaHH> I am mostly working with projects that either take the whole branch history or squash at the point of merge ...

13:07 <PlasmaHH> I could alternatively reset and amend instead of squashing

13:07 <PaulFertser> I guess the end result is the same so whatever you prefer.

13:08 <PaulFertser> But Gerrit should have the final squashed buildable result for each commit you push.

13:08 <PaulFertser> So yes, guess it's the example of the first philosophy you outlined.

13:09 <PlasmaHH> ok, here goes nothin..

13:09 <PaulFertser> I do not like projects which keep the branch history, it clutters the log and also makes my "archeology" (aka git blaming) harder when I'm trying to understand what was introduced why.

13:10 <PaulFertser> And I do not understand this autosquashing either, I guess history rewriting is best performed by the original author who knows what to squash what not to squash and what to keep from all the commit messages.

13:10 <PlasmaHH> yeah it depends a lot on different factors, how often people commit/push how tight everything works together etc...

13:10 <PlasmaHH> yeah any automatgic thing I try to precent ^^

13:10 <PlasmaHH> prevent even

13:11 <PlasmaHH> ok, now I just need to find a way around the company firewall to push this...

13:11 <PaulFertser> http works

13:11 <PaulFertser> You can make a password for that in Gerrit settings.

13:11 <PlasmaHH> http or https ?

13:12 <PaulFertser> HACKING details the process.

13:12 <PaulFertser> It's actually HTTP over TLS so HTTPS, yes.

13:12 <PaulFertser> But since TLS isn't mandatory part of the flow it's called just HTTP password in Gerrit settings.

13:20 <PlasmaHH> crossing fingers... how long usually until jenkins runs?

13:40 <PlasmaHH> ah it did