Fred Wright said:
> In general, it's a good idea to read an actual book on git, rather than
> trying to understand it purely through manpages. The one I used (almost a
> decade ago) is this one:
> https://www.amazon.com/gp/product/1449316387/
Thanks. I like books.
There is a 3rd editi
On Sat, 18 Nov 2023, Fred Wright via devel wrote:
[...]
With or without this problem, it's a bad idea to combine multiple
unrelated changes into a single MR anyway. It's best to stick to one
topic per branch, both locally and in any MRs derived from such
branches.
I neglected to say:
If
In general, it's a good idea to read an actual book on git, rather than
trying to understand it purely through manpages. The one I used (almost a
decade ago) is this one:
https://www.amazon.com/gp/product/1449316387/
It doesn't tell you everything you might want to know, but it cov
Hal Murray wrote:
>
> Merge requests seem reasonable if all goes well. My work flow is roughly:
> download the patch (URL plus ".patch")
> scan it
> maybe apply and test
> approve and merge
Ah, my work turbulence is incompatible with your workflow.
> But things go downhill if I don't li
Merge requests seem reasonable if all goes well. My work flow is roughly:
download the patch (URL plus ".patch")
scan it
maybe apply and test
approve and merge
But things go downhill if I don't like something. What I get from James is an
update to the MR, a patch to the patch. That