* [PATCH] git-daemon: don't ignore pid-file write failure
From: Jim Meyering @ 2007-05-21 7:58 UTC (permalink / raw)
To: git
Note: since the consequence of failure is to call die,
I don't bother to close "f".
Signed-off-by: Jim Meyering <jim@meyering.net>
---
daemon.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/daemon.c b/daemon.c
index e74ecac..674e30d 100644
--- a/daemon.c
+++ b/daemon.c
@@ -970,8 +970,8 @@ static void store_pid(const char *path)
FILE *f = fopen(path, "w");
if (!f)
die("cannot open pid file %s: %s", path, strerror(errno));
- fprintf(f, "%d\n", getpid());
- fclose(f);
+ if (fprintf(f, "%d\n", getpid()) < 0 || fclose(f) != 0)
+ die("failed to write pid file %s: %s", path, strerror(errno));
}
static int serve(char *listen_addr, int listen_port, struct passwd *pass, gid_t gid)
--
1.5.2
^ permalink raw reply related
* Re: [PATCH v2] Submodule merge support
From: Junio C Hamano @ 2007-05-21 7:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Martin Waitz, git
In-Reply-To: <20070521073758.GP3141@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Its a very old Sun C compiler, and it doesn't like structs to be
> initialized that way. Yes, newer compilers are better, and gcc is
> also better, but I'm unable to get our UNIX admins to actually do
> their job and keep systems usable by the users.
>
> /me starts to wonder why he continues with this day-job thing...
Time for a "git company" ;-)?
^ permalink raw reply
* git-svn or git problem...
From: David Kastrup @ 2007-05-21 7:54 UTC (permalink / raw)
To: git
Hi,
I have used git-svn for checking out the trunk of a large Subversion
archive. The .git subdirectory now sits in the /rep/texlive/trunk
directory.
But I actually would now want to have the branches (which are pretty
small in comparison) available in git as well, without checking the
whole trunk out again.
Is there a way to move the .git tracking one directory level upwards
and get the branches into it as well, without checking out the trunk
again (the trunk is several Gigabytes of size)?
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Cross-reference the manpages for git-name-rev and git-describe
From: Shawn O. Pearce @ 2007-05-21 7:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Anand Kumria, git, Johannes Schindelin
In-Reply-To: <7viramfwkq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> > Junio C Hamano <junkio@cox.net> wrote:
> >> wouldn't this be useful?
> >>
> >> $ git-describe --contains --tags 1b600e659
> >> v1.5.0-rc3~34
>
> Now we need to make sure that the name of the option --contains
> is sane, I guess.
I think its sane. I wanted to do a --contains option to describe
a while back, for this reason, but just didn't get around to it.
You also suggested it. Looks like at least two people came up with
that option independently. That's not too bad.
Feel free to edit the patch if something else better comes up.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2] Submodule merge support
From: Junio C Hamano @ 2007-05-21 7:54 UTC (permalink / raw)
To: Martin Waitz; +Cc: Shawn O. Pearce, git
In-Reply-To: <20070521073253.GU5412@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
>> > + if (S_ISDIRLNK(mode)) {
>> > + /* defer dirlinks to another process, don't try to */
>> > + /* read the object "sha" here */
>> > + const char *dirlink_checkout[] = {
>> > + "dirlink-checkout", path, sha1_to_hex(sha), NULL
>> > + };
>> > + struct child_process cmd = {
>> > + .argv = dirlink_checkout,
>> > + .git_cmd = 1,
>> > + };
>>
>> My Solaris 9 system cannot compile this syntax, even though it is
>> a clean way to initalize the child_process.
>
> any special thing it does not like in the above code or does it just
> not support structs that are initialized that way?
Portability rules:
- We do not do C99 initializers;
- We do not do decl-after-statement;
Readability rules:
- We always write NULL, not 0, for a NULL pointer.
There may be a handful more unwritten rules we use.
>> > + status = read(cmd.out, hex, sizeof(hex));
>> > + if (status != 40) return status;
>>
>> OK, this is probably just never trusting the OS, but shouldn't that
>> read be wrapped up in a loop, like our read_in_full? We want 40
>> bytes here, and expect it, and the read call is allowed to return
>> as few as 1 byte....
>
> right.
I think we have read-in-full or something like that for this
exact purpose.
^ permalink raw reply
* Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'
From: Karl Hasselström @ 2007-05-21 7:48 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: catalin.marinas, ydirson, git
In-Reply-To: <20070520211103.17468.21373.stgit@lathund.dewire.com>
On 2007-05-20 23:22:00 +0200, Robin Rosenberg wrote:
> söndag 20 maj 2007 skrev Yann Dirson:
>
> > Also I'm not sure it is a good way to look at "applied" file,
> > since Karl IIRC has plans to change this. Better call "stg top"
> > and not touch that again :)
>
> Calling stg is too slow to be be used here. I that command in my
> first draft for this function and people complained (see the thread
> named "Bash snippet to show branch and patch in bash prompt"). It
> takes ~ 0.15s on here which is very noticable, barely below my pain
> threshold.
>
> We'll update the prompt when and if Karl breaks this.
Yes, I can confirm that I'm hard at work breaking this. :-) I'm trying
out a way to get around the performance bug Catalin found, but I
didn't have time to finish it yesterday.
If that work is included, you could simply find the top patch by doing
git-show-ref and figuring out which patch has the same sha1 as HEAD.
But it sucks that stg starts so slowly. It has gotten better, I
believe (I think Catalin did some work here?), but 150 ms doesn't
really qualify as "instantaneous".
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Cross-reference the manpages for git-name-rev and git-describe
From: Junio C Hamano @ 2007-05-21 7:46 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Brian Gernhardt, Anand Kumria, git, Johannes Schindelin
In-Reply-To: <20070521072025.GO3141@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> wouldn't this be useful?
>>
>> $ git-describe --contains --tags 1b600e659
>> v1.5.0-rc3~34
>
> Like this? ;-)
Yeah, something like that.
Now we need to make sure that the name of the option --contains
is sane, I guess.
^ permalink raw reply
* Re: [PATCH v2] Submodule merge support
From: Shawn O. Pearce @ 2007-05-21 7:37 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20070521073253.GU5412@admingilde.org>
Martin Waitz <tali@admingilde.org> wrote:
> On Mon, May 21, 2007 at 02:20:05AM -0400, Shawn O. Pearce wrote:
> > > @@ -574,6 +575,21 @@ static void update_file_flags(const unsigned char *sha,
> > > void *buf;
> > > unsigned long size;
> > >
> > > + if (S_ISDIRLNK(mode)) {
> > > + /* defer dirlinks to another process, don't try to */
> > > + /* read the object "sha" here */
> > > + const char *dirlink_checkout[] = {
> > > + "dirlink-checkout", path, sha1_to_hex(sha), NULL
> > > + };
> > > + struct child_process cmd = {
> > > + .argv = dirlink_checkout,
> > > + .git_cmd = 1,
> > > + };
> >
> > My Solaris 9 system cannot compile this syntax, even though it is
> > a clean way to initalize the child_process.
>
> any special thing it does not like in the above code or does it just
> not support structs that are initialized that way?
Its a very old Sun C compiler, and it doesn't like structs to be
initialized that way. Yes, newer compilers are better, and gcc is
also better, but I'm unable to get our UNIX admins to actually do
their job and keep systems usable by the users.
/me starts to wonder why he continues with this day-job thing...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Make sure an autogenerated version has at least four parts
From: Martin Waitz @ 2007-05-21 7:36 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git
In-Reply-To: <11797159411969-git-send-email-sam.vilain@catalyst.net.nz>
[-- Attachment #1: Type: text/plain, Size: 251 bytes --]
hoi :)
On Mon, May 21, 2007 at 02:52:21PM +1200, Sam Vilain wrote:
> Otherwise, a custom "v1.5.2.42.gd00b" is considered newer than a
> "v1.5.2.1.69.gcafe".
or just use git describe output without replacing "-" with "."?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git log -S problem
From: Junio C Hamano @ 2007-05-21 7:34 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, j.sixt
In-Reply-To: <200705210727.23898.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Sunday 20 May 2007 23:05, Junio C Hamano wrote:
>> Johannes Sixt <johannes.sixt@telecom.at> writes:
>> > I had expected that the set of commits found by the second search string
>> > are a proper superset of those found by the first one. What's wrong here?
>> > Why does a search for 'merge-base' not find occurences of
>> > 'builtin-merge-base'?
>>
>> 71dfbf224 removes one line that has "git-merge-base$X" and adds
>> one line that has "builtin-merge-base.o". If you count the
>> number of occurences of substring "builtin-merge-base" in the
>> preimage and the postimage, you see one addition. If you count
>> the same for substring "merge-base", the net difference is 0.
>
> But is this how -S is *designed* to work?
http://thread.gmane.org/gmane.comp.version-control.git/14869/focus=14871
For the design background,
http://thread.gmane.org/gmane.comp.version-control.git/6214
^ permalink raw reply
* Re: [PATCH v2] Submodule merge support
From: Martin Waitz @ 2007-05-21 7:32 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070521062005.GK3141@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]
hoi :)
On Mon, May 21, 2007 at 02:20:05AM -0400, Shawn O. Pearce wrote:
> > @@ -574,6 +575,21 @@ static void update_file_flags(const unsigned char *sha,
> > void *buf;
> > unsigned long size;
> >
> > + if (S_ISDIRLNK(mode)) {
> > + /* defer dirlinks to another process, don't try to */
> > + /* read the object "sha" here */
> > + const char *dirlink_checkout[] = {
> > + "dirlink-checkout", path, sha1_to_hex(sha), NULL
> > + };
> > + struct child_process cmd = {
> > + .argv = dirlink_checkout,
> > + .git_cmd = 1,
> > + };
>
> My Solaris 9 system cannot compile this syntax, even though it is
> a clean way to initalize the child_process.
any special thing it does not like in the above code or does it just
not support structs that are initialized that way?
> > + status = read(cmd.out, hex, sizeof(hex));
> > + if (status != 40) return status;
>
> OK, this is probably just never trusting the OS, but shouldn't that
> read be wrapped up in a loop, like our read_in_full? We want 40
> bytes here, and expect it, and the read call is allowed to return
> as few as 1 byte....
right.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Cross-reference the manpages for git-name-rev and git-describe
From: Shawn O. Pearce @ 2007-05-21 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Anand Kumria, git, Johannes Schindelin
In-Reply-To: <7vsl9rmkm0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> wouldn't this be useful?
>
> $ git-describe --contains --tags 1b600e659
> v1.5.0-rc3~34
Like this? ;-)
-->8--
Teach git-describe how to run name-rev
Often users want to know not which tagged version a commit came
after, but which tagged version a commit is contained within.
This latter task is the job of git-name-rev, but most users are
looking to git-describe to do the job.
Junio suggested we make `git describe --contains` run the correct
tool, `git name-rev`, and that's exactly what we do here. The output
of name-rev was adjusted slightly through the new --name-only option,
allowing describe to execv into name-rev and maintain its current
output format.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git-describe.txt | 7 ++++++-
Documentation/git-name-rev.txt | 7 +++++++
builtin-describe.c | 15 +++++++++++++++
builtin-name-rev.c | 23 +++++++++++++++++------
4 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 47a583d..dc47b65 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -8,7 +8,7 @@ git-describe - Show the most recent tag that is reachable from a commit
SYNOPSIS
--------
-'git-describe' [--all] [--tags] [--abbrev=<n>] <committish>...
+'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
DESCRIPTION
-----------
@@ -31,6 +31,11 @@ OPTIONS
Instead of using only the annotated tags, use any tag
found in `.git/refs/tags`.
+--contains::
+ Instead of finding the tag that predates the commit, find
+ the tag that comes after the commit, and thus contains it.
+ Automatically implies --tags.
+
--abbrev=<n>::
Instead of using the default 8 hexadecimal digits as the
abbreviated object name, use <n> digits.
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index d6c8bf8..9a1645d 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -34,6 +34,13 @@ OPTIONS
Read from stdin, append "(<rev_name>)" to all sha1's of nameable
commits, and pass to stdout
+--name-only::
+ Instead of printing both the SHA-1 and the name, print only
+ the name. If given with --tags the usual tag prefix of
+ "tags/" is also ommitted from the name, matching the output
+ of gitlink::git-describe[1] more closely. This option
+ cannot be combined with --stdin.
+
EXAMPLE
-------
diff --git a/builtin-describe.c b/builtin-describe.c
index 165917e..efbd43f 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -3,6 +3,7 @@
#include "tag.h"
#include "refs.h"
#include "builtin.h"
+#include "exec_cmd.h"
#define SEEN (1u<<0)
#define MAX_TAGS (FLAG_BITS - 1)
@@ -242,12 +243,15 @@ static void describe(const char *arg, int last_one)
int cmd_describe(int argc, const char **argv, const char *prefix)
{
int i;
+ int contains = 0;
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
if (*arg != '-')
break;
+ else if (!strcmp(arg, "--contains"))
+ contains = 1;
else if (!strcmp(arg, "--debug"))
debug = 1;
else if (!strcmp(arg, "--all"))
@@ -272,6 +276,17 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
save_commit_buffer = 0;
+ if (contains) {
+ const char **nr = xmalloc((4 + argc - i) * sizeof(char*));
+ nr[0] = "name-rev";
+ nr[1] = "--name-only";
+ nr[2] = "--tags";
+ memcpy(nr + 3, argv + i, (argc - i) * sizeof(char*));
+ nr[3 + argc - i] = NULL;
+ execv_git_cmd(nr);
+ die("unable to start %s", nr[0]);
+ }
+
if (argc <= i)
describe("HEAD", 1);
else
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index ef16385..a639e2f 100644
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
@@ -83,6 +83,7 @@ copy_data:
struct name_ref_data {
int tags_only;
+ int name_only;
const char *ref_filter;
};
@@ -110,6 +111,10 @@ static int name_ref(const char *path, const unsigned char *sha1, int flags, void
if (!prefixcmp(path, "refs/heads/"))
path = path + 11;
+ else if (data->tags_only
+ && data->name_only
+ && !prefixcmp(path, "refs/tags/"))
+ path = path + 10;
else if (!prefixcmp(path, "refs/"))
path = path + 5;
@@ -149,7 +154,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
{
struct object_array revs = { 0, 0, NULL };
int as_is = 0, all = 0, transform_stdin = 0;
- struct name_ref_data data = { 0, NULL };
+ struct name_ref_data data = { 0, 0, NULL };
git_config(git_default_config);
@@ -165,6 +170,9 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
if (!strcmp(*argv, "--")) {
as_is = 1;
continue;
+ } else if (!strcmp(*argv, "--name-only")) {
+ data.name_only = 1;
+ continue;
} else if (!strcmp(*argv, "--tags")) {
data.tags_only = 1;
continue;
@@ -263,14 +271,17 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
struct object * obj = get_indexed_object(i);
if (!obj)
continue;
- printf("%s %s\n", sha1_to_hex(obj->sha1), get_rev_name(obj));
+ if (!data.name_only)
+ printf("%s ", sha1_to_hex(obj->sha1));
+ printf("%s\n", get_rev_name(obj));
}
} else {
int i;
- for (i = 0; i < revs.nr; i++)
- printf("%s %s\n",
- revs.objects[i].name,
- get_rev_name(revs.objects[i].item));
+ for (i = 0; i < revs.nr; i++) {
+ if (!data.name_only)
+ printf("%s ", revs.objects[i].name);
+ printf("%s\n", get_rev_name(revs.objects[i].item));
+ }
}
return 0;
--
1.5.2.14.g45bde-dirty
--
Shawn.
^ permalink raw reply related
* Re: Commit ID in exported Tar Ball
From: Thomas Glanzmann @ 2007-05-21 7:02 UTC (permalink / raw)
To: Brian Gernhardt
Cc: Shawn O. Pearce, Junio C Hamano, René Scharfe,
Frank Lichtenheld, Johan Herland, git, Michael Gernoth
In-Reply-To: <74FC1AD6-199E-4A01-BB9F-AD030659AE29@silverinsanity.com>
Hello Brian,
> dist:
> git archive HEAD > dist.tar
> git describe HEAD > version-file
> tar rf dist.tar version-file
> gzip dist.tar
to be precise that was my first idea when I started the whole
discussion. But I like the patch from Rene much more than that. Because
I want to use it with gitweb and it is definitevly easier to use realize
that with Renes patch.
Thomas
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Thomas Glanzmann @ 2007-05-21 7:00 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Brian Gernhardt, Junio C Hamano, René Scharfe,
Frank Lichtenheld, Johan Herland, git, Michael Gernoth
In-Reply-To: <20070521065355.GN3141@spearce.org>
Hello,
> So what, a magic flag to git-describe like:
> git-describe --untagged HEAD
> 1a8213...
> Where --untagged just means "give me back the raw commit SHA-1 if
> the input ref(s) aren't tagged"?
that is something I would love to live with. But it should also get the
primary objective done which is: Get the commit-id in the tar archive.
Thomas
^ permalink raw reply
* Re: [PATCH] Teach 'git-apply --whitespace=strip' to remove empty lines at the end of file
From: Junio C Hamano @ 2007-05-21 6:57 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <7v1whbmjel.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
>> Ok. This is take 3. It works correctly on standard patches and also on
>> u0 example that you gave above.
>>
>> This patch is on top of git 1.5.2
>>
>> Please check it.
>
> I think the checks and actions are at the right places (I
> haven't looked very closely nor tried to run it yet).
After fixing it up a bit to actually perform the removal only
under --whitespace=strip option, I merged it to 'next' and
pushed the result out. Then I found a slight breakage, when I
tried to reproduce your 6 "whitespace fix" series using that
famous procedure:
$ git checkout master
$ rm -f .git/index
$ git checkout HEAD -- t/ Documentation/
$ git clean -x -d
$ git diff -R --binary HEAD >P.diff
$ git apply --index --whitespace=strip P.diff
We somehow end up removing one LF too many, like this:
diff --git a/contrib/emacs/.gitignore b/contrib/emacs/.gitignore
index c531d98..016d3b1 100644
--- a/contrib/emacs/.gitignore
+++ b/contrib/emacs/.gitignore
@@ -1 +1 @@
-*.elc
+*.elc
\ No newline at end of file
Here is a fix on top of what's in 'next'. I think this is a lot
closer to what I outlined originally. Passes the testsuite but
that does not tell us much, as they did not catch the breakage
in your version.
Care to add a few tests for this new feature? Hint, hint...
-- >8 --
[PATCH] git-apply: Fix removal of new trailing blank lines.
The earlier code removed one newline too many from the hunk that
adds new lines at the end of the file. Also the way the code
counted the added blank lines was somewhat roundabout; I think
the way updated code does it is more direct and easier to
follow:
* We keep track of the number of blank lines added;
* While processing each line, we notice if it adds a blank
line, and increment the counter, or reset it to zero
otherwise;
* When actually we apply the data, we remove the empty lines we
counted earlier if we are applying it at the end of the
file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-apply.c | 48 +++++++++++++++---------------------------------
1 files changed, 15 insertions(+), 33 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index ac7c824..e717898 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1671,7 +1671,7 @@ static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag, i
char *new = xmalloc(size);
const char *oldlines, *newlines;
int oldsize = 0, newsize = 0;
- int trailing_added_lines = 0;
+ int new_blank_lines_at_end = 0;
unsigned long leading, trailing;
int pos, lines;
@@ -1679,6 +1679,7 @@ static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag, i
char first;
int len = linelen(patch, size);
int plen;
+ int added_blank_line = 0;
if (!len)
break;
@@ -1700,16 +1701,6 @@ static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag, i
else if (first == '+')
first = '-';
}
- /*
- * Count lines added at the end of the file.
- * This is not enough to get things right in case of
- * patches generated with --unified=0, but it's a
- * useful upper bound.
- */
- if (first == '+')
- trailing_added_lines++;
- else
- trailing_added_lines = 0;
switch (first) {
case '\n':
@@ -1728,9 +1719,14 @@ static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag, i
break;
/* Fall-through for ' ' */
case '+':
- if (first != '+' || !no_add)
- newsize += apply_line(new + newsize, patch,
- plen);
+ if (first != '+' || !no_add) {
+ int added = apply_line(new + newsize, patch,
+ plen);
+ newsize += added;
+ if (first == '+' &&
+ added == 1 && new[newsize-1] == '\n')
+ added_blank_line = 1;
+ }
break;
case '@': case '\\':
/* Ignore it, we already handled it */
@@ -1740,6 +1736,10 @@ static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag, i
error("invalid start of line: '%c'", first);
return -1;
}
+ if (added_blank_line)
+ new_blank_lines_at_end++;
+ else
+ new_blank_lines_at_end = 0;
patch += len;
size -= len;
}
@@ -1750,24 +1750,6 @@ static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag, i
newsize--;
}
- if (new_whitespace == strip_whitespace) {
- /* Any added empty lines is already cleaned-up here
- * becuase of 'strip_whitespace' flag, so just count '\n'
- */
- int empty = 0;
- while ( empty < trailing_added_lines
- && newsize - empty > 0
- && new[newsize - empty - 1] == '\n')
- empty++;
-
- if (empty < trailing_added_lines)
- empty--;
-
- /* these are the empty lines added at
- * the end of the file, modulo u0 patches.
- */
- trailing_added_lines = empty;
- }
oldlines = old;
newlines = new;
leading = frag->leading;
@@ -1805,7 +1787,7 @@ static int apply_one_fragment(struct buffer_desc *desc, struct fragment *frag, i
if (new_whitespace == strip_whitespace &&
(desc->size - oldsize - offset == 0)) /* end of file? */
- newsize -= trailing_added_lines;
+ newsize -= new_blank_lines_at_end;
diff = newsize - oldsize;
size = desc->size + diff;
--
1.5.2.24.g93d4
^ permalink raw reply related
* Re: Commit ID in exported Tar Ball
From: Brian Gernhardt @ 2007-05-21 6:56 UTC (permalink / raw)
To: Thomas Glanzmann
Cc: Shawn O. Pearce, Junio C Hamano, René Scharfe,
Frank Lichtenheld, Johan Herland, git, Michael Gernoth
In-Reply-To: <20070521063752.GB23350@cip.informatik.uni-erlangen.de>
On May 21, 2007, at 2:37 AM, Thomas Glanzmann wrote:
> so maybe it isn't that useless as I thought it initial is. But my
> point
> still stands. I want the commit id of the HEAD in a _file within_ the
> tarball and I definitively don't want to tag my project before I get a
> unique identifier.
If you haven't tagged anything, then git can't give you anything
better than the SHA-1. Giving a reference relative to a branch isn't
useful, as the branch can change. If the branch doesn't change, it's
really a tag and you should mark it as such.
Hopefully the patch for the "in a file" flag for git-archive will go
in soon (or something like it). I don't think we should make it any
more complex than just the hash, myself. If you want something more
complex a Makefile rule like
dist:
git archive HEAD > dist.tar
git describe HEAD > version-file
tar rf dist.tar version-file
gzip dist.tar
should do the trick. (And you can replace "git describe" with "git
parse-rev" for a bare hash if you'd like.)
~~ Brian
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Shawn O. Pearce @ 2007-05-21 6:53 UTC (permalink / raw)
To: Thomas Glanzmann
Cc: Brian Gernhardt, Junio C Hamano, René Scharfe,
Frank Lichtenheld, Johan Herland, git, Michael Gernoth
In-Reply-To: <20070521063752.GB23350@cip.informatik.uni-erlangen.de>
Thomas Glanzmann <thomas@glanzmann.de> wrote:
> so maybe it isn't that useless as I thought it initial is. But my point
> still stands. I want the commit id of the HEAD in a _file within_ the
> tarball and I definitively don't want to tag my project before I get a
> unique identifier.
So what, a magic flag to git-describe like:
git-describe --untagged HEAD
1a8213...
Where --untagged just means "give me back the raw commit SHA-1 if
the input ref(s) aren't tagged"?
--
Shawn.
^ permalink raw reply
* Re: RFC: submodule terminology
From: Shawn O. Pearce @ 2007-05-21 6:52 UTC (permalink / raw)
To: Raimund Bauer; +Cc: Junio C Hamano, Johan Herland, git, Martin Waitz
In-Reply-To: <1179729886.6187.15.camel@localhost>
Raimund Bauer <ray007@gmx.net> wrote:
> On Sun, 2007-05-20 at 15:59 -0700, Junio C Hamano wrote:
> > I was wondering if we can get away by just calling them
> > "projects", "projects containd in the superproject", etc., as I
> > tend to agree with Linus, who used the term "superproject
> > support" in his talk, that this is not really about creating
> > "subproject" which are somehow different from ordinary projects,
> > but more about supporting superprojects that can contain/point
> > at other projects, which we did not have before 1.5.2 happened.
>
> The "super" or "sub" only comes from where in a hierarchy it is used.
> Somewhere in the middle of the hierarchy it would be both?
Yes. Of course.
> I'd have said a repository can have many "modules" or "projects", and
> each of those can have several branches. A module can hold other
> modules, but from its POV also be part of a super-module (or
> superproject), we just have to take care to not build loops.
You cannot build a loop. OK, let me rephrase:
I can build a loop where at one point in time project A uses project
B as his subproject; then later I can have project B use project
A as a subproject. That's a loop. But the commits themselves are
not in a cycle. There is a specific version of A that requires a
specific version of B, and there is a different version of B that
requires an entirely different version of A.
This loop really just means we have to be smart about how we switch
between versions of a project. Just like if B is required in one
version of superproject A and not in another; when I switch back
and forth in A I expect B to appear/disappear. And I expect it
to work on an airplane, where network access to reclone B is not
available (or is too costly). That means we have to "hide" B when
its not needed.
If you can actually form a loop where version of A requires version
of B and version of B requires the version of A that requires the
version of B... that's a SHA-1 hash collision. If you can make
them at will, you probably can make some good money illegally...
> Is my view of the world correct so far?
Yes.
--
Shawn.
^ permalink raw reply
* Re: RFC: submodule terminology
From: Raimund Bauer @ 2007-05-21 6:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, git, Martin Waitz
In-Reply-To: <7v3b1rje45.fsf@assigned-by-dhcp.cox.net>
On Sun, 2007-05-20 at 15:59 -0700, Junio C Hamano wrote:
> I was wondering if we can get away by just calling them
> "projects", "projects containd in the superproject", etc., as I
> tend to agree with Linus, who used the term "superproject
> support" in his talk, that this is not really about creating
> "subproject" which are somehow different from ordinary projects,
> but more about supporting superprojects that can contain/point
> at other projects, which we did not have before 1.5.2 happened.
The "super" or "sub" only comes from where in a hierarchy it is used.
Somewhere in the middle of the hierarchy it would be both?
I'd have said a repository can have many "modules" or "projects", and
each of those can have several branches. A module can hold other
modules, but from its POV also be part of a super-module (or
superproject), we just have to take care to not build loops.
Is my view of the world correct so far?
--
best regards
Ray
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Thomas Glanzmann @ 2007-05-21 6:37 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Brian Gernhardt, Junio C Hamano, René Scharfe,
Frank Lichtenheld, Johan Herland, git, Michael Gernoth
In-Reply-To: <20070521062953.GL3141@spearce.org>
Hello,
so maybe it isn't that useless as I thought it initial is. But my point
still stands. I want the commit id of the HEAD in a _file within_ the
tarball and I definitively don't want to tag my project before I get a
unique identifier.
Thomas
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Shawn O. Pearce @ 2007-05-21 6:29 UTC (permalink / raw)
To: Thomas Glanzmann
Cc: Brian Gernhardt, Junio C Hamano, René Scharfe,
Frank Lichtenheld, Johan Herland, git, Michael Gernoth
In-Reply-To: <20070520163026.GA7387@cip.informatik.uni-erlangen.de>
Thomas Glanzmann <thomas@glanzmann.de> wrote:
> so this output is useless if you don't have tagged the commit which
> isn't the case. But thanks for the awareness.
Thanks for not quoting Brian's reply. Because I had to go and
quote it manually, so I can say its *NOT* useless...
> Brian Gernhardt <benji@silverinsanity.com> wrote:
> > For version information it is far more useful to use --tags or no
> > options (annotated tags only) instead of --all.
> >
> > # On git.git's master this morning:
> > $ git describe HEAD
> > v1.5.2
Here whatever HEAD's commit is is exactly the commit that the tag
v1.5.2 points at. This commit is definately v1.5.2.
> > $ git describe HEAD^^
> > v1.5.2-rc3-97-g03f6db0
Here whatever commit is 2 commits earlier than HEAD is 97 commits
*after* v1.5.2-rc3 was tagged. That's a good deal of information
right there. I know its v1.5.2-rc3 plus a bunch of additional
commits (97 to be exact). Add another commit and that 97 will
go to 98. Wow, look, an automatic version counter! No user
intervention required!
Sometimes I don't even bother tagging git-gui fixes, for exactly
that reason. The output of git-describe is giving me a count along
my maint branch, or my master branch.
Now that g03f6db0 suffix is also very useful, it means its the
commit whose SHA- starts with 03f6db0. That abbreviated SHA-1
is unique at the time that git-describe ran. At 8 hex digits it
will probably also stay unique for quite some time, even in large
projects like the kernel.
And even if that isn't unique later on, I doubt there will be another
commit with the same leading hex digits that is also 97 commits
after v1.5.2, as counted by `git-rev-list v1.5.2..$it | wc -l`.
So even in the case of a later duplicate, we can get back a full
SHA-1.
And did you know that Git knows how to parse those, and can checkout
that commit?
$ git checkout v1.5.2-rc3-97-g03f6db0
Note: moving to "v1.5.2-rc3-97-g03f6db0" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 03f6db0... Merge branch 'maint' to synchronize with 1.5.1.6
Wow. Magic! Not useless!
--
Shawn.
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Peter Baumann @ 2007-05-21 6:19 UTC (permalink / raw)
To: Thomas Glanzmann
Cc: Brian Gernhardt, Shawn O. Pearce, Junio C Hamano,
René Scharfe, Frank Lichtenheld, Johan Herland, git,
Michael Gernoth
In-Reply-To: <20070520163026.GA7387@cip.informatik.uni-erlangen.de>
On Sun, May 20, 2007 at 06:30:26PM +0200, Thomas Glanzmann wrote:
> Hello,
>
> > For version information it is far more useful to use --tags or no options
> > (annotated tags only) instead of --all.
>
> so this output is useless if you don't have tagged the commit which
> isn't the case. But thanks for the awareness.
>
No. Just _ONE_ tagged commit should be enough. In a project of mine I
tagged the root commit and as I am the only committer and this project
is so simple that I don't have to do a lot of branching/merging, I get a
single line of history
t - o1 - o2 - o3 - o4 <- master
^
|- tagged root commit
This gives me very nicely enumerated commits like tag-1-g<sha1-abbrev> for
the commit o1 and tag-2-g<sha1-abbrev> for o2 ... you get the idea.
-Peter
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Thomas Glanzmann @ 2007-05-21 6:24 UTC (permalink / raw)
To: Brian Gernhardt, Shawn O. Pearce, Junio C Hamano,
René Scharfe, Frank Lichtenheld, Johan Herland, git,
Michael Gernoth
In-Reply-To: <20070521061954.GB8605@xp.machine.xx>
Hello,
> This gives me very nicely enumerated commits like tag-1-g<sha1-abbrev> for
> the commit o1 and tag-2-g<sha1-abbrev> for o2 ... you get the idea.
I get the idea but I don't like it very much. From my point of view the
commit id makes much more sense. The output is cut&pasted anyway.
Thomas
^ permalink raw reply
* Re: [PATCH v2] Submodule merge support
From: Shawn O. Pearce @ 2007-05-21 6:20 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20070520154227.GG5412@admingilde.org>
> @@ -574,6 +575,21 @@ static void update_file_flags(const unsigned char *sha,
> void *buf;
> unsigned long size;
>
> + if (S_ISDIRLNK(mode)) {
> + /* defer dirlinks to another process, don't try to */
> + /* read the object "sha" here */
> + const char *dirlink_checkout[] = {
> + "dirlink-checkout", path, sha1_to_hex(sha), NULL
> + };
> + struct child_process cmd = {
> + .argv = dirlink_checkout,
> + .git_cmd = 1,
> + };
My Solaris 9 system cannot compile this syntax, even though it is
a clean way to initalize the child_process. That's why I've always
used something more like:
struct child_process cmd;
memset(&cmd, 0, sizeof(cmd));
cmd.argv = dirlink_checkout;
cmd.git_cmd = 1;
and actually that raises another point, does the compiler 0 fill
the stack-allocated struct that is initalized like you write, or
does it avoid filling the other fields that aren't mentioned in
the initialization?
> + status = read(cmd.out, hex, sizeof(hex));
> + if (status != 40) return status;
OK, this is probably just never trusting the OS, but shouldn't that
read be wrapped up in a loop, like our read_in_full? We want 40
bytes here, and expect it, and the read call is allowed to return
as few as 1 byte....
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Update bash completion to ignore some more plumbing commands
From: Shawn O. Pearce @ 2007-05-21 6:12 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git, Junio C Hamano
In-Reply-To: <20070519213521.GA32221@diku.dk>
Jonas Fonseca <fonseca@diku.dk> wrote:
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> ---
> contrib/completion/git-completion.bash | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
OK, sorry this missed 1.5.2. I've applied it into my fastimport
master branch, I guess it will be in the next 1.5.2 based release.
;-)
> I am not sure if it is OK to exclude checkout-index as it is
> the only method of exporting the source as a directory. Also,
It might make sense to exclude checkout-index as plumbing, but I
use it myself so often (and tab complete it too) that I want to
keep it in. So I deleted that one line out of your patch when I
applied it.
> I don't understand why git-diff-* is not excluded.
Because I personally also use git diff-tree a lot. The others
(diff-files, diff-index) I *never* use directly so I'm thinking
maybe they should get flagged as plumbing and get removed from
the completion.
--
Shawn.
^ 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