* [PATCH 1/6] Add GIT_REPO_VERSION, and repository_format_version
From: Martin Atukunda @ 2005-11-22 0:28 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
In-Reply-To: <11326192921291-git-send-email-matlads@dsmagic.com>
This variable will enable git to track the repository version. It's
currently set to 0. (in true C style :)
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
---
cache.h | 4 ++++
environment.c | 1 +
2 files changed, 5 insertions(+), 0 deletions(-)
applies-to: 339319e60db7b3f96f8c711407b135a54da7aa2e
976b8d57a80d79853df9c142ba30d39b414e1b8e
diff --git a/cache.h b/cache.h
index c7c6637..54c283d 100644
--- a/cache.h
+++ b/cache.h
@@ -182,6 +182,10 @@ extern int trust_executable_bit;
extern int only_use_symrefs;
extern int diff_rename_limit_default;
+#define GIT_REPO_VERSION 0
+extern int repository_format_version;
+extern int check_repo_format(void);
+
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
#define OWNER_CHANGED 0x0004
diff --git a/environment.c b/environment.c
index b5026f1..3f19473 100644
--- a/environment.c
+++ b/environment.c
@@ -13,6 +13,7 @@ char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
int trust_executable_bit = 1;
int only_use_symrefs = 0;
+int repository_format_version = 0;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 2/6] Make init-db check repo format version if copying a config file.
From: Martin Atukunda @ 2005-11-22 0:28 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
In-Reply-To: <11326192921291-git-send-email-matlads@dsmagic.com>
This patch enables init-db to check the repo format version for a
repository being re-initialised. If the version of the repo is larger than
GIT_VERSION_REPO, it simply dies with an appropriate message.
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
---
init-db.c | 14 ++++++++++++++
setup.c | 19 +++++++++++++++++++
2 files changed, 33 insertions(+), 0 deletions(-)
applies-to: 3e86d91031df530695933e7d9d5d8d9c2f3a683d
601dd50b595a9aa0a57972364262d98290a5d7b2
diff --git a/init-db.c b/init-db.c
index bd88291..90be428 100644
--- a/init-db.c
+++ b/init-db.c
@@ -110,6 +110,19 @@ static void copy_templates_1(char *path,
}
}
+static int init_db_config_check(const char *template_path)
+{
+ DIR *dir;
+ struct dirent *de;
+
+ dir = opendir(template_path);
+ while((de = readdir(dir)) != NULL) {
+ if ((strncmp(de->d_name, "config", 5) == 0))
+ return check_repo_format();
+ }
+ return 0;
+}
+
static void copy_templates(const char *git_dir, int len, char *template_dir)
{
char path[PATH_MAX];
@@ -131,6 +144,7 @@ static void copy_templates(const char *g
template_dir);
return;
}
+ init_db_config_check(template_path);
memcpy(path, git_dir, len);
path[len] = 0;
diff --git a/setup.c b/setup.c
index c487d7e..8597424 100644
--- a/setup.c
+++ b/setup.c
@@ -127,3 +127,22 @@ const char *setup_git_directory(void)
cwd[len] = 0;
return cwd + offset;
}
+
+static int check_repo_config(const char *var, const char *value)
+{
+ if (strcmp(var, "core.repositoryformatversion") == 0) {
+ repository_format_version = git_config_int(var, value);
+ return 0;
+ }
+ return 1;
+}
+
+int check_repo_format(void)
+{
+ if (git_config(check_repo_config) == -1)
+ return -1;
+ if (repository_format_version > GIT_REPO_VERSION)
+ die ("Expected git repo version <= %d, found %d", GIT_REPO_VERSION,
+ repository_format_version);
+ return 0;
+}
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 4/6] Add check_repo_format check for all major operations.
From: Martin Atukunda @ 2005-11-22 0:28 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
In-Reply-To: <11326192921291-git-send-email-matlads@dsmagic.com>
The git-* command set uses 3 entry points in order to prepare
to work with a git repo: enter_repo, get_git_dir, and obviously
setup_git_directory.
This patch adds a check for the repo format version to each of these
entry points. This will automatically enable repo format version
checking for all the git-* programs.
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
---
environment.c | 3 +++
path.c | 1 +
setup.c | 3 +++
3 files changed, 7 insertions(+), 0 deletions(-)
applies-to: 8084b72bfb91efc08a9fa83e0893f21c5f60ad92
5d902692ef7eef2763cadfa646eb9245422579af
diff --git a/environment.c b/environment.c
index 6a961ca..458eff8 100644
--- a/environment.c
+++ b/environment.c
@@ -37,6 +37,9 @@ static void setup_git_env(void)
git_graft_file = getenv(GRAFT_ENVIRONMENT);
if (!git_graft_file)
git_graft_file = strdup(git_path("info/grafts"));
+
+ /* check the repo */
+ check_repo_format();
}
char *get_git_dir(int recheck_env)
diff --git a/path.c b/path.c
index e322dc0..84cb1c5 100644
--- a/path.c
+++ b/path.c
@@ -199,6 +199,7 @@ char *enter_repo(char *path, int strict)
if(access("objects", X_OK) == 0 && access("refs", X_OK) == 0 &&
validate_symref("HEAD") == 0) {
putenv("GIT_DIR=.");
+ get_git_dir(1); /* re-read the env variables */
return current_dir();
}
diff --git a/setup.c b/setup.c
index 8597424..934f9a3 100644
--- a/setup.c
+++ b/setup.c
@@ -97,6 +97,9 @@ const char *setup_git_directory(void)
static char cwd[PATH_MAX+1];
int len, offset;
+ get_git_dir(1);
+ check_repo_format();
+
/*
* If GIT_DIR is set explicitly, we're not going
* to do any discovery
---
0.99.9.GIT
^ permalink raw reply related
* Re: [RFC 1/2] Use remote information in .git/config
From: Junio C Hamano @ 2005-11-22 0:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511212109440.4213@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I am unsure if putting everything in .git/config file is the
>> right approach, though. What will we put there next? ls-files
>> ignore patterns? grafts? alternates? We should be able to
>> even get rid of .git/refs directory hierarchy and replace that
>> with something like this:
>> ...
>> Where will we stop, and why?
>
> Ahh! I have a clear picture of what *I* would put into it: all interesting
> static data about that particular repository which I would not like to
> version.
There are certain things that _might_ benefit from the third
kind we currently do not support: developer opt-in.
Currently, .gitignore and friends (what you call versioned) are
project-wide. Anybody who follows git.git uses _the_ .gitignore
that is from the respository, although they can override with
their own .git/info/exclude, which might be a good candidate for
"core.gitignore = ...". But certain people might want to share
their forked .gitignore without going through hassles to
integrate that to project-wide copy. ".gitignore" might be a
bad example, and grafts may be better. People interested in
Linux archaeology might want to share grafts to let them go back
from tip of 2.6 all the way down to 2.4.0 (or before) while
majority of users do not share that interest.
Obviously, user.name is private to you, but you would still want
to use the same across your repositories.
Once we start thinking about allowing the template mechansim to
give default "config" information to newly created repositories,
having everything in one file may make things a bit awkward to
handle. When you managed to make your colleage interested in
git development, you can let her copy your remotes/junio. Once
you moved remotes/ to .git/config file, while you would not want
her to use copy of your .git/config verbatim without updating at
least user.name, you would want to have her use other pieces in
the .git/config, including [remote.jnio] bits.
The following comments are not about your patch but I am having
a feeling that we ended up having too much flexibility. It may
not necessarily be a bad thing when we view git as pure
plumbing, but it makes things confusing to have too many "you
could do it this way if you want to gain XXX, as long as you are
careful about YYY".
For example, we do not define how checked-out tree, repository
and object database _should_ work together. The officially
recommended way is to have one object database at .git/objects/,
possibly borrowing from somebody via objects/info/alternates,
which hangs under one repository (.git), and the repository can
have one checked-out tree associated with it.
However, it is possible to symlink .git/objects to somewhere
else, to share an object database between two repositories, as
long as you are careful when pruning (you can lose objects the
refs in other repository points at but you do not).
Even worse (or better), you could symlink everything except the
HEAD and index file to somewhere else to have one repository
with multiple checked-out trees (I believe Daniel does this), as
long as you are careful when pulling/fetching (fetching into a
branch that another working tree has checked out will move the
head commit there without updating the index).
Another example is the assumption we place on completeness of
the refs. We pretty much declares that if there are some
objects you cannot reach starting from your refs, your
repository is corrupt (incomplete). But such an incomplete
repository can be useful in certain situations, and some things
work properly but not others. I think using commit-walkers
without -a option can easily create such an incomplete
repository.
The recent "should commit be always utf-8" thread probably falls
into this category. We all know things should be in utf-8, but
other things are possible as long as people understand
boundaries.
Most of the time, what we recommend are the BCP, but
knowledgeable users can deviate from that, to gain some
advantage (e.g. reduced disk space using an incomplete
repository, convenience of having more than one checked-out
trees at the same time, not having to migrate to all UTF-8
system) over the BCP if they are willing to sacrifice something
else or their use pattern is not affected negatively by what
they are losing (e.g. can live without an access to ancient
history, be very careful when pruning and fetching, do not have
people whose names cannot be spelled in KOI-8).
^ permalink raw reply
* [PATCH] Re: [PATCH] Fix git.c compilation target
From: Andreas Ericsson @ 2005-11-21 23:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vlkzhmwq4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> - make git$(X) part of PROGRAMS (probably it is a
> SIMPLE_PROGRAM that does not link with many extra stuff, or a
> class on its own);
>
> - have "install" target depend on "all".
>
Something like this?
##########
Introduce $(ALL_PROGRAMS) for 'all:' and 'install:' to operate on.
Remove $(SIMPLE_PROGRAMS) from $(PROGRAMS) so buildrules don't have
to be overridden.
Put $(SCRIPTS) with the other target-macros so it doesn't get lonely.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
Makefile | 22 ++++++++++++----------
1 files changed, 12 insertions(+), 10 deletions(-)
applies-to: 339319e60db7b3f96f8c711407b135a54da7aa2e
bf68baa57babbff57761a802fde801e71e85807e
diff --git a/Makefile b/Makefile
index d6dad19..0e2f65d 100644
--- a/Makefile
+++ b/Makefile
@@ -102,6 +102,11 @@ SCRIPT_PERL = \
SCRIPT_PYTHON = \
git-merge-recursive.py
+SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
+ $(patsubst %.perl,%,$(SCRIPT_PERL)) \
+ $(patsubst %.py,%,$(SCRIPT_PYTHON)) \
+ gitk git-cherry-pick
+
# The ones that do not have to link with lcrypto nor lz.
SIMPLE_PROGRAMS = \
git-get-tar-commit-id$X git-mailinfo$X git-mailsplit$X \
@@ -125,8 +130,10 @@ 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-config-set$X git-var$X \
- $(SIMPLE_PROGRAMS)
+ git-name-rev$X git-pack-redundant$X git-config-set$X git-var$X
+
+# what 'all' will build and 'install' will install.
+ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS) git$X
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
@@ -339,15 +346,10 @@ endif
ALL_CFLAGS += -DSHA1_HEADER=$(call shellquote,$(SHA1_HEADER))
-SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
- $(patsubst %.perl,%,$(SCRIPT_PERL)) \
- $(patsubst %.py,%,$(SCRIPT_PYTHON)) \
- gitk git-cherry-pick
-
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
-all: $(PROGRAMS) $(SCRIPTS) git
+all: $(ALL_PROGRAMS)
all:
$(MAKE) -C templates
@@ -441,9 +443,9 @@ check:
### Installation rules
-install: $(PROGRAMS) $(SCRIPTS) git
+install: all
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
- $(INSTALL) git $(PROGRAMS) $(SCRIPTS) $(call
shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) $(ALL_PROGRAMS) $(call shellquote,$(DESTDIR)$(bindir))
$(MAKE) -C templates install
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
$(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
---
0.99.9.GIT
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply related
* Re: [PATCH 5/5] git-daemon support for user-relative paths.
From: Junio C Hamano @ 2005-11-21 23:29 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4381AB38.7090209@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Apart from comments and indentation it's more or less exactly what I
> have in my revised git-daemon patch (although without what you mentioned
> in your own reply to this mail).
>
> Do you want the revised one from me or will you apply the original with
> this on top?
Well, let's push out what we have so far to "master" and then
finish up whatever breakage if any in tree.
^ permalink raw reply
* Re: [PATCH] Fix git.c compilation target
From: Junio C Hamano @ 2005-11-21 23:01 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0511210124u5cc0d4efv2045123d92872c66@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> There was more to it.
> The patch removes a reference to git.sh from Makefile and installs
> _all_ programs and scripts.
>
Thanks; the filter-out should go, but I am wondering if it makes
more sense to:
- make git$(X) part of PROGRAMS (probably it is a
SIMPLE_PROGRAM that does not link with many extra stuff, or a
class on its own);
- have "install" target depend on "all".
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Yann Dirson @ 2005-11-21 22:30 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Johannes Schindelin, git
In-Reply-To: <20051121022428.GB7902@kiste.smurf.noris.de>
On Mon, Nov 21, 2005 at 03:24:28AM +0100, Matthias Urlichs wrote:
> If you need a new HEAD *anyway*, then re-basing your trees would
> IMHO be a better solution.
Hell, that does look like a nice solution using current git - thanks.
I'll have to dig into that, and I'll come back if/when I hit its
limits too hard ;)
> I seriously doubt that all of this is worth the effort, given that you
> can do the same thing with a graft line...
Well, unfortunately there is still some things to get ironed out
before we have grafts propagated without yet another wrapper - which
ends up with them being still really private at that time.
But then, grafts may povide an inexpensive scratch space, which could
then be carved into rebased objects when the historian gets happy with
his work.
> and most people could care
> less whether their histor starts at 2.6.11-whatever, 2.4, or 0.11.
Right ! But then someone will occasionally want to use a release
before the start of his history, and it would be a shame to force full
kernel history on all poor developers who only need fresh-enough code.
But I still think we could reconcile those 2 approaches, if we would
allow partial history lines (ie, signing eg. commit chain from 2.6.n
to 2.6.(n+1), with the initial commit starting on a tree and not a
faked "commit from nil").
This would indeed a generalisation of what we have, since we only have
a signed chain of commits from 2.6.12rc2 in the official repo - and
maybe one more ancient from bk history. It would even formally
acknowledge that we do not have the whole of the real history, and it
would leave the Unknown to be well-delimited, for any explorers who
would want to rebuild it, in case it would have any value, IP-wise.
And, more practically, where will the current kernel repo be when its
size will be 100 or 10000 times its current size ? That would allow
to split it without too many problems.
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: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Junio C Hamano @ 2005-11-21 22:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511211653420.2569@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 21 Nov 2005, Josef Weidendorfer wrote:
>
>> On Monday 21 November 2005 14:56, Johannes Schindelin wrote:
>> > With this patch, git automatically extracts the information from
>> > .git/branches and .git/remotes, puts it into .git/config, and renames the
>> > directories to .git/branches.old and .git/remotes.old, respectively.
>>
>> Please... don't trash .git/branches.
>> This is about Cogito, not about Git. You will render every repository cloned
>> with Cogito useless, as it expects a per-branch configuration with the same
>> name as heads.
>>
> I was aware that .git/branches was introduced by Pasky, but as it is
> handled in git-parse-remote.sh, I thought that it may be a bit more
> general than just cogito.
What Josef said is correct in that I was not aware of the fact
that Cogito branches/ are *per-branch* configuration when I did
parse-remote. remotes/ are deliberately *per-remote*
configuration, because it is more efficient when you are
downloading more than one refs from the same remote over a
git-aware protocol. Arguably, it is optimizing for the wrong
case, because it may well be a minority case to keep track of
more than one remote head. I dunno.
I am not sure if it is a good idea to automatically convert what
is stored in .git/branches to .git/remotes (or the equivalent of
the latter in .git/config), but if somebody wanted to do it, the
right thing would be:
- grab the URL without optional fragment '#rembranch' part from
all branches/* file;
- group the ones that fetch from the same URL into one
remotes/$file (what to call that file is very debatable
because the original branches/* is in different namespace and
we cannot tell what the user wants to call the remote),
giving appropriate head mapping. branches/$branch file with
the fragment part '#$rembranch' translates to "Pull:
$rembranch:$branch".
^ permalink raw reply
* Re: Pure renames/copies
From: H. Peter Anvin @ 2005-11-21 22:17 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git
In-Reply-To: <438245CF.9030501@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 257 bytes --]
Better variant, which handles stuff like "4.5%" and rejects
"192.168.0.1". Additionally, make sure numbers are unsigned (I'm making
them unsigned long just for the hell of it), to make sure that
artificial wraparound scenarios don't cause harm.
-hpa
[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 1186 bytes --]
diff --git a/diff.c b/diff.c
index 0391e8c..ffe8a55 100644
--- a/diff.c
+++ b/diff.c
@@ -838,16 +838,29 @@ int diff_opt_parse(struct diff_options *
static int parse_num(const char **cp_p)
{
- int num, scale, ch, cnt;
+ unsigned long num, scale;
+ int ch, dot;
const char *cp = *cp_p;
- cnt = num = 0;
+ num = 0;
scale = 1;
- while ('0' <= (ch = *cp) && ch <= '9') {
- if (cnt++ < 5) {
- /* We simply ignore more than 5 digits precision. */
- scale *= 10;
- num = num * 10 + ch - '0';
+ dot = 0;
+ for(;;) {
+ ch = *cp;
+ if ( !dot && ch == '.' ) {
+ scale = 1;
+ dot = 1;
+ } else if ( ch == '%' ) {
+ scale = dot ? scale*100 : 100;
+ cp++; /* % is always at the end */
+ break;
+ } else if ( ch >= '0' && ch <= '9' ) {
+ if ( scale < 100000 ) {
+ scale *= 10;
+ num = (num*10) + (ch-'0');
+ }
+ } else {
+ break;
}
cp++;
}
@@ -856,7 +869,7 @@ static int parse_num(const char **cp_p)
/* user says num divided by scale and we say internally that
* is MAX_SCORE * num / scale.
*/
- return (MAX_SCORE * num / scale);
+ return (num >= scale) ? MAX_SCORE : (MAX_SCORE * num / scale);
}
int diff_scoreopt_parse(const char *opt)
^ permalink raw reply related
* Re: diff-tree and does not respect grafts
From: Junio C Hamano @ 2005-11-21 22:12 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <87lkzi1aio.fsf@gmail.com>
Santi Béjar <sbejar@gmail.com> writes:
> diff-tree decode directly the commit, so it does not take into
> account the graft file. Is this the expected behaviour?
Expected? Yes, only because I happen to know diff-tree was
written way before grafts are invented and nobody bothered to
change that behaviour. Desireable? Probably not.
^ permalink raw reply
* Re: Pure renames/copies
From: H. Peter Anvin @ 2005-11-21 22:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5ktoe52.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 641 bytes --]
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>Okay, in that post Linus suggests that -M without an argument should be
>>== 100% (1.0), thus avoiding having to mess up the meaning of -M100 as
>>0.100. It seems like a really odd thing to have -M100 mean something
>>that's completely out of line with the rest of the meaning.
>
> True, but it might be too late to change that; I suspect people
> expect -M to do a bit more than pure renames by now.
>
Okay, how about the following? It lets both -M1.0 and -M100% work,
while keeping everything else compatible, and avoiding artificial
special cases.
-hpa
[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 932 bytes --]
diff --git a/diff.c b/diff.c
index 0391e8c..df62d2b 100644
--- a/diff.c
+++ b/diff.c
@@ -843,11 +843,19 @@ static int parse_num(const char **cp_p)
cnt = num = 0;
scale = 1;
- while ('0' <= (ch = *cp) && ch <= '9') {
- if (cnt++ < 5) {
- /* We simply ignore more than 5 digits precision. */
- scale *= 10;
- num = num * 10 + ch - '0';
+ for(;;) {
+ ch = *cp;
+ if ( ch == '.' ) {
+ scale = 1;
+ } else if ( ch == '%' ) {
+ scale = 100;
+ } else if ( ch >= '0' && ch <= '9' ) {
+ if ( scale < 100000 ) {
+ scale *= 10;
+ num = (num*10) + (ch-'0');
+ }
+ } else {
+ break;
}
cp++;
}
@@ -856,7 +864,7 @@ static int parse_num(const char **cp_p)
/* user says num divided by scale and we say internally that
* is MAX_SCORE * num / scale.
*/
- return (MAX_SCORE * num / scale);
+ return (num >= scale) ? MAX_SCORE : (MAX_SCORE * num / scale);
}
int diff_scoreopt_parse(const char *opt)
^ permalink raw reply related
* Re: Pure renames/copies
From: Junio C Hamano @ 2005-11-21 22:00 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43823E31.2050500@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Okay, in that post Linus suggests that -M without an argument should be
> == 100% (1.0), thus avoiding having to mess up the meaning of -M100 as
> 0.100. It seems like a really odd thing to have -M100 mean something
> that's completely out of line with the rest of the meaning.
True, but it might be too late to change that; I suspect people
expect -M to do a bit more than pure renames by now.
^ permalink raw reply
* RSS feed conatins non UTF-8 chars
From: Norbert Kiesel @ 2005-11-18 2:52 UTC (permalink / raw)
To: webmaster
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
Hi,
my RSS feed reader complains that the feed is not UTF-8 although it
claims to be.
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.kernel.org%2Fgit
%2Fgitweb.cgi%3Fp%3Dlinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git%3Ba%
3Drss
Best,
Norbert
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Diffs "from" working directory
From: Catalin Marinas @ 2005-11-21 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhda5of1r.fsf@assigned-by-dhcp.cox.net>
On 21/11/05, Junio C Hamano <junkio@cox.net> wrote:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>
> > My import command sets the author to the e-mail sender, which was you.
> > Maybe this should be changed but I don't know which option is better.
> > In the meantime, you can change the default e-mail template to set the
> > From: line with to the author of the patch and maybe add a Reply-to:
> > with your address.
>
> ... and Sender: perhaps?
Yes.
> The first lines in the commit log message sent over e-mail can
> have "Subject: " (or "[PATCH] "), "From: ", and "Date: " to
> override what is slurped from e-mail headers if you use mailinfo,
> so that might be a better alternative to suggest.
Thanks for the suggestion. It is indeed a good idea to parse the
commit log and override the information from the headers.
--
Catalin
^ permalink raw reply
* Re: [RFC] Make grafts versionable
From: H. Peter Anvin @ 2005-11-21 21:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0511211326110.13959@g5.osdl.org>
Linus Torvalds wrote:
>
> However, there's one fundamental reason:
>
> - if you have a file in ".git", that implies that even a "raw git repo"
> would have versions matter, since technically such a file would be
> inside the "raw" part. And that I find to be confusing. One of the
> whole points of a raw git repo is that because it doesn't have anything
> that is version-controlled and checked out, none of the branches or
> tags are special, and nothing needs to be updated when you push to such
> a repo.
>
> Now, if you have files in .git, suddenly that fundamental nature of a
> raw repository is no longer clear.
>
Note that I didn't actually mean that they should necessarily represent
files in .git/. The point was more that if we wanted to have
version-controlled metadata, using .git/ as a namespace would be suitable.
In particular, I believe that if we ever do that, git should obtain this
metadata from the repository/object database.
> In general, making any internal git data versionable is very confusing. So
> you make the grafts file versionable - that suddenly means that different
> branches may have different parents for the same commit. And that
> depending on which branch you have checked out, git-fsck-cache may result
> in an error, or it may not. That's _nasty_, in my opinion.
>
> So I much prefer to say: everything under ".git" is not versionable, for
> the fundamental reason that the files under .git are "global" to that git
> repository.
>
> And I think .git/grafts in particular makes no sense to version.
>
> If you want to track a git "grafts" file, you can do it as another git
> repository and a symlink.
I fully concur with this (as I pointed out in my post, although perhaps
fuzzily.)
-hpa
^ permalink raw reply
* Re: Diffs "from" working directory
From: Junio C Hamano @ 2005-11-21 21:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0511211328j7c062c07s@mail.gmail.com>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> My import command sets the author to the e-mail sender, which was you.
> Maybe this should be changed but I don't know which option is better.
> In the meantime, you can change the default e-mail template to set the
> From: line with to the author of the patch and maybe add a Reply-to:
> with your address.
... and Sender: perhaps?
The first lines in the commit log message sent over e-mail can
have "Subject: " (or "[PATCH] "), "From: ", and "Date: " to
override what is slurped from e-mail headers if you use mailinfo,
so that might be a better alternative to suggest.
^ permalink raw reply
* Re: Pure renames/copies
From: H. Peter Anvin @ 2005-11-21 21:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsotofd0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>Any reason we can't make it take an actual decimal number, like -M1.0 or
>>-M0.345? It seems odd and annoying to invent our own notation for
>>floating-point numbers, especially in userspace.
>
>
> No reason we "can't". About we "don't", inertia and nothing
> else. It happened around this time.
>
> http://marc.theaimsgroup.com/?l=git&m=111654149421574
>
> We could in addition to take 0 <= x <= 1 decimal number and that
> should be a simple patch to diff.c::parse_num().
>
Okay, in that post Linus suggests that -M without an argument should be
== 100% (1.0), thus avoiding having to mess up the meaning of -M100 as
0.100. It seems like a really odd thing to have -M100 mean something
that's completely out of line with the rest of the meaning.
-hpa
^ permalink raw reply
* Re: [RFC] Make grafts versionable
From: Linus Torvalds @ 2005-11-21 21:35 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Johannes Schindelin, git
In-Reply-To: <43823654.2060904@zytor.com>
On Mon, 21 Nov 2005, H. Peter Anvin wrote:
>
> Now, CVS has a reserved namespace (CVSROOT/) for things under version control
> which are still significant to CVS. The logical equivalent to git would be to
> have .git/ be such a namespace, if it makes sense.
Well, there's two reasons for disallowing git from tracking it's own .git
directory:
- it protects against people doing somethin glike
git-update-cache --add -- $(find . -type f | cut -c3..)
and finding the pre-existing files in ".git"
This used to literally be how I imported trees into git. These days,
you can just do it with "git-ls-files --others", and in fact that is
exactly what "git add" does, so now you can just do
git add .
and be done with it - without getting that ".git" directory by mistake.
So that _old_ reason may not be as valid any more.
However, there's one fundamental reason:
- if you have a file in ".git", that implies that even a "raw git repo"
would have versions matter, since technically such a file would be
inside the "raw" part. And that I find to be confusing. One of the
whole points of a raw git repo is that because it doesn't have anything
that is version-controlled and checked out, none of the branches or
tags are special, and nothing needs to be updated when you push to such
a repo.
Now, if you have files in .git, suddenly that fundamental nature of a
raw repository is no longer clear.
In general, making any internal git data versionable is very confusing. So
you make the grafts file versionable - that suddenly means that different
branches may have different parents for the same commit. And that
depending on which branch you have checked out, git-fsck-cache may result
in an error, or it may not. That's _nasty_, in my opinion.
So I much prefer to say: everything under ".git" is not versionable, for
the fundamental reason that the files under .git are "global" to that git
repository.
And I think .git/grafts in particular makes no sense to version.
If you want to track a git "grafts" file, you can do it as another git
repository and a symlink.
Linus
^ permalink raw reply
* Re: auto-packing on kernel.org? please?
From: Junio C Hamano @ 2005-11-21 21:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511211211130.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> ...just pipe stderr too. That, together with making git-pack-objects tell
> what garbage it got, actually does the rigth thing:
>
> [torvalds@g5 git-clone]$ git repack -a -d
> fatal: expected sha1, got garbage:
> error: Could not read 7f59dbbb8f8d479c1d31453eac06ec765436a780
>
> with this pretty simple patch.
>
> Whaddaya think?
Obviously the right thing to do ;-). I like it.
^ permalink raw reply
* Re: Pure renames/copies
From: Junio C Hamano @ 2005-11-21 21:33 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <438235AA.8070805@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Any reason we can't make it take an actual decimal number, like -M1.0 or
> -M0.345? It seems odd and annoying to invent our own notation for
> floating-point numbers, especially in userspace.
No reason we "can't". About we "don't", inertia and nothing
else. It happened around this time.
http://marc.theaimsgroup.com/?l=git&m=111654149421574
We could in addition to take 0 <= x <= 1 decimal number and that
should be a simple patch to diff.c::parse_num().
^ permalink raw reply
* Re: [PATCH] Stgit - gitmergeonefile.py: handle removal vs. changes
From: Catalin Marinas @ 2005-11-21 21:32 UTC (permalink / raw)
To: cel; +Cc: Blaisorblade, git
In-Reply-To: <437D0949.3060505@citi.umich.edu>
On 17/11/05, Chuck Lever <cel@citi.umich.edu> wrote:
> 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.
These names would need to have a meaning for the result of the 'fold
--threeway' and 'pick' commands. 'patch' and 'original' are ok but
'upstream' might not make sense since for these commands it can
represent the top of an existing patch.
--
Catalin
^ permalink raw reply
* Re: Diffs "from" working directory
From: Catalin Marinas @ 2005-11-21 21:28 UTC (permalink / raw)
To: cel; +Cc: J. Bruce Fields, Linus Torvalds, Blaisorblade, Chuck Lever, git
In-Reply-To: <4381287F.5080402@citi.umich.edu>
On 21/11/05, Chuck Lever <cel@citi.umich.edu> wrote:
> J. Bruce Fields wrote:
> > A "-R" option to "stg diff" would be convenient, sure.--b.
>
> that might be an even more intuitive way to dig out what is wanted.
I also like the idea of having a -R option (--reverse the long
version). This would mean reversing the commit that changed the diff
-r option.
> btw, catalin, this was bruce's patch. i'm not sure why i was listed as
> the author (probably a mistake of mine when i imported his patch into my
> repository). ah well.
My import command sets the author to the e-mail sender, which was you.
Maybe this should be changed but I don't know which option is better.
In the meantime, you can change the default e-mail template to set the
From: line with to the author of the patch and maybe add a Reply-to:
with your address.
--
Catalin
^ permalink raw reply
* 2.6.15-rc2 tag
From: J. Bruce Fields @ 2005-11-21 21:25 UTC (permalink / raw)
To: git
Help! I'm confused.
git-fetch --tags http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
isn't getting me a 2.6.15-rc2 tag. So maybe there's some delay? There
does, however, appear to be a file
http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/tags/v2.6.15-rc2
Its contents are 7305b5cb045e2c71250b5b7472771ed2620bc514 which isn't
anything I can find anywhere.
gitweb, on the other hand:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tag;h=7305b5cb045e2c71250b5b7472771ed2620bc514
shows 3bedff1d73b86e0cf52634efb447e9ada08f2cc6 as the tagged commit,
which is something I do have. What don't I understand?
--b.
^ permalink raw reply
* Re: [RFC] Make grafts versionable
From: H. Peter Anvin @ 2005-11-21 21:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511212152110.4611@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> ... by moving the location from .git/info/grafts to .gitgrafts. This
> allows checking it in like .gitignore, and sure enough also pulling it (as
> well as knowing who the heck added that particular graft anyway).
This is problematic, because it means something that isn't in GIT_DIR
affects its interpretation. I would say that that is a showstopper.
One could even argue that it's incorrect, since it would mean different
points on the history have different grafts.
Now, CVS has a reserved namespace (CVSROOT/) for things under version
control which are still significant to CVS. The logical equivalent to
git would be to have .git/ be such a namespace, if it makes sense.
-hpa
^ 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