9 ms·

I think there are some legitimate criticisms of Git here. But some of them are...odd. Despite using Git in a variety of circumstances, from a local personal rep

by NBJack 3y ago

I think there are some legitimate criticisms of Git here. But some of them are...odd. Despite using Git in a variety of circumstances, from a local personal repo project to very large company repos, I admit I haven't run into about half of these issues. > The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at all on mobile. I hope my team never has to consider their mobile device as a way to check the status of a branch. It hasn't even crossed my mind as a use case. Does this come up often for others?

mintplant 3y ago
All the time. I would say at least 50% of my code browsing is done from my phone. I make heavy use of the mobile GitHub web interface for this (find-references support has been a godsend, search is still meh, I hate how they keep breaking basic find-in-page with SPA jank). Also Searchfox [0] when I need to comb through Firefox code (fast, excellent, no complaints—well, I guess blame on mobile could be better). Context: grad student, programming languages and systems research plus a bunch of IoT hacking on my own time. Either elder Gen Z or youngest possible Millennial, depending where you put the cutoff. [0] https://searchfox.org https://searchfox.org
- inferiorhuman 3y ago
  Yeah, I can't say enough bad things about the Github refresh. The whole thing feels like it was done by people who've never used git (or any SCM) before. It's not just the find-in-page, it's the navigating branches, text selection, keyboard navigation within a page, and general rendering performance that have taken a huge hit. And, of course, all the side effects of requiring javascript to render text.
- FpUser 3y ago
  Can't imagine reading code on those tiny screens.
  - jpc0 3y ago
    And this is why you should stick to an 80 column limit. It's only a pain when you decide your codebase is fine with 120+ columns because "everyone has a widescreen monitor" except no they don't. What if I like vertical monitors, or want 5:4 etc.
    - maccard 3y ago
      Having to cater to the absolute lowest common denominator holds back progress. Why should I be forced to adapt your preferred workflow and limitations if I prefer to have a wide-screen monitor or another standard tool.
      - estebank 3y ago
        Without implying whether one position or the other is stronger, I want to point out that even when you're on a wide screen it's not uncommon to take advantage of that and have at least two screens side by side.
      - jpc0 3y ago
        > Having to cater to the absolute lowest common denominator holds back progress. Market decided wide screen is better on pc, you blindly followed. Market decided that isn't the case on any mobile platform which in case you missed it vastly out numbers pc. There was never an argument about whether wide screen is better or not, only that larger column counts make it harder to read your code. Using obscure single letter variable names also make your code harder to read, is using decent variable names catering to thw lowest common denominator as well, is that a bad thing? Are we holding back progress because we use descriptive names for things? Make your case about column width, there are valid arguments for longer widths. "Because wide screen is better" isn't one I will accept, last I check no other written media prefers being printed in landscape.
    - FpUser 3y ago
      You are assuming too much about me without having a single clue. >"What if I like vertical monitors, or want 5:4 etc." Your choice. Mine - not to work on cell phone. This might change if they will stop crippling smartphones and let it to be hooked to a decent monitors / (future high quality display glasses)
- School-Cotton 3y ago
  Why are you so often in situations where you want to browse code but don’t have access to a general-purpose computer?
  - brigandish 3y ago
    I do it when I want to separate out the thinking/understanding from the doing. I might want to mull over how to do something instead of jumping straight into coding, and I find train journeys an excellent opportunity for this. Or sometimes I want to assess dependencies, perhaps I want to choose a library for doing X, I can sit and read through them on my phone and at least get a feel for them and whittle the list down.
    - iFreilicht 3y ago
      Oh that's a good way to put it! I do this as well, especially on commutes or on walks, but sometimes on the couch as well; I have an idea and think about it actively, but to continue my thought process, I have to look at some code, so I open it on the phone. It always felt weird to get my laptop and look on the "big" screen in those situations, and maybe it's because I just want to think, not to code.
  - tehbeard 3y ago
    I've looked at libraries on github during the commute from links in newsletters. But never done any serious work off a phone, bar irl device testing for "hand feel" of the UI/UX
xrd 3y ago
Well, I'm using git to manage my blog. I wrote an Android editor to edit on GitHub and then modified it to work on gitlab. There are lots of reasons but mostly it is because git is impossible to use on mobile, regardless of whether you are using GitHub or gitlab. Checking status is possible but barely anything beyond that. This write-up really resonated with me in other ways. I wrote a book for O'Reilly about GitHub and still can't wrap my head around git after more than ten years of using it. The points made here resonate with me.
- 8organicbits 3y ago
  I wonder how far you could get with the git client in termux. I got vim running at one point. [1] https://termux.dev/ https://termux.dev/ [2] https://packages.termux.dev/apt/termux-main/pool/main/g/git/ https://packages.termux.dev/apt/termux-main/pool/main/g/git/
  - herewulf 3y ago
    I use git in Termux all the time. It's fine. You just enter commands like normal. I have no idea what the parent to your comment is on about, especially having "written a book".
8organicbits 3y ago
I've tried to extend my work day by checking on projects from the train. Absent spotty data coverage, I've found GitHub works fine and I can do light code reviews easily. GitHub pulse[1] is a great UI for looking at recent activity. This page is bare for the SQLite mirror because they don't work on GitHub so it only has commit history. The linked Caddy project is a better example. IMO it looks more useful than the timeline. I wonder if anyone's built the equivalent view for git/GitHub already. Shouldn't be too difficult. [1] https://github.com/caddyserver/caddy/pulse https://github.com/caddyserver/caddy/pulse
JoeyBananas 3y ago
There's no reason why that feature should not work on mobile. Certainly, it would work on mobile if it was designed/implemented better. People access github from mobile all the time for the same reasons they access it from any other platform. I've certainly done it. > I admit I haven't run into about half of these issues These observations about git are not necessarily "issues." They're more like "value judgements about features." You either agree or you don't, there's nothing to encounter.
Brian_K_White 3y ago
There are all kinds of non-optimal optional ways to do things where it's valuable to have the options and have them work as well as possible vs not having the option. I guess it falls under graceful degrade vs die. It doesn't matter how much better the proper gold plated option is. If it's the only option then it's fragile and that makes it garbage.
- maccard 3y ago
  I disagree. If the alternative is to force everyone to have a sub par experience, them I'd rather a single enforced standard that is usable.
  - Brian_K_White 3y ago
    There is no such dichotomy.
cryptonector 3y ago
> > The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at all on mobile. (The preceding text in TFA makes it clear that this refers to rendering a view of history. This is in a section titled "Git does not provide good situational awareness".) Here's the thing: if you use a rebase workflow then all history will be linear, and that requires nothing fancy for rendering, and it's fast. That's NOT the reason to want to use a rebase workflow, mind you. Fossil doesn't have rebase (though it has cherry-pick, which is the building block for rebase), and D. R. Hipp seems pretty proud of this. I understand his and many others' dislike of rebase, but I believe that dislike is founded on some confusion. I believe rebase workflows are -where they are possible- superior to merge workflows, and that linear history is superior to non-linear history. Let's start with linear history vs. non-linear history. Our brains are very linear, so I think that instantly makes linear history better. It's easy to see that history with lots of branches and merges is non-trivial to understand, and this is much more the case the larger the team of engineers and the larger the number of distinct branches (projects, bug fixes) involved. For example, at Sun Microsystems, Inc. (RIP) we had over 2,000 engineers working on OS/Net, which is the core of the Solaris and Illumos operating systems. At Sun we had a strict linear history mandate, which meant we were using a rebase workflow long long before Git came along. If we had not had that mandate then OS/Net's history would have been incredibly difficult to visualize since one would need a display that could fit hundreds if not more parallel branches. If you actually want to visualize history, then merge workflows just won't scale with project complexity. One might object that, well, for such projects as OS/Net one just wouldn't even attempt to visualize history like that, that one would filter branches of interest and so on. But this comes for free with linear history as with linear history there is no need to attempt to filter what branches get rendered because there is only one branch at all times. If you care about history, what you really want is to see what's changed over time, and that is always linear. At time t_n you have some commit, and at t_n+1 you have some other commit, and so on. That some are merge commits only obscures the fact that if you're spelunking through history (e.g., bisecting), the history is just linear. All those merge commits do is act as something like text folds in editors, hiding away some sub-history, but if you're looking through it then you really do care about the details and you don't want that history hidden. On the other hand, if you're not browsing through the history, then you don't care if there's merge commits or not. So you should just not care for merge commits at all. Linear history is just easier to understand. Yes, you want to squash unnecessary commits before pushing to avoid cluttering history with noise -- no one cares about what typos and brainos you made while writing some bugfix or feature commits, and certainly no one will years after you push. Because rebase workflows lead to linear history, and linear history is better than non-linear history, rebase workflows are better than merge workflows. But also it's just easier to understand rebasing than merging once you understand cherry-picking. At least for me it is. But I think it should be easier for more people too, if only it rebase were explained that way and explained before merges. Besides, if you have N commits in a branch and you merge it into another, when you resolve conflicts you won't know which conflicts and resolutions go with which of those N commits, and you won't care, but if you want to understand your work -and also others to understand your work- it seems much better to rebase and resolve conflicts commit by commit. Getting back to "situational awareness", linear history gives you just that. It's merge workflows that make it hard to be aware of all the recent changes.

by NBJack 3y ago

mintplant 3y ago

All the time. I would say at least 50% of my code browsing is done from my phone. I make heavy use of the mobile GitHub web interface for this (find-references support has been a godsend, search is still meh, I hate how they keep breaking basic find-in-page with SPA jank). Also Searchfox [0] when I need to comb through Firefox code (fast, excellent, no complaints—well, I guess blame on mobile could be better). Context: grad student, programming languages and systems research plus a bunch of IoT hacking on my own time. Either elder Gen Z or youngest possible Millennial, depending where you put the cutoff. [0] https://searchfox.org https://searchfox.org

inferiorhuman 3y ago
Yeah, I can't say enough bad things about the Github refresh. The whole thing feels like it was done by people who've never used git (or any SCM) before. It's not just the find-in-page, it's the navigating branches, text selection, keyboard navigation within a page, and general rendering performance that have taken a huge hit. And, of course, all the side effects of requiring javascript to render text.
FpUser 3y ago
Can't imagine reading code on those tiny screens.
- jpc0 3y ago
  And this is why you should stick to an 80 column limit. It's only a pain when you decide your codebase is fine with 120+ columns because "everyone has a widescreen monitor" except no they don't. What if I like vertical monitors, or want 5:4 etc.
  - maccard 3y ago
    Having to cater to the absolute lowest common denominator holds back progress. Why should I be forced to adapt your preferred workflow and limitations if I prefer to have a wide-screen monitor or another standard tool.
    - estebank 3y ago
      Without implying whether one position or the other is stronger, I want to point out that even when you're on a wide screen it's not uncommon to take advantage of that and have at least two screens side by side.
    - jpc0 3y ago
      > Having to cater to the absolute lowest common denominator holds back progress. Market decided wide screen is better on pc, you blindly followed. Market decided that isn't the case on any mobile platform which in case you missed it vastly out numbers pc. There was never an argument about whether wide screen is better or not, only that larger column counts make it harder to read your code. Using obscure single letter variable names also make your code harder to read, is using decent variable names catering to thw lowest common denominator as well, is that a bad thing? Are we holding back progress because we use descriptive names for things? Make your case about column width, there are valid arguments for longer widths. "Because wide screen is better" isn't one I will accept, last I check no other written media prefers being printed in landscape.
  - FpUser 3y ago
    You are assuming too much about me without having a single clue. >"What if I like vertical monitors, or want 5:4 etc." Your choice. Mine - not to work on cell phone. This might change if they will stop crippling smartphones and let it to be hooked to a decent monitors / (future high quality display glasses)
School-Cotton 3y ago
Why are you so often in situations where you want to browse code but don’t have access to a general-purpose computer?
- brigandish 3y ago
  I do it when I want to separate out the thinking/understanding from the doing. I might want to mull over how to do something instead of jumping straight into coding, and I find train journeys an excellent opportunity for this. Or sometimes I want to assess dependencies, perhaps I want to choose a library for doing X, I can sit and read through them on my phone and at least get a feel for them and whittle the list down.
  - iFreilicht 3y ago
    Oh that's a good way to put it! I do this as well, especially on commutes or on walks, but sometimes on the couch as well; I have an idea and think about it actively, but to continue my thought process, I have to look at some code, so I open it on the phone. It always felt weird to get my laptop and look on the "big" screen in those situations, and maybe it's because I just want to think, not to code.
- tehbeard 3y ago
  I've looked at libraries on github during the commute from links in newsletters. But never done any serious work off a phone, bar irl device testing for "hand feel" of the UI/UX

xrd 3y ago

Well, I'm using git to manage my blog. I wrote an Android editor to edit on GitHub and then modified it to work on gitlab. There are lots of reasons but mostly it is because git is impossible to use on mobile, regardless of whether you are using GitHub or gitlab. Checking status is possible but barely anything beyond that. This write-up really resonated with me in other ways. I wrote a book for O'Reilly about GitHub and still can't wrap my head around git after more than ten years of using it. The points made here resonate with me.

8organicbits 3y ago
I wonder how far you could get with the git client in termux. I got vim running at one point. [1] https://termux.dev/ https://termux.dev/ [2] https://packages.termux.dev/apt/termux-main/pool/main/g/git/ https://packages.termux.dev/apt/termux-main/pool/main/g/git/
- herewulf 3y ago
  I use git in Termux all the time. It's fine. You just enter commands like normal. I have no idea what the parent to your comment is on about, especially having "written a book".

8organicbits 3y ago

I've tried to extend my work day by checking on projects from the train. Absent spotty data coverage, I've found GitHub works fine and I can do light code reviews easily. GitHub pulse[1] is a great UI for looking at recent activity. This page is bare for the SQLite mirror because they don't work on GitHub so it only has commit history. The linked Caddy project is a better example. IMO it looks more useful than the timeline. I wonder if anyone's built the equivalent view for git/GitHub already. Shouldn't be too difficult. [1] https://github.com/caddyserver/caddy/pulse https://github.com/caddyserver/caddy/pulse

JoeyBananas 3y ago

There's no reason why that feature should not work on mobile. Certainly, it would work on mobile if it was designed/implemented better. People access github from mobile all the time for the same reasons they access it from any other platform. I've certainly done it. > I admit I haven't run into about half of these issues These observations about git are not necessarily "issues." They're more like "value judgements about features." You either agree or you don't, there's nothing to encounter.

Brian_K_White 3y ago

There are all kinds of non-optimal optional ways to do things where it's valuable to have the options and have them work as well as possible vs not having the option. I guess it falls under graceful degrade vs die. It doesn't matter how much better the proper gold plated option is. If it's the only option then it's fragile and that makes it garbage.

maccard 3y ago
I disagree. If the alternative is to force everyone to have a sub par experience, them I'd rather a single enforced standard that is usable.
- Brian_K_White 3y ago
  There is no such dichotomy.

cryptonector 3y ago

> > The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at all on mobile. (The preceding text in TFA makes it clear that this refers to rendering a view of history. This is in a section titled "Git does not provide good situational awareness".) Here's the thing: if you use a rebase workflow then all history will be linear, and that requires nothing fancy for rendering, and it's fast. That's NOT the reason to want to use a rebase workflow, mind you. Fossil doesn't have rebase (though it has cherry-pick, which is the building block for rebase), and D. R. Hipp seems pretty proud of this. I understand his and many others' dislike of rebase, but I believe that dislike is founded on some confusion. I believe rebase workflows are -where they are possible- superior to merge workflows, and that linear history is superior to non-linear history. Let's start with linear history vs. non-linear history. Our brains are very linear, so I think that instantly makes linear history better. It's easy to see that history with lots of branches and merges is non-trivial to understand, and this is much more the case the larger the team of engineers and the larger the number of distinct branches (projects, bug fixes) involved. For example, at Sun Microsystems, Inc. (RIP) we had over 2,000 engineers working on OS/Net, which is the core of the Solaris and Illumos operating systems. At Sun we had a strict linear history mandate, which meant we were using a rebase workflow long long before Git came along. If we had not had that mandate then OS/Net's history would have been incredibly difficult to visualize since one would need a display that could fit hundreds if not more parallel branches. If you actually want to visualize history, then merge workflows just won't scale with project complexity. One might object that, well, for such projects as OS/Net one just wouldn't even attempt to visualize history like that, that one would filter branches of interest and so on. But this comes for free with linear history as with linear history there is no need to attempt to filter what branches get rendered because there is only one branch at all times. If you care about history, what you really want is to see what's changed over time, and that is always linear. At time t_n you have some commit, and at t_n+1 you have some other commit, and so on. That some are merge commits only obscures the fact that if you're spelunking through history (e.g., bisecting), the history is just linear. All those merge commits do is act as something like text folds in editors, hiding away some sub-history, but if you're looking through it then you really do care about the details and you don't want that history hidden. On the other hand, if you're not browsing through the history, then you don't care if there's merge commits or not. So you should just not care for merge commits at all. Linear history is just easier to understand. Yes, you want to squash unnecessary commits before pushing to avoid cluttering history with noise -- no one cares about what typos and brainos you made while writing some bugfix or feature commits, and certainly no one will years after you push. Because rebase workflows lead to linear history, and linear history is better than non-linear history, rebase workflows are better than merge workflows. But also it's just easier to understand rebasing than merging once you understand cherry-picking. At least for me it is. But I think it should be easier for more people too, if only it rebase were explained that way and explained before merges. Besides, if you have N commits in a branch and you merge it into another, when you resolve conflicts you won't know which conflicts and resolutions go with which of those N commits, and you won't care, but if you want to understand your work -and also others to understand your work- it seems much better to rebase and resolve conflicts commit by commit. Getting back to "situational awareness", linear history gives you just that. It's merge workflows that make it hard to be aware of all the recent changes.