* Re: Teach "approxidate" about weekday syntax
From: Linus Torvalds @ 2005-11-17 23:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x1eubpr.fsf@assigned-by-dhcp.cox.net>
On Thu, 17 Nov 2005, Junio C Hamano wrote:
>
> It is not English but Gittish, which is fine, but it somehow
> reminds me of the funny way users make themselves understood by
> IF parsers ;-). I am afraid you started small but now are going
> towards the same insanity of gnudate (it has insane yacc grammar
> to grok these things), and I suspect we'd better draw a line
> somewhere.
I think I'm done.
The multi-week "3 sundays ago" part came for free, but the "last sunday"
was actually something I liked.
Seriously, I can't imagine what else we'd want. It parses exact dates
(thanks to the old date-parsing code), and it now parses all the normal
"lazy dates" I can think of.
The fact that you can combine "last saturday" with "three days ago" is
really not a feature as much as a result of the algorithm being so simple
that it just doesn't care, and the combination just happens to work.
My examples were a bit silly as a result. In real life, you'd probably
never use any combinations, but simply use
"December 5th"
"last sunday"
"yesterday"
"two days ago"
"12 hours ago"
and the fact that then some (but definitely not all) combinations of the
above all work is really just an accident and not something that people
should necessarily even depend on.
> > Side note 2: if you want to avoid spaces (because of quoting issues), you
> > can use any non-alphanumberic character instead. So
> >
> > git log --since=2.days.ago
> >
> > works without any quotes.
>
> I think this is a useful change. Thanks.
That's actually not a new change, the approxidate thing always worked that
way, but I thought I'd point it out.
Linus
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: H. Peter Anvin @ 2005-11-17 23:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511171223110.13959@g5.osdl.org>
Linus Torvalds wrote:
> This allows people to use syntax like "last thursday" for the approxidate.
>
> (Or, indeed, more complex "three thursdays ago", but I suspect that would
> be pretty unusual).
>
> NOTE! The parsing is strictly sequential, so if you do
>
> "one day before last thursday"
>
> it will _not_ do what you think it does. It will take the current time,
> subtract one day, and then go back to the thursday before that. So to get
> what you want, you'd have to write it the other way around:
>
> "last thursday and one day before"
>
> which is insane (it's usually the same as "last wednesday" _except_ if
> today is Thursday, in which case "last wednesday" is yesterday, and "last
> thursday and one day before" is eight days ago).
>
> Similarly,
>
> "last thursday one month ago"
>
> will first go back to last thursday, and then go back one month from
> there, not the other way around.
>
> I doubt anybody would ever use insane dates like that, but I thought I'd
> point out that the approxidate parsing is not exactly "standard English".
>
I believe English would always parse from right to left, it might be the
right thing to do...
-hpa
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Yann Dirson @ 2005-11-17 23:07 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
Ryan wrote:
> Junio wrote:
> > Also another rhetorical, tongue-in-cheek question. What is your
> > plan to ripple the graft through to update signed tags? ;-)
>
> :) Well, since I can't resist answering your rhetorical question:
>
> They signed a specific DAG. I'm providing a richer, more complete DAG
> that is a pure-superset of the one they signed. It is not, however,
> equivalent, so their signature is not related to the superset DAG I have
> created. In practice, however, I don't expect that any tag-signers
> would state that there is a meaningful difference between the two DAGs,
> from the perspective of their signature.
Well, that seems the perfect place to mention an idea that's running
in my head since a couple of days, related to the grafing problem.
I'll write it here in case the idea would look interesting to others,
who may then find a solution to the problem stated by Junio.
Current commit objects refer to a child tree, but to parent _commits_.
Whereas it seems necessary to walk through the history line, and
easily get a changelog, it is semantically quite not right: the
changes we record with a commit indeed come from modification of
trees, not of commits. That is, the resulting tree does not depend on
the history of the parent trees, but on the parent trees themselves.
And similarly, tags usually denote a particular state of the tree,
"somewhat" independantly of its history: linux-2.6.11 is the same
beast, whereas the repository holds full history since 0.1 or not.
Indeed that emphasizes that the history lines are on living on a
higher level of abstraction that commits. Now what if we used
trees->tree commits, instead of the current commits->tree ones ? The
main problem would be to be able to reconstruct those history lines,
so that we can still extract the log - what's a better model if we
loose functionnality ? ;)
However, I must admit that at this point, I have not found a
reasonable solution to this problem.
Any genius with a solution out there ? :)
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Add git-config-set, a simple helper for scripts to set config variables
From: Junio C Hamano @ 2005-11-17 22:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511172244230.18285@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This is meant for the end user, who cannot be expected to edit
> .git/config by hand.
>
> Example:
>
> git-config-set core.filemode true
>
> will set filemode in the section [core] to true,
>
> git-config-set --unset core.filemode
>
> will remove the entry (failing if it is not there), and
>
> git-config-set --unset diff.twohead ^recar
>
> will remove the unique entry whose value matches the regex "^recar"
> (failing if there is no unique such entry).
It's kinda funny that your users cannot edit a plain text file
with an editor, but know how to do regex ;-).
I think the true value of this is that Porcelain scripts can
muck with configuration files.
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Junio C Hamano @ 2005-11-17 22:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511171223110.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> ..., you'd have to write it the other way around:
>
> "last thursday and one day before"
>
> which is insane (it's usually the same as "last wednesday" _except_ if
> today is Thursday, in which case "last wednesday" is yesterday, and "last
> thursday and one day before" is eight days ago).
> ...
> I doubt anybody would ever use insane dates like that, but I thought I'd
> point out that the approxidate parsing is not exactly "standard English".
It is not English but Gittish, which is fine, but it somehow
reminds me of the funny way users make themselves understood by
IF parsers ;-). I am afraid you started small but now are going
towards the same insanity of gnudate (it has insane yacc grammar
to grok these things), and I suspect we'd better draw a line
somewhere.
> Side note 2: if you want to avoid spaces (because of quoting issues), you
> can use any non-alphanumberic character instead. So
>
> git log --since=2.days.ago
>
> works without any quotes.
I think this is a useful change. Thanks.
^ permalink raw reply
* Re: [PATCH] Stgit - gitmergeonefile.py: handle removal vs. changes
From: Chuck Lever @ 2005-11-17 22:50 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Blaisorblade, git
In-Reply-To: <b0943d9e0511171410y357fb0bfv@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]
Catalin Marinas wrote:
> On 16/11/05, Blaisorblade <blaisorblade@yahoo.it> wrote:
>>>Another option would be to
>>>remove the file and leave both file.older and file.remote in the tree
>>>(here .remote means the version in the patch)
>>
>>I remember that at times, but .remote is very confusing... I see that's the
>>mishandling is induced by various sources, maybe including "merge" itself,
>>but that program (and possibly others) supports changing the labels, and this
>>should probably be done (using "original", "patched" and "upstream"
>>probably).
>
>
> I know that diff3/merge support labels. I don't exactly remember my
> reasons but I think that I chose those namings because StGIT was
> supporting another type of merge where "patched" etc. did not apply.
>
> I agree that we should change them. I would rather use "ancestor",
> "patch" and "base" but I don't have a strong opinion.
just a data point:
i use "original" "patch" and "older" (set up in .stgitrc) because i
found the default labels to be confusing.
but "original" "patch" and "upstream" make sense to me.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Linus Torvalds @ 2005-11-17 22:44 UTC (permalink / raw)
To: Franck; +Cc: Git Mailing List
In-Reply-To: <cda58cb80511171347yef4f090g@mail.gmail.com>
On Thu, 17 Nov 2005, Franck wrote:
> 2005/11/17, Linus Torvalds <torvalds@osdl.org>:
> >
> > What you probably _can_ do is to find whatever top-most commit you want
> > (say, the v2.6.0 commit), and use grafting to make that have no parents.
> > Then you can do git-prune to get rid of everything under it.
> >
>
> ok that's what I was trying to do by killing the parent object. Now
> when looking a the graph using gitk all old objects have been removed.
> But I'm suprised because the git repository is the same size as it was
> before pruning all old objects. Can you explain why ?
make sure you re-pack if it was packed. "git prune" will not remove packs
at all, so..
Linus
^ permalink raw reply
* git rebase conflict help?
From: Kevin Geiss @ 2005-11-17 22:20 UTC (permalink / raw)
To: git
I fetched my origin branch, then tried to run 'git rebase origin'.
one of my commits from master which is not yet in origin got a
conflict, so git rebase origin told me that the Simple cherry-pick
failed, and the Automatic cherry-pick got conflicts. and it saved the
commit message for me in .msg and my offending commit's id in .rebase-
tmp32409.
I'm not sure how to proceed from here. actually, I know what the
offending changes are, and I could re-do the changes by hand and
commit them again, but I'd like to know what git tools I'm supposed
to use in this case...
thanks.
^ permalink raw reply
* Re: [PATCH] Stgit - gitmergeonefile.py: handle removal vs. changes
From: Catalin Marinas @ 2005-11-17 22:10 UTC (permalink / raw)
To: Blaisorblade; +Cc: git
In-Reply-To: <200511161544.13825.blaisorblade@yahoo.it>
On 16/11/05, Blaisorblade <blaisorblade@yahoo.it> wrote:
> On Tuesday 15 November 2005 10:54, Catalin Marinas wrote:
> Actually, with .git/commits we are reimplementing handling of "unmerged"
> entries... it could be better to use the "unmerged entry" stgit idea. So "stg
> resolved" should modify the entries by itself.
But would a git-diff-tree still show the changes between the current
files and the index if there are unmerged entries? I haven't tried it.
> > My initial idea was to make
> > gitmergeonefile not to leave any unmerged entries in the index. As you
> > could see, there are cases where it failed.
>
> Yep... it seems you took examples from git-merge-one-file, but that's lacking
> (but it's low-level so it's appropriate for it - it must leave unmerged
> entries when there are conflicts).
When I started writing StGIT, my main thoughts were driven towards the
patch merging/commuting via the diff3 algorithm. I found it simpler to
copy the algorithm from git-merge-one-file since that wasn't my main
interest in StGIT. I also looked at how Cogito did it.
> > I can see the following scenarios for a file:
>
> In both cases, we're going to have a conflict, so we leave file.
> {older,remote,local} as appropriate and already done.
>
> > 1. deleted in the base and modified by the patch. It should leave the
> > file in the tree together with file.older.
>
> Why not leaving file.remote? We already do that in general, so we have a
> duplicate, but it's easier to understand.
I agree with this.
> > Another option would be to
> > remove the file and leave both file.older and file.remote in the tree
> > (here .remote means the version in the patch)
>
> I remember that at times, but .remote is very confusing... I see that's the
> mishandling is induced by various sources, maybe including "merge" itself,
> but that program (and possibly others) supports changing the labels, and this
> should probably be done (using "original", "patched" and "upstream"
> probably).
I know that diff3/merge support labels. I don't exactly remember my
reasons but I think that I chose those namings because StGIT was
supporting another type of merge where "patched" etc. did not apply.
I agree that we should change them. I would rather use "ancestor",
"patch" and "base" but I don't have a strong opinion.
> > 2. changed in the base but deleted by the patch. It should remove the
> > file from the tree but leave file.older and file.local. The other
> > option is to leave the file in the tree but, as above, I prefer the
> > first one.
>
> The policy about when to remove the file and when to leave it is very
> personal... the user must anyway solve the conflict in some smart way...
> about the defaults, anything would do, but if we really care we could leave
> the user the choice.
At the moment, the conflicts usually leave the index in the state
before pushing the patch. I think it should also leave the file and
just mark it as conflict in .git/conflicts.
--
Catalin
^ permalink raw reply
* [PATCH 0/4] Add a method to set config variables
From: Johannes Schindelin @ 2005-11-17 21:51 UTC (permalink / raw)
To: git, junkio
Hi,
sorry, just realized that I forgot the sequence numbers, but I am in a
hurry. git_config_set() needs to be there before git-config-set can be
there, and only then the test case can be executed. The documentation only
makes sense once the command is there.
I'll be back in about 2 hours,
Dscho
^ permalink raw reply
* [PATCH] Add test case for git-config-set
From: Johannes Schindelin @ 2005-11-17 21:50 UTC (permalink / raw)
To: git, junkio
... includes the mean tests I mentioned on the list.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
t1300-config-set.sh | 180 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 180 insertions(+), 0 deletions(-)
create mode 100644 t1300-config-set.sh
applies-to: de5d2a42ebd69e3608e0f99f615fbcf55a88c101
3fa048df0d691d3423ec81f8dba947e2c05fa996
diff --git a/t1300-config-set.sh b/t1300-config-set.sh
new file mode 100644
index 0000000..df89216
--- /dev/null
+++ b/t1300-config-set.sh
@@ -0,0 +1,180 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Johannes Schindelin
+#
+
+test_description='Test git-config-set in different settings'
+
+. ./test-lib.sh
+
+test -f .git/config && rm .git/config
+
+git-config-set core.penguin "little blue"
+
+cat > expect << EOF
+#
+# This is the config file
+#
+
+[core]
+ penguin = little blue
+EOF
+
+test_expect_success 'initial' 'cmp .git/config expect'
+
+git-config-set Core.Movie BadPhysics
+
+cat > expect << EOF
+#
+# This is the config file
+#
+
+[core]
+ penguin = little blue
+ Movie = BadPhysics
+EOF
+
+test_expect_success 'mixed case' 'cmp .git/config expect'
+
+git-config-set Cores.WhatEver Second
+
+cat > expect << EOF
+#
+# This is the config file
+#
+
+[core]
+ penguin = little blue
+ Movie = BadPhysics
+[Cores]
+ WhatEver = Second
+EOF
+
+test_expect_success 'similar section' 'cmp .git/config expect'
+
+git-config-set CORE.UPPERCASE true
+
+cat > expect << EOF
+#
+# This is the config file
+#
+
+[core]
+ penguin = little blue
+ Movie = BadPhysics
+ UPPERCASE = true
+[Cores]
+ WhatEver = Second
+EOF
+
+test_expect_success 'similar section' 'cmp .git/config expect'
+
+cat > .git/config << EOF
+[beta] ; silly comment # another comment
+noIndent= sillyValue ; 'nother silly comment
+
+# empty line
+ ; comment
+ haha ="beta" # last silly comment
+[nextSection] noNewline = ouch
+EOF
+
+git-config-set beta.haha alpha
+
+cat > expect << EOF
+[beta] ; silly comment # another comment
+noIndent= sillyValue ; 'nother silly comment
+
+# empty line
+ ; comment
+ haha = alpha
+[nextSection] noNewline = ouch
+EOF
+
+test_expect_success 'really mean test' 'cmp .git/config expect'
+
+git-config-set nextsection.nonewline wow
+
+cat > expect << EOF
+[beta] ; silly comment # another comment
+noIndent= sillyValue ; 'nother silly comment
+
+# empty line
+ ; comment
+ haha = alpha
+[nextSection]
+ nonewline = wow
+EOF
+
+test_expect_success 'really really mean test' 'cmp .git/config expect'
+
+git-config-set beta.haha
+
+cat > expect << EOF
+[beta] ; silly comment # another comment
+noIndent= sillyValue ; 'nother silly comment
+
+# empty line
+ ; comment
+[nextSection]
+ nonewline = wow
+EOF
+
+test_expect_success 'unset' 'cmp .git/config expect'
+
+git-config-set nextsection.NoNewLine "wow2 for me" "for me$"
+
+cat > expect << EOF
+[beta] ; silly comment # another comment
+noIndent= sillyValue ; 'nother silly comment
+
+# empty line
+ ; comment
+[nextSection]
+ nonewline = wow
+ NoNewLine = wow2 for me
+EOF
+
+test_expect_success 'multivar' 'cmp .git/config expect'
+
+git-config-set nextsection.nonewline "wow3" "wow$"
+
+cat > expect << EOF
+[beta] ; silly comment # another comment
+noIndent= sillyValue ; 'nother silly comment
+
+# empty line
+ ; comment
+[nextSection]
+ nonewline = wow3
+ NoNewLine = wow2 for me
+EOF
+
+test_expect_success 'multivar replace' 'cmp .git/config expect'
+
+test_expect_failure 'ambiguous unset' \
+ 'git-config-set --unset nextsection.nonewline'
+
+test_expect_failure 'invalid unset' \
+ 'git-config-set --unset somesection.nonewline'
+
+git-config-set --unset nextsection.nonewline "wow3$"
+
+cat > expect << EOF
+[beta] ; silly comment # another comment
+noIndent= sillyValue ; 'nother silly comment
+
+# empty line
+ ; comment
+[nextSection]
+ NoNewLine = wow2 for me
+EOF
+
+test_expect_success 'multivar unset' 'cmp .git/config expect'
+
+test_expect_failure 'invalid key' 'git-config-set inval.2key blabla'
+
+test_expect_success 'correct key' 'git-config-set 123456.a123 987'
+
+test_done
+
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Add documentation for git-config-set
From: Johannes Schindelin @ 2005-11-17 21:49 UTC (permalink / raw)
To: git, junkio
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Documentation/git-config-set.txt | 108 ++++++++++++++++++++++++++++++++++++++
Documentation/git.txt | 3 +
2 files changed, 111 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-config-set.txt
applies-to: ee7303ec1f89940eeb5b565477ad903c379004fd
51745dec61000862d5afbdf7024e7793424e7c10
diff --git a/Documentation/git-config-set.txt b/Documentation/git-config-set.txt
new file mode 100644
index 0000000..8e897be
--- /dev/null
+++ b/Documentation/git-config-set.txt
@@ -0,0 +1,108 @@
+git-config-set(1)
+===============
+
+NAME
+----
+git-config-set - Set options in .git/config.
+
+
+SYNOPSIS
+--------
+'git-config-set' ( name [value [value_regex]] | --unset name [value_regex] )
+
+DESCRIPTION
+-----------
+You can set/replace/unset options with this command. The name is actually
+the section and the key separated by a dot, and the value will be escaped.
+
+If you want to set/unset an option which can occor on multiple lines, you
+should provide a POSIX regex for the value.
+
+This command will fail if
+
+. .git/config is invalid,
+. .git/config can not be written to,
+. no section was provided,
+. the section or key is invalid,
+. you try to unset an option which does not exist, or
+. you try to unset/set an option for which multiple lines match.
+
+
+OPTIONS
+-------
+
+--unset::
+ Remove the given option from .git/config
+
+
+EXAMPLE
+-------
+
+Given a .git/config like this:
+
+ #
+ # This is the config file, and
+ # a '#' or ';' character indicates
+ # a comment
+ #
+
+ ; core variables
+ [core]
+ ; Don't trust file modes
+ filemode = false
+
+ ; Our diff algorithm
+ [diff]
+ external = "/usr/local/bin/gnu-diff -u"
+ renames = true
+
+ ; Proxy settings
+ [proxy]
+ command="ssh" for "ssh://kernel.org/"
+ command="proxy-command" for kernel.org
+ command="myprotocol-command" for "my://"
+
+you can set the filemode to true with
+
+------------
+% git config-set core.filemode true
+------------
+
+The hypothetic proxy command entries actually have a postfix to discern
+to what URL they apply. Here is how to change the entry for kernel.org
+to "ssh".
+
+------------
+% git config-set proxy.command '"ssh" for kernel.org' 'for kernel.org$'
+------------
+
+This makes sure that only the key/value pair for kernel.org is replaced.
+
+To delete the entry for renames, do
+
+------------
+% git config-set --unset diff.renames
+------------
+
+or just
+
+------------
+% git config-set diff.renames
+------------
+
+If you want to delete an entry for a multivar (like proxy.command above),
+you have to provide a regex matching the value of exactly one line.
+
+
+Author
+------
+Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
+
+Documentation
+--------------
+Documentation by Johannes Schindelin.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 338e5ac..694fee8 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -84,6 +84,9 @@ gitlink:git-checkout-index[1]::
gitlink:git-commit-tree[1]::
Creates a new commit object
+gitlink:git-config-set[1]::
+ Set options in .git/config.
+
gitlink:git-hash-object[1]::
Computes the object ID from a file.
---
0.99.9.GIT
^ permalink raw reply related
* Re: [QUESTION] Access to a huge GIT repository.
From: Franck @ 2005-11-17 21:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511170817480.13959@g5.osdl.org>
2005/11/17, Linus Torvalds <torvalds@osdl.org>:
>
> What you probably _can_ do is to find whatever top-most commit you want
> (say, the v2.6.0 commit), and use grafting to make that have no parents.
> Then you can do git-prune to get rid of everything under it.
>
ok that's what I was trying to do by killing the parent object. Now
when looking a the graph using gitk all old objects have been removed.
But I'm suprised because the git repository is the same size as it was
before pruning all old objects. Can you explain why ?
Thanks
--
Franck
^ permalink raw reply
* Add git-config-set, a simple helper for scripts to set config variables
From: Johannes Schindelin @ 2005-11-17 21:44 UTC (permalink / raw)
To: git, junkio
This is meant for the end user, who cannot be expected to edit
.git/config by hand.
Example:
git-config-set core.filemode true
will set filemode in the section [core] to true,
git-config-set --unset core.filemode
will remove the entry (failing if it is not there), and
git-config-set --unset diff.twohead ^recar
will remove the unique entry whose value matches the regex "^recar"
(failing if there is no unique such entry).
It is just a light wrapper around git_config_set() and
git_config_set_multivar().
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
.gitignore | 1 +
Makefile | 3 ++-
config-set.c | 26 ++++++++++++++++++++++++++
3 files changed, 29 insertions(+), 1 deletions(-)
create mode 100644 config-set.c
applies-to: 8ff699dffc817e92fb2101f538f84c38d5ed0a0f
acf7869a158171bf4552d0b0da64b20d48e4bf27
diff --git a/.gitignore b/.gitignore
index 0dd7b9c..d17a8b5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,6 +17,7 @@ git-clone
git-clone-pack
git-commit
git-commit-tree
+git-config-set
git-convert-objects
git-count-objects
git-cvsexportcommit
diff --git a/Makefile b/Makefile
index ebff990..8e84e28 100644
--- a/Makefile
+++ b/Makefile
@@ -125,7 +125,8 @@ PROGRAMS = \
git-unpack-objects$X git-update-index$X git-update-server-info$X \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
git-update-ref$X git-symbolic-ref$X git-check-ref-format$X \
- git-name-rev$X git-pack-redundant$X git-var$X $(SIMPLE_PROGRAMS)
+ git-name-rev$X git-pack-redundant$X git-config-set$X git-var$X \
+ $(SIMPLE_PROGRAMS)
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
diff --git a/config-set.c b/config-set.c
new file mode 100644
index 0000000..1b1547b
--- /dev/null
+++ b/config-set.c
@@ -0,0 +1,26 @@
+#include "cache.h"
+
+static const char git_config_set_usage[] =
+"git-config-set name [value [value_regex]] | --unset name [value_regex]";
+
+int main(int argc, const char **argv)
+{
+ setup_git_directory();
+ switch (argc) {
+ case 2:
+ return git_config_set(argv[1], NULL);
+ case 3:
+ if (!strcmp(argv[1], "--unset"))
+ return git_config_set(argv[2], NULL);
+ else
+ return git_config_set(argv[1], argv[2]);
+ case 4:
+ if (!strcmp(argv[1], "--unset"))
+ return git_config_set_multivar(argv[2], NULL, argv[3]);
+ else
+ return git_config_set_multivar(argv[1], argv[2], argv[3]);
+ default:
+ usage(git_config_set_usage);
+ }
+ return 0;
+}
---
0.99.9.GIT
^ permalink raw reply related
* Re: [Question] info/grafts file.
From: Yann Dirson @ 2005-11-17 21:45 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Carl Baldwin, Junio C Hamano, git
In-Reply-To: <437BD56A.7030402@michonline.com>
On Wed, Nov 16, 2005 at 07:57:14PM -0500, Ryan Anderson wrote:
> Carl Baldwin wrote:
> > This is fine, I just needed to know.
> >
> > How hard is it to, in a generic way, take a grafts file and reconstruct
> > commits to include the parents in the graft file in the actual tree? I
> > am wondering because I couldn't, after much work, get git-svnimport to
> > find my merges correctly. So, I am needing to hand-graft some merges in
> > to make things right. Any suggestions? I could try to figure something
> > out if I can find some time. I'm good with graph traversals and such.
>
> It's actually pretty easy. I wrote a rough (and not quite safe) tool to
> do this a week or so ago.
>
> http://marc.theaimsgroup.com/?l=git&m=113131673606637&w=2
>
> I will try and clean it up a bit and submit it for inclusion in contrib/
> sometime this coming weekend, but you should be able to use it to solve
> this problem.
>
> It's pretty straightforward, honestly. (And I'm pretty sure it could be
> faster if I did things slightly differently.)
Hey, this exactly looks like the kind of script I intended to write in
the following days ! I'll have a close look at it. Do you have a git
repo from where I could pull the latest version ?
My goal is to write an "AcheoloGIT" toolkit, to be able to reconstruct
an history incrementally, from patches, identifying in the way patches
which build upon other patches. To make it more clear, there are in
the embedded world a number of vendor shipping "jumbo patches", which
include parts or all of official arch-specific trees, with more stuff
added.
And well, since it is not an easy task, the process has to be
incremental, grafting here and there between various parts of the tree
to gradually refine my view of its history.
There is some preliminary work, but for now only focussed on making
the import of series of patches more comforable. Grafting was
supposed to be the next step :)
http://ydirson.free.fr/soft/git/argit.git/
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Teach "approxidate" about weekday syntax
From: Johannes Schindelin @ 2005-11-17 21:44 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511171622450.14287@localhost.localdomain>
Hi,
On Thu, 17 Nov 2005, Nicolas Pitre wrote:
> On Thu, 17 Nov 2005, Linus Torvalds wrote:
>
> > NOTE! The parsing is strictly sequential, so if you do
> >
> > "one day before last thursday"
> >
> > it will _not_ do what you think it does. It will take the current time,
> > subtract one day, and then go back to the thursday before that.
>
> Maybe if you applied the different time units in decreasing size that
> would do the trick? e.g. months have precedence over weeks, weeks over
> weekdays, weekdays over days, etc.
Or even better: make it relative until you find an absolute reference.
I.e. "one day" will be 1 * 86400, and if you then parse "before", it
will get negative, then "last thursday" will be the absolute reference.
'f course, "one day before last thursday in september" will be a PITA.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add functions git_config_set() and git_config_set_multivar()
From: Johannes Schindelin @ 2005-11-17 21:32 UTC (permalink / raw)
To: git, junkio
The function git_config_set() does exactly what you think it does.
Given a key (in the form "core.filemode") and a value, it sets the
key to the value. Example:
git_config_set("core.filemode", "true");
The function git_config_set_multivar() is meant for setting variables which
can have several values for the same key. Example:
[diff]
twohead = resolve
twohead = recarsive
the typo in the second line can be replaced by
git_config_set_multivar("diff.twohead", "recursive", "^recar");
The third argument of the function is a POSIX extended regex which has to
match the value. If there is no key/value pair with a matching value, a new
key/value pair is added.
These commands are also capable of unsetting (deleting) entries:
git_config_set_multivar("diff.twohead", NULL, "sol");
will delete the entry
twohead = resolve
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
cache.h | 2
config.c | 294 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 295 insertions(+), 1 deletions(-)
diff --git a/cache.h b/cache.h
index 99afa2c..f93f516 100644
--- a/cache.h
+++ b/cache.h
@@ -386,6 +386,8 @@ extern int git_default_config(const char
extern int git_config(config_fn_t fn);
extern int git_config_int(const char *, const char *);
extern int git_config_bool(const char *, const char *);
+extern int git_config_set(const char *, const char *);
+extern int git_config_set_multivar(const char *, const char *, const char *);
#define MAX_GITNAME (1000)
extern char git_default_email[MAX_GITNAME];
diff --git a/config.c b/config.c
index 915bb97..bbcafff 100644
--- a/config.c
+++ b/config.c
@@ -1,5 +1,12 @@
-
+/*
+ * GIT - The information manager from hell
+ *
+ * Copyright (C) Linus Torvalds, 2005
+ * Copyright (C) Johannes Schindelin, 2005
+ *
+ */
#include "cache.h"
+#include <regex.h>
#define MAXNAME (256)
@@ -252,3 +259,288 @@ int git_config(config_fn_t fn)
}
return ret;
}
+
+/*
+ * Find all the stuff for git_config_set() below.
+ */
+static struct {
+ int baselen;
+ char* key;
+ regex_t* value_regex;
+ off_t offset;
+ enum { START, SECTION_SEEN, SECTION_END_SEEN, KEY_SEEN } state;
+ int seen;
+} store;
+
+static int store_aux(const char* key, const char* value)
+{
+ switch (store.state) {
+ case KEY_SEEN:
+ if (!strcmp(key, store.key) &&
+ (store.value_regex == NULL ||
+ !regexec(store.value_regex, value, 0, NULL, 0))) {
+ if (store.seen == 1) {
+ fprintf(stderr,
+ "Warning: %s has multiple values\n",
+ key);
+ }
+ store.offset = ftell(config_file);
+ store.seen++;
+ }
+ break;
+ case SECTION_SEEN:
+ if (strncmp(key, store.key, store.baselen+1)) {
+ store.state = SECTION_END_SEEN;
+ break;
+ } else
+ store.offset = ftell(config_file);
+ /* fallthru */
+ case SECTION_END_SEEN:
+ case START:
+ if (!strcmp(key, store.key) &&
+ (store.value_regex == NULL ||
+ !regexec(store.value_regex, value, 0, NULL, 0))) {
+ store.offset = ftell(config_file);
+ store.state = KEY_SEEN;
+ store.seen++;
+ } else if(!strncmp(key, store.key, store.baselen))
+ store.state = SECTION_SEEN;
+ }
+ return 0;
+}
+
+static void store_write_section(int fd, const char* key)
+{
+ write(fd, "[", 1);
+ write(fd, key, store.baselen);
+ write(fd, "]\n", 2);
+}
+
+static void store_write_pair(int fd, const char* key, const char* value)
+{
+ int i;
+
+ write(fd, "\t", 1);
+ write(fd, key+store.baselen+1,
+ strlen(key+store.baselen+1));
+ write(fd, " = ", 3);
+ for (i = 0; value[i]; i++)
+ switch (value[i]) {
+ case '\n': write(fd, "\\n", 2); break;
+ case '\t': write(fd, "\\t", 2); break;
+ case '"': case '\\': write(fd, "\\", 1);
+ default: write(fd, value+i, 1);
+ }
+ write(fd, "\n", 1);
+}
+
+int git_config_set(const char* key, const char* value)
+{
+ return git_config_set_multivar(key, value, NULL);
+}
+
+/*
+ * If value==NULL, unset in (remove from) config,
+ * if value_regex!=NULL, disregard key/value pairs where value does not match.
+ *
+ * Returns 0 on success.
+ *
+ * This function does this:
+ *
+ * - it locks the config file by creating ".git/config.lock"
+ *
+ * - it then parses the config using store_aux() as validator to find
+ * the position on the key/value pair to replace. If it is to be unset,
+ * it must be found exactly once.
+ *
+ * - the config file is mmap()ed and the part before the match (if any) is
+ * written to the lock file, then the changed part and the rest.
+ *
+ * - the config file is removed and the lock file rename()d to it.
+ *
+ */
+int git_config_set_multivar(const char* key, const char* value,
+ const char* value_regex)
+{
+ int i;
+ struct stat st;
+ int fd;
+ char* config_file = strdup(git_path("config"));
+ char* lock_file = strdup(git_path("config.lock"));
+
+ /*
+ * Since "key" actually contains the section name and the real
+ * key name separated by a dot, we have to know where the dot is.
+ */
+ for (store.baselen = 0;
+ key[store.baselen] != '.' && key[store.baselen];
+ store.baselen++);
+ if (!key[store.baselen] || !key[store.baselen+1]) {
+ fprintf(stderr, "key does not contain a section: %s\n", key);
+ return 2;
+ }
+
+ /*
+ * Validate the key and while at it, lower case it for matching.
+ */
+ store.key = (char*)malloc(strlen(key)+1);
+ for (i = 0; key[i]; i++)
+ if (i != store.baselen && (!isalnum(key[i]) ||
+ (i == store.baselen+1 && !isalpha(key[i])))) {
+ fprintf(stderr, "invalid key: %s\n", key);
+ free(store.key);
+ return 1;
+ } else
+ store.key[i] = tolower(key[i]);
+
+ /*
+ * The lock_file serves a purpose in addition to locking: the new
+ * contents of .git/config will be written into it.
+ */
+ fd = open(lock_file, O_WRONLY | O_CREAT | O_EXCL, 0666);
+ if (fd < 0) {
+ fprintf(stderr, "could not lock config file\n");
+ free(store.key);
+ return -1;
+ }
+
+ /*
+ * If .git/config does not exist yet, write a minimal version.
+ */
+ if (stat(config_file, &st)) {
+ static const char contents[] =
+ "#\n"
+ "# This is the config file\n"
+ "#\n"
+ "\n";
+
+ free(store.key);
+
+ /* if nothing to unset, error out */
+ if (value == NULL) {
+ close(fd);
+ unlink(lock_file);
+ return 5;
+ }
+
+ store.key = (char*)key;
+
+ write(fd, contents, sizeof(contents)-1);
+ store_write_section(fd, key);
+ store_write_pair(fd, key, value);
+ } else{
+ int in_fd;
+ char* contents;
+ int offset, new_line = 0;
+
+ if (value_regex == NULL)
+ store.value_regex = NULL;
+ else {
+ store.value_regex = (regex_t*)malloc(sizeof(regex_t));
+ if (regcomp(store.value_regex, value_regex,
+ REG_EXTENDED)) {
+ fprintf(stderr, "Invalid pattern: %s",
+ value_regex);
+ free(store.value_regex);
+ return 6;
+ }
+ }
+
+ store.offset = 0;
+ store.state = START;
+ store.seen = 0;
+
+ /*
+ * After this, store.offset will contain the *end* offset
+ * of the last match, or remain at 0 if no match was found.
+ * As a side effect, we make sure to transform only a valid
+ * existing config file.
+ */
+ if (git_config(store_aux)) {
+ fprintf(stderr, "invalid config file\n");
+ free(store.key);
+ if (store.value_regex != NULL) {
+ regfree(store.value_regex);
+ free(store.value_regex);
+ }
+ return 3;
+ }
+
+ free(store.key);
+ if (store.value_regex != NULL) {
+ regfree(store.value_regex);
+ free(store.value_regex);
+ }
+
+ /* if nothing to unset, error out */
+ if (store.seen == 0 && value == NULL) {
+ close(fd);
+ unlink(lock_file);
+ return 5;
+ }
+
+ store.key = (char*)key;
+
+ in_fd = open(config_file, O_RDONLY, 0666);
+ contents = mmap(NULL, st.st_size, PROT_READ,
+ MAP_PRIVATE, in_fd, 0);
+ close(in_fd);
+
+ if (store.offset == 0) {
+ store.offset = offset = st.st_size;
+ } else if (store.state != KEY_SEEN) {
+ offset = store.offset;
+ } else {
+ int equal_offset = st.st_size,
+ bracket_offset = st.st_size;
+
+ if (value == NULL && store.seen > 1) {
+ fprintf(stderr, "Cannot remove multivar (%s has %d values\n", key, store.seen);
+ close(fd);
+ unlink(lock_file);
+ return 7;
+ }
+ for (offset = store.offset-2; offset > 0
+ && contents[offset] != '\n'; offset--)
+ switch (contents[offset]) {
+ case '=': equal_offset = offset; break;
+ case ']': bracket_offset = offset; break;
+ }
+ if (bracket_offset < equal_offset) {
+ new_line = 1;
+ offset = bracket_offset+1;
+ } else
+ offset++;
+ }
+
+ /* write the first part of the config */
+ write(fd, contents, offset);
+ if (new_line)
+ write(fd, "\n", 1);
+
+ /* write the pair (value == NULL means unset) */
+ if (value != NULL) {
+ if (store.state == START)
+ store_write_section(fd, key);
+ store_write_pair(fd, key, value);
+ }
+
+ /* write the rest of the config */
+ if (store.offset < st.st_size)
+ write(fd, contents + store.offset,
+ st.st_size - store.offset);
+
+ munmap(contents, st.st_size);
+ unlink(config_file);
+ }
+
+ close(fd);
+
+ if (rename(lock_file, config_file) < 0) {
+ fprintf(stderr, "Could not rename the lock file?\n");
+ return 4;
+ }
+
+ return 0;
+}
+
^ permalink raw reply related
* Re: Teach "approxidate" about weekday syntax
From: Nicolas Pitre @ 2005-11-17 21:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511171223110.13959@g5.osdl.org>
On Thu, 17 Nov 2005, Linus Torvalds wrote:
> NOTE! The parsing is strictly sequential, so if you do
>
> "one day before last thursday"
>
> it will _not_ do what you think it does. It will take the current time,
> subtract one day, and then go back to the thursday before that.
Maybe if you applied the different time units in decreasing size that
would do the trick? e.g. months have precedence over weeks, weeks over
weekdays, weekdays over days, etc.
Nicolas
^ permalink raw reply
* Re: [PATCH] Fix git_config_set() for mean cases
From: Johannes Schindelin @ 2005-11-17 21:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x1ful7j.fsf@assigned-by-dhcp.cox.net>
Hi,
[taking the discussion back to public]
On Thu, 17 Nov 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Also, I felt that a function like git_config_set() was lacking for too
> > long from git. Maybe git-init-db does not need that flag, but I guess that
> > we'd want to write config variables comfortably from C at some stage.
>
> Yes. But I hesitate to throw in an interface that dismisses the
> multivalued key problem without thinking things through first.
Okay, I gave it some thought. See below for my points.
> BTW, I think this discussion should be thrown back to the
> public. It went private by accident.
Hereby done.
> Mind rehashing the discussion so far in the open?
>
> The main points I can think of are:
>
> - configuration file format and semantics cleanups (methinks
> it is premature to talk about implementation and interface
> before discussing this).
>
> - allowing sectionless variables seems to be a bug. disallow
> it.
Agree.
> - section names are alnum (i.e. they can start with a digit)
> while variable names are alpha+alnum. is this what we
> want? otherwise how should the rule be changed?
It seems natural to make variables start with alpha, since people are so
used to it. It would not hurt the parsing to make them possibly start with
a digit, but I think it's okay to let it be as it is.
> - multivalued variables. it is nice to have such, and is
> easier to read by humans (methinks). it is not how other
> systems do .ini format, and the tools can live with single
> value and parse it into list of values (methinks that is
> what you are saying). which way are we going? does the
> order matter in such list valued variable in either case?
To recap:
[proxy]
command="ssh" for "ssh://kernel.org/"
command="proxy-command" for kernel.org
command="myprotocol-command" for "my://"
It should be possible to set only the command for kernel.org while leaving
the others. I actually implemented a function
git_config_set_multivar(const char* name, const char* value,
const char* value_regex);
which you can call like this:
git_config_set_multivar(
"proxy.command",
"\"rsh\" for kernel.org",
"for kernel.org$");
to change just the second command. You can use that function also to
unset (i.e. remove) an entry:
git_config_set_multivar(
"proxy.command",
NULL,
"for \"ssh://kernel.org\"$");
> - having a way for scripts to query and update the config file
> programatically is a good thing, both from C level and script
> level (i do not think there is a disagreement between us on
> this point).
There is no disagreement.
> - _if_ we do multivalued variables, what is the interface to
> append, replace, and remove one of the values? (we may be
> able to get away by only supporting "replace the whole
> thing", in which case the program can do git_config_get()
> to grab the list, manipulate the list and feed the updated
> list to git_config_set()).
See above. For clarities sake, I left "git_config_set(name,value)" as
shortcut to "git_config_set_multivar(name,value,NULL)", i.e. calling the
multivar version with value_regex==NULL actually reverts to singlevar
version.
I'll send out the patches in a few minutes (have to get them into shape
first).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make git-pack-redundant non-horribly slow on large sets of packs
From: Alex Riesen @ 2005-11-17 20:39 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, junkio
In-Reply-To: <437C819C.4040507@etek.chalmers.se>
Lukas Sandström, Thu, Nov 17, 2005 14:11:56 +0100:
> Change the smallest-set detection algortithm so that when
> we have found a good set, we don't check any larger sets.
I used latest git (a575603af20a795584d79b32c30bda10fcae5d3f Merge
branch 'tojunio' of http://locke.catalyst.net.nz/git/git-martinlanghoff)
and the patch on top.
Alex Riesen, Thu, Nov 17, 2005 08:45:46 +0100:
> > Could you try updating to the latest snapshot? There was a bug in a
> > list handling function which was fixed recently, perhaps your problem
> > is related.
>
> will try, but I didn't realize yesterday that it might be a good idea
> to keep the old repository around. The lot of packs was automatically
> created by incremental repacking after every pull. Sorry...
ok, pack-redundant --all in a repository with 25 packs completed in
1.346 sec. That's definitely an improvement.
But, the repository (a clone of Linus' kernel) didn't have a
superpack. I created one (git repack -a) and started
"pack-redundant --all". And almost oomed the system (it has 1Gb RAM +
512Mb(historically) swap, BTW): oom-killer killed git-pack-redundant.
Peak memory usage was around 1.3Gb, than everything stopped. The
repository had 140718 objects.
^ permalink raw reply
* Teach "approxidate" about weekday syntax
From: Linus Torvalds @ 2005-11-17 20:36 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This allows people to use syntax like "last thursday" for the approxidate.
(Or, indeed, more complex "three thursdays ago", but I suspect that would
be pretty unusual).
NOTE! The parsing is strictly sequential, so if you do
"one day before last thursday"
it will _not_ do what you think it does. It will take the current time,
subtract one day, and then go back to the thursday before that. So to get
what you want, you'd have to write it the other way around:
"last thursday and one day before"
which is insane (it's usually the same as "last wednesday" _except_ if
today is Thursday, in which case "last wednesday" is yesterday, and "last
thursday and one day before" is eight days ago).
Similarly,
"last thursday one month ago"
will first go back to last thursday, and then go back one month from
there, not the other way around.
I doubt anybody would ever use insane dates like that, but I thought I'd
point out that the approxidate parsing is not exactly "standard English".
Side note 2: if you want to avoid spaces (because of quoting issues), you
can use any non-alphanumberic character instead. So
git log --since=2.days.ago
works without any quotes.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/date.c b/date.c
index 73c063b..d2a67cc 100644
--- a/date.c
+++ b/date.c
@@ -34,7 +34,7 @@ static const char *month_names[] = {
};
static const char *weekday_names[] = {
- "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"
+ "Sundays", "Mondays", "Tuesdays", "Wednesdays", "Thursdays", "Fridays", "Saturdays"
};
/*
@@ -531,6 +531,22 @@ static const char *approxidate_alpha(con
tl++;
}
+ for (i = 0; i < 7; i++) {
+ int match = match_string(date, weekday_names[i]);
+ if (match >= 3) {
+ int diff, n = *num -1;
+ *num = 0;
+
+ diff = tm->tm_wday - i;
+ if (diff <= 0)
+ n++;
+ diff += 7*n;
+
+ update_tm(tm, diff * 24 * 60 * 60);
+ return end;
+ }
+ }
+
if (match_string(date, "months") >= 5) {
int n = tm->tm_mon - *num;
*num = 0;
^ permalink raw reply related
* Re: Question on GIT tutorial.
From: Junio C Hamano @ 2005-11-17 19:47 UTC (permalink / raw)
To: Franck; +Cc: git
In-Reply-To: <cda58cb80511140220n26da3edm@mail.gmail.com>
Franck <vagabon.xyz@gmail.com> writes:
> Hi,
>
> I have a question about the GIT tutorial. At page 21, there is a
> description of "subsystem maintainer" work cycle, I don't understand
> why point 3 is needed. This point tells:
>
> """
> Copy over the packed files from "project lead" public repository to
> your public repository.
> """
>
> Why is it needed ?
That was a remnant from the days some transports did not
understand objects/info/alternates; I think we do not need that
step anymore.
^ permalink raw reply
* Re: [PATCH] Add .git/version
From: Linus Torvalds @ 2005-11-17 19:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josef Weidendorfer, git, Martin Atukunda
In-Reply-To: <7v7jb7uler.fsf@assigned-by-dhcp.cox.net>
On Thu, 17 Nov 2005, Junio C Hamano wrote:
>
> - We want repository-format-version but that may be too
> long. Just saying version is a bit confusing. Abbreviating
> it to repository-version makes it sound as if somebody took a
> snapshot (i.e. tar-tree $commit). Whatever name we choose,
> let's pick a one not so confusing.
My one argument against this is that I don't see why we have to have a
separate file for this.
Why not just add a "core.version" flag to the config file? If no version
exists, assume it's version 1. And then, if we ever start using some other
version, make git-init-db always create the config file (the way we
already do for "core.filemode")
Sure, people can edit the version flag by hand, but hey, that's true even
if it's in a separate .git/version file.
Linus
^ permalink raw reply
* [PATCH 2/5] Server-side support for user-relative paths.
From: Andreas Ericsson @ 2005-11-17 19:37 UTC (permalink / raw)
To: git
This patch basically just removes the redundant code from
{receive,upload}-pack.c in favour of the library code in path.c.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
receive-pack.c | 17 ++++-------------
upload-pack.c | 15 +++------------
2 files changed, 7 insertions(+), 25 deletions(-)
applies-to: b08588da04c14104d2e158d26881062c8f21598a
03ddd42c1ad92bafbb536e9b50368a57013fdba2
diff --git a/receive-pack.c b/receive-pack.c
index 8f157bc..1873506 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -248,11 +248,11 @@ static void unpack(void)
int main(int argc, char **argv)
{
int i;
- const char *dir = NULL;
+ char *dir = NULL;
argv++;
for (i = 1; i < argc; i++) {
- const char *arg = *argv++;
+ char *arg = *argv++;
if (*arg == '-') {
/* Do flag handling here */
@@ -265,18 +265,9 @@ int main(int argc, char **argv)
if (!dir)
usage(receive_pack_usage);
- /* chdir to the directory. If that fails, try appending ".git" */
- if (chdir(dir) < 0) {
- if (chdir(mkpath("%s.git", dir)) < 0)
- die("unable to cd to %s", dir);
- }
-
- /* If we have a ".git" directory, chdir to it */
- chdir(".git");
- putenv("GIT_DIR=.");
+ if(!enter_repo(dir, 0))
+ die("'%s': unable to chdir or not a git archive", dir);
- if (access("objects", X_OK) < 0 || access("refs/heads", X_OK) < 0)
- die("%s doesn't appear to be a git directory", dir);
write_head_info();
/* EOF */
diff --git a/upload-pack.c b/upload-pack.c
index be63132..1834b6b 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -248,7 +248,7 @@ static int upload_pack(void)
int main(int argc, char **argv)
{
- const char *dir;
+ char *dir;
int i;
int strict = 0;
@@ -275,18 +275,9 @@ int main(int argc, char **argv)
usage(upload_pack_usage);
dir = argv[i];
- /* chdir to the directory. If that fails, try appending ".git" */
- if (chdir(dir) < 0) {
- if (strict || chdir(mkpath("%s.git", dir)) < 0)
- die("git-upload-pack unable to chdir to %s", dir);
- }
- if (!strict)
- chdir(".git");
-
- if (access("objects", X_OK) || access("refs", X_OK))
- die("git-upload-pack: %s doesn't seem to be a git archive", dir);
+ if (!enter_repo(dir, strict))
+ die("'%s': unable to chdir or not a git archive", dir);
- putenv("GIT_DIR=.");
upload_pack();
return 0;
}
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 3/5] Client side support for user-relative paths.
From: Andreas Ericsson @ 2005-11-17 19:37 UTC (permalink / raw)
To: git
With this patch, the client side passes identical paths for these two:
ssh://host.xz/~junio/repo
host.xz:~junio/repo
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
connect.c | 53 ++++++++++++++++++++++++++++++++---------------------
1 files changed, 32 insertions(+), 21 deletions(-)
applies-to: cd3bc724fea293b623abee6b0b4995560dd9f32e
c460d84cc8431089ddf6a888a418826ff8248509
diff --git a/connect.c b/connect.c
index c2badc7..73187a1 100644
--- a/connect.c
+++ b/connect.c
@@ -454,34 +454,45 @@ static int git_tcp_connect(int fd[2], co
int git_connect(int fd[2], char *url, const char *prog)
{
char command[1024];
- char *host, *path;
- char *colon;
+ char *host, *path = url;
+ char *colon = NULL;
int pipefd[2][2];
pid_t pid;
- enum protocol protocol;
+ enum protocol protocol = PROTO_LOCAL;
- host = NULL;
- path = url;
- colon = strchr(url, ':');
- protocol = PROTO_LOCAL;
- if (colon) {
- *colon = 0;
+ host = strstr(url, "://");
+ if(host) {
+ *host = '\0';
+ protocol = get_protocol(url);
+ host += 3;
+ path = strchr(host, '/');
+ }
+ else {
host = url;
- path = colon+1;
- protocol = PROTO_SSH;
- if (!memcmp(path, "//", 2)) {
- char *slash = strchr(path + 2, '/');
- if (slash) {
- int nr = slash - path - 2;
- memmove(path, path+2, nr);
- path[nr] = 0;
- protocol = get_protocol(url);
- host = path;
- path = slash;
- }
+ if ((colon = strchr(host, ':'))) {
+ protocol = PROTO_SSH;
+ *colon = '\0';
+ path = colon + 1;
}
}
+ if (!path || !*path)
+ die("No path specified. See 'man git-pull' for valid url syntax");
+
+ /*
+ * null-terminate hostname and point path to ~ for URL's like this:
+ * ssh://host.xz/~user/repo
+ */
+ if (protocol != PROTO_LOCAL && host != url) {
+ char *ptr = path;
+ if (path[1] == '~')
+ path++;
+ else
+ path = strdup(ptr);
+
+ *ptr = '\0';
+ }
+
if (protocol == PROTO_GIT)
return git_tcp_connect(fd, prog, host, path);
---
0.99.9.GIT
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox