* Re: strange cg-add problem
From: Junio C Hamano @ 2005-11-22 16:55 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: git
In-Reply-To: <20051122123058.GB19989@schottelius.org>
Nico -telmich- Schottelius <nico-linux-git@schottelius.org> writes:
> srwali01:/home/server/backup/db# ~/db-dump.sh
> /home/server/backup/db//2005-11-22/13:26 does not exist or is not a regular file
> cg-add: warning: not all files could be added
> cg-commit: Nothing to commit
I do not use cogito, but I suspect it would work if you change
your script to avoid double slash between db and 2005-11-22.
^ permalink raw reply
* Question about handling of heterogeneous repositories
From: Alex Riesen @ 2005-11-22 16:50 UTC (permalink / raw)
To: git
Hi,
it is sometimes the case that a project consists of parts which are
unrelated to each other, and only thing in common between them is that
they all are used in that particular project. For example a program
uses some library and the developer(s) of that program would like to
have the source of that library somewhere close. Well, for this simple
example one could just use two repositories, laid close to each other
in a directory, like project/lib and project/prog.
Now, if I make the example a bit more complex and say, that the
developers of the program are the developers in that project and
change everything under project/ directory, including
project/library/. They are also good people and ready to give the
changes to the library upstream.
How do they achieve that, without sending project/ and project/program/?
For everyone who have an experience with ClearCase or Perforce (I'm
sorry for mentioning it) it is what the "mappings" are often used for:
a project is build together from different parts, which can be worked
on separately.
I'm trying to introduce git at work, but have to prepare myself for
possible questions first, and this is one of them :)
Greetings,
Alex Riesen
^ permalink raw reply
* [PATCH] arguments cleanup and some formatting
From: Alex Riesen @ 2005-11-22 14:59 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 2 bytes --]
[-- Attachment #2: 0003-arguments-cleanup-and-some-formatting.txt --]
[-- Type: text/plain, Size: 1592 bytes --]
Subject: [PATCH] arguments cleanup and some formatting
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
pack-redundant.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
applies-to: 50ace31f398f055b2d9b25dbc86c85ddf15beadc
571f5a3ff794ff1afba5b9b708116c307b0f6aa7
diff --git a/pack-redundant.c b/pack-redundant.c
index 8b37da9..82bc8ad 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -149,8 +149,9 @@ static inline struct llist_item * llist_
}
/* returns a pointer to an item in front of sha1 */
-static inline struct llist_item * llist_sorted_remove(struct llist *list, char *sha1,
- struct llist_item *hint)
+static inline struct llist_item * llist_sorted_remove(struct llist *list,
+ const char *sha1,
+ struct llist_item *hint)
{
struct llist_item *prev, *l;
@@ -218,10 +219,11 @@ static inline size_t pack_list_size(stru
return ret;
}
-static struct pack_list * pack_list_difference(struct pack_list *A,
- struct pack_list *B)
+static struct pack_list * pack_list_difference(const struct pack_list *A,
+ const struct pack_list *B)
{
- struct pack_list *ret, *pl;
+ struct pack_list *ret;
+ const struct pack_list *pl;
if (A == NULL)
return NULL;
@@ -350,8 +352,7 @@ static int is_superset(struct pack_list
diff = llist_copy(list);
while (pl) {
- llist_sorted_difference_inplace(diff,
- pl->all_objects);
+ llist_sorted_difference_inplace(diff, pl->all_objects);
if (diff->size == 0) { /* we're done */
llist_free(diff);
return 1;
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] remove unused variable
From: Alex Riesen @ 2005-11-22 14:58 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 36 bytes --]
It is just assigned, nothing more.
[-- Attachment #2: 0002-remove-unused-variable.txt --]
[-- Type: text/plain, Size: 672 bytes --]
Subject: [PATCH] remove unused variable
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
pack-redundant.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
applies-to: da2488b3948b36edb6f468ad16e247d500679f01
0aeca0da8c4184a8ace0f70ff611527c7f2df75a
diff --git a/pack-redundant.c b/pack-redundant.c
index 3681170..8b37da9 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -493,12 +493,10 @@ static void load_all_objects(void)
{
struct pack_list *pl = local_packs;
struct llist_item *hint, *l;
- int i;
llist_init(&all_objects);
while (pl) {
- i = 0;
hint = NULL;
l = pl->all_objects->front;
while (l) {
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] speedup allocation in pack-redundant.c
From: Alex Riesen @ 2005-11-22 14:56 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 33 bytes --]
Reuse discarded nodes of llists
[-- Attachment #2: 0001-speedup-allocation-in-pack-redundant.c.txt --]
[-- Type: text/plain, Size: 2117 bytes --]
Subject: [PATCH] speedup allocation in pack-redundant.c
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
pack-redundant.c | 32 ++++++++++++++++++++++++++------
1 files changed, 26 insertions(+), 6 deletions(-)
applies-to: 0a8441bc998f995dd35380472314802f53c6e1f3
738ce6cef594ae09b89372859d28f37b1bef9aa1
diff --git a/pack-redundant.c b/pack-redundant.c
index 1519385..3681170 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -36,11 +36,31 @@ struct pll {
size_t pl_size;
};
-static inline void llist_free(struct llist *list)
+static struct llist_item *free_nodes = NULL;
+
+static inline struct llist_item *llist_item_get()
+{
+ struct llist_item *new;
+ if ( free_nodes ) {
+ new = free_nodes;
+ free_nodes = free_nodes->next;
+ } else
+ new = xmalloc(sizeof(struct llist_item));
+
+ return new;
+}
+
+static inline void llist_item_put(struct llist_item *item)
+{
+ item->next = free_nodes;
+ free_nodes = item;
+}
+
+static void llist_free(struct llist *list)
{
while((list->back = list->front)) {
list->front = list->front->next;
- free(list->back);
+ llist_item_put(list->back);
}
free(list);
}
@@ -62,13 +82,13 @@ static struct llist * llist_copy(struct
if ((ret->size = list->size) == 0)
return ret;
- new = ret->front = xmalloc(sizeof(struct llist_item));
+ new = ret->front = llist_item_get();
new->sha1 = list->front->sha1;
old = list->front->next;
while (old) {
prev = new;
- new = xmalloc(sizeof(struct llist_item));
+ new = llist_item_get();
prev->next = new;
new->sha1 = old->sha1;
old = old->next;
@@ -82,7 +102,7 @@ static struct llist * llist_copy(struct
static inline struct llist_item * llist_insert(struct llist *list,
struct llist_item *after, char *sha1)
{
- struct llist_item *new = xmalloc(sizeof(struct llist_item));
+ struct llist_item *new = llist_item_get();
new->sha1 = sha1;
new->next = NULL;
@@ -153,7 +173,7 @@ redo_from_start:
prev->next = l->next;
if (l == list->back)
list->back = prev;
- free(l);
+ llist_item_put(l);
list->size--;
return prev;
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: auto-packing on kernel.org? please?
From: Catalin Marinas @ 2005-11-22 14:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chuck Lever, Carl Baldwin, H. Peter Anvin, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511212134330.13959@g5.osdl.org>
On 22/11/05, Linus Torvalds <torvalds@osdl.org> wrote:
> On Tue, 22 Nov 2005, Chuck Lever wrote:
> > there are some things repacking does that breaks StGIT, though.
> >
> > git repack -d
> >
> > seems to remove old commits that StGIT was still depending on.
>
> If that is true, then "git-fsck-cache" probably also reports errors on a
> StGIT repository. No? Basically, it implies that the tool doesn't know how
> to find all the "heads".
Indeed, 'git repack -d' or 'git prune' might remove the patches which
are not applied since there is no link to them from .git/refs/.
> Could somebody (Catalin?) perhaps tell how tools like git-fsck-cache and
> git-repack could figure out which objects are still in use by stgit?
They don't figure this out at the moment. I initially thought about
implementing these commands in StGIT so that they would pass the
proper references.
> Preferably with some generic mechanism that _other_ projects (not just
> stgit) might want to use?
>
> The preferred way would be to just list the references somewhere under
> .git/refs/stgit, in which case fsck and repack should pick them up
> automatically (so clearly stgit doesn't do that right now ;).
I thought about adding .git/refs/patches/<branch>/* files
corresponding to the every StGIT patch. Are the above git commands
looking at all depths in the .git/refs/ directory?
> > git repack -a -n
> >
> > seems to work fine with StGIT,
>
> Well, it "works", but not "fine". Since it doesn't know about the stgit
> objects, it won't ever pack them.
>
> But maybe that's what stgit wants (since they are "temporary"), but it
> does mean that if you see a big advantage from packing, you might be
> losing some of it.
The 'git repack -a' command would include the applied patches in the
newly created pack but leave out the unapplied ones. It would be even
better to leave all of them out since the StGIT patches are frequently
changed but an independent mechanism for this would complicate GIT -
'git repack' shouldn't pack any of the objects found in
.git/refs/patches/, even if they are reachable via .git/refs/heads/*
(and maybe call the patches directory something like
.git/refs/unpackable or volatile).
--
Catalin
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Andreas Ericsson @ 2005-11-22 13:58 UTC (permalink / raw)
To: linux; +Cc: git, torvalds
In-Reply-To: <20051122132144.24691.qmail@science.horizon.com>
linux@horizon.com wrote:
>>So, would this be considered legal or would it barf on baz?
>>
>>foo # No prefix
>> bar # tab prefix
>> baz # 8 spaces prefix
>
>
> It would barf on baz. "\t" is not a prefix of " ".
>
But to the human eye they are the same. This is just a backwards way of
making the computer think it's smart by recognizing a difference that,
for all human purposes, aren't there. Like Linus said some posts ago;
software should conform to humans. Not the other way around.
>
>>Real fun would be if the mta sends tabs as spaces. Then there'd
>>be no way at all of telling if the config *is* valid or not.
>
>
> We have this problem already with whitespace damage in the "before"
> parts of patches. Are you suggesting that the user will be confused
> because some third party edited their config using an editor that
> messed up the leading whitespace and then just left it broken?
>
This is supposed to be edited by git config-set (or at least editable).
When that breaks or when someone finds it inconvenient people will start
using their editors. The logical way for a user to align new text to
text 8 spaces away is to use the tab key. Depending on the editor (and
the settings of that editor), the user will seem to have made perfectly
correct changes that git will barf on, which brings us back to "software
should conform to humans".
In short; This proposed format is just one step above a binary-format
config file from the user-friendliness perspective.
> There's a certain level of "evil gremlins came in during the night and
> added bugs to my code" that I bloody well expect to be confusing!
>
Can't help you there. I only do the cuddly mogwais.
> You might have problems inserting a line that suffers mailer damage,
> mailer sends you, but if you had sent it as a context diff, the patch
> process would have choked on the whitespace anyway.
>
git only does unified diffs (but doesn't allow any fuzz, so it would
break those too).
> I'm not particularly agitating for an indent-based syntax, but it
> is moderately popular and successful, and anyone criticising it should
> at least know how it works.
>
> The standard interpretation of leading whitespace accepts basically
> that subset of "looks right" that is insensitive to tab setting.
>
>
>>Excellent error messages aren't good enough. It's ok for Python, since
>>that's a programming language. We can expect infinitely more from
>>programmers than we can from users.
>
>
> We're talking about git users here, right?
> More specifically, we're talking about git users who are pulling from
> multiple remote trees, no?
>
> Perhaps you could clarify how this set of people is not a strict
> subset of the set of programmers...
>
Package maintainers, tech-doc writers. Not really suits, but with a hint
of tie nonetheless.
>
>>That's not the point. If everything looks good it should work good,
>>regardless of which editor or tab-setting one's using.
>
>
> Unfortunately, that's provably impossible, because it will look
> different to different people.
>
> Proof by example:
>
> header1
> header2 # 4 spaces
> body3 # 8 spaces
> body4 # one tab
>
> That looks good to me, with 8-space tabs:
>
> header1 {
> header2 {
> body3
> body4
> }
> }
>
> But it also looks great to someone with 4-space tabs:
>
> header1 {
> header2 {
> body3
> }
> body4
> }
>
> Too bad it doesn't work the same.
>
> The standard whitespace-parsing algorithm rejects "body4" on the grounds
> that it's ambiguous.
What I conclude from these examples are that;
1. Any brace-parsing algorithm does the right thing for every case.
2. Indentation-level parsing doesn't, so it's less robust.
Indentation-level parsing is nice-ish in a programming language because
it enforces strong typing so others that read your program can easily do
so. I personally disagree with that, but I can see the point.
How important is it that others can easily read your configuration file?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Fixed git:// IPv4 address problem when compiled with -DNO_IPV6.
From: Paul Serice @ 2005-11-22 13:54 UTC (permalink / raw)
To: git
Failure to dereference a pointer caused incorrect initialization of
the IPv4 address when calling connect() when compiled with -DNO_IPV6.
With this patch and yesterday's patch for git-daemon, it should now be
possible to use the native git protocol for both the client and server
on Cygwin.
Signed-off-by: Paul Serice <paul@serice.net>
---
connect.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 5bc7f67c535dbbbb9340285c82226a8dd6e4afec
b16765657940be2f4d14e8f1e65d35e4b32bea0f
diff --git a/connect.c b/connect.c
index 7a417e5..93f6f80 100644
--- a/connect.c
+++ b/connect.c
@@ -427,7 +427,7 @@ static int git_tcp_connect(int fd[2], co
memset(&sa, 0, sizeof sa);
sa.sin_family = he->h_addrtype;
sa.sin_port = htons(nport);
- memcpy(&sa.sin_addr, ap, he->h_length);
+ memcpy(&sa.sin_addr, *ap, he->h_length);
if (connect(sockfd, (struct sockaddr *)&sa, sizeof sa) < 0) {
close(sockfd);
---
0.99.9.GIT
^ permalink raw reply related
* Re: Get rid of .git/branches/ and .git/remotes/?
From: linux @ 2005-11-22 13:21 UTC (permalink / raw)
To: ae, linux; +Cc: git, torvalds
In-Reply-To: <4382D31E.40400@op5.se>
> So, would this be considered legal or would it barf on baz?
>
> foo # No prefix
> bar # tab prefix
> baz # 8 spaces prefix
It would barf on baz. "\t" is not a prefix of " ".
> Most people have tabsize at 8. Some don't. Some editors insert spaces
> instead of tabs while others don't. If we just match strings we'll
> end up with users sending bug-reports by cut'n pasting their perfectly
> valid-looking config which mixes tabs and spaces just because it's
> been edited by people using different editors.
> Real fun would be if the mta sends tabs as spaces. Then there'd
> be no way at all of telling if the config *is* valid or not.
We have this problem already with whitespace damage in the "before"
parts of patches. Are you suggesting that the user will be confused
because some third party edited their config using an editor that
messed up the leading whitespace and then just left it broken?
There's a certain level of "evil gremlins came in during the night and
added bugs to my code" that I bloody well expect to be confusing!
You might have problems inserting a line that suffers mailer damage,
mailer sends you, but if you had sent it as a context diff, the patch
process would have choked on the whitespace anyway.
I'm not particularly agitating for an indent-based syntax, but it
is moderately popular and successful, and anyone criticising it should
at least know how it works.
The standard interpretation of leading whitespace accepts basically
that subset of "looks right" that is insensitive to tab setting.
> Excellent error messages aren't good enough. It's ok for Python, since
> that's a programming language. We can expect infinitely more from
> programmers than we can from users.
We're talking about git users here, right?
More specifically, we're talking about git users who are pulling from
multiple remote trees, no?
Perhaps you could clarify how this set of people is not a strict
subset of the set of programmers...
>> It irritates you the first few times until you learn to do it right in
>> first place, just like it irritates most beginning C programmers that the
>> compiler keeps complaining about missing semicolons.
> If I'm trying out some new stuff that annoys me three times without me
> seeing an obvious error on my part (in the editor of my choice) I
> usually write it down as broken and move on.
What part of something like:
Can't figure out nesting level on line 232. Its leading
whitespace (" ", all spaces), is not a prefix or
extension of the whitespace on the preceding line 230
("\t", all tabs).
makes the error non-obvious?
If you refuse to read the error message at all, you can get confused,
but you'll also be confused by perfectly valid code producing diagnostics
like "error: dereferencing pointer to incomplete type" if you forget to
#include the right header 200 lines before the location of your error.
>> Computers will be annoying about syntax until they learn to do what
>> I want them to do rather than what I tell them to do, at which point
>> they'll be smart enough to start being annoying by doing what they want
>> to to instead of what I want them to do.
> That's not the point. If everything looks good it should work good,
> regardless of which editor or tab-setting one's using.
Unfortunately, that's provably impossible, because it will look
different to different people.
Proof by example:
header1
header2 # 4 spaces
body3 # 8 spaces
body4 # one tab
That looks good to me, with 8-space tabs:
header1 {
header2 {
body3
body4
}
}
But it also looks great to someone with 4-space tabs:
header1 {
header2 {
body3
}
body4
}
Too bad it doesn't work the same.
The standard whitespace-parsing algorithm rejects "body4" on the grounds
that it's ambiguous. Simple, robust, and no making guesses that lead
to an error message 20 lines beyond the actual problem. It just says
"Hey! Fix line 4!"
>> Seriously, you could always have it print warning messages but try to
>> keep going by assuming 8 space tabs so that at least you can postpone
>> fixing the problem until your current train of thought has pulled into
>> the station.
> There used to be $TABSIZE (or some such). Check it if you implement
> this. Or just skip it entirely. I would prefer the latter.
Fine with me. It's a fallback heuristic anyway.
^ permalink raw reply
* Re: [PATCH 4/6] Add check_repo_format check for all major operations.
From: Martin Atukunda @ 2005-11-22 12:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkzhf5li.fsf@assigned-by-dhcp.cox.net>
On Tuesday 22 November 2005 11:29, Junio C Hamano wrote:
> Martin Atukunda <matlads@dsmagic.com> writes:
> > 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.
>
> Thanks, but I think this one is wrong.
<snip>
> In setup_git_env() you have only read GIT_DIR environment but
> have not done the toplevel discovery. Especially, this is
> called from get_git_dir(), and you call that as the first thing
> as setup_git_directory(). However, that function is supposed to
> be callable by processes that are in a subdirectory, without
> GIT_DIR explicitly specified, and the place get_git_dir() is
> called in that function is way before the discovery of the
> toplevel happens. Until then, you do not know where your .git/
> directory or .git/config file is. If you start in Documentation
> subdirectory in git project, your setup_git_directory() would
> first call get_git_dir(), which says "I assume the config file
> is at ./.git/config -- oh there is no such thing". At that
> point you are checking Documentation/.git/config.
>
> It would happen to work because you intend to allow version 0
> repository for any future version of tool, and even if this
> codepath mistakenly thinks the repository is version 0, it does
> not hurt, as long as your setup_git_directory() calls
> check_repo_format again after doing the toplevel discovery and
> checks the true .git/config file, but I do not think you have
> that call in the current series yet. Even if you had, this does
> not feel quite right to me.
would something like the following apply in this case: (totally untested :)
--
Add check_repo_format check for setup_git_directory(). This check needs
to be done in 2 cases in this function. first if GIT_DIR is set, and also
after the top_level directory is found.
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
diff --git a/setup.c b/setup.c
index 44b9866..45e716a 100644
--- a/setup.c
+++ b/setup.c
@@ -101,8 +101,11 @@ const char *setup_git_directory(void)
* If GIT_DIR is set explicitly, we're not going
* to do any discovery
*/
- if (getenv(GIT_DIR_ENVIRONMENT))
+ if (getenv(GIT_DIR_ENVIRONMENT)) {
+ get_git_dir(1);
+ check_repo_format();
return NULL;
+ }
if (!getcwd(cwd, sizeof(cwd)) || cwd[0] != '/')
die("Unable to read current working directory");
@@ -118,6 +121,8 @@ const char *setup_git_directory(void)
} while (cwd[--offset] != '/');
}
+ check_repo_format();
+
if (offset == len)
return NULL;
^ permalink raw reply related
* strange cg-add problem
From: Nico -telmich- Schottelius @ 2005-11-22 12:30 UTC (permalink / raw)
To: Git ML
[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]
Hello!
I try to backup a MySQLDump and put it into git so we have easy access
to diffs and can have a real history.
The problem I have is that it works perfectly, when running manually,
but when running in the script git refuses to use the file:
----------------------------------------------------------------------
srwali01:/home/server/backup/db# ~/db-dump.sh
/home/server/backup/db//2005-11-22/13:26 does not exist or is not a regular file
cg-add: warning: not all files could be added
cg-commit: Nothing to commit
----------------------------------------------------------------------
(The script can be found at [0].)
When I do that on the command line, this happens:
----------------------------------------------------------------------
srwali01:/home/server/backup/db# cg-add /home/server/backup/db//2005-11-22/13:26
Adding file /home/server/backup/db//2005-11-22/13:26
Ignoring path /home/server/backup/db//2005-11-22/13:26
srwali01:/home/server/backup/db# cg-commit -m "Backup vom 2005-11-22 um 13:26"
cg-commit: Nothing to commit
----------------------------------------------------------------------
When I add it with a relative path it works:
----------------------------------------------------------------------
Adding file 2005-11-22/13:26
srwali01:/home/server/backup/db# cg-commit -m "Backup vom 2005-11-22 um 13:26"
A 2005-11-22/13:26
Committed as 3086174c1c84ce598137062867c07a4b7c619c39.
----------------------------------------------------------------------
When I change it in the script to be relativeo
[( cd "$DDIR"; cg-add "$SUBDIR/$FILENAME"; cg-commit -m "Backup vom $SUBDIR um $FILENAME") ]
than the same happens:
----------------------------------------------------------------------
srwali01:~# ./db-dump.sh
2005-11-22/13:31 does not exist or is not a regular file
cg-add: warning: not all files could be added
cg-commit: Nothing to commit
----------------------------------------------------------------------
Any hint why it behaves differently in script and command line?
Btw, does someone know, why mysqldump does just one insert and a very very long line
and not many inserts with only one value? The bevahiour of it seems to have changed,
as mysqldump did that in earlier releases [sorry bit offtopic].
Greetings,
Nico
[0]: http://linux.schottelius.org/scripts/#db-dump+git.sh
--
Latest project: cinit-0.2.1 (http://linux.schottelius.org/cinit/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Franck @ 2005-11-22 10:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyppf1va.fsf@assigned-by-dhcp.cox.net>
2005/11/22, Junio C Hamano <junkio@cox.net>:
> I was not talking about _your_ case specifically. If you happen
> to have based your partial history on top of a single commit
> then the set of "such and such commits" might be only one, but
> you could for example clone from Linus tip, merge in a couple of
> jgarzik branch heads, put your own commits on top of them and
> then cauterize your history, stopping at those foreign commits.
> In such a case you obviously need to tell others where you
> chopped your history off.
>
I built the lite repository and got an error depending on which
original repo I used to push the lite one. Here is the history:
--------------------------------------------------------------
#
# building my pub repo from the "lite" repository
#
$ git checkout -b lite
$ git-show-branch
* [lite] Merge with Linux 2.6.14.
! [master] Merge with Linux 2.6.14.
! [origin] Merge with db93a82fa9d8b4d6e31c227922eaae829253bb88.
---
# push the initial commit object
$ git push /home/franck/pub/linux/git/linux-lite.git lite
updating 'refs/heads/lite'
from 0000000000000000000000000000000000000000
to 8643db584b46a61c968ae230897869f789bae020
Packing 19558 objects
Unpacking 19558 objects
100% (19558/19558) done
refs/heads/lite: 0000000000000000000000000000000000000000 ->
8643db584b46a61c968ae230897869f789bae020
#
# push first changes from lite repositoy -> KO
#
$ making some hard work
$ git commit -m "Did some hard work"
$ git push /home/franck/pub/linux/git/linux-lite.git lite
updating 'refs/heads/lite'
from 8643db584b46a61c968ae230897869f789bae020
to 730518eea7523afd5b7891bb7849973cab52d963
Packing 0 objects
Unpacking 0 objects
error: unpack should have generated
730518eea7523afd5b7891bb7849973cab52d963, but I can't find it!
$
#
# push first changes from "full" repository -> OK
#
# go to full repository and checkout linux.2.6.14
$ git commit -m "Did some hard work"
$ git push /home/franck/pub/linux/git/linux-lite.git lite
updating 'refs/heads/lite'
from 8643db584b46a61c968ae230897869f789bae020
to 067d05600fe7251b8c923fbeb9ba0068ee272110
Packing 108 objects
Unpacking 108 objects
100% (108/108) done
refs/heads/lite: 8643db584b46a61c968ae230897869f789bae020 ->
067d05600fe7251b8c923fbeb9ba0068ee272110
--------------------------------------------------------------
It seems that the "lite" repository can't be used as a working
repository. And If I use the last method to push some work, I can only
pull that changes from a full repository. From a lite one (without any
changes of course) I get this error:
$ git pull /home/franck/pub/linux/git/linux-lite.git lite
Packing 108 objects
Unpacking 108 objects
100% (108/108) done
Merging HEAD with f42aaff3bf8041c2d43f1ff6fdfe5df6e8a5b00b
Merging:
8643db584b46a61c968ae230897869f789bae020 Merge with Linux 2.6.14.
f42aaff3bf8041c2d43f1ff6fdfe5df6e8a5b00b Did some hard work
found 0 common ancestor(s):
Traceback (most recent call last):
File "/home/fbuihuu/bin/git-merge-recursive", line 870, in ?
firstBranch, secondBranch, graph)
File "/home/fbuihuu/bin/git-merge-recursive", line 67, in merge
mergedCA = ca[0]
IndexError: list index out of range
No merge strategy handled the merge.
Do you have any clues ?
Thanks
--
Franck
^ permalink raw reply
* Re: Diffs "from" working directory
From: Catalin Marinas @ 2005-11-22 10:35 UTC (permalink / raw)
To: cel; +Cc: git
In-Reply-To: <4382A972.1010801@citi.umich.edu>
On 22/11/05, Chuck Lever <cel@citi.umich.edu> wrote:
> Catalin Marinas wrote:
> > My import command sets the author to the e-mail sender, which was you.
>
> for some reason i was under the impression that it would parse the
> Signed-off-by: fields in the patch description, and take the first one
> as the patch author.
If you import a patch file and don't specify an author (and the patch
is not an e-mail), the first Signed-off-by: line is used. As Linus
mentioned, we could get rid of this assumption entirely and just
report an error if no author information is given.
--
Catalin
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Junio C Hamano @ 2005-11-22 9:50 UTC (permalink / raw)
To: Franck; +Cc: git
In-Reply-To: <cda58cb80511220122r76ca69a2y@mail.gmail.com>
Franck <vagabon.xyz@gmail.com> writes:
> 2005/11/21, Junio C Hamano <junkio@cox.net>:
>> Franck <vagabon.xyz@gmail.com> writes:
>>
>> > ... But since I used grafting to "cut"
>> > my light repo and .git/info/grafts file is not copied during
>> > push/pull/clone operations it's not going to work. Is it a scheme that
>> > could work ?
>>
>> If you tell your downloaders that your repository is incomplete
>> and they need to have at least up to such and such commits from
>> another repository, they should be able to slurp from you.
I was not talking about _your_ case specifically. If you happen
to have based your partial history on top of a single commit
then the set of "such and such commits" might be only one, but
you could for example clone from Linus tip, merge in a couple of
jgarzik branch heads, put your own commits on top of them and
then cauterize your history, stopping at those foreign commits.
In such a case you obviously need to tell others where you
chopped your history off.
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Franck @ 2005-11-22 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhda5pw6l.fsf@assigned-by-dhcp.cox.net>
2005/11/21, Junio C Hamano <junkio@cox.net>:
> Franck <vagabon.xyz@gmail.com> writes:
>
> > ... But since I used grafting to "cut"
> > my light repo and .git/info/grafts file is not copied during
> > push/pull/clone operations it's not going to work. Is it a scheme that
> > could work ?
>
> If you tell your downloaders that your repository is incomplete
> and they need to have at least up to such and such commits from
> another repository, they should be able to slurp from you.
>
What do you mean by "have at least up to such and such commits" ? I
can see only one commit that they need: the one I used to create my
public repository...
> It might be possible to teach upload-pack (that is run when your
> downloaders run git-fetch or git-clone against your repository)
> to somehow send a customized error message to the client when it
> finds the other end needs certain objects that you yourself do
> not even have. In that message you could say something like "due
> to space constraints this repository is an incomplete one, and
> you can only use it on top of a clone of such and such
> repository, found at this URL: ...".
>
That's a good idea. We get the same thing when cloning linux
repository. BTW how is it done in that case ?
> > Moreover, I'm wondering if my public repository really needs to store
> > big repo's pack files as it is described in git tutorial ?
>
> What you are trying to do is to keep your public repository
> fsck-objects *un*clean and still let downloaders work with it;
> so I suspect following that section of the tutorial procedure
> defeats the purpose your experiments.
>
Absolutely. My question was not accurate sorry. It should have been
"can I have a public repository wiith fsck-objects unclean and with a
grafts file that should be downloaded when cloning it.
Thanks
--
Franck
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Andreas Ericsson @ 2005-11-22 9:07 UTC (permalink / raw)
To: linux; +Cc: torvalds, git
In-Reply-To: <20051122041843.9436.qmail@science.horizon.com>
linux@horizon.com wrote:
>>This is like Makefiles: if you have spaces in the wrong place, it may all
>>_look_ fine, but the Makefile just doesn't work. Really irritating.
>
>
> Makefiles are more annoying because spaces instead of tabs can cause
> them to work *differently*. It's hard to write syntax that will
> actually do that, but the parser ahs to go past the problem a bit to
> really figure it out, so it can't print a nice error message.
>
> With the strict prefix convention, the parser can produce excellent
> error messages.
>
Excellent error messages aren't good enough. It's ok for Python, since
that's a programming language. We can expect infinitely more from
programmers than we can from users.
> It irritates you the first few times until you learn to do it right in
> first place, just like it irritates most beginning C programmers that the
> compiler keeps complaining about missing semicolons.
>
If I'm trying out some new stuff that annoys me three times without me
seeing an obvious error on my part (in the editor of my choice) I
usually write it down as broken and move on.
> Computers will be annoying about syntax until they learn to do what
> I want them to do rather than what I tell them to do, at which point
> they'll be smart enough to start being annoying by doing what they want
> to to instead of what I want them to do.
>
That's not the point. If everything looks good it should work good,
regardless of which editor or tab-setting one's using.
>
>>Of course, since I believe that tabs are always exactly 8 characters, I'd
>>also be perfectly happy to just declare that anybody who disagrees with me
>>is a moron and deserves to die (*).
>
>
> Seriously, you could always have it print warning messages but try to
> keep going by assuming 8 space tabs so that at least you can postpone
> fixing the problem until your current train of thought has pulled into
> the station.
There used to be $TABSIZE (or some such). Check it if you implement
this. Or just skip it entirely. I would prefer the latter.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Pure renames/copies
From: Santi Bejar @ 2005-11-22 9:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacfxrdao.fsf@assigned-by-dhcp.cox.net>
>
> Probably something like this would suffice.
>
Ok, thanks. Now the only issue with my broken repository (it does not
have all the blobs) is that it outputs:
error: unable to find abcde....
for all the src paths, but the result is ok.
But I can live with it.
Thanks
^ permalink raw reply
* Re: [PATCH 4/6] Add check_repo_format check for all major operations.
From: Junio C Hamano @ 2005-11-22 8:29 UTC (permalink / raw)
To: Martin Atukunda; +Cc: git
In-Reply-To: <113261929333-git-send-email-matlads@dsmagic.com>
Martin Atukunda <matlads@dsmagic.com> writes:
> 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.
Thanks, but I think this one is wrong.
> 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();
> }
> 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
In setup_git_env() you have only read GIT_DIR environment but
have not done the toplevel discovery. Especially, this is
called from get_git_dir(), and you call that as the first thing
as setup_git_directory(). However, that function is supposed to
be callable by processes that are in a subdirectory, without
GIT_DIR explicitly specified, and the place get_git_dir() is
called in that function is way before the discovery of the
toplevel happens. Until then, you do not know where your .git/
directory or .git/config file is. If you start in Documentation
subdirectory in git project, your setup_git_directory() would
first call get_git_dir(), which says "I assume the config file
is at ./.git/config -- oh there is no such thing". At that
point you are checking Documentation/.git/config.
It would happen to work because you intend to allow version 0
repository for any future version of tool, and even if this
codepath mistakenly thinks the repository is version 0, it does
not hurt, as long as your setup_git_directory() calls
check_repo_format again after doing the toplevel discovery and
checks the true .git/config file, but I do not think you have
that call in the current series yet. Even if you had, this does
not feel quite right to me.
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Andreas Ericsson @ 2005-11-22 8:13 UTC (permalink / raw)
To: linux; +Cc: torvalds, git
In-Reply-To: <20051122032014.32539.qmail@science.horizon.com>
linux@horizon.com wrote:
> Actually, most indentation-sensitive languages have a simpler solution:
> they don't try to convert whitespace strings to a number like "horizontal
> position"; they just compare strings.
>
> Each line must either have the same indentation string as some active
> scope, or its indentation must have the current innermost scope as a
> prefix, in which case it introduces a new scope.
>
> This allows anything except for
>
> foo # No prefix
> bar # 4 spaces prefix
> baz # tab prefix: illegal!
>
> The "baz" line would have to begin with 4 spaces to be legal.
> They could be followed by 4 more spaces, or a tab, or any other
> whitespace pattern.
>
So, would this be considered legal or would it barf on baz?
foo # No prefix
bar # tab prefix
baz # 8 spaces prefix
Most people have tabsize at 8. Some don't. Some editors insert spaces
instead of tabs while others don't. If we just match strings we'll
end up with users sending bug-reports by cut'n pasting their perfectly
valid-looking config which mixes tabs and spaces just because it's
been edited by people using different editors.
Real fun would be if the mta sends tabs as spaces. Then there'd
be no way at all of telling if the config *is* valid or not.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Re: [PATCH] Fix git.c compilation target
From: Junio C Hamano @ 2005-11-22 8:08 UTC (permalink / raw)
To: Alex Riesen, Andreas Ericsson; +Cc: git
In-Reply-To: <81b0412b0511212347n6f478824i7ad0ffdaa78285f3@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> On 11/22/05, Andreas Ericsson <ae@op5.se> 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.
>
> Yes, that's what I _actually_ mean :)
Thanks, both. Applied with minor clean-ups for the "clean"
target on top (forgot to remove SIMPLE_PROGRAM), and will push
out.
^ permalink raw reply
* Re: [PATCH] Re: [PATCH] Fix git.c compilation target
From: Alex Riesen @ 2005-11-22 7:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <43825BCF.8040402@op5.se>
On 11/22/05, Andreas Ericsson <ae@op5.se> 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.
>
Yes, that's what I _actually_ mean :)
^ permalink raw reply
* Re: index manipulation -- how?
From: Luben Tuikov @ 2005-11-22 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbr0dgo1f.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
>
> I thought what you originally wanted to do was revert only index
> without losing your changes from the working tree, so just to
> make sure, the above does _not_ do it --- the named file in the
> working tree is also reverted to the one from <tree-ish>.
Exactly what I want.
Thanks,
Luben
P.S. I figured this one out in three stages:
Since checked out files are in rw- mode, but unchecked
files simply do not exist, first I want to "revert"
a changed file in the working tree -- this one is easy.
Then the second stage is if also the index is updated
(but no commit), and the last stage is if also
there is a commit, for which I think I know what to use.
^ permalink raw reply
* Re: index manipulation -- how?
From: Junio C Hamano @ 2005-11-22 7:05 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20051122062048.8891.qmail@web31805.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> (There is a very similar construct in git-checkout.sh.
> So if you apply the patch below, please make sure
> git-checkout.sh doesn't break.)
Thanks.
> Question: so in effect, more generally:
> git checkout <tree-ish> <file>
>
> would do the right thing: update index and the working
> tree as the file <file> looked as it was at <tree-ish>?
Yes that is correct. Also by omitting <tree-ish> you can
checkout from the index.
I thought what you originally wanted to do was revert only index
without losing your changes from the working tree, so just to
make sure, the above does _not_ do it --- the named file in the
working tree is also reverted to the one from <tree-ish>.
^ permalink raw reply
* Re: [RFC] git-format-patch options
From: Luben Tuikov @ 2005-11-22 6:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andreas Ericsson
In-Reply-To: <7vhda5ssxb.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
>
> The case statement that follows that comment is not quite right,
> BTW. "format-patch foo bar..baz" should mean sequence of "foo"
> and then "bar..baz", but it incorrectly translates to a
> malformed "foo..bar..baz".
>
> Modulo that bug, what the current code does is to special case
> one or two arguments case and rewrite them in that case
> statement, and then iterate over the resulting "$@". We barf if
> each 'revpair' is not in rev1..rev2 format.
>
> But it might make sense to (still keeping the above three
> backward compatibility syntax exceptions) interpret "rev" to
> mean "rev^1..rev", like this:
Ok, I don't understand the patch below. I tried
to get from "rev" to a "rev^1..rev" or the identical
"rev^1 rev", but could never do it with git-format-patch.
So for now I just use the "rev^1..rev".
BTW, here is the analogy:
git-diff-tree --pretty=raw -p <commit-id>
does what I want, except that it is not in patch format
as expected. So it is quite possible to just add a
command line parameter to git-diff-tree to indicate
"formatted patch output", and we're done.
Luben
>
> ---
>
> diff --git a/git-format-patch.sh b/git-format-patch.sh
> index 7ee5d32..351790c 100755
> --- a/git-format-patch.sh
> +++ b/git-format-patch.sh
> @@ -99,7 +99,7 @@ filelist=$tmp-files
> # Also, "rev1.." should mean "rev1..HEAD"; git-diff users are
> # familiar with that syntax.
>
> -case "$#,$1" in
> +case "$#,$1$2" in
> 1,?*..?*)
> # single "rev1..rev2"
> ;;
> @@ -131,7 +131,8 @@ do
> rev2=`expr "$revpair" : '.*\.\.\(.*\)'`
> ;;
> *)
> - usage
> + rev1="$revpair^"
> + rev2="$revpair"
> ;;
> esac
> git-rev-parse --verify "$rev1^0" >/dev/null 2>&1 ||
>
>
>
> -
> 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: index manipulation -- how?
From: Luben Tuikov @ 2005-11-22 6:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3blpi6r7.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> >
> >> How do I reverse a _single_ "git-update-index" operation?
> >> Be it --add or just an update.
> >
> > Reverting working tree files are "git checkout HEAD the-file"
> > (both index and working tree file from the head commit) or "git
> > checkout -- the-file" (working tree file from the index), but I
> > do not think there is a prepackaged way to revert only a single
> > index path offhand.
> >
> > git-ls-tree HEAD the-file |
> > sed -e 's/^\([0-7]*\) [^ ]* \(.*\)/\1 \2/' |
> > git-update-index --index-info
Ok.
(There is a very similar construct in git-checkout.sh.
So if you apply the patch below, please make sure
git-checkout.sh doesn't break.)
Question: so in effect, more generally:
git checkout <tree-ish> <file>
would do the right thing: update index and the working
tree as the file <file> looked as it was at <tree-ish>?
Is that correct? Can someone confirm/deny?
Luben
P.S. So both methods as mentioned by Linus and Junio
do what I asked about.
> >
> > should work.
> >
> > I think changing update-index --index-info so that you can lose
> > the sed in between without breaking its other usage (it reads
> > from git-apply --index-info, which does not say " blob " which
> > is what the sed is stripping out) is a worthwhile thing to do.
>
> And here is the patch to let you say:
>
> git-ls-tree HEAD the-file | git-update-index --index-info
>
>
> ---
>
> diff --git a/update-index.c b/update-index.c
> index 5bbc3de..11b7f6a 100644
> --- a/update-index.c
> +++ b/update-index.c
> @@ -338,7 +338,7 @@ static void read_index_info(int line_ter
> struct strbuf buf;
> strbuf_init(&buf);
> while (1) {
> - char *ptr;
> + char *ptr, *tab;
> char *path_name;
> unsigned char sha1[20];
> unsigned int mode;
> @@ -348,12 +348,15 @@ static void read_index_info(int line_ter
> break;
>
> mode = strtoul(buf.buf, &ptr, 8);
> - if (ptr == buf.buf || *ptr != ' ' ||
> - get_sha1_hex(ptr + 1, sha1) ||
> - ptr[41] != '\t')
> + if (ptr == buf.buf || *ptr != ' ')
> goto bad_line;
>
> - ptr += 42;
> + tab = strchr(ptr, '\t');
> + if (!tab || tab - ptr < 41)
> + goto bad_line;
> + if (get_sha1_hex(tab - 40, sha1) || tab[-41] != ' ')
> + goto bad_line;
> + ptr = tab + 1;
>
> if (line_termination && ptr[0] == '"')
> path_name = unquote_c_style(ptr, NULL);
>
>
> -
> 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
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