ITT: Post your last git commit message

ITT: Post your last git commit message
I'll start!

Begin experiments with vehicle beam intersects

Other urls found in this thread:

github.com/rust-lang/rust/pull/31635
github.com/leni536/fast_hilbert_curve
twitter.com/NSFWRedditGif

Fix shit

Hello world!

Tweak fonts.

git did nothing wrong

how do i into git

Update deps

nigger

.postPlz doesn't really need to be dynamic

Not all my classes are that bad. Honest!

Initial commit with files

Make the device heirarchy parser more robust against odd device names.

The parser now collects a list of device IDs in one pass, and then gets the
other needed information (device names and properties) in a second pass.

Should hopefully fix issue #1. However, the ideal fix would be to use Xlib
directly using FFI.

>i18n: Add most messages + german translations

>using Xlib directly via FFI
p-please don't

Yeah, I'm dreading it.

Is there a better way of listing X display servers on your machine than /tmp/X11-unix?

I have a shell script that picks a display server by listing that directory, starting the test display server, listing it again, then using comm to find the new entry. It is painful to look at.

/tmp/X11-unix doesn't even exist on my machine.

Is the DISPLAY environment variable not available for you? Most GUI programs, if they can't read DISPLAY, will just give up. You can do that in your program too without feeling too guilty about it.

I dropped the dot, it is /tmp/.X11-unix

I'm working on a window manager, running it with xvfb-run (which unhelpfully does not print the display server) and connecting with x11vnc so I don't need to reboot or use a virtualization to test.

So DISPLAY will be set to my proper display. Ideally I'd have a way to get display server : PID pairs or something so I could detect the new display without worrying about a race.

/tmp/.X11-unix (note the dot) is *the* standard way of accessing an X server.

If you set DISPLAY=":1" or whatever then that will just tell Xlib to go look in /tmp/.X11-unix. But in principle, an X server could also be listening on a different location or on a TCP socket (instead of UNIX socket), as long as you adjust your DISPLAY to compensate.

You could also check the process list for Xorg processes, I guess.

Oh, I misread your question. I think you can specify what you want the display to be called when you invoke xinit, so it always has the same name.

You can specify the socket index to use as a command line parameter to Xvfb, so either run that yourself (i.e. recreate xvfb-run) or maybe use xvfb-run's -s arg

I didn't realize those were sockets! Thanks.

I should be able to use lsof, then. I'll try when I get home.

I had to do literally the same thing at my last job. What a grind.

Work:
Shove things around
Jot down some TODOs
Make logging available for DataProviders

Play:
Rudimentary implementation of X
Maybe fix X
Current status

>Version 1.03
I don't waste time putting every little fucking change into git because it's a waste of goddamn time. I do what I need and then commit a fucking version.

>See orphaned private repo I haven't touched in 2 years
>Check last commit
>"Shit, I'm at a dead-end"

time to rm -R I guess

Have fun bisecting when you need to figure out a regression.

It was easy here because my boss loves minimalism (i.e. laziness)

Git is for VERSION control, not I MADE 2 CHANGES TO A FILE control..

>Expecting a babby's first commit-style programmer to care about regressions, bugs or actually having users
>Expecting him to even have a bug tracker

Horrible idea. This completely breaks things like git revert, bisect, cherry-pick, and a good portion of what makes Git good with teams of people.

You might as well not use Git at all if that's how you use it.

>You might as well not use Git at all if that's how you use it.
Well, he already essentially isn't, so consider your request honored?

>Git good
This

fix

:^)

Somehow I don't feel any better about it.

>Removed all that fucking VBScript

Look on the bright side. In the past, beginning programmers at his stage of development would have released versioned .zip or .rar files via 1-click hosters instead

Compared to that, git commits are a pretty big step up

>change something
>commit that change
>oh it broke this
>change
>test
>fine
>broke something else
>have to endless loop while now the base fucking git is now broken for anyone that pulls it and would have to figure out at what point it wasn't broken
>"branch!"
>people actually work on branches and want it to be functional from a clean pull at the very fucking least
It's absolutely retarded to commit something until you're ready for it to work. This is what LOCAL STORAGE and LOCAL BACKUPS are for.

My god, today's idiots are so addicted to TEHCLOUD they even use it for development.

> What are topic branches
> What is rebase

You know you can have a strictly local branch that's completely invisible to the outside world until you push it, right?

Git commits aren't pushes, yo. Don't push broken code, but committing WIPs is fine.

Also, if you make small changes and something breaks, you can bisect a commit that works and after a few steps, see exactly the change the broke it.

You're talking about tags, my friend. As in "versioning a release". Marking a specific point in the commit history as something you consider stable.

Commits are file-based. And every change to that file is a new version of it, isn't it?

If your post is bait, then 7/10. If not, I strongly recommend reading up on the basics of version control, the problems it wants to solve, and how it intends to do that

Your greentext is a representation of your inability to use git effectively. Congratulations.

This is either some damn good bait or you really need to learn how Git works because this is stupid.

Yeah, it's called backup files/temp directories/etc. Learn to manage your own goddamn code without having to rely on some fucked up pile of shit bloated "version management" bullshit.

Or... just work on it until it works and upload all at once, LIKE I SAID. Seriously, common goddamn sense.

Your posts are a representation of your inability to use your own goddamn computer effectively and shows that you have accepted the bullshit TEHCLOUD mentality. Congratulations.

>Yeah, it's called backup files/temp directories/etc. Learn to manage your own goddamn code without having to rely on some fucked up pile of shit bloated "version management" bullshit.

git isn't the same thing as a git host, noob.

I have git repos with dozens of commits that aren't in the cloud at all. You can have an entire repo (or an entire branch) locally on your computer.

Are you for real? I hope for your own sake that your aren't.
Either way, this is hilarious.

But, just in case you are serious...the enxt time you are working on a nontrivial project, you should really genuinely try the "many small commits" thing you hate so much. I am not joking when I say it can genuinely increase your quality of life.

>"git blame" becomes useful if you ever wonder "Why was this written like this?"
>"git bisect" can tell you the commit of literally any problem, and if they are small, it is often very obvious why it broke, as well as the circumstances that led up to it
>"git cherry-pick" becomes an unholy-good tool if you ever have to share fixes between multiple branches. (It often requires no development, just a command and poof! Fixed!)
>Working with multiple people stops being a headache when merges don't conflict, and if they do, you don't have to merge 10,000 lines of independent changes.

Also, patches from third parties stop being so trivial when they are absorbed by your megacommits.

>replying to shitty bait

Version 1.5 - Linux/Windows - Check the CHANGELOG.txt for more informations!

If he's not going to use a proper VCS, he should at least use something like undotree + persistent history in vim.

Manually making backups all the time is literally retarded.

I use undotree+persistent undo, 15-minute regular filesystem snapshots, git commits which I push offsite for every change to to /etc or my dotfiles and quarterly backups into cold storage

You can never have enough data safety.

Btrfs? ZFS?

>You can never have enough data safety.
When your livelihood depends on it especially. Nobody important is going to hire the guy who destroyed his company with bad practices.

Rewrote POST/GET query parsing, added support for usernames and tripcodes

sigmoid L

He keeps killing me in Stone Soup.

>caring about data safety
>using btrfs

ZFS obviously

Update README.md

git is for SJWs and meme startups.
perforce is written by professionals and not a bunch of hobbyists.

Added to readme.

Merge branch 'develop'

>Created logo

Create CNAME

Literally this. Only fags code on their raspberry pi while drinking a bulletproof coffee and sharing their code on git while wearing an ironic T-shirt with their dyed hair and eye piercings.

Add git.

So meta.

Not a dev, just a sysadmin. Finally got around to adding the git source tarball and a spec file (for building RPMs) to a repo where I keep my shitty build scripts.

Add SRI to private pages

Date: Wed Jul 27 22:13:19 2016 +0200

Optimize for a theoretical post-shadow world

If shadow glyph gets removed or nerfed, this will still produce a reliable
shieldbearer setup, using blood glyph as a very weak replacement.

Also greatly improve the accuracy of some of the current estimations, after
extensive testing and fine-tuning of variables.

Date: Tue Jul 26 21:58:53 2016 +0200

Add income simulation

For experimenting with the optimal buy strategy

Date: Tue Jul 26 20:23:24 2016 +0200

2016-07-26

Date: Tue Jul 26 14:08:04 2016 +0200

An unreasonable amount of changes

Why is this even a git repo?

Date: Mon Jul 25 00:21:38 2016 +0200

Even more changes

Date: Sun Jul 24 16:25:22 2016 +0200

Lots of changes

Date: Sun Jul 24 10:05:55 2016 +0200

Add .gitignore

Date: Sun Jul 24 10:04:29 2016 +0200

Initial commit

Migrating from a simple post to a full git repository as the project
grew


r8 my commit messages Sup Forums

>git commit -m "akjdnakjndjaknjksndjkansd"

sorry...

git commit -m "akjdnakjndjaknjksndjkansd"

>Why is this even a git repo?
man I've had that in so many commits

I think you're thinking of Sigmund

[Code]Replaces all instances of "Linux" with "GNU/Linux"[/code]

This is me every other month on my SaltStack repo. You end up reimplementing shit over and over again as you learn the various systems.

Forgive my noobishness, but...

In situations like this, are you really supposed to commit to a branch as you go until finally merging it (resulting in a long series of commits during which LITERALLY EVERYTHING is broken and it is very possible that EVERY FILE is touched at some point), or do you get something that at least mostly works and then spend time at the end "fabricating" logical and mostly-atomic commits out of the diffs?

Usually I create my long string of incoherent commits, and then I use rebase to prune the commit history down to something more readable, where each commit is a single independent complete change that doesn't break anything.

Noted, thanks. Will look into those.

Luckily, I'm still the only one using my repos, so I can get away with stupid shit like this beauty I put together after some googling when I realized I had to get a directory of RPM packages and such (already over 1GB in files... plus the shit in .git) out of there:

#!/bin/sh
rm -rf "${1}"
git add "${1}"
git commit -m "${2}"
git filter-branch --prune-empty --tree-filter "rm -rf ${1}" -- --all
git reset --hard
git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d
git reflog expire --expire=now --all
git gc --aggressive --prune=now

git is fucking complicated. No wonder I procrastinated on it for so long....

Remove login system and implement OAuth login with Facebook and Google. Add OAuth table

Just never ever rebase (or in any way retroactively modify) a branch that is already in a public repo. Especially not master.

Here are my rule of thumb guidelines for things I push to master:

>Every commit should be a working state
Never commit something that doesn't compile. The main reasoning here is twofold: 1. An unlucky soul compiling from git at the wrong time should never run into a compile error, 2. `git bisect`

>Every commit should be as isolated as possible
If you change two unrelated things, make a commit for each. The main reasoning here is also twofold: 1. `git revert` should be trivial, 2. It makes `git blame` as accurate as possible

During development, I usually do it in batches of related features. I'll often `commit -a -m tmp` if I need to switch branches or show my work to somebody else, only to reset that commit later and split it up more properly.

My usual workflow is to make several changes and then `commit -p` (or `add -p`) to interactively select hunks that form a distinct change into its own commit. I'll often also end up reordering, rebasing or squashing commits multiple times before merging them into master. `rebase -i master` is your friend here.

keypress/keyrelease callbacks

Oh, for sure. It was still very private and unofficial as I experimented. Black voodoo magic turned out to be slightly preferred to losing what little commit history I already had, so I opted to cheat in that case.

Lesson learned: don't commit shit you can't afford to carry around forever. A million text files? No problem. Hundreds of MB in new binary files every couple of weeks? Maybe not the best solution.

We're using BitBucket, too, which will help keep me honest. It lets you forbid rewriting history. I just need to restrain myself from abusing my admin privileges. :)

Thanks. I had the vague concept, but lack the practice to see how seemingly-conflicting goals snap together. Added those commands to my list of stuff to look up tomorrow. Much appreciated.

>long series of commits during which LITERALLY EVERYTHING is broken
git log | grep -i 'whoops\|fuck' | wc -l
70

Ah OAuth, my first experience with three-way handshakes.

You don't need to escape the pipe, there, since it's already quoted. Not trying to be douchey, just sayin' on the off chance it's helpful.

Yes you do, and it's not a pipe. It's escaped so grep treats it as an "or" instead of a literal "|" character.

Seriously, if you're not sure of something at least try it out yourself before correcting people

>56367770
Feel free to commit anything you like. Just be careful about pushing those commits.

You can even push a branch and then later tell people not to use that branch anymore.

Ah... sorry. That seems to be a GNU-ism of some sort that I wasn't aware of. Your command legit doesn't even work on my OpenBSD laptop, but I just double-checked and it does on a Debian box.

Functions exactly the same for me using BSD-grep, and that's the only way it should work regardless of implementation.

That's what git tag is for, idiot

To clarify:

1) I don't know what the proper name for the '|' character is, I've just always refered to it as a "pipe character".

2) Test results.
On Debian:
$ echo "abc" | grep 'a\|b'
abc
$ echo "abc" | grep 'a|b'
$ echo "abc" | egrep 'a\|b'
$ echo "abc" | egrep 'a|b'
abc

On OpenBSD:
$ echo "abc" | grep 'a\|b'
$ echo "abc" | grep 'a|b'
$ echo "abc" | egrep 'a\|b'
$ echo "abc" | egrep 'a|b'
abc

I apparently also forgot the egrep (or -E option) part.

Client or library? What language?

It doesn't work yet

There's something wrong with your grep on BSD. 'a\|b' should work fine in grep (basic regex mode, the default for BSD's grep), and 'a|b' should work fine in egrep or grep -E (extended regex mode).

>There's something wrong with your grep on BSD.
Uh... no? I've got multiple systems doing the same thing. Even my router, which is just a base release install with pf and OpenSSH configured.

Honestly not trying to troll you or anything. grep 'a\|b' does NOT work on OpenBSD, but egrep 'a|b' and grep -E 'a|b' do work.

Are you looking at another BSD, perhaps? FreeBSD or even an OS X system? Wouldn't be the first time I've encountered OpenBSD being a bit... spartan. First thing that comes to mind: the GNU date command is actually decent for manipulating arbitrary dates, the FreeBSD and OS X versions are serviceable, but the OpenBSD version is comparatively useless.

In a desperate attempt to verify that I'm not crazy, I resorted to Google. Could only come up with very generic terms, but found this:

github.com/rust-lang/rust/pull/31635
>use a compatible syntax for grep GNU/BSD
>The BSD grep for "basic regex" don't support | as alternate operator (at least under OpenBSD).

google analytics

Was client's decision.

Fixed XXX files and code to unify it's XXX to 'YYY', part 3

Convert text to path, so it renders on Github
I'm ashamed.

Come on, spill the GitHub link

From Google.
github.com/leni536/fast_hilbert_curve