The new 'blame_incremental' view requires JavaScript to run. Not all
web browsers implement JavaScript (e.g. text browsers such as Lynx),
and not all users have JavaScript enabled. Therefore instead of
unconditionally linking to 'blame_incremental' view, we use JavaScript
to convert those links to lead to view utilizing JavaScript, by adding
'js=1' to link.
Currently the only action that takes 'js=1' into account is 'blame',
which then acts as if it was called as 'blame_incremental' action.
Possible enhancement would be to do JavaScript redirect by setting
window.location instead of modifying $format and $action in
git_blame_common() subroutine.
The only JavaScript-aware/using view is currently 'blame_incremental'.
While at it move reading JavaScript to git_footer_html() subroutine.
Note that in this view we do not add 'js=1' currently (even though
perhaps we should; note that for consistency we should also add 'js=1'
in links added by JavaScript part of 'blame_incremental').
This idea was originally implemented by Petr Baudis in
http://article.gmane.org/gmane.comp.version-control.git/47614
but it added <script> element with fixBlameLinks() function in page
header, to be added as onload event using 'onload' attribute of HTML
'body' element: <body onload="fixBlameLinks();">. This version adds
script at then end of page (in the page footer), and uses JavaScript
'window.onload=fixLinks();'. Also in Petr version only links marked
with 'blamelink' class were modified, and they were modified by
replacing "a=blame" by "a=blame_incremental"... which doesn't work for
path_info links, and might replace wrong part if there is "a=blame" in
project name, ref name or file name.
Slightly different solution was implemented by Martin Koegler in
http://thread.gmane.org/gmane.comp.version-control.git/47902/focus=47905
Here GitAddLinks() function was in gitweb.js file, not as contents of
<script> element. It was also included in page header (in <head>
element) though, which means waiting for a script to load (and run).
It was smarter in that to "fix" (modify) link, it split URL, modified
value of 'a' parameter, and then recreated modified link. It avoids
trouble with "a=blame" as substring in project name or file name, but
it doesn't work with path_info URL/link in the way it was written.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This requires using 3 colors, not only two, to choose a color that is
different from colors of up to 2 neighbors.
gitweb.js selects the least used color, if more than one color is
possible.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add 'blame_incremental' view, which uses "git blame --incremental"
and JavaScript (Ajax), where 'blame' use "git blame --porcelain".
* gitweb generates initial info by putting file contents (from
"git cat-file") together with line numbers in blame table
* then gitweb makes web browser JavaScript engine call startBlame()
function from gitweb.js
* startBlame() opens XMLHttpRequest connection to 'blame_data' view,
which in turn calls "git blame --incremental" for a file, and
streams output of git-blame to JavaScript (gitweb.js)
* XMLHttpRequest event handler updates line info in blame view as soon
as it gets data from 'blame_data' (from server), and it also updates
progress info
* when 'blame_data' ends, and gitweb.js finishes updating line info,
it fixes colors to match (as far as possible) ordinary 'blame' view,
and updates information about how long it took to generate page.
Gitweb deals with streamed 'blame_data' server errors by displaying
them in the progress info area (just in case).
The 'blame_incremental' view tries to be equivalent to 'blame' action;
there are however a few differences in output between 'blame' and
'blame_incremental' view:
* 'blame_incremental' always used query form for this part of link(s)
which is generated by JavaScript code. The difference is visible
if we use path_info link (pass some or all arguments in path_info).
Changing this would require implementing something akin to href()
subroutine from gitweb.perl in JavaScript (in gitweb.js).
* 'blame_incremental' always uses "rowspan" attribute, even if
rowspan="1". This simplifies code, and is not visible to user.
* The progress bar and progress info are still there even after
JavaScript part of 'blame_incremental' finishes work.
Note that currently no link generated by gitweb leads to this new view.
This code is based on patch by Petr Baudis <pasky@suse.cz> patch, which
in turn was tweaked up version of Fredrik Kuivinen <frekui@gmail.com>'s
proof of concept patch.
This patch adds GITWEB_JS compile configuration option, and modifies
git-instaweb.sh to take gitweb.js into account. The code for
git-instaweb.sh was taken from Pasky's patch.
Signed-off-by: Fredrik Kuivinen <frekui@gmail.com>
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add "This page took XXX seconds and Y git commands to generate"
to page footer, if global feature 'timed' is enabled (disabled
by default). Requires Time::HiRes installed for high precision
'wallclock' time.
Note that Time::HiRes is being required unconditionally; this is
because setting $t0 variable needs to be done fairly early to have
running time of the whole script. If Time::HiRes module were required
only if 'timed' feature is enabled, the earliest place where starting
time ($t0) could be calculated would be after reading gitweb config,
making "time to generate page" info inaccurate.
This code is based on example code by Petr 'Pasky' Baudis.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of using "light2" and "dark2" for class names in 'blame' view
(in place of "light" and "dark" classes in other places) to avoid
changing style on hover in 'blame' view while doing it for other views
(like 'shortlog'), use more advanced CSS, relying on the fact that
more specific selector wins.
While at it add a few comments to gitweb CSS file, and consolidate
some repeated info.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For example for "Junio C Hamano" initials would be "JH". Of course
initials are added (below shortened SHA-1 of blamed commit) only if
group of lines that blame the same commit has 2 or more lines in it.
Initials are extracted using i18n /\b([[:upper:]])\B/g regexp.
Additionally initials help to distinguish boundary commits, as they
use bold weight font too (in addition to shortened SHA-1 of commit).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use "no-previous" class to mark blamed commits which do not have
"previous" header. Those are commits in which blamed file was created
(added); this includes boundary commits. This means that 'linenr'
link leads to blamed commit, not (one of) parent of blamed commit.
Therefore currently line number for such commit uses bold weight font
to denote this situation; the effect is subtle.
Use "multiple-previous" class in the opposite situation, where blamed
commit has multiple "previous" headers (is an evil merge). Currently
this class is not used for styling. In this situation 'linenr' link
leads to first of "previous" commits (first parent).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Luben Tuikov changed 'lineno' link (line number link) from pointing to
'blame' view at given line at blamed commit, to the one at parent of
blamed commit in
244a70e (Blame "linenr" link jumps to previous state at
"orig_lineno", 2007-01-04).
This made it possible to do data mining using 'blame' view, by going
through history of a line using mentioned line number link.
Original implementation called "git rev-parse <commit>^" to find SHA-1
of a parent of a given commit once per each blamed line. In
39c19ce (gitweb: cache $parent_commit info in git_blame(),
2008-12-11)
this was improved so rev-parse was called once per each unique commit
in git-blame output. Alternate solution would be to relax validation
for 'hb' parameter by allowing extended SHA-1 syntax of the form
<rev>^ (perhaps redirecting to gitweb URL with <rev>^ resolved, in
practice moving call to rev-parse to 'the other side of link').
This solution had a bug that it didn't work for boundary commits.
Boundary commits don't have parents, so "git rev-parse <commit>^"
returned literal "<commit>^" (which didn't exists). Gitweb didn't
detect this situation and passed this result literally as 'hb'
parameter in 'linenr' link. Following such link currently gives
400 - Invalid hash base parameter
error; 'hb' parameter is restricted via validate_refname to correct
refnames and doesn't allow for extended SHA-1 syntax. This bug could
have been fixed alternatively by checking if commit is boundary commit,
or check if rev-parse result is unchanged (still ends in '^' prefix).
The solution employing rev-parse to find parent of commit had inherent
problem if blamed commit renamed file; then name of file would be
different in its parent. Solving this outside git-blame would be
difficult and costly (at least cost of additional fork for extra git
command).
Currently gitweb uses information in "previous" header, which was
introduced by Junio C Hamano in
96e1170 (blame: show "previous" information in
--porcelain/--incremental format, 2008-06-04)
This (currently undocumented) header has the following format:
"previous <sha1 of parent commit> <filename at parent>"
Using "previous" header solves both problem of performance and the
problem that blamed commit could have renaming blamed file.
Because "previous" header can be repeated for the same commit when
blamed commit is merge (has more than one parent), and we are
interested usually in _first_ parent, currently we store only first
value if blame header repeats. Using first parent (first "previous"
line) was what gitweb did before; without this change gitweb would use
last parent instead.
If there is no previous commit 'linenr' link points to blamed commit
and blamed filename, making it work correctly for boundary commits.
Acked-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use "boundary" class to mark boundary commits, which currently results
in using bold weight font for SHA-1 of a commit (to be more exact for
all text in the first cell in row, that contains SHA-1 of a commit).
Detecting boundary commits is done by watching for "boundary" header
in "git blame -p" output. Because this header doesn't carry
additional data the regular expression for blame header fields
had to be slightly adjusted.
With current gitweb API only root (parentless) commits can be boundary
commits.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Style for td.error was introduced in 1f1ab5f (gitweb: style done with
stylesheet, 2006-06-20) to replace inline style for errors in old
multi-column "git annotate" based 'blame' view. This view was then
since removed (replaced by "git-blame" based 'blame' view, with fewer
colums), making this style unused.
Make this style more generic by replacing td.error with .error to make
it apply to any element. It will be used in 'blame_incremental' view
to show error messages.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Added the envvar GIT_PS1_SHOWUNTRACKEDFILES to 'git-completion.bash'.
When set to a nonempty value, then the char '%' will be shown next
to the branch name in the bash prompt.
Signed-off-by: Daniel Trstenjak <daniel.trstenjak@science-computing.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
SunOS grep does not understand -C<n> nor -e
Fix export_marks() error handling.
git branch: clean up detached branch handling
git branch: avoid unnecessary object lookups
git branch: fix performance problem
do_one_ref(): null_sha1 check is not about broken ref
Conflicts:
Makefile
The first "grep -C1" test in t7002 does not pass on my SunOS-5.11-i86pc,
and that is not because our way to spawn external grep is broken, but
because the native grep does not understand -C<n>.
It turns out that Peff was also using this option himself because our
Makefile doesn't do that automatically. Brandon Casey uses SUNWspro
compiler without having to set this, and it turns out that the compiler
does not define preprocessor macro __unix__ which made him always use the
built-in grep, never an external one.
Let's be more explicit and say that we do not use external grep on Suns.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- Don't leak one FILE * on error per export_marks() call. Found with
cppcheck and reported by Martin Ettl.
- Abort the potentially long for(;idnums.size;) loop on write errors.
- Record error if fprintf() fails for reasons not required to set the
stream error indicator, such as ENOMEM.
- Add a trailing full-stop to error message when fopen() fails.
Signed-off-by: Matthias Andree <matthias.andree@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the 'show detached branch info' a routine of its own. And in the
process, avoid the object lookup that is unnecessary if the current
branch isn't detached.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
They can be expensive in the cold-cache case, so don't bother looking up
the commits for all branches unless we really need them for some reason.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git branch' looks at _all_ the refs, and verifies them. Which means that
during cold-cache situations with a slow disk (and lots of tags, for
example) it can take several very annoying seconds (7.5s according to a
report by Carlos R. Mafra).
This avoids most of it by simply doing the filtering before looking up
the commits, by using the "raw" version of for_each_ref.
Reported-by: Carlos R. Mafra <crmafra2@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thanks to Ka-Hing Cheung for the initial bug report and patch:
> git-svn uses $ra->get_latest_revnum to find out the latest
> revision, but that can be problematic, because get_latest_revnum
> returns the latest revnum in the entire repository, not
> restricted by whatever URL you used to construct $ra. So if you
> do git svn clone -r HEAD svn://blah/blah/trunk, it won't work if
> the latest checkin is in one of the branches (it will try to
> fetch a rev that doesn't exist in trunk, making the clone
> useless).
Relying on SVN::Core::INVALID_REVNUM (-1) as the "start"
argument to SVN::Ra::get_log() proved unreliable with http(s)
URLs so the result of SVN::Ra::get_latest_revnum() is used as
the "start" argument instead.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
f8948e2 (remote prune: warn dangling symrefs, 2009-02-08) introduced a
more dangerous variant of for_each_ref() family that skips the check for
dangling refs, but it also made another unrelated check optional by
mistake.
The check to see if a ref points at 0{40} is not about brokenness, but is
about a possible future plan to represent a deleted ref by writing 40 "0"
in a loose ref when there is a stale version of the same ref already in
.git/packed-refs, so that we can implement deletion of a ref without
having to rewrite the packed refs file excluding the ref being deleted.
This check has to live outside of the conditional.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The empty assignment NEEDS_SSL_WITH_CRYPTO= was mistakenly paired with the
assignment NEEDS_SSL_WITH_CRYPTO=YesPlease in the "action-if-found"
parameter of the AC_CHECK_LIB macro. The empty assignment was intended for
the "action-if-not-found" section, since in that case, the necessary sha1
hash function was not found and the internal sha1 implementation will be
used instead.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Brought to you thanks to coccinelle:
---8<----
@@
expression *E;
@@
(
E ==
- 0
+ NULL
|
E !=
- 0
+ NULL
|
E =
- 0
+ NULL
)
@@
identifier f;
type T;
@@
T *f(...) {
<...
- return 0;
+ return NULL;
...>
}
--->8----
There are a lot more hits in compat/nedmallox and compat/regex but these
are borrowed code we rather do not want to maintain our own forks for,
and this patch refrains from touching them.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace remaining git-XXX calls with git XXX.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Acked-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This hopefully makes the relationship between threading options of
format-patch and send-email easier to grasp.
Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also mention deprecated aliases that do not appear in the send-email
manpage.
Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "action" parameters for these two tests were supplied incorrectly for
the way the tests were implemented. The tests check whether a program
which calls hstrerror() or basename() successfully links when -lresolv or
-lgen are used, respectively. A successful linking would result in
NEEDS_RESOLV or NEEDS_LIBGEN being unset, and failure would result in
setting the respective variable.
Aside from that issue, the tests did not handle the case where neither
library was necessary for accessing the functions in question. So solve
both of these issues by re-working the two tests so that their form is like
the NEEDS_SOCKET test which attempts to link with just the c library, and
if it fails then assumes that the additional library is necessary and sets
the appropriate variable.
Also an entry in the config.mak.in file is necessary for the NEEDS_LIBGEN
variable to appear in the config.mak.autogen file with the value assigned
by the configure script. Without it, the generated shell script would
contain a snippet like this:
for ac_lib in ; do
...
which is incorrect.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Trailing whitespace and no newline fix
diff --cc: a lost line at the beginning of the file is shown incorrectly
combine-diff.c: fix performance problem when folding common deleted lines
If a patch adds a new line to the end of a file and this line ends with
one trailing whitespace character and has no newline, then
'--whitespace=fix' currently does not remove that trailing whitespace.
This patch fixes this by removing the check for trailing whitespace at
the end of the line at a hardcoded offset which does not take the
eventual absence of newline into account.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When combine-diff inspected the diff from one parent to the merge result,
it misinterpreted a header in the form @@ -l,k +0,0 @@.
This hunk header means that K lines were removed from the beginning of the
file, so the lost lines must be queued to the sline that represents the
first line of the merge result, but we incremented our pointer incorrectly
and ended up queuing it to the second line, which in turn made the lossage
appear _after_ the first line.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For a deleted line in a patch with the parent we are looking at, the
append_lost() function finds the same line among a run of lines that were
deleted from the same location by patches from parents we previously
checked. This is so that patches with two parents
@@ -1,4 +1,3 @@ @@ -1,4 +1,3 @@
one one
-two -two
three three
-quatro -fyra
+four +four
can be coalesced into this sequence, reusing one line that describes the
removal of "two" for both parents.
@@@ -1,4 -1,4 +1,3 @@@
one
--two
three
- quatro
-frya
++four
While reading the second patch (that removes "two" and then "fyra"), after
finding where removal of the "two" matches, we need to find existing
removal of "fyra" (if exists) in the removal list, but the match has to
happen after all the existing matches (in this case "two"). The code used
a naïve O(n^2) algorithm to compute this by scanning the whole removal
list over and over again.
This patch remembers where the next scan should be started in the existing
removal list to avoid this.
Noticed by Linus Torvalds.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mishandling of http(s) in need of escaping was causing
t9118-git-svn-funky-branch-names to fail when SVN_HTTPD_PORT
was defined.
This bug was exposed in (but not caused by)
commit 0b2af457a4
(Fix branch detection when repository root is inaccessible)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Some unrelated tests were developed simultaneously and resulted
in test numbers conflicting. To avoid difficulty when referring
to tests via the "tXXXX" convention, rename the newer tests.
Suggested by Marc Branchaud.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
If the message said "we will be changing the default in the future, so
this is to warn people who want to keep the current default what to do",
it would have made some sense, but as it stands, the message is merely an
unsolicited advertisement for a new feature, which it is not helpful at
all. Squelch it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git log --no-walk' sorts commits by commit time whereas 'git show' does
not (it leaves them as given on the command line). Document this by two
tests so that we never forget why ba1d450 (Tentative built-in "git
show", 2006-04-15) introduced it and 8e64006 (Teach revision machinery
about --no-walk, 2007-07-24) exposed it as an option argument.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reorder tests introduced in fef3a7cc and 54d5cc0e so an intermittent but
unimportant failure on the CVS side related to the former does not interfere
with what is actually being tested.
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Tested-by: Tommy Nordgren <tommy.nordgren@comhem.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we switch branches with "checkout -f", unpack_trees() feeds two
cache_entries to oneway_merge() function in its src[] array argument. The
zeroth entry comes from the current index, and the first entry represents
what the merge result should be, taken from the tree recorded in the
commit we are switching to.
When we have a blob (either regular file or a symlink) in the index and in
the work tree at path "foo", and the switched-to tree has "foo/bar",
i.e. "foo" becomes a directory, src[0] is obviously that blob currently
registered at "foo". Even though we do not have anything at "foo" in the
switched-to tree, src[1] is _not_ NULL in this case.
The unpack_trees() machinery places a special marker df_conflict_entry
to signal that no blob exists at "foo", but it will become a directory
that may have somthing underneath it (namely "foo/bar"), so a usual 3-way
merge can notice the situation.
But oneway_merge() codepath failed to notice this and passed the special
marker directly to merged_entry(). This happens to remove the "foo" in
the end because the df_conflict_entry does not have any name (hence the
"error" message) and its addition in add_index_entry() is rejected, but it
is wrong.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
When we fall back to a standard for_each_reflog_ent() after failing to find
the nth branch switch (or if we had a short reflog) with the call to
for_each_recent_reflog_ent(), we do not need to free the memory allocated
for our strbuf's since a strbuf_reset() will be performed in
grab_nth_branch_switch() before assigning to the entry.
Plus, the strbuf_release() negates the non-zero hint we initially gave to
strbuf_init() just above these lines.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit 650d30d8a1.
Some mailing lists are configured add prefix "[listname] " to all their
messages, and also people hand-edit subject lines, be it an output from
format-patch or a patch generated by some other means.
We cannot stop people from mucking with the subject line, and with the
change, there always will be need for hand editing the subject when that
happens. People have depended on the leading [bracketed string] removal.
In our 'oneway_merge()' we always do an 'lstat()' to see if we might
need to mark the entry for updating.
But we really shouldn't need to do that when the cache entry is already
marked as being ce_uptodate(), and this makes us do unnecessary lstat()
calls if we have index preloading enabled.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not that anybody should ever get it, but somebody did (probably because
of a flaky filesystem, but whatever). And each time I see an error
message that I haven't seen before, I decide that next time it will look
better.
So this makes us write more relevant information about exactly which
file ended up having issues with a missing object. Which will tell
whether it was a tree object, for example, or just a regular file in the
index (and which one).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For some reason, I ended up doing
git show HEAD~5..
as an odd way of asking for a log. I realize I should just have used "git
log", but at the same time it does make perfect conceptual sense. After
all, you _could_ have done
git show HEAD HEAD~1 HEAD~2 HEAD~3 HEAD~4
and saying "git show HEAD~5.." is pretty natural. It's not like "git show"
only ever showed a single commit (or other object) before either! So
conceptually, giving a commit range is a very sensible operation, even
though you'd traditionally have used "git log" for that.
However, doing that currently results in an error
fatal: object ranges do not make sense when not walking revisions
which admittedly _also_ makes perfect sense - from an internal git
implementation standpoint in 'revision.c'.
However, I think that asking to show a range makes sense to a user, while
saying "object ranges no not make sense when not walking revisions" only
makes sense to a git developer.
So on the whole, of the two different "makes perfect sense" behaviors, I
think I originally picked the wrong one. And quite frankly, I don't really
see anybody actually _depending_ on that error case. So why not change it?
So rather than error out, just turn that non-walking error case into a
"silently turn on walking" instead.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
... so it's available for git log, shortlog and gitk.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-scm.com is now the "official" Git project page, having taken over
from git.or.cz, so update the default link accordingly. This saves a
redirect when people hit git.or.cz.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SVN allows uppercase A-F characters in repositories. Although
`svnadmin' does not create UUIDs with uppercase by default, it
is possible to change the UUID of a SVN repository and SVN
itself will make no attempt to normalize them.
Thanks to Esben Skovenborg for discovering this issue.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
