* 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
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 9:00 UTC (permalink / raw)
To: James Pickens; +Cc: git
In-Reply-To: <loom.20080724T065737-580@post.gmane.org>
On 7/24/08, James Pickens <jepicken@gmail.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds <at> 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
> >
>
>
> First things first, thanks a lot for working on this feature. I have an
> enormous project in CVS (144GB repo, containing 65000 directories and
> 463000 files) that I've been wanting to convert to git for a while now,
> and the lack of sparse checkouts was the only thing about git that was
> standing in the way. The project is so big that checking out the whole
> tree all the time is unworkable, and I think my coworkers would hang me
> if I tried to make them use submodules. We already use sparse checkouts
> in CVS to make it manageable, so sparse checkout support in git would
> vastly simplify the transition.
>
> I played around with the patch briefly, and I have a couple of comments
> on the interface.
>
> First, I would want a capability to checkout a directory non-recursively.
> I.e., checkout directory A/B, without also checking out directory A/B/C.
> Perhaps a modifier could be added to a path element to make it
> non-recursive.
This one is difficult (and may probably produce more intrusive patch).
Let's see what I can do.
> Second, I would want a capability to checkout and release directories
> incrementally, similar to how we do it in cvs. For example, I might do
> the following in cvs:
>
> $ cvs co -l A # Checkout dir A non-recursively
> $ cd A
> $ cvs up -l -d B1 B2 # Checkout dirs A/B1 and A/B2 non-recursively
> $ cd B1
> $ cvs up -d C1 C2 # Checkout dirs A/B1/C1 and A/B1/C2 recursively
> (Oops, didn't need C2)
> $ cvs release -d C2
> At this point I would have the following directory tree, assuming the C1
> directory in the repo contained a D1 directory:
>
> A/
> A/B1/
> A/B1/C1/
> A/B1/C1/D1/
> A/B2/
>
> A similar capability in git would be much appreciated.
You can do that with "git checkout --path" (non-recursive checkout aside):
$ git checkout --path=A # checkout full A
$ git checkout --path=A/B1/C1 # no, limit to A/B1/C1 only
$ git checkout --path=A/B1/C1:A/B2 # extend to A/B2 too
>
> Finally, I noticed what I think is a bug: if you do a partial checkout of
> a non-existing directory, you just get an empty tree. I would expect to
> get an error message in that case.
Thanks.
> I hope this is helpful, and thanks again for working on this.
>
> James
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Duy
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Stephan Beyer @ 2008-07-24 8:57 UTC (permalink / raw)
To: david; +Cc: Jakub Narebski, Robin Rosenberg, Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.10.0807232201310.3721@asgard.lang.hm>
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. :)
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] document that git-tag can tag more than heads
From: Kalle Olavi Niemitalo @ 2008-07-24 8:48 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.GSO.4.62.0807240000470.23113@harper.uchicago.edu>
Jonathan Nieder <jrnieder@uchicago.edu> writes:
> Samuel Bronson had the idea of putting "<commit-ish> | <object>"
> for "<object>" because most tags point to commits (and for the
> rest of the manpage, all tags point to commits).
But the argument is not a <commit-ish>. git.txt says:
A command that takes a <commit-ish> argument ultimately
wants to operate on a <commit> object but automatically
dereferences <tag> objects that point at a <commit>.
git-tag does not automatically dereference tag objects that
point to a commit. So if you want to use "|", then it should be
"<commit> | <object>".
^ permalink raw reply
* Re: [PATCH 2/2] git-checkout: improve error messages, detect ambiguities.
From: Pierre Habouzit @ 2008-07-24 8:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ibc9p93.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]
On Wed, Jul 23, 2008 at 11:04:08PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > The patch is twofold: it moves the option consistency checks just under
> > the parse_options call so that it doesn't get in the way of the tree
> > reference vs. pathspecs desambiguation.
>
> I think this goes a bit too far.
>
> Even if you have a file called 'master' tracked in your project, when you
> say:
>
> $ git checkout master
>
> that's almost always branch switching. Forcing "git checkout master --"
> disambiguation for such a common case is simply a wrong thing to do from
> the usability point of view.
>
> So how about (obviously we are interested only in the case without
> disambiguating '--' here):
>
> (3-1) if there is only one token left and if it is a rev, that's the
> branch to check out or commit to detach to.
>
> (3-2) otherwise the user might have mistyped one of the paths, so help
> avoiding by making sure the first token is unambiguously either
> a rev or a path (but not both).
It sounds really reasonable, and your patch seems really fine.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: James Pickens @ 2008-07-24 8:24 UTC (permalink / raw)
To: git
In-Reply-To: <20080723145518.GA29035@laptop>
Nguyễn Thái Ngọc Duy <pclouds <at> 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
>
First things first, thanks a lot for working on this feature. I have an
enormous project in CVS (144GB repo, containing 65000 directories and
463000 files) that I've been wanting to convert to git for a while now,
and the lack of sparse checkouts was the only thing about git that was
standing in the way. The project is so big that checking out the whole
tree all the time is unworkable, and I think my coworkers would hang me
if I tried to make them use submodules. We already use sparse checkouts
in CVS to make it manageable, so sparse checkout support in git would
vastly simplify the transition.
I played around with the patch briefly, and I have a couple of comments
on the interface.
First, I would want a capability to checkout a directory non-recursively.
I.e., checkout directory A/B, without also checking out directory A/B/C.
Perhaps a modifier could be added to a path element to make it
non-recursive.
Second, I would want a capability to checkout and release directories
incrementally, similar to how we do it in cvs. For example, I might do
the following in cvs:
$ cvs co -l A # Checkout dir A non-recursively
$ cd A
$ cvs up -l -d B1 B2 # Checkout dirs A/B1 and A/B2 non-recursively
$ cd B1
$ cvs up -d C1 C2 # Checkout dirs A/B1/C1 and A/B1/C2 recursively
(Oops, didn't need C2)
$ cvs release -d C2
At this point I would have the following directory tree, assuming the C1
directory in the repo contained a D1 directory:
A/
A/B1/
A/B1/C1/
A/B1/C1/D1/
A/B2/
A similar capability in git would be much appreciated.
Finally, I noticed what I think is a bug: if you do a partial checkout of
a non-existing directory, you just get an empty tree. I would expect to
get an error message in that case.
I hope this is helpful, and thanks again for working on this.
James
^ permalink raw reply
* Re: [PATCH] builtin-branch.c: optimize --merged and --no-merged
From: Nanako Shiraishi @ 2008-07-24 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzeg9rhh.fsf_-_@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com> writes:
> "git branch --no-merged $commit" used to compute the merge base between
> the tip of each and every branch with the named $commit, but this was
> wasteful when you have many branches.
I am not sure if I followed the technical description of the patch, but I
have a stupid question. How is --merged different from --contains?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Document disabling core.whitespace values trailing-space and space-before-tab
From: Nanako Shiraishi @ 2008-07-24 8:29 UTC (permalink / raw)
To: "Peter Valdemar Mørch (Lists)"; +Cc: git
In-Reply-To: <4888144E.8090300@sneakemail.com>
Quoting "Peter Valdemar Mrch (Lists)" <4ux6as402@sneakemail.com>:
> 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.
>
> Is there a documentation bug here? If so, I suggest this patch. I
> didn't find anywhere else where the '-setting' syntax was used to
> disable something.
Doesn't gitattributes(5) describe the overall syntax in detail?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-24 8:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231753240.8986@racer>
On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Wed, 23 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:
> > >
> > > > So in short, sparse prefix will be stored in config,
> > > > core.sparsecheckout.
> > >
> > > Do you really think the prefix should be stored anywhere else than the
> > > index?
> > >
> > > With core.sparseCheckout you have to introduce a _sh*tload_ of config
> > > loaders.
> > >
> > > And with core.sparseCheckout you are at the whim of the user, since
> > > .git/config is _supposed_ to be user-editable.
> > >
> > > From a logical point of view, I'd say that the sparse prefix has
> > > nothing to do with the "configuration" of the local repository.
> >
> > 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.
> Ciao,
> Dscho "who seems to recall that the first series was much less intrusive"
The first series only took care of index, so yes it's simpler.
--
Duy
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 8:24 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Dmitry Potapov, Johannes Schindelin, git
In-Reply-To: <20080723170120.GC17648@leksak.fem-net>
On Wed, 23 July 2008, Stephan Beyer wrote:
> Dmitry Potapov wrote:
>> On Wed, Jul 23, 2008 at 11:53:27AM +0200, Johannes Schindelin wrote:
>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>>
>>>> 11. Why did you choose Git? (if you use Git)
>>>> What do you like about using Git?
>>>> (free form, not to be tabulated)
>>>
>>> Again, to avoid hassles with free-form:
>>>
>>> Mandatory: work, mandatory: open source project I am participating
>>> in, speed, scalability, It's What Linus Uses, Other.
>>
>> If we move away from free-form, it should be much more choices here.
>>
>> - Ability to work offline
>> - Cryptographic authentication of history.
>> - Distributed development (pull/push from/to more than one remote repo)
>> - Easy to extend functionality through scripting
>> - Efficient storage model
>> - Elegant design
>> - Fast
>> - Good community support
>> - Rewriting patches before publishing (git rebase, commit --amend)
>> - Scalability (Efficient handling of large projects)
>> - Strong support for non-linear development
>> - Support of wide range of protocols for synchronization.
>> ...
>
> Heh, I can imagine git users reading that survey and thinking
> "What? Git allows me to rewrite patches before publishing?
> And it provides cryptographic integrity? Sounds good. *click*"
>
> Nevertheless, the list is fine ;)
> Perhaps also: "Good reputation".
Perhaps also: "Because it is popular (hype)", and I hope that
"Ability to track code movement" would have any takers. Although
it is hard to distinguish between 'reasons to choose' and 'favourite
features' list; let's make it more 'reasons to choose' (like "feature
rich").
"Good documentation", perhaps, too?
--
Jakub Narebski
Poland
^ 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