* Re: Build Failure: GIT-GUI-VARS
From: Brian Gernhardt @ 2007-05-11 14:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v8xbwgkia.fsf@assigned-by-dhcp.cox.net>
On May 10, 2007, at 10:30 PM, Junio C Hamano wrote:
> I do not either, and obviously does not reproduce for me. Time
> for you to try "make -d" perhaps?
Sorry for the semi-coherent message. It started out as "we should
fix this" and I ended up going "why is it broken", all a little too
late at night. I'm also not used to debugging Makefiles.
And I figured it out (make -p actually was more useful than -d):
It's another issue with doing things before including config.mak. My
config.mak includes the "NO_TCLTK=y" line, which takes effect at
Makefile:485. But gitk-wish is getting included in OTHER_PROGRAMS at
Makefile:272. So gitk-wish gets included because NO_TCLTK isn't
defined at that point, but all the other rules involving gitk don't
get executed because they're after the NO_TCLTK definition.
I think we need to be including the config.mak much earlier in the
Makefile as this is not the first time issues like this have come up
for me. And they tend to be issues that only come up with specific
configurations and are therefore harder to track down. Things I can
see being an issue for people who put their options in config.mak:
149: ifeq ($(prefix),/usr)
224: ifdef WITH_P4IMPORT
271: ifndef NO_TCLTK # My issue today
279-285: ifndef {SHELL,PERL,PYTHON}_PATH
~~ Brian
^ permalink raw reply
* Re: git rebase chokes on directory -> symlink -> directory
From: Linus Torvalds @ 2007-05-11 15:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, H. Peter Anvin, Alex Riesen, Git Mailing List
In-Reply-To: <7v8xbvew16.fsf@assigned-by-dhcp.cox.net>
On Thu, 10 May 2007, Junio C Hamano wrote:
>
> And what is wrong in this case is that the unpack-trees tree
> merging code, which is used everywhere in git to do branch
> switching and merges, is way too inefficient.
Yes, it certainly could be speeded up, but on the other hand:
- it's certainly not really "horribly bad" in most normal operations.
In merging, it tends to be fast enough, and in checkouts the real
expense is checking out the tree, and the unpack-trees part really
isn't a big deal.
- the only case it shows up is really just when you script things, and
compare it to just applying a patch, which is fundamnetally easier.
So I think the reason smarter tree merging hasn't gotten the love and
attention to make it really a *lot* faster is simply that it's already
quite fast enough for most people, and the "rebase using proper merges" is
probably the only case where you can really see the difference.
I'd certainly love for the tree unpacking to handle all the "hey, whole
sub-tree is identical" cases, but I can also see why it's not getting a
lot of traction. It just hasn't been painful enough, and we're already too
damn fast.
Fixing the tree unpacking to do the trees in parallel (so that you don't
have to shuffle the arrays and take a huge performance hit there) was
enough to basically make all normal issues go away.
That said, wouldn't it potentially be quite easy in "unpack_trees_rec()"
to just notice when all the trees are identical, and just not recurse at
all in that case (or - alternatively - recurse, but on entry, just exit
quickly?)
Linus
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Johannes Sixt @ 2007-05-11 16:34 UTC (permalink / raw)
To: hanwen; +Cc: Marco Costalba, git
In-Reply-To: <4643EA77.4040803@xs4all.nl>
Han-Wen Nienhuys wrote:
> http://lilypond.org/git/binaries/mingw/git-1.5.1-1.mingw.exe
This resulted in a mostly working git toolset after I've done this in
addition to installing it:
- Installed MSYS (of course ;)
- Install libiconv-2.dll, which can be found in
diffutils-2.8.7-1-dep.zip from
http://sourceforge.net/project/showfiles.php?group_id=2435 (available in
Section Snapshot->MSYS) (rename libiconv2.dll to libiconv-2.dll)
- Set the path to MSYS and Git manually.
For extra bonus points, I should also have installed
bash-3.1-MSYS-1.0.11-snapshot.tar.bz2 (without which 'git am' fails) and
msysDTK-1.0.1.exe for ssh and perl, but I haven't.
gitk and git-gui are untested; they need tcltk-8.4.1-1.exe, of course.
-- Hannes
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Junio C Hamano @ 2007-05-11 16:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200705111326.35577.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Fri, 11 May 2007, Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> In the new version of git I *think* you can use "git add -u path/"
>>
>> I know you meant well, but next time could you please check the
>> fact before speaking?
>
>> if (i < argc)
>> die("-u and explicit paths are incompatible");
>
>> The list is getting more and more cluttered recently, perhaps
>> which is a good sign that more new people are actually using
>> git. Let's try to keep the signal quality of the messages on
>> the list high.
>
> I'm sorry I haven't checked this before writing, especially that
> information in the synopsis contradict a bit the information in
> the `-u' option description:
> ...
> -u::
> Update all files that git already knows about. This is what
> "git commit -a" does in preparation for making a commit.
What does "git commit -a" do? Does it take paths?
> I think however that "git add -u dir/" could be quite useful; it is
> not needed to have `-u' and explicit paths incompatibile.
I tend to agree, and I think that change should not be too
difficult.
Also it might make sense to have "git commit" use it in the
"git-commit --only $paths" codepath. I dunno.
^ permalink raw reply
* [PATCH] git-archive: don't die when repository uses subprojects
From: Lars Hjemli @ 2007-05-11 16:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Both archive-tar and archive-zip needed to be taught about subprojects.
The tar function died when trying to read the subproject commit object,
while the zip function reported "unsupported file mode".
This fixes both by representing the subproject as an empty directory.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
archive-tar.c | 4 ++--
archive-zip.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c
index d9c30d3..56ff356 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -166,7 +166,7 @@ static void write_entry(const unsigned char *sha1, struct strbuf *path,
} else {
if (verbose)
fprintf(stderr, "%.*s\n", path->len, path->buf);
- if (S_ISDIR(mode)) {
+ if (S_ISDIR(mode) || S_ISDIRLNK(mode)) {
*header.typeflag = TYPEFLAG_DIR;
mode = (mode | 0777) & ~tar_umask;
} else if (S_ISLNK(mode)) {
@@ -278,7 +278,7 @@ static int write_tar_entry(const unsigned char *sha1,
memcpy(path.buf, base, baselen);
memcpy(path.buf + baselen, filename, filenamelen);
path.len = baselen + filenamelen;
- if (S_ISDIR(mode)) {
+ if (S_ISDIR(mode) || S_ISDIRLNK(mode)) {
strbuf_append_string(&path, "/");
buffer = NULL;
size = 0;
diff --git a/archive-zip.c b/archive-zip.c
index 7c49848..1eaf262 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -182,10 +182,10 @@ static int write_zip_entry(const unsigned char *sha1,
goto out;
}
- if (S_ISDIR(mode)) {
+ if (S_ISDIR(mode) || S_ISDIRLNK(mode)) {
method = 0;
attr2 = 16;
- result = READ_TREE_RECURSIVE;
+ result = (S_ISDIR(mode) ? READ_TREE_RECURSIVE : 0);
out = NULL;
uncompressed_size = 0;
compressed_size = 0;
--
1.5.2.rc3-dirty
^ permalink raw reply related
* Re: Build Failure: GIT-GUI-VARS
From: Junio C Hamano @ 2007-05-11 17:10 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git Mailing List
In-Reply-To: <5F2FFEA3-0D62-432D-98F7-8BE896937067@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> On May 10, 2007, at 10:30 PM, Junio C Hamano wrote:
>
>> I do not either, and obviously does not reproduce for me. Time
>> for you to try "make -d" perhaps?
>
> Sorry for the semi-coherent message. It started out as "we should fix
> this" and I ended up going "why is it broken", all a little too late
> at night. I'm also not used to debugging Makefiles.
>
> And I figured it out (make -p actually was more useful than -d): It's
> another issue with doing things before including config.mak.
Ahh, config.mak.
I have not been very sympathetic to config.mak from the
beginning, although people seem to want it. As I try to arrange
variable overrides to be passed from the command line anyway,
I've not used config.mak myself.
> I think we need to be including the config.mak much earlier in the
> Makefile as this is not the first time issues like this have come up
> for me.
However, it needs to be able to override NO_*, NEEDS_* and
friends which means it should come after platform specific
defaults. But one platform wants to change the default
behaviour depend on the settings of NO_*, possibly set in
config.mak.
It is a mess. Moving it around would fix one person's problem
while breaking others. I think the best course of action is
(1) first for somebody more fluent in speaking Makefile than me
to volunteer to tackle this problem, and ask help from the
list;
(2) have people on various "non-stock" configurations sign-up
as testers; this does not have to cover the systems listed
in the ifeq ($(uname_S),XXX) part of the current Makefile;
what is of interest is to see what kind of variables are
overridden on the real-world systems via config.mak;
(3) The volunteer cooks up an improved Makefile, using
config.mak "non-stock" testers have.
This would be something that "volunteer" would be deciding, but
I have a feeling that we can have two config.mak include in the
makefile, one early and one late. But I suspect that picking
the right two places would have the same "moving would fix one
while breaking another" issue.
^ permalink raw reply
* Re: [PATCH] read-tree -m -u: avoid getting confused by intermediate symlinks.
From: Junio C Hamano @ 2007-05-11 17:10 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0705110708y7e3a9024p9e117e2da84ae916@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> On 5/11/07, Junio C Hamano <junkio@cox.net> wrote:
>> @@ -268,6 +268,8 @@ static void unlink_entry(char *name)
>> {
>> char *cp, *prev;
>>
>> + if (has_symlink_leading_path(name))
>> + return;
>
> This can slow down the unlink case quiet considerably.
> Maybe the symlink paths can be cached?
Yes it can, and probably doable.
This is called once per each path that disappears from the
result, relative to the current tree. The number of calls to
this function is potentially quite large.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2-rc3
From: Junio C Hamano @ 2007-05-11 17:10 UTC (permalink / raw)
To: Martin Waitz; +Cc: Alexander Litvinov, git
In-Reply-To: <20070511090201.GC24971@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> Perhaps we should not advertise submodule support that prominently.
> I think we should wait for nice porcelain support before can put it at
> the top of the release announcements.
I understand your point, but I tend to disagree.
> Otherwise we get much too many expectations and too many questions about
> how to use it.
Actually, that is probably a good thing.
As we (including you, whose initial work was instrumental to
stir the discussion that led to the one by Linus) answer them
here, we will accumulate bodies of text that describe what can
be done today, what are missing, what needs to be recursive and
what approaches we can take in the Porcelains. Somebody can
summarize and write documentation pages and to-do list out of
that.
^ permalink raw reply
* Re: [PATCH] [TRIVIAL] Change default man page path to /usr/share/man
From: Ismail Dönmez @ 2007-05-11 17:25 UTC (permalink / raw)
To: git
In-Reply-To: <200705081349.34964.ismail@pardus.org.tr>
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
On Tuesday 08 May 2007 13:49:31 you wrote:
> Hi,
>
> According to FHS standard default man page path is $prefix/share/man [0] ,
> attached patch fixes this for GIT.
>
> [0] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES
>
> Signed-off-by: Ismail Donmez <ismail@pardus.org.tr>
ACK? NAK? Do we care about this? :)
Patch attached again for convenience.
Regards,
ismail
--
Perfect is the enemy of good
[-- Attachment #2: mandir.patch --]
[-- Type: text/x-diff, Size: 298 bytes --]
--- Documentation/Makefile 2007-02-26 21:20:28.000000000 +0200
+++ Documentation/Makefile 2007-02-28 01:18:07.672166995 +0200
@@ -26,7 +26,7 @@
prefix?=$(HOME)
bindir?=$(prefix)/bin
-mandir?=$(prefix)/man
+mandir?=$(prefix)/share/man
man1dir=$(mandir)/man1
man7dir=$(mandir)/man7
# DESTDIR=
^ permalink raw reply
* Re: svn user trying to recover from brain damage
From: Jakub Narebski @ 2007-05-11 17:29 UTC (permalink / raw)
To: git
In-Reply-To: <92fdc3450705090830t64c8f5b9r4af277807dfe834d@mail.gmail.com>
[Cc: Joshua Ball <sciolizer@gmail.com>, git@vger.kernel.org]
Joshua Ball wrote:
> What the heck do these terms mean? The glossary on the Git wiki was
> unhelpful (I'll explain later).
Glossary at GitWiki, http://git.or.cz/gitwiki/GitGlossary is
wikification of "GIT Glossary" from Documentation/glossary.txt
distributed with git-core and installed usually under
/usr/share/doc/git-core-<version>/glossary.html
but also available at
http://www.kernel.org/pub/software/scm/git/doc/glossary.html
This wiki page was created for GitWiki to be self contained
(to be able to reference to anchor in GitGlossary when referring
to some term which needs explanation), and also to be able to add
some links to wiki pages in wikified GitGlossary. This wiki page
is probably a bit outdated.
> head
> head ref
> working tree
> object
> branch
> merge
> master
> commit (as in the phrase "bring the working tree to a given commit")
>
> While the Git wiki does in fact define all of these, it doesn't answer
> any of my questions about those terms:
[cut]
I hope that the following mini-tutorial with some explanations would
help you understand those terms, and clean some SVN misconceptions.
In git history itself is separated from the references to it; when cloning
or fetching from other repository, you get and append missing parts of
history, but the refs on the remote and on local side does not need to
have the same names. In the ascii-art graphs of history objects which
are in "object database" (in history) are on the left, and references
to history are on the right.
/------ object database -----------\ /------- refs --------\
Let's start with the following history (the following repository
structure)
A <-- B <-- C <-- D <----------------- master <------- HEAD
$ git branch branchA
(does not change working directory)
A <-- B <-- C <-- D <----------------- master <------- HEAD
\
\
\--------------- branchA
Branching does not create copy of revisions so far (even if it is
cheap copy like in the case of Subversion). You can always find
the place where branches diverge; it is recorded in repository.
"git merge-base master branchA" returns [id of] revision D.
Creating a branch is just creating a pointer (reference) to some
commit. Head ref, or just a head is this pointer, e.g. 'branchA'
(it resides in $GIT_DIR/refs/heads/branchA). Commit D is often
called branch tip. Branch as a non-cyclical graph of revisions
is, in the case of 'branchA', branch history of commit D including
this commit, i.e. A<--B<--C<--D DAG.
HEAD (case sensitive, all uppercase) is current branch, usuually
pointer to some other branch.
$ git checkout branchA
(changes working directory, updates HEAD)
A <-- B <-- C <-- D <----------------- master /- HEAD
\ /
\ /
\--------------- branchA <-/
Those two above steps can be combined to single command
$ git checkout -b branchA
$ edit; edit; ... (changes working directory)
$ git commit -a
(this creates new commit object E, updates branchA ref, i.e.
ref pointed by HEAD, aka. current branch [head])
A <-- B <-- C <-- D <----------------- master /- HEAD
\ /
\ /
\- E <----------- branchA <-/
Committing (commit as verb) creates commit object E (commit as noun),
and advances branch head to the newly created commit.
$ git checkout master
$ edit; edit; ...
$ git commit -a
A <-- B <-- C <-- D <-- F <------------ master <----- HEAD
\
\
\- E <----------- branchA
Note that "git commit" advances current branch head / tip of current
branch, i.e. branch pointed to by HEAD reference.
$ git merge branchA
This does equivalent of doing "diff3 -E F D E", i.e. 3-way merge on
file level, or "diff3 -E HEAD $(git merge-base HEAD branchA) branchA"
A <-- B <-- C <-- D <-- F <-- G <------ master <----- HEAD
\ /
\ /
\- E- <---------- branchA
Merging (merge as verb) creates merge commit [object] G (merge as noun).
Commit object G has commits G and E as parents (more than one parent).
The information that G is result of merge is recorded in commit
[object] G.
If you have noticed that you want to discard the merge, for example
you don't want to merge yet, i.e. you want to return to state before
merge you can do:
$ git reset --hard ORIG_HEAD
(updates current branch, *does not* update HEAD as a ref,
contrary to git-checkout)
|------\
v \
A <-- B <-- C <-- D <-- F <-- G \----- master <----- HEAD
\ /
\ /
\- E- <---------- branchA
Assume situation at the graph before
$ git checkout branchA
$ edit; edit; ...
$ git commit -a
(creates commit H)
$ git checkout master
$ git merge branchA
This time, because merge is recorded as such, the merge base between
'master' branch (branch we merge into) and 'branchA' (branch being
merged) is commit E. Git knows that it has to merge only changes
accumulated since last merge.
A <-- B <-- C <-- D <-- F <-- G <- J <- master <----- HEAD
\ / /
\ / /
\- E-<-- H <------ branchA
> In the words of Dijkstra, "Since breaking out of bad habits, rather
> than acquiring new ones, is the toughest part of learning, we must
> expect from that system permanent mental damage for most ... exposed
> to it."
>
> May you lead me to a quick recovery. Hail to decentralized version control.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git rebase chokes on directory -> symlink -> directory
From: Junio C Hamano @ 2007-05-11 17:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: Shawn O. Pearce, H. Peter Anvin, Alex Riesen, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0705110835230.3986@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> That said, wouldn't it potentially be quite easy in "unpack_trees_rec()"
> to just notice when all the trees are identical, and just not recurse at
> all in that case (or - alternatively - recurse, but on entry, just exit
> quickly?)
In the threeway case, it should be able to notice that the trees
of the ancestor and the other match, which is the only case we
can safely say that the result will be our tree (aka HEAD) and
we won't mess with the index nor worry about local modifications
made only to the working tree. The case in which all trees
match, regardless of the number of trees involved, should work
the same way.
However, in the threeway case, we still need to make sure that
the index matches the HEAD even when we know the result will be
taken from HEAD, as otherwise we would end up including the
local "git add" made earlier in the merge result. We need to
make sure the index matches HEAD for such a subdirectory in that
case before skipping it.
What is troublesome is that kind of policy logic is not supposed
to happen in unpack_trees_rec() in the current code structure;
instead, that decision is to be made by o->fn().
So, I am not sure if it is that quite easy.
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Han-Wen Nienhuys @ 2007-05-11 17:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Marco Costalba, git
In-Reply-To: <46449B0D.5FCD66F1@eudaptics.com>
2007/5/11, Johannes Sixt <J.Sixt@eudaptics.com>:
> Han-Wen Nienhuys wrote:
> > http://lilypond.org/git/binaries/mingw/git-1.5.1-1.mingw.exe
>
> This resulted in a mostly working git toolset after I've done this in
> addition to installing it:
>
> - Installed MSYS (of course ;)
> - Install libiconv-2.dll, which can be found in
> diffutils-2.8.7-1-dep.zip from
Can you be more specific? Which files required this?
It is entirely coincidental that another DLL from another package
works, and it's a bug in our packaging.
The path to Git should also have been set automatically. I will look into this.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] [TRIVIAL] Change default man page path to /usr/share/man
From: Linus Torvalds @ 2007-05-11 17:42 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: git
In-Reply-To: <200705112025.58095.ismail@pardus.org.tr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 374 bytes --]
On Fri, 11 May 2007, Ismail Dönmez wrote:
>
> ACK? NAK? Do we care about this? :)
I'll Ack it, for what it's worth.
As it is, I actually end up doing
make prefix=/usr/local/share install-doc
(or something like that) to get things in the right place.
I think the old "$(prefix)/man" is just because I still mentally live in
the early 90's most of the time.
Linus
^ permalink raw reply
* Re: [PATCH] [TRIVIAL] Change default man page path to /usr/share/man
From: Junio C Hamano @ 2007-05-11 19:27 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: git
In-Reply-To: <200705112025.58095.ismail@pardus.org.tr>
Ismail Dönmez <ismail@pardus.org.tr> writes:
> On Tuesday 08 May 2007 13:49:31 you wrote:
>> Hi,
>>
>> According to FHS standard default man page path is $prefix/share/man [0] ,
>> attached patch fixes this for GIT.
>>
>> [0] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES
>>
>> Signed-off-by: Ismail Donmez <ismail@pardus.org.tr>
>
> ACK? NAK? Do we care about this? :)
I would not say the patch is wrong per-se, but:
- People who do not override prefix to install in $HOME would
suddenly get their mandir under $HOME/share/man; the fact
nobody complained so far suggests me that these people have
$MANPATH pointing at $HOME/man, which means your patch breaks
things for them, unless they have been overriding mandir in
which case your patch does not matter to them;
- Distros who package git and want to conform to FHS would have
been overriding not just prefix but mandir anyway, so your patch
is not an improvement to them;
- People who override prefix to install locally in /usr or
/usr/local does "make prefix=" thing anyway, and the fact
nobody complained so far suggests me that they have already
known they need to override mandir as well if they do not
like /usr/local/man, so your patch is not an improvement to
them.
That makes one half negative plus two and half neutral.
^ permalink raw reply
* Re: [PATCH] [TRIVIAL] Change default man page path to /usr/share/man
From: Ismail Dönmez @ 2007-05-11 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v646zb1p4.fsf@assigned-by-dhcp.cox.net>
On Friday 11 May 2007 22:27:35 you wrote:
> Ismail Dönmez <ismail@pardus.org.tr> writes:
> > On Tuesday 08 May 2007 13:49:31 you wrote:
> >> Hi,
> >>
> >> According to FHS standard default man page path is $prefix/share/man [0]
> >> , attached patch fixes this for GIT.
> >>
> >> [0] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES
> >>
> >> Signed-off-by: Ismail Donmez <ismail@pardus.org.tr>
> >
> > ACK? NAK? Do we care about this? :)
>
> I would not say the patch is wrong per-se, but:
>
> - People who do not override prefix to install in $HOME would
> suddenly get their mandir under $HOME/share/man; the fact
> nobody complained so far suggests me that these people have
> $MANPATH pointing at $HOME/man, which means your patch breaks
> things for them, unless they have been overriding mandir in
> which case your patch does not matter to them;
Or nobody is reading man pages? *g*
> - Distros who package git and want to conform to FHS would have
> been overriding not just prefix but mandir anyway, so your patch
> is not an improvement to them;
True that.
> - People who override prefix to install locally in /usr or
> /usr/local does "make prefix=" thing anyway, and the fact
> nobody complained so far suggests me that they have already
> known they need to override mandir as well if they do not
> like /usr/local/man, so your patch is not an improvement to
> them.
Most(All?) distros /usr/share/man in MANPATH so I believe this patch shouldn't
break anything but well you have the final say. I am ok with doing
make mandir=/usr/share/man install-doc .
Regards,
ismail
--
Perfect is the enemy of good
^ permalink raw reply
* Re: [PATCH] [TRIVIAL] Change default man page path to /usr/share/man
From: Junio C Hamano @ 2007-05-11 19:44 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: git
In-Reply-To: <200705112242.44618.ismail@pardus.org.tr>
Ismail Dönmez <ismail@pardus.org.tr> writes:
> Most(All?) distros /usr/share/man in MANPATH so I believe this
> patch shouldn't break anything but well you have the final
> say. I am ok with doing make mandir=/usr/share/man install-doc
My preference is to do this early after 1.5.2. I do not want to
touch builds with trivial changes before the final.
^ permalink raw reply
* Re: [PATCH] [TRIVIAL] Change default man page path to /usr/share/man
From: Ismail Dönmez @ 2007-05-11 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwszf9md5.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
On Friday 11 May 2007 22:44:06 Junio C Hamano wrote:
> Ismail Dönmez <ismail@pardus.org.tr> writes:
> > Most(All?) distros /usr/share/man in MANPATH so I believe this
> > patch shouldn't break anything but well you have the final
> > say. I am ok with doing make mandir=/usr/share/man install-doc
>
> My preference is to do this early after 1.5.2. I do not want to
> touch builds with trivial changes before the final.
Ok with me, thank you.
Regards,
ismail
--
Perfect is the enemy of good
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Another fast-import/import-tars issue
From: Chris Riddoch @ 2007-05-11 20:08 UTC (permalink / raw)
To: git
Hi, folks.
I believe I've uncovered an issue in fast-import, but I don't know the
code well enough yet to debug it. So, I'll produce my evidence and
let others work on finding the solution. It should be pretty easy to
reproduce.
First, I'm running: 1.5.2.rc1.9.g6644
Grab the tarball of Perl 5.8.8 - http://www.perl.com/CPAN/src/perl-5.8.8.tar.bz2
Note its md5, just so you know it's not corrupted from the outset.
b8c118d4360846829beb30b02a6b91a7 perl-5.8.8.tar.gz
a377c0c67ab43fd96eeec29ce19e8382 perl-5.8.8.tar.bz2
Try this:
$ tar -xjf perl-5.8.8.tar.bz2
$ cd perl-5.8.8
$ git init
$ git add .
$ git commit -a -m "Import from working tree copy"
Now, for convenience of debugging, I have myself a script I call
~/bin/fast-import-filter.sh:
#!/bin/bash
tee fast-import.log | git fast-import --quiet
Then, I have a slightly-changed ~/bin/import-tars script, like so:
20c20,21
< open(FI, '|-', 'git', 'fast-import', '--quiet')
---
> #open(FI, '|-', 'git', 'fast-import', '--quiet')
> open(FI, '|-', 'fast-import-filter.sh')
Now,
$ import-tars.pl ../perl-5.8.8.tar.bz2
Okay, so the trees pointed to by the tips of the master and
import-tars branches *should* be identical here, right?
$ git diff-tree master: import-tars: | wc -l
229
Not so good.
--
epistemological humility
Chris Riddoch
^ permalink raw reply
* how to set up e-mail notification?
From: Oliver Kullmann @ 2007-05-11 19:55 UTC (permalink / raw)
To: git
Hello,
I have set up a Git repository as a shared repository as described in
the CVS-to-Git conversion manual.
Now I want this shared Git repository to send out notification e-mails
after commits, simulating what with CVS was achieved by
adding to CVSROOT/loginfo the lines
---------------------
# CVS notifications to all users on commit
ALL (echo ""; echo %{sVv}; date; cat) | mutt -s "OKlibrary CVS Commit
-- $USER" e-mail-address_1 e-mail-address_2
---------------------
Now I understand that I shall make
hooks/post-commit
executable, and then fill the file with some script which will send
the e-mails: But apparently this script does not have any parameters,
that is, no information is supplied to it?
So the idea is to write some program which reads the last commit and extracts
the information from the git-repository, and sends the e-mail?
Now I would guess many others have already solved that task, and so I would
be glad it they could tell me such a little script (standard Linux environment).
Thanks in any case!
Oliver
^ permalink raw reply
* Re: [PATCH] user-manual: Use "git config --global" instead of editing ~/.gitconfig
From: Jan Hudec @ 2007-05-11 20:23 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Petr Baudis, Johan Herland, git
In-Reply-To: <20070511034653.GB26896@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]
On Thu, May 10, 2007 at 23:46:53 -0400, J. Bruce Fields wrote:
> On Fri, May 11, 2007 at 01:00:45AM +0200, Petr Baudis wrote:
> > However, in that case I think this is not the good point to show
> > ~/.gitconfig. Your goal at that point should be to get the user able
> > to commit as simply as possible,
>
> Sure.
I would vote for telling users both ways to do it on that spot.
Something along the lines:
git-config --global user.email ...
git-config --global user.name ...
Alternatively, you can edit ~/.gitconfig and add the following:
{{{
[user]
email = ...
name = ...
}}}
I don't like the current description with cat or echo or what it is though.
It requires more thinking than necessary and especially as the mingw port
progresses there will be more Windows users to whom this will be totaly
confusing.
> > and having to manually edit some config file is unnecessary hassle
> > when you can just use these two simple commands;
>
> I don't get it; why are the two commands "simple", and editing a file a
> "hassle"? In terms of, say, time required, or number of keystrokes, I
> suspect the two are about the same. And it seems to me that:
>
> - As users of a tool designed mainly to track changes to text
> files, git users are likely to be pretty proficient at editing
> text files.
> - People also need to be able to view the configuration and
> change it. If they make a typo on the first try, they may
> need to do this sooner rather than later. With a config file,
> this is trivial. With git-config, you have to learn at least
> one new thing (how to query values).
> - The config file is easier to read than the git-config output.
> - You're going to have to edit some text anyway to plug your
> name in, so we can't make this a pure cut-n-paste from the
> docs.
Well, I would not say editing the difference is that big, but I do think it's
easier to call two commands. Maybe it's psychological "I have to write
something to get it working", even though it's actually less keystrokes than
calling the commands.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Johannes Sixt @ 2007-05-11 20:07 UTC (permalink / raw)
To: git, hanwen; +Cc: Marco Costalba
In-Reply-To: <f329bf540705111035v4a6f0b23w49f04c768a410069@mail.gmail.com>
On Friday 11 May 2007 19:35, Han-Wen Nienhuys wrote:
> 2007/5/11, Johannes Sixt <J.Sixt@eudaptics.com>:
> > Han-Wen Nienhuys wrote:
> > > http://lilypond.org/git/binaries/mingw/git-1.5.1-1.mingw.exe
> >
> > This resulted in a mostly working git toolset after I've done this in
> > addition to installing it:
> >
> > - Installed MSYS (of course ;)
> > - Install libiconv-2.dll, which can be found in
> > diffutils-2.8.7-1-dep.zip from
>
> Can you be more specific? Which files required this?
git.exe, for example, hence, at least all builtins.
> It is entirely coincidental that another DLL from another package
> works, and it's a bug in our packaging.
Why should this not work? The diffutils package I mentioned is from MinGW.
Anyway, I think we should not link against libiconv*.dll at all because it
slows down the startup too much.
> The path to Git should also have been set automatically. I will look into
> this.
Well, I did not reboot, or log out and in again. I just opened a CMD after the
installation was complete. Usually, CMD picks up new PATHs if they have been
modified via the Settings->System->Advanced (or whatsitcalled) tool. So, I
thought it would be the same with installations.
-- Hannes
^ permalink raw reply
* [PATCH] Allow fetching references from any namespace
From: Alex Riesen @ 2007-05-11 20:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
not only from the three defined: heads, tags and remotes.
Noticed when I tried to fetch the references created by git-p4-import.bat:
they are placed into separate namespace (refs/p4import/, to avoid showing
them in git-branch output). As canon_refs_list_for_fetch always prepended
refs/heads/ it was impossible, and annoying: it worked before. Normally,
the p4import references are useless anywhere but in the directory managed
by perforce, but in this special case the cloned directory was supposed
to be a backup, including the p4import branch: it keeps information about
where the imported perforce state came from.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
git-parse-remote.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 437b0c3..0506b12 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -143,13 +143,13 @@ canon_refs_list_for_fetch () {
fi
case "$remote" in
'' | HEAD ) remote=HEAD ;;
- refs/heads/* | refs/tags/* | refs/remotes/*) ;;
+ refs/*) ;;
heads/* | tags/* | remotes/* ) remote="refs/$remote" ;;
*) remote="refs/heads/$remote" ;;
esac
case "$local" in
'') local= ;;
- refs/heads/* | refs/tags/* | refs/remotes/*) ;;
+ refs/*) ;;
heads/* | tags/* | remotes/* ) local="refs/$local" ;;
*) local="refs/heads/$local" ;;
esac
--
1.5.2.rc3.17.ge713
^ permalink raw reply related
* Re: [PATCH] read-tree -m -u: avoid getting confused by intermediate symlinks.
From: Junio C Hamano @ 2007-05-11 20:38 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <7vwszfb80y.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
>> On 5/11/07, Junio C Hamano <junkio@cox.net> wrote:
>>> @@ -268,6 +268,8 @@ static void unlink_entry(char *name)
>>> {
>>> char *cp, *prev;
>>>
>>> + if (has_symlink_leading_path(name))
>>> + return;
>>
>> This can slow down the unlink case quiet considerably.
>> Maybe the symlink paths can be cached?
>
> Yes it can, and probably doable.
>
> This is called once per each path that disappears from the
> result, relative to the current tree. The number of calls to
> this function is potentially quite large.
-- >8 --
has_symlink_leading_path(): cache the last lookup
This is on top of the previous one to implement a single-entry
cache for symlinks. The idea is that:
* The caller optionally allocates a buffer to hold the symlink
that caused the check to succeed and passes it in. This is
an in-out parameter that the check reuses the result from the
previous round;
* Because we call things in the index order, removed entries
under what used to be a directory but now is a symlink
cluster together. The has_symlink_leading_path() function
will return true because they are under the same symlink;
* When we see a "this is updated/created" entry, we know we are
no longer inside the directory that previous round of
last_symlink is useful, so we can clear the cached value.
So the calling sequence becomes:
char last_symlink[PATH_MAX];
*last_symlink = '\0';
for each index entry {
if (lose)
unlink_entry(it, last_symlink);
else if (update) {
checkout_entry(it);
*last_symlink = '\0';
}
---
diff --git a/builtin-apply.c b/builtin-apply.c
index 01acba8..8b8705a 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2022,7 +2022,7 @@ static int check_to_create_blob(const char *new_name, int ok_if_exists)
* In such a case, path "new_name" does not exist as
* far as git is concerned.
*/
- if (has_symlink_leading_path(new_name))
+ if (has_symlink_leading_path(new_name, NULL))
return 0;
return error("%s: already exists in working directory", new_name);
diff --git a/cache.h b/cache.h
index ab66263..aaeb04a 100644
--- a/cache.h
+++ b/cache.h
@@ -410,7 +410,7 @@ struct checkout {
};
extern int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *topath);
-extern int has_symlink_leading_path(const char *name);
+extern int has_symlink_leading_path(const char *name, char *last_symlink);
extern struct alternate_object_database {
struct alternate_object_database *next;
diff --git a/symlinks.c b/symlinks.c
index cfecfcf..ee3f914 100644
--- a/symlinks.c
+++ b/symlinks.c
@@ -1,6 +1,6 @@
#include "cache.h"
-int has_symlink_leading_path(const char *name)
+int has_symlink_leading_path(const char *name, char *last_symlink)
{
char path[PATH_MAX];
const char *sp, *ep;
@@ -9,6 +9,16 @@ int has_symlink_leading_path(const char *name)
sp = name;
dp = path;
+ if (last_symlink && *last_symlink) {
+ size_t last_len = strlen(last_symlink);
+ size_t len = strlen(name);
+ if (last_len < len &&
+ !strncmp(name, last_symlink, last_len) &&
+ name[last_len] == '/')
+ return 1;
+ *last_symlink = '\0';
+ }
+
while (1) {
size_t len;
struct stat st;
@@ -24,8 +34,11 @@ int has_symlink_leading_path(const char *name)
if (lstat(path, &st))
return 0;
- if (S_ISLNK(st.st_mode))
+ if (S_ISLNK(st.st_mode)) {
+ if (last_symlink)
+ strcpy(last_symlink, path);
return 1;
+ }
dp[len++] = '/';
dp = dp + len;
diff --git a/unpack-trees.c b/unpack-trees.c
index a6fa32f..906ce69 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -264,11 +264,11 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
* directories, in case this unlink is the removal of the
* last entry in the directory -- empty directories are removed.
*/
-static void unlink_entry(char *name)
+static void unlink_entry(char *name, char *last_symlink)
{
char *cp, *prev;
- if (has_symlink_leading_path(name))
+ if (has_symlink_leading_path(name, last_symlink))
return;
if (unlink(name))
return;
@@ -293,11 +293,12 @@ static void unlink_entry(char *name)
static struct checkout state;
static void check_updates(struct cache_entry **src, int nr,
- struct unpack_trees_options *o)
+ struct unpack_trees_options *o)
{
unsigned short mask = htons(CE_UPDATE);
unsigned cnt = 0, total = 0;
struct progress progress;
+ char last_symlink[PATH_MAX];
if (o->update && o->verbose_update) {
for (total = cnt = 0; cnt < nr; cnt++) {
@@ -311,6 +312,7 @@ static void check_updates(struct cache_entry **src, int nr,
cnt = 0;
}
+ *last_symlink = '\0';
while (nr--) {
struct cache_entry *ce = *src++;
@@ -319,13 +321,15 @@ static void check_updates(struct cache_entry **src, int nr,
display_progress(&progress, ++cnt);
if (!ce->ce_mode) {
if (o->update)
- unlink_entry(ce->name);
+ unlink_entry(ce->name, last_symlink);
continue;
}
if (ce->ce_flags & mask) {
ce->ce_flags &= ~mask;
- if (o->update)
+ if (o->update) {
checkout_entry(ce, &state, NULL);
+ *last_symlink = '\0';
+ }
}
}
if (total)
^ permalink raw reply related
* Re: Using StGIT for tweaking already-committed stuff
From: Yann Dirson @ 2007-05-11 20:40 UTC (permalink / raw)
To: Petr Baudis, Carl Worth, J. Bruce Fields, Linus Torvalds,
Johannes Sixt, catalin.marinas, git
In-Reply-To: <20070510222347.GB12366@diana.vm.bytemark.co.uk>
On Fri, May 11, 2007 at 12:23:47AM +0200, Karl Hasselström wrote:
> On 2007-05-10 22:02:53 +0200, Petr Baudis wrote:
> > Yes, I fear that StGIT hides the index in a similar way that Cogito
> > does. It seems like user index usage is undergoing kind of
> > renaissance these days in Git community (at least it seems to me
> > this way, maybe it's always been this way), it would probably make
> > sense to allow making use of index in StGIT as well.
>
> I agree. It's bad UI for StGIT to behave different from git, given
> that easy interoperation is a goal.
Well, that's an idea that already appeared in some discussions - I
can't speak for Catalin, but I too think it could be a good thing.
Eg, if we're going to use the patchlogs a bit more (and I wish so), it
will be much less cluttered by using the index to select what to
commit with several git-add's, than when using several stg-refresh's.
As noted elsewhere, there are some commands that are a bit superfluous
(add, rm, and the branch-switching feature directly come to mind). It
is especially annoying, eg when "stg rm" behaves differently than "git
rm", by not removing the real file. I have tried recently to avoid
using "git add" and "stg rm", and I am quite pleased with that :)
> > And yes, it would be cool if stg new could guess patch name from the
> > subject line in a similar manner that stg uncommit does.
>
> Good idea. This would be embarrassingly easy to do.
>
> But you can kind of do it today. Just commit with git (my favorite
> here is the emacs modes) and "stg assimilate"!
Well, that's arguably a non-orthodox way of doing things, I like the
idea your "stg new" patch much better :)
Best regards,
--
Yann.
^ permalink raw reply
* Re: StGit: Notice: no parent remote declared for stack
From: Yann Dirson @ 2007-05-11 20:47 UTC (permalink / raw)
To: Rajkumar S; +Cc: git
In-Reply-To: <64de5c8b0704192220j6f5f9493md91a33f537ebb25@mail.gmail.com>
Sorry for the late answer - this mail has been stagnating in my
"postponed folder".
On Fri, Apr 20, 2007 at 10:50:49AM +0530, Rajkumar S wrote:
> I am following another git repository with StGit. In the remote
> repository I am following RELENG_1_2 branch.
>
> I created the StGit repository using stg clone and then changed to
> RELENG_1_2 branch and did a stg init and edited the
> git/remotes/origin to
>
> URL: /usr/local/upstream/.git
> Pull: refs/heads/RELENG_1_2:refs/heads/RELENG_1_2
You are not using git 1.5, are you ? 1.5 uses the new separate-remote
layout, which should setup something similar for you.
>
> When I do an stg pull I get the following error:
>
> Notice: no parent remote declared for stack "RELENG_1_2", defaulting
> to "origin". Consider setting "branch.RELENG_1_2.remote" and
> "branch.RELENG_1_2.merge" with "git repo-config".
>
> What should I set branch.RELENG_1_2.remote and branch.RELENG_1_2.merge
> to ?
It will tell git-pull from which remote repository and branch to pull.
In your case, the default remote "origin", is correct, but stgit (and
git) cannot guess the branch to merge from.
> a sample command would be very helpful as I am not very much upto
> speed with git repo-config
If you have cloned this repo to work on it, I suppose what you want is
a patch stack that branches off the remote RELENG_1_2 branch.
git-clone will have already mirrored it locally to
remotes/origin/RELENG_1_2, so you don't need to edit the remote
definition to add it under refs/heads.
Here is an example, the conf for my main stgit branch, forked off
Catalin's master branch. Note that "branch.master.merge" refers to
the head in the remote repository, not to where it is stored locally.
Also note that branch.master.stgit.pull-policy is only honored by the
development version of stgit (ie. not 1.12.x).
[remote "origin"]
url = http://homepage.ntlworld.com/cmarinas/stgit.git
fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "master.stgit"]
pull-policy = fetch-rebase
Best regards,
--
Yann.
^ 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