Re: Build error with current source release

[Dan Johnson]

On Tue, Feb 24, 2015 at 9:23 AM, J. R. Westmoreland  wrote:
> Hi
>
> I hope it is okay to ask such a question here.
>
> I cloned the current source tree and tried to build it and I get the 
> following error.
> Could someone tell me why and if there is an easy way to fix it?
> I’m running on a Mac and everything ran fine up to this error. Is is an 
> excerpt from my typescript file.
>
> Script started on Mon Feb 23 13:43:01 2015
> XMLTO git-add.1
> xmlto: /Users/jr/Documents/projects/git/Documentation/git-add.xml does not 
> validate (status 3)
> xmlto: Fix document syntax or use --skip-validation option
> I/O error : Attempt to load network entity 
> http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
> /Users/jr/Documents/projects/git/Documentation/git-add.xml:2: warning: failed 
> to load external entity 
> "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";
> D DocBook XML V4.5//EN" 
> "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd";

Can you open this link in your browser/do you need a proxy server to
connect to the internet? When I navigate to that URL it loads for me;
I'm wondering if this is a firewall preventing you from accessing the
dtd
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is there way to set git commit --date to be older than 1970 ?

[Dan Johnson]

On Wed, Oct 29, 2014 at 3:31 PM, Junio C Hamano  wrote:
> Peter Vojtek  writes:
>
>> It seems the commit date can be between 1970 and 2100 (on my 32bit
>> linux),...
>
> The underlying data representation records time as number of seconds
> since epoch (1970-01-01).  Theoretically the codepaths that read
> data could consider negative timestamps to represent times before
> the epoch, but in the context of source code control, negative
> values are more likely to be an indication of a bug or a user
> mistake, and I do not think any existing code in Git is prepared to
> pass such a timestamp as a sane value---instead they diagnose a
> failure and die.

I remember a pretty old thread found some success storing timestamps this way:
http://comments.gmane.org/gmane.comp.version-control.git/152433

-Dan Johnson
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Can I fetch an arbitrary commit by sha1?

[Dan Johnson]

On Thu, Oct 2, 2014 at 9:57 AM, Christian Halstrick
 wrote:
> I always though during fetch I have to specify a refspec and that a
> sha1 would not be accepted as a ref. Firing some like 'git fetch
> origin ' should be forbidden. But in fact I see that such a
> fetch command succeeds if you already have that object in your local
> repo.
>
> My question: is it allowed to fetch sha1's? Shouldn't fetch fail if you try 
> it?
>
> See here:
>
>> git clone -q https://github.com/chalstrick/dondalfi.git
>> cd dondalfi
>> git ls-remote
> From https://github.com/chalstrick/dondalfi.git
> ce08dcc41104383f3cca2b95bd41e9054a957f5b HEAD
> af00f4c39bcc8dc29ed8f59a47066d5993c279e4 refs/foo/b1
> ...
>> git show af00f4c39bcc8dc29ed8f59a47066d5993c279e4
> fatal: bad object af00f4c39bcc8dc29ed8f59a47066d5993c279e4
>> git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4
> error: no such remote ref af00f4c39bcc8dc29ed8f59a47066d5993c279e4
>> git fetch origin refs/foo/b1
> remote: Counting objects: 3, done.
> remote: Compressing objects: 100% (2/2), done.
> remote: Total 3 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From https://github.com/chalstrick/dondalfi
>  * branchrefs/foo/b1 -> FETCH_HEAD
>> git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4
> From https://github.com/chalstrick/dondalfi
>  * branchaf00f4c39bcc8dc29ed8f59a47066d5993c279e4 -> FETCH_HEAD

My understanding is that you are allowed to ask for a SHA1, but most
git servers refuse the request. But if you already have the SHA
locally, then git doesn't neet to bother asking the server for it, so
there's no request to be refused.

But it's been a while for me since I did any git development, so it's
possible I missed something.

-Dan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-am: Handle "git show" output correctly

[Dan Johnson]

On Wed, Sep 12, 2012 at 6:19 PM, Junio C Hamano  wrote:
> Dan Johnson  writes:
>
>>> Not really.  If we start encouraging people to use "git show" output
>>> as a kosher input to "am", we would have to support such use
>>> forever, and we end up painting ourselves in a corner we cannot get
>>> out of easily.
>>
>> If git am emitted a warning when accepting "git show" output, it seems
>> like it would support Peter's use-case without encouraging bad
>> behavior?
>
> Are you seriously suggesting me to sell to our users a new feature
> saying "this does not work reliably, we would not recommend using
> it, no, really, don't trust it." from the day the feature is
> introduced, especially when we know it will not be "the feature does
> not work well yet, but it will, we promise" but is "and it may become
> worse in the future"?
>
> I do not see much point in doing that.
Fair enough.

> Besides, what bad behaviour do we avoid from encouraging with such
> an approach?  As Peter said, the problem is not on the part of the
> user who ended up with an output from "git show", when he really
> wants output from "git format-patch".  Giving the warning to the
> user of "git am" is too late.
I was assuming Peter would accept the patch, and reply with a "in the
future, please submit the output of format-patch", thus correcting the
submitter's behavior. This warning would serve someone who did not
know that they wanted the output of format-patch, and hopefully teach
them to send such a reply message.

> I may be able to be pursuaded to swallow a new script somewhere in
> the contrib/ hierarchy that takes a "git show" output and formats it
> to look like "format-patch" output to be fed to "git am".  That way,
> when a user has trouble with its parsing of "git show" output, at
> least we can ask for the output of the format massaging step to help
> us diagnose where the problem lies.

That sounds like a better approach to me as well.

-- 
-Dan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-am: Handle "git show" output correctly

[Dan Johnson]

On Wed, Sep 12, 2012 at 5:18 PM, Junio C Hamano  wrote:
> Peter Jones  writes:
>
>> Well, if that happens, maybe we could regexp match on
>> "[[:alnum:]_-]+: /someexprthatlookslikeanemailaddress/" ?
>
> I doubt that would be even reliably done.
>
>> But we could
>> also just wait to cross that bridge until we get to it?
>
> Not really.  If we start encouraging people to use "git show" output
> as a kosher input to "am", we would have to support such use
> forever, and we end up painting ourselves in a corner we cannot get
> out of easily.

If git am emitted a warning when accepting "git show" output, it seems
like it would support Peter's use-case without encouraging bad
behavior?

-- 
-Dan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Suggestions for "What's cooking"

[Dan Johnson]

On Wed, Sep 12, 2012 at 3:21 PM, Jens Lehmann  wrote:
> Am 11.09.2012 21:41, schrieb Junio C Hamano:
>> Thanks.  I wish all others paid attention to "What's cooking" like
>> you did here.
>>
>> And if it is hard to do so for whatever reason, suggest a better way
>> for me to publish "What's cooking" or an equivalent (I am interested
>> in finding the least bureaucratic way to help people and keep the
>> balls rolling).
>
> I think "What's cooking" makes lots of sense in its current form
> as one gets a very good overview over current development tracks.
>
> Maybe in addition it would be nice to email the author(s) of a
> series when the state changes or new comments are added (and to
> only include the relevant part from "What's cooking" there). For
> me it's not a big problem as I just have to grep for "submodule"
> to get the bits I care about, but I suspect others might have to
> invest much more time to check the current state of their series
> and may appreciate being mailed directly when something happens.
> Opinions?

I was thinking about this earlier. I wondered if it might even be
worth it just to CC the authors of all topics whose status has changed
since the last what's cooking, to make sure that they see updates
pertinent to them. I know that I at least have filters which catch
emails which CC me and promote them to my inbox, so I would see them
more readily.

My normal mode of operation is that when I have a patch in I check all
the "What's cooking" messages as if I was F5-ing a webpage, to follow
its status. Were I CCd on the message, I would be updated whenever the
mail was sent, which I would appreciate. This also has the nice side
effect of updating patch authors who are not subscribed to the list.

On the other hand, its possible some people would find that this
generated lots of noise, and it might also cause unrelated replies to
the "What's Cooking" message to CC all authors.
-- 
-Dan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2] fetch --all: pass --tags/--no-tags through to each remote

[Dan Johnson]

When fetch is invoked with --all, we need to pass the tag-following
preference to each individual fetch; without this, we will always
auto-follow tags, preventing us from fetching the remote tags into a
remote-specific namespace, for example.

Reported-by: Oswald Buddenhagen 
Signed-off-by: Dan Johnson 
---
On Sat, Sep 1, 2012 at 7:22 AM, Jeff King  wrote:
>Hmm. We allocate argv in fetch_multiple like this:
>
>  const char *argv[12] = { "fetch", "--append" };
>
>and then add a bunch of options to it, along with the name of the
>remote. By my count, the current code can hit exactly 12 (including the
>terminating NULL) if all options are set. Your patch would make it
>possible to overflow. Of course, I may be miscounting since it is
>extremely error-prone to figure out the right number by tracing each
>possible conditional.
>
>Maybe we should switch it to a dynamic argv_array? Like this:
>
>  [1/2]: argv-array: add pop function
>  [2/2]: fetch: use argv_array instead of hand-building arrays

This version is re-rolled to be on top of jk/argv-array, avoiding the issue of
the fixed-size array entirely. If needed, we could of course use the old
version of this patch and bump the number, but I figure this is preferable.

I've also added some test cases to cover this behavior, but I'm not entirely
happy with them. I'm not sure if/how we should be testing the pass-through
behavior of various arguments with fetch --all, but if so, we should probably do
so more thouroughly than I have here, but that just seems like combining
together tests of two unrelated things. It might just make more sense to ignore
it and drop these tests, I don't know.

Sorry this took me a few days to send, I just kept not getting around to it.

 builtin/fetch.c   |  4 
 t/t5514-fetch-multiple.sh | 29 +
 2 files changed, 33 insertions(+)

diff --git a/builtin/fetch.c b/builtin/fetch.c
index 6196e91..4494aed 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -858,6 +858,10 @@ static void add_options_to_argv(struct argv_array *argv)
argv_array_push(argv, "--recurse-submodules");
else if (recurse_submodules == RECURSE_SUBMODULES_ON_DEMAND)
argv_array_push(argv, "--recurse-submodules=on-demand");
+   if (tags == TAGS_SET)
+   argv_array_push(argv, "--tags");
+   else if (tags == TAGS_UNSET)
+   argv_array_push(argv, "--no-tags");
if (verbosity >= 2)
argv_array_push(argv, "-v");
if (verbosity >= 1)
diff --git a/t/t5514-fetch-multiple.sh b/t/t5514-fetch-multiple.sh
index 227dd56..cbd2460 100755
--- a/t/t5514-fetch-multiple.sh
+++ b/t/t5514-fetch-multiple.sh
@@ -151,4 +151,33 @@ test_expect_success 'git fetch --multiple (ignoring 
skipFetchAll)' '
 test_cmp ../expect output)
 '
 
+cat > expect << EOF
+EOF
+
+test_expect_success 'git fetch --all --no-tags' '
+   (git clone one test5 &&
+git clone test5 test6 &&
+(cd test5 && git tag test-tag) &&
+cd test6 &&
+git fetch --all --no-tags &&
+git tag >output &&
+test_cmp ../expect output)
+'
+
+cat > expect << EOF
+test-tag
+EOF
+
+test_expect_success 'git fetch --all --tags' '
+   (git clone one test7 &&
+git clone test7 test8 &&
+(cd test7 &&
+  test_commit test-tag &&
+  git reset --hard HEAD^) &&
+cd test8 &&
+git fetch --all --tags &&
+git tag >output &&
+test_cmp ../expect output)
+'
+
 test_done
-- 
1.7.11.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] fetch --all: pass --tags/--no-tags through to each remote

[Dan Johnson]

Reported-by: Oswald Buddenhagen 
Signed-off-by: Dan Johnson 
---

Junio C Hamano  writes:
>Dan Johnson  writes:
>
>> I believe that is bad interaction with "--all" (probably a bug). If I
>> am remembering correctly, --no-tags is internally a per-remote
>> setting, so I'm guessing it's not getting set on all remotes here.
>>
>> I'll look into this more a bit later tonight. Does fetch --no-tags
>> work when you specify a remote?
>
>Thanks.

And here it is. Apparently we just don't pass those options through. I didn't
look to see if there are any other options we should consider passing through;
it's quite possible there are. I also have not written a test to ensure that
this doesn't break in the future. I will hopefully have time for these things
tomorrow. It's getting too late for me to be able to put sentences together,
so hopefully this mail comes out readable ;)

 builtin/fetch.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/builtin/fetch.c b/builtin/fetch.c
index bb9a074..c6bcbdc 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -857,6 +857,10 @@ static void add_options_to_argv(int *argc, const char 
**argv)
argv[(*argc)++] = "--recurse-submodules";
else if (recurse_submodules == RECURSE_SUBMODULES_ON_DEMAND)
argv[(*argc)++] = "--recurse-submodules=on-demand";
+   if (tags == TAGS_SET)
+   argv[(*argc)++] = "--tags";
+   else if (tags == TAGS_UNSET)
+   argv[(*argc)++] = "--no-tags";
if (verbosity >= 2)
argv[(*argc)++] = "-v";
if (verbosity >= 1)
-- 
1.7.11.1.59.gbc9e7dd.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GC of alternate object store

[Dan Johnson]

On Fri, Aug 31, 2012 at 12:26 PM, Oswald Buddenhagen  wrote:
> On Thu, Aug 30, 2012 at 09:03:34AM -0700, Junio C Hamano wrote:
>> Oswald Buddenhagen  writes:
>>
>> >> Doesn't
>> >>
>> >>git push $over_there 'refs/*:refs/remotes/mine/*'
>> >>
>> >> push your tag v1.0 to refs/remotes/mine/v1.0 over there?  The
>> >> version of git I ship seems to do this just fine.
>> >>
>> > as i wrote before, i'm pulling, not pushing,...
>>
>> You would need to decline the automatic tag following with --no-tags
>> (which in hindsight is misnamed; it really means "do not auto-follow
>> tags"), like so:
>>
>>   cd $over_there &&
>> git fetch --no-tags $my_repository 'refs/*:refs/remotes/mine/*'
>>
>> Otherwise, you will also get tags in refs/tags/.
>>
> git seems to be happily ignoring that flag.
>   git fetch --prune --all --no-tags
> still re-populates the tags after i delete them manually.

I believe that is bad interaction with "--all" (probably a bug). If I
am remembering correctly, --no-tags is internally a per-remote
setting, so I'm guessing it's not getting set on all remotes here.

I'll look into this more a bit later tonight. Does fetch --no-tags
work when you specify a remote?

-- 
-Dan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] teach log --no-walk=unsorted, which avoids sorting

[Dan Johnson]

On Wed, Aug 29, 2012 at 2:15 AM, Martin von Zweigbergk
 wrote:
> When 'git log' is passed the --no-walk option, no revision walk takes
> place, naturally. Perhaps somewhat surprisingly, however, the provided
> revisions still get sorted by commit date. So e.g 'git log --no-walk
> HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result
> (unless the two revisions share the commit date, in which case they
> will retain the order given on the command line). As the commit that
> introduced --no-walk (8e64006 (Teach revision machinery about
> --no-walk, 2007-07-24)) points out, the sorting is intentional, to
> allow things like
>
>  git log --abbrev-commit --pretty=oneline --decorate --all --no-walk
>
> to show all refs in order by commit date.
>
> But there are also other cases where the sorting is not wanted, such
> as
>
>   |
>git log --oneline --no-walk --stdin
>
> To accomodate both cases, leave the decision of whether or not to sort
> up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting
> to 'sorted' for backward-compatibility reasons.
>
> Signed-off-by: Martin von Zweigbergk 
> ---

Perhaps I am missing something from an earlier discussion, but it is
not obvious to me why this is an option to the no-walk behavior and
not something like --sorted/--unsorted as a separate option.

In other words, I don't understand why you always want to sort if you
are doing revision walking.

Thanks for any explanation,
-Dan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: exporting a .git file ?

[Dan Johnson]

On Mon, Aug 27, 2012 at 10:32 AM, Aaron Gray  wrote:
> Hi,
>
> Is there anyway to get my git repository as a single file ?

You're probably looking for the git bundle command (see git bundle
--help), but it's possible you might just want to use tar.

Hope that helps,
-- 
-Dan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: False positive from orphaned_commit_warning() ?

[Dan Johnson]

On Wed, Jul 25, 2012 at 2:53 PM, Paul Gortmaker
 wrote:
> Has anyone else noticed false positives coming from the
> orphan check?  It is warning me about commits that are
> clearly on master.  Here is an example, where I checkout
> master~2 and then switch back to master.  It somehow thinks
> that master~2 is orphaned, when master~2 is by definition
> in the commit chain leading to master.

I've been able to reproduce this with the following simplified recipe,
although I still don't know what is causing the failure (I'm not very
familiar with the code)

git init test
cd test
#make 3 commits
touch a && git add a && git commit -m a
touch b && git add b && git commit -m b
touch c && git add c && git commit -m c

#clone it
cd ..
git clone test test2
cd test2
git checkout master~2
git checkout master
#Warning: you are leaving 1 commit behind, not connected to
#any of your branches


I can't figure out what's going wrong here, but the clone is
important; it doesn't fail without it. It appears to have something to
do with the fact that the cloned repository has a remote, as:
#in test2
git remote rm origin
git checkout master~2
git checkout master

Does not throw the warning, but it's not just the presence of
origin/master that triggers it, as:

cd ../test
git remote add origin ../test2
git fetch origin
git checkout master~2
git checkout master

Does not trigger it either.

Confused,
-- 
-Dan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] git-remote-mediawiki: allow page names with a ':'

[Dan Johnson]

On Tue, Jul 17, 2012 at 10:06 AM, Matthieu Moy  wrote:
> Traditionnally, pages named Foo:Bar are page 'Bar' in namespace 'Foo'.
> However, it is also possible to call a page Foo:Bar if 'Foo' is not a
> namespace. In this case, the actual name of the page is 'Foo:Bar', in the
> main namespace. Since we can't tell with only the filename, query the
> wiki for a namespace 'Foo' in these cases, but deal with the case where
> no such namespace is found.

Might not be worth fixing, and it's just a typo in the commit message, but:
s/Traditionnally/Traditionally/
?

-- 
-Dan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Feature request: fetch --prune by default

[Dan Johnson]

On Thu, Jul 19, 2012 at 12:40 PM, Alexey Muranov
 wrote:
> On 19 Jul 2012, at 13:55, Jeff King wrote:
>
>> I agree it would be much less confusing. However, one downside is that
>> we do not keep reflogs on deleted branches (and nor did the commits in
>> remote branches necessarily make it into the HEAD reflog). That makes
>> "git fetch" a potentially destructive operation (you irrevocably lose
>> the notion of which remote branches pointed where before the fetch, and
>> you open up new commits to immediate pruning by "gc --auto".
>
> If i understand correctly, existence of a reflog entry will not stop "gc" 
> from removing a commit, will it?
> In this case, if a remote branch was rebased or reset, commits can be lost 
> anyway, right?
>From the git-gc man page:
git gc tries very hard to be safe about the garbage it collects. In
particular, it will keep not only objects referenced by your current
set of branches and tags, but also objects referenced by the index,
remote-tracking branches, refs saved by git filter-branch in
refs/original/, or reflogs (which may reference commits in branches
that were later amended or rewound).

So yes, a reflog entry does stop gc from removing objects, including
commits. It will expire old reflog entries (90 days by default)
though, so it's not like they will stay around forever.
-- 
-Dan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Feature request: fetch --prune by default

[Dan Johnson]

On Thu, Jul 19, 2012 at 7:55 AM, Jeff King  wrote:
> On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote:
>
>> i would like
>>
>> `git fetch --prune `
>>
>> to be the default behavior of
>>
>> `git fetch `
>>
>> In fact, i think this is the only reasonable behavior.
>> Keeping copies of deleted remote branches after `fetch` is more confusing 
>> than useful.
>
> I agree it would be much less confusing. However, one downside is that
> we do not keep reflogs on deleted branches (and nor did the commits in
> remote branches necessarily make it into the HEAD reflog). That makes
> "git fetch" a potentially destructive operation (you irrevocably lose
> the notion of which remote branches pointed where before the fetch, and
> you open up new commits to immediate pruning by "gc --auto".
>
> So I think it would be a lot more palatable if we kept reflogs on
> deleted branches. That, in turn, has a few open issues, such as how to
> manage namespace conflicts (e.g., the fact that a deleted "foo" branch
> can conflict with a new "foo/bar" branch).

In the meantime, would it make sense to introduce a configuration
variable to request this behavior?

If so, should it be global?

fetch.prune = always

or per-remote?

remote..prune = always

The global option seems to be more in line with what Alexey is looking
for, but the per-remote one is similar to the tagopt option, which is
a similar idea.

Of course, this might be just a waste of time to introduce a feature
no one would use, in which case we obviously should not introduce such
options.
-- 
-Dan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html