* 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
* Re: Questions about the new
From: Sergio Callegari @ 2009-10-12 17:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AD31EBF.6090307@viscovery.net>
Thanks Johannes for all the detailed explanations
Johannes Sixt <j.sixt <at> viscovery.net> writes:
>
> Sergio schrieb:
> > 1) Grafts and replace entries seem to operate on different aspects
of the
> > history graph. Grafts operate on arcs and replace on nodes.
>
> Correct, but see below about tree and blob objects.
OK, the replace mechanism also can replace a blob object or a tree.
My focus was on commit objects only.
>
> > As such, replace entries seem less general to me.
>
> 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).
>
> Hence, replace entries are more general than grafts.
Limiting the discussion to commit objects, I think there are two
possible scenarios.
1) You create new commits objects as needed
2) You do not.
If you follow 1), I believe grafts and replace entries have exactly the same
flexibility.
If I happen not to like commit B in A---B---C and I want A---B'---C
where B' has
completely different aspects from B I can either replace B by B' or
graft away
B, pretending that the parent of A is B
But there are many things that can be done with grafts merely adding a graft
(e.g. cutting away a part of history, joining history), that cannot be done
with replace entries without creating new commits objects.
I was asking because I was wandering whether replace entries were first
or later
meant to make grafts deprecated. I hope not, because for a few things
working on
arcs seems still nice.
> > Apparently, to simulate a graft with replace entries, you need to
introduce
> > extra commit objects. For instance, if object B has no parents, to
pretend >
> Yes. Use git-cat-file + edit + git-hash-object as explained in this
> message just the other day:
>
http://thread.gmane.org/gmane.comp.version-control.git/129727/focus=129907
Thanks, good pointer. I missed this!
> > Conversely, I guess
> > you can always simulate a replace entry with the graft mechanism,
without the
> > need to add any extra commit object. Am I overlooking something?
>
> You cannot; see above.
Well, I meant for what regards commit objects only.
If I want to replace some commit X by some commit X' I merely need to
modify the
parent information of all the commits that are child of X so that they
pretend
to be child of X', or am I missing something?
> You can even replace tree objects and blob objects
> using replace entries, IIUC, but you cannot do that with grafts.
Definitely right!
> > 2) Is it currently possible to use a replace entry to replace a
commit object
> > with nothing? Namely if B has A as its sole parent, is it possible
to have a
> > replace entry such as A-sha1 becomes null, to pretend that B is a
hierarchy
> > root?
>
> Sure. Just make a commit object that does not have parents.
OK, you need to create a new commit object. At the beginning for some
reason I
thought that you could replace an object
with "nothing" or 00000000000000000000000000000000000000000000
> > 3) If I remember correctly, there was a reason why grafts were not
considered
> > suitable for transferring across repos. Can someone remind me about
it? How
> > does the replace mechanism address this issue?
>
> 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.
>
> OTOH, history walkers (upload-pack, send-pack, pack-objects) and fsck
> never obey replace entries in the history. But they do keep track of them
> (and the history that they reference) because they are referenced
from the
> refs/replace namespace.
>
Thanks for the explanation. Can this be made possible for grafts too?
Wouldn't
it be a matter of having history walkers never obey grafts but keep track of
them (i.e. of the history of the parenthood they reference)?
Like we have "annotated" or heavyweight tags living as objects in the
database,
would it be possible or make sense to have annotated grafts or replace
entries,
so that one can express why, by whom and when history was changed?
^ permalink raw reply
* git stash list with more than 10 items?
From: Jef Driesen @ 2009-10-12 15:47 UTC (permalink / raw)
To: git
Hi,
Is it possible to make "git stash list" show more than 10 items?
Jef
^ permalink raw reply
* Re: Supressing sorting of trees
From: Sal Mangano @ 2009-10-12 16:51 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0910121803360.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:
>
> Hi,
>
> On Mon, 12 Oct 2009, Sal Mangano wrote:
>
> > Shawn O. Pearce <spearce <at> spearce.org> writes:
> >
> > >
> > > Sal Mangano <smangano <at> into-technology.com> wrote:
> > > > I am using Git in a non-standard way and need to make a few twaeks
> > > > in my custom build. I have added a --nosort option to git mktree
> > > > which will suppress the qsort of the tree.
> > > >
> > > > Will this break any other git functions? Are there any commands that
> > > > assume trees are always sorted?
> > >
> > > _YES IT BREAKS GIT_.
> > >
> > > You cannot do this.
> > >
> > > A Git repository whose trees are not sorted according to the Git
> > > specific sort ordering is severly broken and most tools will fail
> > > horribly on it.
> > >
> > > Almost all code which reads trees assumes the names are sorted in a
> > > specific order. These tools perform sorted merges against other tree
> > > like structures. If the names are out of order the merge will fail.
> > > `git fsck` will complain that the tree is not sorted properly. Tools
> > > like `git log -- foo.c` will fail randomly because they break out of
> > > the entry lookup as soon as they find a name that is after foo.c, as
> > > they assume the tree is sorted.
> > >
> > > I could go on. But there is no point.
> > >
> > > Oh, and trust me when I say this, the tree sorting matters. Long ago
> > > JGit had a bug where it didn't sort trees correctly all of the time
> > > and we had a devil of a time tracking down that corruption.
> > >
> >
> > Thanks Shawn. I get the picture.
> >
> > Now, let's assume I am stubborn, crazy or both
> >
> > I can modify fsck to ignore unsorted and at the moment I don't care
> > about merging trees. If I hunt down all usage of base_name_compare will
> > that identify all code with the sort assumption or is there other places
> > as well? I can go > through the entire source to figure this out myself
> > but I need to get something hacked up very quickly and would appreciate
> > help even if you think I am nuts!
>
> Look, one of the most trusted Git contributors just told you that you are
> asking for trouble.
>
> It has nothing to do with being stubborn if you insist on doing it now.
>
> But I smell an XY problem. Why don't you just reveil _what_ you want to
> do (as opposed to _how_ you think you should do it)?
>
> Ciao,
> Dscho
>
>
My apologies for being cryptic.
I am working on a project where I need to create a repository consisting of
hierarchical "blobs" of content (sound familiar?). In this repository the
order of the blobs as specified by the end user is definitely important.
However, I have a bunch of other reqs that fit Git perfectly such as the
ability to quickly tell if two trees are the same using their SHA1 and the
ability to version control the repository. My repository has no relationship
to files stored on a file system unlike a typical use of Git. I also don't
care about whether my repository remains compatible with standard Git because
no one will access this repository using standard Git.
Now I can proceed in a few ways:
1) I can write by repository from scratch.
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
store this information once for the whole "chunks" of the repository.
3) I can change Git to suite my needs understanding that it is not Git
anymore.
For me, (1) makes no sense at this time. I started with the hope that (2)
would work but realized it is very awkward and will cause performance problems
because it means most updates where ordering matters will have to update the
Git trees and my private ordering blob(s). So, after a quick look at the
source code it seemed like hacking Git into what I wanted was easier than 1
or 2.
I realized tree merge would probably break and wanted to know what
else. It is good to know fsck breaks. What else will break that I have to
deal with?
^ permalink raw reply
* [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-12 16:38 UTC (permalink / raw)
To: gister; +Cc: git
‘git bisect reset’ could already checkout an arbitrary commit if you
were on a detached HEAD before starting the bisection. This lets you
specify an arbitrary commit to ‘git bisect reset <commit>’.
This also provides a way to clean the bisection state without moving
HEAD: ‘git bisect reset HEAD’.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
---
git-bisect.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 6f6f039..d319b9f 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -311,8 +311,7 @@ bisect_reset() {
}
case "$#" in
0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
- 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
- die "$1 does not seem to be a valid branch"
+ 1) git rev-parse --verify "$1^{commit}" || exit
branch="$1" ;;
*)
usage ;;
--
1.6.5
^ permalink raw reply related
* Re: Supressing sorting of trees
From: Johannes Schindelin @ 2009-10-12 16:05 UTC (permalink / raw)
To: Sal Mangano; +Cc: git
In-Reply-To: <loom.20091012T171550-239@post.gmane.org>
Hi,
On Mon, 12 Oct 2009, Sal Mangano wrote:
> Shawn O. Pearce <spearce <at> spearce.org> writes:
>
> >
> > Sal Mangano <smangano <at> into-technology.com> wrote:
> > > I am using Git in a non-standard way and need to make a few twaeks
> > > in my custom build. I have added a --nosort option to git mktree
> > > which will suppress the qsort of the tree.
> > >
> > > Will this break any other git functions? Are there any commands that
> > > assume trees are always sorted?
> >
> > _YES IT BREAKS GIT_.
> >
> > You cannot do this.
> >
> > A Git repository whose trees are not sorted according to the Git
> > specific sort ordering is severly broken and most tools will fail
> > horribly on it.
> >
> > Almost all code which reads trees assumes the names are sorted in a
> > specific order. These tools perform sorted merges against other tree
> > like structures. If the names are out of order the merge will fail.
> > `git fsck` will complain that the tree is not sorted properly. Tools
> > like `git log -- foo.c` will fail randomly because they break out of
> > the entry lookup as soon as they find a name that is after foo.c, as
> > they assume the tree is sorted.
> >
> > I could go on. But there is no point.
> >
> > Oh, and trust me when I say this, the tree sorting matters. Long ago
> > JGit had a bug where it didn't sort trees correctly all of the time
> > and we had a devil of a time tracking down that corruption.
> >
>
> Thanks Shawn. I get the picture.
>
> Now, let's assume I am stubborn, crazy or both :-)
>
> I can modify fsck to ignore unsorted and at the moment I don't care
> about merging trees. If I hunt down all usage of base_name_compare will
> that identify all code with the sort assumption or is there other places
> as well? I can go > through the entire source to figure this out myself
> but I need to get something hacked up very quickly and would appreciate
> help even if you think I am nuts!
Look, one of the most trusted Git contributors just told you that you are
asking for trouble.
It has nothing to do with being stubborn if you insist on doing it now.
But I smell an XY problem. Why don't you just reveil _what_ you want to
do (as opposed to _how_ you think you should do it)?
Ciao,
Dscho
^ 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