* Re: [PATCH] push: fix local refs update if already up-to-date
From: Clemens Buchacher @ 2008-11-05 20:28 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20081105024932.GA20907@coredump.intra.peff.net>
On Tue, Nov 04, 2008 at 09:49:32PM -0500, Jeff King wrote:
[...]
> However, I would like to make one additional request. Since you are
> killing off all usage of new_sha1 initial assignment, I think it makes
> sense to just get rid of the variable entirely, so it cannot create
> confusion later.
Ok, I can live with that.
> > > Hmm. I was hoping to see more in update_tracking_ref. With your patch,
> > > we end up calling update_ref for _every_ uptodate ref, which results in
> > > writing a new unpacked ref file for each one. And that _is_ a
> > > performance problem for people with large numbers of refs.
> > [...]
> > I think update_ref already takes care of that. See this check in
> > write_ref_sha1:
> >
> > if (!lock->force_write && !hashcmp(lock->old_sha1, sha1)) {
> > unlock_ref(lock);
> > return 0;
> > }
>
> Nope. That check is a concurrency safeguard. It checks that when we are
> moving the ref from "A" to "B", that the ref still _is_ "A" when we lock
> it.
I think you are confusing this with verify_lock(). The code in
write_ref_sha1() really does compare with the new sha1.
> But more importantly, it is easy to demonstrate the problem with your
> patch:
>
> mkdir parent &&
> (cd parent &&
> git init && touch file && git add file && git commit -m one) &&
> git clone parent child &&
> (cd child &&
> echo BEFORE: && ls -l .git/refs/remotes/origin &&
> git push &&
> echo AFTER: && ls -l .git/refs/remotes/origin)
>
> I get:
>
> BEFORE:
> -rw-r--r-- 1 peff peff 32 2008-11-04 21:43 HEAD
> Everything up-to-date
> AFTER:
> -rw-r--r-- 1 peff peff 32 2008-11-04 21:43 HEAD
> -rw-r--r-- 1 peff peff 41 2008-11-04 21:43 master
>
> Oops. With the patch snippet I posted in my previous message, the
> 'master' ref is not created by the uptodate push.
The reason it doesn't work is a bug in lock_ref_sha1_basic(). Dating back to
pre-"pack-refs" times, this code forces a write if the ref file does not
exist. I will resubmit the patch including your above testcase and a bugfix
for lock_ref_sha1_basic().
Clemens
^ permalink raw reply
* Looking for the perfect git workflow
From: Roderik van der Veer |Smartlounge| @ 2008-11-05 20:10 UTC (permalink / raw)
To: git
Hello,
I'm trying to work out the best way to use git in the workflow for our
projects. We have
migrated from CVS in 2007 and are happy with it, but we have a need for
a more structured
way of working with our different repositories.
Let me describe the project to begin with, we have developed a
java+velocity based cms
system, and all out client sites are based upon this cms. The CMS is in
constant
development, so there are no set releases, only new features when a
customer has a need
for it, or bugfixes. Our project structure, that we cannot changed for
backward
compatibility is something like this:
* project x
o src
+ cms
+ components
# forum
# blog
# etc
+ shop
+ project x
o Webroot
+ images
+ html
+ velocity
# cms
# components
* forum
* blog
* etc
# shop
# project x
We have a git repository for the base cms system containing everything
but the "project
x" folders and the html folder. This git repository contains the base
files (database
transaction layer etc) but also global modules like the "blog" module.
The projects
extend these base files to create the client's website, the project
files are contained
in folders different from the base folders. An added difficulty is that
every java source
folder, has a velocity template folder structure, so for the module
"blog" there are two
folders "blog" in src and "blog" in webroot. The html folder in webroot
contains the html
files and images created by a third party and are updated by a rsync
script from their
server (they cannot use git). So to summarise:
* project x
o src
+ cms (BASE)
+ components
# forum (BASE - FORUM)
# blog (BASE - BLOG)
# etc (BASE - ETC)
+ shop (BASE - SHOP)
+ project x (PROJECT)
o Webroot
+ images (BASE)
+ html (THIRD PARTY)
+ velocity
# cms (BASE)
# components
* forum (BASE - FORUM)
* blog (BASE - BLOG)
* etc (BASE - ETC)
# shop (BASE - SHOP)
# project x (PROJECT)
The cvs and basic git workflow was:
changes from BASE went into the project like this: BASE -> a custom
rsync script ->
PROJECT
changes for BASE from PROJECT were merged back by hand, eighter in
master, or in a
feature branch
Since moving to git we started using the feature branches for big new
features, and just
used master for bugfixes. We developped the client sites using the
master branch combined
with some feature branches. The moment the site was live, the feature
branches were
considered stable and supported, and were merged into master.
So, what's the problem,
1. regressions, because to get a bugfix, you get stuffed with some new
feature or
refactoring. Just keeping everything as branches means you have a lot of
work to build a complete version for the project.
2. merging back by hand is a pain, since you can't forget any templates etc.
3. since BASE contains all the global, non site specific modules, every
project has the
SHOP code, even if it isn't a webshop.
What have we looked at:
1. git submodules -> since every module has two folders, and we don't
want two git
repositories for one module
2. A currently running experiment has an origin remote (the project repo
on our central
server) for it's master and some feature branches. And a remote to the
BASE repo, with a
checked out branch for that specific project.
* PROJECT X
o BASE - remote
+ project-x
o ORIGIN - remote
+ master
+ feature x
+ feature y
When we start the project x project, we merge the BASE/project-x branch
into
ORIGIN/master and start from there. This way we can cherry pick changes
to BASE, and
control the flow from BASE/master to BASE/project-x and from
BASE/project-x into
ORIGIN/master
This works fairly good except that plain "git push" wants to put the
local version of master into
BASE/master (and that is really not the way we want it) and it's bound
to happen that someone forgets to add extra params to the command. And
we have no real way of dealing with problem number 3 (the modules)
So in short, i'm looking for some insight, to create a foolproof
framework to deal with
this kind of setup.
Regards,
Roderik
--
==========================================
Roderik van der Veer
roderik.van.der.veer@smartlounge.be
==========================================
Smartlounge
JP Minckelersstraat 78
B-3000 Leuven
tel: +32 16 311 412
gsm: +32 486 36 66 39
==========================================
http://www.smartlounge.be
==========================================
internet application development & hosting
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Bob Hiestand @ 2008-11-05 19:49 UTC (permalink / raw)
To: geoffrey.russell; +Cc: git, Johannes Schindelin
In-Reply-To: <93c3eada0811041954i24a15e33tcdd89f50c162b8d2@mail.gmail.com>
On Tue, Nov 4, 2008 at 9:54 PM, Geoff Russell
<geoffrey.russell@gmail.com> wrote:
> Thanks Bob but when I ran your version (using master@{15} instead of
> --since =...) it
> effectively dropped the recent history, not the old history. Imagine a sequence
> of 30 commits, no branches. I want to keep, for example, 15 through
> 30 and dump 1
> to 15. So I need to have the working directory as at commit 15 and
> then all the changes
> to bring it up to 30.
>
> ... 11--12--13--14--15 ... 28--29--30
>
> ... Dump 1 to 15 keep 15 to 30.
>
> Your script kept 1 to 15 and dumped the rest.
I guess that's because you're using reflog syntax and pulling up a
commit that isn't on the current branch, due to rebasing, resetting,
or any such activity. Using the reflog syntax, for the few commits I
tried, produced the desired result.
I'm not sure why you'd use reflogs, however, as I believe the
--max-age or --since parameters to rev-list seem to be more in line
with your request. Actually, I'd be surprised if you couldn't
identify the one commit that you wanted to use and use it directly;
the rev-list was just to show an example.
Thank you,
bob
^ permalink raw reply
* Re: GIT and SCC
From: Theodore Tso @ 2008-11-05 19:38 UTC (permalink / raw)
To: Martin Terreni; +Cc: Mike Ralphson, Shawn O. Pearce, git
In-Reply-To: <1225913035.8578.18.camel@terrenisrv1.terrenis.net>
On Wed, Nov 05, 2008 at 09:23:55PM +0200, Martin Terreni wrote:
>
> http://en.wikipedia.org/wiki/SCC_compliant
>
> It is probably not much, but this is what I could find in a minute. many
> VC system have a SCC complaint API (apart of the native). This protocol
> was created by M$ is used by many systems so they are not bound to a
> specific VC tool.
It's a closed-source, undocumented API that you can only get access to
by signing a Microsoft NDA. From the WinMerge API:
SCC API is closed API (no public documentation available) some
IDE's (e.g. Visual Studio) use. There apparently have couple
of reverse-engineered free implementations for SCC API. Status
of those are unknown.
WARNING: Be very sure you are not submitting any code behing
NDA for WinMerge. WinMerge is Open Source so it is not legal
to do. And what is worse it would prevent anybody reading that
code working with SCC (and perhaps also VCS) support.
http://winmerge.org/Wiki/VCS_integration
- Ted
^ permalink raw reply
* Re: GIT and SCC
From: Martin Terreni @ 2008-11-05 19:23 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Shawn O. Pearce, git
In-Reply-To: <e2b179460811051111y2d6e4c5eq19c8b58b93f942a9@mail.gmail.com>
http://en.wikipedia.org/wiki/SCC_compliant
It is probably not much, but this is what I could find in a minute. many
VC system have a SCC complaint API (apart of the native). This protocol
was created by M$ is used by many systems so they are not bound to a
specific VC tool.
Thanks for the quick response any way :)
-----Original Message-----
From: Mike Ralphson <mike.ralphson@gmail.com>
To: Shawn O. Pearce <spearce@spearce.org>
Cc: Martin Terreni <martin@terrenis.net>, git@vger.kernel.org
Subject: Re: GIT and SCC
Date: Wed, 5 Nov 2008 19:11:06 +0000
2008/11/5 Shawn O. Pearce <spearce@spearce.org>:
> Martin Terreni <martin@terrenis.net> wrote:
>> Does Git support SCC in any way?
>
> What is SCC?
>
> Google defines it as the Seminole Community College Campus Web Site
> (www.scc-fl.edu). As far as I know, we do not send them money.
And if we did, would it be hard money?
^ permalink raw reply
* Re: GIT and SCC
From: Mike Ralphson @ 2008-11-05 19:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Martin Terreni, git
In-Reply-To: <20081105182506.GO15463@spearce.org>
2008/11/5 Shawn O. Pearce <spearce@spearce.org>:
> Martin Terreni <martin@terrenis.net> wrote:
>> Does Git support SCC in any way?
>
> What is SCC?
>
> Google defines it as the Seminole Community College Campus Web Site
> (www.scc-fl.edu). As far as I know, we do not send them money.
And if we did, would it be hard money?
^ permalink raw reply
* How to rebase for git svn?
From: Yang Zhang @ 2008-11-05 19:09 UTC (permalink / raw)
To: git
Hi, I made a git svn repository from an svn repository. Then I cloned
the git repository, committed some changes to the clone, and pulled back
to the original repository. However, now the original repository gives
me conflicts whenever I run git svn rebase. I believe this is because
git pull treats the other repository's commits as a branch and merges
them back instead of rebasing them and maintaining the type of linear
history that is good for playing with svn. Any hints as to how to fix
this? I think the solution is to undo the merge that resulted from the
pull, but I don't know how to do this.
I wrote a simple script reproducing exactly what's going on (along with
a transcript of its output). I tried to make it as simple as possible,
but it can probably be simplified even more to reproduce the problem:
http://assorted.svn.sourceforge.net/viewvc/assorted/sandbox/trunk/src/git/gitsvn.bash?revision=1057&view=markup
Thanks in advance for any help!
--
Yang Zhang
http://www.mit.edu/~y_z/
^ permalink raw reply
* git svn woes
From: Yang Zhang @ 2008-11-05 18:52 UTC (permalink / raw)
To: git
For some reason, I'm getting this error when trying to git svn rebase
things from an svn repository to a git repository:
error: patch failed: myfile:1
error: myfile: patch does not apply
I have a simple bash script (and transcript of its output) demonstrating
exactly what I mean:
http://assorted.svn.sourceforge.net/viewvc/assorted/sandbox/trunk/src/git/gitsvn.bash?revision=1056&view=markup
Any hints? Thanks in advance!
--
Yang Zhang
http://www.mit.edu/~y_z/
^ permalink raw reply
* Re: GIT and SCC
From: Shawn O. Pearce @ 2008-11-05 18:25 UTC (permalink / raw)
To: Martin Terreni; +Cc: git
In-Reply-To: <1225909527.8578.10.camel@terrenisrv1.terrenis.net>
Martin Terreni <martin@terrenis.net> wrote:
> Does Git support SCC in any way?
What is SCC?
Google defines it as the Seminole Community College Campus Web Site
(www.scc-fl.edu). As far as I know, we do not send them money.
--
Shawn.
^ permalink raw reply
* GIT and SCC
From: Martin Terreni @ 2008-11-05 18:25 UTC (permalink / raw)
To: git
Does Git support SCC in any way?
Regards,
Martin Terreni
^ permalink raw reply
* Re: [RFC] Referring to a submodule state recorded in a supermodule from within the submodule
From: Johan Herland @ 2008-11-05 18:09 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vhc6mkqxb.fsf@gitster.siamese.dyndns.org>
On Wednesday 05 November 2008, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > I have a stand-alone project, "foo", that I work on myself. The
> > "foo" project is included as a submodule in two other projects,
> > "bar" and "baz", that I don't have any direct affiliation with.
> >
> > Semi-regularly, I like to keep tabs on bar and baz, to see what
> > versions of foo they are using, what changes they have made to foo,
> > and if there are things I could pick up from them, or maybe even
> > things they could learn from eachother.
> >
> > Doing this currently is quite tedious:
> > 1. Clone/Fetch bar and initialize/update its foo submodule
> > 2. Clone/Fetch baz and initialize/update its foo submodule
>
> If I am reading you right and you are only interested in the part
> "foo" in these projects, there is something wrong with the setup of
> "bar" and "baz".
>
> The submodule mechanism is designed to bind an independent project on
> its own as a subdirectory of another project. It seems to me that
> the problem is that "bar" and "baz" projects do not give direct
> access to clone "foo" part of them for you or other people.
No, they do. I can clone foo directly from bar/baz's server. The problem
is that I cannot quickly get at which revision of foo is used by
bar/baz without tedious cloning and interacting with the superrepos.
I basically want to quickly answer questions like "What are the
differences between bar's foo and baz's foo (and my own foo)?"
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH/RFC v3] git add -i: Answer questions with a single keypress
From: Suraj N. Kurapati @ 2008-11-05 17:59 UTC (permalink / raw)
To: git
In-Reply-To: <200811042215.31147.sunaku@gmail.com>
Allows the user to answer 'Stage this hunk' questions with a
single keypress, just like in Darcs. Previously, the user was
forced to press the Return key after every choice they made.
This quickly becomes tiring, burdensome work for the fingers.
Signed-off-by: Suraj N. Kurapati <sunaku@gmail.com>
---
git-add--interactive.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..b71905e 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -877,6 +877,8 @@ sub patch_update_file {
$num = scalar @hunk;
$ix = 0;
+ require Term::ReadKey;
+ Term::ReadKey::ReadMode('cbreak');
while (1) {
my ($prev, $next, $other, $undecided, $i);
$other = '';
@@ -920,7 +922,7 @@ sub patch_update_file {
print;
}
print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
- my $line = <STDIN>;
+ my $line = Term::ReadKey::ReadKey(0);
if ($line) {
if ($line =~ /^y/i) {
$hunk[$ix]{USE} = 1;
@@ -998,6 +1000,7 @@ sub patch_update_file {
}
}
}
+ Term::ReadKey::ReadMode('restore');
my $n_lofs = 0;
my @result = ();
--
1.6.0.3
\0
^ permalink raw reply related
* Re: [PATCH 1/3 v2] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-05 17:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20081104183506.bb9af13a.chriscool@tuxfamily.org>
Le mardi 4 novembre 2008, Christian Couder a écrit :
> This subcommand should be used when you have a branch or a part of a
> branch that isn't easily bisectable because of a bug that has been
> fixed latter.
>
> We suppose that a bug as been introduced at some point, say A, and
> that it has been fixed latter at another point, say B, but that
> between these points the code is not easily testable because of the
> bug, so it's not easy to bisect between these points.
>
> In this case you can create a branch starting at the parent of A, say
> O, that has a fixed history. In this fixed history for example, there
> could be first a commit C that is the result of squashing A and B
> together and then all the commits between A and B that have been
> cherry picked.
>
> For example, let's say the commits between A and B are X1, X2, ... Xn
> and they have been cherry picked after C as Y1, Y2, ... Yn:
>
> C--Y1--Y2--...--Yn
> /
> ...--O--A--X1--X2--...--Xn--B--...
>
> By design, the last cherry picked commit (Yn) should point to the same
> tree as commit B.
>
> So in this case you can say:
>
> $ git bisect replace B Yn
>
> and commit B will be tagged with a special name like:
> "bisect-replace-with-Yn"
>
> (A branch that points to commit Yn will also be created with a name
> like: "bisect-replace-B")
It occured to me that perhaps only the branch is needed and we can get rid
of the tag. This should remove the need to check that the branch still
exists when we are creating grafts.
I will see what I an come up with.
Regards,
Christian.
^ permalink raw reply
* Re: git-svn: Having a "rare" structure
From: Marc Fargas @ 2008-11-05 17:46 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4911DADA.4010902@drmicha.warpmail.net>
Hi,
On Wed, Nov 5, 2008 at 6:41 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> You can delete the bogus branches (using git branch -rd or git
> update-ref -d), but I'm not sure if you can reset git svn's state info:
> You may try messing with .git/svn/.metadata.
I'll try it, if not I'll recreate the repo from scratch ;)) Thanks for the tips!
> I tried the approach I suggested in the last post for real, and things
> seem to work. Only gotcha is I don't know whether django folks will
> stick with putting branches under {releases,features}, that would create
> problems
They say they won't put more folders in branches/ ;))
Thanks again for the tips, that will solve lots of trouble. Thanks!
Cheers.
Marc
--
http://www.marcfargas.com - will be finished someday.
^ permalink raw reply
* Re: [RFC] Referring to a submodule state recorded in a supermodule from within the submodule
From: Junio C Hamano @ 2008-11-05 17:45 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200811051824.28374.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> I have a stand-alone project, "foo", that I work on myself. The "foo"
> project is included as a submodule in two other projects, "bar"
> and "baz", that I don't have any direct affiliation with.
>
> Semi-regularly, I like to keep tabs on bar and baz, to see what versions
> of foo they are using, what changes they have made to foo, and if there
> are things I could pick up from them, or maybe even things they could
> learn from eachother.
>
> Doing this currently is quite tedious:
> 1. Clone/Fetch bar and initialize/update its foo submodule
> 2. Clone/Fetch baz and initialize/update its foo submodule
If I am reading you right and you are only interested in the part "foo" in
these projects, there is something wrong with the setup of "bar" and "baz".
The submodule mechanism is designed to bind an independent project on its
own as a subdirectory of another project. It seems to me that the problem
is that "bar" and "baz" projects do not give direct access to clone "foo"
part of them for you or other people.
^ permalink raw reply
* Re: git-svn: Having a "rare" structure
From: Michael J Gruber @ 2008-11-05 17:41 UTC (permalink / raw)
To: Marc Fargas; +Cc: git
In-Reply-To: <2686a05b0811050736q520f1771t6ffa2840bfb3c308@mail.gmail.com>
Marc Fargas venit, vidit, dixit 05.11.2008 16:36:
> Hi,
>
> On Wed, Nov 5, 2008 at 2:07 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> git config svn-remote.svn.branches
>> 'django/branches/features/*:refs/remotes/svn/features/*'
>>
>> git config --add svn-remote.svn.branches
>> 'django/branches/releases/*:refs/remotes/svn/releases/*'
>>
>> In fact, you should be able to use your previous branches config when
>> fetching up to r9093, then switch to the config I suggested, and the
>> fetch from r9094.
>
> I'll try it right now, I have one q... I've been fetching from svn so
> I now have "like a mess" in the branches dir (and their history) is
> there a way to make git-svn forget about everything after r9093 so I
> can do the config change and re-fetch since then? That'd be awesome.
You can delete the bogus branches (using git branch -rd or git
update-ref -d), but I'm not sure if you can reset git svn's state info:
You may try messing with .git/svn/.metadata.
I tried the approach I suggested in the last post for real, and things
seem to work. Only gotcha is I don't know whether django folks will
stick with putting branches under {releases,features}, that would create
problems.
Cheers,
Michael
^ permalink raw reply
* Re: Slow "git rev-list origin/master --not --all" or "git fetch" slow when downloading nothing
From: Linus Torvalds @ 2008-11-05 17:37 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0811050138j7b8bbed1nd94a999f55e38d61@mail.gmail.com>
On Wed, 5 Nov 2008, Santi Béjar wrote:
>
> In cold cache "git rev-list origin/master --not --all" is slow
> reading many files:
Hmm. It sounds like you possibly don't have packed refs.
Have you done "git gc" on that thing lately? What does "strace" say?
Linus
^ permalink raw reply
* [RFC] Referring to a submodule state recorded in a supermodule from within the submodule
From: Johan Herland @ 2008-11-05 17:24 UTC (permalink / raw)
To: git
Hi,
I have a stand-alone project, "foo", that I work on myself. The "foo"
project is included as a submodule in two other projects, "bar"
and "baz", that I don't have any direct affiliation with.
Semi-regularly, I like to keep tabs on bar and baz, to see what versions
of foo they are using, what changes they have made to foo, and if there
are things I could pick up from them, or maybe even things they could
learn from eachother.
Doing this currently is quite tedious:
1. Clone/Fetch bar and initialize/update its foo submodule
2. Clone/Fetch baz and initialize/update its foo submodule
3. Set up remotes bar_foo and baz_foo in my main foo repo,
pointing to bar/foo and baz/foo, respectively. Fetch.
4. Create tags bar_foo_current and baz_foo_current pointing
to the foo SHA1 sum recorded in baz and baz, respectively.
5. Start comparing bar_foo_current and baz_foo_current to
eachother, and to my own master branch.
Now, bring this into a larger company setting. There are many (~100)
different foo-type projects owned by (~50) different developers. These
projects are included as submodules by several (~20) different
bar/baz-type projects. In addition, each bar/baz-type project has
multiple (~3) branches using various versions of the foo-type
submodules.
Finally, throw in questions like "What are the differences in submodule
FOO between branch X of BAR, and branch Y of BAZ?", for random values
of FOO, X, BAR, Y, and BAZ. It is apparent that the above approach just
doesn't cut it.
Ironically, these questions are fairly easily answered by our current
CVS setup (which applies the supermodule tags/branches to the entire
source tree (including submodules)):
1. cd FOO
2. cvs diff -r BAR_X -r BAZ_Y
What I'd like, is some way to refer to the state of a repo as specified
by the appropriate submodule blob in a superproject commit. Ideally
this should be done remotely as well, so that I don't have to clone the
entire superproject just to get at the appropriate submodule blob.
Crude Proposal:
Define a new "git submodule" subcommand that takes three arguments:
<superURL> <tree-ish> <submoduleName>
The command does the following steps:
1. Locate git repo at <superURL>
2. Resolve <tree-ish> to the tree object within the git repo in #1
3. Locate .gitmodules within the tree object in #2
4. Lookup <submoduleName> in .gitmodules to find its path and URL
5. Locate the submodule blob from the path in #4 within the tree from #2
6. Record the object name (SHA1) stored in the submodule blob from #4
7. Fetch the object name (#7) from the submodule repo (its URL was
found in #4) into the local git repo
8. Store a reference to the fetched object
Given the above command, the tedious steps described at the top can be
reduced to the following (which is reasonably close to the equivalent
CVS commands):
1. git submodule magic-command url/to/bar master foo
2. git submodule magic-command url/to/baz master foo
3. Start comparing the fetched refs to eachother, and
to my own master branch.
If this sounds reasonable, I'd be happy to start coding the above
proposal.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re* Slow "git rev-list origin/master --not --all" or "git fetch" slow when downloading nothing
From: Junio C Hamano @ 2008-11-05 17:32 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0811050138j7b8bbed1nd94a999f55e38d61@mail.gmail.com>
"Santi Béjar" <santi@agolina.net> writes:
> In cold cache "git rev-list origin/master --not --all" is slow
> reading many files:
>
> cold cache:
> $ /usr/bin/time git rev-list origin/master --not --all
> 0.03user 0.02system 0:04.57elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
> 77848inputs+0outputs (410major+1798minor)pagefaults 0swaps
>
> hot cache:
> $ /usr/bin/time git rev-list origin/master --not --all
> 0.01user 0.00system 0:00.06elapsed 31%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+2207minor)pagefaults 0swaps
>
> I think that, in this particular case (when the arguments are the tips
> of some of the branches), this should not read that many files.
What kind of "many files" are you making git read? Do you have too many
unpacked refs? Too many loose objects?
> ... When nothing has changed in the remote repository (so
> refs/<remote>/* has all the remote refs) the "git fetch" could be almost
> instantaneous (even in coldcache),...
You at least need to read:
- what "--all" refs point at; to find this out, you need to read all
unpacked refs files, and one packed-refs file;
- commit objects that these refs point at; to cull refs that do not point
at committish and dereference tag objects that point at commit, you
need to read these objects (either loose objects or in packs);
- commit objects on the ancestry graph starting from the commit pointed
at by origin/master and the commits from "--all" refs, until your
traversal from origin/master hit one of the ancestors of "--all" refs.
I noticed that when you "git pack-refs" (or "git gc"), we do not remove
the leading directories of loose refs that become empty because of
pruning. This can cause many opendir() when you used to have too many
hierachy of refs even after packing them.
dir.c | 13 +++++++++----
pack-refs.c | 5 +++++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git c/dir.c w/dir.c
index 0131983..7241631 100644
--- c/dir.c
+++ w/dir.c
@@ -779,7 +779,12 @@ int is_inside_dir(const char *dir)
return get_relative_cwd(buffer, sizeof(buffer), dir) != NULL;
}
-int remove_dir_recursively(struct strbuf *path, int only_empty)
+/*
+ * option:
+ * 1: remove empty directory;
+ * 2: remove empty subdirectories, but not the directory itself
+ */
+int remove_dir_recursively(struct strbuf *path, int option)
{
DIR *dir = opendir(path->buf);
struct dirent *e;
@@ -803,9 +808,9 @@ int remove_dir_recursively(struct strbuf *path, int only_empty)
if (lstat(path->buf, &st))
; /* fall thru */
else if (S_ISDIR(st.st_mode)) {
- if (!remove_dir_recursively(path, only_empty))
+ if (!remove_dir_recursively(path, !!option))
continue; /* happy */
- } else if (!only_empty && !unlink(path->buf))
+ } else if (!option && !unlink(path->buf))
continue; /* happy, too */
/* path too long, stat fails, or non-directory still exists */
@@ -815,7 +820,7 @@ int remove_dir_recursively(struct strbuf *path, int only_empty)
closedir(dir);
strbuf_setlen(path, original_len);
- if (!ret)
+ if (!ret && option != 2)
ret = rmdir(path->buf);
return ret;
}
diff --git c/pack-refs.c w/pack-refs.c
index 2c76fb1..30fbae8 100644
--- c/pack-refs.c
+++ w/pack-refs.c
@@ -2,6 +2,7 @@
#include "refs.h"
#include "tag.h"
#include "pack-refs.h"
+#include "dir.h"
struct ref_to_prune {
struct ref_to_prune *next;
@@ -73,10 +74,14 @@ static void prune_ref(struct ref_to_prune *r)
static void prune_refs(struct ref_to_prune *r)
{
+ struct strbuf refs = STRBUF_INIT;
+
+ strbuf_addstr(&refs, git_path("refs"));
while (r) {
prune_ref(r);
r = r->next;
}
+ remove_dir_recursively(&refs, 2);
}
static struct lock_file packed;
^ permalink raw reply related
* Re: git-svn: Having a "rare" structure
From: Marc Fargas @ 2008-11-05 15:36 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <49119AAD.2010803@drmicha.warpmail.net>
Hi,
On Wed, Nov 5, 2008 at 2:07 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> git config svn-remote.svn.branches
> 'django/branches/features/*:refs/remotes/svn/features/*'
>
> git config --add svn-remote.svn.branches
> 'django/branches/releases/*:refs/remotes/svn/releases/*'
>
> In fact, you should be able to use your previous branches config when
> fetching up to r9093, then switch to the config I suggested, and the
> fetch from r9094.
I'll try it right now, I have one q... I've been fetching from svn so
I now have "like a mess" in the branches dir (and their history) is
there a way to make git-svn forget about everything after r9093 so I
can do the config change and re-fetch since then? That'd be awesome.
Thanks a lot for the tip! ;)
Sincerelly,
Marc
--
http://www.marcfargas.com - will be finished someday.
^ permalink raw reply
* Re: [PATCH 2/5] git send-email: interpret unknown files as revision lists
From: Junio C Hamano @ 2008-11-05 15:17 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Jeff King
In-Reply-To: <20081105104001.GA22272@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> On Tue, Nov 04, 2008 at 11:54:26PM +0000, Junio C Hamano wrote:
>
>> Somebody already suggested this but I really think GIT: lines should be at
>> the end and use '# ' prefix instead.
>
> This will break previous editor syntax hilighting stuff even more, and
> has the drawback that you can't put shell sniplets in here. I think it's
> why GIT: was chosen. But maybe we just don't care.
Ah, please scratch that "I really think" --- my mistake.
I did not check nor realize "GIT:" is what send-email already does.
^ permalink raw reply
* Re: let git-diff allow patch to delete empty files?
From: Sam Liddicott @ 2008-11-05 14:49 UTC (permalink / raw)
To: git
In-Reply-To: <49118FEE.30408@liddicott.com>
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]
* Sam Liddicott wrote, On 05/11/08 12:22:
> In some cases "patch" cannot apply diff's generated using git-diff, I've
> had a "git diff" output look like this when an empty file was removed as
> the only change:
>
> ..
> However this equivalent pair works by making the file non-empty and then
> deleting it.
>
> diff -Nru 1/here 2/here
> --- 1/here 2008-11-05 09:43:55.000000000 +0000
> +++ 2/here 2008-11-05 09:43:58.000000000 +0000
> @@ -0,0 +1 @@
> +
> diff -Nru 1/here 2/here
> --- 1/here 2008-11-05 09:37:23.000000000 +0000
> +++ 2/here 1970-01-01 01:00:00.000000000 +0100
> @@ -1 +0,0 @@
> -
>
The same problem occurs with new empty files.
Attached is an awk filter which will expand out these git notes into the
2-part unified diff's.
It would be nicer if git did it natively.
Sam
[-- Attachment #2: git-new-delete-filter.awk --]
[-- Type: text/plain, Size: 1430 bytes --]
#! /usr/bin/awk -f
function do_empty() {
if (diff!="" && deleted!="" && indx!="") {
printf("Make patch give the file 1 line\n");
printf("--- %s\n",diff);
printf("+++ %s\n",diff);
printf("@@ -0,0 +1 @@\n+\n");
printf("Make patch delete the 1 line file\n");
printf("--- %s\t\n",diff);
printf("+++ /dev/null\t1970-01-01 01:00:00.000000000\n");
printf("@@ -1 +0,0 @@\n-\n");
}
if (diff!="" && created!="" && indx!="") {
printf("Make patch create the file with 1 line\n");
printf("--- %s\n",diff);
printf("+++ %s\n",diff);
printf("@@ -0,0 +1 @@\n+\n");
printf("Make patch create delete the line but keep the file\n");
printf("--- %s\n",diff);
printf("+++ %s\n",diff);
printf("@@ -1 +0,0 @@\n-\n");
}
no_empty();
}
function no_empty() {
diff="";
deleted="";
created="";
indx="";
}
{
if (in_hunk > 0) in_hunk--;
}
/^diff --git / {
do_empty();
if (! in_hunk) diff=$3;
}
/^deleted file mode / {
if (! in_hunk && diff!="") deleted=$0;
}
/^new file mode / {
if (! in_hunk && diff!="") created=$0;
}
/^index / {
if (! in_hunk && diff!="") indx=$0;
}
/^--- / {
no_empty();
}
/^@@ / {
# read the hunk size
p=index($2,",");
if (p==0) c1=1;
else c1=strtonum(substr($2, p+1));
p=index($3,",");
if (p==0) in_hunk=1;
else in_hunk=strtonum(substr($2, p+1));
if (c1 > in_hunk) in_hunk=c1;
}
{
print;
}
END {
do_empty();
}
^ permalink raw reply
* Re: git-svn: Having a "rare" structure
From: Michael J Gruber @ 2008-11-05 13:07 UTC (permalink / raw)
To: Marc Fargas; +Cc: git
In-Reply-To: <2686a05b0811050204v59edc4a3h7f9ce6c6ecd13058@mail.gmail.com>
Marc Fargas venit, vidit, dixit 05.11.2008 11:04:
> Hi all,
>
> First of all, please CC responses to me as I'm not subscribed to this list ;)
>
> On the subject, I use git-svn to for most of my stuff and also to
> "interact" with some SVN projects out there, there's one that is
> driving me mad.
>
> The Django project has a (somehow) rare SVN structure that I almost
> managet to make git-svn understand, but a recent "rarity" to the
> structure broke it again and I haven't succeeded in making git-svn
> understand it, so I'm trying to get some guidance on how to make
> git-svn understand the structure.
>
> Right know the Django SVN repo is like that:
> browse: http://code.djangoproject.com/browser/django
> svn url: http://code.djangoproject.com/svn/django
>
> trunk/
> tags/notable_moments/
> tags/releases/
> branches/*
> branches/features/
> branches/releases/
>
> Until now, the last two didn't exist and git-svn was working nicely,
> but now "features" and "releases" were created, and git-svn is taking
> them as if they were branches, while they arent (branches are in
> subdirectories of those two).
>
> My git repo was done like that until now:
>
> git svn init --prefix svn/
> http://code.djangoproject.com/svn/django -T trunk -b branches -t
> 'tags/*/*'
> git svn fetch
>
> With that, git-svn understood that tags were in the subdirectories of
> tags/{notable_moments,releases}/ but I can't do that with the branches
> as there are branches also in the top branches/ directory.
>
> I do not really care about those branches on the top directory as
> those are old, so I really only need git-svn to understand the
> {features,releases}/* thing. So:
>
> How can I do something like "-b branches/{features,releases}/*" making
> git-svn ignore the other top-level branches? Or, can I make it
> understand both, the top-level ones and the ones inside those two
> subdirectories?
You can use "-T trunk -t 'tags/*/*'" and then set up the branches config
by hand:
git config svn-remote.svn.branches
'django/branches/features/*:refs/remotes/svn/features/*'
git config --add svn-remote.svn.branches
'django/branches/releases/*:refs/remotes/svn/releases/*'
In fact, you should be able to use your previous branches config when
fetching up to r9093, then switch to the config I suggested, and the
fetch from r9094.
Cheers,
Michael
^ permalink raw reply
* Re: Repo corrupted somehow?
From: Eyvind Bernhardsen @ 2008-11-05 12:26 UTC (permalink / raw)
To: Andrew Arnott; +Cc: Daniel Barkalow, git
In-Reply-To: <alpine.LNX.1.00.0811050043030.19665@iabervon.org>
On 5. nov.. 2008, at 06.56, Daniel Barkalow wrote:
> On Tue, 4 Nov 2008, Andrew Arnott wrote:
>
>> It was the CRLF conversion. When I played around with
>> git config --global core.autocrlf true/false
>> I got the problem to eventually go away.
>>
>> Thanks for all your responses.
>
> It's still worth debugging further, because git should know that it
> wrote
> the files differently and not see that as changes. It's not too
> helpful to
> have autocrlf if it causes this problem.
I think I know what this is. If a repository contains files with
CRLFs, those files will show as modified when core.autcorlf is true
(if you commit them, the CRLFs will be converted to CRs in the
repository, so in a sense they _are_ modified). Try turning autocrlf
back on, cloning the repository, then touching all the files (to make
git check them for changes) and see if you get the same problem.
I proposed an alternative autocrlf implementation on the list a while
back: making it an attribute instead of a configuration setting and
adding a configuration setting to tell git which line ending is
preferred when the autocrlf attribute is set.
That would allow you to turn on autocrlf and let git convert all CRLFs
to CRs in a single commit, thus converting a repository with CRLFs to
one that can be used with autocrlf in a versioned way. In theory that
lets you check out new commits with EOL conversion while old commits
will be left alone (avoiding the problem you saw), but
since .gitattributes is read from the working directory and not the
tree to be checked out, it doesn't work perfectly.
I implemented the easy bit (reading autocrlf from .gitattributes), but
for various reasons the patch has just been gathering dust in my
private git.git repo. Maybe I should dust it off :)
--
Eyvind
^ permalink raw reply
* bidirectional hg <-> git syncing
From: Ondrej Certik @ 2008-11-05 12:48 UTC (permalink / raw)
To: Git Mailing List
Hi,
I wanted to share how we sync hg and git repo and I am interested if
anyone has any comments to it.
In our project [0], we used Mercurial, but recently several of the
core developers including me switched to git, but because we already
wrote docs and taught our users to use mercurial (see for example
[1]), we want to support both. So currently our main repo is still
mercurial and we automatically convert to git using
Our /home/hg/repos/sympy/.hg/hgrc contains:
[hooks]
#update the git repo
changegroup = /home/git/update-sympy.sh
where /home/git/update-sympy.sh is:
-----------
#!/bin/bash
cd /home/git/repos/sympy
sudo /bin/su git -c "../fast-export/hg-fast-export.sh -r /home/hg/repos/sympy"
cd /home/git/repos/
sudo /bin/su git -c "rm -rf sympy.git"
sudo /bin/su git -c "git clone --bare sympy/.git/ sympy.git"
sudo /bin/su git -c "echo 'main SymPy repository' > sympy.git/description"
sudo /bin/su git -c "touch sympy.git/git-daemon-export-ok"
---------
Which uses hg-fast-export to update the git repo.
Before pushing any patches in, we need to convert them to mercurial.
So if the user uses mercurial, nothing changes. If the user (like me)
uses git, I need to convert the patches to mercurial first, so that I
can push it in. So I do the following sequence, starting off my master
branch:
git checkout -b fix
# do some commits
./hgconvert
where the ./hgconvert script is:
-----
#! /bin/bash
work=`mktemp -t -d sym.XXX`
git format-patch -k -p -o $work master..HEAD
# add a new line after the subject line so that Mercurial imports it fine.
sed -i '4a\\' $work/*
cd ~/repos/sympy.hg/
hg import $work/*
rm -r $work
---------
This takes all patches commited after the master and commits them to
my hg repo at ~/repos/sympy.hg/. I'll then push them in, both our hg
and git repo updates and then I do in my local git repository:
git checkout master
git pull # this pulls the changes, essentially the same as in the
"fix" branch, only from our official git repo
git branch -D fix
This works nicely as long as I do not do any merges in my local git
repo. Is there some way to also convert the branches and merges? As I
understood it, there are tools that only convert the whole repo, but
since we already convert the whole repo from hg to git, I need to only
convert the latest commits from git back to hg.
One solution is to fully switch to git and convert to hg automatically
on our server -- and that's what we'll do soon probably. Then we'll be
able to push nonlinear history in git, but only linear in mercurial.
Thanks,
Ondrej
[0] http://code.google.com/p/sympy/
[1] http://docs.sympy.org/sympy-patches-tutorial.html
Ondrej
^ 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