If use_pathinfo is enabled, href now creates links that contain paths in
the form $project/$action/oldhash:/oldname..newhash:/newname for actions
that use hash_parent etc.
If any of the filename contains two consecutive dots, it's kept as a CGI
parameter since the resulting path would otherwise be ambiguous.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch makes it possible to use an URL such as
project/action/somebranch..otherbranch:/filename to get a diff between
different version of a file. Paths like
project/action/somebranch:/somefile..otherbranch:/otherfile are parsed
as well.
All '*diff' actions and in general actions that use $hash_parent[_base]
and $file_parent (e.g. 'shortlog') can now get all of their parameters
from PATH_INFO
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Generate PATH_INFO URLs in the form project/action/hash_base:/filename
rather than project/action/hash_base:filename (the latter form is still
accepted in input).
This minimal change allows relative navigation to work properly when
viewing HTML files in raw ('blob_plain') mode.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When generating path info URLs, reduce the number of CGI parameters by
embedding action and hash_parent:filename or hash in the path.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch enables gitweb to parse URLs with more information embedded
in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
path is now $project/$action/$hash_base:$file_name or
$project/$action/$hash
This is mostly backwards compatible with the old-style gitweb paths,
$project/$branch[:$filename], except when it was used to access a branch
whose name matches a gitweb action.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Completion for new workflow documentation introduced in f948dd8
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Turn short SHA1 names into links too
gitk: Regenerate .po files
gitk: New way of constructing menus that allows for Alt+letter accelerators
gitk: Bind Key-Return to create on new branch dialog
gitk: Fix binding for <Return> in sha1 entry field
gitk: Clean up file encoding code and add enable/disable option
gitk: Implement batch lookup and caching of encoding attrs
gitk: Enhance file encoding support
gitk: Add untranslated error messages to translation
gitk: Fix a bug in collapsing deeply nested trees
gitk: Use <Button-2> for context menus on OSX
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>
'--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>
* 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
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
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>
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>
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
This test creates files with several different umasks and expects their
permissions to be initialized according to the umask, so a default ACL on the
trash directory (which overrides the umask for files created in that directory)
causes the test to fail. To avoid that, remove the default ACL if possible with
setfacl(1).
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
`rebase -i -p` got its rev-list of commits to keep by --left-right and
--cherry-pick. Adding --cherry-pick would drop commits that duplicated changes
already in the rebase target.
The dropped commits were then forgotten about when it came to rewriting the
parents of their descendents, so the descendents would get cherry-picked with
their old, unwritten parents and essentially make the rebase a no-op.
This commit adds a $DOTEST/dropped directory to remember dropped commits and
rewrite their children's parent as the dropped commit's possibly-rewritten
first-parent.
Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Plumbing tools should document what output can be expected.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
POSIX doth sayeth:
"In the regular expression processing described in IEEE Std 1003.1-2001,
the <newline> is regarded as an ordinary character and both a period and
a non-matching list can match one. ... Those utilities (like grep) that
do not allow <newline>s to match are responsible for eliminating any
<newline> from strings before matching against the RE."
Thus far git has not been removing the trailing newline from strings matched
against regular expression patterns. This has the effect that (quoting
Jonathan del Strother) "... a line containing just 'FUNCNAME' (terminated by
a newline) will be matched by the pattern '^(FUNCNAME.$)' but not
'^(FUNCNAME$)'", and more simply not '^FUNCNAME$'.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
