* Re: Split a subversion repo into several git repos
From: Jonathan del Strother @ 2007-10-12 14:23 UTC (permalink / raw)
To: Eivind LM; +Cc: Git Mailing List
In-Reply-To: <op.tz28hnd2jwclfx@ichi>
On 12 Oct 2007, at 15:14, Eivind LM wrote:
> On Thu, 11 Oct 2007 23:40:40 +0200, Sam Vilain <sam@vilain.net> wrote:
>
>> Jonathan del Strother wrote:
>>>> For example, I want to convert one subversion repository which
>>>> contains the folders:
>>>> trunk/projectA
>>>> trunk/projectB
>>>>
>>>> into two git repositories:
>>>> projectA.git
>>>> projectB.git
>>>
>>> I have a slightly different layout to you -
>>>
>>> projectA/trunk
>>> projectA/branches
>>> projectA/tags
>>> projectB/trunk
>>> projectB/branches
>>> projectB/tags
>>> etc
>>>
>>> - but I've been creating separate git repos from that with (for
>>> example) :
>>>
>>> git-svn init -t tags -b branches -T trunk http://svn.host.com/projectA
>>> git-svn fetch
>>>
>>>
>>> Or will git-svn not work with your sort of layout?
>>
>> It does work. Use:
>>
>> git-svn init -t projectA/tags -b projectA/branches \
>> -T trunk/projectA http://svn.host.com/
>> git fetch
>
> With my paths this translates into
>
> $ git-svn init -b eivindlm/branches \
> -t eivindlm/tags \
> -T eivindlm/trunk/src/probesimulator \
> file:///svn-repo/
> , which prints the happy message:
> Initialized empty Git repository in .git/
>
> The next command is unfortunately not as happy:
> $ git fetch
> fatal: 'origin': unable to chdir or not a git archive
> fatal: The remote end hung up unexpectedly
> Cannot get the repository state from origin
I believe you actually wanted "git-svn fetch" here
^ permalink raw reply
* Re: Workflow: split repository?
From: Jan Hudec @ 2007-10-12 14:30 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: Git Mailing List
In-Reply-To: <200710121421.39159.wielemak@science.uva.nl>
[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]
On Fri, Oct 12, 2007 at 14:21:39 +0200, Jan Wielemaker wrote:
> Hi,
>
> I've got a big active project, until yesterday managed using CVS. As
> with any distributed academic research project the repository has become
> a nice mess where most files are in the wrong place and there are
> several almost independent sub-projects living in directories.
>
> The plan is/was to
>
> * Convert everything to GIT (done, through cvs2svn)
> * Everyone keeps hacking on their bits, while one is starting
> to reorganise the structure by moving files and directories
> and changing import headers, and other file references in
> a GIT branch.
> * Now we merge the continued work and the reorganisation to
> end up with a nice clean hierarchy :-)
> * Split the big project into multiple projects. One of the
> reasons is that we want to make part of them public. Others
> we cannot publish as they contain copyrighted data. I understand
> we can reunite them using GIT sub modules.
>
> Does this make sense?
It might make more sense to convert bit by bit, to separate git repositories.
Would save you some git-filter-branch work.
> While splitting we want to *loose* history information for some of the
> projects. That is easy: simply create a new repository from the current
> files. For some however we would like to *preserve* the history. This
> means we would like to pick a hierarchy with its history. After quite
> a bit of reading, I get the impression this cannot be done. Am I right?
It can, but you have to be aware of the pitfalls. Git allows you to create
a new history, which is defined modification of the original history. There
is git-filter-branch command, that can create a repository with just
a subtree and such. But it's a new, independent, history. You can't merge
between the old and new one (but you can rebase the few commits someone made
while you were converting) and anyone who has the old history in his repo
will still have it.
> Is the only way to create a GIT repositiory right away from a subset of
> the CVS for which we want to preserve the history?
No, it's not. It will save you work if you can do as much splitting as
possible during the conversion, ie. convert the bits you know will be
separate separately (and combine them using submodules as appropriate).
But if you have bits that will take a lot of work to factor out, you can
convert to git, make the other code ready to use a submodule and than use
git-filter-branch to extract the right bits of history for the submodule.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Eivind LM @ 2007-10-12 14:47 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <1B9700E6-5DFB-443D-9465-30E0DCAD0619@steelskies.com>
On Fri, 12 Oct 2007 16:23:44 +0200, Jonathan del Strother
<maillist@steelskies.com> wrote:
[...]
>>
>> $ git-svn init -b eivindlm/branches \
>> -t eivindlm/tags \
>> -T eivindlm/trunk/src/probesimulator \
>> file:///svn-repo/
>> , which prints the happy message:
>> Initialized empty Git repository in .git/
>>
>> The next command is unfortunately not as happy:
>> $ git fetch
>> fatal: 'origin': unable to chdir or not a git archive
>> fatal: The remote end hung up unexpectedly
>> Cannot get the repository state from origin
>
>
> I believe you actually wanted "git-svn fetch" here
You are right, that solved the problem :)
So both methods work now, apparently giving the same result. Is there a
difference between the fetch- versus the clone-approach? I am doing this
as a once-and-for-all import, and would like to forget everything about
the subversion repository afterwards.
Thanks,
Eivind
^ permalink raw reply
* Re: Workflow: split repository?
From: Jan Wielemaker @ 2007-10-12 14:57 UTC (permalink / raw)
To: Jan Hudec; +Cc: Git Mailing List
In-Reply-To: <20071012143043.GD7865@efreet.light.src>
Hi Jan,
On Friday 12 October 2007 16:30, Jan Hudec wrote:
> On Fri, Oct 12, 2007 at 14:21:39 +0200, Jan Wielemaker wrote:
> > Does this make sense?
>
> It might make more sense to convert bit by bit, to separate git
> repositories. Would save you some git-filter-branch work.
> > Is the only way to create a GIT repositiory right away from a subset of
> > the CVS for which we want to preserve the history?
>
> No, it's not. It will save you work if you can do as much splitting as
> possible during the conversion, ie. convert the bits you know will be
> separate separately (and combine them using submodules as appropriate).
>
> But if you have bits that will take a lot of work to factor out, you can
> convert to git, make the other code ready to use a submodule and than use
> git-filter-branch to extract the right bits of history for the submodule.
Thanks! git-filter-branch looks a bit overwhelming, but I think I can
manage :-) I'll do the simple things in separate conversions.
Cheers --- Jan
^ permalink raw reply
* Re: [PATCH] add simple install replacement
From: Robert Schiele @ 2007-10-12 15:07 UTC (permalink / raw)
To: Jan Hudec; +Cc: git, gitster
In-Reply-To: <20071012140647.GC7865@efreet.light.src>
[-- Attachment #1: Type: text/plain, Size: 2806 bytes --]
On Fri, Oct 12, 2007 at 04:06:47PM +0200, Jan Hudec wrote:
> On Thu, Oct 11, 2007 at 23:52:37 +0200, Robert Schiele wrote:
> > This patch adds a very simple install replacement script to git.
> > This allows more easy installation on systems that don't have a
> > compatible install.
>
> Do you have a particular case where you need it?
We have some machines here where no compatible install was installed. Sure I
could have built GNU coreutils on all of them but writing this script was just
more convenient for me.
> No such thing here:
> zsh$ /bin/sh
> $ which getopts
> $
>
> Yes, bash and zsh do have that, but my (and I suspect many git users')
> /bin/sh is neither of those. Git scripts should use just POSIX shell
> features for portability.
I just used it because the shells on my machines had it. My idea was that if
someone has a shell with less features we could still replace parts with even
more basic ways of doing things.
> You may want to have a look at /usr/share/automake-1.9/install-sh (or
> /usr/share/automake<something>/install-sh). It shows how to portably process
> options in shell and since it's in fact covered by the MIT/X license (and FSF
> changes are public domain), git could just use it if necessary.
Oh, forgot about that implementation. Since this version is definitely more
advanced I retract my patch and propose to use that one instead.
> Are you sure reall install would do this? The maual (install(1)) states
> following usage variants:
>
> install [OPTION]... [-T] SOURCE DEST
> install [OPTION]... SOURCE... DIRECTORY
> install [OPTION]... -t DIRECTORY SOURCE...
> install [OPTION]... -d DIRECTORY...
I did not intend to write a full replacement for install but cover only the
cases needed to install git.
> Now however there is nothing saying that SOURCE... is at least two, so is
>
> install git /usr/bin
>
> a case of the first or second usage? I would say the second, but your code
> would:
>
> rm -rf /usr/bin
> cp git /usr/bin
No, in your example /usr/bin is a directory and thus this is:
rm -rf /usr/bin/git
cp git /usr/bin
> touch "foo*bar" "a b c"
> ./gitinstall "b*c" "a b c" /tmp
>
> ... will copy a lot of files to /tmp (presuming we are in git source
> directory, where tons of files are called builtin-<something>.c) and complain
> that there is no 'a', no 'b' and no 'c'.
There are no files with special characters in git to be installed. Again this
was meant a _simple_ replacement for install on systems without a compatible
install just to install _git_, not to reinvent the wheel.
Robert
--
Robert Schiele
Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: RCS keyword expansion
From: Barry Fishman @ 2007-10-12 17:05 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.62.0710120726470.11771@perkele.intern.softwolves.pp.se>
Peter Karlsson <peter@softwolves.pp.se> writes:
> Yes, but not embedded in the page in a format that is visible to the
> visitor. For CVS I use something like this:
>
> <p class="date">$Date$</p>
>
> to embed the last update time into the page.
>
I guess everyone moving from CVS/SVN to Git faces rethinking of
what the RCS markers really mean in the context of their project.
In my case the identifier was just a away of seeing when the file was
last changed, and who did it. I decided this fit better as an editor
function, rather than a checkin function.
I changed my editor (Emacs) to convert RCS Ids to timestamps when I
opened a file for reading. This would fix old files. When i wrote out
files I would update the timestamp before writing them (via emacs's
timestamp package). I didn't have to think about it as my RCS Id
stamped files slowly evolve into my editor stamped ones. I'm sure I
could do something similar in VIM, or with a script encapsulating
another editor.
This actually worked out better for me. Now the timestamps were updated
even when I hadn't yet checked in the file. Since I test things before
checking them in, I did not have my file changed after testing by the
checkin process.
I could find the the commit assocated with the file fairly quickly using
"git log" and finding the commit for the file just after its timestamp.
--
Barry Fishman
^ permalink raw reply
* Re: git branch performance problem?
From: Salikh Zakirov @ 2007-10-12 17:32 UTC (permalink / raw)
To: hanwen; +Cc: Linus Torvalds, Lars Hjemli, git
Han-Wen Nienhuys wrote:
> For cherrypicking convenience, I would still appreciate it if there
> was a mechanism similar to alternates that would allow me to view
> objects from an alternate repo; objects found through this mechanism
> should never be assumed to be present in the database, of course.
There exist a script contrib/workdir/git-new-workdir,
which creates a new working copy that literally shares the same object store.
It will share both object store and branches, so some care must be taken:
branch which checkout out in one shared working directory must never be
updated
(committed or pulled into) from the other shared working directory.
Said that, I personally find this trick very useful for browsing code
from different branch and quick bug fixing.
^ permalink raw reply
* Re: git branch performance problem?
From: Salikh Zakirov @ 2007-10-12 17:19 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Lars Hjemli, git
In-Reply-To: <f329bf540710101926vedf8b19p52e3eeb193203d03@mail.gmail.com>
Han-Wen Nienhuys wrote:
> For cherrypicking convenience, I would still appreciate it if there
> was a mechanism similar to alternates that would allow me to view
> objects from an alternate repo; objects found through this mechanism
> should never be assumed to be present in the database, of course.
There exist a script contrib/workdir/git-new-workdir,
which creates a new working copy that literally shares the same object store.
It will share both object store and branches, so some care must be taken:
branch which checkout out in one shared working directory must never be updated
(committed or pulled into) from the other shared working directory.
Said that, I personally find this trick very useful for browsing alternate
branch code and quick bug fixing.
^ permalink raw reply
* Re: RCS keyword expansion
From: Linus Torvalds @ 2007-10-12 17:44 UTC (permalink / raw)
To: Barry Fishman; +Cc: git
In-Reply-To: <m3y7e8jmbm.fsf@barry_fishman.acm.org>
On Fri, 12 Oct 2007, Barry Fishman wrote:
>
> I changed my editor (Emacs) to convert RCS Ids to timestamps when I
> opened a file for reading. This would fix old files. When i wrote out
> files I would update the timestamp before writing them (via emacs's
> timestamp package). I didn't have to think about it as my RCS Id
> stamped files slowly evolve into my editor stamped ones. I'm sure I
> could do something similar in VIM, or with a script encapsulating
> another editor.
I think it might also be potentially interesting to make this just be a
pre-commit hook - although your point that doing it in the editor is to
some degree even nicer, because it also means that it shows up in diffs
even *before* you commit.
But if you want to explore the pre-commit hook approach, what it would
basically boild down to is that at that point you have a list of all files
that have changed, and then you could run some script on them to change
them even further.
I'm sure you'd find some problems with the approach, and I think it
absolutely sucks for merging (ie trivially you'll have all the merge
problems people *always* have with RCS Id's, and now you need to teach the
auto-merger to hide them from you), but it's probably better than trying
to do it at some "core level" (which screws up things like switching
branches etc).
Linus
^ permalink raw reply
* Re: RCS keyword expansion
From: Florian Weimer @ 2007-10-12 17:51 UTC (permalink / raw)
To: git
In-Reply-To: <m3y7e8jmbm.fsf@barry_fishman.acm.org>
* Barry Fishman:
> I changed my editor (Emacs) to convert RCS Ids to timestamps when I
> opened a file for reading. This would fix old files. When i wrote out
> files I would update the timestamp before writing them (via emacs's
> timestamp package). I didn't have to think about it as my RCS Id
> stamped files slowly evolve into my editor stamped ones. I'm sure I
> could do something similar in VIM, or with a script encapsulating
> another editor.
The downside is that this causes totally unncessary conflicts when
merging. Maybe a custom merge handler could deal with that, though.
^ permalink raw reply
* Re: RCS keyword expansion
From: Salikh Zakirov @ 2007-10-12 19:08 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.62.0710120723480.11771@perkele.intern.softwolves.pp.se>
Peter Karlsson wrote:
> But that's not what I want. Then my build procedure would need to do a
> "git status", or whatever you use to get the last commit information
> about a file, on each file that is changed and is to be installed. It
> would be a lot easier if that was done already on checkout through some
> kind of hook.
For what it's worth, I've made a small exercise on git scripting
(which I'm total newbie in), and tried to use filter mechanism
(smudge/clean) for solving the problem Peter stated.
Fundamental problems of this approach were discussed in full
on the mailing list, however, as I understand Peter's situation,
they do not apply, as the web site workspace is 'checkout-only',
and no actual work (commits) are made there.
Thus, it will not cause any merge problems etc.
Anyway, smudge/clean does not give the immediate solution to the problem
because of smaller technical shortcomings:
* smudge filter is not passed a name of file being checked out,
so it is not possible to exactly find the commit identifier.
However, this is alleviated by the fact that 'smudge' is only being run
for the changed files, so the last commit *is* the needed one.
* smudge filter is not passed a commit identifier. This is a bit more serious,
as this information is nowhere to get from otherwise. I tried to use 'HEAD'
value, but apparently it is not yet updated at the moment 'smudge' is being
run, so the files end up with the date of the "previous" commit rather than
the commit being checked out. "Previous" means the commit that was checked
out before. The problem gets worse if different branch is checkout out,
as the files get the timestamp of a previous branch.
AFAIR, lack of information in smudge filter was intentional, to discourage
this particular use of smudge/clean mechanism. However, I think this can be
reconsidered given the Peter's use case: "checkout-only" workspace for immediate
publishing to webserver. Alternatively, anyone interested in this use case
could implement additional smudge arguments as a site-local patch.
And then, there are small annoyances, which seems to be inevitable:
* if you change 'clean' filter and check out earlier revision, it will be
reported as having modifications (due to changed 'clean' definition).
Below is what I ended up with:
.gitattributes:
* filter=date
.git/config:
[filter "date"]
smudge = .git/smudge
clean = .git/clean
.git/clean:
#!/usr/bin/perl -p
s#\$Date[^\$]*\$#\$Date\$#;
.git/smudge:
#!/usr/bin/perl
use POSIX qw(strftime);
$branch = `git-symbolic-ref HEAD`; chomp($branch);
$rev = `git-rev-list -n 1 $branch`; chomp($rev);
open REV, "git show --pretty=raw $rev|";
$time = time; # default to current time
while (<REV>) {
if (/^committer.* (\d+) [\-+]\d*$/) {
$time = $1;
}
}
close REV;
$date = strftime "%Y-%m-%d %H:%M:%S", localtime($time);
while (<>) {
s#\$Date[^\$]*\$#\$Date: $date\$#;
print;
}
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Sam Vilain @ 2007-10-12 20:27 UTC (permalink / raw)
To: Eivind LM; +Cc: Jonathan del Strother, git
In-Reply-To: <op.tz28hnd2jwclfx@ichi>
Eivind LM wrote:
>>
>> git-svn init -t projectA/tags -b projectA/branches \
>> -T trunk/projectA http://svn.host.com/
>> git fetch
>
> With my paths this translates into
>
> $ git-svn init -b eivindlm/branches \
> -t eivindlm/tags \
> -T eivindlm/trunk/src/probesimulator \
> file:///svn-repo/
> , which prints the happy message:
> Initialized empty Git repository in .git/
>
> The next command is unfortunately not as happy:
> $ git fetch
> fatal: 'origin': unable to chdir or not a git archive
> fatal: The remote end hung up unexpectedly
> Cannot get the repository state from origin
>
> I suppose this is due to my silly svn-repo layout... However, after
> some trial and error it seems like the following command gives me what
> I want (I don't need tags or other branches than main):
Whoops, my mistake. That should have been "git svn fetch".
Sam.
^ permalink raw reply
* [PATCH] Fix a crash in ls-remote when refspec expands into nothing
From: Alex Riesen @ 2007-10-12 20:40 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Jeff King, Väinö Järvelä, git, Junio C Hamano,
Lars Hjemli
In-Reply-To: <20071012040745.GC27899@spearce.org>
Originally-by: Väinö Järvelä <v@pp.inet.fi>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
remote.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
Shawn O. Pearce, Fri, Oct 12, 2007 06:07:45 +0200:
> I think the above patch is the only thing to do here. Perhaps Alex
> can write up a formal patch and send it to back to the list and CC
> Lars Hjemli <hjemli@gmail.com> so he can put it into the patch queue.
here you go
diff --git a/remote.c b/remote.c
index e7d735b..a25f66d 100644
--- a/remote.c
+++ b/remote.c
@@ -882,7 +882,8 @@ int get_fetch_map(struct ref *remote_refs,
rm->peer_ref->name);
}
- tail_link_ref(ref_map, tail);
+ if (ref_map)
+ tail_link_ref(ref_map, tail);
return 0;
}
--
1.5.3.4.232.ga843
^ permalink raw reply related
* Imports without Tariffs
From: mfwitten @ 2007-10-12 20:36 UTC (permalink / raw)
To: git
[INTRO]
Hello,
I have come across a problem that could be easily addressed
in order to improve interoperability between CVS and git.
I'm new to using git (and a novice with SCMs in general),
and I really enjoy the way that git allows me to think.
Unfortunately, I am forced to deal with CVS (for one of
my classes), but I have been courageously trying to use
git behind the scenes, as I can already tell CVS is a
nightmare.
[SCENARIO]
I would like to do the following sequence:
(1) Checkout a CVS repository as a git working tree.
=> git cvsimport -A /path -a -k -v -r cvs -C work module
(2) Edit the git working tree and make commits there.
=> cd work
=> vim ... # emacs can go live with CVS ;-P
=> git commit -a -m ...
(3) Export my git working tree commits back to CVS.
=> cd ..; cvs co modules; cd modules
=> for each pertinent git commit hash, HASH:
GIT_DIR=../work/.git git-cvsexportcommit -vc HASH
(4) Update my git working tree from CVS (at some later time).
=> cd ../work
=> git cvsimport -a -k -v -r cvs -C . module
[PROBLEM]
git-cvsimport creates new hash IDs for the same ol' commits.
Running git-cvsimport does indeed do an incremental update of
the 'cvs' remote in the 'work' git repository.
However, the updates are brought in as brand new git commits
with the CVS dates in the log (though changed to UTC +0000!!).
Therefore, when the updated 'cvs' remote branches are merged into
my local branches, git treats the commits I made with cvsexportcommit
as separate history; thus, history is duplicated and merge commits
appear where they shouldn't.
[PARTIAL SOLUTION]
The trick is to populate the 'cvs' remote branches with commits that
have the right hash IDs.
I thought I could do this by hand.
I updated the cvsexportcommit/cvsimport sequence by pushing
my local branches into their respective 'cvs' remote branches,
before running that last cvsimport:
=> for each pertinent git commit hash, HASH:
GIT_DIR=../work/.git git-cvsexportcommit -vc HASH
=>=>=> git push . refs/heads/master:refs/remotes/cvs/master
=> git cvsimport -a -k -v -r cvs -C . module
Of course, git-cvsimport still adds the commits to the 'cvs'
remote branches, duplicating (log) histories.
The difference is that the 'cvs' remote branches become descendants
of the local branches, causing a fast-forward merge with the local
branches; this removes the split histories, but still duplicates
information in an even dumber way, as changes are undone and then
redone.
[SOLUTION]
The trick is to make both git-cvsimport and the user smarter
---- A TALL ORDER!
To make things simple, I think all of the necessary machinery
should be put into git-cvsimport.
The user should first git-cvsexportcommit as necessary.
Then the user should tell git-cvsimport to push from the pertinent git
branches into the pertinent cvsimport branch. To make things even
simpler,
I think that git-cvsimport should make the -r option mandatory; then
git-cvsimport would simply do the pushing as I did:
git push . refs/heads/<branch1>:refs/remotes/<remote>/<branch2>
Then git-cvsimport would mark for each pushed-into branch the timestamp
for when the push occurred. These marks could be put in some special
file,
say .git/CVSIMPORT.
The next time git-cvsimport is used as normal, it can consult this
file for
timestamps, rather than relying on git log timestamps, to determine
if creat-
ing a new commit is necessary.
[CONCLUSION]
I feel that not much is being put into converting between git and
CVS, which
is unfortunate, because a lot of stuff is in CVS out there; here at
MIT,
*all* CS students have to use CVS for at least one semester of
grueling programming
labs.
If conversion between git and CVS is hard, many students will just
learn
what seems easiest---CVS---and they'll decide to use CVS for their
projects
later on (I've already seen this happen); that's not a future I want
to have!
Sincerely,
Michael Witten
[OTHER PROBLEMS]
(1) git-cvsimport creates log entries with UTC times; maybe that's
correct.
(2) git-cvsimport's -A argument must be a full path.
(3) git-cvsexportcommit should automatically handle contiguous commits.
(4) git-cvsimport is written in the most unmaintainable perl ever!
^ permalink raw reply
* Git User's Survey 2007 summary - comparison with previous survey
From: Jakub Narebski @ 2007-10-12 22:07 UTC (permalink / raw)
To: git
It's been more than a year since last Git User's Survey. It would be
interesting to find what changed since then. Therefore the idea to
have another survey.
This is partial comparison of Git User's Survey 2007,
(ending at state from 28 September 2007) with previous
survey.
The current survey can be found here:
http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9
http://tinyurl.com/26774s
The data for current, 2007 survey can be found here:
The data for previous, 2006 survey was taken from following wiki page
http://git.or.cz/gitwiki/GitSurvey2006
---
There were 683 individual responses in 2007 survey.
There were around 117 responses in 2006 survey.
There are 62 questions in 2007 survey, and 31 questions (half of
the number) in 2006 survey.
About you
~~~~~~~~~
01. What country are you in?
Answer | Old | Count
------------------------------------------------
Algeria | | 1
Argentina | | 3
Australia | 3 | 25
Austria | 2 | 9
Belarus | 1 |
Belgium | | 5
Brazil | 2 | 20
Bulgaria | | 1
Canada | 3 | 44
Chile | 1 | 2
China | 2 | 4
Colombia | | 2
Czech Republic | 2 | 10
Denmark | 4 | 7
Ecuador | | 1
Estonia | 1 | 1
Europe | 1 | 1
Finland | 5 | 23
France | 6 | 36
Germany | 14 | 64
Greece | | 3
Hungary | | 2
India | 1 | 13
Ireland | | 2
Israel | | 6
Italy | 3 | 14
Japan | | 4
Jersey | | 1
Latvia | | 1
Lithuania | 1 |
Malaysia | | 1
Mexico | | 1
Netherlands | 3 | 15
New Zealand | | 5
Norway | 1 | 14
Philippines | 1 | 3
Poland | 3 | 6
Portugal | | 2
Puerto Rico | | 1
Romania | | 1
Russian Federation | 2 | 6
Samoa | | 1
Serbia | | 1
Singapore | | 2
Slovak Republic | | 1
Slovenia | | 2
South Africa | 1 | 4
Spain | 2 | 11
Sri Lanka | | 1
Sweden | 6 | 14
Switzerland | 1 | 15
UAE | 1 |
UK / US | | 1
United Kingdom | 8 | 40
United States of America | 35 | 218
Venezuela | | 1
Vietnam | 1 | 1
------------------------------------------------
Base | | 673 / 683
Total (sum) | 117 | 673
England, Scotland and British Isles counts as United Kingdom here.
Table is sorted in alphabetical order.
As before most Git users are in the USA.
There are quite a bit of new countries, only two vanished. Note that
current survey has much more responses, so it is expected.
02. What is your preferred non-programming language?
This is multiple answers question, although most people
gave only one preferred language.
Answer | Old | Count
------------------------------------------------
Afrikaans | | 1
Belarusian | 1 |
Bulgarian | | 1
Castellano | | 2
Catalan | | 1
Chinese | 1 | 2
Czech | 2 | 10
Danish | 5 | 6
Dutch | 4 | 12
English | 71 | 416
Estonian | 1 |
Finnish | 4 | 16
French | 5 | 33
Galician | | 1
German | 12 | 58
Greek | | 2
Hebrew | | 1
HibernoEnglish | | 1
Hungarian | | 3
Italian | 3 | 9
Japanese | 1 | 1
LSF (French sign language) | | 1
Norwegian | | 4
Polish | 3 | 5
Portuguese | | 10
Romanian | | 1
Russian | 4 | 13
Serbian | | 1
Slovenian | | 2
Spanish | 4 | 13
Swedish | 5 | 13
Swiss | | 1
Ukrainian | | 1
Vietnamese | 1 | 1
invalid (computer language) | ? | 37
not understood | ? | 4
------------------------------------------------
Base | | 662 / 683
Total (sum) | 127 | 683
Most of git users prefer English language, at least for dealing with
computers, the same as before.
In previous survey summary the invalid responses were not enumerated.
The question itself is not well formulated, as one can see from the
number of answers with computer language, and "not understood"
answers. I am not native English speaker, but there were suggestions
to use "natural language" instead of "non-programming language". The
question is formulated the same as in previous survey.
03. How old are you?
04. Which programming languages you are proficient with?
Those are new questions, which were not present in previous survey.
Getting started with GIT
~~~~~~~~~~~~~~~~~~~~~~~~
05. How did you hear about GIT?
This question is present in both current (2007) and previous (2006)
survey. But because it uses free-form answer, and tabularization
(dividing data in categories and generating histogram / counting
occurences) is quite different it is not easy to compare results.
In Git User's Survey 2006 (prevuius survey) the dominant source was
LKML (Linux Kernel Mailing List) with 74 / 115 responses, with LWN
leading the rest with 11 / 115 count.
Although LKML still dominates the table for current survey, it is not
by such a wide margin (109/658 = 17% as compared to 74/115 = 64% in
previous one). Many people heard about git because Linux kernel uses
it; Linus Torvalds presentation (talk) at Google (Google Video and
YouTube) got also high count, bit higher than LWN.
But there was no "I wrote it" response in current survey, though...
06. Did you find GIT easy to learn?
Answer | Old | Count
------------------------------------------------
very easy | 6 | 38
easy | 21 | 136
reasonably | 64 | 318
hard | 23 | 131
very hard | 3 | 33
------------------------------------------------
Base | | 656 / 683
Total (sum) | 117 | 656
Nice gaussian curve both for current survey, and previous year survey
data. Most users find GIT reasonably easy to use.
07. What helped you most in learning to use it?
TO DO. This again is a free-form question, present in both surveys.
For current (2007) survey data is not even tabularized yet, although
(some) of responses got listed (without a count). I don't think
comparison with previous result is any interesting, but previous year
data can provide at least some hint on how to divide answers into
categories.
08. What did you find hardest?
TO DO. Yet another free-form question, present in both surveys.
Tabularized for 2006 survey, listed without count for 2007 survey, as
for previous question.
09. When did you start using git? From which version?
TO DO. Again free-form question. Note that in previous survey this
question consisted only of the first part, and read "When did you
start using git?", so it is date that got tabularized, not git version
(mostly). Analysis of current survey data is unfinished, and only
answers in which there was given git version explicitely got
tabularized. For comparison we would need analysis of answers giving
date; and even then I don't think it would be especially useful,
unless very coarse-grained (which year for example).
Other SCMs
~~~~~~~~~~
10. What other SCMs did/do you use?
11. Why did you choose GIT?
12. Why did you choose other SCMs?
13. What would you require from GIT to enable you to change,
if you use other SCM for your project?
14. Did you import your repository from foreign SCM? What SCM?
15. What tool did you use for import?
16. Do your GIT repository interact with other SCM? Which SCM?
17. What tool did/do you use to interact?
This whole section is new, and was not present in previous survey.
How you use GIT
~~~~~~~~~~~~~~~
18. Do you use GIT for work, unpaid projects, or both?
This question had slightly different wording in 2006 survey:
"How you use GIT? Do you use GIT for ...".
Answer / Purpose | Old | Count
------------------------------------------------
work | 14 | 56
unpaid projects | 50 | 212
both | 53 | 377
------------------------------------------------
Base | | 645 / 683
Total (sum) | 117 | 645
In the previous survey unpaid projects (only unpaid) were slightly
less than half of answers (43 %), while current survey shows that
[only] around a third of git users use it only for unpaid projects.
So we see more git used for work.
19. How do you obtain GIT?
Answer | Old | Count
------------------------------------------------
binary package | 31 | 283
source tarball | 33 | 210
pull from main repository | 53 | 153
------------------------------------------------
Base | | 646 / 683
Total (sum) | 117 | 646
As one can see a year ago pull from main repository dominated, while
now binary package dominates, and pull is least used. At least among
people who answered Git User's Survey; the difference might be caused
by the fact that previous survey was distributed mainly among readers
of git mailing list, who run latest 'master' or even 'next' version,
and often contribute to git (see also question 30, "Does git.git
repository include code produced by you?").
On the other hand the difference might be caused by the fact that more
distributions have got git, or that git is more mature and there is no
need to run development version and/or the fact that x.y.z is now
development version following 'master' and not 'maint', and includes
new features.
20. What hardware platforms do you use GIT on?
This is free-form question, tabularized for both current and previous
survey, but tabularized (slightly) differently. It is not suprising,
as extracting architecture and dividing into categories was doneby two
different people: Paolo Ciarrocchi (if I remember correctly) for 2006
survey, and Jakub Narebski (me) for 2007.
Moreover I guess that the _comparison_ is not very interesting; the
current data is.
Hardware platfrom tables should relly be generated by someone better
versed in computer architecture.
21. What OS (please include the version) do you use GIT on?
This question is also free-form. For 2006 survey there is generic
count, and two tables: for Linux (distribution or kernel), and for
other operating systems. The table for 2007 survey is slightly less
generic than the 2006 count, but there are no OS version tables.
There is much more data, and more data without version number.
Perhaps we should have provided examples of answers to this
question...
Answer | Old | Count
---------------------------------------------
AIX | 1 | 1
FreeBSD | 4 | 16
OpenBSD | - | 3
NetBSD | 1 | -
HP-UX | 1 | 1
IRIX | 1 | -
Linux | 167? | 582
MS Windows (Cygwin) | 14 | 22
MS Windows (other) | | 36
MacOS X / Darwin | 11 | 94
Solaris | 3 | 11
SunOS | - | 5
---------------------------------------------
Note that one person can use git on more than one operating system.
The number for Linux from 2006 survey is taken as total for Linux
table. "MS Windows (other)" means msys (native) version, or
unspecified whether Cygwin or MinGW/MSys. If I remember correctly
there were no native Windows version (which is currently under
development) during previous survey.
Most is Linux, as before. MacOS X is quite a percentage in current
survey, and dominates among non-Linux OS, coming before MS Windows.
22. What projects do you track (or download) using GIT
(or git web interface)?
This question was not present in previous survey.
23. How many people do you collaborate with using GIT?
TO DO. This is free-form question; analysis for current survey is not
done yet. The answer is not always simple number, but even those
answers which are limited to simple number (or contain simple number)
are not done yet.
I have posted question if first post in the thread about what ranges
(what categories) should be used here. I haven't received any answer
yet.
Previous survey have table in two parts: first histogram of simple
number of people, second with names of communities (Cairo, Linux
kernel, U-Boot,...).
24. How big are the repositories that you work on?
TO DO. To be done *both* for 2007 (current) survey, and for 2006 one.
25. How many different projects do you manage using GIT?
This question was not present in previous survey.
Previous survey has empty question in this place, between those
questions.
26. Which porcelains do you use?
27. Which git GUI do you use?
28. Which (main) git web interface do you use for your projects?
The list of porcelains is different for previous and current
survey. Git GUIs were moved to the next question in the 2007 survey,
and web interfaces to second next.
Note that there is some ambiguity concerning git-gui: it was put in
current survey in the GUI question only, while some people consider it
[also] porcelain (and put is as 'other' in porcelain).
Multiple answers (one can use more than one porcelain).
Answer (multiple choice) | Old | Count
----------------------------------------------
core-git | 62 | 558
cogito | 22 | 56
Patch management interface: : 13 : 57
..............................................
StGIT | 11 | 41
Guilt (formerly gq) | n/a | 13
pg (deprecated) | 2 | 3
----------------------------------------------
One has to take into account the fact that neither Cogito nor pg
(Patchy GIT) were deprecated during previous survey. Cogito got
deprecated because all of its functionality got moved in some way to
core git, while Petr 'Pasky' Baudis, main Cogito developer, didn't
have time for catching up to new git features.
Guilt is so new that it just simply was not yet created during
previous survey.
29. How do you publish/propagate your changes?
This question was not present in previous survey.
30. Does git.git repository include code produced by you?
(Previous survey had bad English here: "Is the git.git repository
including codes produced by you?")
Answer | Old | Count
------------------------------------------------
Yes | 73 | 99
No | 34 | 512
------------------------------------------------
Base | | 611 / 683
Total (sum) | 107 | 611
Complete reversion: from most survey participants having their
code in git.git (around 70%) a year ago to around a small amount
(around 16%) currently (!).
This might be cause by the fact that (I think) previous survey was
known mostly to people reading git mailing list, who often send their
own patches to this list. Therefore there it would be nice to have
"How did you heard about this survey?" question. (It would also help
finding where it is worth to send notice if/when we would want to make
another survey.)
Note also the following little fact:
$ git shortlog -s --all --before="01-08-2006" | wc -l
119 (and around 117 individual responses in 2006 survey)
$ git shortlog -s --all --before="01-10-2007" | wc -l
215 (and 683 individual responses in 2007 survey)
So it is simply not possible to have the same percentage of git
developers among git users (or rather git survey participants): 70%
out of 683 users is more than 465, which is more than git.git has
developers.
Internationalization
~~~~~~~~~~~~~~~~~~~~
31. Is translating GIT required for wider adoption?
32. What do you need translated?
33. For what language do you need translation for?
This whole section is new, and was not present in previous survey.
What you think of GIT
~~~~~~~~~~~~~~~~~~~~~
34. Overall, how happy are you with GIT?
Answer | Old | Count
------------------------------------------------
unhappy | 1 | 13
not so happy | 19 | 36
happy | 53 | 179
very happy | 41 | 302
completely ecstatic | 1 | 112
------------------------------------------------
Base | | 642 / 683
Total (sum) | 115 | 642
During the year the balance shifted slightly in the positive
direction: from mostly happy to very happy, to mostly very happy
leaning to happy. And we have much more percentage of completely
ecstatic.
Good work!
35. How does GIT compare to other SCM tools you have used?
Answer | Old | Count
------------------------------------------------
Better | 80 | 505
Equal (comparable) | 20 | 96
Worse | 8 | 30
------------------------------------------------
Base | | 631 / 683
Total (sum) | 108 | 631
Here not much changed. The shape of this histogram is almost the same,
with slight shift towards "better than other SCMs used".
Note that 2006 survey has "Equal (or uncomparable)" instead of
"Equal (comparable)" as it is now.
36. What do you like about using GIT?
TO DO. Yet another free-form question. Tabularized for 2006 survey,
most encountered answers listed without count for 2007 survey.
37. What would you most like to see improved about GIT?
(features, bugs, plug-ins, documentation, ...)
TO DO. As above: tabularized somewhat for previous survey, with the
list of ideas (divided broadly into categories) below the table; with
some ideas dropped. For current survey there is only list of most
commonly encountered, and most interesting ideas.
Some of the 2006 ideas got implemented, or are being implemented, like
better documentation (Git User's Manual, documenting options), shallow
clones, win32 native binaries (via MinGS, in development), subproject
support (plumbing and beginnings of porcelain), libification and
builtinification (GSoC projects), increased verbosity when needed and
making error messages more helpful, graphical merges (git-mergetool:
interface to file-level graphical mergers like Meld, KDiff3 etc.), per
user configuration (~/.gitconfig rather that ~/.gitrc, and there is
even system wide configuration). Some of ideas are repeated (like
"The Git Book" idea, although "Git User's Manual" fills it somewhat),
some ideas provided too hard (e.g. lazy clone aka remote alternates)
or without someone to implement them. Some got abandoned, some will
probably never get implemented.
Even some suggestions in 2007 survey are actually implemented already,
for example git development Changelog (present in the form of
RelNotes), shallow clone support, submodules support. This means that
new features are not very well announced (which was also one of
comments in current survey).
38. If you want to see GIT more widely used, what do you think
we could do to make this happen?
TO DO. List of suggestions for 2006 survey; for current 2007 survey
only two most striking.
Changes in GIT (since year ago, or since you started using it)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39. Did you participate in previous Git User's Survey?
40. What improvements you wanted got implemented?
41. What improvements you wanted didn't get implemented?
42. How do you compare current version with version from year ago?
43. Which of the new features do you use?
This whole section is of course new (Git User's Survey 2006 was first
git survey ever; git is not very much older than that), and was not
present in previous survey.
Documentation
~~~~~~~~~~~~~
44. Do you use the GIT wiki?
45. Do you find GIT wiki useful?
Previous survey has two questions in one here: "Do you use the GIT
wiki? If yes, do you find it useful?". This made it hard to
distinguish if "no" means "no I don't use GIT wiki" or "no it is not
useful".
This was one of the improvements over previous version of survey.
46. Do you contribute to GIT wiki?
This question was not present in previous survey.
47. Do you find GIT's on-line help (homepage, documentation) useful?
In 2007 survey there is additional "somewhat useful" answer, which was
not present in the 2006 survey.
Answer | Old | Count
--------------------------------------------
Yes | 88 | 377
No | 20 | 28
Somewhat | - | 172
------------------------------------------
Base | | 577 / 683
Total (sum) | 108 | 577
The results are similar: most users find online help useful.
47b. What is your favourite user documentation for any software
projects or products you have used?
This question is present in 2006 survey, and was removed in current
one. The idea behind question was I guess to have the results in hand
if git ever was to change documentation format. Most likely current
format of documentation (AsciiDoc), or at least idea behind it
(it should be possible to read sources, editing sources without
specialized editor support should be easy even for people who don't
know the format) is here to stay.
48. Do you find help distributed with GIT useful
(manpages, manual, tutorial, HOWTO, release notes)?
49. Did/Do you contribute to GIT documentation?
Those questions were not present in previous survey.
50. What could be improved on the GIT homepage?
TO DO. List of suggestions for 2006 survey, nothing yet for 2007
survey.
51. What topics would you like to have on GIT wiki?
52. What could be improved in GIT documentation?
Those questions were not present in previous survey.
Getting help, staying in touch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
53. Have you tried to get GIT help from other people?
Answer | Old | Count
------------------------------------------------
Yes | 68 | 357
No | 45 | 261
------------------------------------------------
Base | | 618 / 683
Total (sum) | 113 | 618
Around 60% of people tried to get GIT help from other people,
for both current (2007) and previous (2006) survey.
54. If yes, did you get these problems resolved quickly
and to your liking?
Answer | Old | Count
--------------------------------------------
Yes | 68 | 326
No | 45 | 53
------------------------------------------
Base | | 379 / 683
Total (sum) | 113 | 379
The precentage was a bit worse during earlier survey (around 60%) than
for corrent one (around 86%).
This might be caused by the fact that git is now more userfriendly,
and has more features, and problems are easier to resolve.
55. Would commerical (paid) support from a support vendor
be of interest to you/your organization?
This question was not present in previous survey. It was requested
during an RFC for this year (2007) survey.
56. Do you read the mailing list?
Answer | Old | Count
------------------------------------------------
Yes | 67 | 204
No | 50 | 406
------------------------------------------------
Base | | 610 / 683
Total (sum) | 117 | 610
Note that 2006 version had "subscribe" instead of "read" in this
question. Even despite that the number of people reading git mailing
list decreased from more than half (around 57%) to around third
(around 33%). This might be caused by the fact that notice / info
about Git User's Survey 2006 was distributed mainly among git mailing
list and among mailing lists for projects which use git (see also
commets to questions 19 and 30).
The fact that only one third of git users are reading mailing list
(which is nevertheless quite large percentage) means that features
_have_ to be documented somewhere besides mailing list archive and
logs (commit messages).
57. If yes, do you find the mailing list useful?
58. Do you find traffic levels on GIT mailing list OK?
Previous survey has two questions in one here: "If yes, do you find it
useful, and traffic levels OK?". They were split in current survey.
59. Do you use the IRC channel (#git on irc.freenode.net)?
Answer | Old | Count
------------------------------------------------
Yes | 23 | 182
No | 93 | 376
------------------------------------------------
Base | | 558 / 683
Total (sum) | 116 | 558
More people use #git channel now (33% as compared to 20% before).
Nevertheless relatively few people use this form of comminication and
getting help.
60. If yes, do you find IRC channel useful?
This question was not present in previous survey. It nicely follows in
the series of questions about git wiki and git mailing list (do you
use? is it useful?).
61. Did you have problems getting GIT help on mailing list
or on IRC channel? What were it? What could be improved?
This question was not present in previous survey.
Open forum
~~~~~~~~~~
62. What other comments or suggestions do you have
that are not covered by the questions above?
TO DO. There is list of responses for 2006 survey; the 141 responses
in current (2007) survey are not yet analysed.
--
Jakub Narebski
(currently away from net)
^ permalink raw reply
* Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-12 22:08 UTC (permalink / raw)
To: git
In-Reply-To: <8fe92b430710081355i7d3dbaa2q9a8939b55d7ca7dc@mail.gmail.com>
This is continuation of partial summary of Git User's Survey 2007,
ending at state from 28 September 2007.
(response ident "46f95167c967b").
The survey can be found here:
http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9
http://tinyurl.com/26774s
The data this summary is base on can be found here:
----
There were 683 individual responses
Other SCMs
~~~~~~~~~~
13. What would you require from GIT to enable you to change,
if you use other SCM for your project?
TO DO
474 / 683 non-empty responses
List of answers, without count (which for this question is, I think,
less important), divided into broad categories, is shown below
Generic
* being more user-friendly, easier to use
more friendly output from commands
better and clearer error messages
stable command semantics
* reduced number of (visible) commands
clear separation of plumbing and porcelain
* consistent set of commands
consistency if command flags
* easier to learn (easier learning curve)
* more stability
* support UTF-16
* A clearer UI. Read the monotone list archive. 70% of the mails are
UI related. The result is an clear and easy to use intuitive UI
that does what you expect in most cases.
Performance
* better performance on massive trees (FreeBSD)
* good speed on NTFS (MS WIndows)
Documentation
* a good documentation
user/installation documentation
troubleshooting guide
'Git For Dummies', 'The Git Book'
* documented workflows (including centralized repo workflow, or at
least documenting how and why replace it with better workflow)
* development model tutorials
more example usage
best practices
case studies
* guide for designing a branch policy for a shared repository
* screencasts
* documentation in one's native language
* good in-depth administative documentation
* maybe git-tutor program
Specific features
* partial-tree checkouts (partial checkout)
checking out arbitrary subdirectories
* granular permissions (ACL) within the tree
e.g. restricting translators to the po/ subdirectory
* shallow clone from a given commit: git clone --depth <commit>
* automatic (re)packing
* lightweight working copies
* better and well documented submodule support
* multi-project support / multiple sandboxes support
* git-bind/unbind (like in bzr)
* git-sync
* cvs-compatible syntax as an option
* tracking empty directories
* more friendliness with corporate firewalls
* ability to preserve permissions/modes/EA of files and directories
access control features / visibility access control
disabling some users from accessing certain parts of the repository
* being able to merge directories (instead of branches)
* FastCGI gitweb
* some embedded keyword capabilities similar to those provided by CVS
and Subversion
* ignore files during merge
* R/W git server (allow push), with NIS, LDAP support
* pull/rebase into dirty tree
* clearcase dynamic view-like support (externally?)
* better http(s) push via WebDAV: hooks
working and easy to setup push over https
* plain simple FTP upload (push) and download (clone, fetch)
* better working through corporate firewalls
Portability
* native MS Windows support, easy installer package
even better support for all platforms
easier setup on Solaris and AIX
* pre-prepared _static_ binaries for FreeBSD, MacOS X, MS Windows
* less dependencies
* support for more platforms
* a portable version of git, one binary + library (gitbox)
* Windows version(s) mentioned on homepage
GUI
* better (G)UI
TortoiseGit for MS Windows, or other Windows front-end
good, advanced GTK+ 2.x tool to visualize git
* history graph conected to file tree in GUIs
* easier management of remotes using GUI
* better diff viewing tools (side-by-side, like KDiff3)
Other SCMs
* seamless import
BitKeeper / ClearCase import/sync
tool to import TeamWare history into Git
better SCM interop
* SCM rosetta / "Git for <SCM> users" documentation
* import/export tools supporting incremental import and export
* 100% subversion interoperability
* git update (stash, fetch, rebase, unstash) a la CVS
* git-svnserve
* svn:externals support
Tools
* improved administrative tools
* reasonable plugins for IDE (e.g. Visual Studio, KDevelop, NetBeans)
full Eclipse / NetBeans / IntelliJ support
* good integration with apps like Trac and Bugzilla
work with continuous integration tools (cruise control etc...)
* Git+Launchpad
* libification (for tools support)
Other
* SourceForge / Gna! / Google Projects support
(free) hosting with git facilities
FOSS hosting sites supporting git
* commercial support / corporate backing
contractual service
* number of users, to convince my co-workers that they're not
a silly minority
popularity
* projects switching to git
* user education
* marketing, advocacy videos
* convincing coworkers / other members / boss
willingness of the other developers to learn to use it
* training/certification
* a stop to the constant bashing of other SCMs - this doesn't get you
any friends drop the arrogant attitude, work with the rest of the
community and try to make something people can understand in an
hour
* http://wiki.FreeBSD.org/VersionControl
* At work it'd require some kind of miracle. Huge Perforce repository
of highly interrelated stuff in which people can make sweeping
changes in a single changelist. Lots of tools that access Perforce.
Slow as hell.
Getting help, staying in touch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
61. Did you have problems getting GIT help on mailing list
or on IRC channel? What were it? What could be improved?
TO TABULARIZE
99 / 683 non-empty responses
Problems and suggestion for mailing list:
* I answered my own question and no one even commented it. User and
development discussion should be separated. Just release
announcements in the user list.
You need another mailing list for users. The current mailing list
is very developer centric.
The mailing list feels like it's more for developers rather than
users and it's a little intimidating to ask newbie questions there.
Maybe separate git-users and git-dev lists would make sense.
Git mailing list needs a users and developers list. Mixing up the
two is intimidating with all the traffic and the number of patches
and advanced topics that shoot around.
Having separate git-users and git-devel lists would be nice. I
might read both but I hate to ask a newbie question on a list where
50% of the submissions contain patches.
(Other users find mailing list very responsive. Splitting the list
into either git-devel and git-users, or git and git-announce has
its advantages and disadvantages. You can always filter out patch
submission and comments on patches thanks to the "[PATCH .*]"
prefix convention present on mailing list.)
* A question or two with no response at all. In hindsight my query
was way too long-winded but it's still frustrating to be ignored.
I answered my own question and no one even commented it.
(See above)
* The git mailing list is too high traffic to remain on. Maybe split
it into a few lower traffic versions?
Biggest problem is that smaller problems are getting lost in the
growing size of the mailing list.
The sheer amount of traffic makes the mailing list hard to deal
with sometimes. Getting your email tools set up correctly can help
(i.e. auto tag+archive in GMail), but ultimately you still have to
wade around in hundreds of emails you don't care about in order to
find the ones you do care about.
(Most people find traffic levels on git mailing list OK, see
question 58.)
* Will not go through corporate firewall.
(I think it was about mailing list, but perhaps it was about IRC)
I no longer subscribe to the GIT mailing list as ML subscription is
forbidden at my new job, and I have no time at home to read it all.
(You can read git mailing list through many archives / web
interfaces, including MARC and GMane ones, and throught NNTP
(aka. Usenet, aka news) interface on GMane. You don't need to be
subscribed to git mailing list to post.)
* People responded quickly to mailing list queries usually helpfully.
However there was occasionally a touch of annoying 'groupthink' to
the responses; sometimes new users are just confused and really
would be better served by just changing their working habits, but
other times there appeared to be a bit of tunnel-vision on the part
of the longtime git users.
* Trolls could be thrown out ;-) Seriously we had only a few there,
but they are mighty annoying.
* Mostly no. But little help on applying email-patches in win32 using
GMail. I'll get there though :)
(Late addition of smtpserver (with ability to select port number),
smtpuser, smtppass and smtpssl configuration variables / options to
git-send-email should help with _sending_ patches using GMail. As
to applying email-patches, git-am understand both mbox and maildir
formats, not that it help much with win32 mail programs; but you
can always try to save email in raw format from GMail WWW
interface)
Problems and suggestions for IRC:
* The IRC channel has too few people who know answers to questions;
if you're there at the wrong time of day when none of them happen
to be around it's useless. But if you're there at the right time
it's pretty good.
* IRC channel seems to respond to newbie git users quite well, but
mid-level experience often gets no response.
* Traffic on the IRC channel is a bit high. It may need to be split
into a few different high-level topics in the near future.
(IRC channel or git mailing list? I don't remember IRC channel
having high traffic...)
* It's hard to improve IRC. It's such a poor medium for understanding
the communication going on.
(On the other hand it is responsive. I think pastebins helps to
sidestep limitations of the medium. Nevertheless the main medium of
communication is git mailing list, not #git channel.)
* IRC is blocked from work :-( I may try it by tunneling out.
(Any suggestions here?)
Generic problems and suggestions:
* Sometimes you get no answer (on git mailing list or #git channel)
but that happens
* People seem to think the problem isn't with git, and yet I find git
extremely buggy and non-intuitive. Your "Git in 5 minutes" doesn't
even include +x a hook or mention of hooks; neither does linus
speech. If you don't +x a hook, try to figure out what is going
on. I dare you. Git fails silently a bunch, maybe half of the time
by design. Which shouldn't be acceptable.
Try addressing an ssh address in url format: it isn't consistent
and it will fail in half the apps. Same thing with git-ls-remote:
it might have an --upload-pack that works, but this isn't across
the board! From my own debugging none of the shell scripts have an
--upload-pack option that work.
(Not here. This is question about getting help from people, not
about documentation or what you find hardest in GIT.)
* After the last thread the GIT FAQ is almost begging for a 'Please
don't ask about C++' section.
(Truly, Git FAQ (which resides on Git wiki, but perhaps we should
consider extracting it and adding to distribution tarballs) needs
maintenance, updating and adding new frequently asked
questions. Currently there is no FAQ maintainer.)
The other side: getting help success stories:
* Quite the contrary. When Source Mage GNU/Linux switched to using
GIT our developers spent a considerable amount of time asking
questions and discussing features and bugs on #git. The feedback
that we got was fabulous: the GIT developers were helpful
interested in our needs and productive when it came to fixing
bugs. One bug we discovered was even handled by Linus Torvalds
himself and in just a matter of hours! In our eyes the GIT
development community gained rightful reputation as one of the most
friendly and helpful communities there is.
* No, the mailing list has been very responsive. I have never asked a
question on IRC but I sometimes answer newbie questions.
* Mailing list is very interesting especially as I'm working on
egit. IRC is more immediately helpful.
* I'd like to say that I consider #git to be the most useful IRC
channel I've ever been to when it came to getting answers to my
questions. Thanks guys!
The IRC channel is wonderful. The people there do a good job with
questions.
* No problems. In fact the mailing list/IRC could substitute the
documentation but I guess that
(1) does not work in offline mode
(2) _is_ going to get on peoples nerves after a while
(recurring questions)
Open forum
~~~~~~~~~~
62. What other comments or suggestions do you have, that are not
covered by the questions above?
TO DO
141 / 683 non-empty responses
There are many "keep up the great work!" (and equivalent) as answers
to this questions, and a few "worst SCM I've used". Those are excluded
from the lists below.
Suggestions for git:
* One of the biggest complaints I hear is that mercurial's UI is much
more 'intuitive' and user friendly. Perhaps looking at it's
operation and comparing/contrasting would be good.
(Note that changing names of commands for example might be
impossible because of historical reasons and large usebase.
On the other hand perhaps this is just a steep learning curve,
unavoidable for a power tool)
* Mercurial has an excellent tutorial which had my team up and
running in less than a hour after a week struggling to make git do
anything useful.
(I hope that late work on "Git User's Manual" helps here)
* Handling of Unicode (UTF-16 encoded) files is a big pain with git.
Even SVN can do a diff of them.
(The idea that blob is just a bag of bytes will not change; but we
have input/output filters, and soon before-diff filters, connected
with gitattributes)
* I like how in Subversion the commands work relative to the current
directory. With Git I always seem to be dealing with longer paths
and/or have to change to the root.
(Running git from within directory deep within repository structure
should 'just work'. If not, then it is an error... unless in
situation like referring to tree-ish, where path is almost always
relative to project root).
* Keep up the UI simplification and make sure the docs start off with
usage somewhat similar to CVS/SVN. I think many users are scared by
Git because they see the more powerful commands thrown around too
early and get scared.
Git is just too complicated for a typical project. I understand
it's probably great for the Linux kernel but for a smaller project
like mine (Mesa) it's overkill and a frustration. (...) With git
everything seems hard. (...) I've _wasted_ hours trying to figure
out git. That alone is a huge issue. I guess I could go into
specific details about my problems with git but I've already spent
enough time on this survey.
Figure out why people find git hard to learn and eliminate those
barriers to entry. Make git more task-oriented rather than
data-model-oriented the way it is now.
It's a great idea and a powerful tool but it's got a long way to go
before it reaches wider adoption because it's so damn hard to use.
(...) I'm evaluating Mercurial despite its being based on Python
because it feels cleaner and simpler to use. I would prefer to use
Git.
(I think the 1.4 and 1.5 series is a good step in simplifying git
for simple tasks and ordinary user. Core git porcelain improved
much, and now there is no need to use plumbing for every-day tasks)
* No one-pager cheat sheet with the 6 most basic commands on it so
people can go use git.
(This got corrected. There is git cheat sheet on the Internet;
there is link on GitWiki to it)
* Having a git library where other apps can integrate git, along with
bindings for Python would be great.
Make it easier to use by graphical clients like KGit.
(The libification projects from Google Summer of Code would help
there, I think)
* I think that moving away from shell scripts to builtins is a
necessary step but I don't really like it. It would help if you
kept them around, perhaps in contrib/, so that others can learn how
to use the plumbing (I learned a lot about git from reading these
shell scripts).
(Doing it: shell scripts which are moved to builtin are retired to
contrib/examples/ directory).
* Building git is a pain. (SHA1 sources being a problem). Can't git
use autoconf? Also I've heard people have issues with git's
portability (for example some BSD variant). Shell scrips weren't
portable to non bash IIRC and often relied on GNU extensions in
some programs. Native Windows port is also important.
Probably the toughest challenge for Git IMO is that Mercurial,
Darcs and Bazaar are good and similar. Lack of Windows support
makes some people rule out Git altogether even though it may be
better overall.
I'd like to just stress support for windows and central
repositories. (...) In fact most of my friends really wanted to use
git but they wanted a solid native port.
I think key to the adoption of git is that it is made to run on
Windows as well as the other major OSes.
(Git tries to use autoconf in a way that is totally optional, to do
detection and write options for Makefile; you are welcome to
contribute to configure.ac. People work on making git more
portable, for example trying to make it work with dash, defining
in the meantime minimal POSIX-like shell compatibility required.
Native MinGW Windows port is in the development)
* I think that it is very nice that git is in the native OS
repositories for Fedora. The Debian version needs updating.
(git Makefile has rpm target, and git.spec target; perhaps this is
the cause)
* git-blame is manageable (with gc and reduced history etc) but that
slowness still seems to be a negative point for many of my peers. I
wouldn't mind better performance there either. Maybe some kind of
optional indexing for those who want fast blame?
(I recall there were some ideas about how to make git-blame faster
on git mailing list. Making it interactive for graphical blame
tools reduced latency; there is I think a bit place for easy
improvement for reblaming. Maybe packv4 would help with blame
performance... What is I think unchangeable is the fact that
snapshot driven / whole history driven SCMs _always_ would be
slower at least a bit than single-file based SCMs. This tradeoff
is not possible to avoid. But don't forget that git has other
tools for examining history, like path (subsystem) limiting,
searching commit messages, pickaxe search and graphical history
browsing tools like gitk or qgit)
* Get a mascot perhaps O'Reilly animal for O'Reilly GitBook
(Git User's Manual) like the svnbook.
(What animal could Git use for O'Reilly? Herd of horses, or a
pony?)
* I'm wondering what the overall goal is - git's origin as a neutral
ground was fine but it hasn't seemed to take off as a viable
alternative for general use. Do you care about that? Is it ok
that git is it's own little niche?
(Junio, Linus?)
Suggestions about git mailing list:
* Git adoption will be limited by the actions and attitudes of those
on the mailing list. 'If you can't say anything nice...'
(We are nice, I think... to a point)
* The ML had way too much traffic. I think there should be at least a
git-patches@ where people submit there patches and git@ remains for
user/dev discussions.
(Most users find level of traffic on git mailing list O.K. It is
not that hard to separate patch submission and their discussion
from the rest of traffic thanks to [PATCH] prefix convention used.)
Suggestions and comments about this survey:
* Various questions need 'other' options such as the programming
language question. Various questions that already have 'other' as a
possible choice need a text box to fill in the specifics.
(I am not sure if it is possible mixing radiobutton/checkbox with
text field with currently used free survey service, survey.net.nz)
* The text fields (and text areas) of this survey are way too small!
(I am not sure if changing this is possible with currently used
free survey service, survey.net.nz)
* You should do a survey of feature requests.
(See questions 13, 38, 41 and especially 37)
* Shorten survey length. This survey is too damn long. Make the
survey shorter!
Cut down the number of questions on this survey by a factor of 4.
(I think removing the questions which asks very similar question
but in different context be a good start. But that aside: which
questions should be dropped, which concatenated (and which split);
which are useful and which are not?)
* Questions not asked: what can be improved on GitWiki, workflows
used and tools used, kind of repository hosting used for project,
programming experience level and version control experience, using
git for non-programming repositories like ikiwiki or documents,
perceived git stability and number of bugs.
(The surveys is very long as it is now. Those questions are nice,
but it would make survey too long I think.)
* The survey asks about new features that are not in a stable version
of git yet. git-stash comes to mind. This is silly. Not everybody
will track your development branch. I certainly don't. I don't for
other SCMs I use either.
(I tried to put only features which are in released, i.e. numbered,
version. git-stash is in 1.5.3, see Documentation/RelNotes-1.5.3.txt)
* Regarding Q19 (How do you obtain GIT?). I actually use all three
forms on different systems.
Mac: pull from MacPorts
Ubuntu: from git.git
remote systems: tar balls.
(Should it be made multiple choice question, then?)
Some other comments:
* I've been so busy with other projects. I didn't realize so many
interfaces exist. Thanks to this survey I'll spend some time
checking out the wiki for the other interfaces.
I didn't even know about any of the new git features listed in
question 43.
I need to get an up to date version as there are things mentioned
in this survey that I don't know about.
* At the 'Solutions Linux 2007' exhibition in Paris I have been
looking for a service provider that could propose some training
sessions for Git. I couldn't find one. Maybe in 2008...
--
Jakub Narebski
(away from Internet)
^ permalink raw reply
* Re: RCS keyword expansion
From: Johannes Schindelin @ 2007-10-12 22:42 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git
In-Reply-To: <470FC64B.8010707@gmail.com>
Hi,
On Sat, 13 Oct 2007, Salikh Zakirov wrote:
> * smudge filter is not passed a name of file being checked out,
> so it is not possible to exactly find the commit identifier.
> However, this is alleviated by the fact that 'smudge' is only being run
> for the changed files, so the last commit *is* the needed one.
No.
When changing branches, this is not the commit you think it is.
But maybe you humour me and tell me in which context such a smudge filter
is of use. I have yet to encounter an argument that convinces me.
Ciao,
Dscho
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Frank Lichtenheld @ 2007-10-12 23:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <8fe92b430710121508g13917080mac156250abfccf20@mail.gmail.com>
On Sat, Oct 13, 2007 at 12:08:18AM +0200, Jakub Narebski wrote:
> * I think that it is very nice that git is in the native OS
> repositories for Fedora. The Debian version needs updating.
>
> (git Makefile has rpm target, and git.spec target; perhaps this is
> the cause)
Nah, the Debian problem is just bad timing. Debian stable is stuck with
1.4.4 which is unfortunate but not fixable. unstable is very fast with
updates and backports.org is very good, too (but lacks at least 10 days
due to upload policy).
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: RCS keyword expansion
From: Zakirov Salikh @ 2007-10-12 23:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Peter Karlsson
In-Reply-To: <Pine.LNX.4.64.0710122341160.25221@racer.site>
On 13/10/2007, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > * smudge filter is not passed a name of file being checked out,
> > so it is not possible to exactly find the commit identifier.
> > However, this is alleviated by the fact that 'smudge' is only being run
> > for the changed files, so the last commit *is* the needed one.
>
> No.
> When changing branches, this is not the commit you think it is.
Exactly. When switching branches, or merging or fast-forwarding several commits,
the last commit may not be correct. The last commit is only correct
for the files
being updated by the fast-forward to exactly one commit.
Which seem to be pretty natural for the use case of checkout-only
web-published workspace.
> But maybe you humour me and tell me in which context such a smudge filter
> is of use. I have yet to encounter an argument that convinces me.
Your comment prompted me to think about a narrower case of
fast-forwaring to one revision.
In that case, 'smudge' script can have commit identifier in
FETCH_HEAD, so the example
script from previous message with a little modification:
$rev = `git-rev-parse FETCH_HEAD`
gives *exact* solution to the originally stated problem, though for
the specific case
when the web server directory is a checkout-only working directory,
which pulls changes
automatically from master server (as opposed to, e.g., pushing changes
to web server).
Even if the server pulls several revisions at once, it is likely that
they are done in a close succession (otherwise automated update would
have picked them separately), and
important part in web page timestamp is usually date.
Too bad I do not really have a web server and do not need to maintain
timestamps in web pages ... :) git scriptability always amazed me.
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-13 0:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <8fe92b430710121508g13917080mac156250abfccf20@mail.gmail.com>
Hi,
Jakub, thank you very much for doing this. It is a very tedious work, and
I deem it invaluable.
On Sat, 13 Oct 2007, Jakub Narebski wrote:
> * IRC is blocked from work :-( I may try it by tunneling out.
>
> (Any suggestions here?)
I had the same problem, and somebody pointed me to
http://ircatwork.com/cgi-bin/irc/irc.cgi
(But please be nice, or else it will be shut down...)
> * Keep up the UI simplification and make sure the docs start off with
> usage somewhat similar to CVS/SVN. I think many users are scared by
> Git because they see the more powerful commands thrown around too
> early and get scared.
>
> Git is just too complicated for a typical project. I understand
> it's probably great for the Linux kernel but for a smaller project
> like mine (Mesa) it's overkill and a frustration. (...) With git
> everything seems hard. (...) I've _wasted_ hours trying to figure
> out git. That alone is a huge issue. I guess I could go into
> specific details about my problems with git but I've already spent
> enough time on this survey.
I find it always a little strange how people want to use something like
git, but are unwilling to ask. Is this such a big attack on the manliness
to admist one needs help or what?
> Figure out why people find git hard to learn and eliminate those
> barriers to entry. Make git more task-oriented rather than
> data-model-oriented the way it is now.
Frankly, expectations like these make me want to bang somebody's head on
the wall. Why do people expect others to work for them for free? Hard?
> (...) I'm evaluating Mercurial despite its being based on Python
> because it feels cleaner and simpler to use. I would prefer to use
> Git.
You cannot do much about feelings, not with technical means, you can't.
> * No one-pager cheat sheet with the 6 most basic commands on it so
> people can go use git.
>
> (This got corrected. There is git cheat sheet on the Internet;
> there is link on GitWiki to it)
I think it'd be a good idea to put it on git://git.kernel.org/, linked
right before the links to the man pages. Who has permissions to change
that page?
> I'd like to just stress support for windows and central
> repositories. (...) In fact most of my friends really wanted to use
> git but they wanted a solid native port.
If you read what I wrote above, you know exactly what I want to do here.
> * Get a mascot perhaps O'Reilly animal for O'Reilly GitBook
> (Git User's Manual) like the svnbook.
>
> (What animal could Git use for O'Reilly? Herd of horses, or a
> pony?)
OMG Ponies!
Seriously again, is the cheetah taken already?
Speaking of cheetah: there is a project called git-cheetah, its goal being
to provide a TortoiseCVS lookalike for git.
Just wanted to mention it, in case people want it, and are not too shy to
participate in making it closer to the goal.
> * I'm wondering what the overall goal is - git's origin as a neutral
> ground was fine but it hasn't seemed to take off as a viable
> alternative for general use. Do you care about that? Is it ok
> that git is it's own little niche?
>
> (Junio, Linus?)
I am neither, but FWIW I did not have the impression that it is in its own
little niche.
At the GSoC mentor summit, I encountered a rather different stance: people
did not _know_ what distributed SCM means, and were rather afraid of the
concept. Some of them seemed to fight changing their known procedures
tooth and nail. Which is fine by me (I don't have to force anybody to
use git, thankyouverymuch).
A word about the GitFAQ... there was one suggestion that there should be a
FAQ maintainer.
I really have to ask myself why not more people just edit the GitFAQ on
the wiki. I mean, that is the whole purpose of it being on the wiki.
It's not hard either.
Less hard in any case than to find a volunteer for a FAQ maintainer -- I
mean, if most are too busy/lazy/shy to edit the FAQ at all, how do they
expect somebody else to step up?
Ciao,
Dscho
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: J. Bruce Fields @ 2007-10-13 2:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710130130380.25221@racer.site>
On Sat, Oct 13, 2007 at 01:46:40AM +0100, Johannes Schindelin wrote:
> On Sat, 13 Oct 2007, Jakub Narebski wrote:
... (from survey response:)
> > Figure out why people find git hard to learn and eliminate those
> > barriers to entry. Make git more task-oriented rather than
> > data-model-oriented the way it is now.
>
> Frankly, expectations like these make me want to bang somebody's head on
> the wall. Why do people expect others to work for them for free? Hard?
Well, hey, we asked for suggestions. Think of it as a project someone
might want to work on, rather than as a command.
I don't know what they mean by "make git more task-oriented rather than
data-model-oriented", but the first suggestion ("Find out why people
find git hard to learn...") is certainly something I'd enjoy working on
if I found the time.
--b.
^ permalink raw reply
* Re: Imports without Tariffs
From: Jeff King @ 2007-10-13 2:49 UTC (permalink / raw)
To: mfwitten; +Cc: git
In-Reply-To: <1C0D32ED-59F7-43D4-88B1-D7A9E754D639@mit.edu>
On Fri, Oct 12, 2007 at 04:36:29PM -0400, mfwitten@MIT.EDU wrote:
> (4) Update my git working tree from CVS (at some later time).
>
> => cd ../work
> => git cvsimport -a -k -v -r cvs -C . module
>
> [PROBLEM]
>
> git-cvsimport creates new hash IDs for the same ol' commits.
>
> [...]
> Therefore, when the updated 'cvs' remote branches are merged into
> my local branches, git treats the commits I made with cvsexportcommit
> as separate history; thus, history is duplicated and merge commits
> appear where they shouldn't.
You are presumably doing a 'git-pull' on the cvsimport-ed commits. Try
doing a git-rebase, which will filter out commits which make the same
changes. Yes, it means throwing away your original commits, but the new
ones should be morally equivalent (and are now the "official" upstream
of the CVS repository).
-Peff
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Shawn O. Pearce @ 2007-10-13 2:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710130130380.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sat, 13 Oct 2007, Jakub Narebski wrote:
> > * I'm wondering what the overall goal is - git's origin as a neutral
> > ground was fine but it hasn't seemed to take off as a viable
> > alternative for general use. Do you care about that? Is it ok
> > that git is it's own little niche?
> >
> > (Junio, Linus?)
>
> I am neither, but FWIW I did not have the impression that it is in its own
> little niche.
I'm neither too. But I don't think Git is in a niche. OK, well,
in the overall world of software development its certainly in the
niche of version control, as uh, it doesn't do Enterprise Resource
Planning and Large Scale Embezzlement of Monies (ERPaLSEM).
Actually I've seen a number of people on the interweb saying things
like they were switching their project to Git because they felt
it had more staying power than say Monotone or Mercurial, partly
because the kernel devs were actively using it, partly because the
file formats are so simple and sane, and partly because lots of
other projects are using it or are seriously considering it.
> At the GSoC mentor summit, I encountered a rather different stance: people
> did not _know_ what distributed SCM means, and were rather afraid of the
> concept. Some of them seemed to fight changing their known procedures
> tooth and nail. Which is fine by me (I don't have to force anybody to
> use git, thankyouverymuch).
Yes, this attitude *shocked the hell out of me*. I really did not
expect it. I nearly keeled over and died when I realized what the
folks in the back corner of the room were saying.
WINE uses Git. Some folks were outright pissed off that there
was only one committer in WINE. I think they felt the project
was maybe going to die because there was only one committer who
could apply patches. That may wind up being true (there's only so
far that one human can scale without trusted helpers for different
submodules of a large system) but its not Git's fault, or any other
DVCS's fault for that matter. At least its easy to fork WINE.
On the other hand active participants of two major organizations (KDE
and Eclipse) are starting to seriously look at Git. The interest
in Git is growing in both of those groups, which can only be good
for us. We'll learn more about how these groups do development,
and how we can best help them to accomplish more.
--
Shawn.
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Shawn O. Pearce @ 2007-10-13 3:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Johannes Schindelin
In-Reply-To: <8fe92b430710121508g13917080mac156250abfccf20@mail.gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> Other
> * SourceForge / Gna! / Google Projects support
> (free) hosting with git facilities
> FOSS hosting sites supporting git
We may find support for Git on SourceForge in the future, but not
on Google Projects anytime soon, if ever.
At the Google Summer of Code Mentor Summit last Saturday Dscho had a
short chat with someone from the Google Code group. Apparently they
did at least look at Git briefly but concluded that they cannot
implement it on their site as our backend storage database is just
plain files on the local filesystem.
One of the reasons (probably among many but whatever) that I think
Google hired the "SVN guys" as employees is to develop a Google
specific backend for SVN (replaces fsfs and bdb) that stores the
SVN revision data in a Google BigTable cell rather than on the
local filesystem. This allows Google to efficently manage the
entire site, including distributed replication, hot failover, etc...
BigTable is one of their key technologies at this point.
If you don't know about BigTable but want to know more you can
search for details about it via this awesome search engine I have
heard about: http://www.google.com/ :-)
I've managed to glean enough details on BigTable to know that the
Git backend is *not* easily layered on top of it. But the SVN
fsfs backend is actually fairly easy to translate into BigTable,
so I imagine it didn't take the "SVN guys" very long to develop
the new backend, test it, and thus deploy SVN onto Google Projects.
Funny aside: If you really want to know about BigTable apparently
you also need to visit (one of?) the men's room in building 43
on the second floor. There were tutorial posters hanging on the
wall describing how to use BigTable and Sawzall to summerize a
large dataset. Most pubs hang sports pages from the local paper;
Google hangs BigTable documentation. Nerds. All of 'em.
--
Shawn.
^ permalink raw reply
* Re: push fails with unexpected 'matches more than one'
From: Shawn O. Pearce @ 2007-10-13 3:21 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <91A04390-89B2-47B8-9B61-7C7E652670AE@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> I read carefully through the documentation of git-send-pack and
> git-rev-parse. The current implementation of git-send-pack is in line
> with the documented behaviour, as is the implementation of git-rev-
> parse.
>
> So formally everything is correct.
>
> But it is completely against my expectation that git-push <remote>
> <head>
> can successfully resolve a <head> that git-rev-parse fails to parse. I
> understand that refs are not revs ;). But nonetheless, I'd expect that a
> local ref that cannot be parsed by git-rev-parse should also fail to be
> pushed by git-send-pack. I didn't expect that git-send-pack would locate
> <head> as someprefix/<head>.
>
> Why is my expectation wrong?
> Or is the current specification of git-send-pack's ref parsing wrong?
I think its a bug. But I didn't write the original code.
Meaning I think what happened here was someone wanted to enable
git-send-pack to match "master" here with "refs/heads/master" on
the remote side. One easy way to do that was to see if any ref
ended with "/master", as that was what the ref here was called.
Way back when that code was written most Git repositories probably
only ever had that one branch anyway, or maybe two (refs/heads/master
and refs/heads/origin) so matching the trailing suffix never came
up as a bug. Nobody ever had two refs that could possibly match.
Then the documentation got expanded to actually document the behavior
that git-send-pack implemented. Unfortunately that codified the
bug as documented behavior.
So I agree with you Steffen, this is a bug in send-pack, and I run
up against it every once in a while. I've specifically told my
coworkers "NEVER, EVER, EVER, create a branch called 'master' that
isn't exactly refs/heads/master OR ELSE I WILL COME BEAT YOU WITH A
CLUE STICK". They still create "refs/heads/experiments/master".
*sigh*.
I think we should fix it. Anyone that is relying on "git push
$url master" to resolve to "refs/heads/experimental/master" on the
remote side is already playing with fire. But Junio is (rightfully
so) very conservative and doesn't like to break a user's scripts.
We may not be able to fix this until Git 1.6.
--
Shawn.
^ 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