* Re: Wrong time in git-log when using right/ timezone
From: Julian Phillips @ 2007-07-18 17:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Peter Hartlich, git
In-Reply-To: <alpine.LFD.0.999.0707180948080.27353@woody.linux-foundation.org>
On Wed, 18 Jul 2007, Linus Torvalds wrote:
> ie apparently Berlin is in a timezone of its own that is roughly one
> minute and 23 seconds away from CET.
>
> What the *heck*?
>
> I really don't think this is git that is confused: I get the exact same
> thing with "date" too:
>
> [torvalds@woody git]$ TZ=right/Europe/Berlin date ; TZ=CET date
> Wed Jul 18 18:52:25 CEST 2007
> Wed Jul 18 18:52:48 CEST 2007
>
> so it really *is* the tzdata that says that Berlin is not +0200, and it's
> not even +0159, it's something really strange with fractional minutes away
> from UTC.
Well ... not if you compare right/Europe/Berlin vs right/CET
jp3@neutron: ~>TZ=right/CET date '+%H:%M:%S %z'; TZ=right/Europe/Berlin
date '+%H:%M:%S %z'
19:49:45 +0200
19:49:45 +0200
but, I suspect that the following is the underlying cause of the problem?
jp3@neutron: ~>TZ=right/UTC date '+%H:%M:%S %z'; TZ=UTC date '+%H:%M:%S
%z'
17:51:32 +0000
17:51:55 +0000
Is git working internally in TZ=UTC?
--
Julian
---
Homer: We always have one good kid and one lousy kid. Why can't both
our kids be good?
Marge: We have three kids, Homer.
Separate Vacations
^ permalink raw reply
* Re: Empty directories...
From: David Kastrup @ 2007-07-18 17:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707180925030.27353@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But I do want to point out that "tracking a directory" is not at all
> the same thing as "tracking a file", no matter how much you try to
> argue otherwise.
Since I did not try to argue this, could you beat another strawman?
I have seen this prepackaged rant already, but it does not really
address the problem I have been experiencing.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Empty directories...
From: David Kastrup @ 2007-07-18 17:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.LFD.0.999.0707180912430.27353@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 18 Jul 2007, David Kastrup wrote:
>
>> b) The problem is not just that empty directories don't get added
>> into the repository. They also don't get removed again when
>> switching to a different checkout.
>
> Bzzt. Wrong.
>
> We *do* remove directories when all files under them go away.
But empty directories which were empty to start with don't go away
since they are not tracked. And that means that their parents don't
go away.
Git will remove directories which _had_ git-tracked content prior to
the checkout. But it will not register empty directories created
outside of git, and consequently will not remove them.
> HOWEVER (and this is where one of the reasons for not tracking them
> comes in):
>
> ** YOU CANNOT REMOVE A DIRECTORY IF IT HAS SOME UNTRACKED CONTENTS **
>
> Think about that for five seconds, then think about it some
> more. Ponder it.
Linus, condescension is all very nice, but I already told you: I had a
directory hierarchy created outside of git's control (every file comes
into being first outside of git). This hierarchy contained empty
directories. The while hierarchy was committed into git. git
silently skipped registering empty directories. Then a different
version got checked out which did not contain the directory hierarchy
in question. And git left the (unregistered) empty directories in, as
well as all their parent directories.
And that is just plain wrong.
> So the fact is, git *already* does ass good of a job as it could
> possibly do wrt directories that go away: it tries to remove them if
> all the files that are tracked in it have gone away.
But I told git to track the whole directory tree recursively. There
were no uncommitted files it complained about. It is not reasonable
that it is afterwards unable to remove this when I checkout some other
tag.
> A SCM *must*not* just remove that directory. It would be
> horrible. The fact that it has untracked files in it does not make
> those untracked files "unimportant".
Sure. But that it refuses to track the files makes the total behavior
an annoyance. I don't complain _how_ git handles not being able to
track empty directories. I complain about it not being able to track
them in the first place. The consequences are hideous.
> Maybe you feel that way about object files, but what about tracking
> some important parts of your home directory - does the fact that you
> don't necessarily track *all* of it mean that the rest is totally
> unimportant adn that git should just remove it? HELL NO!
When I tell it to track it, it should not refuse. Even if it is
empty. Because if it _stayed_ empty, git can then remove it (and
possibly the parents) when I checkout something else.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Empty directories...
From: Linus Torvalds @ 2007-07-18 17:06 UTC (permalink / raw)
To: Matthieu Moy; +Cc: David Kastrup, Johannes Schindelin, git
In-Reply-To: <vpq4pk1vf7q.fsf@bauges.imag.fr>
On Wed, 18 Jul 2007, Matthieu Moy wrote:
>
> If you checkout a branch, create an empty directory in this branch
> (probably a placeholder, either for future versionned files, or for
> generated files), you cannot tell git "this empty directory is in this
> branch, but not in other ones" without adding a file in it.
Right. Which is the suggested setup: add an empty ".gitignore" file to the
directory, and you're done. It now acts "as if" git tracked the directory
(git will remove the directory when switching branches), but without the
lie that we really track any directory contents.
Linus
^ permalink raw reply
* Re: Wrong time in git-log when using right/ timezone
From: Linus Torvalds @ 2007-07-18 17:01 UTC (permalink / raw)
To: Peter Hartlich; +Cc: git
In-Reply-To: <20070718153614.GA28815@hartlich.com>
On Wed, 18 Jul 2007, Peter Hartlich wrote:
>
> My timezone is set to right/Europe/Berlin. git-log 1.5.2.2 gives me
> output such as:
>
> | Date: Wed Jul 18 16:17:31 2007 +0159
>
> Note the timezone, which should be +0200.
Wow. I just tried:
git show --raw --date=local
with TZ=CET and TZ=right/Europe/Berlin respectively.
Trippy.
I get:
commit 9dfdf14b3805e89aa2782458bda15b3dfae24c09
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jul 16 01:41:17 2007
for the CET case, but for right/Europe/Berlin I get:
commit 9dfdf14b3805e89aa2782458bda15b3dfae24c09
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jul 16 01:39:54 2007
ie apparently Berlin is in a timezone of its own that is roughly one
minute and 23 seconds away from CET.
What the *heck*?
I really don't think this is git that is confused: I get the exact same
thing with "date" too:
[torvalds@woody git]$ TZ=right/Europe/Berlin date ; TZ=CET date
Wed Jul 18 18:52:25 CEST 2007
Wed Jul 18 18:52:48 CEST 2007
so it really *is* the tzdata that says that Berlin is not +0200, and it's
not even +0159, it's something really strange with fractional minutes away
from UTC.
What can I say? "Those wacky Germans - they have a wonderful sense of
humor"?
Linus
^ permalink raw reply
* Re: Empty directories...
From: Matthieu Moy @ 2007-07-18 16:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Kastrup, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.0.999.0707180912430.27353@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
>> b) The problem is not just that empty directories don't get added into
>> the repository. They also don't get removed again when switching to a
>> different checkout.
>
> Bzzt. Wrong.
>
> We *do* remove directories when all files under them go away.
>
> HOWEVER (and this is where one of the reasons for not tracking them comes
> in):
>
> ** YOU CANNOT REMOVE A DIRECTORY IF IT HAS SOME UNTRACKED CONTENTS **
I believe David's point was different.
If you checkout a branch, create an empty directory in this branch
(probably a placeholder, either for future versionned files, or for
generated files), you cannot tell git "this empty directory is in this
branch, but not in other ones" without adding a file in it.
So, doing "git-checkout anotherbranch", this empty directory doesn't
go away. It's just unversionned in both branches, git won't touch it.
--
Matthieu
^ permalink raw reply
* Rsync fetch?
From: Daniel Barkalow @ 2007-07-18 16:37 UTC (permalink / raw)
To: git
The only thing that's totally missing at this point from my builtin-fetch
is rsync. Do we still care? Any takers for actually implementing it?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Empty directories...
From: Linus Torvalds @ 2007-07-18 16:33 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.LFD.0.999.0707180912430.27353@woody.linux-foundation.org>
On Wed, 18 Jul 2007, Linus Torvalds wrote:
>
> So "existence" != "content". Git very much does not track "existence" of
> files, it tracks the total content of them too.
Btw, don't get me wrong: I think that in order to be better at tracking
other SCM's idiotic choices, we could (and I foresee that we eventually
have to) try to track empty directories as a special case too.
So I'm not _against_ the notion of tracking empty directories, and I would
welcome patches that do so. As I mentioned in some earlier thread when
this came up a few weeks ago, I actually suspect that the "subproject"
support probably ended up making it easier, because in many ways an "empty
directory" is very close to a "anonymous subproject" from a low-level
plumbing standpoint (even if it is *not* so from a high-level standpoint).
So I suspect that adding support for empty directories ends up being about
just slightly extending the places that now have subproject support to
know about a new situation.
But I do want to point out that "tracking a directory" is not at all the
same thing as "tracking a file", no matter how much you try to argue
otherwise. The semantics are totally different, and it all boils down to
the fact that when you track a file, you are always talking about the
*full* content of the file, while tracking a directory is always about
tracking just a *subset* of the contents of the directory.
Of course, with directories, there's the trivial case where the subset
happens to be everything, but that is neither the common nor the
interesting case. All the interesting and complex cases happen exactly
when the directory has untracked files in it, and at that point
- you really aren't tracking "contents" any more
- you can no longer recreate the directory from the data you have (so you
cannot remove it on branch switches etc)
- ergo: you're not a content tracker any more, you're a "container"
tracker.
And really, the "nontracked files in a directory" is the *default* thing,
not some really unusual thing that we could disallow.
But I'm not against adding support for "container tracking". I just want
people to understand that it's something totally different from what we do
now. It's much more like subproject support than tracking files.
Linus
^ permalink raw reply
* Re: [PATCH 1/3] Move bundle specific stuff into bundle.[ch]
From: Johannes Schindelin @ 2007-07-18 16:33 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707181140450.14596@iabervon.org>
Hi,
On Wed, 18 Jul 2007, Daniel Barkalow wrote:
> On Wed, 18 Jul 2007, Johannes Schindelin wrote:
>
> > On Tue, 17 Jul 2007, Daniel Barkalow wrote:
> >
> > > You should use -C on this sort of thing, so that the interesting aspects
> > > of the patch are easier to see. (It actually comes out longer in this
> > > case, but it's far easier to tell that the code in the new file is the
> > > same as the old code.)
> >
> > Okay, I wanted it to be kept short, since I really get lost easily in
> > hundreds of "-" lines, with possibly one in the midst being a "+".
>
> Actually, putting the functions in the original order made the -C diff
> shorter than without -C.
True enough!
> > > Aside from presentation, it looks good to me. Shall I stick the
> > > bundle changes into my series? I'd like to have them come before the
> > > patch to switch to builtin-fetch, so that there aren't any revisions
> > > where "git fetch" doesn't have bundle support.
> >
> > Looks fine to me. Seems like you should add a SOB line, too.
>
> Ah, yes. I'll have to see if I'll be the first person in git development
> to have a SOB line that's neither first nor last. :)
We have 28 commits ATM in next's history, having 3 SOB lines:
1e76b702c1e754c7e6df1ced9ce6f1863cb7e092 is the most recent one.
> > > And I think it would be best to take part 3 as a review fix to my
> > > final patch.
> >
> > Yes, definitely. This shows again (to me, at least), that just
> > looking at the code is not enough, you have to run it, too, to review
> > patches.
>
> You caught that by running it? I've been running this code, and I've never
> done anything with it which caused fetch_refs to fail and then checked the
> result. I thought you must have found it by looking for missing checks of
> return values. Or did you find it when you'd implemented half of bundle
> support and it didn't complain?
Exactly. It is the "bundle 1" test that failed.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/3] Move bundle specific stuff into bundle.[ch]
From: Daniel Barkalow @ 2007-07-18 16:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707181053130.14781@racer.site>
On Wed, 18 Jul 2007, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 17 Jul 2007, Daniel Barkalow wrote:
>
> > You should use -C on this sort of thing, so that the interesting aspects
> > of the patch are easier to see. (It actually comes out longer in this
> > case, but it's far easier to tell that the code in the new file is the
> > same as the old code.)
>
> Okay, I wanted it to be kept short, since I really get lost easily in
> hundreds of "-" lines, with possibly one in the midst being a "+".
Actually, putting the functions in the original order made the -C diff
shorter than without -C. In general, a hundred lines of '-' with maybe a
'+' is hard to read, but I think whole functions of '-' without anything
else are easy; scan the left column, and find that the whole thing goes
away. If a patch is discarding blocks which are exactly whole top-level
definitions, those changes are probably either correct or totally broken
(depending on whether those blocks were actually used); you just have to
get suspicious around preprocessor stuff. Your change ended up being
trivially what the message described: bunch of blocks not in one or the
other of the resulting files, some functions make not static, renamed,
and/or had arguments changed, and the function you have to call after
unbundle if you want it.
> > Aside from presentation, it looks good to me. Shall I stick the bundle
> > changes into my series? I'd like to have them come before the patch to
> > switch to builtin-fetch, so that there aren't any revisions where "git
> > fetch" doesn't have bundle support.
>
> Looks fine to me. Seems like you should add a SOB line, too.
Ah, yes. I'll have to see if I'll be the first person in git development
to have a SOB line that's neither first nor last. :)
> > And I think it would be best to take part 3 as a review fix to my final
> > patch.
>
> Yes, definitely. This shows again (to me, at least), that just looking at
> the code is not enough, you have to run it, too, to review patches.
You caught that by running it? I've been running this code, and I've never
done anything with it which caused fetch_refs to fail and then checked the
result. I thought you must have found it by looking for missing checks of
return values. Or did you find it when you'd implemented half of bundle
support and it didn't complain?
^ permalink raw reply
* Re: Empty directories...
From: Linus Torvalds @ 2007-07-18 16:23 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Schindelin, git
In-Reply-To: <858x9ez1li.fsf@lola.goethe.zz>
On Wed, 18 Jul 2007, David Kastrup wrote:
>
> In the same manner as empty regular files have no contents, and git
> tracks those. Existence and permissions are important.
Yes, but directories really are different.
First off, git wouldn't track the permissions anyway (git tracks execute
bits, but for directories that _has_ to be set or git couldn't use them
itself, so that's not going to happen).
Second, and much more important, the directories will exist or not
*regardless* of what git does.
> b) The problem is not just that empty directories don't get added into
> the repository. They also don't get removed again when switching to a
> different checkout.
Bzzt. Wrong.
We *do* remove directories when all files under them go away.
HOWEVER (and this is where one of the reasons for not tracking them comes
in):
** YOU CANNOT REMOVE A DIRECTORY IF IT HAS SOME UNTRACKED CONTENTS **
Think about that for five seconds, then think about it some more. Ponder
it.
So the fact is, git *already* does ass good of a job as it could possibly
do wrt directories that go away: it tries to remove them if all the files
that are tracked in it have gone away.
But that leaves a very common case, namely switching to another branch
without those files, and the directory still having stale object files etc
build crud in it.
A SCM *must*not* just remove that directory. It would be horrible. The
fact that it has untracked files in it does not make those untracked files
"unimportant". Maybe you feel that way about object files, but what about
tracking some important parts of your home directory - does the fact that
you don't necessarily track *all* of it mean that the rest is totally
unimportant adn that git should just remove it? HELL NO!
So directories really _are_ problematic. You cannot (and should not) track
them the same way as you track a file.
And the difference is very fundamental indeed: when you track a regular
file, you track *all* of its content. But when you track a directory,
you don't track it's content *at*all*.
Think about that, and then think about the fact that git is defined as a
"content tracker", and it's not "weasely" at all to say that you don't
track directories.
So your argument is totally bogus. When you track an empty file, you very
much track the *content* of that file, and "empty" just happens to be a
very valid content.
But when you track a "directory", you don't actually track its content at
all, you track it's *existence*, which is a very very very different
thing. I hope you understand from the above what is so different.
(A true "directory content" tracker by definition would have to track
every single file under that directory. You can claim that for the case of
an empty directory the "existence tracking" is 100% equivalent with
"content tracking", but that's simply not true. It becomes non-true the
moment there are any files at all inside that directory, and be honest
now: the only _point_ of an empty directory is that you expect it to
potentially get files under it).
So "existence" != "content". Git very much does not track "existence" of
files, it tracks the total content of them too.
Linus
^ permalink raw reply
* Re: Wrong time in git-log when using right/ timezone
From: Peter Hartlich @ 2007-07-18 16:04 UTC (permalink / raw)
To: git
In-Reply-To: <20070718153614.GA28815@hartlich.com>
I wrote:
> git-log 1.5.2.2 gives me output such as:
Forgot to add that the bug is present in the current dev version.
Regards,
Peter Hartlich
^ permalink raw reply
* [PATCH 2/2] filter-branch: introduce convenience function "skip_commit"
From: Johannes Schindelin @ 2007-07-18 15:54 UTC (permalink / raw)
To: git, gitster
With this function, a commit filter can leave out unwanted commits
(such as temporary commits). It does _not_ undo the changeset
corresponding to that commit, but it _skips_ the revision. IOW
its childrens' tree objects remain the same.
If you like to commit early and often, but want to filter out all
intermediate commits, marked by "@@@" in the commit message, you can
now do this with
git filter-branch --commit-filter '
if git cat-file commit $GIT_COMMIT | grep '@@@' > /dev/null;
then
skip_commit "$@";
else
git commit-tree "$@";
fi' newbranch
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/git-filter-branch.txt | 39 ++++++++++++++++++++++++----------
git-filter-branch.sh | 14 ++++++++++++
t/t7003-filter-branch.sh | 8 +------
3 files changed, 42 insertions(+), 19 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index eaea82d..9dade65 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -111,6 +111,11 @@ OPTIONS
As a special extension, the commit filter may emit multiple
commit ids; in that case, ancestors of the original commit will
have all of them as parents.
++
+You can use the 'map' convenience function in this filter, and other
+convenience functions, too. For example, calling 'skip_commit "$@"'
+will leave out the current commit (but not its changes! If you want
+that, use gitlink:git-rebase[1] instead).
--tag-name-filter <command>::
This is the filter for rewriting tag names. When passed,
@@ -199,34 +204,44 @@ To remove commits authored by "Darl McBribe" from the history:
git filter-branch --commit-filter '
if [ "$GIT_AUTHOR_NAME" = "Darl McBribe" ];
then
- shift;
- while [ -n "$1" ];
- do
- shift;
- echo "$1";
- shift;
- done;
+ skip_commit "$@";
else
git commit-tree "$@";
fi' newbranch
------------------------------------------------------------------------------
+Note that the changes introduced by the commits, and not reverted by
+subsequent commits, will still be in the rewritten branch. If you want
+to throw out _changes_ together with the commits, you should use the
+interactive mode of gitlink:git-rebase[1].
+
+The function 'skip_commits' is defined as follows:
+
+--------------------------
+skip_commit()
+{
+ shift;
+ while [ -n "$1" ];
+ do
+ shift;
+ map "$1";
+ shift;
+ done;
+}
+--------------------------
+
The shift magic first throws away the tree id and then the -p
parameters. Note that this handles merges properly! In case Darl
committed a merge between P1 and P2, it will be propagated properly
and all children of the merge will become merge commits with P1,P2
as their parents instead of the merge commit.
+
To restrict rewriting to only part of the history, specify a revision
range in addition to the new branch name. The new branch name will
point to the top-most revision that a 'git rev-list' of this range
will print.
-Note that the changes introduced by the commits, and not reverted by
-subsequent commits, will still be in the rewritten branch. If you want
-to throw out _changes_ together with the commits, you should use the
-interactive mode of gitlink:git-rebase[1].
-
Consider this history:
------------------
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index b574612..91f3677 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -23,6 +23,20 @@ map()
fi
}
+# if you run 'skip_commit "$@"' in a commit filter, it will print
+# the (mapped) parents, effectively skipping the commit.
+
+skip_commit()
+{
+ shift;
+ while [ -n "$1" ];
+ do
+ shift;
+ map "$1";
+ shift;
+ done;
+}
+
# override die(): this version puts in an extra line break, so that
# the progress is still visible
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 4ddd656..22bb14a 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -132,13 +132,7 @@ test_expect_success "remove a certain author's commits" '
git-filter-branch --commit-filter "\
if [ \"\$GIT_AUTHOR_NAME\" = \"B V Uips\" ];\
then\
- shift;\
- while [ -n \"\$1\" ];\
- do\
- shift;\
- echo \"\$1\";\
- shift;\
- done;\
+ skip_commit \"\$@\";
else\
git commit-tree \"\$@\";\
fi" removed-author &&
--
1.5.3.rc1.16.g9d6f-dirty
^ permalink raw reply related
* [PATCH 1/2] filter-branch: provide the convenience functions also for commit filters
From: Johannes Schindelin @ 2007-07-18 15:52 UTC (permalink / raw)
To: git, gitster
By sourcing git-filter-branch and stopping after the function definitions,
the commit filter can now access the convenience functions like "map".
This is done automatically if you specify a commit filter.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-filter-branch.sh | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 0d000ed..b574612 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -8,9 +8,6 @@
# a new branch. You can specify a number of filters to modify the commits,
# files and trees.
-USAGE="git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]"
-. git-sh-setup
-
warn () {
echo "$*" >&2
}
@@ -69,6 +66,13 @@ set_ident () {
echo "[ -n \"\$GIT_${uid}_NAME\" ] || export GIT_${uid}_NAME=\"\${GIT_${uid}_EMAIL%%@*}\""
}
+# This script can be sourced by the commit filter to get the functions
+test "a$SOURCE_FUNCTIONS" = a1 && return
+this_script="$(cd "$(dirname "$0")"; pwd)"/$(basename "$0")
+
+USAGE="git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]"
+. git-sh-setup
+
tempdir=.git-rewrite
filter_env=
filter_tree=
@@ -118,7 +122,7 @@ do
filter_msg="$OPTARG"
;;
--commit-filter)
- filter_commit="$OPTARG"
+ filter_commit="SOURCE_FUNCTIONS=1 . \"$this_script\"; $OPTARG"
;;
--tag-name-filter)
filter_tag_name="$OPTARG"
--
1.5.3.rc1.16.g9d6f-dirty
^ permalink raw reply related
* Re: "git clone" executed as root on solaris 10 shreds UFS (it is possible to create hardlinks for directories as root under solaris)
From: Linus Torvalds @ 2007-07-18 15:45 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070718085055.GL25037@cip.informatik.uni-erlangen.de>
On Wed, 18 Jul 2007, Thomas Glanzmann wrote:
>
> > the bug is filed.
>
> http://bugs.opensolaris.org/view_bug.do?bug_id=6581318
I don't think the recipient "got it", since it already has a comment about
"just use rmdir".
Can you please tell them that that isn't the point?
Linus
^ permalink raw reply
* Wrong time in git-log when using right/ timezone
From: Peter Hartlich @ 2007-07-18 15:36 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
Hi,
My timezone is set to right/Europe/Berlin. git-log 1.5.2.2 gives me output
such as:
| Date: Wed Jul 18 16:17:31 2007 +0159
Note the timezone, which should be +0200.
I'm using tzcode/tzdata 2007f from <ftp://elsie.nci.nih.gov/pub/>. A small
test script is attached.
Regards,
Peter Hartlich
[-- Attachment #2: tz.sh --]
[-- Type: application/x-sh, Size: 282 bytes --]
^ permalink raw reply
* git-p4 pull request
From: Simon Hausmann @ 2007-07-18 15:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]
The following changes since commit a5e407988b35b7353bd03c770afc647670c25981:
Jim Meyering (1):
git-cvsserver: detect/diagnose write failure, etc.
are available in the git repository at:
git://people.freedesktop.org/~hausmann/git-p4 master
Scott Lamb (2):
git-p4: use subprocess in p4CmdList
git-p4: input to "p4 files" by stdin instead of arguments
Simon Hausmann (3):
git-p4: Cleanup, make listExistingP4Branches a global function for later use.
git-p4: Fix upstream branch detection for submit/rebase with multiple branches.
git-p4: Cleanup, used common function for listing imported p4 branches
contrib/fast-import/git-p4 | 129 ++++++++++++++++++++++++--------------------
1 files changed, 70 insertions(+), 59 deletions(-)
I have used Scotts changes for two days now and had no problems at all.
Based on Alex Riesen's suggestion they are a nice solution around the commandline
limits when calling the p4 client.
The other three changes fix a rather ugly bug when importing multiple depot
paths through p4 branch mappings where it could happen in the end that changes
that were done in git were submitted into the wrong depot paths in perforce itself
due to a faulty rebase onto the wrong git branch.
Would be great if those changes could be included in master.
Thanks,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Rename read_pipe() with read_fd() and make its buffer nul-terminated.
From: Carlos Rica @ 2007-07-18 15:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Kristian Høgsberg
In-Reply-To: <7vps2q6tjf.fsf@assigned-by-dhcp.cox.net>
2007/7/18, Junio C Hamano <gitster@pobox.com>:
>
> > unsigned long size = *return_size;
> > ssize_t iret;
> > unsigned long off = 0;
> >
> > + if (!buf || size <= 1) {
> > + size = alloc_nr(size);
> > + buf = xrealloc(buf, size);
> > + }
> > +
>
> Hmph. The reason this is not "!size" is because you would want
> more than one. As your plan is to use this mostly for the -F
> option of "tag/commit", I suspect using a bit larger default,
> such as 80 (just a line), or probably 1k (most log messages
> would fit in such a buffer), would be more practical.
The true reason is because I before tried using (size-1) instead of (size)
in xread(..., size - off), and then I forgot to remove that condition. Sorry.
>
> > do {
> > iret = xread(fd, buf + off, size - off);
> > if (iret > 0) {
> > off += iret;
> > if (off == size) {
> > - size *= 2;
> > + size = alloc_nr(size);
> > buf = xrealloc(buf, size);
> > }
> > }
> > } while (iret > 0);
> >
> > + if (off == size)
> > + buf = xrealloc(buf, size + 1);
> > + buf[off] = '\0';
> > +
>
> I wonder if doing xread(... (size-1) - off) in the loop would
> ensure (off <= size-1) here. You also would need to update the
> realloc condition inside loop if you do so.
I have chosen that solution to leave the code easy to read, but the
(size-1) version will avoid that additional (but non-frequent) realloc.
I will resend the fixed patch along with the builtin-tag.c one.
^ permalink raw reply
* [PATCH 2/2] Makefile: use $(FIND) instead of find
From: David Kastrup @ 2007-07-18 14:45 UTC (permalink / raw)
To: git
In-Reply-To: <6e14af24a3aa8af7e21e0a3f92c83c82e147202a.1184770193.git.dak@gnu.org>
Some people might prefer to be able to specify the find utility to
use, in particular for the more complicated usage in the
install-symlinks target.
Signed-off-by: David Kastrup <dak@gnu.org>
---
Makefile | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 7e53378..cf72327 100644
--- a/Makefile
+++ b/Makefile
@@ -178,6 +178,7 @@ AR = ar
RM = rm -f
TAR = tar
INSTALL = install
+FIND = find
RPMBUILD = rpmbuild
TCL_PATH = tclsh
TCLTK_PATH = wish
@@ -904,11 +905,11 @@ doc:
TAGS:
$(RM) TAGS
- find . -name '*.[hcS]' -print | xargs etags -a
+ $(FIND) . -name '*.[hcS]' -print | xargs etags -a
tags:
$(RM) tags
- find . -name '*.[hcS]' -print | xargs ctags -a
+ $(FIND) . -name '*.[hcS]' -print | xargs ctags -a
### Detect prefix changes
TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):\
@@ -1000,10 +1001,10 @@ quick-install-doc:
# The somewhat strange looking lines start with an ignored $(MAKE) in
# order to be executed also in make -n calls.
install-symlinks:
- @: $(MAKE) && cd '$(prefix_SQ)' && find . -type d ! \( -iname 'git*' -prune \) -exec echo $(INSTALL) -m 755 -d '$(symlinkprefix)/{}' \;
- @cd '$(prefix_SQ)' && find . -type d ! \( -iname 'git*' -prune \) -exec $(INSTALL) -m 755 -d '$(symlinkprefix)/{}' \;
- @: $(MAKE) && cd '$(prefix_SQ)' && find . \( -type d -iname 'git*' -prune -o ! -type d \) -exec echo $(RM) -r '$(symlinkprefix)/{}' \; -exec echo ln -s '$(prefix_SQ)/{}' '$(symlinkprefix)/{}' \;
- @cd '$(prefix_SQ)' && find . \( -type d -iname 'git*' -prune -o ! -type d \) -exec $(RM) -r '$(symlinkprefix)/{}' \; -exec ln -s '$(prefix_SQ)/{}' '$(symlinkprefix)/{}' \;
+ @: $(MAKE) && cd '$(prefix_SQ)' && $(FIND) . -type d ! \( -iname 'git*' -prune \) -exec echo $(INSTALL) -m 755 -d '$(symlinkprefix)/{}' \;
+ @cd '$(prefix_SQ)' && $(FIND) . -type d ! \( -iname 'git*' -prune \) -exec $(INSTALL) -m 755 -d '$(symlinkprefix)/{}' \;
+ @: $(MAKE) && cd '$(prefix_SQ)' && $(FIND) . \( -type d -iname 'git*' -prune -o ! -type d \) -exec echo $(RM) -r '$(symlinkprefix)/{}' \; -exec echo ln -s '$(prefix_SQ)/{}' '$(symlinkprefix)/{}' \;
+ @cd '$(prefix_SQ)' && $(FIND) . \( -type d -iname 'git*' -prune -o ! -type d \) -exec $(RM) -r '$(symlinkprefix)/{}' \; -exec ln -s '$(prefix_SQ)/{}' '$(symlinkprefix)/{}' \;
### Maintainer's dist rules
--
1.5.3.rc2.41.gb47b1
^ permalink raw reply related
* [PATCH 1/2] Makefile: create an install-symlinks target
From: David Kastrup @ 2007-07-18 10:41 UTC (permalink / raw)
To: git
In-Reply-To: <861wf5iz6o.fsf@lola.quinscape.zz>
This target allows you to have git installed in one location,
and have symbolic links to all of the programs installed in
another location. For example, if git was installed to /opt/git
with
make prefix=/opt/git install
you can install symbolic links in /usr/local/bin with
make symlinkprefix=/usr/local prefix=/opt/git \
install-symlinks
This makes it reasonably easy to remove such a package, by doing
rm -rf /opt/git
and then removing stale links with
find /usr/local -xtype l -print0|xargs -0 rm
(be sure to first see whether you indeed get only stale links listed).
This works by copying the directory hierarchy of $prefix to
$symlinkprefix (not copying or descending to any directories of the
name git* matched case-insensitively), then linking all the rest.
Signed-off-by: David Kastrup <dak@gnu.org>
---
Makefile | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 73b487f..7e53378 100644
--- a/Makefile
+++ b/Makefile
@@ -142,6 +142,7 @@ ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
prefix = $(HOME)
+symlinkprefix = /usr/local
bindir = $(prefix)/bin
gitexecdir = $(bindir)
sharedir = $(prefix)/share
@@ -996,7 +997,13 @@ install-doc:
quick-install-doc:
$(MAKE) -C Documentation quick-install
-
+# The somewhat strange looking lines start with an ignored $(MAKE) in
+# order to be executed also in make -n calls.
+install-symlinks:
+ @: $(MAKE) && cd '$(prefix_SQ)' && find . -type d ! \( -iname 'git*' -prune \) -exec echo $(INSTALL) -m 755 -d '$(symlinkprefix)/{}' \;
+ @cd '$(prefix_SQ)' && find . -type d ! \( -iname 'git*' -prune \) -exec $(INSTALL) -m 755 -d '$(symlinkprefix)/{}' \;
+ @: $(MAKE) && cd '$(prefix_SQ)' && find . \( -type d -iname 'git*' -prune -o ! -type d \) -exec echo $(RM) -r '$(symlinkprefix)/{}' \; -exec echo ln -s '$(prefix_SQ)/{}' '$(symlinkprefix)/{}' \;
+ @cd '$(prefix_SQ)' && find . \( -type d -iname 'git*' -prune -o ! -type d \) -exec $(RM) -r '$(symlinkprefix)/{}' \; -exec ln -s '$(prefix_SQ)/{}' '$(symlinkprefix)/{}' \;
### Maintainer's dist rules
--
1.5.3.rc2.41.gb47b1
^ permalink raw reply related
* Re: [PATCH] Makefile: create an install-symlinks target
From: Peter Baumann @ 2007-07-18 14:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0707181344520.14781@racer.site>
On Wed, Jul 18, 2007 at 01:48:21PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 18 Jul 2007, David Kastrup wrote:
>
> > Use this, for example, to do
> > rm -rf /opt/git
> > make prefix=/opt/git install
> > make symlinkprefix=/usr/local prefix=/opt/git install-symlinks
>
> You mean
>
> This target allows you to have git installed in one location,
> and have symbolic links to all of the programs installed in
> another location. For example, if git was installed to /opt/git
> with
>
> make prefix=/opt/git install
>
> you can install symbolic links in /usr/local/bin with
>
> make symlinkprefix=/usr/local prefix=/opt/git \
> install-symlinks
>
> Hmm. Why not install it with a proper package manager in the correct
> place to begin with? Somehow I find so many symbolic links ugly.
>
Seeing this excellent explantion from Dscho, this sound exactly like a
perfect use case for xstow [1].
It allows you to install your application into e.g. /usr/local/stow/git
and by running 'xstow git' in /usr/local/stow it would create all the
necessary links in /usr/local/{bin,share,doc} or any other place you
want.
-Peter
[1]: http://xstow.sourceforge.net/
^ permalink raw reply
* Re: [PATCH] Makefile: create an install-symlinks target
From: David Kastrup @ 2007-07-18 14:06 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0707180608j7c22631ak87f3ddd6481bccf2@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> On 7/18/07, David Kastrup <dak@gnu.org> wrote:
>> + @: $(MAKE) && cd '$(prefix_SQ)' && find . -mindepth 1 ...
>
> Sometime about now you'll need to define $(FIND) or even $(GNUFIND)
> for find. There are proprietary systems where find is not available or
> does not do what you want it to. There is often a gfind installed somewhere
> on these systems.
I think that the install-symlinks target is rather more specialized
than the tags and TAGS targets, yet those use just "find". I think
I'll be able to throw out the -mindepth, however. It was necessary in
a version that used find $(prefix), since /opt/git matched
-type d -name git*
but with find . this should not be relevant.
I'll amend that patch and prepare a separate one that uses $(FIND)
everywhere.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] filter-branch: get rid of "set -e"
From: Johannes Schindelin @ 2007-07-18 14:05 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86vechj0zz.fsf@lola.quinscape.zz>
Hi,
[please Cc me]
On Wed, 18 Jul 2007, David Kastrup wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > It was reported by Alex Riesen that "set -e" can break something as
> > trivial as "unset CDPATH" in bash.
>
> Not in bash. Just tried it. But there are Bourne shells that do get
> annoyed.
The mail I was replying to _explicitely_ stated that it _was_ with bash.
Not your version of it, but some version.
> > So get rid of "set -e".
>
> I'd rather write
>
> [ "X$CDPATH" = "X" ] || unset CDPATH
We would write that as "test", not "[".
But it is much cleaner to get rid of "set -e" anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] filter-branch: get rid of "set -e"
From: David Kastrup @ 2007-07-18 13:27 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0707181416050.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It was reported by Alex Riesen that "set -e" can break something as
> trivial as "unset CDPATH" in bash.
Not in bash. Just tried it. But there are Bourne shells that do get
annoyed.
> So get rid of "set -e".
I'd rather write
[ "X$CDPATH" = "X" ] || unset CDPATH
With regard to shells, there is an interesting document
(info "(autoconf) Portable Shell")
which is rather disillusioning.
A real horror show is
(info "(autoconf) Limitations of Builtins")
where one learns that using if without else can lead to bad exit
status, too.
--
David Kastrup
^ permalink raw reply
* [PATCH] filter-branch: get rid of "set -e"
From: Johannes Schindelin @ 2007-07-18 13:17 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, gitster
In-Reply-To: <20070710205202.GA3212@steel.home>
It was reported by Alex Riesen that "set -e" can break something as
trivial as "unset CDPATH" in bash.
So get rid of "set -e".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 10 Jul 2007, Alex Riesen wrote:
> I have a Debian system where git-filter-branch exits immediately
> after "unset CDPATH" in git-sh-setup (the command exits with 1,
> as CDPATH is not defined). The system still has bash-2.05a.
>
> git-filter-branch has "set -e", which is why the script finishes
> prematurely. If this is not really needed, maybe it can be
> removed?
I hope I got all of the interesting places equipped by the
appropriate conditional die() calls.
git-filter-branch.sh | 31 +++++++++++++++++--------------
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 5401970..0d000ed 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -8,8 +8,6 @@
# a new branch. You can specify a number of filters to modify the commits,
# files and trees.
-set -e
-
USAGE="git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]"
. git-sh-setup
@@ -141,9 +139,10 @@ git show-ref "refs/heads/$dstbranch" 2> /dev/null &&
die "branch $dstbranch already exists"
test ! -e "$tempdir" || die "$tempdir already exists, please remove it"
-mkdir -p "$tempdir/t"
-cd "$tempdir/t"
-workdir="$(pwd)"
+mkdir -p "$tempdir/t" &&
+cd "$tempdir/t" &&
+workdir="$(pwd)" ||
+die ""
case "$GIT_DIR" in
/*)
@@ -155,12 +154,12 @@ esac
export GIT_DIR GIT_WORK_TREE=.
export GIT_INDEX_FILE="$(pwd)/../index"
-git read-tree # seed the index file
+git read-tree || die "Could not seed the index"
ret=0
-
-mkdir ../map # map old->new commit ids for rewriting parents
+# map old->new commit ids for rewriting parents
+mkdir ../map || die "Could not create map/ directory"
case "$filter_subdir" in
"")
@@ -170,7 +169,7 @@ case "$filter_subdir" in
*)
git rev-list --reverse --topo-order --default HEAD \
--parents --full-history "$@" -- "$filter_subdir"
-esac > ../revs
+esac > ../revs || die "Could not get the commits"
commits=$(wc -l <../revs | tr -d " ")
test $commits -eq 0 && die "Found nothing to rewrite"
@@ -186,10 +185,11 @@ while read commit parents; do
;;
*)
git read-tree -i -m $commit:"$filter_subdir"
- esac
+ esac || die "Could not initialize the index"
export GIT_COMMIT=$commit
- git cat-file commit "$commit" >../commit
+ git cat-file commit "$commit" >../commit ||
+ die "Cannot read commit $commit"
eval "$(set_ident AUTHOR <../commit)" ||
die "setting author failed for commit $commit"
@@ -199,7 +199,8 @@ while read commit parents; do
die "env filter failed: $filter_env"
if [ "$filter_tree" ]; then
- git checkout-index -f -u -a
+ git checkout-index -f -u -a ||
+ die "Could not checkout the index"
# files that $commit removed are now still in the working tree;
# remove them, else they would be added again
git ls-files -z --others | xargs -0 rm -f
@@ -240,7 +241,8 @@ case "$target_head" in
echo Nothing rewritten
;;
*)
- git update-ref refs/heads/"$dstbranch" $target_head
+ git update-ref refs/heads/"$dstbranch" $target_head ||
+ die "Could not update $dstbranch with $target_head"
if [ $(wc -l <../map/$src_head) -gt 1 ]; then
echo "WARNING: Your commit filter caused the head commit to expand to several rewritten commits. Only the first such commit was recorded as the current $dstbranch head but you will need to resolve the situation now (probably by manually merging the other commits). These are all the commits:" >&2
sed 's/^/ /' ../map/$src_head >&2
@@ -277,7 +279,8 @@ if [ "$filter_tag_name" ]; then
warn "unreferencing tag object $sha1t"
fi
- git update-ref "refs/tags/$new_ref" "$new_sha1"
+ git update-ref "refs/tags/$new_ref" "$new_sha1" ||
+ die "Could not write tag $new_ref"
done
fi
--
1.5.3.rc1.16.g9d6f-dirty
^ permalink raw reply related
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