* Re: [RFC] Add --create-cache to repack
From: Nicolas Pitre @ 2011-01-31 21:48 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Johannes Sixt, git, Junio C Hamano, John Hawley
In-Reply-To: <AANLkTimW=fuKrhw6+ZDipEtSGX_oR4LbTZzyAxZ8Pry1@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3348 bytes --]
On Mon, 31 Jan 2011, Shawn Pearce wrote:
> On Fri, Jan 28, 2011 at 17:32, Shawn Pearce <spearce@spearce.org> wrote:
> >>> >
> >>> >> This started because I was looking for a way to speed up clones coming
> >>> >> from a JGit server. Cloning the linux-2.6 repository is painful,
> >
> > Well, scratch the idea in this thread. I think.
>
> Nope, I'm back in favor with this after fixing JGit's thin pack
> generation. Here's why.
>
> Take linux-2.6.git as of Jan 12th, with the cache root as of Dec 28th:
>
> $ git update-ref HEAD f878133bf022717b880d0e0995b8f91436fd605c
> $ git-repack.sh --create-cache \
> --cache-root=b52e2a6d6d05421dea6b6a94582126af8cd5cca2 \
> --cache-include=v2.6.11-tree
> $ git repack -a -d
>
> $ ls -lh objects/pack/
> total 456M
> 1.4M pack-74af5edca80797736fe4de7279b2a81af98470a5.idx
> 38M pack-74af5edca80797736fe4de7279b2a81af98470a5.pack
>
> 49M pack-d3e77c8b3045c7f54fa2fb6bbfd4dceca1e2b9fa.idx
> 89 pack-d3e77c8b3045c7f54fa2fb6bbfd4dceca1e2b9fa.keep
> 368M pack-d3e77c8b3045c7f54fa2fb6bbfd4dceca1e2b9fa.pack
>
> Our "recent history" is 38M, and our "cached pack" is 368M. Its a bit
> more disk than is strictly necessary, this should be ~380M. Call it
> ~26M of wasted disk.
This is fine. When doing an incremental fetch, the thin pack does
minimize the transfer size, but it does increase the stored pack size by
appending a bunch of non delta objects to make the pack complete.
What happens though, is that when gc kicks in, the wasted space is
collected back. Here with a single pack we wouldn't claim that space
back as our current euristics is to reuse delta (non) pairing by
default. Maybe in that case we could simply not reuse deltas if they're
of the REF_DELTA type.
> The "cached object list" I proposed elsewhere in
> this thread would cost about 41M of disk and is utterly useless except
> for initial clones. Here we are wasting about 26M of disk to have
> slightly shorter delta chains in the cached pack (otherwise known as
> our ancient history). So its a slightly smaller waste, and we get
> some (minor) benefit.
Well, of course the ancient history you're willing to keep stable for a
while could be repacked even more aggressively than usual.
> Using the cached pack increased our total data transfer by 2.39 MiB,
That's more than acceptable IMHO. That's less than 1% of the total
transfer.
> I think this is worthwhile. If we are afraid of the extra 2.39 MiB
> data transfer this forces on the client when the repository owner
> enables the feature, we should go back and improve our thin-pack code.
> Transferring 11 MiB to catch up a kernel from Dec 28th to Jan 12th
> sounds like a lot of data,
Well, your timing for this test corresponds with the 2.6.38 merge window
which is a high activity peak for this repository. Still, that would
probably fit the usage scenario in practice pretty well where the cache
pack would be produced on a tagged release which happens right before
the merge window.
> and any improvements in the general
> thin-pack code would shrink the leading thin-pack, possibly getting us
> that 2.39 MiB back.
Any improvement to the thin pack would require more CPU cycles, possibly
lot more. So given this transfer overhead is less than 1% already I
don't think we need to bother.
Nicolas
^ permalink raw reply
* [1.8.0] forbid full fetchspecs in git-pull
From: Thomas Rast @ 2011-01-31 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sean Estabrooks, Björn Steinbrink
In-Reply-To: <7vwrll57ha.fsf@alter.siamese.dyndns.org>
Proposal:
git-pull inherits the full fetchspec invocation syntax from git-fetch,
so that you can do e.g.
git pull origin master:master
usually shooting yourself in the foot in the process. See e.g.
http://thread.gmane.org/gmane.comp.version-control.git/130819/focus=130879 [item 1]
Prohibit this invocation, i.e., disallow any second argument to
git-pull that contains ':'.
History:
I submitted a patch ages ago:
http://article.gmane.org/gmane.comp.version-control.git/130822
Sean seemed to be the only one in favour of the old behaviour, but I
was too lazy to push it past him. (There were some issues with the
test as well.)
I honestly still don't see a valid use-case for the full syntax, let
alone having seen one in the wild; in cases where you are inclined to
do
git pull origin foo:bar
you probably don't need 'bar' to begin with if you can use
'origin/foo' instead, assuming the previous proposal on remote-branch
updating is also included.
Risks:
It's an incompatibility, so scripts may break.
Migration plan:
None; disallow it at the 1.8.0 boundary.
If someone makes a good case why his hands are trained that way, we
might introduce a config variable instead.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [1.8.0] 't/' is standard name for directory with tests
From: Jakub Narebski @ 2011-01-31 21:59 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.1101311459000.8580@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> So I'd suggest doing the following:
> 5) Rename t/ to testsuite/ so this doesn't look like some garbage
> leftover.
Nope. 't/' is the standard name for directory with "normal" tests, at
least in Perl / CPAN land, where TAP comes from ('xt/' is for extra
tests)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Junio C Hamano @ 2011-01-31 22:17 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.2.00.1101311621150.8580@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Mon, 31 Jan 2011, Jeff King wrote:
>
>> Besides being just one more directory to go up and down, it does make
>> history browsing more annoying. As much as I love git's "don't record
>> renames" philosophy, our handling of renames on the viewing side is
>> often annoying. I already get annoyed sometimes following stuff across
>> the s!builtin-!builtin/! change. This would be like that but more so.
>
> So... we do suck at something? So why not take this opportunity to
> shake yourself out of this easy comfort and improve Git as a result on
> both front? :-)
>
>> Or maybe it is a good thing for that reason, as we will eat our own
>> rename dogfood. :)
>
> Exactly! And maybe we'll make Git even more useful in the process.
This part I _could_ actually buy; even though I do not think moving files
without much reason is a good project hygine, it does happen in real life,
and we would want to keep things smooth for real people.
>> > 5) Rename t/ to testsuite/ so this doesn't look like some garbage
>> > leftover.
I am not sure about this "t/" vs "testsuite/".
>> Ugh, more typing. :P
>
> Come on! You sound like an old fart now! ;-)
If we make the top-level directory lean enough, we probably can tab
complete after typing just "cd t" to go to testsuite/ or tests/ or
whatever you come up with, so "more typing" is not a huge issue to me
personally.
I however think the directory name "t/" is not our invention but what we
took from somebody else (perhaps Perl?), and I suspect some people expect
to find tests under there since we have had them there for a long time.
^ permalink raw reply
* Re: [1.8.0] make two-argument fetch update remote branches
From: Matthieu Moy @ 2011-01-31 22:18 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <201101312244.10047.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Running "git fetch origin master" only updates FETCH_HEAD, not
> origin/master, which turns out to be quite confusing for newcomers
> especially after running 'git pull origin master'.
+1
We just got the case on this list of a newbie running "git pull origin
master" to update his local branch, and "git status" still complaining
that the local branch was ahead of the remote by many commits.
Updating the remote-tracking in this case would avoid such confusion.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [1.8.0] make two-argument fetch update remote branches
From: Junio C Hamano @ 2011-01-31 22:24 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201101312244.10047.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Proposal:
>
> Running "git fetch origin master" only updates FETCH_HEAD, not
> origin/master, which turns out to be quite confusing for newcomers
> especially after running 'git pull origin master'.
>
> Since the remote branches in some sense reflect the "last known state"
> of the remote, it would make sense to also update them to whatever a
> two-argument fetch got.
>
> Risks:
>
> Scripts might rely on the current behaviour. The most likely case I
> can think of would be to go along the lines of
>
> git fetch origin master
> git rev-list origin/master...FETCH_HEAD | do_something
>
> to avoid relying on reflogs to get the same result. Seems a bit
> arcane to me though. Such usage would see the updated state, i.e.,
> process an empty range.
>
> Migration plan:
>
> Add a fetch.updateRemoteNamespace (or so) configuration variable that
> defaults to false. When enabled, it turns on the auto-updating
> behaviour.
>
> In 1.8.0, flip the default.
The overall goal is a good one, I think, but it is not a migration plan
without a period where we issue a loud, in-your-face, warning to force
users to choose, is it? I suspect you just didn't write it because it is
so obvious, but I am just making sure it is written down somewhere, so
that whoever ends up implementing this will not forget.
Thanks.
^ permalink raw reply
* Re: [1.8.0] make two-argument fetch update remote branches
From: Eugene Sajine @ 2011-01-31 22:27 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <201101312244.10047.trast@student.ethz.ch>
On Mon, Jan 31, 2011 at 4:44 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Proposal:
>
> Running "git fetch origin master" only updates FETCH_HEAD, not
> origin/master, which turns out to be quite confusing for newcomers
> especially after running 'git pull origin master'.
>
> Since the remote branches in some sense reflect the "last known state"
> of the remote, it would make sense to also update them to whatever a
> two-argument fetch got.
>
> Risks:
>
> Scripts might rely on the current behaviour. The most likely case I
> can think of would be to go along the lines of
>
> git fetch origin master
> git rev-list origin/master...FETCH_HEAD | do_something
>
> to avoid relying on reflogs to get the same result. Seems a bit
> arcane to me though. Such usage would see the updated state, i.e.,
> process an empty range.
>
> Migration plan:
>
> Add a fetch.updateRemoteNamespace (or so) configuration variable that
> defaults to false. When enabled, it turns on the auto-updating
> behaviour.
>
> In 1.8.0, flip the default.
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
+1 I really wanted to write this one my self;)
I would disagree with the migration plan though.
IMHO there is no need to introduce the variable. If it will start
update both FETCH_HEAD and the remote-tracking branches since 1.8 it
will not break any code, because it is added functionality...
In this case FETCH_HEAD will reflect the latest fetch and it doesn't
even need to be removed later on.
just my 2 cents...
Thanks,
Eugene
^ permalink raw reply
* Re: [1.8.0] 't/' is standard name for directory with tests
From: Nicolas Pitre @ 2011-01-31 22:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3d3ncag7r.fsf_-_@localhost.localdomain>
On Mon, 31 Jan 2011, Jakub Narebski wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > So I'd suggest doing the following:
>
> > 5) Rename t/ to testsuite/ so this doesn't look like some garbage
> > leftover.
>
> Nope. 't/' is the standard name for directory with "normal" tests, at
> least in Perl / CPAN land, where TAP comes from ('xt/' is for extra
> tests)
So what? It is not because Perl has set this horrible precedent that we
have to perpetuate it. I personally never saw t used as a directory
name for tests before Git, and I'm not that young anymore unfortunately.
Nicolas
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: João P. Sampaio @ 2011-01-31 22:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Jeff King, git
In-Reply-To: <7vpqrc4t1s.fsf@alter.siamese.dyndns.org>
I think a good code hygiene is important, and some suggestions here
are relevant:
1) I also think there should be a directory for the source code
(namely, src/), and the top level should act as a table of contents.
As a newcomer myself who's trying to grasp Git, I can say an organized
project makes people more inclined join. Therefore, directories should
be named as clearly as possible: see item 2;
2) For item 1, t/ should be renamed to testsuite/. As Junio said, if
we get a more organized project, people could just "cd t" and tab to
autocomplete, or "cd tes" at the worst scenario, which is not such a
big hassle. About people expecting the testsuite to be inside t/, once
they type "cd t" and get an error, most people would look for an
alternative and eventually find the correct folder, or tabbing would
just suggest the name.
3) The top level should hold files that point people towards where
they want to go, helpful files like README and even some
Documentation/ files could get a promotion.
3) As 1.8.0 can be an inflexion for users, so could be for the
developers as well.
--
João Paulo Melo de Sampaio
Computer Engineering Student @ UFSCar
Website: http://www.jpmelos.com
Twitter: twitter.com/jpmelos (@jpmelos)
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Nicolas Pitre @ 2011-01-31 22:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vpqrc4t1s.fsf@alter.siamese.dyndns.org>
On Mon, 31 Jan 2011, Junio C Hamano wrote:
> If we make the top-level directory lean enough, we probably can tab
> complete after typing just "cd t" to go to testsuite/ or tests/ or
> whatever you come up with, so "more typing" is not a huge issue to me
> personally.
>
> I however think the directory name "t/" is not our invention but what we
> took from somebody else (perhaps Perl?), and I suspect some people expect
> to find tests under there since we have had them there for a long time.
If those people are not able to figure out that "testsuite" means where
tests are, especially within a lean top directory, then we might
question the reliability of the tests they might contribute.
Nicolas
^ permalink raw reply
* Re: [RFC] fast-import: notemodify (N) command
From: Sam Vilain @ 2011-01-31 22:37 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jonathan Nieder, vcs-fast-import-devs, git, chriscool,
Johannes.Schindelin, trast, Johan Herland, gitster, git,
Augie Fackler
In-Reply-To: <AANLkTikxFSa1CSujk2zgh4K8SWCuKHRrDRFVNt9JPGo0@mail.gmail.com>
On 01/02/11 10:19, Sverre Rabbelier wrote:
> That's another thing Augie mentioned that he (and I guess the hg
> community at large) dislikes, the fact that they're not propagated.
This is not a "fact".
If you add configuration in your git config to fetch and push the refs,
then they are propagated.
Just because you disagree with the current interface or defaults doesn't
mean the design is wrong. I hear the same arguments against submodules,
which is a shame because the message isn't getting through to people
that the porcelain can and should be extended to make people's lives
easier. It's just that instead of second-guessing what shape they
should take, the design and plumbing are written so that people can
write scripts to make it work.
It's a slower path, but you end up with a better tool at the end of it.
Sam
^ permalink raw reply
* Re: [1.8.0] forbid full fetchspecs in git-pull
From: Junio C Hamano @ 2011-01-31 22:38 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Sean Estabrooks, Björn Steinbrink
In-Reply-To: <201101312255.59841.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Proposal:
>
> git-pull inherits the full fetchspec invocation syntax from git-fetch,
> so that you can do e.g.
>
> git pull origin master:master
>
> usually shooting yourself in the foot in the process. See e.g.
>
> http://thread.gmane.org/gmane.comp.version-control.git/130819/focus=130879 [item 1]
>
> Prohibit this invocation, i.e., disallow any second argument to
> git-pull that contains ':'.
>
> History:
>
> I submitted a patch ages ago:
>
> http://article.gmane.org/gmane.comp.version-control.git/130822
>
> Sean seemed to be the only one in favour of the old behaviour, but I
> was too lazy to push it past him. (There were some issues with the
> test as well.)
As I summarized in $gmane/135813 I don't think there was any objection
against forbidding "git pull" with refspec with colon. There indeed was
an interesting tangent topic that was about valid use cases of "git fetch"
with such refspec, but I think this is orthogonal to that issue.
^ permalink raw reply
* Re: [1.8.0] (v2) default "git merge" without argument to "git merge @{u}"
From: Jeff King @ 2011-01-31 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Miles Bader
In-Reply-To: <7vzkqg4x2h.fsf_-_@alter.siamese.dyndns.org>
On Mon, Jan 31, 2011 at 12:50:30PM -0800, Junio C Hamano wrote:
> Perhaps I should start a new directory in todo branch (say, 1.8.0), accept
> patches from people? I'd grudgingly admit that using Wiki on k.org may be
> less burdensome (I hate editing inside the browser myself), but I'd want
> to keep the mailing list the center of discussion and am afraid that
> forcing people to go to Wiki would fragment the discussion.
I really wish we had a git-backed wiki. I also hate using the browser
for such things (though browser extensions to edit textareas in a Real
Editor at least make it tolerable, it still ends up clunky).
GitHub's wiki gets this right. I'm not saying we should host our wiki
there (well, it _would_ make setting it up pretty damn easy). But their
wiki system (gollum) is open-source, albeit in ruby. And surely there
are other git-backed alternatives (it's been a while since I've looked).
> Proposal:
> [...]
Well, I don't know this is still just an example, but your update looks
fine to me. :)
-Peff
^ permalink raw reply
* Re: [1.8.0] make two-argument fetch update remote branches
From: Junio C Hamano @ 2011-01-31 23:06 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Thomas Rast, git
In-Reply-To: <AANLkTin2kTW85UC1r_1LUDVLiexcVDvt--9ndnXZ2ARS@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> IMHO there is no need to introduce the variable. If it will start
> update both FETCH_HEAD and the remote-tracking branches since 1.8 it
> will not break any code, because it is added functionality...
Then you didn't understand the risks section, did you? Thomas clearly
illustrated with an example where the script _expects_ origin/master to
stay the same after "git fetch origin master".
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Jeff King @ 2011-01-31 23:12 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.1101311621150.8580@xanadu.home>
On Mon, Jan 31, 2011 at 04:28:49PM -0500, Nicolas Pitre wrote:
> > Besides being just one more directory to go up and down, it does make
> > history browsing more annoying. As much as I love git's "don't record
> > renames" philosophy, our handling of renames on the viewing side is
> > often annoying. I already get annoyed sometimes following stuff across
> > the s!builtin-!builtin/! change. This would be like that but more so.
>
> So... we do suck at something? So why not take this opportunity to
> shake yourself out of this easy comfort and improve Git as a result on
> both front? :-)
Yes, we do suck at rename following. The problem is that it is partially
an implementation issue, and partially a fundamental issue. Obviously
--follow sucks pretty hard right now, and that could be fixed. Namely it
follows only a single file, and it interacts very badly with history
simplification.
But even with those things fixed, there will still be annoyances.
It will still be _slower_ to turn it on all the time, for one[1]. And
that's due to fundamental design decisions of the git data structure.
And I'm not knocking those decisions; I think they made the right
tradeoff. But that doesn't mean we don't pay the cost for that tradeoff.
And no matter what your model, renames can be annoying. On-going topics
will have a painful rebase or merge. And people looking at history will
have to deal with the code-base having different names at different
points. Yeah, you can say it's all just "content", but the filenames we
put things in are actually useful.
So I don't think it's wrong to say "renames are a pain, and so should
not be done lightly". I do think it's wrong to say "renames can't be
done"; I just the cost needs to be considered.
-Peff
[1] I'd be interested to see how much we can get around that slowness
using a notes-cache.
^ permalink raw reply
* Re: [1.8.0] forbid full fetchspecs in git-pull
From: Dmitry Potapov @ 2011-01-31 23:15 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git, Sean Estabrooks, Björn Steinbrink
In-Reply-To: <201101312255.59841.trast@student.ethz.ch>
On Mon, Jan 31, 2011 at 10:55:59PM +0100, Thomas Rast wrote:
> Proposal:
>
> git-pull inherits the full fetchspec invocation syntax from git-fetch,
> so that you can do e.g.
>
> git pull origin master:master
>
> usually shooting yourself in the foot in the process. See e.g.
>
> http://thread.gmane.org/gmane.comp.version-control.git/130819/focus=130879 [item 1]
>
> Prohibit this invocation, i.e., disallow any second argument to
> git-pull that contains ':'.
Hmm... I have always thought about "git pull repo refspec" as
"git fetch repo refspec && git merge FETCH_HEAD"
and "git fetch" refuses to fetch into the current branch of a non-bare
repository, so I expected "git merge" to fail in this case too, but it
succeeded though with some warning that fetch updated the current
branch head. I think it is inconsistent and should be fixed, and that
will fix the mentioned confusion as well.
As to disallowing ':' in refspec completely, I am not so sure... Not
that I think it is very useful, but also I don't see how it can hurt
someone provided that the target branch cannot be the current branch.
Dmitry
^ permalink raw reply
* Re: [1.8.0] make two-argument fetch update remote branches
From: Jeff King @ 2011-01-31 23:22 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <201101312244.10047.trast@student.ethz.ch>
On Mon, Jan 31, 2011 at 10:44:09PM +0100, Thomas Rast wrote:
> Running "git fetch origin master" only updates FETCH_HEAD, not
> origin/master, which turns out to be quite confusing for newcomers
> especially after running 'git pull origin master'.
>
> Since the remote branches in some sense reflect the "last known state"
> of the remote, it would make sense to also update them to whatever a
> two-argument fetch got.
I like this one. FYI, I posted a patch in Aug 2009, and there was some
discussion about the impacts (it spills over into the sibling
subthreads):
http://article.gmane.org/gmane.comp.version-control.git/127215
I'm actually still carrying the patch in my repository (and using it
every day!). I guess I should get on polishing it up...
-Peff
^ permalink raw reply
* Re: [1.8.0] make two-argument fetch update remote branches
From: Eugene Sajine @ 2011-01-31 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vd3nc4qr6.fsf@alter.siamese.dyndns.org>
On Mon, Jan 31, 2011 at 6:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Eugene Sajine <euguess@gmail.com> writes:
>
>> IMHO there is no need to introduce the variable. If it will start
>> update both FETCH_HEAD and the remote-tracking branches since 1.8 it
>> will not break any code, because it is added functionality...
>
> Then you didn't understand the risks section, did you? Thomas clearly
> illustrated with an example where the script _expects_ origin/master to
> stay the same after "git fetch origin master".
>
I did understand what Thomas illustrated. I'm just thinking that the
range origin/master...FETCH_HEAD seems to be useful but in fact is
pretty useless, because you cannot guarantee the state of the
origin/master _before_ the fetch and therefore you cannot rely on the
results of range selections involving it.
By "guaranteeing the state" i mean that because of the current
implementation origin/master doesn't always mean/reflect the same
thing: it might be some _old_ and outdated push or it might be some
new state of the remote branch which are IMHO completely different
semantics.
That's exactly why it seems to me that it is important to always
update remote-tracking branches upon any related network operation. So
remote-tracking branch always represents the _same_ thing - the latest
state of the remote branch that you interacted with.
Thanks,
Eugene
^ permalink raw reply
* Re: [1.8.0] (v2) default "git merge" without argument to "git merge @{u}"
From: Thomas Adam @ 2011-02-01 0:01 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Miles Bader
In-Reply-To: <20110131225529.GC14419@sigill.intra.peff.net>
On 31 January 2011 22:55, Jeff King <peff@peff.net> wrote:
> On Mon, Jan 31, 2011 at 12:50:30PM -0800, Junio C Hamano wrote:
>
>> Perhaps I should start a new directory in todo branch (say, 1.8.0), accept
>> patches from people? I'd grudgingly admit that using Wiki on k.org may be
>> less burdensome (I hate editing inside the browser myself), but I'd want
>> to keep the mailing list the center of discussion and am afraid that
>> forcing people to go to Wiki would fragment the discussion.
>
> I really wish we had a git-backed wiki. I also hate using the browser
> for such things (though browser extensions to edit textareas in a Real
> Editor at least make it tolerable, it still ends up clunky).
You mean like ikiwiki (were it used on the main sites)?
http://ikiwiki.info
-- Thomas Adam
^ permalink raw reply
* Re: [RFC] fast-import: notemodify (N) command
From: Sverre Rabbelier @ 2011-02-01 0:13 UTC (permalink / raw)
To: Sam Vilain
Cc: Jonathan Nieder, vcs-fast-import-devs, git, chriscool,
Johannes.Schindelin, trast, Johan Herland, gitster, git,
Augie Fackler
In-Reply-To: <4D4739B5.6080103@vilain.net>
Heya,
On Mon, Jan 31, 2011 at 23:37, Sam Vilain <sam@vilain.net> wrote:
> This is not a "fact".
>
> If you add configuration in your git config to fetch and push the refs,
> then they are propagated.
Heh, I was contemplating whether to add "(by default)" or not, I guess
I should have.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [1.8.0] 't/' is standard name for directory with tests
From: Alex Budovski @ 2011-02-01 0:12 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.1101311728180.8580@xanadu.home>
>> Nope. 't/' is the standard name for directory with "normal" tests, at
>> least in Perl / CPAN land, where TAP comes from ('xt/' is for extra
>> tests)
>
> So what? It is not because Perl has set this horrible precedent that we
> have to perpetuate it. I personally never saw t used as a directory
> name for tests before Git, and I'm not that young anymore unfortunately.
The MySQL project (and its clones) also uses the t/ convention.
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Nicolas Pitre @ 2011-02-01 0:29 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20110131231210.GD14419@sigill.intra.peff.net>
On Mon, 31 Jan 2011, Jeff King wrote:
> On Mon, Jan 31, 2011 at 04:28:49PM -0500, Nicolas Pitre wrote:
>
> > So... we do suck at something? So why not take this opportunity to
> > shake yourself out of this easy comfort and improve Git as a result on
> > both front? :-)
>
> Yes, we do suck at rename following. The problem is that it is partially
> an implementation issue, and partially a fundamental issue. Obviously
> --follow sucks pretty hard right now, and that could be fixed. Namely it
> follows only a single file, and it interacts very badly with history
> simplification.
This is no excuse not to do proper source tree reorganization.
Telling people not to move files around because Git sucks at tracking
them is also the wrong answer.
> But even with those things fixed, there will still be annoyances.
>
> It will still be _slower_ to turn it on all the time, for one[1]. And
> that's due to fundamental design decisions of the git data structure.
> And I'm not knocking those decisions; I think they made the right
> tradeoff. But that doesn't mean we don't pay the cost for that tradeoff.
I agree. However sitting on our back and resisting a cleanup just
because our very tool does poorly in that scenario is just like putting
our heads in the sand and pretend that the problem doesn't exist.
Better do what most people without internal knowledge of Git would do
and just clean up the tree, and then benefit from this extraordinary
opportunity of having this environment right at home where Git
developers have a much greater incentive to work on this issue and
improve things.
> And no matter what your model, renames can be annoying. On-going topics
> will have a painful rebase or merge. And people looking at history will
> have to deal with the code-base having different names at different
> points. Yeah, you can say it's all just "content", but the filenames we
> put things in are actually useful.
Of course. But such is life. Many projects out there are just like
that, and facing this situation ourselves will just help us figure out
ways to make Git even more useful to more people.
> So I don't think it's wrong to say "renames are a pain, and so should
> not be done lightly".
I disagree. This is like saying: "renames are not well supported, so
let's avoid them while using Git." People used to say that of merges
with CVS. Are we going to follow suit de facto? Imagine the Git
detractors taking our source tree mess to exemplify this Git flaw since
"Git developers themselves are unwilling to move files around because
Git sucks at it".
> I do think it's wrong to say "renames can't be
> done"; I just the cost needs to be considered.
Instead, why not saying: "Rename tracking is not as optimal as it could
be, so let's work it out." ?
Nicolas
^ permalink raw reply
* Re: [1.8.0] 't/' is standard name for directory with tests
From: Nicolas Pitre @ 2011-02-01 0:33 UTC (permalink / raw)
To: Alex Budovski; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <AANLkTi=uOhgnKxRpA0Vm2uSe+uznPwjRB-=2e81VTf-f@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 650 bytes --]
On Tue, 1 Feb 2011, Alex Budovski wrote:
> >> Nope. 't/' is the standard name for directory with "normal" tests, at
> >> least in Perl / CPAN land, where TAP comes from ('xt/' is for extra
> >> tests)
> >
> > So what? It is not because Perl has set this horrible precedent that we
> > have to perpetuate it. I personally never saw t used as a directory
> > name for tests before Git, and I'm not that young anymore unfortunately.
>
> The MySQL project (and its clones) also uses the t/ convention.
OK, that makes for another one.
Now what about those hundred counter-example projects _not_ using "t"
but something more descriptive?
Nicolas
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Erik Faye-Lund @ 2011-02-01 0:35 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <20110131231210.GD14419@sigill.intra.peff.net>
On Tue, Feb 1, 2011 at 12:12 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Jan 31, 2011 at 04:28:49PM -0500, Nicolas Pitre wrote:
>
>> > Besides being just one more directory to go up and down, it does make
>> > history browsing more annoying. As much as I love git's "don't record
>> > renames" philosophy, our handling of renames on the viewing side is
>> > often annoying. I already get annoyed sometimes following stuff across
>> > the s!builtin-!builtin/! change. This would be like that but more so.
>>
>> So... we do suck at something? So why not take this opportunity to
>> shake yourself out of this easy comfort and improve Git as a result on
>> both front? :-)
>
> Yes, we do suck at rename following. The problem is that it is partially
> an implementation issue, and partially a fundamental issue. Obviously
> --follow sucks pretty hard right now, and that could be fixed. Namely it
> follows only a single file, and it interacts very badly with history
> simplification.
>
> But even with those things fixed, there will still be annoyances.
>
> It will still be _slower_ to turn it on all the time, for one[1]. And
> that's due to fundamental design decisions of the git data structure.
Does it really have to be? I mean, for whole-file rename-detection, if
we say that we automatically enable rename-detection (by default) as
we reach the first commit that doesn't have a given tree-entry, then
it would only kick in as we're about to terminate the log-output. And
since we're usually reading through a pager, it should means that it
takes a little bit more time before the user knows he's at the end of
the log. It shouldn't really affect the throughput of the data before
the point that becomes an annoyance, right?
At least that's the part that I find the most annoying with the
current rename detection; having to enable the flag as I reach the end
of the history for a file, often having to search through a lot of
commits again.
^ permalink raw reply
* Re: [1.8.0] 't/' is standard name for directory with tests
From: Jakub Narebski @ 2011-02-01 0:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Alex Budovski, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.1101311930280.8580@xanadu.home>
On Tue, 1 Feb 2011, Nicolas Pitre wrote:
> On Tue, 1 Feb 2011, Alex Budovski wrote:
>
> > >> Nope. 't/' is the standard name for directory with "normal" tests, at
> > >> least in Perl / CPAN land, where TAP comes from ('xt/' is for extra
> > >> tests)
> > >
> > > So what? It is not because Perl has set this horrible precedent that we
> > > have to perpetuate it. I personally never saw t used as a directory
> > > name for tests before Git, and I'm not that young anymore unfortunately.
CPAN is around 21000 distributions and 88000 modules. Most of those use
't/' for tests (default CPAN client to download and install modules runs
those tests before installing module).
> > The MySQL project (and its clones) also uses the t/ convention.
>
> OK, that makes for another one.
>
> Now what about those hundred counter-example projects _not_ using "t"
> but something more descriptive?
You mean those counter-example projects that use and include comprehensive
tests, isn't it?
Well, GCC uses 'testsuite/'. Mozilla uses 'testing/'.
--
Jakub Narebski
Poland
^ 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