* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 14:07 UTC (permalink / raw)
To: Marek Zawirski; +Cc: Junio C Hamano, git, Stephan Beyer
In-Reply-To: <48886B8F.6000304@gmail.com>
On Tue, 24 July 2008, Marek Zawirski wrote:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>> (...)
>>
>>> 27. Which of the following features do you use?
>>> (zero or more: multiple choice)
>>> - git-gui or other commit tool, gitk or other history viewer, patch
>>> management interface (e.g. StGIT), bundle, eol conversion,
>>> gitattributes, submodules, separate worktree, reflog, stash,
>>> shallow clone, detaching HEAD, mergetool, interactive rebase,
>>> add --interactive or other partial commit helper, commit
>>> templates, bisect, other (not mentioned here)
>>>
> I've got lost a little bit in this discussion, but some question about
> used GUI for Git maybe interesting - the above one is touching the
> problem. Just egit is missing there.
Actually jgit is in the list of possible choices for the following
question:
16. Which porcelains / interfaces / implementations do you use?
But you have remind me about one feature that is missing from the 27.
list, namely "integration with IDE/editor" (I mean here things like
egit for Eclipse, future KDevelop DVCS integration, future Anjuta
Git integration, git.el or DVC for Emacs, plugin for TextMate, etc.)
--
Jakub Narebski
Poland
^ permalink raw reply
* [EGIT] Supported Eclipse version
From: Marek Zawirski @ 2008-07-24 13:57 UTC (permalink / raw)
To: git, Robin Rosenberg, Shawn O. Pearce
This topic arose after 3.4 release. Are we dropping support for 3.2.x
release or not?
I've recently reported some bug at eclipse.org bugzilla regarding broken
FileDialog for 3.3.x and it was closed, marked as resolved in 3.4 with
comment that 3.3.x stream is finished. Actually, this bug is not
critical, just annoying.
It just seems that eclipse.org is trying to force users to update their
Eclipse soon after next stable release.
3.3 also added some interesting APIs, Robin mentioned it one day. I'm
currently just touching TableViewer API and it also have some nice new
features being available since 3.3.
Do we still have to be compatible with 3.2 release? It's about 2 years
old, with last synchronized release/build February 2007. On the other
hand, some commercial tools are still based upon 3.2 release.
Maybe some users (or developers) from mailing list can tell us about
their opinion?
Marek Zawirski
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 13:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807241443230.8986@racer>
On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
>
>
> > On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > > No, I did mean the index. This is an attribute of the index:
> > > > > either it is sparsely checked out or not. You can even have
> > > > > multiple indices (switching between them by setting
> > > > > GIT_INDEX_FILE) which have different prefixes.
> > > >
> > > > I don't think so. It's a mask for workdir, right? If you save it it
> > > > index, you can switch index and the prefix as well, but workdir
> > > > only has several subtrees that do not fit any other prefix than the
> > > > original prefix.
> > >
> > >
> > > Ah, you adroitly avoided addressing the issue that the user can change
> > > the prefix without the index ever noticing.
> >
> > Forgive my ignorance. I still do not get why index must notice prefix
> > change? The only reason I can think of is that we must make sure there
> > won't be any user-modification in index outside the prefix. But that can
> > be guarded from higher level (plumbings and porcelains) because index is
> > allowed to have modification outside sparse prefix (auto-merged
> > entries).
>
>
> Why do you want to guard it from the outside? When the obvious fix is to
> put together what belongs together?
OK. I am lost here. I do not know how putting sparse prefix and index
together could fix "it" (I think you meant the index guarding). But we
are in -rc period now, probably should not put too much time on this.
I will take time to think about this.
--
Duy
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-07-24 13:44 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0807240629v6958014bpfa9aebde281ff57@mail.gmail.com>
Hi,
On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > No, I did mean the index. This is an attribute of the index:
> > > > either it is sparsely checked out or not. You can even have
> > > > multiple indices (switching between them by setting
> > > > GIT_INDEX_FILE) which have different prefixes.
> > >
> > > I don't think so. It's a mask for workdir, right? If you save it it
> > > index, you can switch index and the prefix as well, but workdir
> > > only has several subtrees that do not fit any other prefix than the
> > > original prefix.
> >
> >
> > Ah, you adroitly avoided addressing the issue that the user can change
> > the prefix without the index ever noticing.
>
> Forgive my ignorance. I still do not get why index must notice prefix
> change? The only reason I can think of is that we must make sure there
> won't be any user-modification in index outside the prefix. But that can
> be guarded from higher level (plumbings and porcelains) because index is
> allowed to have modification outside sparse prefix (auto-merged
> entries).
Why do you want to guard it from the outside? When the obvious fix is to
put together what belongs together?
Hth,
Dscho
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 13:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807241340490.8986@racer>
Hi,
On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > No, I did mean the index. This is an attribute of the index: either
> > > it is sparsely checked out or not. You can even have multiple indices
> > > (switching between them by setting GIT_INDEX_FILE) which have
> > > different prefixes.
> >
> > I don't think so. It's a mask for workdir, right? If you save it it
> > index, you can switch index and the prefix as well, but workdir only has
> > several subtrees that do not fit any other prefix than the original
> > prefix.
>
>
> Ah, you adroitly avoided addressing the issue that the user can change the
> prefix without the index ever noticing.
Forgive my ignorance. I still do not get why index must notice prefix
change? The only reason I can think of is that we must make sure there
won't be any user-modification in index outside the prefix. But that
can be guarded from higher level (plumbings and porcelains) because
index is allowed to have modification outside sparse prefix
(auto-merged entries).
--
Duy
^ permalink raw reply
* [PATCH] git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
From: Abhijit Menon-Sen @ 2008-07-24 13:28 UTC (permalink / raw)
To: Murphy, John; +Cc: git
In-Reply-To: <80915B5E107BED488500050294C6F48712136B@ex2k.bankofamerica.com>
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
At 2008-07-24 09:01:48 -0400, john.murphy@bankofamerica.com wrote:
>
> I presume this was just an oversight when git- commands were removed
> from the bin directory.
Looks like it. The following patch fixes it for me. Does it work for
you on Windows?
-- ams
git-gui/git-gui.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 940677c..a70fa67 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -1670,10 +1670,10 @@ proc do_gitk {revs} {
# -- Always start gitk through whatever we were loaded with. This
# lets us bypass using shell process on Windows systems.
#
- set exe [file join [file dirname $::_git] gitk]
+ set exe [_which gitk]
set cmd [list [info nameofexecutable] $exe]
- if {! [file exists $exe]} {
- error_popup [mc "Unable to start gitk:\n\n%s does not exist" $exe]
+ if {$exe eq {}} {
+ error_popup [mc "Couldn't find gitk in PATH"]
} else {
global env
--
1.5.6.GIT
^ permalink raw reply related
* Git Gui bug calling gitk
From: Murphy, John @ 2008-07-24 13:01 UTC (permalink / raw)
To: git
I have recently installed git: v1.5.6.1-167-gbf270ab and git gui:
gitgui-0.10.2-8-g2add5cb
>From Git Gui we try to run Visualize Branch History and get the
following error:
Unable to start gitk:
c:/cygwin/usr/local/git/libexec/git-core/gitk does not exist
I presume this was just an oversight when git- commands were removed
from the bin directory.
-John Murphy
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Olivier Marin @ 2008-07-24 12:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Nanako Shiraishi, Johannes Schindelin,
René Scharfe, Stephan Beyer, Joe Fiorini, git, Jari Aalto
In-Reply-To: <7v1w1ke9k5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
> Olivier Marin <dkr+ml.git@free.fr> writes:
>
>> Junio C Hamano a écrit :
>>>> diff --git a/git-am.sh b/git-am.sh
>>> ...
>>>> @@ -202,8 +202,15 @@ then
>>> ...
>>>> + case "$skip,$abort" in
>>>> + t,)
>>>> + git rerere clear
>>>> + git read-tree --reset -u HEAD HEAD
>>>> + orig_head=$(cat "$GIT_DIR/ORIG_HEAD")
>>>> + git reset HEAD
>>>> + git update-ref ORIG_HEAD $orig_head
>>>> + ;;
>>> ...
>> I add reset to unstage paths with no conflict that are left behind.
>
> Does removing the last three lines (1) change the behaviour? (2) break any test?
>
> If the answers are "Yes and No", we would need a few more tests in the
> testsuite.
The answers are "Yes and No" and test case update follow.
-- >8 --
From: Olivier Marin <dkr@freesurf.fr>
[PATCH] update test case to protect am --skip behaviour
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
t/t4151-am-abort.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh
index f45ab0a..7d86cdf 100755
--- a/t/t4151-am-abort.sh
+++ b/t/t4151-am-abort.sh
@@ -17,6 +17,8 @@ test_expect_success setup '
for i in 2 3 4 5 6
do
echo $i >>file-1 &&
+ echo $i >otherfile-$i &&
+ git add otherfile-$i &&
test_tick &&
git commit -a -m $i || break
done &&
--
1.6.0.rc0.44.gd618.dirty
^ permalink raw reply related
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-07-24 12:42 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0807240127p5226822atcd4a0711f1bc9c5c@mail.gmail.com>
Hi,
On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> >
> > > On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > > And with core.sparseCheckout you are at the whim of the user,
> > > > since .git/config is _supposed_ to be user-editable.
> > >
> > > Well, whatever place. I chose .git/config because I did not want to
> > > introduce a new config place. But then how about
> > > .git/sparsecheckout?
> >
> > No, I did mean the index. This is an attribute of the index: either
> > it is sparsely checked out or not. You can even have multiple indices
> > (switching between them by setting GIT_INDEX_FILE) which have
> > different prefixes.
>
> I don't think so. It's a mask for workdir, right? If you save it it
> index, you can switch index and the prefix as well, but workdir only has
> several subtrees that do not fit any other prefix than the original
> prefix.
Ah, you adroitly avoided addressing the issue that the user can change the
prefix without the index ever noticing.
Well, in any case, if you do not agree that the prefix is really an
attribute of the index, then there is nothing else I have to say on this
series.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Preserve cwd in setup_git_directory()
From: Nguyen Thai Ngoc Duy @ 2008-07-24 12:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Geoff Russell
In-Reply-To: <alpine.DEB.1.00.0807241324040.8986@racer>
On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
>
> > When GIT_DIR is not set, cwd is used to determine where .git is. If
> > core.worktree is set, setup_git_directory() needs to jump back to the
> > original cwd in order to calculate worktree, this leads to incorrect
> > .git location later in setup_work_tree().
>
>
> I do not understand. core.worktree is either absolute, in which case
> there is no problem. Or it is relative to where the config lives, no?
The problem is GIT_DIR is not absolute in this case. So cwd must stay
where git dir is until it is absolute-ized by setup_work_tree().
--
Duy
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-24 12:39 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Dmitry Potapov, Junio C Hamano, Git Mailing List
In-Reply-To: <FCAEAB20-750E-47B9-B58D-9BB0CB1EEAFF@zib.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1510 bytes --]
Hi,
On Thu, 24 Jul 2008, Steffen Prohaska wrote:
> Dscho,
> Is the following your use case?
>
> "I am the maintainer of this project. I know that this project needs
> crlf conversion, because it is a cross-platform project. Therefore,
> I want to force crlf conversion for this specific project, even if
> the user did not configure core.autocrlf=input on Unix."
No.
My use case is this: a few users work on Windows (Cygwin), others on
MacOSX, yet others on Linux.
We often integrate files from somewhere else, and them Windows guys love
to edit their files with their anachronistic proprietary crap tools that
add CRs where CRs no belongee.
Also, the Windows guys (being Windows guys) cannot be bothered to read
documentation, so they did not set autocrlf.
> Your patch provides a solution, though not a very comfortable one. With
> your patch applied, you could explicitly list all files (or filetypes)
> that are text and mark them with 'crlf'.
Why should I want to do that? I do not _want_ CRs. And them Windows guys
do not need them either; they are often not even aware that their crap
tools introduce them.
> You could also specify 'crlf=input', but I don't understand why you want
> to specify this.
That's what I do. And _I_ need to understand why ;-)
Well, seems I will just continue shouting "why did you commit that
CR-ridden file?" and get shouted back with "why does this §&%&%&!° Git
tool not fix it for me automatically? Even _Subversion_ can do it."
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Stephan Beyer @ 2008-07-24 12:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807241311450.8986@racer>
Hi,
Johannes Schindelin wrote:
> The way it runs with my patch, at least a user has a chance to fix it up
> without a Git expert standing nearby.
>
> I will definitely keep this in my personal fork, even in my personal
> fork of "master" during the rc period. But if you think it is not worth
> it, and others seem to be utterly disinterested (instead discussing
> behavior changes), I will not push further.
I don't know how much my opinion counts here, but I think it definitely
is worth it because I've ran into this *several* times -- "Ooops, where
is my commit? ... ... ... Ah! F***!", which meant that I had to had to
split accidentally squashed commits.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Preserve cwd in setup_git_directory()
From: Johannes Schindelin @ 2008-07-24 12:26 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Geoff Russell
In-Reply-To: <20080724031441.GA26072@laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 888 bytes --]
Hi,
On Thu, 24 Jul 2008, Nguyễn Thái Ngọc Duy wrote:
> When GIT_DIR is not set, cwd is used to determine where .git is. If
> core.worktree is set, setup_git_directory() needs to jump back to the
> original cwd in order to calculate worktree, this leads to incorrect
> .git location later in setup_work_tree().
I do not understand. core.worktree is either absolute, in which case
there is no problem. Or it is relative to where the config lives, no?
Besides, this touches a _very_ delicate part of Git. I'd rather not touch
it during the -rc cycle.
I remember I was opposed to the whole worktree crap, and judging by the
sheer amount of bug reports, next to nobody uses it anyway.
It was implemented in a really ugly manner, too, and my attempt to fix it
was still messy. That is why we have _only_ problems with it.
Just thinking of worktree makes me uneasy,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Johannes Schindelin @ 2008-07-24 12:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyk888z5.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 23 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > If the user called "rebase -i", marked a commit as "edit", "rebase
> > --continue" would automatically amend the commit when there were
> > staged changes.
> >
> > However, this is actively wrong when the current commit is not the one
> > marked with "edit". So guard against this.
>
> At what point in what valid workflow sequence does HEAD become different
> from dotest/amend?
$ rebase -i HEAD~5
<mark one commit as edit>
<Whoa! While editing, I realize that this contains an unrelated
bugfix>
$ git reset HEAD^
$ git add -p
$ git commit
<Edit a bit here, a bit there>
$ git rebase --continue
Sure it is a pilot error. It hit this pilot, too.
> > @@ -419,7 +419,9 @@ do
> > else
> > . "$DOTEST"/author-script ||
> > die "Cannot find the author identity"
> > - if test -f "$DOTEST"/amend
> > + if test -f "$DOTEST"/amend &&
> > + test $(git rev-parse HEAD) = \
> > + $(cat "$DOTEST"/amend)
> > then
> > git reset --soft HEAD^ ||
> > die "Cannot rewind the HEAD"
>
> In what way is this "guarding against it"?
In the way that the user certainly did not mean to amend _this_ HEAD.
Another HEAD was marked with "edit".
By not amending, the user has a chance to fix anything unintended in
another rebase -i more easily, since the two commits have not been
squashed together.
'course, the user should have seen in the editor that popped up that she
is squashing two different commits, should have deleted the whole commit
message to abort, make the independent commit herself (finding the correct
commit to steal the commit message from), then run rebase --continue
(which would no longer commit anything, there being nothing to).
However, that course of action is a bit unintuitive.
The way it runs with my patch, at least a user has a chance to fix it up
without a Git expert standing nearby.
I will definitely keep this in my personal fork, even in my personal
fork of "master" during the rc period. But if you think it is not worth
it, and others seem to be utterly disinterested (instead discussing
behavior changes), I will not push further.
Ciao,
Dscho
^ permalink raw reply
* Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Johannes Schindelin @ 2008-07-24 12:09 UTC (permalink / raw)
To: Marek Zawirski; +Cc: Junio C Hamano, Jakub Narebski, git, Stephan Beyer
In-Reply-To: <48886B8F.6000304@gmail.com>
Hi,
On Thu, 24 Jul 2008, Marek Zawirski wrote:
> Junio C Hamano wrote:
> > I am not sure how and where, but I think j/egit should also be
> > mentioned and/or asked about.
>
> There is no separate mailing list for j/egit, we just used private mails
> for some discussions/less important notifications.
I hope not for too much, because this is one of the lessons of last year's
GSoC (and to a large degree this year's Gitorrent project): if you keep
the project too secret, nobody will know, and as a consequence nobody will
care.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Marek Zawirski @ 2008-07-24 11:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Stephan Beyer
In-Reply-To: <7vsku1gqny.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> (...)
>
>> 27. Which of the following features do you use?
>> (zero or more: multiple choice)
>> - git-gui or other commit tool, gitk or other history viewer, patch
>> management interface (e.g. StGIT), bundle, eol conversion,
>> gitattributes, submodules, separate worktree, reflog, stash,
>> shallow clone, detaching HEAD, mergetool, interactive rebase,
>> add --interactive or other partial commit helper, commit
>> templates, bisect, other (not mentioned here)
>>
I've got lost a little bit in this discussion, but some question about
used GUI for Git maybe interesting - the above one is touching the
problem. Just egit is missing there.
(...)
>> 40. Do you read the mailing list?
>> - yes/no
>>
>
> Which mailing list? Do we want to ask about alternative lists?
>
> I am not sure how and where, but I think j/egit should also be
> mentioned and/or asked about.
>
There is no separate mailing list for j/egit, we just used private mails
for some discussions/less important notifications.
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 10:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Johannes Schindelin
In-Reply-To: <m3tzefvd3q.fsf@localhost.localdomain>
On 7/24/08, Jakub Narebski <jnareb@gmail.com> wrote:
> Second, I think you can simply special case .git* files (.gitignore,
> .gitattributes, .gitmodules), and always check them out for all
> intermediate directories (unless configured otherwise, of course).
> So for example if you have the following directory structure:
>
> A/.gitignore
> A/a
> A/B1/.gitignore
> A/B1/b
> A/B2/.gitignore
> A/B2/c
>
> and you are checking out only subdirectory 'B1' (and all files in it;
> if subdirectories are checked out recursively it depends on
> configuration), and if for example there is .gitignore in every
> directory, then checked out tree would look like this:
>
> A/.gitignore
> A/B1/.gitignore
> A/B1/b
>
> The ability to do this is one of advantages of 'sparse' checkout over
> 'subtree' checkout.
Or teach git to use index version of those files. Or collect all those
files, combine them and put the result to .git/info/exclude (and
similar places). Anyway well organized repos won't have this problem.
Checking some files out as read-only (like this case) may be
interesting. Though I do not how much complicated it can be.
--
Duy
^ permalink raw reply
* [StGit PATCH] Fixed default install location
From: Daniel White @ 2008-07-24 10:20 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Originally broken by addition of Debian package support.
Signed-off-by: Daniel White <daniel@whitehouse.id.au>
---
The default installation direction is actually /usr at present despite
what 'INSTALL' says.
The 'debian/rules' makefile specifies the prefix as /usr so doesn't
seem to depend on this. I've tested the resulting debian package and
everything is still installed correctly under /usr.
setup.cfg | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/setup.cfg b/setup.cfg
index 1eb8e9b..4359033 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -1,2 +1,2 @@
[install]
-prefix: /usr
+prefix: ~
--
1.5.6.2
^ permalink raw reply related
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 10:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Robin Rosenberg, git
In-Reply-To: <alpine.DEB.1.00.0807231659210.8986@racer>
Dnia środa 23. lipca 2008 18:00, Johannes Schindelin napisał:
> On Wed, 23 Jul 2008, Robin Rosenberg wrote:
>> onsdagen den 23 juli 2008 15.18.40 skrev Johannes Schindelin:
>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
>>>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>>>
>>>>> Some people prefer to stay anonymous, so I think email is out.
>>>>>
>>>>>> 04. 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
>>>>>> + (should we include other languages, like C++, Java, PHP,
>>>>>> Ruby,...?)
>>>>>
>>>>> Yes, I think this should be a long list.
>>>>
>>>> I'd rather not have a "laundry list" of languages. I have put C++
>>>> because QGit uses it, Java because of egit/jgit, PHP for web
>>>> interfaces, Ruby because of GitHub and because of Ruby comminity
>>>> choosing Git. I should perhaps add Emacs Lisp, HTML+CSS and
>>>> JavaScript here. What other languages should be considered?
>>>
>>> C# at least, since we had one (pretty unsuccessful) attempt at
>>> reimplementing Git in it.
>>
>> What is the reason for the question? Do we want to know what languages
>> people would like to contribute to Git in or do we want to know what "kind"
>> of programmers are attracted by Git? Making it a long list should make
>> it easier to tabulate the responses.
>
> "could contribute" is more appropriate IMHO. Although you might be right
> to ask "would like to contribute"... ;-)
I think it is both. We would like to know what kind of programmers
(and non-programmers) are attracted to Git, and also what languages
could people contribute to Git.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: david @ 2008-07-24 10:37 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Jakub Narebski, Robin Rosenberg, Johannes Schindelin, git
In-Reply-To: <20080724085725.GA6092@leksak.fem-net>
On Thu, 24 Jul 2008, Stephan Beyer wrote:
> Hi,
>
> david@lang.hm wrote:
>>>> And of course "I am not programmer" response...
>>>
>>> This doesn't make sense, does it?
>>> I know that there are non-programmer's who use git for there
>>> configuration files and other non-programming track files, but
>>> this looks somehow wrong in this survey.
>>
>> there are non-programmers who use git to track projects that they want to
>> be able to run the latest versions of. they don't program, just git pull;
>> make;make install
>
> Ahh, you're totally right. :)
> I wonder if those users take part in a Git User's Survey. We'll see. :)
it depends on how it gets sent out.
if it's just sent to the git lists you won't have many of those users, if
it's sent to lists of projects that use git (and/or publicised in the
newsletters of those projects) we'll get a lot more of them.
due to the concern abot spamming too many lists, I'd suggest getting in
contact with the project leaders and see what they would like or not like.
I suspect that many of them will be happy to have the survey go out to
their users so that git can improve based on the feedback and their users
can think less about git and more about their project ;-)
if most of the project leaders are willing or eager to get the info out
it seems reasonable to go ahead and send a single message out to the other
lists, but if a lot of them are opposed, definantly don't send it anywhere
you didn't get a response.
David Lang
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Sverre Rabbelier @ 2008-07-24 10:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jean-François Veillette, Git, Miguel Arroz
In-Reply-To: <200807240149.27371.jnareb@gmail.com>
On Thu, Jul 24, 2008 at 1:49 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Dnia środa 23. lipca 2008 17:14, Jean-François Veillette napisał:
>> Consider
>> http://www.survs.com
>> It is still in beta but already years ahead of the proposed solution.
>> I don't know about the specific of the beta (cost, availability,
>> etc.) but I had a live presentation of the product and it is an
>> amazingly great product !
>
> It certainly _looks_ nice, but it lacks one very important feature
> (or at least I was not able to find it): the ability to download *RAW*
> data to analyse it off-line using more advanced tools (like for
> example Perl script to clean-up responses; spreadsheet like Excel or
> Gnumeric, or some statictics tool like R to analyze data, for example
> do a correlation between responses to different questions).
I created an account myself and gave it a try. You -can- export in
either an excel sheet or csv through: Surveys > [name of survey] >
Analyze > Export.
> http://www.survey.net.nz allows to download raw data in modified
> CSV format (modified as it allows for line continuation). See for
> example raw data for Git User's Survey 2007 results:
> http://git.or.cz/gitwiki/GitSurvey2007?action=AttachFile&do=get&target=surveydata.csv
As said, the same is possible at the Survs thing, even line
continuations work I think. Below is an sample export of a quick
survey I created and filled in myself. Looks pretty parsable to me :).
"Git Survey 2008"
"Viewed",1
"Incomplete",0
"Complete",1
"Respondent Number","Date","Time","What country are you in?","What is
the language you prefer git to communicate with you?","How old are you
(in years)?","How did you hear about Git?","How are you doing?"
"","","","","","","",""
2,"Jul 24, 08","11:06:56","Netherlands","Dutch","19","News site or
magazine, Blog entry, IRC, Mailing list","Very well, thank you very
much. I was hoping you would ask that question as I was trying to tell
someone that this survs thing is quite nice, actually.
The only downside so far is that you cannot prepare a survey offline
and then upload it to the site.
I'm sure that won't be a problem though."
> There is another nice thing that http://www.survey.net.nz is supposed
> to have (but it doesn't unfortunately work; at least downloading
> current layout of survey to tweak off-line doesn't/didn't work),
> namely ability to create survey off-line using some specified text
> format, and upload it, instead of creating it on-line (which might be
> much work for large surveys).
Agreed, it would be nice to have something like this. Especially when
adding a bunch of options. It doesn't seem that Survs allows you to
create the Surveys offline, but if it doesn'tw ork at survey.net.nz
anyway...?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] builtin-branch.c: optimize --merged and --no-merged
From: Lars Hjemli @ 2008-07-24 10:03 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20080724172929.6117@nanako3.lavabit.com>
On Thu, Jul 24, 2008 at 10:29 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> How is --merged different from --contains?
--merged only shows the branches which are contained by (reachable
from) a specific commit
--contains only shows the branches which contains (descends from) a
specific commit
And finally, --no-merged only shows the branches which are not
contained by a specific commit
--
larsh
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 9:52 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Robin Rosenberg, Johannes Schindelin, git
In-Reply-To: <20080723235359.GB12754@leksak.fem-net>
On Tue, 24 July 2008, Stephan Beyer wrote:
> Jakub Narebski wrote:
>> Dnia środa 23. lipca 2008 16:54, Robin Rosenberg napisał
>>> onsdagen den 23 juli 2008 15.18.40 skrev Johannes Schindelin:
>>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>>> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
>>>>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>>>>
>>>>>>> 04. 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
>>>>>>> + (should we include other languages, like C++, Java, PHP,
>>>>>>> Ruby,...?)
> [...]
>>
>> The idea is, I think, to know what languages people could contribute
>> to Git; see analysis of this question at GitSurvey2007 page on git wiki:
>> http://git.or.cz/gitwiki/GitSurvey2007#head-ecb5564d71e4093e2e93e508380407a26dbcbdea
>
> Oha, is this a Git User's Survey or a Git Potential Contributor's Survey?
> I thought this is some kind of demographic question about the "programming
> background" of the user.
Well, truth to be told it is both. We try here to kill two birds with
one stone: both to have 'programming background' of Git users, and get
to know which parts of code can have many contributors, and which
could have troubles attracting contributors because of the language
they are written in (which is visible in the choice of programming
languages in 2007 survey).
If we want to provide larger number of programming languages to
chose from (with "other" as fallback), we could take for example
top 10 from the TIOBE index, or similar sites:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html (for July 2008)
http://lui.arbingersys.com/index.html (Language Usage Indicators, Jul 10, 2008)
This would bring 'Visual Basic', and perhaps 'Assembly' and 'Lisp'
to the list of choices.
>> And of course "I am not programmer" response...
>
> This doesn't make sense, does it?
>
> I know that there are non-programmer's who use git for there
> configuration files and other non-programming track files, but
> this looks somehow wrong in this survey.
You can manage documents and like (especially written in some
formatting language), you can manage web pages, you can also
use git to only _track_ some projects even if you are not
a programmer yourself.
See for example
http://www.kieranhealy.org/blog/archives/2008/06/29/git-bibs/
http://journal.code4lib.org/articles/86
http://www.scienceforums.net/forum/showthread.php?t=33830
http://www.secomputing.co.uk/2008/06/engineering-log-book.html
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-24 9:41 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20080724172912.6117@nanako3.lavabit.com>
Actually, it gets stranger and stranger!
Nanako Shiraishi nanako3-at-lavabit.com |Lists| wrote:
>> The '-trailing-space' syntax to disable the trailing-space setting
>> is not obvious and not documented as far as I can see. I would have
>> assumed a value of '' would disable it.
>
> Doesn't gitattributes(5) describe the overall syntax in detail?
First, git-config.1 does not mention gitattributes except for specific
settings. core.whitespace is not one of these.
gitattributes.5 has:
> Sometimes you would need to override an setting of an attribute for a
> path to unspecified state. This can be done by listing the name of
> the attribute prefixed with an exclamation point !.
note that this is ! before the *name* of the attribute, and for
"Checking whitespace errors / whitespace":
> The core.whitespace configuration variable allows you to define what
> diff and apply should consider whitespace errors for all paths in the
> project (See git-config(1)). This attribute gives you finer control
> per path.
...
> Unspecified: Use the value of core.whitespace configuration variable
> to decide what to notice as error.
>
> String: Specify a comma separate list of common whitespace problems
> to notice in the same format as core.whitespace configuration
> variable.
So now, git attributes says to unspecify a setting with '!' in front of
the attribute *name*, which for core.whitespace means use the value from
git-config, which if not specified means to error on e.g. trailing-space.
Now, I notice that git's own .gitattributes has this:
> * whitespace=!indent,trail,space
> *.[ch] whitespace
Which I assume actually works, but is invalid according to git-config.1
and gitattributes.5 because:
For the first line, neither of the values 'indent', 'trail' nor 'space'
are valid for core.whitespace, and the '!' notation is not defined in
neither gitattributes.5 nor in git-config.1 for *values*.
For the second line, gitattributes states generally about attributes that:
> Set: The path has the attribute with special value "true"; this is
> specified by listing only the name of the attribute in the attribute
> list.
A value of true (unspecified would have required:"*.[ch] !whitespace")
is not valid for core.whitespace either.
So now (as I read it), neither git-config.1 nor gitattributes.5 specify
how to turn off core.whitespace "elements", but .gitattributes (from git
itself) uses one notation (!) with settings that are invalid for other
reaons, while "grep core.whitespace t/*" uses another notation (-) to
turn off elements.
Also in t/* the elements have various different names, such as: "trail",
"trailing", "trailing-space". t/t4019-diff-wserror.sh also uses this:
> echo "F whitespace=-trail" >.gitattributes
just to make things interesting!
It seems that there is some inconsistency about this. Perhaps
documentation (and changing t/* and .gitattributes accordingly) isn't
such a bad idea! :D
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Jakub Narebski @ 2008-07-24 9:35 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Johannes Schindelin
In-Reply-To: <20080723145518.GA29035@laptop>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> I have not looked at non-builtin commands yet, but I think it's not
> a big deal. We have several rounds before this series is good enough ;)
> So in short, sparse prefix will be stored in config, core.sparsecheckout.
> you have three new commands to enter/update/leave sparse checkout:
>
> git clone --path=prefix # clone with sparse checkout
> git checkout --path=prefix # limit/update checkout paths
> git checkout --full # stop sparse checkout
>
> Other operations should be normal. User attempts to do anything outside
> sparse checkout will get flagged. Git itself should not touch anything
> outside sparse checkout.
>
> One more thing. As files outside sparse checkout will not be checking
> out, .gitignore and .gitattributes from parent directories (outside
> sparse checkout) will be gone too. This may lead to surprise.
>
> Comments are welcome.
A note: my comments here reflects what I have remember from reading
comments in this thread; I have not examined the code, though.
First, I think that 'sparse checkout' is a better idea than former
'subtree (partial) checkout'; and I guess it could be easier to code.
Second, I think you can simply special case .git* files (.gitignore,
.gitattributes, .gitmodules), and always check them out for all
intermediate directories (unless configured otherwise, of course).
So for example if you have the following directory structure:
A/.gitignore
A/a
A/B1/.gitignore
A/B1/b
A/B2/.gitignore
A/B2/c
and you are checking out only subdirectory 'B1' (and all files in it;
if subdirectories are checked out recursively it depends on
configuration), and if for example there is .gitignore in every
directory, then checked out tree would look like this:
A/.gitignore
A/B1/.gitignore
A/B1/b
The ability to do this is one of advantages of 'sparse' checkout over
'subtree' checkout.
Third, about the place where to store information about which paths
are checked out, and which are not. There are three possible places
to store this information:
1. repository configuration, e.g. `core.sparsecheckout' variable
(multivalued?), like for `core.worktree'
2. some text file in $GIT_DIR, e.g. '.git/sparse', like for shallow
clone ("git clone --depth <depth>") it is grafts-like
$GIT_DIR/shallow (see Documentation/technical/shallow.txt).
3. in the index itseld ($GIT_DIR/index), as proposed by Johannes
Schindelin.
While I do think that some information about sparseness should be in
the index, for git to be able to commit from the index for example,
I don't think it is a good place as the only/main place to store
information about which paths are checked out; I think that because
IMVHO git commands should survive hosing (removing) index file.
Just my 2 eurocents.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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