Important missing Git operations which are not doable from the web interface

[cirosantilli]

For non programmers to use GitHub, there must be no CLI.

Yes, there are local GitHub / Git GUI clients, but it would be way better if you didn't have to install stuff on your computer.

A few which I find crucial:

• merge request conflict resolution:

  Either of:

  • merge conflict resolution: concept accepted by GitLab at: https://github.com/gitlabhq/gitlabhq/pull/7345, requested to GitHub at https://github.com/isaacs/github/issues/200
  • rebase -i: https://github.com/booktree/booktree/issues/38
• Some way to make merge request history cleaner. Either of:
  • merge --squash for merge requests: https://github.com/booktree/booktree/issues/11
  • commit --amend: https://github.com/booktree/booktree/issues/37
  • rebase -i: https://github.com/booktree/booktree/issues/38
• multi-file edit in a single commit: https://github.com/booktree/booktree/issues/1
• binary file upload: https://github.com/booktree/booktree/issues/9

I am maintaining a list of such features at: https://github.com/booktree/booktree/issues?q=is%3Aopen+label%3Agithub+label%3Aall-from-web-ui (note that that issue tracker contains many GitLab specific requests outside of those tags).

[mryantho]

The web interface would help with students who may have a network drive, but are unable to install GitHub on school computers.

[geoff-nixon]

I think this title of this issue might be somewhat misleading, or at least confusing.

@mryantho Github does already have a very functional web interface, and you certainly don't need to be a programmer to use it. While there's a lot of room for disagreement particularly with reference to what should be meant by "everything", but for a vast number classroom use cases, its pretty darn sufficient (at least long as one subscribes to the Github Flow methodology).

[Also, it bears mentioning that both the GitHub app and git should work from a network drive, generally speaking.]

From a brief perusal of the GitLab issues you linked:

• #10 and #20 are indeed possible (although you cannot create empty directories): to create a directory, create a new file; in filename field, /s are converted to directory paths. To move a file, delete "past the beginning" of the filename field.
• #14 is also possible: if you didn't initialize the repository when you created it, click the link at "We recommend every repository include a README...", and rename "README.md" as you like.

And at risk of doing their work for them speaking for the good folks @github — if my understanding is correct — my feeling is that the rest of the issues are probably "wontfix" type situations, as:

• #11 (pull request commit squashing) and non-trivial merge conflict resolution are usually considered "bad practice" and discouraged, as they "rewrite history". Its a rather advanced git topic as you're probably aware. The problem is that the "merge" commit ends up containing new, different information than what's in the commit history of either of the branches "merged", which (amongst other consequences) making reverts harder and/or causes further merge conflicts. Instead, the idea is that further commits should be made to the "topic" branch (or a fork thereof) until it no longer is in conflict with the upstream branch, rather than "resolve" conflicts at merge time. Likewise, commits should be squashed (if necessary) prior to the pull request/merge. Maybe someone has good intermediate level link that explains the "why" here better... the nitty-gritty is in the git documentation. See the git-rebase manpage, this, etc.
• #17 (assuming you mean rm -rf, not git rm -rf, since there's not really an 'index' or 'working tree' here), for probably the same reasons cited by the GitLab folks. And I would this this would cause a lot of accidental "catastrophic" commits and reverts.

I agree binary file upload #9 (within the necessary file size limits to prevent abuse) would indeed be a nice feature.

[cirosantilli]

@g--n thanks for the reply!

Yes, some of the ideas on Booktree are already doable on GitHub and only apply to GitLab, let's forget those.

title of this issue might be somewhat misleading

Why? What would be more appropriate.

• pull request commit squashing: most devs rewrite history every day locally through commit amend and rebase -i: we make mistakes and want to publish clean PRs. merge --squash is even less destructive as it does not rewrite branch history and allows for a similar effect over merge requests (multiple commits are turned into one).

  causes further merge conflicts

  I didn't know merge --squash could generate conflicts where merge did not. Can you give an example? (not doubting you, I really want to learn)

  commits should be squashed (if necessary) prior to the pull request/merge

  If we had a way to do that on the web interface, I'd be happy as well. But that's even more potentially problematic than merge --squash which is what I propose.

  further commits should be made to the "topic" branch (or a fork thereof) until it no longer is in conflict with the upstream branch

  But how to you find the conflicts on the current web interface? Locally git status + merge markers do the trick. That's somewhat I propose at: https://github.com/gitlabhq/gitlabhq/pull/7345

• non-trivial merge conflict resolution: maybe we are not talking about the same thing: I meant manually resolving conflicts, which was accepted by GitLab at https://github.com/gitlabhq/gitlabhq/pull/7345 and already implemented in a way by Penflip.
• rm -rf: GitLab's argument was that it is not useful enough, and that I can understand. But I disagree with trying to protect users from themselves: more power requires more responsibility, and there is commit history in any case.

[geoff-nixon]

title of this issue might be somewhat misleading

Why? What would be more appropriate.

As I read it, I sounds as though you're saying there's some absolutely crucial feature that would prevent a student from using GitHub without also having access to a shell. Its really only this really hairy stuff that's missing. So... "let's ask GitHub create a web interface equivalent for all command-line git features" ...or something?

most devs rewrite history every day locally through commit amend and rebase -i: we make mistakes and want to publish clean PRs.

No argument here. But, keyword is locally.

merge --squash is even less destructive as it does not rewrite branch history and allows for a similar effect over merge requests (multiple commits are turned into one).

I didn't know merge --squash could generate conflicts where merge did not. Can you give an example?

Turning multiple commits into one sure sounds like rewriting a branch' history to me... ;) This might help. — be sure to read the "epilogue" (softens the blow a bit), and the first few comments.

maybe we are not talking about the same thing: I meant manually resolving conflicts

No, we're on the same page on the "what", I think. But its a variant of the same problem — your merge commit after manually resolving conflicts that require a human to decide doesn't actually reflect a true "merging in" of the other branch's commits. Its a whole new commit, with its own changes. So if you need to revert a specific commit from that branch or a child branch... well, again, I defer to Linus: https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt

further commits should be made to the "topic" branch (or a fork thereof) until it no longer is in conflict with the upstream branch.

But how to you find the conflicts on the current web interface?

Yeah, that's definitely huge problem — the branch comparison tool will tell you "We can’t automatically merge these branches." But there seems be no way to filter only the changes that are conflicting.

[cirosantilli]

Thanks for the links, I'll have a look.

But, keyword is locally.

As long as you do it on a feature branch on your own fork, it does not matter: it should be clear to others that such branches can be changed at any time, and often are already on push -f