* Re: [PATCH] Do _not_ call unlink on a directory
From: Matthieu Moy @ 2007-07-16 17:18 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git, gitster
In-Reply-To: <11846059721204-git-send-email-sithglan@stud.uni-erlangen.de>
Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
I believe you still have a race condition if ...
> - if (len > state->base_dir_len && state->force && !unlink(buf) && !mkdir(buf, 0777))
> - continue;
... buf exists here as a file ...
> if (!stat(buf, &st) && S_ISDIR(st.st_mode))
> continue; /* ok */
... and became a directory here.
> + if (len > state->base_dir_len && state->force && !unlink(buf) && !mkdir(buf, 0777))
> + continue;
But that's quite unlikely to happen. And I have no fix to propose.
--
Matthieu
^ permalink raw reply
* [PATCH] Do _not_ call unlink on a directory
From: Thomas Glanzmann @ 2007-07-16 17:38 UTC (permalink / raw)
To: git, gitster; +Cc: Thomas Glanzmann
In-Reply-To: <11846059721204-git-send-email-sithglan@stud.uni-erlangen.de>
Calling unlink on a directory on a Solaris UFS filesystem as root makes it
inconsistent. Thanks to Johannes Sixt for the obvious fix.
Signed-off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
---
entry.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/entry.c b/entry.c
index 82bf725..907293f 100644
--- a/entry.c
+++ b/entry.c
@@ -6,18 +6,18 @@ static void create_directories(const char *path, const struct checkout *state)
int len = strlen(path);
char *buf = xmalloc(len + 1);
const char *slash = path;
+ struct stat st;
while ((slash = strchr(slash+1, '/')) != NULL) {
len = slash - path;
memcpy(buf, path, len);
buf[len] = 0;
+ if (!stat(buf, &st) && S_ISDIR(st.st_mode))
+ continue; /* ok */
if (mkdir(buf, 0777)) {
if (errno == EEXIST) {
- struct stat st;
if (len > state->base_dir_len && state->force && !unlink(buf) && !mkdir(buf, 0777))
continue;
- if (!stat(buf, &st) && S_ISDIR(st.st_mode))
- continue; /* ok */
}
die("cannot create directory at %s", buf);
}
--
1.5.2.1
^ permalink raw reply related
* Re: [PATCH] Do _not_ call unlink on a directory
From: Jan-Benedict Glaw @ 2007-07-16 17:41 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git, gitster
In-Reply-To: <11846075213759-git-send-email-sithglan@stud.uni-erlangen.de>
[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]
On Mon, 2007-07-16 19:38:41 +0200, Thomas Glanzmann <sithglan@stud.uni-erlangen.de> wrote:
> Calling unlink on a directory on a Solaris UFS filesystem as root makes it
> inconsistent. Thanks to Johannes Sixt for the obvious fix.
>
> Signed-off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
> ---
> entry.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/entry.c b/entry.c
> index 82bf725..907293f 100644
> --- a/entry.c
> +++ b/entry.c
> @@ -6,18 +6,18 @@ static void create_directories(const char *path, const struct checkout *state)
> int len = strlen(path);
> char *buf = xmalloc(len + 1);
> const char *slash = path;
> + struct stat st;
Whitespace damage.
> while ((slash = strchr(slash+1, '/')) != NULL) {
> len = slash - path;
> memcpy(buf, path, len);
> buf[len] = 0;
> + if (!stat(buf, &st) && S_ISDIR(st.st_mode))
> + continue; /* ok */
Dito.
> if (mkdir(buf, 0777)) {
> if (errno == EEXIST) {
> - struct stat st;
> if (len > state->base_dir_len && state->force && !unlink(buf) && !mkdir(buf, 0777))
> continue;
> - if (!stat(buf, &st) && S_ISDIR(st.st_mode))
> - continue; /* ok */
> }
> die("cannot create directory at %s", buf);
> }
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: "really soon now": an unspecified period of time, likly to
the second : be greater than any reasonable definition
of "soon".
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Brian Downing @ 2007-07-16 17:42 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git, gitster
In-Reply-To: <11846075213759-git-send-email-sithglan@stud.uni-erlangen.de>
On Mon, Jul 16, 2007 at 07:38:41PM +0200, Thomas Glanzmann wrote:
> const char *slash = path;
> + struct stat st;
> memcpy(buf, path, len);
> buf[len] = 0;
> + if (!stat(buf, &st) && S_ISDIR(st.st_mode))
> + continue; /* ok */
You've got some whitespace damage here. Git's style is to use tabs.
-bcd
^ permalink raw reply
* Re: [PATCH] translate bad characters in refnames during git-svn fetch
From: martin f krafft @ 2007-07-16 17:47 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20070716033050.GA29521@muzzle>
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
also sprach Eric Wong <normalperson@yhbt.net> [2007.07.16.0530 +0200]:
> The major issue with this is that it doesn't handle odd cases
> where a refname is sanitized into something (say "1234~2"
> sanitizes to "1234=2"), and then another branch is created named
> "1234=2".
Well, we can't please everyone, can we? :)
I like Jan's proposal about using the % escape, even though it
doesn't make pretty branch names.
On the other hand, we could make the translation regexps
configurable...
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"if they can get you asking the wrong questions,
they don't have to worry about answers."
-- thomas pynchon
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Junio C Hamano @ 2007-07-16 17:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: Marco Costalba, Git Mailing List
In-Reply-To: <81b0412b0707160531mad35ed4x4c89b2d6c6f5f707@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> On 7/16/07, Marco Costalba <mcostalba@gmail.com> wrote:
>> Currently the patch just include the log message because the diff
>> content (-p option) is not buffered but is written with a combination
>> of printf, puts, fputs, fwrite and putchar directly to stdout.
>>
>> My question is, there is a way to get the quantity of bytes written to
>> stdout before they are printed? I'm not an expert of C stdio library,
>> so perhaps this is nonsense, but I was thinking of reading the size of
>> stout buffer before to fflush() (I don't know if it is possible).
>
> It is not possible. Buffers can be flushed at any time (i.e. they are
> flushed when EOL reached and the output is a terminal for stdout).
>
> It is also a bit unclear _why_ do you need the diff output. You don't
> show it immediately anyway.
I'd say making --show-message-size option incompatible with diff output
would be good enough futureproofing for now.
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-16 17:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vodiehko7.fsf@assigned-by-dhcp.cox.net>
On 7/14/07, Junio C Hamano <gitster@pobox.com> wrote:
>
> The current code spits out a log message after formatting it in
> its entirety in core, so we happen to have its size upfront.
> Having to say the size upfront means we close the door for
> alternative implementations that stream the log formatting
> processing.
>
This is a better named patch that try also to easy your correct point
about alternative implementations, in particular a value of zero is
reserved in case git is unable to satisfy the request, so that tools
can fallback on standard '\0' searching.
After inspecting diff.c code I made up my mind only log message can be
sized upfront, diff ocntent is printed by a bunch of printf, fwrite,
fputs, putchar and so on and it's impossible to know the size in
advance.
------------------- cut -------------------
Subject: [PATCH] Add --log-size to git log to print message size
Print message size just before the corresponding message.
Because git log output is normally read incrementally by
porcelain tools, if message size is ignored then an
expensive seek of a delimiting char, as example '\0'
must be done when parsing the output stream.
With this patch it is possible to avoid an otherwise
mandatory seek for '\0' starting from the beginning
of log body.
In case it is not possible to know the size upfront
size value is set to zero.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
Documentation/git-log.txt | 5 +++++
log-tree.c | 3 +++
revision.c | 4 ++++
revision.h | 1 +
4 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 63c1dbe..b539f50 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -64,6 +64,11 @@ include::pretty-options.txt[]
--follow::
Continue listing the history of a file beyond renames.
+--log-size::
+ Before the log message print out its size in bytes. Intended
+ mainly for porcelain tools consumption. If git is unable to
+ produce a valid value size is set to zero.
+
<paths>...::
Show only commits that affect the specified paths.
diff --git a/log-tree.c b/log-tree.c
index 8624d5a..2dc6b1b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -295,6 +295,9 @@ void show_log(struct rev_info *opt,
if (opt->add_signoff)
len = append_signoff(&msgbuf, &msgbuf_len, len,
opt->add_signoff);
+ if (opt->show_log_size)
+ printf("log size %i\n", len);
+
printf("%s%s%s", msgbuf, extra, sep);
free(msgbuf);
}
diff --git a/revision.c b/revision.c
index 28b5f2e..f1cbb1f 100644
--- a/revision.c
+++ b/revision.c
@@ -1149,6 +1149,10 @@ int setup_revisions(int argc, const
die("unknown date format %s", arg);
continue;
}
+ if (!strcmp(arg, "--log-size")) {
+ revs->show_log_size = 1;
+ continue;
+ }
/*
* Grepping the commit log
diff --git a/revision.h b/revision.h
index f46b4d5..98a0a8f 100644
--- a/revision.h
+++ b/revision.h
@@ -81,6 +81,7 @@ struct rev_info {
const char *log_reencode;
const char *subject_prefix;
int no_inline;
+ int show_log_size;
/* Filter by commit log message */
struct grep_opt *grep_filter;
--
1.5.3.rc2-dirty
^ permalink raw reply related
* Re: [PATCH] Do _not_ call unlink on a directory
From: Thomas Glanzmann @ 2007-07-16 17:55 UTC (permalink / raw)
To: Brian Downing; +Cc: git
In-Reply-To: <20070716174239.GG19073@lavos.net>
Hallo Brian,
> You've got some whitespace damage here. Git's style is to use tabs.
I have expandtab in my vim config which writes 8 spaces instead of tabs.
I should change that for git.
Thomas
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-16 17:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <7v4pk444rd.fsf@assigned-by-dhcp.cox.net>
On 7/16/07, Junio C Hamano <gitster@pobox.com> wrote:
>
> I'd say making --show-message-size option incompatible with diff output
> would be good enough futureproofing for now.
>
Oooops, I didn't see your post.
I agree 100%, please tell me if doc it's clear enough or it would be
better to clarify that "message log" it means only message and no diff
content.
Marco
^ permalink raw reply
* Re: [PATCH 0/6] Introduce commit notes
From: Junio C Hamano @ 2007-07-16 17:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andy Parkins, git, Alberto Bertogli, Johan Herland
In-Reply-To: <Pine.LNX.4.64.0707161724110.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Hmph, you are right. In this sequence:
>>
>> hex = sha1_to_hex(commit->object.sha1);
>> snprintf(name, sizeof(name), "%s:%.*s/%.*s",
>> notes_ref_name, 2, hex, 38, hex + 2);
>> if (get_sha1(name, sha1))
>> return;
>>
>> Instead, we could read the tree object by hand in the commit that is
>> referenced by notes_ref_name, which has uniform two letter names for
>> subtrees which can be binary searched, open the tree for that entry,
>> again by hand, and do another binary search because that tree has
>> uniform 38-letter names. That certainly could be done.
>>
>> Sounds like a "fun" project for some definition of the word.
>
> I disagree. One disadvantage to using tree objects is that it is much
> easier to have pilot errors. You could even make a new working tree
> checking out refs/notes/commits and change/add/remove files.
I suspect you read me wrong. I was saying that it is possible
to use a specialized tree object parser in place of get_sha1()
only in the above code to read the tree objects that represents
a 'note'. You obviously would want to do a sanity check such
as:
- The size of the tree object your customized tree parser is
fed is multiple of expected entry size (mode word + 20 SHA1 +
2 + NUL for fan-out, replace 2 with 38 for lower level);
- mode word for the entry is sane (an entry in the fan-out tree
would point at a tree object, an entry in lower level would
point at a blob);
- The name part (2 or 38) are lowercase hexadecimal strings;
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-16 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <e5bfff550707161055i2f12b858n7be155765fb664@mail.gmail.com>
On 7/16/07, Marco Costalba <mcostalba@gmail.com> wrote:
> On 7/16/07, Junio C Hamano <gitster@pobox.com> wrote:
> >
> > I'd say making --show-message-size option incompatible with diff output
> > would be good enough futureproofing for now.
> >
> Oooops, I didn't see your post.
>
> I agree 100%, please tell me if doc it's clear enough or it would be
> better to clarify that "message log" it means only message and no diff
> content.
>
Sorry to bother you again, but my English is very bad and I would like
to be clear.
When i say no diff content I mean that git log --log-size -p it's a
perfect valid command but --log-size will make git print the size of
_only_ the log part, it means from the line after "log size xxx\n"
until the end of log message that can be '\0' (if no diff) or the
beginning of diff part.
Sorry to be pedantic.
Marco
^ permalink raw reply
* Re: "git clone" executed as root on solaris 10 shreds UFS (it is possible to create hardlinks for directories as root under solaris)
From: Thomas Glanzmann @ 2007-07-16 18:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: GIT
In-Reply-To: <20070716171732.GE6134@cip.informatik.uni-erlangen.de>
Hello,
> I asked the UFS maintainer to reconsider to fix this.
the bug is filed.
Thomas
^ permalink raw reply
* Re: [PATCH] Fix git-p4 on Windows to not use the Posix sysconf
From: Simon Hausmann @ 2007-07-16 18:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Alex Riesen, Marius Storm-Olsen, git
In-Reply-To: <20070716053511.GC32566@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]
On Monday 16 July 2007 07:35:11 Shawn O. Pearce wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> > > Thanks. Marius' patch was whitespace damaged in the context lines,
> > > but it was easily repaired. I've got a couple of other small items
> > > in my fastimport repository that I'm going to ask Junio to include
> > > in 1.5.3 shortly.
> >
> > Thanks for taking care of this. I have pulled gfi master into
> > 'master'. Perhaps we would want to tag -rc2 this weekend, run
> > with it for a week or so and see if we need -rc3 before the
> > final.
>
> I'm not entirely sure how we're going to handle the git-p4 patches;
> I see there's already another set available to use '-x -' to avoid
> command line length problems.
>
> I'm more than happy to play patch monkey and ship them through the
> fastimport repository, but since I'm not a p4 user that offers little
> value to the process, other than perhaps to save you a little time.
>
> Simon suggested he might setup a git fork on repo.or.cz himself, at
> which point you could pull the patches for git-p4 directly from him.
>
> Simon?
Yes, sounds good to me. I have tried creating a git clone on repo.or.cz but
somehow I can't edit the project. Need to find pasky on IRC to help me :).
Until then I have created a repository on freedesktop.org:
git://people.freedesktop.org/~hausmann/git-p4
http://gitweb.freedesktop.org/?p=users/hausmann/git-p4;a=summary
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] git-p4: use subprocess in p4CmdList
From: Simon Hausmann @ 2007-07-16 18:33 UTC (permalink / raw)
To: Scott Lamb; +Cc: git
In-Reply-To: <11845582912155-git-send-email-slamb@slamb.org>
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
On Monday 16 July 2007 05:58:10 Scott Lamb wrote:
> This allows bidirectional piping - useful for "-x -" to avoid commandline
> arguments - and is a step toward bypassing the shell.
Thanks! I have pushed your two patches into
http://gitweb.freedesktop.org/?p=users/hausmann/git-p4;a=summary
Unless somebody else wants to try earlier I intend to ask Junio to pull your
changes from there after 1.5.3.
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Scott Lamb @ 2007-07-16 19:05 UTC (permalink / raw)
To: Thomas Glanzmann, git, gitster
In-Reply-To: <vpqd4yss1vo.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
>
> I believe you still have a race condition if ...
>
>> - if (len > state->base_dir_len && state->force && !unlink(buf) && !mkdir(buf, 0777))
>> - continue;
>
> ... buf exists here as a file ...
>
>> if (!stat(buf, &st) && S_ISDIR(st.st_mode))
>> continue; /* ok */
>
> ... and became a directory here.
>
>> + if (len > state->base_dir_len && state->force && !unlink(buf) && !mkdir(buf, 0777))
>> + continue;
>
> But that's quite unlikely to happen. And I have no fix to propose.
>
If arbitrary other tasks are running, the only way to be absolutely
certain you're not calling unlink() in a directory is to never call
unlink().
SUS describes a safe remove(), but Solaris's implementation contains the
same race:
http://src.opensolaris.org/source/xref/pef/phase_I/usr/src/lib/libc/port/gen/rename.c
so I think this patch is the best that can be done.
Best regards,
Scott
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* problem viewing git.git with gitk on cygwin
From: Ray Lehtiniemi @ 2007-07-16 19:30 UTC (permalink / raw)
To: git
hi all
i'm seeing a problem with gitk on cygwin. if i try and view the history of
git itself, it seems to stop at version 22dcbb. interestingly, the next
commit 3ef378 has an embedded CTRL-Z character in the commit message.
possible DOS EOF handling bug? or is there a repo setting i need to be
tweaking?
using git version 1.5.2.2, installed using the cygwin package setup tool.
thanks
ray
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Thomas Glanzmann @ 2007-07-16 19:56 UTC (permalink / raw)
To: Scott Lamb; +Cc: GIT
In-Reply-To: <469BC17D.60806@slamb.org>
Hello,
> If arbitrary other tasks are running, the only way to be absolutely
> certain you're not calling unlink() in a directory is to never call
> unlink().
there is one way to do it safe but it is so ugly that it is
unacceptable: don't call unlink as a privileged user (eg. root). So I
hope that one of the patches make it into git soon. I like the second
patch better because it does less system calls. Not that it matters.
For my co-workers I already build a git version with the patch in so
that they can continue to work as root. Don't even think about asking.
Thomas
^ permalink raw reply
* Re: "git clone" executed as root on solaris 10 shreds UFS (it ispossible to create hardlinks for directories as root under solaris)
From: David Kastrup @ 2007-07-16 19:57 UTC (permalink / raw)
To: git
In-Reply-To: <20070716154559.GD19073@lavos.net>
bdowning@lavos.net (Brian Downing) writes:
> On Mon, Jul 16, 2007 at 04:35:10PM +0200, Johannes Sixt wrote:
>> It tries to remove a *file* that is in the way and create the directory
>> in its place. But since your unlink() behaves incorrectly (it is
>> supposed to *fail* for directories), the logic does not quite work as
>> expected - it mistakes the directory for a file.
>
> http://www.opengroup.org/onlinepubs/007908799/xsh/unlink.html
>
> | The path argument must not name a directory unless the process has
> | appropriate privileges and the implementation supports using unlink() on
> | directories.
Isn't it funny? The problem with the git code is that the path
argument must not name a directory _if_ the process has appropriate
privileges and the implementation supports using unlink() on
directories.
Failure is not an option, it is a requirement.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Linus Torvalds @ 2007-07-16 19:58 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git, gitster
In-Reply-To: <11846059721204-git-send-email-sithglan@stud.uni-erlangen.de>
On Mon, 16 Jul 2007, Thomas Glanzmann wrote:
>
> Calling unlink on a directory on a Solaris UFS filesystem as root makes it
> inconsistent. Thanks to Johannes Sixt for the obvious fix.
Ack, I think this is the right thing to do.
As pointed out, it doesn't _guarantee_ that git won't call "unlink()" on a
directory (race conditions etc), but that's fundamentally true (there is
no "funlink()" like there is "fstat()"), and besides, that is in no way
git-specific (ie it's true of *any* application that gets run as root).
The theoretical race would only happen if somebody on purpose tries to
screw things over, it would never happen under any reasonable usage.
The old ordering of those tests was designed for sane operating systems,
so that you could basically do the unlink() without bothering, but
switching the order around is certainly not a disaster either, and if it
avoids the nasty bug in Solaris it's worth doing.
I have to say that I'm still a bit shocked that Solaris would have that
kind of behaviour. And they call that pile of sh*t "enterprise class"..
Linus
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Thomas Glanzmann @ 2007-07-16 20:00 UTC (permalink / raw)
To: Scott Lamb; +Cc: git, gitster
In-Reply-To: <469BC17D.60806@slamb.org>
Hello,
> so I think this patch is the best that can be done.
is there a reason why we call unlink and not remove?
Thomas
^ permalink raw reply
* Re: [PATCH 6/6] Add git-rewrite-commits
From: Sven Verdoolaege @ 2007-07-16 20:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0707160054340.14781@racer.site>
On Mon, Jul 16, 2007 at 01:38:11AM +0100, Johannes Schindelin wrote:
> Didn't I mention that it was a severe limitation to think of the sha1
> mapping of a 1-to-1 mapping? Think of it more as a relation.
The mapping is used in several operations.
First, there are several things that can happen to a commit
- it's pruned. This includes, for me, path pruning, matching
and a commit filter returning no SHA1s.
- it's rewritten to another commit that can be considered the
"moral equivalent" of that commit. This occurs when a commit
is not pruned, but something else happened to the commit itself or
one of its ancestors. This excludes, for me, the case
where a commit filter returns more than one SHA1.
- it's replaced by more than one SHA1. This can only happen
in a commit filter.
There are at least four operations in which this mapping is used:
- if the parents of a commit have been rewritten to one or more
commits, then they are replaced by the new commits.
If any parent has been pruned, then it is replaced by
the result of applying this operation on _its_ parents.
- any reference (in refs/) that points to a rewritten or pruned
commit is removed and
* if the commit was rewritten to a single commit, then it is
replaced by this commit
* otherwise, there is no moral equivalent single commit, but
we want to ensure we can still access the new commits, so
I create several references, either to each of the many
commits the old commit was rewritten to, or to each of
its nearest unpruned ancestors (i.e., the same set as
described in the previous operation).
- a SHA1 of a commit that appears in a commit message is replaced
by the rewritten commit iff it was rewritten to a single commit.
That is, if the commit was pruned or rewritten (through a commit
filter to more than one commit), then the SHA1 is left alone.
- the mapping available to filters
* if the commit was pruned, an empty file is created
* otherwise a file is created containing all rewritten SHA1s
I understand you want the second operation to only apply
to refs explicitly mentioned on the command line.
What else would you like to change?
skimo
^ permalink raw reply
* Re: A question about git-rev-list
From: Linus Torvalds @ 2007-07-16 20:05 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86wsx0wwvs.fsf@lola.quinscape.zz>
On Mon, 16 Jul 2007, David Kastrup wrote:
>
> if I do
>
> git-rev-list --remove-empty HEAD --not some-commit -- filename | tail -1
>
> do I have any guarantee that the commit id I get (if any) is a direct
> descendant of some-commit?
No. You get the guarantee that
- it's some kind of parent of HEAD
- it's *not* a parent of some-commit
But the trivial case is a simple history like
/-B-\
A D
\-C-/
(where "A" is the root commit, and "D" is the current HEAD, and there are
two development lines from A to D).
If you now do
git-rev-list HEAD --not C
you would generally see B on the list of commits, even though it's
obviously not a direct descendant of C.
No amount of flags will change that. Of course, B might not show up
for _other_ reasons (ie simply because it doesn't change "filename" at
all), but generally you must always think of git-rev-list (and git log) as
a _set_ operation.
There are no git operations that will look for "chain of commits from C to
D" if that is what you want. No such chain necessarily even exists, and
quite often it is ambiguous when it *does* exist (ie there is not a single
chain from A to D, there are two chains).
You could add some kind of function that looks for the "shortest chain of
commits from X to Y", but that would really be something fundamentally
different from what git-rev-list gives you.
Linus
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Linus Torvalds @ 2007-07-16 20:21 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Scott Lamb, git, gitster
In-Reply-To: <20070716200024.GD16878@cip.informatik.uni-erlangen.de>
On Mon, 16 Jul 2007, Thomas Glanzmann wrote:
>
> > so I think this patch is the best that can be done.
>
> is there a reason why we call unlink and not remove?
Exactly because we only want to remove _files_.
If it's already a directory, we don't need to do anything at all (we just
want to go to the next path component).
So what git wants is the modern "unlink()" behaviour that will return
EPERM (oe EISDIR) for a directory.
Not doing that in this day and age is *insane*. That whole "unlink/link"
on directories is original UNIX, but it's original UNIX from several
decades ago. It got fixed long long ago, and mkdir/rmdir have existed as
system calls since at least SVR3. Nobody does the insane "unlink()" any
more.
Except in Solaris, it would appear.
Linus
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Thomas Glanzmann @ 2007-07-16 20:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: GIT
In-Reply-To: <alpine.LFD.0.999.0707161315120.20061@woody.linux-foundation.org>
Hello,
> > is there a reason why we call unlink and not remove?
> Exactly because we only want to remove _files_.
of course. That is the whole point. Call unlink for files, rmdir for
directories.
Thomas
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Linus Torvalds @ 2007-07-16 20:29 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Scott Lamb, git, gitster
In-Reply-To: <alpine.LFD.0.999.0707161315120.20061@woody.linux-foundation.org>
On Mon, 16 Jul 2007, Linus Torvalds wrote:
>
> [..] mkdir/rmdir have existed as
> system calls since at least SVR3.
Correction. Apparently since 4.2BSD (1983).
Linus
^ 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