* Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view
From: Petr Baudis @ 2006-10-24 17:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu01thbvb.fsf@assigned-by-dhcp.cox.net>
On Tue, Oct 24, 2006 at 07:17:28PM CEST, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> >> > Would it even be necessary to use any SHA-1 name in these cases,
> >> > I wonder. Would it make the page less useful if we replace all
> >> > of the above _commit_ with a fixed string, say, "parent"?
> >
> > I really disagree here - what's the point of not using SHA-1? The extra
> > string carries zero information in comparison with the previous state
> > and I just can't see how it *improves* stuff. If you're walking in a
> > maze and making marks on walls, it's still more useful if you have
> > corridors named by "A", "B", "C", "D" on junctions if you sometimes want
> > to walk back to the marked corridors.
>
> I think people would recognize A B C D as names but not 40- or
> 8- hexadecimal letters.
40-digit hex numbers is insane, I agree. But at least I personally tend
to recognize 8-digit hex numbers when dancing around them intensively
for a few minutes. Besides, it can be just "now I took the 8c5 way",
which is much easier to train your neurons too than "now I took the
fourth, uh, or was it the fifth parent? one, two, three, four, fifth...
hmm, what's in the statusbar?".
My point is that this does not improve the situation, and some people
(me) think it makes it worse, so what's the point of the change?
> I do not care much either way, actually, but I think it might
> make more sense to use abbreviated object names. On the other
> hand it may be Ok to have full 40 letters depending on the
> layout (e.g. the set of merge parents are shown on a single line
> in which case it would not fit, etc.).
Yes, I'm all for abbreviated names, but I'm against just writing
"parent" everywhere.
--
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 17:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vzmblhc3y.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> Well, I would send haves for the alternate repository anyway,...
>
> While I agree it would be an optimization if it worked, there is
> one conceptual problem here though, coming from old warts. It's
> not alternate "repository" but it is alternate object store.
> There is no guarantee that refs/ directory that is next to the
> objects/ alternate points at is related to that object store,
> for historical reasons (i.e. we have separate GIT_DIR and
> GIT_OBJECT_DIRECTORIES).
Having said that, I am not opposed to the idea of using refs/
next to objects/ your alternate points at. Certainly I would
not have any objection (heck I would even volunteer to code it
myself if only to see how much we can save) if we did not have
GIT_OBJECT_DIRECTORY in the system (i.e. if we had a guarantee
from the beginning that objects/ directory that is next to refs/
*must* be related). So I am Ok with this change, but I would
feel better if we add a few sentences to repository-layout.txt
that warns about the (technically new although it is very likely
that violating it would not have been useful at all) restriction.
I suspect we could do the same for fetching in principle,
e.g. when you track Linus's and a subsystem maintainer's trees
and these two repositories are linked with alternates at your
end. Fetching into your copy of Linus's and then fetching into
your copy of subsystem would be optimized the same way if you
send refs/ from the alternates as HAVEs, right?
^ permalink raw reply
* Re: [ANNOUNCE] repo.or.cz now supports "project forks"
From: Petr Baudis @ 2006-10-24 17:39 UTC (permalink / raw)
To: git
In-Reply-To: <20061024045201.GX20017@pasky.or.cz>
Dear diary, on Tue, Oct 24, 2006 at 06:52:01AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> 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...
BTW, someone asked me why not stuff it in branches in the same
directory, and it's a valid question. It's been my original plan (and I
might still implement it sometimes since it makes sense in some
situations) but after I formulated it at #git I realized that it's
really a no-go for the general case.
The plan was to have "personal mob-branches", mob/$login/*. Anyone can
make any branch in the mob/$login namespace in any project. But I didn't
feel like implementing it for now, because:
* git-clone / cg-clone -a would clone even the potential gazillion
of mob/$login branches any weirdo can create
* You get own heads namespace but own tags namespace would be
I think more inconvenient since you tend to refere to tags
much more often than to branches (if you even have one than
one branch) and having to write mob/mynameisverylong/xyzzy-1.2.3.4
is, er...
* One of the big points of forks is that you can fork even
mirrored projects. If you start to create branches in mirrored
projects, you can get into very ugly problems when by a chance
the mirrored project gets such a branch as well
One sad consequence is that graphiclog does not include the forked
projects, OTOH perhaps its view would be way too cluttered if it did,
and I want to optimize for a large number of forks. So it would be more
sensible if someone (hint, hint) patched git-browser in a way so that
forked projects include the "forkee"'s refs in the view as well, in
addition to own refs. And perhaps a more general notion for this in the
Git world would be interesting.
--
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: VCS comparison table
From: David Lang @ 2006-10-24 18:03 UTC (permalink / raw)
To: Matthew D. Fuller; +Cc: Linus Torvalds, bazaar-ng, git
In-Reply-To: <20061024163458.GH17019@over-yonder.net>
On Tue, 24 Oct 2006, Matthew D. Fuller wrote:
> On Tue, Oct 24, 2006 at 08:58:56AM -0700 I heard the voice of
> David Lang, and lo! it spake thus:
>>
>> one key difference is that with bzr you have to do this chopping by
>> creating the branches at the time changes are done,
>
> HUH? Why on earth do you think that?
>
> To do this in a git data model, you point at 2 (or 3, or 4, or...)
> revisions, anywhere in the revision-space universe. You derive back a
> DAG of the history from each of them by recursing over parent links.
> You figure out where (if anywhere) those DAG's intersect. And based
> on that, you alter what and how you display; including or excluding
> certain revs, changing the angles of lines or columnation of dots in a
> graph, etc.
>
> To do it in a bzr data model, you would follow *EXACTLY* the same
> steps. As in, you do EXACTLY (a), then EXACTLY (b), then...
it sounded like you were saying that the way to get the slices of the DAG was to
use branches in bzr. to do this you need to create the branches with the correct
info on each branch. this is only practical if the branches are created as the
changes are made, if you try to do this after the fact you need to create the
changes in the branch before you do the slicing.
with git you can look at the DAG and pick any arbatrary points in it as points
to use for the slicing at display time.
>> what people are saying is that it doesn't easily support a truely
>> distributed workflow. this is a very different statement.
>
> And it's one that carries around a lot of unstated assumptions about
> what "truely distributed" means, which *I*'m certainly not
> understanding, because any meaning I can apply to the term doesn't
> lead me to the conclusions it does you. Certainly, depending on your
> workflow, certain parts of the UI are of lesser utility than they are
> in mine, down to and including zero. And it's probably certain that
> some parts of the UI aren't up to handling various workflows, too,
> including OUR workflow. That's kinda what "in development" means...
>
> But that's a very different statement from the claim that they CAN'T
> be without changes to the conceptual model underneath. Just because a
> UI is built around maintaining the fiction of a mainline doesn't mean
> the system requires it. All you'd have to do to abandon it is write a
> different log formatter that didn't show revnos and didn't nest merge
> commits, and change (or add an option to) 'merge' to fast-forward if
> possible. The difference between the views on how the pieces should
> fit together really IS just that fine.
the claim isn't that bzr can't be modified to support these other workflows (it
sounds as if just changing to tools to use the internal refid's rather then the
current refno's would come very close to solving this problem), it's that the
current refno's (use of which is strongly encouraged by the current UI) cannot
support some workflows, and therefor the claim that it supports fully
distributed workflows as well as git is false
remember that this entire thing started with a feature comparison checklist,
the definitions of some of the items on the checklist is being questioned.
after that there's the issue of if the VCS in question has the feature.
this discussion started with two topologies
1. Centralized: all commits must go to one repository, connectivity required to check-in
2. Distributed: everything else
since then one additional topology has been defined, and one has been redefined
1. Centralized: all commits must go to one repository, connectivity required to check-in
2. Star: one repository is 'special' or 'primary' and all other repositories
sync to this, but development can take place against local repositories,
connectivity is only requred when syncing the repositories. as updates take
place the history is defined by the primary repository, and can overwrite or
change the history as defined by local repositories.
3. Distributed: all repositories are equal (any definition of 'primary' is a
matter of convention, not a requirement of the tool) development can take place
against local repositories, connectivity is only required when syncing the
repositories. repositories with no development takeing place can sync back and
forth with no side effects. History displays the same thing no matter what
repository is looked at (allowing for the fact that some repositories may not
have the full history)
everyone agrees that bzr supports the Star topology. Most people (including bzr
people) seem to agree that currently bzr does not support the Distributed
topology.
it's just fine for bzr to not support all possible topologies, the only reason
for discussing these issues (besides everyone understanding each other) is the
feature checklist that started this entire thread, and what is appropriate there
for each VCS (see the early part of this discussion to see how that worked with
git's rename support)
David Lang
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-24 18:25 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <Pine.LNX.4.63.0610241038060.10841@qynat.qvtvafvgr.pbz>
David Lang wrote:
> 1. Centralized: all commits must go to one repository, connectivity
> required to check-in
Bazaar-NG "light checkouts" implements this. Git doesn't support this
topology, and probably wouldn't.
1.5. Disconnected centralized. Like centralized, but you can work (perhaps
limited to what you can do) even without connection to central server.
Minimally you have to be able to commit changes locally, if central server
is not available. Bzr "normal/heavyweight checkouts" are [roughly] abot
this. Git "lazy clone" proposal is about similar thing; you can get git to
support this model (although without space savings) with full
clone + hooks.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view
From: Junio C Hamano @ 2006-10-24 18:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061024172627.GU18879@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Tue, Oct 24, 2006 at 07:17:28PM CEST, Junio C Hamano wrote:
>> Petr Baudis <pasky@suse.cz> writes:
>>
>> >> > Would it even be necessary to use any SHA-1 name in these cases,
>> >> > I wonder. Would it make the page less useful if we replace all
>> >> > of the above _commit_ with a fixed string, say, "parent"?
>> >
>> > I really disagree here - what's the point of not using SHA-1? The extra
>> > string carries zero information in comparison with the previous state
>> > and I just can't see how it *improves* stuff. If you're walking in a
>> > maze and making marks on walls, it's still more useful if you have
>> > corridors named by "A", "B", "C", "D" on junctions if you sometimes want
>> > to walk back to the marked corridors.
>>
>> I think people would recognize A B C D as names but not 40- or
>> 8- hexadecimal letters.
>
> 40-digit hex numbers is insane, I agree. But at least I personally tend
> to recognize 8-digit hex numbers when dancing around them intensively
> for a few minutes. Besides, it can be just "now I took the 8c5 way",
> which is much easier to train your neurons too than "now I took the
> fourth, uh, or was it the fifth parent? one, two, three, four, fifth...
> hmm, what's in the statusbar?".
>
> My point is that this does not improve the situation, and some people
> (me) think it makes it worse, so what's the point of the change?
>
>> I do not care much either way, actually, but I think it might
>> make more sense to use abbreviated object names. On the other
>> hand it may be Ok to have full 40 letters depending on the
>> layout (e.g. the set of merge parents are shown on a single line
>> in which case it would not fit, etc.).
>
> Yes, I'm all for abbreviated names, but I'm against just writing
> "parent" everywhere.
Fully agreed. Please make it so, if you so are inclined,
perhaps between you and Jakub?
^ permalink raw reply
* Re: [PATCH 2/1] gitweb: Use fixed string for "next" link in commitdiff view
From: Jakub Narebski @ 2006-10-24 18:37 UTC (permalink / raw)
To: git
In-Reply-To: <7viri9h8m4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>> Yes, I'm all for abbreviated names, but I'm against just writing
>> "parent" everywhere.
>
> Fully agreed. Please make it so, if you so are inclined,
> perhaps between you and Jakub?
I'm all for abbreviated names (that was my first solution, wasn't it).
This patch was because of Junio mail:
> Would it even be necessary to use any SHA-1 name in these cases,
> I wonder. Would it make the page less useful if we replace all
> of the above _commit_ with a fixed string, say, "parent"?
So please drop this patch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH qgit] Change also tag marks when changing graph size
From: Josef Weidendorfer @ 2006-10-24 18:41 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550610240947i30bc3fc0x49710e4cbb0f0556@mail.gmail.com>
On Tuesday 24 October 2006 18:47, Marco Costalba wrote:
> When changing graph size with CTRL+ and CTRL-
> update also tag/branch marks.
>
> Also little cleanup.
> ---
>
> Hi Josef,
>
> please tell me if you are working on the same files, in this case I
> will step back and wait you to finish your patch series and eventually
> resubmit this one at the end.
No, that is fine. Currently, I have not much time.
Just curious: What did you expect next in my patch series? :-)
Now that everything is drawn directly, the question is what to do with
the new flexibility. E.g. we _could_ implement different
graph drawing algorithms next to the original qgit one,
e.g. mimicking gitk.
However, the highlighting functionality in gitk is really good, and I can
imagine changing the background and color of lanes/commits according to
e.g. ancestor/descendent from/to the nearest tag/branch head.
^ permalink raw reply
* Re: [PATCH] gitweb: Show project's README.html if available
From: Luben Tuikov @ 2006-10-24 19:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20061024113057.GA20017@pasky.or.cz>
--- Petr Baudis <pasky@suse.cz> wrote:
> > Why not instead re-submit a patch implementing what was discussed
> > in this thread bearing the same name:
> >
> > http://marc.theaimsgroup.com/?t=116044914900001&r=1&w=2
>
> This implements
>
> http://marc.theaimsgroup.com/?l=git&m=116047939517299&w=2
>
> I see no other ideas I could take there except various naming proposals
> and perhaps using File::Copy but I'll wait until someone does a
> gitweb-wide change for the latter.
>
> I don't really care _what_ name it bears, but I'd like to have it
> included. :-)
People have suggested that this functionality be folded into the
"Description" column, where the description printed is the
first line of the description file "description" and if clicked
on, it shows the whole "descrption" file.
Luben
^ permalink raw reply
* Re: updating only changed files source directory?
From: Daniel Barkalow @ 2006-10-24 19:12 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <ehjqgf$ggb$1@sea.gmane.org>
On Tue, 24 Oct 2006, Han-Wen Nienhuys wrote:
>
> Hello there,
>
> I'm just starting out with GIT. Initially, I want to use experiment with
> integrating it into our binary builder structure for LilyPond.
>
> The binary builder roughly does this:
>
> 1. get source code updates from a server to a single, local
> repository. This is currently a git repository that is that
> tracks our CVS server.
>
> 2. copy latest commit from a branch to separate source directory.
> This copy should only update files that changed.
>
> 3. Incrementally compile from that source directory
The terminology in the git world is, I think, a little different from what
you expect. We call the thing that contains all of the tracked information
(what you're calling the repository) the "object database"; what we call
the "repository" is a bit different: it primarily keeps track of the heads
of branches, in addition to either containing an object database or
referencing an external one. So you need a repository for each source
directory (because it keeps track of what commit is currently in the
source directory), but it doesn't need to have its own complete object
database, which is what you're trying to share between all of them.
You have a single repository with no source directory that contains the
database and the heads according to the upstream source, and then each
source directory has a repository that contains the head as far as you've
built it in that directory. You fetch into the single bare repository
from upstream, and then pull into each source directory from the bare
repository; this will do the minimal update to the contents of the source
directory automatically.
I think that you want to request a few git features:
- support having a bare repository not on a branch, so that it can fetch
all heads from its upstream. You're not doing anything branch-specific
in the bare repository anyway, but git currently wants a valid HEAD to
accept a path as containing a git repository
- support getting an origin remote configuration with a bare repository
- support cloning a branch of a repository, such that the clone's
"origin" is the upstream's chosen branch, not its "master".
- support cloning without generating a "master" branch in the clone, and
instead starting on "origin"
Then you do:
git clone --bare --no-head --with-origin <upstream> REPOSITORY.git
for each branch:
git clone --shared --branch=<branch> --no-master REPOSITORY.git <branch>
When you want to update:
GIT_DIR=REPOSITORY.git git fetch
for each branch:
(cd <branch>; git pull; make)
Note that all of the features you need are in "clone" for setting things
up nicely automatically; if you arrange everything by hand just right, you
can already to the updating procedure I give.
-Daniel
^ permalink raw reply
* Re: [PATCH] gitweb: Show project's README.html if available
From: Petr Baudis @ 2006-10-24 19:19 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git
In-Reply-To: <524029.7339.qm@web31812.mail.mud.yahoo.com>
On Tue, Oct 24, 2006 at 09:09:03PM CEST, Luben Tuikov wrote:
> --- Petr Baudis <pasky@suse.cz> wrote:
> > > Why not instead re-submit a patch implementing what was discussed
> > > in this thread bearing the same name:
> > >
> > > http://marc.theaimsgroup.com/?t=116044914900001&r=1&w=2
> >
> > This implements
> >
> > http://marc.theaimsgroup.com/?l=git&m=116047939517299&w=2
> >
> > I see no other ideas I could take there except various naming proposals
> > and perhaps using File::Copy but I'll wait until someone does a
> > gitweb-wide change for the latter.
> >
> > I don't really care _what_ name it bears, but I'd like to have it
> > included. :-)
>
> People have suggested that this functionality be folded into the
> "Description" column, where the description printed is the
> first line of the description file "description" and if clicked
> on, it shows the whole "descrption" file.
Please look at the mail the mail I referred was a reply to:
http://marc.theaimsgroup.com/?l=git&m=116047773825208&w=2
--
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
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-24 19:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, bazaar-ng
In-Reply-To: <ehllqj$bee$1@sea.gmane.org>
Dear diary, on Tue, Oct 24, 2006 at 08:25:53PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> David Lang wrote:
>
> > 1. Centralized: all commits must go to one repository, connectivity
> > required to check-in
>
> Bazaar-NG "light checkouts" implements this. Git doesn't support this
> topology, and probably wouldn't.
>
> 1.5. Disconnected centralized. Like centralized, but you can work (perhaps
> limited to what you can do) even without connection to central server.
> Minimally you have to be able to commit changes locally, if central server
> is not available. Bzr "normal/heavyweight checkouts" are [roughly] abot
> this. Git "lazy clone" proposal is about similar thing; you can get git to
> support this model (although without space savings) with full
> clone + hooks.
Cogito can do it now out of the box, having support for cg-commit --push
and cg-update preserving uncommitted local changes.
Not that you probably should use it. ;-)
--
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
^ permalink raw reply
* Re: [PATCH] gitweb: Show project's README.html if available
From: Luben Tuikov @ 2006-10-24 19:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20061024191915.GV18879@pasky.or.cz>
--- Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Oct 24, 2006 at 09:09:03PM CEST, Luben Tuikov wrote:
> > --- Petr Baudis <pasky@suse.cz> wrote:
> > > > Why not instead re-submit a patch implementing what was discussed
> > > > in this thread bearing the same name:
> > > >
> > > > http://marc.theaimsgroup.com/?t=116044914900001&r=1&w=2
> > >
> > > This implements
> > >
> > > http://marc.theaimsgroup.com/?l=git&m=116047939517299&w=2
> > >
> > > I see no other ideas I could take there except various naming proposals
> > > and perhaps using File::Copy but I'll wait until someone does a
> > > gitweb-wide change for the latter.
> > >
> > > I don't really care _what_ name it bears, but I'd like to have it
> > > included. :-)
> >
> > People have suggested that this functionality be folded into the
> > "Description" column, where the description printed is the
> > first line of the description file "description" and if clicked
> > on, it shows the whole "descrption" file.
>
> Please look at the mail the mail I referred was a reply to:
>
> http://marc.theaimsgroup.com/?l=git&m=116047773825208&w=2
I re-read that email. And I also saw what you have at hed.git.
If anything I think we should want to _minimize_ shown material
before the "shortlog" in the "summary" page.
Why?
Well, in a production environment, people often view the "summary" page
to see what has been going on with a project and they are well aware
of what that project is for and/or what it does. It is cumbersome to have
to scroll down each and every time past he annoying "readme", just to see
the first few commits.
Look, your hed.cgi has 7 lines for the description and URL, (as opposed to 4
of next:gitweb.perl) and those already have generous amount of inner-spacing,
making the whole thing extend half the page. This would be annoying in
a production environment.
Now, if you use gitweb as a Web presentation tool of your projects then
this is another story. Then you would want to put colors, graphics, lots
of text here and there, etc, etc.
If we start to include those little things to be supported "optionally",
then we incur bloat to gitweb.
I think what is best to do is to create another script which can show
the fancy-schmancy Web presentation content you want to mix with
with gitweb, and keep gitweb a tool for the enigineer as opposed to
a web presentation application.
That other fancy-schmancy script can keep track of developers,
statistics, bugs, bug counts, etc, etc, as well.
Luben
^ permalink raw reply
* Re: [PATCH] gitweb: Show project's README.html if available
From: Petr Baudis @ 2006-10-24 19:50 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git
In-Reply-To: <701637.67420.qm@web31802.mail.mud.yahoo.com>
Dear diary, on Tue, Oct 24, 2006 at 09:41:04PM CEST, I got a letter
where Luben Tuikov <ltuikov@yahoo.com> said that...
> I re-read that email. And I also saw what you have at hed.git.
>
> If anything I think we should want to _minimize_ shown material
> before the "shortlog" in the "summary" page.
>
> Why?
>
> Well, in a production environment, people often view the "summary" page
> to see what has been going on with a project and they are well aware
> of what that project is for and/or what it does. It is cumbersome to have
> to scroll down each and every time past he annoying "readme", just to see
> the first few commits.
Yes, I agree that this is valid concern. I've been thinking about
showing readme in parallel with the summary box, do people think that
would fix the issue?
--
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
^ permalink raw reply
* [PATCH] Set $HOME for selftests
From: Gerrit Pape @ 2006-10-24 20:00 UTC (permalink / raw)
To: git
Set HOME environment variable to test trash directory and export for
selftests. This fixes the git-svn selftests with nonexistent or not
readable home, as found in at least one automated build system:
http://buildd.debian.org/fetch.cgi?&pkg=git-core&ver=1%3A1.4.2.3-2&arch=alpha&stamp=1161537466&file=log
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
t/test-lib.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 2488e6e..07cb706 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -207,7 +207,8 @@ # Test the binaries we have just built.
# t/ subdirectory and are run in trash subdirectory.
PATH=$(pwd)/..:$PATH
GIT_EXEC_PATH=$(pwd)/..
-export PATH GIT_EXEC_PATH
+HOME=$(pwd)/trash
+export PATH GIT_EXEC_PATH HOME
# Similarly use ../compat/subprocess.py if our python does not
# have subprocess.py on its own.
--
1.4.2.3
^ permalink raw reply related
* git-*arch* in git-arch rpm
From: Gerrit Pape @ 2006-10-24 20:02 UTC (permalink / raw)
To: git
Hi, there're two programs in the git-arch rpm that shouldn't be there:
$ rpm -qlp git-arch-1.4.3.2-1.i386.rpm
/usr/bin/git-archimport
/usr/bin/git-archive
/usr/bin/git-upload-archive
/usr/share/doc/git-arch-1.4.3.2
/usr/share/doc/git-arch-1.4.3.2/git-archimport.html
/usr/share/doc/git-arch-1.4.3.2/git-archimport.txt
/usr/share/doc/git-arch-1.4.3.2/git-archive.html
/usr/share/doc/git-arch-1.4.3.2/git-archive.txt
/usr/share/doc/git-arch-1.4.3.2/git-upload-archive.html
/usr/share/doc/git-arch-1.4.3.2/git-upload-archive.txt
/usr/share/man/man1/git-archimport.1.gz
/usr/share/man/man1/git-archive.1.gz
/usr/share/man/man1/git-upload-archive.1.gz
$
^ permalink raw reply
* git-fetch not working?
From: Andy Parkins @ 2006-10-24 20:00 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
Hello,
$ cat .git/remotes/origin
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: refs/heads/master:refs/heads/up/master
Pull: refs/heads/next:refs/heads/up/next
Pull: refs/heads/maint:refs/heads/up/maint
Pull: +refs/heads/pu:refs/heads/up/pu
$ git fetch
fatal: unexpected EOF
Failed to find remote refs
$ ping -c1 git.kernel.org
PING zeus-pub.kernel.org (204.152.191.5) 56(84) bytes of data.
64 bytes from zeus-pub1.kernel.org (204.152.191.5): icmp_seq=1 ttl=54 time=182
ms
Am I doing something wrong?
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: David Rientjes @ 2006-10-24 20:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64.0610240812410.3962@g5.osdl.org>
On Tue, 24 Oct 2006, Linus Torvalds wrote:
> Yes. However, from a portability (to Windows) standpoint, shell is just
> about the worst choice.
>
> Not that perl/python/etc really help - unless the _whole_ program is one
> perl/python thing. Windows just doesn't like pipelines etc very much.
>
> So I'd like all the _common_ programs to be built-ins..
>
And I would prefer the opposite because we're talking about git. As an
information manager, it should be seen and not heard. Nobody is going to
spend their time to become a git or CVS or perforce expert. As an
individual primarily interested in development, I should not be required
to learn command lines for dozens of different git-specific commands to do
my job quickly and effectively. I would opt for a much more simpler
approach and deal with shell scripting for many of these commands because
I'm familiar with them and I can pipe any command with the options I
already know and have used before to any other command.
As a developer on Linux based systems, I should not need to deal with
code in a revision control system that is longer and less traceable
because the authors of that system decided they wanted to support Windows
too. Moving away from the functionality that the shell provides is a
mistake for a system such as git where it could be so advantageous because
of the inherent nature of git as an information manager.
This is the reason why I was a fan of git long ago and used it for my own
needs before tons of unnecessary features and unneeded complexity was
added on.
David
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-24 20:28 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <Pine.LNX.4.64N.0610241300450.8112@attu4.cs.washington.edu>
David Rientjes wrote:
> This is the reason why I was a fan of git long ago and used it for my own
> needs before tons of unnecessary features and unneeded complexity was
> added on.
But you can still use git as you used it long time ago. The plumbing
commands didn't vanish. Git got rich in porcelanish commands, true, but old
core remains. And GIT_TRACE (quite new addition) certainly helps.
I think git profit very much from being created bottom-up, from main idea of
SCM, through repository format and structure, through plumbing commands,
through porcelain done with scripts, to having many new plumbing commands,
to having many commands builtin, in the future to libification perhaps.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Would be nice to have a "git-checkpoint" command
From: Geert Bosch @ 2006-10-24 20:36 UTC (permalink / raw)
To: git List
(Just an idea, no code yet.)
NAME
----
git-checkpoint - Save current state of the repository
SYNOPSIS
--------
'git-checkpoint' [--stdout] [-n]
DESCRIPTION
-----------
This command generates trees/blobs for all files
in the current git repository, including untracked files
and directories and the .git directory itself, only excluding
.git/objects.
With no options given, tree id is saved in .git/UNDO
OPTIONS
-------
--stdout::
Write tree id of repository state to standard output, and
do not write in .git/UNDO
-n|--no-create::
Don't actually create new objects. Implies --stdout
(Discussion)
This could be used for implementing git-undo and git-redo commands.
Note that an implicit chain of undo commands is kept, by restoring
successive .git/UNDO files. Of course git-undo should save a .git/REDO
file. Ideally both operations would keep a nice undo/redo stack.
The reason for not using commits is that this not meant for keeping
history, just reverting mistakes. In particular, a prune will blow
away all older UNDOs keeping just the last, which is fine. Doing a
checkpoint should always succeed and never require user interaction.
^ permalink raw reply
* Re: git-fetch not working?
From: Petr Baudis @ 2006-10-24 20:54 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, ftpadmin
In-Reply-To: <200610242100.52671.andyparkins@gmail.com>
Hi,
Dear diary, on Tue, Oct 24, 2006 at 10:00:45PM CEST, I got a letter
where Andy Parkins <andyparkins@gmail.com> said that...
> $ cat .git/remotes/origin
> URL: git://git.kernel.org/pub/scm/git/git.git
> Pull: refs/heads/master:refs/heads/up/master
> Pull: refs/heads/next:refs/heads/up/next
> Pull: refs/heads/maint:refs/heads/up/maint
> Pull: +refs/heads/pu:refs/heads/up/pu
>
> $ git fetch
> fatal: unexpected EOF
> Failed to find remote refs
>
> $ ping -c1 git.kernel.org
> PING zeus-pub.kernel.org (204.152.191.5) 56(84) bytes of data.
> 64 bytes from zeus-pub1.kernel.org (204.152.191.5): icmp_seq=1 ttl=54 time=182
> ms
>
> Am I doing something wrong?
nope, I'm getting it as well (hey I know about broken git.kernel.org
in an hour at most now because of the repo.or.cz cronjobs ;) -
git-daemon at the kernel.org machines seems to be broken.
--
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
^ permalink raw reply
* Re: git-fetch not working?
From: H. Peter Anvin @ 2006-10-24 21:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Andy Parkins, git, ftpadmin
In-Reply-To: <20061024205428.GI20017@pasky.or.cz>
Petr Baudis wrote:
> Hi,
>
> Dear diary, on Tue, Oct 24, 2006 at 10:00:45PM CEST, I got a letter
> where Andy Parkins <andyparkins@gmail.com> said that...
>> $ cat .git/remotes/origin
>> URL: git://git.kernel.org/pub/scm/git/git.git
>> Pull: refs/heads/master:refs/heads/up/master
>> Pull: refs/heads/next:refs/heads/up/next
>> Pull: refs/heads/maint:refs/heads/up/maint
>> Pull: +refs/heads/pu:refs/heads/up/pu
>>
>> $ git fetch
>> fatal: unexpected EOF
>> Failed to find remote refs
>>
>> $ ping -c1 git.kernel.org
>> PING zeus-pub.kernel.org (204.152.191.5) 56(84) bytes of data.
>> 64 bytes from zeus-pub1.kernel.org (204.152.191.5): icmp_seq=1 ttl=54 time=182
>> ms
>>
>> Am I doing something wrong?
>
> nope, I'm getting it as well (hey I know about broken git.kernel.org
> in an hour at most now because of the repo.or.cz cronjobs ;) -
> git-daemon at the kernel.org machines seems to be broken.
>
Nope, just tripping the load limit. git1.kernel.org has had loads over
400 today. Oddly enough, the load on git2.kernel.org is in the low teens.
-hpa
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-24 21:51 UTC (permalink / raw)
To: Carl Worth
Cc: Matthew D. Fuller, Linus Torvalds, bazaar-ng, git, Jakub Narebski
In-Reply-To: <87y7r6zgic.wl%cworth@cworth.org>
Sorry for going back to an old mail... but....
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:
I wanted to test how hard it is. So I created a small plugin that will
show the relationsships between revisions... The following commands
bzr init-repo repo --trees
bzr init repo/branchA
cd repo/branchA
bzr whoami --branch "Test Devel 1 <test1@devel.com>"
bzr ci --unchanged -m a1
bzr ci --unchanged -m a2
bzr branch . ../branchB
bzr ci --unchanged -m a3
bzr ci --unchanged -m a4
cd ../branchB
bzr whoami --branch "Test Devel 2 <test2@devel.com>"
bzr ci --unchanged -m b1
bzr ci --unchanged -m b2
bzr merge ../branchA
bzr ci -m merge
bzr ci --unchanged -m b3
bzr ci --unchanged -m b4
cd ../branchA
bzr merge ../branchB
bzr ci -m merge
bzr ci --unchanged -m a5
cd ../branchB
bzr ci --unchanged -m b5
cd ..
bzr dotrepo > test.dot
dot -Tpng test.dot > dotrepo.png
Creates the picture you can see at
http://erik.bagfors.nu/bzr-plugins/dotrepo.png
Please remember that this is a 15 min implementation and as such might
suck (the output is not perfect for example, it's slow, etc). This
just brings in every revision in the entire repo, but to expand it to
just take the branches on the command line, is perfectly possible.
But still.. there is no problem to create this.
/Erik
ps. the plugin can be bzr branched from
http://erik.bagfors.nu/bzr-plugins/dotrepo/
--
google talk/jabber. zindar@gmail.com
SIP-phones: sip:erik_bagfors@gizmoproject.com
^ permalink raw reply
* [PATCH] xdiff: Do not consider lines starting by # hunkworthy
From: Petr Baudis @ 2006-10-25 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This will be probably controversial but in my personal experience, the
amount of time this is the right thing to do because of #defines is negligible
compared to amount of time it is wrong, especially because of #ifs and #endifs
in the middle of functions and also because of comments at the line start when
it concerns non-C files.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
xdiff/xemit.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 714c563..4f20075 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -86,8 +86,7 @@ static void xdl_find_func(xdfile_t *xf,
if (len > 0 &&
(isalpha((unsigned char)*rec) || /* identifier? */
*rec == '_' || /* also identifier? */
- *rec == '(' || /* lisp defun? */
- *rec == '#')) { /* #define? */
+ *rec == '(')) { /* #define? */
if (len > sz)
len = sz;
^ permalink raw reply related
* Re: [RFC] git-split: Split the history of a git repository by subdirectories and ranges
From: Junio C Hamano @ 2006-10-25 0:10 UTC (permalink / raw)
To: git; +Cc: Josh Triplett
In-Reply-To: <453D17B5.6070203@freedesktop.org>
Josh Triplett <josh@freedesktop.org> writes:
> Linus Torvalds wrote:
>>
>> And yes, that's done by the core revision parsing code, so when you do
>>
>> git log --full-history --parents -- $project
>>
>> you do get the rewritten parent output (of course, it's not actually
>> _simplified_, so you get a fair amount of duplicate parents etc which
>> you'd still have to simplify and which don't do anything at all).
>>
>> Without the "--full-history", you get a simplified history, but it's
>> likely to be _too_ simplified for your use, since it will not only
>> collapse multiple identical parents, it will also totally _remove_ parents
>> that don't introduce any new content.
>
> Considering that git-split does exactly that (remove parents that don't
> introduce new content, assuming they changed things outside the
> subtree), that might actually work for us. I just checked, and the
> output of "git log --parents -- $project" on one of my repositories
> seems to show the same sequence of commits as git log --parents on the
> head commit printed by git-split $project (apart from the rewritten
> sha1s), including elimination of irrelevant merges.
So one potential action item that came out from this discussion
for me is to either modify --pretty=raw (or add --pretty=rawish)
that gives the rewritten parents instead of real parents? With
that, you can drop the code to simplify ancestry by hand in your
loop, and also you do not have to do the grafts inforamation
yourself either?
If that is the case I'd be very happy.
The only thing left for us to decide is if reporting the true
parenthood like the current --pretty=raw makes sense (if so we
need to keep it and introduce --pretty=rawfish).
The only in-tree user of --pretty=raw seems to be git-svn but it
only looks at path-unlimited log/rev-list from one given commit,
so the only difference between dumping what is recorded in the
commit object and listing what parents we _think_ the commit has
is what we read from grafts. I think we are safe to just "fix"
the behaviour of --pretty=raw
Comments?
^ 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