* Re: Three-way merge with the index as one way
From: Petr Baudis @ 2005-11-03 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Zack Brown, git
In-Reply-To: <7vy846ma65.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Nov 03, 2005 at 09:02:10AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> git-am 3-way fallback logic constructs a sparse
> temporary tree and uses it for running regular 3-way, and you
> may be able to do something similar.
I'm confused now - if the tree is sparse, how does git-read-tree -m know
that the missing files from the other tree are not deletes?
> Right now git-am takes an
> e-mail patch and when it runs all the way it creates a commit,
> but the core logic that applies patch and falls back to 3-way
> could be separated out for your application. Then you could:
> (1) 'git diff HEAD' before tree-warp to preserve the user
> changes, (2) clean up the working tree to match HEAD,
At this point I get nervous since there is a potential for data loss
when something goes wrong at this point (e.g. system crash). I'm not
saying there are no places like that in Cogito now, but I generally
try to avoid them whenever possible.
> (3) warp to the other tree, and (4) fed the user change perserved
> to git-am core logic. That might give you something near optimum.
>
> About "nonsensical" objects, I am not so sure how nonsensical
> those objects you would record from the working tree
> (intermediate state) are. If you find two trees match on a path
> that has changed in the working tree, there won't be any
> conflict on that paths so it is like the user did an extra
> git-update-index on that path when no merge or warp is involved,
> from object database pollution POV; I do not personally think
> that is such a bad thing.
But if they don't match, you'll get superfluous blobs for the original
index versions which are almost certain to go away.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: New ASCII Art
From: Junio C Hamano @ 2005-11-03 20:30 UTC (permalink / raw)
To: jdl; +Cc: git
In-Reply-To: <E1EXSDW-0005aC-RG@jdl.com>
jdl@freescale.com writes:
> So, I have updated drawings for consideration. See if you buy
> these. And if so, let's ponder where they might go. Then
> I'll patch 'em in...
Thanks for doing this. You have a sale.
> Fundamental Git Index Operations
README (which is included as git(7) Discussion section) might be
a good document to decorate with this. Probably after "The
Workflow; 5) Tying it all together".
> Git Merge Operations
> ====================
>
> +-----------+
> | Object DB |
> | Backing |
> | Store | -------+
> +-----------+ |
> |
> read-tree -m |
> +-----+ tree obj |
> |patch| |
> +-----+ +-----------+ |
> | | Index | <- - - +
> +------------->| "cache" | - - - >+
> git-apply --index +-----------+ |
> |
> |
> read-tree -m -u |
> +-----+ tree obj |
> |patch| |
> +-----+ +-----------+ |
> | | Working |<-------+
> +-------------->| Directory |
> git-apply +-----------+
Note that apply --index updates both index and working tree.
Note that read-tree -m -u takes information from both odb and
index, and updates both index and working tree.
Logically this belongs to "Merging two branches" in the Tutorial
document. The Tutorial introduction claims the document intends
to show how the core level operates to implement higher level
scripts, but currently we lack the lower-level details in the
text that would go well together with this illustration. Please
remind me that I should write something up at the very end of
that section soonish ;-).
> Git Diff Types
Maybe as a side note to "Inspecing Changes" section in the
Tutorial.
> Commit DAG Revision Naming
As an illustration to "SPECIFYING REVISIONS" section of
git-rev-parse(1).
^ permalink raw reply
* Re: [PATCH] RFC: proxy-command support for git://
From: Carl Baldwin @ 2005-11-03 20:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Paul Collins, git
In-Reply-To: <Pine.LNX.4.64.0511031117290.27915@g5.osdl.org>
Another way to do this would be using the ~/.ssh/config file. It would
look something like this:
Host host
ProxyCommand ...
Or, more generically...
Host *.*
ProxyCommand ...
Host *.* assumes that if the machine name has a '.' in it then you are
trying to get outside the firewall. This might not be a good assumption
but it works well where I am.
Then use host:pathname or ssh://host/pathname or whatever.
The advantage of using this is that it works for anything that uses ssh
to get outside the firewall. Not just git. So, setup is minimal.
Carl
On Thu, Nov 03, 2005 at 11:22:35AM -0800, Linus Torvalds wrote:
>
>
> On Thu, 3 Nov 2005, Junio C Hamano wrote:
>
> > Paul Collins <paul@briny.ondioline.org> writes:
> >
> > > I spend some of my time using a network that only allows outgoing TCP
> > > connections to certain ports, and the git-daemon port is not one of them.
> > > This patch below implements an analogue to ssh's ProxyCommand feature
> > > for git, as a less messy alternative to ssh port forwarding.
> >
> > Wonderful.
> >
> > > Questions:
> > >
> > > * Can git already do this and I just failed to notice?
> >
> > Maybe I just failed to notice this too, but I do not think so.
>
> Actually, you could. TWO ways, in fact, afaik.
>
> Just use the "ssh://host/pathname" format (or just "host:pathname") and
> the GIT_SSH environment variable.
>
> You could also override the local command-name with
>
> git-send-pack --exec=my-local-send-program /machine/repo/path
>
> where the "my-local-send-program" will parse /machine/repo/path thing. At
> least that works with git-send-pack, but it's possible it doesn't work
> with some other logic (ie "git push" might decide that it's unhappy that
> /machine/repo/path doesn't exist locally because it thinks it's a local
> path).
>
> Linus
> -
> 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
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: Now What?
From: Junio C Hamano @ 2005-11-03 20:55 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EXTw5-00063o-Gt@jdl.com>
Jon Loeliger <jdl@freescale.com> writes:
> Finally, a procedure or style question. Should this
> write-up be in the form of a structured FAQ? A stand-alone
> expository document?
Earlier I suggested bunch of unconnected Documentation/howto
pages, but I'd like to take it back at least partially. I have
two alternatives; I do not know which one I prefer more...
A table-of-contents (FAQ-list) with task-oriented categorization
would help guide the users facing "Now What?" situation. It
might start like this:
It broke after you tried to ...
* pull from remote
breakage #1 --> see this...
breakage #2 --> see that...
...
* checkout a branch
breakage #1 --> see this...
breakage #2 --> see that...
...
and each breakage and solution would be a separate document.
If we go with this separate FAQ-list approach, I'd love to keep
the result under Documentation/ hierarchy we ship as part of the
source, but I suspect that building-up this kind of thing might
be better suited to Wiki. I wonder if there is a Wiki whose
document storage format is in asciidoc, and uses git as its
revision control backend. Then we could let people update Wiki,
and occasionally merge from there. We also should be able to
push things back to Wiki, essentially treating Wiki as one of
the repositories from the git side. Hmm...
The other alternative is to add "NOW WHAT" section to each man
page. The idea is that "if the last command you ran was this
command and if it did not do what you wanted it to do, here are
its common failure modes and how you would recover from them".
So the materials we covered during the failed pull/merge
discussion would go to "NOW WHAT" section of git-pull(1), with
perhaps git-merge(1) saying "See also".
We would want "EXAMPLES" section for all the major commands as
suggested by Linus anyway, and going this way we _may_ be able
to get away without coming up with the higher level problem
categorization; the user would at least know what the last
command he tried to use was already.
^ permalink raw reply
* Re: little conundrum
From: Peter Eriksen @ 2005-11-03 20:57 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0511031845410.3435@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, Nov 03, 2005 at 06:47:56PM +0100, Johannes Schindelin wrote:
...
> How about this:
>
> cd orig/
> git-init-db
> git-add $(find * -type f)
> git-commit -m "initial"
> cd ../modified
> mv ../orig/.git ./
> git-add $(find * -type f)
> git-commit -a -m "my modifications"
As I stated in another message be careful with links because
they are not of "-type f". In addition do
find * -type l
or at least keep in mind what is really going on.
Peter
^ permalink raw reply
* Re: Three-way merge with the index as one way
From: Junio C Hamano @ 2005-11-03 21:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: Zack Brown, git
In-Reply-To: <20051103202125.GK1431@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> git-am 3-way fallback logic constructs a sparse
>> temporary tree and uses it for running regular 3-way, and you
>> may be able to do something similar.
>
> I'm confused now - if the tree is sparse, how does git-read-tree -m know
> that the missing files from the other tree are not deletes?
The git-am 3-way fallback works like this:
- the patch did not apply to our current head cleanly.
- however, we have all the original blobs, recorded on
'index xxxxxxx..xxxxxxx' line of the patch.
- construct a temporary tree T0 that has only paths affected
by that patch, with the original blobs.
- apply the patch to T0 to construct another temporary tree
T1.
- 3-way merge our current head and T1, pretending as if T0
is our common ancestor. I.e. "read-tree -m -u T0 HEAD T1"
The paths that did not change by the patch (in your case, the
paths without local modification before tree-warp) are not
present in either T0 or T1, so the 3-way merge in the last step
would see that our current head added those paths while T0->T1
transition kept their absense intact --- which results in
added-in-one-side-only.
I think the problem you are solving would be solved by what I
suggested in the earlier message, but probably always doing that
may not be the optimum solution.
- the working tree (and index) is derived from HEAD, but may
not match HEAD (local modifications).
- you want to tree-warp to T1, doing an equivalent of
"read-tree -m -u HEAD T1" but preserving the local
modifications.
You would want a merge between INDEX and T1 using HEAD as the
common ancestor (INDEX is a tree that your user would get if all
the local modification in the working tree were registered with
update-index and then git-write-tree were run).
INDEX
/
HEAD
\
T1
Two-tree form of read-tree -m -u should work as long as
differences between HEAD and INDEX do not interfere with
HEAD->T1 transition. So you probably would first want to try
"read-tree -m -u HEAD T1", and use the 3-way fallback I
described earlier when it fails?
> But if they don't match, you'll get superfluous blobs for the original
> index versions which are almost certain to go away.
Another way of putting it is that I would not particularly worry
about those dangling blobs and trees -- that's what we have 'git
prune' for.
^ permalink raw reply
* Re: [PATCH] RFC: proxy-command support for git://
From: Junio C Hamano @ 2005-11-03 21:31 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20051103204137.GA1343@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> Another way to do this would be using the ~/.ssh/config file. It would
> look something like this:
Maybe I am slow today, but wouldn't this require the other end
(i.e. remote repo) to let you ssh in?
I think the point of the original patch was to give proxied
connection to git:// transport, not git over ssh.
^ permalink raw reply
* Re: little conundrum
From: Alan Chandler @ 2005-11-03 22:02 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0511031845410.3435@wbgn013.biozentrum.uni-wuerzburg.de>
On Thursday 03 Nov 2005 17:47, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 3 Nov 2005, Alan Chandler wrote:
> > I would like to make myself a git repository that contains at the start,
> > an initial commit of the original downloaded source code, and a second
> > commit on the top of that that contains the the current state of play
> > after the changes I have made.
>
> How about this:
>
> cd orig/
> git-init-db
> git-add $(find * -type f)
> git-commit -m "initial"
> cd ../modified
> mv ../orig/.git ./
> git-add $(find * -type f)
> git-commit -a -m "my modifications"
>
> Of course -- in the great tradition of this list -- totally untested.
Also untested, but what about removing the files from the index that aren't in
the working directory?
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* binary safe?
From: Randal L. Schwartz @ 2005-11-03 22:02 UTC (permalink / raw)
To: git
I'm currently about to abandon CVS for my website management,
replacing it with git.
What problems, if any, will I have using git to manage the binary
files for my site, like the custom icons? CVS is doing that just fine
now.
I presume emailing diff-patches is out of the question, but if all I'm
doing is git-push and git-pull (using the shared central repository
model), and if I'm stupid enough to have a merge error it's OK to just
blow up on a binary file, will everything else work fine?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Now What?
From: Junio C Hamano @ 2005-11-03 22:07 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511031151070.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Thu, 3 Nov 2005, Junio C Hamano wrote:
>
>> "Peter Eriksen" <s022018@student.dtu.dk> writes:
>>
>> > ~/git/git-core]cat .git/remotes/origin
>> > URL: git://git.kernel.org/pub/scm/git/git.git
>> > Pull: master:origin
>> >
>> > ~/git/git-core]git-checkout maint
>> > ~/git/git-core]git pull
>>
>> You are merging my master into your "maint", probably a copy of
>> my (previous) maint.
>
> I think the situation is that he really wanted to update master, but
> forgot that he was on the maint branch.
I wonder if it would make sense to have something in .git/remotes/
file that says "run merge only when I am on frotz branch", like
this:
~/git/git-core]cat .git/remotes/origin
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: master:origin
Fetch-Only-Unless: master
~/git/git-core]git-checkout maint
~/git/git-core]git pull
warning: not merging because you are not on 'master' branch.
This would make the above "git pull" behave identical to "git
fetch", and the user can then do:
$ git checkout master
$ git pull . origin
Useful? Useless?
^ permalink raw reply
* Re: little conundrum
From: Alan Chandler @ 2005-11-03 22:17 UTC (permalink / raw)
To: git
In-Reply-To: <20051103200631.GJ1431@pasky.or.cz>
On Thursday 03 Nov 2005 20:06, Petr Baudis wrote:
...
> But you actually do not want to do a merge, but:
>
> $ cd original-version
> $ cg-init
> $ cd ../modified-version
> $ cg-init
> $ cg-branch-add orig ../original-version
> $ cg-fetch orig
> $ echo `cg-object-id` `cg-object-id orig` >.git/info/grafts
very nice
I didn't know about the grafts stuff, but I can see what its doing.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: Now What?
From: Josef Weidendorfer @ 2005-11-03 22:17 UTC (permalink / raw)
To: git
In-Reply-To: <7vll05e9j3.fsf@assigned-by-dhcp.cox.net>
On Thursday 03 November 2005 21:55, Junio C Hamano wrote:
> be better suited to Wiki. I wonder if there is a Wiki whose
> document storage format is in asciidoc, and uses git as its
> revision control backend.
I wonder if Git is the best SCM for a Wiki, as you want per-file
revisions in a Wiki: when reverting a page to a previous version,
this should not modify other pages.
So you have an index and a HEAD for every file.
To snapshot a state of such a multihead repository, it would be
nice to have tag objects able to hold multiple SHAs of commits.
Or can we use tree objects for this?
Josef
^ permalink raw reply
* Re: Now What?
From: Josef Weidendorfer @ 2005-11-03 22:33 UTC (permalink / raw)
To: git
In-Reply-To: <7vll05bd1w.fsf@assigned-by-dhcp.cox.net>
On Thursday 03 November 2005 23:07, Junio C Hamano wrote:
> I wonder if it would make sense to have something in .git/remotes/
> file that says "run merge only when I am on frotz branch", like
> this:
>
> ~/git/git-core]cat .git/remotes/origin
> URL: git://git.kernel.org/pub/scm/git/git.git
> Pull: master:origin
> Fetch-Only-Unless: master
>
> ~/git/git-core]git-checkout maint
> ~/git/git-core]git pull
> warning: not merging because you are not on 'master' branch.
This is quite limiting, if you keep multiple branches from origin in your
repository.
It would be better to be able to specify per-branch Pull lines. I.e. the
default pull action depends on the branch you are on.
URL: git://git.kernel.org/pub/scm/git/git.git
Pull(master): master:origin
~/git/git-core]git-checkout maint
~/git/git-core]git pull
warning: no default pull action for branch 'maint' specified
Syntax arguable.
Josef
^ permalink raw reply
* Re: binary safe?
From: Junio C Hamano @ 2005-11-03 22:49 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86br115r0z.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> I presume emailing diff-patches is out of the question, but if all I'm
> doing is git-push and git-pull (using the shared central repository
> model), and if I'm stupid enough to have a merge error it's OK to just
> blow up on a binary file, will everything else work fine?
It should. I trust git well enough to track some png files in
my day-job project.
^ permalink raw reply
* Re: binary safe?
From: Linus Torvalds @ 2005-11-03 22:50 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86br115r0z.fsf@blue.stonehenge.com>
On Thu, 3 Nov 2005, Randal L. Schwartz wrote:
>
> I'm currently about to abandon CVS for my website management,
> replacing it with git.
>
> What problems, if any, will I have using git to manage the binary
> files for my site, like the custom icons? CVS is doing that just fine
> now.
Git doesn't have any textual representations anywhere.
So the _only_ problem should be "git diff" (and related patch-based tools
- git-apply etc). They'll simply not work. For similar reasons, a
three-way merge will obviously fail.
> I presume emailing diff-patches is out of the question, but if all I'm
> doing is git-push and git-pull (using the shared central repository
> model), and if I'm stupid enough to have a merge error it's OK to just
> blow up on a binary file, will everything else work fine?
Yes. I don't think it's been heavily tested, but the very architecture of
git should mean that there just shouldn't be any issues with binary files
outside of the obvious ones.
The only binary file the kernel ever uses is the logo.gif thing, so it's
been "tested" in the sense that binary files exist, but there's never been
any changes to that file, so..
Linus
^ permalink raw reply
* Re: Now What?
From: Junio C Hamano @ 2005-11-03 22:51 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511032317.15393.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Thursday 03 November 2005 21:55, Junio C Hamano wrote:
>> be better suited to Wiki. I wonder if there is a Wiki whose
>> document storage format is in asciidoc, and uses git as its
>> revision control backend.
>
> I wonder if Git is the best SCM for a Wiki, as you want per-file
> revisions in a Wiki: when reverting a page to a previous version,
> this should not modify other pages.
Sorry, I do not see why per-file revisioning is mandatory.
Wouldn't revert or edit of a single page be just a new commit of
the new whole tree with just a single path changed?
I understand that whole tree history may not be much useful in
Wiki environment, but I do not see why it would hurt to have a
whole tree history (except perhaps the commit log may not be
very useful).
In fact, wouldn't svnwiki already does the same thing?
^ permalink raw reply
* Re: binary safe?
From: Martin Langhoff @ 2005-11-03 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, git
In-Reply-To: <7v7jbpbb3l.fsf@assigned-by-dhcp.cox.net>
On 11/4/05, Junio C Hamano <junkio@cox.net> wrote:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>
> > I presume emailing diff-patches is out of the question, but if all I'm
> > doing is git-push and git-pull (using the shared central repository
> > model), and if I'm stupid enough to have a merge error it's OK to just
> > blow up on a binary file, will everything else work fine?
>
> It should. I trust git well enough to track some png files in
> my day-job project.
Yes it works, and cvsimport -k will do the right thing for you.
We are tracking projects with several binary files. The only issue as
you note is that trading patches with git-format-patch and git-am
doesn't quite deal with it. But you can still do it across different
git heads with git-read-tree -m as long as your binary file merges are
truly trivial.
cheers,
martin
^ permalink raw reply
* Re: binary safe?
From: Nick Hengeveld @ 2005-11-03 23:05 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86br115r0z.fsf@blue.stonehenge.com>
On Thu, Nov 03, 2005 at 02:02:20PM -0800, Randal L. Schwartz wrote:
> What problems, if any, will I have using git to manage the binary
> files for my site, like the custom icons? CVS is doing that just fine
> now.
We're now using git in production to distribute content, of which well
over 90% is binary files. Works great.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Now What?
From: Josef Weidendorfer @ 2005-11-03 23:26 UTC (permalink / raw)
To: git
In-Reply-To: <7vwtjp9wgc.fsf@assigned-by-dhcp.cox.net>
On Thursday 03 November 2005 23:51, Junio C Hamano wrote:
> > I wonder if Git is the best SCM for a Wiki, as you want per-file
> > revisions in a Wiki: when reverting a page to a previous version,
> > this should not modify other pages.
>
> Sorry, I do not see why per-file revisioning is mandatory.
> Wouldn't revert or edit of a single page be just a new commit of
> the new whole tree with just a single path changed?
You are right.
Obviously I should get some sleep ;-)
As you said, by adding a new commit for every page revert, you get
a really messy history. If there is vandalism in a Wiki, wouldn't
it be better to be able to get rid of spam versions of one Wiki page?
> In fact, wouldn't svnwiki already does the same thing?
Probably. I don't know it.
Josef
^ permalink raw reply
* Trying to Update All Heads of a Repository
From: Jon Loeliger @ 2005-11-04 0:23 UTC (permalink / raw)
To: git
Guys and Gals,
*sigh*
This is the sort of thing that mystifies me still.
I think there is (should be?) an easy command and
I just missed that day in class. Feel free to
smack me with the obvious as needed...
I re-cloned (rsync) by git.git tree yesteday.
Today is a new day, and I want to start with
a fresh update of the entire git.git tree.
I have not changed anything in my copy yet.
My goal is a simple update of the entire repository.
% git --version
git version 0.99.9.GIT
Uh, foo. That's a version from 02-Nov-2005. I guess I could
dig out a SHA1 and we'd know exactly what version it is.
(Request: Does it make sense to have a hard SHA1 as
part of git's output version string?)
First, I have this, because it came with a git-clone:
% cat .git/remotes/origin
URL: rsync://rsync.kernel.org/pub/scm/git/git.git
Pull: master:origin
I don't know how to say "Grab all the updates for
all the heads for which I have heads in my .git/refs".
So I hope "git pull --help" will tell me:
% git pull --help
usage: git-fetch-pack [-q] [-v] [--exec=upload-pack] [host:]directory <refs>...
Fetch failure: --help
That would be no. So I hit the man page, and I can't
quite decipher it. I'm dense, so I have to re-read it
a few more times until I fully grok it. Dinner interferes.
Like could I have just said?:
% git fetch rsync://rsync.kernel.org/pub/scm/git/git.git
or
% git fetch rsync://rsync.kernel.org/pub/scm/git/git.git master:origin
% git fetch rsync://rsync.kernel.org/pub/scm/git/git.git pu:pu
% git fetch rsync://rsync.kernel.org/pub/scm/git/git.git todo:todo
Dunno yet.
In the meantime, I figure I can effectively achieve my
goal by:
for each head $h
git checkout -f $h
git pull rsync://rsync.kernel.org/pub/scm/git/git.git $h:$h
So I start with master. I know I can cheat here and rely
on the "Pull: master:origin":
% git pull origin
receiving file list ... done
sent 102 bytes received 12339 bytes 8294.00 bytes/sec
total size is 4708148 speedup is 378.44
* committish: a3114b3428595710d4719dd668531210af5993c9
branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git
* refs/heads/origin: same as branch 'master' of rsync://rsync.kernel.org/pub/scm/git/git
Already up-to-date.
That worked fine:
% git show-branch | head -15
! [maint] GIT 0.99.9b
* [master] Document --since and --until options to rev-parse.
! [origin] Document --since and --until options to rev-parse.
! [pu] Merge branch 'master'
! [todo] GIT 0.99.9
-----
+ [todo] GIT 0.99.9
+ [todo^] 2005-10-26 (prepare for 0.99.9)
+ [todo~2] Update 2005-10-19 afternoon.
+ [todo~3] 2005-10-18 midnight
+ [todo~4] 2005-10-16 early afternoon.
+ [todo~5] 2005-10-16 midnight.
+ [todo~6] Updates 2005-10-14 night
+ [todo~7] Updates 2005-10-12 night.
On to the pu branch:
% git checkout -f pu
% git show-branch | head -10
! [maint] GIT 0.99.9b
! [master] Document --since and --until options to rev-parse.
! [origin] Document --since and --until options to rev-parse.
* [pu] Merge branch 'master'
! [todo] GIT 0.99.9
-----
+ [todo] GIT 0.99.9
+ [todo^] 2005-10-26 (prepare for 0.99.9)
+ [todo~2] Update 2005-10-19 afternoon.
+ [todo~3] 2005-10-18 midnight
And pull it now:
% git pull rsync://rsync.kernel.org/pub/scm/git/git.git pu:pu
receiving file list ... done
sent 102 bytes received 12325 bytes 8284.67 bytes/sec
total size is 4708148 speedup is 378.86
* committish: 6c86914344ea64e3a7b287721bdeaa7d41f8a1c3
branch 'pu' of rsync://rsync.kernel.org/pub/scm/git/git
* refs/heads/pu: does not fast forward to branch 'pu' of rsync://rsync.kernel.org/pub/scm/git/git;
not updating.
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Trying simple merge.
Simple merge failed, trying Automatic merge.
Auto-merging Makefile.
ERROR: git-merge-ours.sh: Not handling case -> a64704f3e52be43b427792ef9c1bbe42af057c87 -> 4f3d053889de4a5ba8e6e5d519c014a51220accd
fatal: merge program failed
Automatic merge failed; fix up by hand
Rats. But why did this fail? I've changed nothing in my tree.
I'm pulling remote pu into local pu directly. I think this
should Just Work...
Uh, now what?
% git status
# On branch refs/heads/pu
#
# Updated but not checked in:
# (will commit)
#
# new file: Documentation/git-http-push.txt
# modified: Documentation/git-rev-parse.txt
# modified: Makefile
# modified: commit.c
# modified: config.c
# modified: fetch-pack.c
# modified: git-branch.sh
# modified: git-checkout.sh
# unmerged: git-merge-ours.sh
# modified: git-push.sh
# new file: git-shallow-pack.sh
# modified: git-svnimport.perl
# new file: http-push.c
# modified: ls-files.c
# modified: name-rev.c
# modified: send-pack.c
# modified: server-info.c
# modified: sha1_name.c
# modified: t/t3001-ls-files-others-exclude.sh
# modified: tag.c
# modified: tag.h
# modified: upload-pack.c
#
#
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# unmerged: git-merge-ours.sh
#
#
# Untracked files:
# (use "git add" to add to commit)
#
# git-merge-ours.sh
% git diff
* Unmerged path git-merge-ours.sh
% cat .git/HEAD
0e6a92bd0b33b3461fb7b7f7eb34647ad93d451d
% cat .git/FETCH_HEAD
6c86914344ea64e3a7b287721bdeaa7d41f8a1c3 branch 'pu' of rsync://rsync.kernel.org/pub/scm/git/git
So. Yes, I know I can "git-add git-merge-ours.sh" and then
do a "git-update-index git-merge-ours.sh" and get a spiffy
new index. And then I can "git-commit" it all, and that
should be everything.
But I really thought that this should Just Work?
Shouldn't this be a fast forward, nice-n-clean-n-easy?
Do I need to add .git/remote entries for each head?
Can I place multiple "Pull: pu:pu" type refspecs into
the one .git/remote/origin? Is that what people do?
Even if that I do that, I still have to manually iterate:
for each head $h
git checkout -f $h
git pull origin $h
More tequilla.
Thanks,
jdl
^ permalink raw reply
* Re: little conundrum
From: Johannes Schindelin @ 2005-11-04 0:41 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200511032202.18900.alan@chandlerfamily.org.uk>
Hi,
On Thu, 3 Nov 2005, Alan Chandler wrote:
> Also untested, but what about removing the files from the index that
> aren't in the working directory?
IIRC "git-commit -a" includes "git-update-index --remove".
Hth,
Dscho
^ permalink raw reply
* Empty temp files in the .git/objects subdirectories
From: walt @ 2005-11-04 0:56 UTC (permalink / raw)
To: git
I've noticed (sometimes) after using cg-update to
pull from Linus's kernel tree, that I have multiple
empty files named *.temp in the various subdirectories
of .git/objects/.
These *.temp files don't exist in Linus's repository
on kernel.org, so I am assuming they must be created
locally at my end by either cogito or git (dunno which).
They cause no problems except for annoying warning
messages, for example, while doing a git-fsck-*.
I'm using git and cogito(HEAD), both updated by using
cg-update from their git repositories on kernel.org,
so I'm current up to the very last minute :o)
Any suggestions how I can discover who is leaving
behind all these spurious empty *.temp files?
^ permalink raw reply
* Re: Trying to Update All Heads of a Repository
From: Linus Torvalds @ 2005-11-04 1:04 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EXpN9-00034x-7g@jdl.com>
On Thu, 3 Nov 2005, Jon Loeliger wrote:
>
> I don't know how to say "Grab all the updates for
> all the heads for which I have heads in my .git/refs".
Well, you can't per se - there's no guarantee that the heads on the other
side match, and in fact usually they won't (at the very minimum, the
remote "master" tends to be the local "origin", although if you never do
any development at _all_, you can make even that match).
I sent out a patch some time ago that added "--all" and "--tags", but only
the "--tags" part was accepted. Arguably for good reasons.
But "git fetch" will take a list of heads. So you can do
git fetch repo master:origin pu todo
and it will update the three local heads (origin, pu and todo) from the
remote heads master, pu and todo respectively).
IF you have a 100% match between heads names locally and remotely, you
could also do something like
git fetch repo $(cd .git/refs ; echo heads/*)
which is pretty cheesy, but should work ;)
As to your experiences with "git pull" - it should work fine too, but you
really do need to make sure that the branch you are in always matches the
branch you're pulling. Otherwise you'll be doing a merge between two
different branches - which is a valid operation, but not what you're
trying to achieve here.
As we saw earlier, the way to undo an unsuccessful "git pull" is to do a
"git reset --hard". Undoing a _successful_ git pull is actually slightly
harder in the general case (it's really undoing a series of commit), but
if you do it right after the pull, you can do
git reset --hard ORIG_HEAD
because "git pull" will save the original head before pulling.
Linus
^ permalink raw reply
* Re: Empty temp files in the .git/objects subdirectories
From: Nick Hengeveld @ 2005-11-04 1:54 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dkebkq$ova$1@sea.gmane.org>
On Thu, Nov 03, 2005 at 04:56:58PM -0800, walt wrote:
> I've noticed (sometimes) after using cg-update to
> pull from Linus's kernel tree, that I have multiple
> empty files named *.temp in the various subdirectories
> of .git/objects/.
These are created by git-http-fetch to hold data as it's being
fetch from the remote repository. They are left behind after a transfer
error so that the next time git-http-fetch runs it can pick up where it
left off. If they're empty though, it would make more sense to delete
them rather than leaving them behind for the next attempt.
This should fix it:
[PATCH] Remove the temp file if it is empty after the request has failed
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
applies-to: 55caf3fd962e3b5a25ee12e09c781e6f5a240672
28738a32636e9f0a326f5d9e662df1e6c594851f
diff --git a/http-fetch.c b/http-fetch.c
index a1b03cd..b12779d 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -520,12 +520,17 @@ static void start_request(struct transfe
static void finish_request(struct transfer_request *request)
{
+ struct stat st;
+
fchmod(request->local, 0444);
close(request->local);
if (request->http_code == 416) {
fprintf(stderr, "Warning: requested range invalid; we may already have all the data.\n");
} else if (request->curl_result != CURLE_OK) {
+ if (stat(request->tmpfile, &st) == 0)
+ if (st.st_size == 0)
+ unlink(request->tmpfile);
return;
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: Empty temp files in the .git/objects subdirectories
From: Junio C Hamano @ 2005-11-04 2:32 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051104015452.GB3001@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> These are created by git-http-fetch to hold data as it's being
> fetch from the remote repository. They are left behind after a transfer
> error so that the next time git-http-fetch runs it can pick up where it
> left off. If they're empty though, it would make more sense to delete
> them rather than leaving them behind for the next attempt.
That makes sense. Thanks.
^ 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