On Thu, Feb 04, 2016 at 07:36:46AM +0200, Dan Aloni wrote:
> > In a sense, that encourages a nice workflow for your intended feature.
> > You have to do:
> >
> > git clone -c user.name=... -c user.email=... clone ...
> >
> > to set up your ident in the newly-cloned repository, or else clone will
> > yell at you. But it's a little unfriendly. If you are just cloning to
> > view and not make commits, you don't need your ident set up. And worse,
> > if you forget to add your "-c" ident, clone will go through the trouble
> > to copy all of the objects, and only then complain about your ident.
>
> I think that forcing to give the configuration in 'git clone' could be
> problematic for automated tools (e.g. o build) that invoke 'git clone'
> just for building purposes (i.e. read-only) to a tool-managed directory.
> And what about sub-modules clones? It would be hard to distinguish manual
> clones and automatic clones anyway.
Yeah. I sort of assumed that people with automated tools _wouldn't_ set
user.explicit. But even with that assumption, I think it's too
unfriendly to continue.
> > So I'd argue that this should only kick in for the strict case. Which
> > means the check _has_ to go into fmt_ident, and we have to somehow
> > inform fmt_ident of the four cases:
> [...]
>
> Looks like an enum type would be better here instead of a set of booleans.
Yeah, if we can actually split the state space into the 4 cases, I agree
an enum would be easier to follow. I'm not 100% sure that my cases map
completely to what the code does now, though.
> > I also wonder if we could simply expose the 4 levels of above in a
> > variable, and default it to type-3. That would let people loosen or
> > tighten as they see fit. But it would be a more complicated patch, so if
> > nobody really cares about it beyond this use case, it may be overkill.
>
> I get the impression from this and your later E-Mails that there are
> much more cases to cover when testing this feature (and I would not
> like to break stuff implementing this, obviously).
>
> The code should be cleaned up anyway. I only delved into that code for
> the first time two days ago, so it would take me more time to come up
> with a new one (though reading your overview here of the cases is going
> to be helpful, thanks).
Feel free to look into this direction, but having pushed a little
further towards the "simple" approach (with the 2 patches I just sent),
I think that does what you want without too much complication. I'd be
fine, too, if you wanted to pick those up[1] and put the finishing
touches on the second one.
-Peff
[1] To clarify, since you are new to the git.git workflow: I'd expect
you to use `git am` to pick up my two patches. Leave me as the
author of the first cleanup patch. Squash your additions onto the
second one using `cherry-pick`, `commit --amend`, or whatever, and
make sure to `commit --reset-author` so that you're the author. Post
both as part of the v4 re-roll.
But that's just "here is what I meant", not "what you have to do". :)
--
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
