* [RFC/PATCH] Documentation: be consistent about "git-" versus "git "
From: Jonathan Nieder @ 2008-06-30 7:30 UTC (permalink / raw)
To: git
I guess this patch is too long (168 KB). You can find it at
<http://home.uchicago.edu/~jrnieder/20080630-git-documentation-patch.txt>.
In a world where git-* are not in $(bindir), using "git-command
<parameters>" in examples in the documentation is not a good
idea. On the other hand, it is convenient for commands to be
named with one word, not two, the manpages are still called
"git-command (1)", and the user is not going to be able to escape
seeing "git-command" in the "wild" from time to time anyway. What
to do?
This patch keeps the dash when naming an operation, command,
program, process, or action but tries to be dashless in all
complete command lines ready to be entered at a shell (i.e.,
without options omitted).
The changes consist mostly of adding and removing dashes
accordingly. Other changes:
* "git clone" has been replaced with "git clone <repo>" (rather
than "git-clone") in the example at the beginning of
user-manual.txt in an attempt to make the switching between
dashed and dashless commands a little less confusing.
* git-merge-one-file has been replaced with $(git
--exec-path)/git-merge-one-file in two places
* /usr/bin/git has been replaced with /usr/bin/git-daemon in the
sample inetd.conf lines in git-daemon(1). The analogous
changes in git-cvsserver(1) have *not* been made.
* Some whitespace changes (spaces changing into dashes
disallowed some line breaks; some sequences of spaces have been
changed into tabs in the same line as other changes)
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
I just realized that most of the rest of the man pages
(aside from git-{sh-setup,parse-remote} (1)) are not ready
for the Git tools to move, either. Here's a start towards
less confusing documentation for that situation.
Sorry for the enormous patch. Hope it gives someone some
amusement. It is only an RFC because
1) I am not sure whether the criterion for dashworthiness
I used is the right one. I tried to follow the lead of
good existing documentation, but there is no one
convention used throughout.
2) I also want to make the formatting a bit more consistent
(always 'git-command' or always `git-command`) in
another patch if that is appropriate, while I am at it.
So I don't want this commited yet.
3) I would be much more comfortable if I could run some
commands to quickly check that this patch only does
what I have claimed it does.
Thoughts? Suggestions?
Documentation/git-add.txt | 2 +-
Documentation/git-am.txt | 4 +-
Documentation/git-annotate.txt | 2 +-
Documentation/git-apply.txt | 2 +-
Documentation/git-archimport.txt | 2 +-
Documentation/git-archive.txt | 2 +-
Documentation/git-blame.txt | 2 +-
Documentation/git-branch.txt | 8 +-
Documentation/git-bundle.txt | 14 ++--
Documentation/git-cat-file.txt | 4 +-
Documentation/git-check-attr.txt | 2 +-
Documentation/git-check-ref-format.txt | 4 +-
Documentation/git-checkout-index.txt | 20 +++---
Documentation/git-checkout.txt | 8 +-
Documentation/git-cherry-pick.txt | 2 +-
Documentation/git-clean.txt | 2 +-
Documentation/git-clone.txt | 2 +-
Documentation/git-commit-tree.txt | 2 +-
Documentation/git-commit.txt | 4 +-
Documentation/git-config.txt | 26 ++++----
Documentation/git-count-objects.txt | 4 +-
Documentation/git-cvsexportcommit.txt | 9 ++-
Documentation/git-cvsimport.txt | 4 +-
Documentation/git-cvsserver.txt | 2 +-
Documentation/git-daemon.txt | 10 ++--
Documentation/git-describe.txt | 10 ++--
Documentation/git-diff-files.txt | 2 +-
Documentation/git-diff-index.txt | 12 ++--
Documentation/git-diff-tree.txt | 8 +-
Documentation/git-diff.txt | 18 +++---
Documentation/git-fast-import.txt | 8 +-
Documentation/git-fetch-pack.txt | 2 +-
Documentation/git-fetch.txt | 4 +-
Documentation/git-filter-branch.txt | 4 +-
Documentation/git-fmt-merge-msg.txt | 4 +-
Documentation/git-for-each-ref.txt | 8 +-
Documentation/git-format-patch.txt | 2 +-
Documentation/git-fsck-objects.txt | 2 +-
Documentation/git-fsck.txt | 4 +-
Documentation/git-gc.txt | 4 +-
Documentation/git-get-tar-commit-id.txt | 2 +-
Documentation/git-grep.txt | 2 +-
Documentation/git-hash-object.txt | 2 +-
Documentation/git-http-fetch.txt | 2 +-
Documentation/git-http-push.txt | 2 +-
Documentation/git-imap-send.txt | 4 +-
Documentation/git-index-pack.txt | 4 +-
Documentation/git-init-db.txt | 2 +-
Documentation/git-init.txt | 6 +-
Documentation/git-instaweb.txt | 4 +-
Documentation/git-lost-found.txt | 2 +-
Documentation/git-ls-files.txt | 2 +-
Documentation/git-ls-remote.txt | 2 +-
Documentation/git-ls-tree.txt | 2 +-
Documentation/git-mailinfo.txt | 6 +-
Documentation/git-mailsplit.txt | 2 +-
Documentation/git-merge-base.txt | 4 +-
Documentation/git-merge-file.txt | 4 +-
Documentation/git-merge-index.txt | 6 +-
Documentation/git-merge-tree.txt | 2 +-
Documentation/git-merge.txt | 8 +-
Documentation/git-mergetool.txt | 16 +++---
Documentation/git-mktag.txt | 2 +-
Documentation/git-mv.txt | 6 +-
Documentation/git-name-rev.txt | 2 +-
Documentation/git-pack-objects.txt | 2 +-
Documentation/git-pack-redundant.txt | 4 +-
Documentation/git-pack-refs.txt | 8 +-
Documentation/git-patch-id.txt | 2 +-
Documentation/git-peek-remote.txt | 2 +-
Documentation/git-prune-packed.txt | 2 +-
Documentation/git-prune.txt | 2 +-
Documentation/git-pull.txt | 2 +-
Documentation/git-push.txt | 2 +-
Documentation/git-quiltimport.txt | 2 +-
Documentation/git-read-tree.txt | 32 +++++-----
Documentation/git-rebase.txt | 18 +++---
Documentation/git-receive-pack.txt | 6 +-
Documentation/git-relink.txt | 2 +-
Documentation/git-remote.txt | 12 ++--
Documentation/git-repack.txt | 10 ++--
Documentation/git-repo-config.txt | 2 +-
Documentation/git-request-pull.txt | 2 +-
Documentation/git-rerere.txt | 4 +-
Documentation/git-rev-list.txt | 10 ++--
Documentation/git-rev-parse.txt | 6 +-
Documentation/git-revert.txt | 2 +-
Documentation/git-rm.txt | 6 +-
Documentation/git-send-email.txt | 2 +-
Documentation/git-send-pack.txt | 2 +-
Documentation/git-shortlog.txt | 6 +-
Documentation/git-show-branch.txt | 4 +-
Documentation/git-show-index.txt | 2 +-
Documentation/git-show-ref.txt | 6 +-
Documentation/git-show.txt | 2 +-
Documentation/git-stash.txt | 14 ++--
Documentation/git-status.txt | 6 +-
Documentation/git-stripspace.txt | 2 +-
Documentation/git-submodule.txt | 10 ++--
Documentation/git-svn.txt | 34 +++++-----
Documentation/git-symbolic-ref.txt | 2 +-
Documentation/git-tag.txt | 16 +++---
Documentation/git-tar-tree.txt | 2 +-
Documentation/git-unpack-file.txt | 2 +-
Documentation/git-unpack-objects.txt | 2 +-
Documentation/git-update-index.txt | 12 ++--
Documentation/git-update-ref.txt | 10 ++--
Documentation/git-update-server-info.txt | 2 +-
Documentation/git-upload-archive.txt | 2 +-
Documentation/git-upload-pack.txt | 2 +-
Documentation/git-var.txt | 4 +-
Documentation/git-verify-pack.txt | 2 +-
Documentation/git-verify-tag.txt | 2 +-
Documentation/git-web--browse.txt | 2 +-
Documentation/git-whatchanged.txt | 6 +-
Documentation/git-write-tree.txt | 2 +-
Documentation/gitattributes.txt | 14 ++--
Documentation/gitcore-tutorial.txt | 94 +++++++++++++++---------------
Documentation/gitcvs-migration.txt | 8 +-
Documentation/gitdiffcore.txt | 2 +-
Documentation/githooks.txt | 10 ++--
Documentation/gitignore.txt | 4 +-
Documentation/gitrepository-layout.txt | 20 +++---
Documentation/gittutorial-2.txt | 18 +++---
Documentation/gittutorial.txt | 34 +++++-----
Documentation/user-manual.txt | 76 ++++++++++++------------
126 files changed, 456 insertions(+), 455 deletions(-)
Patch at
<http://home.uchicago.edu/~jrnieder/20080630-git-documentation-patch.txt>.
^ permalink raw reply
* Re: Git branches - confusing behavior
From: Matt Seitz (matseitz) @ 2008-06-30 7:23 UTC (permalink / raw)
To: git; +Cc: dima.kagan
On May 11, 3:58 am, mitya <dima.ka...@gmail.com> wrote:
> I started with the following steps:
>
> > git-svn clonehttp://svn.test.org/test/trunk
> > cd trunk
> > git branch test_branch
> > git checkout test_branch
> > vi somefile
>
> However, when I execute 'git checkout master', I get:
> M somefile
> Switched to branch "master"
>
> Basically I see that the same file I edited on the 'test_branch'
> branch appears to be modified on the 'master' branch as well.
I was also confused by this behavior. I think this is a documentation issue. In the "man" page for "git-checkout", the "Description" section says:
"...this command switches branches by updating the index and working tree to reflect the specified branch...".
This led me to believe that all files in the working tree would be updated to match the last commit in the specified branch. The "Description" section doesn't mention any exceptions, such as files that have been modified but not committed in the current branch.
There are some clues that this is the intended behavior in the descriptions of the "-f" and "-m" options, and in the "After working in the wrong branch..." example. But it was not clear to me from reading the "man" page (and the "gittutorial" and the "Git User's Guide") that this behavior was correct and intended.
I think it would be helpful in the "Description" section of the "man" page to elaborate on how git updates the working tree to reflect the specified branch. This could include documenting the default handling of files that have been modified in the current branch. A rationale for the behavior would also be helpful. This might have prevented my confusion when first encountering this issue.
--
Matt Seitz
Manager, File System Virtualization
Cisco Systems, Inc.
.:|:.:|:.
^ permalink raw reply
* [PATCH] Skip unwritable tests for root
From: Fernando J. Pereda @ 2008-06-30 7:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Fernando J. Pereda <ferdy@ferdyx.org>
---
t/t0004-unwritable.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/t/t0004-unwritable.sh b/t/t0004-unwritable.sh
index 9255c63..728ec22 100755
--- a/t/t0004-unwritable.sh
+++ b/t/t0004-unwritable.sh
@@ -4,6 +4,13 @@ test_description='detect unwritable repository and fail correctly'
. ./test-lib.sh
+if test "$(id -u)" -eq 0
+then
+ test_expect_success 'root writes to unwritable places, skipping test' :
+ test_done
+ exit
+fi
+
test_expect_success setup '
>file &&
--
1.5.6.1
^ permalink raw reply related
* Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
From: Junio C Hamano @ 2008-06-30 6:44 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Daniel Barkalow, Pieter de Bie,
Git Mailinglist
In-Reply-To: <20080630064031.GA30600@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> Of course, that would have downsides as well. Now git-clone tests cannot
>> be sanely written without setting $HOME to somewhere stable; otherwise
>> they can be randomly affected by buggy $HOME/.gitconfig files the end user
>> may have.
>
> I thought we went through all of this before, and it led to 8bfa6bd6.
> The test scripts set GIT_CONFIG_NOSYSTEM and GIT_CONFIG_NOGLOBAL to
> achieve the same suppression effect.
Ah, thanks. Actually I was scratching my head trying to figure out why it
does not break after I wrote the above ;-)
^ permalink raw reply
* Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
From: Jeff King @ 2008-06-30 6:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Daniel Barkalow, Pieter de Bie,
Git Mailinglist
In-Reply-To: <7vskuv30e6.fsf@gitster.siamese.dyndns.org>
On Sun, Jun 29, 2008 at 11:25:05PM -0700, Junio C Hamano wrote:
> > Honestly, GIT_CONFIG is purely for scripts like git-svn that muck with
> > files that are in the config format to have a way to make sure that they
> > access the file they intend to, and being able to use GIT_CONFIG to keep
> > git programs from reading from $HOME/.gitconfig is primarily for giving
> > our test scripts repeatable environment, nothing more.
[...]
> Of course, that would have downsides as well. Now git-clone tests cannot
> be sanely written without setting $HOME to somewhere stable; otherwise
> they can be randomly affected by buggy $HOME/.gitconfig files the end user
> may have.
I thought we went through all of this before, and it led to 8bfa6bd6.
The test scripts set GIT_CONFIG_NOSYSTEM and GIT_CONFIG_NOGLOBAL to
achieve the same suppression effect.
-Peff
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Stefan Richter @ 2008-06-30 6:27 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Jan Engelhardt, Linux Kernel, Git Mailing List
In-Reply-To: <48684A46.7040802@garzik.org>
Jeff Garzik wrote:
> Stefan Richter wrote:
>> A while ago the default behavior of git pull was changed to fetch all
>> tags which point to objects that can be reached from any of the tracked
>> heads.
>
>
> This does not work in all cases. When I retrieve the latest kernel, it
> downloads the tags:
>
> cd /spare/repo/linux-2.6
> git pull
>
> but when I pull those changes into another local repo, the tags do -not-
> follow the objects:
>
> cd /spare/repo/misc-2.6
> git checkout master
> git pull ../linux-2.6
> git fetch --tags ../linux-2.6 # still required to this day
I guess this is because /spare/repo/misc-2.6 does not have branches of
/spare/repo/linux-2.6 configured as remote (tracking) branches.
--
Stefan Richter
-=====-==--- -==- ====-
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
From: Junio C Hamano @ 2008-06-30 6:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Pieter de Bie, Git Mailinglist
In-Reply-To: <7vwsk730mm.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Honestly, GIT_CONFIG is purely for scripts like git-svn that muck with
> files that are in the config format to have a way to make sure that they
> access the file they intend to, and being able to use GIT_CONFIG to keep
> git programs from reading from $HOME/.gitconfig is primarily for giving
> our test scripts repeatable environment, nothing more.
>
> I think ignoring end-user GIT_CONFIG like this patch does, instead of
> doing random nonsense, would be a good bugfix for "git clone".
Of course, that would have downsides as well. Now git-clone tests cannot
be sanely written without setting $HOME to somewhere stable; otherwise
they can be randomly affected by buggy $HOME/.gitconfig files the end user
may have.
^ permalink raw reply
* Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
From: Junio C Hamano @ 2008-06-30 6:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Pieter de Bie, Git Mailinglist
In-Reply-To: <alpine.DEB.1.00.0806292248160.9925@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 29 Jun 2008, Daniel Barkalow wrote:
>
>> Did we even make a commitment on whether:
>>
>> GIT_CONFIG=foo git clone bar
>>
>> must ignore the environment variable, or simply doesn't necessarily obey
>> it?
>
> I'd rather strongly argue that no matter what is the answer to this
> question, we _HAVE TO_ unsetenv() GIT_CONFIG at some stage, otherwise no
> .git/config will be written.
>
> So, this is a NACK on your patch.
True. We are creating the config file for the new repository, so the
initial setenv() would make sense. We _could_ save away end user's
GIT_CONFIG and restore it where you unsetenv() in your patch, but I do not
think it would buy us anything other than "be consistent with other
programs that misbehave when end user has GIT_CONFIG".
Honestly, GIT_CONFIG is purely for scripts like git-svn that muck with
files that are in the config format to have a way to make sure that they
access the file they intend to, and being able to use GIT_CONFIG to keep
git programs from reading from $HOME/.gitconfig is primarily for giving
our test scripts repeatable environment, nothing more.
I think ignoring end-user GIT_CONFIG like this patch does, instead of
doing random nonsense, would be a good bugfix for "git clone".
^ permalink raw reply
* Re: perl t9700 failures?
From: Johannes Sixt @ 2008-06-30 6:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List, Lea Wiemann
In-Reply-To: <7vzlp47zy8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> I'll commit this
> +perl -MTest::More -e 0 2>/dev/null || {
> + say skip "Perl Test::More unavailable, skipping test"
But without the "skip", right? ;)
-- Hannes
^ permalink raw reply
* Re: [PATCH 13/13] Build in merge
From: Junio C Hamano @ 2008-06-30 5:44 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Johannes Schindelin, Olivier Marin
In-Reply-To: <e8d1385cc49a06ca3fae28231ebc66a333ce4ffb.1214789764.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> diff --git a/builtin-merge.c b/builtin-merge.c
> new file mode 100644
> index 0000000..187038c
> --- /dev/null
> +++ b/builtin-merge.c
> @@ -0,0 +1,1173 @@
> ...
> +static void save_state(void)
> +{
> + int fd;
> + struct child_process stash;
> + const char *argv[] = {"stash", "create", NULL};
> +
> + fd = open(git_path("MERGE_STASH"), O_WRONLY | O_CREAT, 0666);
> + if (fd < 0)
> + die("Could not write to %s", git_path("MERGE_STASH"));
> + memset(&stash, 0, sizeof(stash));
> + stash.argv = argv;
> + stash.out = fd;
> + stash.git_cmd = 1;
> + run_command(&stash);
> +}
I first thought "heh, that's clever" until I noticed that we use "stash
create" with "stash apply" these days instead of cpio for this. I suspect
that we can do away without leaving the stash in this temporary file, but
that comment applies to the scripted version as well.
By the way, it would be consistent to name counterpart to dropsave in the
scripted version as "drop_save" if you use "save_state" and "restore_state".
> +static void reset_hard(unsigned const char *sha1, int verbose)
> +{
> + struct tree *tree;
> + struct unpack_trees_options opts;
> + struct tree_desc t;
> +
> + memset(&opts, 0, sizeof(opts));
> + opts.head_idx = -1;
> + opts.src_index = &the_index;
> + opts.dst_index = &the_index;
> + opts.update = 1;
> + opts.reset = 1;
> + if (verbose)
> + opts.verbose_update = 1;
> +
> + tree = parse_tree_indirect(sha1);
> + if (!tree)
> + die("failed to unpack %s tree object", sha1_to_hex(sha1));
> + parse_tree(tree);
> + init_tree_desc(&t, tree->buffer, tree->size);
> + if (unpack_trees(1, &t, &opts))
> + exit(128); /* We've already reported the error, finish dying */
> +}
Isn't this trashing all the cached stat info from the index? If this is
emulating "reset --hard", it also should set opts.merge and do
oneway_merge, after reading the current index in, I think. Resetting the
index and the working tree is not particularly performance critical part,
but trashing the cached stat info would hurt the performance of everything
that reads the index after this function returns quite badly. I suspect
that you might be better off forking the real thing (reset --hard) if you
cannot get it right here.
> +/* Get the name for the merge commit's message. */
> +static void merge_name(const char *remote, struct strbuf *msg)
> ...
> + strbuf_init(&buf, 0);
> + strbuf_addstr(&buf, "refs/heads/");
> + strbuf_addstr(&buf, remote);
> + dwim_ref(buf.buf, buf.len, branch_head, &ref);
> + if (!hashcmp(remote_head->sha1, branch_head)) {
> + strbuf_addf(msg, "%s\t\tbranch '%s' of .\n",
> + sha1_to_hex(branch_head), remote);
> + return;
> + }
Hmm, why not resolve_ref() so that it does not dwim at all? The point of
the code is so that you can be confident that 'blah' *is* a local branch
when you say "branch 'blah'".
> + /* See if remote matches <name>~<number>, or <name>^ */
> + ptr = strrchr(remote, '^');
> + if (ptr && ptr[1] == '\0') {
> + len = strlen(remote);
> + while ((ptr = (char *)memrchr(remote, '^', len)))
> + if (ptr && ptr[1] == '\0')
> + len = ptr - remote - 1;
> + else
> + break;
That's a funny way to say:
for (len = 0, ptr = remote + strlen(remote);
remote < ptr && ptr[-1] == '^';
ptr--)
len++;
> + if (len) {
> + struct strbuf truname = STRBUF_INIT;
> + strbuf_addstr(&truname, remote);
> + strbuf_setlen(&truname, len);
> + if (dwim_ref(truname.buf, truname.len, buf_sha, &ref)) {
> + strbuf_addf(msg,
> + "%s\t\tbranch '%s' (early part) of .\n",
> + sha1_to_hex(remote_head->sha1), truname.buf);
> + return;
Isn't this wrong? Giving "v1.5.6~20" to this code will strip ~20 and make
remote = "v1.5.6", to which dwim_ref() will happily say Ok, and you end up
saying "branch 'v1.5.6' (early part)", don't you?
> +static int read_tree_trivial(unsigned char *common, unsigned char *head,
> + unsigned char *one)
> +{
> + int i, nr_trees = 0;
> + struct tree *trees[MAX_UNPACK_TREES];
> + struct tree_desc t[MAX_UNPACK_TREES];
> + struct unpack_trees_options opts;
> +
> + memset(&opts, 0, sizeof(opts));
> + opts.head_idx = -1;
Is this the correct head_idx value for this three-way merge? I think it
should be 2 but please double check.
> +static int commit_tree_trivial(const char *msg, unsigned const char *tree,
> + struct commit_list *parents, unsigned char *ret)
> +{
> ...
> +}
We may want to have another patch before this one to abstract most of
cmd_commit_tree() out, perhaps?
> +int cmd_merge(int argc, const char **argv, const char *prefix)
> ...
> + /*
> + * This could be traditional "merge <msg> HEAD <commit>..." and
> + * the way we can tell it is to see if the second token is HEAD,
> + * but some people might have misused the interface and used a
> + * committish that is the same as HEAD there instead.
> + * Traditional format never would have "-m" so it is an
> + * additional safety measure to check for it.
> + */
> + strbuf_init(&buf, 0);
> + if (argc > 1) {
> + unsigned char second_sha1[20];
> +
> + if (get_sha1(argv[1], second_sha1))
> + die("Not a valid ref: %s", argv[1]);
> + second_token = lookup_commit_reference_gently(second_sha1, 0);
> + if (!second_token)
> + die("'%s' is not a commit", argv[1]);
Interesting.
This _superficially_ is quite wrong, because the purpose of this part of
the code is to tell if we got old-style invocation, and we should not
barfing merely because what we got is _not_ old-style. If it is not
old-style, then it would be new-style, and the logic to tell if it is
old-style should ideally not have much knowledge about the new-style
invocation to say "hey, that's an incocrrect new-style invocation". By
the way, this part should probably be in a separate function:
static int is_old_style_invocation(int ac, const char **gv);
Old-style invocation of "git merge" (primarily by "git pull") was
to call it as:
git merge "message here" HEAD $commit1 $commit2...
and it checks the second token ("HEAD" in the above, but people can misuse
the interface to name the current branch name). If the second token is
not a ref that resolves to a commit, all you know is that this is _not_ an
old-style invocation, and calling the program with new-style is not a
crime.
The only reason this is wrong only superficially is because new style
invocation would always be:
git merge [options] $commit1 $commit2...
after stripping the options, and these seemingly wrong die() will complain
when you try to create an Octopus with the new-style syntax and the
parameter given as the second remote parent is not a commit. So the logic
is wrong, the fact that the user gets the same error message for incorrect
old-style invocation (perhaps "git merge <msg> HAED $commit") and
incorrect new-style invocation "git merge $commit1 $nonsense" is just an
accident, and the end result does not hurt, but asks for a "Huh? why does
it check and complain only the second parent here but not the first one?".
It is interesting, but feels quite dirty.
> + }
> +
> + if (!have_message && second_token &&
> + !hashcmp(second_token->object.sha1, head)) {
You need to know that resolve_ref() cleared head[] when head_invalid is
true when reading this code to notice that, unlike the previous round of
this patch, it is Ok not to check head_invalid is fine here. I somehow
feel it is an unnecessary optimization/obfuscation.
But once you have "is_old_style_invocation" suggested earlier, this part
would look much cleaner and the above comment would become unnecessary.
> + for (i = 0; i < argc; i++) {
> + struct object *o;
> +
> + o = peel_to_type(argv[i], 0, NULL, OBJ_COMMIT);
> + if (!o)
> + die("%s - not something we can merge", argv[i]);
> + remotes = &commit_list_insert(lookup_commit(o->sha1),
> + remotes)->next;
> +
> + strbuf_addf(&buf, "GITHEAD_%s", sha1_to_hex(o->sha1));
> + setenv(buf.buf, argv[i], 1);
> + strbuf_reset(&buf);
> + }
> +
> + o = peel_to_type(sha1_to_hex(remoteheads->item->object.sha1),
> + 0, NULL, OBJ_COMMIT);
> + if (!o)
> + return 0;
> +
> + if (checkout_fast_forward(head, remoteheads->item->object.sha1))
> + return 0;
When o does not peel well, or checkout_fast_forward() returns failure,
that would be a failure case, wouldn't it? Why return 0?
Maybe you misread "exit" in shell scripts? It does not mean exit(0); it
means "exit with the same exit status as the last command". So
new_head=$(git rev-parse ...) &&
git read-tree -m -u ... &&
finish || exit
will exit non-zero if any of the commands chained by && fails.
> + if (allow_trivial) {
> + /* See if it is really trivial. */
> + git_committer_info(IDENT_ERROR_ON_NO_NAME);
> + printf("Trying really trivial in-index merge...\n");
> + if (!read_tree_trivial(common->item->object.sha1,
> + head, remoteheads->item->object.sha1))
> + return merge_trivial();
> + printf("Nope.\n");
Nicer, much nicer.
> + /*
> + * At this point, we need a real merge. No matter what strategy
> + * we use, it would operate on the index, possibly affecting the
> + * working tree, and when resolved cleanly, have the desired
> + * tree in the index -- this means that the index must be in
> + * sync with the head commit. The strategies are responsible
> + * to ensure this.
> + */
> + if (use_strategies.nr != 1) {
> + /*
> + * Stash away the local changes so that we can try more
> + * than one.
> + */
> + save_state();
> + single_strategy = 0;
> + } else {
> + unlink(git_path("MERGE_STASH"));
> + single_strategy = 1;
I think s/single_strategy/(use_strategies.nr == 1)/ in the remainder of the
code would be taking advantage of working in C ;-)
> + if (ret) {
> + /*
> + * The backend exits with 1 when conflicts are
> + * left to be resolved, with 2 when it does not
> + * handle the given merge at all.
> + */
> + if (ret == 1) {
Probably from here til ...
> + int cnt = 0;
> ...
> + cnt += count_unmerged_entries();
... here should be a separate "evaluate_result()" function.
> + if (best_cnt <= 0 || cnt <= best_cnt) {
> + best_strategy =
> + &use_strategies.items[i];
> + best_cnt = cnt;
> + }
> + }
> + if (merge_was_ok)
> + break;
> + else
> + continue;
> + }
> +
> + /* Automerge succeeded. */
> + write_tree_trivial(result_tree);
> + automerge_was_ok = 1;
> + break;
> + }
The part of the file I did not comment in this message (except for the
"cast" thing) looked straightforward enough. I did not very carefully
hunt for bugs, but I did not see anything obviously wrong.
Thanks.
^ permalink raw reply
* Re: [PATCH 13/13] Build in merge
From: Junio C Hamano @ 2008-06-30 5:40 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Johannes Schindelin, Olivier Marin
In-Reply-To: <20080630013612.GY2058@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
>> > + if (!remote_head)
>> > + die("%s - not something we can merge", argv[0]);
>> > + update_ref("initial pull", "HEAD", remote_head->sha1, NULL, 0,
>> > + DIE_ON_ERR);
>> > + reset_hard(remote_head->sha1, 0);
>> > + return 0;
>>
>> Makes one wonder reset_hard() (aka "read-tree --reset -u HEAD") ever fail
>> and return here (iow, without calling die()). The answer is luckily no
>> in this case, but it is somewhat unnerving to reviewers.
>
> Actually reset_hard does not return if an error occures:
I know that; didn't I already say "Luckily no"? The point was it was not
apparent from the above 6 lines alone.
>> > + for (i = 0; i < use_strategies.nr; i++) {
>> > + if ((unsigned int)use_strategies.items[i].util &
>> > + NO_FAST_FORWARD)
>> > + allow_fast_forward = 0;
>> > + if ((unsigned int)use_strategies.items[i].util & NO_TRIVIAL)
>> > + allow_trivial = 0;
>>
>> Can we abstract out these ugly casts? Any code that use path_list to
>> store anything but list of paths (i.e. some value keyed with string) tends
>> to have this readability issue.
>
> If you don't cast, you can't use the & operator. If I change the
> path_list_item's util to be an unsigned number then I break fast-export.
> I think if we _really_ want to get rid of those casts, we could have
> something like:
No, no, no. That is not what I meant.
The places that use use_strategies in your code knows too much about the
internal implementation detail of path_list, while path_list pretends to
be a general purpose "table keyed with string" facility. The fact is that
the table is not a very useful general purpose abstraction unless you are
pointing at some structures that exist regardless of your use of path_list
(e.g. you have some "struct object" and you hold pointers in a path_list).
It does not work very well as an abstraction for use case like yours.
With something like:
static inline unsigned nth_strategy_flags(struct path_list *s, int nth)
{
return (unsigned) s->items[nth].util;
}
the checks would be more like:
if (nth_strategy_flags(&use_strategies, i) & NO_FAST_FORWARD)
...
or even:
static inline check_nth_strategy_flags(struct path_list_item *i, unsigned flags)
{
return !((unsigned) i->util & flags);
}
if (check_nth_strategy_flags(&use_strategies,items[i], NO_FAST_FORWARD)
...
either of which would be much easier on the eye.
> Actually the shell version did not check here, either, but yes, I would
> have to. Now I do.
The scripted did not have to do so explicitly, as the one before that have
already caught "more than one common" case in the case arm before this
part. It is already known that "have only one common" condition is true
when you reached the corresponding part of the scripted version.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-06-30 5:38 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080630053302.GA23786@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Jun 29, 2008 at 10:31:00PM -0700, Junio C Hamano wrote:
>
>> > Where do we want to take this? The conversation went something like:
>> >
>> > me: here's a patch where we hint about "remote prune"
>> > you: why not just fix the refs, it's no worse than a rewind
>> > me: we kill reflogs, so it is different than a rewind
>> > you: oh, right
>> >
>> > So I'm not sure if that was "Oh, right, it's not a good idea to remove
>> > the conflicting ref" or "Oh, right, but it's probably still fine."
>>
>> It is "Oh right, it is Ok. Let's cook it in 'next', have it in 'master'
>> and then backmerge to 'maint'".
>
> Sorry if I'm being slow, but what is "it" here? The "warning" patch I
> sent, or a to-be-posted patch that deletes the conflicting ref?
Sorry, my fingers outpaced my brain and gave you gibberish.
Oh right, we should hint about "remote prune" and stop there, at
least for now, as it is not nice to just delete the refs and lose
their reflogs without user's consent.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2008-06-30 5:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsk74hgr.fsf@gitster.siamese.dyndns.org>
On Sun, Jun 29, 2008 at 10:31:00PM -0700, Junio C Hamano wrote:
> > Where do we want to take this? The conversation went something like:
> >
> > me: here's a patch where we hint about "remote prune"
> > you: why not just fix the refs, it's no worse than a rewind
> > me: we kill reflogs, so it is different than a rewind
> > you: oh, right
> >
> > So I'm not sure if that was "Oh, right, it's not a good idea to remove
> > the conflicting ref" or "Oh, right, but it's probably still fine."
>
> It is "Oh right, it is Ok. Let's cook it in 'next', have it in 'master'
> and then backmerge to 'maint'".
Sorry if I'm being slow, but what is "it" here? The "warning" patch I
sent, or a to-be-posted patch that deletes the conflicting ref?
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-06-30 5:31 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080630033034.GB18930@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Jun 29, 2008 at 01:55:13AM -0700, Junio C Hamano wrote:
>
>> * jk/maint-fetch-ref-hier (Thu Jun 26 23:59:50 2008 -0400) 1 commit
>> + fetch: report local storage errors in status table
>>
>> When the remote used to have "foo" branch but now has "foo/bar", fetch
>> refuses to delete the existing remote tracking branch "foo" to create a
>> new remote tracking branch "foo/bar", but the error message was
>> confusing.
>
> Where do we want to take this? The conversation went something like:
>
> me: here's a patch where we hint about "remote prune"
> you: why not just fix the refs, it's no worse than a rewind
> me: we kill reflogs, so it is different than a rewind
> you: oh, right
>
> So I'm not sure if that was "Oh, right, it's not a good idea to remove
> the conflicting ref" or "Oh, right, but it's probably still fine."
It is "Oh right, it is Ok. Let's cook it in 'next', have it in 'master'
and then backmerge to 'maint'".
^ permalink raw reply
* Re: diff/Checking out by date specification
From: Jeff King @ 2008-06-30 5:26 UTC (permalink / raw)
To: Toby Corkindale; +Cc: Junio C Hamano, git
In-Reply-To: <20080630052105.GA21954@sigill.intra.peff.net>
On Mon, Jun 30, 2008 at 01:21:05AM -0400, Jeff King wrote:
> Depending on what you want to do, that may be enough. But more likely,
> you are interested in the actual shape of history, so looking at the
> individual commits with something like "gitk --since=2008-01-01
> --until=2008-01-08" is probably going to be more instructive.
Side note: what you may have _really_ wanted was "what is the difference
between what was in Junio's 'master' branch on those dates". I.e.,
looking at the sequence of states at the tip of some "official" git
repo.
In that case, you could get the answer you want by looking in Junio's
reflog. However, that information is not generally available through
git. There is no support for downloading reflogs, and most people don't
have reflogs enabled on their published bare repos. If Junio enabled
reflogs on pushing to his bare repo, then you could manually download
them into your .git/logs/ hierarchy and pretend that that was your
history of your refs.
-Peff
^ permalink raw reply
* Re: diff/Checking out by date specification
From: Jeff King @ 2008-06-30 5:21 UTC (permalink / raw)
To: Toby Corkindale; +Cc: Junio C Hamano, git
In-Reply-To: <48686339.60205@rea-group.com>
On Mon, Jun 30, 2008 at 02:38:17PM +1000, Toby Corkindale wrote:
> I think it would be good if you could give a couple of examples, such as:
> How would I go about checking out the code at the state it was in at,
> say, 2008-01-01?
> Or how one can get a diff between 2008-01-01 and 2008-01-08?
>
> (I note that "git-diff --until=2008-01-08 --since=2008-01-01" fails, as
> does "git-checkout --until=2008-01-08")
That is a little bit trickier, since there is a not a convenient syntax
for selecting a particular revision by commit time. So you _can_ do
this:
git diff \
`git rev-list -1 --until=2008-01-01 HEAD` \
`git rev-list -1 --until=2008-01-08 HEAD`
But that isn't quite what you want either. Remember that history can
follow many branches simultaneously. So what we are saying with
"--until" here is "show me all the commits that happened before this
time", and then we use "-1" to say "pick the first one." So you are
really picking two points in time that are close to what you want, and
then diffing the two states.
Depending on what you want to do, that may be enough. But more likely,
you are interested in the actual shape of history, so looking at the
individual commits with something like "gitk --since=2008-01-01
--until=2008-01-08" is probably going to be more instructive.
-Peff
^ permalink raw reply
* Re: diff/Checking out by date specification
From: Daniel Barkalow @ 2008-06-30 5:09 UTC (permalink / raw)
To: Toby Corkindale; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <48686339.60205@rea-group.com>
On Mon, 30 Jun 2008, Toby Corkindale wrote:
> Jeff King wrote:
> > On Mon, Jun 30, 2008 at 12:24:03PM +1000, Toby Corkindale wrote:
> >
> > > `man git-rev-parse` seems to indicate that one can look at the state of
> > > the repository by date (absolute or relative), and use this for diff or
> > > checkout, etc.
> > > It includes examples such as "{yesterday}" and "{1979-02-26 18:30:00}".
> >
> > It's a little bit more complex than that. The branch@{time} syntax means
> > "what was in _my_ branch at that time". And if you just cloned, your
> > branch doesn't go back very far.
> >
> > If you want to say "find commits that happened before time T", you want
> > --until or --since (or their aliases --before and --after).
> >
> > Would the documentation patch below have helped with the confusion?
>
> Ah, I see.
> Thanks, yes, that would have made the issue clearer.
>
> I think it would be good if you could give a couple of examples, such as:
> How would I go about checking out the code at the state it was in at, say,
> 2008-01-01?
> Or how one can get a diff between 2008-01-01 and 2008-01-08?
That's not well-defined, except in a particular location. It's pretty
likely that there were some changes that were made by different people
late in 2007, and languished in their local repositories, and were never
merged with each other until after some further changes had been made and
the holiday was over. So there isn't a single state of the code as of
2008-01-01 to compare against.
The usual case for wanting the diff between 2008-01-01 and 2008-01-08 is
that you encountered some version on each of those dates, and you want to
know what the difference is between them, and reflogs work for that, but
it's also possible that what you want is the states that were somewhere
else at that point, and I don't think we have a good solution for that
currently unless you can run git commands there to look at the reflog for
that location.
But, in general, with a distributed system like git, you'll do better to
look at the history graph around that time with gitk and find the states
you're actually interested in by other features or a combination of
features.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: diff/Checking out by date specification
From: Toby Corkindale @ 2008-06-30 4:38 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20080630032744.GA18930@sigill.intra.peff.net>
Jeff King wrote:
> On Mon, Jun 30, 2008 at 12:24:03PM +1000, Toby Corkindale wrote:
>
>> `man git-rev-parse` seems to indicate that one can look at the state of
>> the repository by date (absolute or relative), and use this for diff or
>> checkout, etc.
>> It includes examples such as "{yesterday}" and "{1979-02-26 18:30:00}".
>
> It's a little bit more complex than that. The branch@{time} syntax means
> "what was in _my_ branch at that time". And if you just cloned, your
> branch doesn't go back very far.
>
> If you want to say "find commits that happened before time T", you want
> --until or --since (or their aliases --before and --after).
>
> Would the documentation patch below have helped with the confusion?
Ah, I see.
Thanks, yes, that would have made the issue clearer.
I think it would be good if you could give a couple of examples, such as:
How would I go about checking out the code at the state it was in at,
say, 2008-01-01?
Or how one can get a diff between 2008-01-01 and 2008-01-08?
(I note that "git-diff --until=2008-01-08 --since=2008-01-01" fails, as
does "git-checkout --until=2008-01-08")
thanks for the quick response!
-Toby
>
> -- >8 --
> doc/rev-parse: clarify reflog vs --until for specifying revisions
>
> The rev-parse manpage introduces the branch@{date} syntax,
> and mentions the reflog specifically. However, new users may
> not be familiar with the distinction between the reflog and
> the commit date, so let's help them out with a "you may be
> interested in --until" pointer.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Documentation/git-rev-parse.txt | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
> index 9e273bc..59e95ad 100644
> --- a/Documentation/git-rev-parse.txt
> +++ b/Documentation/git-rev-parse.txt
> @@ -184,7 +184,10 @@ blobs contained in a commit.
> second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value
> of the ref at a prior point in time. This suffix may only be
> used immediately following a ref name and the ref must have an
> - existing log ($GIT_DIR/logs/<ref>).
> + existing log ($GIT_DIR/logs/<ref>). Note that this looks up the state
> + of your *local* ref at a given time; e.g., what was in your local
> + `master` branch last week. If you want to look at commits made during
> + certain times, see `--since` and `--until`.
>
> * A ref followed by the suffix '@' with an ordinal specification
> enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify
--
Toby Corkindale
Software developer
w: www.rea-group.com
REA Group refers to realestate.com.au Ltd (ASX:REA)
Warning - This e-mail transmission may contain confidential information.
If you have received this transmission in error, please notify us
immediately on (61 3) 9897 1121 or by reply email to the sender. You
must destroy the e-mail immediately and not use, copy, distribute or
disclose the contents.
^ permalink raw reply
* Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
From: Daniel Barkalow @ 2008-06-30 3:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Pieter de Bie, Git Mailinglist
In-Reply-To: <7vabh390sc.fsf@gitster.siamese.dyndns.org>
On Sun, 29 Jun 2008, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > ... In any case, I don't think "git clone" is at
> > all special with respect to GIT_CONFIG.
>
> I think "git init" and "git clone" are very special with respect to
> GIT_CONFIG.
>
> * When "init" is run to create a new repository and initialize it, the
> user would want the initial set of configuration populated in the
> configuration file _for that repository_. There however may be some
> customization that affects the way how "init" operates, which might be
> taken from $HOME/.gitconfig. The meaning of GIT_CONFIG can get fuzzy
> here. Possibilities:
>
> (1) Instead of $HOME/.gitconfig (or /etc/gitconfig), the user might
> want such customizations to be read from the file specified by
> GIT_CONFIG. But the user wants to make the resulting new
> repository usable without any custom GIT_CONFIG set (i.e. its
> $GIT_DIR/config will be the place the configuration is written).
>
> (2) The user may want to create a new repository that cannot be used
> with GIT_CONFIG (for some strange reason), i.e. no $GIT_DIR/config
> for the repository, and GIT_CONFIG is used to specify where that
> separate configuration file for the new repository is. The way
> "init" operates does not come from that configuration file that is
> to be created but from elsewhere.
>
> * When "clone" is run, the same confusion as initializing "init" applies.
> In addition, custom GIT_CONFIG to read customizations for behaviour of
> "init" and "fetch" that is done internally by "clone" would play larger
> role.
>
> * When "init" is run to reinitialize an existing repository, it is not
> special in any way with respect to GIT_CONFIG, compared to other
> commands. The GIT_CONFIG names the configuration for that existing
> repository, so we read from it and write to it.
>
> I personally think the case (2) is a very narrow special case that I do
> not think of any sane reason to even wanting to do so. IOW, "you _could_
> interpret the presense of GIT_CONFIG that the user may want to do so, but
> why?" (1) is also probably not very sensible but it makes more sense.
>
> I think Dscho's original patch would support the semantics (1) and it is
> probably much saner than (2) which is your version does (if I am reading
> the two patches correctly).
A bit more information on this. There are 3 possible states for
GIT_CONFIG:
(1) Not set; things work normally
(2) Set to ".git/config"; things work normally except that no global or
system config is used
(3) Set to something else; anything expecting to read or write
configuration related to the repo will misbehave
Historically, clone worked entirely in state (2) regardless of what the
user asked for. Everything else left it how the user had it. Dscho's patch
changes it to initialize the repo in state (2) and fetch in state (1),
still ignoring what the user set. My patch changes it to leave it how the
user has it.
Now, clone writes to the config file before reading any configuration, so,
if it's going to write to ".git/config" instead of $GIT_CONFIG, it can't
read from $GIT_CONFIG either. So there's no way (outside of redesigning
config.c) to make GIT_CONFIG useful for "clone" in particular. Other
commands don't clear it, so they just misbehave if it's set. We can be
pretty sure, therefore, that users will put it either in (1) or (if they
want GIT_CONFIG_NO_GLOBAL and don't know about it and aren't worried about
"clone") in (2). So the practical difference between my patch and Dscho's
is that, with mine, ~/.gitconfig would affect the initialization step if
it actually used any config settings.
If you want anything more clever to happen, that requires config.c
changes of some sort to provide a state where it reads some additional
file but writes the repo's usual one, and probably *also* *my* patch, so
that clone doesn't blow away the user's setting before config.c gets it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2008-06-30 3:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod5kd3im.fsf@gitster.siamese.dyndns.org>
On Sun, Jun 29, 2008 at 01:55:13AM -0700, Junio C Hamano wrote:
> * jk/maint-fetch-ref-hier (Thu Jun 26 23:59:50 2008 -0400) 1 commit
> + fetch: report local storage errors in status table
>
> When the remote used to have "foo" branch but now has "foo/bar", fetch
> refuses to delete the existing remote tracking branch "foo" to create a
> new remote tracking branch "foo/bar", but the error message was
> confusing.
Where do we want to take this? The conversation went something like:
me: here's a patch where we hint about "remote prune"
you: why not just fix the refs, it's no worse than a rewind
me: we kill reflogs, so it is different than a rewind
you: oh, right
So I'm not sure if that was "Oh, right, it's not a good idea to remove
the conflicting ref" or "Oh, right, but it's probably still fine."
-Peff
^ permalink raw reply
* Re: diff/Checking out by date specification
From: Jeff King @ 2008-06-30 3:27 UTC (permalink / raw)
To: Toby Corkindale; +Cc: Junio C Hamano, git
In-Reply-To: <486843C3.30402@rea-group.com>
On Mon, Jun 30, 2008 at 12:24:03PM +1000, Toby Corkindale wrote:
> `man git-rev-parse` seems to indicate that one can look at the state of
> the repository by date (absolute or relative), and use this for diff or
> checkout, etc.
> It includes examples such as "{yesterday}" and "{1979-02-26 18:30:00}".
It's a little bit more complex than that. The branch@{time} syntax means
"what was in _my_ branch at that time". And if you just cloned, your
branch doesn't go back very far.
If you want to say "find commits that happened before time T", you want
--until or --since (or their aliases --before and --after).
Would the documentation patch below have helped with the confusion?
-- >8 --
doc/rev-parse: clarify reflog vs --until for specifying revisions
The rev-parse manpage introduces the branch@{date} syntax,
and mentions the reflog specifically. However, new users may
not be familiar with the distinction between the reflog and
the commit date, so let's help them out with a "you may be
interested in --until" pointer.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-rev-parse.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 9e273bc..59e95ad 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -184,7 +184,10 @@ blobs contained in a commit.
second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value
of the ref at a prior point in time. This suffix may only be
used immediately following a ref name and the ref must have an
- existing log ($GIT_DIR/logs/<ref>).
+ existing log ($GIT_DIR/logs/<ref>). Note that this looks up the state
+ of your *local* ref at a given time; e.g., what was in your local
+ `master` branch last week. If you want to look at commits made during
+ certain times, see `--since` and `--until`.
* A ref followed by the suffix '@' with an ordinal specification
enclosed in a brace pair (e.g. '\{1\}', '\{15\}') to specify
--
1.5.6.1.202.g3a23.dirty
^ permalink raw reply related
* Re: Updated Kernel Hacker's guide to git
From: Jeff Garzik @ 2008-06-30 2:51 UTC (permalink / raw)
To: Stefan Richter
Cc: Jan Engelhardt, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <4778D1CD.4020001@s5r6.in-berlin.de>
Stefan Richter wrote:
> Jan Engelhardt wrote:
>>> http://linux.yyz.us/git-howto.html
>> It says
>>
>> """Don't forget to download tags from time to time.
>>
>> git pull only downloads sha1-indexed object data, and the requested
>> remote head. This misses updates to the .git/refs/tags/ and
>> .git/refs/heads/ directories. For tags, run git fetch --tags $URL."""
>>
>> But when I do git pull on a simple tracking tree (e.g. git-clone
>> torvalds/linux-2.6.git; git pull;) it automatically grabs new tags.
>
> A while ago the default behavior of git pull was changed to fetch all
> tags which point to objects that can be reached from any of the tracked
> heads.
This does not work in all cases. When I retrieve the latest kernel, it
downloads the tags:
cd /spare/repo/linux-2.6
git pull
but when I pull those changes into another local repo, the tags do -not-
follow the objects:
cd /spare/repo/misc-2.6
git checkout master
git pull ../linux-2.6
git fetch --tags ../linux-2.6 # still required to this day
Regards,
Jeff
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Jeff Garzik @ 2008-06-30 2:49 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712310349260.2093@fbirervta.pbzchgretzou.qr>
Jan Engelhardt wrote:
> On Dec 23 2007 06:13, Jeff Garzik wrote:
>> Another year, another update! :)
>>
>> The kernel hacker's guide to git has received some updates:
>>
>> http://linux.yyz.us/git-howto.html
>>
>
> It says
>
> """Don't forget to download tags from time to time.
>
> git pull only downloads sha1-indexed object data, and the requested
> remote head. This misses updates to the .git/refs/tags/ and
> .git/refs/heads/ directories. For tags, run git fetch --tags $URL."""
>
>
> But when I do git pull on a simple tracking tree (e.g. git-clone
> torvalds/linux-2.6.git; git pull;) it automatically grabs new tags.
Unfortunately tags are not copied in all cases. To this day, I still
have to 'git fetch --tags', generally when pulling from one local repo
into another. It's annoying that tags don't follow objects, when pulled.
Jeff
^ permalink raw reply
* diff/Checking out by date specification
From: Toby Corkindale @ 2008-06-30 2:24 UTC (permalink / raw)
To: git
Hi,
`man git-rev-parse` seems to indicate that one can look at the state of
the repository by date (absolute or relative), and use this for diff or
checkout, etc.
It includes examples such as "{yesterday}" and "{1979-02-26 18:30:00}".
I'm struggling to get this to work in real life with cloned
repositories, as I receive an error that the log only goes back to
whenever I cloned the repository.
Is there a way to make this operate upon the remote log?
Eg:
$ git clone git://git.kernel.org/pub/scm/git/git.git
$ cd git
$ git diff "@{yesterday}"
warning: Log for '' only goes back to Mon, 30 Jun 2008 12:22:52 +1000.
fatal: bad object @{yesterday}
Cheers,
Toby
--
Toby Corkindale
Software developer
w: www.rea-group.com
REA Group refers to realestate.com.au Ltd (ASX:REA)
Warning - This e-mail transmission may contain confidential information.
If you have received this transmission in error, please notify us
immediately on (61 3) 9897 1121 or by reply email to the sender. You
must destroy the e-mail immediately and not use, copy, distribute or
disclose the contents.
^ permalink raw reply
* Re: [RFC/PATCH] Documentation: Don't assume git-sh-setup and git-parse-remote are in the PATH
From: Jonathan Nieder @ 2008-06-30 2:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alex Riesen, Jeff King
In-Reply-To: <7vbq1kawje.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> jrnieder@uchicago.edu writes:
>
>> [patch to use . "$(git --exec-path)/git-{parse-remote,sh-setup}"
>> instead of assuming they are in PATH]
>>
>> Junio: I stole the commit message from you. I hope you don't mind.
>
> I don't, but reading the script again, I suspect it is not clear enough
> that the user is also responsible for setting up GIT_DIR appropriately
> before using it, perhaps by sourcing git-sh-setup. We probably would want
> to add it in a separate patch.
Doesn't git-parse-remote.sh begin
GIT_DIR=$(git rev-parse --git-dir 2>/dev/null) || :;
? And I don't imagine we want people to source git-sh-setup before
sourcing git-sh-setup...
Confused,
Jonathan
^ 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