* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Junio C Hamano @ 2006-01-07 0:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randal L. Schwartz, Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0601061525100.3169@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> After all, that's spelled "f o r", but pronounced "foreach". :)
>
> It is official: perl people are crazy.
I sometimes pronounce "foreach" when I see "ef oh ar" in Perl
programs, but I do not do that aloud around other people.
My point was that things like this:
>> print H "$_\0" for @deletedfiles;
is perfectly fine among Perl people (and I would probably even
encourage rewriting git-*.perl scripts in more Perlish style if
the project were about an SCM primarily targetted for Perl
people --- it is not), but look obfuscated without merit to
people who do not talk Perl.
^ permalink raw reply
* Re: [PATCH] rpmbuild doesn't like '-' in version strings
From: Johannes Schindelin @ 2006-01-07 0:47 UTC (permalink / raw)
To: git
In-Reply-To: <43BF05A3.8060407@op5.se>
Hi,
we still could go back to \d.\d.\d.GIT, you know?
Using the output of git-describe only helps if you use git from the
official repository. But when you have a private branch, they are only
misleading. And if you use git from the official repository, you are more
likely to take official versions anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rpmbuild doesn't like '-' in version strings
From: Ryan Anderson @ 2006-01-07 1:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Ellson, git, Linus Torvalds
In-Reply-To: <7voe2prniw.fsf@assigned-by-dhcp.cox.net>
On Fri, Jan 06, 2006 at 02:37:27PM -0800, Junio C Hamano wrote:
>
> Since I do not understand what that "g"
> stands for anyway, how about doing something like this instead?
I'm pretty sure the "g" is my fault, indirectly. When I submitted the
"AUTO_LOCALVERSION" patch to Linux, I prepended a -g to it, so it would
be possible to tell versions based off of a git tree apart from versions
based off of a CVS tree that used md5 to make a short, semi-unique
indicator. Presumably, a CVS variant would've done something like
-c012345678, etc.
So, it's just a little mnemonic to hint that the extra version string
came from a git tree, as opposed to some other semi-random source. It's
value is rather dubious, overall, though.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: trivial: retval of waitpid is not errno
From: Junio C Hamano @ 2006-01-07 2:27 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0601050056p3b51ff7bt5c75802f6ba07092@mail.gmail.com>
Thanks for all the trivial series. Most of them applied as they
are, others I have already sent out comments.
^ permalink raw reply
* Re: git format-patch shell quoting bug
From: Junio C Hamano @ 2006-01-07 2:38 UTC (permalink / raw)
To: Kyle McMartin; +Cc: git
In-Reply-To: <20060104045519.GB29515@quicksilver.road.mcmartin.ca>
Kyle McMartin <kyle@mcmartin.ca> writes:
> There's apparently a quoting bug in git-format-patch. When I import
> a patch with apply-mbox, for example
>
> From: Carlos O'Donell <carlos@parisc-linux.org>
>
> The author field is correctly set, including the "'" in Carlos' name.
> ...
> I believe this recently crept in, as I don't recall seeing it before.
Thanks for spotting this.
There was a similar problem with "git-commit -c". I think I got
both of them right with commit aa66c7:
commit aa66c7ec77d474b737da607d6cb2d07f56628def
Author: Junio C Hamano <junkio@cox.net>
Date: Thu Jan 5 19:50:37 2006 -0800
format-patch/commit: Quote single quote in the author name properly.
Noticed by Kyle McMartin.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The bug was present ever since format-patch started picking up
the original authorship information from the commits, done on
July 22nd last year, between v0.99.1 and v0.99.2.
^ permalink raw reply
* [ANNOUNCE] GIT 1.0.7
From: Junio C Hamano @ 2006-01-07 7:01 UTC (permalink / raw)
To: git; +Cc: linux-kernel
GIT 1.0.7 is available at http://www.kernel.org/pub/software/scm/git/
Just bunch of cleanups, documentation formatting and spelling
fixes, among them notable are:
- git-format-patch and git-commit now handles author names with
' (ASCII 0x27, single quote) character in them properly.
- approxidate parser does not get confused when we say "10 days
ago" immediately after new year.
The master branch has accumulated enough enhancements, and I
plan to do GIT 1.1.0 (and start 1.1.X maintenance series) over
the weekend. What will be there are listed here, but those who
have been running the "master" branch must be familiar with most
of them.
Johannes Schindelin:
git-clone: Support changing the origin branch with -o
Introduce core.sharedrepository
git-init-db: initialize shared repositories with --shared
John Ellson:
Make GIT-VERSION-GEN tolerate missing git describe command
Junio C Hamano:
Versioning scheme changes.
merge-recursive: conflicting rename case.
whatchanged: customize diff-tree output
rev-parse: --show-cdup
check_packed_git_idx(): check integrity of the idx file itself.
checkout: sometimes work from a subdirectory.
ls-tree: chomp leading directories when run from a subdirectory
git-clone: do not special case dumb http.
Tutorial: mention shared repository management.
git-describe: really prefer tags only.
git-describe: use find_unique_abbrev()
git-describe: --tags and --abbrev
git-describe: still prefer annotated tag under --all and --tags
git-describe: documentation.
Makefile: use git-describe to mark the git version.
send-pack/receive-pack: allow errors to be reported back to pusher.
Linus Torvalds:
Add a "git-describe" command
Lukas Sandstrom:
git-pack-redundant: speed and memory usage improvements
YOSHIFUJI Hideaki:
GIT: Support [address] in URLs
^ permalink raw reply
* Re: [PATCH] Teach cvsexportcommit to add new files
From: Martin Langhoff @ 2006-01-07 7:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yann Dirson, git, Martin Langhoff
In-Reply-To: <7virsxrnik.fsf@assigned-by-dhcp.cox.net>
On 1/7/06, Junio C Hamano <junkio@cox.net> wrote:
> Yann Dirson <ydirson@altern.org> writes:
>
> > Teach cvsexportcommit to add new files
> > "cvs add" support was already there, but the "unknown" status
> > returned when querying a file not yet known to cvs caused the
> > script to abort prematurely.
>
> Thanks. I'll take the patch as is, but I noticed that the
> cvsexportcommit still has some room for polishing.
Definitely. It's a bit of a hack job that I got started with, and as
it's /worked for me/ so far, haven't done much with it. I am actually
quite busy at the moment, so I don't think you'll see many patches
from me on this fron yet...
(BTW: I'm hoping to find a bit of time to code the git-cvsdaemon that
I've mentioned before, which would be a hell of an interesting
addition, methinks.)
> * The command is to be run from CVS working copy (as desribed
> in the documentation) and seems to assume that the parent
> commit is checked out at least for the paths involved between
> the commit and the parent (not clearly documented).
Indeed, and you can also use it for the same thing you'd use git-am --
for instance, to "merge into CVS" feature branches kept on GIT.
> * I wonder if it is safe with filenames with embedded SP?
It's not -- shame on me. Backticks should be replaced with
safe_pipe_capture() as Eric's done on git-archimport.
> * I think this grep '^Binary' is unsafe; different versions of
> gnu diff say just "Files differ".
Unsure how to detect binary files safely. Is there a way to ask git
whether it considers the files to be binary?
(snipped several good suggestions here...)
> I am getting an impression that _if_ we care about applying
> fuzzy patch like this, giving fuzz feature to git-apply would
> help this program somewhat, but at the same time I do not think
> of a good reason to even accept nonexact patch when synching two
> SCM histories.
Well, with some fuzz you can use this to merge something into CVS even
if the trunk or branch you're merging into has moved forward a bit.
OTOH, I guess you can go back to git and do a git-rebase if needed.
cheers,
martin
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.7
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-01-07 8:16 UTC (permalink / raw)
To: junkio; +Cc: git, yoshfuji
In-Reply-To: <7vhd8go71t.fsf@assigned-by-dhcp.cox.net>
In article <7vhd8go71t.fsf@assigned-by-dhcp.cox.net> (at Fri, 06 Jan 2006 23:01:34 -0800), Junio C Hamano <junkio@cox.net> says:
> GIT 1.0.7 is available at http://www.kernel.org/pub/software/scm/git/
Allow compilation w/ gcc 2.95.4.
(Or, it is okay to replace path[] with path[0].)
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
diff --git a/describe.c b/describe.c
index 84d96b5..3688c4a 100644
--- a/describe.c
+++ b/describe.c
@@ -17,8 +17,8 @@ static int abbrev = DEFAULT_ABBREV;
static int names = 0, allocs = 0;
static struct commit_name {
const struct commit *commit;
+ char *path;
int prio; /* annotated tag = 2, tag = 1, head = 0 */
- char path[];
} **name_array = NULL;
static struct commit_name *match(struct commit *cmit)
@@ -43,6 +43,7 @@ static void add_to_known_names(const cha
struct commit_name *name = xmalloc(sizeof(struct commit_name) + len);
name->commit = commit;
+ name->path = sizeof(*name);
name->prio = prio;
memcpy(name->path, path, len);
idx = names;
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.0.7
From: David S. Miller @ 2006-01-07 8:29 UTC (permalink / raw)
To: yoshfuji; +Cc: junkio, git
In-Reply-To: <20060107.021614.94523887.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sat, 07 Jan 2006 02:16:14 -0600 (CST)
> @@ -43,6 +43,7 @@ static void add_to_known_names(const cha
> struct commit_name *name = xmalloc(sizeof(struct commit_name) + len);
>
> name->commit = commit;
> + name->path = sizeof(*name);
> name->prio = prio;
> memcpy(name->path, path, len);
> idx = names;
Why are you assigning an integer to a pointer? :-)
Probably you meant something like:
struct commit_name *name = xmalloc(sizeof(struct commit_name) + len);
...
name->path = xmalloc(len);
...
^ permalink raw reply
* needs merge
From: Len Brown @ 2006-01-07 8:32 UTC (permalink / raw)
To: git
a merge results in multiple conflict files.
some of the files are resolved by editing and picking changes from both branches.
but some files I want to ignore the new changes and keep what was originally there.
However, if I restore what was originally in the destination
either by editing the destination and ending up with what i started with,
or via git checkout on the file, i get
$ git commit
my-file needs merge
how do i tell git that there is no merge to do and the (unchanged) working file is what
i want to keep as the result of the merge?
i recall running into this a long time ago and i added blank line to the destination file
and that made git happy, but maybe i shouldn't have to resort to that, yes?
thanks,
-Len
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.7
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-01-07 8:33 UTC (permalink / raw)
To: davem; +Cc: junkio, git
In-Reply-To: <20060107.002904.87767885.davem@davemloft.net>
In article <20060107.002904.87767885.davem@davemloft.net> (at Sat, 07 Jan 2006 00:29:04 -0800 (PST)), "David S. Miller" <davem@davemloft.net> says:
> > name->commit = commit;
> > + name->path = sizeof(*name);
> > name->prio = prio;
> Why are you assigning an integer to a pointer? :-)
> Probably you meant something like:
>
> struct commit_name *name = xmalloc(sizeof(struct commit_name) + len);
>
> ...
> name->path = xmalloc(len);
> ...
oops.... you're right...
--yoshfuji @ about to fly
^ permalink raw reply
* Re: needs merge
From: Junio C Hamano @ 2006-01-07 8:41 UTC (permalink / raw)
To: Len Brown; +Cc: git
In-Reply-To: <200601070332.36654.len.brown@intel.com>
Len Brown <len.brown@intel.com> writes:
> $ git commit
> my-file needs merge
>
> how do i tell git that there is no merge to do and the (unchanged) working file is what
> i want to keep as the result of the merge?
Do you mean running
$ git update-index my-file
to mark the path resolved?
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.7
From: Junio C Hamano @ 2006-01-07 8:43 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: git
In-Reply-To: <20060107.021614.94523887.yoshfuji@linux-ipv6.org>
[Yoshifuji-san, you will see this message twice but everybody
else would not --- I removed your Japanese name from the body of
the message, to pass mail filter at kernel.org]
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> writes:
> Allow compilation w/ gcc 2.95.4.
> (Or, it is okay to replace path[] with path[0].)
This is unfortunate; path[] is the correct C (and path[0] is
not---it is an gcc extension), and we have quite a few of them.
Last time somebody wanted to change all of them to path[] we
found out gcc 2.95 did not like it, and ended up doing path[0]
form. So I'd say change it to path[0] for now.
^ permalink raw reply
* Re: needs merge
From: Len Brown @ 2006-01-07 8:57 UTC (permalink / raw)
To: git
In-Reply-To: <200601070332.36654.len.brown@intel.com>
> git-update-index my-file
yes, that allowed the git commit to complete, thanks.
however, when i then merged that branch into another there seem to
be some phantom conflicts on the very same files.
Do I understand all this output to mean that git attempted two
different merges, and discarded the 1st attempt in favor of the second?
thanks,
-Len
$ /lab/bin/git.merge acpica test
Merging test with ed03f430cdc8c802652467e9097606fedc2c7abc
Merging:
e3627f3165301a7d946c2dc40be93f744f441c30 Auto-update from upstream
ed03f430cdc8c802652467e9097606fedc2c7abc Pull pnpacpi into acpica branch
found 2 common ancestor(s):
0aec63e67c69545ca757a73a66f5dcf05fa484bf [PATCH] Fix posix-cpu-timers sched_time accumulation
ed349a8a0a780ed27e2a765f16cee54d9b63bfee [ACPI] fix pnpacpi regression resulting from ACPICA 20051117
Merging:
0aec63e67c69545ca757a73a66f5dcf05fa484bf [PATCH] Fix posix-cpu-timers sched_time accumulation
ed349a8a0a780ed27e2a765f16cee54d9b63bfee [ACPI] fix pnpacpi regression resulting from ACPICA 20051117
found 1 common ancestor(s):
927fe18397b3b1194a5b26b1d388d97e391e5fd2 Pull 5165 into release branch
Auto-merging arch/i386/kernel/mpparse.c
Auto-merging include/asm-x86_64/mpspec.h
Auto-merging arch/ia64/pci/pci.c
Auto-merging drivers/acpi/utilities/utmisc.c
CONFLICT (content): Merge conflict in drivers/acpi/utilities/utmisc.c
Auto-merging include/acpi/acglobal.h
CONFLICT (content): Merge conflict in include/acpi/acglobal.h
Auto-merging drivers/acpi/scan.c
Auto-merging drivers/acpi/pci_link.c
Merge bfaa3a0777f0fc3b82831cb1daf286f8ac3b4c8d, made by recursive.
drivers/pnp/pnpacpi/rsparser.c | 48 +++++++++++++++++++++++++++++++++++++---
1 files changed, 44 insertions(+), 4 deletions(-)
$
^ permalink raw reply
* cvsexportcommit / cvsimport issues
From: Yann Dirson @ 2006-01-07 9:01 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git, matthias
In-Reply-To: <46a038f90601062329s35163616i7c658e4d6ede294b@mail.gmail.com>
On Sat, Jan 07, 2006 at 08:29:08PM +1300, Martin Langhoff wrote:
> Definitely. It's a bit of a hack job that I got started with, and as
> it's /worked for me/ so far, haven't done much with it. I am actually
> quite busy at the moment, so I don't think you'll see many patches
> from me on this fron yet...
In any case, I'm likely to send occasional patches as I hit the
limitations.
> Indeed, and you can also use it for the same thing you'd use git-am --
> for instance, to "merge into CVS" feature branches kept on GIT.
That's also the way I use it. We have an official CVS repo, and I'm
doing all of my work in git, until it's ready for publication in the
central CVS repo.
While we're talking about cvs<->git, I also hit a couple of problems
with git-cvsimport, which I did not have time to fully investigate:
- when there are very large files in the CVS repo (eg. a 85MB
tarball), cvsimport timeouts while fetching it (saying the server has
gone away), when accesing via pserver or ssh. I tried to play with
the socket timeout, but also it helped to reproducibly import a 15MB
file, I could not raise it enough to get the 85MB file.
Hunting for this problem, I found myself asking the question, why it
was chosen in the first place to implement a cvs client, instead of
using the reference implementation.
I was finally able to workaround this by transfering a copy of the
cvsroot to the local machine, but that's not quite practical :)
- the "-k" flag is dangerous as-is, since it overrides any flag
(eg. -kb) set on the files in the cvs repo. I got a plain
(non-compressed) tarball of sources corrupted because of this, and was
subsequently unable to use -k at all. Fortunately, I had done the
original cvs imports using -ko, so it was not a problem for me, but we
may want to fix the issue eventually, and at least document this
caveat.
- when doing an incremental import using -P, where the 1st patchset
was just a module creation with a single .cvsignore to allow creation
of a pseudo-vendor-branch, and the 2nd patchset was an import on the
said branch, cvsimport complained that it could not find the branch in
my git repo, and I had to create it manually, whereas while importing
all patchsets in one batch, the branch was created without manual
intervention (but import subsequently failed because of the big file
as mentionned above). Similarly, still when using -P, using the local
repository copy, importing the initial patchset complained 'cannot
find "origin"' - I prefered to do this initial import using the
pserver access, which worked fine, and did the later imports via the
local repo.
We could thus want to mention in the doc that -P can also be used to
help circumvent problems by using for each patchset the most adequate
import method :)
- as of cvsps 2.1, patchsets only contain a single tag, even when
there are several of them on the cvs repo. We should surely document
this shortcoming so people do not get caught by surprise.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Use testlib to skip t3300-funny-names
From: Alex Riesen @ 2006-01-07 9:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvewxq8xg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Fri, Jan 06, 2006 23:38:03 +0100:
> > The test cannot be run on cygwin anyway.
> > Corrected the error message to reflect the problem source.
>
> I'd rather see the test actually try to create a funny-named
> testfile and see if it managed to create it, so that it can be
> skipped on non DOS systems that mounted DOS filesystem.
>
> So instead I would do something like this:
>
> +test -f "$p1" && cmp "$p0" "$p1" || {
> + # since FAT/NTFS does not allow tabs in filenames, skip this test
> + say 'Your filesystem does not allow tabs in filenames, test skipped.'
> + test_done
> +}
Yes, that's better
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.7
From: Junio C Hamano @ 2006-01-07 9:56 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: git
In-Reply-To: <7vsls0mns8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> writes:
>
>> Allow compilation w/ gcc 2.95.4.
>> (Or, it is okay to replace path[] with path[0].)
>
> This is unfortunate; path[] is the correct C (and path[0] is
> not---it is an gcc extension), and we have quite a few of them.
> Last time somebody wanted to change all of them to path[] we
> found out gcc 2.95 did not like it, and ended up doing path[0]
> form. So I'd say change it to path[0] for now.
Here is what I am planning to merge into the master/maint. The
patch is for maint which does not ship with describe, but the
problematic path[] can be updated to path[FLEX_ARRAY] as others
when merging it to the master branch.
-- >8 --
Subject: [PATCH] Compilation: zero-length array declaration.
ISO C99 (and GCC 3.x or later) lets you write a flexible array
at the end of a structure, like this:
struct frotz {
int xyzzy;
char nitfol[]; /* more */
};
GCC 2.95 lets you to do this with "char nitfol[0]";
unfortunately this is not allowed by ISO C90.
This declares such construct like this:
struct frotz {
int xyzzy;
char nitfol[FLEX_ARRAY]; /* more */
};
and git-compat-util.h defines FLEX_ARRAY to 0 for gcc 2.95 and
empty for others.
Although I have not tried this myself, if you are using a C90 C
compiler, you should be able to override this with
CFLAGS=-DFLEX_ARRAY=1 from the command line of "make".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
blob.c | 2 +-
cache.h | 9 +++++----
commit.c | 2 +-
git-compat-util.h | 8 ++++++++
ls-files.c | 2 +-
object.c | 2 +-
object.h | 2 +-
receive-pack.c | 2 +-
tag.c | 2 +-
tree.c | 2 +-
10 files changed, 21 insertions(+), 12 deletions(-)
33751f1c4e23e928f18a019292cb8562cd7c7f76
diff --git a/blob.c b/blob.c
index ea52ad5..84ec121 100644
--- a/blob.c
+++ b/blob.c
@@ -1,5 +1,5 @@
-#include "blob.h"
#include "cache.h"
+#include "blob.h"
#include <stdlib.h>
const char *blob_type = "blob";
diff --git a/cache.h b/cache.h
index cb87bec..5fd2687 100644
--- a/cache.h
+++ b/cache.h
@@ -81,7 +81,7 @@ struct cache_entry {
unsigned int ce_size;
unsigned char sha1[20];
unsigned short ce_flags;
- char name[0];
+ char name[FLEX_ARRAY]; /* more */
};
#define CE_NAMEMASK (0x0fff)
@@ -257,7 +257,7 @@ extern int checkout_entry(struct cache_e
extern struct alternate_object_database {
struct alternate_object_database *next;
char *name;
- char base[0]; /* more */
+ char base[FLEX_ARRAY]; /* more */
} *alt_odb_list;
extern void prepare_alt_odb(void);
@@ -271,7 +271,8 @@ extern struct packed_git {
unsigned int pack_use_cnt;
int pack_local;
unsigned char sha1[20];
- char pack_name[0]; /* something like ".git/objects/pack/xxxxx.pack" */
+ /* something like ".git/objects/pack/xxxxx.pack" */
+ char pack_name[FLEX_ARRAY]; /* more */
} *packed_git;
struct pack_entry {
@@ -286,7 +287,7 @@ struct ref {
unsigned char new_sha1[20];
unsigned char force;
struct ref *peer_ref; /* when renaming */
- char name[0];
+ char name[FLEX_ARRAY]; /* more */
};
extern int git_connect(int fd[2], char *url, const char *prog);
diff --git a/commit.c b/commit.c
index edd4ded..fb02ba6 100644
--- a/commit.c
+++ b/commit.c
@@ -1,6 +1,6 @@
+#include "cache.h"
#include "tag.h"
#include "commit.h"
-#include "cache.h"
int save_commit_buffer = 1;
diff --git a/git-compat-util.h b/git-compat-util.h
index c353b27..1a263a6 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -1,6 +1,14 @@
#ifndef GIT_COMPAT_UTIL_H
#define GIT_COMPAT_UTIL_H
+#ifndef FLEX_ARRAY
+#if (__GNUC__ == 2) && (__GNUC_MINOR__ == 95)
+#define FLEX_ARRAY 0
+#else
+#define FLEX_ARRAY /* empty */
+#endif
+#endif
+
#include <unistd.h>
#include <stdio.h>
#include <sys/stat.h>
diff --git a/ls-files.c b/ls-files.c
index cd87430..74ec8c0 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -208,7 +208,7 @@ static int excluded(const char *pathname
struct nond_on_fs {
int len;
- char name[0];
+ char name[FLEX_ARRAY]; /* more */
};
static struct nond_on_fs **dir;
diff --git a/object.c b/object.c
index cf5931a..1577f74 100644
--- a/object.c
+++ b/object.c
@@ -1,8 +1,8 @@
+#include "cache.h"
#include "object.h"
#include "blob.h"
#include "tree.h"
#include "commit.h"
-#include "cache.h"
#include "tag.h"
struct object **objs;
diff --git a/object.h b/object.h
index 336d986..0e76182 100644
--- a/object.h
+++ b/object.h
@@ -9,7 +9,7 @@ struct object_list {
struct object_refs {
unsigned count;
- struct object *ref[0];
+ struct object *ref[FLEX_ARRAY]; /* more */
};
struct object {
diff --git a/receive-pack.c b/receive-pack.c
index 92878ec..ce986fe 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -24,7 +24,7 @@ struct command {
unsigned char updated;
unsigned char old_sha1[20];
unsigned char new_sha1[20];
- char ref_name[0];
+ char ref_name[FLEX_ARRAY]; /* more */
};
static struct command *commands = NULL;
diff --git a/tag.c b/tag.c
index 61ac434..ac0e573 100644
--- a/tag.c
+++ b/tag.c
@@ -1,5 +1,5 @@
-#include "tag.h"
#include "cache.h"
+#include "tag.h"
const char *tag_type = "tag";
diff --git a/tree.c b/tree.c
index e7a7b71..dc1c41e 100644
--- a/tree.c
+++ b/tree.c
@@ -1,8 +1,8 @@
+#include "cache.h"
#include "tree.h"
#include "blob.h"
#include "commit.h"
#include "tag.h"
-#include "cache.h"
#include <stdlib.h>
const char *tree_type = "tree";
--
1.0.7-g0263
^ permalink raw reply related
* Re: needs merge
From: Junio C Hamano @ 2006-01-07 10:28 UTC (permalink / raw)
To: Len Brown; +Cc: git
In-Reply-To: <200601070357.13954.len.brown@intel.com>
Len Brown <len.brown@intel.com> writes:
> however, when i then merged that branch into another there seem to
> be some phantom conflicts on the very same files.
First of all, does the final merge result look correct, without
conflict markers? I've slurped from your tree and tried the
merge myself and it seems that both branches and the merge
result of these branches have the conflicting path the same way,
so I think it did the right thing for you, but I am just trying
to make sure.
> Do I understand all this output to mean that git attempted two
> different merges, and discarded the 1st attempt in favor of the second?
Not really. This is Fredrik's "recursive" merge in action.
acpica (ed03f4) is merged into test (e3627f), but these two
branches have criss-cross merge history and there are two
equally valid common ancestors, 0aec63 and ed349a.
What it did was first to find a merge between these two common
ancestors, during which it found conflicting merge on those
paths.
It then used this merge result (with conflict markers still in
them!) as the "virtual common ancestor" to merge the ed03f4 and
e3627f commits; because both branches have resolved the
conflicting part the same way earlier, this three-way merge
cancels out the part that are marked with conflict markers in
the virtual common ancestor (this is the cutest part of Fredrik
merge algorithm).
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Alex Riesen @ 2006-01-07 10:28 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
In-Reply-To: <86wthd7ypx.fsf@blue.stonehenge.com>
Randal L. Schwartz, Fri, Jan 06, 2006 23:55:54 +0100:
> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
> Junio> So I'd prefer not touching for (@df) { print H "$_\n" } loops.
>
> Being as I'm a *bit* familiar with Perl, I'd write that as:
>
> print H "$_\0" for @deletedfiles;
>
Does not work for old Perl
^ permalink raw reply
* Re: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Junio C Hamano @ 2006-01-07 10:29 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060107102820.GB5536@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Randal L. Schwartz, Fri, Jan 06, 2006 23:55:54 +0100:
>>
>> print H "$_\0" for @deletedfiles;
>
> Does not work for old Perl
How old may I ask?
^ permalink raw reply
* Re: trivial: remove the dots at the end of file names
From: Alex Riesen @ 2006-01-07 10:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0chrniz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Fri, Jan 06, 2006 23:37:24 +0100:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > Subject: [PATCH] Remove the dots at the end of file names
> > to make the output more mouse copy-paste friendly.
>
> > - echo "ERROR: Merge conflict in $4."
> > + echo "ERROR: Merge conflict in $4"
>
> Hmph. I think there are places we state pathname within 'single
> quotes' as a part of sentence, which may have the same issue.
No-no-no! These are perfectly fine (for bash, at least)!
> I understand and am sympathetic to the motivation, but at the same
> time messages that do not end with full-stop somehow make me feel
> quite uneasy. I'll swallow the patch; maybe it is just me.
I hope so. Don't you ever use mouse copy-pasting?!
^ permalink raw reply
* RE: needs merge
From: Brown, Len @ 2006-01-07 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
yes, it did the right thing to the source.
as a user, "cute" isn't the first word that comes to mind:-)
thanks,
-Len
>-----Original Message-----
>From: git-owner@vger.kernel.org
>[mailto:git-owner@vger.kernel.org] On Behalf Of Junio C Hamano
>Sent: Saturday, January 07, 2006 5:29 AM
>To: Brown, Len
>Cc: git@vger.kernel.org
>Subject: Re: needs merge
>
>Len Brown <len.brown@intel.com> writes:
>
>> however, when i then merged that branch into another there seem to
>> be some phantom conflicts on the very same files.
>
>First of all, does the final merge result look correct, without
>conflict markers? I've slurped from your tree and tried the
>merge myself and it seems that both branches and the merge
>result of these branches have the conflicting path the same way,
>so I think it did the right thing for you, but I am just trying
>to make sure.
>
>> Do I understand all this output to mean that git attempted two
>> different merges, and discarded the 1st attempt in favor of
>the second?
>
>Not really. This is Fredrik's "recursive" merge in action.
>
>acpica (ed03f4) is merged into test (e3627f), but these two
>branches have criss-cross merge history and there are two
>equally valid common ancestors, 0aec63 and ed349a.
>
>What it did was first to find a merge between these two common
>ancestors, during which it found conflicting merge on those
>paths.
>
>It then used this merge result (with conflict markers still in
>them!) as the "virtual common ancestor" to merge the ed03f4 and
>e3627f commits; because both branches have resolved the
>conflicting part the same way earlier, this three-way merge
>cancels out the part that are marked with conflict markers in
>the virtual common ancestor (this is the cutest part of Fredrik
>merge algorithm).
>
>-
>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: [PATCH] git-mv.perl: use stderr for error output and cleanup
From: Randal L. Schwartz @ 2006-01-07 10:34 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20060107102820.GB5536@steel.home>
>>>>> "Alex" == Alex Riesen <raa.lkml@gmail.com> writes:
Alex> Randal L. Schwartz, Fri, Jan 06, 2006 23:55:54 +0100:
>> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>>
Junio> So I'd prefer not touching for (@df) { print H "$_\n" } loops.
>>
>> Being as I'm a *bit* familiar with Perl, I'd write that as:
>>
>> print H "$_\0" for @deletedfiles;
>>
Alex> Does not work for old Perl
Correct. It was added for Perl 5.5, first released on 22 July 1998.
Are you really saying you need this code to run on Perl 5.4? There
are a number of other things that would have to be fixed as well.
(We had this conversation a while back.)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [PATCH] git-fetch: auto-following tags.
From: Junio C Hamano @ 2006-01-07 10:34 UTC (permalink / raw)
To: git
I added things to ls-remote so that Cogito can auto-follow tags
easily and correctly a while ago, but git-fetch did not use the
facility. Recently added git-describe command relies on
repository keeping up-to-date set of tags, which made it much
more attractive to automatically follow tags, so we do that as
well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is not 1.0.X material rather for 1.1.0
Documentation/fetch-options.txt | 18 ++
git-fetch.sh | 283 ++++++++++++++++++++++-----------------
2 files changed, 173 insertions(+), 128 deletions(-)
6f3ccd3bdb2e2b2187c93bfa0c6f957b44a2e206
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 200c9b2..1fe8423 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -10,15 +10,23 @@
fetches is a descendant of `<lbranch>`. This option
overrides that check.
+\--no-tags::
+ By default, `git-fetch` fetches tags that point at
+ objects that are downloaded from the remote repository
+ and stores them locally. This option disables this
+ automatic tag following.
+
-t, \--tags::
- By default, the git core utilities will not fetch and store
- tags under the same name as the remote repository; ask it
- to do so using `--tags`. Using this option will bound the
- list of objects pulled to the remote tags. Commits in branches
- beyond the tags will be ignored.
+ Most of the tags are fetched automatically as branch
+ heads are downloaded, but tags that do not point at
+ objects reachable from the branch heads that are being
+ tracked will not be fetched by this mechanism. This
+ flag lets all tags and their associated objects be
+ downloaded.
-u, \--update-head-ok::
By default `git-fetch` refuses to update the head which
corresponds to the current branch. This flag disables the
check. Note that fetching into the current branch will not
update the index and working directory, so use it with care.
+
diff --git a/git-fetch.sh b/git-fetch.sh
index b46b3e5..73e57bd 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -11,6 +11,7 @@ LF='
'
IFS="$LF"
+no_tags=
tags=
append=
force=
@@ -28,6 +29,9 @@ do
-t|--t|--ta|--tag|--tags)
tags=t
;;
+ -n|--n|--no|--no-|--no-t|--no-ta|--no-tag|--no-tags)
+ no_tags=t
+ ;;
-u|--u|--up|--upd|--upda|--updat|--update|--update-|--update-h|\
--update-he|--update-hea|--update-head|--update-head-|\
--update-head-o|--update-head-ok)
@@ -212,133 +216,166 @@ then
fi
fi
-for ref in $reflist
-do
- refs="$refs$LF$ref"
-
- # These are relative path from $GIT_DIR, typically starting at refs/
- # but may be HEAD
- if expr "$ref" : '\.' >/dev/null
- then
- not_for_merge=t
- ref=$(expr "$ref" : '\.\(.*\)')
- else
- not_for_merge=
- fi
- if expr "$ref" : '\+' >/dev/null
- then
- single_force=t
- ref=$(expr "$ref" : '\+\(.*\)')
- else
- single_force=
- fi
- remote_name=$(expr "$ref" : '\([^:]*\):')
- local_name=$(expr "$ref" : '[^:]*:\(.*\)')
-
- rref="$rref$LF$remote_name"
-
- # There are transports that can fetch only one head at a time...
- case "$remote" in
- http://* | https://*)
- if [ -n "$GIT_SSL_NO_VERIFY" ]; then
- curl_extra_args="-k"
- fi
- remote_name_quoted=$(perl -e '
- my $u = $ARGV[0];
- $u =~ s{([^-a-zA-Z0-9/.])}{sprintf"%%%02x",ord($1)}eg;
- print "$u";
- ' "$remote_name")
- head=$(curl -nsfL $curl_extra_args "$remote/$remote_name_quoted") &&
- expr "$head" : "$_x40\$" >/dev/null ||
- die "Failed to fetch $remote_name from $remote"
- echo >&2 Fetching "$remote_name from $remote" using http
- git-http-fetch -v -a "$head" "$remote/" || exit
- ;;
- rsync://*)
- TMP_HEAD="$GIT_DIR/TMP_HEAD"
- rsync -L -q "$remote/$remote_name" "$TMP_HEAD" || exit 1
- head=$(git-rev-parse --verify TMP_HEAD)
- rm -f "$TMP_HEAD"
- test "$rsync_slurped_objects" || {
- rsync -av --ignore-existing --exclude info \
- "$remote/objects/" "$GIT_OBJECT_DIRECTORY/" || exit
-
- # Look at objects/info/alternates for rsync -- http will
- # support it natively and git native ones will do it on the remote
- # end. Not having that file is not a crime.
- rsync -q "$remote/objects/info/alternates" \
- "$GIT_DIR/TMP_ALT" 2>/dev/null ||
- rm -f "$GIT_DIR/TMP_ALT"
- if test -f "$GIT_DIR/TMP_ALT"
- then
- resolve_alternates "$remote" <"$GIT_DIR/TMP_ALT" |
- while read alt
- do
- case "$alt" in 'bad alternate: '*) die "$alt";; esac
- echo >&2 "Getting alternate: $alt"
- rsync -av --ignore-existing --exclude info \
- "$alt" "$GIT_OBJECT_DIRECTORY/" || exit
- done
- rm -f "$GIT_DIR/TMP_ALT"
- fi
- rsync_slurped_objects=t
- }
- ;;
- *)
- # We will do git native transport with just one call later.
- continue ;;
- esac
+fetch_main () {
+ reflist="$1"
+ refs=
+
+ for ref in $reflist
+ do
+ refs="$refs$LF$ref"
+
+ # These are relative path from $GIT_DIR, typically starting at refs/
+ # but may be HEAD
+ if expr "$ref" : '\.' >/dev/null
+ then
+ not_for_merge=t
+ ref=$(expr "$ref" : '\.\(.*\)')
+ else
+ not_for_merge=
+ fi
+ if expr "$ref" : '\+' >/dev/null
+ then
+ single_force=t
+ ref=$(expr "$ref" : '\+\(.*\)')
+ else
+ single_force=
+ fi
+ remote_name=$(expr "$ref" : '\([^:]*\):')
+ local_name=$(expr "$ref" : '[^:]*:\(.*\)')
+
+ rref="$rref$LF$remote_name"
+
+ # There are transports that can fetch only one head at a time...
+ case "$remote" in
+ http://* | https://*)
+ if [ -n "$GIT_SSL_NO_VERIFY" ]; then
+ curl_extra_args="-k"
+ fi
+ remote_name_quoted=$(perl -e '
+ my $u = $ARGV[0];
+ $u =~ s{([^-a-zA-Z0-9/.])}{sprintf"%%%02x",ord($1)}eg;
+ print "$u";
+ ' "$remote_name")
+ head=$(curl -nsfL $curl_extra_args "$remote/$remote_name_quoted") &&
+ expr "$head" : "$_x40\$" >/dev/null ||
+ die "Failed to fetch $remote_name from $remote"
+ echo >&2 Fetching "$remote_name from $remote" using http
+ git-http-fetch -v -a "$head" "$remote/" || exit
+ ;;
+ rsync://*)
+ TMP_HEAD="$GIT_DIR/TMP_HEAD"
+ rsync -L -q "$remote/$remote_name" "$TMP_HEAD" || exit 1
+ head=$(git-rev-parse --verify TMP_HEAD)
+ rm -f "$TMP_HEAD"
+ test "$rsync_slurped_objects" || {
+ rsync -av --ignore-existing --exclude info \
+ "$remote/objects/" "$GIT_OBJECT_DIRECTORY/" || exit
+
+ # Look at objects/info/alternates for rsync -- http will
+ # support it natively and git native ones will do it on
+ # the remote end. Not having that file is not a crime.
+ rsync -q "$remote/objects/info/alternates" \
+ "$GIT_DIR/TMP_ALT" 2>/dev/null ||
+ rm -f "$GIT_DIR/TMP_ALT"
+ if test -f "$GIT_DIR/TMP_ALT"
+ then
+ resolve_alternates "$remote" <"$GIT_DIR/TMP_ALT" |
+ while read alt
+ do
+ case "$alt" in 'bad alternate: '*) die "$alt";; esac
+ echo >&2 "Getting alternate: $alt"
+ rsync -av --ignore-existing --exclude info \
+ "$alt" "$GIT_OBJECT_DIRECTORY/" || exit
+ done
+ rm -f "$GIT_DIR/TMP_ALT"
+ fi
+ rsync_slurped_objects=t
+ }
+ ;;
+ *)
+ # We will do git native transport with just one call later.
+ continue ;;
+ esac
+
+ append_fetch_head "$head" "$remote" \
+ "$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
+
+ done
+
+ case "$remote" in
+ http://* | https://* | rsync://* )
+ ;; # we are already done.
+ *)
+ ( : subshell because we muck with IFS
+ IFS=" $LF"
+ (
+ git-fetch-pack "$remote" $rref || echo failed "$remote"
+ ) |
+ while read sha1 remote_name
+ do
+ case "$sha1" in
+ failed)
+ echo >&2 "Fetch failure: $remote"
+ exit 1 ;;
+ esac
+ found=
+ single_force=
+ for ref in $refs
+ do
+ case "$ref" in
+ +$remote_name:*)
+ single_force=t
+ not_for_merge=
+ found="$ref"
+ break ;;
+ .+$remote_name:*)
+ single_force=t
+ not_for_merge=t
+ found="$ref"
+ break ;;
+ .$remote_name:*)
+ not_for_merge=t
+ found="$ref"
+ break ;;
+ $remote_name:*)
+ not_for_merge=
+ found="$ref"
+ break ;;
+ esac
+ done
+ local_name=$(expr "$found" : '[^:]*:\(.*\)')
+ append_fetch_head "$sha1" "$remote" \
+ "$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
+ done
+ ) || exit ;;
+ esac
- append_fetch_head "$head" "$remote" \
- "$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
+}
-done
+fetch_main "$reflist"
-case "$remote" in
-http://* | https://* | rsync://* )
- ;; # we are already done.
-*)
- IFS=" $LF"
- (
- git-fetch-pack "$remote" $rref || echo failed "$remote"
- ) |
- while read sha1 remote_name
- do
- case "$sha1" in
- failed)
- echo >&2 "Fetch failure: $remote"
- exit 1 ;;
- esac
- found=
- single_force=
- for ref in $refs
+# automated tag following
+case "$no_tags$tags" in
+'')
+ taglist=$(IFS=" " &&
+ git-ls-remote --tags "$remote" |
+ sed -ne 's|^\([0-9a-f]*\)[ ]\(refs/tags/.*\)^{}$|\1 \2|p' |
+ while read sha1 name
do
- case "$ref" in
- +$remote_name:*)
- single_force=t
- not_for_merge=
- found="$ref"
- break ;;
- .+$remote_name:*)
- single_force=t
- not_for_merge=t
- found="$ref"
- break ;;
- .$remote_name:*)
- not_for_merge=t
- found="$ref"
- break ;;
- $remote_name:*)
- not_for_merge=
- found="$ref"
- break ;;
- esac
- done
- local_name=$(expr "$found" : '[^:]*:\(.*\)')
- append_fetch_head "$sha1" "$remote" \
- "$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
- done || exit
- ;;
+ test -f "$GIT_DIR/$name" && continue
+ git-check-ref-format "$name" || {
+ echo >&2 "warning: tag ${name} ignored"
+ continue
+ }
+ git-cat-file -t "$sha1" >/dev/null 2>&1 || continue
+ echo >&2 "Auto-following $name"
+ echo ".${name}:${name}"
+ done)
+ case "$taglist" in
+ '') ;;
+ ?*)
+ fetch_main "$taglist" ;;
+ esac
esac
# If the original head was empty (i.e. no "master" yet), or
--
1.0.7-g0263
^ permalink raw reply related
* Re: trivial: remove the dots at the end of file names
From: Junio C Hamano @ 2006-01-07 10:35 UTC (permalink / raw)
To: git
In-Reply-To: <20060107103202.GC5536@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> I hope so. Don't you ever use mouse copy-pasting?!
Not mouse, but I always work inside "screen" and use
copy&paste.
^ 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