* Re: Commit ID in exported Tar Ball
From: Junio C Hamano @ 2007-05-19 21:00 UTC (permalink / raw)
To: René Scharfe
Cc: Frank Lichtenheld, Johan Herland, git, Thomas Glanzmann,
Michael Gernoth
In-Reply-To: <464F5CA2.3070809@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Something like the following patch? Since we're already embedding the
> commit ID in a comment, we might as well offer creating a synthetic file
> for it, too, if that solves a user's problem that might be difficult to
> work around otherwise.
Are you detecting and erroring out if the named file already
exists in the tree being archived?
Should we? Maybe we should just replace with warning?
Also should we silently ignore the request if the tree-ish is
not a commit-ish, or error out?
^ permalink raw reply
* Re: [PATCH] Teach 'git-apply --whitespace=strip' to remove empty lines at end of file
From: Junio C Hamano @ 2007-05-19 20:39 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <464EF7D2.4030406@gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
> Signed-off-by: Marco Costalba <mcostalba@gmail.com>
> ---
> builtin-apply.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-apply.c b/builtin-apply.c
> index 0399743..f17f838 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -1738,6 +1738,10 @@ static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag, i
> newsize--;
> }
>
> + if (new_whitespace == strip_whitespace)
> + while (newsize > 1 && !strncmp(new + newsize - 2, "\n\n", 2))
> + newsize--;
> +
> oldlines = old;
> newlines = new;
> leading = frag->leading;
I agree to what you are trying to do, but this patch is wrong.
You are stripping trailing newlines that were NOT introduced by
the patch, but happened to be present in the preimage (and in
the context).
Try it on this test vector:
cat >AAA <<\EOF
a
b
c
d
e
f
g
h
i
j
k
EOF
cat >P.diff <<\EOF
diff --git a/AAA b/AAA
index 59f6a9c..ffb28f5 100644
--- a/AAA
+++ b/AAA
@@ -1,4 +1,4 @@
-a
+A
b
c
d
@@ -6,12 +6,11 @@ d
e
f
+
+
g
h
-i
-
-j
k
EOF
^ permalink raw reply related
* Re: [PATCH (amend)] cvsserver: Add test cases for config file handling
From: Frank Lichtenheld @ 2007-05-19 20:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xbkwpl2.fsf@assigned-by-dhcp.cox.net>
On Sat, May 19, 2007 at 01:00:57PM -0700, Junio C Hamano wrote:
> Well, It seems that all of our foreign SCM tests tends to be
> slower than other tests, so I would be happier if a single run
Which only shows that git is so much faster than anything else ;)
> of one test covers everything we would want to cover, when I run
> "make test", rather than having multiple set-up steps that are
> identical in two different tests. So in that sense, I was not
> talking about code duplication which can be solved by splitting
> the duplicated part into a separate file and sourcing it from
> two scripts -- that is not a solution.
Ok, thanks for the clarification. I will merge the two test files
for now and resubmit.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: René Scharfe @ 2007-05-19 20:22 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Johan Herland, git, Thomas Glanzmann, Michael Gernoth
In-Reply-To: <20070517171150.GL5272@planck.djpig.de>
Frank Lichtenheld schrieb:
> On Thu, May 17, 2007 at 06:57:22PM +0200, Johan Herland wrote:
>> Of course, it all depends on whether the $Id$ conversion is triggered by
>> git-archive...
>
> Another possibility might be to add a commandline switch to git-archive
> so you can decide whether the commit id should be added as a header to
> the tar file (which it already supports) or as a ordinary file (which
> should be reasonable trivial to implement). The question if whether
> it would be worth to add that feature. Don't know if there are many
> other users out there that need it.
Something like the following patch? Since we're already embedding the
commit ID in a comment, we might as well offer creating a synthetic file
for it, too, if that solves a user's problem that might be difficult to
work around otherwise.
René
Documentation/git-archive.txt | 4 ++++
archive-tar.c | 7 +++++++
archive-zip.c | 7 +++++++
archive.h | 1 +
builtin-archive.c | 11 +++++++++++
5 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 721e035..ac31aac 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -43,6 +43,10 @@ OPTIONS
--prefix=<prefix>/::
Prepend <prefix>/ to each filename in the archive.
+--commit-id-file=<filename>::
+ Adds a file to the archive containing the commit ID. This option
+ is ignored if <tree-ish> references a tree instead of a commit.
+
<extra>::
This can be any options that the archiver backend understand.
See next section.
diff --git a/archive-tar.c b/archive-tar.c
index 33e7657..555850a 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -319,6 +319,13 @@ int write_tar_archive(struct archiver_args *args)
}
read_tree_recursive(args->tree, args->base, plen, 0,
args->pathspec, write_tar_entry);
+ if (args->commit_sha1 && args->commit_sha1_file) {
+ unsigned char fake_sha1[20];
+ pretend_sha1_file(sha1_to_hex(args->commit_sha1), 40,
+ OBJ_BLOB, fake_sha1);
+ write_tar_entry(fake_sha1, args->base, plen,
+ args->commit_sha1_file, 0100666, 0);
+ }
write_trailer();
return 0;
diff --git a/archive-zip.c b/archive-zip.c
index 3cbf6bb..88c5dfa 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -328,6 +328,13 @@ int write_zip_archive(struct archiver_args *args)
}
read_tree_recursive(args->tree, args->base, plen, 0,
args->pathspec, write_zip_entry);
+ if (args->commit_sha1 && args->commit_sha1_file) {
+ unsigned char fake_sha1[20];
+ pretend_sha1_file(sha1_to_hex(args->commit_sha1), 40,
+ OBJ_BLOB, fake_sha1);
+ write_zip_entry(fake_sha1, args->base, plen,
+ args->commit_sha1_file, 0100666, 0);
+ }
write_zip_trailer(args->commit_sha1);
free(zip_dir);
diff --git a/archive.h b/archive.h
index 6838dc7..020f82f 100644
--- a/archive.h
+++ b/archive.h
@@ -8,6 +8,7 @@ struct archiver_args {
const char *base;
struct tree *tree;
const unsigned char *commit_sha1;
+ const char *commit_sha1_file;
time_t time;
const char **pathspec;
unsigned int verbose : 1;
diff --git a/builtin-archive.c b/builtin-archive.c
index 7f4e409..e58ea16 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -151,6 +151,7 @@ int parse_archive_args(int argc, const char **argv, struct archiver *ar)
int extra_argc = 0;
const char *format = "tar";
const char *base = "";
+ const char *commit_sha1_file = NULL;
int verbose = 0;
int i;
@@ -174,6 +175,10 @@ int parse_archive_args(int argc, const char **argv, struct archiver *ar)
base = arg + 9;
continue;
}
+ if (!prefixcmp(arg, "--commit-id-file=")) {
+ commit_sha1_file = arg + 17;
+ continue;
+ }
if (!strcmp(arg, "--")) {
i++;
break;
@@ -192,6 +197,11 @@ int parse_archive_args(int argc, const char **argv, struct archiver *ar)
usage(archive_usage);
if (init_archiver(format, ar) < 0)
die("Unknown archive format '%s'", format);
+ if (commit_sha1_file) {
+ size_t namelen = strlen(commit_sha1_file);
+ if (namelen == 0 || commit_sha1_file[namelen - 1] == '/')
+ die("Invalid commit ID file name: %s", commit_sha1_file);
+ }
if (extra_argc) {
if (!ar->parse_extra)
@@ -201,6 +211,7 @@ int parse_archive_args(int argc, const char **argv, struct archiver *ar)
}
ar->args.verbose = verbose;
ar->args.base = base;
+ ar->args.commit_sha1_file = commit_sha1_file;
return i;
}
^ permalink raw reply related
* Re: [PATCH] git-archive: recursive prefix directory creation
From: Junio C Hamano @ 2007-05-19 20:22 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List
In-Reply-To: <464F568B.9030308@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Junio C Hamano schrieb:
>> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>>
>>> Currently git-archive only adds a single directory entry for prefixes,
>>> e.g. for --prefix=a/b/c/ only the directory a/b/c/ would be added to
>>> the archive, not a/ nor a/b/. While tar and unzip don't seem to have
>>> a problem handling these missing entries, their omission was not
>>> intended.
>>
>> Until we start tracking directories (we briefly discussed, and I
>> think I agree with Linus that it should not be too painful), I'd
>> rather keep the current behaviour which I feel is more
>> consistent with what we really are doing.
>
> Hmm, fair enough. I started out with a simple cleanup and then I guess
> went a bit overboard with that overblown path walker. :-]
Well, I take that back -- I did not realize you were primarily
talking about the LEADING part of the path.
^ permalink raw reply
* Re: merge summaries
From: Junio C Hamano @ 2007-05-19 20:20 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vy7jkwr96.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> What is so wrong if merge summaries of pulls from you were committed
>> to topic branches. Later when you pull such branches the summaries
>> shouldn't be a problem. A short-log of the topic branch wouldn't
>> contain the summaries.
>>
>> Probably I do not fully understand what "the wrong way around" means.
>
> I think you understand it very well.
>
> As long as you stay as a "pull-only" person, and will never ask
> the upstream to pull back from you, what first parent log would
> show would make perfectly good sense. However, once a pull from
> you by the upstream happens, the resulting history would get the
> summary in the merge you did, which is totally unwanted --- the
> upstream already had those summarized commits long time ago in
> its history.
Having said that.
The criteria to decide "wanted vs unwanted" all boil down to
essentially the question of who "owns" the history. Although
Linus often says that the point of distributed development is
that nobody is special, at the end of day, once you asked the
"upstream" to pull from you, your history becomes part of HIS
history, and at that point, when HE browses the history (which
he now thinks as HIS history), the summary shows the summary the
wrong way. So in that sense, merge.summary is going against the
philosophy of distributedness.
The summary message is useful in a very short term (i.e. while
it is still near the tip of the branch and running "git log"),
but I think JBF is correct to point out that it is showing a
shortcoming of our history browsing tools. The information
recorded there can easily be reproduced on the fly. Whenever
you see a merge commit, you can choose one parent to base your
view of the history upon (typically the first parent), and
summarize commits that are reachable from other parents but not
from that parent (e.g. for a typical two-parent merge, you would
run "git short-log $commit^1..$commit^2").
^ permalink raw reply
* Re: [PATCH 2/2] Teach "delta" attribute to pack-objects.
From: Junio C Hamano @ 2007-05-19 20:03 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, git
In-Reply-To: <56b7f5510705190910h7e5ed03bnbc5a1b9a1369fc9f@mail.gmail.com>
"Dana How" <danahow@gmail.com> writes:
> ... But such an attribute should be
> ignored when --stdout is in effect -- it only affects on-disk
> repacking, not packing for transfers, which is why it's named "repack".
Yes -- if we want to have an option to keep objects selectively
left out of packs in loose format, you would need 'repack' which
acts differently between the server-feeding-client case vs
packing-repository case.
Which is a bigger change that I did not want to show in the
quick-and-clean patch, but I would agree we would want both.
^ permalink raw reply
* Re: [PATCH (amend)] cvsserver: Add test cases for config file handling
From: Junio C Hamano @ 2007-05-19 20:00 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git
In-Reply-To: <20070519140521.GA4085@planck.djpig.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
>> But I certainly don't intend to do all the tests in one big file which
>> will become rather large over time. If you're concerned with code
>> duplication, maybe I should move the code to a separate file and source
>> it from there?
>
> Still waiting on a comment here...
Well, It seems that all of our foreign SCM tests tends to be
slower than other tests, so I would be happier if a single run
of one test covers everything we would want to cover, when I run
"make test", rather than having multiple set-up steps that are
identical in two different tests. So in that sense, I was not
talking about code duplication which can be solved by splitting
the duplicated part into a separate file and sourcing it from
two scripts -- that is not a solution.
Another thing we would need to decide (with Eric who has the
same issue) is how to structure the tests that try daemons. We
worked it around by using :fork: for the first cvsserver test,
but we would eventually want the real pserver test as well.
^ permalink raw reply
* Re: [PATCH] git-archive: recursive prefix directory creation
From: René Scharfe @ 2007-05-19 19:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vbqggy8ym.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Currently git-archive only adds a single directory entry for prefixes,
>> e.g. for --prefix=a/b/c/ only the directory a/b/c/ would be added to
>> the archive, not a/ nor a/b/. While tar and unzip don't seem to have
>> a problem handling these missing entries, their omission was not
>> intended.
>
> Until we start tracking directories (we briefly discussed, and I
> think I agree with Linus that it should not be too painful), I'd
> rather keep the current behaviour which I feel is more
> consistent with what we really are doing.
Hmm, fair enough. I started out with a simple cleanup and then I guess
went a bit overboard with that overblown path walker. :-]
René
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Junio C Hamano @ 2007-05-19 19:56 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Josef Weidendorfer, Andy Parkins, git, Nicolas Pitre,
Steven Grimm
In-Reply-To: <20070519181228.GP4708@mellanox.co.il>
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> Fetching from a new URL (not just "different from what is
>> defined in .gitmodules") is a major deal from security point of
>> view (you should not fetch from stranger you do not trust).
>
> I'm sorry, I'm confused. I thought the "URL" in .gitmodules
> is just a unique project key/name? So how come you are now
> speaking about fetching from it?
Sorry for confusing you. The point was by default that we
should not blindly follow URL given from upstream -- the
statement you quoted is one justification why my strawman uses
the URL in .gitmodules as a mere hint and look-up key.
Having said that, I'd ask not to take minor details in the
strawman too literally and seriously. I am 100% sure that we
would be in a serious trouble if what we end up doing matches
literally what my handwaving strawman suggested. The strawman
was thrown out to the open primarily so that (smarter and more
beautiful) people who thought the issues longer and harder to
express their opinions easier by having something to compare
their unique ideas against, nothing more.
I am slightly more than 50% sure that we would not want to tie
subproject fetch/clone into superproject fetch/clone, and _if_
we would tie it to anything, it would be to the checkout, but
that is only my gut feeling. Maybe we end up not tying
subproject fetch/clone to anything that happens in the
superproject; we may even do it in a completely different way
than the strawman said it _might_ work. That's perfectly fine.
The expectation from me sending out that handwaving strawman was
to help encouraging others to present their ideas, with
justifications. And having something to compare against, even
if it is just a handwaving strawman, is often much easier when
presenting your ideas and showing which part of your design is
important. You can say something like "the strawman fails in
this scenario, which is important in real life for such and such
reasons, and my design handles it this way" -- and everybody
can discuss if it is an important design consideration, and what
the best design to solve that problem if it is.
So don't take that strawman, especially the details in it, too
seriously, but take it as what it was: a firestarter.
^ permalink raw reply
* Re: merge summaries
From: Junio C Hamano @ 2007-05-19 19:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <73A1C4C5-50E9-4844-85F8-00D99682B6D4@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> What is so wrong if merge summaries of pulls from you were committed
> to topic branches. Later when you pull such branches the summaries
> shouldn't be a problem. A short-log of the topic branch wouldn't
> contain the summaries.
>
> Probably I do not fully understand what "the wrong way around" means.
I think you understand it very well.
As long as you stay as a "pull-only" person, and will never ask
the upstream to pull back from you, what first parent log would
show would make perfectly good sense. However, once a pull from
you by the upstream happens, the resulting history would get the
summary in the merge you did, which is totally unwanted --- the
upstream already had those summarized commits long time ago in
its history.
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Junio C Hamano @ 2007-05-19 18:20 UTC (permalink / raw)
To: skimo; +Cc: Alex Riesen, git
In-Reply-To: <20070519130542.GR942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> Does everyone agree that we should fetch (possibly after asking
> for confirmation from the use) _during_ the checkout ?
> I now only fetch submodules during a fetch of the supermodule
> (actually, in my current patch set, I only fetch a submodule
> the first time I see it, but that's a bug), but if there is
> a consensus on this, I can switch to fetching during checkout.
I think fetching of subproject during fetch or clone of
superproject would not make much sense. Making it part of
superproject checkout would probably be the way we will end up
going. The detail of "which part of the checkout" would need to
be defined, and I tend to agree with Alex that checkout itself
would need to be multi-phased, but I think that is a minor
implementation detail we can discuss after how the overall flows
should look like.
> As to the key to use to lookup the URL in the config, right
> now I simply use the directory name where it is attached
> (which seems like a useful default to me).
> I'm not all that convinced that we should store a default URL
> in history, so AFAICS, the only thing we need to store is a
> mapping between directory names and subproject names.
> It has been suggested to do that in .gitattributes.
> Is that OK for everyone, or do we really need a separate .gitmodules ?
If your (super)repository is _the_ only repository that knows
about the aggregation it is doing, I do not think you need
anything, as .git/config in the subproject would know where to
get updates from. Otherwise, Project wide suggestions need to
be there in some machine readable form if you were to allow such
superproject distributed, be it in .gitmodules or
.gitattributes, don't they?
And frankly, I think .gitattributes is a wrong place to store
it, as its semantics is to give attributes to paths that MATCH
the glob. You can argue that a pattern in .gitattributes can be
written to match only one path, but it still feels conceptually
wrong. Something more concrete and exact, like the second level
key of .git/config and .gitmodules file format, is preferable.
^ permalink raw reply
* Re: [PATCH] git-archive: recursive prefix directory creation
From: Junio C Hamano @ 2007-05-19 18:17 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List
In-Reply-To: <464EE169.30306@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Currently git-archive only adds a single directory entry for prefixes,
> e.g. for --prefix=a/b/c/ only the directory a/b/c/ would be added to
> the archive, not a/ nor a/b/. While tar and unzip don't seem to have
> a problem handling these missing entries, their omission was not
> intended.
Until we start tracking directories (we briefly discussed, and I
think I agree with Linus that it should not be too painful), I'd
rather keep the current behaviour which I feel is more
consistent with what we really are doing.
^ permalink raw reply
* Re: Commits gone AWOL, but not reported by git-fsck --unreachable
From: Junio C Hamano @ 2007-05-19 18:15 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Matthieu Moy, Anand Kumria, git
In-Reply-To: <839C7D1E-E1D0-4EA1-8221-789C418CB242@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> On May 19, 2007, at 12:55 PM, Matthieu Moy wrote:
>
>> Brian Gernhardt <benji@silverinsanity.com> writes:
>>
>>> On May 19, 2007, at 12:08 PM, Matthieu Moy wrote:
>>>
>>>> The commit introducing it is
>>>> 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b,
>>>> and I'd say it's in git 1.5.1:
>>>>
>>>> $ git-describe --tags 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b
>>>> v1.5.1-34-g566842f
>>>
>>> Actually, I think that means it's 34 commits *after* v1.5.1, not
>>> before. It's in 1.5.2-rc0, but none of the 1.5.1.* series.
>>
>> You're right. Then, is there any easy way to ask git the oldest tag(s)
>> that a commit is an ancestor of? In other words, which command should
>> I have typed above?
>
> I did it the hard way with "git log v1.5.1..v.1.5.1.1", "..1.5.1.2",
> and using grep to look for 566842. Anybody better at constructing
> these incantations want to chime in?
Perhaps "git-name-rev --refs='refs/tags/v*' $it"?
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Michael S. Tsirkin @ 2007-05-19 18:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Josef Weidendorfer, Andy Parkins, git, Michael S. Tsirkin,
Nicolas Pitre, Steven Grimm
In-Reply-To: <7vejle6p96.fsf@assigned-by-dhcp.cox.net>
> Fetching from a new URL (not just "different from what is
> defined in .gitmodules") is a major deal from security point of
> view (you should not fetch from stranger you do not trust).
I'm sorry, I'm confused. I thought the "URL" in .gitmodules
is just a unique project key/name? So how come you are now
speaking about fetching from it?
--
MST
^ permalink raw reply
* Using git to store /etc, redux
From: David Härdeman @ 2007-05-19 17:48 UTC (permalink / raw)
To: git
I recently had the idea to store and track /etc using git. When googling
the topic I came across the "Using git to store /etc" thread from the
end of last year which provided some interesting details on what would
be necessary.
It seems the file metadata (owner, group, mode, xattrs, etc) was the big
stumbling point, so I wrote up a tool over the last few days which
allows the metadata to be stored in a separate file which can be stored
along with the rest of the data in the repo (or separately).
This is also useful for tripwire type checks and for other types of
storage which drops some of the metadata (tar comes to mind)...
The tool (metastore) is available from:
git://git.hardeman.nu/metastore.git
Not completely cleaned up yet (it lacks a real README and some Makefile
targets) but I hope it might be useful to others (it sure is to me).
Please CC me on any replies.
--
David Härdeman
^ permalink raw reply
* Re: Commits gone AWOL, but not reported by git-fsck --unreachable
From: Brian Gernhardt @ 2007-05-19 17:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Anand Kumria, git
In-Reply-To: <vpq8xbkoir8.fsf@bauges.imag.fr>
On May 19, 2007, at 12:55 PM, Matthieu Moy wrote:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> On May 19, 2007, at 12:08 PM, Matthieu Moy wrote:
>>
>>> The commit introducing it is
>>> 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b,
>>> and I'd say it's in git 1.5.1:
>>>
>>> $ git-describe --tags 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b
>>> v1.5.1-34-g566842f
>>
>> Actually, I think that means it's 34 commits *after* v1.5.1, not
>> before. It's in 1.5.2-rc0, but none of the 1.5.1.* series.
>
> You're right. Then, is there any easy way to ask git the oldest tag(s)
> that a commit is an ancestor of? In other words, which command should
> I have typed above?
I did it the hard way with "git log v1.5.1..v.1.5.1.1", "..1.5.1.2",
and using grep to look for 566842. Anybody better at constructing
these incantations want to chime in?
~~ Brian
^ permalink raw reply
* Re: Commits gone AWOL, but not reported by git-fsck --unreachable
From: Matthieu Moy @ 2007-05-19 16:55 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Anand Kumria, git
In-Reply-To: <A04FB6C2-20B2-4263-9D58-6C281C04C6C4@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> On May 19, 2007, at 12:08 PM, Matthieu Moy wrote:
>
>> The commit introducing it is 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b,
>> and I'd say it's in git 1.5.1:
>>
>> $ git-describe --tags 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b
>> v1.5.1-34-g566842f
>
> Actually, I think that means it's 34 commits *after* v1.5.1, not
> before. It's in 1.5.2-rc0, but none of the 1.5.1.* series.
You're right. Then, is there any easy way to ask git the oldest tag(s)
that a commit is an ancestor of? In other words, which command should
I have typed above?
--
Matthieu
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Josef Weidendorfer @ 2007-05-19 16:55 UTC (permalink / raw)
To: Steven Grimm
Cc: Andy Parkins, git, Michael S. Tsirkin, Junio C Hamano,
Nicolas Pitre
In-Reply-To: <464E4C94.5070408@midwinter.com>
On Saturday 19 May 2007, Steven Grimm wrote:
> Andy Parkins wrote:
> > Bear in mind that what you're suggesting is no different in implementation
> > from what Junio is suggesting but with one difference: in Junio's option
> > the "identifier" will act as a default URL if no override is found.
> >
>
> I don't like using the URL as the key for one simple reason:
> ...
Another argument against naming the key for subprojects "URL" in
config/.gitmodules:
It can happen quite easily that a superprojects includes 2 subprojects
which really are only different branches of the same project, e.g.
GCC 4.1 and GCC 4.2 branch, e.g. to do regression testing with different
compiler versions.
But these two subprojects would be cloned from exactly the same URL.
So you artificially have to change one of the two URLs for this to
work, already at the start of your subproject.
The same example shows that the SHA1 of a projects root commit can not
work as a subproject key.
Josef
^ permalink raw reply
* [PATCH] Tech 'git-apply' that spaces before a tab are candidate for stripping
From: Marco Costalba @ 2007-05-19 16:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Currently 'git-apply' identify as stealth space a line starting with
spaces followed by a tab.
This patch updates the algorithm to find spaces + tab also in the
middle of a line and not only at the beginning.
As example lines like
"#define MY_VALUE \t 1"
are now identified and cleaned up if option '--whitespace=strip' is
used.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
There are a bunch of this type in current git tree.
builtin-apply.c | 72 ++++++++++++++++++++++++++++++------------------------
1 files changed, 40 insertions(+), 32 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index f17f838..9e82757 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1586,6 +1586,32 @@ static void remove_last_line(const char **rbuf,
int *rsize)
*rsize = offset + 1;
}
+static int copy_line(char **output_ptr, const char *patch, int start, int len)
+{
+ char *output = *output_ptr;
+ int space_start = 0;
+ int i, end = start + len;
+
+ for (i = start; i < end; i++) {
+
+ char ch = patch[i];
+
+ if (ch == ' ' && !space_start)
+ space_start = i;
+
+ else if (space_start && ch != ' ') {
+ if (ch == '\t') {
+ *output_ptr = output - (i - space_start);
+ return space_start;
+ }
+ space_start = 0;
+ }
+ *output++ = ch;
+ }
+ *output_ptr = output;
+ return 0;
+}
+
struct buffer_desc {
char *buffer;
unsigned long size;
@@ -1602,17 +1628,14 @@ static int apply_line(char *output, const char
*patch, int plen)
int i;
int add_nl_to_tail = 0;
int fixed = 0;
- int last_tab_in_indent = -1;
- int last_space_in_indent = -1;
- int need_fix_leading_space = 0;
- char *buf;
+ int space_start;
+ const char *old = output;
if ((new_whitespace != strip_whitespace) || !whitespace_error ||
*patch != '+') {
memcpy(output, patch + 1, plen);
return plen;
}
-
if (1 < plen && isspace(patch[plen-1])) {
if (patch[plen] == '\n')
add_nl_to_tail = 1;
@@ -1621,44 +1644,29 @@ static int apply_line(char *output, const char
*patch, int plen)
plen--;
fixed = 1;
}
+ space_start = copy_line(&output, patch, 1, plen);
+ while (space_start) {
- for (i = 1; i < plen; i++) {
- char ch = patch[i];
- if (ch == '\t') {
- last_tab_in_indent = i;
- if (0 <= last_space_in_indent)
- need_fix_leading_space = 1;
- }
- else if (ch == ' ')
- last_space_in_indent = i;
- else
- break;
- }
-
- buf = output;
- if (need_fix_leading_space) {
- /* between patch[1..last_tab_in_indent] strip the
- * funny spaces, updating them to tab as needed.
+ /* strip the funny spaces, updating them to tab as needed
+ * strip is done one space sequence at time, until line end
*/
- for (i = 1; i < last_tab_in_indent; i++, plen--) {
+ fixed = 1;
+ for (i = space_start; i < plen + 1; i++) {
+
char ch = patch[i];
if (ch != ' ')
- *output++ = ch;
+ break;
else if ((i % 8) == 0)
*output++ = '\t';
}
- fixed = 1;
- i = last_tab_in_indent;
+ space_start = copy_line(&output, patch, i, plen + 1 - i);
}
- else
- i = 1;
-
- memcpy(output, patch + i, plen);
if (add_nl_to_tail)
- output[plen++] = '\n';
+ *output++ = '\n';
if (fixed)
applied_after_stripping++;
- return output + plen - buf;
+
+ return output - old;
}
static int apply_one_fragment(struct buffer_desc *desc, struct
fragment *frag, int inaccurate_eof)
--
1.5.2.rc3.88.g4c3ba-dirty
^ permalink raw reply related
* Re: Git branching & pulling
From: Wink Saville @ 2007-05-19 16:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, git
In-Reply-To: <7vveepxr7m.fsf@assigned-by-dhcp.cox.net>
> Ah, if you ever interact with only single remote repository,
> then that is certainly a valid reason not to say anything else.
For reference my git version:
wink@ic2d1:~/linux/kvm-linux-2.6$ git --version
git version 1.5.2.rc0.g520d
This is very close to my situation, except in the mothership
is linux-2.6.git, kvm.git or git.git. So I have two primary objectives, first
periodically synchronize my repository with the remotes. Second, synchronize
my branches with their "remotes".
My expectations are that when I'm on a branch and do a git-pull with no
parameters I should "fetch" from that branches "remotes" and "merge" into
the current branch. This is how linus's repo seems to work.
But with kvm.git it appears I need to be quite explicit:
wink@ic2d1:~/linux/kvm-linux-2.6$ git-checkout -b test
Switched to a new branch "test"
wink@ic2d1:~/linux/kvm-linux-2.6$ git-pull
fatal: 'master': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
Cannot get the repository state from master
wink@ic2d1:~/linux/kvm-linux-2.6$ git-pull .
error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
Already up-to-date.
wink@ic2d1:~/linux/kvm-linux-2.6$ git-pull . master
Already up-to-date.
wink@ic2d1:~/linux/kvm-linux-2.6$
So to get consistent behavior it seems I should
always use the two parameter form. But the behavior
with no parameters was very convenient and less
error prone as the branch should always know
from where it was cloned:)
Here is another experiment cloning a local repo created
with 1.5.2-rc0 where tried git-pull's:
wink@ic2d1:~$ git-clone testgit testgit-clone
Initialized empty Git repository in /home/wink/testgit-clone/.git/
remote: Generating pack...
remote: Done counting 6 objects.
remote: Deltifying 6 objects...
remote: /6) done/6) done
remote: Total 6 (delta 0), reused 0 (delta 0)
Indexing 6 objects...
100% (6/6) done
wink@ic2d1:~$ cd testgit-clone/
wink@ic2d1:~/testgit-clone$ git-pull
Already up-to-date.
wink@ic2d1:~/testgit-clone$ git-pull .
Already up-to-date.
wink@ic2d1:~/testgit-clone$ git-pull ../testgit
Already up-to-date.
wink@ic2d1:~/testgit-clone$ git-pull ../testgit master
Already up-to-date.
wink@ic2d1:~/testgit-clone$ git-checkout -b test master
Switched to a new branch "test"
wink@ic2d1:~/testgit-clone$ git-pull .
Already up-to-date.
wink@ic2d1:~/testgit-clone$ git-pull . master
Already up-to-date.
wink@ic2d1:~/testgit-clone$ git-pull
Warning: No merge candidate found because value of config option
"branch.test.merge" does not match any remote branch fetched.
No changes.
wink@ic2d1:~/testgit-clone$
Why did last git-pull generate the warning, this seems wrong?
Regards,
Wink Saville
^ permalink raw reply
* Re: Commits gone AWOL, but not reported by git-fsck --unreachable
From: Brian Gernhardt @ 2007-05-19 16:20 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Anand Kumria, git
In-Reply-To: <vpq646opzio.fsf@bauges.imag.fr>
On May 19, 2007, at 12:08 PM, Matthieu Moy wrote:
> The commit introducing it is 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b,
> and I'd say it's in git 1.5.1:
>
> $ git-describe --tags 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b
> v1.5.1-34-g566842f
Actually, I think that means it's 34 commits *after* v1.5.1, not
before. It's in 1.5.2-rc0, but none of the 1.5.1.* series.
~~ Brian
^ permalink raw reply
* Re: Commits gone AWOL, but not reported by git-fsck --unreachable
From: Matthieu Moy @ 2007-05-19 16:08 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <pan.2007.05.19.15.45.46@progsoc.org>
Anand Kumria <wildfire@progsoc.org> writes:
> On Sat, 19 May 2007 08:11:54 -0400, Jeff King wrote:
>
>> On Sat, May 19, 2007 at 05:09:33AM -0700, Robin H. Johnson wrote:
>>
>>> Ahh, they do show up there (and I learnt a new git command now, thanks)
>>> - the ones that I can remember the Subject lines for anyway.
>>>
>>> Any hints for the future on finding stuff that is in the reflog but not
>>> in the tree? (Remembering every subject line isn't feasible).
>>
>> Try 'git-fsck --unreachable --no-reflogs'. :)
>
> What version? git 1.5.1.4 doesn't seem to have that.
The commit introducing it is 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b,
and I'd say it's in git 1.5.1:
$ git-describe --tags 566842f62bdf1f16c2e94fb431445d2e6c0f3f0b
v1.5.1-34-g566842f
--
Matthieu
^ permalink raw reply
* Re: [PATCH 2/2] Teach "delta" attribute to pack-objects.
From: Dana How @ 2007-05-19 16:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, danahow
In-Reply-To: <11795608922961-git-send-email-junkio@cox.net>
On 5/19/07, Junio C Hamano <junkio@cox.net> wrote:
> This teaches pack-objects to use .gitattributes mechanism so
> that the user can specify certain blobs are not worth spending
> CPU cycles to attempt deltification.
>
> The name of the attrbute is "delta", and when it is set to
> false, like this:
>
> == .gitattributes ==
> *.jpg -delta
>
> they are always stored in the plain-compressed base object
> representation.
And we could also have an attribute "repack" :
== .gitattributes ==
*.wmv -repack
which would result in *.wmv files [enormous] not being packed.
Since add_object_entry() now gets the name and
can reject objects (e.g. currently on their current packing status),
a call to "no_pack" which mirrors your new "no_try_delta"
could be inserted there. But such an attribute should be
ignored when --stdout is in effect -- it only affects on-disk
repacking, not packing for transfers, which is why it's named "repack".
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: Commits gone AWOL, but not reported by git-fsck --unreachable
From: Anand Kumria @ 2007-05-19 15:45 UTC (permalink / raw)
To: git
In-Reply-To: <20070519121154.GA10268@coredump.intra.peff.net>
On Sat, 19 May 2007 08:11:54 -0400, Jeff King wrote:
> On Sat, May 19, 2007 at 05:09:33AM -0700, Robin H. Johnson wrote:
>
>> Ahh, they do show up there (and I learnt a new git command now, thanks)
>> - the ones that I can remember the Subject lines for anyway.
>>
>> Any hints for the future on finding stuff that is in the reflog but not
>> in the tree? (Remembering every subject line isn't feasible).
>
> Try 'git-fsck --unreachable --no-reflogs'. :)
What version? git 1.5.1.4 doesn't seem to have that.
Anand
^ 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