On Tue, 27 Apr 2021 01:17:38 -0600,
Junio C Hamano wrote:
>
> Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
>
> >> +check_equal () {
> >> test_debug 'echo'
> >> test_debug "echo \"check a:\" \"{$1}\""
> >> test_debug "echo \" b:\" \"{$2}\""
> >> - if [ "$1" = "$2" ]; then
> >> + if [ "$1" = "$2" ]
> >> + then
> >
> > We prefer `test` over `[`, so it might make sense to update that, as
> > well, along with these other style cleanups.
>
> If I were working on this, I wouldn't bother.
In this case, it's not just about consistency with git-core, it's
about consistency within contrib/subtree; there were just 2 or 3
places where it used `[` instead of `test`.
> If Luke is volunteering to take over its maintainership, it would be
> appreciated by its users. It has been in the "abandonware" status
> for too long.
I think I am volunteering.
We have been using git-subtree increasingly heavily at Ambassador Labs
(née Datawire) for about 2 years now, and I don't see that changing.
What I'm doing now is trying to get >2 years of accumulated patches in
to a submittable state (a lot of the patches were bad; for instance on
my main branch `git subtree add` is broken, but that's fine, because
you don't use `add` all the time like you do `split` or `merge`, but
that's something I need to fix before submitting it). Assuming that
we're going to continue being heavy users of it, and are going to
continue to patch issues with it, I'd rather let that live upstream
rather than telling all of my coworkers to get it from
<https://github.com/LukeShu/git>.
With a recent change in project scheduling, I anticipate that I'll
have bandwidth to be able to handle that. (It's what's giving me
adequate time to work through this pile of existing patches, anyway.)
What does being a maintainer consist of? Are there standups that I
should join?
> As far as I am concerned, contrib/subtree has always been treated as
> a borrowed code [*] that is written in a dialect of shell that is
> different from what our scripts are written in, and there are too
> many style differences (I wouldn't call them violations---nobody has
> expected the code there to follow our style, or attempted to enforce
> our style there) to bother coercing.
>
> [Footnote]
>
> * ... as opposed to a properly maintained part of the git-core
> proper.
Elsewhere in the thread, you suggested that subtree be taken out of
git.git, and live as a standalone project.
I'm not entirely opposed to that, but
1. I'm not sure how whoever picks it up (me) establishes their
git-subtree as the "real" subtree (get a blessing from Avery?).
2. I think a lot of the reason why more people don't use git-subtree
is that the core 'split' operation doesn't quite work reliably
(and also it can be quite slow), and so it doesn't get
recommended. I would like nothing more than to improve the
'split' reliability to where it does start to gain adoption, to
where we can think about it graduating from contrib/ to git-core.
3. Many systems (Arch Linux and macOS, at least) give users
git-subtree as part of the stock Git install. If I'm interested
in growing git-subtree adoption, I'd be a fool to give that up :)
On the other hand, I think that in the long-ish term git-subtree wants
to be rewritten in a better-suited language. My personal inclination
would be Go, but if I ever want it to graduate to git-core, it'd have
to be C, huh?
--
Happy hacking,
~ Luke Shumaker
