* Re: Topic descriptions
From: Robin Rosenberg @ 2006-12-07 10:45 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Junio C Hamano
In-Reply-To: <200612070837.16412.andyparkins@gmail.com>
torsdag 07 december 2006 09:37 skrev Andy Parkins:
> On Wednesday 2006, December 06 22:31, Junio C Hamano wrote:
> > I am unlikely to use such a thing for the "What's in" message,
> > though. The part that talks about "what the current status is"
> > is much easier to write when I need to talk about "the current";
> > otherwise I'd be forced to remember to think if I need to update
> > the information, every time I touch topic branches.
>
> It wasn't so much the what's current - as you say that would be fairly
> ridiculous as it's so fluid. It was more a description of the topic. I've
> got tonnes of branches where I have quickly thought of an idea and started
> work on it, only to get bored and move on. Describing a topic in such a
> short space as "ap/short-name" is hard.
Your situation sounds similiar to mine, but I don't use regular git branches
much. Rather I use stacked git instead. Stgit's patches can be though of as
virtual branches. Instead of creating a dozen branches I have a dozen commits
managed by stgit that I can choose from (and combine) easily, creating and
destroying private "branches".
^ permalink raw reply
* Re: git pull and merging.
From: Josef Weidendorfer @ 2006-12-07 11:27 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <4577B8C0.3060200@gmail.com>
On Thursday 07 December 2006 07:46, Aneesh Kumar K.V wrote:
> Josef Weidendorfer wrote:
> > Now, instead of "git pull", git should default to
> >
> > git pull origin refs/heads/devel:refs/remotes/origin/devel
>
>
>
> this means the remote reference is refs/heads/devel and local tracking
> branch for that is refs/remotes/origin/devel.
Yes.
> > ie. it should update the local tracking branch "refs/remotes/origin/devel"
> > with the remote branch "refs/heads/devel".
> > The tracking branch "refs/remotes/origin/devel" will be merged with current
> > branch afterwards.
> >
>
>
> That will be merged is the tricky part.
No. The merging part actually is the easiest, because everything about
what to merge with what is already decided in "git pull" 's fetch phase:
* git fetch leaves the branches fetched _and_ what to merge of them
in .git/FETCH_HEAD. Example for "git pull" it git.git's master(shorted):
de51fa... branch 'master' of git://.../git/git
49ed2b... not-for-merge branch 'maint' of git://.../git/git
b772ef... not-for-merge branch 'next' of git://.../git/git
Which means: Already in the fetch phase, we look up branch.*.merge to
decide what to write into this file.
* the merge phase just looks up .git/FETCH_HEAD and merges all branches into
the current branch which are _not_ marked as "not-for-merge". There
is nothing tricky here: We did the 1st phase of pull in the same
"current" branch, so there really is no need to check any branch.*.merge
value again.
> > Now looking at the documentation for branch.<name>.merge, it talks
> > about the remote branch, which is "refs/heads/devel" in your case, ie.
> > the first part of the refspec of the full "git pull" command above.
> >
>
> This is most confusing part. What merge indicate is not about refs/heads/devel
> should track refs/remotes/origin/devel. That is specfied in the remote config option.
Yes. But the value of branch.*.merge, which is the _remote_ side of such a refspec
tracking specification given in remote.*.fetch's, will be checked against all
remote parts of refspecs fetched in the 1st phase of "git pull". And it is already
decided in the fetch phase what to merge.
Now looking at it, I think this semantic really is screwed and utterly confusing.
Why decides branch.*.merge about actions done in fetch (I think even if you did
"git fetch" alone)? OK, actually, that is an implementation detail and not
really important.
More important: Because "branch.*.merge" specifies a _remote_ branch,
the user has to understand that this info is already used in the fetch.
The intuitive mental model of a user about how it works IMHO is that
"branch.*.merge" is checked in the merge phase (as the name of the option suggests).
But this way, how could the merge phase know about any remote branch at all,
which does not need to be touched at all in the merge phase?
IMHO we should somehow change the semantic of branch.*.merge to specify the _local_
refspec part, as this is the branch which actually gets merged.
This is the only way that a user could grasp the meaning of it.
Perhaps introduce "branch.*.defaultmerge", and obsoleting "branch.*.merge"?
> I guess we need to have a standard way of saying the branches.
>
> May be we want to document it in repo-config.
>
> local branch on which changes can be made <branch-name>
> local tracking branch refs/remotes/<remote-name>/<branch-name>
This is not forced, but can be changed by configuration.
> remote branch refs/heads/<branch-name>
?
^ permalink raw reply
* Remote 'master' not updated, but works somehow
From: Andreas Ericsson @ 2006-12-07 11:31 UTC (permalink / raw)
To: Git Mailing List
Having for a long time been thoroughly annoyed by our strict umasks, I
decided to write a little program to deal with it, and naturally I put
it in a git repo. After the initial commit
(c0fa1db09bad112f7271378d907bf33d74c06f6b) I published it to my git
space on our development server and cloned it out again (to get the
nifty remotes things set up for free).
Then I noticed I had rushed it, as I usually do with hacks involving a
total of less than 200 lines of code, so I had to make a couple of more
commits to make it work.
After having pushed the fixes to the public site I went to have a look
at it in gitweb, at https://devel.op5.se/~exon/git/
I was quite surprised to find that 'master' was still pointing to the
root commit. After the usual culprits were excluded (permissions, bad
paths, whatnot), I decided to try to clone the repo again to a different
location.
Here's what happened:
devel!exon:~$ git clone softpub/mkpub.git/ mkpub
remote: Generating pack...
remote: Done counting 17 objects.
remote: Deltifying 17 objects.
remote: 100% (17/17) done
Indexing 17 objects.
remote: Total 17 (delta 3), reused 0 (delta 0)
100% (17/17) done
Resolving 3 deltas.
devel!exon:~$ cat softpub/mkpub.git/refs/heads/master
c0fa1db09bad112f7271378d907bf33d74c06f6b
devel!exon:~$ cat mkpub/.git/refs/heads/master
5ba01a4709bcc8b482b207ba91d78ddb689a4091
devel!exon:~$ cd mkpub/
devel!exon:~/mkpub$ git push
Everything up-to-date
devel!exon:~/mkpub$ git rev-list master
5ba01a4709bcc8b482b207ba91d78ddb689a4091
e6a80831737517aa7ef29628429a18935b71de1d
8926e1519f69d95685ab5252886e7b237e21108e
c0bfedaf572ee550af7927acb89a1a2e01c1ef2c
c0fa1db09bad112f7271378d907bf33d74c06f6b
devel!exon:~/mkpub$ GIT_DIR=../softpub/mkpub.git/ git rev-list master
c0fa1db09bad112f7271378d907bf33d74c06f6b
(yes, the repo only has 4 commits)
And that's where I am now. Note that *cloning* from the repo actually
works, although I can't for the life of me figure out why.
Any thoughts?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Remote 'master' not updated, but works somehow
From: Andreas Ericsson @ 2006-12-07 11:35 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <4577FBAB.4070802@op5.se>
scratch this. I just noticed I had somehow managed to get the directory
setup like this:
devel:softpub/mkpub.git <-- a real repo
devel:softpub/mkpub.git/.git <-- the repo that got pushed to
Andreas Ericsson wrote:
> Having for a long time been thoroughly annoyed by our strict umasks, I
> decided to write a little program to deal with it, and naturally I put
> it in a git repo. After the initial commit
> (c0fa1db09bad112f7271378d907bf33d74c06f6b) I published it to my git
> space on our development server and cloned it out again (to get the
> nifty remotes things set up for free).
>
> Then I noticed I had rushed it, as I usually do with hacks involving a
> total of less than 200 lines of code, so I had to make a couple of more
> commits to make it work.
>
> After having pushed the fixes to the public site I went to have a look
> at it in gitweb, at https://devel.op5.se/~exon/git/
>
> I was quite surprised to find that 'master' was still pointing to the
> root commit. After the usual culprits were excluded (permissions, bad
> paths, whatnot), I decided to try to clone the repo again to a different
> location.
>
> Here's what happened:
>
> devel!exon:~$ git clone softpub/mkpub.git/ mkpub
> remote: Generating pack...
> remote: Done counting 17 objects.
> remote: Deltifying 17 objects.
> remote: 100% (17/17) done
> Indexing 17 objects.
> remote: Total 17 (delta 3), reused 0 (delta 0)
> 100% (17/17) done
> Resolving 3 deltas.
>
> devel!exon:~$ cat softpub/mkpub.git/refs/heads/master
> c0fa1db09bad112f7271378d907bf33d74c06f6b
> devel!exon:~$ cat mkpub/.git/refs/heads/master
> 5ba01a4709bcc8b482b207ba91d78ddb689a4091
> devel!exon:~$ cd mkpub/
> devel!exon:~/mkpub$ git push
> Everything up-to-date
> devel!exon:~/mkpub$ git rev-list master
> 5ba01a4709bcc8b482b207ba91d78ddb689a4091
> e6a80831737517aa7ef29628429a18935b71de1d
> 8926e1519f69d95685ab5252886e7b237e21108e
> c0bfedaf572ee550af7927acb89a1a2e01c1ef2c
> c0fa1db09bad112f7271378d907bf33d74c06f6b
> devel!exon:~/mkpub$ GIT_DIR=../softpub/mkpub.git/ git rev-list master
> c0fa1db09bad112f7271378d907bf33d74c06f6b
>
> (yes, the repo only has 4 commits)
>
> And that's where I am now. Note that *cloning* from the repo actually
> works, although I can't for the life of me figure out why.
>
> Any thoughts?
>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Locked down (but still shared) repositories
From: Shawn Pearce @ 2006-12-07 11:35 UTC (permalink / raw)
To: git
I have a number of repositories that I want to share across a number
of users on the same UNIX system.
For various auditing reasons the repositories need to be tightly
controlled. That is the following cannot be permitted:
* delete or overwrite a loose object;
* delete or overwrite a pack file;
* delete or overwrite a ref, except see below;
* change the config;
* change the description;
* change HEAD;
The only changes that are permissible can be made through
git-receive-pack, which limits the user to only the following:
* upload (possibly new) objects;
* create/update/force-update a ref;
* delete a ref;
And the latter two are controlled by a very strict update hook.
The update hook checks the ref name and real user id against
an ACL file (info/allowed-users) and checks to see if the user
can perform the requested operation against that ref, with four
operations being recognized:
* A == the ref is being created;
* U == the ref is being fast-forwarded;
* R == the ref is being rewound/reset;
* D == the ref is being deleted;
The update hook also requires that all lines returned by:
git-rev-list --pretty=raw $3 --not --all | egrep ^committer
correspond to a name/email address combination registered in another
table for the real user id (info/allowed-committers). Which means
we can actually trust the committer field of all commits which
are referenced by refs, as the UNIX system authenticated them.
The tagger field is also checked for every tag, but its slightly
more involved than the simple line above as it peels back the tag
layers as needed. :)
So the update hook is update-hook-example.txt, but suffering from
extreme paranoia and has been put on steriods. I'm considering
sending it in for Documentation/howto, or contrib.
Which brings me to the following problem:
I can't create the repository with --shared, as the UNIX users
all have normal shell access to the system. (/bin/rm would work
wonders to let a user violate a number of the items above.)
I also cannot create secondary git-only UNIX accounts for each user,
using git-shell in the git-only account. (For example "spearce"
and "spearce-git", with the latter using git-shell and being in a
group which does have repository access, while the former doesn't.)
The workaround that I have come up with is the following:
The repositories are all owned by a single user, and were created
without --shared, so only the owner can modify the repository.
The repositories are however readable by a specific group, and
all permitted users of that repository are members of that group.
So they can read the repository files directory, which works very
well with objects/info/alternates. :-)
git-receive-pack on this system is owned by the same repository
owner, and is also marked setuid. Consequently when a user pushes
into a repository the effective uid is that of the repository owner,
objects can be written, refs can be changed, the update hook runs
setuid, and it enforces everything.
The problem now is what happens when users try to use Git
as a distributed tool and push changes between their own two
repositories? Even if the two specific users can agree on using
--shared (because maybe they actually read the Git manual and want
to use that feature), git-receive-pack runs setuid as the blessed
repository user. Any update hook installed within one of these
'user private' repositories is untrusted, but will be running with
enough permissions to run /bin/rm and destroy data. See above
about how I can't have that...
So I've patched git-receive-pack to refuse to run if its running
setuid and the hook's owner isn't the effective uid, or the hook
is group/world writable. This seems to close the last hole, but
it also makes hooks/update and hooks/post-update useless in user
private repositories on this system.
I'm sending this to try and solicit better ideas from the mailing
list. We have a lot of UNIX guru types, and a lot of Git guru types,
and they are all smarter than I... ;-)
--
^ permalink raw reply
* Re: Remote 'master' not updated, but works somehow
From: Shawn Pearce @ 2006-12-07 11:49 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <4577FC6A.9050707@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> scratch this. I just noticed I had somehow managed to get the directory
> setup like this:
>
> devel:softpub/mkpub.git <-- a real repo
> devel:softpub/mkpub.git/.git <-- the repo that got pushed to
One's gotta wonder how that's ever a valid directory setup...
Although I'm running a configuration of:
root/proj.git <-- a real repo
root/proj.git/info/new-commit-check <-- a fake repo
where new-commit-check has root/proj.git not only as an alternate
ODB but also has root/proj.git/refs symlinked into its own refs
directory.
--
^ permalink raw reply
* Re: Topic descriptions
From: Martin Waitz @ 2006-12-07 11:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7v4ps8y7un.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]
hoi :)
On Wed, Dec 06, 2006 at 02:31:28PM -0800, Junio C Hamano wrote:
> But that description thing would be useful in gitweb, for
> example.
And it could be useful to automatically generate the summary for
please-pull mails or for the [0/N] patch introduction mail.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Locked down (but still shared) repositories
From: Martin Waitz @ 2006-12-07 12:21 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061207113539.GA10781@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 588 bytes --]
hoi :)
On Thu, Dec 07, 2006 at 06:35:39AM -0500, Shawn Pearce wrote:
> So I've patched git-receive-pack to refuse to run if its running
> setuid and the hook's owner isn't the effective uid, or the hook
> is group/world writable. This seems to close the last hole, but
> it also makes hooks/update and hooks/post-update useless in user
> private repositories on this system.
perhaps don't refuse to run, but simply change back to the safed uid?
Or use one special machine which hosts the repository and which has
the modified version of git installed.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Andreas Ericsson @ 2006-12-07 13:25 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Marco Costalba, Git Mailing List
In-Reply-To: <20061206195142.GE20320@spearce.org>
Shawn Pearce wrote:
>
> Perhaps there is some fast IPC API supported by Qt that you could
> use to run the revision listing outside of the main UI process,
> to eliminate the bottlenecks you are seeing and remove the problems
> noted above? One that doesn't involve reading from a pipe I mean...
>
Why not just fork() + exec() and read from the filedescriptor? You can
up the output buffer of the forked program to something suitable, which
means the OS will cache it for you until you copy it to a buffer in qgit
(i.e., read from the descriptor).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* How to conver no branches/tags svn repo to git ?
From: Dongsheng Song @ 2006-12-07 13:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
e.g.
http://svn.berlios.de/viewcvs/open-iscsi/
http://svn.berlios.de/svnroot/repos/open-iscsi
Can I convert / to master simply ?
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Andreas Ericsson @ 2006-12-07 13:36 UTC (permalink / raw)
To: hanwen; +Cc: Jakub Narebski, git
In-Reply-To: <4576E9DF.5090709@xs4all.nl>
Han-Wen Nienhuys wrote:
> Since git does recursive makes, among others in
>
> perl/
> Documentation/
> templates/
> contrib/
>
> there should be Makefiles in said directories. Otherwise, every rule
> in the toplevel Makefile saying
>
>
> $(MAKE) -C subdir/
>
> will fail because $builddir/ does not have a Makefile in
> $builddir/subdir.
>
This part should have been in the commit message, possibly without the
"among others ... (examples)" and possibly with an added "This patch
makes it so by letting fnurg create them through smurfing the frotz".
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Commit f84871 breaks build on OS X
From: Brian Gernhardt @ 2006-12-07 13:54 UTC (permalink / raw)
To: git
When I pulled the most recent changes for git (de51faf), `make` began
failing with the following messages:
make -C perl PERL_PATH='/usr/bin/perl' prefix='/usr/local/stow/git' all
Makefile out-of-date with respect to Makefile.PL /System/Library/Perl/
5.8.6/darwin-thread-multi-2level/Config.pm /System/Library/Perl/5.8.6/
darwin-thread-multi-2level/CORE/config.h
Cleaning current config before rebuilding Makefile...
mv: rename perl.mak to perl.mak.old: No such file or directory
make[1]: *** [perl.mak] Error 1
make: *** [all] Error 2
My system is (OS 10.4.8):
$ uname -a
Darwin 127.0.0.1 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25
19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
$ fink --version
Package manager version: 0.25.2
Distribution version: 0.8.1.rsync i386
$ cat config.mak
prefix=/usr/local/stow/git
COLLISION_CHECK=y
NO_DARWIN_PORTS=y
I started trying to use `git bisect` and after several attempts (I
eventually learned the correct pattern of `rm perl/Makefile` and `git
reset --hard`) I found out that the error began with
commit f848718a6980ebda0eb5afb2ca49c3bc1e7b2b1d
Author: Alex Riesen <raa.lkml@gmail.com>
Date: Mon Dec 4 10:50:04 2006 +0100
Make perl/ build procedure ActiveState friendly.
On Cygwin + ActivateState Perl, Makefile generated with
MakeMaker is not usable because of line-endings and
back-slashes.
This teaches perl/Makefile to write a handcrafted equivalent
perl.mak file with 'make NO_PERL_MAKEMAKER=NoThanks'.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'll admit that I'm not savvy enough with make and perl to figure out
how to correct it, although `git revert f84871` does fix it. Can
anyone help?
^ permalink raw reply
* Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Johannes Schindelin @ 2006-12-07 14:13 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Andy Parkins, git
In-Reply-To: <200612070349.58521.Josef.Weidendorfer@gmx.de>
Hi,
On Thu, 7 Dec 2006, Josef Weidendorfer wrote:
> On Thursday 07 December 2006 00:23, Johannes Schindelin wrote:
> > Hi,
> >
> > On Wed, 6 Dec 2006, Josef Weidendorfer wrote:
> >
> > > On Wednesday 06 December 2006 13:07, Andy Parkins wrote:
> > > > The [branch "master"] section is such that there is no change to the
> > > > functionality of git-pull, but that functionality is now explicitly
> > > > documented.
> > >
> > > Nice. However, changing "git-clone" for this is an adhoc solution and
> > > looks wrong.
> >
> > Not to me. There is _no_ other place to put this, if you want to help
> > people graps the concept of branch.*.merge.
>
> As far as I understand, git-clone defaults to kind of a mirror operation
> while changing remotes ref names slightly as tracking branches, and
> afterwards, it sets up a local branch for development, which is
> branched off from the branch which tracks remote's master.
Yes. And I should back off from my strong language: I think this git-clone
the most obvious program to set branch.master.merge. It should make life
easier for new Git users.
Ciao,
^ permalink raw reply
* cygwin, 44k files: how to commit only index?
From: Alex Riesen @ 2006-12-07 14:27 UTC (permalink / raw)
To: git
I have a kind of awkward project to work with (~44k files, many binaries).
The normal "git commit", which seem to be more than enough
for anything and anyone else, is a really annoying procedure
in my context. It spend too much time refreshing index and
generating list of the files for the commit message.
At first I stopped using git commit -a (doing only update-index),
now I'm about to start using write-tree/commit-tree/update-ref
directly. It helps, but sometimes I really miss -F/-C. It's also
ugly: I can (and almost did) commit an unchanged tree.
Is there any simple way to modify git commit for such a workflow?
Failing that, any simple and _fast_ way to find out if the index
^ permalink raw reply
* Re: [PATCH] Documentation: reorganize cvs-migration.txt
From: Johannes Schindelin @ 2006-12-07 14:28 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20061207041805.GC3457@fieldses.org>
Hi,
On Wed, 6 Dec 2006, J. Bruce Fields wrote:
> Modify cvs-migration.txt so it explains first how to develop against a
> shared repository, then how to set up a shared repository, then how to
> import a repository from cvs. Though this seems chronologically
> backwards, it's still readable in this order, and it puts the more
> commonly needed material closer to the front.
This is a laudable goal, and the order makes sense (put first that what
most people are interested in).
A few comments:
- just skimming the patch, I found "commiting" (needs another "t"), and
"-bare" (needs another "-").
- It might make more sense to "git init-db --shared" and fetch the initial
revision into it, rather than clone it and then fix. You might also want
to mention that the "--shared" of -clone is different in meaning from
that of -init-db (make just a footnote of it, to avoid intimidating
readers).
- By far the easiest method to import from cvs is to go to a checked out
_CVS_ working directory, and just say "git cvsimport".
Ciao,
Dscho
^ permalink raw reply
* Re: Commit f84871 breaks build on OS X
From: Alex Riesen @ 2006-12-07 14:33 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <2D096A57-D7B3-49C7-81E4-EB47A0D933B2@silverinsanity.com>
On 12/7/06, Brian Gernhardt <benji@silverinsanity.com> wrote:
> When I pulled the most recent changes for git (de51faf), `make` began
> failing with the following messages:
>
> make -C perl PERL_PATH='/usr/bin/perl' prefix='/usr/local/stow/git' all
> Makefile out-of-date with respect to Makefile.PL /System/Library/Perl/
> 5.8.6/darwin-thread-multi-2level/Config.pm /System/Library/Perl/5.8.6/
> darwin-thread-multi-2level/CORE/config.h
Strange. You seem to have the old, generated Makefile you perl/
directory. Haven't your pull failed? If so, I suspect that
rm perl/Makefile
git reset --hard
git pull git...
^ permalink raw reply
* Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Josef Weidendorfer @ 2006-12-07 14:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andy Parkins, git
In-Reply-To: <Pine.LNX.4.63.0612071511440.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Thursday 07 December 2006 15:13, Johannes Schindelin wrote:
> > > > Nice. However, changing "git-clone" for this is an adhoc solution and
> > > > looks wrong.
> > >
> > > Not to me. There is _no_ other place to put this, if you want to help
> > > people graps the concept of branch.*.merge.
> >
> > As far as I understand, git-clone defaults to kind of a mirror operation
> > while changing remotes ref names slightly as tracking branches, and
> > afterwards, it sets up a local branch for development, which is
> > branched off from the branch which tracks remote's master.
>
> Yes. And I should back off from my strong language: I think this git-clone
> the most obvious program to set branch.master.merge. It should make life
> easier for new Git users.
Oh, no problem ;-) I myself used quite strong words. And I fully agree that
it makes life easier for users. And it is way easier to do it in git-clone
because
(1) in git-clone we _know_ that we branch of a tracking branch; in git-branch,
we first have to check if we want the configuration set.
(2) git-branch is more difficult to change because it's written in C :-)
However, as discussed in another thread, branch.*.merge currently has quite
a strange semantic [*1*], and without changing, users have no way to grasp this
configuration option.
And that branch renaming feature cooking in pu really has to move branch
attributes too, when we even officially set them now in git-clone.
Josef
[*1*] Currently, in branch.*.merge you have to specify the remote branch name
of a refspec which updates a local tracking branch in the fetch phase of git pull.
^ permalink raw reply
* Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Josef Weidendorfer @ 2006-12-07 14:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64cowers.fsf@assigned-by-dhcp.cox.net>
On Thursday 07 December 2006 04:44, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > IMHO there only should be one place/command which is creating new branches,
> > and which is called by other porcelain commands [*1*].
>
> Giving an option to git branch to set something like this up
> would be nice. I would agree the division of labor you propose
> is a good way to keep the scripts maintainable.
>
> It however is a different matter if we would want to set up the
> merge default always in the way you propose for a new branch at
> the policy level.
>
> It also is a different matter if "git branch" has enough
> information to figure out which upstream "origin" needs to be
> fetched from, given an origin SHA-1 expression to create a new
> branch from, at the technical level
We could setup the branch.*.remote option for every tracking branch
git-clone is fetching (and git-fetch with the wildcard refspec).
And git-branch sets branch.*.remote/merge for the new branch
whenever it sees that a remote is set for the branch we are
branching off.
> It entirely is possible to use the same remotes/origin/
> hierarchy to track two physically different URLs (thus two
> different "origin"s) on a mobile machine that has different
> connectivity to the outside world depending on where you are
> ("that mirror is closer from here" and "I need to go over the
> firewall while I am here"). Because they track the logically
> same repository, it does not make sense to use different
> hierarchies under remotes/ for this purpose.
>
> In such a setup, "git branch new origin/for-public" would not be
> able to tell which "origin" to fetch from
I see.
But I hope with my suggestion above, this can be looked up then
in the branch."remotes/origin/for-public".remote option.
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Johannes Schindelin @ 2006-12-07 14:53 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Shawn Pearce, Marco Costalba, Git Mailing List
In-Reply-To: <45781639.1050208@op5.se>
Hi,
On Thu, 7 Dec 2006, Andreas Ericsson wrote:
> Shawn Pearce wrote:
> >
> > Perhaps there is some fast IPC API supported by Qt that you could use
> > to run the revision listing outside of the main UI process, to
> > eliminate the bottlenecks you are seeing and remove the problems noted
> > above? One that doesn't involve reading from a pipe I mean...
> >
>
> Why not just fork() + exec() and read from the filedescriptor? You can
> up the output buffer of the forked program to something suitable, which
> means the OS will cache it for you until you copy it to a buffer in qgit
> (i.e., read from the descriptor).
Could somebody remind me why different processes are needed? I thought
that the revision machinery should be used directly, by linking to
libgit.a...
Ciao,
Dscho
^ permalink raw reply
* Re: Commit f84871 breaks build on OS X
From: Johannes Schindelin @ 2006-12-07 14:55 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <2D096A57-D7B3-49C7-81E4-EB47A0D933B2@silverinsanity.com>
Hi,
On Thu, 7 Dec 2006, Brian Gernhardt wrote:
> When I pulled the most recent changes for git (de51faf), `make` began
> failing with the following messages: [...]
I found the same, but could not reproduce it. But a "touch perl/perl.mak"
fixes at least compilation.
Ciao,
Dscho
^ permalink raw reply
* shallow clones, was Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2006-12-07 14:59 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: Junio C Hamano, git
In-Reply-To: <87zma06ptm.fsf@wine.dyndns.org>
Hi,
On Thu, 7 Dec 2006, Alexandre Julliard wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> * js/shallow (Fri Nov 24 16:00:13 2006 +0100)
> >>
> >> Probably with a better documentation of its limitations and caveats,
> >> this should be mergeable to 'master'.
> >
> > The more I see the missing reaction, the less sure I am this is a sensible
> > thing to do.
>
> I'm not sure what reaction you expect, but this is something a lot of
> our occasional Wine users are requesting. The Wine full history is 80Mb,
> and that's a big download if you just want to try a quick patch. Now of
> course you won't see these users around here hacking on shallow clone,
> most likely they just went and downloaded Wine from the CVS mirror
> instead. But it's a shame to have to maintain a CVS mirror just for that
> purpose...
Sorry, I was just mumbling about the fact that I would _like_ to hear back
about successes and failures. If there are problems I want to fix them.
So, do you actually know of people who _used_ (as opposed to "tested")
shallow clones?
Ciao,
Dscho
^ permalink raw reply
* Re: Commit f84871 breaks build on OS X
From: Pazu @ 2006-12-07 15:20 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0612070633i7aec43dse7a8beda64437103@mail.gmail.com>
Alex Riesen <raa.lkml <at> gmail.com> writes:
> Strange. You seem to have the old, generated Makefile you perl/
> directory. Haven't your pull failed? If so, I suspect that
I've found the same problem as the OP. First my pull failed like you said, but
then I completely wiped my working copy and tried checkout again -- this time it
worked fine. However, the build still fails with the error mentioned by the OP.
-- Pazu
^ permalink raw reply
* Re: [PATCH] Documentation: reorganize cvs-migration.txt
From: J. Bruce Fields @ 2006-12-07 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu008uucx.fsf@assigned-by-dhcp.cox.net>
On Wed, Dec 06, 2006 at 09:51:10PM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
> > index 6812683..773fc99 100644
> > --- a/Documentation/cvs-migration.txt
> > +++ b/Documentation/cvs-migration.txt
> > @@ -1,113 +1,21 @@
>
> This conflicted in a funny way with your own commit but I think
> this version (773fc99 blob) supersedes its contents.
Oh, yeah, sorry, I should have made an incremental patch.
> I munged only one line, though. The title of this section
> should not be "a CVS repository" but "a shared repository" for
> obvious reasons ;-).
Oops, yes, thanks!
^ permalink raw reply
* Re: Commit f84871 breaks build on OS X
From: Andreas Ericsson @ 2006-12-07 15:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Gernhardt, git
In-Reply-To: <Pine.LNX.4.63.0612071554180.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 7 Dec 2006, Brian Gernhardt wrote:
>
>> When I pulled the most recent changes for git (de51faf), `make` began
>> failing with the following messages: [...]
>
> I found the same, but could not reproduce it. But a "touch perl/perl.mak"
> fixes at least compilation.
>
I had to do the same. Somewhere, there's a "mv" that tries to move
perl.mak out of the way and doesn't properly detect the fact that it
isn't there.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* git-svnimport breakage as of git-1.4.4
From: Daniel Drake @ 2006-12-07 15:26 UTC (permalink / raw)
To: git; +Cc: sashak
Hi,
git-svnimport broken between git-1.4.3.5 and git-1.4.4
I have found that commit 83936a29e275bc0c04f60d3333e4951a9e16b1fc is the
cause of this.
I am using git-svnimport to work with a repo with this layout:
https://server/repo/trunk
https://server/repo/tags/x.y.z
https://server/repo/branches/somebranch
Starting a fresh import:
# git-svnimport -v -i -C repo -r https://server repo
Fetching from 1 to 10707 ...
Tree ID 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed change 1:/ 2004-12-22 22:53:27)
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Commit ID 2614c05ac4c5f24eb89cea056a7d46c909084d8c
Writing to refs/heads/origin
DONE: 1 origin 2614c05ac4c5f24eb89cea056a7d46c909084d8c
RA layer request failed: PROPFIND request failed on '/trunk/.cvsignore':
PROPFIND of '/trunk/.cvsignore': 405 Method Not Allowed (https://server)
at /usr/bin/git-svnimport line 358
According to the server logs, git is requesting /trunk/.cvsignore rather
than /repo/trunk/.cvsignore
I'm happy to test patches and whatnot but don't have time to investigate
further right now.
Thanks!
--
Daniel Drake
Brontes Technologies, A 3M Company
^ 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