On Tue, Dec 29, 2015 at 12:02:30AM -0500, Jeff King wrote:
> Given that using symlinks is only
> triggered by an undocumented (!) option that presumably very few people
> use, I'm inclined to leave it as-is.
Sorry, I am wrong here. We do document core.preferSymlinkRefs. I missed
it because my gre
On Mon, Dec 28, 2015 at 10:45:19AM +0100, Michael Haggerty wrote:
> > +static int create_ref_symlink(struct ref_lock *lock, const char *target)
> [...]
> > + char *ref_path = get_locked_file_path(lock->lk);
> > + unlink(ref_path);
> > + ret = symlink(target, ref_path);
> [...]
>
> This func
On 12/20/2015 08:34 AM, Jeff King wrote:
> The create_symref() function predates the existence of
> "struct lock_file", let alone the more recent "struct
> ref_lock". Instead, it just does its own manual dot-locking.
> Besides being more code, this has a few downsides:
>
> - if git is interrupted
On Mon, Dec 21, 2015 at 12:50:28PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > #ifndef NO_SYMLINK_HEAD
> > - if (prefer_symlink_refs) {
> > - unlink(ref_path);
> > - if (!symlink(target, ref_path))
> > - goto done;
>
> I see that the original
Jeff King writes:
> #ifndef NO_SYMLINK_HEAD
> - if (prefer_symlink_refs) {
> - unlink(ref_path);
> - if (!symlink(target, ref_path))
> - goto done;
I see that the original was sloppy (most certainly my bad) ...
> + char *ref_path = get_locked
The create_symref() function predates the existence of
"struct lock_file", let alone the more recent "struct
ref_lock". Instead, it just does its own manual dot-locking.
Besides being more code, this has a few downsides:
- if git is interrupted while holding the lock, we don't
clean up the loc
6 matches
Mail list logo