Re: git format-patch can clobber existing patch

["Σταύρος Ντέντος" <stdedos@gmail.com>]

Ντέντος Σταύρος
On Fri, Feb 22, 2019 at 9:38 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> > On Thu, Feb 21, 2019 at 03:40:09PM -0800, Junio C Hamano wrote:
> >> Σταύρος Ντέντος  <stdedos@gmail.com> writes:
> >> > Would it make sense / be easy enough to have some clobbering check / flag?
> >>
> >> Given that use of '-o' to redirect to a fresh/new directory would
> >> reduce the risk of such clobbering, and use of '-v' to force
> >> different filenames would reduce the risk of such clobbering,
> >> it seems to me that aborting the operation when we fail to open
> >> the output, without any option to override and allow clobbering,
> >> would make sense.  If existing files record 4 patch series
> >> 0001-x.patch, 0002-y.patch, 0003-z.patch, and 0004-w.patch, and you
> >> generate with "format-patch --allow-clobbering" a three-patch series,
> >> it would overwrite 0001 thru 0003 but will not remove 0004, so the
> >> end result will still be confusing.

There might be a handful of complexities / undefined behaviors coming
out of this; however, I think "not" overwriting a file to be a higher
directive (given that then, it is unrecoverable).
Using any of the '-o', '-v' might be helpful - if you are re-running
commands from history, however, it wouldn't necessarily provide any
protection ;-)

> > I think a flag for this would be useful. For people that store tarballs
> > (or pristine-tar files) and patches in their repository, overwriting the
> > existing files is definitely desired.
> >
> > My personal preference is that the flag be --no-clobber, but I can see
> > arguments for the other side as well.

On my head, I was thinging that preferably `git config
format-patch.no-clobber true` could be set, instead of (continuously)
carrying around a `--no-clobber` flag.
I should've probably be more clear about that. However, any way is "as
good as any".

> That's actually simpler, which is good, as we do not have to worry
> about adjusting the existing tests that rely on the clobbering
> behaviour ;-).
>
> I'll find time before I leave for my offline week, but this
> obviously will not be merged before the upcoming release.
>
> Thanks.  I think I've mostly outlined a three-patch series to do
> this ready.
>
>
>
>
>
>
>