Git's getting in my way again
-
@blakeyrat said in Git's getting in my way again:
Your branch is up-to-date with 'origin/develop'
Stolen --- not written by me:
107
down vote
accepted
What the status is telling you is that you're behind the ref called origin/master which is a local ref in your local repo. In this case that ref happens to track a branch in some remote, called origin, but the status is not telling you anything about the branch on the remote. It's telling you about the ref, which is just a commit ID stored on your local filesystem (in this case, it's typically in a file called .git/refs/remotes/origin/master in your local repo).
git pull does two operations; first it does a git fetch to get up to date with the commits in the remote repo (which updates the origin/master ref in your local repo), then it does a git merge to merge those commits into the current branch.
Until you do the fetch step (either on its own or via git pull) your local repo has no way to know that there are additional commits upstream, and git status only looks at your local origin/master ref.
When git status says up-to-date, it means "up-to-date with the branch that the current branch tracks", which in this case means "up-to-date with the local ref called origin/master". That only equates to "up-to-date with the upstream status that was retrieved last time we did a fetch" which is not the same as "up-to-date with the latest live status of the upstream".
Why does it work this way? Well the fetch step is a potentially slow and expensive network operation. The design of Git (and other distributed version control systems) is to avoid network operations when unnecessary, and is a completely different model to the typical client-server system many people are used to. It's entirely possible to use Git offline, with no connection to a centralized server, and the output of git status reflects this.
Creating and switching branches (and checking their status) in Git is supposed to be lightweight, not something that performs a slow network operation to a centralized system. The assumption when designing Git, and the git status output, was that users understand this. With the adoption of Git by lots and lots of users who are not familiar with DVCS this assumption is not always valid.
-
@masonwheeler said in Git's getting in my way again:
@thecpuwizard Then how can it possibly make meaningful reports about my status in relation to the actual remote, is it is purporting to do here?
Because git caches remote branch pointers locally, and you can pull from those local caches without an internet connection.
@blakeyrat said in Git's getting in my way again:
I don't see the word "cached" there
Everything in git is cached, always. The only times that is not true is
git fetch(andgit pull), andgit pushI guess. Therefore the default assumption you should always make is that it's talking about cached data.
-
@lb_ said in Git's getting in my way again:
@masonwheeler said in Git's getting in my way again:
@thecpuwizard Then how can it possibly make meaningful reports about my status in relation to the actual remote, is it is purporting to do here?
Because git caches remote branch pointers locally, and you can pull from those local caches without an internet connection.
@blakeyrat said in Git's getting in my way again:
I don't see the word "cached" there
Everything in git is cached, always. The only times that is not true is
git fetch(andgit pull), andgit pushI guess. Therefore the default assumption you should always make is that it's talking about cached data.It's the drawback of using a distributed version control system as if it were a centralized control system. This is just one of the bits of bullshit you encounter.
EDIT: Not disagreeing BTW, just restating the context.
-
@thecpuwizard That explanation is excellent from a technical perspective, but the message weren't misleading in the first place, end users wouldn't need to look up the six-paragraph explanation of what it means since it doesn't mean what it says.
-
@jbert said in Git's getting in my way again:
It's the drawback of using a distributed version control system as if it were a
centralizednormal control system.FTFY, because 99.99% of software projects are centralized. This is (one of many reasons) why Git is a bad fit.
-
@masonwheeler said in Git's getting in my way again:
because 99.99% of software projects are centralized
[citation needed]
-
@masonwheeler said in Git's getting in my way again:
why Git is a bad fit
...for what? You can't just say X is a bad fit and then put a period there. It's always situational.
If you meant to say "in general" then I will agree to disagree.
-
@lb_ Yes, I meant to say "in general."
Git was created by the Linux project, to fit the specific needs of the Linux project, which don't look anything at all like the needs of most software projects.
-
@masonwheeler said in Git's getting in my way again:
FTFY, because 99.99% of software projects are centralized.
That might have been true in 1982, but nowadays, not so much.
-
@masonwheeler yeah I agree that has been a major setback, but thankfully we've been able to make changes over the years. It still sucks that the CLI and underlying library are the same thing.
-
@heterodox said in Git's getting in my way again:
@thecpuwizard That explanation is excellent from a technical perspective, but the message weren't misleading in the first place, end users wouldn't need to look up the six-paragraph explanation of what it means since it doesn't mean what it says.
Well, the message is correct in its context.
However, no git manual ever starts with "git commands are local and use locally cached data by default". Instead they go on about commits, branches, HEAD, refs, remotes and remote-tracking branches, sprinkled with some graph theory.
The message could be made less deceiving for people who assume that git is online-by-default by mentioning that it's the locally cached branch, though I guess it would offend Linus' delicate sensibilities.
-
@raceprouk said in Git's getting in my way again:
@masonwheeler said in Git's getting in my way again:
FTFY, because 99.99% of software projects are centralized.
That might have been true in 1982, but nowadays, not so much.
How many projects have you worked on where you pushed to something other than the central repo? (Not counting Github, which goes out of its way to force that paradigm on you whether it makes sense or not.)
-
@heterodox said in Git's getting in my way again:
@thecpuwizard That explanation is excellent from a technical perspective, but the message weren't misleading in the first place, end users wouldn't need to look up the six-paragraph explanation of what it means since it doesn't mean what it says.
Short version "local" origin and "remote" origin are two different things.
Better?
I will agree, not much better - but it was claimed as a BUG, which is different.
-
@raceprouk said in Git's getting in my way again:
@masonwheeler said in Git's getting in my way again:
FTFY, because 99.99% of software projects are centralized.
That might have been true in 1982, but nowadays, not so much.
How many corporate projects are not? VERY few. As soon as there is one budget [or any of a number of other factors that eventually trace back to a single corporate point] the project is not distributed.
-
@masonwheeler said in Git's getting in my way again:
How many projects have you worked on where you pushed to something other than the central repo?
Irrelevant. There are millions of software projects in the world, and a significant proportion of them are distributed. To extrapolate a global statistic from a single developer is an exercise in futility.
-
@heterodox said in Git's getting in my way again:
@thecpuwizard said in Git's getting in my way again:
But it is not purporting to do ANYTHING related to the remote. It is saying that the working folder matches the HEAD in the locally cached repository........
Somebody is making a mistake in their attributions - I NEVER posted that.
-
@thecpuwizard Blubrity blurbity blurbity.
Yet another AWFUL UI decision explained with "you stupid uneducated idiots are just too stupid to use our beautiful source control system! Have we told you about the directed acyclic graph yet?"
Seriously, stop encouraging this type of garbage behavior. Software is supposed to be for HUMAN BEINGS to use.
-
@lb_ said in Git's getting in my way again:
yeah I agree that has been a major setback, but thankfully we've been able to make changes over the years. It still sucks that the CLI and underlying library are the same thing.
"we"? You're on the Git team?
Oh man I want to punch you SO MUCH right now.
-
@thecpuwizard said in Git's getting in my way again:
I will agree, not much better - but it was claimed as a BUG, which is different.
The fact we're having this discussion means it's a bug.
Usability problems are bugs.
Any message from a piece of software that requires several paragraphs of explanation is a bug.
-
@raceprouk said in Git's getting in my way again:
Irrelevant. There are millions of software projects in the world, and a significant proportion of them are distributed. To extrapolate a global statistic from a single developer is an exercise in futility.
100% relevant. Remember, it does not mater where thing are geographically, that is not what distributed refers to.
Multiple remotes, owned by different organizations, is one of the primary indicators of the software being distributed from a point of control, etc.
-
@thecpuwizard said in Git's getting in my way again:
Somebody is making a mistake in their attributions - I NEVER posted that.
I'm confused. I click the link and it goes right to the post where you said that.
-
@heterodox said in Git's getting in my way again:
@thecpuwizard said in Git's getting in my way again:
Somebody is making a mistake in their attributions - I NEVER posted that.
I'm confused. I click the link and it goes right to the post where you said that.
No, I said that checkout was a local only operation, then mason ASKED me the question....
-
@blakeyrat said in Git's getting in my way again:
Any message from a piece of software that requires several paragraphs of explanation is a bug.
A number of scientific programs I have worked with have messages that take multiple chapters of textbooks to explain!
That being said, that in many cases, it is a real problem, yet the software is working as designed and using terminology in the context that is defined for the application......
-
@thecpuwizard said in Git's getting in my way again:
@raceprouk said in Git's getting in my way again:
Irrelevant. There are millions of software projects in the world, and a significant proportion of them are distributed. To extrapolate a global statistic from a single developer is an exercise in futility.
100% relevant. Remember, it does not mater where thing are geographically, that is not what distributed refers to.
I'm not arrogant or conceited enough to believe that my experience is definitive and typical of the industry at large.
-
@thecpuwizard said in Git's getting in my way again:
A number of scientific programs I have worked with have messages that take multiple chapters of textbooks to explain!
Ok. Sorry you work with such buggy software.
@thecpuwizard said in Git's getting in my way again:
That being said, that in many cases, it is a real problem,
No shit.
@thecpuwizard said in Git's getting in my way again:
yet the software is working as designed
The problem is it was designed by incompetents that shouldn't be allowed within 100 meters of a keyboard.
@thecpuwizard said in Git's getting in my way again:
in the context that is defined for the application......
...............................................................................................................................................................................................................................................................................................................
Look if the software wasn't shit, the message wouldn't be confusing and this little aside wouldn't exist. Moreover, the initial problem that prompted this thread probably also wouldn't exist.
-
@thecpuwizard said in Git's getting in my way again:
No, I said that checkout was a local only operation, then mason ASKED me the question....
And then you answered it and I quoted your answer. It's the first time those words appeared on the page. I'd post my own screenshot but I'm on mobile.
... am I on drugs or are you? Are you making some point about non-literal "attribution" I'm simply not getting? Can someone other than the two of us explain the confusion here?
-
@raceprouk said in Git's getting in my way again:
I'm not arrogant or conceited enough to believe that my experience is definitive and typical of the industry at large.
Nor am I...
However working with large datasets [think Gartner group sized] it is reasonable to establish some statistical information.
I can loop back if desired about how multiple remotes is a decent measure that Git is being used with software that is actually distributed for independent development [such as Linux OS], but for this post, lets take that as a reasonable premise.
As of April 17th 2017 [the last date I have data for, but hard to believe there would be significant change], less that 2% of GitHub repositories had any remotes [indicating they are top level repositories], and less that 0.05% has multiple remotes [indicating distribution]. Not definitive, but a pretty good indicator.
-
@heterodox said in Git's getting in my way again:
... am I on drugs or are you? Are you making some point about non-literal "attribution" I'm simply not getting? Can someone other than the two of us explain the confusion here?
Pretty sure it is not me, but if it is, would I know????
-
@thecpuwizard said in Git's getting in my way again:
As of April 17th 2017 [the last date I have data for, but hard to believe there would be significant change], less that 2% of GitHub repositories had any remotes [indicating they are top level repositories], and less that 0.05% has multiple remotes [indicating distribution]. Not definitive, but a pretty good indicator.
And how many of those are active? I've lost count of the number of GitHub repos I've come across that haven't had an update in years.
-
@thecpuwizard said in Git's getting in my way again:
@heterodox said in Git's getting in my way again:
... am I on drugs or are you? Are you making some point about non-literal "attribution" I'm simply not getting? Can someone other than the two of us explain the confusion here?
Pretty sure it is not me, but if it is, would I know????
Hmm, it was me [in a way]....
I misread one of the quotes... The thread is consistent with me taking the position that "Checkout" never purports to be talking about a remote [although the use of origin does mislead people who are not aware that there is a local meaning to origin as well as a remote one]
-
@raceprouk said in Git's getting in my way again:
And how many of those are active? I've lost count of the number of GitHub repos I've come across that haven't had an update in years.
How does "when" something was active have any impact on determining how something was used at the time it was active????
For projects that are distributed, there are typically 3 or more repositories with appropriate remotes set up within a very short period [and then more added as the distribution spreads - if it does].
-
@thecpuwizard said in Git's getting in my way again:
How does "when" something was active have any impact on determining how something was used at the time it was active????
Because including ten thousand projects that once had two commits three years ago skews the numbers so badly it makes the analysis worthless. Not to mention trends continue to evolve, and three years is a long time in software development.
-
@raceprouk said in Git's getting in my way again:
@thecpuwizard said in Git's getting in my way again:
How does "when" something was active have any impact on determining how something was used at the time it was active????
Because including ten thousand projects that once had two commits three years ago skews the numbers so badly it makes the analysis worthless. Not to mention trends continue to evolve, and three years is a long time in software development.
Next numbers will be out in October, let me see if I can get them to add some filters to the reports...
But, do you really think that accounts for it? Of the "ten thousand projects that once had two commits three years ago" how many do you think were created just to have a repository for a single developer or a small group intending to work together on a common goal?
I believe that the vast majority (99%+) of the ones that meet your criteria fall into one of the two categories I just mentioned.
-
@thecpuwizard said in Git's getting in my way again:
As of April 17th 2017 [the last date I have data for, but hard to believe there would be significant change], less that 2% of GitHub repositories had any remotes [indicating they are top level repositories], and less that 0.05% has multiple remotes [indicating distribution]. Not definitive, but a pretty good indicator.
It's not a helpful metric, as GitHub does other weird things. For example, when someone forks on GitHub then the relationship between the two repositories is not indicated in the repository itself, but rather in other metadata. Another problem is that if the point of coordination between a repository on GitHub and elsewhere is not on GitHub, you won't actually have the information that the other is upstream. Even if we were to limit ourselves to relatively recently active repositories, you'd still have these other issues.
Your metric doesn't capture quite what you think it does and so is highly misleading.
-
@blakeyrat said in Git's getting in my way again:
"we"? You're on the Git team?
We as a society, not we as in me and my buddies the git developers. I've never even seen git's code.
-
@blakeyrat said in Git's getting in my way again:
Imagine how much less annoyed everybody would have been if you had put information critical to understanding your post inside the post itself.
It's not even the relevant information. The revelant information would be how long had passed since the last fetch or pull, not the checkout.
TRWTF is @masonwheeler doesn't understand how git works. More due to the latter than the former, no doubt.
-
@zecc said in Git's getting in my way again:
TRWTF is @masonwheeler doesn't understand how git works.
Does anybody?
-
@masonwheeler said in Git's getting in my way again:
Does anybody?
And yet, the mass migration to Git from well understood and appropriate alternatives continues.....
-
@lb_ said in Git's getting in my way again:
Because git caches remote branch pointers locally, and you can pull from those local caches without an internet connection.
It doesn't, really. It creates local branches named after the names of remotes and remote branches. And it makes it easy to synch them . But they're still local branches.
Btw, it's possible I've been
d, but I can't minimize my post to keep reading on mobile, and I don't want to have to scroll back. Screw you, NodeBB. I want my red boob.
-
@masonwheeler said in Git's getting in my way again:
@raceprouk said in Git's getting in my way again:
@masonwheeler said in Git's getting in my way again:
FTFY, because 99.99% of software projects are centralized.
That might have been true in 1982, but nowadays, not so much.
How many projects have you worked on where you pushed to something other than the central repo?
Most projects I've worked on
I'm working on a feature branch. I fetch from origin. I see new commits on the master branch. I want to fast forward my local master to origin/master, but I don't want to switch branch/merge/switch back, so I do
git push . origin/master:master
-
@masonwheeler said in Git's getting in my way again:
@zecc said in Git's getting in my way again:
TRWTF is @masonwheeler doesn't understand how git works.
Does anybody?
I know how the underlying model works. If someone starts blathering about content-addressible manifest synchronisation in a high-dimensional distributed manifold, they're probably telling you the real truth. You probably won't understand the explanation; the underlying model is very sophisticated and not at all obvious at initial inspection.
The git source code itself? Never seen it, and really never want to. My mind-control worms value their sanity.
-
@cark said in Git's getting in my way again:
@masonwheeler said in Git's getting in my way again:
@raceprouk said in Git's getting in my way again:
@masonwheeler said in Git's getting in my way again:
FTFY, because 99.99% of software projects are centralized.
That might have been true in 1982, but nowadays, not so much.
How many projects have you worked on where you pushed to something other than the central repo?
Most projects I've worked on
I'm working on a feature branch. I fetch from origin. I see new commits on the master branch. I want to fast forward my local master to origin/master, but I don't want to switch branch/merge/switch back, so I do
git push . origin/master:masterThose sound like the same repro that you are fetching from and pushing (possibly with PR) to.... That is not what I am talking about...
Instead consider a dozen companies, which each have remotes for different distributions of a common base. Company 1 may typically interact with Association A, but also fetch selected commits from Association B or submit a PR to Association B. Company 2 does similar but with a different percentage of interactions with each of the associations...
Now from here there are many different firms who customize one or more of the companies Distributions [1,2,....] as well as submit PR's directly to one or more associations [A,B,...]. When there is cooperation between these firms, there may also be exchanges directly between the firms without impacting a primary company or an association..
THAT is an example of a distributed development environment...
-
@timebandit said in Git's getting in my way again:
@thecpuwizard said in Git's getting in my way again:
Yup, "checkout" is a local only operation, does not look at the actual remote....
Exactly. Some people don't understand what Distributed means
But "origin/branch" is what you call remote stuff. The message isn't being clear by specifying whether you're up to date with the local or remote version.
-
@blakeyrat said in Git's getting in my way again:
I know you guys all think I'm a retard, but I know how CLIs work at a fundamental level. Until you type something new in, they just sit there doing nothing for hours or days.
Yes, you're being a retard. This is one of those, "When you hear hoofbeats, think of horses not zebras," kind of moments.
-
@heterodox said in Git's getting in my way again:
@thecpuwizard said in Git's getting in my way again:
But it is not purporting to do ANYTHING related to the remote. It is saying that the working folder matches the HEAD in the locally cached repository........
It doesn't say that at all, and since it names the remote in the message even, it's understandable that an end user would think the remote was contacted for status.
Also, it really means your working copy (or whatever git calls that) is now the HEAD of the 'develop' branch. Saying "Your branch" is very misleading here, because that doesn't mean shit as for what you have checked out into your working copy.
-
@boomzilla said in Git's getting in my way again:
But "origin/branch" is what you call remote stuff.
No, it is not what I (or others) call "remote stuff".... Perhaps part of the issue is that you are going so... Consider...
[code]
git remote -v
bakkdoor https://github.com/bakkdoor/grit (fetch)
bakkdoor https://github.com/bakkdoor/grit (push)
cho45 https://github.com/cho45/grit (fetch)
cho45 https://github.com/cho45/grit (push)
defunkt https://github.com/defunkt/grit (fetch)
defunkt https://github.com/defunkt/grit (push)
koke git://github.com/koke/grit.git (fetch)
koke git://github.com/koke/grit.git (push)
origin git@github.com:mojombo/grit.git (fetch)
origin git@github.com:mojombo/grit.git (push)
[/code]Multiple remotes [5 of them - an indication that distribution is being done ;) ]
Each one of them has a local copy [which is updated by a FETCH]. Thus you have a LOCAL item of the same name.
When you CHECKOUT you are simply switching your working copy to match the named LOCAL copy.
-
@thecpuwizard said in Git's getting in my way again:
No, it is not what I (or others) call "remote stuff".... Perhaps part of the issue is that you are going so... Consider...
It looks to me like your examples are agreeing with me. See, right at the bottom of the remote list is
origin.@thecpuwizard said in Git's getting in my way again:
When you CHECKOUT you are simply switching your working copy to match the named LOCAL copy.
Yes, I get this. I'm just saying that this is not what the git message says.
Also, you can use use three backticks : ``` instead of bbcode code tags.
-
@boomzilla said in Git's getting in my way again:
It looks to me like your examples are agreeing with me. See, right at the bottom of the remote list is origin.
Aside from implicit/default implications, there is no difference between backdoor, cho45, defunct, koke, or origin....each is just shorthand. In fact you can change the names with git remote set-url NAME URL at any time
Yes, I get this. I'm just saying that this is not what the git message says.
But it is....albeit not with every word explicit (i.e. it requires understanding)
Your branch that is currently selected into the working folder is up-to-date with the local branch with the shortname name of 'origin/develop'.
That seems a little verbose, once one has a solid understanding.
Also, you can use use three backticks : ``` instead of bbcode code tags.
Thanks... I rarely use markup here beyond clicking the icons at the top :)
-
@thecpuwizard said in Git's getting in my way again:
Aside from implicit/default implications, there is no difference between backdoor, cho45, defunct, koke, or origin....each is just shorthand. In fact you can change the names with git remote set-url NAME URL at any time
Right. But the point there is that the names refer to those remote things.
@thecpuwizard said in Git's getting in my way again:
Your branch that is currently selected into the working folder is up-to-date with the local branch with the shortname name of 'origin/develop'.
No, again, you're confusing branch with working copy. A branch is stuff in a repo. It's most definitely not a working copy. This git message is making less and less sense the more I think about it.
@thecpuwizard said in Git's getting in my way again:
That seems a little verbose, once one has a solid understanding.
No, it's flat out wrong and misleading. A correct message would be:
Your working copy is currently up to date with the HEAD of branch develop.
-
@boomzilla - My last post along these lines....
Your local clone IS a Repository (almost certainly implemented as a hidden .git folder). The contents of these items are named. There is nothing "remote" involved directly here.
The "working folder"/"working copy" is the content that is visible and (almost certainly) rooted at the same directory that contains the hidden .git folder [Repository].
The message(s) from local commands (such as checkout) are referring to the relationship between these local items.
It is only when a command related to remote operations (such as fetch) are used that the name of the item is resolved to a URL and the activity involves something that is remote.
Have a great weekend (at least what is left of it)....
