GitHub is driving my nut - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: May 20, 2025, 08:37:37 pm
content: I don't usually use git for collaborative work.I mean, I don't use it at all at work.I use it locally sometimes for personal stuff.I'm writing a GNU/Linux article on Xscale, since I've experimented with different platforms, from Compaq to Sharp.Nothing special.Anyway, not just a journalist, I'm just a draft-writer, in this case, the linux/arm-{v4, v5} "expert" guy.Even if I don't know much about it (I am more MIPS-addicted).Just, what I know is of interest to the two guys I collaborate with.They gave me access to a private repository on GitHub.I'm at the first draft version of my part of the article.I worked locally, on my laptopQuoteSimple git pull request to sync stuff, right?Everything seemed to have gone well, I see the files on github.But there is a problem!If I click on the (open) "new pull request" button ...... it does not let me do anything.QuoteThis message appears, and I really do not understandW_h_A_T?

author: DiTBho
author_rank: Super Contributor
timestamp: May 20, 2025, 08:47:59 pm
content: (at work, we use proprietary software, instead of { Git, Svn, Mercury, ... } )

author: langwadt
author_rank: Super Contributor
timestamp: May 20, 2025, 08:55:34 pm
content: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request?tool=cli?

author: dave j
author_rank: Regular Contributor
timestamp: May 20, 2025, 09:06:59 pm
content: I've found thePro Git booka good guide to using it.

author: DiTBho
author_rank: Super Contributor
timestamp: May 20, 2025, 09:17:09 pm
content: I didn't understand what I did wrong: if the repo is empty, what I did should work.I opened a new branch, changed two things just to be able to commit, and forced aCode:git branch v01-draftgit checkout v01-draftnano README.txtgit commit -agit push --set-upstream origin v01-draftThis way it lets me open a pull request.But, is it correct?

author: DiTBho
author_rank: Super Contributor
timestamp: May 20, 2025, 09:34:29 pm
content: (Umm, I didn't mention, "md_util" is a tool I wrote myself.It can be used with "-head" to "extract" the outline from a markdown document.Nothing special, and it doesn't do anything special)

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 20, 2025, 10:29:01 pm
content: You can useCode:git checkout -b <new branch>as a shortcut for git branch/git checkout to create a new local branch.Otherwise yes, this is correct, you're pushing to a new branch.github is a bit of a mess, but anyway. I don't think you can issue a "pull request" on the main/master branch (which I assume is what you wanted) without going through another branch, as you did last. That's how it's supposed to work, otherwise you're just pushing to the main branch, that's not a pull request, that would directly add your commit to it.Now if there was no prior data in the main branch, at least for your new directory, there isn't necessarily a need to issue a pull request, it all depends on the rights you have to the github repo. If the owner didn't give you write rights to the main branch, you can't push to it directly, hence you need to issue a pull request via a branch of your own.But if you have write rights to the main branch and you're pushing new stuff, there is no need to issue a pull request, you can push directly.

author: dferyance
author_rank: Regular Contributor
timestamp: May 21, 2025, 12:10:18 am
content: Yeah don't bother with pull-requests. They aren't really great even in the scenarios that they work for. In your case, collaborating with 2 other people, it seems unnecessary and and extra complication. No need to branch just commit + push. Make sure your version control tools work for you, not the other way around.

author: julian1
author_rank: Frequent Contributor
timestamp: May 21, 2025, 12:11:08 am
content: If you can see the pushed branch on github, then everything is fine on the git side.Perhaps they didn't give you permissions to raise a pull-request?

author: DiTBho
author_rank: Super Contributor
timestamp: May 21, 2025, 10:51:01 am
content: They suggested:```cp -r /your-stuff/* ./git checkout -b draftgit add .git commit -m "first draft"git push```So, I think I don't have wr permissions to the master, and pull requests need a branch.

author: DiTBho
author_rank: Super Contributor
timestamp: May 21, 2025, 11:08:39 am
content: Quote from: dferyance on May 21, 2025, 12:10:18 amIndeed "Doors", the version control I use at work, works this way, just commit + push."Branch to pull request" is something new to me.I am using git on GNU/Linux. All in text console.

author: DiTBho
author_rank: Super Contributor
timestamp: May 21, 2025, 11:16:47 am
content: Quote from: SiliconWizard on May 20, 2025, 10:29:01 pmGitHub is very confusing.Thanks for your post.Yes, I tried to issue a "pull request" on the "main branch" without going through another branch.

author: ledtester
author_rank: Super Contributor
timestamp: May 21, 2025, 12:09:36 pm
content: Quote from: DiTBho on May 20, 2025, 08:37:37 pmGenerally you issue a pull request from a different repo.For instance, you start with the original repo.Then you fork it on github so you have your own copy.After you make changes to the forked repo you create a pull request (from the forked repo).If the owner of the original repo approves it, your changes are incorporated into the original repo.

author: DiTBho
author_rank: Super Contributor
timestamp: May 21, 2025, 01:27:06 pm
content: Quote from: ledtester on May 21, 2025, 12:09:36 pmeh, but I don't have the permission to fork

author: shapirus
author_rank: Super Contributor
timestamp: May 21, 2025, 02:33:40 pm
content: Quote from: DiTBho on May 21, 2025, 01:27:06 pmThat's just one of the ways of doing it. Another is to create a branch.It's the way pull requests work. Pull request is a proposition made by a user to accept achangesetfrom where they have saved their work into the target (generally known as upstream) repo&branch. A changeset is a set of commits which, combined, represent the difference between the source and the target. For the difference to even exist as such, you need a source that the target will be compared against. This source is a branch which can be a branch in a forked repository or the original repository.It's actually pretty convenient once you grasp the principles a little bit and gain some experience. It's no news that git was created by aliens for aliens. But it's a good tool, because they knew exactly how to do it right. It just needs some getting used to. There's an enormous amount of info about it on the web, which helps with that.Speaking specifically of github (which isone ofgit repository web hostings), it has a "compare" endpoint that lets you compare forks or branches and create a pull request for the shown changeset if applicable, for example (just a random url from my browsing history):https://github.com/goharbor/harbor/compare/v2.8.3...morlay:harbor:patch-v2.8.3This endpoint may sometimes (for me personally -- always) be more convenient to use by typing the revisions/tags/branches directly in the address bar rather than finding where the heck they have hidden this in the UI.

author: krish2487
author_rank: Frequent Contributor
timestamp: May 21, 2025, 04:38:26 pm
content: Quote from: dferyance on May 21, 2025, 12:10:18 amand a large part of doing so hinges on learning how to use the tools in the first place. You cant use a drill as a hammer to drive nails and complain that a drill is a bad hammer. git is for collaborative work, the key word beingcollaborative. pull requests, branches, forks are a part of this workflow.@DiTBhothere are plenty of git tutorials floating around. My suggestion is to pull the trigger and commit some time to learn the idea behind the git workflow.I m not stupid enough to say right and wrong about the tools, just that in your case you need to reorient yourself to make git work for you. Once you get the hang of how git is designed to be used, it will be straightforward and painless.

author: shapirus
author_rank: Super Contributor
timestamp: May 21, 2025, 04:42:47 pm
content: Quote from: krish2487 on May 21, 2025, 04:38:26 pmNot necessarily. Before anything else, it is a version control system. Yes, with very good collaborative work capabilities, of course.But it can be super useful for solo projects just as well, for all the benefits a version control system provides (and yes, pull requests and other things can be used when working alone too).

author: krish2487
author_rank: Frequent Contributor
timestamp: May 21, 2025, 04:47:45 pm
content: Quote from: shapirus on May 21, 2025, 04:42:47 pmAgreed. My point was that git was designed to help manage development of the linux kernel, as a replacement for a propreitary vcs ( I forget which.. ). and a collaborative workflow was always one of its core features.. apart from version control of course... heheh.. Now, the collaborative features are also incredibly useful as you have mentioned for solo development..

author: shapirus
author_rank: Super Contributor
timestamp: May 21, 2025, 05:29:37 pm
content: Quote from: krish2487 on May 21, 2025, 04:47:45 pmI vaguely remember (and I may be wrong) that they used CVS back then. It's not proprietary, but as far as collaborative development goes, I can tell you that in the hell where programmers go after life they are most definitely forced to use only CVS for everything. And then there's a separate subdivision of that hell where they have Microsoft Visual SourceSafe, but that's only for very special sinners.

author: dferyance
author_rank: Regular Contributor
timestamp: May 21, 2025, 05:32:08 pm
content: It was designed as a replacement for emailing patch files back and forth. If this is your form of collaboration, it is perfect for it. But most projects, even across time zones, don't work this way.It is like how you have to create a branch in order to do a pull-request / code review. But I don't want to branch, oh well. Now my branch is out of sync and I have to sync it up. Should I merge or re-base? Whoops, I have some local changes, I better stash it and stash pop later. Now I have merge conflict markers.All these tools are perfectly fine in the right context. Git, pull requests, git flow all have been incredibly useful. I use git daily and despite its frustrations, it is much better than some systems I've used. But for a couple people sharing work, it isn't the right model.

author: krish2487
author_rank: Frequent Contributor
timestamp: May 21, 2025, 07:12:48 pm
content: Quote from: shapirus on May 21, 2025, 05:29:37 pmIt was bitkeeper.. I looked it up after posting the message.. :-) and bitkeeper is propreitary..

author: abeyer
author_rank: Frequent Contributor
timestamp: May 21, 2025, 07:14:38 pm
content: Quote from: krish2487 on May 21, 2025, 07:12:48 pmWas. It was later open sourced too. Then kind of died off. Though arguably their non-compete clauses in the community license may have done more to spur git development and adoption than anyone else.

author: krish2487
author_rank: Frequent Contributor
timestamp: May 21, 2025, 07:20:20 pm
content: Quote from: dferyance on May 21, 2025, 05:32:08 pm1. email is a low bar to sharing the patch files.. you can mail physical patch files if you feel so.. the workflow is not dependant on the method of transport.. the idea of diffs and patches remains as valid irrespective of the mode of transport.2. That is the central idea of git afaiu, that each developer has their isolated sandbox to work, without disturbing the flow for others. branches and pull requests are just phase gates to allow for a controlled integration into one immutable source branch of truth that all developers can rely on. If you flip your point on its head.. what happens to other developers work when you merge without having branches and prs..isnt that a much more bigger issue.. that one uncontrolled commit to develop disturbs the work of all the other developers ?? as you have mentioned.. the push-to-develop model works untilexactlytwo developers.. after that a branch-pr strategy is the least disruptive

author: krish2487
author_rank: Frequent Contributor
timestamp: May 21, 2025, 07:22:34 pm
content: Quote from: abeyer on May 21, 2025, 07:14:38 pmI wasnt aware of that.. thanks for the information.I guess I learnt something new today.

author: dferyance
author_rank: Regular Contributor
timestamp: May 23, 2025, 12:29:41 am
content: QuoteYeah essentially that is my point. Large distributed teams need that behavior. Before Linux used a version control system it was patches distributed via email and mailing lists. A non-distributed version control system wouldn't work for the development model. And generally I like the distributed version control model (I'm still disappointed that git won over mercurial).But really for a small to even medium sized team, collaboration is much easier if everyone is working off of the same thing. Not a separate branch, not something out of sync -- everyone on the same page. You can mostly do that with git by just committing to master and doing frequent push / pulls. Making everyone jump through hoops (i.e. branches and PRs) to be all integrated makes things harder in that scenario.

author: dobsonr741
author_rank: Frequent Contributor
timestamp: May 23, 2025, 01:58:37 am
content: Show us the output of “git status” and the output of the final “git push”Nothing wrong with git, you just did not learn/practice enough