* Re: [PATCH 1/2] Suggest use of 'git add' when 'nothing to commit' gets shown.
From: Andreas Ericsson @ 2006-12-15 9:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, Andy Parkins
In-Reply-To: <20061215001350.GA26755@spearce.org>
Shawn O. Pearce wrote:
> else
> if [ -z "$(git-ls-files)" ]; then
> - echo >&2 Nothing to commit
> + echo >&2 "Nothing to commit (use \"git add\" include for commit)"
s/git add include/git add to include/
> 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");
Here it's "on files", whereas in other threads people have stated that
git add adds content, so perhaps
use \"git add file1 file2\" to include for commit
which also gives a nice "simplest-possible-usage" message.
> 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");
Same here.
> 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");
> }
This is same as first one (missing "to " before "include").
It would probably be nice to use one and the same message everywhere though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: What's in git.git (stable)
From: Andy Parkins @ 2006-12-15 8:58 UTC (permalink / raw)
To: git
In-Reply-To: <7vk60uyrau.fsf@assigned-by-dhcp.cox.net>
On Thursday 2006 December 14 23:46, Junio C Hamano wrote:
> > There truly is something wrong with me.
>
> I did not mean it that way. I only took it as a sign that maybe
Don't worry; I've got thicker skin than that. I was simply amazed at my lack
of comprehension ability. :-)
> > 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.
Absolutely. I'd agree that only <newbranch> is worth even considering.
> * 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).
I find myself swayed by this. This is indeed something that happens to me a
lot. In certain circumstances I've been defeated by git because I couldn't
switch to the other branch to make that quick commit because my local changes
conflicted with that other branch. The solution I use is to commit the bug
fix in the wrong branch, finish my current on-topic commit then
rebase/reset/etc to put everything where it should be.
> 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.
Yep. Although you've persuaded me with the above example, I think this is the
correct path. It's not wise to add every bell and whistle just because we
can. As long as there is /a/ way to achieve every task, that's good enough,
we don't need every way to achieve every task. We might even argue that
git's flexibility is what makes it harder to learn. It's similar to UNIX in
that respect - hard to learn, easy to use.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH] Add --add option to git-repo-config
From: Jakub Narebski @ 2006-12-15 8:54 UTC (permalink / raw)
To: git
In-Reply-To: <75CF19E7-7953-4C0A-B4CE-E9BB6822E062@silverinsanity.com>
Brian Gernhardt wrote:
> 'git-repo-config' [--global] [type] name [value [value_regex]]
> +'git-repo-config' [--global] [type] --add name value
In few places it seems that original has one space at beginning of line,
and added value lacks this space.
Otherwise, very nice patch. Thanks!
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: svn versus git
From: Andreas Ericsson @ 2006-12-15 8:52 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: Andy Parkins, git
In-Reply-To: <200612142313.27741.arekm@maven.pl>
Arkadiusz Miskiewicz wrote:
> 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).
>
sed and grep are, along with awk, part of the tools that are required to
be present on all unix systems. Sorry for the confusion with coreutils
(the package / software project).
When you set up a chroot environment, you want to at least copy /bin,
/lib and /sbin to the new root and then remove whatever you *know* you
don't need from them. Those directories should hold all programs the
system needs to properly boot up.
>> We no longer require external merge tools.
> Starting from which version?
>
Latest only. It was added 2006-12-06 and the dependency on external
merge program was removed in a commit created 2006-12-13. Junio merged
the merge-code into master one hour later. It is not in the maint
branch, so I don't know if any distributions ship git with the new
xdl_merge() thing. It's *very* good though. Kudos to Johannes Schindelin
for really making things right.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH] git-show: grok blobs, trees and tags, too
From: Jakub Narebski @ 2006-12-15 8:50 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612141129320.3635@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> +For tags, it shows the tag message and the referenced objects.
[...]
> +EXAMPLES
> +--------
> +
> +git show v1.0.0::
> + Shows the tag `v1.0.0`.
This changes semantic. Before this patch "git show v1.0.0" showed
_commit_, not a tag. Well, you can get commit using "git show v1.0.0^{}"...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: changing log entries
From: Jakub Narebski @ 2006-12-15 8:48 UTC (permalink / raw)
To: git
In-Reply-To: <200612141037.35061.andyparkins@gmail.com>
Andy Parkins wrote:
> On Wednesday 2006 December 13 23:08, Jon Masters wrote:
>
>> Anyway, now I would like to change an existing log entry to make it a
>> bit cleaner (read: add a first line that's under 80 characters). What's
>> the best way to change an existing log entry for a commit?
>
> If it's HEAD you want to change:
> git-commit --amend
>
> If it's not, it's a bit harder. You could pull each commit out as a patch and
> apply them again later after a git-reset. However, git has a tool for
> automating a lot of that: git-rebase. man git-rebase has some excellent
> examples.
>
> * -- A -- B -- C (master)
>
> Let's say you want to edit A; make a new branch at A:
>
> $ git branch temp-edit-branch master^^
>
> * -- A (temp-edit-branch)
> \
> B -- C (master)
>
> Edit A with git-commit --amend. This makes a new A, A' that has the new
> commit message:
>
> * -- A' (temp-edit-branch)
> \
> A -- B -- C (master)
>
> Then you switch to "master" and rebase master onto temp-edit-branch; you can
> then delete temp-edit-branch
>
> $ git-checkout master
> $ git-rebase temp-edit-branch
Theoretically you should do
$ git rebase --onto temp-edit-branch master^^ master
but thanks to automatic detection that patch is already applied the
above also should work. Well, unless you edit the commit so much
that git does not recognize it as the same commit...
> $ git branch -D temp-edit-branch
>
> * -- A' -- B' -- C' (master)
> \
> A -- B -- C
...in which case "git rebase temp-edit-branch master" would give you
* -- A' --A* -- B* -- C* (master)
\
A -- B -- C
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] make commit message a little more consistent and conforting
From: Andreas Ericsson @ 2006-12-15 8:34 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, Andy Parkins, git
In-Reply-To: <20061215042459.GC27343@spearce.org>
Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
>> It is nicer to let the user know when a commit succeeded all the time,
>> not only the first time. Also the commit sha1 is much more useful than
>> the tree sha1 in this case.
>
> I agree the commit sha1 is more useful than the tree sha1, but I'm
> not really sure its useful to show the commit sha1 post commit.
> If you want to show something the diffstat like what git merge does
> is better.
>
diffstats can be huge though. I'd rather have those only with -v option.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Avoiding uninteresting merges in Cairo
From: Shawn Pearce @ 2006-12-15 7:53 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87slfh4xkm.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> On Thu, 14 Dec 2006 22:25:30 -0500, Shawn Pearce wrote:
> > I saw three things happen to poor jwatt that really threw him for
> > a loop, and I think they are all more likely related to Git than
> > to the Cairo project specifically:
>
> Yes. Also a fourth one was a filesystem case-insensitivity issue. We
> recently imported an external library into cairo that had some
> filenames with capital letters. We then renamed them to the
> all-lowercase filenames we like. Poor jwatt was unlucky enough to have
> cloned with a capitalized filename, and then was trying to pull the
> latest with the lowercase filename and he got:
>
> fatal: Untracked working tree file 'test/pdiff/lpyramid.h'
> would be overwritten by merge
>
> This was in some sense worse than the other problems since it stopped
> him cold and gave him no idea what was wrong nor how to fix it.
This is a huge problem on filesystems where case does not matter
(FAT, Mac OS X's HFS+, NTFS). We really should put something into
git to detect this when it happens and help the user get out of
the box they have worked themselves into.
> > * His user.name/user.email is probably not what he wanted;
> >
> > * His Cygwin/Windows system made some *.c/*.c files 0755 without
> > him realizing it;
>
> Those two issues did silently put garbage in the commits. I don't know
> how to best fix the name/email thing. Maybe on the first commit with
> no user.name and user.email configuration git could create them,
> announce them to the user, and instruct them on how to change them:
>
> No name or email configuration exists. Using:
>
> U-JONATHAN-X60S\jonathan <jonathan@Jonathan-X60s.(none)>
>
> You can change these with the following commands:
>
> git repo-config user.name Your Name
> git repo-config user.email user@example.com
>
> And maybe mention --global as well.
I've been thinking that is the right thing to do, somewhere
in git-commit, but I can't decide if its best to save that
per-repository or per user, or be interactive and get confirmation
from the user, or just display it and hope the user noticed.
> As for the filemode setting, shouldn't that be configured by default
> the right way for Windows git?
No. The problem is Git tries to be smart and see if filemode works
by chmodding the config file and then looking to see if that worked
the way we expected it to. It usually does on Cygwin when using
NTFS. But then if you edit a file non-executable file with a native
Windows application Cygwin may suddenly think its executable again,
and now our core.filemode=true guess isn't actually right anymore.
We probably should just hardcode core.filemode to false on Cygwin.
If the user actually wants core.filemode to be true on Cygwin then
he/she will probably also know enough about this issue with native
Windows applications that the additional hurdle of turning on the
option by hand won't be a big one for them.
> > * gitweb made it appear as though a whole lot of Carl's recent
> > work was somehow undone in the merge.
>
> That looks like a simple gitweb bug. None of the other tools, (gitk,
> git log -p), consider a trivial merge commit like this as having
> anything interesting in it worth displaying.
Right. gitweb is doing `diff HEAD^1 HEAD` which is quite wrong on
a merge commit. Especially here where the trunk was pulled into
the topic branch, rather than the topic branch being pulled into
the trunk.
--
^ permalink raw reply
* [PATCH] Teach bash the new features of 'git show'.
From: Shawn O. Pearce @ 2006-12-15 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Now that 'git show' accepts ref:path as an argument to specify a
tree or blob we should use the same completion logic as we support
for cat-file's object identifier.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 24 +++++++++++++++++++++---
1 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 9c4d23a..234cd09 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -752,6 +752,24 @@ _git_reset ()
COMPREPLY=($(compgen -W "$opt $(__git_refs)" -- "$cur"))
}
+_git_show ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --pretty=*)
+ COMPREPLY=($(compgen -W "
+ oneline short medium full fuller email raw
+ " -- "${cur##--pretty=}"))
+ return
+ ;;
+ --*)
+ COMPREPLY=($(compgen -W "--pretty=" -- "$cur"))
+ return
+ ;;
+ esac
+ __git_complete_file
+}
+
_git ()
{
local i c=1 command __git_dir
@@ -802,7 +820,7 @@ _git ()
rebase) _git_rebase ;;
repo-config) _git_repo_config ;;
reset) _git_reset ;;
- show) _git_log ;;
+ show) _git_show ;;
show-branch) _git_log ;;
whatchanged) _git_log ;;
*) COMPREPLY=() ;;
@@ -839,7 +857,7 @@ complete -o default -o nospace -F _git_push git-push
complete -o default -F _git_rebase git-rebase
complete -o default -F _git_repo_config git-repo-config
complete -o default -F _git_reset git-reset
-complete -o default -F _git_log git-show
+complete -o default -o nospace -F _git_show git-show
complete -o default -o nospace -F _git_log git-show-branch
complete -o default -o nospace -F _git_log git-whatchanged
@@ -861,7 +879,7 @@ complete -o default -F _git_merge_base git-merge-base.exe
complete -o default -F _git_name_rev git-name-rev.exe
complete -o default -o nospace -F _git_push git-push.exe
complete -o default -F _git_repo_config git-repo-config
-complete -o default -o nospace -F _git_log git-show.exe
+complete -o default -o nospace -F _git_show git-show.exe
complete -o default -o nospace -F _git_log git-show-branch.exe
complete -o default -o nospace -F _git_log git-whatchanged.exe
fi
--
^ permalink raw reply related
* [PATCH] [Makefile] Export PERL_PATH
From: Luben Tuikov @ 2006-12-15 7:03 UTC (permalink / raw)
To: git
PERL_PATH is used by perl/Makefile so export it.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 6a86132..f016982 100644
--- a/Makefile
+++ b/Makefile
@@ -227,6 +227,8 @@ ifndef PERL_PATH
PERL_PATH = /usr/bin/perl
endif
+export PERL_PATH
+
LIB_FILE=libgit.a
XDIFF_LIB=xdiff/lib.a
--
1.4.4.2.g9bf39
^ permalink raw reply related
* [PATCH] Provide more meaningful output from 'git init-db'.
From: Shawn O. Pearce @ 2006-12-15 5:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Parkins, Nicolas Pitre
In-Reply-To: <Pine.LNX.4.64.0612142141420.18171@xanadu.home>
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.
As most users at that time were rather technical UNIXy folk the
message "defaulting to local storage area" made sense to some and
seemed reasonable.
But it doesn't really convey any meaning to the new Git user,
as they don't know what a 'local storage area is' nor do they
know enough about Git to care. It also really doesn't tell the
experienced Git user a whole lot about the command they just ran,
especially if they might be reinitializing an existing repository
(e.g. to update hooks).
So now we print out what we did ("Initialized empty" or
"Reinitialized existing"), what type of repository ("" or "shared"),
and what location the repository will be in ("$GIT_DIR").
Suggested in part 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 | 2 +-
Documentation/tutorial-2.txt | 2 +-
Documentation/tutorial.txt | 2 +-
builtin-init-db.c | 21 ++++++++++++++-------
4 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 47505aa..abe74a7 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -57,7 +57,7 @@ $ git-init-db
to which git will reply
----------------
-defaulting to local storage area
+Initialized empty Git repository in .git/
----------------
which is just git's way of saying that you haven't been doing anything
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
index 6389de5..7a692d7 100644
--- a/Documentation/tutorial-2.txt
+++ b/Documentation/tutorial-2.txt
@@ -18,7 +18,7 @@ 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
+Initialized empty Git repository in .git/
$ 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..cb808d9 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -38,7 +38,7 @@ $ git init-db
Git will reply
------------------------------------------------
-defaulting to local storage area
+Initialized empty Git repository in .git/
------------------------------------------------
You've now initialized the working directory--you may notice a new
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 235a0ee..8f2b750 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -164,13 +164,14 @@ static void copy_templates(const char *git_dir, int len, const char *template_di
closedir(dir);
}
-static void create_default_files(const char *git_dir, const char *template_path)
+static int create_default_files(const char *git_dir, const char *template_path)
{
unsigned len = strlen(git_dir);
static char path[PATH_MAX];
unsigned char sha1[20];
struct stat st1;
char repo_version_string[10];
+ int reinit;
if (len > sizeof(path)-50)
die("insane git directory %s", git_dir);
@@ -218,7 +219,8 @@ static void create_default_files(const char *git_dir, const char *template_path)
* branch, if it does not exist yet.
*/
strcpy(path + len, "HEAD");
- if (read_ref("HEAD", sha1) < 0) {
+ reinit = !read_ref("HEAD", sha1);
+ if (!reinit) {
if (create_symref("HEAD", "refs/heads/master") < 0)
exit(1);
}
@@ -239,6 +241,8 @@ static void create_default_files(const char *git_dir, const char *template_path)
git_config_set("core.filemode",
filemode ? "true" : "false");
}
+
+ return reinit;
}
static const char init_db_usage[] =
@@ -256,7 +260,7 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
const char *sha1_dir;
const char *template_dir = NULL;
char *path;
- int len, i;
+ int len, i, reinit;
for (i = 1; i < argc; i++, argv++) {
const char *arg = argv[1];
@@ -274,10 +278,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.
@@ -287,7 +289,7 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
*/
check_repository_format();
- create_default_files(git_dir, template_dir);
+ reinit = create_default_files(git_dir, template_dir);
/*
* And set up the object store.
@@ -314,5 +316,10 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
git_config_set("receive.denyNonFastforwards", "true");
}
+ printf("%s%s Git repository in %s/\n",
+ reinit ? "Reinitialized existing" : "Initialized empty",
+ shared_repository ? " shared" : "",
+ git_dir);
+
return 0;
}
--
^ permalink raw reply related
* Re: [PATCH] make commit message a little more consistent and conforting
From: Shawn Pearce @ 2006-12-15 4:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Andy Parkins, git
In-Reply-To: <Pine.LNX.4.64.0612142307160.18171@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> It is nicer to let the user know when a commit succeeded all the time,
> not only the first time. Also the commit sha1 is much more useful than
> the tree sha1 in this case.
I agree the commit sha1 is more useful than the tree sha1, but I'm
not really sure its useful to show the commit sha1 post commit.
If you want to show something the diffstat like what git merge does
is better.
For one thing it confirms that git accepted the changes. For another
it shows you *which* changes it accepted. Plus it responds just
like git-merge or git-pull does.
Of course the meaning of the diffstat is entirely different in both
cases; in the commit case its what has been recorded while in the
merge case its not only what has been recorded into your current
branch history but also what has been done to your working directory.
--
^ permalink raw reply
* [PATCH] make commit message a little more consistent and conforting
From: Nicolas Pitre @ 2006-12-15 4:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <Pine.LNX.4.64.0612141343200.18171@xanadu.home>
It is nicer to let the user know when a commit succeeded all the time,
not only the first time. Also the commit sha1 is much more useful than
the tree sha1 in this case.
This patch also introduces a -q switch to supress this message as well
as the summary of created/deleted files.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 47505aa..1c31159 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -336,17 +336,9 @@ $ commit=$(echo 'Initial commit' | git-commit-tree $tree)
$ git-update-ref HEAD $commit
------------------------------------------------
-which will say:
-
-----------------
-Committing initial tree 8988da15d077d4829fc51d8544c097def6644dbb
-----------------
-
-just to warn you about the fact that it created a totally new commit
-that is not related to anything else. Normally you do this only *once*
-for a project ever, and all later commits will be parented on top of an
-earlier commit, and you'll never see this "Committing initial tree"
-message ever again.
+In this case this creates a totally new commit that is not related to
+anything else. Normally you do this only *once* for a project ever, and
+all later commits will be parented on top of an earlier commit.
Again, normally you'd never actually do this by hand. There is a
helpful script called `git commit` that will do all of this for you. So
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 97d66ef..0b74cd7 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -113,6 +113,9 @@ but can be used to amend a merge commit.
as well. This is usually not what you want unless you
are concluding a conflicted merge.
+-q|--quiet::
+ Supress commit summary message.
+
\--::
Do not interpret any more arguments as options.
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
index 6389de5..8606381 100644
--- a/Documentation/tutorial-2.txt
+++ b/Documentation/tutorial-2.txt
@@ -22,14 +22,14 @@ defaulting to local storage area
$ echo 'hello world' > file.txt
$ git add .
$ git commit -a -m "initial commit"
-Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe
+Created initial commit 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
create mode 100644 file.txt
$ echo 'hello world!' >file.txt
$ git commit -a -m "add emphasis"
+Created commit c4d59f390b9cfd4318117afde11d601c1085f241
------------------------------------------------
-What are the 40 digits of hex that git responded to the first commit
-with?
+What are the 40 digits of hex that git responded to the commit with?
We saw in part one of the tutorial that commits have names like this.
It turns out that every object in the git history is stored under
@@ -39,13 +39,25 @@ the same data twice (since identical data is given an identical SHA1
name), and that the contents of a git object will never change (since
that would change the object's name as well).
+It is expected that the content of the commit object you created while
+following the example above generates a different SHA1 hash than
+the one shown above because the commit object records the time when
+it was created and the name of the person performing the commit.
+
We can ask git about this particular object with the cat-file
-command--just cut-and-paste from the reply to the initial commit, to
-save yourself typing all 40 hex digits:
+command. Don't copy the 40 hex digits from this example but use those
+from your own version. Note that you can shorten it to only a few
+characters to save yourself typing all 40 hex digits:
------------------------------------------------
-$ git cat-file -t 92b8b694ffb1675e5975148e1121810081dbdffe
-tree
+$ git-cat-file -t 54196cc2
+commit
+$ git-cat-file commit 54196cc2
+tree 92b8b694ffb1675e5975148e1121810081dbdffe
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+
+initial commit
------------------------------------------------
A tree can refer to one or more "blob" objects, each corresponding to
@@ -102,8 +114,7 @@ $ find .git/objects/
and the contents of these files is just the compressed data plus a
header identifying their length and their type. The type is either a
-blob, a tree, a commit, or a tag. We've seen a blob and a tree now,
-so next we should look at a commit.
+blob, a tree, a commit, or a tag.
The simplest commit to find is the HEAD commit, which we can find
from .git/HEAD:
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index e2e690a..856f3cd 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -107,8 +107,6 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
if (new_parent(parents))
parents++;
}
- if (!parents)
- fprintf(stderr, "Committing initial tree %s\n", argv[1]);
init_buffer(&buffer, &size);
add_buffer(&buffer, &size, "tree %s\n", sha1_to_hex(tree_sha1));
diff --git a/git-commit.sh b/git-commit.sh
index 05828bb..395bcd2 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -80,6 +80,7 @@ no_edit=
log_given=
log_message=
verify=t
+quiet=
verbose=
signoff=
force_author=
@@ -241,6 +242,10 @@ $1"
signoff=t
shift
;;
+ -q|--q|--qu|--qui|--quie|--quiet)
+ quiet=t
+ shift
+ ;;
-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
verbose=t
shift
@@ -615,11 +620,17 @@ then
git-rerere
fi
-if test -x "$GIT_DIR"/hooks/post-commit && test "$ret" = 0
+if test "$ret" = 0
then
- "$GIT_DIR"/hooks/post-commit
+ if test -x "$GIT_DIR"/hooks/post-commit
+ then
+ "$GIT_DIR"/hooks/post-commit
+ fi
+ if test -z "$quiet"
+ then
+ echo "Created${initial_commit:+ initial} commit $commit"
+ git-diff-tree --summary --root --no-commit-id HEAD
+ fi
fi
-test "$ret" = 0 && git-diff-tree --summary --root --no-commit-id HEAD
-
^ permalink raw reply related
* Re: What's in git.git (stable)
From: Nicolas Pitre @ 2006-12-15 4:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7v7iwu93rv.fsf@assigned-by-dhcp.cox.net>
On Thu, 14 Dec 2006, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
> > $ git commit
> > Revision XXXXXXXXXXXXXXXXXX successfully added.
> >
> > I'd actually argue that git-commit is a particular problem because it's too
> > fast. You quit editing your commit message and bang, you're back at the
> > command line. Then you run git-log to make sure it really was committed.
>
> You keep repeating that you want to know the object name of the
> newly created commit. I would very strongly agree with you that
> it would be a fatal UI bug of git-commit if that information
> were vital for the end user after making each commit.
I think this is not the point.
Of course the name of the newly created commit isn't _that_ important.
But so is the "Committing initial tree 5220388..." message.
And in the commit case, you are left with a blank screen and just a
shell prompt after you quit the text editor for the log message, which
is a bit worrisome. My initial reflex is not to think "ah it just did
what I asked it" but rather "hmmm has it just crashed on me?"
Having a single line of feedback when a commit has completed would not
be overly verbose and remove that impression of committing into a
void I'd think.
Note that, as I said in another thread, I'm really not advocating for
git-add to do the same. The git-add is a relatively simple and
lightweight operation that has not the same impact as a commit has
_conceptually_. It doesn't clear the screen for one thing so just
returning to the shell prompt (unless -v is used) is plenty sufficient.
I'm following up with a patch to implement what I think should be done.
^ permalink raw reply
* Re: Avoiding uninteresting merges in Cairo
From: Carl Worth @ 2006-12-15 4:01 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061215032530.GM26202@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]
On Thu, 14 Dec 2006 22:25:30 -0500, Shawn Pearce wrote:
> I saw three things happen to poor jwatt that really threw him for
> a loop, and I think they are all more likely related to Git than
> to the Cairo project specifically:
Yes. Also a fourth one was a filesystem case-insensitivity issue. We
recently imported an external library into cairo that had some
filenames with capital letters. We then renamed them to the
all-lowercase filenames we like. Poor jwatt was unlucky enough to have
cloned with a capitalized filename, and then was trying to pull the
latest with the lowercase filename and he got:
fatal: Untracked working tree file 'test/pdiff/lpyramid.h'
would be overwritten by merge
This was in some sense worse than the other problems since it stopped
him cold and gave him no idea what was wrong nor how to fix it.
> * His user.name/user.email is probably not what he wanted;
>
> * His Cygwin/Windows system made some *.c/*.c files 0755 without
> him realizing it;
Those two issues did silently put garbage in the commits. I don't know
how to best fix the name/email thing. Maybe on the first commit with
no user.name and user.email configuration git could create them,
announce them to the user, and instruct them on how to change them:
No name or email configuration exists. Using:
U-JONATHAN-X60S\jonathan <jonathan@Jonathan-X60s.(none)>
You can change these with the following commands:
git repo-config user.name Your Name
git repo-config user.email user@example.com
And maybe mention --global as well.
As for the filemode setting, shouldn't that be configured by default
the right way for Windows git?
> * gitweb made it appear as though a whole lot of Carl's recent
> work was somehow undone in the merge.
That looks like a simple gitweb bug. None of the other tools, (gitk,
git log -p), consider a trivial merge commit like this as having
anything interesting in it worth displaying.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Avoiding uninteresting merges in Cairo
From: Shawn Pearce @ 2006-12-15 3:25 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87tzzx4zm7.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> One thing I've been meaning to do is to write up a more complete
> introduction on using git to manage cairo's tree to put into cairo's
> wiki or so, (it would have helped a newcomer like jwatt here).
I saw three things happen to poor jwatt that really threw him for
a loop, and I think they are all more likely related to Git than
to the Cairo project specifically:
* His user.name/user.email is probably not what he wanted;
* His Cygwin/Windows system made some *.c/*.c files 0755 without
him realizing it;
* gitweb made it appear as though a whole lot of Carl's recent
work was somehow undone in the merge.
--
^ permalink raw reply
* Re: Avoiding uninteresting merges in Cairo
From: Carl Worth @ 2006-12-15 3:17 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061215020629.GK26202@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]
On Thu, 14 Dec 2006 21:06:29 -0500, Shawn Pearce wrote:
> http://lists.freedesktop.org/archives/cairo/2006-April/006648.html
>
> after he had a merge gone wrong in his working directory and was
> asking for help.
>
> Cario has seriously been using `reset --hard HEAD^` as part of its
> workflow since April?
I wrote that in April, but I've never pointed anyone at it since
then. I've learned a lot since then, (and git has changed too).
One thing I've been meaning to do is to write up a more complete
introduction on using git to manage cairo's tree to put into cairo's
wiki or so, (it would have helped a newcomer like jwatt here).
> Why haven't you pushed for a rebase merge
> strategy to be tried before a trivial index merge as an option in
> git-merge (e.g. pull.twohead=rebase recursive)?
I've mentioned it as an idea once or twice on this list. I've never
"pushed" for any change along these lines simply because I haven't
ever done any implementation for this.
Also, I don't actually need this. I don't use the "reset --hard"
workflow suggested in the mail above. I always obtain remote changes
with "git fetch" and then examine things locally and decide to either
merge (or fast forward) with "git pull", (though maybe I'll start
using "git merge" now), or else to use "git rebase" to avoid the noisy
merge commits.
That workflow of fetching changes and then exploring them locally
before merging is why I rarely take advantage of the combined
fetch+merge aspect of "git pull". It's exceedingly rare for me to ever
call "git pull" with any URL but ".", (though I use "git fetch" with
various URLs on a regular basis).
-Carl
PS. It's funny how much easier it is to type "cario" than "cairo". I
used to do that all the time, (though in this sentence here, when I
actually _tried_ to type "cario" it came out as "cairo" the first
time). I think the "cario" typo is a Qwerty artefact---the left hand
gets all its keypresses in before the right hand gets going.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Stop telling users we are 'defaulting to local storage area'.
From: Nicolas Pitre @ 2006-12-15 2:43 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git, Andy Parkins
In-Reply-To: <20061215022543.GL26202@spearce.org>
On Thu, 14 Dec 2006, Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
> > > It also breaks from our normal behavior of not printing
> > > anything if the command was successful.
>
> > I really don't think this is a good rule.
> >
> > NOte that I'm not against commands that are silent by default. I really
> > think that git-add should remain silent on success by default when
> > successful.
> >
> > But the rule of thumb should be about the importance of the action
> > performed by the command.
> > But git-init-db is really important.
>
> A very reasonable argument, butchered for my evil quoting needs. :-)
>
> If we want to keep letting git-init-db output something, then
> the output should be a lot more meaningful to the average English
> speaking new Git user than "defaulting to local storage area".
Absolutely!
> BTW, I almost also submitted a patch to remove the "Committing
> initial tree ..." message in git-commit-tree, but thought twice about
> it as committing an initial tree is sort of an important difference
> from normal activity that we should highlight it somehow...
Please ignore that one. I'm working on a patch to handle the commit
case (need to update the tutorial accordingly).
^ permalink raw reply
* Re: git-fetch fails with error code 128
From: Nicolas Pitre @ 2006-12-15 2:31 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Andy Parkins, git
In-Reply-To: <200612142325.kBENPF1u001043@laptop13.inf.utfsm.cl>
On Thu, 14 Dec 2006, Horst H. von Brand wrote:
> > 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.
This is a very possible cause, especially if both processes
(pack-objects and unpack-objects) are running at the same time on the
same machine.
^ permalink raw reply
* Re: git-fetching from a big repository is slow
From: Nicolas Pitre @ 2006-12-15 2:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn Pearce, Geert Bosch, Andreas Ericsson, Andy Parkins, git
In-Reply-To: <Pine.LNX.4.63.0612150013390.3635@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, 15 Dec 2006, Johannes Schindelin wrote:
> 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.
Yes! Run git-repack -a -d on the remote repository.
^ permalink raw reply
* Re: [PATCH] Stop telling users we are 'defaulting to local storage area'.
From: Shawn Pearce @ 2006-12-15 2:25 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Andy Parkins
In-Reply-To: <Pine.LNX.4.64.0612142059301.18171@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
> > It also breaks from our normal behavior of not printing
> > anything if the command was successful.
> I really don't think this is a good rule.
>
> NOte that I'm not against commands that are silent by default. I really
> think that git-add should remain silent on success by default when
> successful.
>
> But the rule of thumb should be about the importance of the action
> performed by the command.
> But git-init-db is really important.
A very reasonable argument, butchered for my evil quoting needs. :-)
If we want to keep letting git-init-db output something, then
the output should be a lot more meaningful to the average English
speaking new Git user than "defaulting to local storage area".
E.g.:
$ git init-db
Initialized empty Git repository in .git/
would probably make a lot more sense to new and expert users alike.
I'm fine with the above form, I just think that the message we have
now could benefit from being sent to the land from which there is
no return, or be rewritten...
BTW, I almost also submitted a patch to remove the "Committing
initial tree ..." message in git-commit-tree, but thought twice about
it as committing an initial tree is sort of an important difference
from normal activity that we should highlight it somehow...
--
^ permalink raw reply
* Re: git-fetch fails with error code 128
From: Nicolas Pitre @ 2006-12-15 2:25 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612142308.45376.andyparkins@gmail.com>
On Thu, 14 Dec 2006, Andy Parkins wrote:
> 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.
Could you please instrument patch-delta.c to determine which of the
"return NULL" is executed?
^ permalink raw reply
* Re: [PATCH] Stop telling users we are 'defaulting to local storage area'.
From: Nicolas Pitre @ 2006-12-15 2:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, Andy Parkins
In-Reply-To: <20061214230902.GA26506@spearce.org>
On Thu, 14 Dec 2006, Shawn O. Pearce wrote:
[...]
> It also breaks from our normal behavior of not printing
> anything if the command was successful.
Before everybody starts believing everybody agrees with this I'll have
to throw a tile in the pond.
I really don't think this is a good rule.
NOte that I'm not against commands that are silent by default. I really
think that git-add should remain silent on success by default when
successful.
But the rule of thumb should be about the importance of the action
performed by the command. git-add is a less important command than
git-init-db or git-commit _conceptually_. You can do multiple git-add
in whatever order, even repeatedly, and it won't change the outcome.
It is "conceptually lightweight". But git-init-db is really important.
Without it you just can't do anything. It should give the user the
impression that something did actually happen, especially since this is
the git comand any new git user is most likely to use first. Saying
back "git repository initialized" tells the user "OK you can start now".
Saying nothing might just leave the user wondering if everything is
actually fine.
^ permalink raw reply
* Avoiding uninteresting merges in Cairo
From: Shawn Pearce @ 2006-12-15 2:06 UTC (permalink / raw)
To: cworth; +Cc: git
I was just talking with jwatt today in #git and he pointed me at
the following email from
http://lists.freedesktop.org/archives/cairo/2006-April/006648.html
after he had a merge gone wrong in his working directory and was
asking for help.
Cario has seriously been using `reset --hard HEAD^` as part of its
workflow since April? Why haven't you pushed for a rebase merge
strategy to be tried before a trivial index merge as an option in
git-merge (e.g. pull.twohead=rebase recursive)?
--
^ 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