Re: [PATCH v2 05/10] replace: make sure --edit results in a different object

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, May 17, 2014 at 08:41:27AM +0200, Christian Couder wrote:

> It's a bad idea to create a replace ref for an object
> that points to the original object itself.
> 
> That's why we have to check if the result from editing
> the original object is a different object and error out
> if it isn't.

I think that's reasonable.

Another option, which I think I mentioned earlier, would be to delete
any existing replacement ref, and return success. So you could use that
to "revert" a replaced object back to its original non-replaced form.

On a similar note, we might want to consider what happens when you
"--edit" an object which already has a replacement. Right now you end up
editing the _original_ object. I wonder if it would make sense to start
the editor with the contents of the replacement object (in which case
you might even "revert" without realizing it).

But those can easily come later if somebody feels like working on them.
Erroring out is not that bad an outcome, since the user can then "git
replace -d" themselves if they want to.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]