This is an archive of the discontinued LLVM Phabricator instance.

[git-llvm] Do not reinvent `@{upstream}`
ClosedPublic

Authored by davezarzycki on Sep 6 2019, 1:18 AM.

Details

Summary

Make git-llvm more robust when used with a nontrivial repository.

Diff Detail

Event Timeline

davezarzycki created this revision.Sep 6 2019, 1:18 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 6 2019, 1:18 AM
mehdi_amini accepted this revision.Sep 6 2019, 9:08 PM

LGTM.
Nice! I didn't this notation, apparently it's been there since 1.7.
You can also use @{u} shortcut for it, I'll try to remember this

This revision is now accepted and ready to land.Sep 6 2019, 9:08 PM

Hi! I think this might've broken the normal workflow for using this helper script shown in https://llvm.org/docs/GettingStarted.html#for-developers-to-commit-changes-from-git

Normally, my workflow is

$ git checkout branch-to-do-work-on
$ # make and add my changes
$ git commit 
$ git llvm push

But on the git llvm push I get

`git merge-base HEAD '@{upstream}'` returned 128
fatal: no upstream configured for branch 'branch-to-do-work-on'

I think this patch might be the cause of this. Could you look into it?

davezarzycki closed this revision.Sep 8 2019, 4:08 AM

Hi @leonardchan,

  1. Working with and configuring upstream branches is fundamental to using git.
  2. It was a mistake for the git-llvm script to assume that the remote named "origin" is the official LLVM repository. For many people, "origin" is probably correct, but for many others, and the remote named origin depends on which repository was cloned first.
  3. Your local branch isn't setup correctly. You can fix that with git branch --set-upstream-to=origin/master (assuming that origin is the correct name of the remote server in your git repository).
  4. When you use git branch or git checkout, please remember to use --track if that is what you want/need.

I hope this helps,
Dave

Do we have the same ability as git push to specify the remote? The equivalent of git push origin master (which works without having an upstream branch)?

In any case the doc should be updated!

The script doesn't have the ability to specify the name of the remote server. That being said, the script is only designed to work with one backend server due to how it hides SVN and in the future how it will hide GitHub status check magic.

What do you see as needing updating in the documentation?

thakis added a subscriber: thakis.Sep 9 2019, 5:44 PM

Similar to leonardchan, this broke my workflow too. Please don't break user's workflows. If there's no good fix for this, I think this should be reverted.

thakis added a comment.Sep 9 2019, 5:45 PM

To add some more words, previously we could git checkout -b foo, hack a bit commit, and run this script. Now this requires additional, long flags. I don't think making a corner case work that nobody noticed being broken for many months is worth making everything more inconvenient for everyone.

I took the responsibility of reverting in r371480, since I approved this revision without anticipating the behavior change.

To add some more words, previously we could git checkout -b foo, hack a bit commit, and run this script. Now this requires additional, long flags. I don't think making a corner case work that nobody noticed being broken for many months is worth making everything more inconvenient for everyone.

This is a very good point. How do we move forward though?
With the migration to GitHub around the corner, I think it'll be important to have git llvm behaves as much as possible as thin wrapper on top of git (in case you don't know git llvm push will be mandatory to push to LLVM on GitHub, as far as I know).

utils/git-svn/git-llvm
199

Losing the fallback here wasn't really intended I guess, or at least it wasn't acknowledged and made explicit in the commit message.

davezarzycki added a comment.EditedSep 10 2019, 12:38 AM

I took the responsibility of reverting in r371480, since I approved this revision without anticipating the behavior change.

To add some more words, previously we could git checkout -b foo, hack a bit commit, and run this script. Now this requires additional, long flags. I don't think making a corner case work that nobody noticed being broken for many months is worth making everything more inconvenient for everyone.

This is a very good point. How do we move forward though?
With the migration to GitHub around the corner, I think it'll be important to have git llvm behaves as much as possible as thin wrapper on top of git (in case you don't know git llvm push will be mandatory to push to LLVM on GitHub, as far as I know).

I think it really depends on what the community wants. Is git-llvm a transitional tool? Or do people want to keep using it long after the transition?

Personally, I hope that git-llvm can go away after the transition, so deprecating deviations from normal git behavior is preferable (like the assumption that the remote is named "origin"). That being said, there seems to be some desire in the community to use git-llvm as a way to workaround GitHub quirks (like the lack of pre-receive hooks to enforce community norms like "no merge commits").

In any case, we can certainly fall back to origin/master if @{upstream} fails and warn about this behavior being different from git proper.

Dave

PS – Hi @thakis. I think it is unfair and incorrect to say that "nobody noticed" that the existing behavior was problematic. I noticed. And I'd wager others did also. That being said, the kinds of people that would notice that "origin" is hardcoded into git-llvm also tend to be the kinds of people that can workaround this git-llvm bug until they get tired of doing so and submit a patch.

thakis added a comment.EditedSep 10 2019, 5:07 AM

Upon re-reading this sounds a bit accusatory. That's not how I meant this, apologies for that! I understand you're solving a problem you're having and that's a fine thing to do of course. I'm just trying to say that this particular approach (unintentionally!) caused a problem for me, and I imagine for many people using the monorepo.

I'm trying to brainstorm ways forward that solve your problem without breaking me.

Upon re-reading this sounds a bit accusatory. That's not how I meant this, apologies for that! I understand you're solving a problem you're having and that's a fine thing to do of course. I'm just trying to say that this particular approach (unintentionally!) caused a problem for me, and I imagine for many people using the monorepo.

I'm trying to brainstorm ways forward that solve your problem without breaking me.

No worries. FYI – If you type: git checkout -b myNewBranch origin/master then the upstream tracking will automatically be setup.

I don't know what the long-term plans for this script are. I don't have a strong opinion, but weakly agree that it'd be good if it went away. In that case, I personally wouldn't add a warning and just make it temporarily do the (usually :P) right thing of using origin/master as upstream if there's no explicit upstream. If there's a warning however, it'd be nice if it included git checkout -b myNewBranch origin/master as suggested command to run, since I found that difficult to find. (Thanks for mentioning it!)

Alternatively, accepting something like git llvm push origin like mehdi suggested further up sounds good to me.

I don't know what the long-term plans for this script are.

The only way for us to enforce linear history on GitHub at the moment is to mandate the use of the script unfortunately.

My preference if the script stays after migration would be to not differ from git native behavior to not be surprising (I mean that git llvm push should be aligned on git push).
I hope that the issue faced here can be circumvented with better newcomers documentation. Aligning on the native git behavior means also that any git documentation (or StackOverflow answer) would apply equally to git llvm.

I don't know what the long-term plans for this script are.

The only way for us to enforce linear history on GitHub at the moment is to mandate the use of the script unfortunately.

Food for thought:

  1. git-llvm is run client side, so the linear history check isn't technically "enforced".
  2. with SVN, nothing stopped people from merging into master other than social norms and the world didn't end.
  3. why not just trust people after a few months to not do merge commits and then warn/punish people that do? Then git-llvm can go away.
  4. alternatively, one could just have a frequently run script force update master to the last pre-merge commit and send out an automated and angrily worded email.
  5. nag/beg GitHub to make merge commits optionally require project administrator privileges. I'd hope for a high-profile project like LLVM, they would consider it.

I don't know what the long-term plans for this script are.

The only way for us to enforce linear history on GitHub at the moment is to mandate the use of the script unfortunately.

Food for thought:

  1. git-llvm is run client side, so the linear history check isn't technically "enforced".

Someone would have to be really malicious to work around the server-side checks that goes with the client though. This is in the range of getting commit access removed IMO.

  1. nag/beg GitHub to make merge commits optionally require project administrator privileges. I'd hope for a high-profile project like LLVM, they would consider it.

I think we requested it a couple of time already, I don't think it got anywhere though.