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

>>56362372

Fix shit

Hello world!

Tweak fonts.

File: HFC.png (10KB, 541x486px) Image search: [Google]

10KB, 541x486px

>>56362372
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!

>>56362372
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.

>>56362372
>i18n: Add most messages + german translations

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

>>56364154
Yeah, I'm dreading it.

>>56364144
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.

>>56364206
/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.

>>56364225
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.

>>56364206
>>56364225

/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.

>>56364206
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.

>>56364293
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

>>56364310
I didn't realize those were sockets! Thanks.

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

>>56364145

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

>>56362372

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

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

>>56364351
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..

>>56364722
>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

>>56364689
>>56364755
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.

>>56364764
>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?

>>56364764
>Git good
This

fix

:^)

>>56364773
Somehow I don't feel any better about it.

>Removed all that fucking VBScript

>>56364797
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

>>56364764
>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.

>>56364858
> What are topic branches
> What is rebase

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

>>56364858
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.

>>56364755
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

File: 250px-Ep_26_congratulations.jpg (23KB, 250x189px) Image search: [Google]

23KB, 250x189px

>>56364858

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

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

>>56364887
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.

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

>>56364923
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.

File: 1472377067014.png (78KB, 321x185px) Image search: [Google]

78KB, 321x185px

>>56364975
>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.

>>56364975

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

>>56364975
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.

>>56364975
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.

>>56364872
>>56364887
>>56364898
>>56364923
>>56364924
>replying to shitty bait

>>56362372

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

>>56365203
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.

>>56365272
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.

>>56365309
Btrfs? ZFS?

>>56365309
>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.

File: akari!.jpg (2MB, 1300x1560px) Image search: [Google]

2MB, 1300x1560px

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

>>56362372

sigmoid L

>>56365506
He keeps killing me in Stone Soup.

>>56365344
>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.

>>56362372

Merge branch 'develop'

>Created logo

Create CNAME

>>56366176
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 /g/

>>56362372

>git commit -m "akjdnakjndjaknjksndjkansd"

>>56366397

sorry...

git commit -m "akjdnakjndjaknjksndjkansd"

>>56366389
>

Why is this even a git repo?

man I've had that in so many commits

>>56365640
I think you're thinking of Sigmund

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

>>56366389
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?

>>56367077
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.

>>56367146
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

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

>>56367077
>>56367146
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.

>>56362372

keypress/keyrelease callbacks

>>56367337
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. :)

>>56367347
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.

>>56367077
>long series of commits during which LITERALLY EVERYTHING is broken

 git log | grep -i 'whoops\|fuck' | wc -l
70

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

>>56368213
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.

>>56368320
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.

>>56368434
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.

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

>>56364689
That's what git tag is for, idiot

>>56368509
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.

>>56365482
Client or library? What language?

It doesn't work yet

>>56368581
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).

>>56368675
>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.

>>56368866
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:

https://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.

>>56369060
Come on, spill the GitHub link

>>56369091
From Google.
https://github.com/leni536/fast_hilbert_curve

>>56369102
Hah, that's kinda cool.

>>56366517
He is a bastard though.