Re: git head configure fails
Hmmm, sorry for the noise. It seems that the debian package autoconf2.64 works. However somehow deleting and installing autoconfxxx left a autoconf2.50 binary installed, which the pike run_autoconfig script seems to prefers and causes the error. /Marc
Re: git head configure fails
Try an older autoconf version. autoconf 2.13, autoconf 2.59 and autoconf 2.64 from debian packages all produce the same error. Which one do you use? Best regards, Marc
Re: git head configure fails
Marc Dirix wrote: I currently git this error with pike7.8 git head: checking for sys/param.h... (cached) yes /root/pike3/pike/src/modules/Image/configure: line 3380: syntax error near unexpected token `;;' /root/pike3/pike/src/modules/Image/configure: line 3380: ` ac_cv_path_GREP=$ac_path_GREP ac_path_GREP_found=:;;' Try an older autoconf version. -- Stephen. Warning: Dates in calendar are closer than they appear.
Re: Git ident patches (Re: Feedback (Re: pcvs2git.pike))
are you planning to submit those fixes to git upstream? it would be inconvenient to need a custom git implementation to make the import script (or worse the repository) work well. greetings, martin.
Re: git down for maintenance
Peter Bortas @ Pike developers forum wrote: The zone running the git and git-web services on eureka are down until we figure out if git-web needs updating to fix some vulnerabilities. I can upgrade it to the latest version, no real pain there. Or I could disabled git-web for the time being. -- Sincerely, Stephen R. van den Berg. Ping me harder!
Re: git down for maintenance
Peter Bortas @ Pike developers forum wrote: The zone running the git and git-web services on eureka are down until we figure out if git-web needs updating to fix some vulnerabilities. I can upgrade it to the latest version, no real pain there. Or I could disabled git-web for the time being. Either should be fine. -- Sincerely, Stephen R. van den Berg.
Re: git down for maintenance
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote: Peter Bortas @ Pike developers forum wrote: The zone running the git and git-web services on eureka are down until we figure out if git-web needs updating to fix some vulnerabilities. I can upgrade it to the latest version, no real pain there. Or I could disabled git-web for the time being. Either should be fine. Well, I need ssh access to actually do either. Could someone please open up the zone again? -- Sincerely, Stephen R. van den Berg. Ping me harder!
Re: git down for maintenance
zone booted up again.
Re: git down for maintenance
Peter Bortas @ Pike developers forum wrote: zone booted up again. Thanks. Git (and gitweb) updated to version 1.6.2.103.gc4994 of March 9th 2009. -- Sincerely, Stephen R. van den Berg. Ping me harder!
Re: Git repository
The copyright statement says 1994, and the archived releases of LPC4 I can find date from April 1994 to September 1994, so end of 1994 sounds about right.
Re: Git repository
Helper script count_r2lines (counts total and original lines for a
particular path and revision):
--8--
#!/bin/sh
if [ $# != 2 ]; then
echo 2 Usage: $0 dir rev
exit 1
fi
dir=$1
rev=$2
repos=file://$HOME/repos/Pike/
hit=0
tot=0
svn ls -r$rev -R $reposPike/$dir@$rev | sed -e '/\/$/d' | while read f;
do
set `svn annotate -r$rev $reposPike/$dir/$f@$rev | sed -e 's/^
*\([0-9]*\) *.*$/\1/' | /usr/xpg4/bin/awk 'BEGIN {x=0} $1==2 { x++ } END
{print x,NR}'`
hit=`expr $hit + $1`
tot=`expr $tot + $2`
echo $hit $tot
done | tail -1
--8--
Main script (runs the helper script for each pike branch at head, and
for the original ulpc checkin):
--8--
#!/bin/sh
doit() {
dir=$1
rev=$2
name=$3
set `./count_r2lines $dir $rev`
echo $name $1 $2
}
for i in 7.8 7.6 7.4 7.2 7.0 0.6 0.5 ulpc ulpc.old; do
doit $i head $i
done
doit ulpc 2 ulpc.0
--8--
Pike script for presentation of the raw data generated by the main
script:
--8--
#!/home/marcus/bin/pike
int lcnt0;
int main()
{
array(string) x = Stdio.read_file(r2lines.data)/\n-({});
sscanf(x[-1], %*s %*d %d, lcnt0);
foreach(x, string y) {
string n; int l, t;
sscanf(y, %s %d %d, n, l, t);
write(%-8s %5d / %6d %5.1f%% %5.1f%%\n,
n, l, t, 100.0*l/t, 100.0*l/lcnt0);
}
return 0;
}
--8--
I ran this on eureka-svn, but if you change the assignment of repos
to http://eureka-svn.lysator.liu.se/; it should run anywhere.
Ac-counting (Re: Git repository)
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: Helper script count_r2lines (counts total and original lines for a particular path and revision): Does it disregard empty lines in the count? -- Sincerely, Stephen R. van den Berg. There are three types of people in the world; those who can count, and those who can't.
Ac-counting (Re: Git repository)
Nope. Adapting the sed command to do that is left as an execercise. :-)
Re: Git repository
a rough cut of the diagram is now here: https://pike.ida.liu.se/development/history.xml i'll leave beautification to the graphicians i made this graph using git git diff --shortstat to compare all the branches. 0.3b and 0.4 are included because there are some changes going on that would otherwise not be visible. greetings, martin.
Re: Git repository
Infotastic! Would be interesting to space out the x axis according to release times too, for yet another perspective on the data.
Re: Git repository
yes, i considered doing a similar graph that not only has the releases but compares changes from month to month (or even week to week, given one pixel width per week this should make for a nice graph :-) greetings, martin.
Re: Git repository
I've now reconnected the history of ulpc(.old) to the main Pike development line in the Subversion reposiotry, so if you do svn log -v http://pike-svn.lysator.liu.se/Pike/7.8/src/pike_memory.c you'll go al the way back to r2. :-) (Also, you can use blame to find out that the hashstr() function still looks almost exactly like it did in the beginning.)
Re: Git repository
it would be nice to get an overview of how much of the original code is still left. maybe even for every version, to see the amount of change happening. greetings, martin.
Re: Git repository
Should be possible to find out with a script. I assume the interresting metric would be how much of the current code is original rather than how much of the original code is current?
Re: Git repository
both actually, while 10% of the current code being original means that there is a lot of new code, it could be that 90% of the original code is still current, which would means that most of the original code survived but the whole codebase grew by a magnitude. do that for each major revision and we get a nice graph of how the code evolved over time. greetings, martin.
Re: Git repository
Ok, the results are in: 7.8 7481 / 873478 0.9% 15.9% 7.6 7965 / 690785 1.2% 16.9% 7.4 8761 / 652559 1.3% 18.6% 7.2 11612 / 466609 2.5% 24.7% 7.0 12801 / 341128 3.8% 27.2% 0.6 15764 / 210659 7.5% 33.5% 0.5 20061 / 132486 15.1% 42.6% ulpc 42087 / 91730 45.9% 89.4% ulpc.old 43881 / 52093 84.2% 93.2% ulpc.0 47101 / 47101 100.0% 100.0% ulpc.0 is the original checkin of ulpc into the Infovav repository, so it's 100% original by definition. :-) The numbers for each repository are: * Number of lines which are original * Total number of lines * Percentage of lines which are original * Percentage of the original lines which remain Binary files are not taken into account, but the only binary file which exists in ulpc.0 is doc/manual/ulpc-inside3.gif, and this file obviously did not survive the transition to Pike.
Re: Git repository
Oh, and there's 13 years and 1 month of development between ulpc.0 and today (ulpc.0 commit date was 1995-08-09).
Re: Git repository
very nice! do we know the date when ulpc was started? greetings, martin.
Re: Git repository
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote: The recommended practice is that for back/forwardports the commit id's of the originating cherry-picked patches are mentioned at the bottom of the new commit message. Unfortunately that won't help (if we) in the future use git for backports, since the new backports will get the same graphs once again. No. The backports in Pike would be done in git using git cherry-pick. And as-is git cherry-pick does not create a parent reference, but gives you the option of a textual reference in the free-form commit message. This means that the current practice of creating extra parents for the backports has to be altered into either: - Textual references at the bottom of the commit message. - Or usage of a new (native git) link which I'm trying to get included into git as we speak. I believe the problem lies in how gitk determines what branch(es) a commit is on rather than on our use of grafts for backports. That's what I thought first as well, and it might even be true, but it's not what the git community wants to fix. It's either the first or the second option above, and I'm pushing for the second at the moment. This means that I'll have to regenerate the backport/forwardport way of linking to modify the commit messages instead of the graft/parent list. -- Sincerely, Stephen R. van den Berg. Be spontaneous!
Re: Git repository
Correct. And apparently it was/is intended for merges only, even though the diff-machinery already delivers correct results even if it's a cherry-pick instead of a merge. Does it? That's also a thing that confuses me: Consider commit 1cc21ef0320ecb734d4db5b85dbdc0406815e38e, which is a grafted merge from 7.8 to 7.6. In gitk, it shows a three-way merge, where the diff from the 7.6 parent shows the patch, as expected. The diff from 7.8 apparently shows whatever differences there are between 7.8 and 7.6 that happens to be in the context of the 7.6 parent diff (e.g. the verify_mexec_hdr line). That's odd imho. Assuming parent pointers mean merges, I'd expect to see all differences between the 7.8 and 7.6 versions of the file. If this was a real merge rather than a cherry-pick, the three-way diff would have a lot of essential information missing. If, otoh, gitk can tell that the parent pointer into the 7.8 branch is a cherry-pick relation (using a property I've yet to understand), then I'd expect to see a two-way diff on the 7.6 branch only - the differences to 7.8 would just be garbage. I also get confused with git-log: Look at the same commit with git log -p 1cc21ef0. Then it doesn't show any diff at all, neither against 7.6 nor 7.8. What's worse, if I use only git log -p on the 7.6 branch and search for the commit there then I don't see the diff either. If I look at the log on a branch, I really expect to see _all_ diffs that leads up to the current content. Maybe this can be explained with that the log due to all the backport merges skips over to the 7.8 tree after a while, but using --first-parent doesn't help. Btw, speaking of git-log, how does one make it print out the branches like gitk does? If parent pointers are used for both of these, then how would git tell a merge from a cherry-pick? Well, the difference can be inferred from the content, /.../ I'm curious, how does that work? I guess this could explain the (imo) strange results I'm discussing above. The properties I'm going to propose are that the link: - Is called something like origin. - That it contains the SHA1 of the commit we're picking from in addition to the --mainline parent-number (in case there are multiple parents). - A commit can have an arbitrary number of origin links. - The origin link is weak by default, i.e. once inside a repository it will keep alive any referenced commits, but it will not cause the linked to commit to be fetched or pulled from a remote repository automatically. Sounds sane to me, but I'm only a n00b. Btw, my main use case for cherry-pick links are, as I've said elsewhere, to get an accurate log of the difference with git log A..B. I see now that git-log has a --cherry-pick option which claims to detect cherry-picked patches anyway. How does it work? The commit diffs have to be byte-for-byte identical?
Re: Git repository
On Tue, Sep 09, 2008 at 04:45:02PM +, Martin Stjernholm, Roxen IS @ Pike developers forum wrote: Btw, speaking of git-log, how does one make it print out the branches like gitk does? i think you are looking for --decorate Print out the ref names of any commits that are shown. greetings, martin.
Re: Git repository
--decorate helps a bit, but it still doesn't show the branch(es) each commit is made on. Thanks for the tip anyway.
Re: Git repository
Ok good, that should make the history more straight and simple. Still, it would be nice if git had some builtin concept of cherry-picked patches between branches, so it'd be possible to write e.g. git log 7.6..7.8 to see all commits that really are in 7.8 only.
Re: Git repository
actually, there is a concept that could help, in addition to the normall commit hash there is als an object hash that is only made out of the diff and maybe the comment (not sure), now all that is needed is tools to find multiple occurances of these and connect them. that search could be expensive though, so any commits found would need to be recorded somewhere. greetings, martin.
Re: Git repository
Like embee, I'm curious about those backport grafts that appear as merges. Is this only a problem of representation in gitk and git-log? To me it seems odd to describe them as merges since I reckon that content would be identical after a merge. I did some backchecks on the git mailinglist now, and it appears that I was a bit overly optimistic in my assumption that git is able to distinguish between backports and merges based on parenthood alone. The recommended practice is that for back/forwardports the commit id's of the originating cherry-picked patches are mentioned at the bottom of the new commit message. Unfortunately that won't help (if we) in the future use git for backports, since the new backports will get the same graphs once again. I believe the problem lies in how gitk determines what branch(es) a commit is on rather than on our use of grafts for backports. This means that I'll have to regenerate the backport/forwardport way of linking to modify the commit messages instead of the graft/parent list. -- Sincerely, Stephen R. van den Berg.
Re: Git repository
true, but if the backport was done with a git cherry-pick they would have at least the same author and timestamp. (ok, at that point one might as well explicitly mark the cherry pick...) greetings, martin.
Re: Git repository
Unfortunately that won't help (if we) in the future use git for backports, since the new backports will get the same graphs once again. I don't understand this. What graphs? I believe the problem lies in how gitk determines what branch(es) a commit is on rather than on our use of grafts for backports. Correct me if I'm wrong, but a graft is a way to artificially add a parent/child relation, isn't it? If a commit has two (or more) parents, isn't that per definition a merge of them, which should cause a join of their respective branches? Cherry-picked patches are rather different since only the patch itself is taken from the other branch, not the whole content of that branch. If parent pointers are used for both of these, then how would git tell a merge from a cherry-pick?
Re: Git repository
could you please post the commit ids? greetings, martin.
Re: Git repository
Added DMALLOC_USE_HASHBASE mode is
fe982070cac0283b79a3a4a3a54b7865537acab7.
Also regarding src/pike_memory.c, its history starts with
memory.{c,h} renamed to pike_memory.{c,h}
(4e86f944a018c5397e3c55693b0637f63987e7d7). Regardless of -M, -C and
--find-copies-harder flags, I can't see the history past that point.
Re: Git repository
On Sat, Sep 06, 2008 at 12:40:02PM +, Martin Stjernholm, Roxen IS @ Pike developers forum wrote: Added DMALLOC_USE_HASHBASE mode is fe982070cac0283b79a3a4a3a54b7865537acab7. ah, i think i see the problem. it looks like the backports somehow get indicated as whole merges. not sure what stephen has done here, i thought that backports were added as grafts which is extra data not part of the commits themselves. take a look at 3ddc88c0499fc084d5ddc3a38cb2620e3cfb4a63 and you see the merge lines that cause the confusion. stephen, can yopu elaborate on this? greetings, martin.
Re: Git repository
Martin Baehr wrote: On Sat, Sep 06, 2008 at 12:40:02PM +, Martin Stjernholm, Roxen IS @ Pike developers forum wrote: Added DMALLOC_USE_HASHBASE mode is fe982070cac0283b79a3a4a3a54b7865537acab7. ah, i think i see the problem. it looks like the backports somehow get indicated as whole merges. I know the problem. It's a flaw in the way gitk determines the (main) branch a certain commit is on. I.e. the graphical display is correct, the notification of which tags lie ahead and in the past is confused by the backport links. The tree is essentially correct, I have a patch to gitk in the works to actually cleanup this behaviour and show the correct values. As for now, until the fully backport-connected history is finished and the patch to gitk is in, you can reduce the clutter in the gitk view by using: gitk --first-parent 7.8 7.6 7.4 7.2 7.0 0.6 0.5 -- Sincerely, Stephen R. van den Berg. You cannot propel yourself forward by patting yourself on the back.
Re: Git
Martin Stjernholm, Roxen IS @ Pike developers forum wrote: More precisely, -F is the relevant flag. Unfortunately it doesn't work with -c. I've bug reported that. Still I think I'd prefer to configure git status to not use the pager at all. There were elaborate discussions about this on the git mailinglist about three months ago, I'll try and look up what the consensus was. git-svn keeps a lot of state in memory, maybe even has memory leaks, don't know for sure. What helps, everytime, is simply killing and restarting git-svn. Git-svn is *very* good at restarting and picking up right where it left off. Tried that, didn't help the speed at all. It also gc'd by itself every once in a while, and doing an extra gc didn't improve things either. Well, I do know that I always ran it on a local SVN repo (when doing huge imports). So for Pike, either copy the repo locally using the dumpfile, or use SVK to mirror the SVN repo, then run git-svn. -- Sincerely, Stephen R. van den Berg. How many weeks are there in a lightyear?
Re: Answer and some nice ideas perhaps (Re: Git repository bug)
Stephen R. van den Berg wrote: Stephen R. van den Berg wrote: Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: There should be a similar difference between That should have read: git blame README-CVS git blame --find-copies-harder README-CVS It turns out that git blame doesn't understand the --find-copies-harder option (yet), but does understand the equivalent -C -C (which git diff and show understand as well). git blame -C -C README-CVS will allow git to traverse back through copy-modify-commit history. -- Sincerely, Stephen R. van den Berg. How many weeks are there in a lightyear?
Re: Git
Martin B?hr wrote: On Mon, Jul 28, 2008 at 11:15:02PM +, Martin Stjernholm, Roxen IS @ Pike developers forum wrote: g. Anyone having local branches which are based off of commits in the old git repository will have to rebase those How do you go about that? Manually rebasing every branch yes. Say you have the following two aliases in /etc/gitconfig: [alias] makepatch = format-patch -k --stdout applypatch = am -k --whitespace=nowarn Say you have a local branch called mybranch with commits: A-B-c-d-e Where A-B are part of the public repository. Then I'd do a: git checkout mybranch git makepatch B /tmp/mybranchinpatchformat Then resync the repository/branches to the history-changed master repository. Then: git checkout mybranch git applypatch /tmp/mybranchinpatchformat And you'd end up with: A'-B'-c'-d'-e' Even if it's simple to rebase, I think it'd be best to avoid steps f-h as much as possible. I don't think there is any arguing here. I was actually planning to fix the repository once, and be done with it, we just have to get all hens on deck for people to check most of it. And only if we missed a large enough amount of things, we'd ever repeat it, but most likely not. git can work just fine with a shared repository too. I wouldn't like to see the plethora of branches and merges on the server, though. agreed. Let me emphasize this: IMO the best model would be to have a central git repository with just (currently) the main branches: 0.5 0.6 7.0 7.2 7.4 7.6 7.7 nt-tools extra_tests Nothing more, nothing less. Commits on those branches are linear, but backports or forward ports/merges can be done directly and hence are visible when viewed in gitk (unless you use --first-parent which strips all the merge/porting links). A nice linear sequence of commits on each version branch keeps things simple. We've been working that way for years now and I haven't seen any real reason to change that. But that shouldn't be a big problem to accomplish just by dictating policy, I guess. i think for us a mixed model makes the most sense. people with write access push into the core branches, but other potential contributers can still be pulled from by a core developer and then pushed from there. Quite. On the central repository new and/or temporary branches should not be created. People can do that on their own repos as much as they want; temporary branches on the central repo should be the exception rather than the rule. Zino has good points that svn fits better on the server: It's more mature, more mature in what sense? if everyone uses git on the client side then the maturity of svn on the server does not muy anything because you still have to deal with git. it only adds hassle which wouldn't exist otherwise. Same question. More mature in which way? Git is maturing at an amazing rate (codebase wise), most open source projects either start with git or move from CVS or SVN to git these days. it's closer to cvs so that the server tools around it don't need much change, the largest change should be in the fact that the rcs files are not accessible anymore but have to be replaced with calls to the svn module. at the same time calls to git can be added. Indeed, for every CVS/SVN command, there is an equivalent git command. So rewriting the tools to SVN or git is just as much effort. and it's afterall built with that sharing model in mind. it has been built with a this is all we know, so this is all you get mindset. git is being built with a there are many ways to do it, and we want to support all of them mindset. I dare say that most deployments of Git use the central repository model (like CVS/SVN). It's just that Linux development uses the more purely distributed model due to its sheer size and depth of the project. Maybe a good way to accomplish both ends is to use the bidirectional git-svn bridge? Afaict it's made for the case when the primary repo is in svn. It advices against doing git-style heavily branched development, which is good on the server side (see above). And using svn for storage allows properties, which git lacks. I will play around a bit with git-svn. Which properties are you missing (git has properties, like file modes, BTW)? git-svn is the most featureful dcvs-svn bridge i came accross (only bzr might be a bit better, but it is less mature), but it has it's Having SVN as a central repository would work, of course, but it would be inconvenient at best, because SVN is not as good with merges (both the actual process, as well as recording the merge history). Also, a rather large drawback (I think) for SVN is that it is immutable. Case in point: if someone (by mistake) checks in a large 50MB Yahoo-UI binary blob, then this blob will be part of the SVN repository forever and cannot easily be removed. The only thing you can do is painstakingly dump the whole repository, filter out the bad
Re: Git
Same question. More mature in which way? Git is maturing at an amazing rate (codebase wise), most open source projects either start with git or move from CVS or SVN to git these days. [citation needed] :-) What statistical material do you base this on?
Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: Same question. More mature in which way? Git is maturing at an amazing rate (codebase wise), most open source projects either start with git or move from CVS or SVN to git these days. [citation needed] :-) What statistical material do you base this on? FWIW, the Debian popularity contest shows: http://people.debian.org/~igloo/popcon-graphs/index.php?packages=darcs%2Cgit-core%2Cmercurial%2C+subversion%2C+bzr%2C+cvsshow_vote=onwant_percent=onwant_legend=onfrom_date=2003-10-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1 that: - The percentage of people picking svn nowadays is roughly constant (after a sharp drop as git came along). - The percentage of people picking git is rising steadily. - The percentage of people picking CVS is dropping steadily. - The other VCSes play not role of significance. At this rate, git will overtake SVN in percentage by the end of 2009 (provided the rate doesn't accelerate more). If you view the charts without the percentage view, you get absolute numbers, which is difficult to interpret, since the number of voters constantly rises over time. I'm not saying that this graph says everything, but I do know that the rate of development of git is an order of magnitude larger than that of any of the other VCSes. If anyone needs pointers with regard which cvs sequences substitute with which git commands/sequences, let us know. Incidentally there are several packages out there (some rough, some polished) that give you more traditional interfaces to git. In any case, if you want to appreciate the day-to-day capabilities of git, you should learn what the index/staging area means and how it works. -- Sincerely, Stephen R. van den Berg. People who think they know everything are annoying to those of us who do.
Re: Git
On Tue, Jul 29, 2008 at 02:58:01PM +0200, Stephen R. van den Berg wrote: - The percentage of people picking svn nowadays is roughly constant (after a sharp drop as git came along). that drop is actually in all packages, so i think it is just a case of changing the counting In any case, if you want to appreciate the day-to-day capabilities of git, you should learn what the index/staging area means and how it works. git add -p my favourite command! greetings, martin.
Re: Git
- Original Message From: Stephen R. van den Berg [EMAIL PROTECTED] To: pike-devel@lists.lysator.liu.se Sent: Tuesday, July 29, 2008 8:58:01 AM Subject: Re: Git Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: Same question. More mature in which way? Git is maturing at an amazing rate (codebase wise), most open source projects either start with git or move from CVS or SVN to git these days. [citation needed] :-) What statistical material do you base this on? FWIW, the Debian popularity contest shows: http://people.debian.org/~igloo/popcon-graphs/index.php?packages=darcs%2Cgit-core%2Cmercurial%2C+subversion%2C+bzr%2C+cvsshow_vote=onwant_percent=onwant_legend=onfrom_date=2003-10-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1 that: - The percentage of people picking svn nowadays is roughly constant (after a sharp drop as git came along). - The percentage of people picking git is rising steadily. - The percentage of people picking CVS is dropping steadily. - The other VCSes play not role of significance. -- Sorry to throw in my 2 cents, but... Given that the poll is only debian (I use fedora, and lots of people don't use debian based distributions), also that it is only getting people who actually use the poll, and probably a bunch of other caveats. I probably wouldn't count on those types of polls to have any kind of statistical significance.
Re: Git
Well, the user base of the tools doesn't necessarily reflect the distribution of repository types among projects. There only has to be one project which many are interrested in (say, the Linux kernel, a project which would be of special interrest to users of a Linux distibution such as Debian) using a specific tool for people (and this includes also those who are not activeley participating in the development of the project) to install the client tool. It doesn't mean that they use that tool for their own projects (if any). I, for one, have CVS, svn, git, darcs and brz installed, and a popularity context would have no way of knowing which I use for starting new projects, or moving existing projects to. Even if we were to infer that the relative number of repositories is changing in favour of git, I don't see how you can draw the conclusion that _most_ projects start with git or move to git. If we were to draw any conclusion from this graph it would be that _most_ projects are shutting down their repositories completely, since the number of users who have any VCS at all has decreased from =45% to =20% (the exact figure depends on the overlap caused by people haveing more than one installed), meaning that the number of VCS installations (and by your logic the number of open-source projects) has been cut in half. So _most_ the projects (50%) must have been discontinued?
Re: Git
Lance Dillon wrote: Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: Same question. More mature in which way? Git is maturing at an amazing rate (codebase wise), most open source projects either start with git or move from CVS or SVN to git these days. [citation needed] :-) What statistical material do you base this on? FWIW, the Debian popularity contest shows: Given that the poll is only debian (I use fedora, and lots of people don't use debian based distributions), also that it is only getting people who actually use the poll, and probably a bunch of other caveats. I probably wouldn't count on those types of polls to have any kind of statistical significance. Like any statistic, you're free to (mis)interpret it any which way you want. If you have others, I'd love to have a peek. In any case, I don't base my response on just this statistic. It's also based on the general impression I have from all the developers I'm in contact with (both in real life, as well as direct friends, as well as developer's mailinglists); but since that boils down to a sort of gut feeling, that is even more vague than the debian popularity contest (which I never vote for myself, BTW). -- Sincerely, Stephen R. van den Berg. People who think they know everything are annoying to those of us who do.
Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: Well, the user base of the tools doesn't necessarily reflect the distribution of repository types among projects. There only has to be Very true. The statistic shown is just that, a statistic, and since I don't have any others, that's all I can show. I know it's just as bad as most other statistics; the other information I have is even more vague than this silly graph. that _most_ projects start with git or move to git. If we were to draw any conclusion from this graph it would be that _most_ projects are shutting down their repositories completely, since the number of users who have any VCS at all has decreased from =45% to =20% (the exact figure depends on the overlap caused by people haveing more than one installed), meaning that the number of VCS installations (and by your logic the number of open-source projects) has been cut in half. So _most_ the projects (50%) must have been discontinued? Well, like I said, don't overweight this graph... But since you are starting to pick it apart, we might as well do it properly... What it probably means, is that the number of people installing Debian are increasingly non-developers. I.e. the growth rate of Debian installs is higher than the growth rate of the number of developers amongst them. This would be expected, not everyone has a need to use VCS systems. -- Sincerely, Stephen R. van den Berg. People who think they know everything are annoying to those of us who do.
Re: Git
The statistic shown is just that, a statistic, and since I don't have any others, that's all I can show. I know it's just as bad as most other statistics; the other information I have is even more vague than this silly graph. Fair enough. I was hoping for something more substantial since you were able to quantify your claim, but I guess that was just a case of accidental wording. The part I have a hard time believing is that most existing projects are switching to git. Even if a lot of projects are, there are tons of open source projects. sourceforge alone contains 290808 projects, and they don't provide git repositories (only CVS and svn). Well, like I said, don't overweight this graph... But since you are starting to pick it apart, we might as well do it properly... What it probably means, is that the number of people installing Debian are increasingly non-developers. Yup. This is a hypotheses which the graph _does_ give support to at least. :-) Or possibly that there are now more non-developers using popularity contest. (Didn't they change so that it always asks during installation now, instead of you having to enable it manually?)
Re: Git
i think yes, and i think also ubuntu added it probably in april last year (which would explain the sudden drop around that time) greetings, martin.
Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: accidental wording. The part I have a hard time believing is that most existing projects are switching to git. Even if a lot of projects are, there are tons of open source projects. sourceforge alone contains 290808 projects, and they don't provide git repositories (only CVS and svn). True. What I probably mean by most open source projects, is that of the people that I know from the Open Source community which have been around since at least 1994, the majority speaks highly of git and is moving all their projects into it or will do so in a short while. You're completely right that in sheer numbers, that doesn't account for most open source projects. But it's the projects I care about, and they are the people who's opinion I value, hence the somewhat rapid and probably biased conclusion (I guess I consider them trendsetters, and the rest of the projects trendfollowers). E.g. most GNU projects use git as their master repositories these days. Yup. This is a hypotheses which the graph _does_ give support to at least. :-) Or possibly that there are now more non-developers using popularity contest. (Didn't they change so that it always asks during installation now, instead of you having to enable it manually?) I think yes. But I rarely perform raw installations these days, I simply copy a similar system, and then remove/add packages to taste. -- Sincerely, Stephen R. van den Berg. People who think they know everything are annoying to those of us who do.
Re: Git
E.g. most GNU projects use git as their master repositories these days. Is there some statistics on e.g. Savannah to support this?
Re: Git
I pulled up the list of official GNU projects on Savannah (349 projects), and manually checked the first 25. CVS: 18 Git: 1 Both CVS and Git: 3 Both CVS and Svn: 1 No repository at savannah: 2 Still looks like CVS is in majority to me.
Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: E.g. most GNU projects use git as their master repositories these days. Is there some statistics on e.g. Savannah to support this? Well, same thing here, in this case when I say most, I actually mean that I was looking at the page that lists the git projects, and most of the core GNU tools I still remember from long ago were on it. Look here to see what they moved to git: http://git.savannah.gnu.org/gitweb/ -- Sincerely, Stephen R. van den Berg. People who think they know everything are annoying to those of us who do.
Re: Git
I also checked the latest 5 created official GNU projects: CVS: 1 Both CVS and Mercurial: 1 Both CVS and Subversion: 2 Both CVS and git: 1 A closer race, but only one for git and two for svn... :-)
Re: Git
Am I the only one who thinks this discussion really belongs elsewhere? Pros and cons about various VC systems as well as tutorials about their command-line flags feels very off-topic to me.
Re: Git
Well, we can of course make the repository switch without prior discussion. In that case I suppose we'd go a head with the (now several years old) plan to switch to svn.
Re: Git
Well, same thing here, in this case when I say most, I actually mean that I was looking at the page that lists the git projects, and most of the core GNU tools I still remember from long ago were on it. Ok, so you actually mean that most of the projects that use git are GNU projects? Looking at a page that lists git projects you are of course going to see 100% git. :-)
Re: Git
Indeed.
Re: Git
Well, when facts which turn out to be unsubstantiated are brought here, it seems appropriate to scrutinize them, no?
Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: Well, we can of course make the repository switch without prior discussion. In that case I suppose we'd go a head with the (now several years old) plan to switch to svn. Switching to SVN is always better than continuing to use CVS. The point just is that Git does everything SVN does already, but adds more at no additional cost. So why settle for less? -- Sincerely, Stephen R. van den Berg. People who think they know everything are annoying to those of us who do.
Re: Git
I see that the maintainer of diffutils is extra influential on you, since you list his/her project twice. :-)
Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: I see that the maintainer of diffutils is extra influential on you, since you list his/her project twice. :-) Must be a woman then :-). Sorry, didn't notice that mistake until after sending. -- Sincerely, Stephen R. van den Berg. People who think they know everything are annoying to those of us who do.
Re: Git
What? Last time I checked it did not have any version controlled meta data handling at all.
Re: Git
more mature in what sense? if everyone uses git on the client side then the maturity of svn on the server does not muy anything because you still have to deal with git. it only adds hassle which wouldn't exist otherwise. Same question. More mature in which way? Git is maturing at an amazing rate (codebase wise), most open source projects either start with git or move from CVS or SVN to git these days. We're clearly getting into a hand-waving area here. I don't have any solid evidence where either git or svn might cause integration problems or breakage. I'd have to implement pelix-NG with both tools to provide that. But it is as you say: It is maturing very fast, hence it's not mature yet. I found several new and semi-essential features just by moving from the latest Ubuntu package to the latest upstream release. I think it's reasonable to say that a lot more is changing, and some of it at deeper levels, in git right now than in svn. That means both that there's still a need for such changes, and that the changes increase the risk for bugs. Anyway, arguments like that are a bit FUDish. To get to an earthlier level it's probably required to look in more detail how the server setup would be in either case, which tools around the repo would be used, how much work there is to fix it, and how willing people are to do that. Personally I don't have much to contribute to that debate. Indeed, for every CVS/SVN command, there is an equivalent git command. /.../ You can't honestly believe it's that simple. The commands are different, the output is different, many core concepts are different, there are subtle semantic differences in the kind of data you put into the commands and get back. Which properties are you missing (git has properties, like file modes, BTW)? The eol handling property is nice when the same file is edited from both unix and windows. Content type is also good to allow better diffing, annotation and merging. (In svn it's currently only used to tell text and binary files apart, basically. But the possibility for more content-specific plugins exist. A fully structural diff/blame/merge for xml files would be quite neat, for instance.) In-file expansion of $Id$ stuff can be controlled with them too. Which, btw, is something I haven't found in git. Putting the commit hash inside the file would invariably change it, so that's not possible. I guess the best one could do is to expand it with a timestamp and the closest tag, but even so it'd be a useful feature. Git gives you tools to actually fix that with a small price to pay: anyone who already synced from that branch, will have to rebase, but other than that, there is no downtime, no complicated dump-editing; it's all less-filling and easy to use. I wouldn't call that price small, though. It's good that the possibility exists, but it should be used only in extraordinary cases. Another detail in the comparison is that windows support for svn is infinitely better. Not that windows is a very important platform for us, but we are afterall attempting to change that a bit. Btw, git-svn choked on the pike svn repo. I let it run through the night and it had only gotten to 0.7 by the morning, and each imported commit and tagging was becoming slower and slower. Something there isn't scaling properly. Haven't dug into it very much, though.
Re: Git
On Tue, Jul 29, 2008 at 05:15:02PM +, Martin Stjernholm, Roxen IS @ Pike developers forum wrote: But it is as you say: It is maturing very fast, hence it's not mature yet. I found several new and semi-essential features just by moving from the latest Ubuntu package to the latest upstream release. yes, that's true i also keep discovering new features in new releases that i don't want to live without once i know them just out of curiosity which features are those for you? (also what was the annoyance that caused you to get the git source to fix it?) The eol handling property is nice when the same file is edited from both unix and windows. i believe there is something for eol handling in git, check the hooks. In-file expansion of $Id$ stuff can be controlled with them too. there is an approximation for this, i believe it works by adding the id at checkout, and removing it at checkin. again, see the hooks anyone who already synced from that branch, will have to rebase I wouldn't call that price small, though. smaller than the svn price. Btw, git-svn choked on the pike svn repo. hmm, i think i managed to get through it ayear ago. did you access the repo locally? i set up a copy of the repo on my machine to do the import. greetings, martin.
Re: Git
i was including the price to actually implement the change in the repo. dump, edit, reload is way more expensive than fixing a comit and rebasing. greetings, martin.
Re: Git
Yes, but what was being talked about now was what people who had the repository checked out had to do. The cost to implement the change in the repo only has to be paid once, the cost to rebase needs to be paid for each checked out tree.
Re: Git
just out of curiosity which features are those for you? More subcommands to git-stash so that stashes actually get useful: Earlier the only option was to clear all of them or nothing, which means that one could only use them to very temporary things. Now I've got 12 stashes with assorted small hacks in them. For small things I think they're better than branches because you can give them longer descriptions and they don't clutter up the view in gitk. There were some other odds and ends too which I don't quite remember. (also what was the annoyance that caused you to get the git source to fix it?) I haven't actually fixed anything yet. I pulled down the source to make me newer ubuntu packages. I took a look at fixing so that the pager isn't used for short output though; it's annoying that git status has started to use the pager too all the time. Overall I mostly miss more configurability: Ways to set default arguments to various commands, better control over the blame line format. I also miss a counterpart to the -l option to cvs diff. i believe there is something for eol handling in git, check the hooks. They don't help for associating specific behaviors with specific files. there is an approximation for this, i believe it works by adding the id at checkout, and removing it at checkin. again, see the hooks Ok. That'd be nice to have by default. Would require properties or something like them, though. Btw, git-svn choked on the pike svn repo. hmm, i think i managed to get through it ayear ago. did you access the repo locally? i set up a copy of the repo on my machine to do the import. No, over the net. Do you think the network traffic increases with each imported commit? That'd be even worse. My theory is that git-svn doesn't use a good indexed storage to map between hashes and svn revisions, or something like that.
Re: Git
On Tue, Jul 29, 2008 at 05:50:02PM +, Martin Stjernholm, Roxen IS @ Pike developers forum wrote: More subcommands to git-stash so that stashes actually get useful: Earlier the only option was to clear all of them or nothing, which means that one could only use them to very temporary things. Now I've got 12 stashes with assorted small hacks in them. For small things I think they're better than branches because you can give them longer descriptions and they don't clutter up the view in gitk. hmm, i actually think they clutter up the gitk view more than a branch, but then, gitk only shows the latest stash, not all of them. I took a look at fixing so that the pager isn't used for short output though; it's annoying that git status has started to use the pager too all the time. oh, doesn't happen for me. No, over the net. Do you think the network traffic increases with each imported commit? no, come to think of it, i probably had to restart git-svn a few times. i did here at work where importing a repo over the (local) network took 10 days. greetings, martin. -- cooperative communication with sTeam - caudium, pike, roxen and unix offering: programming, training and administration - anywhere in the world -- pike programmer working in china community.gotpike.org unix system- iaeste.(tuwien.ac|or).at open-steam.org administrator caudium.orgis.schon.org Martin Bähr http://www.iaeste.or.at/~mbaehr/
Re: Git
Since the discussion is for/prior to switching repository, I actually do think it belongs in the developers forum... :p It's a bit TLDR though, can we have an executive summary when you're done?
Re: Git
Peter Bortas @ Pike developers forum wrote: What? Last time I checked it did not have any version controlled meta data handling at all. True. Personally I don't miss it, keeping the metadata accurate usually was more of a hassle than a feature to me (in SVN). I tended to create rules to autotag based on content or name of the file. Once you do that it is just as easy to actually use the rules on the fly, without ever storing the attributes. Another note of interest (not necessarily my view, but interesting enough to read, I'd think) with respect to metadata is: http://plasmasturm.org/log/487/ -- Sincerely, Stephen R. van den Berg. People who think they know everything are annoying to those of us who do.
Re: Git
Another note of interest (not necessarily my view, but interesting enough to read, I'd think) with respect to metadata is: http://plasmasturm.org/log/487/ He's got a point that it's a good concept to track content without regard to the file that contains it, but that applies only to metadata for file identity. At least content type is inherently file bound and is best expressed as a property.
Re: Git
Martin Stjernholm, Roxen IS @ Pike developers forum wrote: make me newer ubuntu packages. I took a look at fixing so that the pager isn't used for short output though; it's annoying that git status has started to use the pager too all the time. Try: LESS=-inqMSFXx4 in your environment (or a suitable subset), it solves that problem. Overall I mostly miss more configurability: Ways to set default arguments to various commands, Checkout man git-config (if you haven't already), and man gitattributes. better control over the blame line format. I also miss a counterpart to the -l option to cvs diff. git diff . (Note the trailing dot). will limit the diff to the current directory and subdirs. It's not quite the same as -l because it *does* recurse. i believe there is something for eol handling in git, check the hooks. They don't help for associating specific behaviors with specific files. man gitattributes, crlf attribute. there is an approximation for this, i believe it works by adding the id at checkout, and removing it at checkin. again, see the hooks Ok. That'd be nice to have by default. Would require properties or something like them, though. man gitattributes, ident attribute. Btw, git-svn choked on the pike svn repo. hmm, i think i managed to get through it ayear ago. did you access the repo locally? i set up a copy of the repo on my machine to do the import. No, over the net. Do you think the network traffic increases with each imported commit? That'd be even worse. My theory is that git-svn doesn't use a good indexed storage to map between hashes and svn revisions, or something like that. git-svn keeps a lot of state in memory, maybe even has memory leaks, don't know for sure. What helps, everytime, is simply killing and restarting git-svn. Git-svn is *very* good at restarting and picking up right where it left off. -- Sincerely, Stephen R. van den Berg. People who think they know everything are annoying to those of us who do.
Re: Git
Peter Bortas @ Pike developers forum wrote: What? Last time I checked it did not have any version controlled meta data handling at all. Well, then it must be christmas :-)... man gitattributes reveals version controlled data handling (version controlled, because it is easily managed inside a .gitattributes file which can be put in every subdir(tree) you'd like). You can actually chose to have them version controlled or not, i.e. they can go into .git/info/attributes or they can go into .gitattributes files that are placed inside the repository. -- Sincerely, Stephen R. van den Berg. People who think they know everything are annoying to those of us who do.
Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: Yes, but what was being talked about now was what people who had the repository checked out had to do. The cost to implement the change in the repo only has to be paid once, the cost to rebase needs to be paid for each checked out tree. Not quite. What I said was: Git gives you tools to actually fix that with a small price to pay: anyone who already synced from that branch, will have to rebase, but other than that, there is no downtime, no complicated dump-editing; it's all less-filling and easy to use. In git you can fix a commit, even if you notice the mistake an hour after checking things in. You can fix it without dumping/restoring the repository. The only problem would be people that already commited new commits on top of your commit, those commits get new hashes and need to be rebased. -- Sincerely, Stephen R. van den Berg. People who think they know everything are annoying to those of us who do.
Re: Git
That IS an improvement.
Re: Git
Try: LESS=-inqMSFXx4 in your environment (or a suitable subset), it solves that problem. More precisely, -F is the relevant flag. Unfortunately it doesn't work with -c. I've bug reported that. Still I think I'd prefer to configure git status to not use the pager at all. It's not quite the same as -l because it *does* recurse. Yep, that's the problem. man gitattributes, crlf attribute. Thanks for the tip about attributes. The svn solution for it, where the properties are directly associated with the files themselves, is still more elegant imo. Anyway, .gitattributes files are not any worse than things like .cvsignore. It's workable. man gitattributes, ident attribute. Ok, good. I think this should be turned on by default in the git repo so that all those $Id$ get back in business again. git-svn keeps a lot of state in memory, maybe even has memory leaks, don't know for sure. What helps, everytime, is simply killing and restarting git-svn. Git-svn is *very* good at restarting and picking up right where it left off. Tried that, didn't help the speed at all. It also gc'd by itself every once in a while, and doing an extra gc didn't improve things either.
Re: Git
Martin Stjernholm, Roxen IS @ Pike developers forum wrote: Same question. More mature in which way? Git is maturing at an amazing rate (codebase wise), most open source projects either start with git or move from CVS or SVN to git these days. But it is as you say: It is maturing very fast, hence it's not mature yet. I found several new and semi-essential features just by moving from the latest Ubuntu package to the latest upstream release. Please keep in mind that many, if not all, of those initially missing features are things which never existed before in any VCS. So it's not really fair to compare that to e.g. SVN where some of those features are simply not viable. Maturity does not have a lot to do with number of features. I has a lot to do with having those features for a long time to the point where no new features are added and stability has been achived. CVS is mature and stable. SVN is mature and fairly stable. git is not mature and not stable.
Re: Git
On Mon, Jul 28, 2008 at 01:40:03PM +, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: chiyo:/tmp/pike% git log --full-diff -M -C --until=1999-02-01 src/modules/_math commit abca4daf0d9e7fd4965f63e5dc45c3173cc74230 Merge: ab24694... c35e2fe... Ok, but what was actually changed in this commit? you hit a merge commit, for those the diff display is usually supressed, you can get it with git show abca4daf0d9e7fd4965f63e5dc45c3173cc74230 not sure why there is only one result. chiyo:/tmp/pike% git log --full-diff -M -C --until=1998-12-20 src/modules/math fatal: ambiguous argument 'src/modules/math': unknown revision or path not in the working tree. Use '--' to separate paths from revisions So how do I specify a repository path rather than a working tree path then? as the message says, use --: git log --full-diff -M -C --until=1998-12-20 -- src/modules/math greetings, martin.
Re: Git
you hit a merge commit, for those the diff display is usually supressed, you can get it with git show abca4daf0d9e7fd4965f63e5dc45c3173cc74230 I assume ++ in the diffs mean added with history? How do I see where it is added from? The --- side is shown as /dev/null. Also, that it should list this commit at all is strange, because the commit merged some fixes from 0.6 by hubbe on 1999-01-01 did not touch the math module at all. It modified the following files: NT/tools/lib.pike NT/tools/rntcc NT/tools/sprshd NT/init_nt src/modules/Perl/configure.in src/modules/files/efuns.c src/modules/files/file.c src/modules/spider/xml.c src/configure.in src/fdlib.c Is this a result of misinterpreting the first CVS commit after the split as the split itself? I think this should be fixed. I have a list of good dates to insert synthetic commits for all the splits. as the message says, use --: git log --full-diff -M -C --until=1998-12-20 -- src/modules/math Ok, that works. And if I omit the --until, it stops on the same commit as when I log _math (but from the other direction, so to speak), which kind of makes sense. But I still can't get log or show to actually display the rename as such. Blame output seems ok for src/modules/_math/math.c at least.
Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: Is this a result of misinterpreting the first CVS commit after the split as the split itself? I think this should be fixed. I have a list of good dates to insert synthetic commits for all the splits. What is the point of inserting synthetic commits for the splits? I.e. it's not clear to me if it solves anything. -- Sincerely, Stephen R. van den Berg. Even if man could understand women, he still wouldn't believe it.
Re: Git
Martin Stjernholm, Roxen IS @ Pike developers forum wrote: Does the current export at srb's server correctly represent the 7.4/7.5/7.6/etc branches? I haven't been able to go back to e.g. the 7.6/7.7 split. Thought it would be possible using gitk. That already is correct. The branches are: 0.5 0.6 7.0 7.2 7.4 7.6 7.7 extra_tests nt-tools There are tags for other old branches that never lived as separate branches, e.g.: v0 ulpc.old ulpc 0.7 7.1 7.3 7.5 I.e. git log 7.5 shows the commit exactly prior to the 7.6/7.7 split. I guess a good start for a git export would be your svn export where you've sorted all that out. Just using git instead wouldn't magically make all those issues dissappear, would it? I have used the blessed SVN export as a base, but it still contained numerous errors which I had to fix (some missing files, CR/LF mistakes *including* in binary files). At the moment I consider the git repo to be more accurate than the SVN export. I will do an automated backcheck with *all* CVS checkouts though, and find (and fix) all remaining differences. Btw, I still haven't been able to get a good overview of the branches and how they connect to each other. Is there a view for that in gitk? (Or some other tool?) gitk --all or gitk 0.5 0.6 7.0 7.2 7.4 7.6 7.7 nt-tools extra_tests (provided that you created local branches for all origin/... remotes). should go a long way. However, for a more complete view, you need the rsynced version of my git repo; since it contains the majority of the backports as merges. Nevertheless, the git://git.cuci.nl/pike repository contains a lot of backports and all branches in full correctly. -- Sincerely, Stephen R. van den Berg. Even if man could understand women, he still wouldn't believe it.
Re: Git
git branch -a --contains origin/HEAD which branches origin/HEAD is contained in. that means those branches are the same or newer than origin/HEAD from there you can investigate further. i usually just look at gitk to see the branch relationship. greetings, martin.
Re: Git
The splits contain changes to the repository (renames and deletes) which are not CVS commits but done directly in the cvsroot. So if you check out 7.2 and 7.3 from immediately after the 7.1 split, they will differ (7.2 will contain lib/modules/String.pmod, but 7.3 will contain lib/modules/_String.pmod instead).
Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: I think that, depending on how the git import script works, some issues might actually disappear magically. But there are others that won't. For example the fact that split points are not associated with a CVS commit, so you have to fake one (something that the current git import apparently doesn't). I have specifically and manually removed the fake split commits after importing from SVN, because they didn't add information AFAICS. Why would you want them in the repository? Importing from the svn export should work, I expect it's mainly a question of defining how repository paths should be mapped to git branches. (Are git branch names version controlled? In the svn export the main development branch is renamed 0.5-0.6-0.7-7.0-7.1-7.3-7.5-7.7 at apropriate times.) Git branches can be demoted to tags at the flip of a switch at anytime, and that probably is what we should be doing. I.e. in git, after the 7.8/7.9 split, I'll be changing the 7.7 branch to become a tag, and then copy that tag into 2 branches, 7.8 and 7.9. Whereas master is then pointing to 7.9, but that is just convention in git, and doesn't have a lot of realworld implications. -- Sincerely, Stephen R. van den Berg. Even if man could understand women, he still wouldn't believe it.
Re: Git
I have used the blessed SVN export as a base, but it still contained numerous errors which I had to fix (some missing files, CR/LF mistakes *including* in binary files). It would be nice if you could report any such errors you find. Which missing files, for example? CR/LF mistakes might be due to the lack of a svn:eol-style (or svn:content-type, int the case of binaries) property. All files are stored as BLOBs in the repository, but can get CR/LF converted upon checkout. Please indicate the files and I'll add the properties.
Re: Git
It is possible to generate some kind of tree without resorting to GTK applications?
Re: Git
On Mon, Jul 28, 2008 at 03:00:03PM +, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: For example the fact that split points are not associated with a CVS commit, so you have to fake one (something that the current git import apparently doesn't). because git doesn't need it. only svn makes a commit for the split. in git the split is represented by the fact that a parent commit has two children. the parent is before the split, and the two children are after. what extra information would a split commit give you? the exact time when you decided to make the split? how is that relevant? for git, a split does not become relevent until you actually make a commit to the new branch, as such the split time is the time when the second child is created, until then the history is linear, and no split actually occured before that point, regardless of when you made the decision to split. (Are git branch names version controlled? In the svn export the main development branch is renamed 0.5-0.6-0.7-7.0-7.1-7.3-7.5-7.7 at apropriate times.) git branches are simple references. just like symlinks, that point to the head of the branch. there is a reflog for each branch (if activated) which shows where a branch-head has been pointing to at previous times. but that information is purely local and won't be reproduced when someone clones the repo. so when you get the repo you do not get any branch name history, only the current state. there is also nothing that tells you which branch a given commit used to be part of, there are only ways to show which branch a commit is part of at this moment (git branch --contains commit) greetings, martin.
Re: Git
I have specifically and manually removed the fake split commits after importing from SVN, because they didn't add information AFAICS. Why would you want them in the repository? They add the information about when the changes to the repository done at the split were made. In the current git repository, those changes seem to be erroneously reported as part of a completely unrelated commit several days later. (The exact date isn't all that important, but I don't want totally unrelated changes grouped together as a single commit.) Git branches can be demoted to tags at the flip of a switch at anytime, and that probably is what we should be doing. I.e. in git, after the 7.8/7.9 split, I'll be changing the 7.7 branch to become a tag, and then copy that tag into 2 branches, 7.8 and 7.9. Whereas master is then pointing to 7.9, but that is just convention in git, and doesn't have a lot of realworld implications. Well, that makes sense I guess. Btw, what is the difference (implied by the convention) between master and HEAD?
Re: Git
gitk is tcl/tk you can get an ascii tree using git log --graph, everything else would involve graphics of some kind. greetings, martin.
Re: Git
for git, a split does not become relevent until you actually make a commit to the new branch, Or when you change one of the destination repositories by other means that making a commit. Which is what has happened at the split points.
Re: Git
Thank you, that helped. Is there some way to collapse the view so that only branches and their splits and merges are shown?
Re: Git
you can get an ascii tree using git log --graph, I meant of the relationsships between all the branches. Wouldn't that be git branch rather than git log? Either way, neither log or branch seemed to recognize the --graph option.
Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: The splits contain changes to the repository (renames and deletes) which are not CVS commits but done directly in the cvsroot. So if you check out 7.2 and 7.3 from immediately after the 7.1 split, they will differ (7.2 will contain lib/modules/String.pmod, but 7.3 will contain lib/modules/_String.pmod instead). I see. Well, I'll look into that, if I find differences, I'll create fake splitcommits. -- Sincerely, Stephen R. van den Berg. Even if man could understand women, he still wouldn't believe it.
Re: Git
On Mon, Jul 28, 2008 at 03:20:04PM +, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: Well, that makes sense I guess. Btw, what is the difference (implied by the convention) between master and HEAD? master is just a default branch name and completely irrelevant if you don't want to use it (i actually think stephen should remove the master branch from the git repo, since it doesn't make much sense for us) HEAD is name for the current active, checked out commit. it is not a branch. if you switch branches, then your HEAD changes. (see git reflog for where HEAD has been) there should not actually be a branch with that name, i wonder what happened here. stephen? greetings, martin.
Re: Git
On Mon, Jul 28, 2008 at 03:25:03PM +, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: you can get an ascii tree using git log --graph, I meant of the relationsships between all the branches. Wouldn't that be git branch rather than git log? sorry, you need of course also here specify that you want to see all branches: git log --abbrev-commit --pretty=oneline --graph --date-order --all is the most convenient way i came up with. Either way, neither log or branch seemed to recognize the --graph option. then your version of git is to old. --graph is a very new addition i believe in 1.5.6 (my version is 1.5.6.1) greetings, martin.
Re: Git
then your version of git is to old. --graph is a very new addition i believe in 1.5.6 (my version is 1.5.6.1) 1.5.4.3. I have an up-to-date Ubuntu Hardy Heron.
Re: Git
such a feature would be really nice indeed, but at the moment it does not exist. i wonder how hard it would be to add it to gitk. greetings, martin.
Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: then your version of git is to old. --graph is a very new addition i believe in 1.5.6 (my version is 1.5.6.1) 1.5.4.3. I have an up-to-date Ubuntu Hardy Heron. Try adding backports. I'm not quite sure where the latest version of git is in ubuntu. In debian it's in testing. Or, use: git clone git://git.kernel.org/pub/scm/git/git.git and make install it from the master branch. -- Sincerely, Stephen R. van den Berg. Even if man could understand women, he still wouldn't believe it.
Re: Git
Try adding backports. I'm not quite sure where the latest version of git is in ubuntu. I have backports already. And intrepid has the same version as hardy.
Re: Git
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: I have used the blessed SVN export as a base, but it still contained numerous errors which I had to fix (some missing files, CR/LF mistakes *including* in binary files). It would be nice if you could report any such errors you find. Which I did make some noise about that in the beginning of my svn/cvs - git odyssee on this list. missing files, for example? I'll have to look it back up in the mailinglist logs, although I didn't mention every missing file; I'll see what I can hand you. CR/LF mistakes might be due to the lack of a svn:eol-style (or svn:content-type, int the case of binaries) property. All files are stored as BLOBs in the repository, but can get CR/LF converted upon checkout. Please indicate the files and I'll add the properties. Well, from memory, please add it to *all* binary files (graphics mostly), and all files which have CR/LF endings because they were created or intended for DOS/Windows. Especially the graphics files (png/gif) were a PITA to correct. -- Sincerely, Stephen R. van den Berg. Even if man could understand women, he still wouldn't believe it.
