* Re: Ignoring local changes
From: Rogan Dawes @ 2006-12-14 21:27 UTC (permalink / raw)
To: Pazu; +Cc: git
In-Reply-To: <9e7ab7380612140855p1f4ee6c1l5ef24c4d1d169da6@mail.gmail.com>
Pazu wrote:
> 2006/12/14, Andreas Ericsson <ae@op5.se>:
>
>> Correction: I just tested this, and while git-add won't touch the file,
>> git-update-index will, and git-status still shows it as modified.
>
> Yes, and that's exactly my problems. There are a number of
> modified/removed files in my working copy that were previously added
> to the repository, and git-status shows them as modified/removed, even
> when they're listed in .gitignore or .git/info/exclude
>
>> This feels like a bug to me.
>
> Dunno, sounds like this is by design. I acknowledge that my situation
> is unusual, and most often, you'll want to always track a file once
> it's been added to the repository.
>
> -- Pazu
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.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Andreas Ericsson @ 2006-12-14 21:55 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <20061214200245.GP1747@spearce.org>
Shawn Pearce wrote:
>
> About the only trouble that can cause is a failed push when
> git-receive-pack needs to generate the reflog entry but cannot
> get the user's committer data because their gecos information
> doesn't exist.
>
In that case, it would be best if it let the commit go through using
only the username. Reflogs are fixable afterwards, so there's no real
harm done.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Ignoring local changes
From: Pazu @ 2006-12-14 21:56 UTC (permalink / raw)
To: git
In-Reply-To: <9e7ab7380612141336p3b930047l3a4a76947239162f@mail.gmail.com>
Pazu <pazu <at> pazu.com.br> writes:
> I know, could remove them only from my local branch, and never push the
> commit that removed the files…
And that makes me think about yet another nice feature: configure git[-svn] to
"block" a commit, meaning that a blocked commit would never be pushed out when
doing a git push or git-svn dcommit.
-- Pazu
^ permalink raw reply
* Re: [PATCH] "master" should be treated no differently from any other branch
From: Shawn Pearce @ 2006-12-14 21:57 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612142137.54505.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> On Thursday 2006, December 14 21:30, Junio C Hamano wrote:
>
> > I guess that question indicates that the part of my message you
> > did not quote was not written cleanly enough.
>
> It was; I'm just stupid.
>
> Let's make the special case "linux-master" and then Linus gets what he wants
> and consistency is restored.
>
> No? Okay, I give up then. :-)
What about we do instead:
[branch]
mergeMessageTemplate = "Merge '%(remoteref)' from '%(remoteurl)' into '%(localref)'
%(summary)"
[branch "master"]
mergeMessageTemplate = "Merge '%(remoteref)' from '%(remoteurl)'
%(summary)"
? IOW let the user supply the merge template message in the
repository config somehow and use string placeholders like what
show-ref accepts? Then the default can be to not have the "into" at
all, and Linus surely could just set his branch.mergeMessageTemplate
to a string which gives him the message that he and his fellow
kernel hackers find to be useful?
--
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-14 21:58 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Andy Parkins
In-Reply-To: <20061214114546.GI1747@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Andy Parkins <andyparkins@gmail.com> wrote:
>> How's this then:
>>
>> $ git commit
>> $ git commit
>> $ git commit
>> $ git reset HEAD^^^
>>
>> "AGGGHHHHHH! I meant HEAD^^"
>>
>> At this point I start running "git-prune -n | grep commit" and some liberal
>> use of git-show to try and find the hash of the object so I can do
>
> At this point I usually try to politely suggest that users do:
>
> git repo-config --global core.logAllRefUpdates true
>
> and in the future do something like:
>
>> $ git commit # {4}
>> $ git commit # {3}
>> $ git commit # {2}
>> $ git reset HEAD^^^ # {1}
>>
>> "AGGGHHHHHH! I meant HEAD^^"
>
> $ git reset HEAD@{4}
>
> should give you what
>
> $ git reset HEAD^^
>
> would have given had you not added the extra ^. :-)
Correct but a bad example that does not demonstrate the real
power of reflog. Andy's AGGGHHHHHH can be recovered with a
simple:
$ git reset ORIG_HEAD
The real beauty of reflog is that you can usually count number
of commands (not just commit) the way you did and recover with
the @{n} syntax. With one caveat -- a porcelain might implement
what it does as more than one transaction on the ref, in which
case counting commands does not help. You need to first make
sure the value of n in @{n} you thought is appropriate is really
the one you want; you would always run "git show -s HEAD@{4}"
before doing the recovering reset in practice, in other words.
And it is not very easy to view where ref was in each step with
existing set of tools.
Not until the attached patch, which was very lightly tested.
You would use it like this:
$ git-show-branch --reflog next
! [next@{0}] Merge branch 'js/show' into next
! [next@{1}] Merge branch 'jc/cdup' into next
! [next@{2}] Merge branch 'master' into next
! [next@{3}] Merge branch 'jc/cdup' into next
----
- [next@{0}] Merge branch 'js/show' into next
+ [next@{0}^2] git-show: grok blobs, trees and tags, too
-- [next@{1}] Merge branch 'jc/cdup' into next
++ [next@{1}^2] git-reset [--mixed] <tree> [--] <paths>...
++ [next@{1}^2^] git-reset: make it work from within a subdirectory.
++ [next@{1}^2~2] git-fetch: make it work from within a subdirectory.
++ [next@{0}^2^] INSTALL: no need to have GNU diff installed
-- [next@{0}^2~2] Merge branch 'maint'
++ [next@{0}^2~2^2] Bypass expensive content comparsion during...
- [next@{3}] Merge branch 'jc/cdup' into next
+ [next@{3}^2] git-reset [--mixed] <tree> [--] <paths>...
+ [next@{3}^2^] git-reset: make it work from within a subdirectory.
+ [next@{3}^2~2] git-fetch: make it work from within a subdirectory.
+ [next@{3}^2~3] Bypass expensive content comparsion during re...
++ + [next@{0}^2~3] Update git-diff documentation
-- - [next@{0}^2~4] Merge branch 'jc/diff--cached'
++ + [next@{0}^2~5] git-svn: allow both diff.color and color.diff
++ + [next@{0}^2~6] repacked packs should be read-only
---- [next@{2}] Merge branch 'master' into next
This shows the actual reflog from the 'next' branch on my
primary repository. It shows that I did a merge of jc/cdup
branch into 'next' to run tests at next@{3}, but later rewound
that merge at next@{2} and merged the rebased jc/cdup again
later at next@{1} [*1*].
[Footnote]
*1* Of course, I did all of the above rewinding and rebasing
before pushing the result out, so the general public do not have
to worry about rewinding and rebasing.
---
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index fb1a400..559bb18 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -6,7 +6,7 @@
#include "builtin.h"
static const char show_branch_usage[] =
-"git-show-branch [--sparse] [--current] [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [--topics] [<refs>...]";
+"git-show-branch [--sparse] [--current] [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [--topics] [<refs>...] | --reflog[=n] <branch>";
static int default_num;
static int default_alloc;
@@ -17,6 +17,8 @@ static const char **default_arg;
#define REV_SHIFT 2
#define MAX_REVS (FLAG_BITS - REV_SHIFT) /* should not exceed bits_per_int - REV_SHIFT */
+#define DEFAULT_REFLOG 4
+
static struct commit *interesting(struct commit_list *list)
{
while (list) {
@@ -570,6 +572,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
int head_at = -1;
int topics = 0;
int dense = 1;
+ int reflog = 0;
git_config(git_show_branch_config);
@@ -615,6 +618,15 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
dense = 0;
else if (!strcmp(arg, "--date-order"))
lifo = 0;
+ else if (!strcmp(arg, "--reflog")) {
+ reflog = DEFAULT_REFLOG;
+ }
+ else if (!strncmp(arg, "--reflog=", 9)) {
+ char *end;
+ reflog = strtoul(arg + 9, &end, 10);
+ if (*end != '\0')
+ die("unrecognized reflog count '%s'", arg + 9);
+ }
else
usage(show_branch_usage);
ac--; av++;
@@ -622,7 +634,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
ac--; av++;
/* Only one of these is allowed */
- if (1 < independent + merge_base + (extra != 0))
+ if (1 < independent + merge_base + (extra != 0) + (!!reflog))
usage(show_branch_usage);
/* If nothing is specified, show all branches by default */
@@ -631,9 +643,22 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
if (all_heads + all_tags)
snarf_refs(all_heads, all_tags);
- while (0 < ac) {
- append_one_rev(*av);
- ac--; av++;
+ if (reflog) {
+ int reflen;
+ if (!ac)
+ die("--reflog option needs one branch name");
+ reflen = strlen(*av);
+ for (i = 0; i < reflog; i++) {
+ char *name = xmalloc(reflen + 20);
+ sprintf(name, "%s@{%d}", *av, i);
+ append_one_rev(name);
+ }
+ }
+ else {
+ while (0 < ac) {
+ append_one_rev(*av);
+ ac--; av++;
+ }
}
head_p = resolve_ref("HEAD", head_sha1, 1, NULL);
^ permalink raw reply related
* Re: svn versus git
From: Andreas Ericsson @ 2006-12-14 22:07 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: Andy Parkins, git
In-Reply-To: <200612142000.54409.arekm@maven.pl>
Arkadiusz Miskiewicz wrote:
> On Wednesday 13 December 2006 23:00, Andy Parkins wrote:
>> Hello,
>>
>> With all the discussion about user interface difficulties, I started to
>> write a comparison with subversion document. (I was assuming that people
>> find subversion easy). As much as I love git, I was expecting to find that
>> it's hard to use interface would have subversion as the clear winner. I
>> was hoping that would then give guidance as to what could be fixed in git.
>>
>> I was surprised, therefore, to find that in each case I was finding that
>> git was the winner.
>
> subversion is a winner when it comes to options handling (especially --help)
> and better (error) messages. That's one of reason why people find it easy.
>
Yup. Most discussions about what git can do to improve usually ends up
in a patch that fixes either documentation or error- / help-messages.
> 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)...).
>
perl and the standard coreutils, which afaik are required to be present
on all unix systems. We no longer require external merge tools.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: svn versus git
From: Arkadiusz Miskiewicz @ 2006-12-14 22:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Andy Parkins, git
In-Reply-To: <4581CB38.8050401@op5.se>
On Thursday 14 December 2006 23:07, Andreas Ericsson 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)...).
>
> perl and the standard coreutils, which afaik are required to be present
> on all unix systems.
That's not all. sed and grep is also used. There may be some others hidden
deep in git and it would be good to have that docummented (I've hit the
problem already with missing some tool when preparing chroot for git).
> We no longer require external merge tools.
Starting from which version?
--
Arkadiusz Miśkiewicz PLD/Linux Team
^ permalink raw reply
* Re: svn versus git
From: Shawn Pearce @ 2006-12-14 22:23 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: Andreas Ericsson, Andy Parkins, git
In-Reply-To: <200612142313.27741.arekm@maven.pl>
Arkadiusz Miskiewicz <arekm@maven.pl> wrote:
> > We no longer require external merge tools.
> Starting from which version?
Not released yet, its sitting in 'next'. Hopefully 1.5.
--
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Andreas Ericsson @ 2006-12-14 22:28 UTC (permalink / raw)
To: Geert Bosch; +Cc: Johannes Schindelin, Andy Parkins, git
In-Reply-To: <C287764F-6755-4291-A87A-3E8816E90B49@adacore.com>
Geert Bosch wrote:
>
> On Dec 14, 2006, at 10:06, Andreas Ericsson wrote:
>
>> It wouldn't work for this particular case though. In our distribution
>> repository we have ~300 bzip2 compressed tarballs with an average size
>> of 3MiB. 240 of those are between 2.5 and 4 MiB, so they don't
>> drastically differ, but neither do they delta well.
>>
>> One option would be to add some sort of config option to skip
>> attempting deltas of files with a certain suffix. That way we could
>> just tell it to ignore *.gz,*.tgz,*.bz2 and everything would work just
>> as it does today, but a lot faster.
>
> Such special magic based on filenames is always a bad idea. Tomorrow
> somebody
> comes with .zip files (oh, and of course .ZIP), then it's .jpg's other
> compressed content. In the end git will be doing lots of magic and still
> perform
> badly on unknown compressed content.
>
Hence config option. People can tell git to skip trying to delta
whatever they want. For this particular mothership repo, we only ever
work against it when we're at the office, meaning resulting datasize is
not an issue, but data computation can be a real bottle-neck.
> There is a very simple way of detecting compressed files: just look at the
> size of the compressed blob and compare against the size of the expanded
> blob.
> If the compressed blob has a non-trivial size which is close to the
> expanded
> size, assume the file is not interesting as source or target for deltas.
>
> Example:
> if (compressed_size > expanded_size / 4 * 3 + 1024) {
> /* don't try to deltify if blob doesn't compress well */
> return ...;
> }
>
Many compression algorithms generate similar output for similar input.
Most source-code projects change relatively little between releases, so
they *could* delta well, it's just that in our repo they don't.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Shawn Pearce @ 2006-12-14 22:38 UTC (permalink / raw)
To: Horst H. von Brand
Cc: Geert Bosch, Andreas Ericsson, Johannes Schindelin, Andy Parkins,
git
In-Reply-To: <200612142212.kBEMCVeu032626@laptop13.inf.utfsm.cl>
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:
> Shawn Pearce <spearce@spearce.org> wrote:
>
> [...]
>
> > And yet I get good delta compression on a number of ZIP formatted
> > files which don't get good additional zlib compression (<3%).
>
> .zip is something like a tar of the compressed files, if the files inside
> the archive don't change, the deltas will be small.
Yes, especially when the new zip is made using the exact same
software with the same parameters, so the resulting compressed file
stream is identical for files whose content has not changed. :-)
Since this is actually a JAR full of Java classes which have
been recompiled, its even more interesting that javac produced an
identical class file given the same input. I've seen times where
it doesn't thanks to the automatic serialVersionUID field being
somewhat randomly generated.
--
^ permalink raw reply
* [PATCH] Enable reflogs by default in any repository with a working directory.
From: Shawn O. Pearce @ 2006-12-14 22:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wn243mu.fsf@assigned-by-dhcp.cox.net>
New and experienced Git users alike are finding out too late that
they forgot to enable reflogs in the current repository, and cannot
use the information stored within it to recover from an incorrectly
entered command such as `git reset --hard HEAD^^^` when they really
meant HEAD^^ (aka HEAD~2).
So enable reflogs by default in all future versions of Git, unless
the user specifically disables it with:
[core]
logAllRefUpdates = false
in their .git/config or ~/.gitconfig.
We only enable reflogs in repositories that have a working directory
associated with them, as shared/bare repositories do not have
an easy means to prune away old log entries, or may fail logging
entirely if the user's gecos information is not valid during a push.
This heuristic was suggested on the mailing list by Junio.
Documentation was also updated to indicate the new default behavior.
We probably should start to teach usuing the reflog to recover
from mistakes in some of the tutorial material, as new users are
likely to make a few along the way and will feel better knowing
they can recover from them quickly and easily, without fsck-objects'
lost+found features.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/config.txt | 7 +++++--
builtin-init-db.c | 4 ++++
cache.h | 1 +
environment.c | 9 +++++++++
4 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a3587f8..8abb082 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -79,8 +79,11 @@ core.logAllRefUpdates::
file is automatically created for branch heads.
This information can be used to determine what commit
- was the tip of a branch "2 days ago". This value is
- false by default (no automated creation of log files).
+ was the tip of a branch "2 days ago".
+
+ This value is true by default in a repository that has
+ a working directory associated with it, and false by
+ default in a bare repository.
core.repositoryFormatVersion::
Internal variable identifying the repository format and layout
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 235a0ee..214fc8e 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -239,6 +239,10 @@ static void create_default_files(const char *git_dir, const char *template_path)
git_config_set("core.filemode",
filemode ? "true" : "false");
}
+
+ /* Enable logAllRefUpdates if a working tree is attached */
+ git_config_set("core.logallrefupdates",
+ !is_bare_git_dir(git_dir) ? "true" : "false");
}
static const char init_db_usage[] =
diff --git a/cache.h b/cache.h
index f2ec5c8..2d3df98 100644
--- a/cache.h
+++ b/cache.h
@@ -123,6 +123,7 @@ extern int cache_errno;
#define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
#define GRAFT_ENVIRONMENT "GIT_GRAFT_FILE"
+extern int is_bare_git_dir(const char *dir);
extern const char *get_git_dir(void);
extern char *get_object_directory(void);
extern char *get_refs_directory(void);
diff --git a/environment.c b/environment.c
index 84d870c..b7256eb 100644
--- a/environment.c
+++ b/environment.c
@@ -48,6 +48,15 @@ static void setup_git_env(void)
git_graft_file = getenv(GRAFT_ENVIRONMENT);
if (!git_graft_file)
git_graft_file = xstrdup(git_path("info/grafts"));
+ log_all_ref_updates = !is_bare_git_dir(git_dir);
+}
+
+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);
}
const char *get_git_dir(void)
--
^ permalink raw reply related
* Re: What's in git.git (stable)
From: Shawn Pearce @ 2006-12-14 22:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wn243mu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Maybe a check to say if $GIT_DIR is ".git" or ends with "/.git"
> then enable it and otherwise honor the configuration variable,
> without changing the default in the code (with your patch) nor
> in the default configuration ("enable for new repositories" as I
> suggested) might be a workable compromise.
See my latest patch. Though that patch also sets the value in the
config file, much as core.filemode is also set in the config file,
based on the guess determined by init-db at the time it was executed.
--
^ permalink raw reply
* Re: What's in git.git (stable)
From: Andy Parkins @ 2006-12-14 22:50 UTC (permalink / raw)
To: git
In-Reply-To: <7v4pry16n5.fsf@assigned-by-dhcp.cox.net>
On Thursday 2006, December 14 21:58, Junio C Hamano wrote:
> Correct but a bad example that does not demonstrate the real
> power of reflog. Andy's AGGGHHHHHH can be recovered with a
> simple:
>
> $ git reset ORIG_HEAD
HAHA! I knew reading this mailing list would pay off.
It amazes me that there is always an answer. It's almost becoming a
pantomime - I say "well git can't do this", and you say "oh yes it can".
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Horst H. von Brand @ 2006-12-14 22:12 UTC (permalink / raw)
To: Shawn Pearce
Cc: Geert Bosch, Andreas Ericsson, Johannes Schindelin, Andy Parkins,
git
In-Reply-To: <20061214194636.GO1747@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
[...]
> And yet I get good delta compression on a number of ZIP formatted
> files which don't get good additional zlib compression (<3%).
.zip is something like a tar of the compressed files, if the files inside
the archive don't change, the deltas will be small.
--
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: What's in git.git (stable)
From: Andy Parkins @ 2006-12-14 22:55 UTC (permalink / raw)
To: git
In-Reply-To: <7vmz5q18cn.fsf@assigned-by-dhcp.cox.net>
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?
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 :-)
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Geert Bosch @ 2006-12-14 23:01 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andreas Ericsson, Johannes Schindelin, Andy Parkins, git
In-Reply-To: <20061214194636.GO1747@spearce.org>
On Dec 14, 2006, at 14:46, Shawn Pearce wrote:
> 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.
Yes, that's because for zip files each file in the archive is
compressed independently. Similar things might happen when
checking in uncompressed tar files with JPG's. The question
is whether you prefer bad time usage or bad space usage when
handling large binary blobs. Maybe we should use a faster,
less precise algorithm instead of giving up.
Still, I think doing anything based on filename is a mistake.
If we want to have a heuristic to prevent spending too much time
on deltifying large compressed files, the heuristic should be
based on content, not filename.
Maybe we could some "magic" as used by the file(1) command
that allows git to say a bit more about the content of blobs.
This could be used both for ordering files during deltification
and to determine wether to try deltification at all.
-Geert
^ permalink raw reply
* Re: What's in git.git (stable)
From: Shawn Pearce @ 2006-12-14 23:03 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
In-Reply-To: <200612132237.10051.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> * git-show-branch output is cryptic.
Agreed. I still don't know how to read its output. So I just
don't use it. Ever. :-)
--
^ permalink raw reply
* 'git diff HEAD' pager quirks
From: Jeff Garzik @ 2006-12-14 22:01 UTC (permalink / raw)
To: Git Mailing List
So, after a 'yum upgrade' brought me git-core-1.4.4.2-2.fc6, I
discovered that "git diff HEAD" will produce paged output, if at a tty.
Nice, I like the improvement.
However, when there is no output at all (nothing dirty in working dir),
"git diff HEAD" will sometimes invoke $PAGER ("/usr/bin/less" here)
__anyway__.
This causes the cursor to jump down 20-30 lines, before returning the
command prompt. Annoying. Example follows.
Jeff
---------------------<begin BEFORE>----------------------------
[jgarzik@pretzel libata-dev]$ git diff HEAD
[jgarzik@pretzel libata-dev]$
---------------------<end BEFORE>------------------------------
---------------------<begin AFTER>-----------------------------
[jgarzik@pretzel libata-dev]$ git diff HEAD
[jgarzik@pretzel libata-dev]$
^ permalink raw reply
* [PATCH] Stop telling users we are 'defaulting to local storage area'.
From: Shawn O. Pearce @ 2006-12-14 23:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Parkins
Back in the old days of Git when people messed around with their
GIT_DIR environment variable more often it was nice to know whether
or not git-init-db created a .git directory or used GIT_DIR.
But now that we are making excuses in the documentation about why
this message gets printed by git-init-db we should just remove it
entirely. It doesn't really help the user to understand what just
happened. It also breaks from our normal behavior of not printing
anything if the command was successful.
Suggested by Andy Parkins in his Git 'niggles' list
(<200612132237.10051.andyparkins@gmail.com>).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/core-tutorial.txt | 14 +++-----------
Documentation/tutorial-2.txt | 1 -
Documentation/tutorial.txt | 6 ------
builtin-init-db.c | 4 +---
4 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 47505aa..f90c66c 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -54,17 +54,9 @@ $ cd git-tutorial
$ git-init-db
------------------------------------------------
-to which git will reply
-
-----------------
-defaulting to local storage area
-----------------
-
-which is just git's way of saying that you haven't been doing anything
-strange, and that it will have created a local `.git` directory setup for
-your new project. You will now have a `.git` directory, and you can
-inspect that with `ls`. For your new empty project, it should show you
-three entries, among other things:
+You will now have a `.git` directory, and you can inspect that with
+`ls`. For your new empty project, it should show you three entries,
+among other things:
- a file called `HEAD`, that has `ref: refs/heads/master` in it.
This is similar to a symbolic link and points at
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
index 6389de5..f7f2e1c 100644
--- a/Documentation/tutorial-2.txt
+++ b/Documentation/tutorial-2.txt
@@ -18,7 +18,6 @@ Let's start a new project and create a small amount of history:
$ mkdir test-project
$ cd test-project
$ git init-db
-defaulting to local storage area
$ echo 'hello world' > file.txt
$ git add .
$ git commit -a -m "initial commit"
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 02dede3..88ace3b 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -35,12 +35,6 @@ $ cd project
$ git init-db
------------------------------------------------
-Git will reply
-
-------------------------------------------------
-defaulting to local storage area
-------------------------------------------------
-
You've now initialized the working directory--you may notice a new
directory created, named ".git". Tell git that you want it to track
every file under the current directory with (notice the dot '.'
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 235a0ee..405b9a1 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -274,10 +274,8 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
* Set up the default .git directory contents
*/
git_dir = getenv(GIT_DIR_ENVIRONMENT);
- if (!git_dir) {
+ if (!git_dir)
git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
- fprintf(stderr, "defaulting to local storage area\n");
- }
safe_create_dir(git_dir, 0);
/* Check to see if the repository version is right.
--
^ permalink raw reply related
* Re: svn versus git
From: Johannes Schindelin @ 2006-12-14 23:10 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: Andy Parkins, git
In-Reply-To: <200612142000.54409.arekm@maven.pl>
Hi,
On Thu, 14 Dec 2006, Arkadiusz Miskiewicz 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)...).
Open the file "INSTALL".
Hth,
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:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061214224117.GA26374@spearce.org>
On Thu, Dec 14, 2006 at 05:41:17PM -0500, Shawn O. Pearce wrote:
> New and experienced Git users alike are finding out too late that
> they forgot to enable reflogs in the current repository, and cannot
> use the information stored within it to recover from an incorrectly
> entered command such as `git reset --hard HEAD^^^` when they really
> meant HEAD^^ (aka HEAD~2).
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?
^ permalink raw reply
* git-fetch fails with error code 128
From: Andy Parkins @ 2006-12-14 23:08 UTC (permalink / raw)
To: git
Hello,
This is with my big "every linux patch" repository that I talked about in
another thread. To bring you up to speed:
1. Made repository
2. Made a zip of the .git directory
3. Copied the zip elsewhere
4. Extracted it into a temporary directory
5. Went to an out-of-date version of this repository
6. Used git-fetch to update it.
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
What does that mean? I ran fsck --full on the source repository, but it's
made no difference.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Johannes Schindelin @ 2006-12-14 23:15 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Geert Bosch, Andreas Ericsson, Andy Parkins, git
In-Reply-To: <20061214194636.GO1747@spearce.org>
Hi,
On Thu, 14 Dec 2006, Shawn Pearce wrote:
> Geert Bosch <bosch@adacore.com> wrote:
> > Such special magic based on filenames is always a bad idea. Tomorrow
> > somebody
> > comes with .zip files (oh, and of course .ZIP), then it's .jpg's other
> > compressed content. In the end git will be doing lots of magic and
> > still perform
> > badly on unknown compressed content.
> >
> > There is a very simple way of detecting compressed files: just look
> > at the
> > size of the compressed blob and compare against the size of the
> > expanded blob.
> > If the compressed blob has a non-trivial size which is close to the
> > expanded
> > size, assume the file is not interesting as source or target for deltas.
> >
> > Example:
> > 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.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Enable reflogs by default in any repository with a working directory.
From: Shawn Pearce @ 2006-12-14 23:18 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20061214231038.GC5147@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Thu, Dec 14, 2006 at 05:41:17PM -0500, Shawn O. Pearce wrote:
> > New and experienced Git users alike are finding out too late that
> > they forgot to enable reflogs in the current repository, and cannot
> > use the information stored within it to recover from an incorrectly
> > entered command such as `git reset --hard HEAD^^^` when they really
> > meant HEAD^^ (aka HEAD~2).
>
> 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.
--
^ permalink raw reply
* 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
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