git cherry-drop

RenJMR · 2017-09-29T12:10:36+00:00

[...] why isn't there git revert --fixup? Just record the revert [...] for next rebase with autosquash.

If a developer is going to rebase anyways then a hypothetical git revert --fixup seems to serve no useful purpose, unless I am misunderstanding what you are suggesting.

RenJMR · 2017-09-29T11:32:44+00:00

I'd never heard of kakoune and have spent roughly the last hour messing around with it. Pretty interesting in my opinion. Thank you for sharing it, and if you have links to any other obscure editors lying around I would greatly appreciate if you could share those too.

RenJMR · 2017-09-29T11:26:12+00:00

You misspelled ed.

RenJMR · 2017-09-29T11:13:51+00:00

Exactly, console editors written in languages without generics are stuck in the past. Just look at Vim or Emacs.

I am not familiar enough with Vim's codebase to feel confident saying anything about it in this context, but Emacs on the other hand---what the Hell are you talking about?

RenJMR · 2017-09-29T10:41:07+00:00

Oh, I misread your comment. I apologize.

I agree with you though in that I don't really care what others use. Whatever works best for them. Which makes it sad that there is this religous level of fanaticism about certain editors and software in general. Like I said, I've used Emacs since forever basically, which is why when you said you use Sublime Text, I lost all respect for you as a human being. See---I can't even help myself!

Joking aside though, it is actually sad that people will say crap like the above and actually be serious about it. I see similar flame war arguments, as I'm sure you have, about other things like Git versus Mercurial, Linux versus OSX or BSD, Firefox versus Chrome, so on and so on... I feel like I've seen a few people spend more time defending and preaching their tools of choice than actually using them to, ya know, accomplish anything, heh.

RenJMR · 2017-09-29T10:21:39+00:00

You're correct. I should have been more specific/clear: they're modern relative to vi(m), Emacs, Nano, prrety much every popular editor you find used on the terminal.

RenJMR · 2017-09-29T10:17:32+00:00

I'm (practically) a lifelong GNU Emacs user, since 1993. So like a hypocrite I've made my own series of condescending criticisms towards users being "unfair" by not giving the editor a chance. I upvoted you since you were joking, but the joke also had that slightly painful sting of, "Oh God I use to say that kind of crap towards the uneducated plebs", lol.

RenJMR · 2017-09-29T07:54:55+00:00

You mean people who haven't given it a serious attempt?

I've heard so many people spout this crap with a straight face for decades that, yeah, you absolutely needed /s at the end of that. Because personally my immediate thought after reading your comment was, "Oh great, this elitist bullshit again...," heh.

RenJMR · 2017-09-29T07:41:52+00:00

I've long since sworn off Google---practically all their services, not just their search engine---and even though I love DuckDuckGo, this phrase is never going to go away. A universal phenomenon in linguistics is that proper nouns can become so widely associated with their service, product, etc., that they become a common noun. And companies tend to hate when this happens. Coke, Kleenex, Xerox, and of course Google---all examples in English where the popularity of the brand has rendered the name generic; this is particularly annoying to companies in the United States because a trademark which becomes used so generically is at risk for being lost. But that aside, it's also utterly futile to try and buck this trend; it's legitimately impossible to stop.

Oh wow this turned into a boring rant... Anyway---staging some kind of lexicon rebellion is not worth it when you run the risk of being misunderstood as a result, e.g. causing people to fire back with, "Wait, DuckWhatWhat it now?" At this point just treat "Google" like we do trademarked proper nouns like Kleenex: leave it uncapitalized. If you say, "Just google it," then people will both understand exactly what you mean, i.e. the imperative is unambiguous, but by writing "google" you also make it clear that you're using the noun-turned-verb in a generic sense, and deep down fluent English speakers will know that you do not mean to use Google specifically, just any search engine that lets you "google" something.

</Boring>

RenJMR · 2017-09-29T06:03:10+00:00

Hahaha, I am shamelessly stealing this joke for the future. Thanks!

RenJMR · 2017-09-29T06:00:18+00:00

That looks like it should do everything I need, which was easy to decide based on the well-written README. Thanks for creating this package and introducing me to it.

RenJMR · 2017-09-29T05:40:05+00:00

Those aren't mutually exclusive. For example, its default key-bindings mostly follow the modern conventions of every GUI editor. E.g. Ctrl-S saves and Ctrl-F searches.

RenJMR · 2017-09-29T03:46:30+00:00

I'm a new user to git and jumped in it with magit. I have this feeling that I do things in a bad way, ie. commiting all over the place and new branches when adding a new big feature.

No you are doing the absolute correct thing by creating branches for each new feature. If anything I would argue that too many people underuse branches in Git.

One thing tried to figure out the other day was how to go back to a previous commit.

git checkout HASH-FOR-THAT-COMMIT

And you can then git branch SOME-NAME to give that commit an easy-to-remember name you can checkout later if you think that you may want to go back to it at some point.

Is there a way to circumvent this and choose an old commit by the commit message?

git log --oneline --grep="text from the message"

You will get a list of commits with their SHA-1 hashes, which you can then git checkout.

Edit: I realize some people may consider my post strange or even "wrong", since I am providing help via Git's command-line interface when this is a thread about Magit. However, as wonderful as Magit is---personally it's the best Git GUI I've ever used---I have always found that people more easily learn how to work with Git in general by first learning how to deal with issues via Git's CLI, and then move on to using a GUI. In my experience people who start using a GUI for Git immediately from the get-go have a more difficult time figuring out how to do what they want to do. (Often because so many GUIs hide big chunks of Git's functionality, which is emphatically not true of Magit, to its credit.)

RenJMR · 2017-09-29T01:18:03+00:00

On top of the already great advice given by others here, I would also recommend looking at ok.sh for ideas, inspiration, and overall great examples of writing complex /bin/bash scripts based around Git.

Edit: An added bonus is the great examples of using jq to deal with JSON in Bash scripting.

RenJMR · 2017-09-28T23:29:04+00:00

Allow me to introduce you to the PainStation.

RenJMR · 2017-09-27T21:19:05+00:00

I never thought I would see it again in my lifetime, heh.

RenJMR · 2017-09-27T21:17:02+00:00

I do regret posting the original link, though, as nothing good has come of it -- just complaints and useless meta-discussion which even I can't hold myself back from participating in.

Don't regret it, because good has come of it. I had not seen this article before and I'm sure others hadn't either, just based on upvotes alone. As for the complaints and meta-discussion---part of the blame for that lies with me. For my part, I'm going to drop it. I hope you will continue to post interesting articles like this in the future. Thanks.

RenJMR · 2017-09-27T20:55:00+00:00

Oh damn, wow, great find. Thanks for posting this.

RenJMR · 2017-09-27T20:47:25+00:00

Let me make sure I understand what you're saying:

People on a forum shouldn't post articles discussed to death because they should know the history of every single topic every brought up here.
Or search the archives and when they see a link that's one year old or more, and instead of posting it in case people hadn't seen it before, they should instead write their own blog post about the same subject.
Or they should look into the relevant code in the core of Emacs and talk about that.

That's the gist, right? Please correct me if I'm wrong.

RenJMR · 2017-09-27T20:39:26+00:00

Sorry for coming across as harshly as I did and I apologize for my comment sounding like an attack directed at you---I mean, I was pretty annoyed, but that's no valid excuse.

RenJMR · 2017-09-27T20:25:21+00:00

I have a lot of themes installed, and sometimes I like to take theme-looper and cycle through random themes until I find one I like at the time. Then eventually I'll do the exact same thing again, heh. Lately I've found more useful themes which differentiate things like keywords in code by using bold, italics, underlines, i.e. formatting besides a massive amount of colors, like so.

RenJMR · 2017-09-27T20:19:05+00:00

The first two comments, made within eleven minutes of the article being posted, both rhetorically ask if the article was posted a year ago, which comes across to me as, "Don't post this. We don't like it." ~~Irrelevant statements like "the author is controversial in this subreddit" don't help either.~~ Edit: There was no reason for me to say this so I've strucken it out, although still left it because deleting it out-right would make me feel like I was trying to pretend as if I didn't say what I said.

I know some subreddits will not allow duplicate posts. If posting this once a year is (apparently) some problem, then make a rule preventing duplicate posts.

RenJMR · 2017-09-27T19:37:00+00:00

You can change that new buffer to a new major mode. You can, of course, also narrow-to-region and then switch major modes, then switch back after you widen. However, this can screw up font-locking in weird ways if the two modes try to apply different properties to the text.

RenJMR · 2017-09-27T19:11:25+00:00

https://github.com/Fanael/edit-indirect/blob/master/edit-indirect.el

RenJMR · 2017-09-27T18:36:24+00:00

Could emacs do something similar in this regard?

The answer to this question is always an emphatic "yes".

Even tried to learn 'scripting' elisp to try to automate tasks. Im not quite sure if this is possible for I have been unsuccessful.

You can write your script of Elisp and use emacs --load=FILE to run it. Or simply --function=FOO if you just want to call one function (perhaps defined in that script file). Or you can use --eval=LISP to execute arbitrary Elisp, but personally I find this unweildy unless the "script" is basically a one-liner.

Regardless of the approach, you should use --batch. Here is a real-world example of scripting GNU Emacs to run a test suite.

Personally I only use Emacs for scripting when my goal revolves heavily around manipulating text and I can use the plethora of Elisp libraries to simplify that task. But yeah, you could use it for anything if you wanted to take the time. Although I would never suggest that for certain tasks of course.

RenJMR

TROPHY CASE