* Re: [PATCH v2] msvc: Fix compilation error due to missing mktemp() declaration
From: Junio C Hamano @ 2011-01-11 20:14 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list, kusmabite
In-Reply-To: <4D2CA28A.4070401@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> ping... Are there any remaining concerns regarding this patch?
I dunno. Is everybody on the Windows side happy with it?
^ permalink raw reply
* Re: [PATCH] fast-import: Don't barf if import-marks file is missing
From: Junio C Hamano @ 2011-01-11 20:05 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Jonathan Nieder, Git List
In-Reply-To: <1294766058-29739-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> The --import-marks option used to barf when the specified marks file
> doesn't exist. Change its meaning to "read marks file if it exists" so
> that callers don't have to handle bootstraping as a special case.
It is very plausible that people other than you are relying on "barf if it
does not exist" semantics, and the above does not justify breaking their
workflow.
I'd suggest making this an optional feature.
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Jeff King @ 2011-01-11 20:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Kleine-König, git
In-Reply-To: <20110111192020.GA15608@sigill.intra.peff.net>
On Tue, Jan 11, 2011 at 02:20:20PM -0500, Jeff King wrote:
> Hmm. One other thing to note on these ambiguity tests.
I was starting to get confused with all the back-and-forth, so here is a
squashed patch that contains everything discussed so far: my original
tests, your squashed patches, my test fixups, and the less-subtle
resolve_ref thing.
I didn't bisect the breakage, so I'm not sure how far back it goes. But
this is potentially maint-worthy.
This doesn't include any tests or fixes for "git checkout -b newbranch
ambiguous". I'll work on that separately as a patch on top.
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Subject: [PATCH] checkout: fix bug with ambiguous refs
The usual dwim_ref lookup prefers tags to branches. Because
checkout primarily works on branches, though, we switch that
behavior to prefer branches.
However, there was a bug in the implementation in which we
used lookup_commit_reference (which used the regular lookup
rules) to get the actual commit to checkout. Checking out an
ambiguous ref therefore ended up putting us in an extremely
broken state in which we wrote the branch ref into HEAD, but
actually checked out the tree for the tag.
This patch fixes the bug by always attempting to pull the
commit to be checked out from the branch-ified version of
the name we were given.
Patch by Junio, tests and commit message from Jeff King.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/checkout.c | 23 ++++++++------
t/t2019-checkout-amiguous-ref.sh | 59 ++++++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+), 10 deletions(-)
create mode 100755 t/t2019-checkout-amiguous-ref.sh
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 757f9a0..d3cfaf0 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -678,7 +678,7 @@ static const char *unique_tracking_name(const char *name)
int cmd_checkout(int argc, const char **argv, const char *prefix)
{
struct checkout_opts opts;
- unsigned char rev[20];
+ unsigned char rev[20], branch_rev[20];
const char *arg;
struct branch_info new;
struct tree *source_tree = NULL;
@@ -832,18 +832,21 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
argc--;
new.name = arg;
- if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
- setup_branch_path(&new);
+ setup_branch_path(&new);
- if ((check_ref_format(new.path) == CHECK_REF_FORMAT_OK) &&
- resolve_ref(new.path, rev, 1, NULL))
- ;
- else
- new.path = NULL;
+ if (check_ref_format(new.path) == CHECK_REF_FORMAT_OK &&
+ resolve_ref(new.path, branch_rev, 1, NULL))
+ hashcpy(rev, branch_rev);
+ else
+ new.path = NULL; /* not an existing branch */
+
+ if (!(new.commit = lookup_commit_reference_gently(rev, 1))) {
+ /* not a commit */
+ source_tree = parse_tree_indirect(rev);
+ } else {
parse_commit(new.commit);
source_tree = new.commit->tree;
- } else
- source_tree = parse_tree_indirect(rev);
+ }
if (!source_tree) /* case (1): want a tree */
die("reference is not a tree: %s", arg);
diff --git a/t/t2019-checkout-amiguous-ref.sh b/t/t2019-checkout-amiguous-ref.sh
new file mode 100755
index 0000000..943541d
--- /dev/null
+++ b/t/t2019-checkout-amiguous-ref.sh
@@ -0,0 +1,59 @@
+#!/bin/sh
+
+test_description='checkout handling of ambiguous (branch/tag) refs'
+. ./test-lib.sh
+
+test_expect_success 'setup ambiguous refs' '
+ test_commit branch file &&
+ git branch ambiguity &&
+ git branch vagueness &&
+ test_commit tag file &&
+ git tag ambiguity &&
+ git tag vagueness HEAD:file &&
+ test_commit other file
+'
+
+test_expect_success 'checkout ambiguous ref succeeds' '
+ git checkout ambiguity >stdout 2>stderr
+'
+
+test_expect_success 'checkout produces ambiguity warning' '
+ grep "warning.*ambiguous" stderr
+'
+
+test_expect_success 'checkout chooses branch over tag' '
+ echo refs/heads/ambiguity >expect &&
+ git symbolic-ref HEAD >actual &&
+ test_cmp expect actual &&
+ echo branch >expect &&
+ test_cmp expect file
+'
+
+test_expect_success 'checkout reports switch to branch' '
+ grep "Switched to branch" stderr &&
+ ! grep "^HEAD is now at" stderr
+'
+
+test_expect_success 'checkout vague ref succeeds' '
+ git checkout vagueness >stdout 2>stderr &&
+ test_set_prereq VAGUENESS_SUCCESS
+'
+
+test_expect_success VAGUENESS_SUCCESS 'checkout produces ambiguity warning' '
+ grep "warning.*ambiguous" stderr
+'
+
+test_expect_success VAGUENESS_SUCCESS 'checkout chooses branch over tag' '
+ echo refs/heads/vagueness >expect &&
+ git symbolic-ref HEAD >actual &&
+ test_cmp expect actual &&
+ echo branch >expect &&
+ test_cmp expect file
+'
+
+test_expect_success VAGUENESS_SUCCESS 'checkout reports switch to branch' '
+ grep "Switched to branch" stderr &&
+ ! grep "^HEAD is now at" stderr
+'
+
+test_done
--
1.7.3.5.4.g0dc52
^ permalink raw reply related
* Re: clone breaks replace
From: Johannes Sixt @ 2011-01-11 20:00 UTC (permalink / raw)
To: Jeff King
Cc: Phillip Susi, Jonathan Nieder, git, Christian Couder,
Stephen Bash
In-Reply-To: <20110111195107.GA18714@sigill.intra.peff.net>
On Dienstag, 11. Januar 2011, Jeff King wrote:
> I think you missed the first part of this discussion. Phillip is
> proposing that it should, and I am arguing against it.
You're right, sorry for the noise. Now I understand this three-word-subject.
-- Hannes
^ permalink raw reply
* Re: clone breaks replace
From: Jeff King @ 2011-01-11 19:51 UTC (permalink / raw)
To: Johannes Sixt
Cc: Phillip Susi, Jonathan Nieder, git, Christian Couder,
Stephen Bash
In-Reply-To: <201101112048.57326.j6t@kdbg.org>
On Tue, Jan 11, 2011 at 08:48:57PM +0100, Johannes Sixt wrote:
> On Dienstag, 11. Januar 2011, Jeff King wrote:
> > On Tue, Jan 11, 2011 at 10:24:01AM -0500, Phillip Susi wrote:
> > > Yes, either a new branch or separate historical repository could be
> > > published to pull the original history from, or git would need to pass
> > > the --no-replace-objects flag to git-upload-pack on the server, causing
> > > it to ignore the replace and send the original history.
> >
> > AFAIK, git can't pass --no-replace-objects to the server over git:// (or
> > smart http). You would need a protocol extension.
>
> Why would you have to? git-upload-pack never looks at replacement objects.
I think you missed the first part of this discussion. Phillip is
proposing that it should, and I am arguing against it.
-Peff
^ permalink raw reply
* Re[2]: [PATCH] userdiff: match Pascal class methods
From: Алексей Шумкин @ 2011-01-11 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vipxv45ky.fsf@alter.siamese.dyndns.org>
JCH> Alexey Shumkin <zapped@mail.ru> writes:
>> Class declarations were already covered by the second pattern, but class methods have the 'class' keyword in front too. Account for it.
JCH> Too long a line (which I could re-wrap locally but I'd rather not be in
JCH> the business of doing that for everybody).
Ooh, I'm sorry
>> PATTERNS("pascal",
>> - "^((procedure|function|constructor|destructor|interface|"
>> + "^(((class[ \t]+)?(procedure|function)|constructor|destructor|interface|"
>> "implementation|initialization|finalization)[ \t]*.*)$"
JCH> Earlier we took "^procedure frotz", "^function frotz", etc. and now we
JCH> also take "^class procedure frotz", "^class function frotz", but not
JCH> "^class constructor frotz"---am I reading the patterns correctly?
Yes, you're reading correctly. 'class' keyword might precede only
'procedure' or 'function' keyword but not the other ones
^ permalink raw reply
* Re: clone breaks replace
From: Johannes Sixt @ 2011-01-11 19:48 UTC (permalink / raw)
To: Jeff King
Cc: Phillip Susi, Jonathan Nieder, git, Christian Couder,
Stephen Bash
In-Reply-To: <20110111173922.GB1833@sigill.intra.peff.net>
On Dienstag, 11. Januar 2011, Jeff King wrote:
> On Tue, Jan 11, 2011 at 10:24:01AM -0500, Phillip Susi wrote:
> > Yes, either a new branch or separate historical repository could be
> > published to pull the original history from, or git would need to pass
> > the --no-replace-objects flag to git-upload-pack on the server, causing
> > it to ignore the replace and send the original history.
>
> AFAIK, git can't pass --no-replace-objects to the server over git:// (or
> smart http). You would need a protocol extension.
Why would you have to? git-upload-pack never looks at replacement objects.
> And here's another corner case I thought of:
>
> Suppose you have some server S1 with this history:
>
> A--B--C--D
>
> and a replace object truncating history to look like:
>
> B'--C--D
>
> You clone from S1 and have only commits B', C, and D (or maybe even B,
> depending on the implementation). But definitely not A, nor its
> associated tree and blobs.
Why so? Cloning transfers the database using git-upload-pack,
git-pack-objects, git-index-pack, and git-unpack-objects. All of them have
object replacements disabled. (And AFAICS, there is no possibility to
*enable* it.)
Therefore, after cloning you get
A--B--C--D
and perhaps also the replacement object B'.
Hint: git grep read_replace_refs
-- Hannes
^ permalink raw reply
* Re: git-repack & big files
From: Phillip Susi @ 2011-01-11 19:48 UTC (permalink / raw)
To: Pietro Battiston; +Cc: git
In-Reply-To: <1294772603.3435.67.camel@voubian.casa>
On 1/11/2011 2:03 PM, Pietro Battiston wrote:
> That's unfortunate - I think I prefer to split my mailboxes than to
> loose many of the nice features git provides. But thanks a lot for the
> suggestion.
I'm curious what features of git you find helpful for this purpose. The
history log doesn't seem useful at all. Generally mail is only added,
and sometimes deleted, never changed, so it also does not seem useful to
keep multiple revisions. If you really want that though, rdiff-backup
will do that and keep the old revisions delta compressed.
I use Maildir instead of mbox and do a nightly incremental backup of the
whole system with dump, so any mail I might loose by accident I can pull
from the backup if it is older than a day, and I never delete mail.
^ permalink raw reply
* Re: clone breaks replace
From: Christian Couder @ 2011-01-11 19:32 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jeff King, Junio C Hamano, Phillip Susi, git, Stephen Bash
In-Reply-To: <20110111175621.GC15133@burratino>
Hi,
On Tuesday 11 January 2011 18:56:21 Jonathan Nieder wrote:
>
> A potential usability enhancement might be to allow additional
> replacement hierarchies to be requested on a per command basis, like
>
> GIT_REPLACE_REFS=refs/remotes/origin/views/2009 gitk --all
>
> along the lines of GIT_NOTES_REF.
Yes, it should not be much work to implement GIT_REPLACE_REFS like the above,
but I think it should accept a list of ref directories, for example:
GIT_REPLACE _REFS=".:bisect:refs/remotes/origin/views/2009"
Best regards,
Christian.
^ permalink raw reply
* Re: JGIT newbie question
From: Shawn Pearce @ 2011-01-11 19:30 UTC (permalink / raw)
To: sundarbun; +Cc: git, jgit-dev
In-Reply-To: <1294771910028-5911913.post@n2.nabble.com>
On Tue, Jan 11, 2011 at 10:51, sundarbun <sundarbun@yahoo.com> wrote:
> I am looking into using JGit from Java
JGit related questions are probably better directed to the
jgit-dev@eclipse.org mailing list, as that is the list most of the
JGit contributors monitor and answer questions on. The project is
hosted at http://www.eclipse.org/jgit/ so you may find more resources
there too, including the latest 0.10.1 release.
> to get some files from source control
> for an application that runs on AWS.
> We currently use SVNKit and it seems to work fine. We recently made the
> switch to git and I am having a hard time finding a sample that allows one
> to
> (a) init or create a ocal repo with my credentials and path to the tree that
> I am interested in...
Use the Git object in the org.eclipse.jgit.api package. There is an
init method that can create a new repository at the given directory.
> (a) get a bunch of files from my remote repo
Try the checkout() method on the Git object.
> (b) commit any changes back in...
Try the commit() method on the Git object.
But if you want to avoid using the working directory, you'll need to
go through a much lower-level API, setting up your own DirCache, and
using an ObjectReader and ObjectInserter to interact with the
Repository class. Doing this requires some knowledge of the basic Git
data model (commits, trees, blobs).
--
Shawn.
^ permalink raw reply
* Re: git-archive and core.eol
From: René Scharfe @ 2011-01-11 19:24 UTC (permalink / raw)
To: kusmabite; +Cc: Git Mailing List, msysGit, eyvind.bernhardsen
In-Reply-To: <AANLkTi=WyzVzPkhOAMC2A8Dd=Zj_P-7YMVP-GaUz0-Qm@mail.gmail.com>
Am 10.01.2011 14:00, schrieb Erik Faye-Lund:
> On Mon, Jan 10, 2011 at 1:11 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>> test. So now I've got to figure out what is different between your
>> test and mine. Perhaps I misdiagnosed to begin with?
>>
>
> No, it doesn't quite seem like I misdiagnosed, but your test had
> different expectations than I have after reading the documentation. I
> expected core.autocrlf=true + core.eol=lf to pretty much be identical
> to core.autocrlf=false, but only because LF->LF conversion is a NOP.
>
> 'core.autocrlf' is documented as meaning the same as setting the
> 'text' attribute to 'auto' for all files, plus "files that contain
> CRLF in the repository will not be touched". I figured that last part
> shouldn't affect me as I only had LFs in the repository.
>
> If I disable core.autocrlf, I get what I want (no matter what I set
> core.eol to, it seems). But I still don't understand WHY
> core.autocrlf=true + core.eol=lf outputs CRLF.
>
> It seems to me that there's a big gap between what the documentation
> claims and what actually happens here.
Having stared a bit at the test results, I think you only need to accept
that setting core.autocrlf=true during output overrules any core.eol
setting and gives you CRLF line endings no matter what's in the repository.
core.autocrlf=input overrules core.eol, too, in that no output conversion
takes place, no matter what the latter is set to.
I don't know if this is intended or even useful -- I don't use the options
myself, so I don't grok the possible use cases. Perhaps something like
this can help? Or do we need code changes?
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ff7c225..6082f77 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -202,7 +202,7 @@ core.eol::
'lf', 'crlf' and 'native', which uses the platform's native
line ending. The default value is `native`. See
linkgit:gitattributes[5] for more information on end-of-line
- conversion.
+ conversion. This variable is ignored if `core.autocrlf` is set.
core.safecrlf::
If true, makes git check if converting `CRLF` is reversible when
@@ -257,7 +257,8 @@ core.autocrlf::
setting if you want to have `CRLF` line endings in your
working directory even though the repository does not have
normalized line endings. This variable can be set to 'input',
- in which case no output conversion is performed.
+ in which case no output conversion is performed. This variable
+ overrules `core.eol`.
core.symlinks::
If false, symbolic links are checked out as small plain files that
^ permalink raw reply related
* Re: bug? in checkout with ambiguous refnames
From: Jeff King @ 2011-01-11 19:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Kleine-König, git
In-Reply-To: <20110111065509.GG10094@sigill.intra.peff.net>
On Tue, Jan 11, 2011 at 01:55:09AM -0500, Jeff King wrote:
> On Fri, Jan 07, 2011 at 02:54:17PM -0500, Jeff King wrote:
>
> > +test_expect_success 'checkout reports switch to detached HEAD' '
> > + grep "Switched to branch" stderr &&
> > + ! grep "^HEAD is now at" stderr
>
> Junio, one minor fixup here. The test is correct, but the description
> should read "checkout reports switch to branch", not "...detached HEAD".
Hmm. One other thing to note on these ambiguity tests. Apparently we did
already have a test for this in t7201 (which should perhaps be renamed
into the t20* area with the other checkout tests), but it was passing.
The problem is that the current behavior is way more broken than just
"accidentally choose tag over branch". It actually writes the branch ref
into HEAD, but checks out the tree from the tag! The test in 7201 only
checks the former, but our new test checked the latter.
Probably we should be checking both, just to be sure (and yes, with your
patch it does the right thing):
diff --git a/t/t2019-checkout-amiguous-ref.sh b/t/t2019-checkout-amiguous-ref.sh
index e2b330b..606081b 100755
--- a/t/t2019-checkout-amiguous-ref.sh
+++ b/t/t2019-checkout-amiguous-ref.sh
@@ -22,6 +22,9 @@ test_expect_success 'checkout produces ambiguity warning' '
'
test_expect_success 'checkout chooses branch over tag' '
+ echo refs/heads/ambiguity >expect &&
+ git symbolic-ref HEAD >actual &&
+ test_cmp expect actual &&
echo branch >expect &&
test_cmp expect file
'
@@ -41,6 +44,9 @@ test_expect_success VAGUENESS_SUCCESS 'checkout produces ambiguity warning' '
'
test_expect_success VAGUENESS_SUCCESS 'checkout chooses branch over tag' '
+ echo refs/heads/vagueness >expect &&
+ git symbolic-ref HEAD >actual &&
+ test_cmp expect actual &&
echo branch >expect &&
test_cmp expect file
'
^ permalink raw reply related
* Re: [PATCH] userdiff: match Pascal class methods
From: Junio C Hamano @ 2011-01-11 19:13 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <1294736039-5912-1-git-send-email-zapped@mail.ru>
Alexey Shumkin <zapped@mail.ru> writes:
> Class declarations were already covered by the second pattern, but class methods have the 'class' keyword in front too. Account for it.
Too long a line (which I could re-wrap locally but I'd rather not be in
the business of doing that for everybody).
> PATTERNS("pascal",
> - "^((procedure|function|constructor|destructor|interface|"
> + "^(((class[ \t]+)?(procedure|function)|constructor|destructor|interface|"
> "implementation|initialization|finalization)[ \t]*.*)$"
Earlier we took "^procedure frotz", "^function frotz", etc. and now we
also take "^class procedure frotz", "^class function frotz", but not
"^class constructor frotz"---am I reading the patterns correctly?
^ permalink raw reply
* Re: git-repack & big files
From: Stephen Bash @ 2011-01-11 19:12 UTC (permalink / raw)
To: Pietro Battiston; +Cc: git, Phillip Susi
In-Reply-To: <1294772603.3435.67.camel@voubian.casa>
----- Original Message -----
> From: "Pietro Battiston" <me@pietrobattiston.it>
> To: "Phillip Susi" <psusi@cfl.rr.com>
> Sent: Tuesday, January 11, 2011 2:03:23 PM
> Subject: Re: git-repack & big files
>
> > > 2) do I have any hope that in one way or another my 500+ MB
> > > mailboxes
> > > with relatively small changes over time are archived smartly
> > > (=diffs) by
> > > git at the current state of development? If I understand
> > > correctly, the
> > > project git-bigfiles³ would just "solve" my problems by not making
> > > differences of big files.
> >
> > Git is not a backup tool. You should use rsync rdiff-backup instead.
>
> That's unfortunate - I think I prefer to split my mailboxes than to
> loose many of the nice features git provides. But thanks a lot for the
> suggestion.
Off topic: Do you have the option to change to a solution that uses MailDir as the storage format rather than mbox?
http://en.wikipedia.org/wiki/Maildir
Stephen
^ permalink raw reply
* Re: git-repack & big files
From: Pietro Battiston @ 2011-01-11 19:03 UTC (permalink / raw)
To: Phillip Susi; +Cc: git
In-Reply-To: <4D2C7AA9.1020506@cfl.rr.com>
Il giorno mar, 11/01/2011 alle 10.43 -0500, Phillip Susi ha scritto:
> On 1/11/2011 2:37 AM, Pietro Battiston wrote:
> > Since it perfectly does what it is not optimized to do... I then wonder
> > when it does not do what it declares: if I run git-repack² with the
> > parameter --window-memory set to, for instance, "100m", it takes
> > hundreds and hundreds of MB of memory until it runs out of memory, fails
> > a malloc and aborts.
> > So, two questions:
>
> --window-memory reduces the window size to try and stay under the limit,
> but the window size can not be reduced below 1.
OK, I think I understood. Still, I don't think there are many doubts
that the documentation is misleading when it says "the window size will
dynamically scale down so as to not take up more than N bytes in
memory". That's all.
> > 2) do I have any hope that in one way or another my 500+ MB mailboxes
> > with relatively small changes over time are archived smartly (=diffs) by
> > git at the current state of development? If I understand correctly, the
> > project git-bigfiles³ would just "solve" my problems by not making
> > differences of big files.
>
> Git is not a backup tool. You should use rsync rdiff-backup instead.
That's unfortunate - I think I prefer to split my mailboxes than to
loose many of the nice features git provides. But thanks a lot for the
suggestion.
Pietro
^ permalink raw reply
* JGIT newbie question
From: sundarbun @ 2011-01-11 18:51 UTC (permalink / raw)
To: git
Hi All:
I am looking into using JGit from Java to get some files from source control
for an application that runs on AWS.
We currently use SVNKit and it seems to work fine. We recently made the
switch to git and I am having a hard time finding a sample that allows one
to
(a) init or create a ocal repo with my credentials and path to the tree that
I am interested in...
(a) get a bunch of files from my remote repo
(b) commit any changes back in...
I have searched through this list and have not had any luck.
If there is someone out there that can help me that would be much
appreciated.
thanks!
Sundarbun
--
View this message in context: http://git.661346.n2.nabble.com/JGIT-newbie-question-tp5911913p5911913.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] Documentation/rev-parse: --verify does not check existence
From: Thomas Rast @ 2011-01-11 18:51 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Zachery Hostens
Rather counterintuitively,
$ git rev-parse --verify aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
does *not* fail. The check is based solely on whether we can come up
with something that "looks like" a SHA1, not whether the object
actually exists. To wit:
# this cannot be done with update-ref as that *does* check
$ echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa > .git/refs/heads/nonexistent
$ git rev-parse --verify nonexistent
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Note that the commit message of 79162bb makes clear that this is
exactly the intended behaviour:
git-rev-parse: Allow a "zeroth" parent of a commit - the commit itself.
This sounds nonsensical, but it's useful to make sure that the result is
a commit.
[...]
Also, since the "parent" code will actually parse the commit, this,
together with the "--verify" flag, will verify not only that the result
is a single SHA1, but will also have verified that it's a proper commit
that we can see.
Document this clearly in the description for --verify.
Furthermore the second item in EXAMPLES
* Print the commit object name from the revision in the $REV shell variable:
seems to imply that rev-parse should actually check that the object
exists *and* is a commit, when in reality it does neither. We could
suggest the ^0 trick alluded to above, but instead document the more
verbose (and clear)
$ git rev-parse --verify "$REV^{commit}"
Observe that if you ran
$ git rev-parse --verify "nonexistent^{commit}"
after the above setup, the failure would come from the ^{} peeling
operator and not from --verify.
Noticed-by: Zachery Hostens <zacheryph@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-rev-parse.txt | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index ff23cb0..779fa87 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -59,8 +59,9 @@ OPTIONS
instead.
--verify::
- The parameter given must be usable as a single, valid
- object name. Otherwise barf and abort.
+ The parameter must either be formed like an object name, or
+ dereference to an object name. This does 'not' verify that
+ the object actually exists! See EXAMPLES below.
-q::
--quiet::
@@ -292,21 +293,31 @@ EXAMPLES
$ git rev-parse --verify HEAD
------------
-* Print the commit object name from the revision in the $REV shell variable:
+* Print the object name from the revision in the $REV shell variable:
+
------------
$ git rev-parse --verify $REV
------------
+
-This will error out if $REV is empty or not a valid revision.
+This will error out if $REV does not dereference to a well-formed
+object name (i.e., SHA1).
-* Same as above:
+* Same as above, but also verify that the object exists and is a commit:
++
+------------
+$ git rev-parse --verify "$REV^{commit}"
+------------
++
+This works because the `{caret}\{commit\}` peeling operator will fail
+unless the object exists and can be peeled into a commit.
+
+* Print the object name from $REV, but default to master:
+
------------
$ git rev-parse --default master --verify $REV
------------
+
-but if $REV is empty, the commit object name from master will be printed.
+If $REV is empty, the commit object name from master will be printed.
Author
--
1.7.4.rc1.309.g58aa0
^ permalink raw reply related
* Re: clone breaks replace
From: Phillip Susi @ 2011-01-11 18:42 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jeff King, git, Christian Couder, Stephen Bash
In-Reply-To: <20110111182225.GE15133@burratino>
On 1/11/2011 1:22 PM, Jonathan Nieder wrote:
>> 1) Those tracking your repo don't have breakage when they next fetch
>> because the chain of commits they were tracking has been destroyed and
>> replaced by a completely different one.
>
> This does not require transport respecting replacements. Just start
> a new line of history and teach "git pull" to pull replacement refs
> first when requested in the refspec.
That's what I've been saying. My statement that you quote above is
stating why git replace is better than git filter-branch.
>> 2) It is obvious when a replace has been done, and the original is
>> still available. This is good for auditing and traceability. Paper
>> trails are good.
>
> With the method you are suggesting, others do _not_ always have the
> original still available. After I fetch from you with
> --respect-hard-replacements, then while I am on an airplane I will
> have this hard replacement ref staring at me that I cannot remove.
They may not have it in their local repository, but it is clear that
there IS an original history, and the replace record comment should tell
them from where they can fetch it, and those tracking the repository
before the replace was added already have it.
Using filter-branch on the other hand, is a sort of dirty hack that
violates the integrity constrains normally in place, and can leave you
with a history that has no indication that there ever was more.
> If the original goes missing or gets corrupted on the few machines
> that had it, the hard replacement ref is permanent.
I think it goes without saying that if you loose part of the repository,
and there are no other copies, then you have lost part of the repository.
> If the modified history is much shorter than the original (as in the
> use case you described), would building it really take so much CPU and
> I/O? Moreover, is the extra CPU time to keep checking all the
> replacements on the client side worth saving that one-time CPU time
> expenditure on the server?
It would take more than just inserting the replace record. I'm not sure
what you mean by "keep checking all the replacements on the client side".
^ permalink raw reply
* Re: [PATCH] svndump.c: Fix a printf format compiler warning
From: Jonathan Nieder @ 2011-01-11 18:39 UTC (permalink / raw)
To: Ramsay Jones
Cc: Junio C Hamano, GIT Mailing-list, David Barr,
Ramkumar Ramachandra
In-Reply-To: <4D2C9EB1.2050100@ramsay1.demon.co.uk>
Ramsay Jones wrote:
> --- a/vcs-svn/svndump.c
> +++ b/vcs-svn/svndump.c
> @@ -211,7 +211,7 @@ void svndump_read(const char *url)
> if (key == keys.svn_fs_dump_format_version) {
> dump_ctx.version = atoi(val);
> if (dump_ctx.version > 2)
> - die("expected svn dump format version <= 2, found %d",
> + die("expected svn dump format version <= 2, found %"PRIu32,
> dump_ctx.version);
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
I think we should just use "int", but that is a wider sweeping change
for another time. Thanks.
Does gcc or sparse provide a warning that could have caught this
mistake?
^ permalink raw reply
* Re: [PATCH v2] msvc: Fix compilation error due to missing mktemp() declaration
From: Ramsay Jones @ 2011-01-11 18:33 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list, kusmabite
In-Reply-To: <4D1F8F06.9090700@ramsay1.demon.co.uk>
Ramsay Jones wrote:
> Commit d1b6e6e (win32: use our own dirent.h, 2010-11-23) removed
> the compat/vcbuild/include/dirent.h compatibility header file.
> This file, among other things, included the <io.h> system header
> file which provides the declaration of the mktemp() function.
>
> In order to fix the compilation error, we add an include directive
> for <io.h> to the compat/mingw.h header.
>
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
>
> Change from v1:
> - add #include to compat/mingw.h rather than compat/vcbuild/include/unistd.h
>
> ATB,
> Ramsay Jones
>
> compat/mingw.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/compat/mingw.h b/compat/mingw.h
> index cafc1eb..1c6bc02 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -1,5 +1,6 @@
> #include <winsock2.h>
> #include <ws2tcpip.h>
> +#include <io.h>
>
> /*
> * things that are not available in header files
ping... Are there any remaining concerns regarding this patch?
Just let me know.
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [RFC/PATCH] t9157-*.sh: Add an svn version check
From: Ramsay Jones @ 2011-01-11 18:21 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: git, Junio C Hamano, stevenrwalter, normalperson
In-Reply-To: <1294478342.2791.4.camel@fixed-disk>
Anders Kaseorg wrote:
> On Thu, 2011-01-06 at 18:29 +0000, Ramsay Jones wrote:
>> +svn_ver="$(svn --version --quiet)"
>> +case $svn_ver in
>> +[0-1].[0-4].[0-6])
>
> Thanks for the patch. Can I suggest the more precise
>
> 0.* | 1.[0-4].*)
>
Heh, yeah that would be more accurate! Thanks. ;-)
Junio, I've attached a fix-up patch below...
ATB,
Ramsay Jones
--- >8 ---
From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Date: Mon, 10 Jan 2011 23:21:26 +0000
Subject: [PATCH] t9157-*.sh: Make the svn version check more precise
These tests require an svn version 1.5 or newer to run correctly.
In particular, all 1.4.x versions and earlier are too old, so fix
up the case label regex to cover this range exactly.
[Fix provided by Anders Kaseorg <andersk@MIT.EDU>]
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
t/t9157-git-svn-fetch-merge.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t9157-git-svn-fetch-merge.sh b/t/t9157-git-svn-fetch-merge.sh
index accf61e..991d2aa 100755
--- a/t/t9157-git-svn-fetch-merge.sh
+++ b/t/t9157-git-svn-fetch-merge.sh
@@ -8,7 +8,7 @@ test_description='git svn merge detection'
svn_ver="$(svn --version --quiet)"
case $svn_ver in
-[0-1].[0-4].[0-6])
+0.* | 1.[0-4].*)
skip_all="skipping git-svn test - SVN too old ($svn_ver)"
test_done
;;
--
1.7.3
^ permalink raw reply related
* [PATCH] svndump.c: Fix a printf format compiler warning
From: Ramsay Jones @ 2011-01-11 18:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list, Jonathan Nieder
In particular, on systems that define uint32_t as an unsigned long,
gcc complains as follows:
CC vcs-svn/svndump.o
vcs-svn/svndump.c: In function `svndump_read':
vcs-svn/svndump.c:215: warning: int format, uint32_t arg (arg 2)
In order to suppress the warning we use the C99 format specifier
macro PRIu32 from <inttypes.h>.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
vcs-svn/svndump.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/vcs-svn/svndump.c b/vcs-svn/svndump.c
index fa580e6..2ad2c30 100644
--- a/vcs-svn/svndump.c
+++ b/vcs-svn/svndump.c
@@ -211,7 +211,7 @@ void svndump_read(const char *url)
if (key == keys.svn_fs_dump_format_version) {
dump_ctx.version = atoi(val);
if (dump_ctx.version > 2)
- die("expected svn dump format version <= 2, found %d",
+ die("expected svn dump format version <= 2, found %"PRIu32,
dump_ctx.version);
} else if (key == keys.uuid) {
dump_ctx.uuid = pool_intern(val);
--
1.7.3
^ permalink raw reply related
* Re: clone breaks replace
From: Jonathan Nieder @ 2011-01-11 18:22 UTC (permalink / raw)
To: Phillip Susi; +Cc: Jeff King, git, Christian Couder, Stephen Bash
In-Reply-To: <4D2C7948.6080304@cfl.rr.com>
Hi,
Thoughts on use cases. Jeff already explained the main protocol
problem to be solved very well (thanks!).
Phillip Susi wrote:
> 1) Those tracking your repo don't have breakage when they next fetch
> because the chain of commits they were tracking has been destroyed and
> replaced by a completely different one.
This does not require transport respecting replacements. Just start
a new line of history and teach "git pull" to pull replacement refs
first when requested in the refspec.
It could work like this:
alice$ git branch historical
alice$ git checkout --orphan newline
alice$ git branch newroot
alice$ ... hack hack hack ...
alice$ git replace newroot historical
alice$ git push world refs/replace/* +HEAD:master
bob$ git remote show origin
URL: git://git.alice.example.com/project.git
Ref specifier: refs/replace/*:refs/replace/* refs/heads/*:refs/remotes/origin/*
HEAD branch: master
Remote branch:
master tracked
Local branch configured for 'git pull':
master merges with remote master
bob$ git pull
remote: Counting objects: 18, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 11 (delta 8), reused 0 (delta 0)
Unpacking objects: 100% (11/11), done.
From git://git.alice.example.com/project.git
* [new replacement] 87a8c7yc65c87c98c87c6a87c8a -> replace/87a8c7yc65c87c98c87c6a87c8a
a78c9df..8c98df9 master -> origin/master
> 2) It is obvious when a replace has been done, and the original is
> still available. This is good for auditing and traceability. Paper
> trails are good.
With the method you are suggesting, others do _not_ always have the
original still available. After I fetch from you with
--respect-hard-replacements, then while I am on an airplane I will
have this hard replacement ref staring at me that I cannot remove.
If the original goes missing or gets corrupted on the few machines
that had it, the hard replacement ref is permanent.
> 3) Inserting a replace record takes a lot less cpu and IO than
> filter-branch rewriting the entire chain.
If the modified history is much shorter than the original (as in the
use case you described), would building it really take so much CPU and
I/O? Moreover, is the extra CPU time to keep checking all the
replacements on the client side worth saving that one-time CPU time
expenditure on the server?
If (and only if) so then I see how that could be an advantage.
Sorry for the longwinded message. Hope that helps,
Jonathan
^ permalink raw reply
* Re: clone breaks replace
From: Jeff King @ 2011-01-11 18:03 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Phillip Susi, git, Christian Couder, Stephen Bash
In-Reply-To: <20110111175621.GC15133@burratino>
On Tue, Jan 11, 2011 at 11:56:21AM -0600, Jonathan Nieder wrote:
> Maybe something like
>
> git fetch origin refs/views/2009/*:refs/replace/*
Heh, yeah, that is much simpler than what I did. :)
> A potential usability enhancement might be to allow additional
> replacement hierarchies to be requested on a per command basis, like
>
> GIT_REPLACE_REFS=refs/remotes/origin/views/2009 gitk --all
>
> along the lines of GIT_NOTES_REF.
Yes, that is a much better solution, IMHO.
-Peff
^ permalink raw reply
* Re: bug? in checkout with ambiguous refnames
From: Jeff King @ 2011-01-11 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Kleine-König, git
In-Reply-To: <7vvd1v4bmt.fsf@alter.siamese.dyndns.org>
On Tue, Jan 11, 2011 at 09:02:18AM -0800, Junio C Hamano wrote:
> > Also, one other question while we are on the subject. I think we all
> > agree that "git checkout $foo" should prefer $foo as a branch. But what
> > about "git checkout -b $branch $start_point"?
>
> That has always been defined as a synonym for
>
> git branch $branch $start_point && git checkout $branch
>
> so $start_point is just a random extended SHA-1 expression.
That's what I would have expected, but I wanted to write a test to make
sure it was the case.
But it's not. Even taking away the die, my second test here fails (built
on top of the three previous commits under discussion):
diff --git a/t/t2019-checkout-amiguous-ref.sh b/t/t2019-checkout-amiguous-ref.sh
index e2b330b..7a6b30b 100755
--- a/t/t2019-checkout-amiguous-ref.sh
+++ b/t/t2019-checkout-amiguous-ref.sh
@@ -50,4 +50,13 @@ test_expect_success VAGUENESS_SUCCESS 'checkout reports switch to detached HEAD'
! grep "^HEAD is now at" stderr
'
+test_expect_success 'new branch from ambiguous start_point works' '
+ git checkout -b newbranch ambiguity
+'
+
+test_expect_success 'checkout chooses tag over branch for start_point' '
+ echo tag >expect &&
+ test_cmp expect file
+'
+
test_done
For bonus fun, doing this:
git branch newbranch ambiguity
git checkout newbranch
_does_ prefer the branch. So it is checkout feeding create_branch() the
modified sha1. I'll see if I can dig further.
-Peff
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox