0 0

Cheap Git 2.27.0 Hosting Recommendation

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.

What’s New on Git 2.27.0?

Git 2.27 Release Notes
======================

Updates since v2.26
——————-

Backward compatibility notes

* When “git describe C” finds that commit C is pointed by a signed or
annotated tag, which records T as its tagname in the object, the
command gives T as its answer. Even if the user renames or moves
such a tag from its natural location in the “refs/tags/” hierarchy,
“git describe C” would still give T as the answer, but in such a
case “git show T^0” would no longer work as expected. There may be
nothing at “refs/tags/T” or even worse there may be a different tag
instead.

Starting from this version, “git describe” will always use the
“long” version, as if the “–long” option were given, when giving
its output based on such a misplaced tag to work around the problem.

* “git pull” issues a warning message until the pull.rebase
configuration variable is explicitly given, which some existing
users may find annoying—those who prefer not to rebase need to
set the variable to false to squelch the warning.

* The transport protocol version 2, which was promoted to the default
in Git 2.26 release, turned out to have some remaining rough edges,
so it has been demoted from the default.

UI, Workflows & Features

* A handful of options to configure SSL when talking to proxies have
been added.

* Smudge/clean conversion filters are now given more information
(e.g. the object of the tree-ish in which the blob being converted
appears, in addition to its path, which has already been given).

* When “git describe C” finds an annotated tag with tagname A to be
the best name to explain commit C, and the tag is stored in a
“wrong” place in the refs/tags hierarchy, e.g. refs/tags/B, the
command gave a warning message but used A (not B) to describe C.
If C is exactly at the tag, the describe output would be “A”, but
“git rev-parse A^0” would not be equal as “git rev-parse C^0”. The
behavior of the command has been changed to use the “long” form
i.e. A-0-gOBJECTNAME, which is correctly interpreted by rev-parse.

* “git pull” learned to warn when no pull.rebase configuration
exists, and neither –[no-]rebase nor –ff-only is given (which
would result a merge).

* “git p4” learned four new hooks and also “–no-verify” option to
bypass them (and the existing “p4-pre-submit” hook).

* “git pull” shares many options with underlying “git fetch”, but
some of them were not documented and some of those that would make
sense to pass down were not passed down.

* “git rebase” learned the “–no-gpg-sign” option to countermand
commit.gpgSign the user may have.

* The output from “git format-patch” uses RFC 2047 encoding for
non-ASCII letters on From: and Subject: headers, so that it can
directly be fed to e-mail programs. A new option has been added
to produce these headers in raw.

* “git log” learned “–show-pulls” that helps pathspec limited
history views; a merge commit that takes the whole change from a
side branch, which is normally omitted from the output, is shown
in addition to the commits that introduce real changes.

* The interactive input from various codepaths are consolidated and
any prompt possibly issued earlier are fflush()ed before we read.

* Allow “git rebase” to reapply all local commits, even if the may be
already in the upstream, without checking first.

* The ‘pack.useSparse’ configuration variable now defaults to ‘true’,
enabling an optimization that has been experimental since Git 2.21.

* “git rebase” happens to call some hooks meant for “checkout” and
“commit” by this was not a designed behaviour than historical
accident. This has been documented.

* “git merge” learns the “–autostash” option.

* “sparse-checkout” UI improvements.

* “git update-ref –stdin” learned a handful of new verbs to let the
user control ref update transactions more explicitly, which helps
as an ingredient to implement two-phase commit-style atomic
ref-updates across multiple repositories.

* “git commit-graph write” learned different ways to write out split
files.

* Introduce an extension to the commit-graph to make it efficient to
check for the paths that were modified at each commit using Bloom
filters.

* The approxidate parser learns to parse seconds with fraction and
ignore fractional part.

* The userdiff patterns for Markdown documents have been added.

* The sparse-checkout patterns have been forbidden from excluding all
paths, leaving an empty working tree, for a long time. This
limitation has been lifted.

* “git restore –staged –worktree” now defaults to take the contents
out of “HEAD”, instead of erring out.

* “git p4” learned to recover from a (broken) state where a directory
and a file are recorded at the same path in the Perforce repository
the same way as their clients do.

* “git multi-pack-index repack” has been taught to honor some
repack.* configuration variables.

Performance, Internal Implementation, Development Support etc.

* The advise API has been revamped to allow more systematic enumeration of
advice knobs in the future.

* SHA-256 transition continues.

* The code to interface with GnuPG has been refactored.

* “git stash” has kept an escape hatch to use the scripted version
for a few releases, which got stale. It has been removed.

* Enable tests that require GnuPG on Windows.

* Minor test usability improvement.

* Trace2 enhancement to allow logging of the environment variables.

* Test clean-up continues.

* Perf-test update.

* A Windows-specific test element has been made more robust against
misuse from both user’s environment and programmer’s errors.

* Various tests have been updated to work around issues found with
shell utilities that come with busybox etc.

* The config API made mixed uses of int and size_t types to represent
length of various pieces of text it parsed, which has been updated
to use the correct type (i.e. size_t) throughout.

* The “–decorate-refs” and “–decorate-refs-exclude” options “git
log” takes have learned a companion configuration variable
log.excludeDecoration that sits at the lowest priority in the
family.

* A new CI job to build and run test suite on linux with musl libc
has been added.

* Update the CI configuration to use GitHub Actions, retiring the one
based on Azure Pipelines.

* The directory traversal code had redundant recursive calls which
made its performance characteristics exponential with respect to
the depth of the tree, which was corrected.

* “git blame” learns to take advantage of the “changed-paths” Bloom
filter stored in the commit-graph file.

* The “bugreport” tool has been added.

* The object walk with object filter “–filter=tree:0” can now take
advantage of the pack bitmap when available.

* Instead of always building all branches at GitHub via Actions,
users can specify which branches to build.

* Codepaths that show progress meter have been taught to also use the
start_progress() and the stop_progress() calls as a “region” to be
traced.

* Instead of downloading Windows SDK for CI jobs for windows builds
from an external site (wingit.blob.core.windows.net), use the one
created in the windows-build job, to work around quota issues at
the external site.

Fixes since v2.26
—————–

* The real_path() convenience function can easily be misused; with a
bit of code refactoring in the callers’ side, its use has been
eliminated.
(merge 49d3c4b481 am/real-path-fix later to maint).

* Update “git p4” to work with Python 3.
(merge 6bb40ed20a yz/p4-py3 later to maint).

* The mechanism to prevent “git commit” from making an empty commit
or amending during an interrupted cherry-pick was broken during the
rewrite of “git rebase” in C, which has been corrected.
(merge 430b75f720 pw/advise-rebase-skip later to maint).

* Fix “git checkout –recurse-submodules” of a nested submodule
hierarchy.
(merge 846f34d351 pb/recurse-submodules-fix later to maint).

* The “–fork-point” mode of “git rebase” regressed when the command
was rewritten in C back in 2.20 era, which has been corrected.
(merge f08132f889 at/rebase-fork-point-regression-fix later to maint).

* The import-tars importer (in contrib/fast-import/) used to create
phony files at the top-level of the repository when the archive
contains global PAX headers, which made its own logic to detect and
omit the common leading directory ineffective, which has been
corrected.
(merge c839fcff65 js/import-tars-do-not-make-phony-files-from-pax-headers later to maint).

* Simplify the commit ancestry connectedness check in a partial clone
repository in which “promised” objects are assumed to be obtainable
lazily on-demand from promisor remote repositories.
(merge 2b98478c6f jt/connectivity-check-optim-in-partial-clone later to maint).

* The server-end of the v2 protocol to serve “git clone” and “git
fetch” was not prepared to see a delim packets at unexpected
places, which led to a crash.
(merge cacae4329f jk/harden-protocol-v2-delim-handling later to maint).

* When fed a midx that records no objects, some codepaths tried to
loop from 0 through (num_objects-1), which, due to integer
arithmetic wrapping around, made it nonsense operation with out of
bounds array accesses. The code has been corrected to reject such
an midx file.
(merge 796d61cdc0 dr/midx-avoid-int-underflow later to maint).

* Utitiles run via the run_command() API were not spawned correctly
on Cygwin, when the paths to them are given as a full path with
backslashes.
(merge 05ac8582bc ak/run-command-on-cygwin-fix later to maint).

* “git pull –rebase” tried to run a rebase even after noticing that
the pull results in a fast-forward and no rebase is needed nor
sensible, for the past few years due to a mistake nobody noticed.
(merge fbae70ddc6 en/pull-do-not-rebase-after-fast-forwarding later to maint).

* “git rebase” with the merge backend did not work well when the
rebase.abbreviateCommands configuration was set.
(merge de9f1d3ef4 ag/rebase-merge-allow-ff-under-abbrev-command later to maint).

* The logic to auto-follow tags by “git clone –single-branch” was
not careful to avoid lazy-fetching unnecessary tags, which has been
corrected.
(merge 167a575e2d jk/use-quick-lookup-in-clone-for-tag-following later to maint).

* “git rebase -i” did not leave the reflog entries correctly.
(merge 1f6965f994 en/sequencer-reflog-action later to maint).

* The more aggressive updates to remote-tracking branches we had for
the past 7 years or so were not reflected in the documentation,
which has been corrected.
(merge a44088435c pb/pull-fetch-doc later to maint).

* We’ve left the command line parsing of “git log :/a/b/” broken for
about a full year without anybody noticing, which has been
corrected.
(merge 0220461071 jc/missing-ref-store-fix later to maint).

* Misc fixes for Windows.
(merge 3efc128cd5 js/mingw-fixes later to maint).

* “git rebase” (again) learns to honor “–no-keep-empty”, which lets
the user to discard commits that are empty from the beginning (as
opposed to the ones that become empty because of rebasing). The
interactive rebase also marks commits that are empty in the todo.
(merge 50ed76148a en/rebase-no-keep-empty later to maint).

* Parsing the host part out of URL for the credential helper has been corrected.
(merge 4c5971e18a jk/credential-parsing-end-of-host-in-URL later to maint).

* Document the recommended way to abort a failing test early (e.g. by
exiting a loop), which is to say “return 1”.
(merge 7cc112dc95 jc/doc-test-leaving-early later to maint).

* The code that refreshes the last access and modified time of
on-disk packfiles and loose object files have been updated.
(merge 312cd76130 lr/freshen-file-fix later to maint).

* Validation of push certificate has been made more robust against
timing attacks.
(merge 719483e547 bc/constant-memequal later to maint).

* The custom hash function used by “git fast-import” has been
replaced with the one from hashmap.c, which gave us a nice
performance boost.
(merge d8410a816b jk/fast-import-use-hashmap later to maint).

* The “git submodule” command did not initialize a few variables it
internally uses and was affected by variable settings leaked from
the environment.
(merge 65d100c4dd lx/submodule-clear-variables later to maint).

* Raise the minimum required version of docbook-xsl package to 1.74,
as 1.74.0 was from late 2008, which is more than 10 years old, and
drop compatibility cruft from our documentation suite.
(merge 3c255ad660 ma/doc-discard-docbook-xsl-1.73 later to maint).

* “git log” learns “–[no-]mailmap” as a synonym to “–[no-]use-mailmap”
(merge 88acccda38 jc/log-no-mailmap later to maint).

* “git commit-graph write –expire-time=<timestamp>” did not use the
given timestamp correctly, which has been corrected.
(merge b09b785c78 ds/commit-graph-expiry-fix later to maint).

* Tests update to use “test-chmtime” instead of “touch -t”.
(merge e892a56845 ds/t5319-touch-fix later to maint).

* “git diff” in a partial clone learned to avoid lazy loading blob
objects in more casese when they are not needed.
(merge 95acf11a3d jt/avoid-prefetch-when-able-in-diff later to maint).

* “git push –atomic” used to show failures for refs that weren’t
even pushed, which has been corrected.
(merge dfe1b7f19c jx/atomic-push later to maint).

* Code in builtin/*, i.e. those can only be called from within
built-in subcommands, that implements bulk of a couple of
subcommands have been moved to libgit.a so that they could be used
by others.
(merge 9460fd48b5 dl/libify-a-few later to maint).

* Allowing the user to split a patch hunk while “git stash -p” does
not work well; a band-aid has been added to make this (partially)
work better.

* “git diff-tree –pretty –notes” used to hit an assertion failure,
as it forgot to initialize the notes subsystem.
(merge 5778b22b3d tb/diff-tree-with-notes later to maint).

* “git range-diff” fixes.
(merge 8d1675eb7f vd/range-diff-with-custom-pretty-format-fix later to maint).

* “git grep” did not quote a path with unusual character like other
commands (like “git diff”, “git status”) do, but did quote when run
from a subdirectory, both of which has been corrected.
(merge 45115d8490 mt/grep-cquote-path later to maint).

* GNU/Hurd is also among the ones that need the fopen() wrapper.
(merge 274a1328fb jc/gnu-hurd-lets-fread-read-dirs later to maint).

* Those fetching over protocol v2 from linux-next and other kernel
repositories are reporting that v2 often fetches way too much than
needed.
(merge 11c7f2a30b jn/demote-proto2-from-default later to maint).

* The upload-pack protocol v2 gave up too early before finding a
common ancestor, resulting in a wasteful fetch from a fork of a
project. This has been corrected to match the behaviour of v0
protocol.
(merge 2f0a093dd6 jt/v2-fetch-nego-fix later to maint).

* The build procedure did not use the libcurl library and its include
files correctly for a custom-built installation.
(merge 0573831950 jk/build-with-right-curl later to maint).

* Tighten “git mailinfo” to notice and error out when decoded result
contains NUL in it.
(merge 3919997447 dd/mailinfo-with-nul later to maint).

* Fix in-core inconsistency after fetching into a shallow repository
that broke the code to write out commit-graph.
(merge 37b9dcabfc tb/reset-shallow later to maint).

* The commit-graph code exhausted file descriptors easily when it
does not have to.
(merge c8828530b7 tb/commit-graph-fd-exhaustion-fix later to maint).

* The multi-pack-index left mmapped file descriptors open when it
does not have to.
(merge 6c7ff7cf7f ds/multi-pack-index later to maint).

* Recent update to Homebrew used by macOS folks breaks build by
moving gettext library and necessary headers.
(merge a0b3108618 ds/build-homebrew-gettext-fix later to maint).

* Incompatible options “–root” and “–fork-point” of “git rebase”
have been marked and documented as being incompatible.
(merge a35413c378 en/rebase-root-and-fork-point-are-incompatible later to maint).

* Error and verbose trace messages from “git push” did not redact
credential material embedded in URLs.
(merge d192fa5006 js/anonymise-push-url-in-errors later to maint).

* Update the parser used for credential.<URL>.<variable>
configuration, to handle <URL>s with ‘/’ in them correctly.
(merge b44d0118ac bc/wildcard-credential later to maint).

* Recent updates broke parsing of “credential.<url>.<key>” where
<url> is not a full URL (e.g. [credential “https://”] helper = …)
stopped working, which has been corrected.
(merge 9a121b0d22 js/partial-urlmatch-2.17 later to maint).
(merge cd93e6c029 js/partial-urlmatch later to maint).

* Some of the files commit-graph subsystem keeps on disk did not
correctly honor the core.sharedRepository settings and some were
left read-write.

* In error messages that “git switch” mentions its option to create a
new branch, “-b/-B” options were shown, where “-c/-C” options
should be, which has been corrected.
(merge 7c16ef7577 dl/switch-c-option-in-error-message later to maint).

* With the recent tightening of the code that is used to parse
various parts of a URL for use in the credential subsystem, a
hand-edited credential-store file causes the credential helper to
die, which is a bit too harsh to the users. Demote the error
behaviour to just ignore and keep using well-formed lines instead.
(merge c03859a665 cb/credential-store-ignore-bogus-lines later to maint).

* The samples in the credential documentation has been updated to
make it clear that we depict what would appear in the .git/config
file, by adding appropriate quotes as needed..
(merge 177681a07e jk/credential-sample-update later to maint).

* “git branch” and other “for-each-ref” variants accepted multiple
–sort=<key> options in the increasing order of precedence, but it
had a few breakages around “–ignore-case” handling, and tie-breaking
with the refname, which have been fixed.
(merge 7c5045fc18 jk/for-each-ref-multi-key-sort-fix later to maint).

* The coding guideline for shell scripts instructed to refer to a
variable with dollar-sign inside arithmetic expansion to work
around a bug in old versions of dash, which is a thing of the past.
Now we are not forbidden from writing $((var+1)).
(merge 32b5fe7f0e jk/arith-expansion-coding-guidelines later to maint).

* The <stdlib.h> header on NetBSD brings in its own definition of
hmac() function (eek), which conflicts with our own and unrelated
function with the same name. Our function has been renamed to work
around the issue.
(merge 3013118eb8 cb/avoid-colliding-with-netbsd-hmac later to maint).

* The basic test did not honor $TEST_SHELL_PATH setting, which has
been corrected.
(merge 0555e4af58 cb/t0000-use-the-configured-shell later to maint).

* Minor in-code comments and documentation updates around credential
API.
(merge 1aed817f99 cb/credential-doc-fixes later to maint).

* Teach “am”, “commit”, “merge” and “rebase”, when they are run with
the “–quiet” option, to pass “–quiet” down to “gc –auto”.
(merge 7c3e9e8cfb jc/auto-gc-quiet later to maint).

* The code to skip unmerged paths in the index when sparse checkout
is in use would have made out-of-bound access of the in-core index
when the last path was unmerged, which has been corrected.

* Serving a “git fetch” client over “git://” and “ssh://” protocols
using the on-wire protocol version 2 was buggy on the server end
when the client needs to make a follow-up request to
e.g. auto-follow tags.
(merge 08450ef791 cc/upload-pack-v2-fetch-fix later to maint).

* “git bisect replay” had trouble with input files when they used
CRLF line ending, which has been corrected.
(merge 6c722cbe5a cw/bisect-replay-with-dos later to maint).

* “rebase -i” segfaulted when rearranging a sequence that has a
fix-up that applies another fix-up (which may or may not be a
fix-up of yet another step).
(merge 02471e7e20 js/rebase-autosquash-double-fixup-fix later to maint).

* “git fsck” ensures that the paths recorded in tree objects are
sorted and without duplicates, but it failed to notice a case where
a blob is followed by entries that sort before a tree with the same
name. This has been corrected.
(merge 9068cfb20f rs/fsck-duplicate-names-in-trees later to maint).

* Code clean-up by removing a compatibility implementation of a
function we no longer use.
(merge 84b0115f0d cb/no-more-gmtime later to maint).

* When a binary file gets modified and renamed on both sides of history
to different locations, both files would be written to the working
tree but both would have the contents from “ours”. This has been
corrected so that the path from each side gets their original content.

* Fix for a copy-and-paste error introduced during 2.20 era.
(merge e68a5272b1 ds/multi-pack-verify later to maint).

* Update an unconditional use of “grep -a” with a perl script in a test.
(merge 1eb7371236 dd/t5703-grep-a-fix later to maint).

* Other code cleanup, docfix, build fix, etc.
(merge 564956f358 jc/maintain-doc later to maint).
(merge 7422b2a0a1 sg/commit-slab-clarify-peek later to maint).
(merge 9c688735f6 rs/doc-passthru-fetch-options later to maint).
(merge 757c2ba3e2 en/oidset-uninclude-hashmap later to maint).
(merge 8312aa7d74 jc/config-tar later to maint).
(merge d00a5bdd50 ss/submodule-foreach-cb later to maint).
(merge 64d1022e14 ar/test-style-fixes later to maint).
(merge 4a465443a6 ds/doc-clone-filter later to maint).
(merge bb2dbe301b jk/t3419-drop-expensive-tests later to maint).
(merge d3507cc712 js/test-junit-finalization-fix later to maint).
(merge 2149b6748f bc/faq later to maint).
(merge 12dc0879f1 jk/test-cleanup later to maint).
(merge 344420bf0f pb/rebase-doc-typofix later to maint).
(merge 7cd54d37dc dl/wrapper-fix-indentation later to maint).
(merge 78725ebda9 jc/allow-strlen-substitution-in-shell-scripts later to maint).
(merge 2ecfcdecc6 jm/gitweb-fastcgi-utf8 later to maint).
(merge 0740d0a5d3 jk/oid-array-cleanups later to maint).
(merge a1aba0c95c js/t0007-typofix later to maint).
(merge 76ba7fa225 ma/config-doc-fix later to maint).
(merge 826f0c0df2 js/subtree-doc-update-to-asciidoctor-2 later to maint).
(merge 88eaf361e0 eb/mboxrd-doc later to maint).
(merge 051cc54941 tm/zsh-complete-switch-restore later to maint).
(merge 39102cf4fe ms/doc-revision-illustration-fix later to maint).
(merge 4d9378bfad eb/gitweb-more-trailers later to maint).
(merge bdccbf7047 mt/doc-worktree-ref later to maint).
(merge ce9baf234f dl/push-recurse-submodules-fix later to maint).
(merge 4153274052 bc/doc-credential-helper-value later to maint).
(merge 5c7bb0146e jc/codingstyle-compare-with-null later to maint).

Branching and Merging

The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model.

Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds.

This means that you can do things like:

• Frictionless Context Switching. Create a branch to try out an idea, commit a few times, switch back to where you branched from, apply a patch, switch back to where you are experimenting, and merge it in.
• Role-Based Codelines. Have a branch that always contains only what goes to production, another that you merge work into for testing, and several smaller ones for day to day work.
• Feature Based Workflow. Create new branches for each new feature you’re working on so you can seamlessly switch back and forth between them, then delete each branch when that feature gets merged into your main line.
• Disposable Experimentation. Create a branch to experiment in, realize it’s not going to work, and just delete it – abandoning the work—with nobody else ever seeing it (even if you’ve pushed other branches in the meantime).

Small and Fast

Git is fast. With Git, nearly all operations are performed locally, giving it a huge speed advantage on centralized systems that constantly have to communicate with a server somewhere.

Git was built to work on the Linux kernel, meaning that it has had to effectively handle large repositories from day one. Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Speed and performance has been a primary design goal of the Git from the start.

Benchmarks

Let’s see how common operations stack up against Subversion, a common centralized version control system that is similar to CVS or Perforce. Smaller is faster.

Distributed

One of the nicest features of any Distributed SCM, Git included, is that it’s distributed. This means that instead of doing a “checkout” of the current tip of the source code, you do a “clone” of the entire repository.

Multiple Backups

This means that even if you’re using a centralized workflow, every user essentially has a full backup of the main server. Each of these copies could be pushed up to replace the main server in the event of a crash or corruption. In effect, there is no single point of failure with Git unless there is only a single copy of the repository.

Any Workflow

Because of Git’s distributed nature and superb branching system, an almost endless number of workflows can be implemented with relative ease.

Subversion-Style Workflow

A centralized workflow is very common, especially from people transitioning from a centralized system. Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

Data Assurance

The data model that Git uses ensures the cryptographic integrity of every bit of your project. Every file and commit is checksummed and retrieved by its checksum when checked back out. It’s impossible to get anything out of Git other than the exact bits you put in.

Staging Area

Unlike the other systems, Git has something called the “staging area” or “index”. This is an intermediate area where commits can be formatted and reviewed before completing the commit.

One thing that sets Git apart from other tools is that it’s possible to quickly stage some of your files and commit them without committing all of the other modified files in your working directory or having to list them on the command line during the commit.

Free and Open Source

Git is released under the GNU General Public License version 2.0, which is an open source license. The Git project chose to use GPLv2 to guarantee your freedom to share and change free software—to make sure the software is free for all its users.

Are you looking for Cheap Git 2.27.0 Hosting? Finding a high quality Cheap Git 2.27.0 Hosting provider is crucial for your web application. Your Git 2.27.0 application can only run smooth if it will be hosted on a server which can provide a higher up time & plenty of computing resources. There’re thousands of web hosting providers which offer asp.net hosting, but choosing Cheap Git 2.27.0 Hosting provider is a time consuming task. To make your buying decision easy we’ve concluded 3 Best yet Cheap Git 2.27.0 Hosting providers which are reliable and offer affordable Git 2.27.0 Hosting so that every one can afford it.

Cheap Git 2.27.0 Hosting Recommendation

How to Choose Cheap Git 2.27.0 Hosting Recommendation?

Reliability and Speed of Access

Not only should the web host be reliable and fast, it should guarantee its uptime (the time when it is functional). Look for a minimum uptime of 99%. In fact, even 99% is actually too low — it really should be 99.5% or higher. The host should provide some sort of refund (eg prorated refund or discount) if it falls below that figure. Note though that guarantees are often hard to enforce from your end — especially if the host denies there was any downtime. However, without that guarantee, the web host will have little incentive to ensure that its servers are running all the time.

Data Transfer (Traffic/Bandwidth)

Data transfer (sometimes loosely referred to as “traffic” or “bandwidth”) is the amount of bytes transferred from your site to visitors when they browse your site.

Don’t believe any commercial web host that advertises “unlimited bandwidth”. The host has to pay for the bandwidth, and if you consume a lot of it, they will not silently bear your costs. Many high bandwidth websites have found this out the hard way when they suddenly receive an exorbitant bill for having “exceeded” the “unlimited bandwidth”. Always look for details on how much traffic the package allows. I personally always stay clear of any host that advertises “unlimited transfer”, even if the exact amount is specified somewhere else (sometimes buried in their policy statements). Usually you will find that they redefine “unlimited” to be limited in some way.

In addition, while bandwidth provided is something you should always check, do not be unduly swayed by promises of incredibly huge amounts of bandwidth. Chances are that your website will never be able to use that amount because it will hit other limits, namely resource limits.

To give you a rough idea of the typical traffic requirements of a website, most new sites that don’t provide video or music on their site use less than 3 GB of bandwidth per month. Your traffic requirements will grow over time, as your site becomes more well-known, so you will need to also check their policy when you exceed your data transfer limit: is there a published charge per GB over the allowed bandwidth? Is the charge made according to actual usage or are you expected to pre-pay for a potential overage? It is better not to go for hosts that expect you to prepay for overages, since it is very hard to forsee when your site will exceed its bandwidth and by how much.

Disk space

For the same reason as bandwidth, watch out also for those “unlimited disk space” schemes. Many new sites (that don’t host videos or music) need less than 20 MB of web space, so even if you are provided with a host that tempts you with 100 GB (or “unlimited space”), be aware that you are unlikely to use that space, so don’t let the 100 GB space be too big a factor in your consideration when comparing with other web hosts. The hosting company is also aware of that, which is why they feel free to offer you that as a means of enticing you to host there.

Technical support

Does its technical support function 24 hours a day, 7 days a week (often abbreviated 24/7), all year around? Note that I will not accept a host which does not have staff working on weekends or public holidays. You will be surprised at how often things go wrong at the most inconvenient of times. Incidentally, just because a host advertises that it has 24/7 support does not necessarily mean that it really has that kind of support. Test them out by emailing at midnight and on Saturday nights, Sunday mornings, etc. Check out how long they take to respond. Besides speed of responses, check to see if they are technically competent. You wouldn’t want to sign up with a host that is run by a bunch of salesmen who only know how to sell and not fix problems.

Email, Autoresponders, POP3, Mail Forwarding

If you have your own site, you will probably want to have email addresses at your own domain, like sales@yourdomain.com, etc. Does the host allow you to set up whatever email addresses you want on your domain, so that mail can be forwarded to your current email address, or placed into a mail box on your web hosting account itself? Can you set an email address to automatically reply to the sender with a preset message (called an autoresponder)? Can you retrieve your mail with your email software?

Control Panel

This is called various names by different hosts, but essentially, they all allow you to manage different aspects of your web account yourself. Typically, and at the very minimum, it should allow you to do things like add, delete, and manage your email addresses, and change passwords for your account. I will not sign up with a host where I have to go through their technical support each time I want to change a password or add/delete an email account. Such tasks are common maintenance chores that every webmaster performs time and time again, and it would be a great hassle if you had to wait for their technical support to make the changes for you.

Web Server and Operating System

Is the type of operating system and server important?

In general, most people will want to sign up for a web host offering a Unix-based system (like Linux, FreeBSD or OpenBSD) and running the Apache web server. Most web-based software assume your website is running on such a system, and you will usually experience fewer compatibility issues with it. There are also a lot of guides available on the Internet on configuring such systems, so finding help when you need it is easier as well.

In my opinion, the only time when you will want to use a Windows server is if you’re running Windows-specific programs, like ASP scripts. But even then, you’ll probably be better off looking for a PHP-equivalent, and using a Unix-based system.

Price

I was actually hesitant to list this, but I guess it’s futile not to. However, I would caution that while price is always a factor, you should realise (“realize” in US English) that you often get what you pay for, although it’s not necessarily true that the most expensive hosts are the best.

Monthly/Quarterly/Annual Payment Plans

Most web hosts allow you to select an annual payment plan that gives you a cheaper rate than if you were to pay monthly. My current personal preference is to pay monthly with all new web hosts until I’m assured of their reliability and honesty. Paying monthly allows me to switch web hosts quickly when I find that the current host does not meet my requirements: this way, I’m not tied down to a bad web host because I have prepaid for an entire year. I do this even if the new web host guarantees that they will refund the balance if I’m dissatisfied, since at the point I sign up, I have no assurance that they will honour their guarantee. Later (usually after a couple of years), when I’m satisfied with the host, I may change payment plans to the discounted annual plans.

Resellers?

Not all hosting companies own or lease their own web servers. Some of them are actually resellers for some other hosting company. The disadvantage of using a reseller is the possibility that you are dealing with people who don’t know much about the system they are selling and who take longer to help you (they have to transmit your technical support request to the actual hosting company for it to be acted upon). However, this also depends on both the reseller and the underlying hosting company. It is thus wise not to rule out all resellers; there are a number of reliable and fast ones who are actually quite good and cheap. In fact, a number of resellers sell the same packages cheaper than their original hosting company. If you find out that a particular company is a reseller, you will need to investigate both the reseller and the real hosting company.

International

If you don’t stay in the USA, you have the option of hosting your site with some local provider. The advantage here is the ease of dealing with them (they are after all easily accessible by phone call or a visit), your familiarity with the local laws and easy recourse to those laws should it be necessary. It should be your choice if your target audience is local (eg a local fast food delivery service). On the other hand, hosting it in USA has the advantage of faster access for what is probably the largest number of your overseas visitors (particularly if you have an English-speaking audience). You also have a large number of hosting companies to choose from, and as a result, cheaper prices too.

About Post Author

Anjali Punjab

anjalipunjabb@gmail.com

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %