* Re: [PATCH] Let --decorate show HEAD position
From: Thomas Rast @ 2009-10-12 20:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, René Scharfe
In-Reply-To: <4c70c935ab67266684aa14e38e276795cf1776db.1255337211.git.trast@student.ethz.ch>
Thomas Rast wrote:
> diff --git a/log-tree.c b/log-tree.c
> index 1618f3c..f7d54f2 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -43,6 +43,7 @@ void load_ref_decorations(int flags)
> if (!loaded) {
> loaded = 1;
> for_each_ref(add_ref_decoration, &flags);
> + head_ref(add_ref_decoration, &flags);
> }
> }
Damn, this fails tests and I only just noticed while testing another
series. Sorry for the noise, reroll upcoming...
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: quote in help code example
From: Miklos Vajna @ 2009-10-12 19:40 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091012102926.GA3937@debian.b2j>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
On Mon, Oct 12, 2009 at 06:29:26PM +0800, bill lam <cbill.lam@gmail.com> wrote:
> In git man, eg. git help filter-branch
> The code examples for command line or shell scripts inside .ft pairs
> use (smart?) quote instead of single quotes, like
>
> .ft C
> git filter-branch --tree-filter ´rm filename´ HEAD
> .ft
>
> Is this intentional or just some configuration problem during
> compiling.
Just a guess: do you have docbook-xsl >=1.73.0 and you did not set
ASCIIDOC_NO_ROFF?
Try rebuilding the documentation using 'make ASCIIDOC_NO_ROFF=YesPlease'.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git-stash documentation: mention default options for 'list'
From: Jeff King @ 2009-10-12 19:39 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jef Driesen, git
In-Reply-To: <20091012193739.GR23777@genesis.frugalware.org>
On Mon, Oct 12, 2009 at 09:37:39PM +0200, Miklos Vajna wrote:
> I just noticed this was not mentioned in the manpage.
Thanks, looks like an improvement to me.
-Peff
^ permalink raw reply
* [PATCH] git-stash documentation: mention default options for 'list'
From: Miklos Vajna @ 2009-10-12 19:37 UTC (permalink / raw)
To: Jeff King; +Cc: Jef Driesen, git
In-Reply-To: <20091012175201.GA10263@coredump.intra.peff.net>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
I just noticed this was not mentioned in the manpage.
Documentation/git-stash.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 3f14b72..fafe728 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -78,7 +78,8 @@ stash@{1}: On master: 9cc0589... Add git-stash
----------------------------------------------------------------
+
The command takes options applicable to the 'git-log'
-command to control what is shown and how. See linkgit:git-log[1].
+command to control what is shown and how. If no options are set, the
+default is `-n 10`. See linkgit:git-log[1].
show [<stash>]::
--
1.6.4
^ permalink raw reply related
* Re: Supressing sorting of trees
From: Martin Langhoff @ 2009-10-12 19:36 UTC (permalink / raw)
To: Sal Mangano; +Cc: git
In-Reply-To: <loom.20091012T182258-9@post.gmane.org>
On Mon, Oct 12, 2009 at 6:51 PM, Sal Mangano
<smangano@into-technology.com> wrote:
> 2) I can use Git unchanged but preserve order by storing some information in
> each sub tree (e.g. an extra blob) which retains the real order. I can also
This #2 is your best bet by far. An extra blob in each subdir is just
one option, you can handle this "extra metadata" in a number of ways
-- maybe external to git, on a separate history will work best.
The downsides of messing with internal tree handling of git are so
staggering that you'd do better to throw git away.
(this is from experience of abusing git to various purposes that have
little to do with version control :-) )
In other words: Shaun and Dscho are right, so right that it hurts.
hth,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: sylvain @ 2009-10-12 19:08 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, Steven Noonan, git
In-Reply-To: <20091012183519.GA10686@coredump.intra.peff.net>
Quoting Jeff King <peff@peff.net>:
> On Mon, Oct 12, 2009 at 02:20:17PM -0400, sylvain@demarque.qc.ca wrote:
>
> I think that it sort of works, actually. It seems to do OK if you do
> something like:
>
> $ GIT_DIR=/path/to/store/repo; export GIT_DIR
> $ GIT_WORK_TREE=/; export GIT_WORK_TREE
> $ git init
> $ cd /etc/whatever
> $ git add .
>
> So probably the bug is in detecting the location of the work tree when
> it is not explicitly given. You can use the explicit style as a
> workaround for now.
>
> -Peff
Thank you! Great idea!
export GIT_DIR=/root/.git
export GIT_WORK_TREE=/
echo "*" >> /root/.git/info/exclude
The Golden Solution of the Gods! :-D
^ permalink raw reply
* Re: Questions about the new
From: Dmitry Potapov @ 2009-10-12 19:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sergio, git
In-Reply-To: <4AD31EBF.6090307@viscovery.net>
On Mon, Oct 12, 2009 at 02:19:11PM +0200, Johannes Sixt wrote:
>
> With grafts you can only change parenthood; with replace entries you can
> change parenthood *and* all other aspects of a commit (message, author,
> committer, dates).
Actually, you can. I have written a script that did exactly this. It
required to modify parents to point to the new commit. The tricky part
was that modification could be on top of other modifications, but I was
able to handle this case too. Yet, my script was so hackish that I have
never dared to share it with someone (and I used it only couple times
during CVS to Git conversion).
>
> Hence, replace entries are more general than grafts.
I think both mechanism are theoretically equivalent, but with grafts,
it was rather difficult to replace objects (but not impossible!).
> The problem with grafts was that, for example, git-pack-objects obeyed the
> graft, and could create a broken repository by removing grafted-away
> objects. And since git-fsck also obeyed the graft, it did not notice the
> breakage.
Moreover, grafted-away objects could be removed by the garbage collector...
Dmitry
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Matthieu Moy @ 2009-10-12 19:02 UTC (permalink / raw)
To: sylvain; +Cc: git
In-Reply-To: <20091012012826.7sffggwmm8sk0cc8@webmail.demarque.qc.ca>
sylvain@demarque.qc.ca writes:
> localhost / # cd etc
> localhost etc # git add X11/xorg.conf
> fatal: pathspec 'etc/X11/xorg.conf' did not match any files
cd ..
git add etc/X11/xorg.conf
works. I don't know why the other doesn't (just tested adding from an
untracked directory in another project, it does work).
If you want to version a large directory like /, I'd advise putting
"*" in /.gitignore to make sure Git never tries to traverse the whole
filesystem.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: backup git repo on every commit
From: Shawn O. Pearce @ 2009-10-12 18:37 UTC (permalink / raw)
To: Christian Himpel; +Cc: Israel Garcia, git
In-Reply-To: <20091012183504.GA3872@mrslave>
Christian Himpel <chressie@googlemail.com> wrote:
> Since this is meant as a backup, is there also a sane way to push the
> reflog entries as well? Or is it okay just to copy .git/logs to the
> backup repository?
There isn't a way to transfer reflogs, but one could rsync them
over to the backup. Some records might be missing their SHA-1 in
the backup if that particular object wasn't pushed there, but the
reflog code is generally tolerant of those garbage records.
--
Shawn.
^ permalink raw reply
* Re: Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Björn Steinbrink @ 2009-10-12 18:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Euguess, Mikael Magnusson, Matthieu Moy, Jeff King, Jay Soffian,
git
In-Reply-To: <alpine.DEB.1.00.0910120941150.4985@pacific.mpi-cbg.de>
On 2009.10.12 09:49:50 +0200, Johannes Schindelin wrote:
> On Tue, 6 Oct 2009, Euguess@gmail.com wrote:
> > I'ma new user of git and I don't think i will ever have a commit in
> > git.git, because I'm not a programmer (I'm QA).
[...]
> > As for the solution i would choose the "simplest thing that will work" -
> > so i think that we just have to notify user about his suicide attempt to
> > checkout nonlocal branch and offer him a correct syntax to go with.
> >
> > Something like below should work:
> >
> > % git clone git://git.git git
> > % git checkout next
> > You're attempting to checkout to non-local branch. This will lead to your HEAD
> > being detached (our team is on its way!).
> > Do you want to check out local branch 'next' tracking 'origin/next' instead?
> > y/n
> >
> > if yes, then:
> > Created branch "next" tracking "origin/next"
> > You can update it with 'git pull'.
> >
> > If no - abort or continue with checkout to nonlocal branch? ('m not sure if
> > detaching HEAD can provide some benefits if done on purpose)
> >
> > I hope I'm not missing anything...
>
> No, I think that is something perfectly fine to expect in a software whose
> UI complexity is unfortunately pretty much in disagreement with its
> internal complexity.
>
> One thing one might add for the technically inclined folks (i.e. those who
> need to implement, and to see that Git is in dear need of some
> user-friendliness first): "git checkout" is a porcelain (i.e. a program
> meant for end-user consumption), and as such should not have a problem to
> react to isatty(0) (i.e. "is the input coming directly from the
> console?").
So I didn't mean to chime in, but anyway... A few days ago, uau on #git
said that he thinks that "git clone" shouldn't create any branch heads
at all. Instead, git should learn to do something like "svn up", when
the user checked out a remote tracking branch. That was specifically
meant for users that _don't_ commit, like, say, QA guys ;-)
I didn't quite agree on the idea (feel free to tell me that I just blank
out UI problems :-p), but anyway, I felt like coming up with some hack
that achieves said functionality. The result was inspired by "git
checkout -" and looks at HEAD's reflog to figure out whether the user
has checked out a remote tracking branch the last time he used checkout
to switch branches. I dared to call it "git-up" in my $HOME/bin ;-)
#!/bin/bash
MODE=${1:---merge}
RTB=$(git rev-parse --symbolic-full-name $(git reflog | grep 'checkout: moving from .* to' | head -1 | sed -e 's/.* to //'))
if [ ${RTB:0:13} != "refs/remotes/" ]
then
echo "You're not on a remote tracking branch"
exit 1
fi
SRTB=${RTB#refs/remotes/}
REMOTE=${SRTB%/*}
git fetch $REMOTE
git reset $MODE $RTB
It's obviously basically just "git reset" on crack, happily dropping
local commits. A "real" implementation would likely have to have more
checks to ensure that the user is using it in an expected way (like
checking that refs/remotes/whatever..HEAD is empty). And it could be
made to work with regular branch heads as well then, as a "fast-forward
only" way of updating (think "git merge --ff-only", but in a less
illogical way, as "--ff-only" actually means "don't create a merge",
which is kinda weird, at least to me).
As I said, I don't really agree on the idea of not creating any branch
heads on "clone", but maybe it's because I'm not a "don't commit, just
watch" person. And the theoretical "git up" command might be handy for
guys that just want to follow things, and thus don't really need branch
heads. At the moment, I don't have any intentions to improve the hack
(also due to lack of time), but if it seems worthwhile to anyone, feel
free to pick it up.
Björn, -ENOPATCH ;-)
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Jeff King @ 2009-10-12 18:35 UTC (permalink / raw)
To: sylvain; +Cc: Alex Riesen, Steven Noonan, git
In-Reply-To: <20091012142017.vrs4v2cc8wgws8g4@webmail.demarque.qc.ca>
On Mon, Oct 12, 2009 at 02:20:17PM -0400, sylvain@demarque.qc.ca wrote:
> >It's more of "a note to the future generation of developers": "Hey guys,
> >we didn't need that working, but if you have a night to spare could you
> >please finish that?"
>
> Ok, then I won't wait for it to work. I will dive in Git's code and
> play the "future generation of developers" part... some day. ;-)
>
> Thank you! :-)
I think that it sort of works, actually. It seems to do OK if you do
something like:
$ GIT_DIR=/path/to/store/repo; export GIT_DIR
$ GIT_WORK_TREE=/; export GIT_WORK_TREE
$ git init
$ cd /etc/whatever
$ git add .
But it does not work if you try to make things work automatically:
$ cd /
$ git init
$ cd /etc/whatever
$ git add .
So probably the bug is in detecting the location of the work tree when
it is not explicitly given. You can use the explicit style as a
workaround for now.
-Peff
^ permalink raw reply
* Re: backup git repo on every commit
From: Christian Himpel @ 2009-10-12 18:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Israel Garcia, git
In-Reply-To: <20091012141544.GF9261@spearce.org>
On Mon, Oct 12, 2009 at 07:15:44AM -0700, Shawn O. Pearce wrote:
> Israel Garcia <igalvarez@gmail.com> wrote:
> git remote add --mirror backup you@another.host:path/to/backup.git
>
> cat >.git/hooks/post-commit
> #!/bin/sh
> git push backup
> ^D
>
> chmod a+x .git/hooks/post-commit
Since this is meant as a backup, is there also a sane way to push the
reflog entries as well? Or is it okay just to copy .git/logs to the
backup repository?
Thanks,
chressie
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Alex Riesen @ 2009-10-12 18:30 UTC (permalink / raw)
To: sylvain; +Cc: Steven Noonan, git
In-Reply-To: <20091012142017.vrs4v2cc8wgws8g4@webmail.demarque.qc.ca>
On Mon, Oct 12, 2009 at 20:20, <sylvain@demarque.qc.ca> wrote:
> Quoting Alex Riesen <raa.lkml@gmail.com>:
>> It's more of "a note to the future generation of developers": "Hey guys,
>> we didn't need that working, but if you have a night to spare could you
>> please finish that?"
>
> Ok, then I won't wait for it to work. I will dive in Git's code and play the
> "future generation of developers" part... some day. ;-)
>
> Thank you! :-)
>
Hmm... This strategy to encourage new contributors didn't quite worked out.
Must try something else next time. Do you like sweets? Just asking...
^ permalink raw reply
* Re: git refuses to work with gvim
From: Joshua Roys @ 2009-10-12 18:29 UTC (permalink / raw)
To: Matthieu Moy; +Cc: sebastian, git
In-Reply-To: <vpq8wfgg4u1.fsf@bauges.imag.fr>
On 10/12/2009 08:43 AM, Matthieu Moy wrote:
> sebastian@CoLi.Uni-SB.DE writes:
>
>> # git commit something
>> fatal: no commit message? aborting commit.
>> #
>
> The problem is that gvim returns immediately, and lets the window
> opened (try it in a terminal, "gvim foo.txt" returns immediately). Git
> expects the commit message to be written and saved when $EDITOR
> returns.
>
> A quick search for "wait" in the man pages tells me that
>
> GIT_EDITOR='gvim -f' git commit
>
> works.
>
> (BTW, this is in no way specific to Git, 99% applications calling
> $EDITOR will expect the same behavior)
>
Hello,
Also, a :help nofork leads to gui-fork and guioptions, which tells you
that you can add the following to .vimrc (not .gvimrc, see :help go-f):
set guioptions+=f
--
Joshua Roys
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Markus Heidelberg @ 2009-10-12 18:30 UTC (permalink / raw)
To: sylvain; +Cc: git
In-Reply-To: <20091012012826.7sffggwmm8sk0cc8@webmail.demarque.qc.ca>
sylvain@demarque.qc.ca, 12.10.2009:
> Git is good, Git is great! All praise the Git! :-D
>
> What do you people think about this strange phenomena?
>
> localhost / # git --version
> git version 1.6.4.4
>
> localhost / # git init
> Initialized empty Git repository in //.git/
>
> localhost / # cd etc
> localhost etc # git add X11/xorg.conf
> fatal: pathspec 'etc/X11/xorg.conf' did not match any files
"git add etc/X11/xorg.conf" works, seems to be a bug.
Markus
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: sylvain @ 2009-10-12 18:20 UTC (permalink / raw)
To: Alex Riesen; +Cc: Steven Noonan, git
In-Reply-To: <81b0412b0910121115s26c6c08s1ea54c28851faf05@mail.gmail.com>
Quoting Alex Riesen <raa.lkml@gmail.com>:
> On Mon, Oct 12, 2009 at 20:06, Steven Noonan <steven@uplinklabs.net> wrote:
>> I've had this problem too, but I eventually realized it was git's way
>> of telling me I shouldn't do that. But even so, it'd be good if we
>> _could_.
>
> It's more of "a note to the future generation of developers": "Hey guys,
> we didn't need that working, but if you have a night to spare could you
> please finish that?"
Ok, then I won't wait for it to work. I will dive in Git's code and
play the "future generation of developers" part... some day. ;-)
Thank you! :-)
^ permalink raw reply
* Re: Filesystem has no item: Working copy path [...] does not exist in repository at /usr/bin/git-svn line 3856
From: Eric Wong @ 2009-10-12 18:20 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <9accb4400910120848n6a1e4036l5e45ce3882deb5aa@mail.gmail.com>
Daniele Segato <daniele.bilug@gmail.com> wrote:
> Hi,
> i'm trying to clone a public SVN repo (user = guest, password is
> empty/blank/not neeeded)
>
> this was my steps:
>
> $ git --version
> git version 1.5.6.5
Hi Daniele,
First I thought this was a problem fixed in
83c2fcff214fe89649fcd88e095d9961a36b53dd (git v1.6.2 or later),
but then I tried running it just to make sure.
> $ mkdir plugins
> $ cd plugins
> $ git svn init http://svn.liferay.com/repos/public/plugins -T trunk -b
> branches # doesn't have tags
> $ git svn fetch
> [...]
> # it takes hours.....
> [...]
> r25355 = ee13a19e656e6f96b1ebb562b10ee7fa688921df (svn/trunk)
> Filesystem has no item: Working copy path 'plugins/branches/trunk'
> does not exist in repository at /usr/bin/git-svn line 3856
>
>
> after that revision it give me that error... and then stops.
> if I issue again the git svn fetch it keep telling me the error and I
> can't complete the cloning.
This is a namespace conflict, the "trunk" ref is conflicting with a
(what seems to be a miscreated) branch named "trunk". I anticipated
this problem originally but figured it was rare/uncommon enough that I
didn't want to burden users by prefixing all branches with something:
------------------------------------------------------------------------
r25364 | michael.hashimoto | 2009-01-21 14:06:53 -0800 (Wed, 21 Jan 2009) | 1 line
Changed paths:
A /plugins/branches/trunk
Created directory 'plugins/branches/trunk'.
------------------------------------------------------------------------
r25365 | michael.hashimoto | 2009-01-21 14:07:15 -0800 (Wed, 21 Jan 2009) | 1 line
Changed paths:
D /plugins/branches/trunk
Removed plugins/branches/trunk
Since it looks pretty obvious that "trunk" was miscreated here from the
revision history, you can skip these two revisions in your import by
recontinuing the clone with "git svn fetch -r25365:HEAD"
If you encounter this problem further in a non-workaroundable way,
you can prefix the local branches refs:
Replace:
[svn-remote "svn"]
branches = plugins/branches/*:refs/remotes/svn/*
With:
[svn-remote "svn"]
branches = plugins/branches/*:refs/remotes/svn/branches/*
I didn't do this by default since I figured very few people would create
a branch named "trunk" (and those who did, did it accidentally as it
seems to be the case here).
Hope that helps.
--
Eric Wong
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Alex Riesen @ 2009-10-12 18:15 UTC (permalink / raw)
To: Steven Noonan; +Cc: sylvain, git
In-Reply-To: <f488382f0910121106h64571b93jb92372a1d7720b10@mail.gmail.com>
On Mon, Oct 12, 2009 at 20:06, Steven Noonan <steven@uplinklabs.net> wrote:
> I've had this problem too, but I eventually realized it was git's way
> of telling me I shouldn't do that. But even so, it'd be good if we
> _could_.
It's more of "a note to the future generation of developers": "Hey guys,
we didn't need that working, but if you have a night to spare could you
please finish that?"
^ permalink raw reply
* Re: Merge (or maybe rebase) question
From: Alex Riesen @ 2009-10-12 18:13 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0910120455k7ab5aa5ag8d701050e7acec5f@mail.gmail.com>
On Mon, Oct 12, 2009 at 13:55, Howard Miller <howard@e-learndesign.co.uk> wrote:
> Another how best to do this.
>
> - I have my project all nicely in git with all the different releases
> and versions in there going back years. Happy :-)
>
> - I have a customer who has heaviliy modified an oldish version of the
> software.
>
> - I have identified the version that they modified and created a
> branch in my git repo based on that version (i.e. what they would have
> started with before modifying it)
That's the branch where you should apply their changes. Let name it "theirs".
And I assume your normal branch is called master.
> - Their changes where applied to a simple download - no version
> control, no nothing.
>
> I now need to update them to the latest version of the software - can
> git help me here or is it all a disaster?
You can have it with both merge and rebase.
Merge:
$ git checkout master
$ git merge theirs
Now your master contains a tree where their and your changes
are mixed. Exactly how they are mixed (IOW, how you resolved
conflicts, what exactly have you taken from their tree, etc) is
recorded in the merge commit. You can't export this information out
of Git repo (so it is readily and simply usable without Git, that is).
That's usually not a problem.
Rebase:
$ git checkout theirs^0
$ git rebase master
The rebase can cause conflicts.
$ git branch new-theirs
$ git checkout new-theirs
Now you are on a branch which contains their changes on top of your
current development branch. The software as "they" had it is in "theirs".
You can export their changes to your *current* tree to anyone as patches.
No one can tell anything about where the changes were created in the
first place (the "base"), though. That's the major downside of the approach.
> PS. To make matters worse - their original is full of expanced CVS
> $Id:$ tags so it will look to git like every single file has changed.
You can filter them out using you favorite editor or scripting language
and commit the filtered tree. Gits merge considers only the final
states of the branches it merges.
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Steven Noonan @ 2009-10-12 18:06 UTC (permalink / raw)
To: sylvain; +Cc: git
In-Reply-To: <20091012135910.ujqifycf9cwsk4ss@webmail.demarque.qc.ca>
I've had this problem too, but I eventually realized it was git's way
of telling me I shouldn't do that. But even so, it'd be good if we
_could_.
- Steven
On Mon, Oct 12, 2009 at 10:59 AM, <sylvain@demarque.qc.ca> wrote:
> Hello there. I know I was being goofy, but here is the real down to
> earth question :
>
> Is there a known bug/feature that prevents Git from being used at "/"?
> It seems that there is a problem either at "git init" or "git add"
> when the repository is located at "/.git". (Git 1.6.4.4, see example
> below)
>
> Thank you!
>
> Quoting sylvain@demarque.qc.ca:
>
>> Git is good, Git is great! All praise the Git! :-D
>>
>> What do you people think about this strange phenomena?
>>
>> localhost / # git --version
>> git version 1.6.4.4
>>
>> localhost / # git init
>> Initialized empty Git repository in //.git/
>>
>> localhost / # cd etc
>> localhost etc # git add X11/xorg.conf
>> fatal: pathspec 'etc/X11/xorg.conf' did not match any files
>>
>> Aside from the obvious question of why would I want to Git the whole
>> tree ("But all files deserve the Holy Presence of the Git!"), why does
>> Git refuse the love offering from "/etc/X11/xorg.conf"? Is it because
>> it contains font directory configurations?
>>
>> Commit and [ENTER] to all,
>>
>> S! :-)
>> --
>> 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
> --
> 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
>
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: sylvain @ 2009-10-12 17:59 UTC (permalink / raw)
To: git
In-Reply-To: <20091012012826.7sffggwmm8sk0cc8@webmail.demarque.qc.ca>
Hello there. I know I was being goofy, but here is the real down to
earth question :
Is there a known bug/feature that prevents Git from being used at "/"?
It seems that there is a problem either at "git init" or "git add"
when the repository is located at "/.git". (Git 1.6.4.4, see example
below)
Thank you!
Quoting sylvain@demarque.qc.ca:
> Git is good, Git is great! All praise the Git! :-D
>
> What do you people think about this strange phenomena?
>
> localhost / # git --version
> git version 1.6.4.4
>
> localhost / # git init
> Initialized empty Git repository in //.git/
>
> localhost / # cd etc
> localhost etc # git add X11/xorg.conf
> fatal: pathspec 'etc/X11/xorg.conf' did not match any files
>
> Aside from the obvious question of why would I want to Git the whole
> tree ("But all files deserve the Holy Presence of the Git!"), why does
> Git refuse the love offering from "/etc/X11/xorg.conf"? Is it because
> it contains font directory configurations?
>
> Commit and [ENTER] to all,
>
> S! :-)
> --
> 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
^ permalink raw reply
* Re: git stash list with more than 10 items?
From: Jeff King @ 2009-10-12 17:52 UTC (permalink / raw)
To: Jef Driesen; +Cc: git
In-Reply-To: <havj2n$d85$1@ger.gmane.org>
On Mon, Oct 12, 2009 at 05:47:34PM +0200, Jef Driesen wrote:
> Is it possible to make "git stash list" show more than 10 items?
Try "git stash list -30".
Stash listing is internally just "git log -g refs/stash", so you can
pass any formatting or limiting arguments you want there (see the git
log documentation for ideas). If no arguments are given, we pass "-10".
-Peff
^ permalink raw reply
* Re: git refuses to work with gvim
From: Markus Heidelberg @ 2009-10-12 17:37 UTC (permalink / raw)
To: sebastian; +Cc: git
In-Reply-To: <20091012134312.236d250e@gzip.coli.uni-saarland.de>
sebastian@coli.uni-sb.de, 12.10.2009:
> Hi,
> a few days ago I decided to switch from vim to gvim. To make use of
> this in most cases I added :gui to my .vimrc which should make most
> applications automatically switch to use gvim if they used the vim
> command before.
>
> But git seems to have problems with this. If I do now a "git commit
> something" not the gui is opened but the console-version of vim.
git probably calls vi and not vim. Maybe vi doesn't respect your .vimrc?
> OS: Debian Lenny
Doesn't install Debian a vim-tiny package for vi without gui and another
for vim?
Markus
^ permalink raw reply
* Re: [PATCH 2/3] git config: clarify bool types
From: Felipe Contreras @ 2009-10-12 17:14 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <4AD3216B.7030507@drmicha.warpmail.net>
On Mon, Oct 12, 2009 at 3:30 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 12.10.2009 12:03:
>> On Mon, Oct 12, 2009 at 8:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> The value is what it is, the --bool and --bool-or-int options don't
>>>> specify the value type, just how it is interpreted. For example: a value
>>>> of '1' can be interpreted as 'true'.
>>>
>>> It is not really about "interpreting", but about showing, isn't it?
>>
>> Unless you are setting it, instead of reading it.
>>
>
> I'd still suggest fixing the typo ("interpreted") and spelling out
> "boolean".
Oops! You mean s/intepreted/interpreted/?
If we spell 'boolean' we might as well spell 'integer'; I think bool
and int are fine.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: add global config section
From: Felipe Contreras @ 2009-10-12 17:09 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano, J. Bruce Fields, Jonathan Nieder
In-Reply-To: <4AD32024.6020005@drmicha.warpmail.net>
On Mon, Oct 12, 2009 at 3:25 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 11.10.2009 22:43:
>> So that users get to know how to configure git from the get-to with good
>> practical example (color.ui = auto) that most people would probably like
>> anyway.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>> Documentation/user-manual.txt | 27 +++++++++++++++++++++++++++
>> 1 files changed, 27 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
>> index 67ebffa..ff2563a 100644
>> --- a/Documentation/user-manual.txt
>> +++ b/Documentation/user-manual.txt
>> @@ -40,6 +40,33 @@ without any explanation.
>> Finally, see <<todo>> for ways that you can help make this manual more
>> complete.
>>
>> +[[getting-started]]
>> +Getting started
>> +=============
>> +
>> +Git's configuration is distributed among different locations--this manual will
>> +only to deal with 'global' (for the user) and 'repository' variables, where
>> +'repository' variables take precedence over 'global' ones.
>
> Well, you do talk about "system" below, and that's about it. Also, the
> configuration is not really distributed among different locations. Most
> newbies interested in a *D*VCS will misunderstand this (as git having
> distributed configuration).
>
> Alternative:
>
> Git's default configuration can be changed on a system wide, global (per
> user) and local (per repository) level, in the order of increasing
> precedence.
When I read that it's not clear if the local level discards the global
level completely or it's aggregated. If we specify that it's only the
variables that take precedence it might be clearer:
Git's configuration is composed of variables that are stored in
multiple locations: 'system' (all users), 'global' (for the user), and
'repository' -- in decreasing order of precedence.
>> +
>> +You would probably want to start setting up something useful:
>> +------------------------------------------------
>> +$ git config --global color.ui auto
>> +------------------------------------------------
>> +
>> +This will make prettier the output of certain commands such as `git diff`, but
>> +that's not important; what is important here is that `color.ui` has been
>> +stored in the 'global' configuration.
>
> This will make certain commands such as `git diff` use colors in the
> output. What is important here is that the value `auto` for the option
> `color.ui` has been stored in the 'global' configuration. Use `--system`
> for the system wide configuration; specifying neither `--system` nor
> `--global` makes `git config` access the local configuration.
I think we should only mention (once) the system wide configuration,
but not cover it. That's for system administrators, not users.
>> +
>> +View and manually modify the configuration by opening `~/.gitconfig`:
>
> View and manually modify the global configuration by opening
> `~/.gitconfig` in your editor or using `git config --global --edit`:
I have separate patches for 'git config --edit', but Junio suggested
to hold them back because --edit is a relatively new option.
>> +------------------------------------------------
>> +[color]
>> + ui = auto
>> +------------------------------------------------
>> +
>> +Other locations are `/etc/gitconfig` (system), and `.git/config` (repository).
>
> I don't even think we should talk about locations here, "git config -e"
> should be the first user's way to do it.
I disagree. Most useful configurations (color.ui, user.email) should
be global. The complete newbie might think: cool, now I have my git
properly configured (with 'git config -e'), and then when cloning a
new repo (s)he would think: ok, git just forgot what I told him. When
that happens (s)he would have to re-learn and re-configure git.
When users think about configuration, it's usually a 'global'
configuration, so that's what we should teach from the beginning and
make sure they understand the difference between 'global' and
'repository' configurations.
>> +
>> +More git configurations will be covered in the rest of the manual, if you want
>> +to learn more look at linkgit:git-config[1] for details.
>
> "Configurations" is ambiguous, it can be easily (mis)understood as
> "types of configuration" (global, local etc.). Also, the above doesn't
> really cover even one option. How about:
>
> This manual covers many configuration options (such as `color.ui.`). For
> more details on the `git config` command as well as all configuration
> options see linkgit:git-config[1].
Looks better, except s/configuration options/configuration variables/
Cheers.
--
Felipe Contreras
^ 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