fast

@@ -1,969 +0,0 @@
-GIT-PUSH(1)                        Git Manual                       GIT-PUSH(1)
-
-NAME
-       git-push - Update remote refs along with associated objects
-
-SYNOPSIS
-       git push [--all | --branches | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
-                  [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-q | --quiet] [-v | --verbose]
-                  [-u | --set-upstream] [-o <string> | --push-option=<string>]
-                  [--[no-]signed|--signed=(true|false|if-asked)]
-                  [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]]
-                  [--no-verify] [<repository> [<refspec>...]]
-
-DESCRIPTION
-       Updates remote refs using local refs, while sending objects necessary to
-       complete the given refs.
-
-       You can make interesting things happen to a repository every time you
-       push into it, by setting up hooks there. See documentation for git-
-       receive-pack(1).
-
-       When the command line does not specify where to push with the
-       <repository> argument, branch.*.remote configuration for the current
-       branch is consulted to determine where to push. If the configuration is
-       missing, it defaults to origin.
-
-       When the command line does not specify what to push with <refspec>...
-       arguments or --all, --mirror, --tags options, the command finds the
-       default <refspec> by consulting remote.*.push configuration, and if it
-       is not found, honors push.default configuration to decide what to push
-       (See git-config(1) for the meaning of push.default).
-
-       When neither the command-line nor the configuration specifies what to
-       push, the default behavior is used, which corresponds to the simple
-       value for push.default: the current branch is pushed to the
-       corresponding upstream branch, but as a safety measure, the push is
-       aborted if the upstream branch does not have the same name as the local
-       one.
-
-OPTIONS
-       <repository>
-           The "remote" repository that is the destination of a push operation.
-           This parameter can be either a URL (see the section GIT URLS below)
-           or the name of a remote (see the section REMOTES below).
-
-       <refspec>...
-           Specify what destination ref to update with what source object. The
-           format of a <refspec> parameter is an optional plus +, followed by
-           the source object <src>, followed by a colon :, followed by the
-           destination ref <dst>.
-
-           The <src> is often the name of the branch you would want to push,
-           but it can be any arbitrary "SHA-1 expression", such as master~4 or
-           HEAD (see gitrevisions(7)).
-
-           The <dst> tells which ref on the remote side is updated with this
-           push. Arbitrary expressions cannot be used here, an actual ref must
-           be named. If git push [<repository>] without any <refspec> argument
-           is set to update some ref at the destination with <src> with
-           remote.<repository>.push configuration variable, :<dst> part can be
-           omitted—such a push will update a ref that <src> normally updates
-           without any <refspec> on the command line. Otherwise, missing :<dst>
-           means to update the same ref as the <src>.
-
-           If <dst> doesn’t start with refs/ (e.g.  refs/heads/master) we will
-           try to infer where in refs/* on the destination <repository> it
-           belongs based on the type of <src> being pushed and whether <dst> is
-           ambiguous.
-
-           •   If <dst> unambiguously refers to a ref on the <repository>
-               remote, then push to that ref.
-
-           •   If <src> resolves to a ref starting with refs/heads/ or
-               refs/tags/, then prepend that to <dst>.
-
-           •   Other ambiguity resolutions might be added in the future, but
-               for now any other cases will error out with an error indicating
-               what we tried, and depending on the
-               advice.pushUnqualifiedRefname configuration (see git-config(1))
-               suggest what refs/ namespace you may have wanted to push to.
-
-           The object referenced by <src> is used to update the <dst> reference
-           on the remote side. Whether this is allowed depends on where in
-           refs/* the <dst> reference lives as described in detail below, in
-           those sections "update" means any modifications except deletes,
-           which as noted after the next few sections are treated differently.
-
-           The refs/heads/* namespace will only accept commit objects, and
-           updates only if they can be fast-forwarded.
-
-           The refs/tags/* namespace will accept any kind of object (as
-           commits, trees and blobs can be tagged), and any updates to them
-           will be rejected.
-
-           It’s possible to push any type of object to any namespace outside of
-           refs/{tags,heads}/*. In the case of tags and commits, these will be
-           treated as if they were the commits inside refs/heads/* for the
-           purposes of whether the update is allowed.
-
-           I.e. a fast-forward of commits and tags outside refs/{tags,heads}/*
-           is allowed, even in cases where what’s being fast-forwarded is not a
-           commit, but a tag object which happens to point to a new commit
-           which is a fast-forward of the commit the last tag (or commit) it’s
-           replacing. Replacing a tag with an entirely different tag is also
-           allowed, if it points to the same commit, as well as pushing a
-           peeled tag, i.e. pushing the commit that existing tag object points
-           to, or a new tag object which an existing commit points to.
-
-           Tree and blob objects outside of refs/{tags,heads}/* will be treated
-           the same way as if they were inside refs/tags/*, any update of them
-           will be rejected.
-
-           All of the rules described above about what’s not allowed as an
-           update can be overridden by adding an the optional leading + to a
-           refspec (or using --force command line option). The only exception
-           to this is that no amount of forcing will make the refs/heads/*
-           namespace accept a non-commit object. Hooks and configuration can
-           also override or amend these rules, see e.g.
-           receive.denyNonFastForwards in git-config(1) and pre-receive and
-           update in githooks(5).
-
-           Pushing an empty <src> allows you to delete the <dst> ref from the
-           remote repository. Deletions are always accepted without a leading +
-           in the refspec (or --force), except when forbidden by configuration
-           or hooks. See receive.denyDeletes in git-config(1) and pre-receive
-           and update in githooks(5).
-
-           The special refspec : (or +: to allow non-fast-forward updates)
-           directs Git to push "matching" branches: for every branch that
-           exists on the local side, the remote side is updated if a branch of
-           the same name already exists on the remote side.
-
-           tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>.
-
-       --all, --branches
-           Push all branches (i.e. refs under refs/heads/); cannot be used with
-           other <refspec>.
-
-       --prune
-           Remove remote branches that don’t have a local counterpart. For
-           example a remote branch tmp will be removed if a local branch with
-           the same name doesn’t exist any more. This also respects refspecs,
-           e.g.  git push --prune remote refs/heads/*:refs/tmp/* would make
-           sure that remote refs/tmp/foo will be removed if refs/heads/foo
-           doesn’t exist.
-
-       --mirror
-           Instead of naming each ref to push, specifies that all refs under
-           refs/ (which includes but is not limited to refs/heads/,
-           refs/remotes/, and refs/tags/) be mirrored to the remote repository.
-           Newly created local refs will be pushed to the remote end, locally
-           updated refs will be force updated on the remote end, and deleted
-           refs will be removed from the remote end. This is the default if the
-           configuration option remote.<remote>.mirror is set.
-
-       -n, --dry-run
-           Do everything except actually send the updates.
-
-       --porcelain
-           Produce machine-readable output. The output status line for each ref
-           will be tab-separated and sent to stdout instead of stderr. The full
-           symbolic names of the refs will be given.
-
-       -d, --delete
-           All listed refs are deleted from the remote repository. This is the
-           same as prefixing all refs with a colon.
-
-       --tags
-           All refs under refs/tags are pushed, in addition to refspecs
-           explicitly listed on the command line.
-
-       --follow-tags
-           Push all the refs that would be pushed without this option, and also
-           push annotated tags in refs/tags that are missing from the remote
-           but are pointing at commit-ish that are reachable from the refs
-           being pushed. This can also be specified with configuration variable
-           push.followTags. For more information, see push.followTags in git-
-           config(1).
-
-       --[no-]signed, --signed=(true|false|if-asked)
-           GPG-sign the push request to update refs on the receiving side, to
-           allow it to be checked by the hooks and/or be logged. If false or
-           --no-signed, no signing will be attempted. If true or --signed, the
-           push will fail if the server does not support signed pushes. If set
-           to if-asked, sign if and only if the server supports signed pushes.
-           The push will also fail if the actual call to gpg --sign fails. See
-           git-receive-pack(1) for the details on the receiving end.
-
-       --[no-]atomic
-           Use an atomic transaction on the remote side if available. Either
-           all refs are updated, or on error, no refs are updated. If the
-           server does not support atomic pushes the push will fail.
-
-       -o <option>, --push-option=<option>
-           Transmit the given string to the server, which passes them to the
-           pre-receive as well as the post-receive hook. The given string must
-           not contain a NUL or LF character. When multiple
-           --push-option=<option> are given, they are all sent to the other
-           side in the order listed on the command line. When no
-           --push-option=<option> is given from the command line, the values of
-           configuration variable push.pushOption are used instead.
-
-       --receive-pack=<git-receive-pack>, --exec=<git-receive-pack>
-           Path to the git-receive-pack program on the remote end. Sometimes
-           useful when pushing to a remote repository over ssh, and you do not
-           have the program in a directory on the default $PATH.
-
-       --[no-]force-with-lease, --force-with-lease=<refname>,
-       --force-with-lease=<refname>:<expect>
-           Usually, "git push" refuses to update a remote ref that is not an
-           ancestor of the local ref used to overwrite it.
-
-           This option overrides this restriction if the current value of the
-           remote ref is the expected value. "git push" fails otherwise.
-
-           Imagine that you have to rebase what you have already published. You
-           will have to bypass the "must fast-forward" rule in order to replace
-           the history you originally published with the rebased history. If
-           somebody else built on top of your original history while you are
-           rebasing, the tip of the branch at the remote may advance with their
-           commit, and blindly pushing with --force will lose their work.
-
-           This option allows you to say that you expect the history you are
-           updating is what you rebased and want to replace. If the remote ref
-           still points at the commit you specified, you can be sure that no
-           other people did anything to the ref. It is like taking a "lease" on
-           the ref without explicitly locking it, and the remote ref is updated
-           only if the "lease" is still valid.
-
-           --force-with-lease alone, without specifying the details, will
-           protect all remote refs that are going to be updated by requiring
-           their current value to be the same as the remote-tracking branch we
-           have for them.
-
-           --force-with-lease=<refname>, without specifying the expected value,
-           will protect the named ref (alone), if it is going to be updated, by
-           requiring its current value to be the same as the remote-tracking
-           branch we have for it.
-
-           --force-with-lease=<refname>:<expect> will protect the named ref
-           (alone), if it is going to be updated, by requiring its current
-           value to be the same as the specified value <expect> (which is
-           allowed to be different from the remote-tracking branch we have for
-           the refname, or we do not even have to have such a remote-tracking
-           branch when this form is used). If <expect> is the empty string,
-           then the named ref must not already exist.
-
-           Note that all forms other than --force-with-lease=<refname>:<expect>
-           that specifies the expected current value of the ref explicitly are
-           still experimental and their semantics may change as we gain
-           experience with this feature.
-
-           "--no-force-with-lease" will cancel all the previous
-           --force-with-lease on the command line.
-
-           A general note on safety: supplying this option without an expected
-           value, i.e. as --force-with-lease or --force-with-lease=<refname>
-           interacts very badly with anything that implicitly runs git fetch on
-           the remote to be pushed to in the background, e.g.  git fetch origin
-           on your repository in a cronjob.
-
-           The protection it offers over --force is ensuring that subsequent
-           changes your work wasn’t based on aren’t clobbered, but this is
-           trivially defeated if some background process is updating refs in
-           the background. We don’t have anything except the remote tracking
-           info to go by as a heuristic for refs you’re expected to have seen &
-           are willing to clobber.
-
-           If your editor or some other system is running git fetch in the
-           background for you a way to mitigate this is to simply set up
-           another remote:
-
-               git remote add origin-push $(git config remote.origin.url)
-               git fetch origin-push
-
-           Now when the background process runs git fetch origin the references
-           on origin-push won’t be updated, and thus commands like:
-
-               git push --force-with-lease origin-push
-
-           Will fail unless you manually run git fetch origin-push. This method
-           is of course entirely defeated by something that runs git fetch
-           --all, in that case you’d need to either disable it or do something
-           more tedious like:
-
-               git fetch              # update 'master' from remote
-               git tag base master    # mark our base point
-               git rebase -i master   # rewrite some commits
-               git push --force-with-lease=master:base master:master
-
-           I.e. create a base tag for versions of the upstream code that you’ve
-           seen and are willing to overwrite, then rewrite history, and finally
-           force push changes to master if the remote version is still at base,
-           regardless of what your local remotes/origin/master has been updated
-           to in the background.
-
-           Alternatively, specifying --force-if-includes as an ancillary option
-           along with --force-with-lease[=<refname>] (i.e., without saying what
-           exact commit the ref on the remote side must be pointing at, or
-           which refs on the remote side are being protected) at the time of
-           "push" will verify if updates from the remote-tracking refs that may
-           have been implicitly updated in the background are integrated
-           locally before allowing a forced update.
-
-       -f, --force
-           Usually, the command refuses to update a remote ref that is not an
-           ancestor of the local ref used to overwrite it. Also, when
-           --force-with-lease option is used, the command refuses to update a
-           remote ref whose current value does not match what is expected.
-
-           This flag disables these checks, and can cause the remote repository
-           to lose commits; use it with care.
-
-           Note that --force applies to all the refs that are pushed, hence
-           using it with push.default set to matching or with multiple push
-           destinations configured with remote.*.push may overwrite refs other
-           than the current branch (including local refs that are strictly
-           behind their remote counterpart). To force a push to only one
-           branch, use a + in front of the refspec to push (e.g git push origin
-           +master to force a push to the master branch). See the <refspec>...
-           section above for details.
-
-       --[no-]force-if-includes
-           Force an update only if the tip of the remote-tracking ref has been
-           integrated locally.
-
-           This option enables a check that verifies if the tip of the
-           remote-tracking ref is reachable from one of the "reflog" entries of
-           the local branch based in it for a rewrite. The check ensures that
-           any updates from the remote have been incorporated locally by
-           rejecting the forced update if that is not the case.
-
-           If the option is passed without specifying --force-with-lease, or
-           specified along with --force-with-lease=<refname>:<expect>, it is a
-           "no-op".
-
-           Specifying --no-force-if-includes disables this behavior.
-
-       --repo=<repository>
-           This option is equivalent to the <repository> argument. If both are
-           specified, the command-line argument takes precedence.
-
-       -u, --set-upstream
-           For every branch that is up to date or successfully pushed, add
-           upstream (tracking) reference, used by argument-less git-pull(1) and
-           other commands. For more information, see branch.<name>.merge in
-           git-config(1).
-
-       --[no-]thin
-           These options are passed to git-send-pack(1). A thin transfer
-           significantly reduces the amount of sent data when the sender and
-           receiver share many of the same objects in common. The default is
-           --thin.
-
-       -q, --quiet
-           Suppress all output, including the listing of updated refs, unless
-           an error occurs. Progress is not reported to the standard error
-           stream.
-
-       -v, --verbose
-           Run verbosely.
-
-       --progress
-           Progress status is reported on the standard error stream by default
-           when it is attached to a terminal, unless -q is specified. This flag
-           forces progress status even if the standard error stream is not
-           directed to a terminal.
-
-       --no-recurse-submodules, --recurse-submodules=check|on-demand|only|no
-           May be used to make sure all submodule commits used by the revisions
-           to be pushed are available on a remote-tracking branch. If check is
-           used Git will verify that all submodule commits that changed in the
-           revisions to be pushed are available on at least one remote of the
-           submodule. If any commits are missing the push will be aborted and
-           exit with non-zero status. If on-demand is used all submodules that
-           changed in the revisions to be pushed will be pushed. If on-demand
-           was not able to push all necessary revisions it will also be aborted
-           and exit with non-zero status. If only is used all submodules will
-           be pushed while the superproject is left unpushed. A value of no or
-           using --no-recurse-submodules can be used to override the
-           push.recurseSubmodules configuration variable when no submodule
-           recursion is required.
-
-           When using on-demand or only, if a submodule has a
-           "push.recurseSubmodules={on-demand,only}" or "submodule.recurse"
-           configuration, further recursion will occur. In this case, "only" is
-           treated as "on-demand".
-
-       --[no-]verify
-           Toggle the pre-push hook (see githooks(5)). The default is --verify,
-           giving the hook a chance to prevent the push. With --no-verify, the
-           hook is bypassed completely.
-
-       -4, --ipv4
-           Use IPv4 addresses only, ignoring IPv6 addresses.
-
-       -6, --ipv6
-           Use IPv6 addresses only, ignoring IPv4 addresses.
-
-GIT URLS
-       In general, URLs contain information about the transport protocol, the
-       address of the remote server, and the path to the repository. Depending
-       on the transport protocol, some of this information may be absent.
-
-       Git supports ssh, git, http, and https protocols (in addition, ftp and
-       ftps can be used for fetching, but this is inefficient and deprecated;
-       do not use them).
-
-       The native transport (i.e. git:// URL) does no authentication and should
-       be used with caution on unsecured networks.
-
-       The following syntaxes may be used with them:
-
-       •   ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>
-
-       •   git://<host>[:<port>]/<path-to-git-repo>
-
-       •   http[s]://<host>[:<port>]/<path-to-git-repo>
-
-       •   ftp[s]://<host>[:<port>]/<path-to-git-repo>
-
-       An alternative scp-like syntax may also be used with the ssh protocol:
-
-       •   [<user>@]<host>:/<path-to-git-repo>
-
-       This syntax is only recognized if there are no slashes before the first
-       colon. This helps differentiate a local path that contains a colon. For
-       example the local path foo:bar could be specified as an absolute path or
-       ./foo:bar to avoid being misinterpreted as an ssh url.
-
-       The ssh and git protocols additionally support ~<username> expansion:
-
-       •   ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>
-
-       •   git://<host>[:<port>]/~<user>/<path-to-git-repo>
-
-       •   [<user>@]<host>:~<user>/<path-to-git-repo>
-
-       For local repositories, also supported by Git natively, the following
-       syntaxes may be used:
-
-       •   /path/to/repo.git/
-
-       •   file:///path/to/repo.git/
-
-       These two syntaxes are mostly equivalent, except when cloning, when the
-       former implies --local option. See git-clone(1) for details.
-
-       git clone, git fetch and git pull, but not git push, will also accept a
-       suitable bundle file. See git-bundle(1).
-
-       When Git doesn’t know how to handle a certain transport protocol, it
-       attempts to use the remote-<transport> remote helper, if one exists. To
-       explicitly request a remote helper, the following syntax may be used:
-
-       •   <transport>::<address>
-
-       where <address> may be a path, a server and path, or an arbitrary
-       URL-like string recognized by the specific remote helper being invoked.
-       See gitremote-helpers(7) for details.
-
-       If there are a large number of similarly-named remote repositories and
-       you want to use a different format for them (such that the URLs you use
-       will be rewritten into URLs that work), you can create a configuration
-       section of the form:
-
-                   [url "<actual-url-base>"]
-                           insteadOf = <other-url-base>
-
-       For example, with this:
-
-                   [url "git://git.host.xz/"]
-                           insteadOf = host.xz:/path/to/
-                           insteadOf = work:
-
-       a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
-       rewritten in any context that takes a URL to be
-       "git://git.host.xz/repo.git".
-
-       If you want to rewrite URLs for push only, you can create a
-       configuration section of the form:
-
-                   [url "<actual-url-base>"]
-                           pushInsteadOf = <other-url-base>
-
-       For example, with this:
-
-                   [url "ssh://example.org/"]
-                           pushInsteadOf = git://example.org/
-
-       a URL like "git://example.org/path/to/repo.git" will be rewritten to
-       "ssh://example.org/path/to/repo.git" for pushes, but pulls will still
-       use the original URL.
-
-REMOTES
-       The name of one of the following can be used instead of a URL as
-       <repository> argument:
-
-       •   a remote in the Git configuration file: $GIT_DIR/config,
-
-       •   a file in the $GIT_DIR/remotes directory, or
-
-       •   a file in the $GIT_DIR/branches directory.
-
-       All of these also allow you to omit the refspec from the command line
-       because they each contain a refspec which git will use by default.
-
-   Named remote in configuration file
-       You can choose to provide the name of a remote which you had previously
-       configured using git-remote(1), git-config(1) or even by a manual edit
-       to the $GIT_DIR/config file. The URL of this remote will be used to
-       access the repository. The refspec of this remote will be used by
-       default when you do not provide a refspec on the command line. The entry
-       in the config file would appear like this:
-
-                   [remote "<name>"]
-                           url = <URL>
-                           pushurl = <pushurl>
-                           push = <refspec>
-                           fetch = <refspec>
-
-       The <pushurl> is used for pushes only. It is optional and defaults to
-       <URL>. Pushing to a remote affects all defined pushurls or all defined
-       urls if no pushurls are defined. Fetch, however, will only fetch from
-       the first defined url if multiple urls are defined.
-
-   Named file in $GIT_DIR/remotes
-       You can choose to provide the name of a file in $GIT_DIR/remotes. The
-       URL in this file will be used to access the repository. The refspec in
-       this file will be used as default when you do not provide a refspec on
-       the command line. This file should have the following format:
-
-                   URL: one of the above URL formats
-                   Push: <refspec>
-                   Pull: <refspec>
-
-       Push: lines are used by git push and Pull: lines are used by git pull
-       and git fetch. Multiple Push: and Pull: lines may be specified for
-       additional branch mappings.
-
-   Named file in $GIT_DIR/branches
-       You can choose to provide the name of a file in $GIT_DIR/branches. The
-       URL in this file will be used to access the repository. This file should
-       have the following format:
-
-                   <URL>#<head>
-
-       <URL> is required; #<head> is optional.
-
-       Depending on the operation, git will use one of the following refspecs,
-       if you don’t provide one on the command line. <branch> is the name of
-       this file in $GIT_DIR/branches and <head> defaults to master.
-
-       git fetch uses:
-
-                   refs/heads/<head>:refs/heads/<branch>
-
-       git push uses:
-
-                   HEAD:refs/heads/<head>
-
-OUTPUT
-       The output of "git push" depends on the transport method used; this
-       section describes the output when pushing over the Git protocol (either
-       locally or via ssh).
-
-       The status of the push is output in tabular form, with each line
-       representing the status of a single ref. Each line is of the form:
-
-            <flag> <summary> <from> -> <to> (<reason>)
-
-       If --porcelain is used, then each line of the output is of the form:
-
-            <flag> \t <from>:<to> \t <summary> (<reason>)
-
-       The status of up-to-date refs is shown only if --porcelain or --verbose
-       option is used.
-
-       flag
-           A single character indicating the status of the ref:
-
-           (space)
-               for a successfully pushed fast-forward;
-
-           +
-               for a successful forced update;
-
-           -
-               for a successfully deleted ref;
-
-           *
-               for a successfully pushed new ref;
-
-           !
-               for a ref that was rejected or failed to push; and
-
-           =
-               for a ref that was up to date and did not need pushing.
-
-       summary
-           For a successfully pushed ref, the summary shows the old and new
-           values of the ref in a form suitable for using as an argument to git
-           log (this is <old>..<new> in most cases, and <old>...<new> for
-           forced non-fast-forward updates).
-
-           For a failed update, more details are given:
-
-           rejected
-               Git did not try to send the ref at all, typically because it is
-               not a fast-forward and you did not force the update.
-
-           remote rejected
-               The remote end refused the update. Usually caused by a hook on
-               the remote side, or because the remote repository has one of the
-               following safety options in effect: receive.denyCurrentBranch
-               (for pushes to the checked out branch),
-               receive.denyNonFastForwards (for forced non-fast-forward
-               updates), receive.denyDeletes or receive.denyDeleteCurrent. See
-               git-config(1).
-
-           remote failure
-               The remote end did not report the successful update of the ref,
-               perhaps because of a temporary error on the remote side, a break
-               in the network connection, or other transient error.
-
-       from
-           The name of the local ref being pushed, minus its refs/<type>/
-           prefix. In the case of deletion, the name of the local ref is
-           omitted.
-
-       to
-           The name of the remote ref being updated, minus its refs/<type>/
-           prefix.
-
-       reason
-           A human-readable explanation. In the case of successfully pushed
-           refs, no explanation is needed. For a failed ref, the reason for
-           failure is described.
-
-NOTE ABOUT FAST-FORWARDS
-       When an update changes a branch (or more in general, a ref) that used to
-       point at commit A to point at another commit B, it is called a
-       fast-forward update if and only if B is a descendant of A.
-
-       In a fast-forward update from A to B, the set of commits that the
-       original commit A built on top of is a subset of the commits the new
-       commit B builds on top of. Hence, it does not lose any history.
-
-       In contrast, a non-fast-forward update will lose history. For example,
-       suppose you and somebody else started at the same commit X, and you
-       built a history leading to commit B while the other person built a
-       history leading to commit A. The history looks like this:
-
-                 B
-                /
-            ---X---A
-
-       Further suppose that the other person already pushed changes leading to
-       A back to the original repository from which you two obtained the
-       original commit X.
-
-       The push done by the other person updated the branch that used to point
-       at commit X to point at commit A. It is a fast-forward.
-
-       But if you try to push, you will attempt to update the branch (that now
-       points at A) with commit B. This does not fast-forward. If you did so,
-       the changes introduced by commit A will be lost, because everybody will
-       now start building on top of B.
-
-       The command by default does not allow an update that is not a
-       fast-forward to prevent such loss of history.
-
-       If you do not want to lose your work (history from X to B) or the work
-       by the other person (history from X to A), you would need to first fetch
-       the history from the repository, create a history that contains changes
-       done by both parties, and push the result back.
-
-       You can perform "git pull", resolve potential conflicts, and "git push"
-       the result. A "git pull" will create a merge commit C between commits A
-       and B.
-
-                 B---C
-                /   /
-            ---X---A
-
-       Updating A with the resulting merge commit will fast-forward and your
-       push will be accepted.
-
-       Alternatively, you can rebase your change between X and B on top of A,
-       with "git pull --rebase", and push the result back. The rebase will
-       create a new commit D that builds the change between X and B on top of
-       A.
-
-                 B   D
-                /   /
-            ---X---A
-
-       Again, updating A with this commit will fast-forward and your push will
-       be accepted.
-
-       There is another common situation where you may encounter
-       non-fast-forward rejection when you try to push, and it is possible even
-       when you are pushing into a repository nobody else pushes into. After
-       you push commit A yourself (in the first picture in this section),
-       replace it with "git commit --amend" to produce commit B, and you try to
-       push it out, because forgot that you have pushed A out already. In such
-       a case, and only if you are certain that nobody in the meantime fetched
-       your earlier commit A (and started building on top of it), you can run
-       "git push --force" to overwrite it. In other words, "git push --force"
-       is a method reserved for a case where you do mean to lose history.
-
-EXAMPLES
-       git push
-           Works like git push <remote>, where <remote> is the current branch’s
-           remote (or origin, if no remote is configured for the current
-           branch).
-
-       git push origin
-           Without additional configuration, pushes the current branch to the
-           configured upstream (branch.<name>.merge configuration variable) if
-           it has the same name as the current branch, and errors out without
-           pushing otherwise.
-
-           The default behavior of this command when no <refspec> is given can
-           be configured by setting the push option of the remote, or the
-           push.default configuration variable.
-
-           For example, to default to pushing only the current branch to origin
-           use git config remote.origin.push HEAD. Any valid <refspec> (like
-           the ones in the examples below) can be configured as the default for
-           git push origin.
-
-       git push origin :
-           Push "matching" branches to origin. See <refspec> in the OPTIONS
-           section above for a description of "matching" branches.
-
-       git push origin master
-           Find a ref that matches master in the source repository (most
-           likely, it would find refs/heads/master), and update the same ref
-           (e.g.  refs/heads/master) in origin repository with it. If master
-           did not exist remotely, it would be created.
-
-       git push origin HEAD
-           A handy way to push the current branch to the same name on the
-           remote.
-
-       git push mothership master:satellite/master dev:satellite/dev
-           Use the source ref that matches master (e.g.  refs/heads/master) to
-           update the ref that matches satellite/master (most probably
-           refs/remotes/satellite/master) in the mothership repository; do the
-           same for dev and satellite/dev.
-
-           See the section describing <refspec>... above for a discussion of
-           the matching semantics.
-
-           This is to emulate git fetch run on the mothership using git push
-           that is run in the opposite direction in order to integrate the work
-           done on satellite, and is often necessary when you can only make
-           connection in one way (i.e. satellite can ssh into mothership but
-           mothership cannot initiate connection to satellite because the
-           latter is behind a firewall or does not run sshd).
-
-           After running this git push on the satellite machine, you would ssh
-           into the mothership and run git merge there to complete the
-           emulation of git pull that were run on mothership to pull changes
-           made on satellite.
-
-       git push origin HEAD:master
-           Push the current branch to the remote ref matching master in the
-           origin repository. This form is convenient to push the current
-           branch without thinking about its local name.
-
-       git push origin master:refs/heads/experimental
-           Create the branch experimental in the origin repository by copying
-           the current master branch. This form is only needed to create a new
-           branch or tag in the remote repository when the local name and the
-           remote name are different; otherwise, the ref name on its own will
-           work.
-
-       git push origin :experimental
-           Find a ref that matches experimental in the origin repository (e.g.
-           refs/heads/experimental), and delete it.
-
-       git push origin +dev:master
-           Update the origin repository’s master branch with the dev branch,
-           allowing non-fast-forward updates.  This can leave unreferenced
-           commits dangling in the origin repository.  Consider the following
-           situation, where a fast-forward is not possible:
-
-                           o---o---o---A---B  origin/master
-                                    \
-                                     X---Y---Z  dev
-
-           The above command would change the origin repository to
-
-                                     A---B  (unnamed branch)
-                                    /
-                           o---o---o---X---Y---Z  master
-
-           Commits A and B would no longer belong to a branch with a symbolic
-           name, and so would be unreachable. As such, these commits would be
-           removed by a git gc command on the origin repository.
-
-SECURITY
-       The fetch and push protocols are not designed to prevent one side from
-       stealing data from the other repository that was not intended to be
-       shared. If you have private data that you need to protect from a
-       malicious peer, your best option is to store it in another repository.
-       This applies to both clients and servers. In particular, namespaces on a
-       server are not effective for read access control; you should only grant
-       read access to a namespace to clients that you would trust with read
-       access to the entire repository.
-
-       The known attack vectors are as follows:
-
-        1. The victim sends "have" lines advertising the IDs of objects it has
-           that are not explicitly intended to be shared but can be used to
-           optimize the transfer if the peer also has them. The attacker
-           chooses an object ID X to steal and sends a ref to X, but isn’t
-           required to send the content of X because the victim already has it.
-           Now the victim believes that the attacker has X, and it sends the
-           content of X back to the attacker later. (This attack is most
-           straightforward for a client to perform on a server, by creating a
-           ref to X in the namespace the client has access to and then fetching
-           it. The most likely way for a server to perform it on a client is to
-           "merge" X into a public branch and hope that the user does
-           additional work on this branch and pushes it back to the server
-           without noticing the merge.)
-
-        2. As in #1, the attacker chooses an object ID X to steal. The victim
-           sends an object Y that the attacker already has, and the attacker
-           falsely claims to have X and not Y, so the victim sends Y as a delta
-           against X. The delta reveals regions of X that are similar to Y to
-           the attacker.
-
-CONFIGURATION
-       Everything below this line in this section is selectively included from
-       the git-config(1) documentation. The content is the same as what’s found
-       there:
-
-       push.autoSetupRemote
-           If set to "true" assume --set-upstream on default push when no
-           upstream tracking exists for the current branch; this option takes
-           effect with push.default options simple, upstream, and current. It
-           is useful if by default you want new branches to be pushed to the
-           default remote (like the behavior of push.default=current) and you
-           also want the upstream tracking to be set. Workflows most likely to
-           benefit from this option are simple central workflows where all
-           branches are expected to have the same name on the remote.
-
-       push.default
-           Defines the action git push should take if no refspec is given
-           (whether from the command-line, config, or elsewhere). Different
-           values are well-suited for specific workflows; for instance, in a
-           purely central workflow (i.e. the fetch source is equal to the push
-           destination), upstream is probably what you want. Possible values
-           are:
-
-           •   nothing - do not push anything (error out) unless a refspec is
-               given. This is primarily meant for people who want to avoid
-               mistakes by always being explicit.
-
-           •   current - push the current branch to update a branch with the
-               same name on the receiving end. Works in both central and
-               non-central workflows.
-
-           •   upstream - push the current branch back to the branch whose
-               changes are usually integrated into the current branch (which is
-               called @{upstream}). This mode only makes sense if you are
-               pushing to the same repository you would normally pull from
-               (i.e. central workflow).
-
-           •   tracking - This is a deprecated synonym for upstream.
-
-           •   simple - push the current branch with the same name on the
-               remote.
-
-               If you are working on a centralized workflow (pushing to the
-               same repository you pull from, which is typically origin), then
-               you need to configure an upstream branch with the same name.
-
-               This mode is the default since Git 2.0, and is the safest option
-               suited for beginners.
-
-           •   matching - push all branches having the same name on both ends.
-               This makes the repository you are pushing to remember the set of
-               branches that will be pushed out (e.g. if you always push maint
-               and master there and no other branches, the repository you push
-               to will have these two branches, and your local maint and master
-               will be pushed there).
-
-               To use this mode effectively, you have to make sure all the
-               branches you would push out are ready to be pushed out before
-               running git push, as the whole point of this mode is to allow
-               you to push all of the branches in one go. If you usually finish
-               work on only one branch and push out the result, while other
-               branches are unfinished, this mode is not for you. Also this
-               mode is not suitable for pushing into a shared central
-               repository, as other people may add new branches there, or
-               update the tip of existing branches outside your control.
-
-               This used to be the default, but not since Git 2.0 (simple is
-               the new default).
-
-       push.followTags
-           If set to true, enable --follow-tags option by default. You may
-           override this configuration at time of push by specifying
-           --no-follow-tags.
-
-       push.gpgSign
-           May be set to a boolean value, or the string if-asked. A true value
-           causes all pushes to be GPG signed, as if --signed is passed to git-
-           push(1). The string if-asked causes pushes to be signed if the
-           server supports it, as if --signed=if-asked is passed to git push. A
-           false value may override a value from a lower-priority config file.
-           An explicit command-line flag always overrides this config option.
-
-       push.pushOption
-           When no --push-option=<option> argument is given from the command
-           line, git push behaves as if each <value> of this variable is given
-           as --push-option=<value>.
-
-           This is a multi-valued variable, and an empty value can be used in a
-           higher priority configuration file (e.g.  .git/config in a
-           repository) to clear the values inherited from a lower priority
-           configuration files (e.g.  $HOME/.gitconfig).
-
-               Example:
-
-               /etc/gitconfig
-                 push.pushoption = a
-                 push.pushoption = b
-
-               ~/.gitconfig
-                 push.pushoption = c
-
-               repo/.git/config
-                 push.pushoption =
-                 push.pushoption = b
-
-               This will result in only b (a and c are cleared).
-
-       push.recurseSubmodules
-           May be "check", "on-demand", "only", or "no", with the same behavior
-           as that of "push --recurse-submodules". If not set, no is used by
-           default, unless submodule.recurse is set (in which case a true value
-           means on-demand).
-
-       push.useForceIfIncludes
-           If set to "true", it is equivalent to specifying --force-if-includes
-           as an option to git-push(1) in the command line. Adding
-           --no-force-if-includes at the time of push overrides this
-           configuration setting.
-
-       push.negotiate
-           If set to "true", attempt to reduce the size of the packfile sent by
-           rounds of negotiation in which the client and the server attempt to
-           find commits in common. If "false", Git will rely solely on the
-           server’s ref advertisement to find commits in common.
-
-       push.useBitmaps
-           If set to "false", disable use of bitmaps for "git push" even if
-           pack.useBitmaps is "true", without preventing other git operations
-           from using bitmaps. Default is true.
-
-GIT
-       Part of the git(1) suite
-
-Git 2.48.1                         01/14/2025                       GIT-PUSH(1)

webpage/about.html

@@ -21,7 +21,6 @@
 		<a href="donate.html">Donations</a>
 		<a href="patchnotes.html" id="afix">Patch notes</a>
 		<a href="screenshots.html" id="afix">Screenshots</a>
-		<a href="https://git.x1b.dev/waterjones/y2k.website" target="_blank">Source code</a>
 	<h4>[Communication]</h4>
 		<a href="irc.html">IRC</a>
 		<a href="mailto:y2k.cs@proton.me">Email</a>
@@ -47,11 +46,10 @@
 <center>
 	<div>
 		<p id="smoltext">powered by nostalgia 2023-2025 - page written by waterjones
-		<br>last edited on: Wednesday, January 29th, 2025 @ 15:57 EET<br> email us: y2k.cs@proton.me</p>
+		<br>last edited on: Tuesday, January 28th, 2025 @ 11:17 EET<br> email us: y2k.cs@proton.me</p>
 		<a href="https://wiby.org/" id="aimage" target="_blank"><img width="88px" height="31px" src="https://wiby.org/about/wiby.org.gif" alt="wiby.org"></a>
 		<a href="https://www.w3schools.com/html/html_responsive.asp" id="aimage" target="_blank"><img width="88px" height="31px" src="https://seirdy.one/p/b/mobilefriendly.1035495686.png" alt="we're mobile friendly now!"></a>
-		<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
+				<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
-		<a href="https://git.x1b.dev/" id="aimage" target="_blank"><img width="88px" height="31px" src="x1b.png" alt="git.x1b.dev"></a>
 		<a href="https://ko-fi.com/waterjones" id="aimage" target="_blank"><img width="88px" height="31px" src="kofi.png" alt="consider supporting us"></a>
 		<a href="index.html" id="aimage"><img width="88px" height="31px" src="y2kcsbutton.png" alt="y2k.cs" target="_blank"></a>
 	</div>

webpage/donate.html

@@ -21,7 +21,6 @@
 		<a href="donate.html">Donations</a>
 		<a href="patchnotes.html" id="afix">Patch notes</a>
 		<a href="screenshots.html" id="afix">Screenshots</a>
-		<a href="https://git.x1b.dev/waterjones/y2k.website" target="_blank">Source code</a>
 	<h4>[Communication]</h4>
 		<a href="irc.html">IRC</a>
 		<a href="mailto:y2k.cs@proton.me">Email</a>
@@ -56,11 +55,10 @@
 <center>
 	<div>
 		<p id="smoltext">powered by nostalgia 2023-2025 - page written by waterjones
-		<br>last edited on: Wednesday, January 29th, 2025 @ 15:57 EET<br> email us: y2k.cs@proton.me</p>
+		<br>last edited on: Tuesday, January 28th, 2025 @ 11:18 EET<br> email us: y2k.cs@proton.me</p>
 		<a href="https://wiby.org/" id="aimage" target="_blank"><img width="88px" height="31px" src="https://wiby.org/about/wiby.org.gif" alt="wiby.org"></a>
 		<a href="https://www.w3schools.com/html/html_responsive.asp" id="aimage" target="_blank"><img width="88px" height="31px" src="https://seirdy.one/p/b/mobilefriendly.1035495686.png" alt="we're mobile friendly now!"></a>
 				<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
-		<a href="https://git.x1b.dev/" id="aimage" target="_blank"><img width="88px" height="31px" src="x1b.png" alt="git.x1b.dev"></a>
 		<a href="https://ko-fi.com/waterjones" id="aimage" target="_blank"><img width="88px" height="31px" src="kofi.png" alt="consider supporting us"></a>
 		<a href="index.html" id="aimage"><img width="88px" height="31px" src="y2kcsbutton.png" alt="y2k.cs" target="_blank"></a>
 	</div>

webpage/index.html

@@ -21,7 +21,6 @@
 		<a href="donate.html">Donations</a>
 		<a href="patchnotes.html" id="afix">Patch notes</a>
 		<a href="screenshots.html" id="afix">Screenshots</a>
-		<a href="https://git.x1b.dev/waterjones/y2k.website" target="_blank">Source code</a>
 	<h4>[Communication]</h4>
 		<a href="irc.html">IRC</a>
 		<a href="mailto:y2k.cs@proton.me">Email</a>
@@ -31,26 +30,6 @@
 	</p>
 </div>
 <div class="boxmiddle">
-	<h2>[Mobile & widescreen support]</h2> <h4>[Friday, January 31st, 2025]</h4>
-	<hr size="1" noshade>
-	<p>After a long battle with spaghetti code, we finally managed to make our website have the <b>"Responsive Web Design".</b> Now you can view this website on your phone without having to turn on the <b>Desktop mode!</b><br>
-	<span id="smoltext">The websites content has also been adjusted for more comfortable content viewing on widescreen resolutions.</p>
-	<figure>
-	<center>
-	<img src="responsive.gif" alt="Boxes go brrr" class="clickable-image" title="You can click & hold on the GIF to make it bigger.">
-	</center>
-	</figure>
-	<p>We moved the top bar navigation to the side, so everything is in one place & we also finished our <a href="donate.html" id="adless" style="color:white; text-decoration: none;"><b>donation</b></a> page so if you want to pitch in a euro or two, now you can.</p>
-	<p>We moved all the patch notes from our Discord server to here, so if you're curious about our history & progression, you can check it out <a href="patchnotes.html" id="adless" style="color: white; text-decoration: none;"><b>here!</b></a><br>
-	<span id="smoltext">I think there are some new patch notes from today!</span></p>
-	<p>This website's code is now open source & you can check it out at <a href="https://git.x1b.dev/waterjones/y2k.website" id="adless" style="text-decoration: none; color: white;"><b>git.x1b.dev!</b></a><br>
-	<span id="smoltext">Contributions for making our website more optimized are welcome as well.</p>
-	<p>We have moved from <b>quakenet.org</b> to <b>oftc.net</b> for our IRC chatroom.<br>
-	<span id="smoltext">You can use the <b style="color:grey;">/connect irc.oft.net</b> command to connect to the server and <b style="color:grey;">/join #y2k.cs</b> command to join our chatroom on your prefered IRC client. Or you can simply use the built-in qwebirc interface on our <a href="irc.html" id="adless">IRC</a> page.</p> 
-	<p>We're also happy to announce that you can now find us on <a href="https://wiby.org/" id="adless" style="color: white; text-decoration: none"><b>wiby.org!</b></a> So from now on, we will have a cool looking wiby.org badge at the bottom of our site with plenty of other late 90's inspired badges.<br>
-	<span id="smoltext">For those who are unaware, this search engine indexes old look-alike webpages with simple html code but you can also <a href="https://wiby.org/submit/"id="adless">submit</a> your own page on their search engine which is what we did. Didn't expect us to actually turn up on their search engine so that's pretty awesome!</span></p>
-	<p style="color:grey;"> [ waterjones ]</p>
-
 <h2>[Website changes]</h2> <h4>[Friday, January 24th, 2025]</h4>
 	<hr size="1" noshade>
 	<p>After a few days of work, we have improved our website. We have added a few new pages that you can go & visit if you're interested. We also applied lots of changes so lets get started!</p>
@@ -90,14 +69,14 @@
 <div class="box">
 		<h4>New Discord members:</h4>
 		<ol>
-		<li>mikjelis<br>
 		<li>friedman6523<br>
 		<li>robg6364<br>
+		<li>denimukas<br>
 		</ol>
 		<h4>Best #Deathmatch players:</h4>
 		<ol>
-		<li>y2k.kencarson<br>
 		<li>poppinbeans<br>
+		<li>y2k.leanlover2013<br>
 		<li>jFs<br>
 		</ol>
 		<h4>Best #Classic players:</h4>
@@ -112,11 +91,10 @@
 <center>
 	<div>
 		<p id="smoltext">powered by nostalgia 2023-2025 - page written by waterjones
-		<br>last edited on: Friday, January 31st, 2025 @ 08:56 EET<br> email us: y2k.cs@proton.me</p>
+		<br>last edited on: Tuesday, January 28th, 2025 @ 11:18 EET<br> email us: y2k.cs@proton.me</p>
 		<a href="https://wiby.org/" id="aimage" target="_blank"><img width="88px" height="31px" src="https://wiby.org/about/wiby.org.gif" alt="wiby.org"></a>
 		<a href="https://www.w3schools.com/html/html_responsive.asp" id="aimage" target="_blank"><img width="88px" height="31px" src="https://seirdy.one/p/b/mobilefriendly.1035495686.png" alt="we're mobile friendly now!"></a>
 				<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
-		<a href="https://git.x1b.dev/" id="aimage" target="_blank"><img width="88px" height="31px" src="x1b.png" alt="git.x1b.dev"></a>
 		<a href="https://ko-fi.com/waterjones" id="aimage" target="_blank"><img width="88px" height="31px" src="kofi.png" alt="consider supporting us"></a>
 		<a href="index.html" id="aimage"><img width="88px" height="31px" src="y2kcsbutton.png" alt="y2k.cs" target="_blank"></a>
 		</div>

webpage/irc.html

@@ -21,7 +21,6 @@
 		<a href="donate.html">Donations</a>
 		<a href="patchnotes.html" id="afix">Patch notes</a>
 		<a href="screenshots.html" id="afix">Screenshots</a>
-		<a href="https://git.x1b.dev/waterjones/y2k.website" target="_blank">Source code</a>
 	<h4>[Communication]</h4>
 		<a href="irc.html">IRC</a>
 		<a href="mailto:y2k.cs@proton.me">Email</a>
@@ -30,16 +29,15 @@
 	<a href="http://users4.smartgb.com/g/g.php?a=s&i=g44-82757-3d" id="afix">Guestbook</a>
 	</p>
 </div>
-<iframe src="https://webchat.oftc.net/?channels=y2k.cs&uio=OT10cnVlJjExPTEzMw1a"></iframe>
+<iframe src="http://webchat.quakenet.org/?channels=#y2k.cs&uio=d4"></iframe>
 </div>
 <center>
 	<div>
 		<p id="smoltext">powered by nostalgia 2023-2025 - page written by waterjones
-		<br>last edited on: Wednesday, January 29th, 2025 @ 18:32 EET<br> email us: y2k.cs@proton.me</p>
+		<br>last edited on: Tuesday, January 28th, 2025 @ 11:17 EET<br> email us: y2k.cs@proton.me</p>
 		<a href="https://wiby.org/" id="aimage" target="_blank"><img width="88px" height="31px" src="https://wiby.org/about/wiby.org.gif" alt="wiby.org"></a>
 		<a href="https://www.w3schools.com/html/html_responsive.asp" id="aimage" target="_blank"><img width="88px" height="31px" src="https://seirdy.one/p/b/mobilefriendly.1035495686.png" alt="we're mobile friendly now!"></a>
 				<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
-			<a href="https://git.x1b.dev/" id="aimage" target="_blank"><img width="88px" height="31px" src="x1b.png" alt="git.x1b.dev"></a>
 		<a href="https://ko-fi.com/waterjones" id="aimage" target="_blank"><img width="88px" height="31px" src="kofi.png" alt="consider supporting us"></a>
 		<a href="index.html" id="aimage"><img width="88px" height="31px" src="y2kcsbutton.png" alt="y2k.cs" target="_blank"></a>
 	</div>

webpage/maplist.html

@@ -21,7 +21,6 @@
 		<a href="donate.html">Donations</a>
 		<a href="patchnotes.html" id="afix">Patch notes</a>
 		<a href="screenshots.html" id="afix">Screenshots</a>
-		<a href="https://git.x1b.dev/waterjones/y2k.website" target="_blank">Source code</a>
 	<h4>[Communication]</h4>
 		<a href="irc.html">IRC</a>
 		<a href="mailto:y2k.cs@proton.me">Email</a>
@@ -145,11 +144,10 @@
 <center>
 	<div>
 		<p id="smoltext">powered by nostalgia 2023-2025 - page written by waterjones
-		<br>last edited on: Wednesday, January 29th, 2025 @ 15:59 EET<br> email us: y2k.cs@proton.me</p>
+		<br>last edited on: Tuesday, January 28th, 2025 @ 11:19 EET<br> email us: y2k.cs@proton.me</p>
 		<a href="https://wiby.org/" id="aimage" target="_blank"><img width="88px" height="31px" src="https://wiby.org/about/wiby.org.gif" alt="wiby.org"></a>
 		<a href="https://www.w3schools.com/html/html_responsive.asp" id="aimage" target="_blank"><img width="88px" height="31px" src="https://seirdy.one/p/b/mobilefriendly.1035495686.png" alt="we're mobile friendly now!"></a>
-		<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
+				<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
-		<a href="https://git.x1b.dev/" id="aimage" target="_blank"><img width="88px" height="31px" src="x1b.png" alt="git.x1b.dev"></a>
 		<a href="https://ko-fi.com/waterjones" id="aimage" target="_blank"><img width="88px" height="31px" src="kofi.png" alt="consider supporting us"></a>
 		<a href="index.html" id="aimage"><img width="88px" height="31px" src="y2kcsbutton.png" alt="y2k.cs" target="_blank"></a>
 	</div>

webpage/patchnotes.html

@@ -21,7 +21,6 @@
 		<a href="donate.html">Donations</a>
 		<a href="patchnotes.html" id="afix">Patch notes</a>
 		<a href="screenshots.html" id="afix">Screenshots</a>
-		<a href="https://git.x1b.dev/waterjones/y2k.website" target="_blank">Source code</a>
 	<h4>[Communication]</h4>
 		<a href="irc.html">IRC</a>
 		<a href="mailto:y2k.cs@proton.me">Email</a>
@@ -31,32 +30,6 @@
 	</p>
 </div>
 <div class="boxmiddleright">
-<h2> [v1.05]
-<h4>[Friday, January 31st, 2025]</h4>
-<hr size="1" noshade>
-<h4>[Discord Server Changes]</h4>
-	<ul>
-	<li>Removed un-used channels
-	<li>Changed the <b>#patch-notes</b> format.
-	</ul>
-<h4>[Counter-Strike 1.6 Server Changes]</h4>
-	<p>Changes for <b>#Classic</b></p>
-	<ul>
-	<li>The round time has been increased from <b>1:45</b> to <b>2:30</b> minutes.<br>
-	<span id="smoltext">The time limit is still kept at 90 minutes.</span>
-	<li>We introduced a win limit. Win <b>sixteen</b> rounds for a map change to occur.<br>
-	<span id="smoltext">The round limit is still kept at 30 rounds.</span>
-	<li>We changed how spectating works. Now you can spectate your own team in <b>first-person only.</b>
-	<li>Players now can <b>chat with spectators</b> & vise versa.<br>
-	<span id="smoltext">More testing is needed.</span>
-	</ul>
-	<p>Changed for <b>#Deathmatch</b></p>
-	<ul>
-	<li>There's a chance that players on T side would <b>spawn with a C4 on defuse maps</b>. That's no longer the case.
-	<li>Players can <b>chat with spectators</b> as well.
-	</ul>
-<p style="color:grey;">[ waterjones ]</p>
-
 <h2>[v1.0]</h2>
 <h4>[Friday, January 17th, 2025]</h4>
 <hr size="1" noshade>
@@ -491,11 +464,10 @@ Upcoming projects:
 <center>
 	<div>
 		<p id="smoltext">powered by nostalgia 2023-2025 - page written by waterjones
-		<br>last edited on: Friday, January 31st, 2025 @ 08:51 EET<br> email us: y2k.cs@proton.me</p>
+		<br>last edited on: Tuesday, January 28th, 2025 @ 11:19 EET<br> email us: y2k.cs@proton.me</p>
 		<a href="https://wiby.org/" id="aimage" target="_blank"><img width="88px" height="31px" src="https://wiby.org/about/wiby.org.gif" alt="wiby.org"></a>
 		<a href="https://www.w3schools.com/html/html_responsive.asp" id="aimage" target="_blank"><img width="88px" height="31px" src="https://seirdy.one/p/b/mobilefriendly.1035495686.png" alt="we're mobile friendly now!"></a>
 				<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
-		<a href="https://git.x1b.dev/" id="aimage" target="_blank"><img width="88px" height="31px" src="x1b.png" alt="git.x1b.dev"></a>
 		<a href="https://ko-fi.com/waterjones" id="aimage" target="_blank"><img width="88px" height="31px" src="kofi.png" alt="consider supporting us"></a>
 		<a href="index.html" id="aimage"><img width="88px" height="31px" src="y2kcsbutton.png" alt="y2k.cs" target="_blank"></a>
 	</div>

webpage/rules.html

@@ -21,7 +21,6 @@
 		<a href="donate.html">Donations</a>
 		<a href="patchnotes.html" id="afix">Patch notes</a>
 		<a href="screenshots.html" id="afix">Screenshots</a>
-		<a href="https://git.x1b.dev/waterjones/y2k.website" target="_blank">Source code</a>
 	<h4>[Communication]</h4>
 		<a href="irc.html">IRC</a>
 		<a href="mailto:y2k.cs@proton.me">Email</a>
@@ -63,11 +62,10 @@
 <div>
 <center>
 		<p id="smoltext">powered by nostalgia 2023-2025 - page written by waterjones
-		<br>last edited on: Wednesday, January 29th, 2025 @ 15:59 EET<br> email us: y2k.cs@proton.me</p>
+		<br>last edited on: Tuesday, January 28th, 2025 @ 11:19 EET<br> email us: y2k.cs@proton.me</p>
 		<a href="https://wiby.org/" id="aimage" target="_blank"><img width="88px" height="31px" src="https://wiby.org/about/wiby.org.gif" alt="wiby.org"></a>
 		<a href="https://www.w3schools.com/html/html_responsive.asp" id="aimage" target="_blank"><img width="88px" height="31px" src="https://seirdy.one/p/b/mobilefriendly.1035495686.png" alt="we're mobile friendly now!"></a>
 				<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
-			<a href="https://git.x1b.dev/" id="aimage" target="_blank"><img width="88px" height="31px" src="x1b.png" alt="git.x1b.dev"></a>
 		<a href="https://ko-fi.com/waterjones" id="aimage" target="_blank"><img width="88px" height="31px" src="kofi.png" alt="consider supporting us"></a>
 		<a href="index.html" id="aimage"><img width="88px" height="31px" src="y2kcsbutton.png" alt="y2k.cs" target="_blank"></a>
 </center>

webpage/screenshots.html

@@ -21,7 +21,6 @@
 		<a href="donate.html">Donations</a>
 		<a href="patchnotes.html" id="afix">Patch notes</a>
 		<a href="screenshots.html" id="afix">Screenshots</a>
-		<a href="https://git.x1b.dev/waterjones/y2k.website" target="_blank">Source code</a>
 	<h4>[Communication]</h4>
 		<a href="irc.html">IRC</a>
 		<a href="mailto:y2k.cs@proton.me">Email</a>
@@ -67,18 +66,17 @@
 	</span>
 	</figcaption>
 	</figure>
-	<p id="smoltext">You can contribute to this gallery by sending your screenshots to our email. We would also highly appreciate if the screenshots were taken in an aspect ratio of 4:3 or 5:4. Any screenshots that were taken in any other aspect ratio will be automatically dismissed unless the screenshots are stretched but retain 4:3 aspect ratio after editing.</p>
+	<p id="smoltext">You can contribute to this gallery by sending your screenshots to our email.</p>
 	</center>
 </div>
 </div>
 <center>
 	<div>
 		<p id="smoltext">powered by nostalgia 2023-2025 - page written by waterjones
-		<br>last edited on: Thursday, January 30th, 2025 @ 11:48 EET<br> email us: y2k.cs@proton.me</p>
+		<br>last edited on: Tuesday, January 28th, 2025 @ 11:19 EET<br> email us: y2k.cs@proton.me</p>
 		<a href="https://wiby.org/" id="aimage" target="_blank"><img width="88px" height="31px" src="https://wiby.org/about/wiby.org.gif" alt="wiby.org"></a>
 		<a href="https://www.w3schools.com/html/html_responsive.asp" id="aimage" target="_blank"><img width="88px" height="31px" src="https://seirdy.one/p/b/mobilefriendly.1035495686.png" alt="we're mobile friendly now!"></a>
-		<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
+				<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
-		<a href="https://git.x1b.dev/" id="aimage" target="_blank"><img width="88px" height="31px" src="x1b.png" alt="git.x1b.dev"></a>
 		<a href="https://ko-fi.com/waterjones" id="aimage" target="_blank"><img width="88px" height="31px" src="kofi.png" alt="consider supporting us"></a>
 		<a href="index.html" id="aimage"><img width="88px" height="31px" src="y2kcsbutton.png" alt="y2k.cs" target="_blank"></a>
 	</div>

webpage/servers.html

@@ -21,7 +21,6 @@
 		<a href="donate.html">Donations</a>
 		<a href="patchnotes.html">Patch notes</a>
 		<a href="screenshots.html">Screenshots</a>
-		<a href="https://git.x1b.dev/waterjones/y2k.website" target="_blank">Source code</a>
 	<h4>[Communication]</h4>
 		<a href="irc.html">IRC</a>
 		<a href="mailto:y2k.cs@proton.me">Email</a>
@@ -34,11 +33,10 @@
 </div>
 <center>
 		<p id="smoltext">powered by nostalgia 2023-2025 - page written by waterjones
-		<br>last edited on: Wednesday, January 29th, 2025 @ 16:00 EET<br> email us: y2k.cs@proton.me</p>
+		<br>last edited on: Tuesday, January 28th, 2025 @ 11:20 EET<br> email us: y2k.cs@proton.me</p>
 		<a href="https://wiby.org/" id="aimage" target="_blank"><img width="88px" height="31px" src="https://wiby.org/about/wiby.org.gif" alt="wiby.org"></a>
 		<a href="https://www.w3schools.com/html/html_responsive.asp" id="aimage" target="_blank"><img width="88px" height="31px" src="https://seirdy.one/p/b/mobilefriendly.1035495686.png" alt="we're mobile friendly now!"></a>
-		<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
+				<a href="https://micro-editor.github.io/" id="aimage" target="_blank"><img width="88px" height="31px" src="micro.png" alt="this website was written on Micro"></a>
-		<a href="https://git.x1b.dev/" id="aimage" target="_blank"><img width="88px" height="31px" src="x1b.png" alt="git.x1b.dev"></a>
 		<a href="https://ko-fi.com/waterjones" id="aimage" target="_blank"><img width="88px" height="31px" src="kofi.png" alt="consider supporting us"></a>
 		<a href="index.html" id="aimage"><img width="88px" height="31px" src="y2kcsbutton.png" alt="y2k.cs" target="_blank"></a>
 </center>

webpage/style.css

@@ -1,21 +1,35 @@
 * {
 	box-sizing: border-box;
 }
+/*
+.foo {
+  display: -webkit-box;
+  display: -moz-box;
+  display: -ms-flexbox;
+  display: -webkit-flex;
+  display: flex;
+  -webkit-box-orient: horizontal;
+  -moz-box-orient: horizontal;
+  -webkit-box-direction: normal;
+  -moz-box-direction: normal;
+  -webkit-flex-direction: row;
+  -ms-flex-direction: row;
+  flex-direction: row;
+}
+*/
 body {
  font-family: Arial, Helvetica, sans-serif;
  font-size: 12px;
  line-height: 14px;
  background-color: black;
  padding: 0.5%;
- margin-left: 20%;
- margin-right: 20%;
 }
 html * {
  color: white;
 }
 @font-face {
  font-family: 'Draco';
- src: url('https://y2kcs.neocities.org/Draco/Draco.otf');
+ src: url('Draco/Draco.otf');
  format("opentype");
 }
 a {
@@ -47,13 +61,13 @@ hr {
  color: grey;
 }
 .clickable-image {
- width: 80%;
+ width: 60%;
  height: auto;
  object-fit: cover;
  border: 1px solid #fff;
 }
 .clickable-image:active {
- width:100%;
+ width:70%;
  height:auto;
 }
 a:hover {
@@ -115,22 +129,6 @@ iframe {
 	word-wrap: break-word;
 	width: 85%;
 }
-@media only screen and (max-width: 1440px) {
-/*HD 4:3 PC resolutions*/
- body {
-  margin-left: 10%;
-  margin-right: 10%;
- }
-}
-@media only screen and (max-width: 1024px) {
-/*smaller 4:3 PC resolutions*/
- body {
-  margin-left: 0%;
-  margin-right: 0%;
-  padding-left: 12px;
-  padding-right: 12px
- }
-}
 @media only screen and (max-width: 750px) {
 /* mobile phones*/
  .box, .container {
@@ -153,13 +151,13 @@ iframe {
   width:100%;
  }
  .clickable-image {
-  width: 90%;
+  width: 80%;
   height: auto;
   object-fit: cover;
   border: 1px solid #fff;
  }
  .clickable-image:active {
-  width:100%;
+  width:90%;
   height:auto;
  }
 }