* Re: Do "git add" as a builtin
From: Linus Torvalds @ 2006-05-18 16:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605180917060.10823@g5.osdl.org>
On Thu, 18 May 2006, Linus Torvalds wrote:
> >
> > But if people are ok with changing it from a "print a warning and ignore"
> > into an _error_, we could just move it into "add_cache_entry()".
>
> This is the incremental patch to do that instead, if you prefer it.
Thinking some more about it, I think I personally much prefer this.
Especially as a quick look-through seems to say that there's actually a
path through git-update-index too that allows a unverified filename to get
into the index (the new "--unresolve" thing also misses the need to verify
the path).
Making it a fatal error makes it more obvious that the user did something
fundamentally wrong. And the safety in doing it in add_cache_entry() just
makes be happier, particularly in light of the above problem with
--unresolve.
That still leaves the question of whether we should also drop all the
"verify_path()" calls in update-index.c, and make it fatal there too. I
think we probably should.
(At that point we could turn verify_path() back into a static function,
this time local entirely to read-cache.c, rather than update-index.c)
Linus
^ permalink raw reply
* Re: Do "git add" as a builtin
From: Junio C Hamano @ 2006-05-18 16:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605180929450.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Thinking some more about it, I think I personally much prefer this.
I like this much better than the old (pre-builtin) behaviour.
> Especially as a quick look-through seems to say that there's actually a
> path through git-update-index too that allows a unverified filename to get
> into the index (the new "--unresolve" thing also misses the need to verify
> the path).
Perhaps, but unresolve splits an entry that is available from
the heads being merged, so it would use unverified filename to
try finding the ents from trees, but get_tree_entry() would not
find one, so I think we are safe already. Nevertheless, I think
your change makes things more strict and safer.
I doubt this would break people's scripts. If they were relying
on the old behaviour, that means they threw real paths and
garbage at update-index and relied on it to sift them apart,
which indicates they were buggy to begin with anyway.
^ permalink raw reply
* Re: Do "git add" as a builtin
From: Linus Torvalds @ 2006-05-18 17:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmhfnupz.fsf@assigned-by-dhcp.cox.net>
On Thu, 18 May 2006, Junio C Hamano wrote:
>
> Perhaps, but unresolve splits an entry that is available from
> the heads being merged, so it would use unverified filename to
> try finding the ents from trees, but get_tree_entry() would not
> find one, so I think we are safe already.
Yes, I agree, that looks safe.
> I doubt this would break people's scripts. If they were relying
> on the old behaviour, that means they threw real paths and
> garbage at update-index and relied on it to sift them apart,
> which indicates they were buggy to begin with anyway.
Agreed. I don't think the semantic change can really break anything, and
if anything will probably help expose any really strange/broken stuff.
Linus
^ permalink raw reply
* git status and empty directories
From: Matthias Lederhofer @ 2006-05-18 17:57 UTC (permalink / raw)
To: git
Today I've been working on some source with many empty directories.
git-status shows all empty directories under "Untracked files: (use
"git add" to add to commit)" but adding is impossible. And if it would
be possible to add the directory, because a new file exists in the
directory, it still shows up in the same place, indistinguishable from
the empty directories.
Things I could think of to solve this:
- hide empty directories if the user does not ask explicitly for them
with a command line option
- vice versa: add a command line option to hide empty directories
(I'd prefer the first one)
Another category in git-status for empty directories which cannot be
added could be interesting too because the comment 'use "git add" to
add to commit' is quite misleading.
Perhaps there should also be another option to show files in untracked
directories.
Any comments? If a patch would be accepted I'll take a look at
writing one. Adding the correct options to git-ls-files seems quite
trivial.
^ permalink raw reply
* Re: git status and empty directories
From: Linus Torvalds @ 2006-05-18 18:12 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <E1Fgmkh-0000ur-Hn@moooo.ath.cx>
On Thu, 18 May 2006, Matthias Lederhofer wrote:
>
> - hide empty directories if the user does not ask explicitly for them
> with a command line option
Like this?
Makes sense to me, although I didn't add the option to disable it.
Linus
---
diff --git a/git-commit.sh b/git-commit.sh
index 6ef1a9d..ed00b5c 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -136,11 +136,11 @@ #'
if test -f "$GIT_DIR/info/exclude"
then
- git-ls-files -z --others --directory \
+ git-ls-files -z --others --directory --no-empty-directory \
--exclude-from="$GIT_DIR/info/exclude" \
--exclude-per-directory=.gitignore
else
- git-ls-files -z --others --directory \
+ git-ls-files -z --others --directory --no-empty-directory \
--exclude-per-directory=.gitignore
fi |
perl -e '$/ = "\0";
^ permalink raw reply related
* Re: git status and empty directories
From: Matthias Lederhofer @ 2006-05-18 18:29 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605181112040.10823@g5.osdl.org>
> Like this?
This is exactly the patch I'm using at the moment and I don't really
need an option to unhide empty directories. Maybe someone else
complains for some reason but git clean -d -n shows empty directories
too.
An option to show untracked files instead of untracked directories
like
> git-ls-files -z --others --exclude-per-directory=.gitignore
would be interesting to see what would be added instead of doing ls
manually.
^ permalink raw reply
* Re: Shipping man pages?
From: Junio C Hamano @ 2006-05-18 18:33 UTC (permalink / raw)
To: Mark Rosenstand; +Cc: git, Tilman Sauerbeck
In-Reply-To: <1147945298.1320.35.camel@mjollnir>
Mark Rosenstand <mark@borkware.net> writes:
> On Thu, 2006-05-18 at 01:06 -0700, Junio C Hamano wrote:
>
>> If you are building from the source, please build from the
>> source. Everything you need is right there.
>
> But asciidoc is a royal PITA to package or install - it doesn't even
> provide a Makefile: http://www.methods.co.nz/asciidoc/userguide.html#X38
>
> Additionally it carries the whole docbook dependency chain with it.
That's a consequence of _your_ choice to build the documentation
files from the source, when I give you preformatted files in
html/man branches and/or prepackaged binary distributions. Even
plain "make all" nor "make install" do not build them.
IOW, not my problem.
We accomplish things by saying "I did this, it solves my
problem, and it would help others -- so I share", not by
demanding others to do things for you by saying "If you do this,
it would solve my problem. Now go do it". That's how open
source works.
>> Why does this have to come up so often, and everybody who asks
>> for them never supplies the patch to do so?
>
> Because it seems like a political decision rather than a technical one
I do not see why that is political. Do you need a politician to
tell you what is source and what isn't?
> (it's trivial to add the docs as a prerequisite for the dist target.)
Being trivial does not change things a whit, because I do not do
things I consider useless only because they are trivial.
You have to first convince me that it is useful to others, and
one way to do so is by showing that you care deeply enough about
it -- doing the work yourself (instead of demanding _me_ to do
something I do not believe is a good idea yet) is a good way to
do so. That would tell me that it is a real problem to you.
When that happens, I might start considering the possibility
that a solution to that problem may be useful to other people.
And it actually makes things actively worse to whine without
doing the work yourself when the necessary change is trivial.
You are saying that you cannot be bothered to do that yourself
even though the change is trivial, which implies you _can_ live
without formatted pages just fine. The conclusion is that not
having the formatted pages is not such a big deal to you (after
all, asciidoc toolchain might be a bear to install, but the
documents formatted in it are very easy to read in the source
form).
Now, with a patch, Tilman showed us he cares deeply enough, so
I'll take a look at it. Thanks, Tilman.
^ permalink raw reply
* Re: Shipping man pages?
From: Linus Torvalds @ 2006-05-18 18:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Rosenstand, git, Tilman Sauerbeck
In-Reply-To: <7vodxvkws8.fsf@assigned-by-dhcp.cox.net>
On Thu, 18 May 2006, Junio C Hamano wrote:
>
> That's a consequence of _your_ choice to build the documentation
> files from the source, when I give you preformatted files in
> html/man branches and/or prepackaged binary distributions. Even
> plain "make all" nor "make install" do not build them.
Btw, in case others didn't notice, the easiest way to install the
pre-packaged branch is a truly disgusting hack:
cd git
git tar-tree man | (cd /usr/share/man ; tar xvf -)
or similar (yeah, you need to be root to do the unpack, of course, and
you may need to change the /usr/share/man to whatever is appropriate for
your distribution).
No need to actually even check out the 'man' branch.
Linus
^ permalink raw reply
* Feature wish: Cloning without history
From: Sven Ekman @ 2006-05-18 19:21 UTC (permalink / raw)
To: git
Hello,
Would it be possible to add an option to git-clone to
skip the complete history? The result should be a
repository which contains the current head only (or
maybe a specified tag) and has that commit id added to
.git/info/grafts. For the fetch process, this would
certainly have to imply the --no-tags flag.
>From a user's point of view I'd imagine something like
this:
git-clone --no-history=v2.6.16 \
git://git.kernel.org/.../linux-2.6.git
The background: I'm regularly building kernels for a
handful of machines, and while I am happy to use the
blessings of git to get updates from the -stable
releases, I see no point in wasting space for a copy
of the complete kernel history on every single
machine. In practice this works pretty good, once I
have manually created such a castrated repository.
Sven
^ permalink raw reply
* Re: Feature wish: Cloning without history
From: Jakub Narebski @ 2006-05-18 19:35 UTC (permalink / raw)
To: git
In-Reply-To: <20060518192144.15912.qmail@web25913.mail.ukl.yahoo.com>
Sven Ekman wrote:
> Would it be possible to add an option to git-clone to
> skip the complete history? The result should be a
> repository which contains the current head only (or
> maybe a specified tag) and has that commit id added to
> .git/info/grafts. For the fetch process, this would
> certainly have to imply the --no-tags flag.
It is certainly reccuring request.
Check for "shallow clone" in git mailing list archives.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Make "git rev-list" be a builtin
From: Linus Torvalds @ 2006-05-18 21:19 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This was surprisingly easy. The diff is truly minimal: rename "main()" to
"cmd_rev_list()" in rev-list.c, and rename the whole file to reflect its
new built-in status.
We should have done this long ago.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
[ NOTE! The diff is a git-only "git diff -M" with rename information,
because quite frankly, it's just a hell of a lot more readable that way.
But I thought I'd mention it explicitly, since it won't apply for
anybody who tries to apply it as a regular unified diff with "patch" ]
Makefile | 6 +++---
rev-list.c => builtin-rev-list.c | 3 ++-
builtin.h | 1 +
git.c | 1 +
4 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 3a28580..281fa69 100644
--- a/Makefile
+++ b/Makefile
@@ -158,7 +158,7 @@ PROGRAMS = \
git-ls-files$X git-ls-tree$X git-mailinfo$X git-merge-base$X \
git-merge-index$X git-mktag$X git-mktree$X git-pack-objects$X git-patch-id$X \
git-peek-remote$X git-prune-packed$X git-read-tree$X \
- git-receive-pack$X git-rev-list$X git-rev-parse$X \
+ git-receive-pack$X git-rev-parse$X \
git-send-pack$X git-show-branch$X git-shell$X \
git-show-index$X git-ssh-fetch$X \
git-ssh-upload$X git-tar-tree$X git-unpack-file$X \
@@ -170,7 +170,7 @@ PROGRAMS = \
BUILT_INS = git-log$X git-whatchanged$X git-show$X \
git-count-objects$X git-diff$X git-push$X \
- git-grep$X git-add$X
+ git-grep$X git-add$X git-rev-list$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
@@ -218,7 +218,7 @@ LIB_OBJS = \
BUILTIN_OBJS = \
builtin-log.o builtin-help.o builtin-count.o builtin-diff.o builtin-push.o \
- builtin-grep.o builtin-add.o
+ builtin-grep.o builtin-add.o builtin-rev-list.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/rev-list.c b/builtin-rev-list.c
similarity index 99%
rename from rev-list.c
rename to builtin-rev-list.c
index 235ae4c..171f9d5 100644
--- a/rev-list.c
+++ b/builtin-rev-list.c
@@ -7,6 +7,7 @@ #include "blob.h"
#include "tree-walk.h"
#include "diff.h"
#include "revision.h"
+#include "builtin.h"
/* bits #0-15 in revision.h */
@@ -291,7 +292,7 @@ static void mark_edges_uninteresting(str
}
}
-int main(int argc, const char **argv)
+int cmd_rev_list(int argc, const char **argv, char **envp)
{
struct commit_list *list;
int i;
diff --git a/builtin.h b/builtin.h
index ccd0e31..a94d728 100644
--- a/builtin.h
+++ b/builtin.h
@@ -26,5 +26,6 @@ extern int cmd_count_objects(int argc, c
extern int cmd_push(int argc, const char **argv, char **envp);
extern int cmd_grep(int argc, const char **argv, char **envp);
extern int cmd_add(int argc, const char **argv, char **envp);
+extern int cmd_rev_list(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index 6a470cf..e2bba53 100644
--- a/git.c
+++ b/git.c
@@ -52,6 +52,7 @@ static void handle_internal_command(int
{ "diff", cmd_diff },
{ "grep", cmd_grep },
{ "add", cmd_add },
+ { "rev-list", cmd_rev_list },
};
int i;
rename rev-list.c => builtin-rev-list.c (99%)
^ permalink raw reply related
* [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Yann Dirson @ 2006-05-18 21:35 UTC (permalink / raw)
To: junkio; +Cc: git
This test fails with 1.3.x and HEAD. This is a very serious bug, since it
causes data loss.
I am not sure whether it is normal that git-fsck-objects does not retun an
error code, while we can see it reports the inconsistency in --verbose
mode. At least trying to directly access the dropped commit triggers an
error anyway.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
t/t6200-prune-grafts.sh | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/t/t6200-prune-grafts.sh b/t/t6200-prune-grafts.sh
new file mode 100755
index 0000000..80d0d59
--- /dev/null
+++ b/t/t6200-prune-grafts.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Yann Dirson
+#
+set -e
+
+test_description='Test that git-prune does not nuke revs hidden by a graft'
+
+. ./test-lib.sh
+
+echo First > A && git-add A && git-commit -m "Add A."
+echo First > B && git-add B && git-commit -m "Add B."
+echo Second >> A && git-update-index A && git-commit -m "Append to A."
+
+test_expect_success 'initial state is valid' 'git-fsck-objects'
+
+echo $(git-rev-parse HEAD) $(git-rev-parse HEAD^^) > .git/info/grafts
+
+test_expect_success 'grafted state is valid' 'git-fsck-objects'
+test_expect_success 'prune with the graft in effect' 'git-prune'
+test_expect_success 'grafted state is valid' 'git-fsck-objects'
+
+rm .git/info/grafts
+
+test_expect_success 'grafted state is still valid' 'git-fsck-objects'
+test_expect_success 'previously-hidden rev is still there' 'git-cat-file commit HEAD^'
+
+test_done
^ permalink raw reply related
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Linus Torvalds @ 2006-05-18 21:37 UTC (permalink / raw)
To: Yann Dirson; +Cc: junkio, git
In-Reply-To: <20060518213519.14577.67309.stgit@gandelf.nowhere.earth>
On Thu, 18 May 2006, Yann Dirson wrote:
>
> This test fails with 1.3.x and HEAD. This is a very serious bug, since it
> causes data loss.
Is it/does it?
I'd assume that if you have a graft, you _want_ the history to be hidden
and pruned.
That's how you'd drop history, if you wanted to do it on purpose.
Linus
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Junio C Hamano @ 2006-05-18 21:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605181435230.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Is it/does it?
>
> I'd assume that if you have a graft, you _want_ the history to be hidden
> and pruned.
>
> That's how you'd drop history, if you wanted to do it on purpose.
I haven't looked at what the test does, but I think he is
talking about the opposite. fsck by design does not honor
grafts, and if you grafted a history back to your true root
commit, that "older" history will be lost.
^ permalink raw reply
* Re: Make "git rev-list" be a builtin
From: Junio C Hamano @ 2006-05-18 21:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605181415090.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This was surprisingly easy. The diff is truly minimal: rename "main()" to
> "cmd_rev_list()" in rev-list.c, and rename the whole file to reflect its
> new built-in status.
>
> We should have done this long ago.
Should we have?
Certainly it is almost trivial, and it means we need to worry
about one less file, but is that the point?
^ permalink raw reply
* tailor (Was: gateway status?)
From: Yann Dirson @ 2006-05-18 22:07 UTC (permalink / raw)
To: Martin Langhoff; +Cc: David Lang, git
In-Reply-To: <46a038f90605160609u19a356ccx9467c32100731b9@mail.gmail.com>
On Wed, May 17, 2006 at 01:09:19AM +1200, Martin Langhoff wrote:
> On 5/16/06, David Lang <dlang@digitalinsight.com> wrote:
> >I seem to remember seeing discussion of gateways to cvs/svn that would let
> >a project use a git repository and allow clients to use cvs/svn clients to
> >retreive data.
>
> I suspect you might be thinking of git-cvsserver. The code has no
> known bugs, but is has only seen limited use by in-house dev teams.
Another tool that I don't see mentionned often here is tailor, which
has the ability to act as a gatway between git and a good selection of
other SCMs, including cvs and svn. I have not yet tried it with git
though, so any comments from people having shaked it a bit would be
useful :)
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: Make "git rev-list" be a builtin
From: Linus Torvalds @ 2006-05-18 22:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejyrngto.fsf@assigned-by-dhcp.cox.net>
On Thu, 18 May 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> >
> > We should have done this long ago.
>
> Should we have?
>
> Certainly it is almost trivial, and it means we need to worry
> about one less file, but is that the point?
Take a look at the size of the binaries before and after.
This is the _stripped_ binaries (on ppc) before:
-rwxr-xr-x 9 torvalds torvalds 213392 May 18 14:56 git
-rwxr-xr-x 1 torvalds torvalds 167540 May 18 14:56 git-rev-list
and after:
-rwxr-xr-x 10 torvalds torvalds 216740 May 18 14:56 git
-rwxr-xr-x 10 torvalds torvalds 216740 May 18 14:56 git-rev-list
ie the "git" binary grew by about 3kB, and the "git-rev-list" binary
shrank by about 164kB (because it now takes zero disk-space: it's the same
as the git binary).
So on ppc, you win about 160kB of disk space from this (and much more if
you don't strip the binaries - "git-rev-list" is over half a megabyte
with the debugging info for me).
Now, x86 probably has less of that, because it's a denser instruction set,
but I'd expect that to be in the 100kB range too.
Linus
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Linus Torvalds @ 2006-05-18 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viro3nh07.fsf@assigned-by-dhcp.cox.net>
On Thu, 18 May 2006, Junio C Hamano wrote:
>
> I haven't looked at what the test does, but I think he is
> talking about the opposite. fsck by design does not honor
> grafts, and if you grafted a history back to your true root
> commit, that "older" history will be lost.
Ahh. Ok. Gotcha.
Linus
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Yann Dirson @ 2006-05-18 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7viro3nh07.fsf@assigned-by-dhcp.cox.net>
On Thu, May 18, 2006 at 02:46:16PM -0700, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > Is it/does it?
> >
> > I'd assume that if you have a graft, you _want_ the history to be hidden
> > and pruned.
> >
> > That's how you'd drop history, if you wanted to do it on purpose.
>
> I haven't looked at what the test does, but I think he is
> talking about the opposite. fsck by design does not honor
> grafts, and if you grafted a history back to your true root
> commit, that "older" history will be lost.
I'm not sure I understand what you're saying. AFACT fsck does not
ignore grafts: if a rev is not accessible from heads because of a
graft, prune drops it, and fsck does not see a problem.
Linus, I understand your point, but the current situation is
problematic: a graft does not get propagated by cg-clone (and I
suppose not by git-clone or git-fetch either), so cloning a tree which
has undergone such a pruning operation results in an incomplete clone
(indeed it is how I met the problem). Since grafts are supposed to
have local effect only (as far as I understand), I see it as a bad
indication to have such a remote effect.
Maybe to make things safe, prune should by default consider both
physical and grafted parents as accessible, and a flag could be added
to get the current behaviour for people really knowing what they're
doing ?
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: tailor (Was: gateway status?)
From: Martin Langhoff @ 2006-05-18 22:16 UTC (permalink / raw)
To: Yann Dirson; +Cc: David Lang, git
In-Reply-To: <20060518220759.GA6535@nowhere.earth>
On 5/19/06, Yann Dirson <ydirson@altern.org> wrote:
> Another tool that I don't see mentionned often here is tailor, which
> has the ability to act as a gatway between git and a good selection of
> other SCMs, including cvs and svn. I have not yet tried it with git
> though, so any comments from people having shaked it a bit would be
> useful :)
Last I looked, a few months ago, it didn't track branches.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Junio C Hamano @ 2006-05-18 22:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Yann Dirson
In-Reply-To: <Pine.LNX.4.64.0605181500470.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 18 May 2006, Junio C Hamano wrote:
>>
>> I haven't looked at what the test does, but I think he is
>> talking about the opposite. fsck by design does not honor
>> grafts, and if you grafted a history back to your true root
>> commit, that "older" history will be lost.
>
> Ahh. Ok. Gotcha.
>
> Linus
Is it really OK?
I said "fsck by design does not honor" as a flamebait.
And what I said was completely untrue. Sorry.
If you have a commit chain A->B->C and graft B away by saying
C's parent is A, fsck does read graft and discards B. But that
is what the user asked to do, so I agree with your initial
response to Yann.
And the opposite case of grafting older history back to the real
root commit was a false alarm. You would not lose such a
history, because the ancestry traversal will go right through
the real root and traverses the older history.
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Junio C Hamano @ 2006-05-18 22:36 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20060518222045.GB6535@nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> I'm not sure I understand what you're saying.
Please don't; I was asleep when I typed it -- sorry.
I was hoping fsck was doing the right thing for a very low level
tool -- verify commit objects itself, without relying on the
object parser machinery which does funky things like grafts.
Apparently it doesn't -- which is mostly good. You can safely
remove commits you wanted to discard by grafting it away like
your test did, and you can keep unrelated history you grafted to
the back of your real root commit.
For the "clone without propagating grafts" issue, I think we
need to have a way to communicate grafts across repositories.
As you say, grafts is a local policy issue, but when you start
cloning you _are_ sharing that local policy across repositories.
Futzing fsck to honor and ignore grafts at the same time sounds
like a band-aid to me.
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Yann Dirson @ 2006-05-18 22:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <20060518222045.GB6535@nowhere.earth>
On Fri, May 19, 2006 at 12:20:45AM +0200, Yann Dirson wrote:
> On Thu, May 18, 2006 at 02:46:16PM -0700, Junio C Hamano wrote:
> > Linus Torvalds <torvalds@osdl.org> writes:
> >
> > > Is it/does it?
> > >
> > > I'd assume that if you have a graft, you _want_ the history to be hidden
> > > and pruned.
> > >
> > > That's how you'd drop history, if you wanted to do it on purpose.
> >
> > I haven't looked at what the test does, but I think he is
> > talking about the opposite. fsck by design does not honor
> > grafts, and if you grafted a history back to your true root
> > commit, that "older" history will be lost.
>
> I'm not sure I understand what you're saying. AFACT fsck does not
> ignore grafts: if a rev is not accessible from heads because of a
> graft, prune drops it, and fsck does not see a problem.
>
> Linus, I understand your point, but the current situation is
> problematic: a graft does not get propagated by cg-clone (and I
> suppose not by git-clone or git-fetch either), so cloning a tree which
> has undergone such a pruning operation results in an incomplete clone
> (indeed it is how I met the problem). Since grafts are supposed to
> have local effect only (as far as I understand), I see it as a bad
> indication to have such a remote effect.
To make my point maybe more clear: if someone really wants to make a
graft permanent, wouldn't some history rewriting (eg. with
cg-admin-rewritehist, but see the patch I posted against it) be the
way to go, instead of relying on out-of-band transfer of graft data ?
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Junio C Hamano @ 2006-05-18 22:53 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20060518225216.GC6535@nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> To make my point maybe more clear: if someone really wants to make a
> graft permanent, wouldn't some history rewriting ... be the
> way to go,...
Yes.
^ permalink raw reply
* [PATCH] Allow pickaxe to be used via git log.
From: Sean @ 2006-05-19 1:31 UTC (permalink / raw)
To: git
Handle the -S option when passed to git log such that only the appropriate
commits are displayed. Unlike "whatchanged", by default no diff output
is produced.
---
This came out of recent comments on #git and will hopefully further reduce
the need for git-whatchanged.
ecdfaa21dbff93a6a387b02e1f1d3ebf05ee517d
revision.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
ecdfaa21dbff93a6a387b02e1f1d3ebf05ee517d
diff --git a/revision.c b/revision.c
index 2294b16..2e18b2b 100644
--- a/revision.c
+++ b/revision.c
@@ -743,6 +743,13 @@ int setup_revisions(int argc, const char
continue;
}
opts = diff_opt_parse(&revs->diffopt, argv+i, argc-i);
+ if (revs->diffopt.pickaxe && revs->always_show_header) {
+ revs->always_show_header = 0;
+ revs->diff = 1;
+ revs->diffopt.recursive = 1;
+ if (revs->diffopt.output_format == DIFF_FORMAT_RAW)
+ revs->diffopt.output_format = DIFF_FORMAT_NO_OUTPUT;
+ }
if (opts > 0) {
revs->diff = 1;
i += opts - 1;
--
1.3.GIT
^ 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