From: mkoegler@auto.tuwien.ac.at (Martin Koegler)
To: Jakub Narebski <jnareb@gmail.com>
Cc: Petr Baudis <pasky@suse.cz>, git@vger.kernel.org
Subject: Re: [PATCH 0/5] gitweb: Support for arbitrary diffs
Date: Tue, 4 Sep 2007 08:31:51 +0200 [thread overview]
Message-ID: <20070904063151.GA17799@auto.tuwien.ac.at> (raw)
In-Reply-To: <200709031023.42366.jnareb@gmail.com>
On Mon, Sep 03, 2007 at 10:23:41AM +0200, Jakub Narebski wrote:
> On Mon, 3 September 2007, Petr "Pasky" Baudis wrote:
>
> > To hijack this post a bit, another patch in the queue (the incremental
> > blame thingie) introduces blame.js. Do you think that we should keep the
> > .js files separate, or instead have one big gitweb.js with everything?
> > I'm inclined to the second possibility in order to reduce the number of
> > requests, but it comes at a price of slightly worse maintainability.
Why is the maintainablility reduced?
gitweb.perl is also a collection of different function, which are kept
in one file. Where is the difference to a javascript file?
Keeping everything into one file will make it more likely, that the
code is not developed totally different (in the terms of code style,
variable/function names, ...).
In the moment, there is the problem, which patch should introduce the
js file. We need a common base patch, which introduces an empty
gitweb.js.
Keeping the two functions separate has problems. Every patch need to
hook into the onload event. To avoid merge conflicts, my current patch
saves the old handler and overwrite it with its on version, which
calls back into the saved handler.
If we would have on js file, we can add in the base patch an empty
JavaScript function for this.
Then Hooking in the onload event would mean, to only add some new
lines to the function. The resulting merge conflicts are
easier to resolve (as they affect independet lines) compared to
the current '<body onload="hook1(); hook2();">'
> On the other hand if we have blame.js separate, we could load it
> (require it) only for the 'blame' view, it means only when needed.
>
> gitweb.js would contain JavaScript code used by all (or almost all)
> views, then...
>
> I don't think gitweb.js would be as large as gitweb.perl, if we are
> talking about maintability ;-)
The size of gitweb.js should not matter. On a modern browser, the
first request will fetch the whole Javascript file. For subseqent
request, the webserver returns "not modified". Having two javascript
file means two checks.
mfg Martin Kögler
next prev parent reply other threads:[~2007-09-04 6:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-02 14:46 [PATCH 0/5] gitweb: Support for arbitrary diffs Martin Koegler
2007-09-02 14:46 ` [PATCH 1/5] gitweb: Support comparing blobs with different names Martin Koegler
2007-09-02 14:46 ` [PATCH 2/5] gitweb: support filename prefix in git_patchset_body/git_difftree_body Martin Koegler
2007-09-02 14:46 ` [PATCH 3/5] gitweb: Add treediff view Martin Koegler
2007-09-02 14:46 ` [PATCH 4/5] gitweb: Selecting diffs in JavaScript Martin Koegler
2007-09-02 14:46 ` [PATCH 5/5] Show Difflinks in an other color Martin Koegler
2007-09-03 0:19 ` [PATCH 0/5] gitweb: Support for arbitrary diffs Jakub Narebski
2007-09-03 1:33 ` Petr Baudis
2007-09-03 2:10 ` Junio C Hamano
2007-09-03 8:23 ` Jakub Narebski
2007-09-04 6:31 ` Martin Koegler [this message]
2007-09-03 12:22 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070904063151.GA17799@auto.tuwien.ac.at \
--to=mkoegler@auto.tuwien.ac.at \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=pasky@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).