_ikke_

In git, branches are pointers to commits (branches are a specific kind of refs or references). When you commit, git creates a new commit object, links it to the last commit on that branch, and then points that branch to the new commit.

This way, you get a chain of commits, each pointing to the previous commit, and and branch references pointing to the last commit of each branch.

The commit is not orphaned, because the tag is still pointing to it, but it's indeed not reachable from a branch anymore.

git does not update local tags when the tag has changed remotely (see "on retagging" in the git tag man-page), so it would have to be a different tag.

Merging it back would be confusing, because you know have the old branch and the new branch in your history. It would cause the tag to be reachable again from master though.

What we are talking about is whether or not you should rewrite public history. The technical reason is based on the fact if others have access to this history or not.

It does not matter if you pushed it to a private repository where some other people still have access to; they might have fetched that history and committed on, which causes unexpected results when you rewrite such a branch.

I tend to use published history / commits for this reason to make it less confusing.

You said:

> anything accessible without any authorization.

Even if it does require authorization, it's considered public in regard to this discussion.

When people talk about public commits it means commits other people have access too, and more specific, were able to commit on top. Authorization has nothing to do with it. In practice it means anything you have pushed.

An exception can be made for topic branches, especially in a pull-request workflow. These branches could be rebased / amended to update the final result, even after they have been pushed already.

Bisect also becomes useless because of large commits. Even if you find the commit, the change it introduces can be so large you don't git much improvement.

Git allows you to clean up your feature branches to prevent these kind of fix commits.

Look at git.git. They don't require people to squash all their commits into a single patch, but still every patch should be compilable.

That's what things like git rebase are for (nice workflow with git commit --fixup + git rebase -i --autosquash). Then you clean up your fixes, while still keeping valuable history. With squash merges you are throwing out the baby with the bathwater.

I have a laptop with in installation that's 4/5 years old, and still running. Except for the occasional things, no problems with upgrading (even transitioning to systemd went fine without problems).

He was comparing the tls equivalent of how SSH works. First time you connect to an ssh server, you have to accept the host key, which most people do not (and in most situations, can not) verify.

My approach is a web app. It's not native, but effective.

In order to do so, Apple has to make an update that loosens the restrictions the current version has.

Once that update exists, it can be installed on any device because it has been signed by Apple.

The problem isn't that IPv6 isn't backwards compattible. The problem is that IPv4 is not forwards compattible.

Arstechnica has an article about it: http://arstechnica.com/business/2016/01/ipv6-celebrates-its-...

github released an announcement: https://github.com/blog/2111-issue-and-pull-request-template...

Sorry, accidentally down-voted.

From the blogpost:

> Image IDs now represent the content that is inside an image, in a similar way to how Git commit hashes represent the content inside commits.

I think that's why Newegg is doing this. They try to invalidate the patents of patent trolls so they can't abuse them against smaller companies.

Not with initiatives like letsencrypt.

I created my catch-all on a subdomain. While it gives a problem with certain websites (don't consider it a valid e-mail address), I barely receive spam on it.

They are the sysadmins of the individual networks that compose the internet.

They arrange with each other to connect their networks, sometimes payed, sometimes with no money exchanged.

These admins are not self-appointed admins over the 'internet', but they just maintain their own networks.

How is the uptime of the machine being detected?

You'd have to travel faster then light to outrun the light emmited from years ago.

I always recommend people to use `git push --force-with-lease`. It's more to type, but it verifies if the remote branch is the same as the remote tracking branch, so you don't accidentally rewrite branches someone else has pushed to.

The object model of git is described as a directed acyclic graph, thus by definition, it has no cycles, which wouldn't make sense for a version control system anyway.

That said, this is most likely just meant as a fun visualization, because the visualization does look like a railway map.

We use this guide often in the #git irc channel where Seth Robertson used to frequent.

It's a nice guide because sometimes people don't even know what they really want because terms like revert are overloaded.

11:40 UTC "We're doing emergency maintenance to recover the site".

Not withstanding exploits, the user still has to accept the offered link, so it's not really stealthy in that case.

NFC in Android is not active while the device is locked [0]

> Android-powered devices are usually looking for NFC tags when the screen is unlocked, unless NFC is disabled in the device's Settings menu.

So to use this, the hacker already needs an unlocked device, in which case it's just as easy to download the payload directly.

Usually, the range for NFC to work is quite close, 4 cm or less [1], and I don't think these chips have the capability to increase the range.

[0]: http://developer.android.com/guide/topics/connectivity/nfc/n...

[1]: https://developer.android.com/guide/topics/connectivity/nfc/...

Because HEAD is in this case not 'attached' to a branch, which means there is no branch which can be advanced to keep track of the new commit.

For all intents and purposes, as long as no other branch is pointing to that commit, that commit is 'lost'. It's not immediately removed from your hard drive, but it's no longer considered part of your history.

Note that the technical name for branches in git is refs or references, which more accurately describe their nature.

Yes, but it's a lock where they have to provide the key too, and the only way to prevent you from manually opening the lock is obfuscating this process.