* Re: GitTogether '09
From: Shawn O. Pearce @ 2009-03-18 16:11 UTC (permalink / raw)
To: Scott Chacon; +Cc: Sverre Rabbelier, Christian Couder, git, gittogether
In-Reply-To: <d411cc4a0903180905x1cb2a1c2j87922300dbf77e7b@mail.gmail.com>
Scott Chacon <schacon@gmail.com> wrote:
> On Wed, Mar 18, 2009 at 7:35 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > There is also the most popular issue of budgets. ??GitTogether '08
> > wasn't free for us. ??Its cheaper than anything we would get from a
> > conference venue/hotel outside the Googleplex, but it still was a
> > non-trivial sum. ??We simply may not have the funds for it this year.
>
> Let me know if I can help out at all. If Google doesn't want to host
> it, but everyone still wants to string together the GSOC summit and
> this, I'm sure GitHub can find a nice venue for us and get some food
> and whatnot. Or, if we can simply 'sponsor' it or something - give
> the Goog money to host it for us, however that might work. We want to
> help this happen again this year, so keep me in the loop and we can
> make sure it gets handled somehow.
Hey Scott, thanks. FWIW, Google doesn't co-sponsor events. So if we
do host it, we'll cover everything like we did last year, but maybe
GitHub can sponsor an off-site dinner again, like it did last year.
But perhaps this year you guys could select the venue for that. :-)
Anyway, today is not the best day to go asking for budget and time
from LH (big GSoC announcement today). Give me a week or two to
figure out if Google can host us here or in Portland. FWIW, last
year Portland around the Linux Plumbers conference was tossed out
as an option, but it was too close calendar wise to be possible
for planning purposes.
--
Shawn.
^ permalink raw reply
* Re: GitTogether '09
From: Scott Chacon @ 2009-03-18 16:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Sverre Rabbelier, Christian Couder, git, gittogether
In-Reply-To: <20090318143532.GD23521@spearce.org>
Hey,
On Wed, Mar 18, 2009 at 7:35 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> On Wed, Mar 18, 2009 at 08:05, Christian Couder <chriscool@tuxfamily.org> wrote:
>> > I thought that it was only one international airplane ticket last year,
>> > except perhaps when there are no US based mentor. And we are not sure that
>> > Google or another company in the Bay Area will be able to host us this
>> > year. So the cost of hosting the GitTogether might be higher than the cost
>> > of a few airplane tickets.
>>
>> Last year Google provided two international airplane tickets and was
>> able to host us, we can at least ask them to host us again this year
>> (if that is what we decide on).
>
> Did Google do two international tickets last year for Git? Hmm,
> don't go spreading that word around. Very few groups got that
> amount of travel money for the mentor summit. Maybe none others.
>
> IMHO, _if_ Git is accepted this year, and _if_ the mentor summit is
> held this fall as it has been in the past, Google will most likely
> cover only one ticket, especially if we actually also supported a
> GitTogether immediately after.
>
>> Shawn, how likely is it that Google will provide hosting for another
>> GitTogether this year?
>
> I will ask.
>
> Last year it was difficult on LH. Despite the fact that most of
> the attendees probably never even met her, she put a lot of work
> into the GitTogether behind the scenes. Without her efforts,
> the GitTogether simply would not have happened here.
>
> It was also *immediately* after the biggest event of the year
> that she and her team run (GSoC mentor summit), and really close
> to two other very big events that they run. They were working
> pretty much 7 days a week for over 3 months straight, and were
> really looking forward to some time off when I threw GitTogether
> '08 into their calendar.
>
> I'm not sure I can ask LH to put her and her team through that again.
> I want to continue living. :-)
>
> There is also the most popular issue of budgets. GitTogether '08
> wasn't free for us. Its cheaper than anything we would get from a
> conference venue/hotel outside the Googleplex, but it still was a
> non-trivial sum. We simply may not have the funds for it this year.
Let me know if I can help out at all. If Google doesn't want to host
it, but everyone still wants to string together the GSOC summit and
this, I'm sure GitHub can find a nice venue for us and get some food
and whatnot. Or, if we can simply 'sponsor' it or something - give
the Goog money to host it for us, however that might work. We want to
help this happen again this year, so keep me in the loop and we can
make sure it gets handled somehow.
Scott
>
> --
> Shawn.
> --
> 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
>
^ permalink raw reply
* Re: [EGIT RFC PATCH(was Re: egit problem with sym linked eclipse project dirs)] Add some support for symlinked projects.
From: Stephen Bannasch @ 2009-03-18 16:02 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, git
In-Reply-To: <200903120756.07853.robin.rosenberg.lists@dewire.com>
At 7:56 AM +0100 3/12/09, Robin Rosenberg wrote:
>torsdag 12 mars 2009 03:57:09 skrev Stephen Bannasch
><stephen.bannasch@deanbrook.org>:
>> OK ... I'm a bit confused now because I no longer have Git listed as
>> a repository type for Team Sharing.
>>
> > I deleted the existing org.spearce.* eclipse plugins
...
> > The new plugins are there:
>>
>> [eclipse]$ ls plugins/org.spearce.*
>> plugins/org.spearce.egit.core.test_0.4.0.200903112237.jar
>> plugins/org.spearce.egit_0.4.0.200903112237.jar
>> plugins/org.spearce.egit.core_0.4.0.200903112237.jar
>> plugins/org.spearce.jgit_0.4.0.200903112237.jar
>> plugins/org.spearce.egit.ui_0.4.0.200903112237.jar
>>
>> Quit and restarted Eclipse.
>>
>> When I select a project with an existing git repository and try to
>> enable team/sharing only CVS and SVN are listed.
>
>You don't have the a matching feature. That could be it, but I'm not sure.
>You can also try starting eclipse witth the -clean switch. Looking at the
><workspace>/.metadata/.log could also give you some hints.
I figured out the problem I had when testing the patched egit plugin.
If I had installed egit from the update site I had to do more than
just delete the jars -- I had to delete the whole feature from within
Eclipse -- and then install the new plugin built from source.
In figuring this out I ended up testing the original problem with the
master branch from earlier today and didn't see the issue I
originally reported.
Did you already integrate the experimental patch?
Here's a documentation patch:
From feb1ae0ccf7f671506853f4f49e9041950404b3d Mon Sep 17 00:00:00 2001
From: Stephen Bannasch <stephen.bannasch@gmail.com>
Date: Wed, 18 Mar 2009 11:51:56 -0400
Subject: [PATCH] clarify how to delete egit plugin when installing new build
---
EGIT_INSTALL | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/EGIT_INSTALL b/EGIT_INSTALL
index 3a8f249..3a9c209 100644
--- a/EGIT_INSTALL
+++ b/EGIT_INSTALL
@@ -21,7 +21,16 @@ things.
INSTALLATION INSTRUCTIONS
-- Delete any old versions of the plugin in the
<eclipse-path>/plugins/org.spearce.*
+First remove any existing egit plugin.
+
+If you have installed egit from the egit update site
http://www.jgit.org/update-site:
+
+ delete the plugin from Software Updates and Add-ons from within Eclipse
+
+If you have installed the plugin from source:
+
+ delete any old versions of the plugin jars in the
<eclipse-path>/plugins/org.spearce.*
+
- Start eclipse
- Make sure a recent JDK 1.5.0_11 or JDK 1.6.x is among your
installed JRE's. Which
one is the default should not matter but Java 6 is recommended.
--
1.6.1.2
>For debugging/testing in general it is often easier to launch Eclipse from
>eclipse (Run As) without reinstalling.
As part of this test I need to switch to another workspace and I
couldn't get that working with "Run As".
^ permalink raw reply related
* Re: [PATCH] gc --aggressive: make it really aggressive
From: Johannes Schindelin @ 2009-03-18 16:01 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <Pine.LNX.4.64.0712061201580.27959@racer.site>
Hi,
On Thu, 6 Dec 2007, Johannes Schindelin wrote:
>
> The default was not to change the window or depth at all. As suggested
> by Jon Smirl, Linus Torvalds and others, default to
>
> --window=250 --depth=250
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
Guess what. This is still unresolved, and yet somebody else had to be
bitten by 'git gc --aggressive' being everything but aggressive.
So... I think it is high time to resolve the issue, either by applying
this patch with a delay of over one year, or by the pack wizards trying to
implement that 'never fall back to a worse delta' idea mentioned in this
thread.
Although I suggest, really, that implying --depth=250 --window=250 (unless
overridden by the config) with --aggressive is not at all wrong.
Ciao,
Dscho
^ permalink raw reply
* Re: GitTogether '09
From: Shawn O. Pearce @ 2009-03-18 15:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Christian Couder, git, gittogether
In-Reply-To: <alpine.DEB.1.00.0903181551380.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 18 Mar 2009, Shawn O. Pearce wrote:
> >
> > Did Google do two international tickets last year for Git?
>
> I do not think so. Mugwump got the international airplane ticket, AFAIR,
> and warthog the local "ticket".
Oh, so it was two tickets.
Mugwump and Sverre flew on Google's dime. The reason Sverre was
invited was his already heavy involvement with Melange.
Google initially asked me to spend our international ticket on
Sverre only, but I talked them into including Mugwump too once I
pointed out Sverre was attending for Google's own selfish reasons
(Melange) and not to represent Git.
warthog9 is a local. Local mentors were accepted en-masse near
the end of registration when a lot of orgs had open mentor slots.
You flew on your own dime. I'm local. David also managed to fly
on Google's dime, but out of his manager's business travel budget
and not the Summer of Code budget.
--
Shawn.
^ permalink raw reply
* Re: Rebasing local patches
From: Johannes Schindelin @ 2009-03-18 15:48 UTC (permalink / raw)
To: Nicolas Morey-Chaisemartin; +Cc: git@vger.kernel.org
In-Reply-To: <49BA0DBB.7000700@morey-chaisemartin.com>
Hi,
On Fri, 13 Mar 2009, Nicolas Morey-Chaisemartin wrote:
> >> I noticed that when the branch was rebased on the centralized and
> >> repo and origin/our_patches is up-to-date in mine.
> >>
> >> If I checkout another branch and then ckecout our_branches, I got a
> >> message telling my our_patches and the one from the server have
> >> diverged (or you are two commits behind...).
> >>
> >> How can you get this info directly without leaving/rejoining your
> >> branch?
> >
> > It is also part of "git status"' output.
>
> Is there some option to just get the status of HEAD against tracked
> branch and not the index status? I guess I could do an alias but an
> option would be nicer ;)
Just try "git checkout".
Ciao,
Dscho
^ permalink raw reply
* Re: fetch and pull
From: Björn Steinbrink @ 2009-03-18 15:31 UTC (permalink / raw)
To: John Dlugosz; +Cc: Nanako Shiraishi, git, Junio C Hamano
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A3FC468@EXCHANGE.trad.tradestation.com>
On 2009.03.18 11:18:41 -0400, John Dlugosz wrote:
> > 2) I don't think that's a common setup, and it's not a default
> > setup, so that hardly qualifies for "normally".
>
> How many users of git on a team have it set up by someone who already
> knows what he's doing? I think bad or broken setups might be more
> common. For example, I didn't have any "fetch" setting under remote
> until I started reading this list and digging in more.
Hm? Both clone and "remote add" setup the fetch line by default. So you
manually adjusted the config to add the remote as just an url alias? I'm
not convinced that such manual config changes are "normal" either. At
least you're most likely the first user from which I've heard that he
did that.
Björn
^ permalink raw reply
* RE: fetch and pull
From: John Dlugosz @ 2009-03-18 15:18 UTC (permalink / raw)
To: Björn Steinbrink, Nanako Shiraishi; +Cc: git, Junio C Hamano
In-Reply-To: <20090318085849.GA8118@atjola.homenet>
> 2) I don't think that's a common setup, and it's not a default setup,
> so
> that hardly qualifies for "normally".
How many users of git on a team have it set up by someone who already knows what he's doing? I think bad or broken setups might be more common. For example, I didn't have any "fetch" setting under remote until I started reading this list and digging in more. And the upstream repository is not bare.
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: Ability to edit message from git rebase --interactive.
From: Marcel M. Cary @ 2009-03-18 14:52 UTC (permalink / raw)
To: Michael J Gruber
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Johannes Schindelin,
Olivier Goffart, git@vger.kernel.org
In-Reply-To: <49C0C4C5.5070802@drmicha.warpmail.net>
Michael J Gruber wrote:
> Sverre Rabbelier venit, vidit, dixit 18.03.2009 06:42:
>> Heya,
>>
>> On Wed, Mar 18, 2009 at 02:06, Junio C Hamano <gitster@pobox.com> wrote:
>>> Jeff King <peff@peff.net> writes:
>>> I am not quite sure what rephrase is buying us. Do we also want to
>>> introduce retree that allows you to muck with the tree object recorded
>>> without giving you a chance to clobber the commit log message?
>> Is that a common operation? Rephrase is, at least to me...
>>
>
> Rephrase for sure is common, and for sure can be done currently... It's
> only that "commit --amend, save&quit, continue" could be shortened.
>
> OTOH: Most commonly one would want to rephrase a commit message or two
> without actually rebasing anything. And the proposed change doesn't help
> as much as it could, in two respects:
>
> 1) I want to be able to say "rephrase HEAD~2" without having to edit a
> rebase action script. (That would be useful for rewriting a single
> commit as well, and could be added easily.)
>
> 2) Currently, all rebasing operations have trouble with merges. But if
> all I want to do is rephrasing a log message then no diff/apply is
> necessary, no rewriting of trees, no change in the DAG structure (i.e.
> connectivity; sha1s change, of course). So there should be a special
> mode for DAG-preserving rewrites, where one can be sure that merges are
> fully preserved.
>
> 2) seems to be the most important point to make rephrasing safe and
> convenient.
Interesting points about skipping the action script and preserving
structure. I just tried to do something like that with filter-branch:
git filter-branch --msg-filter 'cat > tmp; $EDITOR tmp < '$(tty)' >
'$(tty)' 2>&1; cat tmp' ^HEAD^ HEAD
And discovered that it will neither accept "HEAD^^..HEAD^" nor "HEAD^"
as a shortcut for a rev-list containing a single commit. But if you're
content to save and quit each message through the branch tip and specify
the range, it seems to work.
I have no idea what it would take to make filter-branch support the
additional kinds of rev and rev list specifications, or if that would be
undesirable.
I'm assuming it accomplishes (2) because of the nature of filter-branch.
Marcel
^ permalink raw reply
* Re: GitTogether '09
From: Johannes Schindelin @ 2009-03-18 14:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Sverre Rabbelier, Christian Couder, git, gittogether
In-Reply-To: <20090318143532.GD23521@spearce.org>
Hi,
On Wed, 18 Mar 2009, Shawn O. Pearce wrote:
> Sverre Rabbelier <srabbelier@gmail.com> wrote:
> > On Wed, Mar 18, 2009 at 08:05, Christian Couder <chriscool@tuxfamily.org> wrote:
> > > I thought that it was only one international airplane ticket last
> > > year, except perhaps when there are no US based mentor. And we are
> > > not sure that Google or another company in the Bay Area will be able
> > > to host us this year. So the cost of hosting the GitTogether might
> > > be higher than the cost of a few airplane tickets.
> >
> > Last year Google provided two international airplane tickets and was
> > able to host us, we can at least ask them to host us again this year
> > (if that is what we decide on).
>
> Did Google do two international tickets last year for Git?
I do not think so. Mugwump got the international airplane ticket, AFAIR,
and warthog the local "ticket".
Ciao,
Dscho
^ permalink raw reply
* Re: GitTogether '09
From: Shawn O. Pearce @ 2009-03-18 14:35 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Christian Couder, git, gittogether
In-Reply-To: <fabb9a1e0903180254u5569e9f5u5e1aa43fa2d1d178@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Wed, Mar 18, 2009 at 08:05, Christian Couder <chriscool@tuxfamily.org> wrote:
> > I thought that it was only one international airplane ticket last year,
> > except perhaps when there are no US based mentor. And we are not sure that
> > Google or another company in the Bay Area will be able to host us this
> > year. So the cost of hosting the GitTogether might be higher than the cost
> > of a few airplane tickets.
>
> Last year Google provided two international airplane tickets and was
> able to host us, we can at least ask them to host us again this year
> (if that is what we decide on).
Did Google do two international tickets last year for Git? Hmm,
don't go spreading that word around. Very few groups got that
amount of travel money for the mentor summit. Maybe none others.
IMHO, _if_ Git is accepted this year, and _if_ the mentor summit is
held this fall as it has been in the past, Google will most likely
cover only one ticket, especially if we actually also supported a
GitTogether immediately after.
> Shawn, how likely is it that Google will provide hosting for another
> GitTogether this year?
I will ask.
Last year it was difficult on LH. Despite the fact that most of
the attendees probably never even met her, she put a lot of work
into the GitTogether behind the scenes. Without her efforts,
the GitTogether simply would not have happened here.
It was also *immediately* after the biggest event of the year
that she and her team run (GSoC mentor summit), and really close
to two other very big events that they run. They were working
pretty much 7 days a week for over 3 months straight, and were
really looking forward to some time off when I threw GitTogether
'08 into their calendar.
I'm not sure I can ask LH to put her and her team through that again.
I want to continue living. :-)
There is also the most popular issue of budgets. GitTogether '08
wasn't free for us. Its cheaper than anything we would get from a
conference venue/hotel outside the Googleplex, but it still was a
non-trivial sum. We simply may not have the funds for it this year.
--
Shawn.
^ permalink raw reply
* Re: Suggested Workflow Question
From: Robin Rosenberg @ 2009-03-18 13:52 UTC (permalink / raw)
To: Roger Garvin; +Cc: git
In-Reply-To: <loom.20090318T125717-946@post.gmane.org>
onsdag 18 mars 2009 14:00:51 skrev Roger Garvin <yoyodyn@gmail.com>:
> Martin Langhoff <martin.langhoff <at> gmail.com> writes:
>
> > We've done a ton of that. Even better than emailing is that you can
> > have a repo on a usb stick/disk.
> >
>
> That would be great except that most of our customers do not technically allow
> us to plug USB drives into any of their computers. It's a rather silly rule
> actually but the drives could be confiscated.
>
> Thank you for the links to the other thread. I will read through those today.
> I am hoping that this is simpler in practice than it looks on paper, cause what
> I see on paper is a fully connected graph of all our employees with all our
> customers multiple source locations and with our office server. It seems like
> it could get out of control for tracking where changes might be (who is holding
> them)
Don't forget the option of mailing bundles (man git-bundle). Those will give the effect of push/fetch via e-mail. I.e. the exact same commit SHA's get replicated, That may be relevant for the branches that contain your released/official test code.
-- robin
^ permalink raw reply
* Git-shell do not work when git is not installed in PATH
From: Gustaf Gunnarsson @ 2009-03-18 13:16 UTC (permalink / raw)
To: git
Hi,
git-shell is unable to spawn git-receive-pack, git-upload-pack and
git-cvsserver when git is not installed in PATH.
As far as I understund it is impossible to get
git_extract_argv0_path() to work when using git-shell and the only
path the actually works to use is GIT_EXEC_PATH. Hence, could the
defaults be changed so that git is also installed in GIT_EXEC_PATH or
is there some better solution?
//Gustaf
^ permalink raw reply
* Re: Suggested Workflow Question
From: Roger Garvin @ 2009-03-18 13:00 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90903172141o7b272c17v2c485bb66b529fe8@mail.gmail.com>
Martin Langhoff <martin.langhoff <at> gmail.com> writes:
> We've done a ton of that. Even better than emailing is that you can
> have a repo on a usb stick/disk.
>
That would be great except that most of our customers do not technically allow
us to plug USB drives into any of their computers. It's a rather silly rule
actually but the drives could be confiscated.
Thank you for the links to the other thread. I will read through those today.
I am hoping that this is simpler in practice than it looks on paper, cause what
I see on paper is a fully connected graph of all our employees with all our
customers multiple source locations and with our office server. It seems like
it could get out of control for tracking where changes might be (who is holding
them)
Roger Garvin
^ permalink raw reply
* t5505-remote fails on Windows
From: Johannes Sixt @ 2009-03-18 11:42 UTC (permalink / raw)
To: Jay Soffian; +Cc: Git Mailing List
I see this failure related to 'git remote show':
* expecting success:
(cd test &&
git config --add remote.origin.fetch
refs/heads/master:refs/heads/upstream &&
git fetch &&
git checkout -b ahead origin/master &&
echo 1 >> file &&
test_tick &&
git commit -m update file &&
git checkout master &&
git branch --track octopus origin/master &&
git branch --track rebase origin/master &&
git branch -d -r origin/master &&
git config --add remote.two.url ../two &&
git config branch.rebase.rebase true &&
git config branch.octopus.merge "topic-a topic-b topic-c" &&
(cd ../one &&
echo 1 > file &&
test_tick &&
git commit -m update file) &&
git config --add remote.origin.push : &&
git config --add remote.origin.push
refs/heads/master:refs/heads/upstream &&
git config --add remote.origin.push +refs/tags/lastbackup &&
git config --add remote.two.push
+refs/heads/ahead:refs/heads/master &&
git config --add remote.two.push
refs/heads/master:refs/heads/another &&
git remote show origin two > output &&
git branch -d rebase octopus &&
test_cmp expect output)
>From d:/Src/mingw-git/t/trash directory.t5505-remote/one
* [new branch] master -> upstream
Branch ahead set up to track remote branch refs/remotes/origin/master.
Switched to a new branch "ahead"
[ahead 847549e] update
1 files changed, 1 insertions(+), 0 deletions(-)
Switched to branch "master"
Branch octopus set up to track remote branch refs/remotes/origin/master.
Branch rebase set up to track remote branch refs/remotes/origin/master.
Deleted remote branch origin/master (9d34b14).
[master 6329a3c] update
1 files changed, 1 insertions(+), 0 deletions(-)
error: src refspec refs/tags/lastbackup does not match any.
Deleted branch rebase (9d34b14).
Deleted branch octopus (9d34b14).
--- expect Wed Mar 18 11:22:53 2009
+++ output Wed Mar 18 11:22:54 2009
@@ -12,8 +12,8 @@
and with remote topic-c
rebase rebases onto remote master
Local refs configured for 'git push':
- master pushes to master (local out of date)
master pushes to upstream (create)
+ master pushes to master (local out of date)
* remote two
URL: ../two
HEAD branch (remote HEAD is ambiguous, may be one of the following):
* FAIL 8: show
As you can see, the entries for "master pushes to..." are reversed. It
seems that this output is not stable. Before I delve into this, do you
know whether there is some data structure involved that does not guarantee
the order? Such as a hash table, a opendir/readdir sequence, or perhaps
while reading the config file?
It looks like we have to explicitly sort the list somewhere.
-- Hannes
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Johannes Schindelin @ 2009-03-18 11:44 UTC (permalink / raw)
To: Allan Caffee; +Cc: git
In-Reply-To: <20090318100512.GA7932@linux.vnet>
Hi,
On Wed, 18 Mar 2009, Allan Caffee wrote:
> I know that _some_ people arn't particularly fond of colors, but I was
> wondering how difficult it would be to colorize the edges on the --graph
> drawn by the log command? It can be a little tricky trying to follow
> them with a relatively complex history. I was thinking something like
> gitk already does.
That's a good idea! (And it is mentioned as a TODO in graph.c...)
> Is anybody else interested in seeing this?
Count me in. Are you interested in implementing this?
If so:
- you need to #include "color.h" in graph.c
- you need to insert a color identifier into struct column (there is an
XXX comment at the correct location)
- you need to find a way to determine colors for the branches
- you need to put the handling into the function
graph_output_pre_commit_line() in graph.c (and probably
graph_output_commit_char(), graph_output_post_merge_line(),
graph_output_collapsing_line(), graph_padding_line(), and
graph_output_padding_line(), too)
- it would make sense IMHO to introduce a new function that takes a
pointer to an strbuf, a pointer to a struct column and a char (or maybe
a string) that adds the appropriately colorized char (or string) to the
strbuf
- use the global variable diff_use_color to determine if the output should
be colorized at all
- probably you need to make an array of available colors or some such
(which might be good to put into color.[ch])
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] MinGW: implement mmap
From: Johannes Schindelin @ 2009-03-18 11:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List, Janos Laube
In-Reply-To: <49C0A462.3060902@kdbg.org>
Hi,
On Wed, 18 Mar 2009, Johannes Sixt wrote:
> From: Janos Laube <janos.dev@gmail.com>
> Date: Fri, 13 Mar 2009 16:50:45 +0100
>
> Add USE_WIN32_MMAP which triggers the use of windows' native
> file memory mapping functionality in git_mmap()/git_munmap() functions.
>
> As git functions currently use mmap with MAP_PRIVATE set only, this
> implementation supports only that mode for now.
>
> On Windows, offsets for memory mapped files need to match the allocation
> granularity. Take this into account when calculating the packed git-
> windowsize and file offsets. At the moment, the only function which makes
> use of offsets in conjunction with mmap is use_pack() in sha1-file.c.
>
> Git fast-import's code path tries to map a portion of the temporary
> packfile that exceeds the current filesize, i.e. offset+length is
> greater than the filesize. The NO_MMAP code worked with that since pread()
> just reads the file content until EOF and returns gracefully, while
> MapViewOfFile() aborts the mapping and returns 'Access Denied'.
> Working around that by determining the filesize and adjusting the length
> parameter.
>
> Signed-off-by: Janos Laube <janos.dev@gmail.com>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
In case anybody wonders why this is not integrated into mingw.[ch]: I
asked for it, as it is Windows-specific and could benefit Cygwin (or MSVC,
should someone attempt that), too.
And I think I missed this style in the patch:
> +void *git_mmap
> +(void *start, size_t length, int prot, int flags, int fd, off_t offset)
> +{
... which I would like to see fixed, of course... :-)
Unfortunately, there is also a long line, which is corrupted due to
wrapping:
> + hmap = CreateFileMapping((HANDLE)_get_osfhandle(fd), 0,
> PAGE_WRITECOPY,
> + 0, 0, 0);
It is easily fixed by moving the PAGE_WRITECOPY to the next line.
These are only style issues, though.
The more important part is: how much does this buy us (or is it more
expensive, as we saw one MacOSX at one stage). Janos was nice enough to
perform some benchmark tests, and saw a ~40% improvement on rev-list
--objects --all on a sizeable project (GCC 'twas, IIRC). Funnily, the
numbers got better when reducing the window, up until 1MB, and they got
worse when enlarging the window.
So I guess there will be a follow-up patch at some stage which changes the
default pack window size on Windows to something smaller than 64MB.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] contrib/difftool: use a separate config namespace for difftool commands
From: Wincent Colaiuta @ 2009-03-18 10:53 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, markus.heidelberg, Jay Soffian, git
In-Reply-To: <20090318043543.GB13653@gmail.com>
El 18/3/2009, a las 5:35, David Aguilar escribió:
> Junio C Hamano <gitster@pobox.com> wrote:
>> Markus Heidelberg <markus.heidelberg@web.de> writes:
>>
>>> Jay Soffian <jaysoffian@gmail.com> wrote:
>>>>
>>>> Aside, (for Junio I guess...), what's the reason this command is in
>>>> contrib, and by what criteria might it graduate to being installed
>>>> with the rest of the git commands?
>>>>
>>>> j.
>>>
>>> I'd like to see it as a general git tool, too.
>>> Maybe it can even share some common functionality with git-
>>> mergetool.
>>
>> The code was copied and pasted very heavily, and I think (IIRC) the
>> author
>> was a bit too ashamed to have it outside contrib/ before it is
>> properly
>> refactored or something like that. Which I happen to agree with,
>> by the
>> way.
>
> I'll work on some patches to get the ball rolling on this.
>
>
> Here's what I see as the steps I would take:
>
> 1. move difftool into the root, update Makefile, etc.
>
> 2. factor out the similarities between merge/difftool and
> put them in maybe git-tool-lib.sh?
Given that git-difftool shares basically all the same options as "git
diff", I think a good long-term plan would be looking at adding the "--
tool" option to "git diff" itself so that users wouldn't have to learn
a new subcommand, just a new option.
(Whether this is done by rolling the functionality of "git-difftool"
into "git diff" itself, or delegating to a separate "git-difftool"
command doesn't matter so much, now that most commands are neatly
tucked away in $(git --exec-path) now.)
Cheers,
Wincent
^ permalink raw reply
* Re: submodules inside submodules?
From: Matthias Nothhaft @ 2009-03-18 10:28 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200903181046.54556.johan@herland.net>
2009/3/18 Johan Herland <johan@herland.net>:
> On Tuesday 17 March 2009, Johannes Schindelin wrote:
>> On Tue, 17 Mar 2009, Matthias Nothhaft wrote:
>> > can I put submodules into submodules?
>>
>> Yes.
>
> However, initializing them is a bit clunky, as Git will only init/update one
> "level" of submodules at a time. In other words, a single "git submodule
> update --init" will only intialize the first level of submodules. You will
> have to redo that command within submodules that have their own (i.e.
> nested) submodules.
Oh, thanks for that hint.
regards,
Matthias
^ permalink raw reply
* Re: [PATCH] Define a version of lstat(2) specially for copy operation
From: Johannes Sixt @ 2009-03-18 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Jeff King, layer, git
In-Reply-To: <7v8wn3i3ee.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> I've always thought core.filemode was about "On FAT the filesystem does
> not have x-bit and Cygwin fakes it by looking at .exe extension and using
> other heuristics", but this lstat() "trick" is not about that. It is "On
> Windows you need to issue multiple FS API calls in order to get full
> information to fill struct stat, which is expensive. We omit the one to
> learn about the x-bit; it won't make a difference because most people run
> with core.filemode."
>
> If that is what is going on, I have a few quick questions:
>
> (1) How much of "struct stat" information can you get with the easiest
> and quickest FS API call on Windows? Does it give you big enough
> subset of what we store in the cache entry to detect modification
> reliably?
Yes.
> (2) When you do an equivalent of "chmod +x path" on Windows, does it
> change one of the fields in your answer to (1)? In other words, can
> you detect such a change with the fastest and reliable-enough FS API
> call?
Unfortunately, no. That's why we have this discussion.
> If answers to both questions are "yes", then I suspect we might be able to
> improve the situation without sacrificing performance too much.
>
> In the generic part, we use lstat(2) for various purposes:
>
> * To learn existence and type of a FS entity, in order to decide if we
> need to descend into a directory or treat it as a blob;
The fast version does not detect Cygwin's symbolic links, hence, not all
types of FS entity that we are interested in are covered.
> * To learn the current "status" that can be compared with what is stored
> in the cache entry, in order to decide if the FS entity hasn't been
> modified;
>
> * To learn the last-modified timestamp, in order to implement the
> racy-git avoidance logic;
>
> * To learn x-bit, so that we can update it in the cache entry, and give
> the appropriate x-bit to a file that we create (Alex's
> lstat_for_copy() is about this usage).
>
> If the first three can be learned with a fast-and-reliable-enough FS API
> call, and the x-bit and perhaps something else that do not fall into the
> first three need a lot more work to figure out, we could split lstat()
> into two. The result from a "fast" variant of lstat() is used for the
> first three and allow platform implementation of it to be incomplete
> (i.e. the Cygwin "trick" to omit x-bit is OK for that purpose), and add
> another "slow" variant to complement it:
Sorry that I skip your elaboration on this. First, I barely understand
read-cache.c; and second, I have the feeling that this is
over-engineering: It introduces a genericity that we don't need in
practice. We don't need it because Cygwin by default is built with
NO_TRUSTABLE_FILEMODE, and the X-bit is uninteresting in this case anyway
[*]. And there is no other platform that would make use of it. Not even
the MinGW port, because it wouldn't have a "slow" part, either.
[*] Ok, Cygwin's slow part would also recognize symbolic links, but we
haven't heard complaints about the fast lstat() implementation in this
respect. Perhaps because we have an escape door for people who need it
(core.ignorecygwinfstricks=false).
> And if we do not need such an extra "struct gitstat", then there is no
> reason for us to introduce lstat_fast(). We can just use lstat(), keep
> the "fast and incomplete" Cygwin one as lstat(), but insert calls to
> lstat_remainder() at strategic places. Immediately before copy_file() is
> called in builtin-init-db.c::copy_templates_1() would be one of those
> strategic places.
But that wouldn't be different in principle from Alex's patch that
introduced lstat_for_copy(), would it? Since it would be used in exactly
the same strategic places.
-- Hannes
^ permalink raw reply
* [RFC] Colorization of log --graph
From: Allan Caffee @ 2009-03-18 10:05 UTC (permalink / raw)
To: git
I know that _some_ people arn't particularly fond of colors, but I was
wondering how difficult it would be to colorize the edges on the
--graph drawn by the log command? It can be a little tricky trying to
follow them with a relatively complex history. I was thinking something
like gitk already does. Is anybody else interested in seeing this?
~Allan
^ permalink raw reply
* Re: Local clone checks out wrong branch based on remote HEAD
From: Michael J Gruber @ 2009-03-18 10:05 UTC (permalink / raw)
To: Jeff King; +Cc: Tom Preston-Werner, git
In-Reply-To: <20090318005413.GC25454@coredump.intra.peff.net>
Jeff King venit, vidit, dixit 18.03.2009 01:54:
> On Tue, Mar 17, 2009 at 12:19:35PM -0700, Tom Preston-Werner wrote:
>
>> After cloning this with a standard `git clone`, the refs are:
>>
>> [11:48][tom@solid:~/dev/sandbox/site(release)]$ git branch -r -v
>> origin/HEAD a52528a Fixed some routing problems
>> origin/release a52528a Fixed some routing problems
>> origin/trunk a52528a Fixed some routing problems
>>
>> And the checked out branch is 'release' instead of 'trunk' as I would expect:
>
> As others have explained, this is because the information is lacking at
> the client and we are forced to make a guess. There is a heuristic in
> the guess to prefer "master" if it is an option. I suppose we could make
> a similar exception for "trunk", which might make sense to people
> working with SVN repositories.
>
> OTOH, I am not sure I want to open the can of worms that is writing an
> exhaustive list of heuristics that will work for everybody. Fixing the
> protocol itself would probably be easier. :)
One might even argue that in case of ambiguities, checking out a
detached head would be most appropriate. Really, why impose creation of
certain local branches on a user at all, unless asked for? Detached
heads are natural in git! But I don't really expect positive consensus
on that one...
Michael
^ permalink raw reply
* Re: GitTogether '09
From: Sverre Rabbelier @ 2009-03-18 9:54 UTC (permalink / raw)
To: Christian Couder, Shawn O. Pearce; +Cc: git, gittogether
In-Reply-To: <200903180805.32440.chriscool@tuxfamily.org>
Heya,
On Wed, Mar 18, 2009 at 08:05, Christian Couder <chriscool@tuxfamily.org> wrote:
> I thought that it was only one international airplane ticket last year,
> except perhaps when there are no US based mentor. And we are not sure that
> Google or another company in the Bay Area will be able to host us this
> year. So the cost of hosting the GitTogether might be higher than the cost
> of a few airplane tickets.
Last year Google provided two international airplane tickets and was
able to host us, we can at least ask them to host us again this year
(if that is what we decide on).
Shawn, how likely is it that Google will provide hosting for another
GitTogether this year?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Ability to edit message from git rebase --interactive.
From: Michael J Gruber @ 2009-03-18 9:54 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Olivier Goffart,
git
In-Reply-To: <fabb9a1e0903172242v6f67aa9er40fe0ae2a2db7bc3@mail.gmail.com>
Sverre Rabbelier venit, vidit, dixit 18.03.2009 06:42:
> Heya,
>
> On Wed, Mar 18, 2009 at 02:06, Junio C Hamano <gitster@pobox.com> wrote:
>> Jeff King <peff@peff.net> writes:
>> I am not quite sure what rephrase is buying us. Do we also want to
>> introduce retree that allows you to muck with the tree object recorded
>> without giving you a chance to clobber the commit log message?
>
> Is that a common operation? Rephrase is, at least to me...
>
Rephrase for sure is common, and for sure can be done currently... It's
only that "commit --amend, save&quit, continue" could be shortened.
OTOH: Most commonly one would want to rephrase a commit message or two
without actually rebasing anything. And the proposed change doesn't help
as much as it could, in two respects:
1) I want to be able to say "rephrase HEAD~2" without having to edit a
rebase action script. (That would be useful for rewriting a single
commit as well, and could be added easily.)
2) Currently, all rebasing operations have trouble with merges. But if
all I want to do is rephrasing a log message then no diff/apply is
necessary, no rewriting of trees, no change in the DAG structure (i.e.
connectivity; sha1s change, of course). So there should be a special
mode for DAG-preserving rewrites, where one can be sure that merges are
fully preserved.
2) seems to be the most important point to make rephrasing safe and
convenient.
Michael
^ permalink raw reply
* Re: fetch and pull
From: Junio C Hamano @ 2009-03-18 9:37 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Nanako Shiraishi, John Dlugosz, git
In-Reply-To: <20090318085849.GA8118@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> 1) You do "git pull git://host/repo.git" or similar, i.e. you don't use
> a remote. Because then, no refspec is given to fetch, and it defaults to
> fetching HEAD.
> ...
> 1) probably isn't that common for most users, and even if, it's not
> one of the commands given as examples to which the paragraph applies.
I think "a maintainer responds to a pull request" is the only case that
happens often in practice for a fetch+merge of HEAD from a remote
repository.
Even in that case, we strongly encourage people to say not just "which
repository location" but also "which branch", i.e.
Linus, please pull from:
git://git.or.cz/alt-git.git for-linus
to obtain the following commits.
When Linus cuts and pastes that to his shell, the command will become:
$ git pull git://git.or.cz/alt-git.git for-linus
and HEAD is not involved in such a use case.
^ 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