* [PATCH 1/3] Parse and report branch configuration along with remote configuration.
From: Daniel Barkalow @ 2007-06-12 3:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
remote.c | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-------
remote.h | 13 +++++++++
2 files changed, 94 insertions(+), 11 deletions(-)
diff --git a/remote.c b/remote.c
index d904616..1fbceeb 100644
--- a/remote.c
+++ b/remote.c
@@ -5,6 +5,12 @@
static struct remote **remotes;
static int allocated_remotes;
+static struct branch **branches;
+static int allocated_branches;
+
+static struct branch *current_branch;
+static const char *default_remote_name;
+
#define BUF_SIZE (2048)
static char buffer[BUF_SIZE];
@@ -67,6 +73,45 @@ static struct remote *make_remote(const char *name, int len)
return remotes[empty];
}
+static struct branch *make_branch(const char *name, int len)
+{
+ int i, empty = -1;
+ char *refname;
+
+ for (i = 0; i < allocated_branches; i++) {
+ if (!branches[i]) {
+ if (empty < 0)
+ empty = i;
+ } else {
+ if (len ? (!strncmp(name, branches[i]->name, len) &&
+ !branches[i]->name[len]) :
+ !strcmp(name, branches[i]->name))
+ return branches[i];
+ }
+ }
+
+ if (empty < 0) {
+ empty = allocated_branches;
+ allocated_branches += allocated_branches ? allocated_branches : 1;
+ branches = xrealloc(branches,
+ sizeof(*branches) * allocated_branches);
+ memset(branches + empty, 0,
+ (allocated_branches - empty) * sizeof(*branches));
+ }
+ branches[empty] = xcalloc(1, sizeof(struct branch));
+ if (len)
+ branches[empty]->name = xstrndup(name, len);
+ else
+ branches[empty]->name = xstrdup(name);
+ refname = malloc(strlen(name) + strlen("refs/heads/") + 1);
+ strcpy(refname, "refs/heads/");
+ strcpy(refname + strlen("refs/heads/"),
+ branches[empty]->name);
+ branches[empty]->refname = refname;
+
+ return branches[empty];
+}
+
static void read_remotes_file(struct remote *remote)
{
FILE *f = fopen(git_path("remotes/%s", remote->name), "r");
@@ -144,20 +189,25 @@ static void read_branches_file(struct remote *remote)
add_uri(remote, p);
}
-static char *default_remote_name = NULL;
-static const char *current_branch = NULL;
-static int current_branch_len = 0;
-
static int handle_config(const char *key, const char *value)
{
const char *name;
const char *subkey;
struct remote *remote;
- if (!prefixcmp(key, "branch.") && current_branch &&
- !strncmp(key + 7, current_branch, current_branch_len) &&
- !strcmp(key + 7 + current_branch_len, ".remote")) {
- free(default_remote_name);
- default_remote_name = xstrdup(value);
+ struct branch *branch;
+ if (!prefixcmp(key, "branch.")) {
+ name = key + 7;
+ subkey = strrchr(name, '.');
+ branch = make_branch(name, subkey - name);
+ if (!value)
+ return 0;
+ if (!strcmp(subkey, ".remote")) {
+ branch->remote_name = xstrdup(value);
+ if (branch == current_branch)
+ default_remote_name = branch->remote_name;
+ } else if (!strcmp(subkey, ".merge"))
+ branch->merge_name = xstrdup(value);
+ return 0;
}
if (prefixcmp(key, "remote."))
return 0;
@@ -212,8 +262,8 @@ static void read_config(void)
head_ref = resolve_ref("HEAD", sha1, 0, &flag);
if (head_ref && (flag & REF_ISSYMREF) &&
!prefixcmp(head_ref, "refs/heads/")) {
- current_branch = head_ref + strlen("refs/heads/");
- current_branch_len = strlen(current_branch);
+ current_branch =
+ make_branch(head_ref + strlen("refs/heads/"), 0);
}
git_config(handle_config);
}
@@ -551,3 +601,23 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
}
return 0;
}
+
+struct branch *branch_get(const char *name)
+{
+ struct branch *ret;
+
+ read_config();
+ if (!name || !strcmp(name, "HEAD"))
+ ret = current_branch;
+ else
+ ret = make_branch(name, 0);
+ if (ret->remote_name) {
+ ret->remote = remote_get(ret->remote_name);
+ if (ret->merge_name) {
+ ret->merge = malloc(sizeof(*ret->merge));
+ ret->merge->src = ret->merge_name;
+ remote_find_tracking(ret->remote, ret->merge);
+ }
+ }
+ return ret;
+}
diff --git a/remote.h b/remote.h
index 01dbcef..14615e8 100644
--- a/remote.h
+++ b/remote.h
@@ -38,4 +38,17 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
*/
int remote_find_tracking(struct remote *remote, struct refspec *refspec);
+struct branch {
+ const char *name;
+ const char *refname;
+
+ const char *remote_name;
+ struct remote *remote;
+
+ const char *merge_name;
+ struct refspec *merge;
+};
+
+struct branch *branch_get(const char *name);
+
#endif
--
1.5.2.901.g27ad4-dirty
^ permalink raw reply related
* [PATCH 2/3] Add refspec search for push destinations
From: Daniel Barkalow @ 2007-06-12 3:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Also clarifies the comment for tracking refs, and shares the implementation.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
remote.c | 17 ++++++++++++++---
remote.h | 9 ++++++++-
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/remote.c b/remote.c
index 1fbceeb..b6d6fd6 100644
--- a/remote.c
+++ b/remote.c
@@ -339,11 +339,12 @@ int remote_has_uri(struct remote *remote, const char *uri)
return 0;
}
-int remote_find_tracking(struct remote *remote, struct refspec *refspec)
+static int find_refspec(struct refspec *refspecs, int refspec_nr,
+ struct refspec *refspec)
{
int i;
- for (i = 0; i < remote->fetch_refspec_nr; i++) {
- struct refspec *fetch = &remote->fetch[i];
+ for (i = 0; i < refspec_nr; i++) {
+ struct refspec *fetch = &refspecs[i];
if (!fetch->dst)
continue;
if (fetch->pattern) {
@@ -370,6 +371,16 @@ int remote_find_tracking(struct remote *remote, struct refspec *refspec)
return -1;
}
+int remote_find_tracking(struct remote *remote, struct refspec *refspec)
+{
+ return find_refspec(remote->fetch, remote->fetch_refspec_nr, refspec);
+}
+
+int remote_find_push(struct remote *remote, struct refspec *refspec)
+{
+ return find_refspec(remote->push, remote->push_refspec_nr, refspec);
+}
+
static int count_refspec_match(const char *pattern,
struct ref *refs,
struct ref **matched_ref)
diff --git a/remote.h b/remote.h
index 14615e8..01f83b7 100644
--- a/remote.h
+++ b/remote.h
@@ -34,10 +34,17 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
int nr_refspec, char **refspec, int all);
/*
- * For the given remote, reads the refspec's src and sets the other fields.
+ * For the given remote, reads the refspec's src and sets the other
+ * fields for a fetch refspec.
*/
int remote_find_tracking(struct remote *remote, struct refspec *refspec);
+/*
+ * For the given remote, reads the refspec's src and sets the other
+ * fields for a push refspec.
+ */
+int remote_find_push(struct remote *remote, struct refspec *refspec);
+
struct branch {
const char *name;
const char *refname;
--
1.5.2.901.g27ad4-dirty
^ permalink raw reply related
* [PATCH 0/3] Support config-based names
From: Daniel Barkalow @ 2007-06-12 3:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
It can be useful to refer to commits in remotes based on their configured
relationship to local branches. For example, "git log HEAD^[push]..HEAD"
would, when pushing is set up, show what hasn't been pushed yet.
I picked base^[word] as the format for sha1 names which are some arbitrary
function of base. I think this format isn't used for anything yet, isn't
valid as ref names, and is structureally suitable for having a variety of
extensions. I added {branch}^[merge] for the default head to merge into
{branch} and {branch}^[push] for the tracking ref for the remote branch to
push {branch} to. The push one could be extended to include the branch to
push to by default at other remotes as {branch}^[push:{remote}]. I'm not
too picky about the format for this, if there's something better for the
space of sha1 names that don't have to be super compact and may have lots
of options.
(In order to prepare this email, I set up a push default of my branch to
next, and did: "git log --reverse HEAD^[push]..HEAD" and "git diff --stat
HEAD^[push]...HEAD")
Patch 1 is likely to be independantly useful for things like a
builtin-fetch, which needs to get configuration for branches along with
remotes.
Patch 1: Parse and report branch config
Patch 2: Search for matching push refspec in configuration
Patch 3: Add sha1 names using the preceding functions
remote.c | 109 +++++++++++++++++++++++++++++++++++++++++++++++++++-------
remote.h | 22 +++++++++++-
sha1_name.c | 50 +++++++++++++++++++++++++++
3 files changed, 166 insertions(+), 15 deletions(-)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Please remerge git-gui.git into git.git
From: Shawn O. Pearce @ 2007-06-12 2:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd502niu3.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> Sorry for the screw-up. Will do when able. This week I am a
> bit busy with day job and other stuff and expect to be slow on
> git side.
No big deal, just don't release a git.git without merging git-gui
again please. But it already sounds like you won't be doing that.
;-)
One of the risks I took on when you started carrying git-gui in
git.git like this was patches stepping on git-gui by accident,
or people submitting patches to both git.git and git-gui.git in
the same patchfile (uh, Makefiles anyone?!?).
I'll be happy when the subproject support is mature enough that
git-gui can be unmerged from git.git, and we can instead just point
git.git at the git-gui project. But I still think its a good idea to
distribute git-gui as part of the release tarball for core Git; users
have come to expect they can find a stable version of git-gui there,
much as they also expect to find a reasonably stable version of gitk.
--
Shawn.
^ permalink raw reply
* Re: Problem with a push
From: Junio C Hamano @ 2007-06-12 1:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: plexq, git
In-Reply-To: <alpine.LFD.0.98.0706111727240.14121@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> That said, I don't think that's necessarily the right answer in the longer
> run. It's how git people do things, but it's not necessarily the *best*
> way of doing things. I think the better solution in the longer term is to
> simply improve how "git push" works:
>
> - we should probably do the same kinds of .git/config file entries for
> pushing as we do for fetching, and just get rid of the old implicit
> model, and instead have a nice refspec pattern model for what gets
> pushed instead.
>
> I _think_ the refspec cleanup work by Daniel makes this something we
> can almost already do. Daniel?
That has already been there long before Daniel's patches.
> - we should also likely have some way to specify what happens when you
> push into a branch that is currently checked out and has a working tree
> associated with it.
>
> This was briefly discussed a few weeks ago, but nobody cared enough, I
> suspect.
That actially is in the todo:TODO for some time. Just have been
too busy to look into it.
> anyway, I think the _proper_ thing to do would be to associate each
> [remote] entry in the config file with a "push" refspec pattern, the way
> we do for "fetch" already.
I do not think that is enough. A sane thing if we were doing
"git push" from scratch and there is no existing user's fingers
to re-train, would be:
* "git-push" without anything will default to "git-push
origin"; this has been working for a long time.
* "git-push $remote" when there is [remote] refspec config use
that refspecs, not "matching refs"; this also has been
working for a long time.
* We would want to change git-push so that "git-push $remote"
will _NOT_ default to 'matching refs'. We keep that
'matching refs' behaviour only when the other end is a bare
repository.
* For "git-push $remote" to a non-bare repository, that does
not have [remote] push refspecs, we probably would want to
change the default to refuse operation, or push only
'matching heads' (as opposed to 'matching refs').
Alternatively, we could teach "git clone" and "git remote add"
to add push refspec in the config, and keep the 'matching refs
if there is no push refspec in the config' behaviour.
However, the push refspec needs to be different depending on the
bareness of the remote, and I do not see a good way to arrange
this.
"git clone" does communicate with the remote, so theoretically
we ought to be able to do that, but there currently is no way to
indicate bareness of the remote to the client.
"git remote add" by default does not even communicate with the
remote, so without telepathy that is even more cumbersome to
arrange than "git clone" case.
^ permalink raw reply
* Re: Asking again... [Re: how to properly import perforce history?]
From: Han-Wen Nienhuys @ 2007-06-12 1:19 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Alex Riesen, git
In-Reply-To: <200706112346.13628.simon@lst.de>
Simon Hausmann escreveu:
>> system("p4 revert %s" % f)
>> system("p4 delete %s" % f)
>
> Ooops, indeed. Makes me realizes that I've never actually submitted files with
> spaces in the name :). For now I've quoted them with double quotes like in
> the other places, which is better than nothing. Thanks for spotting!
>>> import commands
>>> commands.mkarg ('$foo bar')
" '$foo bar'"
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: git-p4 fails when cloning a p4 depo.
From: Han-Wen Nienhuys @ 2007-06-12 1:13 UTC (permalink / raw)
To: git
In-Reply-To: <1621f9fa0706081113w7bb765ebx74f03a7407b753cb@mail.gmail.com>
Benjamin Sergeant escreveu:
> A perforce command with all the files in the repo is generated to get
> all the file content.
> Here is a patch to break it into multiple successive perforce command
> who uses 4K of parameter max, and collect the output for later.
>
> It works, but not for big depos, because the whole perforce depo
> content is stored in memory in P4Sync.run(), and it looks like mine is
> bigger than 2 Gigs, so I had to kill the process.
General idea of the patch is ok. some nits:
> + chunk = ''
> + filedata = []
> + for i in xrange(len(files)):
why not
for f in files:
?
> + f = files[i]
> + chunk += '"%s#%s" ' % (f['path'], f['rev'])
> + if len(chunk) > 4000 or i == len(files)-1:
4k seems reasonable enough, but can you take the min() with
os.sysconf('SC_ARG_MAX') ?
Can you address this and resend so we can apply the patch?
Thanks.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: git-p4 fails when cloning a p4 depo.
From: Han-Wen Nienhuys @ 2007-06-12 1:08 UTC (permalink / raw)
To: git; +Cc: Benjamin Sergeant
In-Reply-To: <200706090038.33799.simon@lst.de>
Simon Hausmann escreveu:
> On Friday 08 June 2007 20:13:55 Benjamin Sergeant wrote:
>> A perforce command with all the files in the repo is generated to get
>> all the file content.
>> Here is a patch to break it into multiple successive perforce command
>> who uses 4K of parameter max, and collect the output for later.
>>
>> It works, but not for big depos, because the whole perforce depo
>> content is stored in memory in P4Sync.run(), and it looks like mine is
>> bigger than 2 Gigs, so I had to kill the process.
>
> I'd be generally fine with splitting up the "p4 print ..." calls into chunks
> but you have a good point with the memory usage. The old approach of calling
> print per file did not have any of those limitations. Han-Wen, what do you
> think? How much of a performance improvement is the batched print?
One unscientific measurement (getting 1 file vs. 30 files)
indicates that this is about 5x times faster.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: git-p4 fails when cloning a p4 depo.
From: Han-Wen Nienhuys @ 2007-06-12 1:07 UTC (permalink / raw)
To: git; +Cc: Han-Wen Nienhuys, Benjamin Sergeant, git
In-Reply-To: <200706090038.33799.simon@lst.de>
Simon Hausmann escreveu:
> On Friday 08 June 2007 20:13:55 Benjamin Sergeant wrote:
>> A perforce command with all the files in the repo is generated to get
>> all the file content.
>> Here is a patch to break it into multiple successive perforce command
>> who uses 4K of parameter max, and collect the output for later.
>>
>> It works, but not for big depos, because the whole perforce depo
>> content is stored in memory in P4Sync.run(), and it looks like mine is
>> bigger than 2 Gigs, so I had to kill the process.
>
> I'd be generally fine with splitting up the "p4 print ..." calls into chunks
> but you have a good point with the memory usage. The old approach of calling
> print per file did not have any of those limitations. Han-Wen, what do you
> think? How much of a performance improvement is the batched print?
One unscientific measurement (getting 1 file vs. 30 files)
indicates that this is about 5x times faster.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Problem with a push
From: Linus Torvalds @ 2007-06-12 0:40 UTC (permalink / raw)
To: plexq; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706111832070.4830@www.mintpixels.com>
On Mon, 11 Jun 2007, Alex R.M. Turner wrote:
>
> Cool - that totally makes sense, HEAD is a link to master. so updating
> HEAD failed because it was already up to date.
Yes. Well, strictly speaking it failed because it _wasn't_ up-to-date
*before* the push (so "git push" thought it should update it), but it had
become up-to-date (through the symref link) by the time it was actually
its turn to be updated.
> The command was simply:
>
> git push
Ok, as Junio points out, it's then just the fact that both repositories
had the same "remote" refs, and then the default of just updating
everything in common kicks in.
That default used to make sense back when, but it doesn't make sense for
remotes, since those are generally "local" to each repo.
> This repo was cloned from one on another server (the server I use to
> backup everything) with a git clone command:
Yeah. Normally you'd (well, _I_ would) only push to bare repositories, and
normally you wouldn't make those bare repositories have "remotes" entries,
which is why you're the first to apparently even notice this insanity.
It wasn't your fault, it's simply bad defaults for git behaviour.
The behaviour for "git pull" has improved _immensely_ over the last few
months, but "git push" still does the same thing it always did, because
fewer people care about pushing than pulling, and because the old "git
push" behaviour of just updating all the branches in common actually
happens to be the right thing when you do *not* make the central
repository contain remote branches of its own.
> Based on all this, what is the correct way to update my core repo on my
> server? (I'm sorry - I'm pretty new to git, so I haven't quite cottoned on
> to some aspects yet).
With the current git model, I would suggest:
- for "central" repositories, use a bare repository, and don't create
"remotes" branches in that central repository at all.
- for other repositories, don't push into them, just _pull_ into them
(because that also knows about updating the working tree etc: pushing
is really meant to be done only into bare and central ones that don't
actually have any work happening in them, and _cannot_ have any work
happening in them because they don't even have a working directory
associated with them)
That said, I don't think that's necessarily the right answer in the longer
run. It's how git people do things, but it's not necessarily the *best*
way of doing things. I think the better solution in the longer term is to
simply improve how "git push" works:
- we should probably do the same kinds of .git/config file entries for
pushing as we do for fetching, and just get rid of the old implicit
model, and instead have a nice refspec pattern model for what gets
pushed instead.
I _think_ the refspec cleanup work by Daniel makes this something we
can almost already do. Daniel?
- we should also likely have some way to specify what happens when you
push into a branch that is currently checked out and has a working tree
associated with it.
This was briefly discussed a few weeks ago, but nobody cared enough, I
suspect.
anyway, I think the _proper_ thing to do would be to associate each
[remote] entry in the config file with a "push" refspec pattern, the way
we do for "fetch" already.
Linus
^ permalink raw reply
* Re: Please remerge git-gui.git into git.git
From: Junio C Hamano @ 2007-06-11 23:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070611231013.GM6073@spearce.org>
Sorry for the screw-up. Will do when able. This week I am a
bit busy with day job and other stuff and expect to be slow on
git side.
^ permalink raw reply
* Re: Problem with a push
From: Junio C Hamano @ 2007-06-11 23:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: plexq, git
In-Reply-To: <alpine.LFD.0.98.0706111556160.14121@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> What was the command line? In particular, was this a "git push --all" or
> something? I think we should make sure that we do *not* push remotes by
> default (and if you really *really* want to push remotes, you'd have to
> specify them explicitly).
I suspect that people (probably rightfully) just say "git push"
without saying anything else, and the so-useful-for-old-timers
default "matching refs" behaviour bites them when they do so.
If you create a non-bare clone, clone from that, and then try to
push from the second generation clone to the first generation
non-bare clone, surely there will be "matching" remotes/origin/,
except that they are not really matching X-<.
^ permalink raw reply
* Re: Asking again... [Re: how to properly import perforce history?]
From: Scott Lamb @ 2007-06-11 23:41 UTC (permalink / raw)
To: Alex Riesen; +Cc: Simon Hausmann, git
In-Reply-To: <20070611231648.GC4649@steel.home>
Alex Riesen wrote:
> Scott Lamb, Mon, Jun 11, 2007 23:20:43 +0200:
>>>>> git-p4 clone //depot/project/path [libs/project/path] [rev-range]
>>>> I'm not sure I understand the libs/project/path part, ...
>>> Your client contains the mappings. It defines how the pathnames on the
>>> p4 server relate to that on your computer. In the example above file
>> >from the depot path //depot/project/path can be found in the directory
>>> of the p4 client in the subdirectories libs/project/path.
>> git-p4 doesn't even use a p4 client, ...
>
> I didn't say: "using p4 client, figure out where to put the files".
> I said: _here_ is the mapping, put the files where I told you to.
No, you didn't say. The words you used would make equal sense with "the
tool should look for //depot/project/path in the working copy at
libs/project/path".
>>>> Han-Wen implemented also support for importing multiple depot paths at
>>>> the same time (and tracking them in one git branch).
>>> And where does he put the depot paths? As they are in depot? How does
>>> this corelate to the setups done by genuine P4 users (the poor souls)
>>> where the mappings are not always 1-to-1 right from the root? Or you
>>> haven't got any?
>> Could you give a concrete example of what you have and what you are
>> trying to produce?
>
> Get the p4 file //depot/project/file and put it into git as
> libs/project/file.
Okay. Keep in mind that you're the first person to find this important.
>
>>>> The environment I'm working in is not too big and fairly liberal and
>>>> reasonably disciplined.
>>> You must be very strange environment indeed. Carefully balanced.
>> Not that strange. My company's setup is pretty simple, too. The project
>> I'm working on just uses has each branch under
>> "//depot/project/BRANCH/...".
>
> It is not a branch (as a "line of development"). It is merely a
> directory with server-side backup. Why do people continue call them
> branches, I wonder...
You're being deliberately dense, but I'll explain anyway.
We have several branches of our code. We keep each one in Perforce under
//depot/project/BRANCH/... with appropriate integration history between.
We follow the best practices outlined in the Perforce manual. [1] We use
the same terminology as defined in the Perforce manual.
From your comments, I would guess that you have badly mismanaged your
Perforce tree. Since the other people working on the tool apparently
have not, you may have to do your own work to migrate away.
Subversion has a very similar model to Perforce (the main differences
being that svn does not track merge history and does not have a separate
tag system). I have a Subversion repository in which I did not follow
the recommended practices for branching. Who do I blame for that? Me.
Who will fix it? Hopefully me. I may ask for help, but I'll do so with a
better attitude than you.
>> Maybe your environment is the odd one?
>
> Just what do you think is a client view? Ever wondered what the
> right-hand side of lines in the "View:" section is for?
I know what client views are, and I know what they are capable of. I can
say the same thing about symlinks. Is an importer tool broken if it does
not follow a bizarre reorganization of the source working copy through
symlinks?
[1] -
http://www.perforce.com/perforce/doc.072/manuals/p4guide/06_codemgmt.html#1065698
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* Re: Problem with a push
From: Alex R.M. Turner @ 2007-06-11 23:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: plexq, git
In-Reply-To: <alpine.LFD.0.98.0706111556160.14121@woody.linux-foundation.org>
On Mon, 11 Jun 2007, Linus Torvalds wrote:
>
>
> On Mon, 11 Jun 2007, Alex R.M. Turner wrote:
> >
> > I get the following error when pushing after a merge:
> >
> > updating 'refs/heads/master'
> > from c18f9e4350c26e6b45d0a282ff32991784becbdd
> > to 39b7d927720c9f2810e0af5311975119c0d7c7bd
> > updating 'refs/remotes/origin/HEAD'
> > from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
> > to c18f9e4350c26e6b45d0a282ff32991784becbdd
> > updating 'refs/remotes/origin/master'
> > from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
> > to c18f9e4350c26e6b45d0a282ff32991784becbdd
>
> Ok, pushing out remote branches is a bit odd in the first place. As in
> "you probably shouldn't do that". The "remote" branches are really local
> to each repo, and updating them by pushing is really quite suspect.
>
> So the regular "master" branch pushed out fine:
>
> > refs/heads/master: c18f9e4350c26e6b45d0a282ff32991784becbdd -> 39b7d927720c9f2810e0af5311975119c0d7c7bd
>
> and that part is all ok.
>
> However, I think the problem is this:
>
> > refs/remotes/origin/HEAD: 1e631edb3078ec3a4d1fa598c8f410f6a61659b0 -> c18f9e4350c26e6b45d0a282ff32991784becbdd
>
> You updated the HEAD file, but that actually is a _symbolic_ ref, which
> normally points to refs/removes/origin/HEAD, and that in turn explains the
> other errors:
>
> > ng refs/remotes/origin/master failed to lock
> > error: Ref refs/remotes/origin/master is at c18f9e4350c26e6b45d0a282ff32991784becbdd but expected 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
> > error: failed to lock refs/remotes/origin/master
> > error: failed to push to 'ssh://aturner@svn.mintpixels.com/data/git/mls'
>
> What happened is that the "remotes/origin/master" branch already got
> updated when you updated HEAD, so now git is complaining that you are
> trying to update it again, but it no longer has the same value that it had
> originally (since you changed it).
>
> > but when I try it again, it just says Everything up-to-date.
>
> Right. Because the HEAD update really already did all the changes (to
> _both_ remotes/origin/HEAD _and_ remotes/origin/master, since it was a
> symref), so next time around there is nothing to push, and you won't see
> this issue any more.
>
> So I don't think there was anything reall bad going on, except for the
> fact that you really shouldn't try to push out remote branches.
>
> What was the command line? In particular, was this a "git push --all" or
> something? I think we should make sure that we do *not* push remotes by
> default (and if you really *really* want to push remotes, you'd have to
> specify them explicitly).
>
> Linus
>
Cool - that totally makes sense, HEAD is a link to master. so updating
HEAD failed because it was already up to date. The command was simply:
git push
This repo was cloned from one on another server (the server I use to
backup everything) with a git clone command:
git clone ssh://aturner@svn.mintpixels.com/data/git/mls
.git/config looks like this:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = ssh://aturner@svn.mintpixels.com/data/git/mls
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[user]
email = alex@mintpixels.com
name = Alex R.M. Turner
git branch -a shows:
* master
origin/HEAD
origin/master
Based on all this, what is the correct way to update my core repo on my
server? (I'm sorry - I'm pretty new to git, so I haven't quite cottoned on
to some aspects yet).
Alex
^ permalink raw reply
* Re: Asking again... [Re: how to properly import perforce history?]
From: Alex Riesen @ 2007-06-11 23:16 UTC (permalink / raw)
To: Scott Lamb; +Cc: Simon Hausmann, git
In-Reply-To: <466DBCAB.8090006@slamb.org>
Scott Lamb, Mon, Jun 11, 2007 23:20:43 +0200:
> >>> git-p4 clone //depot/project/path [libs/project/path] [rev-range]
> >>
> >>I'm not sure I understand the libs/project/path part, ...
> >
> >Your client contains the mappings. It defines how the pathnames on the
> >p4 server relate to that on your computer. In the example above file
> >from the depot path //depot/project/path can be found in the directory
> >of the p4 client in the subdirectories libs/project/path.
>
> git-p4 doesn't even use a p4 client, ...
I didn't say: "using p4 client, figure out where to put the files".
I said: _here_ is the mapping, put the files where I told you to.
> >>Han-Wen implemented also support for importing multiple depot paths at
> >>the same time (and tracking them in one git branch).
> >
> >And where does he put the depot paths? As they are in depot? How does
> >this corelate to the setups done by genuine P4 users (the poor souls)
> >where the mappings are not always 1-to-1 right from the root? Or you
> >haven't got any?
>
> Could you give a concrete example of what you have and what you are
> trying to produce?
Get the p4 file //depot/project/file and put it into git as
libs/project/file.
> >>The environment I'm working in is not too big and fairly liberal and
> >>reasonably disciplined.
> >
> >You must be very strange environment indeed. Carefully balanced.
>
> Not that strange. My company's setup is pretty simple, too. The project
> I'm working on just uses has each branch under
> "//depot/project/BRANCH/...".
It is not a branch (as a "line of development"). It is merely a
directory with server-side backup. Why do people continue call them
branches, I wonder...
> Maybe your environment is the odd one?
Just what do you think is a client view? Ever wondered what the
right-hand side of lines in the "View:" section is for?
^ permalink raw reply
* Please remerge git-gui.git into git.git
From: Shawn O. Pearce @ 2007-06-11 23:10 UTC (permalink / raw)
To: Junio C Hamano, git
Currently the tree between git-gui.git and git.git:git-gui does
not match, due to a6080a0a44d5ead84db3dabbbc80e82df838533d, aka the
"War on whitespace".
I really want the git-gui tree in git.git to always match the tree
of the 2nd parent of the merge commit, as that is how git-gui's
own GIT-VERSION-GEN script finds the git-gui commit DAG and gets
git-describe to produce a git-gui specific version number, rather
than the git.git version number.
Right now that script is barfing and coming up with "0.8.GITGUI",
which isn't a valid version number, and means nothing to everyone.
So new `maint` and `master` branches are in git-gui.git.
Thanks! ;-)
--
Shawn.
^ permalink raw reply
* Re: [RFC] Teach diff to imply --find-copies-harder upon -C -C
From: Brian Gernhardt @ 2007-06-11 23:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706112109180.4059@racer.site>
On Jun 11, 2007, at 4:12 PM, Johannes Schindelin wrote:
>
> earlier, a second "-C" on the command line had no effect. But since
> I use
> "--find-copies-harder" quite a bit, and it is so long to type, and
> I am
> an inherently lazy person, I'd like the second "-C" to be a
> shortcut for
> "--find-copies-harder".
I like it. "git-diff -C -C ..." reads "git-diff, find copies. No
really, find copies."
~~ Brian
^ permalink raw reply
* Re: Problem with a push
From: Linus Torvalds @ 2007-06-11 23:03 UTC (permalink / raw)
To: plexq; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706111632050.4406@www.mintpixels.com>
On Mon, 11 Jun 2007, Alex R.M. Turner wrote:
>
> I get the following error when pushing after a merge:
>
> updating 'refs/heads/master'
> from c18f9e4350c26e6b45d0a282ff32991784becbdd
> to 39b7d927720c9f2810e0af5311975119c0d7c7bd
> updating 'refs/remotes/origin/HEAD'
> from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
> to c18f9e4350c26e6b45d0a282ff32991784becbdd
> updating 'refs/remotes/origin/master'
> from 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
> to c18f9e4350c26e6b45d0a282ff32991784becbdd
Ok, pushing out remote branches is a bit odd in the first place. As in
"you probably shouldn't do that". The "remote" branches are really local
to each repo, and updating them by pushing is really quite suspect.
So the regular "master" branch pushed out fine:
> refs/heads/master: c18f9e4350c26e6b45d0a282ff32991784becbdd -> 39b7d927720c9f2810e0af5311975119c0d7c7bd
and that part is all ok.
However, I think the problem is this:
> refs/remotes/origin/HEAD: 1e631edb3078ec3a4d1fa598c8f410f6a61659b0 -> c18f9e4350c26e6b45d0a282ff32991784becbdd
You updated the HEAD file, but that actually is a _symbolic_ ref, which
normally points to refs/removes/origin/HEAD, and that in turn explains the
other errors:
> ng refs/remotes/origin/master failed to lock
> error: Ref refs/remotes/origin/master is at c18f9e4350c26e6b45d0a282ff32991784becbdd but expected 1e631edb3078ec3a4d1fa598c8f410f6a61659b0
> error: failed to lock refs/remotes/origin/master
> error: failed to push to 'ssh://aturner@svn.mintpixels.com/data/git/mls'
What happened is that the "remotes/origin/master" branch already got
updated when you updated HEAD, so now git is complaining that you are
trying to update it again, but it no longer has the same value that it had
originally (since you changed it).
> but when I try it again, it just says Everything up-to-date.
Right. Because the HEAD update really already did all the changes (to
_both_ remotes/origin/HEAD _and_ remotes/origin/master, since it was a
symref), so next time around there is nothing to push, and you won't see
this issue any more.
So I don't think there was anything reall bad going on, except for the
fact that you really shouldn't try to push out remote branches.
What was the command line? In particular, was this a "git push --all" or
something? I think we should make sure that we do *not* push remotes by
default (and if you really *really* want to push remotes, you'd have to
specify them explicitly).
Linus
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Frank Lichtenheld @ 2007-06-11 22:59 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <11815891463922-git-send-email-hjemli@gmail.com>
On Mon, Jun 11, 2007 at 09:12:25PM +0200, Lars Hjemli wrote:
> +Consider the following .gitmodules file:
> +
> + [submodule 'libfoo']
> + path = include/foo
> + url = git://foo.com/git/lib.git
> +
> + [submodule 'libbar']
> + path = include/bar
> + url = git://bar.com/git/lib.git
> +
Still the wrong quotes.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Does anyone have any benchmarks against CVS?
From: Junio C Hamano @ 2007-06-11 22:45 UTC (permalink / raw)
To: Martin Langhoff; +Cc: linux@horizon.com, git
In-Reply-To: <46a038f90706111454i5f4898b5kd77d18f4a893904e@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> It _will_ be a bit of an apple-to-oranges comparison, but you could
> use a few large-ish projects that have a published GIT gateway.
> ...
> - cvs status vs git status
This _is_ apples and oranges. git status is not about "the
current status of working tree" but about "what I would commit
if I were to say git-commit at this moment". "cvs status" does
a lot more, I think. Also I haven't met anybody who says "cvs
status" is useful; people seem to use "cvs -q update -n" often
when they want to know "what's different between me and
upstream"?
> - cvs update vs git pull
While that is a valid comparison, I think CVS users use "cvs
update" (especially "cvs -q update -n" variant) far more
frequently for the purpose of seeing "what did I change so far"
than truly try to update from the upstream. So a comparison
that has more real-life significance would be "cvs -q update -n"
vs "git diff --name-status HEAD".
There are a handful more.
- "git pull -n" vs "cvs up" when your tree is clean and you are
a dozen revs behind.
- "cvs co -rother-branch" vs "git checkout other-branch".
- "cvs diff -rold-version" vs "git diff old-version".
- "git am a-dozen-of-mails" vs its cvs equivalent.
- "git rebase a-dozen-of-commits" vs its cvs equivalent.
- "git log path/to/directory/" vs its cvs equivalent
^ permalink raw reply
* Re: Does anyone have any benchmarks against CVS?
From: Robin H. Johnson @ 2007-06-11 22:30 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <46a038f90706111454i5f4898b5kd77d18f4a893904e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]
On Tue, Jun 12, 2007 at 09:54:50AM +1200, Martin Langhoff wrote:
> On 11 Jun 2007 05:04:51 -0400, linux@horizon.com <linux@horizon.com> wrote:
> > It seems to be common knowledge that git is a heck of a lot faster than
> > CVS at most operations, but I'd like to do a little evangelizing and
> > I can't seem to find a benchmark to support that claim.
>
> It _will_ be a bit of an apple-to-oranges comparison, but you could
> use a few large-ish projects that have a published GIT gateway.
> Measure time and bw use of
>
> - cvs co vs git clone
On the Git side, give breakdowns of the time for cloning with --bare
(git-fetch) and the separate actual checkout time.
Also compare the effects of shallow clones.
> - cvs update vs git pull
Again, do both the git-fetch and git-merge portions.
> - cvs log (at top level) vs git log
cvs history vs. git log might be more appropriate in the top level
sense.
--
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
* Re: Does anyone have any benchmarks against CVS?
From: david @ 2007-06-11 22:06 UTC (permalink / raw)
To: Martin Langhoff; +Cc: linux@horizon.com, git
In-Reply-To: <46a038f90706111454i5f4898b5kd77d18f4a893904e@mail.gmail.com>
On Tue, 12 Jun 2007, Martin Langhoff wrote:
> Date: Tue, 12 Jun 2007 09:54:50 +1200
> From: Martin Langhoff <martin.langhoff@gmail.com>
> To: "linux@horizon.com" <linux@horizon.com>
> Cc: git@vger.kernel.org
> Subject: Re: Does anyone have any benchmarks against CVS?
>
> On 11 Jun 2007 05:04:51 -0400, linux@horizon.com <linux@horizon.com> wrote:
>> It seems to be common knowledge that git is a heck of a lot faster than
>> CVS at most operations, but I'd like to do a little evangelizing and
>> I can't seem to find a benchmark to support that claim.
>
> It _will_ be a bit of an apple-to-oranges comparison, but you could
> use a few large-ish projects that have a published GIT gateway.
> Measure time and bw use of
>
> - cvs co vs git clone
given that the result of this is that cvs gives you one version and git
clone gives you the entire history you should probably also test what it
takes to checkout an older version after doing the first one.
David Lang
> - cvs status vs git status
> - cvs update vs git pull
> - cvs log (at top level) vs git log
> - cvs log path/to/file vs git log path/to/file
>
> I would suggest
>
> - Moodle (for which I maintain an http-fetchable repo at
> http://git.catalyst.net.nz/git/moodler2.git )
> - PostgreSQL (repo.or.cz hosts a repo)
>
> cheers
>
>
> m
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Does anyone have any benchmarks against CVS?
From: Martin Langhoff @ 2007-06-11 21:54 UTC (permalink / raw)
To: linux@horizon.com; +Cc: git
In-Reply-To: <20070611090451.26209.qmail@science.horizon.com>
On 11 Jun 2007 05:04:51 -0400, linux@horizon.com <linux@horizon.com> wrote:
> It seems to be common knowledge that git is a heck of a lot faster than
> CVS at most operations, but I'd like to do a little evangelizing and
> I can't seem to find a benchmark to support that claim.
It _will_ be a bit of an apple-to-oranges comparison, but you could
use a few large-ish projects that have a published GIT gateway.
Measure time and bw use of
- cvs co vs git clone
- cvs status vs git status
- cvs update vs git pull
- cvs log (at top level) vs git log
- cvs log path/to/file vs git log path/to/file
I would suggest
- Moodle (for which I maintain an http-fetchable repo at
http://git.catalyst.net.nz/git/moodler2.git )
- PostgreSQL (repo.or.cz hosts a repo)
cheers
m
^ permalink raw reply
* Re: Asking again... [Re: how to properly import perforce history?]
From: Simon Hausmann @ 2007-06-11 21:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070611201232.GA4649@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]
On Monday 11 June 2007 22:12:32 Alex Riesen wrote:
[...]
> > > And, BTW, don't you have a small problem with filenames with
> > > spaces and quoting?
> >
> > I'm not aware of any problems. For example in our depot we have filenames
> > with spaces in them and they appear just fine in my git import. Did you
> > run into any specific case? It could very well be that there's a bug
> > somewhere that I'm just not hitting myself, so I'm curious :)
>
> No, I just looking at the source. Does python have some magic for
> running programs with system() when passed a format string? Like here:
>
> for f in filesToAdd:
> system("p4 add %s" % f)
> for f in filesToDelete:
> system("p4 revert %s" % f)
> system("p4 delete %s" % f)
Ooops, indeed. Makes me realizes that I've never actually submitted files with
spaces in the name :). For now I've quoted them with double quotes like in
the other places, which is better than nothing. Thanks for spotting!
> BTW, sometimes you quote the names, but obviously wrong (think about
> filenames containing double quotes):
>
> system("p4 edit \"%s\"" % path)
> editedFiles.add(path)
Indeed, for file names with double quotes that doesn't work. I guess I'll have
to change that to subprocess.Popen then :)
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Johannes Schindelin @ 2007-06-11 21:40 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sam Vilain, Steven Grimm, Shawn O. Pearce, Junio C Hamano,
Daniel Barkalow, Theodore Ts'o, Git Mailing List
In-Reply-To: <alpine.LFD.0.99.0706110930170.12885@xanadu.home>
Hi,
On Mon, 11 Jun 2007, Nicolas Pitre wrote:
> But you'd better have a concrete data set and result numbers to convince
> me. Designing software for hypothetical situations before they actually
> exist leads to bloatware.
Right you are. So I'll not mention it until I have it ;-)
Ciao,
Dscho
^ 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