* Re: Subprojects tasks
From: Martin Waitz @ 2006-12-16 22:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, git
In-Reply-To: <7v64cbeeiv.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]
hoi :)
Junio, I'll take a more detailed look at your mail tomorrow, after I
regenerated from all the Guinness I had tonight ;-)
On Sat, Dec 16, 2006 at 01:07:04PM -0800, Junio C Hamano wrote:
> Sven Verdoolaege <skimo@kotnet.org> writes:
> > On Sat, Dec 16, 2006 at 10:32:36AM -0800, Junio C Hamano wrote:
> >> I suspect the hardest part is "rev-list --objects" (now most of
> >> it is found in revision.c). [..] But I think the updated
> >> code needs to know that "link" needs to be unwrapped and
> >> contained "commit" needs to be injected back to the ancestry
> >> walking machinery.
Well, I already got to the point of using the commit directly,
instead of any link object. It even worked with rev-list --objects
in all my test cases. That is, I could correctly clone/pack/pull
the complete project including all modules.
> > Wouldn't we then run into the scalability problems Linus was
> > concerned about ?
This is a real problem.
> If the plumbing layer does not have to (although I haven't
> thought it through, it does feel like it even shouldn't) unwrap
> "link" and let the Porcelain layer to deal with it, that would
> certainly make rev-list/revision.c part simpler.
Yes. However, it makes other things more complicated.
If the plumbing does not do all the subproject stuff and you don't have
everything in one database it is much more difficult to really get
a consistent database when cloning or fetching (you have to get even old
submodule commits which are not reachable by the current supermodule
tree anymore, perhaps even submodules which do not exist anymore).
I did not have much time to think about these issues in the last day and
am not yet convinced on how to proceed,
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [RFC] gitweb wishlist and TODO list (part 1)
From: Jakub Narebski @ 2006-12-16 23:00 UTC (permalink / raw)
To: git; +Cc: Kernel Org Admin, Petr Baudis
This is yet another series of planned gitweb features. This part
concentrates on improving gitweb rather than on adding new features.
Comments appreciated.
Copy send to Kernel.Org admin (which probably is most interested
in improving gitweb and git performance), and to Petr Baudis which
maintains repo.or.cz public git hosting site, which runs new(est)
version of gitweb.
1. Cleanup
* HTML cleanup.
There are still some places where we use presentational HTML elements
like <i>. I'd rather have it replaced by adding class to appropriate
element, and adding proper rule to CSS. This would make changing the
style easier, but it would make generated page larger.
On the other hand we use class element when sometimes id attribute would
be better, and sometimes (in the tables) it would be better served to
add <col> and <colgroup> elements, and use header attribute and select
CSS style by this attribute value.
* CSS cleanup.
Use descendant selectors more, and use other selectors like parent or
grandchild, instead of relying on class, to remove some of redundancy in
CSS file. This would make ading similar elements easier (for example
README for a project has now wrong style), and most probably would make
CSS style smaller.
Perhaps we should reorder CSS file, and add some comments, to make it's
maintenance easier, and make it easier to add style for new elements.
* Code cleanup.
There is still a bit of code cleanup, especially in the subroutines
which were not refactored yet. For example git_search should take
advance of git-rev-list / git-log --grep, --author and --committer
options, and split search output into pages. Untabify should perhaps be
moved to esc_html, now that esc_path is separated... or perhaps not.
2. Performance etc.
* Better support for mod_perl in "CGI mode". Planned support for mod_perl
in handler mode and support for FastCGI via CGI::Fast.
Add support for mod_perl so it wouldn't need to be run with
+ParseHeaders, and wouldn't need to set CGI environment variables. This
can speed up gitweb a bit under mod_perl. The problem is how to do this
to be able to run gitweb under CGI, FastCGI, mod_perl 1.0 and 2.0.
This includes separating generating HTTP headers into separate
subroutine, at first thin wrapper around "print $cgi->header(...)".
* Native config reading.
This could speed up gitweb a bit at least in configurations where
repository is allowed to override default features (like blame,
snapshot, pickaxe) and sometimes change their options.
It would also allow to move some gitweb configuration, like description,
homepage (in repo.or.cz), cloneurl from separate loose files in $GIT_DIR
of a repository to it's proper place in the config. I'd rather add
category as gitweb.category configuration variable than as yet another
file in .git. Without native config reading it would be hard to add
sensibly configureable committags support.
The problem lies with lack of formal description of config file, and in
git specific additions which make ready modules for INI config parsing
infeasible. But it is not insurmountable. I think that config reader
should be then incorporated in Git.pm module. We for sure need some
tests for it added.
By the way, should we always parse whole config file like in
Tie::Memoize? Or read only one variable, if tieing it to hash then with
Tie::Hash? Or some combination of both?
* Cache validation and infinite cache for unchanging pages
By itself cache validation would not bring much performance boost (for
gitweb installations with large traffic), but with the reverse proxy,
aka. caching engine, aka. HTTP accelerator in front of server this could
help a lot.
This means sending proper Last-Modifed: and ETag: (if HTTP/1.1) headers,
and checking If-Modified-Since: and If-None-Match: headers, replying
with 304 Not Modified. This should work both with gitweb called both as
CGI script, and from mod_perl. While at it we should return always only
HTTP header, without generating (if possible) and writing any contents
on HEAD requests (and other which do not need body).
The idea is to use query string (current arguments) with all hashes
replaced by it's current value as sha1 for ETag, and to use committer
date for Last-Modified. If possible, we could use stat info: date of
last modification of given "loose" ref, or packed refs file, although
that might be inaccurate. Not always we can check if cache is valid
without calling any git command, but usually we would be able to do this
after only a few commands. Implementing cache validation might mean that
we would have to restructure code a bit.
Separate subroutine for HTTP headers generation would help with writing
cache validation.
Bundled together is using "infinite" (or at least large: currently we
use +1d) Expires: and/or Cache-Control: max-age (if HTTP/1.1) for
unchanging pages. Although those pages are usually rarely accessed...
Next parts: new features, improving existing views etc. in next email.
--
Jakub Narebski
^ permalink raw reply
* Re: Subprojects tasks
From: Martin Waitz @ 2006-12-16 23:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <em1erl$pne$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
hoi :)
On Sat, Dec 16, 2006 at 07:45:11PM +0100, Jakub Narebski wrote:
> Or .gitlink file, if we decide to implement it (as lightweight checkout and
> support for submodules which one can easily move/rename).
I still don't get the advantage of a .gitlink file over an ordinary
repository with alternates or a symlink.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-16 23:10 UTC (permalink / raw)
To: git
Things that I feel should be done need to be done to complete
v1.5.0 are:
- 'git-rm' needs to be fixed up as Linus outlined; remove
working tree file and index entry but have a sanity check to
make sure the working tree file match the index and HEAD.
- tutorials and other Porcelain documentation pages need to be
updated to match the updated 'git-add' and 'git-rm' (to be
updated), and their description should be made much less
about implementation; they should talk in terms of end-user
workflows.
We need a full sweep on Porcelain-ish documentation.
- now reflog is enabled by default for user repositories, I
have two worries about its effect, fortunately can be killed
with a single stone.
* the reflog grows unbounded;
* revisions recorded in the reflog can be pruned out,
rendering some entries in reflog useless.
I am thinking about teaching fsck-objects and prune to keep
revisions recorded in the reflog; we would need an end-user
way to prune older reflog entries and I would appreciate
somebody codes it up, but even without it, people can always
use "vi" or "ed" on reflog files ;-).
- 'git-add' might want to do 'update-index --replace'; probably
needs a sanity-checking discussion before implementing it.
- 'git-svn' users should speak out about two issues:
* use of svn command line client as the backend is being
removed;
* 'git-svn commit' command is being renamed to avoid
confusion, and potentially 'dcommit' will be renamed to
'commit'.
Please discuss these with Eric.
- we might want to address the issue that 'git-status' output
does not make it easy to tell mode changes from content
changes. Personally I do not like cryptic "M+" output format
proposed by Lars and find the current output more readable.
----------------------------------------------------------------
As usual, '+' are both in 'next' and 'pu', '-' are in 'pu' only.
* jn/web (Sat Dec 16 17:12:55 2006 +0100) 9 commits
- gitweb: Add some mod_perl specific support
+ gitweb: Add "next" link to commit view
+ gitweb: Add title attribute to ref marker with full ref name
+ gitweb: Do not show difftree for merges in "commit" view
+ gitweb: SHA-1 in commit log message links to "object" view
+ gitweb: Hyperlink target of symbolic link in "tree" view (if
possible)
+ gitweb: Add generic git_object subroutine to display object of any
type
+ gitweb: Show target of symbolic link in "tree" view
+ gitweb: Don't use Content-Encoding: header in git_snapshot
All except the tip (mod_perl) looked good and should be in
v1.5.0; I haven't formed an opinion on mod_perl change yet.
* js/branch-config (Sat Dec 16 15:15:02 2006 +0100) 2 commits
+ git-branch: rename config vars branch.<branch>.*, too
+ add a function to rename sections in the config
This moves branch.$foo.* variables to branch.$bar.* when $foo
branch is renamed to $bar. Because we already have branch -m
(stands for "mv"), this series is a must-have in v1.5.0.
* jc/clone (Sat Dec 16 01:53:10 2006 -0800) 4 commits
+ git-clone: lose the traditional 'no-separate-remote' layout
+ git-clone: lose the artificial "first" fetch refspec
+ git-pull: refuse default merge without branch.*.merge
+ git-clone: use wildcard specification for tracking branches
Fixes the workflow wart and removes the traditional layout that
maps remote 'master' to refs/heads/origin. Also 'git pull' and
'git pull origin' would not merge the ref on the first Pull:
line (nor remote.*.fetch item) anymore. You either have to give
an explicit command line parameter or branch.$currbranch.merge
item. With blessing from Linus, this will be in v1.5.0.
* ew/svn-pm (Fri Dec 15 23:58:08 2006 -0800) 3 commits
+ git-svn: rename 'commit' command to 'set-tree'
+ git-svn: remove support for the svn command-line client
+ git-svn: convert to using Git.pm
It is in 'next' because I agree it is in the right direction in
the longer term, but not in 'master' because this might be
controvertial for shorter term. The users should decide.
** jc/reflog (Thu Dec 14 15:58:56 2006 -0800) 1 commit
- Teach show-branch how to show ref-log data.
A strawman to make reflog data a bit more browsable; it would be
useful while recovering from a mistake you made recently. Not
essential and can wait or be dropped if people do not find it
useful.
** jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits
- git-add --interactive: hunk splitting
- git-add --interactive
I've thought about further allowing to edit the patches in the
'patch' subcommand, but the more I think about it, the less it
makes sense from the workflow point of view. Will be the topic
for a separate message.
** sv/git-svn (Tue Dec 5 16:17:38 2006 +1100) 5 commits
. git-svn: re-map repository URLs and UUIDs on SVK mirror paths
. git-svn: collect revision properties when fetching
. git-svn: collect SVK source URL on mirror paths
. git-svn: let libsvn_ls_fullurl return properties too
. git-svn: make test for SVK mirror path import
Still held but dropped from 'pu' for now (depends on "sub sys"
that was removed from git-svn).
** jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
- git-explain
Backburnered.
* jc/blame-boundary (Fri Dec 1 20:45:45 2006 -0800) 1 commit
+ git-blame: show lines attributed to boundary commits differently.
Will merge.
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
+ git-merge: preserve and merge local changes when doing fast
forward
Will merge, if only to see what breaks.
* js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits
+ fetch-pack: Do not fetch tags for shallow clones.
+ get_shallow_commits: Avoid memory leak if a commit has been
reached already.
+ git-fetch: Reset shallow_depth before auto-following tags.
+ upload-pack: Check for NOT_SHALLOW flag before sending a shallow
to the client.
+ fetch-pack: Properly remove the shallow file when it becomes
empty.
+ shallow clone: unparse and reparse an unshallowed commit
+ Why didn't we mark want_obj as ~UNINTERESTING in the old code?
+ Why does it mean we do not have to register shallow if we have
one?
+ We should make sure that the protocol is still extensible.
+ add tests for shallow stuff
+ Shallow clone: do not ignore shallowness when following tags
+ allow deepening of a shallow repository
+ allow cloning a repository "shallowly"
+ support fetching into a shallow repository
+ upload-pack: no longer call rev-list
Undecided but not likely to be in v1.5.0. Needs more real
project testing.
** jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
- gitweb: steal loadavg throttle from kernel.org
Undecided.
** jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
- blame: --show-stats for easier optimization work.
Developer only.
** jc/leftright (Sun Oct 22 17:32:47 2006 -0700) 1 commit
- rev-list --left-right
Backburnered.
** jc/diff (Mon Sep 25 23:03:34 2006 -0700) 1 commit
- para-walk: walk n trees, index and working tree in parallel
Backburnered.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
+ git-diff/git-apply: make diff output a bit friendlier to GNU patch
(part 2)
Not in v1.5.0.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2006-12-16 23:10 UTC (permalink / raw)
To: git
At the end is a list of stuff merged to 'master' since the last
announcement.
----------------------------------------------------------------
Andy Parkins (1):
git-status always says what branch it's on
Brian Gernhardt (2):
Add --add option to git-repo-config
Make git-diff documentation use [--] when it should.
Johannes Schindelin (3):
INSTALL: no need to have GNU diff installed
git-show: grok blobs, trees and tags, too
Document git-merge-file
Junio C Hamano (7):
Revert "git-diff: Introduce --index and deprecate --cached."
git-svn: allow both diff.color and color.diff
Update git-diff documentation
git-fetch: make it work from within a subdirectory.
git-reset: make it work from within a subdirectory.
git-reset [--mixed] <tree> [--] <paths>...
merge: give a bit prettier merge message to "merge branch~$n"
Luben Tuikov (1):
Export PERL_PATH
Nicolas Pitre (2):
repacked packs should be read-only
make commit message a little more consistent and conforting
Quy Tonthat (1):
git-clone documentation
Shawn Pearce (7):
Bypass expensive content comparsion during rename detection.
Avoid accessing a slow working copy during diffcore operations.
Provide more meaningful output from 'git init-db'.
Enable reflogs by default in any repository with a working directory.
Teach bash the new features of 'git show'.
Suggest use of "git add file1 file2" when there is nothing to commit.
Align section headers of 'git status' to new 'git add'.
^ permalink raw reply
* Re: Subprojects tasks
From: Sven Verdoolaege @ 2006-12-16 23:14 UTC (permalink / raw)
To: Martin Waitz; +Cc: Junio C Hamano, git
In-Reply-To: <20061216225810.GD12411@admingilde.org>
On Sat, Dec 16, 2006 at 11:58:10PM +0100, Martin Waitz wrote:
> On Sat, Dec 16, 2006 at 01:07:04PM -0800, Junio C Hamano wrote:
> > Sven Verdoolaege <skimo@kotnet.org> writes:
> > > On Sat, Dec 16, 2006 at 10:32:36AM -0800, Junio C Hamano wrote:
> > >> I suspect the hardest part is "rev-list --objects" (now most of
> > >> it is found in revision.c). [..] But I think the updated
> > >> code needs to know that "link" needs to be unwrapped and
> > >> contained "commit" needs to be injected back to the ancestry
> > >> walking machinery.
>
> Well, I already got to the point of using the commit directly,
> instead of any link object.
I think Junio is simply refering to the type of the object as represented
in a tree and that the value would indeed just be the commit hash, as in
your implementation.
^ permalink raw reply
* Re: Subprojects tasks
From: Jakub Narebski @ 2006-12-16 23:15 UTC (permalink / raw)
To: Martin Waitz; +Cc: git, Josef Weidendorfer
In-Reply-To: <20061216230108.GE12411@admingilde.org>
Hi!
Martin Waitz wrote:
> On Sat, Dec 16, 2006 at 07:45:11PM +0100, Jakub Narebski wrote:
>>
>> Or .gitlink file, if we decide to implement it (as lightweight checkout and
>> support for submodules which one can easily move/rename).
>
> I still don't get the advantage of a .gitlink file over an ordinary
> repository with alternates or a symlink.
Moving or renaming the directory with a submodule. With alternates,
when you rename or move directory with a submodule, you have to add
alternate for new place / new name, or alter existing alternate.
With symlinks you risk broken symlinks.
When using alternates-like modules file, you can regenerate or
generate "alternates" on checkout, but...
With .gitlink file you can specify GIT_DIR sor submodule as given
directory relative to this directory or one of its parents, so you
can rename and move submodules freely.
P.S. The second (first?) purpose of .gitlink is to be able to have
lightweight checkout, i.e. more than one working area associated with
one repository.
P.P.S. Cc to the author of current .gitlink proposal, to Josef
Weidendorfer.
Message-ID: <200612082252.31245.Josef.Weidendorfer@gmx.de>
http://permalink.gmane.org/gmane.comp.version-control.git/33755
--
Jakub Narebski
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2006-12-16 23:29 UTC (permalink / raw)
To: git
In-Reply-To: <7vodq3a136.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Things that I feel should be done need to be done to complete
> v1.5.0 are:
[...]
> - now reflog is enabled by default for user repositories, I
> have two worries about its effect, fortunately can be killed
> with a single stone.
>
> * the reflog grows unbounded;
>
> * revisions recorded in the reflog can be pruned out,
> rendering some entries in reflog useless.
>
> I am thinking about teaching fsck-objects and prune to keep
> revisions recorded in the reflog; we would need an end-user
> way to prune older reflog entries and I would appreciate
> somebody codes it up, but even without it, people can always
> use "vi" or "ed" on reflog files ;-).
I'd rather not have prune keep revisions recorded in reflog. Reflog
keeps also amended commits, and blobs from incrementally staged
commits. Or perhaps make it an configuration option, default to
true for new users (or have an option to git-prune to ignore reflog).
As of "reflog grows unbounded"... perhaps we should encourage to use
logrotate for that (well, perhaps git-prune and porcelains which deal
with reflog should be able to uncompress reflog if needed).
> - 'git-svn' users should speak out about two issues:
>
> * use of svn command line client as the backend is being
> removed;
>
> * 'git-svn commit' command is being renamed to avoid
> confusion, and potentially 'dcommit' will be renamed to
> 'commit'.
>
> Please discuss these with Eric.
What about remote.<repo>.url = svn://ser.ver/repo/ idea?
> ** jc/reflog (Thu Dec 14 15:58:56 2006 -0800) 1 commit
> - Teach show-branch how to show ref-log data.
>
> A strawman to make reflog data a bit more browsable; it would be
> useful while recovering from a mistake you made recently. Not
> essential and can wait or be dropped if people do not find it
> useful.
Looks useful.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [BUG] making docs blows up in b1bfcae438ad:git-merge-file.txt
From: Randal L. Schwartz @ 2006-12-16 23:41 UTC (permalink / raw)
To: git
asciidoc -b xhtml11 -d manpage -f asciidoc.conf git-merge-file.txt
ERROR: manpage document title is mandatory
ERROR: git-merge-file.txt: line 3: title not permitted in sidebar body
ERROR: git-merge-file.txt: line 8: title not permitted in sidebar body
ERROR: git-merge-file.txt: line 15: title not permitted in sidebar body
ERROR: git-merge-file.txt: line 46: title not permitted in sidebar body
ERROR: git-merge-file.txt: line 65: title not permitted in sidebar body
ERROR: git-merge-file.txt: line 79: title not permitted in sidebar body
ERROR: git-merge-file.txt: line 84: title not permitted in sidebar body
ERROR: git-merge-file.txt: line 89: title not permitted in sidebar body
ERROR: git-merge-file.txt: line 92: closing [blockdef-example] delimiter expected
make[1]: *** [git-merge-file.html] Error 1
make: *** [doc] Error 2
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: [BUG] making docs blows up in b1bfcae438ad:git-merge-file.txt
From: A Large Angry SCM @ 2006-12-16 23:47 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86y7p7cssx.fsf@blue.stonehenge.com>
Randal L. Schwartz wrote:
> asciidoc -b xhtml11 -d manpage -f asciidoc.conf git-merge-file.txt
> ERROR: manpage document title is mandatory
> ERROR: git-merge-file.txt: line 3: title not permitted in sidebar body
> ERROR: git-merge-file.txt: line 8: title not permitted in sidebar body
> ERROR: git-merge-file.txt: line 15: title not permitted in sidebar body
> ERROR: git-merge-file.txt: line 46: title not permitted in sidebar body
> ERROR: git-merge-file.txt: line 65: title not permitted in sidebar body
> ERROR: git-merge-file.txt: line 79: title not permitted in sidebar body
> ERROR: git-merge-file.txt: line 84: title not permitted in sidebar body
> ERROR: git-merge-file.txt: line 89: title not permitted in sidebar body
> ERROR: git-merge-file.txt: line 92: closing [blockdef-example] delimiter expected
> make[1]: *** [git-merge-file.html] Error 1
> make: *** [doc] Error 2
>
>
^ permalink raw reply
* Re: Subprojects tasks
From: Josef Weidendorfer @ 2006-12-17 0:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Martin Waitz, git
In-Reply-To: <200612170015.24162.jnareb@gmail.com>
On Sunday 17 December 2006 00:15, Jakub Narebski wrote:
> Hi!
>
> Martin Waitz wrote:
> > On Sat, Dec 16, 2006 at 07:45:11PM +0100, Jakub Narebski wrote:
> >>
> >> Or .gitlink file, if we decide to implement it (as lightweight checkout and
> >> support for submodules which one can easily move/rename).
> >
> > I still don't get the advantage of a .gitlink file over an ordinary
> > repository with alternates or a symlink.
>
> Moving or renaming the directory with a submodule. With alternates,
> when you rename or move directory with a submodule, you have to add
> alternate for new place / new name, or alter existing alternate.
> With symlinks you risk broken symlinks.
Yes.
IMHO it simply is added flexibility to allow a checkout to be separate from
the .git/ directory, same as explicitly setting $GIT_DIR would do.
So this .gitlink file is on the one hand one kind of convenience for users
which want to keep their repository separate, yet do not want to specify
$GIT_DIR all the time in front of git commands.
The .gitlink file simply makes the linkage to the separate repository
persistent.
In the scope of submodules, you get the benefit that you can not lose
submodule repositories by doing a "rm -rf *" (or similar, e.g. deleting
dirs with submodules in it) in the supermodule checkout. Actually, the
latter is a valid action: delete a submodule in the next commit;
when going back at an earlier commit, the submodule should be there again.
So IMHO you allow far more possibilities by separating GITDIR from the
checkout of submodules.
However. I think that this .gitlink file proposal can be seen as kind
of independent from submodule support at first; it should be easy to
make this work together later on. E.g. submodule root directories
can be easily detected when they have a .gitlink file (instead of
.git/ directory), and so on.
This said, I started implementing it, but do not have anything useful
to show yet.
Some issues:
* Probably, it is better to go with a _file_ .git instead of a file
.gitlink, as this way, the user is forced to either go with the
git repository in _directory_ .git/ or external linkage with
the _file_ ".git".
* Even when a .gitlink file is detected, we should honor a
$GIT_DIR environment variable set by the user. Unfortunately, $GIT_DIR
also can be set by porcelain commands to specify "this command only
works in the toplevel directory of a git checkout", i.e. these
porcelain commands set GIT_DIR to ".git". IMHO this is a hack, and
we explicitly should tell the plumbing about these need e.g. via another
environment variable (or a option) without implicitly forcing it by
setting $GIT_DIR.
* In the way to make the .gitlink file as flexible as
possible (and to use it for lightweight checkouts), it really should
support $GIT_HEAD_FILE, which would replace "HEAD" with the content
of $GIT_HEAD_FILE. E.g. with GIT_HEAD_FILE=MYHEAD, the command
"git log HEAD" really should internally work as "git log MYHEAD"
(ie. use the .git/MYHEAD file instead). It is arguable whether the
usage of "ORIG_HEAD" by the user or in porcelain should map to file
"ORIG_MYHEAD". Probably not. However, changing this in all places
is some work, and I assume that therefore nobody has ever implemented
$GIT_HEAD_FILE - which IMHO really would be useful by itself.
^ permalink raw reply
* Re: Subprojects tasks
From: Josef Weidendorfer @ 2006-12-17 0:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Martin Waitz, git
In-Reply-To: <200612170015.24162.jnareb@gmail.com>
On Sunday 17 December 2006 00:15, Jakub Narebski wrote:
> > I still don't get the advantage of a .gitlink file over an ordinary
> > repository with alternates or a symlink.
Forgot one thing:
To separate the repository files from a checkout, a symlink is not
enough, as you lose the linkage when you move the checkout or the
repository; you could use an absolute symlink target, but that also
has inconveniences.
So you want some kind of smart linking. And this is another
important part of the .gitlink file proposal.
^ permalink raw reply
* [PATCH 1/2] Teach all of log family --left-right output.
From: Junio C Hamano @ 2006-12-17 0:12 UTC (permalink / raw)
To: git
This makes reviewing
git log --left-right --merge --no-merges -p
a lot more pleasant.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is on the tip of jc/leftright topic, currently only in
'pu'. Earlier I had this only for git-rev-list. Now log
family knows about this.
builtin-rev-list.c | 7 +------
log-tree.c | 26 ++++++++++++++++++++++----
revision.c | 4 ++++
revision.h | 1 +
4 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 4364035..1bb3a06 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -45,7 +45,6 @@ static int bisect_list;
static int show_timestamp;
static int hdr_termination;
static const char *header_prefix;
-static int show_left_right;
static void show_commit(struct commit *commit)
{
@@ -55,7 +54,7 @@ static void show_commit(struct commit *commit)
fputs(header_prefix, stdout);
if (commit->object.flags & BOUNDARY)
putchar('-');
- else if (show_left_right) {
+ else if (revs.left_right) {
if (commit->object.flags & SYMMETRIC_LEFT)
putchar('<');
else
@@ -247,10 +246,6 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
bisect_list = 1;
continue;
}
- if (!strcmp(arg, "--left-right")) {
- show_left_right = 1;
- continue;
- }
if (!strcmp(arg, "--stdin")) {
if (read_from_stdin++)
die("--stdin given twice?");
diff --git a/log-tree.c b/log-tree.c
index 8787df5..35be33a 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -114,6 +114,14 @@ void show_log(struct rev_info *opt, const char *sep)
opt->loginfo = NULL;
if (!opt->verbose_header) {
+ if (opt->left_right) {
+ if (commit->object.flags & BOUNDARY)
+ putchar('-');
+ else if (commit->object.flags & SYMMETRIC_LEFT)
+ putchar('<');
+ else
+ putchar('>');
+ }
fputs(diff_unique_abbrev(commit->object.sha1, abbrev_commit), stdout);
if (opt->parents)
show_parents(commit, abbrev_commit);
@@ -192,10 +200,20 @@ void show_log(struct rev_info *opt, const char *sep)
opt->diffopt.stat_sep = buffer;
}
} else {
- printf("%s%s%s",
- diff_get_color(opt->diffopt.color_diff, DIFF_COMMIT),
- opt->commit_format == CMIT_FMT_ONELINE ? "" : "commit ",
- diff_unique_abbrev(commit->object.sha1, abbrev_commit));
+ fputs(diff_get_color(opt->diffopt.color_diff, DIFF_COMMIT),
+ stdout);
+ if (opt->commit_format != CMIT_FMT_ONELINE)
+ fputs("commit ", stdout);
+ if (opt->left_right) {
+ if (commit->object.flags & BOUNDARY)
+ putchar('-');
+ else if (commit->object.flags & SYMMETRIC_LEFT)
+ putchar('<');
+ else
+ putchar('>');
+ }
+ fputs(diff_unique_abbrev(commit->object.sha1, abbrev_commit),
+ stdout);
if (opt->parents)
show_parents(commit, abbrev_commit);
if (parent)
diff --git a/revision.c b/revision.c
index 3d989c3..d84f46e 100644
--- a/revision.c
+++ b/revision.c
@@ -853,6 +853,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
revs->boundary = 1;
continue;
}
+ if (!strcmp(arg, "--left-right")) {
+ revs->left_right = 1;
+ continue;
+ }
if (!strcmp(arg, "--objects")) {
revs->tag_objects = 1;
revs->tree_objects = 1;
diff --git a/revision.h b/revision.h
index f92a4d4..4585463 100644
--- a/revision.h
+++ b/revision.h
@@ -41,6 +41,7 @@ struct rev_info {
limited:1,
unpacked:1, /* see also ignore_packed below */
boundary:1,
+ left_right:1,
parents:1;
/* Diff flags */
--
1.4.4.2.g83c5
^ permalink raw reply related
* [PATCH 2/2] Make left-right automatic.
From: Junio C Hamano @ 2006-12-17 0:12 UTC (permalink / raw)
To: git
When using symmetric differences, I think the user almost always
would want to know which side of the symmetry each commit came
from. So this removes --left-right option from the command
line, and turns it on automatically when a symmetric difference
is used ("git log --merge" counts as a symmetric difference
between HEAD and MERGE_HEAD).
Just in case, a new option --no-left-right is provided to defeat
this, but I do not know if it would be useful.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I think this would make life easier for merge-heavy people.
I'd push this out on 'next' soonish.
revision.c | 13 ++++++++++---
revision.h | 1 +
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/revision.c b/revision.c
index d84f46e..56819f8 100644
--- a/revision.c
+++ b/revision.c
@@ -853,8 +853,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
revs->boundary = 1;
continue;
}
- if (!strcmp(arg, "--left-right")) {
- revs->left_right = 1;
+ if (!strcmp(arg, "--no-left-right")) {
+ revs->no_left_right = 1;
continue;
}
if (!strcmp(arg, "--objects")) {
@@ -1055,13 +1055,18 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
void prepare_revision_walk(struct rev_info *revs)
{
int nr = revs->pending.nr;
+ int has_symmetric = 0;
struct object_array_entry *list = revs->pending.objects;
revs->pending.nr = 0;
revs->pending.alloc = 0;
revs->pending.objects = NULL;
while (--nr >= 0) {
- struct commit *commit = handle_commit(revs, list->item, list->name);
+ struct commit *commit;
+
+ if (list->item->flags & SYMMETRIC_LEFT)
+ has_symmetric = 1;
+ commit = handle_commit(revs, list->item, list->name);
if (commit) {
if (!(commit->object.flags & SEEN)) {
commit->object.flags |= SEEN;
@@ -1073,6 +1078,8 @@ void prepare_revision_walk(struct rev_info *revs)
if (revs->no_walk)
return;
+ if (!revs->no_left_right && has_symmetric)
+ revs->left_right = 1;
if (revs->limited)
limit_list(revs);
if (revs->topo_order)
diff --git a/revision.h b/revision.h
index 4585463..b2ab814 100644
--- a/revision.h
+++ b/revision.h
@@ -41,6 +41,7 @@ struct rev_info {
limited:1,
unpacked:1, /* see also ignore_packed below */
boundary:1,
+ no_left_right:1,
left_right:1,
parents:1;
--
1.4.4.2.g83c5
^ permalink raw reply related
* Re: [PATCH] Add file addition/deletion indicator in diffstat
From: Nguyen Thai Ngoc Duy @ 2006-12-17 0:12 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <20061111123331.GA23829@localhost>
Hi Junio,
I have used this patch for a while and found it actually useful,
especially while inspecting "git-log --stat". And if you prefer "git
diff --stat" over "git status", it may tell you which file you added
or deleted. So my only guess is that you missed it somehow. If it is
refused, may I know the reason? I can improve it on request :-)
On 11/11/06, pclouds@gmail.com <pclouds@gmail.com> wrote:
> For new files, " (new)" will be appended to filenames.
> For deleted files, " (deleted)" will be appended to filenames.
--
^ permalink raw reply
* Re: [BUG] making docs blows up in b1bfcae438ad:git-merge-file.txt
From: The Answering Machine @ 2006-12-16 23:47 UTC (permalink / raw)
To: git
In-Reply-To: <4584857D.703@gmail.com>
I've received your mail.
Your message has been queued, and will probably be read within 48 hours.
In the meanwhile, if you're curious about where I am, or what I'm
doing, or have a question that you think I might get asked frequently,
or answer frequently even when not asked, you can check out my FAQ by
sending email to the FAQserver at:
<merlyn-faq@stonehenge.com>
(The subject line and body of the message are ignored.)
Thank you!
(Please save this message. You'll get it only once a month, although
the FAQ above is updated frequently and you can request it as you wish.)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] Add file addition/deletion indicator in diffstat
From: Junio C Hamano @ 2006-12-17 0:15 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0612161612r36470c2fm3c0f19e56f6a16a@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> I have used this patch for a while and found it actually useful,
> especially while inspecting "git-log --stat". And if you prefer "git
> diff --stat" over "git status", it may tell you which file you added
> or deleted. So my only guess is that you missed it somehow. If it is
> refused, may I know the reason? I can improve it on request :-)
Doesn't seem to add much value over existing --summary.
^ permalink raw reply
* Re: git-add fails after file type change
From: Steven Grimm @ 2006-12-17 0:19 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Git Mailing List
In-Reply-To: <45843C5A.8020501@gmail.com>
A Large Angry SCM wrote:
> Did you try "git-update-index --replace dir"?
Turns out that doesn't work. It gives me the same error I get without
the --replace option:
error: dir: cannot add to the index - missing --add option?
fatal: Unable to process file dir
However, "git rm" followed by "git add" does seem to work. So for now it
looks like that'll be the best bet when I run into this problem (should
be possible to automate it, even.) The better error message from Junio's
patch will at least make the failure less mysterious.
IMO it'd still be nice if the porcelain could provide a "make the index
look like the working directory" operation that worked even in the face
of changes like this, adding and/or removing files as needed. But it's
possible that my crazy git-as-backup-device setup is the only place
where this is even an issue; typical git users can use "git mv" and
never run into the problem.
-Steve
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-17 0:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <em1vgj$bc3$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Things that I feel should be done need to be done to complete
>> v1.5.0 are:
> [...]
>> - now reflog is enabled by default for user repositories, I
>> have two worries about its effect, fortunately can be killed
>> with a single stone.
>>
>> * the reflog grows unbounded;
>>
>> * revisions recorded in the reflog can be pruned out,
>> rendering some entries in reflog useless.
>>
>> I am thinking about teaching fsck-objects and prune to keep
>> revisions recorded in the reflog; we would need an end-user
>> way to prune older reflog entries and I would appreciate
>> somebody codes it up, but even without it, people can always
>> use "vi" or "ed" on reflog files ;-).
>
> I'd rather not have prune keep revisions recorded in reflog. Reflog
> keeps also amended commits, and blobs from incrementally staged
> commits.
That is exactly why I would want to protect them from pruning;
the current alternative, git-lost-found, is usable but not so
nice from the point of view of end users . The user should be
able to use show-branch --reflog, or use a different mode of
operation in the log family [*1*] to inspect the otherwise lost
commits, and as you prune unneeded reflog entries you could
prune those objects.
You could certainly arrange things the other way around. As a
part of prune, you can prune the reflog entries that refer to
commits that were pruned away and no longer available.
HOWEVER, that is very unfriendly to the end users, because they
do not have much control in what 'prune' removes. If you want
to keep a dozen or so recent states just in case you may have to
salvage rewound states (e.g. you may realize your amended commit
was faulty), how would you tell 'prune' to keep only those
objects from getting pruned?
That's right -- by holding references to them. And that is
exactly how making prune to take reflog into account would help
the user. If the user has unwanted commits (say, everything
that are more than 7 days old, plus this and that commits you
rewound an hour ago), they can be pruned away from reflog and
prune will take care of the rest.
So doing it in the way I described makes a lot more sense than
doing the other way around.
[Footnote]
*1* I have to warn you that this would require quite different
code to walk the commits, but certainly a lot simpler than the
ancestry traversal. If you are interested in learning the
internals, this may be a good project to start with.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Torgil Svensson @ 2006-12-17 0:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Josef Weidendorfer, R. Steve McKown, Linus Torvalds
In-Reply-To: <200612161732.11746.jnareb@gmail.com>
On 12/16/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Well, I just rather have than <sha1 of tree/blob> the definition
> of sparse checkout (for example subdirectory name, or file name,
> or glob pattern).
This is entirely an UI issue:
On 12/16/06, Torgil Svensson <torgil.svensson@gmail.com> wrote:
> is based around Linus 'module'-file and keep things simple. A git
> configuration file that specifies:
> * link name for reference
> * local path to link
> * submodule source
> * submodule path to tree/blob
> * submodule commit / HEAD / branch
> * options (depth-limit , ...)
On 12/16/06, Jakub Narebski <jnareb@gmail.com> wrote:
> And if you have that, you don't need <sha1 of tree/blob> in repository, in link object.
Correct. Since the commit contains all the version information, the
following combinations should give the same information iff we keep
the commit in the database:
1. <sha1 of commit> + <sha1 of tree/blob>
2. <sha1 of commit> + <symlink to tree/blob>
I used the sha1 because I wanted them to behave exactly like
trees/blobs in the database for operations that can disregard the
commit info. Now, if we keep the commit in the database as Linus
suggests we can reach the target from there with a symlink. This would
be more readable but also cost a few object lookups extra iterating
over the symlink.
> With sparse (for example defined by 'src/*.h') or partial (for example
> defined by 'Documentation/') checkout you should be able to merge
> upstream... unless conflicts are in the not checked out part.
This would be a great feature! Will this conflict with path shortcuts?
If so, we might consider two types of objects: "link" which cannot
merge upstream and "module" which can merge upstream and contains a
.git object repository.
IMHO, "module" is a more intuitive name for specifying a
(functionality wise fully fledged) submodule with a repository inside.
"link" could be used for just mirroring a tree/blob. I'm not sure if a
separation is needed on a technical level.
> Have you read http://git.or.cz/gitwiki/SubprojectSupport on GitWiki?
Yes
> Have you tested the experimental submodule support (proof of concept)
Not yet
^ permalink raw reply
* Re: [PATCH] Add file addition/deletion indicator in diffstat
From: Nguyen Thai Ngoc Duy @ 2006-12-17 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcvv8jjb.fsf@assigned-by-dhcp.cox.net>
On 12/17/06, Junio C Hamano <junkio@cox.net> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > I have used this patch for a while and found it actually useful,
> > especially while inspecting "git-log --stat". And if you prefer "git
> > diff --stat" over "git status", it may tell you which file you added
> > or deleted. So my only guess is that you missed it somehow. If it is
> > refused, may I know the reason? I can improve it on request :-)
>
> Doesn't seem to add much value over existing --summary.
Oh.. I didn't know that option. Sorry for the noise.
--
^ permalink raw reply
* Re: Subprojects tasks
From: Josef Weidendorfer @ 2006-12-17 0:32 UTC (permalink / raw)
To: Martin Waitz; +Cc: Junio C Hamano, skimo, git
In-Reply-To: <20061216225810.GD12411@admingilde.org>
On Saturday 16 December 2006 23:58, Martin Waitz wrote:
> > If the plumbing layer does not have to (although I haven't
> > thought it through, it does feel like it even shouldn't) unwrap
> > "link" and let the Porcelain layer to deal with it, that would
> > certainly make rev-list/revision.c part simpler.
>
> Yes. However, it makes other things more complicated.
> If the plumbing does not do all the subproject stuff and you don't have
> everything in one database
Even without plumbing doing the subproject stuff, we could use the
same, unified database for the objects. Or do I miss something?
As you said: the problem are submodule commit in superproject trees which
are not reachable by refs of the submodule. However, we only need these
commits when cloning/fetching the submodule in the scope of cloning/fetching
the superproject; we simply can not use here a normal repository of the
submodule, as these commits would be not available there.
We should add a plumbing command for "Give me the minimal set of commits
(from all submodules) which have all the submodule link object ids as ancestors
which appear in the history of a given commit (from a superproject)".
With this, building the set of objects to pack/fetch/clone into a unified
object database for a superproject with its submodules should be easy.
It is also needed for pruning the unified object database.
Pruning in submodules simply would print out an error "Pruning in submodules
not supported. Prune in the superproject instead".
Josef
^ permalink raw reply
* Re: git-add fails after file type change
From: Junio C Hamano @ 2006-12-17 0:46 UTC (permalink / raw)
To: git
In-Reply-To: <45848CF8.4000704@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> A Large Angry SCM wrote:
>> Did you try "git-update-index --replace dir"?
>
> Turns out that doesn't work. It gives me the same error I get without
> the --replace option:
>
> error: dir: cannot add to the index - missing --add option?
> fatal: Unable to process file dir
"update-index --replace --add" would be the way.
$ git ls-files -s
100644 fa457baf8abbf5dd3bb4cbfab0c5a4cf0523d7f8 0 1/2
100644 00750edc07d6415dcc07ae0351e9397b0222b7ba 0 3
$ ls -F
./ ../ 1/ 3 .git/
There is file 1/2 in directory 1.
$ mv 1 tmp ; mv 3 1 ; mv tmp 3
$ ls -F
./ ../ 1 3/ .git/
I just swapped them.
$ git update-index --replace --add 1
$ git ls-files -s
100644 00750edc07d6415dcc07ae0351e9397b0222b7ba 0 1
100644 00750edc07d6415dcc07ae0351e9397b0222b7ba 0 3
You are allowing update-index to 'add' things so you would need
to say --add regardless of --replace (--replace is only to allow
removal of conflicting entries while adding). In the hindsight,
we could have implied --add with --replace, but that is the way
it is, and update-index is not a Porcelain so there is not much
point fixing it now.
But I think you helped me to spot a bug ;-).
$ git update-index --replace --add 3/2
$ git ls-files -s
100644 00750edc07d6415dcc07ae0351e9397b0222b7ba 0 1
100644 00750edc07d6415dcc07ae0351e9397b0222b7ba 0 3
100644 fa457baf8abbf5dd3bb4cbfab0c5a4cf0523d7f8 0 3/2
The entry '3' should have been removed when we did --replace.
This index cannot be written out as a tree:
$ git write-tree
You have both 3 and 3/2
fatal: git-write-tree: error building trees
Currently we need to remove '3' by hand X-<.
$ git update-index --remove 3
$ git ls-files -s
100644 00750edc07d6415dcc07ae0351e9397b0222b7ba 0 1
100644 fa457baf8abbf5dd3bb4cbfab0c5a4cf0523d7f8 0 3/2
$ git write-tree
77be0dd800d74913a90662e35215ee648815fc17
^ permalink raw reply
* Re: git-add fails after file type change
From: Junio C Hamano @ 2006-12-17 1:39 UTC (permalink / raw)
To: git
In-Reply-To: <7vvekb73jh.fsf@assigned-by-dhcp.cox.net>
When replacing an existing file A with a directory B that has a
file B/C in it in the index, 'update-index --replace --add B/C'
did not properly remove the file to make room for the new
directory.
There was a trivial logic error, most likely a cut & paste one,
dating back to quite early days of git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> But I think you helped me to spot a bug ;-).
>
> $ git update-index --replace --add 3/2
> $ git ls-files -s
> 100644 00750edc07d6415dcc07ae0351e9397b0222b7ba 0 1
> 100644 00750edc07d6415dcc07ae0351e9397b0222b7ba 0 3
> 100644 fa457baf8abbf5dd3bb4cbfab0c5a4cf0523d7f8 0 3/2
>
> The entry '3' should have been removed when we did --replace.
> This index cannot be written out as a tree:
>
> $ git write-tree
> You have both 3 and 3/2
> fatal: git-write-tree: error building trees
And this fixes it.
read-cache.c | 2 +-
t/t0000-basic.sh | 9 +++++++++
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index a602010..e856a2e 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -517,7 +517,7 @@ static int has_dir_name(const struct cache_entry *ce, int pos, int ok_to_replace
pos = cache_name_pos(name, ntohs(create_ce_flags(len, stage)));
if (pos >= 0) {
retval = -1;
- if (ok_to_replace)
+ if (!ok_to_replace)
break;
remove_cache_entry_at(pos);
continue;
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
index 3260d1d..0cd1c41 100755
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -272,4 +272,13 @@ test_expect_success \
wc -l) &&
test $numparent = 1'
+test_expect_success 'update-index D/F conflict' '
+ mv path0 tmp &&
+ mv path2 path0 &&
+ mv tmp path2 &&
+ git update-index --add --replace path2 path0/file2 &&
+ numpath0=$(git ls-files path0 | wc -l) &&
+ test $numpath0 = 1
+'
+
test_done
^ permalink raw reply related
* Re: [RFC] gitweb wishlist and TODO list (part 1)
From: Junio C Hamano @ 2006-12-17 1:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Kernel Org Admin, Petr Baudis
In-Reply-To: <200612170000.06771.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> This is yet another series of planned gitweb features. This part
> concentrates on improving gitweb rather than on adding new features.
> Comments appreciated.
>
> Copy send to Kernel.Org admin (which probably is most interested
> in improving gitweb and git performance), and to Petr Baudis which
> maintains repo.or.cz public git hosting site, which runs new(est)
> version of gitweb.
To be honest, I think the 0th item of this wishlist and TODO
list would be to find a sucker^Wvolunteer who will maintain the
gitweb installation at kernel.org, for the message to be of any
interest to kernel.org admins.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox