* Re: [PATCH/RFC 2/2] Make path-limiting be incremental when possible.
From: Junio C Hamano @ 2006-03-31 8:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603301652531.27203@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This is an absolutely huge deal for anything like "git log -- <pathname>",
> but also for some things that we don't do yet - like the "find where
> things changed" logic I've described elsewhere, where we want to find the
> previous revision that changed a file.
>...
> Btw, don't even bother testing this with the git archive. git itself is so
> small that parsing the whole revision history for it takes about a second
> even with path limiting.
By the way, I forgot to praise you ;-).
Even on a fast machine, the old one was not very useful, but
this one is _instantaneous_. Very good job.
$ PAGER=cat GIT_DIR=/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
/usr/bin/time git log -1 --pretty=short -- drivers/
commit ce362c009250340358a7221f3cdb7954cbf19c01
Merge: 064c94f... cd7a920...
Author: Linus Torvalds <torvalds@g5.osdl.org>
Merge git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6
15.44user 0.19system 0:25.11elapsed 62%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+18050minor)pagefaults 0swaps
$ PAGER=cat GIT_DIR=/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
/usr/bin/time ./git.pu log -1 --pretty=short -- drivers/
commit ce362c009250340358a7221f3cdb7954cbf19c01
Merge: 064c94f... cd7a920...
Author: Linus Torvalds <torvalds@g5.osdl.org>
Merge git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6
0.00user 0.00system 0:00.00elapsed 50%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+388minor)pagefaults 0swaps
^ permalink raw reply
* Re: [PATCH] cvsimport: use git-update-ref when updating
From: Johannes Schindelin @ 2006-03-31 10:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6ab1iy2.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 30 Mar 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This simplifies code, and also fixes a subtle bug: when importing in a
> > shared repository, where another user last imported from CVS, cvsimport
> > used to complain that it could not open <branch> for update.
>
> The second hunk look sensible but I do not know about "use Fcntl"
> since I do not see anything you are adding that starts to use it...
O_EXCL. Without "use Fcntl;" perl says I am not allowed to use bareword
things in strict mode or some such.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cvsimport: use git-update-ref when updating
From: Eric Wong @ 2006-03-31 10:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0603311207270.20122@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 30 Mar 2006, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > This simplifies code, and also fixes a subtle bug: when importing in a
> > > shared repository, where another user last imported from CVS, cvsimport
> > > used to complain that it could not open <branch> for update.
> >
> > The second hunk look sensible but I do not know about "use Fcntl"
> > since I do not see anything you are adding that starts to use it...
>
> O_EXCL. Without "use Fcntl;" perl says I am not allowed to use bareword
> things in strict mode or some such.
Huh? I still don't see where O_EXCL is used.
> > > + system("git-update-ref refs/heads/$branch $cid") == 0
Passing args to system() in list form is always preferable in case
there's a shell-unfriendly variable:
system("git-update-ref", "refs/heads/$branch", $cid) == 0
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] cvsimport: use git-update-ref when updating
From: Johannes Schindelin @ 2006-03-31 11:14 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20060331103230.GB15159@hand.yhbt.net>
Hi,
On Fri, 31 Mar 2006, Eric Wong wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Thu, 30 Mar 2006, Junio C Hamano wrote:
> >
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > > > This simplifies code, and also fixes a subtle bug: when importing in a
> > > > shared repository, where another user last imported from CVS, cvsimport
> > > > used to complain that it could not open <branch> for update.
> > >
> > > The second hunk look sensible but I do not know about "use Fcntl"
> > > since I do not see anything you are adding that starts to use it...
> >
> > O_EXCL. Without "use Fcntl;" perl says I am not allowed to use bareword
> > things in strict mode or some such.
>
> Huh? I still don't see where O_EXCL is used.
Yes. I did not make that point clear enough, I guess. My first approach
was to reimplement git-update-ref in perl, which worked well enough, until
I remembered that you could just call programs from perl :-)
> > > > + system("git-update-ref refs/heads/$branch $cid") == 0
>
> Passing args to system() in list form is always preferable in case
> there's a shell-unfriendly variable:
>
> system("git-update-ref", "refs/heads/$branch", $cid) == 0
Old habit dies hard.
---
git-cvsimport.perl | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 3728294..fe6298b 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -677,11 +677,7 @@ my $commit = sub {
waitpid($pid,0);
die "Error running git-commit-tree: $?\n" if $?;
- open(C,">$git_dir/refs/heads/$branch")
- or die "Cannot open branch $branch for update: $!\n";
- print C "$cid\n"
- or die "Cannot write branch $branch for update: $!\n";
- close(C)
+ system("git-update-ref", "refs/heads/$branch", $cid) == 0
or die "Cannot write branch $branch for update: $!\n";
if($tag) {
^ permalink raw reply related
* Re: Possible --boundary bug
From: Marco Costalba @ 2006-03-31 16:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Paul Mackerras
In-Reply-To: <7v64lvvyev.fsf@assigned-by-dhcp.cox.net>
On 3/31/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > Sorry, the good description is below, please ignore the wrong previous one.
>
> I think this patch should fix it.
>
Yes. It works for me.
Thanks
Marco
^ permalink raw reply
* Re: windows problems summary
From: Eric W. Biederman @ 2006-03-31 19:25 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0603020649u99a2035i3b8adde8ddce9410@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> This is just to summarize all the problems which make porting to that
> thing so boring. Maybe if we have them all on one page, it'd be easier
> to locate the workarounds (it can be one thread, for example).
>
> 1. opened and mmaped files can't be removed or renamed
> (caused workaround with reading index in memory)
> 2. command can safely contain only one argument
> (breaks and complicates passing things between processes)
> 3. no fork
> (slows down and complicates passing things between processes)
> 4. non-unix permissions model
> (breaks x-attr)
> 5. real slow filesystems and caching
> (makes everything slow. I noticed I'm trying to avoid git status!).
> Caused workaround with manual checkout)
> 6. real slow program startup
> (makes everything slow, eventually may cause everything being put
> in one super-executable, just to avoid spawning new processes,
> with all associated problems. Makes scripting harder)
>
> I hope this message can be a start of a big porting thread,
> even though it is only about windows at the moment.
Not to forget make install gets confused when there
is a file named INSTALL in the git directory.
Eric
^ permalink raw reply
* Re: [PATCH/RFC 2/2] Make path-limiting be incremental when possible.
From: Linus Torvalds @ 2006-03-31 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v3bgzxgbg.fsf@assigned-by-dhcp.cox.net>
On Thu, 30 Mar 2006, Junio C Hamano wrote:
>
> There already was a report that --boundary stuff is not quite
> right, so what you are seeing might be that the new code exposes
> its original breakage even more. I haven't looked into the
> breakage of the original version yet either, so I cannot really
> say how your change breaks it.
[ Awake and thinking about this again ]
No, I think the new breakage was just because I was being a stupid ass.
When I converted get_revision() to do the parent parsing up at the top
instead of at the bottom, I just didn't think correctly about your new
BOUNDARY code, and my conversion for that was just wrong. Part of the "do
the parents early" code was also removing the current commit early, so
suddenly your BOUNDARY case for doing that thing was just removing some
other random commit instead, which was obviously wrong.
The fix is trivial - with the new get_revision() organization, the
BOUNDARY case special-case actually goes away entirely, and this trivial
patch (on top of my 2/2 patch) should just fix it.
At least it passes my tests again now, and looking at the code everything
seems sane.
Linus
---
diff --git a/revision.c b/revision.c
index 0e3f074..753633e 100644
--- a/revision.c
+++ b/revision.c
@@ -796,18 +796,6 @@ struct commit *get_revision(struct rev_i
if (revs->parents)
rewrite_parents(commit);
}
- /* More to go? */
- if (revs->max_count) {
- if (commit->object.flags & BOUNDARY) {
- /* this is already uninteresting,
- * so there is no point popping its
- * parents into the list.
- */
- struct commit_list *it = revs->commits;
- revs->commits = it->next;
- free(it);
- }
- }
commit->object.flags |= SHOWN;
return commit;
} while (revs->commits);
^ permalink raw reply related
* Re: [PATCH/RFC 2/2] Make path-limiting be incremental when possible.
From: Linus Torvalds @ 2006-03-31 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wwjvwz9.fsf@assigned-by-dhcp.cox.net>
On Fri, 31 Mar 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > This is an absolutely huge deal for anything like "git log -- <pathname>",
> > but also for some things that we don't do yet - like the "find where
> > things changed" logic I've described elsewhere, where we want to find the
> > previous revision that changed a file.
> >...
> > Btw, don't even bother testing this with the git archive. git itself is so
> > small that parsing the whole revision history for it takes about a second
> > even with path limiting.
>
> By the way, I forgot to praise you ;-).
>
> Even on a fast machine, the old one was not very useful, but
> this one is _instantaneous_. Very good job.
Indeed. It's why I'd really like this to be merged before 1.3.0 - it moves
a certain class of problems from "it works" to "it's actually usable".
Now, the _real_ usage I foresee (which just wasn't practical before) is
the interactive annotation thing - this won't help a _full_file_ annotate
(which usually needs to go back to the very first version of a file
anyway), but it should make it possible to play with an incremental one
(the "graphical git-whatchanged" kind).
But even just the "git log" difference makes it worth it.
Linus
^ permalink raw reply
* Re: [PATCH/RFC 2/2] Make path-limiting be incremental when possible.
From: Junio C Hamano @ 2006-03-31 20:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603311135290.27203@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> The fix is trivial - with the new get_revision() organization, the
> BOUNDARY case special-case actually goes away entirely, and this trivial
> patch (on top of my 2/2 patch) should just fix it.
Yes, that is exactly the fix I have in "pu" -- I suspect you
replied before getting to my response last night.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] Make path-limiting be incremental when possible.
From: Linus Torvalds @ 2006-03-31 20:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfykyuzc2.fsf@assigned-by-dhcp.cox.net>
On Fri, 31 Mar 2006, Junio C Hamano wrote:
>
> Yes, that is exactly the fix I have in "pu" -- I suspect you
> replied before getting to my response last night.
No, I just get too much email, and hadn't read your response carefully
enough, so I just missed the fact that you had already found the problem.
Linus
^ permalink raw reply
* Moving a file back to an earlier revision.
From: David Ho @ 2006-03-31 21:13 UTC (permalink / raw)
To: git
Hi,
Another user question. Other may actually have similar needs.
I am working on a board port on a separate branch. The branch has
accumulated several revision of changes to a driver I worked on. Now,
someone has come along with a better fix so I want to help test his
patch. To do that I have to revert my changes to that driver (several
revisions back) before I can apply his patch.
What would be a convenient way to do that with git?
TIA, David
^ permalink raw reply
* Re: Moving a file back to an earlier revision.
From: Linus Torvalds @ 2006-03-31 21:26 UTC (permalink / raw)
To: David Ho; +Cc: git
In-Reply-To: <4dd15d180603311313t7781f2ebk616276e9134f6472@mail.gmail.com>
On Fri, 31 Mar 2006, David Ho wrote:
>
> I am working on a board port on a separate branch. The branch has
> accumulated several revision of changes to a driver I worked on. Now,
> someone has come along with a better fix so I want to help test his
> patch. To do that I have to revert my changes to that driver (several
> revisions back) before I can apply his patch.
>
> What would be a convenient way to do that with git?
Don't revert.
Just pick the point you want to start testing his patch at (with gitk, for
example, just cut-and-paste the sha1), and do
git checkout -b test-better-fix <sha1>
which creates a new branch ("test-better-fix") that starts at that point,
and checks it out.
Then, just apply the patch, and off you go. You now have _both_ his patch
and your own series in separate branches, so you can cherry-pick and do
other things (like do a "diff" between branches - which can sometimes be
useful too to verify that the two branches end up fixing all the same
problems).
Linus
^ permalink raw reply
* Re: Moving a file back to an earlier revision.
From: David Ho @ 2006-03-31 21:32 UTC (permalink / raw)
To: git
In-Reply-To: <4dd15d180603311313t7781f2ebk616276e9134f6472@mail.gmail.com>
Sorry I might already have found it.
File revisions
+----+----+
1 2 3
git diff commit(3)..commit(1) filename | git-apply
David
On 3/31/06, David Ho <davidkwho@gmail.com> wrote:
> Hi,
>
> Another user question. Other may actually have similar needs.
>
> I am working on a board port on a separate branch. The branch has
> accumulated several revision of changes to a driver I worked on. Now,
> someone has come along with a better fix so I want to help test his
> patch. To do that I have to revert my changes to that driver (several
> revisions back) before I can apply his patch.
>
> What would be a convenient way to do that with git?
>
> TIA, David
>
^ permalink raw reply
* Re: Moving a file back to an earlier revision.
From: Junio C Hamano @ 2006-03-31 21:49 UTC (permalink / raw)
To: David Ho; +Cc: git
In-Reply-To: <4dd15d180603311332p60fa1867nc303bd92d515b4e0@mail.gmail.com>
"David Ho" <davidkwho@gmail.com> writes:
>> I am working on a board port on a separate branch. The branch has
>> accumulated several revision of changes to a driver I worked on. Now,
>> someone has come along with a better fix so I want to help test his
>> patch. To do that I have to revert my changes to that driver (several
>> revisions back) before I can apply his patch.
>>
>> What would be a convenient way to do that with git?
>
> Sorry I might already have found it.
>
> File revisions
>
> +----+----+
> 1 2 3
>
> git diff commit(3)..commit(1) filename | git-apply
[please do not top-post].
That lets you go back to the state before 1, so what you are
doing is to start from here:
---0---1---2---3
and
---0---1---2---3---*
where * has the same tree as 0, and then on top of that you
apply his patch:
---0---1---2---3---X
But what if you find a room for further improvements in his
patch? You could commit X (which is revert of 321 *and* his
patch) and then build on top of it, like this:
---0---1---2---3---X---Y
and feed him "diff X..Y" back.
However.
What Linus said is more natural in git. Starting from the same
picture, you do this:
X (side branch to test his patch on)
/
---0---1---2---3 (your original branch)
You apply his patch to a new branch. You could even make
further improvements like this:
X---Y
/
---0---1---2---3
And if you decide Y is better than your version 3 after all, you
can switch to his branch and then pick up anything important
from your development track between 0..3 on top of Y by
cherry-picking, and you can even later discard your original
development track. On the other hand, if you end up deciding 3
is better than Y after all, you can just discard the whole side
branch.
Remember, a branch in git is very cheap, and is a powerful way
to keep track of things while you decide which alternate
universe to take. And even after you decide, you could always
look at and even build on the other universe.
^ permalink raw reply
* Re: Moving a file back to an earlier revision.
From: David Ho @ 2006-03-31 22:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603311324040.27203@g5.osdl.org>
On 3/31/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Don't revert.
>
> Just pick the point you want to start testing his patch at (with gitk, for
> example, just cut-and-paste the sha1), and do
>
> git checkout -b test-better-fix <sha1>
>
> which creates a new branch ("test-better-fix") that starts at that point,
> and checks it out.
I forget to mention I have also in my branch changes necessary to run
on my board. So what I did was
git-branch test-better-fix my-branch
git-checkout test-better-fix
git-diff commit(my-fixes)..commit(original) filename | git-apply
git-commit
>
> Then, just apply the patch, and off you go. You now have _both_ his patch
> and your own series in separate branches, so you can cherry-pick and do
> other things (like do a "diff" between branches - which can sometimes be
> useful too to verify that the two branches end up fixing all the same
> problems).
>
Yes, good point.
Thanks, David
^ permalink raw reply
* Re: Moving a file back to an earlier revision.
From: David Ho @ 2006-03-31 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacb6thc7.fsf@assigned-by-dhcp.cox.net>
> Remember, a branch in git is very cheap, and is a powerful way
> to keep track of things while you decide which alternate
> universe to take. And even after you decide, you could always
> look at and even build on the other universe.
I feel embarrassed to say this but in my branch there are commits to
the driver and other commits for the board so it looks more like
---0---D1---B1---B2---D2---B3---B4---
D* - driver changes
B* - board changes
So to go back to the 0 state I lose my board changes. But I hope what
I did (in my reply to Linus) is very close to your idea of having
separate branches.
David
^ permalink raw reply
* Default remote branch for local branch
From: Pavel Roskin @ 2006-04-01 1:48 UTC (permalink / raw)
To: git
Hello!
This is not a ready-to-use proposal, but I think my message can prompt
useful changes in GIT or in the "porcelain".
Let's see how remote changes end up in the head branch of the local
repository (sorry for possible mistakes in terminology):
branch in "remote" local index,
a remote -------> branch -------> branch ------> tree
repository (e.g. origin) (e.g. master)
Brought in sync by:
fetch merge checkout
Relationship stored in:
.git/remotes nowhere!!! .git/HEAD
If I fetch a remote branch, git knows where to get changes. If I change
the current branch, git remembers that. But git doesn't remember the
relationship between branches mirroring the remote branches and branches
used for local development.
There are situations when I want to work for a significant time on a
certain branch. Significant time means that changes are made by
others, and I'm supposed to integrate them and make more changes. Yet I
may want to take advantage of some patches from another team that uses
the other repository.
I want GIT and porcelains work the same way if I'm working with
repository 1 or repository 2. As it stands now, git gives preferential
treatment to the "origin" branch. Whatever branch I'm on, "git-pull"
will pull from "origin". I believe the special role of the "origin"
branch should be reduced to cg-clone and similar commands.
I think it would be convenient to have git remember the remote branch
for the given local branch. git should know that if HEAD points to
"local-B", "git-fetch" should fetch from "remote-B", not from "origin".
To implement this, git would have to implement attributes for local
branches (other ideas are welcome). Currently, there are no attributes
for local branches other than the top SHA1 in .git/refs/heads/
Once at the topic of branch attributes, let's see what else could be
useful? I think that would be the creator of the branch and the comment
(e.g. "this is for tested commits only, to be merged tomorrow" etc).
Where can this data be stored? Probably in blobs pointed to by refs in
e.g. .git/refs/branch-data/ or just in plain files e.g.
under .git/branch-data/
I know, it sounds like a lot of work to save a few keystrokes. But I
think it may be worth it. Working on different branches should have the
same "look and feel". Otherwise, git would repeat a design error of
CVS, where the head branch was given preference e.g. for date based
updates.
I'm sorry, reading this mailing list is beyond my capabilities, so
certain overlaps with other postings may be expected, unless I'm
suggesting something totally off-base :-)
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Default remote branch for local branch
From: Junio C Hamano @ 2006-04-01 3:05 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1143856098.3555.48.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> This is not a ready-to-use proposal, but I think my message can prompt
> useful changes in GIT or in the "porcelain".
>...
> I think it would be convenient to have git remember the remote branch
> for the given local branch. git should know that if HEAD points to
> "local-B", "git-fetch" should fetch from "remote-B", not from "origin".
I am in favor of the general direction this is going. Something
like this was mentioned on the list in the past twice (I think
Johannes was involved in the discussion but I do not remember
the details offhand).
My understanding is that Cogito uses $GIT_DIR/branches/$name
file as a configuration file per branch - currently it only
records which remote repository's what remote branch the local
branch $name interfaces with.
The $GIT_DIR/remotes/$name file is to describe each remote
repository, and it _wants_ to be able to describe all the
branches we are interested in, primarily because uploading and
downloading multiple, related heads at once is more efficient.
How remote branches are kept track of with the local tracking
branch, and how remote branches are updated from the local
branch heads, are described by Push/Pull lines there.
As you pointed out, we do not have a convenient way to tell git
where you typically merge things from per local branch. There
are different patterns I've seen:
- Promiscous. For example, "master" branch of Linus repository
pulls from many subsystem maintainers. Linus could have one
"remotes" file per subsystem maintainer he often pulls from
(and "for-linus" branch name in each remote repository tends
to stay the same), and unlike the rest of us he does not seem
to pull into many local branches. The current "remotes"
setup is really optimized for this mode of usage (you can use
"remotes" without having local tracking branches).
- Merging topic branches into "master" (or "release") branch
and "next" (or "testing") branch -- inside local repository.
- CVS-like remote tracking. A single "primary" remote branch
is tracked using local "origin", merged into local "master"
and pushed back to the remote. Both Cogito-like branches/
setup and having a single $GIT_DIR/remotes/origin file with
single Push/Pull line would work equally well.
- Multiple subsystem maintainer trees tracked in the same local
repository. Most generally, two local branches per each
remote head can be used (one tracking branch to fetch into,
another to build your changes based on it). Alternatively,
you can use one local branch per each remote head without
using any tracking branch.
Your proposal to give default branch to pull from per the local
branch would help only the last case. The first one you do not
switch between local branches at all and pull from many
different places; the second is to merge from different topic
branches from time to time and does not benefit from fixed
configuration; the third does not even need configuration.
Maybe you would want something like this.
In $GIT_DIR/config:
[pull]
origin = linus for master
origin = irq-pio of libata for ata-irq-pio
origin = pata-drivers of libata for ata-pata
In $GIT_DIR/remotes/linus:
URL: git://git.kernel.org/.../torvalds/linux-2.6.git
Pull: refs/heads/master:refs/heads/linus
In $GIT_DIR/remotes/libata
URL: git://git.kernel.org/.../jgarzik/libata-dev.git
Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
Pull: refs/heads/pata-drivers:refs/remotes/libata/pata-drivers
This is to maintain three local branches: master, ata-irq-pio
and ata-pata.
You are obviously interested in the mainline Linus kernel, so
while you are on your "master" branch, we will look for
"pull.origin .* for master" and find out you would want
remotes/linus file to be used. His "master" is copied to your
local "linus" branch, and merged into your "master" branch.
$ git pull
becomes equivalent to:
$ git pull linus
You are also interested in the libata work by Jeff, and while
you are on your ata-pata branch
$ git pull
becomes roughly equivalent to:
$ git pull libata pata-drivers
While we are on the topic, it _might_ be worthwhile to think
about revamping the syntax of $GIT_DIR/remotes file, maybe even
breaking backward compatibility. The Pull: lines can be
independently specified which gives flexibility, but I suspect
local tracking branches from the same remote tend to live in the
same place; IOW, you would probably not do something like:
URL: git://git.kernel.org/.../jgarzik/libata-dev.git
Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
Pull: refs/heads/pata-drivers:refs/heads/pata-drivers
in practice.
^ permalink raw reply
* Moving to BK
From: Petr Baudis, Junio C Hamano @ 2006-04-01 0:00 UTC (permalink / raw)
To: linux-kernel; +Cc: git
We are pleased to announce that both of us will be working for
BitMover Inc., starting this month.
Petr, the author of the popular Cogito front-end for git, will
be modifying Cogito so that it natively works on BK
repositories. The superior Cogito user interface will
extensively increase added business value of BK by enabling a
variety of innovative workflows for smooth and economical
developer cooperation.
Junio, the current maintainer of git "stupid content tracker",
will first be working on a gateway to import development
histories stored in git into BK. This move adds value to BK by
freeing the data so far locked in git repositories and making
them available to the BK users. He may later work on
reimplementing some parts of the git for BK, but it is expected
that there aren't that many. For example, the "rename
detection" part is not necessary -- BK natively supports rename
tracking, which is a far superiour approach.
There currently is no plan for either of us to be working on the
conversion from BK to git. There is no technical reason to do
so, and it does not make business sense for BitMover Inc.
either.
- 30 -
^ permalink raw reply
* Re: Moving to BK
From: David S. Miller @ 2006-04-01 3:14 UTC (permalink / raw)
To: pasky, junio; +Cc: linux-kernel, git
In-Reply-To: <200604010311.k313BYeS026266@hera.kernel.org>
April 1st is upon us again.
^ permalink raw reply
* Re: Moving to BK
From: Alexander Litvinov @ 2006-04-01 3:17 UTC (permalink / raw)
To: David S. Miller; +Cc: pasky, junio, linux-kernel, git
In-Reply-To: <20060331.191416.108058500.davem@davemloft.net>
> April 1st is upon us again.
Damn, I have forgot about this. Good joke !
^ permalink raw reply
* Re: Default remote branch for local branch
From: Pavel Roskin @ 2006-04-01 4:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodzmngfp.fsf@assigned-by-dhcp.cox.net>
Hello, Junio!
On Fri, 2006-03-31 at 19:05 -0800, Junio C Hamano wrote:
> - Multiple subsystem maintainer trees tracked in the same local
> repository. Most generally, two local branches per each
> remote head can be used (one tracking branch to fetch into,
> another to build your changes based on it). Alternatively,
> you can use one local branch per each remote head without
> using any tracking branch.
>
> Your proposal to give default branch to pull from per the local
> branch would help only the last case.
Exactly. I tried to track the main Linus repository and Jeff Garzik's
netdev in one place. Then I discovered that my repository if full of
unintended merges made by "stg pull".
> The first one you do not
> switch between local branches at all and pull from many
> different places; the second is to merge from different topic
> branches from time to time and does not benefit from fixed
> configuration; the third does not even need configuration.
>
> Maybe you would want something like this.
>
> In $GIT_DIR/config:
>
> [pull]
> origin = linus for master
> origin = irq-pio of libata for ata-irq-pio
> origin = pata-drivers of libata for ata-pata
First of all, using "origin" on every line carries to little
information.
Secondly, I think the relationship should be between a local development
branch and a local tracking branch. After all, all remote data is
placed on a local tracking branch first. It's better not to jump over
layers of abstraction. Suppose I want to update "masterB". I tell git
to sync "originB" first. git already has rules what to do if it should
sync "originB". Let's not supersede those rules.
I would write the config like this:
[branch-upstream]
master = linus
ata-irq-pio = irq-pio
ata-pata = pata-drivers
> While we are on the topic, it _might_ be worthwhile to think
> about revamping the syntax of $GIT_DIR/remotes file, maybe even
> breaking backward compatibility. The Pull: lines can be
> independently specified which gives flexibility, but I suspect
> local tracking branches from the same remote tend to live in the
> same place; IOW, you would probably not do something like:
>
> URL: git://git.kernel.org/.../jgarzik/libata-dev.git
> Pull: refs/heads/irq-pio:refs/remotes/libata/irq-pio
> Pull: refs/heads/pata-drivers:refs/heads/pata-drivers
>
> in practice.
Sorry, I don't understand this part.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Moving to BK
From: Linus Torvalds @ 2006-04-01 4:30 UTC (permalink / raw)
To: David S. Miller; +Cc: pasky, junio, linux-kernel, git
In-Reply-To: <20060331.191416.108058500.davem@davemloft.net>
On Fri, 31 Mar 2006, David S. Miller wrote:
>
> April 1st is upon us again.
I really like the new slashdot look. "OMG!!! Ponies!!!"
I hope they keep it after Apr 1st.
Linus
^ permalink raw reply
* Re: Default remote branch for local branch
From: Jakub Narebski @ 2006-04-01 5:38 UTC (permalink / raw)
To: git
In-Reply-To: <1143856098.3555.48.camel@dv>
Pavel Roskin wrote:
> I'm sorry, reading this mailing list is beyond my capabilities, so
> certain overlaps with other postings may be expected, unless I'm
> suggesting something totally off-base :-)
You might want to read "Efficient cloning" thread where
--use-separate-remote and --reference options were introduced:
http://marc.theaimsgroup.com/?l=git&m=114280442802681&w=2
http://www.gelato.unsw.edu.au/archives/git/0603/18113.html
http://thread.gmane.org/gmane.comp.version-control.git/17724
and which had discussion on similar subjects (somewhere).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Moving to BK
From: Randy.Dunlap @ 2006-04-01 6:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: davem, pasky, junio, linux-kernel, git
In-Reply-To: <Pine.LNX.4.64.0603312030060.27203@g5.osdl.org>
On Fri, 31 Mar 2006 20:30:40 -0800 (PST) Linus Torvalds wrote:
>
>
> On Fri, 31 Mar 2006, David S. Miller wrote:
> >
> > April 1st is upon us again.
>
> I really like the new slashdot look. "OMG!!! Ponies!!!"
Goes with the sandals and pony tails.
> I hope they keep it after Apr 1st.
---
~Randy
^ 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