* [PATCH] gitweb: Restore object-named links in item lists
From: Petr Baudis @ 2006-10-24 3:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20061024031240.2500.93420.stgit@rover>
This restores the redundant links removed earlier. It supersedes my patch
to stick slashes to tree entries.
Sorry about the previous version of the patch, an unrelated snapshot link
addition to tree entries slipped through (and it it didn't even compile);
I've dropped the idea of snapshot links in tree entries in the meantime
anyway.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 28 ++++++++++++++++++++++------
1 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4a2025c..661d1dd 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1793,16 +1793,18 @@ sub git_print_tree_entry {
file_name=>"$basedir$t->{'name'}", %base_key),
-class => "list"}, esc_html($t->{'name'})) . "</td>\n";
print "<td class=\"link\">";
+ print $cgi->a({-href => href(action=>"blob", hash=>$t->{'hash'},
+ file_name=>"$basedir$t->{'name'}", %base_key)},
+ "blob");
if ($have_blame) {
- print $cgi->a({-href => href(action=>"blame", hash=>$t->{'hash'},
+ print " | " .
+ $cgi->a({-href => href(action=>"blame", hash=>$t->{'hash'},
file_name=>"$basedir$t->{'name'}", %base_key)},
"blame");
}
if (defined $hash_base) {
- if ($have_blame) {
- print " | ";
- }
- print $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
+ print " | " .
+ $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
hash=>$t->{'hash'}, file_name=>"$basedir$t->{'name'}")},
"history");
}
@@ -1819,8 +1821,12 @@ sub git_print_tree_entry {
esc_html($t->{'name'}));
print "</td>\n";
print "<td class=\"link\">";
+ print $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
+ file_name=>"$basedir$t->{'name'}", %base_key)},
+ "tree");
if (defined $hash_base) {
- print $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
+ print " | " .
+ $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
file_name=>"$basedir$t->{'name'}")},
"history");
}
@@ -1903,6 +1909,9 @@ sub git_difftree_body {
print $cgi->a({-href => "#patch$patchno"}, "patch");
print " | ";
}
+ print $cgi->a({-href => href(action=>"blob", hash=>$diff{'from_id'},
+ hash_base=>$parent, file_name=>$diff{'file'})},
+ "blob") . " | ";
print $cgi->a({-href => href(action=>"blame", hash_base=>$parent,
file_name=>$diff{'file'})},
"blame") . " | ";
@@ -1948,6 +1957,9 @@ sub git_difftree_body {
}
print " | ";
}
+ print $cgi->a({-href => href(action=>"blob", hash=>$diff{'to_id'},
+ hash_base=>$hash, file_name=>$diff{'file'})},
+ "blob") . " | ";
print $cgi->a({-href => href(action=>"blame", hash_base=>$hash,
file_name=>$diff{'file'})},
"blame") . " | ";
@@ -1988,6 +2000,9 @@ sub git_difftree_body {
}
print " | ";
}
+ print $cgi->a({-href => href(action=>"blob", hash=>$diff{'from_id'},
+ hash_base=>$parent, file_name=>$diff{'from_file'})},
+ "blob") . " | ";
print $cgi->a({-href => href(action=>"blame", hash_base=>$parent,
file_name=>$diff{'from_file'})},
"blame") . " | ";
@@ -2155,6 +2170,7 @@ sub git_shortlog_body {
href(action=>"commit", hash=>$commit), $ref);
print "</td>\n" .
"<td class=\"link\">" .
+ $cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") . " | " .
$cgi->a({-href => href(action=>"commitdiff", hash=>$commit)}, "commitdiff") . " | " .
$cgi->a({-href => href(action=>"tree", hash=>$commit, hash_base=>$commit)}, "tree");
if (gitweb_have_snapshot()) {
^ permalink raw reply related
* Pushing vs. alternates
From: Petr Baudis @ 2006-10-24 3:53 UTC (permalink / raw)
To: git
Hi,
I don't have time to code that myself right now, so I'm just tossing
an idea around - pushing to a directory with alternates set up should
avoid sending objects that are already in the alternate object database.
This is obviously very hard to achieve, but I think it should be
possible to do something like look if $alternate/../refs/ exists and in
that case send haves for those refs - that could give good results. Or
is that a bad idea for some reason?
That would be quite useful for the repo.or.cz's forked objects.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* [ANNOUNCE] repo.or.cz now supports "project forks"
From: Petr Baudis @ 2006-10-24 4:52 UTC (permalink / raw)
To: git
Hi,
FYI, the http://repo.or.cz/ public Git hosting now supports project
forking, which basically means that if you've done something cool to an
existing project and want to publish your work, you can create a "fork"
of the project on repo.or.cz and it will group nicely together in gitweb
and users will be hinted about the possibility to use --reference when
cloning your changes; also, repo.or.cz disk space will be conserved
thanks to the alternates mechanism. ;-)
The other main goal aside gitweb grouping wasn't achieved yet though -
greatly reduced push times. Hey, pushing Git to a new repository takes
inordinate amount of time (actually also mostly because all the objects are
unpacked on the remote side, which is silly as well), I didn't try pushing
Linux kernel to a fresh repository but it'll likely take ages. The idea
would be to make git-receive-pack take alternates into account when
announcing what commits does the server side have, but someone will need
to code up a patch for that...
It wasn't tested heavily, so please tell me about any warts you hit.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Pushing vs. alternates
From: Junio C Hamano @ 2006-10-24 5:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061024035335.GW20017@pasky.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
> I don't have time to code that myself right now, so I'm just tossing
> an idea around - pushing to a directory with alternates set up should
> avoid sending objects that are already in the alternate object database.
That is probably only relevant for the first time, since
subsequent pushes have refs from its own repository that tracks
the tips of branches that was pushed for the last time.
And first time usage when you are initializing the repository
with alternates, you have direct access to that repository
(that's how you can set up alternates), you can as easily do the
initial fetch/clone as well at that time.
So it might be a nice addition but I suspect it would not matter
much in practice.
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-24 5:42 UTC (permalink / raw)
To: Matthew D. Fuller; +Cc: Jakub Narebski, bazaar-ng, git, Erik Bågfors
In-Reply-To: <20061024003834.GE17019@over-yonder.net>
On Mon, 23 Oct 2006, Matthew D. Fuller wrote:
> On Mon, Oct 23, 2006 at 07:26:57PM -0500 I heard the voice of
> Matthew D. Fuller, and lo! it spake thus:
> > On Mon, Oct 23, 2006 at 04:24:30PM -0700 I heard the voice of
> > Linus Torvalds, and lo! it spake thus:
> > >
> > > The problem? How do you show a commit that is _common_ to two
> > > branches, but has different revision names in them?
> >
> > Why would you?
>
> I beg your pardon; that was awful ambiguous of me. I meant "In such a
> case, where the whole purpose of what you're doing is to you're look
> at multiple branches to see relationships between them, why WOULD you
> be using branch-local identifiers for revisions at all?"
Well, I would use the globally unique ones, certainly. It's the only thing
that makes sense.
However, I'd also argue that once you start doing that, _mixing_ the
globally unique and stable ones and the "simple" ones is a mistake: you'd
be better off having told your users to use the global ones from the very
beginning, and trying to make _those_ as simple to use as possible.
Because once you start using both, you're just going to confuse your users
horribly, and they'll consider the globally unique one really irritating,
because they're used to using something totally different in most other
contexts.
Using the _same_ names everywhere is just better.
Linus
^ permalink raw reply
* Re: [PATCH] Make git-branch a builtin
From: Shawn Pearce @ 2006-10-24 5:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfydewqbb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Lars Hjemli <hjemli@gmail.com> wrote:
> > [snip]
> >> ---
> >> Makefile | 3 +-
> >> builtin-branch.c | 217 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> builtin.h | 1 +
> >> git-branch.sh | 131 --------------------------------
> >> git.c | 1 +
> >> 5 files changed, 221 insertions(+), 132 deletions(-)
> > [snip]
> >> diff --git a/git-branch.sh b/git-branch.sh
> >> deleted file mode 100755
> >> index 4379a07..0000000
> >> --- a/git-branch.sh
> >> +++ /dev/null
> >> @@ -1,131 +0,0 @@
> > [snip 131 lines]
> >
> > Aside from compatability with non-Git tools...
> >
> > Wouldn't it make more sense to just include the full SHA1 of the
> > file we are deleting rather than the entire 131 line negative diff?
>
> How would you do "git apply -R" on something like that?
Uh, you have the full SHA1 in the index line. So you just have to
reattach that blob to the named path... pretty simple actually.
Of course this is yet another code path in apply and as Petr pointed
out on this same thread its nice to know what you are deleting so
you can compare it to what else is changing in the same patch... so
this suggestion of mine is probably just a waste of bytes.
--
Shawn.
^ permalink raw reply
* Re: Pushing vs. alternates
From: Shawn Pearce @ 2006-10-24 5:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vmz7muvqu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Petr Baudis <pasky@ucw.cz> writes:
>
> > I don't have time to code that myself right now, so I'm just tossing
> > an idea around - pushing to a directory with alternates set up should
> > avoid sending objects that are already in the alternate object database.
>
> That is probably only relevant for the first time, since
> subsequent pushes have refs from its own repository that tracks
> the tips of branches that was pushed for the last time.
>
> And first time usage when you are initializing the repository
> with alternates, you have direct access to that repository
> (that's how you can set up alternates), you can as easily do the
> initial fetch/clone as well at that time.
>
> So it might be a nice addition but I suspect it would not matter
> much in practice.
What would be useful in practice is not unpacking the first pack
pushed to the an empty repository, or better yet just dealing with
converting thin packs to standalone packs rather than unpacking
to loose objects when the number of objects in the incoming pack
exceeds some configured threshold.
Which Linus and Nico already took stabs at doing but haven't finished...
--
Shawn.
^ permalink raw reply
* Re: VCS comparison table
From: Shawn Pearce @ 2006-10-24 5:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Erik Bågfors, bazaar-ng, git, Matthew D. Fuller,
Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0610232239220.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> Using the _same_ names everywhere is just better.
I find that it is simpler too. :-)
^ permalink raw reply
* Re: updating only changed files source directory?
From: Shawn Pearce @ 2006-10-24 5:55 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <ehjqgf$ggb$1@sea.gmane.org>
Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
> For a VCS, this is slightly nonstandard use, as we don't do any work
> in the working dir, we just compile from it, but have many working
> directories.
Its not nonstandard use. A lot of projects perform rolling builds
which trigger anytime there are changes; very active projects
would always be building and thus would always want to have the
VCS only update those files which actually changed, to minimize
the compile time.
> I have some questions and remarks
>
> * Is there a command analogous to git-clone for updating a repository?
> Right now, I'm using a combination of
Yes, its called git-fetch and git-pull. Which leads us to...
> git-http-fetch -a <branch> <url>
> wget <url>/refs/head/<branch> ## dump to <myrepo>/refs/head/<branch>
>
> for all branches I want to know about. I was looking for a command
> that would update the heads of all branches.
Why not use git-fetch?
Create a .git/remotes file named 'origin' and put in there the URL
you want to fetch from and the list of branches you want to download
and keep current.
Then downloading the changes to the build repository is as simple
as running `git-fetch` with no parameters (as it defaults to reading
the origin file).
> * How do I update a source directory?
Always keep the source directory on a branch that is not listed
in the .git/remotes/origin file. This way the fetch will always
succeed without failure.
Then you can do after the fetch:
git-reset --hard <committish>
and the source directory will be updated to <committish> (which
could just be a branch name of one of those branches you fetch,
or could be a full SHA1, or a tag, etc.).
The reset --hard process will only change the files that really have
to change. This means it will run in linear time proportional to the
number of files needing to be updated; and only those files which are
different between the working directory and <committish> will have
new modification dates. Therefore incremental rebuilds will work.
> * As far as I can see, there is no reason to have only one index in a
> git repository. Why isn't it possible to specify an alternate
> index-file with an option similar to --git-dir ?
The index is key to getting the fast update of the working directory.
You can change the index with the (rather undocuments) GIT_INDEX_FILE
environment variable. I do this in a few tools I have written
around Git, but I don't do it very often.
--
Shawn.
^ permalink raw reply
* Re: VCS comparison table
From: Lachlan Patrick @ 2006-10-24 6:02 UTC (permalink / raw)
To: bazaar-ng, git
In-Reply-To: <vpq4ptz2uh8.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
> Sean <seanlkml@sympatico.ca> writes:
>> We don't need plugins to extend features, we just add the feature to
>> the source. The example I asked about earlier is a case in point.
>> Apparently in bzr "bisect" was implemented as a plugin, yet in Git it
>> was implemented as a command without any issue at all,
>
> I'd compare bzr's plugins to Firefox extensions.
So, bzr's plug-in architecture provides a 'protocol' for communicating
with bzr? Or is it functionally the same as a Python module which is
loaded after being named on the bzr command-line (or placed in a special
folder) then executed along with all the other plug-ins? I'm trying to
understand if writing a plug-in is any simpler than understanding the
bzr source code.
Can I ask the git folks what Sean meant in the above about a 'command'.
Are you talking about shell scripts? Is 'git' the only program you need?
AFAIK, 'bzr' is the sole program in Bazaar, and everything is done with
command line options to bzr. Is that true of git? To what extent is git
tied to a [programmable] shell? I've heard someone say there's no
Windows version of git for some reason, can someone elaborate?
Ta,
Loki
^ permalink raw reply
* Re: VCS comparison table
From: Shawn Pearce @ 2006-10-24 6:23 UTC (permalink / raw)
To: Lachlan Patrick; +Cc: bazaar-ng, git
In-Reply-To: <453DAC87.8050203@research.canon.com.au>
Lachlan Patrick <loki@research.canon.com.au> wrote:
> Can I ask the git folks what Sean meant in the above about a 'command'.
> Are you talking about shell scripts? Is 'git' the only program you need?
'git' is actually two things:
1) Its a wrapper command which executes 'git-foo' if you call it
with 'foo' as its first parameter. It searches for 'git-foo'
in the GIT_EXEC_PATH environment variable, which has a default
set at compile time, usually to the directory you are going to
install Git into.
2) Its most of the core Git plumbing. There are currently around 48
'builtin' commands. These are things which 'git' knows how to do
without executing another program. If you look at the installation
these 48 builtin commands are just hardlinks back to 'git'. For
example 'git-update-index' is really just a hardlink back to 'git'
and 'git' knows to perform the update index logic when its called
as either 'git-update-index' or as 'git update-index'.
We're moving more towards #2, but there are still a large number
of commands which fall into #1.
> AFAIK, 'bzr' is the sole program in Bazaar, and everything is done with
> command line options to bzr. Is that true of git?
No. In Git at least half of the things Git can do are not builtin to
'git' and thus require exec()'ing an external program (e.g. git-fetch).
However these often appear as though they are command line options to
'git' as 'git fetch' just means exec 'git-fetch' (by #1 above).
On the other hand there are a wide range of tools which are more or
less the same thing, just with different options applied to them.
All of the diff programs, log, whatchanged, show - these are all
just variations on a theme. Their individual implementations are
very tiny as they all use the same library code.
> To what extent is git
> tied to a [programmable] shell?
Git is still very much tied to a shell. For example 'git commit'
is really the shell script 'git-commit'. This is a rather long
shell script and it does a lot of things for the user; not having
it would make Git useless to for most people. It also has not been
rewritten in C. There is a roadmap however to convert it to C to
help remove the programmable shell requirement and people have been
slowly performing the (rather tedious) conversion work.
> I've heard someone say there's no
> Windows version of git for some reason, can someone elaborate?
Git runs on Cygwin. But there's no native Win32 (without Cygwin)
version of Git because:
- Git uses POSIX APIs and expects POSIX behavior from the OS its
running on. Without a compatability layer to make Windows act
like UNIX Git won't run. Cygwin happens to be a really good
compatability layer.
- Git requires a Bourne shell for many of its important tools,
such as 'git commit'. Windows lacks such a program, at least
out of the box, but its in Cygwin.
- Git relies on a helper program called 'merge' to perform three
way file merges. This tool may or may not be ported to native
Win32 (I don't know) but it is in Cygwin.
- Git requires some libraries for certain features, such as libexpat
or libcurl. I don't know if these are available for native Win32
but they are available on Cygwin.
- Windows isn't the primary target platform for many of the Git
contributors. Some consider the fact that it even runs there
at all a minor miracle, and that's only possible due to the hard
work the Cygwin folks have done.
- ... I'm sure there's other reasons ...
--
Shawn.
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.3.2
From: Junio C Hamano @ 2006-10-24 6:27 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.4.3.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.3.2.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.3.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.3.2.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.3.2-1.$arch.rpm (RPM)
This is primarily to fix two rather embarrasing breakage
discovered post 1.4.3.1 release.
- The pager change to default to LESS=FRS exposed problem with less
that switches to alternate screen, shows its output and then switches
back immediately from the alternate screen afterwards -- which means
the user would not have a chance to see _anything_.
- Older upload-pack protocol clients did not pass host= and recent
git-daemon change to support virtual hosting did not handle this
correctly (although it attempted to do so, the check was borked).
----------------------------------------------------------------
Changes since v1.4.3.1 are as follows:
Alexandre Julliard (1):
prune-packed: Fix uninitialized variable.
J. Bruce Fields (1):
Make prune also run prune-packed
Jakub Narebski (2):
gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
gitweb: Do not esc_html $basedir argument to git_print_tree_entry
Jim Meyering (2):
git-clone: honor --quiet
xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header.
Junio C Hamano (2):
pager: default to LESS=FRSX not LESS=FRS
daemon: do not die on older clients.
Karl Hasselstrøm (1):
git-vc: better installation instructions
Lars Hjemli (1):
Fix usagestring for git-branch
Petr Baudis (1):
gitweb: Fix setting $/ in parse_commit()
Rene Scharfe (1):
git-merge: show usage if run without arguments
Santi Béjar (1):
Documentation for the [remote] config
^ permalink raw reply
* Re: VCS comparison table
From: Linus Torvalds @ 2006-10-24 6:31 UTC (permalink / raw)
To: Lachlan Patrick; +Cc: bazaar-ng, git
In-Reply-To: <453DAC87.8050203@research.canon.com.au>
On Tue, 24 Oct 2006, Lachlan Patrick wrote:
>
> Can I ask the git folks what Sean meant in the above about a 'command'.
> Are you talking about shell scripts? Is 'git' the only program you need?
Historically, "git" was _only_ a wrapper program. When you did
git log
it just executed the real program called "git-log", which was often a
shell-script. That was just so that things could easily be extended, and
you could use shell-script for simple one-liner things, and native C for
more "core" stuff.
For example, "git log" used to be a one-line shell-script that just did
git-rev-list --pretty HEAD | LESS=-S ${PAGER:-less}
but it ended up being a lot more capable, and eventually just rewritten
as an internal command..
These days, most of the simple things like "git log" are all built into
the "git" program, although for anything not built in, it still acts as
just a wrapper, which allows not only random functionality to still be
written in shell (or sometimes perl), but also ends up being the simplest
possible plug-in mechanism: you can define your own commands by just
writing a shell-script thing, calling it "git-mycommand", installing it in
the proper place, and it ends up being accessible as "git mycommand".
That allows for easy prototyping in your language of choice.
> AFAIK, 'bzr' is the sole program in Bazaar, and everything is done with
> command line options to bzr. Is that true of git? To what extent is git
> tied to a [programmable] shell? I've heard someone say there's no
> Windows version of git for some reason, can someone elaborate?
Almost all of "core" git is pure C, which unlike something like python or
perl obviously tends to have a fair amount of system issues. That said,
much of it really is fairly portable, so doing the built-in git stuff
should _largely_ work even natively under Windows with some effort.
The problem ends up being that few enough people seem to develop under
Windows, and the cygwin port works better (because it handles a number of
the portability issues and also handles the scripts that are still shell).
Those two issues seem to mean that not a lot of effort has been put into
aiming for a native windows binary (or into moving away from shell
scripts).
Most of the shell scripts really are fairly simple. So if somebody
_really_ wanted to, it would probably not be hard to spend some effort to
either just write them as C and turn them into built-ins, or porting them
to some other scripting language.
Of course, most Windows users don't seem to really want a command line
interface at all. IDE integration would appear to be more interesting to
some people.
Linus
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-10-24 6:32 UTC (permalink / raw)
To: git
* The 'maint' branch has spawned 1.4.3.2 tonight.
* The 'master' branch has these since the last announcement. In
addition to all fixes in 1.4.3.2, a major change is that it
contains Nico's delta-base-offset series that has been cooking
in "next" for quite some time.
Alexandre Julliard (1):
prune-packed: Fix uninitialized variable.
Dmitry V. Levin (1):
git-clone: define die() and use it.
Eric Wong (1):
git-send-email: do not pass custom Date: header
J. Bruce Fields (1):
Make prune also run prune-packed
Jakub Narebski (4):
gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
gitweb: Do not esc_html $basedir argument to git_print_tree_entry
gitweb: Improve git_print_page_path
gitweb: Add '..' (up directory) to tree view if applicable
Jim Meyering (3):
Don't use $author_name undefined when $from contains no /\s</.
git-clone: honor --quiet
xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header.
Junio C Hamano (5):
pack-objects: document --delta-base-offset option
git-repack: repo.usedeltabaseoffset
pager: default to LESS=FRS
pager: default to LESS=FRSX not LESS=FRS
daemon: do not die on older clients.
Karl Hasselström (2):
git-vc: better installation instructions
ignore-errors requires cl
Lars Hjemli (2):
Fix typo in show-index.c
Fix usagestring for git-branch
Linus Torvalds (1):
git-apply: prepare for upcoming GNU diff -u format change.
Nicolas Pitre (10):
introduce delta objects with offset to base
teach git-unpack-objects about deltas with offset to base
teach git-index-pack about deltas with offset to base
make git-pack-objects able to create deltas with offset to base
make pack data reuse compatible with both delta types
let the GIT native protocol use offsets to delta base when possible
zap a debug remnant
allow delta data reuse even if base object is a preferred base
index-pack: compare only the first 20-bytes of the key.
add the capability for index-pack to read from a stream
Petr Baudis (1):
gitweb: Fix setting $/ in parse_commit()
Rene Scharfe (1):
git-merge: show usage if run without arguments
Santi Béjar (1):
Documentation for the [remote] config
Shawn Pearce (1):
Use column indexes in git-cvsserver where necessary.
* The 'next' branch, in addition, has these.
- Linus's packed-refs and related changes are supposed to
graduate to "master" when the dust settles from the
tonight's update. I think it is pretty much ready.
- git-blame --porcelain should be ready to get pushed out, but
it's not that urgent.
- Superseding git-annotate by git-blame could be merged
anytime.
- We have accumulated some gitweb changes in "next". Some
depend on the packed-refs and related work, and some other
depend on blame --porcelain.
- An early part of my git-pickaxe is in "next", but more
interesting bits are still cooking in "pu".
Alan Chandler (1):
Gitweb - provide site headers and footers
Andy Whitcroft (2):
cvsimport: move over to using git-for-each-ref to read refs.
git-for-each-ref: improve the documentation on scripting modes
Christian Couder (12):
Add [-s|--hash] option to Linus' show-ref.
Use Linus' show ref in "git-branch.sh".
Document git-show-ref [-s|--hash] option.
Fix show-ref usage for --dereference.
Add pack-refs and show-ref test cases.
When creating branch c/d check that branch c does not already exists.
Uncomment test case: git branch c/d should barf if branch c exists.
Fix a remove_empty_dir_recursive problem.
Clean up "git-branch.sh" and add remove recursive dir test cases.
Use git-update-ref to delete a tag instead of rm()ing the ref file.
Check that a tag exists using show-ref instead of looking for the ref file.
Do not create tag leading directories since git update-ref does it.
Dennis Stosberg (2):
lock_ref_sha1_basic does not remove empty directories on BSD
Remove bashism from t3210-pack-refs.sh
Jeff King (3):
wt-status: use simplified resolve_ref to find current branch
gitignore: git-pack-refs is a generated file.
gitignore: git-show-ref is a generated file.
Johannes Schindelin (2):
Fix git-update-index --again
show-branch: mark active branch with a '*' again
Jonas Fonseca (1):
Add man page for git-show-ref
Junio C Hamano (55):
upload-pack: stop the other side when they have more roots than we do.
Add git-for-each-ref: helper for language bindings
Fix t1400-update-ref test minimally
fsck-objects: adjust to resolve_ref() clean-up.
symbolit-ref: fix resolve_ref conversion.
Add callback data to for_each_ref() family.
Tell between packed, unpacked and symbolic refs.
pack-refs: do not pack symbolic refs.
git-pack-refs --prune
pack-refs: fix git_path() usage.
lock_ref_sha1_basic: remove unused parameter "plen".
Clean-up lock-ref implementation
update-ref: -d flag and ref creation safety.
update a few Porcelain-ish for ref lock safety.
Teach receive-pack about ref-log
receive-pack: call setup_ident before git_config
ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
refs: minor restructuring of cached refs data.
lock_ref_sha1(): do not sometimes error() and sometimes die().
lock_ref_sha1(): check D/F conflict with packed ref when creating.
delete_ref(): delete packed ref
git-branch: remove D/F check done by hand.
show-ref --hash=len, --abbrev=len, and --abbrev
git-fetch: adjust to packed-refs.
Fix refs.c;:repack_without_ref() clean-up path
gitweb: make leftmost column of blame less cluttered.
git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
pack-refs: use lockfile as everybody else does.
gitweb: prepare for repositories with packed refs.
Revert 954a6183756a073723a7c9fd8d2feb13132876b0
pack-refs: call fflush before fsync.
blame.c: whitespace and formatting clean-up.
git-blame: --show-number (and -n)
git-blame: --show-name (and -f)
blame.c: move code to output metainfo into a separate function.
ref-log: allow ref@{count} syntax.
git-blame --porcelain
gitweb: use blame --porcelain
core.logallrefupdates create new log file only for branch heads.
git-pack-refs --all
core.logallrefupdates thinko-fix
blame: Document and add help text for -f, -n, and -p
gitweb: spell "blame --porcelain" with -p
pack-objects: use of version 3 delta is now optional.
gitweb: use for-each-ref to show the latest activity across branches
Revert "pack-objects: use of version 3 delta is now optional."
ref-log: fix D/F conflict coming from deleted refs.
git-pickaxe: blame rewritten.
git-pickaxe -M: blame line movements within a file.
git-pickaxe -C: blame cut-and-pasted lines.
git-pickaxe: pagenate output by default.
git-pickaxe: fix nth_line()
git-pickaxe: improve "best match" heuristics
git-pickaxe: introduce heuristics to avoid "trivial" chunks
sha1_name.c: avoid compilation warnings.
Linus Torvalds (6):
Add "git show-ref" builtin command
Teach "git checkout" to use git-show-ref
Start handling references internally as a sorted in-memory list
Add support for negative refs
Make ref resolution saner
Enable the packed refs file format
Luben Tuikov (4):
gitweb: blame: print commit-8 on the leading row of a commit-block
gitweb: blame: Mouse-over commit-8 shows author and date
gitweb: blame porcelain: lineno and orig lineno swapped
git-revert with conflicts to behave as git-merge with conflicts
Petr Baudis (6):
Fix broken sha1 locking
Fix buggy ref recording
gitweb: Restore object-named links in item lists
gitweb: Make search type a popup menu
gitweb: Do not automatically append " git" to custom site name
gitweb: Show project's README.html if available
Rene Scharfe (1):
Built-in cherry
Ryan Anderson (1):
Remove git-annotate.perl and create a builtin-alias for git-blame
* The 'pu' branch, in addition, has these.
Junio C Hamano (11):
git-pickaxe: do not keep commit buffer.
git-pickaxe: do not confuse two origins that are the same.
git-pickaxe: get rid of wasteful find_origin().
git-pickaxe: swap comparison loop used for -C
merge: loosen overcautious "working file will be lost" check.
rev-list --left-right
para-walk: walk n trees, index and working tree in parallel
merge-recursive: use abbreviated commit object name.
merge-recursive: make a few functions static.
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
t3200: git-branch testsuite update
Lars Hjemli (1):
Make git-branch a builtin
Petr Baudis (1):
gitweb: Support for 'forks'
^ permalink raw reply
* Re: [PATCH] Make git-branch a builtin
From: Junio C Hamano @ 2006-10-24 6:43 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061024054408.GA9724@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
>> > Wouldn't it make more sense to just include the full SHA1 of the
>> > file we are deleting rather than the entire 131 line negative diff?
>>
>> How would you do "git apply -R" on something like that?
>
> Uh, you have the full SHA1 in the index line. So you just have to
> reattach that blob to the named path... pretty simple actually.
Bzzzt; wrong answer.
Think of a future when you can shallowly clone near the tip of
git repository that does not have shell-script git-branch.sh
anymore. You cannot expect to already have the preimage of the
patch in such a case. You would still want to be able to revert
the change with "git apply -R".
^ permalink raw reply
* Re: VCS comparison table
From: David Rientjes @ 2006-10-24 6:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Lachlan Patrick, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610232318200.3962@g5.osdl.org>
On Mon, 23 Oct 2006, Linus Torvalds wrote:
> Historically, "git" was _only_ a wrapper program. When you did
>
> git log
>
> it just executed the real program called "git-log", which was often a
> shell-script. That was just so that things could easily be extended, and
> you could use shell-script for simple one-liner things, and native C for
> more "core" stuff.
>
> For example, "git log" used to be a one-line shell-script that just did
>
> git-rev-list --pretty HEAD | LESS=-S ${PAGER:-less}
>
> but it ended up being a lot more capable, and eventually just rewritten
> as an internal command..
>
Some of the internal commands that have been coded in C are actually much
better handled by the shell in the first place. It's much simpler to
write and extend as well as being much more traceable for runtime
problems. The shell commands that would be used for most of these git
routines have options for requesting it to be more verbose so the user
actually has a lot more power over reporting and/or logging. In addition
it tends to be more portable and the amount of code is drastically reduced
in a script style of programming. The criticisms against such use of
shell scripting tends to be a matter of personal taste. People believe,
for some reason or another, that it is a lower-class type of programming
that is less robust and is harder to understand. Seldom have there been
cogent arguments for coding such features in C as opposed to shell
scripting, especially in the case of git where the shell becomes a very
powerful ally.
David
^ permalink raw reply
* Re: [PATCH] git-send-email: do not pass custom Date: header
From: Junio C Hamano @ 2006-10-24 6:46 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061023093824.GB8749@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Eric Wong wrote:
>>
>> > We already generate a Date: header based on when the patch was
>> > emailed. ?git-format-patch includes the Date: header of the
>> > patch. ?Having two Date: headers is just confusing, so we
>> > just use the current Date:
>> >
>> > Often the mailed patches in a patch series are created over a
>> > series of several hours or days, so the Date: header from the
>> > original commit is incorrect for email, and often far off enough
>> > for spam filters to complain.
>>
>> But that makes us lose original commit date. And git format-patch
>> is if I remember correctly together with git-am used in git-rebase.
>
> This patch is for git-send-email, and only affects the way they
> are sent over SMTP. Output of git-format-patch is unchanged.
An alternative to satisfy both (Jakub wants original author date
propagated to the recipient of the e-mail who will run "git-am"
to apply the patch; you do not want to throw potentially ancient
author date as the e-mail's Date: to SMTP layer) is to use
sending date in e-mail header (like your patch does) _and_ leave
the Date: header for the original author date as the first line
of the e-mail message, separated with the real body of the message
with a blank line.
^ permalink raw reply
* Re: [PATCH] Fix bad usage of mkpath in builtin-branch.sh
From: Junio C Hamano @ 2006-10-24 6:46 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <1161655176461-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> When checking if a branch start point referred to a commit-object,
> the result of mkpath() was used as argument to get_sha1(), which
> didn't work out as planned.
>
> Now it's xstrdup'd first.
>
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> ---
> builtin-branch.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-branch.c b/builtin-branch.c
> index ffc2db0..f86bf68 100755
I've already fixed up this perm-mode breakage (and other
breakages, possibly) so when I am done with these patches
tonight please resync with me.
^ permalink raw reply
* Re: [PATCH] Make git-branch a builtin
From: Shawn Pearce @ 2006-10-24 6:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7r6qkmg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> >> > Wouldn't it make more sense to just include the full SHA1 of the
> >> > file we are deleting rather than the entire 131 line negative diff?
> >>
> >> How would you do "git apply -R" on something like that?
> >
> > Uh, you have the full SHA1 in the index line. So you just have to
> > reattach that blob to the named path... pretty simple actually.
>
> Bzzzt; wrong answer.
>
> Think of a future when you can shallowly clone near the tip of
> git repository that does not have shell-script git-branch.sh
> anymore. You cannot expect to already have the preimage of the
> patch in such a case. You would still want to be able to revert
> the change with "git apply -R".
Yet another valid argument for having the data needed for the
preimage available.
I've already agreed with Petr that having the data there is probably
better than not. Now I'm also agreeing with you. There is little
need to beat a dead horse. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] gitweb: Make search type a popup menu
From: Jakub Narebski @ 2006-10-24 7:33 UTC (permalink / raw)
To: git
In-Reply-To: <20061024031546.2877.51620.stgit@rover>
Petr Baudis wrote:
> This makes the multiple search types actually usable by the user;
> if you don't read the gitweb source, you don't even have an idea
> that you can write things like that there.
This is I think good change, although I'm not sure if I like changing
using search operators to using additional CGI parameter.
Having help page for search is _certainly_ very good change. Perhaps
we should put it out-of-line, not embedded? Just a thought...
This patch changes search box into something similar to Google
"Advanced Search". Yet Google "Advanced Search" box generates search
query using search operators. Search operators are just more powerfull.
I know that gitweb doesn't use this power now (it uses only one operator,
first if I remember correctly), but we can do this in the future
(e.g. searching for both author and specified string in commit message,
or searching for given author OR given committer). Well, we can always
change it back...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: updating only changed files source directory?
From: Jakub Narebski @ 2006-10-24 7:48 UTC (permalink / raw)
To: git
In-Reply-To: <ehjqgf$ggb$1@sea.gmane.org>
Han-Wen Nienhuys wrote:
> I have some questions and remarks
I see that you are using fairly low level commands (plumbing commands)
> git-http-fetch -a <branch> <url>
> wget <url>/refs/head/<branch> ## dump to <myrepo>/refs/head/<branch>
instead of setting $GIT_DIR/remotes/origin file and using "git fetch".
BTW. "git fetch" will not update branch you are on, unless --update-head-ok
option is used.
> git --git-dir <myrepo> read-tree <committish>
>
> cd <srcdir>
> git --git-dir <myrepo> checkout-index -a -f
instead of
git --git-dir=<myrepo> checkout <branch>
(-f is Force a re-read of everything)
> * As far as I can see, there is no reason to have only one index in a
> git repository. Why isn't it possible to specify an alternate
> index-file with an option similar to --git-dir ?
--git-dir is alternative to setting GIT_DIR. You can use GIT_INDEX_FILE
to specify alternate index file. Documented in git(7), section
"ENVIRONMENT VARIABLES".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-24 7:52 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Jakub Narebski, bazaar-ng, git
In-Reply-To: <46a038f90610231739x5beffc90u33c6a81f461974ec@mail.gmail.com>
On 10/24/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 10/24/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > On Tue, 24 Oct 2006, Erik Bågfors wrote:
> > >
> > > I don't see any problem doing a "gitk --all" equivalent in bzr.
> >
> > The problem? How do you show a commit that is _common_ to two branches,
> > but has different revision names in them?
>
> Eric,
It's Erik :)
> coming from an Arch background, I understand the whole per-branch
> commitids approach. After using GIT for a while, you start realising
> that it tries to pin down things in the wrong place.
>
> This is specially visible if you run `gitk --all` before and after a
> merge. Or on a project with many merges (if you can, get a checkout of
> git itself, and browse its history with gitk).
>
> Before the merge, you see
>
> --o--o--o--o
> \
> \--o--o
>
> and after
>
> --o--o--o--o
> \ \
> \--o--o--o
>
> Now, after it's merged somewhere, both commits are part of its
> history, regardless of where they come from. And it is very clear if
> two branches have been merging and remerging.
>
> Where a commit originated does not matter. And fancy
> repo-and-branch-centric names get in the way. A lot. And they re
> mostly meaningless as soon as you put what matters in the commit
> message. Which means that that bit of metadata that you are hoping
> that the revno keeps "indirectly" isn't lost on cherry picking.
Let's make one thing clear. Revnos are NOT stored with the revision,
they are not "names" of the revision. They are basically just
shortcuts to specific revisions, that only makes sence in the context
of a branch.
As human beings this is something we are very used to in everyday
life. I don't always call my friends with firstname and surname, I
just use first name or even "mate". As long as it's clear who I'm
talking about in that contect. If there are multiple people with the
same first name, then we might have to use the surname as well.
Same with bzr. In the context of a branch, revnos works as shortcuts
to the revision id. In the context of multiple branches, they don't.
I think they do serve a good purpose but I don't really think that we
absolutely need them either.
> I guess that's where I used to find revnos useful as they contained
> some basic metadata. With bzr it seems to be author-repo-branch where
> branch is hopefully "line of work" but all of that can be (and should
> be) in the commit message.
>
> You can see similar info in the first part of the commit message for
> most git-hosted projects. It'll say something like
>
> cvsserver: fix the frobnicator to be sequential
>
> which means that at that point, you could be working in a branch
> called fix-this-fscking-thing-attempt524" and no-one would know ;-)
>
> And in a few years (even months) time, that bit of metadata you were
> hoping to keep is totally irrelevant. What you have in the commit
> message remains relevant and useful.
I'm not even going to try to understand the argument here as they are
about a totally different thing and doesn't make any sense to me.
I think this disussion is getting out of hand.
There are a few things that are being discussed
1. Revnos are bad/good
2. treating "leftmost" parrent special is bad/good
3. plugins are useless/useful
4. And now, storing branch information should be done manually (if
wanted) and not automatically.
1. I don't really care, I haven't seen any confusion based on it, but
I don't have a very strong opinion about it either.
2. This is something I do care about. For me, this is the only
logical way of doing it. It might be because I am used to it now, but
when I started to look at bzr/hg/git/darcs/etc, I just got a so much
more clear view of the history when running a standard log command,
that it was one of the first things that attracted me to bzr. This is
just a user talking.
There might be technical reasons why it's better to not do it, but for
me it works the way I expect, therefore I'm happy
3. This is just silly
4. No comment.
/Erik
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-24 7:31 UTC (permalink / raw)
To: Carl Worth
Cc: Linus Torvalds, bazaar-ng, git, Matthew D. Fuller, Jakub Narebski
In-Reply-To: <87y7r6zgic.wl%cworth@cworth.org>
On 10/24/06, Carl Worth <cworth@cworth.org> wrote:
> On Mon, 23 Oct 2006 19:26:57 -0500, "Matthew D. Fuller" wrote:
> >
> > On Mon, Oct 23, 2006 at 04:24:30PM -0700 I heard the voice of
> > Linus Torvalds, and lo! it spake thus:
> > >
> > > The problem? How do you show a commit that is _common_ to two
> > > branches, but has different revision names in them?
> >
> > Why would you?
>
> Assume you've got two long-lived branches and one periodically gets
> merged into the other one. The combined history might look as follows
> (more recent commits first):
>
> f g
> | |
> d e
> |\ /
> b c
> |/
> a
>
> The point is that it is extremely nice to be able to visualize things
> that way. Say I've got a "dev" branch that points at f and a "stable"
> branch that points at g. With this, a command like:
>
> gitk dev stable
>
> would result in a picture just like the above. Can a similar figure be
> made with bzr? Or only the following two separate pictures:
The above picture can easily be created with bzr if you have a
utility/plugin that does it. There is none that does it yet, but there
are no problems doing one.
Of course, in such a context revision numbers have no use. But see,
revision numbers is not mandatory in bzr, so that's not a problem.
I haven't really had a need for such a tool, but I do see where it can
be very useful to have.
> f g
> | |
> d e
> |\ |
> b c c
> |/ |
> a a
>
This is what you would get if you visualize the two separate branches,
and not the common repository.
/Erik
^ permalink raw reply
* Re: renames in StGIT
From: Karl Hasselström @ 2006-10-24 8:17 UTC (permalink / raw)
To: Sean; +Cc: Catalin Marinas, git
In-Reply-To: <20061023125344.f82426ad.seanlkml@sympatico.ca>
On 2006-10-23 12:53:44 -0400, Sean wrote:
> On Mon, 23 Oct 2006 17:47:06 +0100
> "Catalin Marinas" <catalin.marinas@gmail.com> wrote:
>
> > On 22/10/06, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > Should this perhaps be an item in the TODO list?
> >
> > Only if it doesn't drastically affect the performance.
>
> There are some situation where it would be really quite handy. The
> performance of the human having to hand resolve a failed push
> because of renames is often worse ;o) If it does become a
> performance problem, perhaps you could make it an optional parameter
> to "stg push".
Yes, this is my opinion too, both for patch generation and pushing.
Having it always on is a bad idea at least for patch generation for
obvious reasons, and may be a bad idea for pushing for performance
reasons, but I definitely think there should be a flag to enable it.
There are situations when you know your upstream can read git patches,
and being able to retry a failed push with rename detection instead of
having to resolve the conflict manually could save lots of time, as
Sean said. Besides, Linus is always bragging about how fast git
merging is, and we all trust Linus, right? :-)
An optional flag is already available for the very handy "check if
patch was merged upstream" feature, and it's definitely the right
thing to do there. (Though I end up always using that flag even when I
know my patches aren't in upstream, since the extra cost is barely
noticeable.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-24 8:37 UTC (permalink / raw)
To: Erik Bågfors; +Cc: Martin Langhoff, Linus Torvalds, bazaar-ng, git
In-Reply-To: <845b6e870610240052l70ad72f4ma30065f151828dfd@mail.gmail.com>
Erik Bågfors wrote:
> I think this disussion is getting out of hand.
>
> There are a few things that are being discussed
> 1. Revnos are bad/good
> 2. treating "leftmost" parrent special is bad/good
> 3. plugins are useless/useful
> 4. And now, storing branch information should be done manually (if
> wanted) and not automatically.
>
> 1. I don't really care, I haven't seen any confusion based on it, but
> I don't have a very strong opinion about it either.
To use revnos[*1*] you have to have branch as path through DAG. Bzr does
that by treating first parent special, which leads to empty merges
in fast-forward case.
Using revnos as implemented in bzr leads to some (perhaps unforeseen)
consequences.
[*1*] Meaning that revnos won't change on you.
> 2. This is something I do care about. For me, this is the only
> logical way of doing it. It might be because I am used to it now, but
> when I started to look at bzr/hg/git/darcs/etc, I just got a so much
> more clear view of the history when running a standard log command,
> that it was one of the first things that attracted me to bzr. This is
> just a user talking.
Git has reflog for when you are interested in branch tip history
(which also stores "reason" for branch tip change: pull, amending
a commit, rebase,...). Git doesn't unfortunately have git-ref-log
command (or --ref option to git-log) to display reflog in user friendly
format.
Git users are used to use graphical history viewers (mainly gitk and
qgit, but there is also gitview, tig and git-browser) more to have
clear view of history, view that log cannot provide.
That said I _thing_ that caring about "branch identity" is just
something you are used to, perhaps because bzr doesn't have wonderfull
git log limiting specifiers aka. builtin git log searching (a..b,
a...b, --max-count, -- <path>, --committer, --grep etc.).
> There might be technical reasons why it's better to not do it, but for
> me it works the way I expect, therefore I'm happy
I think it would be better to maintain "branch identity" separately and
not in DAG, but that might have other problems I have not seen.
> 3. This is just silly
I think the discussion/arguments were twofold.
First, Bazaar-NG has plugin infrastructure "for free" because it is
written in Python, which allows modules loading and monkey-patching.
Git core is written in C, and git is not yet fully libified.
Second, all that can be done with plugins except for core changes can be
done in Git writing scripts (this also allows for fast prototyping).
All except core changes can be done writing few lines in C, but you
have to compile against some version of Git, and don't have advantages
of bultin command; git is OSS project.
> 4. No comment.
Storing branch information could be done automatically on demand ;-)
--
Jakub Narebski
Poland
^ 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