* Re: git-shortlog mailmap
From: Jakub Narebski @ 2006-10-26 13:13 UTC (permalink / raw)
To: git
In-Reply-To: <4540AD6E.6070201@op5.se>
Andreas Ericsson wrote:
> Jakub Narebski wrote:
>> Petr Baudis wrote:
>>>
>>> Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter
>>> where Jakub Narebski <jnareb@gmail.com> said that...
>>>>
>>>> BTW. both Perl version and builtin shorlog have email->real name translation
>>>> table built in. In Perl script version it is in __DATA__ section, and we
>>>> could update it using Inline::Files module, in C version it was in table.
>>>> But in fact this list is project specific. Shouldn't we make it customizable
>>>> (::sigh::, yet another file in $GIT_DIR...).
>>>>
>>> I really dislike the fact that we _do_ this mapping at all, this seems
>>> so much a totally wrong point at which to do it. The information tracked
>>> in Git is still wrong and all the tools except shortlog still display it
>>> wrong - why should shortlog in particular be special? Why don't we do
>>> this at the git-am time instead?
>>
>> Because git-shortlog has to deal also with _historical_ data, which caused
>> one way or the other to have only email and not realname recorded. So till
>> history gets rewritteen, and tags resigned, git-shortlog has to do the
>> mapping to have meaningfull output.
>
> Wouldn't this be better implemented in the rev-list code then, so all
> log viewers can benefit from it?
Because this belongs to porcelain. Plumbing shouldn't show something
that isn't there.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-shortlog mailmap
From: Andreas Ericsson @ 2006-10-26 12:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehqaco$r4l$1@sea.gmane.org>
Jakub Narebski wrote:
> Petr Baudis wrote:
>
>> I think I've complained about this in the past, but can't find the mail.
>>
>> Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter
>> where Jakub Narebski <jnareb@gmail.com> said that...
>>> Johannes Schindelin wrote:
>>>
>>>> BTW what happened to the builtin shortlog? It is the last Perl script I
>>>> use regularly... (should make people happy who are stuck with Activision
>>>> Perl...)
>>> BTW. both Perl version and builtin shorlog have email->real name translation
>>> table built in. In Perl script version it is in __DATA__ section, and we
>>> could update it using Inline::Files module, in C version it was in table.
>>> But in fact this list is project specific. Shouldn't we make it customizable
>>> (::sigh::, yet another file in $GIT_DIR...).
>> I really dislike the fact that we _do_ this mapping at all, this seems
>> so much a totally wrong point at which to do it. The information tracked
>> in Git is still wrong and all the tools except shortlog still display it
>> wrong - why should shortlog in particular be special? Why don't we do
>> this at the git-am time instead?
>
> Because git-shortlog has to deal also with _historical_ data, which caused
> one way or the other to have only email and not realname recorded. So till
> history gets rewritteen, and tags resigned, git-shortlog has to do the
> mapping to have meaningfull output.
Wouldn't this be better implemented in the rev-list code then, so all
log viewers can benefit from it?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: git-shortlog mailmap
From: Jakub Narebski @ 2006-10-26 12:41 UTC (permalink / raw)
To: git
In-Reply-To: <20061026123424.GQ20017@pasky.or.cz>
Petr Baudis wrote:
> I think I've complained about this in the past, but can't find the mail.
>
> Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Johannes Schindelin wrote:
>>
>> > BTW what happened to the builtin shortlog? It is the last Perl script I
>> > use regularly... (should make people happy who are stuck with Activision
>> > Perl...)
>>
>> BTW. both Perl version and builtin shorlog have email->real name translation
>> table built in. In Perl script version it is in __DATA__ section, and we
>> could update it using Inline::Files module, in C version it was in table.
>> But in fact this list is project specific. Shouldn't we make it customizable
>> (::sigh::, yet another file in $GIT_DIR...).
>
> I really dislike the fact that we _do_ this mapping at all, this seems
> so much a totally wrong point at which to do it. The information tracked
> in Git is still wrong and all the tools except shortlog still display it
> wrong - why should shortlog in particular be special? Why don't we do
> this at the git-am time instead?
Because git-shortlog has to deal also with _historical_ data, which caused
one way or the other to have only email and not realname recorded. So till
history gets rewritteen, and tags resigned, git-shortlog has to do the
mapping to have meaningfull output.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: Fix up bogus $stylesheet declarations
From: Petr Baudis @ 2006-10-26 12:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This seems to be a pre-++ residual declaration and it wasn't good for
anything at all besides flooding the webserver errorlog with "omg, our in
the same scope!!" warnings.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d737b2b..1d91f7f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -51,10 +51,6 @@ our $site_footer = "++GITWEB_SITE_FOOTER
# URI of stylesheets
our @stylesheets = ("++GITWEB_CSS++");
-our $stylesheet;
-# default is not to define style sheet, but it can be overwritten later
-undef $stylesheet;
-
# URI of default stylesheet
our $stylesheet = "++GITWEB_CSS++";
^ permalink raw reply related
* git-shortlog mailmap
From: Petr Baudis @ 2006-10-26 12:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: torvalds, git
In-Reply-To: <ehputm$ch2$3@sea.gmane.org>
I think I've complained about this in the past, but can't find the mail.
Dear diary, on Thu, Oct 26, 2006 at 11:25:50AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Johannes Schindelin wrote:
>
> > BTW what happened to the builtin shortlog? It is the last Perl script I
> > use regularly... (should make people happy who are stuck with Activision
> > Perl...)
>
> BTW. both Perl version and builtin shorlog have email->real name translation
> table built in. In Perl script version it is in __DATA__ section, and we
> could update it using Inline::Files module, in C version it was in table.
> But in fact this list is project specific. Shouldn't we make it customizable
> (::sigh::, yet another file in $GIT_DIR...).
I really dislike the fact that we _do_ this mapping at all, this seems
so much a totally wrong point at which to do it. The information tracked
in Git is still wrong and all the tools except shortlog still display it
wrong - why should shortlog in particular be special? Why don't we do
this at the git-am time instead?
And overally, things would be simpler if people would just require the
author name to be recorded in the mail properly when applying the patch;
AIUI at least in case of the kernel this mapping shouldn't really be
needed anymore anyway since with the signoff protocol, you already
require all the contributors to reveal their realnames in signoffs?
People can then as well just write that in their from headers as well.
Linus?
So what about making git-am by default refuse to apply patches with
missing author realnames?
--
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: Vincent Ladeuil @ 2006-10-26 12:33 UTC (permalink / raw)
To: Jeff King; +Cc: bazaar-ng, git
In-Reply-To: <20061026111338.GA15179@coredump.intra.peff.net>
>>>>> "Jeff" == Jeff King <peff@peff.net> writes:
Jeff> On Thu, Oct 26, 2006 at 12:52:05PM +0200, Vincent Ladeuil wrote:
>> Ok, so git make a distinction between the commit (code created by
>> someone) and the tree (code only).
Jeff> Yes (a commit is a tree, zero or more parents, commit message, and
Jeff> author/committer info).
The parents of a tree are also trees or can/must they be commits ?
>> Commits are defined by their parents.
Jeff> Partially, yes.
I buy that this "partially" means "the other parts are irrelevant
to this discussion".
>> Trees are defined by their content only ?
Jeff> Yes.
So it is possible that : starting from a tree T,
- I make a patch A,
- you make the patch B,
- A and B are equal (stop watching above my shoulder please, or what is me ?),
- we both commit,
- we pull changes from each other repository.
We will end up with a tree T2 with a hash corresponding to both
T+A and T+B, but each of us will have a different commit id CA
and CB both pointing to T2, did I get it ?
Vincent
^ permalink raw reply
* Re: What's in git.git
From: Petr Baudis @ 2006-10-26 12:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk62npipb.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Oct 26, 2006 at 10:47:12AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> gitweb: use for-each-ref to show the latest activity across branches
It's a pity that for-each-ref is used only for that, I'd appreciate a
lot if git_get_refs_list() could use it too, for the sake of
repo.or.cz:glibc-cvs.git summary view, which is massive. :-)
> I looked at Pasky's "project forks" gitweb code, and while I
> liked it a lot (having a demonstration site repo.or.cz really
> helps), I read on #git log that Pasky himself was having
> doubt, so it is parked in "pu", not in "next".
I had doubts in the middle of implementing it, but now I don't - for
summary of why, please see
http://news.gmane.org/find-root.php?message_id=<20061024173943.GF20017@pasky.or.cz>
--
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: Jakub Narebski @ 2006-10-26 12:18 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <20061026121253.GE17019@over-yonder.net>
Matthew D. Fuller wrote:
> On Thu, Oct 26, 2006 at 12:13:39PM +0200 I heard the voice of
> Andreas Ericsson, and lo! it spake thus:
>> Matthew D. Fuller wrote:
>>>
>>>In git, this is a non-issue because you don't get to CHOOSE which
>>>way to work.
>>
>> Yes they do.
>
> Not where I was going with that section of the mail; I was looking at
> just the merge vs fast-forward distinction. In git, you don't get to
> choose; in bzr you do.
You can get similar workflow in git using 'origin'/'master' pair, I think.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's in git.git
From: Jakub Narebski @ 2006-10-26 12:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061026120824.GO20017@pasky.or.cz>
Dnia czwartek 26. października 2006 14:08, Petr Baudis napisał:
> Dear diary, on Thu, Oct 26, 2006 at 11:12:36AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> This unfortunately means that I cannot test gitweb based on 'master'
>> branch using _released_ git core, git version 1.4.3.3, as it doesn't have
>> git-for-each-ref nor git-show-ref.
>>
>> BTW. do people often use latest gitweb with older git binaries? Should
>> we try to wait for core feature to mature to released version before using
>> it in gitweb? Or perhaps we should add some kind of version checking, and
>> provide workrounds, e.g. using $ENV{GIT_DIR} if git core doesn't support
>> --git-dir option, pathlimit filtering using git-rev-list piped to
>> git-diff-tree --stdin in git_history if there is no --full-history
>> option, show always HEAD activity if there is no git-for-each-ref
>> etc.; well the latest we can do without checking for git core version, just
>>
>> if -x qx($GIT --exec-path)/git-for-each-ref
>
> I can't imagine a situation where you would _want_ to use latest gitweb
> but refuse to use older git binaries - can you explain why do you want
> to do that?
Theoretically? I could have Perl installed, have installed tools Git
requires to use but not have installed tools Git require to compile.
Hence forced to use pre-compiled binaries.
But that is not my situation.
> If you don't want to install the latest master systemwide, that's
> reasonable, but you can just keep the latest master for the gitweb
> script and/or your personal use.
Well, I'd use compiled 'master' version of git for gitweb, then...
--
Jakub Narebski
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-26 12:13 UTC (permalink / raw)
To: Nicholas Allen; +Cc: bazaar-ng, git
In-Reply-To: <4540A1FE.4050300@ableton.com>
Nicholas Allen wrote:
> Jakub Narebski wrote:
>>
>> 4. Supports Renames. I could agree with "Somewhat" because of not yet
>> implemented --follow option to git-rev-list (and therefore all porcelain).
>> Perhaps it would be closer to truth to leave the marker (background color)
>> as for "Somewhat" and write "N/A" with note that Git has contents and
>> pathname based heuristic detection of renames, or just put "Detect" or
>> "Detection" here.
>>
>> I would certainly change description of what means that SCM doesn't "Support
>> Renames" or has it implemented partially. Current explanation relies
>> heavily on _implementation_. The correct wording of current definition
>> would be that SCM doesn't support renames if history of a file "as visible
>> to SCM" is broken into before rename and after rename part, and that SCM
>> support it partially if you can track history of renamed file from
>> post-rename name but there is left in void history of pre-rename file.
>> But with this definition Git _does_ "Supports Renames".
>
> I would have thought that supports renames would also involve flagging a
> conflict when merging a file that has been renamed on 2 separate
> branches. ie 2 branches rename the file to different names and then one
> branch is merged into the other. In this situation, the user should be
> told of a rename conflict. Bzr supports this as far as I know. Not sure
> about git though as I have never used it.
If I remember correctly Git usually resolves such conflict. If it cannot
resolve it, it tells user of rename conflict (add/add conflict or rename/add
conflict).
Unfortunately Git tutorial part 3 on merges is not yer written.
--
Jakub Narebski
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-26 12:12 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: David Lang, bazaar-ng, git
In-Reply-To: <45408A53.10400@op5.se>
On Thu, Oct 26, 2006 at 12:13:39PM +0200 I heard the voice of
Andreas Ericsson, and lo! it spake thus:
> Matthew D. Fuller wrote:
> >
> >In git, this is a non-issue because you don't get to CHOOSE which
> >way to work.
>
> Yes they do.
Not where I was going with that section of the mail; I was looking at
just the merge vs fast-forward distinction. In git, you don't get to
choose; in bzr you do.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
^ permalink raw reply
* Re: What's in git.git
From: Petr Baudis @ 2006-10-26 12:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehpu4t$ch2$1@sea.gmane.org>
Dear diary, on Thu, Oct 26, 2006 at 11:12:36AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> This unfortunately means that I cannot test gitweb based on 'master'
> branch using _released_ git core, git version 1.4.3.3, as it doesn't have
> git-for-each-ref nor git-show-ref.
>
> BTW. do people often use latest gitweb with older git binaries? Should
> we try to wait for core feature to mature to released version before using
> it in gitweb? Or perhaps we should add some kind of version checking, and
> provide workrounds, e.g. using $ENV{GIT_DIR} if git core doesn't support
> --git-dir option, pathlimit filtering using git-rev-list piped to
> git-diff-tree --stdin in git_history if there is no --full-history
> option, show always HEAD activity if there is no git-for-each-ref
> etc.; well the latest we can do without checking for git core version, just
>
> if -x qx($GIT --exec-path)/git-for-each-ref
I can't imagine a situation where you would _want_ to use latest gitweb
but refuse to use older git binaries - can you explain why do you want
to do that?
If you don't want to install the latest master systemwide, that's
reasonable, but you can just keep the latest master for the gitweb
script and/or your personal use.
--
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 1/3] make index-pâck able to complete thin packs
From: Catalin Marinas @ 2006-10-26 11:57 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jakub Narebski, git
In-Reply-To: <20061026105841.GB16372@diana.vm.bytemark.co.uk>
On 26/10/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-10-26 11:13:47 +0100, Catalin Marinas wrote:
> > Karl Hasselström <kha@treskal.com> wrote:
> > > On 2006-10-26 09:50:48 +0200, Jakub Narebski wrote:
> > > > That said, git-am should understand QP with coding in mail
> > > > headers.
> > >
> > > I really hope it does, since I just patched StGIT to generate such
> > > headers. (Out of pure vanity -- I don't want my name mangled!)
> >
> > It looks like it does, that's how I applied some of your patches
> > ('stg import' doesn't understand them).
>
> Hmm. So now I know why you haven't taken my "stg email" patches. I
> guess I'll have to fix 'stg import' then. :-)
That's one of the reasons (and I didn't have time to document myself
before giving a proper reply). The other is that Gnus (and gmail)
doesn't display the messages properly - it shows a lot of "=20". Is it
possible not to affect the body (or make it optional)? People only
using "patch" to apply the diffs would have problems with this
encoding.
--
^ permalink raw reply
* Re: VCS comparison table
From: Nicholas Allen @ 2006-10-26 11:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <ehq78n$ec7$1@sea.gmane.org>
>
> 4. Supports Renames. I could agree with "Somewhat" because of not yet
> implemented --follow option to git-rev-list (and therefore all porcelain).
> Perhaps it would be closer to truth to leave the marker (background color)
> as for "Somewhat" and write "N/A" with note that Git has contents and
> pathname based heuristic detection of renames, or just put "Detect" or
> "Detection" here.
>
> I would certainly change description of what means that SCM doesn't "Support
> Renames" or has it implemented partially. Current explanation relies
> heavily on _implementation_. The correct wording of current definition
> would be that SCM doesn't support renames if history of a file "as visible
> to SCM" is broken into before rename and after rename part, and that SCM
> support it partially if you can track history of renamed file from
> post-rename name but there is left in void history of pre-rename file.
> But with this definition Git _does_ "Supports Renames".
I would have thought that supports renames would also involve flagging a
conflict when merging a file that has been renamed on 2 separate
branches. ie 2 branches rename the file to different names and then one
branch is merged into the other. In this situation, the user should be
told of a rename conflict. Bzr supports this as far as I know. Not sure
about git though as I have never used it.
^ permalink raw reply
* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Catalin Marinas @ 2006-10-26 11:52 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jakub Narebski, git
In-Reply-To: <20061026105841.GB16372@diana.vm.bytemark.co.uk>
On 26/10/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-10-26 11:13:47 +0100, Catalin Marinas wrote:
> > Karl Hasselström <kha@treskal.com> wrote:
> > > On 2006-10-26 09:50:48 +0200, Jakub Narebski wrote:
> > > > That said, git-am should understand QP with coding in mail
> > > > headers.
> > >
> > > I really hope it does, since I just patched StGIT to generate such
> > > headers. (Out of pure vanity -- I don't want my name mangled!)
> >
> > It looks like it does, that's how I applied some of your patches
> > ('stg import' doesn't understand them).
>
> Hmm. So now I know why you haven't taken my "stg email" patches. I
> guess I'll have to fix 'stg import' then. :-)
That's one of the reasons (and I didn't have time to document myself
before giving a proper reply). The other is that Gnus (and gmail)
doesn't display the messages properly - it shows a lot of "=20". Is it
possible not to affect the body (or make it optional)? People only
using "patch" to apply the diffs would have problems with this
encoding.
--
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-26 11:48 UTC (permalink / raw)
To: bazaar-ng; +Cc: git
In-Reply-To: <45408A53.10400@op5.se>
Andreas Ericsson wrote:
> On a side-note, git has made my life easier, so I childishly want to
> defend it and see it on top of every list in the world. Something I'm
> sure I share with more people on this list and with some of the bazaar
> users/devs. ;-)
Let's then us review what started this thread, namely comparison chart
between source control systems
http://bazaar-vcs.org/RcsComparisons
1. Decentralized. O.K.
2. Disconnected Ops. O.K.
3. Simple Namespace. Should be named "Simple Rev Names" instead, Bazaar
should have note that revnos work only for specific workflows
(star-topology); for Git it should be perhaps "Somewhat" here, as <ref>~<n>
(or <ref>@{<n>} if reflog is enabled) _are_ simple (if volatile for branch
<refs>). $(git-merge-base <ref1> <ref2>), usually "hidden" in
<ref1>..<ref2> or <ref1>...<ref2> shortcut is also I think simple. There
was huge discussion here about revnos, revids, workflows (development
topology), fast-forwards, empty merges etc. Bazaar-NG and Git puts
emphasisis on other things. Additionally tags supports removes some of
perceived revnos advantages; tags are simple.
4. Supports Renames. I could agree with "Somewhat" because of not yet
implemented --follow option to git-rev-list (and therefore all porcelain).
Perhaps it would be closer to truth to leave the marker (background color)
as for "Somewhat" and write "N/A" with note that Git has contents and
pathname based heuristic detection of renames, or just put "Detect" or
"Detection" here.
I would certainly change description of what means that SCM doesn't "Support
Renames" or has it implemented partially. Current explanation relies
heavily on _implementation_. The correct wording of current definition
would be that SCM doesn't support renames if history of a file "as visible
to SCM" is broken into before rename and after rename part, and that SCM
support it partially if you can track history of renamed file from
post-rename name but there is left in void history of pre-rename file.
But with this definition Git _does_ "Supports Renames".
I'd rather split "Supports Renames" into engine part (does SCM
remember/detect that rename took place _as_ rename, not remember/detect it
as copiying+deletion; something other than rename) and user interface part:
can user easily deal with renames (this includes merging and viewing file
history).
5 and 6. Needs Repository/Supports Repository. The name is very, very
unclean and stems from branch-centricness of Bazaar. Git should probably
have "Yes" here, as for Git branch is just reference to its tip in
revisions DAG (plus optionally branch tip history in reflog). On the other
hand Git _can_ share object database like branches can be gathered together
to share data into repository. You can have one-branch repositories, you
can clone whole repositories (perhaps Bazaar should have "Somewhat" for
Supports Repository as it doesn't support cloning of whole repository...
bzt, wrong, there is example plugin for that), and you can clone (using
Cogito) only one branch of repository and you can fetch only selected
branches of repository.
Thinking more about it those items should probably read "Support Individual
Branches" (as: can you get only the branch you are interested in, can SCM
support one-branch workflow) and "Support Branch Grouping" or "Support Data
Sharing" (as: can you share DAG between branches, can you share DAG between
repositories).
7. Checkouts (as a noun). This probably read "Support Centralized and
Disconnected Centralized Workflow" but that is perhaps too wordy. Git would
have "No" for "Centralized" and "Somewhat" for "Disconnected Centralized"
meaning that you can set up Git repository to be equivalent of heavyweight
checkout, and push changes to some given repository on commit.
8. Partial Checkouts (as a verb). Here Git should have perhaps "Minimal", as
you can have partial checkouts but only with care (and you still need whole
repository). "No?" is also correct (?).
9. Atomic Commits. O.K. You have to remember that there are consequences
of having Atomic Commits on the details of Partial Checkouts.
10. Cheap Branching Anywhere. Git should probably have "Yes! Yes! Yes!"
here ;-)
11. Smart Merge. O.K. Should probably be explained what constitutes smart
merging. Perhaps instead of "Yes" there should be name of default/smartest
merge strategy used?
12. Cherrypicks. What constitutes "Yes" here? Why "Somewhat" for Git?
It does have git-cherry-pick command for cherry picking...
13. Plugins. I would put "Somewhat" here, or "Scriptable" in the "Somewhat"
or "?" background color for Git. And add note that it is easy to script up
porcelanish command, and to add another merge strategy. There also was
example plugin infrastructure for Cogito, so I'd opt for "Someahwt"
marking.
14. Has Special Server. O.K.
15. Req. Dedicated Server. O.K.
16. Good Windows support. I'd put "Cygwin" instead of "No" for Git, although
with the same marking. And perhaps add note that Git relies heavily on
POSIX.
17 and 18. Fast Local Performance and Fast Network Performance. O.K.
19. Ease of Use. Hmmm... I don't know for Git. I personally find it very
easy to use, but I have not much experiences with other SCM. I wonder why
Bazaar has "No" there...
Too much rewriting to correct the page...
^ permalink raw reply
* shortlog, was Re: merge-recursive, was Re: What's in git.git
From: Andreas Ericsson @ 2006-10-26 11:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0610261114520.3286@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>
> BTW what happened to the builtin shortlog? It is the last Perl script I
> use regularly... (should make people happy who are stuck with Activision
> Perl...)
>
I keep writing
git log --short
when I really want
git log --pretty=short | git shortlog
I'll have a look at making it work if I get a spare moment.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-26 11:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, git, bazaar-ng, Linus Torvalds, Lachlan Patrick,
David Rientjes
In-Reply-To: <7v3b9cnlx7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> - Learn the itches David and other people have, that the
> current git Porcelain-ish does not scratch well, and enrich
> Documentation/technical with real-world working scripts built
> around plumbing.
>
Isn't this how git has been developed since day one, more or less? If a
command is missing, it gets added as a shell-script. I agree with you on
the "pipes from this sent here does this, and look how useful it is"
lectures are gone since many commands were rewritten. Otoh, they're gone
because they now instead provide examples on how to interface with the
libified parts of git, so it's not a loss per se, just a switch in what
it teaches.
I also agree with David that shell is much more fun to muck around with
and prototype in, because you see results to much faster. However, since
our plumbing is so rock-solid (and getting extended with --stdin options
to more and more commands), I see no reason why we shouldn't have a "how
to extend git" with the old shell-based porcelain scripts up somewhere
at the web. Perhaps it would kill two birds with one stone and increase
the addition of new utilities to git, while at the same time keeping the
already rewritten commands in C.
Btw, the old shell-versions still work with the new plumbing (well,
mostly anyways). They just have problems with filenames and revisions
with spaces and special chars and things like that, same as they've
always had.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-26 11:18 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <877iyne4dm.fsf@alplog.fr>
Vincent Ladeuil wrote:
> Ok, so git make a distinction between the commit (code created by
> someone) and the tree (code only).
>
> Commits are defined by their parents.
>
> Trees are defined by their content only ?
Trees are collections of tuples: (mode, type, sha1, name), where mode
is simplified mode of a file or directory (only if it is symlink, directory,
file or executable file is tracked), type is blob (file) or tree
(directory), sha1 is sha1 of contents of given entry, and name is filename
of given entry.
> If that's the case, how do you proceed ?
>
> Calculate a sha1 representing the content (or the content of the
> diff from parent) of all the files and dirs in the tree ? Or
> from the sha1s of the files and dirs themselves recursively based
> on sha1s of the files and dirs they contain ?
sha1 of object is sha1 of type+contents if I remember correctly. So the sha1
of tree is based on sha1 of the files and dirs it contain.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-26 11:15 UTC (permalink / raw)
To: David Rientjes; +Cc: Jeff King, Linus Torvalds, Lachlan Patrick, bazaar-ng, git
In-Reply-To: <Pine.LNX.4.64N.0610250954380.31053@attu2.cs.washington.edu>
David Rientjes wrote:
> On Wed, 25 Oct 2006, Jeff King wrote:
>
>>> This all became very obvious when the tutorials came out on "how to use
>>> git in 20 commands or less" effectively. These tutorials shouldn't need
>>> to exist with an information manager that started as a quick, efficient,
>>> and _simple_ project. You're treating git development in the same light
>> Sorry, I don't see how this is related to the programming language _at
>> all_. Are you arguing that the interface of git should be simplified so
>> that such tutorials aren't necessary? If so, then please elaborate, as
>> I'm sure many here would like to hear proposals for improvements. If
>> you're arguing that git now has too many features, then which features
>> do you consider extraneous?
>>
>
> It's not, it's related to the original vision of git which was meant for
> efficiency and simplicity.
Compared to todays version, original git was neither efficient nor
simple. Unless you mean "some random version along the way where git had
everything *I* need and not the useless cruft that other people use", in
which case it's simply a very egotistical view of things.
> A year ago it was very easy to pick up the
> package and start using it effectively within a couple hours. Keep in
> mind that this was without tutorials, it was just reading man pages.
> Today it would be very difficult to know what the essential commands are
> and how to use them simply to get the job done, unless you use the
> tutorials.
Have you tried "git --help"? It shows the most common commands and a
short description of what they do. It's a very good pointer to which
man-pages you need to read, and I imagine this would actually be one of
the very first commands that new git users try. If they don't but just
expect things to work according to some premade mental model they have
of scm's, I'd say they'd be screwed no matter which software they tried.
> This _inherently_ goes against the approach of trying to
> provide something that is simple to the developer.
>
> Revision control is something that should exist in the background that
> does it's simple job very efficiently. Unfortunately git has tried to
> move its presence into the foreground and requiring developers to spend
> more time on learning the system.
>
No it hasn't. The ten or so commands that Linus first introduced when
announcing git still work pretty much the same. Nobody in their right
mind would ever claim that those ten commands made up anything that even
remotely resembled a complete scm, but they were something to build on
by anyone who wanted to extend it. So far, ~220 people have wanted to
extend it in ways that others thought useful, because their patches are
apparently in the git tree.
> Have you never tried to show other people git without giving them a
> tutorial on the most common uses? Try it and you'll see the confusion.
> That _specifically_ illustrates the ever-increasing lack of simplicity
> that git has acquired.
>
Well, my head hurt when I tried to learn CVS without a tutorial, and
mercurial and darcs and svn as well. I didn't pick up the functionality
of the 'ls' command completely without reading the man-page for it. If
you want something that works for everyone without having to read any
documentation what so ever, buy Lego, cause computers ain't for you, my
friend.
>> I don't agree with this. There are tons of enhancements that I find
>> useful (e.g., '...' rev syntax, rebasing with 3-way merge, etc) that I
>> think other developers ARE using. There are scalability and performance
>> improvements. And there are new things on the way (Junio's pickaxe work)
>> that will hopefully make git even more useful than it already is.
>>
>
> There are _not_ scalability improvements. There may be some slight
> performance improvements, but definitely not scalability. If you have
> ever tried to use git to manage terabytes of data, you will see this
> becomes very clear. And "rebasing with 3-way merge" is not something
> often used in industry anyway if you've followed the more common models
> for revision control within large companies with thousands of engineers.
> Typically they all work off mainline.
>
Actually, I don't see why git shouldn't be perfectly capable of handling
a repo containing several terabytes of data, provided you don't expect
it to turn up the full history for the project in a couple of seconds
and you don't actually *change* that amount of data in each revision. If
you want a vcs that handles that amount with any kind of speed, I think
you'll find rsync and raw rvs a suitable solution.
On the other hand, you fellas at google don't really use git to store
the data from the search database, do you? I mean, it's written for
source control management. People that tried to keep their mboxes in git
failed miserably, because large files that constantly change just
doesn't work well with git.
>> If you don't think recent git versions are worthwhile, then why don't
>> you run an old version? You can even use git to cherry-pick patches onto
>> your personal branch.
>>
>
> I do. And that's why I would recommend to any serious developer to use
> 1.2.4; this same version that I used for kernel development at Google.
>
>> Where?
>>
>
> Few months back here on the mailing list. When I tried cleaning up even
> one program, I got the response back from the original author "why fix a
> non-problem?" because his argument was that since it worked the code
> doesn't matter.
>
> http://marc.theaimsgroup.com/?l=git&m=115589472706036
>
> And that is simply one thread of larger conversations that have taken
> place off-list and aren't archived.
>
First off, the code got changed as per Junio's desires. He's the
maintainer and gets to choose about coding style and readability vs
microoptimizations.
Second, why keep discussions about git development off-list?
Third, if you still have issues with it, why not provide a patch and see
if Junio accepts it? Cleaner and faster code will, in my experience,
always get accepted. Code that is cleaner from one devs point of view
but doesn't actually provide any other benefits will be dropped to the
floor, and rightly so.
>> I don't agree, but since you haven't provided anything specific enough
>> to discuss, there's not much to say.
>>
>
> If there's a question about some of the sloppiness in the git source code
> as it stands today, that's a much bigger issue than the sloppiness. My
> advice would be to pick up a copy of K&R's 2nd edition C programming
> language book, read it, and then take a tour of the source code.
>
The first sentence doesn't make sense. The second one is just rude, and
formed by your own opinion on how code should be written. But again,
submit patches and see if Junio accepts them. If he doesn't, and you
really, really *really* can't stand the changes he and the rest of the
git community wants in, fork your own version and hack away til your
heart's content. Git makes it easy for you, whichever version you use.
>> Can you name one customization that you would like to perform now that
>> you feel can't be easily done (and presumably that would have been
>> easier in the past)?
>>
>
> Yes, those mentioned above.
>
Which ones? The git-mv changes you submitted were applied (although in a
different shape), so there must be other ones. Rewriting C builtins as
shell-scripts is not really an option, because portability and
performance *does* matter.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: VCS comparison table
From: Jeff King @ 2006-10-26 11:15 UTC (permalink / raw)
To: Vincent Ladeuil
Cc: James Henstridge, Junio C Hamano, bazaar-ng, Matthew D. Fuller,
Linus Torvalds, Carl Worth, Andreas Ericsson, git, Jakub Narebski
In-Reply-To: <20061026111338.GA15179@coredump.intra.peff.net>
On Thu, Oct 26, 2006 at 07:13:39AM -0400, Jeff King wrote:
> Yes (a commit is a tree, zero or more parents, commit message, and
> author/committer info).
Sorry, I should clarify: a commit is a _tree id_, zero or more _parent
ids_, commit message, etc.
^ permalink raw reply
* Re: VCS comparison table
From: Jeff King @ 2006-10-26 11:13 UTC (permalink / raw)
To: Vincent Ladeuil
Cc: James Henstridge, Junio C Hamano, bazaar-ng, Matthew D. Fuller,
Linus Torvalds, Carl Worth, Andreas Ericsson, git, Jakub Narebski
In-Reply-To: <877iyne4dm.fsf@alplog.fr>
On Thu, Oct 26, 2006 at 12:52:05PM +0200, Vincent Ladeuil wrote:
> Ok, so git make a distinction between the commit (code created by
> someone) and the tree (code only).
Yes (a commit is a tree, zero or more parents, commit message, and
author/committer info).
> Commits are defined by their parents.
Partially, yes.
> Trees are defined by their content only ?
Yes.
> Calculate a sha1 representing the content (or the content of the
> diff from parent) of all the files and dirs in the tree ? Or
> from the sha1s of the files and dirs themselves recursively based
> on sha1s of the files and dirs they contain ?
Recursively. Each tree is an ordered list of 4-tuples: pathname, type,
sha1, mode. If the type is "blob" then the sha1 is the hash of the file
contents. If the type is "tree" then the sha1 is the id of a sub-tree.
The id of a tree is the sha1 hash of the data structure.
> I ask because the later seems to provide some nice effects
> similar to what makes BDD
> (http://en.wikipedia.org/wiki/Binary_decision_diagram) so
> efficient: you can compare graphs of any complexity or size in
> O(1) by just comparing their signatures.
Yes, if two trees' hashes compare equal, they contain the same data. I
believe we are not currently using this optimization to find merge
differences, but there was some discussion earlier this week about doing
so.
^ permalink raw reply
* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Karl Hasselström @ 2006-10-26 10:58 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Jakub Narebski, git
In-Reply-To: <tnxac3j4c6c.fsf@arm.com>
On 2006-10-26 11:13:47 +0100, Catalin Marinas wrote:
> Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2006-10-26 09:50:48 +0200, Jakub Narebski wrote:
> >
> > > That said, git-am should understand QP with coding in mail
> > > headers.
> >
> > I really hope it does, since I just patched StGIT to generate such
> > headers. (Out of pure vanity -- I don't want my name mangled!)
>
> It looks like it does, that's how I applied some of your patches
> ('stg import' doesn't understand them).
I suppose I should have checked, but we do supposedly support patches
written in any sane e-mail client, and real e-mail clients will encode
headers.
Hmm. So now I know why you haven't taken my "stg email" patches. I
guess I'll have to fix 'stg import' then. :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: merge-recursive, was Re: What's in git.git
From: Johannes Schindelin @ 2006-10-26 10:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7v7iyno0qk.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 26 Oct 2006, Junio C Hamano wrote:
> This is a prime demonstration that it makes more sense to keep script
> version until we flush out configurability issues.
Okay, I agree.
BTW before somebody asks: No, I did _not_ implement the .mailmap
functionality. But once things are flushed out with the configuration, and
_if_ the builtin is not undesired, I will implement it.
Since Linux really is a special guest, maybe we'd want to integrate the
dot3 thing in .mailmap, and override the Linux defaults _only_ if .mailmap
exists. Thoughts?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-svnimport: support for partial imports
From: Karl Hasselström @ 2006-10-26 10:54 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Junio C Hamano, git, Matthias Urlichs
In-Reply-To: <20061026103120.GA15502@sashak.voltaire.com>
On 2006-10-26 12:31:20 +0200, Sasha Khapyorsky wrote:
> On 10:47 Thu 26 Oct, Karl Hasselström wrote:
> > Isn't this already doable with "-T trunk/path/to/our/project -t
> > tags/path/to/our/project -b branches/path/to/our/project"?
>
> In such case git-svnimport will not be able to resolve branches and
> tags names - note that actual SVN paths are:
>
> branches/<branch-name>/path/to/our/project
> tags/<tag-name>/path/to/our/project
Aahh, right. I didn't think of that.
--
Karl Hasselström, kha@treskal.com
^ 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