3 ms·

I don't understand at all what you're saying. Sounds like you push your code to a branch called master that tracks master but sits on a separate repo and then y

by zo1 5y ago

I don't understand at all what you're saying. Sounds like you push your code to a branch called master that tracks master but sits on a separate repo and then you apply your commits after approval via patches? Seems like you're recreating the concept of branches using repos and then using patches instead of merging. Either way, just so you know, this kind of attitude and that you think it's a-ok to use such a convoluted process for what is effectively the same thing would 100% mean me not hiring you. That may not mean much on some random forum on the net, but you will encounter it a lot as the industry is definitely not aligned to this odd flow you described.

boomlinde 5y ago
I'm not sure how you read what you're suggesting into my description. I make a commit. git commit # ... git commit # or two I push them to the staging area for a given branch, in this case master git push HEAD:refs/for/master This isn't a branch in the traditional sense but git conveniently sees it that way. Now they're immediately available for review. That looks something like this (this is not from my workplace, but the Go team's Gerrit instance): https://go-review.googlesource.com/c/go/+/361916 https://go-review.googlesource.com/c/go/+/361916 > Either way, just so you know, this kind of attitude and that you think it's a-ok to use such a convoluted process for what is effectively the same thing would 100% mean me not hiring you. That's fine. There are plenty of companies that manage to hire based on competence, experience and references so I'm not exactly aching to get hired at a place that would deny me for having used Gerrit.