Finally I bit the bullet and did a full sweep of this document.
The changes are mostly clarifications, adjusting old terminology
to the glossary compatible one, and asciidoc formatting.
Imports a project history from one or more Arch repositories, following
the branching and tagging across repositories. Note you should import
separate projects to separate GIT repositories.
Supported
- Imports, tags and simple commits.
- File renames
- Arch tags
- Binary files
- Large trees
- Multiple repositories
- Branches
TODO:
- Allow re-running the import on an already-imported project
- Follow merges using Arch data
- Audit shell escaping of filenames
- Better support for file metadata
- Better/safer creation of temp directories
Unsupported:
- Arch 'configuration'
[jc: my arch/tla is very rusty and after Tom announced he is stepping
down as the maintainer I have very little motivation to relearn it,
so I would appreciate if people discuss any bugs or enhancements
directly with Martin. Of course I can help with the git end of the
issues.]
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm testing bisection to find a bug that causes my G5 to no longer boot,
and during the process have found this command line very nice:
gitk bisect/bad --not $(cd .git/refs ; ls bisect/good-*)
it basically shows the state of bisection with the known bad commit as the
top, and cutting off all the good commits - so what you see are the
potential buggy commits.
When testing bisection and using gitk to visualize the result, it was
obvious that the termination condition was broken.
We know what the bad entry is only when the bisection ends up telling us
to test the known-bad entry again.
Also, add a safety net: if somebody marks as good something that includes
the known-bad point, we now notice and complain, instead of writing an
empty revision to the new bisection branch.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
parse-remote: trivial fix to allow refs/{heads,tags}/ spelled easier.
Earlier we always prefixed refs/heads to the token given to "git fetch"
(and "git pull") as refspec. This was a mistake. Allow them to be
spelled like "master:refs/tags/paulus" to mean "I want to fetch the
master there and store it as my local "paulus" tag.
When we resolve a merge between two branches, and it removes a file in the
current branch, we notify the person doing the resolve with a big nice
notice like
Removing xyzzy
which is all well and good.
HOWEVER, we also do this when the file was actually removed in the current
branch, and we're merging with another branch that didn't have it removed
(or, indeed, if the other branch _did_ have it removed, but the common
parent was far enough back that the file still existed in there).
And that just doesn't make sense. In that case we're not removing
anything: the file didn't exist in the branch we're merging into in the
first place. So the message just makes people nervous, and makes no sense.
This has been around forever, but I never bothered to do anything about
it.
Until now.
The trivial fix is to only talk about removing files if the file existed
in the branch we're merging into, but will not exist in the result.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not verify reverted/cherry-picked/rebased patches.
The original committer may have used validation criteria that is less
stricter than yours. You do not want to lose the changes even if they
are done in substandard way from your 'commit -v' verifier's point of
view.
git-repack-script: Add option to repack all objects.
This originally came from Frank Sorenson, but with a bit of rework to
allow future enhancements without changing the external interface for
pack pruning part.
With the '-a' option, all objects in the current repository are packed
into a single pack. When the '-d' option is given at the same time,
existing packs that were made redundant by this round of repacking are
deleted.
Since we currently have only two repacking strategies, one with '-a'
(everything into one) and the other without '-a' (incrementally pack
only the unpacked ones), the '-d' option is meaningful only when used
with '-a'; it removes the packs existed before we did the "everything
into one" repacking. At least for now.
Signed-off-by: Junio C Hamano <junkio@cox.net> Acked-by: Frank Sorenson <frank@tuxrocks.com>
(cherry picked from bfed505327e31221d8de796b3af880bad696b149 commit)
Earlier show-branch gave names only to commits reachable via first
parent ancestry chain. Change the naming code to name everybody.
The original idea was to stop at the first merge point in the
topological order, and --more=<n> to show commits until we show <n>
more extra merge points. However depending on the order of how we
discover the commits, it additionally showed parents of the <n>th
merge points, which was unnecessary.
This attempts to minimally cope with a subset of MIME "features" often
seen in patches sent to our mailing lists. Namely:
- People's name spelled in characters outside ASCII (both on From:
header and the signed-off-by line).
- Content-transfer-encoding using quoted-printable (both in
multipart and non-multipart messages).
These MIME features are detected and decoded by "git mailinfo".
Optionally, with the '-u' flag, the output to .info and .msg is
transliterated from its original chaset to utf-8. This is to
encourage people to use utf8 in their commit messages for
interoperability.
Applymbox accepts additional flag '-u' which is passed to mailinfo.
Signed-off-by: Junio C Hamano / 濱野 純 <junkio@cox.net>
Now the rebase is rewritten to use git cherry-pick, there is no user
for that ancient script. I've checked Cogito and StGIT to make sure
they do not use it.
The reverse patch application using "git apply" sometimes is too
rigid. Since the user would get used to resolving conflicting merges
by hand during the normal merge experience, using the same machinery
would be more helpful rather than just giving up.
Cherry-picking and reverting are essentially the same operation.
You pick one commit, and apply the difference that commit introduces
to its own commit ancestry chain to the current tree. Revert applies
the diff in reverse while cherry-pick applies it forward. They share
the same logic, just different messages and merge direction.
Not that I ignore portability to compilers that are properly C99, but
keeping compilation with GCC working is more important, at least for
now. We would probably end up declaring with "name[1]" and teach the
allocator to subtract one if we really aimed for portability, but that
is left for later rounds.
Teach git-status-script about git-ls-files --others
When there is non-empty $GIT_DIR/info/exclude file, use it along
with .gitignore per-directory exclude pattern files (which was
a convention agreed on the list while ago and is compatible with
Cogito) to generate a list of ignored files as well.
[PATCH] Make .git directory validation code test HEAD
Inspired by a report by Kalle Valo, this changes git-sh-setup-script and
the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a
symlink, since a number of core git features depend on that these days.
We used to allow a regular file there, but git-fsck-cache has been
complaining about that for a while, and anything that uses branches
depends on the HEAD file being a symlink, so let's just encode that as a
fundamental requirement.
Before, a non-symlink HEAD file would appear to work, but have subtle bugs
like not having the HEAD show up as a valid reference (because it wasn't
under "refs"). Now, we will complain loudly, and the user can fix it up
trivially instead of getting strange behaviour.
This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY"
being directories, since the other tests will implicitly test for that
anyway (ie the tests for HEAD, refs and 00 would fail).
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
When the "git pull" command updates the branch head you are
currently on, before doing anything else, first update your
index file and the working tree contents to that of the new
branch head. Otherwise, the later resolving steps would think
your index file is attempting to revert the change between the
original head commit and the updated head commit.
It uses two-tree fast-forward form of "read-tree -m -u" to
prevent losing whatever local changes you may have in the
working tree to do this update. I think this would at least
make things safer (a lot safer), and prevent mistakes.
Also "git fetch" command is forbidden from fetching and fast
forwarding the current branch head unless --update-head-ok flag
is given. "git pull" passes the flag when it internally calls
"git fetch".
You can define WITH_SEND_EMAIL to include the send-email command as
part of the installation. Since Debian, unlike RPM/Fedora, has the
two necessary Perl modules available as part of the mainline
distribution, there is no reason for us to shy away from shipping
send-email.
Gitzilla updated bunch of undocumented command pages, so move the
entries in the main documentation index around to put them in proper
category. Ordering within category will be fixed later.
Various updates and cleanups for my howto on using branches in GIT
as a Linux subsystem maintainer. Three categories of changes:
1) Updates for new features in GIT 0.99.5
2) Changes to use "git fetch" rather than "git pull" to update
local linus branch.
3) Cleanups suggested by Len Brown
Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
The "verify_pathspec()" function doesn't test for ending NUL character in
the pathspec, causing some really funky and unexpected behaviour. It just
happened to work in the cases I had tested.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
[PATCH] Allow "+remote:local" refspec to cause --force when fetching.
With this we could say:
Pull: master:ko-master +pu:ko-pu
to mean "fast forward ko-master with master, overwrite ko-pu with pu",
and the latter one does not require the remote "pu" to be descendant
of local "ko-pu".
[PATCH] Make "git pull" and "git fetch" default to origin
Amos Waterland sent in a patch for the pre-multi-head aware
version of "git pull" to do this, but the code changed quite a
bit since then. If there is no argument given to pull from, and
if "origin" makes sense, default to fetch/pull from "origin"
instead of barfing.
[jc: besides, the patch by Amos broke the non-default case where
explicit refspecs are specified, and did not make sure we know
what "origin" means before defaulting to it.]
This script uses the list of heads and their origin multi-head "git
fetch" left in the $GIT_DIR/FETCH_HEAD file, and makes an octopus
merge on top of the current HEAD using them.
The implementation tries to be strict for the sake of safety. It
insists that your working tree is clean (no local changes) and matches
the HEAD, and when any of the merged heads does not automerge, the
whole process is aborted and tries to rewind your working tree is to
the original state.
Update git-pull to match updated git-fetch and allow pull to
fetch from multiple remote references. There is no support for
resolving more than two heads, which will be done with "git
octopus".
Update "git ls-remote" to use git-parse-remote-script.
- A <refspec> of form "<src>:<dst>" is to fetch the objects
needed for the remote ref that matches <src>, and if <dst>
is not empty, store it as a local <dst>.
- "tag" followed by <next> is just an old way of saying
"refs/tags/<next>:refs/tags/<next>"; this mimics the
current behaviour of the third form above and means "fetch
that tag and store it under the same name".
- A single token <refspec> without colon is a shorthand for
"<refspec>:" That is, "fetch that ref but do not store
anywhere".
- when there is no <refspec> specified
- if <remote> is the name of a file under $GIT_DIR/remotes/
(i.e. a new-style shorthand), then it is the same as giving
the <refspec>s listed on Pull: line in that file.
- if <remote> is the name of a file under $GIT_DIR/branches/
(i.e. an old-style shorthand, without trailing path), then it
is the same as giving a single <refspec>
"<remote-name>:refs/heads/<remote>" on the command line, where
<remote-name> is the remote branch name (defaults to HEAD, but
can be overridden by .git/branches/<remote> file having the
URL fragment notation). That is, "fetch that branch head and
store it in refs/heads/<remote>".
- otherwise, it is the same as giving a single <refspec>
that is "HEAD:".
The SHA1 object names of fetched refs are stored in FETCH_HEAD,
one name per line, with a comment to describe where it came from.
This is later used by "git resolve" and "git octopus".
Recent changes in git have broken cg-log. git-rev-list no longer
prints "commit" in front of commit hashes. It turn out a local
"prefix" variable in main() shadows a file-scoped "prefix" variable.
The patch removed the local "prefix" variable since its value is never
used (in the intended way, that is). The call to
setup_git_directory() is kept since it has useful side effects.
The file-scoped "prefix" variable is renamed to "commit_prefix" just
in case someone reintroduces "prefix" to hold the return value of
setup_git_directory().
Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier rounds broke 'whatchanged -p'. In attempting to fix this,
make two axis of output selection in rev-parse orthogonal:
--revs-only tells it not to output things that are not revisions nor
flags that rev-list would take.
--no-revs tells it not to output things that are revisions or
flags that rev-list would take.
--flags tells it not to output parameters that do not start with
a '-'.
--no-flags tells it not to output parameters that starts with a '-'.
So for example 'rev-parse --no-revs -p arch/i386' would yield '-p arch/i386',
while 'rev-parse --no-revs --flags -p archi/i386' would give just '-p'.
Also the meaning of --verify has been made stronger. It now rejects
anything but a single valid rev argument. Earlier it passed some flags
through without complaining.
Pulling from a packed repository over dumb transport without the
server info file fails, so run update-server-info automatically
after a repack by default. This can be disabled with the '-n'
flag.
Try to find the optimum merge base while resolving.
The merge-base command acquires a new option, '--all', that causes it
to output all the common ancestor candidates. The "git resolve"
command then uses it to pick the optimum merge base by picking the one
that results in the smallest number of nontrivial merges.
Replace unsetenv() and setenv() with older putenv().
Solaris 8 doesn't have the newer unsetenv() and setenv()
functions, so replace them with putenv(). The one use of
unsetenv() in fsck-cache.c now sets GIT_ALTERNATE_OBJECT_
DIRECTORIES to the empty string. Every place that var
is used, NULLs are also replaced with empty strings, so
it's ok.
Omitting the first branch in ?: is a GNU extension. Cute,
but not supported by other compilers. Replaced mostly
by explicit tests. Calls to getenv() simply are repeated
on non-GNU compilers.
This trivial patch makes "git-rev-list" able to handle not being in
the top-level directory. This magically also makes "git-whatchanged"
do the right thing.
Trivial scripting fix to make sure that "git log" also works.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
I have been feeling that the current behaviour of "git reset" is
not quite optimal, but so far could not express exactly what I
felt was wrong with it. This patch clarifies it.
There are at least two situations you may want to "reset" your
working tree.
1. You made a mess in your working tree. You want to switch
back to a known good state and start over. This mess may be
a result of your own editing, a merge that had too many
conflicting changes that you do not feel like to resolve by
hand at this moment, or a botched application of a patch you
received from somewhere.
In this case, you would want to have "git reset HEAD" reset
the index file to the tree read from the HEAD commit and the
files in the working tree to match index (i.e. "git status"
should say "Nothing to commit", without any "unrecorded
changes").
The current behaviour leaves the files in the working tree
intact, which requires you to run "git checkout -f". Also
you need to remember "rm -f" any files that the botched patch
may have left in the working tree if the purpose of this
"reset" is to attempt to apply it again; most likely the
patch would fail if such a file is left behind.
2. You have discovered that commits you made earlier need to be
reorganized. The simplest example is to undo the last
commit, re-edit some files, and redo the commit. Another
simple eample is to undo the last two commits, and commit the
changes in those two commits as a single commit.
In this case, you would want to have "git reset HEAD^" reset
the $GIT_DIR/HEAD to the commit object name of the parent
commit of the current commit (i.e. rewinding one commit),
leave the index file and the files in the working tree in a
state where you can easily make a commit that records a tree
that resembles what you have in the current index file and
the working tree.
The current behaviour is almost OK for this purpose, except
that you need to find which files you need to manually run
"git add" yourself. They are files that are in the original
HEAD commit and not in the commit you are resetting to.
The default without the type flag is to do "--mixed", which is
the current behaviour.
A hard reset would be used for 1 and works in this way:
(1) remember the set of paths that appear in the current
index file (which may even have unmerged entries) and
the current $GIT_DIR/HEAD commit.
(2) "read-tree --reset" the specified <commit-ish> (default
to HEAD), followed by "checkout-cache -f -u -a".
(3) remove any files that appear in (1) but not in
<commit-ish> from the working tree.
(4) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update
$GIT_DIR/HEAD with the specified <commit-ish>.
(5) remove leftover $GIT_DIR/MERGE_HEAD
A soft reset would be used for 2 and works in this way:
(1) Make sure that the index file is merged and we do not
have MERGE_HEAD; otherwise it does not make sense to do
soft reset.
(2) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update
$GIT_DIR/HEAD with the specified <commit-ish>.
Note that with the current behaviour, "git diff" is the way to
see what could be committed immediately after "git reset". With
the "soft reset" described here you would need to say "git diff
HEAD" to find that out.
I am not sure what mixed reset (the current behaviour) is good
for. If nobody comes up with a good use case it may not be a
bad idea to remove it.
Clean-up output from"git show-branch" and document it.
When showing only one branch a lot of default output becomes redundant,
so clean it up a bit, and document what is shown. Retire the earlier
implementation "git-show-branches-script".