* Re: [PATCH] add log.fulldiff config option
From: Junio C Hamano @ 2006-12-20 10:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <7v8xh3j86h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Your understanding needs to be clarified on how paths are
> filtered, and how log family and diff interacts, and probably
> these need to be better documented.
Having said that, I realized that I was making the same mistake
that our existing documentation was criticized for.
Let me first digress to address the documentation criticism.
The description on plumbing were (and still are) far more
thorough than porcelain-ish, and the conjecture by the person
who criticized them was because developers were keen documenting
the real work (plumbing) soon after they finished coding than
the frill (porcelain-ish).
I think the real reason for this is somewhat different. At
least to me, git.git was about the plumbing, and I did not want
to be in the Porcelain business at all [*1*]. Instead, I wanted
to encourage healthy competition among Porcelains. What was
shipped with git.git was meant to be "barely usable examples".
But this vision has not materialized fully yet, fortunately
because we did not end up splitting the userbase too early on.
But this was unfortunate for two reasons. One of them is that
different Porcelains would have brought completely different
ways of thinking and workflows into the picture.
Because git.git was primarily about the plumbing, the main focus
of the interface the plumbing offers was not about integration
and uniformity but modularity. Designing them as independent
building blocks as much as practical, and describing them fully,
were part of completing the plumbing. And the "barely usable
examples" started their lives as a set of trivial pipelines,
whose meaning was quite obvious and straightforward when you
understand the plumbing parts used in them. It also had UI
warts. "barely usable examples" cheated their command line
parsing, and the flags used by the plumbing showed through its
thin veneer to the UI used by the end users.
But that was a long time ago. Now we are in the v1.5.0 process,
whose theme is "usability and teachability".
Now, viewing in that light, what I described in the previous
message may have been a precise description of how things happen
to work currently, but it was not about the reason how and why
they were designed to be (because there was little design at the
UI level). We should instead (or at least "in addition") be
talking more about how things ought to be.
I described why --full-diff and --pickaxe-all are different
options, you can give 4 combinations of them, and how the
combinations work differently and why. That does not justify
that all of these four combinations make sense. In fact, I do
not think they do.
When pickaxe is used and --full-diff is given to 'log', I think
it does not make any sense not to use --pickaxe-all. So, I
think at the level of log family commands, unifying these two
flags make a lot of sense (although I earlier said "no").
Although --diff-filter does not have a corresponding option that
makes it behave all-or-none (i.e. an equivalent to --pickaxe-all),
it is conceivable that you might want to say:
$ git log --diff-filter=A --full-diff --diff-filter-all
to view commits that add new files with full diffs (not just
added paths). If we were to add that, I think it makes sense to
internally have a flag separate from pickaxe-all to express it
but when 'log' uses --full-diff, it does not make any sense not
to enable it. In other words,
$ git log -M --diff-filter=R -Sstring --full-diff
should internally enable pickaxe-all and diff-filter-all and
show all of diff that has renames in the paths that change
"string" [*2*].
[Footnote]
*1* I once wanted to do a Porcelain of my own, after finding it
distasteful that Cogito tried to hide the index back when it did
not even use the index properly for merges. But things have
been improved quite a lot in Cogito land and I do not have
anything against it anymore. And as you all know, I like StGIT
very much.
*2* This is actually in line with what we did in 582af688. As a
member of 'log' family, 'git log' were originally meant to show
commit messages for all commits that revision traversal gave it,
regardless of the diff output (and without the diffcore
transformation, when revision traversal said a commit is
interesting, the commit always has some diff or a merge). When
used in conjunction with --pickaxe and --diff-filter, however,
this layering made the command much less useful. We fixed the
problem by violating the layering and made the log command aware
of the underlying diff machinery's output filter. I think the
same would apply to the issue we are currently discussing.
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support in pre-commit hook
From: Andy Parkins @ 2006-12-20 10:08 UTC (permalink / raw)
To: git
In-Reply-To: <200612200901.30584.andyparkins@gmail.com>
Hello,
Help...
> +if [ -f .gitmodules ]; then
This doesn't work because git-commit is not necessarily in the root of the
working tree. How do I safely get that root? While ${GIT_DIR}/.. would work
it is not guaranteed.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Change in git-svn dcommit semantics?
From: Jakub Narebski @ 2006-12-20 11:38 UTC (permalink / raw)
To: git
In-Reply-To: <7v3b7bnz6q.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
>> And is there an easier way to find these things than "git rev-list
>> HEAD | git diff-tree -r -s --stdin -SCOLLISION | xargs git show"? I
>> cobbled that together from poking around inside gitk (which mostly
>> works in OS X, but has some issues that make me prefer the command
>> line).
>
> I typically do:
>
> git log --full-diff -p -SCOLLISION
>
> The --full-diff option helps because it shows the diff for other
> files (that do not have different number of substring COLLISION
> in the pre and postimage) in the same commit as well.
Yet another undocumented option. Sigh...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Change in git-svn dcommit semantics?
From: Brian Gernhardt @ 2006-12-20 11:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <emb77h$cf2$1@sea.gmane.org>
On Dec 20, 2006, at 6:38 AM, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
>> The --full-diff option helps because it shows the diff for other
>> files (that do not have different number of substring COLLISION
>> in the pre and postimage) in the same commit as well.
>
> Yet another undocumented option. Sigh...
I'd send in a patch to fix that (little gnome work is what I do in
Wikipedia, and seems to be what I do here), but the option seems to
be in setup_revision.c:setup_revisions, which is used in several
places. Is there a central place to put that in the documentation?
Should there be?
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support in pre-commit hook
From: Brian Gernhardt @ 2006-12-20 11:49 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612201008.49045.andyparkins@gmail.com>
On Dec 20, 2006, at 5:08 AM, Andy Parkins wrote:
> Hello,
>
> Help...
>
>> +if [ -f .gitmodules ]; then
>
> This doesn't work because git-commit is not necessarily in the root
> of the
> working tree. How do I safely get that root? While ${GIT_DIR}/..
> would work
> it is not guaranteed.
The way to do that seems to be "git rev-parse --git-dir". I'm not
sure why it's not just "git --git-dir" or similar (probably just
historical reasons), but there you go.
^ permalink raw reply
* Re: Change in git-svn dcommit semantics?
From: Jeff King @ 2006-12-20 11:57 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Jakub Narebski, git
In-Reply-To: <360A3F7A-0849-4BCE-8550-1F05BB9821C5@silverinsanity.com>
On Wed, Dec 20, 2006 at 06:47:45AM -0500, Brian Gernhardt wrote:
> >>The --full-diff option helps because it shows the diff for other
> >>files (that do not have different number of substring COLLISION
> >>in the pre and postimage) in the same commit as well.
> >
> >Yet another undocumented option. Sigh...
>
> I'd send in a patch to fix that (little gnome work is what I do in
> Wikipedia, and seems to be what I do here), but the option seems to
> be in setup_revision.c:setup_revisions, which is used in several
> places. Is there a central place to put that in the documentation?
> Should there be?
Please read the rest of the thread for some explanation from Junio on
how this option works.
I think it makes sense to group the porcelain-ish options together for
git-log/git-whatchanged (and potentially git-show). Really, they can
take any of the diff-options or any of the rev-list options. The
rev-list options are not currently grouped for inclusion in another man
page. The diff options are available in diff-options.txt, but are not
included by the log manpages. They probably should be.
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support in pre-commit hook
From: Jakub Narebski @ 2006-12-20 11:59 UTC (permalink / raw)
To: git
In-Reply-To: <200612201008.49045.andyparkins@gmail.com>
Andy Parkins wrote:
> Help...
>
>> +if [ -f .gitmodules ]; then
>
> This doesn't work because git-commit is not necessarily in the root of the
> working tree. How do I safely get that root? While ${GIT_DIR}/.. would work
> it is not guaranteed.
Do you want "git rev-parse --show-prefix" or "git rev-parse --show-cdup",
or "git rev-parse --git-dir" perhaps? (Although here rev in rev-parse is
misnomer).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support in pre-commit hook
From: Jakub Narebski @ 2006-12-20 12:01 UTC (permalink / raw)
To: git
In-Reply-To: <A76C0FA3-1649-409B-B0D4-C22865622C1F@silverinsanity.com>
Brian Gernhardt wrote:
>
> On Dec 20, 2006, at 5:08 AM, Andy Parkins wrote:
>
>> Hello,
>>
>> Help...
>>
>>> +if [ -f .gitmodules ]; then
>>
>> This doesn't work because git-commit is not necessarily in the root
>> of the
>> working tree. How do I safely get that root? While ${GIT_DIR}/..
>> would work
>> it is not guaranteed.
>
> The way to do that seems to be "git rev-parse --git-dir". I'm not
> sure why it's not just "git --git-dir" or similar (probably just
> historical reasons), but there you go.
Because it is "git --git-dir=<PATH>" to set it (probably).
Although it is not insurmountable difficulity...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support in pre-commit hook
From: Andy Parkins @ 2006-12-20 12:11 UTC (permalink / raw)
To: git
In-Reply-To: <emb8ev$egb$1@sea.gmane.org>
On Wednesday 2006 December 20 11:59, Jakub Narebski wrote:
> Do you want "git rev-parse --show-prefix" or "git rev-parse --show-cdup",
> or "git rev-parse --git-dir" perhaps? (Although here rev in rev-parse is
> misnomer).
--show-cdup was the one. Thanks so much. I tried git-var, never even thought
of git-rev-parse.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support in pre-commit hook
From: Andreas Ericsson @ 2006-12-20 12:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <emb8h2$io4$1@sea.gmane.org>
Jakub Narebski wrote:
> Brian Gernhardt wrote:
>
>> On Dec 20, 2006, at 5:08 AM, Andy Parkins wrote:
>>
>>> Hello,
>>>
>>> Help...
>>>
>>>> +if [ -f .gitmodules ]; then
>>> This doesn't work because git-commit is not necessarily in the root
>>> of the
>>> working tree. How do I safely get that root? While ${GIT_DIR}/..
>>> would work
>>> it is not guaranteed.
>> The way to do that seems to be "git rev-parse --git-dir". I'm not
>> sure why it's not just "git --git-dir" or similar (probably just
>> historical reasons), but there you go.
>
> Because it is "git --git-dir=<PATH>" to set it (probably).
> Although it is not insurmountable difficulity...
AFAIR, the discussions long ago went along the lines of "if no argument
is passed to any of the --*-dir options, print out the current value".
If "git --git-dir" doesn't print the directory name of the .git
directory inside the repo you're currently in, I'd consider it a bug.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* [RFC/PATCH] Implement poor-man's submodule support using commit hooks
From: Andy Parkins @ 2006-12-20 13:09 UTC (permalink / raw)
To: git
Make a file called .gitmodules. In it, list the paths containing a
submodule. Add that file to the index.
This patch adds a check to the pre-commit hook finds that file and pulls
the HEAD hash out of each of the listed submodule repositories. That
hash is then listed to the .gitmodules file along with the submodule
name and .gitmodules is added back to the repository.
You've now got poor-man's submodule support. Any commits to the
submodule will change the hash and hence the .gitmodules file will be
different and therefore will show up as "modified" to git.
It's not got any nice UI for checking out (obviously) or merging; but it
does at least record the state of a project. With a bit of manual work you
can easily check out the right commit in the submodule. If there were a
post-checkout hook script, this could probably be automated.
To prevent git-prune in the submodule from removing references that the
supermodule refers to the post-commit hook reads the .gitmodules file
and creates a file in submodule/.git/refs/superrefs/ that refers to the
hash we've references. git-prune in the submodule will find that
reference and hence won't remove it from under us.
Problems:
- git-prune in the supermodule doesn't clean the supermodule refs in
the submodule
- no checkout support
- no reset support
- no merge support (other than what git provides for the .gitmodule
file)
- no check for dirty submodule before commit
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
This is in replacement of the previous patch.
I've used the --show-cdup option of git-rev-parse to make it work even in
subdirectories. I've also added git-prune protection by adding a post-commit
script to reference the hash in the submodule.
What'd you reckon? Might be useful until real submodule support arrives.
If there is no .gitmodules file in the root, then git behaves as it always did.
I suppose if this were actually found to be really useful, it should go in
git-commit.sh itself, rather than the hooks.
templates/hooks--post-commit | 29 +++++++++++++++++++++++++-
templates/hooks--pre-commit | 47 +++++++++++++++++++++++++++++++++++++++++-
2 files changed, 74 insertions(+), 2 deletions(-)
diff --git a/templates/hooks--post-commit b/templates/hooks--post-commit
index 8be6f34..551d928 100644
--- a/templates/hooks--post-commit
+++ b/templates/hooks--post-commit
@@ -5,4 +5,31 @@
#
# To enable this hook, make this file executable.
-: Nothing
+# Poor-man's Submodules
+# ---------------------
+# If we're here, then a commit has succeeded. If submodule support is enabled
+# then we need a way of telling the submodule that we now reference a hash
+# owned by it, so that it is not pruned.
+WORKINGTOP=$(git-rev-parse --show-cdup)
+GITMODULES="${WORKINGTOP}.gitmodules"
+if [ -f "$GITMODULES" ]; then
+ cat "$GITMODULES" |
+ while read subdir hash
+ do
+ SUBMODULEPATH="$WORKINGTOP$subdir/.git/refs/superrefs"
+
+ # XXX: check if the line is a comment
+
+ # check if the subdir is a repository
+ if [ ! -d "$WORKINGTOP$subdir/.git" ]; then
+ continue;
+ fi
+
+ # Write the hash to a file of the same name - this means that if we get
+ # multiple commits that refer to the submodule, we only get one file in
+ # the submodule, as the submodule hash is constant across supermodule
+ # commits
+ mkdir -p "$SUBMODULEPATH"
+ echo $hash > "$SUBMODULEPATH/$hash"
+ done
+fi
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 723a9ef..7718369 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -67,5 +67,50 @@ perl -e '
}
}
exit($found_bad);
-'
+' || exit 1
+
+# Poor-man's Submodules
+# ---------------------
+# Enable poor-man's submodule support when .gitmodules is present
+# Simply create a .gitmodules file listing the paths in your repository
+# that contain other git repositories; each line will be replaced with the
+# path followed by the hash of the current HEAD of the submodule.
+# When the submodule changes hash this file will be different from the
+# version in the repository and a change will be noted - voila, submodules.
+# Of course there is no checkout support, but at least the current state
+# will be accurately recorded
+WORKINGTOP=$(git-rev-parse --show-cdup)
+GITMODULES="${WORKINGTOP}.gitmodules"
+if [ -f "$GITMODULES" ]; then
+ cat "$GITMODULES" |
+ while read subdir hash
+ do
+ # check if the line is a comment and output it anyway
+ if (expr "x$subdir" : "x#" >/dev/null) then
+ echo "$subdir $hash"
+ continue;
+ fi
+
+ # check if the subdir is a repository
+ if [ ! -d "$WORKINGTOP$subdir/.git" ]; then
+ echo "$subdir is not a git repository, so it can't be a submodule"
+ exit 1;
+ fi
+
+ # XXX: really need a check here and quit if the submodule is
+ # dirty
+
+ echo "$subdir $(GIT_DIR=$WORKINGTOP$subdir/.git git-rev-parse HEAD)"
+ done > newgitmodules
+ # Update
+ mv newgitmodules "$GITMODULES"
+
+ # This relies on the .gitmodules file having already been added to
+ # the repository - perhaps this should be automated?
+ git-update-index "$GITMODULES" ||
+ (
+ echo "FATAL: Submodule tracker file, $GITMODULES, is not tracked in this repository." >&2
+ exit 1
+ )
+fi
--
1.4.4.2.g0d2a
^ permalink raw reply related
* Corrupt pack file using older versions of git on a newer repo..
From: Sean @ 2006-12-20 13:27 UTC (permalink / raw)
To: git
This is probably expected behavior, but when bisecting another Git
issue[1], i found that after a fresh clone of the git repository using
1.4.4.2 I got the following corrupt pack file when accessing that repo
with an old version of git:
$ git --version
git version 1.4.2
$ git log
fatal: corrupted pack file .git/objects/pack/pack-d75f6a8307f8d8ce9727fe27107486839c54aef6.pack
When reverting to 1.4.3 instead, a git reset triggered the corrupt pack
error. Anyway, just a heads up in case it actually matters.
Sean
[1] The "Git" issue turned out not to be Git at all but rather the
Beagle search daemon which seems to touch file stat information as
it scans files in a git repo causing strange git status and diff
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support using commit hooks
From: Johannes Sixt @ 2006-12-20 13:29 UTC (permalink / raw)
To: git
In-Reply-To: <200612201309.02119.andyparkins@gmail.com>
Andy Parkins wrote:
> +WORKINGTOP=$(git-rev-parse --show-cdup)
> +GITMODULES="${WORKINGTOP}.gitmodules"
> +if [ -f "$GITMODULES" ]; then
> + cat "$GITMODULES" |
useless-use-of-cat-syndrome
> + while read subdir hash
Wouldn't it be better to have the order of subdir and hash swapped? That
way subdir may contain blanks, and it gives nicer alignment in the file
because of the constant length of the hashes.
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support using commit hooks
From: Martin Waitz @ 2006-12-20 13:36 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612201309.02119.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
hoi :)
On Wed, Dec 20, 2006 at 01:09:01PM +0000, Andy Parkins wrote:
>
> You've now got poor-man's submodule support. Any commits to the
> submodule will change the hash and hence the .gitmodules file will be
> different and therefore will show up as "modified" to git.
I started with something similiar, too.
You can have a look at http://git.admingilde.org/tali/git.git/module
which tries to implement submodules without changing the core.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support using commit hooks
From: Andy Parkins @ 2006-12-20 13:47 UTC (permalink / raw)
To: git
In-Reply-To: <45893AC6.910D5748@eudaptics.com>
On Wednesday 2006 December 20 13:29, Johannes Sixt wrote:
> > + cat "$GITMODULES" |
>
> useless-use-of-cat-syndrome
I tried
while
do
done < file1 > file1
And that didn't work. However, it was racy anyway using the same file, so I
changed to as it is now, but forgot to switch back to input redirection.
diff --git a/git-commit.sh b/git-commit.sh
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 7718369..74edfe2 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -82,7 +82,6 @@ perl -e '
WORKINGTOP=$(git-rev-parse --show-cdup)
GITMODULES="${WORKINGTOP}.gitmodules"
if [ -f "$GITMODULES" ]; then
- cat "$GITMODULES" |
while read subdir hash
do
# check if the line is a comment and output it anyway
@@ -101,7 +100,7 @@ if [ -f "$GITMODULES" ]; then
# dirty
echo "$subdir $(GIT_DIR=$WORKINGTOP$subdir/.git git-rev-parse HEAD)"
- done > newgitmodules
+ done < "$GITMODULES" > newgitmodules
# Update
mv newgitmodules "$GITMODULES"
> > + while read subdir hash
>
> Wouldn't it be better to have the order of subdir and hash swapped? That
> way subdir may contain blanks, and it gives nicer alignment in the file
> because of the constant length of the hashes.
Unfortunately, it is the hash that is optional. When you create the file, you
don't list the hashes, you list the subdirectories. I suppose I could make
it so you have to give "000000" or something first?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply related
* Re: [RFC/PATCH] Implement poor-man's submodule support using commit hooks
From: Andy Parkins @ 2006-12-20 13:48 UTC (permalink / raw)
To: git
In-Reply-To: <20061220133648.GQ12411@admingilde.org>
On Wednesday 2006 December 20 13:36, Martin Waitz wrote:
> I started with something similiar, too.
> You can have a look at http://git.admingilde.org/tali/git.git/module
> which tries to implement submodules without changing the core.
I wasn't really trying to do away with the need for core changes; I just
wanted something simple that I could use today.
If this is old news - no problem. Drop it.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support using commit hooks
From: Jakub Narebski @ 2006-12-20 14:07 UTC (permalink / raw)
To: git
In-Reply-To: <200612201347.13805.andyparkins@gmail.com>
Andy Parkins wrote:
> On Wednesday 2006 December 20 13:29, Johannes Sixt wrote:
>>> + while read subdir hash
>>
>> Wouldn't it be better to have the order of subdir and hash swapped? That
>> way subdir may contain blanks, and it gives nicer alignment in the file
>> because of the constant length of the hashes.
>
> Unfortunately, it is the hash that is optional. When you create the file, you
> don't list the hashes, you list the subdirectories. I suppose I could make
> it so you have to give "000000" or something first?
That's the convention git uses in git-diff, reflog, etc.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support using commit hooks
From: Johannes Sixt @ 2006-12-20 14:18 UTC (permalink / raw)
To: git
In-Reply-To: <200612201309.02119.andyparkins@gmail.com>
Andy Parkins wrote:
> + # check if the subdir is a repository
> + if [ ! -d "$WORKINGTOP$subdir/.git" ]; then
> + echo "$subdir is not a git repository, so it can't be a submodule"
You must redirect the message to >&2 otherwise it remains invisible (it
goes into file newgitmodules).
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support using commit hooks
From: Andy Parkins @ 2006-12-20 14:20 UTC (permalink / raw)
To: git
In-Reply-To: <embfus$d50$1@sea.gmane.org>
On Wednesday 2006 December 20 14:07, Jakub Narebski wrote:
> > Unfortunately, it is the hash that is optional. When you create the
> > file, you don't list the hashes, you list the subdirectories. I suppose
> > I could make it so you have to give "000000" or something first?
>
> That's the convention git uses in git-diff, reflog, etc.
They are all outputs though; this is an input. I did it that way round so
that I could say:
cat .gitmodules <<EOF
submodule1
submodule2
EOF
And that was it. Of course, this doesn't work when there are spaces in the
filename, so I guess it's got to be
cat .gitmodules <<EOF
000 submodule1
000 submodule2
EOF
I'll wait to see if there are more objections before posting an updated patch.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support using commit hooks
From: Rogan Dawes @ 2006-12-20 14:33 UTC (permalink / raw)
To: Andy Parkins; +Cc: Git Mailing List
In-Reply-To: <200612201347.13805.andyparkins@gmail.com>
Andy Parkins wrote:
> On Wednesday 2006 December 20 13:29, Johannes Sixt wrote:
>
>>> + cat "$GITMODULES" |
>> useless-use-of-cat-syndrome
>
> I tried
>
> while
> do
> done < file1 > file1
>
> And that didn't work.
It wouldn't, since the redirection overwrites the file at the same time
as trying to read from it. A better way is to redirect to a temp file,
and rename it if the previous operation was successful.
e.g.
0 $ echo true > t
0 $ sed 's/true/false/g' < t > t~ && mv t~ t || rm t~
0 $ cat t
false
and
0 $ echo true > t
0 $ (sed 's/true/false/g' < t > t~; false) && mv t~ t || rm t~
0 $ cat t
true
0 $ ls t~
ls: t~: No such file or directory
2 $
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support using commit hooks
From: Andy Parkins @ 2006-12-20 14:35 UTC (permalink / raw)
To: git
In-Reply-To: <20061220133648.GQ12411@admingilde.org>
On Wednesday 2006 December 20 13:36, Martin Waitz wrote:
> I started with something similiar, too.
> You can have a look at http://git.admingilde.org/tali/git.git/module
> which tries to implement submodules without changing the core.
I had a look at that; and my previous objection still applies: it blends two
repositories. I'd rather they were separate.
Having them separate is what makes my little hook scripts really simple; there
is no special initialisation script needed, and the neither the supermodule
nor the submodule needs special treatment; and there is no need for any
alternates or new object type. If I want to forget about submodule support I
just delete the .gitmodules file and it's all back to normal.
I don't say you're wrong in your chosen method, and I don't say I'm right. I
wasn't really planning on going much further with these scripts, they
actually represent all that I personally want from a submodule system, I am
sure others would want far more sophistication.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC/PATCH] Implement poor-man's submodule support using commit hooks
From: Andy Parkins @ 2006-12-20 14:40 UTC (permalink / raw)
To: git
In-Reply-To: <458949C4.1020207@dawes.za.net>
On Wednesday 2006 December 20 14:33, Rogan Dawes wrote:
> It wouldn't, since the redirection overwrites the file at the same time
Of course you are correct; however it wasn't completely crazy. Before now,
I've replaced files in C by doing
fd_old = open( "someexistingfile" );
unlink( "someexistingfile" );
fd_new = open( "someexistingfile" );
So I was really just trying it in case bash did a similar thing internally.
> as trying to read from it. A better way is to redirect to a temp file,
> and rename it if the previous operation was successful.
That's what I ended up doing; as you say it's better anyway because the error
conditions don't mean that the .gitmodules file ends up half written.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* [BUG] git --git-dir dies with bus error
From: Brian Gernhardt @ 2006-12-20 14:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jakub Narebski, git
In-Reply-To: <45892E16.2040301@op5.se>
On Dec 20, 2006, at 7:35 AM, Andreas Ericsson wrote:
> AFAIR, the discussions long ago went along the lines of "if no
> argument is passed to any of the --*-dir options, print out the
> current value". If "git --git-dir" doesn't print the directory name
> of the .git directory inside the repo you're currently in, I'd
> consider it a bug.
Consider this a bug then:
$ git --git-dir
Bus error
$ git --version
git version 1.4.4.1.GIT
$ git rev-parse origin/master
8336afa563fbeff35e531396273065161181f04c
$ gdb git
(gdb) set args --git-dir
(gdb) run
Starting program: /usr/local/stow/git/src/git/git --git-dir
Reading symbols for shared libraries ..+ done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x900332e6 in setenv ()
(gdb) bt
#0 0x900332e6 in setenv ()
#1 0x00001f9e in handle_options (argv=0xbffff4a4, argc=0xbffff4a0)
at git.c:76
#2 0x000022da in main (argc=1, argv=0xbffff504, envp=0xbffff50c) at
git.c:346
My current HEAD (and installed version) just includes my "remove
COLLISION_CHECK" patch on top of git master. This is on OS 10.4.8
with fink 0.26. It appears to be trying to set GIT_DIR to some non-
set section of memory. Bad git, bad. I'd try to patch this myself
(to at least display an error instead of dying), but I'm deep in my
actual project code right now.
^ permalink raw reply
* [PATCH] rev-list: Document --skip and add test cases.
From: Robert Fitzsimons @ 2006-12-20 14:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Fitzsimons, git
In-Reply-To: <7vbqlznzjm.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
---
> I am having a hard time convincing myself that this is a feature
> that is a narrow special case for rev-list and does not belong
> to the generic revision traversal machinery.
Your implementation is much better then mine. Here's some documentation
and a set of test cases.
Robert
Documentation/git-rev-list.txt | 5 ++++
t/t6005-rev-list-count.sh | 51 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index ec43c0b..9e0dcf8 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -10,6 +10,7 @@ SYNOPSIS
--------
[verse]
'git-rev-list' [ \--max-count=number ]
+ [ \--skip=number ]
[ \--max-age=timestamp ]
[ \--min-age=timestamp ]
[ \--sparse ]
@@ -139,6 +140,10 @@ limiting may be applied.
Limit the number of commits output.
+--skip='number'::
+
+ Skip 'number' commits before starting to show the commit output.
+
--since='date', --after='date'::
Show commits more recent than a specific date.
diff --git a/t/t6005-rev-list-count.sh b/t/t6005-rev-list-count.sh
new file mode 100755
index 0000000..334fccf
--- /dev/null
+++ b/t/t6005-rev-list-count.sh
@@ -0,0 +1,51 @@
+#!/bin/sh
+
+test_description='git-rev-list --max-count and --skip test'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ for n in 1 2 3 4 5 ; do \
+ echo $n > a ; \
+ git add a ; \
+ git commit -m "$n" ; \
+ done
+'
+
+test_expect_success 'no options' '
+ test $(git-rev-list HEAD | wc -l) = 5
+'
+
+test_expect_success '--max-count' '
+ test $(git-rev-list HEAD --max-count=0 | wc -l) = 0 &&
+ test $(git-rev-list HEAD --max-count=3 | wc -l) = 3 &&
+ test $(git-rev-list HEAD --max-count=5 | wc -l) = 5 &&
+ test $(git-rev-list HEAD --max-count=10 | wc -l) = 5
+'
+
+test_expect_success '--max-count all forms' '
+ test $(git-rev-list HEAD --max-count=1 | wc -l) = 1 &&
+ test $(git-rev-list HEAD -1 | wc -l) = 1 &&
+ test $(git-rev-list HEAD -n1 | wc -l) = 1 &&
+ test $(git-rev-list HEAD -n 1 | wc -l) = 1
+'
+
+test_expect_success '--skip' '
+ test $(git-rev-list HEAD --skip=0 | wc -l) = 5 &&
+ test $(git-rev-list HEAD --skip=3 | wc -l) = 2 &&
+ test $(git-rev-list HEAD --skip=5 | wc -l) = 0 &&
+ test $(git-rev-list HEAD --skip=10 | wc -l) = 0
+'
+
+test_expect_success '--skip --max-count' '
+ test $(git-rev-list HEAD --skip=0 --max-count=0 | wc -l) = 0 &&
+ test $(git-rev-list HEAD --skip=0 --max-count=10 | wc -l) = 5 &&
+ test $(git-rev-list HEAD --skip=3 --max-count=0 | wc -l) = 0 &&
+ test $(git-rev-list HEAD --skip=3 --max-count=1 | wc -l) = 1 &&
+ test $(git-rev-list HEAD --skip=3 --max-count=2 | wc -l) = 2 &&
+ test $(git-rev-list HEAD --skip=3 --max-count=10 | wc -l) = 2 &&
+ test $(git-rev-list HEAD --skip=5 --max-count=10 | wc -l) = 0 &&
+ test $(git-rev-list HEAD --skip=10 --max-count=10 | wc -l) = 0
+'
+
+test_done
--
1.4.4.2.g80fef-dirty
^ permalink raw reply related
* Re: Corrupt pack file using older versions of git on a newer repo..
From: Nicolas Pitre @ 2006-12-20 15:30 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP11ADF6C984028A9DED853FAECF0@CEZ.ICE>
On Wed, 20 Dec 2006, Sean wrote:
>
> This is probably expected behavior, but when bisecting another Git
> issue[1], i found that after a fresh clone of the git repository using
> 1.4.4.2 I got the following corrupt pack file when accessing that repo
> with an old version of git:
>
> $ git --version
> git version 1.4.2
>
> $ git log
> fatal: corrupted pack file .git/objects/pack/pack-d75f6a8307f8d8ce9727fe27107486839c54aef6.pack
To make that repository accessible with older git versions simply run
git-repack -a -d using version 1.4.4.2.
The clone with version 1.4.4.2 added OBJ_OFS_DELTA objects to the pack
which older git versions don't know about. Those objects are used for
pack transport when both ends know about them as they take less space.
But the repack doesn't use them by default so a full repack will get rid
of them automatically.
^ 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