RFC: Deleting git-svn folder (git-llvm, git-svnrevert, git-svnup)

Hi everyone,

I would like to delete this folder of svn to git migration tools.
https://github.com/llvm/llvm-project/tree/master/llvm/utils/git-svn

My understanding of these tools is that they were useful for when we were migrating between Git and SVN, but now, since the migration is complete, they can be deleted as they are either unnecessary or there are other more common workflow options (ie git llvm push → git push).

  • Is there any reason these scripts should continue to exist that I’m not aware of?
  • I’d like to delete these next Monday. Is that timeline unacceptable to anyone?

Thanks,

Here is a link to the patch: https://reviews.llvm.org/D79348

Giving at least one explicit:

Sounds good to me.

Deleted this morning. Thanks!

I was actually using git llvm in my daily workflow.

Could you explain why we want people to move away from that script?

In addition to the convenience, it prevented me from accidentally creating a new branch (which I did before with push once).

Cheers,

Johannes

A new branch was accidentally pushed today. arcpatch-D62368

I was also using “git llvm push” to commit, sort of out of habit. What’s a recommended, alternative way to push?

Just push :slight_smile:

FWIW, if you do your development in git-branches, it is a little more than that. IT ends up being:

git push origin HEAD:master.

Which is somewhat easy to mess up. For example, I inverted the HEAD/master at one point and ended up creating a branch named “HEAD” at one point.

@Zola, Eric,

I really feel the communication and reasoning here is problematic.

What I most dislike about the process most is how questions and concerns are then ignored or played down.

Thanks,

Johannes

@Zola, Eric,

I really feel the communication and reasoning here is problematic.

From my perspective, you removed stuff “we don’t need”, ignoring whether it is used, and then let people figure out how to deal with the result.

What I most dislike about the process most is how questions and concerns are then ignored or played down.

Honestly, I think Zola did more than I’d have expected to be done for this - sending out the proposal (to llvm-dev, not just llvm-commits, even) & waiting a week for feedback.

Suggesting that LLVM developers (the, apparently rather small (based on feedback from before/after this change) number of them) migrate to the standard git functionality for contributing to git projects seems like it’s in line with discussions I recall seeing before and after the git migration - that the git-llvm scripts were migration tools (there was some discussion about whether they might be used for more post-migration, to enforce certain constraints, etc - but those ideas were not accepted/moved forward with).

I have some concern about adding these scripts back in as they may lead to greater divergence in developer experience and/or become less relevant over time and a weird thing for newcomers to stumble over, perhaps. But I don’t feel /that/ strongly, if other folks particularly prefer using them, they seem mostly harmless.

  • Dave

TBH, all I initially asked for, still ask for, is a reason why `git
llvm` was being removed. Your email was the only one that hinted on a
reason.

(more below)

>
>> @Zola, Eric,
>>
>> I really feel the communication and reasoning here is problematic.
>>
>> From my perspective, you removed stuff "we don't need", ignoring whether
>> it is used, and then let people figure out how to deal with the result.
>>
>> What I most dislike about the process most is how questions and concerns
>> are then ignored or played down.
>>
> Honestly, I think Zola did more than I'd have expected to be done for this
> - sending out the proposal (to llvm-dev, not just llvm-commits, even) &
> waiting a week for feedback.

Sure. That is why I did not mention the process that lead to the situation.
I think my email/questions are well in line with post-commit review
standards but people seem to disagree.

> Suggesting that LLVM developers (the, apparently rather small (based on
> feedback from before/after this change) number of them) migrate to the
> standard git functionality for contributing to git projects seems like it's
> in line with discussions I recall seeing before and after the git migration
> - that the git-llvm scripts were migration tools (there was some discussion
> about whether they might be used for more post-migration, to enforce
> certain constraints, etc - but those ideas were not accepted/moved forward
> with).

I recall no decision being made back in October 2019 and that we will
see how it goes. Till now I thought it went fine, or at least I haven't
understood what needed fixing.

> I have some concern about adding these scripts back in as they may lead to
> greater divergence in developer experience and/or become less relevant over
> time and a weird thing for newcomers to stumble over, perhaps. But I don't
> feel /that/ strongly, if other folks particularly prefer using them, they
> seem mostly harmless.

I don't think I understand your concerns. Could you elaborate what
divergence you can see in the future? FWIW, if the scripts are broken
and people stumble over them it means no one takes care of them and
removal is adequate.

Thanks,
Johannes

> - Dave
>
>>
>> Thanks,
>>
>> Johannes
>>
>> FWIW, if you do your development in git-branches, it is a little more than that. IT ends up being:
>>
>> git push origin HEAD:master.
>>
>> Which is somewhat easy to mess up. For example, I inverted the HEAD/master at one point and ended up creating a branch named “HEAD” at one point.
>>
>> From: llvm-dev <llvm-dev-bounces@lists.llvm.org> <llvm-dev-bounces@lists.llvm.org> On Behalf Of Eric Christopher via llvm-dev
>> Sent: Tuesday, May 12, 2020 11:59 AM
>> To: Hiroshi Yamauchi <yamauchi@google.com> <yamauchi@google.com>
>> Cc: llvm-dev <llvm-dev@lists.llvm.org> <llvm-dev@lists.llvm.org>
>> Subject: Re: [llvm-dev] RFC: Deleting git-svn folder (git-llvm, git-svnrevert, git-svnup)
>>
>> Just push :slight_smile:
>>
>> I was also using "git llvm push" to commit, sort of out of habit. What's a recommended, alternative way to push?
>>
>> I was actually using `git llvm` in my daily workflow.
>>
>> Could you explain why we want people to move away from that script?
>>
>> In addition to the convenience, it prevented me from accidentally creating a new branch (which I did before with push once).
>>
>> Cheers,
>>
>> Johannes
>>
>> Deleted this morning. Thanks!
>>
>> Zola Bridges
>>
>> Giving at least one explicit:
>>
>> Sounds good to me.
>>
>> Here is a link to the patch: https://reviews.llvm.org/D79348
>>
>> Zola Bridges
>>
>> Hi everyone,
>>
>> I would like to delete this folder of svn to git migration tools.
>> https://github.com/llvm/llvm-project/tree/master/llvm/utils/git-svn
>>
>> My understanding of these tools is that they were useful for when we
>>
>> were migrating between Git and SVN, but now, since the migration is
>>
>> complete, they can be deleted as they are either unnecessary or there are
>>
>> other more common workflow options (ie git llvm push --> git push).
>>
>> - Is there any reason these scripts should continue to exist that
>>
>> I'm not aware of?
>>
>> - I'd like to delete these next Monday. Is that timeline
>>
>> unacceptable to anyone?
>>
>> Thanks,
>>
>> Zola Bridges
>>
>> _______________________________________________
>>
>> LLVM Developers mailing list
>> llvm-dev@lists.llvm.org<mailto:llvm-dev@lists.llvm.org> <llvm-dev@lists.llvm.org>
>> llvm-dev Info Page
>>
>> _______________________________________________
>>
>> LLVM Developers mailing list
>> llvm-dev@lists.llvm.org<mailto:llvm-dev@lists.llvm.org> <llvm-dev@lists.llvm.org>
>> llvm-dev Info Page
>> _______________________________________________
>> LLVM Developers mailing listllvm-dev@lists.llvm.org<mailto:llvm-dev@lists.llvm.org> <llvm-dev@lists.llvm.org>llvm-dev Info Page
>>
>> _______________________________________________
>> LLVM Developers mailing listllvm-dev@lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

TBH, all I initially asked for, still ask for, is a reason why git llvm was being removed.

Fair enough - and 24 hours later no one had replied to your inquiry - I don’t think that’s a huge deal, to be honest - I’ve certainly had to follow-up with higher email latencies than that pretty regularly. Eric had replied to someone else’s question pretty reasonably “what do I use instead?” “git push” (what most people have been using since the transition)

Your email was the only one that hinted on a
reason.

I think the original proposal & response covered that - they seem(ed) like dead code (“My understanding of these tools is that they were useful for when we were migrating between Git and SVN, but now, since the migration is complete, they can be deleted as they are either unnecessary or there are other more common workflow options (ie git llvm push → git push).”) - some folks agreed, and time was given in case anyone had use cases they wanted to bring up & didn’t.

(more below)

@Zola, Eric,

I really feel the communication and reasoning here is problematic.

From my perspective, you removed stuff “we don’t need”, ignoring whether
it is used, and then let people figure out how to deal with the result.

What I most dislike about the process most is how questions and concerns
are then ignored or played down.

Honestly, I think Zola did more than I’d have expected to be done for
this

  • sending out the proposal (to llvm-dev, not just llvm-commits, even) &
    waiting a week for feedback.

Sure. That is why I did not mention the process that lead to the situation.
I think my email/questions are well in line with post-commit review
standards but people seem to disagree.

I don’t think your first email was unreasonable/not sure anyone’s saying it was unreasonable?

Suggesting that LLVM developers (the, apparently rather small (based on
feedback from before/after this change) number of them) migrate to the
standard git functionality for contributing to git projects seems
like it’s
in line with discussions I recall seeing before and after the git
migration

  • that the git-llvm scripts were migration tools (there was some
    discussion
    about whether they might be used for more post-migration, to enforce
    certain constraints, etc - but those ideas were not accepted/moved
    forward
    with).

I recall no decision being made back in October 2019 and that we will
see how it goes. Till now I thought it went fine, or at least I haven’t
understood what needed fixing.

I think the migration went fine, yes - but these scripts seem to me like a vestige of the hybrid situation & no longer needed/especially beneficial.

I have some concern about adding these scripts back in as they may
lead to
greater divergence in developer experience and/or become less
relevant over
time and a weird thing for newcomers to stumble over, perhaps. But I
don’t
feel /that/ strongly, if other folks particularly prefer using them, they
seem mostly harmless.

I don’t think I understand your concerns. Could you elaborate what
divergence you can see in the future? FWIW, if the scripts are broken
and people stumble over them it means no one takes care of them and
removal is adequate.

I’d generally prefer to remove things sooner rather than later, personally. I believe some of the original motivation was an offline discussion about adding more features (to trim unnecessary Phabricator fields, I believe) to them & a response was that they’re not really used/encouraged & so adding features wouldn’t be especially valuable - so the thought was to go the other way, rather than keeping them around, and building processes that might only work with the scripts & then being let down when those processes aren’t adhered to by most of the community (because they’re not using the scripts) it’d be better to remove them and standardize practices on the plain git tools.

  • Dave

For some reason this thread seems to be gone in a wrong direction. I'm sorry for that.

The discussion on the RFC asked for a reason to keep the script, I think we heard reasons to do so (due to branches).

Now, I was unable to determine if the `git llvm` scripts was removed "just as part of the bunch" or if we expect a problem with the script.

If it is the former, are there reasons against adding it back?

Thanks,

Johannes

I think the only reason is whether or not we want to encourage anything as part of them or whether we want “llvm specific” commit advice/instructions/etc where we want people to use these for sure.

That said, git isn’t the most command line friendly of VCSs for me so if we want to have something that makes things just a little easier I’m down, but would like to see what we expect them to do documented (here?) and … documented (on the web page).

Thoughts?

-eric

For some reason this thread seems to be gone in a wrong direction. I’m
sorry for that.

All good (:

The discussion on the RFC asked for a reason to keep the script, I think
we heard reasons to do so (due to branches).

Yeah, it seems harmless enough to keep git-llvm if some folks find it useful. I don’t object.

Now, I was unable to determine if the git llvm scripts was removed
“just as part of the bunch” or if we expect a problem with the script.

If it is the former, are there reasons against adding it back?

I think it was intentionally removed, as I mentioned - there was a discussion about adding features to it, and a general consensus that it didn’t have mainstream usage/adding features wouldn’t get a lot of traction (chicken & egg problem, to be sure - don’t get users without features, can’t justify features without users) - but, yes, if a few folks are still finding value in the scripts I don’t mind them sticking around, I think they’re pretty harmless.

Re, Eric’s:

“I think the only reason is whether or not we want to encourage anything as part of them or whether we want “llvm specific” commit advice/instructions/etc where we want people to use these for sure.
That said, git isn’t the most command line friendly of VCSs for me so if we want to have something that makes things just a little easier I’m down, but would like to see what we expect them to do documented (here?) and … documented (on the web page).”

I don’t mind too much, really - they’ve been useful for some folks so far, I don’t think adding them back in should necessarily involve a higher bar than their existence/original introduction did previously (& like the git-svn tools - some folks used them, some didn’t, etc) and I’d probably have somewhat more significant feelings about not wanting to encourage their use further (for the same chicken-and-egg-y reasons) in formal “how to work with LLVM” documentation, but if it’s documented amongst other tools rather than promoted as a “here’s how to work with llvm” I wouldn’t have any objection. (& if people want to encourage this as the canonical way to do LLVM, I think that discussion’s certainly something that could be had - I’m just expressing my personal opinion about that direction)

  • Dave

For some reason this thread seems to be gone in a wrong direction. I'm sorry for that.

The discussion on the RFC asked for a reason to keep the script, I think we heard reasons to do so (due to branches).

Now, I was unable to determine if the `git llvm` scripts was removed "just as part of the bunch" or if we expect a problem with the script.

If it is the former, are there reasons against adding it back?

The reason I am in favor of removing this script is that it avoids the
problem where people report problems with their local git configuration
as bugs in the script.

-Tom

For some reason this thread seems to be gone in a wrong direction. I’m
sorry for that.

All good (:

The discussion on the RFC asked for a reason to keep the script, I think
we heard reasons to do so (due to branches).

Yeah, it seems harmless enough to keep git-llvm if some folks find it useful. I don’t object.

Now, I was unable to determine if the git llvm scripts was removed
“just as part of the bunch” or if we expect a problem with the script.

If it is the former, are there reasons against adding it back?

I think it was intentionally removed, as I mentioned - there was a discussion about adding features to it, and a general consensus that it didn’t have mainstream usage/adding features wouldn’t get a lot of traction (chicken & egg problem, to be sure - don’t get users without features, can’t justify features without users) - but, yes, if a few folks are still finding value in the scripts I don’t mind them sticking around, I think they’re pretty harmless.

Re, Eric’s:

“I think the only reason is whether or not we want to encourage anything as part of them or whether we want “llvm specific” commit advice/instructions/etc where we want people to use these for sure.
That said, git isn’t the most command line friendly of VCSs for me so if we want to have something that makes things just a little easier I’m down, but would like to see what we expect them to do documented (here?) and … documented (on the web page).”

I don’t mind too much, really - they’ve been useful for some folks so far, I don’t think adding them back in should necessarily involve a higher bar than their existence/original introduction did previously (& like the git-svn tools - some folks used them, some didn’t, etc) and I’d probably have somewhat more significant feelings about not wanting to encourage their use further (for the same chicken-and-egg-y reasons) in formal “how to work with LLVM” documentation, but if it’s documented amongst other tools rather than promoted as a “here’s how to work with llvm” I wouldn’t have any objection. (& if people want to encourage this as the canonical way to do LLVM, I think that discussion’s certainly something that could be had - I’m just expressing my personal opinion about that direction)

Sounds good to me. As I was telling Johannes: “My input in VCSs discussions should be taken with a very large grain of salt”. I just want it to be straightforward and reduce possible areas of issues :slight_smile:

-eric

For some reason this thread seems to be gone in a wrong direction. I'm sorry for that.

The discussion on the RFC asked for a reason to keep the script, I think we heard reasons to do so (due to branches).

Now, I was unable to determine if the `git llvm` scripts was removed "just as part of the bunch" or if we expect a problem with the script.

If it is the former, are there reasons against adding it back?

The reason I am in favor of removing this script is that it avoids the
problem where people report problems with their local git configuration
as bugs in the script.

I see. I did not expect that was happening.

I was hoping it would allow us to solve common problems, .e.g., what we learn form the threads asking how to deal with git directly.

I also thought, the script would give us also a nice way forward once we change our workflow again (without requiring everyone to do it manually).

Cheers,

Johannes

FWIW, I’m not against people using the script if there’s a good reason for it, but I’d be somewhat opposed to mandating it, as that could easily get confusing for people like me who work in both downstream and upstream repos who wouldn’t want to use the scripts downstream - it would be fairly straightforward to forget to use it/use it incorrectly, and depending on what the script actually does, this could cause various unwanted side effects, which may not even be noticed immediately.