* Re: [RFH] lifetime rule for url parameter to transport_get()?
From: Daniel Barkalow @ 2011-08-23 17:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vsjosrs0w.fsf@alter.siamese.dyndns.org>
On Tue, 23 Aug 2011, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Does anybody remember why we use a copied string of "ref_git_copy" in
> > builtin/clone.c::setup_reference()?
> >
> > ref_git = real_path(option_reference);
> > ...
> > ref_git_copy = xstrdup(ref_git);
>
> It didn't have anything to do with transport/remote layer.
>
> This codepath uses real_path() and optionally mkpath(), both of which
> returns a short-lived static buffer to return its findings, and long-term
> users are expected to copy it away.
Yeah, that fits with my expectation, given the lack of a comment and the
fact that you were asking about clone and not also fetch.
At least originally, the remote and transport data was expected to live
until the process exits, since it's a small, bounded number of small
objects. If I'd included functions to free the structures, I'd have had
them free the strings they were passed.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2011, #03; Thu, 11)
From: Ramsay Jones @ 2011-08-20 21:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: pascal, git, Johannes Sixt
In-Reply-To: <7vhb5e73hy.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Pascal Obry <pascal@obry.net> writes:
>
>> Junio,
>>
>>> * po/cygwin-backslash (2011-08-05) 2 commits
>>> - On Cygwin support both UNIX and DOS style path-names
>>> - git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
>>>
>>> I think a further refactoring (no, not my suggestion) was offered?
>> I think the current patchset is fine. It is always possible to improve
>> things but the current patch goes in the right direction. So to me it
>> is ready as-is.
>
> Not very assuring to hear that only from the original submitter, no?
Commit 704c335 (On Cygwin support both UNIX and DOS style path-names,
05-08-2011) in pu needs an update to fix the commit message.
Also, I didn't see any response to Johannes Sixt's query concerning
backslash in pathspec. (I personally don't want to go down that
route, but ...)
ATB,
Ramsay Jones
^ permalink raw reply
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Junio C Hamano @ 2011-08-23 17:15 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Marat Radchenko, git
In-Reply-To: <4E53C89A.9000604@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Marat Radchenko venit, vidit, dixit 23.08.2011 12:52:
>>> Is that a very large tree or a very slow file system?
>> Tree is large (500k files), file system is irrelevant since all time is spend on CPU.
>>
>>> Do we enumerate all
>>> differing files and only then limit diff output by path??
>>
>> Dunno, that's why I am asking why it is so slow.
>
> Well, we have to read the full tree before diffing.
Not necessarily, especially when pathspec is given like the original post,
i.e. "git diff $tree_ish -- $path". We would need to open tree objects
that lead to the leaf of the $path and a blob, but other objects won't be
needed.
The default diff backend tries to come up with minimal changes by spending
extra cycles, so it is not so surprising if the file compared is large-ish
and/or has very many similar lines in itself (in which case there are many
potential matching line pairs between the preimage and the postimage to be
examined to produce a minimal diff).
^ permalink raw reply
* Re: [PATCH] git-svn: Destroy the cache when we fail to read it
From: Junio C Hamano @ 2011-08-23 17:05 UTC (permalink / raw)
To: Eric Wong; +Cc: Jason Gross, git, Jonathan Nieder
In-Reply-To: <20110823081546.GA28091@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Jason Gross <jgross@MIT.EDU> wrote:
>> my $cache_path = "$ENV{GIT_DIR}/svn/.caches/";
>
> Can we make the caches sharable by encoding variables like
> $Config{use64bitint} and $Storable::VERSION into $cache_path?
>
> Something like this (untested):
>
> use Config;
>
> my $cache_path = "$ENV{GIT_DIR}/svn/.caches/";
> $cache_path .= "$Config{use64bitint}.$Storable::VERSION/";
>
> We'll blow everybody's cache away once during the git-svn upgrade, but
> in the future people will be able to share the same working tree between
> different versions of perl/Storable/whatnot without needing extra code
> to detect croaks, different build options, and nuking each other's
> caches.
Meaning multiple directories and people share with those with systems with
similar characteristics? It certainly is better than silently getting
confused or barfing when reading 32LE data on 64BE box, and presumably it
would be easy to implement, but is that the best we can do with memoize?
I am wondering if memoize can be told to use a platform independent
serializer backend that is reasonably efficient.
^ permalink raw reply
* Re: How to check out the repository at a particular point in time
From: Jonathan Nieder @ 2011-08-23 16:53 UTC (permalink / raw)
To: Michael Witten
Cc: Matthieu Moy, rdiezmail-temp2, Thomas Rast, Michael J Gruber,
Hilco Wijbenga, git
In-Reply-To: <CAMOZ1BuMfUT4D_UasLXsjDrXRKDw4EF_U-CV8tsS9W7AP+f8ow@mail.gmail.com>
Michael Witten wrote:
> Indeed. That example makes perfect sense when so-called `branches'
> master and new-feature are rightfully thought of as the `pointers'
> (or, `references') that they are.
You are right to point out there is potential for confusion, because
different VCSes model the practice of branching and merging in so many
different ways:
- a single text field in each commit, as in Mercurial
- a list of "sticky" keywords attached to each commit, as in CVS
- special revision numbers, as in CVS
- special directory names, as in Subversion
- pointers to the tip of a line of history, as in Git
Each model has its strengths and weaknesses in terms of supporting
different operations one might to perform on a branch:
- creating a branch
- advancing a branch
- studying the history of development on a single branch
- fetching and pushing
- renaming a branch
- deleting
- comparing the history of two branches
- merging and deleting the now-merged-in branch
- merging and not deleting the now-merged-in branch
- "context switch" from working on one branch to another
In particular, you are right to emphasize that in git's model, "what
was on the foo branch at 12:00pm on Saturday" is just not a well
defined question. The foo branch tip might have been at commit A on
my machine, commit B on a server we share, and commit C on your
machine, so Git doesn't even bother --- branch refs are pointers into
history rather than participating in the history themselves.
Instead, we can content ourselves with the answers to questions like
"what was in the foo branch at 12pm on Saturday on the server used as
a rendezvous point", by logging in and examining the reflog on the
server.
A nice side-benefit is that branch refs are considered to be _private_
unless they are pushed or mentioned in a commit message. So there is
no pressure to come up with good names for them.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [RFH] lifetime rule for url parameter to transport_get()?
From: Junio C Hamano @ 2011-08-23 16:50 UTC (permalink / raw)
To: git; +Cc: Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <7vipppt175.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Does anybody remember why we use a copied string of "ref_git_copy" in
> builtin/clone.c::setup_reference()?
>
> ref_git = real_path(option_reference);
> ...
> ref_git_copy = xstrdup(ref_git);
It didn't have anything to do with transport/remote layer.
This codepath uses real_path() and optionally mkpath(), both of which
returns a short-lived static buffer to return its findings, and long-term
users are expected to copy it away.
I'll add a comment to that effect in the code.
^ permalink raw reply
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Marat Radchenko @ 2011-08-23 16:45 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E53C89A.9000604@drmicha.warpmail.net>
On вт 23 авг 2011 19:34:50 MSD, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Well, we have to read the full tree before diffing.
I don't see why you need that.
> But I can't
> reproduce the extreme difference which you observed (0.003s vs. 30s)
Well, I have an extreme repo (sadly, private) that has already shown several scalability issues in various parts of git code. Hope this thread will help to improve it.
> In your case, do you have a lot of differing files besides the one you
> are limitting to?
1. I'm diffing a single (and rather small, <50kb) text file
2. Diff is done between two branches (master and bugfix for a particular release) one of which (master) already has several thousands of commits after fork, so yes, whole tree diffs a lot.
P.S. Fix for [1] might somewhat improve the situation but it still isn't clear to me why whole tree needs to be processed when specific path is given. Btw, it is 30s even with --no-renames.
[1] http://git.661346.n2.nabble.com/git-diff-is-slow-patience-is-fast-td6667216.html
^ permalink raw reply
* Re: [PATCH 0/2] clone-local fixup
From: Junio C Hamano @ 2011-08-23 16:26 UTC (permalink / raw)
To: Hui Wang; +Cc: git
In-Reply-To: <4E5321C9.4080301@gmail.com>
Hui Wang <jason77.wang@gmail.com> writes:
> This patch series solved the problem from the root cause. :-)
>
> But there is a little problem in the second patch, i provide an
> incremental patch basing on your second patch, if it is fine to you,
> it is OK to squash this patch to your second patch.
Thanks. We also need the following fix-up, as I changed the semantics of
add_to_alternates_file() to take the path to the "objects" directory.
diff --git a/builtin/clone.c b/builtin/clone.c
index 284e325..63c34d0 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -336,14 +336,17 @@ static const struct ref *clone_local(const char *src_repo,
const char *dest_repo)
{
const struct ref *ret;
- struct strbuf src = STRBUF_INIT;
- struct strbuf dest = STRBUF_INIT;
struct remote *remote;
struct transport *transport;
- if (option_shared)
- add_to_alternates_file(src_repo);
- else {
+ if (option_shared) {
+ struct strbuf alt = STRBUF_INIT;
+ strbuf_addf(&alt, "%s/objects", src_repo);
+ add_to_alternates_file(alt.buf);
+ strbuf_release(&alt);
+ } else {
+ struct strbuf src = STRBUF_INIT;
+ struct strbuf dest = STRBUF_INIT;
strbuf_addf(&src, "%s/objects", src_repo);
strbuf_addf(&dest, "%s/objects", dest_repo);
copy_or_link_directory(&src, &dest, src_repo, src.len);
^ permalink raw reply related
* Re: How to check out the repository at a particular point in time
From: Michael Witten @ 2011-08-23 16:23 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jonathan Nieder, rdiezmail-temp2, Thomas Rast, in-git-vger,
Michael J Gruber, Hilco Wijbenga, git
In-Reply-To: <vpqliuk85ze.fsf@bauges.imag.fr>
On Tue, Aug 23, 2011 at 16:09, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Michael Witten wrote:
>>> On Mon, Aug 22, 2011 at 15:18, R. Diez <rdiezmail-temp2@yahoo.de> wrote:
>>
>>>> I still don't quite understand how git works, but let me
>>>> risk a naive statement here. If "a-b-c-M" were 'master',
>>>> and "d-e-f" were 'new-feature', then on April 1st the
>>>> current version on 'master' is 'b', because I merged the
>>>> 'new-feature' branch at a later point in time. Does that
>>>> make sense?
>>>
>>> O! for the love all that is Holy!
>>
>> Wait, what's wrong with what R. Diez said? It's exactly what
>> --first-parent gives you.
>
> Not really. Suppose, on April 1st, I have
>
> A--B--C <-master
> \
> D--E <-new-feature
>
> Then, I merge from upstream
>
> A--B-----C <-master
> \ \
> D--E--F <-new-feature
>
> and then I push to master, or master fast-forward-pulls from me:
>
> A--B-----C
> \ \
> D--E--F <-new-feature, master
>
> Then, what used to be in master on April 1st is C, but --first-parent
> will give you E instead.
Indeed. That example makes perfect sense when so-called `branches'
master and new-feature are rightfully thought of as the `pointers'
(or, `references') that they are.
Moreover, Jonathan, can't you see that your more knowledgeable mind
has automatically smoothed over the inaccuracies presented by R.
Diez's description? In particular, a `branch' has nothing to do with
walking a commit object's ancestry.
^ permalink raw reply
* Re: How to check out the repository at a particular point in time
From: Matthieu Moy @ 2011-08-23 16:09 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Michael Witten, rdiezmail-temp2, Thomas Rast, in-git-vger,
Michael J Gruber, Hilco Wijbenga, git
In-Reply-To: <20110823160525.GB3545@elie.gateway.2wire.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Michael Witten wrote:
>> On Mon, Aug 22, 2011 at 15:18, R. Diez <rdiezmail-temp2@yahoo.de> wrote:
>
>>> I still don't quite understand how git works, but let me
>>> risk a naive statement here. If "a-b-c-M" were 'master',
>>> and "d-e-f" were 'new-feature', then on April 1st the
>>> current version on 'master' is 'b', because I merged the
>>> 'new-feature' branch at a later point in time. Does that
>>> make sense?
>>
>> O! for the love all that is Holy!
>
> Wait, what's wrong with what R. Diez said? It's exactly what
> --first-parent gives you.
Not really. Suppose, on April 1st, I have
A--B--C <-master
\
D--E <-new-feature
Then, I merge from upstream
A--B-----C <-master
\ \
D--E--F <-new-feature
and then I push to master, or master fast-forward-pulls from me:
A--B-----C
\ \
D--E--F <-new-feature, master
Then, what used to be in master on April 1st is C, but --first-parent
will give you E instead.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: How to check out the repository at a particular point in time
From: Jonathan Nieder @ 2011-08-23 16:05 UTC (permalink / raw)
To: Michael Witten
Cc: rdiezmail-temp2, Thomas Rast, in-git-vger, Michael J Gruber,
Hilco Wijbenga, git
In-Reply-To: <CAMOZ1Bti3ZtAEOtLiUYSkWE+rO_VQd09NAn58Cn4hZBu8f-aFQ@mail.gmail.com>
Michael Witten wrote:
> On Mon, Aug 22, 2011 at 15:18, R. Diez <rdiezmail-temp2@yahoo.de> wrote:
>> I still don't quite understand how git works, but let me
>> risk a naive statement here. If "a-b-c-M" were 'master',
>> and "d-e-f" were 'new-feature', then on April 1st the
>> current version on 'master' is 'b', because I merged the
>> 'new-feature' branch at a later point in time. Does that
>> make sense?
>
> O! for the love all that is Holy!
Wait, what's wrong with what R. Diez said? It's exactly what
--first-parent gives you.
^ permalink raw reply
* Re: How to check out the repository at a particular point in time
From: Michael Witten @ 2011-08-23 15:54 UTC (permalink / raw)
To: rdiezmail-temp2
Cc: Thomas Rast, in-git-vger, Michael J Gruber, Jonathan Nieder,
Hilco Wijbenga, git
In-Reply-To: <1314026326.37332.YahooMailClassic@web25408.mail.ukl.yahoo.com>
On Mon, Aug 22, 2011 at 15:18, R. Diez <rdiezmail-temp2@yahoo.de> wrote:
>> The main problem is that your request is not very
>> well-defined: in
>> nonlinear history there will in general be more than one
>> commit at the
>> time requested.
>>
>> ---a----b----c----M---- (M is a merge)
>> \ /
>> d-----e----f
>>
>> ^----April 1st
>>
>> Suppose you ask git for "the newest commit as of April 1st"
>> in this history. Is it supposed to give you b or d?
>
> I still don't quite understand how git works, but let me
> risk a naive statement here. If "a-b-c-M" were 'master',
> and "d-e-f" were 'new-feature', then on April 1st the
> current version on 'master' is 'b', because I merged the
> 'new-feature' branch at a later point in time. Does that
> make sense?
O! for the love all that is Holy!
You see, guys? The term `branch' was a TERRIBLE choice.
What git calls `branch master' in your example is just a pointer to
the commit object `M'; it has nothing to do with particular lineages
like `a-b-c-M'.
Please see my discussion with Hilco, starting here:
http://marc.info/?l=git&m=131364675708355&w=2
Message-ID: CAMOZ1BsZvXsnnWAPXR7UGKdqOMwuGB-ffaAPk55U_1dcjZUcDw@mail.gmail.com
and this email in particular:
http://marc.info/?l=git&m=131396006222173&w=2
Message-ID: CAMOZ1BvpnP_729YOHrrPW3B8wa5c4cLyD_qAQ5rTuy0JqNiiXg@mail.gmail.com
which also includes the following very germane link:
http://slashdot.org/comments.pl?sid=2350536&cid=36903136
^ permalink raw reply
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Michael J Gruber @ 2011-08-23 15:34 UTC (permalink / raw)
To: Marat Radchenko; +Cc: git
In-Reply-To: <1314096731.15017.2.camel@n900.home.ru>
Marat Radchenko venit, vidit, dixit 23.08.2011 12:52:
>> Is that a very large tree or a very slow file system?
> Tree is large (500k files), file system is irrelevant since all time is spend on CPU.
>
>> Do we enumerate all
>> differing files and only then limit diff output by path??
>
> Dunno, that's why I am asking why it is so slow.
Well, we have to read the full tree before diffing. But I can't
reproduce the extreme difference which you observed (0.003s vs. 30s),
only a factor of ten or so for a repo with 100k files:
git init
seq 0 100000|while read n ; do echo a > a$n;done
git add .
git commit -m m
echo b > a0
On a ramdisk, I get:
time git diff > /dev/null
real 0m0.160s
user 0m0.064s
sys 0m0.190s
time git diff -- a0 > /dev/null
real 0m0.070s
user 0m0.051s
sys 0m0.021s
time git diff HEAD > /dev/null
real 0m0.266s
user 0m0.145s
sys 0m0.212s
time git diff HEAD -- a0 > /dev/null
real 0m0.171s
user 0m0.136s
sys 0m0.033s
time git show HEAD:a0 > /dev/null
real 0m0.018s
user 0m0.009s
sys 0m0.007s
time git show HEAD:a0 | diff -u - a0 > /dev/null
real 0m0.019s
user 0m0.010s
sys 0m0.008s
Stumped.
In your case, do you have a lot of differing files besides the one you
are limitting to? Anyway, that does not seem to make a huge difference
in my timings. (Just tried.) Still Stumped.
Michael
^ permalink raw reply
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Michael Witten @ 2011-08-23 15:20 UTC (permalink / raw)
To: Marat Radchenko; +Cc: Michael J Gruber, git
In-Reply-To: <1314096731.15017.2.camel@n900.home.ru>
On Tue, Aug 23, 2011 at 10:52, Marat Radchenko <marat@slonopotamus.org> wrote:
>> Do we enumerate all differing files and only then
>> limit diff output by path??
>
> Dunno, that's why I am asking why it is so slow.
Why in the world do you think that question was directed at you?
^ permalink raw reply
* Re: Merge after directory rename ?
From: Michael Witten @ 2011-08-23 14:50 UTC (permalink / raw)
To: Marcin Wiśnicki; +Cc: git
In-Reply-To: <CAC9GOO8w_zZ8wuRambnGoaS+rKskdjuSZVpF+b4mzdhzK48bjg@mail.gmail.com>
2011/8/22 Marcin Wiśnicki <mwisnicki@gmail.com>:
> Well kind of. Your example was different because you have created dir1
> independently on branch1 and master in which case automatic rename
> wouldn't be expected. If you would've created dir1 before branching
> and renamed dir1 to dir3 (renamed all files under dir1) then I would
> expect a rename while merging.
I already covered this case in my initial paragraph. Good Luck!
^ permalink raw reply
* Re: Branches & directories
From: Michael Witten @ 2011-08-23 14:46 UTC (permalink / raw)
To: Hilco Wijbenga
Cc: Kyle Moffett, Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <CAE1pOi1axNmGaPVXqBH02x0N=Z6tgO9R00RTokuJm50eY-OoNg@mail.gmail.com>
On Mon, Aug 22, 2011 at 20:10, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
> On 22 August 2011 12:31, Kyle Moffett <kyle@moffetthome.net> wrote:
>> On Mon, Aug 22, 2011 at 14:49, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>>> On 22 August 2011 05:46, Kyle Moffett <kyle@moffetthome.net> wrote:
>>>> On Mon, Aug 22, 2011 at 01:36, Hilco Wijbenga <hilco.wijbenga@gmail.com> wrote:
>>>>> On 21 August 2011 20:01, Kyle Moffett <kyle@moffetthome.net> wrote:
>>>> In particular, even "git stash" intentionally does not preserve file times,
>>>> so you would end up rebuilding everything anyways because all of your
>>>> source files would be as new as your object files.
>>>
>>> Yes, I just noticed that. Why do you say "intentionally"? Is extra
>>> work being done to make it so? If yes, then shouldn't that be
>>> configurable?
>>
>> Well, there's 2 reasons:
>>
>> (1) The GIT data-structures simply have no place for file timestamps, and
>> "git stash" is simply a special way of dumping files into a temporary commit.
>
> That's what I thought. The "intentionally" threw me off. It's not
> intentional, it's just a side effect.
No, it's intentional.
This discussion about timestamps is not new; the mailing list is
littered with people wondering about it. The data structures are the
way they are for intentional reasons, as suggested by Kyle's example.
>> (2) You almost always *don't* want to preserve timestamps. For example:
>>
>> $ git checkout -b my-feature origin/master
>> $ vim some-file.c
>> $ make
>> $ git add some-file.c && git commit -m "A new feature"
>> $ git checkout -b my-bugfix origin/master
>> $ vim other-file.c
>> $ make
>>
>> If GIT preserved timestamps, the second "make" would fail to rebuild the
>> product "some-file.o" because "some-file.c" is still older than it, even
>> though "some-file.c" has changed since the last build!!!
>>
>> Really, GIT is only intended for storing source code. If you want to store
>> other kinds of things (like timestamps, permissions, etc), then you need to
>> turn them into source code (IE: a text file and a "make install" target) and
>> then store them that way.
>
> Yep, that all makes sense. I just wish there was at least an option to
> keep the timestamp (and possibly other such things). Even Subversion
> can do that... ;-) After all, not everybody uses C & make.
Yes, well, the crux there is `(and possibly other such things)'. That
is an open-ended specification because nobody can agree on what such
things should include.
One of git's major design goals has been efficiency, so it's natural
that git only handles what is necessary for its prime purpose of
managing a history of line-oriented textual content.
However, other tools have been built on top of git's infrastructure in
order to store all manner of metadata (usually for the purposes of
backing up files with all of their special metadata).
Essentially, only *you* know what `other such things' *you* need, so
it's up to you to design a way of storing such information and
retrieving it yourself. After all, not everybody (indeed, nearly
nobody, I'd wager) has your specific difficulties.
^ permalink raw reply
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Marat Radchenko @ 2011-08-23 10:52 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E537AF0.9070604@drmicha.warpmail.net>
> Is that a very large tree or a very slow file system?
Tree is large (500k files), file system is irrelevant since all time is spend on CPU.
> Do we enumerate all
> differing files and only then limit diff output by path??
Dunno, that's why I am asking why it is so slow.
^ permalink raw reply
* Re: [PATCH] Mark http-fetch without -a as deprecated
From: Ben Walton @ 2011-08-23 13:05 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <vpqvcto391x.fsf@bauges.imag.fr>
Excerpts from Matthieu Moy's message of Tue Aug 23 03:02:02 -0400 2011:
Hi Matthieu,
> Bad indentation. Git indents with tabs, not spaces. Also, you can break
> the line to make both the error message and the source code fit on 80
> characters.
Yes, sorry. Too much dependence on emacs 'doing the right thing' I
guess. I'll fix both of these issues and resubmit.
> No opinion on whether the deprecation is sensible, though. If it is,
> add something in the documentation, not just in the code.
Yes, good point. I'll include this documentation change as well.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply
* Re: [PATCH 4/4] Add documentation for ref namespaces
From: Ævar Arnfjörð Bjarmason @ 2011-08-23 10:38 UTC (permalink / raw)
To: Jamey Sharp
Cc: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Jeff King,
Jakub Narebski, git, Josh Triplett
In-Reply-To: <1307470885-4018-5-git-send-email-jamey@minilop.net>
On Tue, Jun 7, 2011 at 20:21, Jamey Sharp <jamey@minilop.net> wrote:
> Document the namespace mechanism in a new gitnamespaces(7) page.
> Reference it from receive-pack and upload-pack.
This breaks the build on older asciidoc versions, the fix is to do
what I did in f5008f56d5aba06598e1c6272f4f55b4ee4bb016.
^ permalink raw reply
* Re: Missing blobs after pruning dangling commits
From: Marcin Wiśnicki @ 2011-08-23 10:16 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E5372E5.1070509@drmicha.warpmail.net>
2011/8/23 Michael J Gruber <git@drmicha.warpmail.net>:
> Suggestions:
Neither of them helped, however I've added old packs from backup and did
git fsck
git repack -ad
git reflog expire --expire=0 --all
git repack -ad
git prune
git fsck
And now everything is fine.
Only thing that concerns me is that there are still two packs:
$ ls -la .git/objects/pack/
total 145632
drwxr-xr-x 2 marcin.w Administ 4096 Aug 23 11:42 .
drwxr-xr-x 4 marcin.w Administ 20480 Aug 23 11:47 ..
-rw-r--r-- 1 marcin.w Administ 529152 Aug 9 15:01
.tmp-3616-pack-83952e51abdea7469eef06dde2e692e04ba8f9f3.idx
-rw-r--r-- 1 marcin.w Administ 149572531 Aug 9 15:01
.tmp-3616-pack-83952e51abdea7469eef06dde2e692e04ba8f9f3.pack
-r--r--r-- 1 marcin.w Administ 555724 Aug 23 11:42
pack-3cd1ec9be7cdb31d8eac4404c249edf9c1654937.idx
-r--r--r-- 1 marcin.w Administ 147570858 Aug 23 11:42
pack-3cd1ec9be7cdb31d8eac4404c249edf9c1654937.pack
Both files have identical ACLs but pack-3cd1.. has dos attribute
"readonly". Toggling this attribute on any file does not seem to have
an effect on git repack. Both packs are present in
.git/objects/info/packs.
Deleting it by hand followed by repack -ad and fsck seems to work
though, which means it was redundant yet not removed by repack.
> Could you share that repo or is it private?
Unfortunately I can't.
^ permalink raw reply
* Re: How to check out the repository at a particular point in time
From: PJ Weisberg @ 2011-08-23 10:04 UTC (permalink / raw)
To: Thomas Rast; +Cc: rdiezmail-temp2, git@vger.kernel.org, in-git-vger@baka.org
In-Reply-To: <201108231117.00314.trast@student.ethz.ch>
On Tue, Aug 23, 2011 at 2:17 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> I personally think that's crazy and -- if you want to avoid the work
> of "really" using submodules -- support Jens's suggestion of having
> the buildbot automatically assemble an "I tested this" superproject.
Or create a tag in each separate repository, using the same tag name
to indicate versions that were tested together. Or you could do the
same with a branch, since a branch is basically a tag that moves. You
would just have to make sure only the buildbot updated that branch.
-PJ
^ permalink raw reply
* Re: What's the difference between `git show branch:file | diff -u - file` vs `git diff branch file`?
From: Michael J Gruber @ 2011-08-23 10:03 UTC (permalink / raw)
To: Marat Radchenko; +Cc: git
In-Reply-To: <loom.20110823T091132-107@post.gmane.org>
Marat Radchenko venit, vidit, dixit 23.08.2011 09:25:
> $ time git show branch:file | diff -u - file > /dev/null
>
> real 0m0.003s
> user 0m0.000s
> sys 0m0.000s
>
> $ time git diff branch -- file > /dev/null
>
> real 0m31.442s
> user 0m31.040s
> sys 0m0.380s
>
> What does git diff do so it takes that much time? And is there any flag to git
> diff so that it will work as fast as show + diff? I thought these two are
> equivalent but from run time it is obvious that they aren't.
>
> gprof output: http://slonopotamus.org/git-diff/git-diff-branch.gprof.txt
>
Is that a very large tree or a very slow file system?
>From the gprof output, it would appear that we compare a lot of cache
entries (or rather: spent most time on...). Do we enumerate all
differing files and only then limit diff output by path??
Michael
^ permalink raw reply
* Re: Missing blobs after pruning dangling commits
From: Michael J Gruber @ 2011-08-23 9:29 UTC (permalink / raw)
To: Marcin Wiśnicki; +Cc: git
In-Reply-To: <CAC9GOO-cAKTvUyKvrijA8H8z4uRFkTjzJ_dqS_-aO1MYB-yaTw@mail.gmail.com>
Marcin Wiśnicki venit, vidit, dixit 22.08.2011 16:29:
> Hello,
>
> recently I had git-fsck report some dangling references:
>
> $ git fsck
> dangling commit 9275ee571ead7a75ba57e16ba23155a178459918
> dangling commit 047bd63ae82b7540098515467f50562e374edada
> dangling commit 839cee3c8e16231e6523ecf8b855ef0863787990
> dangling commit f7cb119ea71cb3cc739331f2e26bf3e9fdbba24a
> dangling commit 68d41b28f320aff303c5a89b25e2243ad2e526f2
> dangling commit effcf50a636d2f08e21706f41eb8ae3c4c577166
>
> This is completely local (isolated) repository.
> Based on related FAQ entry ("remove old objects after filter-branch"),
> I did this:
>
> $ git reflog expire --expire=0 --all
> $ git repack -ad
> $ git prune
>
> Unfortunately, now fsck complains:
>
> $ git fsck
> missing blob 6d2ddd86d4594f8c756cc31b72d61653255a3161
> missing blob 6c537408f0b2226c0b6dae9b0ef0f92710fb25ed
> missing blob 2db55c1e39fd80e39eccefc617b852d3ac93abe9
> $ git --version
> git version 1.7.6.msysgit.0
>
> Is this a bug ?
>
> Also, how can I find where this blob came from. I've tried grepping
> all commits in original repo (from backup):
>
> $ gitwhich() {
> git log --all --pretty=format:'%T %H' | while read tree commit; do
> git ls-tree -r $tree | grep -q $1 && echo $commit;
> done
> }
> $ gitwhich 2db55c1e39fd80e39eccefc617b852d3ac93abe9
>
> but nothing was found.
Suggestions:
Try git fsck --unreachable.
There may be tree objects which reference those blobs but are not
referenced by a tree or commit. (They should have been pruned, but could
have been stuck in a pack.)
Try repacking again after the prune step.
Could you share that repo or is it private?
Michael
^ permalink raw reply
* Re: How to check out the repository at a particular point in time
From: Thomas Rast @ 2011-08-23 9:17 UTC (permalink / raw)
To: rdiezmail-temp2; +Cc: PJ Weisberg, git@vger.kernel.org, in-git-vger@baka.org
In-Reply-To: <1314085268.42103.YahooMailClassic@web25406.mail.ukl.yahoo.com>
R. Diez wrote:
>
> check out HEAD, it should always work
Please stop using HEAD like this, you'll just confuse your coworkers
(and yourself). HEAD denotes the currently checked out commit.
[Unlike SVN it is *not* the most recent version of anything.] Thus by
definition, 'git checkout HEAD' is a no-op.
The newest commit on a branch is denoted by its branch name, because
as Jens said, a branch is in fact a pointer to its tip[1] commit.
> Now you're saying I cannot reliably checkout last week's versions
> because yesterday I did a merge from an older branch? You mean that
> git stores everything with clean graphs and numeric pointers, so it
> cannot know what this repository looked like last week?
Indeed. Especially if forced pushes are allowed, there is no way to
know what was in the repo at a given time unless you have (local)
reflogs enabled on remote branches and going back until the time you
want.
> As the developer, I have full control, I can decide what the
> branches are called and how the public repository is
> updated/pushed/whatever. I can control the clock so there are no
> time skews.
>
> What do I have to do in order to be able to reliably checkout last
> week's versions without too much administrative work? I just want to
> get the same result today as if I had done a checkout last week from
> the public repository and had made a back-up copy of the working
> directory then.
Assuming
* you never do a non-fast-forward (i.e., forced) push
* you never have any clock skew
* you always merge features into master (not the other way around)
* you always push immediately after committing on master
you can get there by using 'git log -1 --first-parent --until=...'
as mentioned in my first email.
I personally think that's crazy and -- if you want to avoid the work
of "really" using submodules -- support Jens's suggestion of having
the buildbot automatically assemble an "I tested this" superproject.
[1] or "head" in lowercase (thus "branch head"), but I prefer tip to
avoid confusion
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] git-svn: Destroy the cache when we fail to read it
From: Eric Wong @ 2011-08-23 8:15 UTC (permalink / raw)
To: Jason Gross; +Cc: git, Jonathan Nieder
In-Reply-To: <1313979422-21286-1-git-send-email-jgross@mit.edu>
Jason Gross <jgross@MIT.EDU> wrote:
> my $cache_path = "$ENV{GIT_DIR}/svn/.caches/";
Can we make the caches sharable by encoding variables like
$Config{use64bitint} and $Storable::VERSION into $cache_path?
Something like this (untested):
use Config;
my $cache_path = "$ENV{GIT_DIR}/svn/.caches/";
$cache_path .= "$Config{use64bitint}.$Storable::VERSION/";
We'll blow everybody's cache away once during the git-svn upgrade, but
in the future people will be able to share the same working tree between
different versions of perl/Storable/whatnot without needing extra code
to detect croaks, different build options, and nuking each other's
caches.
--
Eric Wong
^ 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