This changes the link detection logic to accept strings of between 6
and 40 hex characters as a possible SHA1 ID of another commit, rather
than insisting on seeing the full 40 hex characters.
To make the logic that turns a possible link into an actual link work
with abbreviated IDs, this changes the way the commitinterest array is
used, and puts the code that deals with it in a pair of new functions.
The commitinterest array is now indexed by just the first 4 characters
of the interesting SHA1 ID, and each element is a list of id + command
pairs. This also pulls out the logic for expanding an abbreviated
SHA1 to the list of matching full IDs into its own function (the way
it is done is still the same slow way it was done before, which should
be improved some day).
This also fixes the bug where clicking on a link would take you to the
wrong commit if the line number of the target had changed since the
link was made.
This is based on a patch by Linus Torvalds, but totally rewritten by me.
Signed-off-by: Paul Mackerras <paulus@samba.org>
06cbe855 (Make core.sharedRepository more generic, 2008-04-16) made
several testcases in t1301-shared-repo.sh which fail if on a system
which creates files with extended attributes (e.g. SELinux), since ls
appends a '+' sign to the permission set in such cases. In fact,
POSIX.1 allows ls to add a single printable character after the usual
3x3 permission bits to show that an optional alternate/additional access
method is associated with the path.
This fixes the testcase to strip any such sign prior to verifying the
permission set.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tested-by: Deskin Miller <deskinm@umich.edu>
* tr/workflow-doc:
Documentation: add manpage about workflows
Documentation: Refer to git-rebase(1) to warn against rewriting
Documentation: new upstream rebase recovery section in git-rebase
* dp/checkattr:
git-check-attr(1): use 'verse' for multi-line synopsis sections
check-attr: Add --stdin option
check-attr: add an internal check_attr() function
The code to complain when -b is not given but an explicit --track/--no-track
override was given from the command line was unchanged on one branch and
reworked on the other branch. The merge result incorrectly kept it.
Spotted by Matt McCutchen.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was originally implemented in c236bcd061
but was lost to a mismerge in 9ba929ed65.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This attempts to make a manpage about workflows that is both handy to
point people at it and as a beginner's introduction.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pb/rename-rowin32:
Do not rename read-only files during a push
Looks-fine-to-me-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
This changes the "die_on_error" boolean parameter to a mere "flags", and
changes the existing callers of hold_lock_file_for_update/append()
functions to pass LOCK_DIE_ON_ERROR.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When core.prefersymlinkrefs is in use, detaching the HEAD by
checkout incorrectly clobbers the tip of the current branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'--signoff' uses commiter name always to add the signoff line,
make it explicit in the documentation.
Signed-off-by: Abhijit Bhopatkar <bain@devslashzero.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When aborting a failed merge that has brought in a new path using "git
reset --hard" or "git read-tree --reset -u", we used to first forget about
the new path (via read_cache_unmerged) and then matched the working tree
to what is recorded in the index, thus ending up leaving the new path in
the work tree.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Hopefully the final draft release notes update before 1.6.0.3
diff(1): clarify what "T"ypechange status means
contrib: update packinfo.pl to not use dashed commands
force_object_loose: Fix memory leak
tests: shell negation portability fix
When diffing binary files, it is sometimes nice to see the
differences of a canonical text form rather than either a
binary patch or simply "binary files differ."
Until now, the only option for doing this was to define an
external diff command to perform the diff. This was a lot of
work, since the external command needed to take care of
doing the diff itself (including mode changes), and lost the
benefit of git's colorization and other options.
This patch adds a text conversion option, which converts a
file to its canonical format before performing the diff.
This is less flexible than an arbitrary external diff, but
is much less work to set up. For example:
$ echo '*.jpg diff=exif' >>.gitattributes
$ git config diff.exif.textconv exiftool
$ git config diff.exif.binary false
allows one to see jpg diffs represented by the text output
of exiftool.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The "diff" gitattribute is somewhat overloaded right now. It
can say one of three things:
1. this file is definitely binary, or definitely not
(i.e., diff or !diff)
2. this file should use an external diff engine (i.e.,
diff=foo, diff.foo.command = custom-script)
3. this file should use particular funcname patterns
(i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
Most of the time, there is no conflict between these uses,
since using one implies that the other is irrelevant (e.g.,
an external diff engine will decide for itself whether the
file is binary).
However, there is at least one conflicting situation: there
is no way to say "use the regular rules to determine whether
this file is binary, but if we do diff it textually, use
this funcname pattern." That is, currently setting diff=foo
indicates that the file is definitely text.
This patch introduces a "binary" config option for a diff
driver, so that one can explicitly set diff.foo.binary. We
default this value to "don't know". That is, setting a diff
attribute to "foo" and using "diff.foo.funcname" will have
no effect on the binaryness of a file. To get the current
behavior, one can set diff.foo.binary to true.
This patch also has one additional advantage: it cleans up
the interface to the userdiff code a bit. Before, calling
code had to know more about whether attributes were false,
true, or unset to determine binaryness. Now that binaryness
is a property of a driver, we can represent these situations
just by passing back a driver struct.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Both sets of code assume that one specifies a diff profile
as a gitattribute via the "diff=foo" attribute. They then
pull information about that profile from the config as
diff.foo.*.
The code for each is currently completely separate from the
other, which has several disadvantages:
- there is duplication as we maintain code to create and
search the separate lists of external drivers and
funcname patterns
- it is difficult to add new profile options, since it is
unclear where they should go
- the code is difficult to follow, as we rely on the
"check if this file is binary" code to find the funcname
pattern as a side effect. This is the first step in
refactoring the binary-checking code.
This patch factors out these diff profiles into "userdiff"
drivers. A file with "diff=foo" uses the "foo" driver, which
is specified by a single struct.
Note that one major difference between the two pieces of
code is that the funcname patterns are always loaded,
whereas external drivers are loaded only for the "git diff"
porcelain; the new code takes care to retain that situation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This makes erroneous output slightly easier to see. We also
flip the argument order to match our usual style.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
format-patch is most commonly used for multiple patches at once when
sending a patchset, in which case we want to number the patches; on
the other hand, single patches are not usually expected to be
numbered.
In other words, the typical behavior expected from format-patch is the
one obtained by enabling autonumber, so we set it to be the default.
Users that want to disable numbering for a particular patchset can do
so with the existing -N command-line switch. Users that want to
change the default behavior can use the format.numbering config key.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Test-updates-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Win32 does not allow renaming read-only files (at least on a Samba
share), making push into a local directory to fail. Thus, defer
the chmod() call in index-pack.c:final() only after
move_temp_to_file() was called.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* pb/commit-where:
tutorial: update output of git commit
reformat informational commit message
git commit: Reformat output somewhat
builtin-commit.c: show on which branch a commit was added
With all calls to alloc_ref() gone, we can remove it and then we're free
to give alloc_ref_from_str() the shorter name. It's a much nicer
interface, as the callers always need to have a name string when they
allocate a ref anyway and don't need to calculate and pass its length+1
any more.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace pairs of alloc_ref() and strcpy() with alloc_ref_from_str(),
simplifying the code.
In connect.c, also a pair of alloc_ref() and memcpy() is replaced --
the additional cost of a strlen() call should not have too much of an
impact. Consistency and simplicity are more important.
In remote.c, the code was allocating 11 bytes more than needed for
the name part, but I couldn't see them being used for anything.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In three cases in remote.c, a "raw" ref is allocated using alloc_ref()
and then its is constructed using sprintf(). Clean it up by adding a
helper function, alloc_ref_with_prefix(), which creates a composite
name. Use it in alloc_ref_from_str(), too, as it simplifies the code.
Open code alloc_ref() in alloc_ref_with_prefix(), as the former is
going to be removed in the patch after the next.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
read_packed_sha1 expectes its caller to free the buffer it returns, which
force_object_loose didn't do.
This leak is eventually triggered by "git gc", when it is manually invoked
or there are too many packs around, making gc totally unusable when there
are lots of unreachable objects.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is the result of running make update-po and removing or fixing
the strings that were fuzzily matched. The ones that were fixed were
the ones where the only change was "git rev-list" to "git log", and
the "about gitk" message where the copyright year got updated.
To get xgettext to see the menu labels as needing translation, it
was necessary for arrange for them to be preceded by "mc". This
therefore changes makemenu to ignore the first element in each
menu item so that it can be "mc" in the makemenu call.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The test to make sure that checkout fails when --track was asked for and
we cannot set up tracking information in t7201 was wrong, and it turns out
that the implementation for that feature itself was buggy. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the "git status" display code was originally converted
to C, we copied the code from ls-files to discover whether a
pathname returned by read_directory was an "other", or
untracked, file.
Much later, 5698454e updated the code in ls-files to handle
some new cases caused by gitlinks. This left the code in
wt-status.c broken: it would display submodule directories
as untracked directories. Nobody noticed until now, however,
because unless status.showUntrackedFiles was set to "all",
submodule directories were not actually reported by
read_directory. So the bug was only triggered in the
presence of a submodule _and_ this config option.
This patch pulls the ls-files code into a new function,
cache_name_is_other, and uses it in both places. This should
leave the ls-files functionality the same and fix the bug
in status.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the caller supplies --tags they want the lightweight, unannotated
tags to be searched for a match. If a lightweight tag is closer
in the history, it should be matched, even if an annotated tag is
reachable further back in the commit chain.
The same applies with --all when matching any other type of ref.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-By: Uwe Kleine-König <ukleinek@strlen.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 969c8775 introduced a test which uses the non-portable construct:
command1 && ! command2 | command3
which must be
command1 && ! (command2 | command3)
to work on bsd shells (this is another example of bbf08124, which fixed
several similar cases).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some misguided documents floating on the Net suggest this sequence:
mkdir newdir && cd newdir
git init
git remote add origin $url
git pull origin master:master
"git pull" has known about misguided "pull" that lets the underlying fetch
update the current branch for a long time. It also has known about
"git pull origin master" into a branch yet to be born.
These two workarounds however were not aware of the existence of each
other and did not work well together. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is inspired by patches from Robin Rosenberg but takes a different
approach. This adds a "makemenu" procedure for constructing menus
that allows the menu layout to be specified in a clear fashion, and
provides one place where the alt+letter accelerators can be detected
and handled.
The alt+letter accelerator is specified by putting an ampersand (&)
before the letter for the accelerator in the menu item name. (Two
ampersands in succession produce one ampersand in the menu item as
it appears on screen.) This is handled in makemenu.
We also add an mca procedure which is like mc but also does the
ampersand translation, for use when we want to refer to a menu item
by name. The mca name and the locations where we use it were
shamelessly stolen from Robin Rosenberg's patch.
This doesn't actually add any alt+letter accelerators yet.
Signed-off-by: Paul Mackerras <paulus@samba.org>
* maint:
t1301-shared-repo.sh: don't let a default ACL interfere with the test
git-check-attr(1): add output and example sections
xdiff-interface.c: strip newline (and cr) from line before pattern matching
t4018-diff-funcname: demonstrate end of line funcname matching flaw
t4018-diff-funcname: rework negated last expression test
Typo "does not exists" when git remote update remote.
remote.c: correct the check for a leading '/' in a remote name
Add testcase to ensure merging an early part of a branch is done properly
Conflicts:
t/t7600-merge.sh
