* Re: way to automatically add untracked files?
From: Johannes Schindelin @ 2007-08-06 0:17 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Theodore Tso, Johan Herland, git, Shawn O. Pearce, Miles Bader
In-Reply-To: <C3725674-7B33-4B2F-9386-704540D51C0E@zib.de>
Hi,
On Sun, 5 Aug 2007, Steffen Prohaska wrote:
>
> On Aug 5, 2007, at 6:11 PM, Theodore Tso wrote:
>
> > On Sun, Aug 05, 2007 at 02:11:24PM +0200, Johan Herland wrote:
> > > $ hg addremove --help
> > > hg addremove [OPTION]... [FILE]...
> > >
> > > add all new files, delete all missing files
> > >
> > > Add all new files and remove all missing files from the repository.
> > >
> > > New files are ignored if they match any of the patterns in .hgignore.
> > > As
> > > with add, these changes take effect at the next commit.
> > >
> > > Adding a git-addremove command should not be much work, and it would be a
> > > lot friendlier to people whose workflow is more aligned with #2 than #1.
> >
> > Not much work at all:
> >
> > # git config --system --add alias.addremove "git add . ; git add -u"
>
> But how can I handle the [FILE]... from above?
See
http://git.or.cz/gitwiki/Aliases#head-714f0aa64cb53eda636d41e16bf2b99477588685
Hth,
Dscho
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Johannes Schindelin @ 2007-08-06 0:16 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Theodore Tso, Shawn O. Pearce, Miles Bader
In-Reply-To: <200708052116.04140.johan@herland.net>
Hi,
On Sun, 5 Aug 2007, Johan Herland wrote:
> On Sunday 05 August 2007, Theodore Tso wrote:
> > On Sun, Aug 05, 2007 at 02:11:24PM +0200, Johan Herland wrote:
> > > Adding a git-addremove command should not be much work, and it would be
> > > a lot friendlier to people whose workflow is more aligned with #2 than
> > > #1.
> > Not much work at all:
> >
> > # git config --system --add alias.addremove "git add . ; git add -u"
Note that this will not work: you have to add an exclamation mark before
"git add", because it has to execute two commands.
Note also that I do _not_ suggest using --system. This option forces you
to run git as root on sane systems, which I think is wrong. Rather use
"--global" to make it globally available to _you_.
> But I'm wondering whether we'd want to include it in git by default
> (instead of having to tell confused users to add the alias).
I recommend against that, too. All too often, I have some temporary files
in the working tree, and I'll be dimmed if I'm the only one. So
"addremove" adds too much possibility for pilot errors.
My opinion here is not set in stone, though. Maybe you can convince me.
Ciao,
Dscho
^ permalink raw reply
* Re: GIT push to sftp (feature request)
From: Jakub Narebski @ 2007-08-06 0:14 UTC (permalink / raw)
To: git
In-Reply-To: <vpqir7t8vy0.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
>> Git tries to be smart in at least 2 ways that don't work with dump
>> protocols: it works locklessly (yet it performs atomic updates) and it
>> sends only the objects needed over the wire (saving a lot of
>> bandwidth).
>>
>> Using dumb protocols it's impossible to do either.
But git _can_ push over http protocol (with WebDAV), and http is a dumb
protocol, and over rsync (although it is deprecated).
> That's not exactly true. You can't be as efficient with dumb protocols
> than you are with a dedicated protocol (something with some
> intelligence on both sides), but at least the second point you mention
> can be achieved with a dumb protocol, and bzr is a proof of existance.
> To read over HTTP, it uses ranges request, and to push over
> ftp/sftp/webdav, it appends new data to existing files (its ancestor,
> GNU Arch, also had a way to be network-efficient on dumb protocols).
If I understand correctly to read (fetch) over http and other dumb
protocols (like ftp), git uses two indices .git/info/refs
and .git/objects/info/packs which must be present on the server serving
http protocol (see git-update-server-info) to calculate which packs
to get, and I think it always downloads whole packs, but I'm not sure...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Miles Bader @ 2007-08-06 0:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6mheem0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> I've written documentaiton in texinfo format in the past, and one
> thing I found quite painful was maintaining the node header with
> prev/next links --- tedious, error prone and boring.
Actually, the prev/next/up parts of @node are optional in the input file
-- if you just leave them out, makeinfo will fill them in for you.
-miles
--
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-06 0:11 UTC (permalink / raw)
To: Torgil Svensson; +Cc: Dmitry Kakurin, Marius Storm-Olsen, git
In-Reply-To: <e7bda7770708051641h15bd38abo659e74322e6232c0@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5044 bytes --]
Hi,
On Mon, 6 Aug 2007, Torgil Svensson wrote:
> On 8/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > > 1. Unpacking in a folder that have space in it's path gave various
> > > errors of this type (here, msysGit is unpacked on the desktop
> > > C:\Documents and settings\.... ) : make[1]: C:/Documents: Command
> > > not found
> >
> > Good point. Did you fix it? If so, where is the patch? Or even
> > better, what is your account on repo.or.cz so I can add it, and you
> > can commit your fix yourself?
>
> I didn't. I bypassed it (unpacked to C:\). I found the bug however
> (missed quoting):
>
> $ diff -urN msysGit msysGit-fixed
> diff -urN msysGit/git/git-gui/Makefile msysGit-fixed/git/git-gui/Makefile
> --- msysGit/git/git-gui/Makefile Fri Aug 3 15:00:16 2007
> +++ msysGit-fixed/git/git-gui/Makefile Mon Aug 6 01:22:53 2007
> @@ -4,7 +4,7 @@
> #
>
> GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
> - @$(SHELL_PATH) ./GIT-VERSION-GEN
> + @"$(SHELL_PATH)" ./GIT-VERSION-GEN
AFAICT this _fixes_ compilation in a patch containing spaces, not break
it.
> diff: msysGit/git/gitweb/test/M??rchen: No such file or directory
> diff: msysGit-fixed/git/gitweb/test/M??rchen: No such file or directory
Yes, that Märchen is a constant pain. I think it is the reason Kai
vanished: he does not want to bear the consequences of his wrong doing.
Of course, it has exposed errors regarding encoding in filenames. But
those are errors in the OSes (or in this case, MSys), and _not_ to be
fixed within git.
> I'll make an account and send you the details when I get an public
> SSH-key, haven't done that in windows before. Can I share private key on
> both windows and Linux box?
Yes. However, I inherently distrust Windows. So I made a separate
account on Windows.
NOTE: earlier installers included msys-rxvt.bat. I now _know_ for a fact
that a lot of things are strangely broken under Rxvt. For example,
creating an ssh key, of all things.
I'd be more than happy to add you to the member list.
> > > 2. rxvt-terminal had some freezes
> >
> > I did not experience those. Could you research further?
Those "freezes" were due to the fact that Rxvt incorrectly updates stderr
in a blocking way, or not at all (don't know which). There are more
things that do not work in Rxvt, and only after trying the same in cmd
(which I do not like for various reasons) I found out that rxvt.exe is at
fault.
I would be glad if somebody managed to compile rxvt herself and fix all
those bugs (see http://code.google.com/p/msysgit/ for a short list of the
most pressing issues I found). As it is, I have enough work to do with
the rest of msysGit, and for the moment, I can at least work in cmd. Even
ssh push works.
> Some observations:
> "git log" on mingw archive trigger this every time for me (hangs on
> different places each time).
Never experienced those.
> "cmd" terminal (msys.bat) seems to pipe "git log" to less while rxvt
> terminal outputs lots of text very fast (msys-rxvt.bat) and freezes.
> Output:ing lots of text itself doesn't seem to be an issue ("make -d"
> doesn't freeze and outputs _lots_ of text)
It never froze for me. However, as stated, Rxvt is too workaroundable for
me to work on it (although I like Rxvt better than cmd). Any help
appreciated very much.
> > > 3. "gitk --all" said "Error reading commits: fatal: write failure on
> > > stdout: Invalid argument"
> >
> > I did not even bother testing gitk... Any idea what is going wrong?
gitk worked fine for me, as long as I had _any_ refs in the repo.
> The fconfigure -blocking command seems to be not supported under
> mingw. This patch makes the error go away. Another issue that is
> probably related to this is that gitk doesn't list all commits. I
> don't know how to solve this properly.
>
> diff --git a/gitk b/gitk
> index 43d88ca..69e5149 100755
> --- a/gitk
> +++ b/gitk
> @@ -147,7 +147,7 @@ proc getcommitlines {fd view} {
> unset commfd($view)
> notbusy $view
> # set it blocking so we wait for the process to terminate
> - fconfigure $fd -blocking 1
> + #fconfigure $fd -blocking 1
I have to wonder how you called it... From msys.bat, cd'ing into a valid
repository, I had no issues whatsoever.
> > > 4. Mouse-wheel didn't work to scroll views in gitk
> >
> > Again, no idea why. Could you please investigate?
>
> Tough one since I didn't take the tcl tk debugging class. Doesn't work
> for me in cygwin either. I don't know if it's implemented at all. Does
> it work for anyone else?
I just tested via VNC, and indeed, it does not work. My guess is that
MinGW's Tk version has a different number assigned to the scroll wheel
(the scroll wheel is usually implemented as constant fire on a special
mouse button; AFAICT buttons 4 and 5 are assumed to be the scroll buttons
in gitk).
Now, I do not know what these are called on Windows, but there should be a
thing like "xev" on Windows, too... Anybody?
Ciao,
Dscho
^ permalink raw reply
* Re: GIT push to sftp (feature request)
From: Martin Langhoff @ 2007-08-06 0:00 UTC (permalink / raw)
To: Martin Langhoff, pavlix, git
In-Reply-To: <vpqir7t8vy0.fsf@bauges.imag.fr>
On 8/6/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> > Git tries to be smart in at least 2 ways that don't work with dump
> > protocols: it works locklessly (yet it performs atomic updates) and it
> > sends only the objects needed over the wire (saving a lot of
> > bandwidth).
> >
> > Using dumb protocols it's impossible to do either.
>
> That's not exactly true. You can't be as efficient with dumb protocols
You are right -- I should have said: it's pretty hard, and we haven't
put the effort ;-)
there's been discussion recently of having info in the pack index that
would support http range requests.
> (its ancestor,
> GNU Arch, also had a way to be network-efficient on dumb protocols).
Do I remember your name from gnuarch-users? -- that Arch/tla was never
particularly efficient, and fetches of large updates were slow and
painful. Surely it was efficient on paper though :-p
> Regarding atomic and lock-less updates, I believe this is
> implementable too as soon as you have an atomit "rename" in the
> protocol. But here, bzr isn't a proof of existance, it does locking.
And I should have said - minimal locking rather than no locking
To update it safely, you need to open with a lock, read to ensure the
sha1 is what you think it is, write the new sha1, close. A rename is
still subject to race conditions.
IMVHO it would be good to have a way to push over sftp even it it is
slow, unsafe and full of big blinking warnings. git itself is sane
enough that the client side won't get corrupted or lose data if there
is a race condition on the server side.
Given a brief delay, the client can probably check - post push - that
the operation wasn't clobbered by a race condition. Of course, this
*is* sticks-and-bubblegum approach on the server side. But a solid
client repo makes almost any server-side disaster recoverable.
cheers,
martin
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Miles Bader @ 2007-08-06 0:00 UTC (permalink / raw)
To: git
In-Reply-To: <200708052116.04140.johan@herland.net>
Johan Herland <johan@herland.net> writes:
>> # git config --system --add alias.addremove "git add . ; git add -u"
>
> But I'm wondering whether we'd want to include it in git by default (instead
> of having to tell confused users to add the alias).
An easier-to-type name e.g. "addrm" would be good though...
-miles
--
`Life is a boundless sea of bitterness'
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Torgil Svensson @ 2007-08-05 23:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Kakurin, Marius Storm-Olsen, git
In-Reply-To: <Pine.LNX.4.64.0708040123560.14781@racer.site>
On 8/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
Hi
Thank you for your reply.
> > 1. Unpacking in a folder that have space in it's path gave various
> > errors of this type (here, msysGit is unpacked on the desktop
> > C:\Documents and settings\.... ) : make[1]: C:/Documents: Command not
> > found
>
> Good point. Did you fix it? If so, where is the patch? Or even better,
> what is your account on repo.or.cz so I can add it, and you can commit
> your fix yourself?
I didn't. I bypassed it (unpacked to C:\). I found the bug however
(missed quoting):
$ diff -urN msysGit msysGit-fixed
diff -urN msysGit/git/git-gui/Makefile msysGit-fixed/git/git-gui/Makefile
--- msysGit/git/git-gui/Makefile Fri Aug 3 15:00:16 2007
+++ msysGit-fixed/git/git-gui/Makefile Mon Aug 6 01:22:53 2007
@@ -4,7 +4,7 @@
#
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
- @$(SHELL_PATH) ./GIT-VERSION-GEN
+ @"$(SHELL_PATH)" ./GIT-VERSION-GEN
-include GIT-VERSION-FILE
uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
diff: msysGit/git/gitweb/test/M?¤rchen: No such file or directory
diff: msysGit-fixed/git/gitweb/test/M?¤rchen: No such file or directory
I'll make an account and send you the details when I get an public
SSH-key, haven't done that in windows before. Can I share private key
on both windows and Linux box?
> > 2. rxvt-terminal had some freezes
> I did not experience those. Could you research further?
Some observations:
"git log" on mingw archive trigger this every time for me (hangs on
different places each time).
"cmd" terminal (msys.bat) seems to pipe "git log" to less while rxvt
terminal outputs lots of text very fast (msys-rxvt.bat) and freezes.
Output:ing lots of text itself doesn't seem to be an issue ("make -d"
doesn't freeze and outputs _lots_ of text)
> > 3. "gitk --all" said "Error reading commits: fatal: write failure on
> > stdout: Invalid argument"
> I did not even bother testing gitk... Any idea what is going wrong?
The fconfigure -blocking command seems to be not supported under
mingw. This patch makes the error go away. Another issue that is
probably related to this is that gitk doesn't list all commits. I
don't know how to solve this properly.
diff --git a/gitk b/gitk
index 43d88ca..69e5149 100755
--- a/gitk
+++ b/gitk
@@ -147,7 +147,7 @@ proc getcommitlines {fd view} {
unset commfd($view)
notbusy $view
# set it blocking so we wait for the process to terminate
- fconfigure $fd -blocking 1
+ #fconfigure $fd -blocking 1
if {[catch {close $fd} err]} {
set fv {}
if {$view != $curview} {
$ grep '\-blocking' gitk | wc -l
10
(all sets blocking to 0 except for the one in getcommitlines above)
> > 4. Mouse-wheel didn't work to scroll views in gitk
>
> Again, no idea why. Could you please investigate?
Tough one since I didn't take the tcl tk debugging class. Doesn't work
for me in cygwin either. I don't know if it's implemented at all. Does
it work for anyone else?
//Torgil
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Junio C Hamano @ 2007-08-05 23:38 UTC (permalink / raw)
To: David Kastrup
Cc: Linus Torvalds, Steven Grimm, Sam Ravnborg, Ismail D?nmez, git
In-Reply-To: <85bqdlj1lh.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
>> So stop this *insane* insistence of emacs. You should learn to just
>> assume that people don't even have it installed!
>
> We were discussing Texinfo, not Emacs. Please focus.
I would welcome if the set of our documentation output formats
included *.info pages.
However, as the input format, texinfo _is_ painful. AsciiDoc is
100x easier. I've written documentaiton in texinfo format in
the past, and one thing I found quite painful was maintaining
the node header with prev/next links --- tedious, error prone
and boring. There is no good editor to help you maintain them
other than Emacs texinfo mode as far as I know.
^ permalink raw reply
* git-blame and blame GUI wishlist
From: Jakub Narebski @ 2007-08-05 22:09 UTC (permalink / raw)
To: git
1. In git-gui blame viewer you can click on shortened sha1 of a commit
to see file at given version. Unfortunately git-gui goes to other
version of a file by reblaming a file starting from scratch.
It would be nice to have
git blame --incremental=<revision1> <revision2> -- <file>
which would blame only lines which differ between <revision1>
and <revision2>. We can assume that <revision2> is ancestor of
<revision1>, I think. I'm not completely sure if it is possible
and reasonable, i.e. if one can assume that only lines which
differ need reblaming...
And of course use this feature in "git-gui blame" which should
speed up exploring file history a bit.
2. Sometimes I'm interested only in part of a file. Thus I'd like
"git-gui blame" to understand line-range parameter of git-blame.
It means that I'd like to be able to say for example:
git gui blame -L '/^sub git_feed/,/^}$/' HEAD -- gitweb/gitweb.perl
and have only given range of lines blamed, with the rest grayed out
in the "inactive control" style. Of course in the case I specified
line range incorrectly, I'd like to have menu entry or a button to
reblame _whole_ file... Or perhaps do blaming of a whole file in the
background, after blaming specified range fo lines.
This should speed up "git gui blame" a bit. By the way, of course
git-gui should start with the selected line-range visible.
3. Sometimes when reviewing patches I do wonder: why the preimage looks
like it looks like. It would be useful in that situation to be able
to blame the patch (context lines and pre-image lines). Although I'm
not suer if it would bevery useful and used often [enough].
P.S. qgit uses some bottom-up all-files mechanism to get the blame of
all the files together. Could anyone describe in few sentences the
algorithm qgit uses? Would it be useful to put it available e.g. in
gitlib-thin for other viewers, or not; what do you think?
P.P.S. Of couse the examples and ideas are not limited to "git gui
blame"...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Document GIT_SSH environment variable alongside other variables
From: Jakub Narebski @ 2007-08-05 22:16 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20070804060652.GA28379@spearce.org>
Shawn O. Pearce wrote:
> The GIT_SSH environment variable has survived for quite a while
> without being documented, but has been mentioned on list and on
> my day-job repositories can only be accessed via magic supplied
> through the wonderous hack that is GIT_SSH.
Thanks a lot.
By the way, I plan on documenting existing environmental variables used
by git better (for after 1.5.3). First, separate "Environmental
variables" section in Documentation/git.txt into separate file (similar
to the config.txt file), named environment.txt. Second, add to the list
of variables links to variables which are documented in other manpages,
similarly to how for example GIT_AUTHOR_NAME etc. are described. Then
add one by one environmental variables which are not documented at all:
GIT_SSH_PUSH/GIT_SSH_PULL, GIT_CURL_VERBOSITY, GIT_REFLOG_ACTION,
GIT_GRAFT_FILE and GIT_TEMPLATE_DIR.
--
Jakub Narebski
Poland
^ permalink raw reply
* [RFC (take 4)] Git User's Survey 2007
From: Jakub Narebski @ 2007-08-05 20:51 UTC (permalink / raw)
To: git
In-Reply-To: <200707250358.58637.jnareb@gmail.com>
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.
First there is a question about the form of survey. Should we use web
based survey, as the survey before (http://www.survey.net.nz), sending
emails with link to this survey, or perhaps do email based survey,
with email Reply-To: address put for this survey alone?
Second, what questions should be put in the survey, and in the case of
single choice and multiple choice questions what possible answers
should be? Below are slightly extended questions from the last
survey. Please comment on it.
Third, where to send survey to? I was thinking about git mailing list,
LKML, and mailing list for git projects found on GitProjects page on
GIT wiki. Do you want to add some address? Or should info about GIT
User's Survey 2007 be sent also to one of on-line magazines like
LinuxToday, or asked to put on some blog?
Those lists include:
wine-users, xmms2-devel, xcb (freedesktop), cairo, u-boot-users,
git mailing list, lklm (emails thanks to Paolo Ciarrocchi)
LWN, NewsForge, Slashdot, OSNews,
Those lists might include:
CRUX Linux, Source Mage Linux, DirectFB, GNU LilyPond, OLPC,
Thousands Parsec, X.Org, Mesa3D, Beryl -> Compiz Fusion,
Other possibilities:
OpenOffice.org, Mozilla (MozillaZine), SeaMonkey,
KDE (dot.kde.net), GNOME, Blue GNU
Hmmm... the list of questions got a bit long: 65 questions
so far (some of those are optional and depend on answers to
other question). Isn't it too much?
References:
http://marc.info/?l=git&m=115116592330648&w=2
http://marc.info/?l=git&m=115364303813936&w=2
http://git.or.cz/gitwiki/GitSurvey
----
Hi all,
We would like to ask you a few questions about your use of the GIT
version control system. This survey is mainly to understand who is
using GIT, how and why.
The results will be published to the GIT wiki and discussed on the git
mailing list.
We'll close the survey in three weeks starting from today, <date>.
Please devote a few minutes of your time to fill this simple
questionnaire, it will help a lot the git community to understand your
needs, what you like of git, and of course what you don't like of it.
The survey can be found here:
http://www.survey.net.nz/survey.php? <number>
----
About you
1. What country are you in?
2. What is your preferred non-programming language?
3. How old are you?
4. Which programming languages you are proficient with?
(The choices include programming languages used by git)
(zero or more: multiple choice)
- C, shell, Perl, Python, Tcl/Tk
Getting started with GIT
1. How did you hear about GIT?
2. Did you find GIT easy to learn?
- very easy/easy/reasonably/hard/very hard
3. What helped you most in learning to use it?
4. What did you find hardest?
5. When did you start using git? From which version?
* (date, or version, or both)
Other SCMs
1. What other SCM did you use?
2. What other SCM do you use currently?
3. What other SCM do you use as a main SCM for your project
instead of git, if any?
4. Why did you choose this SCM?
* example: better MS Windows support
5. What would you require from git to enable you to change,
if you use other SCM for your project?
6. Did you import your repository from foreign SCM?
7. What tool did you use for import?
8. Do your git repository interact with other SCM?
9. What tool did/do you use?
How you use GIT
1. Do you use GIT for work, unpaid projects, or both?
work/unpaid projects/both/none(*)
(*)I use git to interact with some project I'm interested in
2. How do you obtain GIT? Source tarball, binary package, or
pull the main repository?
- binary package/source tarball/pull from main repository
3. What hardware platforms do you use GIT on?
* examples: i386, x86_64, ARM, PowerPC, Alpha, g5, ...
4. What OS (please include the version) do you use GIT on?
* examples: Linux, MS Windows (Cygwin/MinGW/gitbox),
IRIX, HP-UX, Solaris, FreeBSD, ...
(please give kernel version and distribution for Linux)
5. What projects do you track (or download) using GIT
(or git web interface)?
6. How many people do you collaborate with using GIT?
7. How big are the repositories that you work on? (e.g. how many
files, how much disk space, how deep is the history?)
* number of files in repository: "git ls-tree -r HEAD | wc -l"
* largest file under version control
* pack size of freshly cloned fully packed repository
* number of commits in straight line, number of commits in branch
("git rev-list --first-parent HEAD | wc -l",
"git rev-list HEAD | wc -l")
8. How many different projects do you manage using GIT?
9. Which porcelains do you use?
(zero or more: multiple choice)
- core-git, cogito (deprecated), StGIT, guilt, pg (deprecated),
my own scripts, other
10. Which git GUI do you use
(zero or more: multiple choice)
- gitk, git-gui, qgit, gitview, giggle, tig, instaweb,
(h)gct, qct, KGit, git.el, other
11. Which (main) git web interface do you use for your projects?
- gitweb/cgit/wit (Ruby)/git-php/other
12. How do you publish/propagate your changes?
(zero or more: multiple choice)
- push, pull request, format-patch + email, bundle, other
13. Does git.git repository include code produced by you?
- yes/no
Internationalization
1. Is translating GIT required for wider adoption?
- yes/no/somewhat
2. What do you need translated?
* examples: git-gui, qgit, git messages, manpages,
user's manual
3. For what language do you need translation for?
What you think of GIT
1. Overall, how happy are you with GIT?
- unhappy/not so happy/happy/very happy/completely ecstatic
2. How does GIT compare to other SCM tools you have used?
- worse/equal (or comparable)/better
3. What do you like about using GIT?
4. What would you most like to see improved about GIT?
(features, bugs, plug-ins, documentation, ...)
5. If you want to see GIT more widely used, what do you
think we could do to make this happen?
Changes in GIT (since year ago, or since you started using it)
1. Did you participate in previous Git User's Survey?
- yes/no
2. What improvements you wanted got implemented?
3. What improvements you wanted didn't get implemented?
4. How do you compare current version iwth version from year ago?
- current version is: better/worse/no changes
5. Which of the new features do you use?
(zero or more: multiple choice)
- git-gui, bundle, eol conversion, gitattributes,
submodules, worktree, release notes, user's manual,
reflog, stash, shallow clone, detached HEAD, fast-import,
mergetool, interactive rebase, commit template, blame improvements,
other (not mentioned here)
6. If you selected "other", what are those features?
Documentation
1. Do you use the GIT wiki?
- yes/no
2. Do you find GIT wiki useful?
- yes/no/somewhat
3. Do you contribute to GIT wiki?
- yes/no/only corrections or spam removal
4. Do you find GIT's on-line help (homepage, documentation) useful?
- yes/no/somewhat
5. Do you find help distributed with GIT useful
(manpages, manual, tutorial, HOWTO, release notes)?
- yes/no/somewhat
6. Do you contribute to GIT documentation?
- yes/no
7. What could be improved on the GIT homepage?
8. What topics would you like to have on GIT wiki?
9. What could be improved in GIT documentation?
Getting help, staying in touch
1. Have you tried to get GIT help from other people?
- yes/no
2. If yes, did you get these problems resolved quickly
and to your liking?
- yes/no
3. Would commerical (paid) support from a support vendor
be of interest to you/your organization?
4. Do you subscribe to the mailing list?
- yes/no
5. Do you read the mailing list? What method do you use?
- subscribed/news interface/RSS interface/archives/
/post + reply-to request/digests/I don't read it
6. If yes, do you find it useful?
- yes/no (optional)
7. Do you find traffic levels on GIT mailing list OK.
- yes/no? (optional)
8. Do you use the IRC channel (#git on irc.freenode.net)?
- yes/no
9. If yes, do you find IRC channel useful?
- yes/no (optional)
10. Did you have problems getting GIT help on mailing list or
on IRC channel? What were it? What could be improved?
Open forum
1. What other comments or suggestions do you have that are not
covered by the questions above?
--
Jakub Narebski
^ permalink raw reply
* Re: [RFC (take 3)] Git User's Survey 2007
From: Jakub Narebski @ 2007-08-05 20:06 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85sl6ziw7x.fsf@lola.goethe.zz>
On Sat, 4 August 2007, David Kastrup wrote:
>
> I miss a question about developer and mailing list attitude. That is
> often inversely proportional to the quality of help and support: one
> has forums where lots of friendly people without much of a clue hang
> out, and then there are some where one can always get competent and
> fast help in one package with an ulcer.
What about a compromise (question)?
----
Getting help, staying in touch
[...]
10. Did you have problems getting GIT help on mailing list or
on IRC channel? What were those problems? What could be improved?
----
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: J. Bruce Fields @ 2007-08-05 22:31 UTC (permalink / raw)
To: David Kastrup; +Cc: bkorb, Linus Torvalds, git
In-Reply-To: <857io9hblv.fsf@lola.goethe.zz>
On Mon, Aug 06, 2007 at 12:15:24AM +0200, David Kastrup wrote:
> Or things like including the manual pages in an appendix or elsewhere.
> Any chance for that? Slim, at least for me.
I'd like to do exactly that at some point. I was hoping it would be as
simple as just adding a bunch of include:: statements, but there's
probably some more obstacles. If someone had the time to look into what
would be required to get it working, I'd be grateful.
--b.
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: J. Bruce Fields @ 2007-08-05 22:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, gitster, git
In-Reply-To: <20070805222213.GA12168@fieldses.org>
On Sun, Aug 05, 2007 at 06:22:13PM -0400, J. Bruce Fields wrote:
> On Sun, Aug 05, 2007 at 02:58:11PM +0100, Johannes Schindelin wrote:
> > On Sun, 5 Aug 2007, Steffen Prohaska wrote:
> >
> > > git gui is especially useful because it allows to select diff hunks.
> >
> > You should give a _big_ _fat_ _red_ warning there.
> >
> > If you selectively commit diff hunks, you _never_ tested what you
> > committed.
>
> A big warning would be out of place in what is for now just an isolated
> sentence in two different places. But I agree with you that this would
> be worth mentioning in any eventual full-fledged git-gui tutorial.
(Oh, and my own attempt, along with a couple other minor manual updates,
is in the master branch at
git://linux-nfs.org/~bfields/git.git master
Feel free to take that whenever, if it looks OK, Junio.)
--b.
^ permalink raw reply
* Re: GIT push to sftp (feature request)
From: Matthieu Moy @ 2007-08-05 22:20 UTC (permalink / raw)
To: Martin Langhoff; +Cc: pavlix, git
In-Reply-To: <46a038f90708051412p722aa906v73e986a805f1558b@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> Git tries to be smart in at least 2 ways that don't work with dump
> protocols: it works locklessly (yet it performs atomic updates) and it
> sends only the objects needed over the wire (saving a lot of
> bandwidth).
>
> Using dumb protocols it's impossible to do either.
That's not exactly true. You can't be as efficient with dumb protocols
than you are with a dedicated protocol (something with some
intelligence on both sides), but at least the second point you mention
can be achieved with a dumb protocol, and bzr is a proof of existance.
To read over HTTP, it uses ranges request, and to push over
ftp/sftp/webdav, it appends new data to existing files (its ancestor,
GNU Arch, also had a way to be network-efficient on dumb protocols).
Regarding atomic and lock-less updates, I believe this is
implementable too as soon as you have an atomit "rename" in the
protocol. But here, bzr isn't a proof of existance, it does locking.
(BTW, about bzr, it also has a dedicated server now)
--
Matthieu
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: J. Bruce Fields @ 2007-08-05 22:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, gitster, git
In-Reply-To: <Pine.LNX.4.64.0708051457110.14781@racer.site>
On Sun, Aug 05, 2007 at 02:58:11PM +0100, Johannes Schindelin wrote:
> On Sun, 5 Aug 2007, Steffen Prohaska wrote:
>
> > git gui is especially useful because it allows to select diff hunks.
>
> You should give a _big_ _fat_ _red_ warning there.
>
> If you selectively commit diff hunks, you _never_ tested what you
> committed.
A big warning would be out of place in what is for now just an isolated
sentence in two different places. But I agree with you that this would
be worth mentioning in any eventual full-fledged git-gui tutorial.
--b.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-05 22:15 UTC (permalink / raw)
To: bkorb; +Cc: Linus Torvalds, git
In-Reply-To: <46B6446D.4030607@gnu.org>
Bruce Korb <bkorb@gnu.org> writes:
> Linus Torvalds wrote:
>
>> AsciiDoc is *also* a source format. But the source format is
>> already readable IN ITSELF. Which is the whole point!
>
> Readable, just not writable. It's markup language is a bunch of
> special characters that require familiarity to understand.
Well, one problem I find that the documentation of both Asciidoc and
the connected Docbook toolchain is horribly subpar.
One part of the problem is that asciidoc.txt is written in Asciidoc,
and so you can't pick apart markup from content in the explanations
when reading the "readable in itself" documents.
Another problem is that most of the details of conversion to Docbook,
and what results in what XML output, are completely glossed over. And
then there are further problems in that downstream Docbook processors
are documented even worse.
Then there is the problem that the markup can be redefined: the
sectioning underlines explained in the asciidoc documentation differ
from that _used_ in the documentation and again from that used in the
git documentation.
Now I can, in fact, use
docbook2x-texi --info --to-stdout user-manual.xml >user-manual.info
and get a working info file: not just basically working, but quite
fine (missing an index, though).
So there are "minor details" to fill in, like generated file names and
info directory entries. Would you think that there is _any_ way of
finding out how to represent this in Docbook, or if you find out that,
how to get it from Asciidoc into Docbook?
Forget it.
Or things like including the manual pages in an appendix or elsewhere.
Any chance for that? Slim, at least for me.
Texinfo source certainly looks less pretty than Asciidoc, but then
makeinfo can produce plain text output from it looking quite like
Asciidoc. And whatever you may think about Texinfo as a format and
the generated info files and their readers: it is damn well
documented.
Asciidoc is quite readonly in many respects at the moment for me, and
I don't even know where to start in order to fix that.
And it does not help that there are multiple conversions involved with
a pretty opaque in-between XML representation. In contrast, Texinfo
has a single well-documented source format and direct converters to
the target formats.
And its syntax is straightforward enough to write additional
converters if one wants to (makeinfo can even produce Docbook output,
so perhaps I may have a chance to reverse-engineer some required
information from there).
Whatever. It is pretty clear that Texinfo is not going to be
interesting enough to maintain for most git developers to continue
this particular thread, as it won't progress beyond a simple and ugly
advocacy and name-calling thread.
Anyway, the necessary structural information (indexing, directory info
etc) presumably can be spliced into Asciidoc documents once somebody
finds out how to do this, and then Texinfo can be _generated_ from it
for those who need it.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: How to figure out what 'git push' would do?
From: Alex Riesen @ 2007-08-05 22:09 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <515E28B6-85AF-4379-870A-CFECF19B74DE@zib.de>
Steffen Prohaska, Sun, Aug 05, 2007 21:56:37 +0200:
> >
> > $ git fetch
> > $ gitk local..REPO/master
> >
>
> That applies only for a single branch. If I prepared a couple of
> branches for pushing and somehow want to double check what I prepared,
> 'git push --dry-run' would be quite handy. I know how to handle the
> situation and could write a custom script that does all necessary
> checks. But I haven't found an out-of-the-box solution for double
> checking right before 'git push'
Well, you can do gitk local1..REPO/remote1 local2..REPO/remote2,
of course, but yes, there is not out-of-the-box solution.
And a straight-forward implementation of "git-push --dry-run" doesn't
look simple... The remote sides git-receive-pack still have to be
called for any useful information, like the references updated and the
SHA-1s they get. IOW, if you can update your system easily to support
--dry-run, it still does not mean the server admin will do that just
as readily. And AFAICS, receive-pack dies if given a parameter it
does not know (it dies on every command line argument which begins
with "-", as it looks). Maybe we should change that first for a very
slow start...
It is simplier to modify git-ls-remote of git-remote to just compare
reference on local and remote side.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Bruce Korb @ 2007-08-05 21:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0708051221290.5037@woody.linux-foundation.org>
Linus Torvalds wrote:
>> Yes, name-calling and ad hominem attacks again.
>
> No. Emacs _is_ odd. It's not even installed by default on most modern
> Linux distributions.
Hi Linus,
Thus disparaging distributions that do install it. I've not had
to pull any extra packages to get it so far, but I only update
every few years. I've been a happy emacs user for 24 years.
> There's no name-calling there. That's just a solid fact.
The name calling is unseemly on all sides.
>> Please try to remember that Texinfo is a _source_ format, and it
>> produces reasonably hyperrefed and coherent PDF and HTML documents as
>> well as plain ASCII. That it is also able to produce working info
>> files should not bother you.
>
> You do not even know what you are talking about.
>
> AsciiDoc is *also* a source format. But the source format is already
> readable IN ITSELF. Which is the whole point!
Readable, just not writable. It's markup language is a bunch
of special characters that require familiarity to understand.
Sure, you can peruse the text just fine, but why should this
sort of thing:
= My Doc Title =
be preferred to:
@settitle My Doc Title
@chapter, @section, @subsection really make a lot more sense to me
than this sort of cruft (my disparaging term):
Level 0 (top level): ======================
Level 1: ----------------------
Level 2: ~~~~~~~~~~~~~~~~~~~~~~
Level 3: ^^^^^^^^^^^^^^^^^^^^^^
Level 4 (bottom level): ++++++++++++++++++++++
It really boils down to preferences and familiarity and should
not degenerate into nasty name calling.
> Headers? Lists? They look like headers and lists in the .txt files. No
> need to think about it as a reader.
So do well-formatted .texi docs. I don't really like anything
other than WYSIWYG, but that doesn't lend it self to reformatting
into man pages et al.
> See? Texinfo is decidedly inferior. But you don't have to take it so
> personally. So is pretty much anything else. Anything XML/SGML is even
> *worse*.
Bah! They all have their drawbacks and preferences are going to weight
drawbacks differently.
So let's all dislike all our choices, eh? Cheers - Bruce
^ permalink raw reply
* Re: GIT push to sftp (feature request)
From: Martin Langhoff @ 2007-08-05 21:12 UTC (permalink / raw)
To: pavlix; +Cc: git
In-Reply-To: <200708051105.44376.pavlix@pavlix.net>
On 8/5/07, pavlix <pavlix@pavlix.net> wrote:
> Did I miss something?
Unfortunately, git does not "push" over protocols that cannot execute
git on the remote server. We call them "dumb protocols" and if you
search this list for that name, you'll find lots.
Git tries to be smart in at least 2 ways that don't work with dump
protocols: it works locklessly (yet it performs atomic updates) and it
sends only the objects needed over the wire (saving a lot of
bandwidth).
Using dumb protocols it's impossible to do either. And these days it's
not that hard to setup git (or any other binary) to execute at the
remote end.
Bazaar-NG and others do support dumb protocols, and (I think) they do
it by using one big lock over the repo. But the lock is not safe, and
things can (and do) go wrong with weak locking schemes.
git used to support rsync -- but I don't think that works anymore for
pushes. Other than git over ssh, perhaps you can try the apache module
that implements git over http?
hope that helps,
martin
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Johan Herland @ 2007-08-05 19:16 UTC (permalink / raw)
To: git; +Cc: Theodore Tso, Shawn O. Pearce, Miles Bader
In-Reply-To: <20070805161117.GE28263@thunk.org>
On Sunday 05 August 2007, Theodore Tso wrote:
> On Sun, Aug 05, 2007 at 02:11:24PM +0200, Johan Herland wrote:
> > Adding a git-addremove command should not be much work, and it would be
> > a lot friendlier to people whose workflow is more aligned with #2 than
> > #1.
> Not much work at all:
>
> # git config --system --add alias.addremove "git add . ; git add -u"
>
> :-)
Nice :)
But I'm wondering whether we'd want to include it in git by default (instead
of having to tell confused users to add the alias).
> (And the performance problem with git add . is fixed in 1.5.3-rc4,
> right?)
Yes, according to Junio elsewhere in this thread.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Problem with bisect
From: Larry Finger @ 2007-08-05 20:33 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Sean, git
In-Reply-To: <20070805194454.GI25680@cip.informatik.uni-erlangen.de>
Thomas Glanzmann wrote:
> Hello,
>
>> I'm using git version 1.4.4.2.g04509
>
> 1.4 has a issue with bisect at least the Debian 1.4 versio. Update to
> 1.5 and try again.
I'm now using git version 1.5.3.rc4 and still have the same situation.
Larry
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-05 20:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <85y7gphkdd.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> So by advocating Texinfo, you're advocating something that is
>> OBJECTIVELY WORSE than what we have now.
>>
>> And I tried to explain why, by pointing out that info files (which
>> was the case you tried to push as an advantage) aren't actually an
>> advantage to any normal user.
>
> Linus, your "normal user" does not get any documentation that can
> usefully be employed for navigating a large body of documentation.
>
> Anyway, this particular flame feast might be somewhat irrelevant: I
> have read up a bit on AsciiDoc and Docbook.
Ok, it turns out that
docbook2x-texi --info --to-stdout usermanual.xml >usermanual.info
cranks out (after a few inexplicable warnings/errors) a completely
functional info file. The one thing that is conspicously missing is
indexing and info-dir information, and that's because it is not in the
source in the first place.
Whether you want to believe it or not, this already helps me
_considerably_ find my way around git.
So info, at least for the manual, can at the current point of time be
supported by merely adding Makefile targets.
Since an index is useful for other output formats, I don't think that
there should be objections to adding indexing info into the manual.
This takes the AsciiDoc form of ((primary)) for a primary entry
appearing in the text, and (((primary[, secondary[, third]]))) for a
hierarchical entry not appearing in the text itself.
Correct?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] send-email: let sanitize_address_rfc822 do rfc2047 quoting
From: Uwe Kleine-König @ 2007-08-05 20:09 UTC (permalink / raw)
To: git; +Cc: Uwe Kleine-König
Without this patch I'm not able to properly send emails as I have a
non-ascii character in my name.
The former version tried to fix-up the real name part with double quotes
if it includes a '.'. I removed this as rfc2047 can handle a dot, too.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
---
Hello,
I already sent a similar patch that was discussed a bit[1], but was not taken.
The list of allowed character was taken from Python's email package.
Comparing with the former version I removed the quoting as described in
the 2nd paragraph of the log and now I only test $recipient_name once.
I will try to send this patch with next + this patch. I think it should
work in principle, but --suppress-from is not honored. I will take a
look on this issue later.
Best regards
Uwe
[1] http://thread.gmane.org/gmane.comp.version-control.git/52093
git-send-email.perl | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index f43f92f..5785e29 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -459,16 +459,27 @@ sub unquote_rfc2047 {
return "$_";
}
-# If an address contains a . in the name portion, the name must be quoted.
+# The name part of an address must consist only of alnum chars, space and a few
+# others.
+# If it contains a "forbidden" char in the name port, quote it according to
+# rfc2047.
sub sanitize_address_rfc822
{
my ($recipient) = @_;
- my ($recipient_name) = ($recipient =~ /^(.*?)\s+</);
- if ($recipient_name && $recipient_name =~ /\./ && $recipient_name !~ /^".*"$/) {
- my ($name, $addr) = ($recipient =~ /^(.*?)(\s+<.*)/);
- $recipient = "\"$name\"$addr";
+ my ($recipient_name, $recipient_addr) = ($recipient =~ /^(.*?)(\s+<.*)/);
+
+ if ($recipient_name) {
+ if ($recipient_name =~ /[^-a-zA-Z0-9!*+\/ ]/ && $recipient_name !~ /=\?utf-8\?q?.*\?=/) {
+ $recipient_name =~ s/([^-a-zA-Z0-9!*+\/ ])/sprintf("=%02X", ord($1))/eg;
+ $recipient_name =~ s/ /_/;
+ $recipient_name =~ s/(.*)/=\?utf-8\?q\?$1\?=/;
+ }
+
+ return "$recipient_name$recipient_addr";
+
+ } else {
+ return "$recipient";
}
- return $recipient;
}
sub send_message
--
1.5.3.rc3.13.g7ab3
^ permalink raw reply related
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