* Re: [PATCH] git-clone: lose the traditional 'no-separate-remote' layout
From: Linus Torvalds @ 2006-12-16 16:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virgci2ux.fsf_-_@assigned-by-dhcp.cox.net>
On Sat, 16 Dec 2006, Junio C Hamano wrote:
>
> And this drops it; modulo bugs, I think this is about it for
> v1.5.0 around this area.
Ahh, you said that yourself, and I hadn't even noticed that you already
merged xdl_merge into master too.
So here's an "AOL high five": <me too>.
^ permalink raw reply
* "intro to git" in Portland Oregon on Monday
From: Randal L. Schwartz @ 2006-12-16 17:06 UTC (permalink / raw)
To: git
If you're close enough to drop by, I'm giving my hastily prepared
"intro to git" talk Monday night in Portland Oregon. Details at
<http://article.gmane.org/gmane.org.user-groups.linux.portland/14545>.
If you're in a reviewing mood, I'm slowly updating my draft of the talk at
<http://www.stonehenge.com/pic/Git.pdf>. That's just a temp location
though... I'll push it to archive.org when I've finally presenting it.
Thanks to Junio and (someone else, sorry) for giving me feedback already.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Steven Grimm @ 2006-12-16 17:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Jakub Narebski
In-Reply-To: <7v4prwn0lp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> It's just a common courtesy, not "tackling".
>
Interesting. I'd actually prefer people *remove* me from the CC list --
I find it annoying to get two copies of every message in threads I reply
to. I'm already subscribed to the mailing list, so there's no point
having me on the Cc line too. (Mind you, as annoyances go it's a pretty
insignificant one.)
I can understand the case of people who aren't on the list wanting to
get replies, but why does someone who *is* on the list want to be CCed?
Is it just that there's no good way to tell in advance which category a
given person falls into, so best to be on the safe side?
^ permalink raw reply
* git-add fails after file type change
From: Steven Grimm @ 2006-12-16 18:16 UTC (permalink / raw)
To: Git Mailing List
In the course of experimenting with using git for my snapshot backups, I
ran into what looks like a bug in git-add: it croaks when it tries to
add a file whose type has changed, specifically when a directory gets
moved and a symbolic link is put in the old location pointing to the new
one. Here's a simple test case:
$ git init-db
defaulting to local storage area
$ mkdir dir
$ echo foo > dir/file
$ git add .
$ git commit -m "initial commit" -a
Committing initial tree f4bc9c50d08b041f5e096fa68e243c34170f1cd8
create mode 100644 dir/file
$ mv dir dir.real
$ ln -s dir.real dir
$ git add .
fatal: unable to add dir to index
Is "git add ." the wrong thing to do here? I have been using it as a
generic "pick up all the files I haven't added yet" command. Or is this
a bug?
For what it's worth, "git update-index dir" and "git update-index --add
dir" both fail too.
^ permalink raw reply
* Re: git-add fails after file type change
From: Jakub Narebski @ 2006-12-16 18:31 UTC (permalink / raw)
To: git
In-Reply-To: <458437E0.1050501@midwinter.com>
Steven Grimm wrote:
> In the course of experimenting with using git for my snapshot backups, I
> ran into what looks like a bug in git-add: it croaks when it tries to
> add a file whose type has changed, specifically when a directory gets
> moved and a symbolic link is put in the old location pointing to the new
> one. Here's a simple test case:
>
> $ git init-db
> defaulting to local storage area
> $ mkdir dir
> $ echo foo > dir/file
> $ git add .
> $ git commit -m "initial commit" -a
> Committing initial tree f4bc9c50d08b041f5e096fa68e243c34170f1cd8
> create mode 100644 dir/file
> $ mv dir dir.real
> $ ln -s dir.real dir
> $ git add .
> fatal: unable to add dir to index
Works if you use "git mv dir dir.real".
$ git init-db
defaulting to local storage area
$ mkdir dir
$ echo foo > dir/file
$ git add .
$ git commit -m "initial commit" -a
Committing initial tree f4bc9c50d08b041f5e096fa68e243c34170f1cd8
$ git mv dir dir.real
$ ln -s dir.real dir
$ git add .
$ git commit -m "second commit" -a
$ git ls-tree HEAD
120000 blob e05f72eddb14362b836c3612c13d441b097a065a dir
040000 tree 4a1c03029e7407c0afe9fc0320b3258e188b115e dir.real
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Subprojects tasks
From: Junio C Hamano @ 2006-12-16 18:32 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
Because I am primarily a plumber, I was thinking about the
changes that need to be done at the plumbing level. I only
looked at the prototype when it was announced, and I do not know
the progress you made since then. Could you tell us the current
status?
I am assuming that the overall design is based on what Linus
proposed long time ago with his "gitlink" object. That is,
* the index and the tree object for the superproject has a
"link" object that tells there is a directory and the
corresponding commit object name from the subproject. Unlike
my previous "bind commit" based prototype, index does not
have any blobs nor trees from the subproject.
* the subproject is on its own, and can exist unaware of the
existence of its superproject (there is no back-link at the
object layer).
* the subproject and the superproject are loosely coupled. An
act of committing in one does not automatically make a
corresponding commit in the other at the plumbing level.
For now, I assume that the representation of the "link" object
is (after the usual object header) 40-byte hexadecimal SHA-1 of
the commit object, plus a LF, but that is a minor detail.
At the object layer, obviously you would need a new object type
allocated, "link", and the mode-bits assigned in the tree
object. You should be able to cover cat-file, fsck-objects
(connectivity through link->commit), pack-objects and
unpack-objects (they need to know about the new object type) at
that stage.
With the index, in addition to the mode bits and "link" object's
SHA-1, you would need to decide what to do with ce_match_stat(),
to keep track of the information "update-index --refresh" updates.
My recommendation is to:
(1) Look at the directory the "link" is at, and find .git/
subdirectory (that is the $GIT_DIR for the subproject) and
its .git/HEAD;
(2) If that points at a loose ref, use the file's stat()
information (e.g stat("$sub/.git/refs/heads/master"));
(3) Otherwise, use the packed-ref file's stat() information
(e.g stat("$sub/.git/packed-refs")).
Then ce_match_stat() for a "link" entry can do the same
computation and tell if the subproject has changed its HEAD.
I think "update-index --add $directory" should check if .git/
exists and looks like a valid repository, and make a "link"
object out of "$directory/.git/HEAD".
Another issue with the index is what to put in the cache_tree
structure; I think "link" can be treated just like blob (both
files and symlinks).
Then read-tree (bulk of it is in unpack-trees.c) needs to be
taught to read in "link" and put that into the index -- this
should be straightforward.
After you have a working index, you should be able to do
write-tree (writes the new "link" entry as is, without
descending into the subproject) trivially.
It is debatable what 'checkout-index -f' should do when the
subproject is already checked out and its HEAD points at a
different commit. I am tempted to say that it should go there
and run "reset --hard", but I feel uneasy about that because it
is a blatant layering violation. Maybe it should simply ignore
link entries and let the Porcelain layer take care of them.
Then there are three diff- brothers at the plumbing level. I
think it is reasonable not to make them recurse into "link",
even with the presense of -r (recursive) option (Porcelain "git
diff" might want to recurse into the subproject, perhaps with a
new --recurse-harder option, though).
That means diff-files either skips a "link" entry if
ce_match_stat() says it is clean, or feeds "link" and its
recorded SHA-1 from the index on the left hand side, and 0{40}
on the right hand side with "link" type (after verifying that
"$sub/.git" is still there -- otherwise you would say that the
working tree has lost that subproject). "Read from the working
tree" done for diff-files for a "link" object would grab the
commit SHA-1 from the tip of the current branch of the
subproject, format it as the value of a "link" object (I am
assuming just a 40-byte commit SHA-1, plus a LF) and would
compare that with the result of read_sha1_file() on the link
object recorded in the index when producing -p (patch) output.
diff-tree would compare "link" entries without descending into
them. "link" and "blob" would compare just like "symlink" and
"blob" would compare.
diff-index with --cached would work like diff-tree (two concrete
SHA-1), and without --cached would work like diff-files (one
SHA-1 from the tree, another is either from the index if
ce_match_stat() says it is clean, 0{40} otherwise).
I suspect the hardest part is "rev-list --objects" (now most of
it is found in revision.c). Theoretically, if the code can
handle "tag"s, it should be able to handle "link"s, but I have a
feeling that the ancestry traversal code that walks commits is
not prepared to see "commit" object to appear from somewhere in
the middle of traversal. A commit so far can be wrapped only by
tags zero or more times, and a tag never appears inside anything
but another tag, so the code can just keep peeling the tag until
it sees a non-tag and after that it will be living in the world
that has only commit->tree->blob hierarchy, and can afford to do
the ancestry based solely on "commit" and can treat reachability
for "tree" and "blob" as afterthought. But I think the updated
code needs to know that "link" needs to be unwrapped and
contained "commit" needs to be injected back to the ancestry
walking machinery.
Once you have "rev-list --objects", you should be able to drive
pack-objects with its output. I do not think there is much to
change in that program.
My gut feeling is that it would take about 2-3 weeks for a
competent plumber working on full time to make the above changes
to the plumbing side into presentable shape.
On the Porcelain side, you would need policy design, some of
which were discussed on the list, such as what committing and
fetching in a superproject mean and should do. I do not have a
guestimate of the amount of work that would involve.
^ permalink raw reply
* Re: git-add fails after file type change
From: A Large Angry SCM @ 2006-12-16 18:35 UTC (permalink / raw)
To: Steven Grimm; +Cc: Git Mailing List
In-Reply-To: <458437E0.1050501@midwinter.com>
Steven Grimm wrote:
> In the course of experimenting with using git for my snapshot backups, I
> ran into what looks like a bug in git-add: it croaks when it tries to
> add a file whose type has changed, specifically when a directory gets
> moved and a symbolic link is put in the old location pointing to the new
> one. Here's a simple test case:
>
> $ git init-db
> defaulting to local storage area
> $ mkdir dir
> $ echo foo > dir/file
> $ git add .
> $ git commit -m "initial commit" -a
> Committing initial tree f4bc9c50d08b041f5e096fa68e243c34170f1cd8
> create mode 100644 dir/file
> $ mv dir dir.real
> $ ln -s dir.real dir
> $ git add .
> fatal: unable to add dir to index
>
> Is "git add ." the wrong thing to do here? I have been using it as a
> generic "pick up all the files I haven't added yet" command. Or is this
> a bug?
>
> For what it's worth, "git update-index dir" and "git update-index --add
> dir" both fail too.
^ permalink raw reply
* Re: git-add fails after file type change
From: Steven Grimm @ 2006-12-16 18:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <em1e1v$lse$1@sea.gmane.org>
Jakub Narebski wrote:
> Works if you use "git mv dir dir.real".
>
This came up during my testing of snapshot backups. The *real* sequence
is more like
$ git checkout -b new-snapshot
$ rsync /live/directory .
$ git add .
In other words, I don't know in advance that there's a rename or (short
of turning on verbose rsync output and parsing it) which parts of the
tree have changed at all. So I can't easily use git-mv here.
It still feels like a bug that "git add" can fail with no useful
diagnostic. It actually took me a fair while to figure out what was
going on here -- at first I thought it was having trouble with symlinks
in general, then with absolute-path symlinks (which the actual symlink
in question is), then I thought maybe it was a corrupt index. It wasn't
until I went back and looked at the previous snapshot that I was
overlaying this one on top of that I realized there used to be a
directory where that symlink lives now.
^ permalink raw reply
* Re: Subprojects tasks
From: Jakub Narebski @ 2006-12-16 18:45 UTC (permalink / raw)
To: git
In-Reply-To: <7vzm9nelob.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> (1) Look at the directory the "link" is at, and find .git/
> subdirectory (that is the $GIT_DIR for the subproject) and
> its .git/HEAD;
Or .gitlink file, if we decide to implement it (as lightweight checkout and
support for submodules which one can easily move/rename).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-add fails after file type change
From: Junio C Hamano @ 2006-12-16 19:23 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <458437E0.1050501@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> $ mkdir dir
> $ echo foo > dir/file
> $ git add .
> ...
> Committing initial tree f4bc9c50d08b041f5e096fa68e243c34170f1cd8
> create mode 100644 dir/file
> $ mv dir dir.real
> $ ln -s dir.real dir
> $ git add .
> fatal: unable to add dir to index
You didn't tell the index to remove dir/file. You cannot have
dir and dir/file at the same time.
^ permalink raw reply
* Re: [RFC/PATCH (take 3)] gitweb: Add some mod_perl specific support
From: Junio C Hamano @ 2006-12-16 19:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11662855752162-git-send-email-jnareb@gmail.com>
I have your (take 2) merged already last night in my tree but
haven't pushed the result out. Does this replace it?
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-16 19:57 UTC (permalink / raw)
To: Steven Grimm; +Cc: Johannes Schindelin, git, Jakub Narebski
In-Reply-To: <4584290E.6080006@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> Interesting. I'd actually prefer people *remove* me from the CC list --
> I find it annoying to get two copies of every message in threads I
> reply to. I'm already subscribed to the mailing list, so there's no
> point having me on the Cc line too. (Mind you, as annoyances go it's a
> pretty insignificant one.)
>
> I can understand the case of people who aren't on the list wanting to
> get replies, but why does someone who *is* on the list want to be
> CCed? Is it just that there's no good way to tell in advance which
> category a given person falls into, so best to be on the safe side?
There is no cheap and mechanical way to tell that for the
sender, and even when the sender can tell, it is not polite to
do so (see next paragraph), unless the recipient specifically
ask for it. On the other hand, filtering duplicates at the
recipient's end could be mechanically done without wasting the
human time. And people's time tend to be a lot more expensive
than machine time and the cost to send extra bits over the wire.
Some people (including me) prioritize e-mails and respond to
messages that are addressed To: them first, then Cc: next, and
finally the rest of the messages that came only through the
mailng list. Dropping a recipient from the Cc: list, even when
the sender knows that recipient is on the list, breaks this.
People can safely remove *themselves* from the CC: list when the
mailing list they subscribe to are on the CC: list as well.
This would interact with the prioritizing I mentioned above, but
that is done as a choice by them as the recipient of the
replies, so there is no problem in doing so.
^ permalink raw reply
* Re: [RFC/PATCH (take 3)] gitweb: Add some mod_perl specific support
From: Jakub Narebski @ 2006-12-16 20:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virgbei6z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I have your (take 2) merged already last night in my tree but
> haven't pushed the result out. Does this replace it?
Yes, that replaces it. I'm very sorry for the confusion.
I have noticed that I would need to add "use Apache2::RequestRec"
or it's mod_perl 1.0 equivalent before I can use $r->path_info().
--
Jakub Narebski
^ permalink raw reply
* Re: Subprojects tasks
From: Sven Verdoolaege @ 2006-12-16 20:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, git
In-Reply-To: <7vzm9nelob.fsf@assigned-by-dhcp.cox.net>
On Sat, Dec 16, 2006 at 10:32:36AM -0800, Junio C Hamano wrote:
> I suspect the hardest part is "rev-list --objects" (now most of
> it is found in revision.c). [..] But I think the updated
> code needs to know that "link" needs to be unwrapped and
> contained "commit" needs to be injected back to the ancestry
> walking machinery.
Do we want "link" to be unwrapped, though ?
> Once you have "rev-list --objects", you should be able to drive
> pack-objects with its output.
Wouldn't we then run into the scalability problems Linus was
concerned about ?
^ permalink raw reply
* Re: Subprojects tasks
From: Junio C Hamano @ 2006-12-16 21:07 UTC (permalink / raw)
To: skimo; +Cc: Martin Waitz, git
In-Reply-To: <20061216203553.GA25274MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> On Sat, Dec 16, 2006 at 10:32:36AM -0800, Junio C Hamano wrote:
>> I suspect the hardest part is "rev-list --objects" (now most of
>> it is found in revision.c). [..] But I think the updated
>> code needs to know that "link" needs to be unwrapped and
>> contained "commit" needs to be injected back to the ancestry
>> walking machinery.
>
> Do we want "link" to be unwrapped, though ?
>
>> Once you have "rev-list --objects", you should be able to drive
>> pack-objects with its output.
>
> Wouldn't we then run into the scalability problems Linus was
> concerned about ?
Hmph.
If the plumbing layer does not have to (although I haven't
thought it through, it does feel like it even shouldn't) unwrap
"link" and let the Porcelain layer to deal with it, that would
certainly make rev-list/revision.c part simpler.
I like it.
^ permalink raw reply
* Changes between main releases of git
From: Jakub Narebski @ 2006-12-16 21:07 UTC (permalink / raw)
To: git
We are now close according to Junio to git 1.5.0.
I'd like to ask by the occasion what were main changes
between main versions (main releases) of git, say starting
from v1.0.0? TIA.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Changes between main releases of git
From: Junio C Hamano @ 2006-12-16 21:20 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <em1n78$iud$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> We are now close according to Junio to git 1.5.0.
We only just started talking about v1.5.0. I would expect it to
be at least a month away, probably more. Definitely not by
Christmas nor Linus's birthday.
> I'd like to ask by the occasion what were main changes
> between main versions (main releases) of git, say starting
> from v1.0.0?
I would agree we would LOVE to have that list by the time we do
a real v1.5.0, so that should be on the TO-DO list. The
essential sources of information are:
* Previous "What's in" summaries.
* Previous "GIT v1.X.X" announcements.
* Output from this (pick the ones that are not marked with ^)
for txt in Documentation/*.txt
do
git blame v1.0.0..next -- "$txt"
done
* Output from this
git log v1.0.0..next
My time however is rather tight and I feel it is better spent on
the real development and release management. People who has
been following the git list long enough should be able to come
up with a draft to help the process.
I happen to think you are among the more qualified people.
^ permalink raw reply
* Re: [RFC/PATCH (take 3)] gitweb: Add some mod_perl specific support
From: Junio C Hamano @ 2006-12-16 21:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612162103.18695.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>> I have your (take 2) merged already last night in my tree but
>> haven't pushed the result out. Does this replace it?
>
> Yes, that replaces it. I'm very sorry for the confusion.
>
> I have noticed that I would need to add "use Apache2::RequestRec"
> or it's mod_perl 1.0 equivalent before I can use $r->path_info().
I noticed the difference by applying the patch to the parent of
(take 2) commit I made and diffing. It would be nice to have
the above two line comment somewhere in the message, probably
immediately after the three-dash lines, but no biggie.
Thanks for the clarification.
^ permalink raw reply
* Re: [RFC/PATCH] Change "refs/" references to symbolic constants
From: Junio C Hamano @ 2006-12-16 21:44 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612141644.06167.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> Changed repeated use of the same constants for the ref paths to be
> symbolic constants.
This is not rejected nor forgotten but has not been applied yet,
and may not be immediately.
I would love to have this; it would reduce mistakes (spelling
"refs/head/" would silently compile fine and result in a broken
command, while spelling PATH_REFS_HEAD would be caught by the
compiler).
A sad thing is this needs to be done when things are relatively
quiescent.
So I would apply this before v1.5.0 (or a replacement, if you
have updates), but it might have to wait a bit until I I can say
"ok, no big patches to C part is pending right now and it is a
good time to do this clean-up".
^ permalink raw reply
* Re: [RFC/PATCH 2/2] git-svn: rename 'commit' command to 'set-tree'
From: Eric Wong @ 2006-12-16 21:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqm4ezv8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > 'set-tree' probably accurately describes what the command
> > formerly known as 'commit' does.
> >
> > I'm not entirely sure that 'dcommit' should be renamed to 'commit'
> > just yet... Perhaps 'push' or 'push-changes'?
>
> I think Pasky did such a three-way rename to avoid breaking
> people's fingers. I thought it was a reasonable transition
> strategy, but some people might say its only effect was to break
> people's fingers not just once but twice, so Pasky himself
> and/or Cogito users may have some input on this.
Good point about breaking fingers twice. I don't think 'commit'
accurately describes any current operation that git-svn does; so the
command can probably go away safely. I'm guessing that something along
the lines of 'push' is probably a better way to describe 'dcommit'.
> We are talking about major UI change between 1.4 series and
> v1.5.0 on the core Porcelain-ish side, so if you feel confident
> that things would settle down in a month or so in the git-svn
> front, it may be a good idea to roll sweeping changes into the
> same timeframe.
I plan on supporting remotes in the config file; and adding support for
svn in git-fetch (wrapping git-svn multi-fetch, which should get faster
by then)
--
^ permalink raw reply
* Re: git-add fails after file type change
From: Junio C Hamano @ 2006-12-16 21:58 UTC (permalink / raw)
To: git; +Cc: Steven Grimm, Nicolas Pitre
In-Reply-To: <45843C5A.8020501@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Steven Grimm wrote:
>> In the course of experimenting with using git for my snapshot
>> backups, I ran into what looks like a bug in git-add: it croaks when
>> it tries to add a file whose type has changed, specifically when a
>> directory gets moved and a symbolic link is put in the old location
>> pointing to the new one. Here's a simple test case:
>>
>> $ git init-db
>> defaulting to local storage area
>> $ mkdir dir
>> $ echo foo > dir/file
>> $ git add .
>> $ git commit -m "initial commit" -a
>> Committing initial tree f4bc9c50d08b041f5e096fa68e243c34170f1cd8
>> create mode 100644 dir/file
>> $ mv dir dir.real
>> $ ln -s dir.real dir
>> $ git add .
>> fatal: unable to add dir to index
>>
>> Is "git add ." the wrong thing to do here? I have been using it as a
>> generic "pick up all the files I haven't added yet" command. Or is
>> this a bug?
>>
>> For what it's worth, "git update-index dir" and "git update-index
>> --add dir" both fail too.
>
> Did you try "git-update-index --replace dir"?
Good point. I've forgotten about "--replace" codepath, although
that is all my code (May 7, 2005).
Maybe "git add" should internally use ADD_CACHE_OK_TO_REPLACE
(or error out and have an option to enable it)?
In any case, the error message could be made a bit more helpful,
like this.
---
diff --git a/read-cache.c b/read-cache.c
index eae4745..a602010 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -609,7 +609,7 @@ int add_cache_entry(struct cache_entry *ce, int option)
if (!skip_df_check &&
check_file_directory_conflict(ce, pos, ok_to_replace)) {
if (!ok_to_replace)
- return -1;
+ return error("'%s' appears as both a file and as a directory", ce->name);
pos = cache_name_pos(ce->name, ntohs(ce->ce_flags));
pos = -pos-1;
}
^ permalink raw reply related
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-16 22:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <em0u4k$8hs$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Things that need to be done to complete what have been merged to
>> 'master' are:
>
> What about discussed but not implemented moving restriction on non-head refs
> from git-checkout (forbidding to checkout tags, remotes, and arbitrary
> commits like HEAD~n) to git-commit (allowing commiting only to heads refs)?
Did I miss a patch? ;-)
I've taken a look at it once, and it is usually easy to decide
if we should allow or disallow manipulation of the HEAD at
individual places that tries to look at it or modify it, but
there are many places and giving reasonable error messages to
all of the places we would want to disallow would be quite a lot
of work. In other words, it is rather a wide-and-shallow change
all over manipulators section of Porcelain. So from my point of
view it is backburnered, but that does not mean I would object
to a patch that does it cleanly ;-).
^ permalink raw reply
* Re: git-fetch fails with error code 128
From: Andy Parkins @ 2006-12-16 22:12 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nicolas Pitre
In-Reply-To: <7vy7p8omdh.fsf@assigned-by-dhcp.cox.net>
On Friday 2006, December 15 21:55, Junio C Hamano wrote:
> Thanks --- very much appreciated. When it comes to
> inter-repository object transfer, we take compatibility very
> seriously.
Okay. Before I started bisecting I thought I'd do some other experiments.
Having tested fetch from remote and a fetch from local and finding the same
results, I've done all the tests locally.
So; here goes. I've got these directories:
linux-partial/ (this is every patch from v1.0.0 to v2.1.63)
linux-full/ (this is every patch from v1.0.0 to v2.5.75)
linux-partial/ is the one I reported the original error on, later I confirmed
that the same error happened with a local fetch from linux-full. I cloned
both of these.
linux-partial-clone/ (made with git clone linux-partial linux-partial-clone)
linux-full-clone/ (made with git clone linux-full linux-full-clone)
Tests:
- A fetch from linux-full to linux-partial, this one failed with error 128
- A fetch from linux-full-clone to linux-partial, this one failed with
error 128
- A fetch from linux-full to linux-partial-clone, this one succeeded
- A fetch from linux-full-clone to linux-partial-clone, this one succeeded
(unsurprisingly)
Next I ran git-prune in linux-partial. The fetch then succeeded. Bizarre.
So, the strange result is that it is a difference in the destination directory
that is triggering the error, and whatever that fault is is fixed by
git-cloning that destination repository, or git-pruning the destination.
Unfortunately I've now lost my test case, because the prune fixed it. Bah.
Oh well, this fault can be marked "on hold until I get it to fail again".
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: git-add fails after file type change
From: Steven Grimm @ 2006-12-16 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <7vodq3cxl7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Maybe "git add" should internally use ADD_CACHE_OK_TO_REPLACE
> (or error out and have an option to enable it)?
>
That sounds right to me. Maybe there are cases where this isn't true,
but -- especially given the recent move toward making "git add" the
suggested porcelain command for updating the index -- I want "git add
foo" to stick the current contents of "foo" into the index, regardless
of what might have been there under that name previously. I'll grant
that it's not a super-common use case to rename or delete a directory
and put a file in its place, but it's IMO not an unreasonable thing to
want git to track without undue hassle, given that it claims to support
renames. I'm fine with having to supply an extra option to get that
automatic behavior.
But barring that, the patch would at least have saved me a lot of
head-scratching.
-Steve
^ permalink raw reply
* Re: Subprojects tasks
From: Martin Waitz @ 2006-12-16 22:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, git
In-Reply-To: <7v64cbeeiv.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]
hoi :)
Junio, I'll take a more detailed look at your mail tomorrow, after I
regenerated from all the Guinness I had tonight ;-)
On Sat, Dec 16, 2006 at 01:07:04PM -0800, Junio C Hamano wrote:
> Sven Verdoolaege <skimo@kotnet.org> writes:
> > On Sat, Dec 16, 2006 at 10:32:36AM -0800, Junio C Hamano wrote:
> >> I suspect the hardest part is "rev-list --objects" (now most of
> >> it is found in revision.c). [..] But I think the updated
> >> code needs to know that "link" needs to be unwrapped and
> >> contained "commit" needs to be injected back to the ancestry
> >> walking machinery.
Well, I already got to the point of using the commit directly,
instead of any link object. It even worked with rev-list --objects
in all my test cases. That is, I could correctly clone/pack/pull
the complete project including all modules.
> > Wouldn't we then run into the scalability problems Linus was
> > concerned about ?
This is a real problem.
> If the plumbing layer does not have to (although I haven't
> thought it through, it does feel like it even shouldn't) unwrap
> "link" and let the Porcelain layer to deal with it, that would
> certainly make rev-list/revision.c part simpler.
Yes. However, it makes other things more complicated.
If the plumbing does not do all the subproject stuff and you don't have
everything in one database it is much more difficult to really get
a consistent database when cloning or fetching (you have to get even old
submodule commits which are not reachable by the current supermodule
tree anymore, perhaps even submodules which do not exist anymore).
I did not have much time to think about these issues in the last day and
am not yet convinced on how to proceed,
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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