* Re: [ANNOUNCE] GIT 1.2.1
From: Michael Fischer @ 2006-02-18 4:31 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmkrizuw.fsf@assigned-by-dhcp.cox.net>
*sigh*
I got confused about git pull origin and git pull master.
Tutorial seems to tell me I should have said git pull origin
and left well enough alone.
Now I get:
fatal: you need to resolve your current index first
How do I do that?
TIA.
Michael
--
Michael Fischer Happiness is a config option.
michael@visv.net Recompile and be happy.
^ permalink raw reply
* [PATCH] git-svn: remove files from the index before adding/updating
From: Eric Wong @ 2006-02-18 5:04 UTC (permalink / raw)
To: git; +Cc: Eric Wong
This fixes a bug when importing where a directory gets removed/renamed
but is immediately replaced by a file of the same name in the same
revision.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
c142c70866ab8ce1765e4b88506aa79b5c5c1427
diff --git a/contrib/git-svn/git-svn b/contrib/git-svn/git-svn
index 2caf057..71a8b3b 100755
--- a/contrib/git-svn/git-svn
+++ b/contrib/git-svn/git-svn
@@ -580,13 +580,12 @@ sub svn_info {
sub sys { system(@_) == 0 or croak $? }
sub git_addremove {
- system( "git-ls-files -z --others ".
+ system( "git-diff-files --name-only -z ".
+ " | git-update-index --remove -z --stdin; ".
+ "git-ls-files -z --others ".
"'--exclude-from=$GIT_DIR/$GIT_SVN/info/exclude'".
- "| git-update-index --add -z --stdin; ".
- "git-ls-files -z --deleted ".
- "| git-update-index --remove -z --stdin; ".
- "git-ls-files -z --modified".
- "| git-update-index -z --stdin") == 0 or croak $?
+ " | git-update-index --add -z --stdin; "
+ ) == 0 or croak $?
}
sub s_to_file {
--
1.2.0.g4d1a-dirty
^ permalink raw reply related
* Re: What's in git.git
From: Junio C Hamano @ 2006-02-18 6:49 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060217142836.13137.qmail@science.horizon.com>
linux@horizon.com writes:
> Er... what does this do, again? I couldn't find the list
> discussion, and I can get this exact effect in vanilla 1.2.1
> with "git rebase master~1 topic".
>...
> OTOH, I can imagine wanting
>...
> A B---C topic
> / /
> D---E---F---G master
Yup. The example was a bad one, but the above, and in general
X---A'--B'--C' topic
D---E---F---G master
on an arbitrary X was what I wanted to do.
^ permalink raw reply
* Re: contrib/ area
From: Junio C Hamano @ 2006-02-18 6:49 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <873biikx6k.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> Is there interest in an emacs interface for git? I posted a first
> version (http://marc.theaimsgroup.com/?l=git&m=113313040724346&w=2)
> some time ago, I'd be happy to send you a patch with my latest version
> if you want to include it.
Martin already said he wants it, and I would second that. VC
backend is one of the things I kept in the TODO list for quite a
while (I think since early September 2005)...
^ permalink raw reply
* Re: contrib/ area
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: git
In-Reply-To: <cc723f590602170436l5b33ae6s1780c3c8d6383627@mail.gmail.com>
Aneesh Kumar <aneesh.kumar@gmail.com> writes:
> Attaching below the same in the form of patch generated by git format-patch
I'll let it pass this time, but you forgot a sign-off and
perhaps forgot to read Documentation/SubmittingPatches ;-).
^ permalink raw reply
* Re: [PATCH] git-repack question
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060217213824.5848.qmail@science.horizon.com>
linux@horizon.com writes:
> (Legalese: Patch placed in the public domain; copyright abandoned.)
The rest of the patch looks good, but I'd rather prefer a patch
with a proper sign-off, strongly prefereable with a real name so
that we can attach blame on later when another SCO happens ;-).
^ permalink raw reply
* Re: [PATCH] Prevent git-upload-pack segfault if object cannot be found
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87hd6x34lf.wl%cworth@cworth.org>
Thanks, this is the last remaining call that did not check its
return value from opendir().
I queued this one and three clone things from you. They will
appear in "next" first, but also be in 1.2.2.
^ permalink raw reply
* Re: [PATCH] git-rev-parse: Fix --short= option parsing
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20060218011053.GB2562@diku.dk>
Thanks. I queued the two fixes from you.
They will first appear in "next" and also in 1.2.2.
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
> ---
> commit 013b99654ee464856d266a72f0203d0fee2b0d11
> tree 3c961d6ebb8b9805ee3950ec081679de15f5a9ba
> parent 16e2efc524d181cf46dcb252532139a0aff4a28f
> author Jonas Fonseca <fonseca@diku.dk> Sat, 18 Feb 2006 02:05:11 +0100
> committer Jonas Fonseca <fonseca@antimatter.localdomain> Sat, 18 Feb 2006 02:05:11 +0100
BTW, what git-based tool do you use to spit out this ugly format?
Full object name of the parent commit is useful only if the
recipient has that object, and it is not one of mine, so it is
unlikely nobody but you would have it. Name of the tree is what
you would get _after_ applying this patch, so it also is not
very useful for e-mail communication.
^ permalink raw reply
* Re: [PATCH 1/5] Fixes for ancient versions of GNU make
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602171522020.24274@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/Makefile b/Makefile
> index d7d79de..b3401ac 100644
> --- a/Makefile
> +++ b/Makefile
> ...
> +# These will be used inside ''
> +SHELL_PATH_QUOTED = $(subst ','\'',$(SHELL_PATH))
> ...
> diff --git a/t/Makefile b/t/Makefile
> index 5c5a620..d78404f 100644
> --- a/t/Makefile
> +++ b/t/Makefile
> @@ -8,17 +8,14 @@ SHELL_PATH ?= $(SHELL)
> TAR ?= $(TAR)
>
> # Shell quote;
> -# Result of this needs to be placed inside ''
> -shq = $(subst ','\'',$(1))
> -# This has surrounding ''
> -shellquote = '$(call shq,$(1))'
> +SHELL_PATH_QUOTED = '$(subst ','\'',$(SHELL_PATH))'
I am not opposed to avoiding $(call), but subst everywhere look
ugly ;-).
You inherited this problem, but these two symbols in different
Makefiles with the same name mean two completely different
things, which confused me quite badly.
So if we were to do this portability fix, how about consistently
defining it without surrounding sq pair? Most of the places in
the main Makefile you use the symbol with other string, with the
whole thing quoted inside a sq pair, so that would make things
easier to read.
Then the one that uses it in the t/Makefile in 5/5 becomes:
$(T):
@echo "*** $@ ***"; '$(SHELL_PATH_QUOTED)' $@ $(GIT_TEST_OPTS)
^ permalink raw reply
* Re: [PATCH 5/5] Optionally work without python
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0602171523510.24274@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> In some setups (notably server setups) you do not need that dependency.
> Gracefully handle the absence of python when NO_PYTHON is defined.
> +ifdef NO_PYTHON
> + TEST_DEFS += NO_PYTHON=YesPlease
> +endif
I wonder if there is a better way to do this. All future
NO_BLAH that may affect tests need to have something like this
otherwise.
> -default_strategies='recursive'
> +if test -z "@@NO_PYTHON@@"; then
> + default_strategies='recursive'
> +else
> + default_strategies='resolve'
> +fi
Somebody commented on this part to make it shorter...
I'll take 2, 3, and 4 from this series for now. They will
appear in "next". Thanks.
^ permalink raw reply
* [PATCH] pack-objects: avoid delta chains that are too long.
From: Junio C Hamano @ 2006-02-18 6:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkwa6zk6.fsf@assigned-by-dhcp.cox.net>
This tries to rework the solution for the excess delta chain
problem. An earlier commit worked it around ``cheaply'', but
repeated repacking risks unbound growth of delta chains.
This version counts the length of delta chain we are reusing
from the existing pack, and makes sure a base object that has
sufficiently long delta chain does not get deltified.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This solves the problem by doing exactly what the previous
commit log suggested. We limit the chain depth correctly, to
save the user of the resulting pack from suffering runtime
overhead.
Will be in "next" tonight.
pack-objects.c | 43 +++++++++++++++++++++++++++++++++++--------
1 files changed, 35 insertions(+), 8 deletions(-)
e4c9327a77bd59e85d4b17a612e78977d68773ee
diff --git a/pack-objects.c b/pack-objects.c
index 38e1c99..0c9f4c9 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -10,16 +10,22 @@ static const char pack_usage[] = "git-pa
struct object_entry {
unsigned char sha1[20];
unsigned long size; /* uncompressed size */
- unsigned long offset; /* offset into the final pack file (nonzero if already written) */
+ unsigned long offset; /* offset into the final pack file;
+ * nonzero if already written.
+ */
unsigned int depth; /* delta depth */
+ unsigned int delta_limit; /* base adjustment for in-pack delta */
unsigned int hash; /* name hint hash */
enum object_type type;
- unsigned char edge; /* reused delta chain points at this entry. */
enum object_type in_pack_type; /* could be delta */
unsigned long delta_size; /* delta data size (uncompressed) */
struct object_entry *delta; /* delta base object */
struct packed_git *in_pack; /* already in pack */
unsigned int in_pack_offset;
+ struct object_entry *delta_child; /* delitified objects who bases me */
+ struct object_entry *delta_sibling; /* other deltified objects who
+ * uses the same base as me
+ */
};
/*
@@ -470,7 +476,8 @@ static void check_object(struct object_e
entry->delta = base_entry;
entry->type = OBJ_DELTA;
- base_entry->edge = 1;
+ entry->delta_sibling = base_entry->delta_child;
+ base_entry->delta_child = entry;
return;
}
@@ -513,15 +520,32 @@ static void hash_objects(void)
}
}
+static unsigned int check_delta_limit(struct object_entry *me, unsigned int n)
+{
+ struct object_entry *child = me->delta_child;
+ unsigned int m = n;
+ while (child) {
+ unsigned int c = check_delta_limit(child, n + 1);
+ if (m < c)
+ m = c;
+ child = child->delta_sibling;
+ }
+ return m;
+}
+
static void get_object_details(void)
{
int i;
- struct object_entry *entry = objects;
+ struct object_entry *entry;
hash_objects();
prepare_pack_ix();
- for (i = 0; i < nr_objects; i++)
- check_object(entry++);
+ for (i = 0, entry = objects; i < nr_objects; i++, entry++)
+ check_object(entry);
+ for (i = 0, entry = objects; i < nr_objects; i++, entry++)
+ if (!entry->delta && entry->delta_child)
+ entry->delta_limit =
+ check_delta_limit(entry, 1);
}
typedef int (*entry_sort_t)(const struct object_entry *, const struct object_entry *);
@@ -598,8 +622,11 @@ static int try_delta(struct unpacked *cu
* that depend on the current object into account -- otherwise
* they would become too deep.
*/
- if (cur_entry->edge)
- max_depth /= 4;
+ if (cur_entry->delta_child) {
+ if (max_depth <= cur_entry->delta_limit)
+ return 0;
+ max_depth -= cur_entry->delta_limit;
+ }
size = cur_entry->size;
if (size < 50)
--
1.2.1.g9b132
^ permalink raw reply related
* empty ident error on pull
From: carbonated beverage @ 2006-02-18 7:05 UTC (permalink / raw)
To: git
I'm tracking the Linux kernel repo via git, and got the following:
barbeque/zarathustra:linux-2.6: git pull
Unpacking 885 objects
100% (885/885) done
* refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Auto-following refs/tags/v2.6.16-rc4
Unpacking 1 objects
100% (1/1) done
* refs/tags/v2.6.16-rc4: storing tag 'v2.6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Trying really trivial in-index merge...
Wonderful.
fatal: empty ident <barbeque@zarathustra.internal.psychosnugglebunnies.net.> not allowed
Then I tried the following:
barbeque/zarathustra:linux-2.6: git-fsck-objects
dangling tree 47678b69f7dcc6d5fcae007d1e4fe511fd260e5b
barbeque/zarathustra:linux-2.6: git prune
barbeque/zarathustra:linux-2.6: git-fsck-objects
barbeque/zarathustra:linux-2.6: git pull
* refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Trying really trivial in-index merge...
Wonderful.
fatal: empty ident <barbeque@zarathustra.internal.psychosnugglebunnies.net.> not allowed
Okay... so... what now? I'm still a bit clueless when it comes to git. Using
it for some of my personal projects has gotten me a bit more comfortable with
it, but my usage is still along the lines of "CVS without warts", for now.
(And yes, it's the concept of the index file that's still throwing me for
a loop :-)
I was tracking the repo with "current" versions of git until I got the above
error message the first time. Went to a 1.1.6 tarball of git, pulled the
repro from scratch, all seemed well. Upgraded to 1.2.1, tried a pull today,
and got the above.
The system above is a Debian/sarge amd64 system, using gcc 3.3.5.
-- DN
Daniel
^ permalink raw reply
* Re: git-cvs-import retries
From: Junio C Hamano @ 2006-02-18 7:27 UTC (permalink / raw)
To: Martin Mares; +Cc: git
In-Reply-To: <mj+md-20060217.193146.10308.albireo@ucw.cz>
Martin Mares <mj@ucw.cz> writes:
> Hello!
>...
> This patch extends the retry check and makes the symptoms go away.
> However, take it with a grain of salt as I don't understand yet why the
> connection is aborted.
>
> Have a nice fortnight
> --
> Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
> Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
> A jury consists of 12 persons chosen to decide who has the better lawyer.
>
>
> Signed-Off-By: Martin Mares <mj@ucw.cz>
>
> --- old/git-cvsimport 2006-02-17 13:02:24.000000000 +0100
First, one technicality. You can see what's wrong with the
above, right? Remember, the top part of your message goes into
the commit log, so we do not want "Hello!" nor signature.
> +++ new/git-cvsimport 2006-02-17 18:13:06.000000000 +0100
> @@ -371,7 +371,7 @@
>
> $self->_file($fn,$rev) and $res = $self->_line($fh);
>
> - if (!defined $res) {
> + if (!defined $res || $res eq '') {
> # retry
> $self->conn();
> $self->_file($fn,$rev)
I read _line() three times but its return value is the lexical
variable $res which is initialized to 0 and then either reset to
0 by assignment or updated with $res += somethingelse. So I do
not see how you can get a defined but empty string in there.
Even when _file() returns false, the $res variable in file()
(the function you are modifying) is not initialized, so it would
stay undefined.
Maybe I am missing something very obvious, but I cannot see how
this can make any difference. Please enlighten.
^ permalink raw reply
* Re: Why can't git-rebase back up?
From: Junio C Hamano @ 2006-02-18 7:39 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: linux, git
In-Reply-To: <43F5FA10.5020605@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> The order of precedence works as such:
> .git/<anchor-name>
> .git/refs/<anchor-name>
> .git/refs/tags/<tag-name>
> .git/refs/heads/<branch-name>
> sha1, with git magic to allow abbreviations
>
> This is why you can't sanely have a branch named HEAD.
Actually, you should be able to sanely have a branch named HEAD.
When git barebone Porcelain tools _expect_ branch name from the
user (not just a random committish), they _ought_ to prefix
"refs/heads" in front of it, exactly in order to help
disambiguate things.
Otherwise you have spotted a bug, so please send in a fix.
It is however a different story if you can keep your sanity if
you created a branch called HEAD. You have to remember to
explicitly say refs/heads/HEAD, where a command wants any
committish or treeish.
^ permalink raw reply
* Re: Why can't git-rebase back up?
From: Junio C Hamano @ 2006-02-18 7:39 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060217135938.7412.qmail@science.horizon.com>
linux@horizon.com writes:
> But suppose discover a nasty bug in -rc3 and want to move my build branch
> back to -rc2. "git-rebase v2.6.16-rc2" does nothing. After a bit
> of thought, I realize why, but sometime I do want to back up.
>
> What's the best way to do that? Should git-rebase take an optional
> third argument which is the branch head we are moving away from?
> E.g. what I want to do would be
>
> git-rebase v2.6.16-rc2 build v2.6.16-rc3
The one in "next" has a topic branch change which lets you say:
$ git rebase --onto v2.6.16-rc2 v2.6.16-rc3 build
which is a shorthand for
$ git checkout build
$ git rebase --onto v2.6.16-rc2 v2.6.16-rc3
That is, tear out my changes that forked from the development
trail that led to v2.6.16-rc3, and graft them on top of
v2.6.16-rc2.
^ permalink raw reply
* Re: stGIT: commit vs export vs mail
From: Catalin Marinas @ 2006-02-18 8:30 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: git
In-Reply-To: <Pine.WNT.4.63.0602171802030.2172@jbrandeb-desk.amr.corp.intel.com>
On 18/02/06, Jesse Brandeburg <jesse.brandeburg@intel.com> wrote:
> On Fri, 17 Feb 2006, Catalin Marinas wrote:
> > Jesse Brandeburg wrote:
> >> stg mail <blah blah blah>
> >> or
> >> stg commit
> >
>
> I'm trying to commit changes to a local repository so that the maintainer
> can do a "pull" off of my repository.
All the applied patches in your repository are visible via HEAD. There
is no need to do a commit, unless you want to store them permanently.
The way of using StGIT in contributor mode is to always have the base
of the stack identical to the HEAD of the upstream repository.
I usually just mail the patches but the other way would be to apply
the patches you want to be merged and ask the maintainer to pull from
it. Once the changes were pulled, you could run 'stg pull' on your
repository and StGIT should detect which patches were merged and
whether there are any conflicts (patches modified upstream for
example).
If you want to continue the work on your branch before the maintainer
would pull the changes, you can create a separate "stable" branch for
this. Either use 'stg branch --clone' or simply create it with 'stg
branch --create base' and pick the patches you want merged.
> the stgit command stg commit freezes patches that I've made into my
> repository. I think I get that, but I've been wrong before. Its just
> that I can template the Signed-off-by: line for emails, but when I do a
> stg commit I want the thing to have the Signed-off-by: line in the commit
> text (like above where I added it by hand)
>
> I guess I'll just change my templates to not auto add the Signed-off-by
> line and then things will work okay, as I'll just add the line during stg
> new ...
I got it now. You added Signed-off-by to the mail template. As I said
above, commit should not be used to facilitate the maintainer pulling.
It is already available since the patches are valid GIT commits.
--
Catalin
^ permalink raw reply
* Re: contrib/ area
From: Aneesh Kumar @ 2006-02-18 8:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe15upnl.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]
On 2/18/06, Junio C Hamano <junkio@cox.net> wrote:
> Aneesh Kumar <aneesh.kumar@gmail.com> writes:
>
> > Attaching below the same in the form of patch generated by git format-patch
>
> I'll let it pass this time, but you forgot a sign-off and
> perhaps forgot to read Documentation/SubmittingPatches ;-).
>
>
How about sending the patches as attachment below. I am not sure how
to inline patches in gmail.
-aneesh
[-- Attachment #2: 0001-Fix-a-typo.txt --]
[-- Type: text/plain, Size: 791 bytes --]
>From nobody Mon Sep 17 00:00:00 2001
From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Date: Sat Feb 18 13:54:50 2006 +0530
Subject: Fix a typo
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
3cca8b8cf1840cf7179ffc89ce52fe2c012beaf6
diff --git a/contrib/gitview/gitview.txt b/contrib/gitview/gitview.txt
index 171295a..fcf759c 100644
--- a/contrib/gitview/gitview.txt
+++ b/contrib/gitview/gitview.txt
@@ -32,7 +32,7 @@ EXAMPLES
Show as the changes since version v2.6.12 that changed any file in the include/scsi
or drivers/scsi subdirectories
- gitk --since=2.weeks.ago
+ gitview --since=2.weeks.ago
Show the changes during the last two weeks
--
1.2.1.g45d2-dirty
^ permalink raw reply related
* [RFC] empty ident?
From: Junio C Hamano @ 2006-02-18 8:44 UTC (permalink / raw)
To: git
It appears that some people who did not care about having bogus
names in their own commit messages are bitten by the recent
change to require a sane environment [*1*].
While it was a good idea to prevent people from using bogus
names to create commits and doing sign-offs, the error message
is not very informative. This patch attempts to warn things
upfront and hint people how to fix their environments.
Likes, dislikes, don't cares?
[Footnote]
*1* The thread is this one.
http://marc.theaimsgroup.com/?t=113868084800004
Especially this message.
http://marc.theaimsgroup.com/?m=113932830015032
---
diff --git a/ident.c b/ident.c
index 23b8cfc..09d4d71 100644
--- a/ident.c
+++ b/ident.c
@@ -46,6 +46,15 @@ static void copy_gecos(struct passwd *w,
}
+static const char au_env[] = "GIT_AUTHOR_NAME";
+static const char co_env[] = "GIT_COMMITTER_NAME";
+static const char env_hint[] =
+"\n*** Environment problem:\n"
+"*** Your name cannot be determined from your system services (gecos).\n"
+"*** You would need to set %s and %s\n"
+"*** environment variables; otherwise you won't be able to perform\n"
+"*** certain operations because of \"empty ident\" errors.\n\n";
+
int setup_ident(void)
{
int len;
@@ -57,6 +66,11 @@ int setup_ident(void)
/* Get the name ("gecos") */
copy_gecos(pw, git_default_name, sizeof(git_default_name));
+ if (!*git_default_name) {
+ if (!getenv(au_env) || !getenv(co_env))
+ fprintf(stderr, env_hint, au_env, co_env);
+ }
+
/* Make up a fake email address (name + '@' + hostname [+ '.' + domainname]) */
len = strlen(pw->pw_name);
if (len > sizeof(git_default_email)/2)
^ permalink raw reply related
* Re: Why can't git-rebase back up?
From: linux @ 2006-02-18 8:56 UTC (permalink / raw)
To: junkio, linux; +Cc: git
In-Reply-To: <7vmzgpru8m.fsf@assigned-by-dhcp.cox.net>
> The one in "next" has a topic branch change which lets you say:
>
> $ git rebase --onto v2.6.16-rc2 v2.6.16-rc3 build
>
> which is a shorthand for
>
> $ git checkout build
> $ git rebase --onto v2.6.16-rc2 v2.6.16-rc3
>
> That is, tear out my changes that forked from the development
> trail that led to v2.6.16-rc3, and graft them on top of
> v2.6.16-rc2.
Ah, exactly what I was looking for!
However, why did you decide to make the *destination* the option?
Just giving a naive user's perspective, the argument to git-rebase
is the *destination*, and it "magically" figures out the source.
It would seem more natural to me to have an option to explicltly
specify the "from" and leave the positional argument as the "to".
That also lets you do something about the rebasing-a-merged-branch
problem. If you have:
g-->h-->i-->j topic
/ /
a-->b-->c-->d-->e-->f master
Then I'd expect "git-rebase master topic" to fail with
an error message like:
Error: "topic" and "master" do not have a unique common
ancestor. Possible common ancestors:
b (master~4)
d (master~2)
Rebasing a branch with merges is generally not recommended,
but if you want to do it, you need to specify where to cut
off the branch to move. You probably want one of the above.
And you have to use "git-rebase --from b master" or --from d.
H'm... is that unique? What if you have a bizarre merge pattern
line
k--->l---->m
/ \
| g-->h-->i-->j topic
|/
a-->b-->c-->d-->e-->f master
or
g-->h-->i-->j topic
/ /
a-->b---------->c-->d master
is "--from b" well-defined? I'll have to play with the existing
code to see what it does.
^ permalink raw reply
* Re: contrib/ area
From: Junio C Hamano @ 2006-02-18 9:02 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: git
In-Reply-To: <cc723f590602180038i4186b38axa1cc7e06be385da0@mail.gmail.com>
"Aneesh Kumar" <aneesh.kumar@gmail.com> writes:
> How about sending the patches as attachment below. I am not sure how
> to inline patches in gmail.
For some reason, attachment is usually frowned upon, but if you
cannot do anything else, then at least please do _not_ hide the
commit log message in the attachment.
The short description of the patch should be on the Subject:
line. Make sure it makes sense if your short description
appeared in "git log --pretty=short" output without the rest of
the commit log message. "Fix a typo" is an example of bad
description -- you cannot tell typo in what part of the tree was
fixed by the commit.
And the rest of the log message, including the sign-off,
should be in the main text. Also short administrative message
should come *after* the three-dash separators.
So, I would have done the message I am replying to like this:
*** From: "Aneesh Kumar" <aneesh.kumar@gmail.com>
To: gitster
cc: git@vger.kernel.org
Subject: gitview: typofix in documentation
*** Date: Sat Feb 18 13:54:50 2006 +0530
I forgot to change the name of the program when I copy &
pasted.
Signed-off-by: An Ku <an.ku@g.com>
---
On 2/18/06, Junio C Hamano <junkio@cox.net> wrote:
> Aneesh Kumar <aneesh.kumar@gmail.com> writes:
>
> > Attaching below the same in the form of patch genera...
>
> I'll let it pass this time, but you forgot a sign-off ...
> perhaps forgot to read Documentation/SubmittingPatches...
>
How about sending the patches as attachment below. I am not
sure how to inline patches in gmail.
-aneesh
[git-diff output comes here, preferrably inline but
otherwise as a text/plain attachment.]
Let your MUA fill in *** lines. You _could_ override them with
the first lines of the _body_ of your message like this if you
really need it. Most of the time you shouldn't care.
*** From: "Aneesh Kumar" <aneesh.kumar@gmail.com>
To: gitster
cc: git@vger.kernel.org
Subject: gitview: typofix in documentation
*** Date: Sat Feb 18 13:54:50 2006 +0530
From: "An Ku" <an.ku@gmail.com>
Date: Fri Feb 17 10:00:00 2006 +0530
I forgot to change the name of the program when I copy &
pasted.
Signed-off-by: An Ku <an.ku@g.com>
---
...
^ permalink raw reply
* Re: Why can't git-rebase back up?
From: Junio C Hamano @ 2006-02-18 9:15 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060218085608.30325.qmail@science.horizon.com>
linux@horizon.com writes:
> That also lets you do something about the rebasing-a-merged-branch
> problem. If you have:
>
> g-->h-->i-->j topic
> / /
> a-->b-->c-->d-->e-->f master
Ideally, you should be able to come up with:
g'->h'->j' topic
/
a-->b-->c-->d-->e-->f master
But it should not matter. You should not be merging master (or
any other branches that might have interaction with the topic)
into your topic branches to begin with.
Instead, use a separate test branch and merge both topic and
master into it:
g-->h-->j topic
/ \
/---o---o---o test
/ /
a-->b-->c-->d-->e-->f master
Once your topic is fully cooked, you would merge it into
master. If the area topic and master touch overlaps, you might
have to resolve the same conflict you would have already
resolved when you merged (j) commit into test in the above
picture, but that is why we have "git rerere" ;-).
BTW, why are we suddenly having many nameless people on this
list, I wonder...
^ permalink raw reply
* Re: [RFC] empty ident?
From: Nicolas Vilz 'niv' @ 2006-02-18 10:00 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmkpqco1.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 790 bytes --]
Junio C Hamano wrote:
> It appears that some people who did not care about having bogus
> names in their own commit messages are bitten by the recent
> change to require a sane environment [*1*].
>
> While it was a good idea to prevent people from using bogus
> names to create commits and doing sign-offs, the error message
> is not very informative. This patch attempts to warn things
> upfront and hint people how to fix their environments.
Mh... it made me not using cg-init, but git-init, and after that editing
.git/config, before the first commit.
This doesn't apply to works with git-svn, because here imported commits
are tailored from the base-uuid of the SVN repository and the commit-user.
niv <niv@$uuid>
after that i can setup my .git/config, as well.
Sincerly
Nicolas
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.2.1
From: Andreas Ericsson @ 2006-02-18 10:39 UTC (permalink / raw)
To: Michael Fischer; +Cc: git
In-Reply-To: <20060218043113.GA8976@blinkenlights.visv.net>
Michael Fischer wrote:
> *sigh*
>
> I got confused about git pull origin and git pull master.
>
> Tutorial seems to tell me I should have said git pull origin
> and left well enough alone.
>
> Now I get:
>
> fatal: you need to resolve your current index first
>
> How do I do that?
>
If you just want to clean the index so you can pull from origin again,
you should be able to just do
$ git reset --hard origin
If you've got local changes that has caused conflicts in the index you
need to fix that up first and commit them.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH 1/5] Fixes for ancient versions of GNU make
From: Johannes Schindelin @ 2006-02-18 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wy1upn3.fsf@assigned-by-dhcp.cox.net>
Some versions of GNU make do not understand $(call), and have problems to
interpret rules like this:
some_target: CFLAGS += -Dsome=defs
Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
---
On Fri, 17 Feb 2006, Junio C Hamano wrote:
> I am not opposed to avoiding $(call), but subst everywhere look
> ugly ;-).
Agreed. But I think it is a minor hassle for few, and an
improvement for more.
> You inherited this problem, but these two symbols in different
> Makefiles with the same name mean two completely different
> things, which confused me quite badly.
Fixed. Tested. Works.
Makefile | 69 ++++++++++++++++++++++++++++++++++++++----------------------
t/Makefile | 7 ++----
2 files changed, 46 insertions(+), 30 deletions(-)
165dab0734398530da84da3ae6df37f33293c660
diff --git a/Makefile b/Makefile
index d7d79de..0a978c2 100644
--- a/Makefile
+++ b/Makefile
@@ -203,12 +203,6 @@ LIB_OBJS = \
LIBS = $(LIB_FILE)
LIBS += -lz
-# Shell quote;
-# Result of this needs to be placed inside ''
-shq = $(subst ','\'',$(1))
-# This has surrounding ''
-shellquote = '$(call shq,$(1))'
-
#
# Platform specific tweaks
#
@@ -413,7 +407,22 @@ endif
endif
endif
-ALL_CFLAGS += -DSHA1_HEADER=$(call shellquote,$(SHA1_HEADER)) $(COMPAT_CFLAGS)
+# Shell quote (do not use $(call) to accomodate ancient setups);
+
+SHA1_HEADER_QUOTED = $(subst ','\'',$(SHA1_HEADER))
+template_dir_QUOTED = $(subst ','\'',$(template_dir))
+
+SHELL_PATH_QUOTED = $(subst ','\'',$(SHELL_PATH))
+PERL_PATH_QUOTED = $(subst ','\'',$(PERL_PATH))
+PYTHON_PATH_QUOTED = $(subst ','\'',$(PYTHON_PATH))
+GIT_PYTHON_DIR_QUOTED = $(subst ','\'',$(GIT_PYTHON_DIR))
+
+# prepend DESTDIR to these
+DESTDIR_bindir_QUOTED = $(subst ','\'',$(DESTDIR)$(bindir))
+DESTDIR_gitexecdir_QUOTED = $(subst ','\'',$(DESTDIR)$(gitexecdir))
+DESTDIR_GIT_PYTHON_DIR_QUOTED = $(subst ','\'',$(DESTDIR)$(GIT_PYTHON_DIR))
+
+ALL_CFLAGS += -DSHA1_HEADER='$(SHA1_HEADER_QUOTED)' $(COMPAT_CFLAGS)
LIB_OBJS += $(COMPAT_OBJS)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
@@ -432,7 +441,7 @@ git$X: git.c $(LIB_FILE)
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
rm -f $@
- sed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \
+ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_QUOTED)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
$@.sh >$@
@@ -440,15 +449,15 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.
$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
rm -f $@
- sed -e '1s|#!.*perl|#!$(call shq,$(PERL_PATH))|' \
+ sed -e '1s|#!.*perl|#!$(PERL_PATH_QUOTED)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.perl >$@
chmod +x $@
$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py
rm -f $@
- sed -e '1s|#!.*python|#!$(call shq,$(PYTHON_PATH))|' \
- -e 's|@@GIT_PYTHON_PATH@@|$(call shq,$(GIT_PYTHON_DIR))|g' \
+ sed -e '1s|#!.*python|#!$(PYTHON_PATH_QUOTED)|' \
+ -e 's|@@GIT_PYTHON_PATH@@|$(GIT_PYTHON_DIR_QUOTED)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.py >$@
chmod +x $@
@@ -474,32 +483,42 @@ git$X git.spec \
%.o: %.S
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
-exec_cmd.o: ALL_CFLAGS += -DGIT_EXEC_PATH=\"$(gitexecdir)\"
+exec_cmd.o: exec_cmd.c
+ $(CC) -o $*.o -c $(ALL_CFLAGS) -DGIT_EXEC_PATH=\"$(gitexecdir)\" $<
git-%$X: %.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
-git-mailinfo$X : SIMPLE_LIB += $(LIB_4_ICONV)
$(SIMPLE_PROGRAMS) : $(LIB_FILE)
$(SIMPLE_PROGRAMS) : git-%$X : %.o
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIB_FILE) $(SIMPLE_LIB)
-git-http-fetch$X: fetch.o http.o
-git-http-push$X: http.o
+git-mailinfo$X: mailinfo.o $(LIB_FILE)
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(LIB_FILE) $(SIMPLE_LIB) $(LIB_4_ICONV)
+
git-local-fetch$X: fetch.o
git-ssh-fetch$X: rsh.o fetch.o
git-ssh-upload$X: rsh.o
git-ssh-pull$X: rsh.o fetch.o
git-ssh-push$X: rsh.o
-git-http-fetch$X: LIBS += $(CURL_LIBCURL)
-git-http-push$X: LIBS += $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-git-rev-list$X: LIBS += $(OPENSSL_LIBSSL)
+git-http-fetch$X: fetch.o http.o http-fetch.o
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(LIBS) $(CURL_LIBCURL)
+
+git-http-push$X: http.o http-push.o
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
+
+git-rev-list$X: rev-list.o
+ $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+ $(LIBS) $(OPENSSL_LIBSSL)
init-db.o: init-db.c
$(CC) -c $(ALL_CFLAGS) \
- -DDEFAULT_GIT_TEMPLATE_DIR=$(call shellquote,"$(template_dir)") $*.c
+ -DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_QUOTED)"' $*.c
$(LIB_OBJS): $(LIB_H)
$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H)
@@ -531,13 +550,13 @@ check:
### Installation rules
install: all
- $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
- $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(gitexecdir))
- $(INSTALL) $(ALL_PROGRAMS) $(call shellquote,$(DESTDIR)$(gitexecdir))
- $(INSTALL) git$X gitk $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) -d -m755 '$(DESTDIR_bindir_QUOTED)'
+ $(INSTALL) -d -m755 '$(DESTDIR_gitexecdir_QUOTED)'
+ $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_gitexecdir_QUOTED)'
+ $(INSTALL) git$X gitk $(DESTDIR_bindir_QUOTED)'
$(MAKE) -C templates install
- $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
- $(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
+ $(INSTALL) -d -m755 '$(DESTDIR_GIT_PYTHON_DIR_QUOTED)'
+ $(INSTALL) $(PYMODULES) '$(DESTDIR_GIT_PYTHON_DIR_QUOTED)'
install-doc:
$(MAKE) -C Documentation install
diff --git a/t/Makefile b/t/Makefile
index 5c5a620..e7e4229 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -8,17 +8,14 @@ SHELL_PATH ?= $(SHELL)
TAR ?= $(TAR)
# Shell quote;
-# Result of this needs to be placed inside ''
-shq = $(subst ','\'',$(1))
-# This has surrounding ''
-shellquote = '$(call shq,$(1))'
+SHELL_PATH_QUOTED = $(subst ','\'',$(SHELL_PATH))
T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
all: $(T) clean
$(T):
- @echo "*** $@ ***"; $(call shellquote,$(SHELL_PATH)) $@ $(GIT_TEST_OPTS)
+ @echo "*** $@ ***"; '$(SHELL_PATH_QUOTED)' $@ $(GIT_TEST_OPTS)
clean:
rm -fr trash
--
1.2.1.geb73
^ permalink raw reply related
* [PATCH] archimport: remove files from the index before adding/updating
From: Eric Wong @ 2006-02-18 11:49 UTC (permalink / raw)
To: git, junkio
In-Reply-To: <11402390872301-git-send-email-normalperson@yhbt.net>
This fixes a bug when importing where a directory gets removed/renamed
but is immediately replaced by a file of the same name in the same
changeset.
This fix only applies to the accurate (default) strategy the moment.
This patch should also fix the fast strategy if/when it is updated
to handle the cases that would've triggered this bug.
This bug was originally found in git-svn, but I remembered I did the
same thing with archimport as well.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-archimport.perl | 28 +++++++++++++---------------
1 files changed, 13 insertions(+), 15 deletions(-)
011fe464212c52d46ad5b797eb1d8f86c1d77916
diff --git a/git-archimport.perl b/git-archimport.perl
index 841738d..6792624 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -346,12 +346,10 @@ sub process_patchset_accurate {
}
# update the index with all the changes we got
+ system('git-diff-files --name-only -z | '.
+ 'git-update-index --remove -z --stdin') == 0 or die "$! $?\n";
system('git-ls-files --others -z | '.
'git-update-index --add -z --stdin') == 0 or die "$! $?\n";
- system('git-ls-files --deleted -z | '.
- 'git-update-index --remove -z --stdin') == 0 or die "$! $?\n";
- system('git-ls-files -z | '.
- 'git-update-index -z --stdin') == 0 or die "$! $?\n";
return 1;
}
@@ -416,22 +414,14 @@ sub process_patchset_fast {
# imports don't give us good info
# on added files. Shame on them
if ($ps->{type} eq 'i' || $ps->{type} eq 't') {
- system('git-ls-files --others -z | '.
- 'git-update-index --add -z --stdin') == 0 or die "$! $?\n";
system('git-ls-files --deleted -z | '.
'git-update-index --remove -z --stdin') == 0 or die "$! $?\n";
+ system('git-ls-files --others -z | '.
+ 'git-update-index --add -z --stdin') == 0 or die "$! $?\n";
}
# TODO: handle removed_directories and renamed_directories:
-
- if (my $add = $ps->{new_files}) {
- while (@$add) {
- my @slice = splice(@$add, 0, 100);
- system('git-update-index','--add','--',@slice) == 0 or
- die "Error in git-update-index --add: $! $?\n";
- }
- }
-
+
if (my $del = $ps->{removed_files}) {
unlink @$del;
while (@$del) {
@@ -462,6 +452,14 @@ sub process_patchset_fast {
}
}
+ if (my $add = $ps->{new_files}) {
+ while (@$add) {
+ my @slice = splice(@$add, 0, 100);
+ system('git-update-index','--add','--',@slice) == 0 or
+ die "Error in git-update-index --add: $! $?\n";
+ }
+ }
+
if (my $mod = $ps->{modified_files}) {
while (@$mod) {
my @slice = splice(@$mod, 0, 100);
--
1.2.1.gffaf
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox