* Re: git-fetch fails with error code 128
From: Shawn Pearce @ 2006-12-14 23:19 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612142308.45376.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> $ git fetch
> remote: Generating pack...
> remote: Done counting 189146 objects.
> remote: Result has 186566 objects.
> remote: Deltifying 186566 objects.
> remote: 100% (186566/186566) done
> Unpacking 186566 objects
> fatal: failed to apply delta
> fatal: unpack-objects died with error code 128
> Fetch failure: /home/andyp/projects/temp/.git
>
> What does that mean? I ran fsck --full on the source repository, but it's
> made no difference.
Bad voodoo. What does 'git fetch -k' do? It uses slightly
different code for handling the deltas...
--
^ permalink raw reply
* Re: git-fetch fails with error code 128
From: Horst H. von Brand @ 2006-12-14 23:25 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612142308.45376.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> This is with my big "every linux patch" repository that I talked about in
> another thread. To bring you up to speed:
[...]
> This gave me the following output:
>
> $ git fetch
> remote: Generating pack...
> remote: Done counting 189146 objects.
> remote: Result has 186566 objects.
> remote: Deltifying 186566 objects.
> remote: 100% (186566/186566) done
> Unpacking 186566 objects
> fatal: failed to apply delta
> fatal: unpack-objects died with error code 128
> Fetch failure: /home/andyp/projects/temp/.git
Happened to me yesterday or so pulling the vanilla kernel (big push shortly
before 2.6.20-rc1). Trying again somewhat later went through flawlessly.
Might have been git running out of memory.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Johannes Schindelin @ 2006-12-14 23:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xha2osd.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 14 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > git-show-ref traverses every single _local_ tag when called. This is to
> > overcome the problem that tags can be packed now, so a simple file
> > existence check is not sufficient.
>
> Is "traverses every single _local_ tag" a fact? It might go
> through every single _local_ (possibly stale) packed tag in
> memory but it should not traverse $GIT_DIR/refs/tags.
>
> If I recall correctly, show-ref (1) first checks the filesystem
> "$GIT_DIR/$named_ref" and says Ok if found and valid; otherwise
> (2) checks packed refs (reads $GIT_DIR/packed-refs if not
> already).
If I read builtin-show-ref.c correctly, it _always_ calls
for_each_ref(show_ref, NULL);
The only reason that the loop in for_each_ref can stop early is if
show_ref returns something different than 0. But it does not! Every single
return in show_ref() returns 0. It does not matter, though (see below).
> So that would be at most one open (which may fail in (1)) and one
> open+read (in (2)). Unless we are talking about fork+exec overhead,
> that "traverse" should be reasonably fast.
>
> Where is the bottleneck?
The problem is that so many stat()s _do_ take time. Again, if I read the
code correctly, it not only stat()s every loose ref, but also resolves the
refs in get_ref_dir(), which is called from get_loose_refs(), which is
unconditionally called in for_each_ref().
Even if the refs are packed, it takes quite _long_ (I confirmed this). And
it is not at all necessary! Instead of a O(n^2) we can easily reduce this
to O(n*log(n)), and we can reduce the n fork()&exec()s of git-show-ref by
a single one.
Ciao,
Dscho
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Shawn Pearce @ 2006-12-14 23:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Geert Bosch, Andreas Ericsson, Andy Parkins, git
In-Reply-To: <Pine.LNX.4.63.0612150013390.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 14 Dec 2006, Shawn Pearce wrote:
> > Geert Bosch <bosch@adacore.com> wrote:
> > > if (compressed_size > expanded_size / 4 * 3 + 1024) {
> > > /* don't try to deltify if blob doesn't compress well */
> > > return ...;
> > > }
> >
> > And yet I get good delta compression on a number of ZIP formatted files
> > which don't get good additional zlib compression (<3%). Doing the above
> > would cause those packfiles to explode to about 10x their current size.
>
> A pity. Geert's proposition sounded good to me.
>
> However, there's got to be a way to cut short the search for a delta
> base/deltification when a certain (maybe even configurable) amount of time
> has been spent on it.
I'm not sure time is the best rule there.
Maybe if the object is large (e.g. over 512 KiB or some configured
limit) and did not compress well when we last deflated it
(e.g. Geert's rule above) then only try to delta it against another
object whose hinted filename is very close/exactly matches and
whose size is very close, and don't make nearly as many attempts
on the matching hunks within any two files if the file appears to
be binary and not text.
I'm OK with a small increase in packfile size as a result of slightly
less optimal delta base selection on the really large binary files
due to something like the above, but 10x is insane.
--
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Josef Weidendorfer @ 2006-12-14 23:07 UTC (permalink / raw)
To: Torgil Svensson; +Cc: R. Steve McKown, Linus Torvalds, git
In-Reply-To: <e7bda7770612141327r11368e4dtabe8077e96545040@mail.gmail.com>
On Thursday 14 December 2006 22:27, Torgil Svensson wrote:
> This example is somewhat complex since the build for lib1.so and the
> header-file might not has gone through the same commit on the lib1
> subproject. Consider this example:
If you want to track build results for some source,
why would you ever want these builds go out of sync with the source?
As the built files depend on the source (and other things), the
source should be a submodule of the build project.
Hmm... I think I see a problem / wish for submodules here.
With the current submodule proposal, we force submodules to be
subdirectories inside of a supermodule.
Your example has the folling submodule dependence
("X ==> Y" means Y being a submodule of X):
App ==> Lib
^ ^
| |
AppBuild ==> LibBuild
If we force submodules to be subdirectories of supermodules,
Lib needlessly will have to appear two times in a checkout of
AppBuild.
However, there is nothing wrong with it. Yet, you perhaps want
the 2 Lib submodules not to go out of sync. This easily
can be done with symlinking the Lib checkouts. As they are submodules,
everything should work fine.
Perhaps an option you want to have is to force a checkout
of AppBuild to make these symlinking itself when it detects
identical submodules links.
Hmmm... the only problem with a symlink is that it can go wrong
when moved. Unfortunately, I do not have a good solution for
this. We can not make UNIX symlinks smart in any way.
Hardlinking directories would be a solution, but that is not
possible.
Another thing:
With normal "$buildroot != $srcroot" environments, the source
can not be a subdirectory of the build directory.
Yet, we want to specify submodule/supermodule relation.
This is difficult to do with a submodule object, as it needs
to appear in trees in the supermodule.
Actually, the best workaround for this is to make Lib a direct
submodule of AppBuild, and specify the relationship of
LibBuild ==> Lib only in AppBuild.
BTW, build project commits probably should not depend on any
history of other build commits.
So you actually want all build commits to be root commits, and
have a tag name which could include the source commit id from
which the build was done. This gives some loose coupling.
> Link: /headers/lib1.h -> <lib1-commit3>/src/lib1.h
> Link: /bin/lib1.so -> <build1-commit>/i386/lib1/lib1.so
> Link: /bin/app1 -> <build1-commit>/i386/app1/app1
>
>
> <lib1-commit1>, <lib1-commit2> and <lib1-commit3> should be the same,
> dictated by the app1 project.
I do not see any problem here. Symlinks are stored in the git repository.
As the AppBuild commit depends on App and LibBuild submodule commits, the
symlinks always should be correct.
> Can we enforce this in the modules file
> or should the different supermodules fix this somehow using
> scripts/hooks?
I do not see any need for an hook. But of course, a checkout hook should
be able to generate files/links. However, IMHO this should be not
done with hooks but with Makefile targets.
> How do the super-projects in this case get access to the blobs pointed
> by the links - transparent or explicit in the build-process?
Submodules should automatically be checked out when checking out the
supermodule. So the blobs should already be there.
Or do I miss something?
^ permalink raw reply
* Re: Using git as a general backup mechanism
From: Steven Grimm @ 2006-12-14 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfybkof3s.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> (2) End of week comes. Create an empty branch 'weekly' if you
> do not already have one. Make a full tree snapshot, and
> create a parentless commit for the week if the 'weekly'
> branch did not exist, or make it a child of the 'weekly'
> commit from the last week. Discard 'lastweek' branch if
> you have one, and rename 'daily' branch to 'lastweek'.
That sounds like it'd work, but doesn't it imply that the history of a
given file in the backups is not continuous? That is, an old copy of a
file on the "weekly" branch doesn't have any kind of ancestor
relationship with the same file on the "daily" branch? While that's
obviously no different than the current git-less situation where there's
no notion of ancestry at all, it'd be neat if this backup scheme could
actually track long-term changes to individual files.
I wonder if rebasing can get me what I want. Something like:
(1) Make a new branch from the latest daily. Commit a full tree
snapshot to the new branch. (Each branch has exactly one commit.)
(2) To expire a daily backup, rebase the second-oldest daily branch,
which will initially be a child of the oldest daily branch, under
the latest weekly branch instead. Delete the oldest daily branch.
I believe the right commands here would be:
git-rebase -s recursive -s ours --onto latest-weekly \
oldest-daily second-oldest-daily
git-branch -D oldest-daily
(Not sure about the double "-s", but I want it to detect renames
where possible and never flag any conflicts.)
(3) At the end of the week, instead of expiring the oldest daily
branch, rename it to indicate that it's now a weekly snapshot.
(That will implicitly do the first part of step 2, since the
next daily branch in line will already be a descendant of the
newly renamed branch.)
Repeat step 2, rebasing against the latest monthly branch,
to expire the oldest weekly.
(4) To expire an old monthly, rebase the second-oldest monthly branch
under the initial empty revision, then delete the oldest monthly.
This is basically step 2 again, but rebasing under a fixed starting
point.
(5) Run git-prune to expire the objects in the deleted branches, then
git-repack -a -d to delta-compress everything.
That's a bit convoluted, admittedly, and probably a perversion of
everything pure about the branch system, but would it work? The big
thing I'm not sure about here is whether, after doing my rebase and
delete in step 2, the objects from the oldest daily will actually be
removed by git-prune. They should be unreachable at that point, I think.
^ permalink raw reply
* Re: [PATCH] INSTALL: no need to have GNU diff installed
From: Johannes Schindelin @ 2006-12-14 23:40 UTC (permalink / raw)
To: Eric Wong; +Cc: git, junkio
In-Reply-To: <20061214204634.GF8179@localdomain>
Hi,
On Thu, 14 Dec 2006, Eric Wong wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > Since a long time, we have inbuilt diff generation.
>
> We still require it for running tests. And git-rerere just
> added a dependency on it (my fault :)
Ah! Some of the tests are my fault, since I find the output of "diff -u"
so much more pleasant than "cmp" when trying to find a bug.
How about adding a GNU diff look alike, say "git-file-diff"?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
From: J. Bruce Fields @ 2006-12-14 23:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061214231832.GF26202@spearce.org>
On Thu, Dec 14, 2006 at 06:18:32PM -0500, Shawn Pearce wrote:
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > Stupid question--I assume a mention in the reflog doesn't count as a
> > real reference to an object, so they won't save you in the case when you
> > pruned recently?
>
> Not a stupid question. Your assumption is correct, its not a real
> reference, so prune will remove things that the log mentions but
> that refs don't currently mention.
OK, thanks. So we just need to make sure that's documented someplace.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-14 23:46 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612142255.33564.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Thursday 2006, December 14 21:22, Junio C Hamano wrote:
>
>> This is interesting. You said "commit -b", were pointed out
>> that you were talking about "checkout -b", and just after saying
>> "yup, that is right, I was", you again say "commit -b".
>
> There truly is something wrong with me.
I did not mean it that way. I only took it as a sign that maybe
"first create and switch to a branch and then work and commit
there, in separate steps", which is how git encourages things to
be done, does not match people's mental model so well.
> I'm not sure about your "commit -b"; is it wise to have /another/ way of
> making a branch? I mean - I'm clearly confused enough, have a heart :-)
I said "commit -b <newbranch>" and deliberately avoided saying
"commit -b <anybranch>", because I did not want to open another
can of worms while we are discussing so many good things
already, and my head can hold only a handful topics at once.
But people on the list (and #git channel) sometimes wished an
easy way to help the following workflow.
* I am in the middle of working on a new feature. As a good
git user, I am on a topic branch dedicated for that purpose.
* While working on it, I find an obvious bug that I would not
want to fix on the branch (the topic branch I am currently on
is not about fixing that bug).
* But I fix it in the working tree anyway, because otherwise I
would forget. It happens to be in an isolated file that my
current topic does not need to modify (say, I was looking at
a function in that file that my new feature needs to call and
I wanted to study its calling convention. And I found a typo in
the comment near the function).
* The fix does not belong to the current topic, but can go to
the 'master' branch straight. It's a fix in the comment that
cannot possibly break things, and I can/will test it later
anyway.
* So with the existing set of tools, I would go there, commit
and then come back:
$ git checkout [-m] master
$ git commit -m 'fix typo in that-file' that-file
$ git checkout [-m] topic
But it might be faster to say:
$ git commit -b master -m 'fix typo in that-file' that-file
to make a commit on the other branch and come back
immediately afterwards.
* In the same situation, when the 'master' is closed for some
administrative reason (e.g. "deep freeze before a release and
strict bugfixes and nothing else are allowed"), I would create
a new 'typofix' branch and do the same. I can rebase it
later on 'master' when it reopens.
$ git commit -b typofix -m 'fix typo in that-file' that-file
... much later when master reopens ...
$ git rebase --onto master topic typofix
It's just a possible typesaver, but I am likely not using it
myself (my fingers are already trained to do the three command
sequence dance).
I do agree that it adds one more way to do the same thing and
would make the documentation noisier, potentially adding more to
the confusion. So let's not go there.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Horst H. von Brand @ 2006-12-14 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vk60vbcfz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
[...]
> In general the principle ought to be not to say anything if the
> command does exactly what it was told to do successfully, unless
> the operation is expected to take longer than other normal
> commands in the git suite, or something that is rarely used.
Nodz. Just hoary Unix tradition.
> Perhaps under "[user] expert" control.
Nope. You'd be surprised what kind of people consider themselves
"experts"... I'd prefer adding -v/--verbose flags to all commands (if
nothing else, for symmetry's sake), have a '[default] --verbose' controlling
this across the board (perhaps also '[default "command"] --verbose'), with
'[default]' setting default switches.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: What's in git.git (stable)
From: Johannes Schindelin @ 2006-12-14 23:53 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612142255.33564.andyparkins@gmail.com>
Hi,
On Thu, 14 Dec 2006, Andy Parkins wrote:
> On Thursday 2006, December 14 21:22, Junio C Hamano wrote:
>
> > This is interesting. You said "commit -b", were pointed out
> > that you were talking about "checkout -b", and just after saying
> > "yup, that is right, I was", you again say "commit -b".
>
> There truly is something wrong with me. Is there some sort of record
> for number of mistakes made in one thread? Have I won yet?
Honestly, I do not see anything you have done wrong. After all, a good
idea came from it.
> I'm not sure about your "commit -b"; is it wise to have /another/ way of
> making a branch? I mean - I'm clearly confused enough, have a heart :-)
I actually would _love_ that feature. Yeah, it's possible with existing
git commands, but it would be _convenient_.
Ciao,
Dscho
^ permalink raw reply
* Re: git-fetch fails with error code 128
From: Junio C Hamano @ 2006-12-15 0:02 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Nicolas Pitre
In-Reply-To: <200612142308.45376.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> $ git fetch
> remote: Generating pack...
> remote: Done counting 189146 objects.
> remote: Result has 186566 objects.
> remote: Deltifying 186566 objects.
> remote: 100% (186566/186566) done
> Unpacking 186566 objects
> fatal: failed to apply delta
> fatal: unpack-objects died with error code 128
> Fetch failure: /home/andyp/projects/temp/.git
>
> What does that mean? I ran fsck --full on the source repository, but it's
> made no difference.
Andy, which version of git do you run (I presume they are the
same version, as you are doing the local fetching), and which
version of git was the "slightly out of date" repository
prepared with?
I think this is the second time I've seen a report of unpacker
barfing on the mailing list. Nico, anything rings a bell?
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Johannes Schindelin @ 2006-12-15 0:07 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Geert Bosch, Andreas Ericsson, Andy Parkins, git
In-Reply-To: <20061214232936.GH26202@spearce.org>
Hi,
On Thu, 14 Dec 2006, Shawn Pearce wrote:
> I'm OK with a small increase in packfile size as a result of slightly
> less optimal delta base selection on the really large binary files due
> to something like the above, but 10x is insane.
Not if it is a server having to do all the work. Along with all the work
for all other clients. When you do a fetch, you really should be nice to
the serving side.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/2] Suggest use of 'git add' when 'nothing to commit' gets shown.
From: Shawn O. Pearce @ 2006-12-15 0:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Parkins
If a user modifies files and runs 'git commit' (without the very
useful -a option) and they have not yet updated the index they
are probably coming from another SCM-like tool which would perform
the same as 'git commit -a' in this case. Showing the user their
current status and a final line of "nothing to commit" is not very
reassuring, as the user might believe that Git did not recognize
their files were modified.
Instead we can suggest as part of the 'nothing to commit' message
that the user invoke 'git add' to add files to their next commit.
Suggested by Andy Parkins in his Git 'niggles' list
(<200612132237.10051.andyparkins@gmail.com>).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-commit.sh | 2 +-
wt-status.c | 7 ++++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 05828bb..fb69e11 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -515,7 +515,7 @@ then
current="$(git-rev-parse --verify HEAD)"
else
if [ -z "$(git-ls-files)" ]; then
- echo >&2 Nothing to commit
+ echo >&2 "Nothing to commit (use \"git add\" include for commit)"
exit 1
fi
PARENTS=""
diff --git a/wt-status.c b/wt-status.c
index 6e9414d..f9ed54f 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -163,7 +163,7 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
int i;
if (q->nr)
wt_status_print_header("Changed but not updated",
- "use git-add on files to include for commit");
+ "use \"git add\" on files to include for commit");
for (i = 0; i < q->nr; i++)
wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
if (q->nr)
@@ -250,7 +250,7 @@ static void wt_status_print_untracked(const struct wt_status *s)
}
if (!shown_header) {
wt_status_print_header("Untracked files",
- "use \"git add\" to add to commit");
+ "use \"git add\" on files to include for commit");
shown_header = 1;
}
color_printf(color(WT_STATUS_HEADER), "#\t");
@@ -292,7 +292,8 @@ void wt_status_print(struct wt_status *s)
if (s->verbose && !s->is_initial)
wt_status_print_verbose(s);
if (!s->commitable)
- printf("%s\n", s->amend ? "# No changes" : "nothing to commit");
+ printf("%s (use \"git add\" include for commit)\n",
+ s->amend ? "# No changes" : "Nothing to commit");
}
int git_status_config(const char *k, const char *v)
--
1.4.4.2.g72f5
^ permalink raw reply related
* [PATCH 2/2] Align section headers of 'git status' to new 'git add'.
From: Shawn O. Pearce @ 2006-12-15 0:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <2d2d4a64dab54a6d156b599afd69d7607fb228f6.1166141607.git.spearce@spearce.org>
Now that 'git add' is considered a first-class UI for 'update-index'
and that the git add documentation states "Even modified files must
be added to the set of changes about to be committed" we should
make the output of 'git status' align with that documentation and
common usage.
So now we see a status output such as:
# Added but not yet committed:
# (will commit)
#
# new file: x
#
# Changed but not added:
# (use "git add" on files to include for commit)
#
# modified: x
#
# Untracked files:
# (use "git add" on files to include for commit)
#
# y
which just reads better in the context of using 'git add' to
manipulate a commit (and not a checkin, whatever the heck that is).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git-runstatus.txt | 6 +++---
Documentation/git-status.txt | 6 +++---
Documentation/tutorial-2.txt | 10 +++++-----
wt-status.c | 4 ++--
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-runstatus.txt b/Documentation/git-runstatus.txt
index 89d7b92..e76ef05 100644
--- a/Documentation/git-runstatus.txt
+++ b/Documentation/git-runstatus.txt
@@ -16,9 +16,9 @@ DESCRIPTION
Examines paths in the working tree that has changes unrecorded
to the index file, and changes between the index file and the
current HEAD commit. The former paths are what you _could_
-commit by running 'git-update-index' before running 'git
-commit', and the latter paths are what you _would_ commit by
-running 'git commit'.
+commit by running 'git-add' before running 'git commit', and
+the latter paths are what you _would_ commit by running
+'git commit'.
If there is no path that is different between the index file and
the current HEAD commit, the command exits with non-zero status.
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index ce7857e..0dd9136 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -15,9 +15,9 @@ DESCRIPTION
Examines paths in the working tree that has changes unrecorded
to the index file, and changes between the index file and the
current HEAD commit. The former paths are what you _could_
-commit by running 'git-update-index' before running 'git
-commit', and the latter paths are what you _would_ commit by
-running 'git commit'.
+commit by running 'git-add' before running 'git commit', and
+the latter paths are what you _would_ commit by running
+'git commit'.
If there is no path that is different between the index file and
the current HEAD commit, the command exits with non-zero
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
index f7f2e1c..918a562 100644
--- a/Documentation/tutorial-2.txt
+++ b/Documentation/tutorial-2.txt
@@ -341,23 +341,23 @@ situation:
------------------------------------------------
$ git status
#
-# Updated but not checked in:
+# Added but not yet committed:
# (will commit)
#
# new file: closing.txt
#
#
-# Changed but not updated:
-# (use git-update-index to mark for commit)
+# Changed but not added:
+# (use "git add" on files to include for commit)
#
# modified: file.txt
#
------------------------------------------------
Since the current state of closing.txt is cached in the index file,
-it is listed as "updated but not checked in". Since file.txt has
+it is listed as "added but not yet committed". Since file.txt has
changes in the working directory that aren't reflected in the index,
-it is marked "changed but not updated". At this point, running "git
+it is marked "changed but not added". At this point, running "git
commit" would create a commit that added closing.txt (with its new
contents), but that didn't modify file.txt.
diff --git a/wt-status.c b/wt-status.c
index f9ed54f..8cc4d5d 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -162,7 +162,7 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
{
int i;
if (q->nr)
- wt_status_print_header("Changed but not updated",
+ wt_status_print_header("Changed but not added",
"use \"git add\" on files to include for commit");
for (i = 0; i < q->nr; i++)
wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
@@ -178,7 +178,7 @@ void wt_status_print_initial(struct wt_status *s)
read_cache();
if (active_nr) {
s->commitable = 1;
- wt_status_print_header("Updated but not checked in",
+ wt_status_print_header("Added but not yet committed",
"will commit");
}
for (i = 0; i < active_nr; i++) {
--
^ permalink raw reply related
* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
From: Johannes Schindelin @ 2006-12-15 0:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061214224117.GA26374@spearce.org>
Hi,
On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
> +int is_bare_git_dir (const char *dir)
> +{
> + if (!strcmp(dir, DEFAULT_GIT_DIR_ENVIRONMENT))
> + return 0;
> + const char *s = strrchr(dir, '/');
> + return !s || strcmp(s + 1, DEFAULT_GIT_DIR_ENVIRONMENT);
> }
This function does not really determine if the repo is bare. I have no
better name for it, though.
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git (stable)
From: Horst H. von Brand @ 2006-12-15 0:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andy Parkins, git
In-Reply-To: <Pine.LNX.4.63.0612141147200.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 14 Dec 2006, Andy Parkins wrote:
[...]
> > "newbie" doesn't mean "idiot". Everybody wants to understand what is
> > going on.
> I heartly disagree. I saw so many faces _begging_ me to just say _what_ to
> do, not _why_, and quickly, please.
So? This is meant to be a /tool/. Not wanting to know how it works doesn't
make one an idiot, it is just economy.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: Ignoring local changes
From: Johannes Schindelin @ 2006-12-15 0:15 UTC (permalink / raw)
To: Pazu; +Cc: Rogan Dawes, git
In-Reply-To: <9e7ab7380612141336p3b930047l3a4a76947239162f@mail.gmail.com>
Hi,
On Thu, 14 Dec 2006, Pazu wrote:
> 2006/12/14, Rogan Dawes <discard@dawes.za.net>:
>
> > Why not remove it from the repo, then set .gitignore?
> >
> > If it is generated code, or compiled code, it probably shouldn't be in
> > the repo in the first place . . . Simply correct that mistake, and you
> > are good to go.
>
> Basically, because I don't want to mess with the upstream. I know, I
> can remove them only from my local branch, and never push the commit
> that removed the files, and that's what I'll probably do if there's no
> other way -- but it would be best if I could just ignore the files. It
> doesn't sound unreasonable, does it?
It is not unreasonable. But I could not find an easy way to do it with
git. It should be easy to hack it into it, though.
Ciao,
Dscho
^ permalink raw reply
* Re: svn versus git
From: Johannes Schindelin @ 2006-12-15 0:19 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0612140910t6aff44e1m9570b20850a41b87@mail.gmail.com>
Hi,
On Fri, 15 Dec 2006, Nguyen Thai Ngoc Duy wrote:
> On 12/14/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > - have you seen the patch for git-show today, which would include this
> > > > functionality?
> > >
> > > I didn't. From the patch, it seems git-show can show the index via
> > > ::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is
> > > not intuitive though. Perhaps you should mention that it can show
> > > index (and how) in the git-show document
> >
> > Well, you can reference blobs that way, but not trees.
>
> Oh, yeah. Isn't this a good oppotunity to add --index option to git-show?
> git-show --index will show the index. git-show --index file will show
> the file content. This makes git-show a little unconsistent though as
> it may or may not require argument <object>.
>
> Another option is treat '::' alone specially -- call git-ls-files.
Hmm. I don't know... It would make the code rather messy. And are you
really interested in the content stored in the index? In all cases I can
think of, you are better off with a diff vs. working directory or ref.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
From: Shawn Pearce @ 2006-12-15 0:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612150112010.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
>
> > +int is_bare_git_dir (const char *dir)
> > +{
> > + if (!strcmp(dir, DEFAULT_GIT_DIR_ENVIRONMENT))
> > + return 0;
> > + const char *s = strrchr(dir, '/');
> > + return !s || strcmp(s + 1, DEFAULT_GIT_DIR_ENVIRONMENT);
> > }
>
> This function does not really determine if the repo is bare. I have no
> better name for it, though.
guess_if_bare_git_dir ?
I struggled to name that thing because it can't really tell, its just
guessing... but it is going to be right most of the time. Of course
I'm sure there's some Git user somewhere who will confuse it.
--
^ permalink raw reply
* Re: What's in git.git (stable)
From: Johannes Schindelin @ 2006-12-15 0:23 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Andy Parkins, git
In-Reply-To: <200612150015.kBF0F7vL004864@laptop13.inf.utfsm.cl>
Hi,
On Thu, 14 Dec 2006, Horst H. von Brand wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 14 Dec 2006, Andy Parkins wrote:
>
> [...]
>
> > > "newbie" doesn't mean "idiot". Everybody wants to understand what is
> > > going on.
>
> > I heartly disagree. I saw so many faces _begging_ me to just say _what_ to
> > do, not _why_, and quickly, please.
>
> So? This is meant to be a /tool/. Not wanting to know how it works doesn't
> make one an idiot, it is just economy.
My thoughts exactly.
And I did not want to force understanding onto the users. Heck, I even
know people who use git and do not know about the index! They don't need
to, either.
Ciao,
Dscho
^ permalink raw reply
* Re: Using git as a general backup mechanism
From: Junio C Hamano @ 2006-12-15 0:33 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <4581DF3E.3070806@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> Junio C Hamano wrote:
>> (2) End of week comes. Create an empty branch 'weekly' if you
>> do not already have one. Make a full tree snapshot, and
>> create a parentless commit for the week if the 'weekly'
>> branch did not exist, or make it a child of the 'weekly'
>> commit from the last week. Discard 'lastweek' branch if
>> you have one, and rename 'daily' branch to 'lastweek'.
>
> That sounds like it'd work, but doesn't it imply that the history of a
> given file in the backups is not continuous? That is, an old copy of a
> file on the "weekly" branch doesn't have any kind of ancestor
> relationship with the same file on the "daily" branch? While that's
> obviously no different than the current git-less situation where
> there's no notion of ancestry at all, it'd be neat if this backup
> scheme could actually track long-term changes to individual files.
You can keep them connected by rewriting history of bounded
number of commits. When you start a new week, you would make
the Monday commit a child of the tip of weekly branch that
represents the latest weekly shapshot. Then on Friday, the
history would show the 5 commits during the week and behind that
would be a sequence of commits with one-per-week granularity.
When you rotate the week's daily log out and the commit for
Monday is based on the weekly history you are going to toss out,
you may need to rebase that week's daily log branch.
Let's say your policy is to keep daily log for at least one week
and enough number of end-of-week weekly logs. Let's say it is
week #2 right now.
Aooo... (week #2 daily)
/|
ooooooB | (week #1 daily)
/ |
o--------o---------C (end-of-week weekly log)
The first commit in this week's daily log (A) would have two
parents: last commit from daily log of week #1 (B), and the
latest commit on the end-of-week weekly log (C). Most likely, B
and C would have exactly the same tree. That way, you would
have at least 7 days of daily log; at the end of this week you
would have close to 14 days but "keeping at least one week" is
satisfied.
When starting the 3rd week, you will discard 1st week's log; you
would need to rewrite 7 days worth of commits from week #2,
because the first commit of week #2 should now only have one
parent (C), and you would forget the commit on the last day of
week #1 as its parent (B). Which cascades through 7 commits you
made during week #2. You are not changing any trees, so this
should be quite efficient.
Then the first daily commit of 3rd week would have two parents,
the commit at the end of week #2 daily branch (D), and a new
commit (E) at the tip of the end-of-week log. Again, D and E
would have the identical trees.
o...... (week #3 daily)
/|
Aooo..D | (week #2 daily)
| |
(week #1 daily - gone) | |
| |
o--------o---------C-------E (end-of-week weekly log)
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Junio C Hamano @ 2006-12-15 0:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612150015330.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> If I read builtin-show-ref.c correctly, it _always_ calls
> for_each_ref(show_ref, NULL);
Ok, that settles it. If there is a reason to have --verify, we
should really special case it. There is no point in looping,
because verify does not do the tail match (which could cause
ambiguity) and its answer should be either "yes it is there" or
"no there is no such ref".
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Shawn Pearce @ 2006-12-15 0:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Geert Bosch, Andreas Ericsson, Andy Parkins, git
In-Reply-To: <Pine.LNX.4.63.0612150105450.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 14 Dec 2006, Shawn Pearce wrote:
>
> > I'm OK with a small increase in packfile size as a result of slightly
> > less optimal delta base selection on the really large binary files due
> > to something like the above, but 10x is insane.
>
> Not if it is a server having to do all the work. Along with all the work
> for all other clients. When you do a fetch, you really should be nice to
> the serving side.
Yes, that's true.
But I fail to see what that has to do with the part you quoted above.
A 1% increase in transfer bandwidth may be better for a server if
it halves the CPU usage or disk IO usage if the server has more
bandwidth than those available; likewise a 1% decrease in transfer
bandwidth may be better for a server if it has lots of CPU to spare
but very little network bandwidth available.
Since every server is different its not like we can tune for just
one of those cases and cross our fingers.
--
^ permalink raw reply
* Re: svn versus git
From: Horst H. von Brand @ 2006-12-15 0:58 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: Andy Parkins, git
In-Reply-To: <200612142000.54409.arekm@maven.pl>
Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
[...]
> ps. I'm blind or there is no documentation about what utilities are needed to
> get git fully working? (like sed, coreutils, grep, rcs package (merge tool
> afaik needed)...).
Look at the .spec (or .spec.in) file, they record what the running git
needs.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ 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