Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git is too hard

changelog.com

Post reply on HN
Print view View original

791–800 of 821 posts

Re: Git is too hard

#791

Post by magicalhippo »

yencabulator wrote: post #734
magicalhippo wrote: post #336

Earlier quoted context omitted.

> porcelain without it encourage overly large commits? Not for me. When using Mercurial back in the day I would manually split up commit, usually by copying over sets of files into a clean repo and committing there. In Git tho the staging area is a lie. It encourages you commit half-truths. What I'd really want is to be able to enter a commit mode where the on-disk and staging area roles are flipped. I want the stuff…

> In Git tho the staging area is a lie. It encourages you commit half-truths. What I'd really want is to be able to enter a commit mode where the on-disk and staging area roles are flipped. https://github.com/tv42/staged does something like that by writing the staged content to a temp dir. (It has some smarts for Go GOPATH adjusting on top, but might not do things right with modules, at this time.)

Thinking about it, I guess it should be possible to flip this around by using a temporary local branch. Commit everything there, then cherry-pick into repo dir and commit proper.

Once done delete temp branch and push.

Re: Git is too hard

#792

Post by madhadron »

rwallace wrote: post #756
madhadron wrote: post #544

Earlier quoted context omitted.

> And yet, command shells are pretty good software. This is a contentious statement. Fred Brooks himself calls the separate command language, which began with JCL on OS/360, a mistake.

Now that is interesting! Do you remember where he said this?

In this interview at least: https://cacm.acm.org/magazines/2015/11/193333-an-interview-w...

Re: Git is too hard

#793

Post by ajuc »

jobigoud wrote: post #778
ajuc wrote: post #86

Earlier quoted context omitted.

The underyling concepts are fine, the problem with git for me is the inconsistent command line interface. Stuff I'm doing less often than once a month I have to check in the manual every time. And it's nothing inherently hard - stuff like removing one change from staging or cleaning up local branch to be exactly like remote. The interface just feels like stuff is arbitrarily assigned to different commands :)

> stuff like removing one change from staging I click on the file and click on "unstage". I don't know why people insist on using the command line for their dvcs. Is it even possible to selectively unstage or reset only a part of a file without a GUI?

> I don't know why people insist on using the command line for their dvcs.

I use both. More complicated stuff I usually do from the command line because I do them rarely enough, and I change IDEs often enough - that I just don't know how to do them in IDEs.

I used git regularly for last 6 years and in that time I've been using eclipse, netbeans, kdevelop, qtcreator, visual studio and intelliJ. And a few fringe IDEs as one-offs. I would have to remember 7 different paths in nested context menus for everything. I believe it's not "unstage" but "rollback" in IntelliJ, but I would have to check that in documentation before I do it anyway.

> Is it even possible to selectively unstage or reset only a part of a file without a GUI?

Sure - it's even faster than in gui, because you do it with keyboard only. I just can't remember the exact options.

Re: Git is too hard

#794

Post by Supermancho »

jamienicol wrote: post #541
recursive wrote: post #462

Earlier quoted context omitted.

I believe I've really only needed to do that once. git bisect handled it in about 10 minutes IIRC. It's hard for me to imagine how I could achieve a net time savings against that level of commit-hunting.

I envy you then. I spend a great deal of time looking through history to find bugs. An unclean history is less likely to work well with bisect too, as the individual commits may be broken.

> I spend a great deal of time looking through history to find bugs.

You mean when where and how a change was introduced? I dont think bugs are located in the history, since bugs are operational failures on a deployed branch.

Re: Git is too hard

#795

Post by horsawlarway »

eiz wrote: post #762
horsawlarway wrote: post #739

Earlier quoted context omitted.

I have no problem with using Slack or Hangouts or Discord or some other chat solution while at work. I also tend to use discord/steam for throw-away conversation with friends. At no point did I appeal to authority or history in my argument above, so drop the shit around > "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices." --- If you think Chat apps are winning, let me know when…

> If you think Chat apps are winning, let me know when you can buy an item online without an account linked to an Email. I'd love to see an example. https://www.amazon.com/gp/help/customer/display.html?nodeId=...

Sure, but it's limited to mobile numbers where an sms provides the same value as a proof of record. That's why it's limited to mobile phones.

And SMS operates with the same functional principle as email - I own the text after receiving it, and can use it as needed.

Re: Git is too hard

#796

Post by horsawlarway »

rakoo wrote: post #771
horsawlarway wrote: post #739

Earlier quoted context omitted.

I have no problem with using Slack or Hangouts or Discord or some other chat solution while at work. I also tend to use discord/steam for throw-away conversation with friends. At no point did I appeal to authority or history in my argument above, so drop the shit around > "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices." --- If you think Chat apps are winning, let me know when…

> If you think Chat apps are winning, let me know when you can buy an item online without an account linked to an Email. I'd love to see an example. You can do pretty much anything you want in WeChat, and you don't need an email.

Ok, this one is entirely fair, but also I'd argue the circumstances around it are a little different.

Given how tightly integrated wechat is with the chinese government, and the restriction of wechat pay to use with folks who have a Chinese/Hong Kong bank account, we're talking about different levels of utility around preserving the record.

If the government chooses not to honor your transaction record, it doesn't really matter if you have a copy yourself.

Re: Git is too hard

#798

Post by horsawlarway »

wpietri wrote: post #758
horsawlarway wrote: post #739

Earlier quoted context omitted.

I have no problem with using Slack or Hangouts or Discord or some other chat solution while at work. I also tend to use discord/steam for throw-away conversation with friends. At no point did I appeal to authority or history in my argument above, so drop the shit around > "Lo it was handed down to us by Postel the Wise, and none shall tamper with His choices." --- If you think Chat apps are winning, let me know when…

> drop the shit around You jumped into a discussion. The person I replied to was treating the email we happen to have as some sort of unchangeable given. That's what I am objecting to. If you are disavowing that side of his argument, feel free to say so, but it looks to me like you lean pretty heavily on it. > let me know when you can buy an item online without an account linked to an Email. I'd love to see an exampl…

> It's not a replacement, it's a complement

> [Chat apps] can work great in a well structured environment

> Use each as needed

> I also tend to use discord/steam for throw-away conversation with friends

Yes, clearly I'm only advocating for the use of email in its current form for all communication, see me lean so hard above?

---

Wechat might as well be the Chinese government, and it requires a Chinese/Hong Kong bank account to use Wechat Pay. If the government won't honor your transaction record, keeping a copy yourself isn't very useful...

Re: Git is too hard

#799

Post by MaxBarraclough »

yencabulator wrote: post #728
MaxBarraclough wrote: post #694

Earlier quoted context omitted.

> "automatic GC" which combines these "loose objects" into a "pack file"; and within that "pack file", it uses a binary diff (a xdelta) between similar objects to reduce the total size Isn't it the case then that git doesn't store in full every version of a tracked file?

Deduplication and compression do not imply diffs.

git does perform delta compression. From what I can gather, git's storage engine uses conventional compression (zlib), deduplication (exactly identical files need not be stored twice) and delta compression (between similar files).

The question was does git's implementation store - in full - every version of a tracked file? The answer is that it doesn't. git has a sophisticated storage engine precisely to avoid the inefficiencies of the naive approach.

Re: Git is too hard

#800

Post by jamienicol »

Supermancho wrote: post #794
jamienicol wrote: post #541

Earlier quoted context omitted.

I envy you then. I spend a great deal of time looking through history to find bugs. An unclean history is less likely to work well with bisect too, as the individual commits may be broken.

> I spend a great deal of time looking through history to find bugs. You mean when where and how a change was introduced? I dont think bugs are located in the history, since bugs are operational failures on a deployed branch.

Yes, I phrased that badly. Let's say looking through history to understand the context of when bugs were introduced and how to fix them
Post reply on HN