Although it is not advisable, we have always allowed a branch
and a tag to have the same basename (i.e. it is not illegal to
have refs/heads/frotz and refs/tags/frotz at the same time).
When talking about a specific commit, the interpretation of
'frotz' has always been "use tag and then check branch",
although we warn when ambiguities exist.
However "git checkout $name" is defined to (1) first see if it
matches the branch name, and if so switch to that branch; (2)
otherwise it is an instruction to detach HEAD to point at the
commit named by $name. We did not follow this definition when
$name appeared under both refs/heads/ and refs/tags/ -- we
switched to the branch but read the tree from the tagged commit,
which was utterly bogus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Encode ' ' using '=20' even though rfc2047 allows using '_' for
readability. Unfortunately, many programs do not understand this and
just leave the underscore in place. Using '=20' seems to work better.
[jc: with adjustment to t3901]
Signed-off-by: Kristian Høgsberg <hoegsberg@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This test case would have caught the bug fixed by revision
c23290d5.
It puts various forms of $Id$ into a file in the repository,
without allowing git to collapse them to uniformity. Then enables the
$Id$ expansion on checkout, and checks that what is checked out has
coped with the various forms.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates t4014 to check the two fixes for git-am and git-commit
we observed with "echo" that does backslash interpolation by default
without being asked with -e option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When e8438420bb allowed us to reload
the marks table on subsequent runs of fast-import we really broke
things, as we set pack_id to MAX_PACK_ID for any objects we imported
into the marks table. Creating a branch from that mark should fail
as we attempt to read the object through a non-existant packed_git
pointer. Instead we have to use the normal Git object system to
locate the older commit, as we ourselves do not have a reference
to the packed_git it resides in.
This bug only occurred because t9300 was not complete enough.
When we added the --import-marks feature we didn't actually test
its implementation enough to verify the function worked as intended.
I have corrected that, and included the changes as part of this fix.
Prior versions of fast-import fail the new test(s); this commit
allows them to pass.
Credit for this bug find goes to Simon Hausmann <simon@lst.de> as
he recently identified a similiar bug in the tree lazy-loading path.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-add reads this variable, and honours the contents of that file if that
exists. Match this behaviour in git-status, too.
Noticed by Evan Carroll on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Noticed that there were only tests for --int, but not
for --bool. Add some.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
$Id$ is present already in SVN and CVS; it would mean that people
converting their existing repositories won't have to make any changes to
the source files should they want to make use of the ident attribute.
Given that it's a feature that's meant to calm those very people, it
seems obtuse to make them edit every file just to make use of it.
I think that bzr uses $Id$; Mercurial has examples hooks for $Id$;
monotone has $Id$ on its wishlist. I can't think of a good reason not
to stick with the de-facto standard and call ours $Id$ instead of
$ident$.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
For tracking branches and tags, git-svn prefers to connect
to the root of the repository or at least the level that
houses branches and tags as well as trunk. However, users
that are accustomed to tracking a single directory have
no use for this feature.
As pointed out by Junio, users may not have permissions to
connect to connect to a higher-level path in the repository.
While the current minimize_url() function detects lack of
permissions to certain paths _after_ successful logins, it
cannot effectively determine if it is trying to access a
login-only portion of a repo when the user expects to
connect to a part where anonymous access is allowed.
For people used to the git-svnimport switches of
--trunk, --tags, --branches, they'll already pass the
repository root (or root+subdirectory), so minimize URL
isn't of too much use to them, either.
For people *not* used to git-svnimport, git-svn also
supports:
git svn init --minimize-url \
--trunk http://repository-root/foo/trunk \
--branches http://repository-root/foo/branches \
--tags http://repository-root/foo/tags
And this is where the new --minimize-url command-line switch
comes in to allow for this behavior to continue working.
You cannot currently checkout the tip of an existing branch
without moving to the branch.
This allows you to detach your HEAD and place it at such a
commit, with:
$ git checkout master^0
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-cvsserver has a bug in its configuration file output parser
that makes it choke if the configuration has these:
[diff]
color = auto
[diff.color]
whitespace = blue reverse
This needs to be fixed, but thanks to that bug, a separate bug
in t9400 test script was discovered. The test discarded
GIT_CONFIG instead of pointing at the proper one to be used in
the exoprted repository. This allowed user's .gitconfig and (if
exists) systemwide /etc/gitconfig to affect the outcome of the
test, which is a big no-no.
The patch fixes the problem in the test. Fixing the
git-cvsserver's configuration parser is left as an exercise to
motivated volunteers ;-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rather than updating all working tree paths, we limit
ourselves to paths listed on the command line.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When switching from a branch with both x86_64/boot/Makefile and
i386/boot/Makefile to another branch that has x86_64/boot as a
symlink pointing at ../i386/boot, the code incorrectly removed
i386/boot/Makefile.
This was because we first removed everything under x86_64/boot
to make room to create a symbolic link x86_64/boot, then removed
x86_64/boot/Makefile which no longer exists but now is pointing
at i386/boot/Makefile, thanks to the symlink we just created.
This fixes it by using the has_symlink_leading_path() function
introduced previously for git-apply in the checkout codepath.
Earlier, "git checkout" was broken in t4122 test due to this
bug, and the test had an extra "git reset --hard" as a
workaround, which is removed because it is not needed anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
HPA noticed that git-rebase fails when changes involve symlinks
in the middle of the hierarchy. Consider:
* The tree state before the patch is applied has arch/x86_64/boot
as a symlink pointing at ../i386/boot/
* The patch tries to remove arch/x86_64/boot symlink, and
create bunch of files there: .gitignore, Makefile, etc.
git-apply tries to be careful while applying patches; it never
touches the working tree until it is convinced that the patch
would apply cleanly. One of the check it does is that when it
knows a path is going to be created by the patch, it runs
lstat() on the path to make sure it does not exist.
This leads to a false alarm. Because we do not touch the
working tree before all the check passes, when we try to make
sure that arch/x86_64/boot/.gitignore does not exist yet, we
haven't removed the arch/x86_64/boot symlink. The lstat() check
ends up seeing arch/i386/boot/.gitignore through the
yet-to-be-removed symlink, and says "Hey, you already have a
file there, but what you fed me is a patch to create a new
file. I am not going to clobber what you have in the working
tree."
We have similar checks to see a file we are going to modify does
exist and match the preimage of the diff, which is done by
directly opening and reading the file.
For a file we are going to delete, we make sure that it does
exist and matches what is going to be removed (a removal patch
records the full preimage, so we check what you have in your
working tree matches it in full -- otherwise we would risk
losing your local changes), which again is done by directly
opening and reading the file.
These checks need to be adjusted so that they are not fooled by
symlinks in the middle.
- To make sure something does not exist, first lstat(). If it
does not exist, it does not, so be happy. If it _does_, we
might be getting fooled by a symlink in the middle, so break
leading paths and see if there are symlinks involved. When
we are checking for a path a/b/c/d, if any of a, a/b, a/b/c
is a symlink, then a/b/c/d does _NOT_ exist, for the purpose
of our test.
This would fix this particular case you saw, and would not
add extra overhead in the usual case.
- To make sure something already exists, first lstat(). If it
does not exist, barf (up to this, we already do). Even if it
does seem to exist, we might be getting fooled by a symlink
in the middle, so make sure leading paths are not symlinks.
This would make the normal codepath much more expensive for
deep trees, which is a bit worrisome.
This patch implements the first side of the check "making sure
it does not exist". The latter "making sure it exists" check is
not done yet, so applying the patch in reverse would still
fail, but we have to start from somewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use the :fork: access method to force cvs to
call "$CVS_SERVER server" even when accessing a local
repository.
Add a basic test for checkout and some tests for update.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This tests the -d, -n, -f, -x, and -X options to git-clean.
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix t4200 so that it also works on OS X by not relying on gnu
extensions to sed.
Signed-off-by: Bryan Larsen <bryan@larsen.st>
Signed-off-by: Junio C Hamano <junkio@cox.net>
For example Mac OS X lacks the seq command. So we cannot use it
there. A good old while loop works just as good.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some other programs get the user's email address from $EMAIL, so fall back to
that if we don't have a Git-specific email address.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also leave a warning for future merge-recursive explorers.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The interface is similar to the custom low-level merge drivers.
First you configure your filter driver by defining 'filter.<name>.*'
variables in the configuration.
filter.<name>.clean filter command to run upon checkin
filter.<name>.smudge filter command to run upon checkout
Then you assign filter attribute to each path, whose name
matches the custom filter driver's name.
Example:
(in .gitattributes)
*.c filter=indent
(in config)
[filter "indent"]
clean = indent
smudge = cat
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'ident' attribute set to path squashes "$ident:<any bytes
except dollor sign>$" to "$ident$" upon checkin, and expands it
to "$ident: <blob SHA-1> $" upon checkout.
As we have two conversions that affect checkin/checkout paths,
clarify how they interact with each other.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of running rev-list and picking earlier lines using head/tail pipeline,
grab commit object name as we build commits. This also removes a non POSIX
use of tail with -linenum (more posixly-correct way to say it is "-n linenum")
Signed-off-by: Junio C Hamano <junkio@cox.net>
A Large Angry SCM (gitzilla) noticed that on an unnamed platform, tail -c
wants its byte count as part of the option, not as a separate argument.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that git-commit got chatty, we have to shut it up again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The function common_prefix() is used to find the common subdirectory of
a couple of pathnames. When checking if the next pathname matches up with
the prefix, it incorrectly checked the whole path, not just the prefix
(including the slash). Thus, the expensive part of the loop was executed
always.
The other bug is more serious: if the first and the last pathname in the
list have a longer common prefix than the common prefix for _all_ pathnames
in the list, the longer one would be chosen. This bug was probably hidden
by the fact that bash's wildcard expansion sorts the results, and the code
just so happens to work with sorted input.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This enhances the attributes mechanism so that external programs
meant for existing GIT_EXTERNAL_DIFF interface can be specifed
per path.
To configure such a custom diff driver, first define a custom
diff driver in the configuration:
[diff "my-c-diff"]
command = <<your command string comes here>>
Then mark the paths that you want to use this custom driver
using the attribute mechanism.
*.c diff=my-c-diff
The intent of this separation is that the attribute mechanism is
used for specifying the type of the contents, while the
configuration mechanism is used to define what needs to be done
to that type of the contents, which would be specific to both
platform and personal taste.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the semantics of 'crlf' so that .gitattributes file
can say "this is text, even though it may look funny".
Setting the `crlf` attribute on a path is meant to mark the path
as a "text" file. 'core.autocrlf' conversion takes place
without guessing the content type by inspection.
Unsetting the `crlf` attribute on a path is meant to mark the
path as a "binary" file. The path never goes through line
endings conversion upon checkin/checkout.
Unspecified `crlf` attribute tells git to apply the
`core.autocrlf` conversion when the file content looks like
text.
Setting the `crlf` attribut to string value "input" is similar
to setting the attribute to `true`, but also forces git to act
as if `core.autocrlf` is set to `input` for the path.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The following tests available:
- create subprojects: create a directory in the superproject,
initialize a git repo in it, and try adding it in super project.
Make a commit in superproject
- check if fsck ignores the subprojects: it just should give no errors
- check if commit in a subproject detected: make a commit in
subproject, git-diff-files in superproject should detect it
- check if a changed subproject HEAD can be committed: try
"git-commit -a" in superproject. It should commit changed
HEAD of a subproject
- check if diff-index works for subproject elements: compare the index
(changed by previuos tests) with the initial commit (which created
two subprojects). Should show a change for the recently changed subproject
- check if diff-tree works for subproject elements: do the same, just use
git-diff-tree. This test is somewhat redundant, I just added it for
completeness (diff, diff-files, and diff-index are already used)
- check if git diff works for subproject elements: try to limit
the diff for the name of a subproject in superproject:
git diff HEAD^ HEAD -- subproject
- check if clone works: try a clone of superproject and compare
"git ls-files -s" output in superproject and cloned repo
- removing and adding subproject: rename test. Currently implemented
as "git-update-index --force-remove", "mv" and "git-add".
- checkout in superproject: try to checkout the initial commit
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Noticed by applying two diffs of different contexts to the same file.
The check for existence of a file was wrong: the test assumed it was
a directory and reset the errno (twice: directly and by calling
lstat). So if an entry existed and was _not_ a directory no attempt
was made to rename into it, because the errno (expected by renaming
code) was already reset to 0. This resulted in error:
fatal: unable to write file file mode 100644
For Linux, removing "errno = 0" is enough, as lstat wont modify errno
if it was successful. The behavior should not be depended upon,
though, so modify the "if" as well.
The test simulates this situation.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the configuration syntax for defining a low-level
merge driver to be:
[merge "<<drivername>>"]
driver = "<<command line>>"
name = "<<driver description>>"
which is much nicer to read and is extensible. Credit goes to
Martin Waitz and Linus.
In addition, when we use an external low-level merge driver, it
is reported as an extra output from merge-recursive, using the
value of merge.<<drivername>.name variable.
The demonstration in t6026 has also been updated.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows users to specify custom low-level merge driver per
path, using the attributes mechanism. Just like you can specify
one of built-in "text", "binary", "union" low-level merge
drivers by saying:
* merge=text
.gitignore merge=union
*.jpg merge=binary
pick a name of your favorite merge driver, and assign it as the
value of the 'merge' attribute.
A custom low-level merge driver is defined via the config
mechanism. This patch introduces 'merge.driver', a multi-valued
configuration. Its value is the name (i.e. the one you use as
the value of 'merge' attribute) followed by a command line
specification. The command line can contain %O, %A, and %B to
be interpolated with the names of temporary files that hold the
common ancestor version, the version from your branch, and the
version from the other branch, and the resulting command is
spawned.
The low-level merge driver is expected to update the temporary
file for your branch (i.e. %A) with the result and exit with
status 0 for a clean merge, and non-zero status for a conflicted
merge.
A new test in t6026 demonstrates a sample usage.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This demonstrates how the new low-level per-path merge backends,
union and ours, work, and shows how they are controlled by the
gitattribute mechanism.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates git-rev-list --objects to be a bit more careful
when listing a blob object to make sure the blob actually
exists, and uses it to make sure the quick-fetch optimization we
introduced earlier is not fooled by a previous incomplete fetch.
The quick-fetch optimization works by running this command:
git rev-list --objects <<commit-list>> --not --all
where <<commit-list>> is a list of commits that we are going to
fetch from the other side. If there is any object missing to
complete the <<commit-list>>, the rev-list would fail and die
(say, the commit was in our repository, but its tree wasn't --
then it will barf while trying to list the blobs the tree
contains because it cannot read that tree).
Usually we do not have the objects (otherwise why would we
fetching?), but in one important special case we do: when the
remote repository is used as an alternate object store
(i.e. pointed by .git/objects/info/alternates). We could check
.git/objects/info/alternates to see if the remote we are
interacting with is one of them (or is used as an alternate,
recursively, by one of them), but that check is more cumbersome
than it is worth.
The above check however did not catch missing blob, because
object listing code did not read nor check blob objects, knowing
that blobs do not contain any further references to other
objects. This commit fixes it with practically unmeasurable
overhead.
I've benched this with
git rev-list --objects --all >/dev/null
in the kernel repository, with three different implementations
of the "check-blob".
- Checking with has_sha1_file() has negligible (unmeasurable)
performance penalty.
- Checking with sha1_object_info() makes it somewhat slower,
perhaps by 5%.
- Checking with read_sha1_file() to cause a fully re-validation
is prohibitively expensive (about 4 times as much runtime).
In my original patch, I had this as a command line option, but
the overhead is small enough that it is not really worth it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
[jc: also fix 0a5280a9 that incorrectly changed the title of one test.]
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make every test executable. Remove exec-attribute from included shell files,
they can't used standalone anyway.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
instead of embedded subshell. It actually breaks here (dash as /bin/sh):
t4201-shortlog.sh: 27: Syntax error: Missing '))'
FATAL: Unexpected exit with code 2
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
At the same time, we do not want to allow arbitrary strings for
attribute names, as we are likely to want to extend the syntax
later. Allow only alnum, dash, underscore and dot for now.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This defines the semantics of 'crlf' attribute as an example.
When a path has this attribute unset (i.e. '!crlf'), autocrlf
line-end conversion is not applied.
Eventually we would want to let users to build a pipeline of
processing to munge blob data to filesystem format (and in the
other direction) based on combination of attributes, and at that
point the mechanism in convert_to_{git,working_tree}() that
looks at 'crlf' attribute needs to be enhanced. Perhaps the
existing 'crlf' would become the first step in the input chain,
and the last step in the output chain.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a fairly complete list of tests for various aspects of pack
index versions 1 and 2.
Tests on index v2 include 32-bit and 64-bit offsets, as well as a nice
demonstration of the flawed repacking integrity checks that index
version 2 intend to solve over index version 1 with the per object CRC.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano