* Re: [PATCH] stgit: fix clone
From: Chuck Lever @ 2006-01-11 22:47 UTC (permalink / raw)
To: cel; +Cc: Pavel Roskin, Catalin Marinas, git
In-Reply-To: <43C58916.6030409@citi.umich.edu>
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
Chuck Lever wrote:
> hi pavel-
>
> exactly where does the clone operation fail? is it at the checkout step?
>
> seems to me the "git clone" script should create an environment where
> "git-rev-parse --git-dir" ought to work correctly.
oops. i see it now.
stgit/main.py does a special stack.Series('master') just for the clone
command. it really shouldn't do this -- the crt_series.init() in the
clone command ought to be fixed to do this properly.
catalin, do you agree?
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 451 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source 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://troy.citi.umich.edu/u/cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH] stgit: fix clone
From: Chuck Lever @ 2006-01-11 22:39 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Catalin Marinas, git
In-Reply-To: <1137017966.10975.8.camel@dv>
[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]
hi pavel-
exactly where does the clone operation fail? is it at the checkout step?
seems to me the "git clone" script should create an environment where
"git-rev-parse --git-dir" ought to work correctly.
Pavel Roskin wrote:
> "stg clone" is currently broken:
>
> $ stg clone http://homepage.ntlworld.com/cmarinas/stgit.git
> stg clone: git-rev-parse --git-dir failed
>
> This happens with current git. "git-rev-parse --git-dir" doesn't work
> in an empty directory. The patch avoids running "git-rev-parse
> --git-dir" when the requested command doesn't assume existence of git
> repository.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> ---
> Warning: this is my first non-trivial patch to StGIT and the first patch
> to a Python program.
>
> diff --git a/stgit/git.py b/stgit/git.py
> index a7b1c3f..0e63f69 100644
> --- a/stgit/git.py
> +++ b/stgit/git.py
> @@ -82,13 +82,16 @@ __commits = dict()
> # Functions
> #
>
> -def get_base_dir():
> +def get_base_dir(assume_top = False):
> """Different start-up variables read from the environment
> """
> if 'GIT_DIR' in os.environ:
> return os.environ['GIT_DIR']
> else:
> - return _output_one_line('git-rev-parse --git-dir')
> + if assume_top:
> + return '.git'
> + else:
> + return _output_one_line('git-rev-parse --git-dir')
>
> def get_commit(id_hash):
> """Commit objects factory. Save/look-up them in the __commits
> diff --git a/stgit/stack.py b/stgit/stack.py
> index 8b7c296..1c080b3 100644
> --- a/stgit/stack.py
> +++ b/stgit/stack.py
> @@ -263,7 +263,7 @@ class Series:
> self.__name = git.get_head_file()
>
> if self.__name:
> - base_dir = git.get_base_dir()
> + base_dir = git.get_base_dir(assume_top = (name == 'master'))
> self.__patch_dir = os.path.join(base_dir, 'patches',
> self.__name)
> self.__base_file = os.path.join(base_dir, 'refs', 'bases',
>
>
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 451 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source 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://troy.citi.umich.edu/u/cel/
version:2.1
end:vcard
^ permalink raw reply
* [PATCH] stgit: fix clone
From: Pavel Roskin @ 2006-01-11 22:19 UTC (permalink / raw)
To: Catalin Marinas, git
"stg clone" is currently broken:
$ stg clone http://homepage.ntlworld.com/cmarinas/stgit.git
stg clone: git-rev-parse --git-dir failed
This happens with current git. "git-rev-parse --git-dir" doesn't work
in an empty directory. The patch avoids running "git-rev-parse
--git-dir" when the requested command doesn't assume existence of git
repository.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
Warning: this is my first non-trivial patch to StGIT and the first patch
to a Python program.
diff --git a/stgit/git.py b/stgit/git.py
index a7b1c3f..0e63f69 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -82,13 +82,16 @@ __commits = dict()
# Functions
#
-def get_base_dir():
+def get_base_dir(assume_top = False):
"""Different start-up variables read from the environment
"""
if 'GIT_DIR' in os.environ:
return os.environ['GIT_DIR']
else:
- return _output_one_line('git-rev-parse --git-dir')
+ if assume_top:
+ return '.git'
+ else:
+ return _output_one_line('git-rev-parse --git-dir')
def get_commit(id_hash):
"""Commit objects factory. Save/look-up them in the __commits
diff --git a/stgit/stack.py b/stgit/stack.py
index 8b7c296..1c080b3 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -263,7 +263,7 @@ class Series:
self.__name = git.get_head_file()
if self.__name:
- base_dir = git.get_base_dir()
+ base_dir = git.get_base_dir(assume_top = (name == 'master'))
self.__patch_dir = os.path.join(base_dir, 'patches',
self.__name)
self.__base_file = os.path.join(base_dir, 'refs', 'bases',
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: [PATCH] (Updated) Exec git programs without using PATH.
From: Junio C Hamano @ 2006-01-11 21:32 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: Linus Torvalds, Andreas Ericsson, git
In-Reply-To: <1137014812.11717.669.camel@brick.watson.ibm.com>
Michal Ostrowski <mostrows@watson.ibm.com> writes:
> I briefly tried to consider if I could hide the various fork()+exec()
> sequences behind something like the run_command*() interfaces (which
> would move us down the direction of something "spawn()"-like). I found
> that there's a lot of variation between the various paths in terms of
> what happens between fork() and exec() on the various paths that does
> not lend itself to such consolidation.
>
> I'd love to be convinced otherwise.
Unfortunately I am with Michal on this one (both "eh, I do not
think that is feasible" and "I'd love to be...").
The run_command*() interfaces and its users were the best I
could come up with as far as such consolidations could go when I
did it.
^ permalink raw reply
* Re: [PATCH] (Updated) Exec git programs without using PATH.
From: Michal Ostrowski @ 2006-01-11 21:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.64.0601111238550.5073@g5.osdl.org>
On Wed, 2006-01-11 at 12:42 -0800, Linus Torvalds wrote:
>
> On Wed, 11 Jan 2006, Junio C Hamano wrote:
> >
> > For your (primarily Michal, but other interested parties as
> > well) reference, here is the diff between your patch in the
> > message I am replying to and what I placed in the "pu" branch
> > last night.
>
> Tangentially related note: maybe we should try to move to a "spawn()" like
> interface so that it could port better to native Windows interfaces?
>
> Even under Linux, using vfork()+exec() is actually faster than a regular
> fork/exec, so there are potential advantages.
>
> The real advantage of fork+exec is how you can do arbitrary setup between
> the two, without needing insanely complex rules for file descriptors etc.
> But maybe we don't have tons of those issues?
>
I briefly tried to consider if I could hide the various fork()+exec()
sequences behind something like the run_command*() interfaces (which
would move us down the direction of something "spawn()"-like). I found
that there's a lot of variation between the various paths in terms of
what happens between fork() and exec() on the various paths that does
not lend itself to such consolidation.
I'd love to be convinced otherwise.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* Re: [PATCH] (Updated) Exec git programs without using PATH.
From: Linus Torvalds @ 2006-01-11 20:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michal Ostrowski, Andreas Ericsson, git
In-Reply-To: <7vek3esdw0.fsf@assigned-by-dhcp.cox.net>
On Wed, 11 Jan 2006, Junio C Hamano wrote:
>
> For your (primarily Michal, but other interested parties as
> well) reference, here is the diff between your patch in the
> message I am replying to and what I placed in the "pu" branch
> last night.
Tangentially related note: maybe we should try to move to a "spawn()" like
interface so that it could port better to native Windows interfaces?
Even under Linux, using vfork()+exec() is actually faster than a regular
fork/exec, so there are potential advantages.
The real advantage of fork+exec is how you can do arbitrary setup between
the two, without needing insanely complex rules for file descriptors etc.
But maybe we don't have tons of those issues?
Linus
^ permalink raw reply
* [PATCH 1/2] Use light stacking for non-option arguments.
From: Andreas Ericsson @ 2006-01-11 20:42 UTC (permalink / raw)
To: git
This patch adds some simple library code that can help C-programs
in the git suite ignore argument ordering without interfering
with the current argument parsing code too much.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
Makefile | 4 ++--
stack.c | 42 ++++++++++++++++++++++++++++++++++++++++++
stack.h | 9 +++++++++
3 files changed, 53 insertions(+), 2 deletions(-)
create mode 100644 stack.c
create mode 100644 stack.h
5ebd4cbfef1a2c369f763eb3a98f079ffb4f6b5d
diff --git a/Makefile b/Makefile
index c9c15b5..ba861fb 100644
--- a/Makefile
+++ b/Makefile
@@ -165,7 +165,7 @@ LIB_FILE=libgit.a
LIB_H = \
blob.h cache.h commit.h count-delta.h csum-file.h delta.h \
diff.h epoch.h object.h pack.h pkt-line.h quote.h refs.h \
- run-command.h strbuf.h tag.h tree.h git-compat-util.h
+ run-command.h stack.h strbuf.h tag.h tree.h git-compat-util.h
DIFF_OBJS = \
diff.o diffcore-break.o diffcore-order.o diffcore-pathspec.o \
@@ -176,7 +176,7 @@ LIB_OBJS = \
date.o diff-delta.o entry.o ident.o index.o \
object.o pack-check.o patch-delta.o path.o pkt-line.o \
quote.o read-cache.o refs.o run-command.o \
- server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
+ server-info.o setup.o sha1_file.o sha1_name.o stack.o strbuf.o \
tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
fetch-clone.o \
$(DIFF_OBJS)
diff --git a/stack.c b/stack.c
new file mode 100644
index 0000000..e76a197
--- /dev/null
+++ b/stack.c
@@ -0,0 +1,42 @@
+#include <stdlib.h>
+#include <string.h>
+#include "stack.h"
+#include "git-compat-util.h"
+
+struct stack *stack_push(struct stack *s, const void *ptr)
+{
+ if (!s)
+ s = xcalloc(1, sizeof(struct stack));
+
+ if (s) {
+ s->stack = xrealloc(s->stack, sizeof(void *) * s->ents + 1);
+ s->stack[s->ents++] = (void *)ptr;
+ }
+
+ return s;
+}
+
+/* pull is from top, pop from bottom */
+void *stack_pull(struct stack *s)
+{
+ if (s && s->next < s->ents)
+ return s->stack[s->next++];
+
+ return NULL;
+}
+
+void *stack_pop(struct stack *s)
+{
+ if (s && s->ents)
+ return s->stack[--s->ents];
+
+ return NULL;
+}
+
+void stack_destroy(struct stack *s)
+{
+ if (s && s->stack) {
+ free(s->stack);
+ memset(s, 0, sizeof(struct stack));
+ }
+}
diff --git a/stack.h b/stack.h
new file mode 100644
index 0000000..5682559
--- /dev/null
+++ b/stack.h
@@ -0,0 +1,9 @@
+struct stack {
+ void **stack;
+ unsigned ents, next;
+};
+
+struct stack *stack_push(struct stack *s, const void *ptr);
+void *stack_pull(struct stack *s);
+void *stack_pop(struct stack *s);
+void stack_destroy(struct stack *s);
--
1.1.0
^ permalink raw reply related
* [PATCH 2/2] git-describe: Ignore argument ordering.
From: Andreas Ericsson @ 2006-01-11 20:42 UTC (permalink / raw)
To: git
Use the simple stacking code to do so.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
describe.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
9d03987889b62405be7b3fe09fb5dfa81245af00
diff --git a/describe.c b/describe.c
index fda4102..bd4b591 100644
--- a/describe.c
+++ b/describe.c
@@ -141,10 +141,12 @@ static void describe(const char *ref)
int main(int argc, char **argv)
{
- int i, desc = 0;
+ int i;
+ struct stack *st = NULL;
+ const char *arg;
for (i = 1; i < argc; i++) {
- const char *arg = argv[i];
+ arg = argv[i];
if (!strcmp(arg, "--all")) {
all = 1;
@@ -160,12 +162,15 @@ int main(int argc, char **argv)
abbrev = DEFAULT_ABBREV;
continue;
}
- describe(arg);
- desc++;
+
+ st = stack_push(st, arg);
}
- if (!desc)
+ if (!st)
describe("HEAD");
+ while ((arg = stack_pull(st)))
+ describe(arg);
+
return 0;
}
--
1.1.0
^ permalink raw reply related
* [PATCH 0/2] Argument order shouldn't matter
From: Andreas Ericsson @ 2006-01-11 20:42 UTC (permalink / raw)
Many of the C-programs in the git suite are sensitive to argument
ordering. That's a bit backwards for a modern tool-kit.
The first of these two patches provides some simple library code
to handle arbitrary pointers in a stack-like manner, although in
addition to stack_push() and stack_pop(), with their obvious meanings,
there's also stack_pull() which fetches from the bottom of the stack.
Err... that is, it fetches the least recently pushed item first.
The second patch is just an example of its implementation so we can
get the discussions going.
--
Makefile | 4 ++--
describe.c | 15 ++++++++++-----
stack.c | 42 ++++++++++++++++++++++++++++++++++++++++++
stack.h | 9 +++++++++
4 files changed, 63 insertions(+), 7 deletions(-)
--
git version 1.1.0
^ permalink raw reply
* Re: [PATCH] (Updated) Exec git programs without using PATH.
From: Junio C Hamano @ 2006-01-11 20:33 UTC (permalink / raw)
To: Michal Ostrowski; +Cc: Andreas Ericsson, git
In-Reply-To: <1136999157.11717.658.camel@brick.watson.ibm.com>
Michal Ostrowski <mostrows@watson.ibm.com> writes:
> The git suite may not be in PATH (and thus programs such as
>...
> Includes modifications by Junio C Hamano <junkio@cox.net>.
Thanks for the update (you did it even without line wrapping
this time).
I made further fixes last night and it is in the proposed
updates ("pu") branch. This branch is used to hold and showcase
what I plan to eventually merge into the master branch, and
consists of the topic branches merged on top of what is in the
master branch. To disect to see what shape I munged your patch
into, please look at it with gitk or gitweb and find "Merge
branch mo/exec" commit (my topic branches are named after patch
author and topic keyword). The second parent of that commit is
the tip of the topic branch mo/exec when the merge was made.
A word of caution to people on the list (not limited to Michal)
is needed again, because it's been a while since I talked about
the proposed updates branch last time (which was pre 1.0.0
release IIRC).
The "pu" branch is regularly rebuilt by merging private topic
branches on top of the then-current master branch, by doing
this:
$ git checkout pu
$ git reset --hard master ;# build from scratch!
$ git pull . topic1
$ git pull . topic2
$ ...
$ git pull . topicN
What this means is that you (not just Michal---"people") should
not base your development on top of "pu" branch proper, since
you will have a hard time updating and merging. Disecting my
"pu" branch to find the topic branch that corresponds to your
topic, and doing your development and patch preparation based on
that branch tip (and tell me that the patch is against your
topic branch, or "pu") is possible, but even that is not always
an easy option, since I may occasionally have to rebase my topic
branches as well. You can always send in an updated patch based
on my master, and I'll manage with three-way merge to pick out
the real changes since your last iteration.
For your (primarily Michal, but other interested parties as
well) reference, here is the diff between your patch in the
message I am replying to and what I placed in the "pu" branch
last night.
-- >8 --
Updates on top of comments last night.
- git-unpack-objects are run via execv_git_cmd, so no "git-"
prefix should be given.
- two more files need #include "exec_cmd.h".
---
diff --git a/receive-pack.c b/receive-pack.c
index 6120dbe..eae31e3 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -6,7 +6,7 @@
static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
-static char *unpacker[] = { "git-unpack-objects", NULL };
+static char *unpacker[] = { "unpack-objects", NULL };
static int report_status = 0;
diff --git a/send-pack.c b/send-pack.c
index 4a420a6..990be3f 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -3,6 +3,7 @@
#include "tag.h"
#include "refs.h"
#include "pkt-line.h"
+#include "exec_cmd.h"
static const char send_pack_usage[] =
"git-send-pack [--all] [--exec=git-receive-pack] <remote> [<head>...]\n"
diff --git a/shell.c b/shell.c
index d40dfe4..fc0c73c 100644
--- a/shell.c
+++ b/shell.c
@@ -1,5 +1,6 @@
#include "cache.h"
#include "quote.h"
+#include "exec_cmd.h"
static int do_generic_cmd(const char *me, char *arg)
{
^ permalink raw reply related
* [PATCH] git-describe: Show HEAD by default.
From: Andreas Ericsson @ 2006-01-11 20:33 UTC (permalink / raw)
To: git
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
describe.c | 27 +++++++++++++++++----------
1 files changed, 17 insertions(+), 10 deletions(-)
b3c6fee2b1dda213fe8439da2c14189abab9bdf7
diff --git a/describe.c b/describe.c
index a0180f5..fda4102 100644
--- a/describe.c
+++ b/describe.c
@@ -98,11 +98,20 @@ static int compare_names(const void *_a,
return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
}
-static void describe(struct commit *cmit)
+static void describe(const char *ref)
{
struct commit_list *list;
static int initialized = 0;
struct commit_name *n;
+ unsigned char sha1[20];
+ struct commit *cmit;
+
+ if (get_sha1(ref, sha1) < 0)
+ usage(describe_usage);
+
+ cmit = lookup_commit_reference(sha1);
+ if (!cmit)
+ usage(describe_usage);
if (!initialized) {
initialized = 1;
@@ -132,12 +141,10 @@ static void describe(struct commit *cmit
int main(int argc, char **argv)
{
- int i;
+ int i, desc = 0;
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
- unsigned char sha1[20];
- struct commit *cmit;
if (!strcmp(arg, "--all")) {
all = 1;
@@ -153,12 +160,12 @@ int main(int argc, char **argv)
abbrev = DEFAULT_ABBREV;
continue;
}
- if (get_sha1(arg, sha1) < 0)
- usage(describe_usage);
- cmit = lookup_commit_reference(sha1);
- if (!cmit)
- usage(describe_usage);
- describe(cmit);
+ describe(arg);
+ desc++;
}
+
+ if (!desc)
+ describe("HEAD");
+
return 0;
}
--
1.1.0
^ permalink raw reply related
* Re: RFC: Subprojects
From: Linus Torvalds @ 2006-01-11 20:06 UTC (permalink / raw)
To: Simon Richter; +Cc: Johannes Schindelin, git
In-Reply-To: <43C55FEF.2090108@hogyros.de>
On Wed, 11 Jan 2006, Simon Richter wrote:
>
> Exactly. The questions I posed in the last paragraph of the initial mail,
> rewritten for clarity, would be
> - "should cg-commit automatically create a commit in the master project when
> a change in the subproject is committed?", and
No.
Don't commit in the "parent" thing automatically. The sub-project should
be as independent as possible, and you should see a commit to that to be
nothing more than "editing" a regular file in the top-level project.
In many ways, if you decide to look into doing a "gitlink" kind of object,
that object really _does_ conceptually point to the .git/HEAD file in the
subproject. So when you do a commit in the subproject, conceptually that
is no different from editing the .git/HEAD.
Then, when you want to commit the _dependency_ of the top-level project on
the sub-project, you commit in the top level. That commit probably does
other things too: it probably also commits the code in the top level that
now depends on the sub-project changes.
So don't tie the two together any more than necessary. My suggested usage
case has the big advantage that the sub-project is much less tightly
coupled, so you can do things like "git pull" _inside_ the subproject, to
update it, and then do a big compile in the top-level project to reflect
the changes (and perhaps update stuff at the top level to conform to
changes in the sub-project), and then commit in the top independently
(which will now automatically pick up the changes to .git/HEAD that "git
pull" did on the subproject).
> - "should cg-commit automatically commit all changes to subprojects when a
> path that has been listed on the command line contains a subproject?".
Again, I'd really suggest not. If you keep the "gitlink" really meaning
the ".git/HEAD" contents of the subproject (which is a good semantic
rule), then if there is any dirty state in the sub-project, it is totally
irrelevant to a "git commit". Because it's dirty, it's not part of of
.git/HEAD yet.
Now, obviously you should make "git status" _talk_ about the fact that the
sub-project is dirty, so that the committer sees that the sub-project
needs committing first (the same way "git status" now informs git commit
about dirty files that haven't been updated).
(I'm saying "git" here all the time rather than cg-, because not only
don't I know cogito very well, I think you want to do most of the core at
the git level, and just teach cg about the new capability).
Linus
^ permalink raw reply
* Re: git binary size...
From: Andreas Ericsson @ 2006-01-11 20:00 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <43C562F7.1090000@zytor.com>
H. Peter Anvin wrote:
> Andreas Ericsson wrote:
>>
>> strip:
>> strip $(STRIP_OPTS) $(PROGRAMS)
>>
>> so Linus can set STRIP_OPTS=--strip-debug and everybody's happy.
>>
>
> The proper way to do this is:
>
> strip:
> $(STRIP) $(STRIP_OPTS) $(PROGRAMS)
>
> For "strip", this is frequently omitted, though. Since "strip" is
> architecture-dependent, though, this is necessary for cross-compilation.
>
Damn! I almost made it through the entire day without learning anything,
and now you come along and spoil it all.
Oh well, new game tomorrow. ;)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git binary size...
From: H. Peter Anvin @ 2006-01-11 19:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andreas Ericsson, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601111134560.5073@g5.osdl.org>
Linus Torvalds wrote:
>
> Well, that ends up shaving some more from the binaries, but at a much
> bigger cost than just removing "-g".
>
> With stripped binaries, you can't really do _anything_. You get a
> core-file, and you're screwed.
>
> With non-stripped binaries you can at least see the function the SIGSEGV
> happened in, and you usually even get a half-way decent backtrace etc.
>
That's the really nice bit with the way e.g. RPM does it. You don't
have to have the debug information around most of the time, but you can
do "yum install git-debuginfo" and suddenly you have it all -- and yet
the binary is unchanged, so your random core file actually matches the
debuginfo.
-hpa
^ permalink raw reply
* Re: git binary size...
From: H. Peter Anvin @ 2006-01-11 19:56 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <43C56278.6090105@op5.se>
Andreas Ericsson wrote:
> H. Peter Anvin wrote:
>
>>
>> I disagree with both of these. Most users will not install via "make
>> install", but rather via a package manager. Package managers have
>> long since dealt with this problem; in the case of rpm, the debug
>> information is stripped off into a separate package. Having "make
>> install" strip would break that -- although defining $(STRIP) makes it
>> a bit easier to deal with (STRIP=: make install).
>>
>
> Fair point. So how about a strip: target for just stripping the binaries
> in the directory? That way one can do "make strip install", but
> everything else will work as always. Better yet, make it
>
> strip:
> strip $(STRIP_OPTS) $(PROGRAMS)
>
> so Linus can set STRIP_OPTS=--strip-debug and everybody's happy.
>
The proper way to do this is:
strip:
$(STRIP) $(STRIP_OPTS) $(PROGRAMS)
For "strip", this is frequently omitted, though. Since "strip" is
architecture-dependent, though, this is necessary for cross-compilation.
-hpa
^ permalink raw reply
* Re: git binary size...
From: Andreas Ericsson @ 2006-01-11 19:54 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <43C55EE4.9010103@zytor.com>
H. Peter Anvin wrote:
>
> I disagree with both of these. Most users will not install via "make
> install", but rather via a package manager. Package managers have long
> since dealt with this problem; in the case of rpm, the debug information
> is stripped off into a separate package. Having "make install" strip
> would break that -- although defining $(STRIP) makes it a bit easier to
> deal with (STRIP=: make install).
>
Fair point. So how about a strip: target for just stripping the binaries
in the directory? That way one can do "make strip install", but
everything else will work as always. Better yet, make it
strip:
strip $(STRIP_OPTS) $(PROGRAMS)
so Linus can set STRIP_OPTS=--strip-debug and everybody's happy.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git binary size...
From: Linus Torvalds @ 2006-01-11 19:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <43C558FB.3030102@op5.se>
On Wed, 11 Jan 2006, Andreas Ericsson wrote:
>
> strip:
> strip $(PROGRAMS)
>
> install: strip
Well, that ends up shaving some more from the binaries, but at a much
bigger cost than just removing "-g".
With stripped binaries, you can't really do _anything_. You get a
core-file, and you're screwed.
With non-stripped binaries you can at least see the function the SIGSEGV
happened in, and you usually even get a half-way decent backtrace etc.
Linus
^ permalink raw reply
* Re: RFC: Subprojects
From: Simon Richter @ 2006-01-11 19:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0601110928350.5073@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 6042 bytes --]
Hi,
Linus Torvalds wrote:
> Turning a _snapshot_ of a subproject into a subdirectory is easy: you can
> literally just create a subdirectory, copy it there, and it will re-use
> all the objects that the subproject uses (ie the top-level project will
> have a "tree" entry that just points to the same tree entry as the
> top-level commit in the sub-project).
Exactly. My proposal is to allow the tree object to point to the
toplevel commit object directly, thus importing the entire project[1].
> However, while that works as a way to import snapshots, it doesn't work in
> any other way. It allows you to share objects with the "real project", and
> it's space-efficient etc, but there's no shared history, and you cannot
> merge back-and-forth, which is probably what you really want to do.
Well, the history cannot be really shared, as turning subtrees to
projects and vice versa is a valid use case (and in fact something I do
pretty often in my projects, as various "helper" classes evolve into
"utility" libraries). Since the subproject needs to be self-contained,
the history before it became a separate project will be difficult to
represent, to say the least.
> Quite frankly, you really probably want more of a "git-aware symlink" kind
> of thing. I'd really hesitate (in fact, I'd object) to re-use the existing
> "tree" type for it, but you're not the only one to have asked for
> subproject support, so this is clearly not a odd request.
[...]
> What we _could_ do is for you to first do a commit in the "independent"
> subproject (it really would be a totally independent git repository in all
> ways: you could continue to merge it with other subprojects of the same
> type), and then you could commit a new pointer to that subproject in the
> master project.
Exactly. The questions I posed in the last paragraph of the initial
mail, rewritten for clarity, would be
- "should cg-commit automatically create a commit in the master
project when a change in the subproject is committed?", and
- "should cg-commit automatically commit all changes to subprojects
when a path that has been listed on the command line contains a
subproject?".
There are three cases, basically:
- change to subproject, part of a larger set of changes, not ready for
prime time: A commit in the subproject, master left alone (obviously,
the directory would show as "modified".
- change to subproject, fixing a bug that affects the master project.
You'd expect these to happen often, as I could fix stuff that the master
doesn't care about in another tree. In this case, you'd want a new
commit to happen in the master as well, for everyone to enjoy.
- change to subproject and master that need to go in sync, like
renaming a configure option. Obviously, this can also happen after an
update of the subproject, so creating a new commit on the master after
an update is bad, but normal behaviour for update would be to merge and
create a commit instantly if there were no conflicts.
> The two would really be fundamentally independent: they'd be two different
> git projects, one would just have a strange kind of "symlink" to the
> other, which would include a name and the top commit SHA1 of the other
> project.
Well, that would be exactly what the tree contains. One could do an
additional level of indirection with another object that just points to
an sha1 (because its name is given by the tree referencing it).
Having such an object would mainly have the advantage of being extensible.
> I'd suggest adding a new kind of object ("gitlink") which has some
> well-specified format (20-byte SHA1 + ASCII C string "name" - the name
> translation to external repository would be done in the .git/config file
> of the "outer" project).
Well, most people would likely not care about the external repository of
the subproject, as they can get all the objects from the master project.
I'm not even sure the subproject needs an "origin" branch by default, as
you can push changes to the master project's maintainers who would then
eventually push them on to the subproject's maintainers (in fact I
believe it's vital to be able to keep changes to the subproject in the
master project so development can go on while the subproject maintainers
review the changes.
> Then a special file mode to indicate that in the
> "struct tree", and support for "git-update-cache" to understand how such
> an object is really tied into the "<pathname>/.git/HEAD" file rather than
> the rest of the directory contents.
That sounds pretty simple actually.
> Then a "git fetch" would have to be taught to recursively fetch the other
> subproject when the "gitlink" changes.
I think that would be mostly implicit if we were to use a direct
tree->commit reference, but can be implemented trivially even for the
link objects.
> It should be doable: somebody could try to implement a rough first draft
> (maybe not very seamless at first).
Indeed. I just wanted to have rough use cases thrown at me before I even
think of implementing something like it.
Simon
[1] There is a slight problem with that approach: When you cherry-pick
changes into a subproject (like I did today with the asm-arm/uaccess.h
constness fix), the subproject will have a separate branch whose head is
known to the outer project only. When the subproject gets merged with
its origin later, that branch is no longer needed, and it makes a lot of
sense to have the master project reference origin again. This means that
if you look at the history of the inner project from the POV of the
outer, the new commit is no longer a descendant of the old, but in fact
it may be a good idea to attempt a fast-forward merge nevertheless as
going through the common ancestor is very likely to cause conflicts
here, and those conflicts have already been resolved, or you wouldn't be
seeing an updated subproject link (i.e. you just want to preserve local
changes and stuff committed on top of the old reference).
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Re: git binary size...
From: Junio C Hamano @ 2006-01-11 19:40 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <43C558FB.3030102@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> I'd suggest adding
>
> strip:
> strip $(PROGRAMS)
>
> install: strip
>
> to Makefile instead.
That sounds sane. Binary distribution _might_ hate us if we did
so, though. IIRC Debian wanted to build with -g and strip
before installation themselves. I do not know how this
interacts with rpmbuild.
^ permalink raw reply
* Re: git binary size...
From: H. Peter Anvin @ 2006-01-11 19:39 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <43C558FB.3030102@op5.se>
Andreas Ericsson wrote:
>
> I'd suggest adding
>
> strip:
> strip $(PROGRAMS)
>
> install: strip
>
> to Makefile instead. That way people working on various git-tools won't
> have to remember to override the CFLAGS when debugging new stuff.
>
I disagree with both of these. Most users will not install via "make
install", but rather via a package manager. Package managers have long
since dealt with this problem; in the case of rpm, the debug information
is stripped off into a separate package. Having "make install" strip
would break that -- although defining $(STRIP) makes it a bit easier to
deal with (STRIP=: make install).
However, if the concern is "the average user" I really think there is no
reason do bother with this at all -- the average user should to "yum
install git" or whatever is the equivalent for their distribution. This
ain't 1990.
-hpa
^ permalink raw reply
* Re: reverting back both working copy and commits
From: Junio C Hamano @ 2006-01-11 19:37 UTC (permalink / raw)
To: Bahadir Balban; +Cc: git
In-Reply-To: <7ac1e90c0601110832u6fc3a3bcwb7e584445610e53f@mail.gmail.com>
Bahadir Balban <bahadir.balban@gmail.com> writes:
> % git-branch master-2006-get-rid-of-commits
>
> % git-reset --hard [sha1id]
>
> where sha1id is the id of commit I want to revert back to. After this,
> git-log points at the right commit (the one with [sha1id]) as the last
> commit made. However, the working copy is left in the original state,
> i.e with the unwanted changes.
Eh? That should not happen.
Could you elaborate?
$ git diff master-2006-get-rid-of-commits
should show differences between the wrongly committed state and
your working tree.
$ git diff --cached HEAD ;# or git diff --cached [sha1id]
should show *nothing* and
$ git diff HEAD ;# or git diff [sha1id]
should also show nothing.
What is different between what I just described "Thess should
happen" and what actually happens to you? I use "git reset
--hard" all the time, probably a lot more often than other
people, and I'd be surprised if things are not working.
What "git reset --hard" would leave behind are files in the
working tree that you had when you made the wrongly done commit,
which were *not* known to git (i.e. you forgot to "git add"
before committing). Since they are not known to git, "reset --hard"
does not touch them.
^ permalink raw reply
* Re: Checking git-cherry-pick Use Case
From: Junio C Hamano @ 2006-01-11 19:29 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Git List
In-Reply-To: <1136997967.29751.198.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
> My first question is that I expected to see
> something more like this (hand edited):
>
> ! [dev] Stuff jdl made up and committed
> * [jdl] Early stuff jdl made up
> ! [origin] Original stuff
> ---
> ++ [dev] Stuff jdl made up and committed
> + [dev^] Merge branch 'jdl'
> ++ [jdl^] Early stuff jdl made up
> +++ [origin] Original stuff
>
> That is, the _same_ commit is now in both the "dev"
> and "jdl" branches, so why does it have two lines here?
Because they are not the same commit; they are two separate
commits, that happen to have the same commit log message and
authorship information, and perhaps even result to show the same
"diff" if asked by 1-parameter git-diff-tree, but they are
different commit objects nevertheless.
Funnily enough, I think I sent out almost exactly the same
message as yours the last couple of days regarding workflows,
after I hacked a bit on gitweb ;-).
^ permalink raw reply
* Re: reverting back both working copy and commits
From: Andreas Ericsson @ 2006-01-11 19:28 UTC (permalink / raw)
To: Bahadir Balban; +Cc: git
In-Reply-To: <7ac1e90c0601110832u6fc3a3bcwb7e584445610e53f@mail.gmail.com>
Bahadir Balban wrote:
> Hi,
>
> I made some commits that later on I wanted to cancel. I did:
>
> % git-branch master-2006-get-rid-of-commits
>
> % git-reset --hard [sha1id]
>
> where sha1id is the id of commit I want to revert back to. After this,
> git-log points at the right commit (the one with [sha1id]) as the last
> commit made. However, the working copy is left in the original state,
> i.e with the unwanted changes.. How do I also revert the working
> sources into an earlier state.
>
The branch where you do the reset is the one being reset, so you should
have simply done the reset in the original branch without creating a new
one. If you're nervous you're gonna screw up you can do this;
git checkout <branch-with-unwanted-commit>
git tag anchor
git reset --hard <commit-ish>
If you find you've landed on the wrong commit you can undo the change with
git reset --hard anchor
which will restore the branch to wherever you were prior to the first
reset. Making an anchor tag is useful if you do several resets. You can
use ORIG_HEAD to undo a single reset.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git binary size...
From: Andreas Ericsson @ 2006-01-11 19:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601111021450.5073@g5.osdl.org>
Linus Torvalds wrote:
> Guess what the difference is here?
>
> [torvalds@g5 ~]$ du -sh bin/
> 14M bin/
> [torvalds@g5 ~]$ du -sh bin/
> 5.8M bin/
>
> Give up?
>
> In one case, "git" was compiled with the default options in the git
> Makefile. In the other one, the "-g" was removed.
>
> Now, maybe this is extra visible with PowerPC (32-bit) binaries, and it's
> not as bad on x86, but it's still a bit distressing.
>
> That "-g" doesn't buy users much of anything, and I doubt most developers
> care that deeply most of the time either (and can easily add it when they
> do care). It's left-over from long ago when it was much more useful.
>
> So I'd suggest just removing it.
>
I'd suggest adding
strip:
strip $(PROGRAMS)
install: strip
to Makefile instead. That way people working on various git-tools won't
have to remember to override the CFLAGS when debugging new stuff.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Proxy and authentication
From: Nick Hengeveld @ 2006-01-11 18:51 UTC (permalink / raw)
To: Beber; +Cc: git
In-Reply-To: <4615f4910601110653k5e2e8ffapb962a8b0829eeb11@mail.gmail.com>
On Wed, Jan 11, 2006 at 03:53:23PM +0100, Beber wrote:
> Is there plan to allow proxy authentication and http/webdav remote
> repository authentication ?
You can use .netrc for HTTP auth credentials, but I don't believe that
handles proxy authentication.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ 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