On Mon, 2015-07-06 at 18:51 +0200, Michael Haggerty wrote:
> > +{
> > + int i, status = 0, start = 0;
>
> It looks like start is initialized unconditionally after the first loop,
> so the initialization here is a red herring.
Will fix.
> So, I have a philosophical question here with a practical side...
>
> It appears that this command allows you to create a reflog for a
> reference that doesn't yet exist. At first blush, this seems to make
> sense. Suppose you want the creation of a reference to be logged. Then
> you can first turn on its reflog, then create it.
>
> But I think this is going to create problems. Reflogs are rather
> intimately connected to their references. For example, writes to a
> reflog are guarded by locking the corresponding reference. And currently
> a reflog file is deleted when the corresponding reference is deleted.
> Also, there are constraints about which references can coexist; for
> example, references "refs/heads/foo" and "refs/heads/foo/bar" cannot
> exist at the same time, because (at least when using the filesystem
> backend), "refs/heads/foo" would have to be both a file and a directory
> at the same time. So if one of these references already exists, it would
> be an error to create a reflog for the other one.
>
> Similarly, if there is a reflog file for one of these references that
> was created by this command, but there is not yet a corresponding
> reference, then any command that later tries to create the other
> reference will not be able to create the reflog for *that* reference
> because it will conflict with the existing reflog. I doubt that the
> reference creation is smart enough to deal with this situation.
>
> So all in all, I think it is unwise to allow a reflog to be created
> without its corresponding reference.
>
> This, in turn, suggests one or both of the following alternatives:
>
> 1. Allow "git reflog create", but only for references that already exist.
This turns out not to work for git stash, which wants to create a reflog
for stash creation.
> 2. If we want to allow a reflog to be created at the same time as the
> corresponding reference, the reference-creation commands ("git branch",
> "git tag", "git update-ref", and maybe some others) probably need a new
> option like "--create-reflog" (and, for symmetry, probably
> "--no-create-reflog").
git branch should already autocreate reflogs, since the refs it creates
are under refs/heads.
> At the API level, it might make sense for the ref-transaction functions
> to get a new "REF_FORCE_CREATE_REFLOG" flag or something.
Junio was opposed to the converse flag, so I'm going to just add
manually add code to create reflogs.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
