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.
When the configuration has variables unrelated to low-level
merge drivers (e.g. merge.summary), the code failed to ignore
them but did something totally senseless.
Fix funny types used in attribute value representation
It was bothering me a lot that I abused small integer values
casted to (void *) to represent non string values in
gitattributes. This corrects it by making the type of attribute
values (const char *), and using the address of a few statically
allocated character buffer to denote true/false. Unset attributes
are represented as having NULLs as their values.
Added in-header documentation to explain how git_checkattr()
routine should be called.
Allow low-level driver to specify different behaviour during internal merge.
This allows [merge "drivername"] to have a variable "recursive"
that names a different low-level merge driver to be used when
merging common ancestors to come up with a virtual ancestor.
Custom low-level merge driver: change the configuration scheme.
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.
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:
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.
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.
Allow specifying specialized merge-backend per path.
This allows 'merge' attribute to control how the file-level
three-way merge is done per path.
- If you set 'merge' to true, leave it unspecified, or set it
to "text", we use the built-in 3-way xdl-merge.
- If you set 'merge' to false, or set it to "binary, the
"binary" merge is done. The merge result is the blob from
'our' tree, but this still leaves the path conflicted, so
that the mess can be sorted out by the user. This is
obviously meant to be useful for binary files.
- 'merge=union' (this is the first example of a string valued
attribute, introduced in the previous one) uses the "union"
merge. The "union" merge takes lines in conflicted hunks
from both sides, which is useful for line-oriented files such
as .gitignore.
Instead fo setting merge to 'true' or 'false' by using 'merge'
or '-merge', setting it explicitly to "text" or "binary" will
become useful once we start allowing custom per-path backends to
be added, and allow them to be activated for the default
(i.e. 'merge' attribute specified to 'true' or 'false') case,
using some other mechanisms. Setting merge attribute to "text"
or "binary" will be a way to explicitly request to override such
a custom default for selected paths.
Currently there is no way to specify random programs but it
should be trivial for motivated contributors to add later.
There is one caveat, though. ll_merge() is called for both
internal ancestor merge and the outer "final" merge. I think an
interactive custom per-path merge backend should refrain from
going interactive when performing an internal merge (you can
tell it by checking call_depth) and instead just call either
ll_xdl_merge() if the content is text, or call ll_binary_merge()
otherwise.
This allows you to define three values (and possibly more) to
each attribute: true, false, and unset.
Typically the handlers that notice and act on attribute values
treat "unset" attribute to mean "do your default thing"
(e.g. crlf that is unset would trigger "guess from contents"),
so being able to override a setting to an unset state is
actually useful.
- If you want to set the attribute value to true, have an entry
in .gitattributes file that mentions the attribute name; e.g.
*.o binary
- If you want to set the attribute value explicitly to false,
use '-'; e.g.
*.a -diff
- If you want to make the attribute value _unset_, perhaps to
override an earlier entry, use '!'; e.g.
*.a -diff
c.i.a !diff
This also allows string values to attributes, with the natural
syntax:
attrname=attrvalue
but you cannot use it, as nobody takes notice and acts on
it yet.
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.
This adds "attribute macros" (for lack of better name). So far,
we have low-level attributes such as crlf and diff, which are
defined in operational terms --- setting or unsetting them on a
particular path directly affects what is done to the path. For
example, in order to decline diffs or crlf conversions on a
binary blob, no diffs on PostScript files, and treat all other
files normally, you would have something like these:
* diff crlf
*.ps !diff
proprietary.o !diff !crlf
That is fine as the operation goes, but gets unwieldy rather
rapidly, when we start adding more low-level attributes that are
defined in operational terms. A near-term example of such an
attribute would be 'merge-3way' which would control if git
should attempt the usual 3-way file-level merge internally, or
leave merging to a specialized external program of user's
choice. When it is added, we do _not_ want to force the users
to update the above to:
The way this patch solves this issue is to realize that the
attributes the user is assigning to paths are not defined in
terms of operations but in terms of what they are.
All of the three low-level attributes usually make sense for
most of the files that sane SCM users have git operate on (these
files are typically called "text'). Only a few cases, such as
binary blob, need exception to decline the "usual treatment
given to text files" -- and people mark them as "binary".
So this allows the $GIT_DIR/info/alternates and .gitattributes
at the toplevel of the project to also specify attributes that
assigns other attributes. The syntax is '[attr]' followed by an
attribute name followed by a list of attribute names:
[attr] binary !diff !crlf !merge-3way
When "binary" attribute is set to a path, if the path has not
got diff/crlf/merge-3way attribute set or unset by other rules,
this rule unsets the three low-level attributes.
It is expected that the user level .gitattributes will be
expressed mostly in terms of attributes based on what the files
are, and the above sample would become like this:
* As described above, you can define these macros only in
$GIT_DIR/info/attributes and toplevel .gitattributes.
* There is no attempt to detect circular definition of macro
attributes, and definitions are evaluated from bottom to top
as usual to fill in other attributes that have not yet got
values. The following would work as expected:
[attr] text diff crlf
[attr] ps text !diff
*.ps ps
while this would most likely not (I haven't tried):
[attr] ps text !diff
[attr] text diff crlf
*.ps ps
* When a macro says "[attr] A B !C", saying that a path does
not have attribute A does not let you tell anything about
attributes B or C. That is, given this:
[attr] text diff crlf
[attr] ps text !diff
*.txt !ps
path hello.txt, which would match "*.txt" pattern, would have
"ps" attribute set to zero, but that does not make text
attribute of hello.txt set to false (nor diff attribute set to
true).
This is in the same spirit as the previous one. Earlier 'diff'
meant 'do the built-in binary heuristics and disable patch text
generation based on it' while '!diff' meant 'do not guess, do
not generate patch text'. There was no way to say 'do generate
patch text even when the heuristics says it has NUL in it'.
Earlier we said 'crlf lets the path go through core.autocrlf
process while !crlf disables it altogether'. This fixes the
semantics to:
- Lack of 'crlf' attribute makes core.autocrlf to apply
(i.e. we guess based on the contents and if platform
expresses its desire to have CRLF line endings via
core.autocrlf, we do so).
- Setting 'crlf' attribute to true forces CRLF line endings in
working tree files, even if blob does not look like text
(e.g. contains NUL or other bytes we consider binary).
- Setting 'crlf' attribute to false disables conversion.
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.
Add basic infrastructure to assign attributes to paths
This adds the basic infrastructure to assign attributes to
paths, in a way similar to what the exclusion mechanism does
based on $GIT_DIR/info/exclude and .gitignore files.
An attribute is just a simple string that does not contain any
whitespace. They can be specified in $GIT_DIR/info/attributes
file, and .gitattributes file in each directory.
Each line in these files defines a pattern matching rule.
Similar to the exclusion mechanism, a later match overrides an
earlier match in the same file, and entries from .gitattributes
file in the same directory takes precedence over the ones from
parent directories. Lines in $GIT_DIR/info/attributes file are
used as the lowest precedence default rules.
A line is either a comment (an empty line, or a line that begins
with a '#'), or a rule, which is a whitespace separated list of
tokens. The first token on the line is a shell glob pattern.
The rest are names of attributes, each of which can optionally
be prefixed with '!'. Such a line means "if a path matches this
glob, this attribute is set (or unset -- if the attribute name
is prefixed with '!'). For glob matching, the same "if the
pattern does not have a slash in it, the basename of the path is
matched with fnmatch(3) against the pattern, otherwise, the path
is matched with the pattern with FNM_PATHNAME" rule as the
exclusion mechanism is used.
This does not define what an attribute means. Tying an
attribute to various effects it has on git operation for paths
that have it will be specified separately.
* maint:
git-quiltimport complaining yet still working
config.txt: Fix grammatical error in description of http.noEPSV
config.txt: Change pserver to server in description of gitcvs.*
config.txt: Document core.autocrlf
config.txt: Document gitcvs.allbinary
Do not default to --no-index when given two directories.
Use rev-list --reverse in git-rebase.sh
There were two bugs: "stop_here" doesn't exist, but the bug that causes
this code to trigger in the *first* place is the wrong use of "$dotest".
It should be ".dotest"
This is essentially the same bug introduced by 87ab7992, one was
fixed with 0d38ab25 but this was somehow left behind.
* jc/cherry:
Documentation: --cherry-pick
git-log --cherry-pick A...B
Refactor patch-id filtering out of git-cherry and git-format-patch.
Add %m to '--pretty=format:'
handle_options in git wrapper miscounts the options it handled.
handle_options did not count the number of used arguments
correctly. When --git-dir was used the extra argument was
not added to the number of handled arguments.
Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier --subject-prefix patch forgot that format-patch is
not the only codepath that adds the "[PATCH]" prefix, and broke
everybody else in the log family.
By default we are pretty quiet about the actual commands that
we are running. So we should continue to be quiet about the new
merge-subtree hardlink to merge-recursive. Technically this is not
a builtin, but it is close because subtree is actually builtin to
a non-builtin. So lets just make things easy and call it a builtin.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
This is meant to be a saner replacement for "git-cherry".
When used with "A...B", this filters out commits whose patch
text has the same patch-id as a commit on the other side. It
would probably most useful to use with --left-right.
Refactor patch-id filtering out of git-cherry and git-format-patch.
This implements the patch-id computation and recording library,
patch-ids.c, and rewrites the get_patch_ids() function used in
cherry and format-patch to use it, so that they do not pollute
the object namespace. Earlier code threw non-objects into the
in-core object database, and hoped for not getting bitten by
SHA-1 collisions. While it may be practically Ok, it still was
an ugly hack.
When used with '--boundary A...B', this shows the -/</> marker
you would get with --left-right option to 'git-log' family.
When symmetric diff is not used, everybody is shown to be on the
"right" branch.
* builtin-grep.c (strtoul_ui): Move function definition from here, to...
* git-compat-util.h (strtoul_ui): ...here, with an added "base" parameter.
* builtin-grep.c (cmd_grep): Update use of strtoul_ui to include base, "10".
* builtin-update-index.c (read_index_info): Diagnose an invalid mode integer
that is out of range or merely larger than INT_MAX.
(cmd_update_index): Use strtoul_ui, not sscanf.
* convert-objects.c (write_subdirectory): Likewise.
Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Add custom subject prefix support to format-patch (take 3)
Add a new option to git-format-patch, entitled --subject-prefix that allows
control of the subject prefix '[PATCH]'. Using this option, the text 'PATCH' is
replaced with whatever input is provided to the option. This allows easily
generating patches like '[PATCH 2.6.21-rc3]' or properly numbered series like
'[-mm3 PATCH N/M]'. This patch provides the implementation and documentation.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
GIT 1.5.1.1
cvsserver: Fix handling of diappeared files on update
fsck: do not complain on detached HEAD.
(encode_85, decode_85): Mark source buffer pointer as "const".
cvsserver: Fix handling of diappeared files on update
Only send a modified response if the client sent a
"Modified" entry. This fixes the case where the
file was locally deleted on the client without
being removed from CVS. In this case the client
will only have sent the Entry for the file but nothing
else.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Acked-by: Martin Langhoff <martin@catalyst.net.nz> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Detached HEAD is just a normal state of a repository. Do not
say anything about it.
Do not give worrying "error:" messages when we let the user know
that the HEAD points at nothing (i.e. yet to be born branch),
nor we do not have any default refs to start following the
objects chain. Reword them as "notice:".
gitweb: Allow configuring the default projects order and add order 'none'
Introduce new configuration variable $default_projects_order
that can be used to specify the default order of projects on
the index page if no 'o' parameter is given.
Allow a new value 'none' for order that will cause the projects
to be in the order we learned about them. In case of reading the
list of projects from a file, this should be the order as they are
listed in the file. In case of reading the list of projects from
a directory this will probably give random results depending on the
filesystem in use.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Acked-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Make it possible to use the forks feature even when
reading the list of projects from a file, by creating
a list of known prefixes as we go. Forks have to be
listed after the main project in order to be recognised
as such.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Acked-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
cvsexportcommit -p : fix the usage of git-apply -C.
Unlike 'patch --fuzz=NUM', which specifies the number of lines allowed
to mismatch, 'git-apply -CNUM' requests the match of NUM lines of
context. Omitting -C requests full context match, and that's what
should be used for cvsexportcommit -p.
* jc/merge-subtree:
A new merge stragety 'subtree'.
It is safe to merge this early as this is a feature that user
explicitly needs to ask for and would not trigger otherwise. A
known issue with the current implementation is that the subtree
matching heuristics is very stupid. It could run ls-tree twice
and try to count intersection.
Giving it wider audience would help it to get improved by
motivated volunteers.
* maint:
Add Documentation/cmd-list.made to .gitignore
git-svn: fix log command to avoid infinite loop on long commit messages
git-svn: dcommit/rebase confused by patches with git-svn-id: lines
git-svn: bail out on incorrect command-line options
git-svn: fix log command to avoid infinite loop on long commit messages
This bug has been around since the the conversion to use the
Git.pm library back in October or November. Eventually I'd like
"git rev-list/log" to have the option to not truncate overly
long messages.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn: dcommit/rebase confused by patches with git-svn-id: lines
When patches are merged from another git-svn managed branch,
they will have the git-svn-id: metadata line in them (generated
by git-format-patch).
When doing rebase or dcommit via git-svn, this would cause
git-svn to find the wrong upstream branch. We now verify
that the commit is consistent with the value in the .rev_db
file.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn: bail out on incorrect command-line options
"git svn log" is the only command that needs the pass-through
option in Getopt::Long; otherwise we will bail out and let the
user know something is wrong.
Also, avoid printing out unaccepted mixed-case options (that
are reserved for the command-line) such as --useSvmProps
in the usage() function.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'jc/read-tree-df' (early part):
Fix switching to a branch with D/F when current branch has file D.
Fix twoway_merge that passed d/f conflict marker to merged_entry().
Fix read-tree --prefix=dir/.
unpack-trees: get rid of *indpos parameter.
unpack_trees.c: pass unpack_trees_options structure to keep_entry() as well.
add_cache_entry(): removal of file foo does not conflict with foo/bar
This merge strategy largely piggy-backs on git-merge-recursive.
When merging trees A and B, if B corresponds to a subtree of A,
B is first adjusted to match the tree structure of A, instead of
reading the trees at the same level. This adjustment is also
done to the common ancestor tree.
If you are pulling updates from git-gui repository into git.git
repository, the root level of the former corresponds to git-gui/
subdirectory of the latter. The tree object of git-gui's toplevel
is wrapped in a fake tree object, whose sole entry has name 'git-gui'
and records object name of the true tree, before being used by
the 3-way merge code.
If you are merging the other way, only the git-gui/ subtree of
git.git is extracted and merged into git-gui's toplevel.
The detection of corresponding subtree is done by comparing the
pathnames and types in the toplevel of the tree.
git-push to multiple locations does not stop at the first failure
When pushing into multiple repositories with git push, via
multiple URL in .git/remotes/$shorthand or multiple url
variables in [remote "$shorthand"] section, we used to stop upon
the first failure. Continue the operation and report the
failure at the end.
This came up on #git when somebody was getting 'unable to create
./objects/tmp_oXXXX' but sweared he had write permission to that
directory. It turned out that the repository URL was changed
and he was accessing a repository he does not have a write
permission anymore.
I am not sure how much this would have helped somebody who
believed he was accessing location when the permission of that
location was changed while he was looking the other way, though.
But giving more information on the error path would be better,
and the next change would be helped with this as well.
* cc/bisect:
git-bisect: allow bisecting with only one bad commit.
t6030: add a bit more tests to git-bisect
git-bisect: modernization
Documentation: bisect: "start" accepts one bad and many good commits
Bisect: teach "bisect start" to optionally use one bad and many good revs.
* maint:
Documentation: tighten dependency for git.{html,txt}
Makefile: iconv() on Darwin has the old interface
t5300-pack-object.sh: portability issue using /usr/bin/stat
t3200-branch.sh: small language nit
usermanual.txt: some capitalization nits
Make builtin-branch.c handle the git config file
rename_ref(): only print a warning when config-file update fails
Distinguish branches by more than case in tests.
Avoid composing too long "References" header.
cvsimport: Improve formating consistency
cvsimport: Reorder options in documentation for better understanding
cvsimport: Improve usage error reporting
cvsimport: Improve documentation of CVSROOT and CVS module determination
cvsimport: sync usage lines with existing options
Documentation: tighten dependency for git.{html,txt}
Every time _any_ documentation page changed, cmds-*.txt files
were regenerated, which caused git.{html,txt} to be remade. Try
not to update cmds-*.txt files if their new contents match the
old ones.
The libiconv on Darwin uses the old iconv() interface (2nd argument is a
const char **, instead of a char **). Add OLD_ICONV to the Darwin
variable definitions to handle this.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Acked-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
t5300-pack-object.sh: portability issue using /usr/bin/stat
In the test 'compare delta flavors', /usr/bin/stat is used to get file size.
This isn't portable. There already is a dependency on Perl, use its '-s'
operator to get the file size.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-bisect: allow bisecting with only one bad commit.
This allows you to say:
git bisect start
git bisect bad $bad
git bisect next
to start bisection without knowing a good commit. This would
have you try a commit that is half-way since the beginning of
the history, which is rather wasteful if you already know a good
commit, but if you don't (or your history is short enough that
you do not care), there is no reason not to allow this.
This moves the knowledge about .git/config usage out of refs.c and into
builtin-branch.c instead, which allows git-branch to update HEAD to point
at the moved branch before attempting to update the config file. It also
allows git-branch to exit with an error code if updating the config file
should fail.
Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
rename_ref(): only print a warning when config-file update fails
If git_config_rename_section() fails, rename_ref() used to return 1, which
left HEAD pointing to an absent refs/heads file (since the actual renaming
had already occurred).
Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
The number of characters in a line MUST be no more than 998 characters,
and SHOULD be no more than 78 characters (RFC2822).
It is much safer to fold the header by ourselves.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
cvsimport: Reorder options in documentation for better understanding
The current order the options are documented in makes no sense
at all to me. Reorder them so that similar options are grouped
together and also order them somehwhat by importance.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
Sync both the usage lines in the code and the asciidoc
documentation with the real list of options. While
all options seems to be documented in the asciidoc
document, not all of them were listed in the usage line.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Fix lseek(2) calls with args 2 and 3 swapped
Honor -p<n> when applying git diffs
Fix dependency of common-cmds.h
Fix renaming branch without config file
DESTDIR support for git/contrib/emacs
gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches
Document --left-right option to rev-list.
Revert "builtin-archive: use RUN_SETUP"
rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email.
rerere: make sorting really stable.
Fix t4200-rerere for white-space from "wc -l"
Bisect: teach "bisect start" to optionally use one bad and many good revs.
One bad commit is fundamentally needed for bisect to run,
and if we beforehand know more good commits, we can narrow
the bisect space down without doing the whole tree checkout
every time we give good commits.
git bisect start
git bisect bad $bad
git bisect good $good1 $good2...
On the other hand, there may be some confusion between revs
(<bad> and <good>...) and <pathspec>... if -- is not used
and if an invalid rev or a pathspec that looks like a rev is
given.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
This function was not called "add_file_to_cache()" only because
an ancient program, update-cache, used that name as an internal
function name that does something slightly different. Now that
is gone, we can take over the better name.
The plan is to name all functions that operate on the default
index xxx_cache(). Later patches create a variant of them that
take an explicit parameter xxx_index(), and then turn
xxx_cache() functions into macros that use "the_index".