git bug? + question

git bug? + question

[Miles Bader]

Hi,

I tried the following sequence of commands to make two clones of a
remote repository, but got an error:

   $ git clone --use-separate-remote ssh://fp.gnu.org/~/git/snogray.git snogray-git
   $ git clone --use-separate-remote --reference snogray-git ssh://fp.gnu.org/~/git/snogray.git imp-sample
   error: refs/reference-tmp/refs/remotes/origin/HEAD points nowhere!

Is this a real error, or bad usage?

Also, a question:  Is there anyway to make git-clone use
--use-separate-remote by default?  I'm trying for a "lots of branches in
a single shared remote repository" style, and use-separate-remote seems
more sane for this usage.

I'm using git version 1.4.3.3.

Thanks,

-Miles

-- 
"I distrust a research person who is always obviously busy on a task."

Re: git bug? + question

[Junio C Hamano]

Miles Bader <miles.bader@necel.com> writes:

> Also, a question:  Is there anyway to make git-clone use
> --use-separate-remote by default?  I'm trying for a "lots of branches in
> a single shared remote repository" style, and use-separate-remote seems
> more sane for this usage.

This was suggested last week on the list, and I think it is a
sensible thing to do.

Karl Hasselström <kha@treskal.com> writes:

> On 2006-10-26 10:11:50 -0700, Linus Torvalds wrote:
>
>> But it's a good rule in general, just because it makes a certain
>> common workflow explicit. In fact, we really probably should start
>> to always use the "refs/remote/origin/HEAD" kind of syntax by
>> default, where you can't even _switch_ to the branch maintained in
>> the remote repository, because it's not a real branch locally.
>
> Seconded. I really like having remote branches in their own namespace
> where I can't confuse them with my local branches by mistake -- and
> that the branches of different remotes end up in different separate
> namespaces.
>
>> So normally you should consider the "origin" branch to be a pointer
>> to WHAT YOU FETCHED LAST - and that implies that you shouldn't
>> commit to it, because then it loses that meaning (now it's "what you
>> fetched last and then committed your own work on top of", which is
>> something totally different).
>
> Defaulting to --use-separate-remotes would mean not having to explain
> this to every single confused new user. :-)

The only downside that I can think of is that it affects me or
anybody who works on more than one machine on multiple branches
slightly negatively.

I know I keep "master" checked out on my secondary machines when
I am done working there, so the mapping origin:master,
maint:maint, next:next, and +pu:pu I get by default has been
easy for me to work on.  With the current layout, updating and
building four variants can be done with:

	git pull
        for b in master maint next pu
        do
        	git checkout $b && make || break
	done

which is efficient (guaranteed to do only one fetch from remote)
and convenient.  Also I have Push: mapping set up on my
main machine to do master:origin, next:next, maint:maint, and
+pu:pu so that I can replace the first "git pull" on the
secondary machine with "git push secondary" on my main machine.

With separate remotes, I'd need something like:

	for b in master maint next pu
        do
        	git checkout $b && git pull && make || break
	done

And I also would need to have per-branch configuration to merge
from ". remotes/origin/$b" without re-fetching while on a
non-master branch $b, for the above to work.  I still need to
remember to process "master" first, so all things considered,
this is a regression in usability for my workflow.

But that is probably a minor inconvenience to a minority.  Most
of the world follow others' repositories that have a single
primary head, and defaulting to use separate-remote would help
them a lot.

So I am in favor of the change, but this is not something we can
do in a flag-day fashion.  We would probably need updating the
tutorial and the documentation first.

Re: git bug? + question

[Sean]

On Thu, 02 Nov 2006 18:40:30 -0800
Junio C Hamano <junkio@cox.net> wrote:

> which is efficient (guaranteed to do only one fetch from remote)
> and convenient.  Also I have Push: mapping set up on my
> main machine to do master:origin, next:next, maint:maint, and
> +pu:pu so that I can replace the first "git pull" on the
> secondary machine with "git push secondary" on my main machine.

One thing that would make separate-remotes nicer to work with
is to have an automatic mapping between any local branch and
one of the same name in remotes.

So for instance, if you have a local branch named pu checked
out and you pull from origin, remotes/origin/pu would be merged
after the fetch unless a manual mapping was defined in the
remotes or config file.

Maybe even going as far as automatically creating a local branch
for each remote branch on clone is worth considering.

On a peripherally related topic, someone on the xorg list was
complaining that after the initial clone, there is no easy way
to track branches that get added/deleted from the remote repo.
It would be nice if pull had an option to automatically add
and remove remote branches from the remotes/<remote>/xxx
namespace.

Re: git bug? + question

[Karl Hasselström]

On 2006-11-02 18:40:30 -0800, Junio C Hamano wrote:

> which is efficient (guaranteed to do only one fetch from remote) and
> convenient.

Hmm, this is interesting. 99% of the time, I use "git fetch", followed
by "git pull . remotes/origin/foo" (often having run gitk in between
the two in order to see what's coming). I like to know what I'm
pulling (yes, I know how to undo a bad pull, but still ...).

> And I also would need to have per-branch configuration to merge from
> ". remotes/origin/$b" without re-fetching while on a non-master
> branch $b, for the above to work.

This is a good point. The "remotes/$repo/$branch" names are quite a
mouthful to type, so default pull sources would be a definite
improvement. (It would also be an improvement for the case when the
user is susceptible to the human factor.) Simply defaulting to pull
from the branch that this branch was cloned from should do the trick
(but the pull source should of course be editable).

> I still need to remember to process "master" first, so all things
> considered, this is a regression in usability for my workflow.

Where does this constraint come from?

> But that is probably a minor inconvenience to a minority.  Most
> of the world follow others' repositories that have a single
> primary head, and defaulting to use separate-remote would help
> them a lot.

I can attest that separate remotes is a usability win also when using
several branches from more than one remote source. It's actually
possible to infer from the branch name (remotes/$repo/$branch) which
branch from which repository is being tracked.

As an aside, in case of several remote repositories, "git fetch --all"
would be handy.

-- 
Karl Hasselström, kha@treskal.com

Re: git bug? + question

[Karl Hasselström]

On 2006-11-02 22:45:49 -0500, Sean wrote:

> One thing that would make separate-remotes nicer to work with is to
> have an automatic mapping between any local branch and one of the
> same name in remotes.
>
> So for instance, if you have a local branch named pu checked out and
> you pull from origin, remotes/origin/pu would be merged after the
> fetch unless a manual mapping was defined in the remotes or config
> file.

I would rather see the default pull source of a branch being
determined by which branch it was branched off of. But this should
mean the same thing in this case. We'd just have to have the heuristic
that default pulls from a remotes/*/* branch causes a fetch, while a
default pull from a local branch does not.

> Maybe even going as far as automatically creating a local branch for
> each remote branch on clone is worth considering.

Yes, maybe. It should make for a good default for beginners, at least.

> On a peripherally related topic, someone on the xorg list was
> complaining that after the initial clone, there is no easy way to
> track branches that get added/deleted from the remote repo. It would
> be nice if pull had an option to automatically add and remove remote
> branches from the remotes/<remote>/xxx namespace.

That would definitely be useful. But I want it in fetch, not pull. :-)
Well, I suppose it could be in both.

Hmm, I think my dislike of remote pulls can be summed up as: I find it
convoluted to have a command that will fetch multiple remote branches,
then merge just one of them into my current branch. (I have no problem
with pull when the branches to pull are specified explicitly, since in
that case they are all merged.) With explicitly specified default pull
sources it would get better, since then I would know that the correct
branch would be merged, but I still don't quite like it.

-- 
Karl Hasselström, kha@treskal.com

Re: git bug? + question

[Junio C Hamano]

Karl Hasselström <kha@treskal.com> writes:

> On 2006-11-02 18:40:30 -0800, Junio C Hamano wrote:
>
>> I still need to remember to process "master" first, so all things
>> considered, this is a regression in usability for my workflow.
>
> Where does this constraint come from?

    With separate remotes, I'd need something like:

            for b in master maint next pu
            do
                    git checkout $b && git pull && make || break
            done

    And I also would need to have per-branch configuration to merge
    from ". remotes/origin/$b" without re-fetching while on a
    non-master branch $b, for the above to work.  I still need to
    remember to process "master" first, so all things considered,
    this is a regression in usability for my workflow.

Because I'll have to have the per-branch configuration that
would say something like this:

	[remote."gitster"]
		url = gitster.example.com:/home/junio/git.git/
        	fetch = heads/maint:remotes/gitster/maint
        	fetch = heads/master:remotes/gitster/master
        	fetch = heads/next:remotes/gitster/next
        	fetch = +heads/pu:remotes/gitster/pu

	[branch."master"]
        	remote = gitster
                merge = heads/master
	[branch."maint"]
        	remote = .
                merge = remotes/gitster/maint
	[branch."next"]
        	remote = .
                merge = remotes/gitster/next
	...

Side note: the above would not actually work because I am
missing an earlier patch by Santi to special case 'dot' as the
value of "branch.$name.remote", but I think you get the idea.

This requires that by the time we update maint, next and pu
branches with what is in the upstream, their corresponding
remotes/gitster/* branches are already up-to-date and do not
have to be re-fetched, and processing master first is what
guarantees it.

I do not mind treating "master" specially at all; my otherwise
idle repositories with working tree (read: ones on secondary
machines I use primarily to build git binary for that machine or
that platform, not to develop on) always have "master" checked
out; I start working in them while "master" is checked out, and
I'll be on "master" before I leave that machine.

If I keep using the traditional layout, where master is fetched
to origin and next, maint and pu are used to track the remote, I
do not have to do any of the above remote/branch configuration
in the .git/config file, and after one "git pull" while on
"master", I'd have all four branches up to date, ready to be
checked out and compiled.

But I suspect this "following multiple branches at the same
time, switch between them only to compile, test and install but
never develop on them" workflow is rather specific to top-level
maintainer's workflow and that is why I said defaulting to
separate-remote would be an inconvenience to a minority.

Re: git bug? + question

[Andy Parkins]

On Friday 2006 November 03 07:48, Karl Hasselström wrote:

> Hmm, this is interesting. 99% of the time, I use "git fetch", followed
> by "git pull . remotes/origin/foo" (often having run gitk in between

I often do this too; and have found that the "remotes" is not needed provided 
there is no overlap with your local branch names.  The above can be replaced 
with

  git pull . origin/foo

This relies on there being no "origin/foo" local branch.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE

Re: git bug? + question

[Andy Parkins]

On Friday 2006 November 03 08:51, Junio C Hamano wrote:

> time, switch between them only to compile, test and install but
> never develop on them" workflow is rather specific to top-level
> maintainer's workflow and that is why I said defaulting to
> separate-remote would be an inconvenience to a minority.

This is only a question of the default; why couldn't you (when it exists) use?

  git clone --dont-use-separate-remote URL

To get exactly what you always had if that's what you want?


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE

Re: git bug? + question

[Sean]

On Fri, 3 Nov 2006 09:12:32 +0100
Karl Hasselström <kha@treskal.com> wrote:

> I would rather see the default pull source of a branch being
> determined by which branch it was branched off of. But this should
> mean the same thing in this case. We'd just have to have the heuristic
> that default pulls from a remotes/*/* branch causes a fetch, while a
> default pull from a local branch does not.

Well, when you create a branch a branch.<branch>.merge entry could be
automatically made so that a merge from the proper place happens.
But in the absence of any config merge entries, it would be nice to
default to the same branch name from the remote namespace.  This
removes the need to create merge entries for the initial clone.
Of course, currently you have to create branch.<branch>.merge
entries by hand.

> > On a peripherally related topic, someone on the xorg list was
> > complaining that after the initial clone, there is no easy way to
> > track branches that get added/deleted from the remote repo. It would
> > be nice if pull had an option to automatically add and remove remote
> > branches from the remotes/<remote>/xxx namespace.
> 
> That would definitely be useful. But I want it in fetch, not pull. :-)
> Well, I suppose it could be in both.

Yes.
 
> Hmm, I think my dislike of remote pulls can be summed up as: I find it
> convoluted to have a command that will fetch multiple remote branches,
> then merge just one of them into my current branch. (I have no problem
> with pull when the branches to pull are specified explicitly, since in
> that case they are all merged.) With explicitly specified default pull
> sources it would get better, since then I would know that the correct
> branch would be merged, but I still don't quite like it.

Yeah.. Although fetching multiple remotes makes more sense as an
optimization, especially when using a separate remotes namespace.
Perhaps the real confusion is created because the only porcelain 
level merge command current in Git is "git pull .".  A separate
name might make things easier to grasp.

Sean

Re: git bug? + question

[Karl Hasselström]

On 2006-11-03 00:51:32 -0800, Junio C Hamano wrote:

> Karl Hasselström <kha@treskal.com> writes:
>
> > On 2006-11-02 18:40:30 -0800, Junio C Hamano wrote:
> >
> > > I still need to remember to process "master" first, so all
> > > things considered, this is a regression in usability for my
> > > workflow.
> >
> > Where does this constraint come from?
>
> Because I'll have to have the per-branch configuration that would
> say something like this:
>
>       [remote."gitster"]
>               url = gitster.example.com:/home/junio/git.git/
>               fetch = heads/maint:remotes/gitster/maint
>               fetch = heads/master:remotes/gitster/master
>               fetch = heads/next:remotes/gitster/next
>               fetch = +heads/pu:remotes/gitster/pu
>
>       [branch."master"]
>               remote = gitster
>               merge = heads/master
>       [branch."maint"]
>               remote = .
>               merge = remotes/gitster/maint
>       [branch."next"]
>               remote = .
>               merge = remotes/gitster/next
>       ...
>
> This requires that by the time we update maint, next and pu branches
> with what is in the upstream, their corresponding remotes/gitster/*
> branches are already up-to-date and do not have to be re-fetched,
> and processing master first is what guarantees it.

Ahh, here is where our workflows differ: I would want to have "remote
= ." for all the branches, and use "git fetch" to update the remotes.
(I guess this is only natural; my workflow requires less state in the
head of the user, and so is easier for beginners, while yours is
slightly more efficient in terms of number of commands that have to be
given.)

Hmm. How about changing the meaning of "remote" slightly? Like this:

      [remote."gitster"]
              url = gitster.example.com:/home/junio/git.git/
              fetch = heads/master:remotes/gitster/master
              fetch = heads/next:remotes/gitster/next
      [branch."master"]
              remote = gitster
              merge = remotes/gitster/master
      [branch."next"]
              remote = gitster
              merge = remotes/gitster/next

This would mean: When the user says "git pull" in master, use the
remote gitster to fetch updates to remotes/gitster/master, then merge
remotes/gitster/master into master.

With this scheme, "git pull" would never fetch any other branches than
those about to be merged; to fetch more in one go, use "git fetch".

I realize this would break existing configs quite badly, so don't take
it too seriously.

-- 
Karl Hasselström, kha@treskal.com

Re: git bug? + question

[Karl Hasselström]

On 2006-11-03 04:25:40 -0500, Sean wrote:

> Yeah.. Although fetching multiple remotes makes more sense as an
> optimization, especially when using a separate remotes namespace.

That's what "git fetch" is for. :-)

> Perhaps the real confusion is created because the only porcelain
> level merge command current in Git is "git pull .". A separate name
> might make things easier to grasp.

Indeed. Having pull = fetch + merge and not having a porcelain merge
command is not good, usability-wise. As is, one _has_ to learn the
weird ways of pull even if one is only interested in using separate
commands to fetch and merge.

-- 
Karl Hasselström, kha@treskal.com

Re: git bug? + question

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

hoi :)

On Fri, Nov 03, 2006 at 12:51:32AM -0800, Junio C Hamano wrote:
>     With separate remotes, I'd need something like:
> 
>             for b in master maint next pu
>             do
>                     git checkout $b && git pull && make || break
>             done
> 
>     And I also would need to have per-branch configuration to merge
>     from ". remotes/origin/$b" without re-fetching while on a
>     non-master branch $b, for the above to work.  I still need to
>     remember to process "master" first, so all things considered,
>     this is a regression in usability for my workflow.

you could also run git-fetch first and then always default to
the local repository.  But that would of course make pull just
a shortcut for merge, without any fetch.

Would it be so bad for you to call fetch three times?
I think the most intuitive thing for pull would be to fetch into
remotes/<remotename>/* and then to merge
remotes/<remotename>/<currentbranch>.

-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: git bug? + question

[Santi Béjar]

On 11/3/06, Martin Waitz <tali@admingilde.org> wrote:
> I think the most intuitive thing for pull would be to fetch into
> remotes/<remotename>/* and then to merge
> remotes/<remotename>/<currentbranch>.

Yes as the default branch to merge instead the first line, the problem
is that it changes the current behaviour. But I think the most
intuitive thing would be to record the branch it is based off at the
branch creation time. Something similar to my patch:

Oct 17 [PATCHv2] git-branch: Set branch properties
Message-ID: <87y7rf80es.fsf@gmail.com>

Note that it is for the "old" git-branch.sh.

Re: git bug? + question

[Linus Torvalds]

On Fri, 3 Nov 2006, Junio C Hamano wrote:
> 
> 	[remote."gitster"]

Btw, why the '.'? It doesn't even work with a dot, you have to have a 
space, which is also a lot more readable..

Also, may I suggest that we just extend the format with a robust default 
value thing?

It should be reasonably easy to have just the rule:

 - add a new "remote.<remote>.branch" thing that lists multiple simple 
   branches separated by whitespace.

 - a "simple branch" is just a "implicit refspec" for the relationship
   "heads/<name>:remotes/<remote>/<name>"

And then you should be able to write all of your cumbersome config options 
as a simple

	[remote "gitster"]
		url = gitster.example.com:/home/junio/git.git/
		branch = maint master next +pu

and you're all done. It would imply everything you said.

This would basically require that "git-parse-remote" be re-written as a 
native builtin, because quite frankly, it would be too damn painful any 
other way, but it really shouldn't be that nasty. In fact, I think we 
should have done that long ago, because the shell-code is just horrid for 
things like this.

For example, for builtin-push (which is currently the only thing that 
parses "remote" entries in C), you'd just need to do something like the 
appended..  It would generate the full refspecs from the "branch" config 
automatically.

		Linus

---
diff --git a/builtin-push.c b/builtin-push.c
index d23974e..805ffa8 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -123,15 +123,33 @@ static int get_remote_config(const char*
 {
 	if (!strncmp(key, "remote.", 7) &&
 	    !strncmp(key + 7, config_repo, config_repo_len)) {
-		if (!strcmp(key + 7 + config_repo_len, ".url")) {
+	    	const char *subkey = key + 7 + config_repo_len;
+		if (!strcmp(subkey, ".url")) {
 			if (config_current_uri < MAX_URI)
 				config_uri[config_current_uri++] = xstrdup(value);
 			else
 				error("more than %d URL's specified, ignoring the rest", MAX_URI);
 		}
-		else if (config_get_refspecs &&
-			 !strcmp(key + 7 + config_repo_len, ".push"))
-			add_refspec(xstrdup(value));
+		else if (config_get_refspecs) {
+			if (!strcmp(subkey, ".push"))
+				add_refspec(xstrdup(value));
+			else if (!strcmp(subkey, ".branch")) {
+				while (isspace(*value))
+					value++;
+				while (*value) {
+					const char *end = value;
+					while (!isspace(*end))
+						end++;
+					add_refspec(xsprintf("heads/%.*s:remotes/%.*s/%.*s",
+						end-value, value,
+						config_repo_len, config_repo,
+						end-value, value));
+					while (isspace(*end))
+						end++;
+					value = end;
+				}
+			}
+		}
 	}
 	return 0;

Re: git bug? + question

[Jakub Narebski]

Josef Weidendorfer wrote:

> Other option: Introduce "fetchonly" line which ignores the original
> fetch lines in the remote section.

I like this.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git bug? + question

[Josef Weidendorfer]

On Friday 03 November 2006 10:46, Karl Hasselström wrote:
> Hmm. How about changing the meaning of "remote" slightly? Like this:

That's not good, as it changes existing config meaning.
But why not support fetch lines in [branch.*] sections?

Ie. instead of

>       [remote."gitster"]
>               url = gitster.example.com:/home/junio/git.git/
>               fetch = heads/master:remotes/gitster/master
>               fetch = heads/next:remotes/gitster/next
>       [branch."master"]
>               remote = gitster
>               merge = remotes/gitster/master
>       [branch."next"]
>               remote = gitster
>               merge = remotes/gitster/next

make your config look like

       [remote."gitster"]
               url = gitster.example.com:/home/junio/git.git/
       [branch."master"]
               remote = gitster
               fetch = heads/master:remotes/gitster/master
               merge = remotes/gitster/master
       [branch."next"]
               remote = gitster
               fetch = heads/next:remotes/gitster/next
               merge = remotes/gitster/next

A fetch line in [branch.*] means: Also fetch this refspec in
addition to the refspecs specified in the remote section.
Problem being that "git fetch gitster" does nothing anymore :-(

Other option: Introduce "fetchonly" line which ignores the original
fetch lines in the remote section.

       [remote."gitster"]
               url = gitster.example.com:/home/junio/git.git/
               fetch = heads/master:remotes/gitster/master
               fetch = heads/next:remotes/gitster/next
       [branch."master"]
               remote = gitster
               fetchonly = heads/master:remotes/gitster/master
               merge = remotes/gitster/master

Re: git bug? + question

[Josef Weidendorfer]

On Friday 03 November 2006 18:13, Jakub Narebski wrote:
> Josef Weidendorfer wrote:
> 
> > Other option: Introduce "fetchonly" line which ignores the original
> > fetch lines in the remote section.
> 
> I like this.

That's implementing it:

=================================
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -156,6 +156,18 @@ canon_refs_list_for_fetch () {

 # Returns list of src: (no store), or src:dst (store)
 get_remote_default_refs_for_fetch () {
+       # if there are any branch.${curr_branch}.fetchonly entries,
+       # only use them as default
+       curr_branch=$(git-symbolic-ref HEAD | \
+               sed -e 's|^refs/heads/||')
+       fetchonly_branches=$(git-repo-config \
+               --get-all "branch.${curr_branch}.fetchonly")
+       if test ! -z $fetchonly_branches
+       then
+               canon_refs_list_for_fetch -d "$1" $fetchonly_branches
+               return
+       fi
+
        data_source=$(get_data_source "$1")
        case "$data_source" in
        '' | config-partial | branches-partial)
=================================

The problem with this small patch is that with

       [remote."gitster"]
               url = gitster.example.com:/home/junio/git.git/
               fetch = heads/master:remotes/gitster/master
               fetch = heads/next:remotes/gitster/next
       [branch."master"]
               remote = gitster
               fetchonly = heads/master:remotes/gitster/master
               merge = remotes/gitster/master

and current branch "master", even "git fetch gitster" does not
fetch both branches, which is expected IMHO. We would need to
pass the info that an explicit repository was given down to
get_remote_default_refs_for_fetch().

Re: git bug? + question

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

> On Friday 2006 November 03 08:51, Junio C Hamano wrote:
>
>> time, switch between them only to compile, test and install but
>> never develop on them" workflow is rather specific to top-level
>> maintainer's workflow and that is why I said defaulting to
>> separate-remote would be an inconvenience to a minority.
>
> This is only a question of the default; why couldn't you (when
> it exists) use?
>
>   git clone --dont-use-separate-remote URL

Because I do not need it ;-).  If we switch the default to
separate-remote, I'd just let clone to lay it out that way and
then update the ref layout myself to suit my needs.  So it is
really just the matter of deciding which is more appropriate
default for the majority.

Re: git bug? + question

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> On Fri, 3 Nov 2006, Junio C Hamano wrote:
>> 
>> 	[remote."gitster"]
>
> Btw, why the '.'? It doesn't even work with a dot, you have to have a 
> space, which is also a lot more readable..

Untested example ;-).

I do not have to use any of these in real life because I work in
repositories laid out without separate remotes.

> This would basically require that "git-parse-remote" be re-written as a 
> native builtin, because quite frankly, it would be too damn painful any 
> other way, but it really shouldn't be that nasty. In fact, I think we 
> should have done that long ago, because the shell-code is just horrid for 
> things like this.

I agree.

I am rediscovering git-cvsimport and git-cvsexportcommit right
now, and one thing I wished was git-cvsimport to have worked as
if it is a git-fetch of an exotic flavor.  Integrating it into
git-fetch so that "URL: cvs://repo.si.to/ry" in .git/remotes
would do a sensible thing and make git-cvsimport honor
"Pull: HEAD:remotes/cvs/master" would both need some work in
parse-remote, and doing anything more complicated than the
current parse-remote in shell is quite painful.

Re: git bug? + question

[Shawn Pearce]

Sean <seanlkml@sympatico.ca> wrote:
> On Fri, 3 Nov 2006 09:12:32 +0100
> Karl Hasselström <kha@treskal.com> wrote:
> 
> > I would rather see the default pull source of a branch being
> > determined by which branch it was branched off of. But this should
> > mean the same thing in this case. We'd just have to have the heuristic
> > that default pulls from a remotes/*/* branch causes a fetch, while a
> > default pull from a local branch does not.
> 
> Well, when you create a branch a branch.<branch>.merge entry could be
> automatically made so that a merge from the proper place happens.

Yes, definately.  For most people I know that use Git the branch
they branched off of is the one they need to pull in on a regular
basis to keep their topic branch current.  They rarely pull other
branches in.

> But in the absence of any config merge entries, it would be nice to
> default to the same branch name from the remote namespace.  This
> removes the need to create merge entries for the initial clone.
> Of course, currently you have to create branch.<branch>.merge
> entries by hand.

Nack.  I'd rather see the entries added/removed from .git/config when
the branch is created/deleted, just like the ref and the reflog are
created/deleted.  It makes behavior more consistent for the user
and it is mostly self documenting...

	"why is branch FOO pulling FOO by default?  ahhh, its in
	.git/config after git branch FOO FOO."

Same goes for git-clone.  The branch.master.merge=origin/master
entry should be in .git/config file after the clone is complete.

-- 

Re: git bug? + question

[Shawn Pearce]

Sean <seanlkml@sympatico.ca> wrote:
> On Thu, 02 Nov 2006 18:40:30 -0800
> Junio C Hamano <junkio@cox.net> wrote:
> 
> > which is efficient (guaranteed to do only one fetch from remote)
> > and convenient.  Also I have Push: mapping set up on my
> > main machine to do master:origin, next:next, maint:maint, and
> > +pu:pu so that I can replace the first "git pull" on the
> > secondary machine with "git push secondary" on my main machine.
> 
> One thing that would make separate-remotes nicer to work with
> is to have an automatic mapping between any local branch and
> one of the same name in remotes.
> 
> So for instance, if you have a local branch named pu checked
> out and you pull from origin, remotes/origin/pu would be merged
> after the fetch unless a manual mapping was defined in the
> remotes or config file.
> 
> Maybe even going as far as automatically creating a local branch
> for each remote branch on clone is worth considering.

Nack.

I work with a workflow where our central repository has 2 important
branches (vmtip and vmvt), and a bunch of transient developer
topic branches (e.g. sp/foo).  We only have a master branch in this
repository so that git-clone will clone it without choking during
the clone.  Users tend to do immediately after a clone:

	git branch -D master
	git branch -D origin
	git branch -D ... other topic branches not interested in ...
	edit .git/remotes/origin ... delete topic branches ...

Why?  Because vmtip and vmdvt have meaning to these users, much as
pu has meaning.  Really vmtip is roughly equal to master in Git and
vmdvt is roughly equal to maint but not having the mental mapping of
"vmtip == master" just makes things easier.

Creating a local branch for every remote branch would just make
things worse in the above workflow; not to mention it makes it
confusing for other users who might be fetching into a repository
and expecting their local "next" to to update automatically after
a fetch...
 
> On a peripherally related topic, someone on the xorg list was
> complaining that after the initial clone, there is no easy way
> to track branches that get added/deleted from the remote repo.
> It would be nice if pull had an option to automatically add
> and remove remote branches from the remotes/<remote>/xxx
> namespace.

Or at least deleting/skipping over a branch you listed to fetch
from the remote that no longer happnes to be on the remote.  This is
causing some pain due to the topic branches noted above.

-- 

Re: git bug? + question

[Sean]

On Fri, 3 Nov 2006 15:36:10 -0500
Shawn Pearce <spearce@spearce.org> wrote:

> > Maybe even going as far as automatically creating a local branch
> > for each remote branch on clone is worth considering.
> 
> Nack.
> 
> I work with a workflow where our central repository has 2 important
> branches (vmtip and vmvt), and a bunch of transient developer
> topic branches (e.g. sp/foo).  We only have a master branch in this
> repository so that git-clone will clone it without choking during
> the clone.  Users tend to do immediately after a clone:
> 
> 	git branch -D master
> 	git branch -D origin
> 	git branch -D ... other topic branches not interested in ...
> 	edit .git/remotes/origin ... delete topic branches ...

I think your Nack was a little rash here.  The feature would be quite
useful to work flows other than yours.  It sounds like what _you_ want
is a feature to select branches when cloning rather than the current
default of cloning all.  That would stop your developers having to 
delete branches and editing .git/remotes/origin immediately
after cloning.

Re: git bug? + question

[Sean]

On Fri, 3 Nov 2006 15:29:45 -0500
Shawn Pearce <spearce@spearce.org> wrote:

> Nack.  I'd rather see the entries added/removed from .git/config when
> the branch is created/deleted, just like the ref and the reflog are
> created/deleted.  It makes behavior more consistent for the user
> and it is mostly self documenting...
> 
> 	"why is branch FOO pulling FOO by default?  ahhh, its in
> 	.git/config after git branch FOO FOO."
> 
> Same goes for git-clone.  The branch.master.merge=origin/master
> entry should be in .git/config file after the clone is complete.

Well that's certainly an alternative implementation that achieves 
the same thing.  The essential point is that most of the time the
Git user should not have to manually create the merge entries
in the config file.  Git should be smart enough to get it right
most of the time automatically.

Re: git bug? + question

[Jeff King]

On Fri, Nov 03, 2006 at 03:29:45PM -0500, Shawn Pearce wrote:

> Nack.  I'd rather see the entries added/removed from .git/config when
> the branch is created/deleted, just like the ref and the reflog are
> created/deleted.  It makes behavior more consistent for the user
> and it is mostly self documenting...

If we go this route, please consider updating .git/auto-branch-config or
similar, and adding the functionality to include that file into
.git/config.

I think the concept of automagically munging a user-editable config file
is problematic, especially when users might manage those files with
version control or other systems.

Re: git bug? + question

[Shawn Pearce]

Sean <seanlkml@sympatico.ca> wrote:
> On Fri, 3 Nov 2006 15:36:10 -0500
> Shawn Pearce <spearce@spearce.org> wrote:
> 
> > > Maybe even going as far as automatically creating a local branch
> > > for each remote branch on clone is worth considering.
> > 
> > Nack.
> > 
> > I work with a workflow where our central repository has 2 important
> > branches (vmtip and vmvt), and a bunch of transient developer
> > topic branches (e.g. sp/foo).  We only have a master branch in this
> > repository so that git-clone will clone it without choking during
> > the clone.  Users tend to do immediately after a clone:
> > 
> > 	git branch -D master
> > 	git branch -D origin
> > 	git branch -D ... other topic branches not interested in ...
> > 	edit .git/remotes/origin ... delete topic branches ...
> 
> I think your Nack was a little rash here.  The feature would be quite
> useful to work flows other than yours.  It sounds like what _you_ want
> is a feature to select branches when cloning rather than the current
> default of cloning all.  That would stop your developers having to 
> delete branches and editing .git/remotes/origin immediately
> after cloning.

After reading your reply you are probably correct.  I can see there
may be workflows that want every remote branch also created as a
local branch.

I could certainly live with a command line option to clone, e.g.:

	git clone --only vmdvt,vmtip user@host:/path...

So yes, my 'Nack' may have been a little too rash.

-- 

Re: git bug? + question

[Shawn Pearce]

Sean <seanlkml@sympatico.ca> wrote:
> On Fri, 3 Nov 2006 15:29:45 -0500
> Shawn Pearce <spearce@spearce.org> wrote:
> 
> > Nack.  I'd rather see the entries added/removed from .git/config when
> > the branch is created/deleted, just like the ref and the reflog are
> > created/deleted.  It makes behavior more consistent for the user
> > and it is mostly self documenting...
> > 
> > 	"why is branch FOO pulling FOO by default?  ahhh, its in
> > 	.git/config after git branch FOO FOO."
> > 
> > Same goes for git-clone.  The branch.master.merge=origin/master
> > entry should be in .git/config file after the clone is complete.
> 
> Well that's certainly an alternative implementation that achieves 
> the same thing.  The essential point is that most of the time the
> Git user should not have to manually create the merge entries
> in the config file.  Git should be smart enough to get it right
> most of the time automatically.

Agreed completely.  At least though with repo-config we have a
command line tool which users/scripts alike can use to read/edit
the configuration of a "remote"; .git/remotes/ has no such tool.

-- 

Re: git bug? + question

[Shawn Pearce]

Jeff King <peff@peff.net> wrote:
> On Fri, Nov 03, 2006 at 03:29:45PM -0500, Shawn Pearce wrote:
> 
> > Nack.  I'd rather see the entries added/removed from .git/config when
> > the branch is created/deleted, just like the ref and the reflog are
> > created/deleted.  It makes behavior more consistent for the user
> > and it is mostly self documenting...
> 
> If we go this route, please consider updating .git/auto-branch-config or
> similar, and adding the functionality to include that file into
> .git/config.
> 
> I think the concept of automagically munging a user-editable config file
> is problematic, especially when users might manage those files with
> version control or other systems.

Most users that I know use repo-config to munge their .git/config
rather than editing it by hand.  Though with more data stored in
it for branches and remotes that is probably going to change.

If we go this route I wonder if want to say create a config file
per branch and then use a wildcard include like Apache's httpd.conf
wildcard include, e.g.:

	.git/config:
		include branch_configs/**/*.config

	.git/branch_configs/refs/heads/master.config:
		[branch "master"]
			...

As then git-branch is only manipulating one file per branch.

-- 

Re: git bug? + question

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

> On Friday 03 November 2006 10:46, Karl Hasselström wrote:
>> Hmm. How about changing the meaning of "remote" slightly? Like this:
>
> That's not good, as it changes existing config meaning.
>...
> Other option: Introduce "fetchonly" line which ignores the original
> fetch lines in the remote section.
>
>        [remote."gitster"]
>                url = gitster.example.com:/home/junio/git.git/
>                fetch = heads/master:remotes/gitster/master
>                fetch = heads/next:remotes/gitster/next
>        [branch."master"]
>                remote = gitster
>                fetchonly = heads/master:remotes/gitster/master
>                merge = remotes/gitster/master

That is a regression in that now I need to fetch twice (in the
above example, in reality four).

Re: git bug? + question

[Junio C Hamano]

Sean <seanlkml@sympatico.ca> writes:

> I think your Nack was a little rash here.  The feature would be quite
> useful to work flows other than yours.  It sounds like what _you_ want
> is a feature to select branches when cloning rather than the current
> default of cloning all.  That would stop your developers having to 
> delete branches and editing .git/remotes/origin immediately
> after cloning.

I think this conversation demonstrates that this previous
statement of yours was also rather rash:

  The essential point is that most of the time the Git user
  should not have to manually create the merge entries in the
  config file.  Git should be smart enough to get it right most
  of the time automatically.

There is no "get it right most of the time" that would apply to
every workflow.  We should just admit that no default layout and
configuration would suit everybody's needs.  What we should do
is to try to capture a handful useful patterns and make it easy
for people to apply those canned patterns.

For example, that is what we did for "git clone".  We identified
two common layouts, traditional and separate-remote, and we
support both.  The reason we might want to favor separate-remote
over traditional should be based on the expected workflow and
expertise level of the majority of users.  If a census turns out
that the more experienced people tend to prefer traditional
layout, then changing the default to separate-remote would be
easier even if people with workflow separate-remote is more
appropriate is not the absolute majority, because the layout can
be easily changed by more experienced folks.

I think the "what should the default merge source be" topic is
very similar.  There is no single _right_ way and to some extent
what the vanilla default is does not really matter.

Re: git bug? + question

[Sean]

On Sat, 04 Nov 2006 04:03:39 -0800
Junio C Hamano <junkio@cox.net> wrote:

> There is no "get it right most of the time" that would apply to
> every workflow.  We should just admit that no default layout and
> configuration would suit everybody's needs.  What we should do
> is to try to capture a handful useful patterns and make it easy
> for people to apply those canned patterns.

Consider it admitted ;o)  But there is no need to have just a single
configuration that suits everybody.  For instance, nobody is saying
to do away with the current default in favor of use-separate-remotes.
That is why someone saying "Nak" to a feature where all branches
are checked out locally on clone is "rash".  Because it _is_ valuable
to some workflows.  There is no reason Git could not support it.  If
it gets in the way of some workflows, then we just make it a
configuration option.  However, I don't feel strongly about this
particular option, if you notice in my email I merely suggested it
for discussion.

But by the same token, Git should _better_ support Shawn's example
workflow where currently Git makes him delete a bunch of branches
and edit the remotes/origin file every time after cloning.  It would
be rash of me to send out a Nak for such an improvement just because
I don't need that feature.

All that remains is coming to some consensus on which set of options
should be enabled for new Git users.  Once someone is up to speed, they
can enable whichever options support their workflow.  But once they've
enabled those options, Git should do it's best to support that workflow
without a lot of manual intervention most of the time.  That's what
the options I was suggesting would do for some workflows.

Re: git bug? + question

[Josef Weidendorfer]

On Saturday 04 November 2006 13:03, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> 
> > On Friday 03 November 2006 10:46, Karl Hasselström wrote:
> >> Hmm. How about changing the meaning of "remote" slightly? Like this:
> >
> > That's not good, as it changes existing config meaning.
> >...
> > Other option: Introduce "fetchonly" line which ignores the original
> > fetch lines in the remote section.
> >
> >        [remote."gitster"]
> >                url = gitster.example.com:/home/junio/git.git/
> >                fetch = heads/master:remotes/gitster/master
> >                fetch = heads/next:remotes/gitster/next
> >        [branch."master"]
> >                remote = gitster
> >                fetchonly = heads/master:remotes/gitster/master
> >                merge = remotes/gitster/master
> 
> That is a regression in that now I need to fetch twice (in the
> above example, in reality four).

Hmm. You do not need to use it.
However, there are use cases for this.

For example, I am mostly interested in what's new on the
next and master branch in the git repository. There is no need for me
to always fetch pu or maint.

So I can use (I am behind a firewall):

[remote "origin"]
        url = http://www.kernel.org/pub/scm/git/git.git
        fetch = master:origin
        fetch = maint:maint
        fetch = next:next
        fetch = todo:todo
        fetch = +pu:pu

[branch "master"]
        remote = origin
        fetchonly = master:origin
	fetchonly = next:next
        merge = origin

and get master and next with a "git fetch" when on master, and
"git fetch origin" would fetch all branches.

Re: git bug? + question

[Josef Weidendorfer]

On Saturday 04 November 2006 06:03, Shawn Pearce wrote:
> After reading your reply you are probably correct.  I can see there
> may be workflows that want every remote branch also created as a
> local branch.
> 
> I could certainly live with a command line option to clone, e.g.:
> 
> 	git clone --only vmdvt,vmtip user@host:/path...

Still missing here: What branch should be checked out after
cloning?

Perhaps it is better to extend git-checkout to allow to do the
correct thing when the user specifies a read-only branch from
refs/remotes. E.g. with refs/remotes/origin/vmdvt,

 	git checkout origin/vmdvt

should create a new local branch refs/heads/vmdvt which forks
from remotes/origin/vmdvt (and abort with
error if refs/heads/vmdvt already exists without being the local
development branch for remotes/origin/vmdvt), add to .git/config

[branch "vmdvt"]
	remote = origin
	merge = remotes/origin/vmdvt

and switch to this new created branch.

Given this addition to git-checkout, the implicit default
action after cloning with --use-separate-remote should be

	git checkout origin/master

where "master" can be changed on the git-clone command line
to another branch, e.g. "--checkout vmdvt".

IMHO, this addition to git-checkout would make it a lot
easier to work with --use-separate-remote, as there,
every branch other the master is read-only.

And if you have two remote repositories with a master branch
each, and you want to develop locally on both, this could
be accomplished with

	git checkout -b othermaster remotes/otherrepo/master

Re: git bug? + question

[Shawn Pearce]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Saturday 04 November 2006 06:03, Shawn Pearce wrote:
> > After reading your reply you are probably correct.  I can see there
> > may be workflows that want every remote branch also created as a
> > local branch.
> > 
> > I could certainly live with a command line option to clone, e.g.:
> > 
> > 	git clone --only vmdvt,vmtip user@host:/path...
> 
> Still missing here: What branch should be checked out after
> cloning?

Ah.

I probably should have also stated that my users should be doing
-n as well with git clone, then using git checkout -b to create
a new branch from one of the refs they did clone.  (Reason is we
strictly follow a topic branch model of development, with even the
developer's local branches beginning with their initials.)

But you have a good point.  Cloning with say --only as I show above
might be confusing as its not defined what branch to checkout after
the clone.
 
> Perhaps it is better to extend git-checkout to allow to do the
> correct thing when the user specifies a read-only branch from
> refs/remotes. E.g. with refs/remotes/origin/vmdvt,
> 
>  	git checkout origin/vmdvt
> 
> should create a new local branch refs/heads/vmdvt which forks
> from remotes/origin/vmdvt (and abort with
> error if refs/heads/vmdvt already exists without being the local
> development branch for remotes/origin/vmdvt)

Yes, that would work for our workflow.  I won't try to speak about
anyone else's.

I'd also say that if the local branch (refs/heads/vmdvt) exists and
if `git pull . origin/vmdvt` is going to be a fast-forward that the
fast-forward should happen during the checkout.  That way after the
checkout is complete you really do have what is in origin/vmdvt,
but are sitting on a local branch.

-- 

Re: git bug? + question

[Shawn Pearce]

Sean <seanlkml@sympatico.ca> wrote:
> All that remains is coming to some consensus on which set of options
> should be enabled for new Git users.  Once someone is up to speed, they
> can enable whichever options support their workflow.  But once they've
> enabled those options, Git should do it's best to support that workflow
> without a lot of manual intervention most of the time.  That's what
> the options I was suggesting would do for some workflows.

Agreed.

Since I already have to spell out the entire clone command line
(including URL) for my users asking them to also include a few
options (such as the hypothetical "--only vmdvt,vmtip -n") is not
a problem.  As in my workflow could be in the more "advanced user"
category.  :-)

-- 

Re: git bug? + question

[Andy Whitcroft]

Josef Weidendorfer wrote:
> On Saturday 04 November 2006 06:03, Shawn Pearce wrote:
>> After reading your reply you are probably correct.  I can see there
>> may be workflows that want every remote branch also created as a
>> local branch.
>>
>> I could certainly live with a command line option to clone, e.g.:
>>
>> 	git clone --only vmdvt,vmtip user@host:/path...
> 
> Still missing here: What branch should be checked out after
> cloning?

Does any need to be checked out?  Or perhap I should put it another way,
when we make a virgin repository we default to master checked out but
its not joined to the DAG.  Perhaps we can just init-db and fetch the
specified branches and we are done.  The user will then checkout things
as they need and if they do not need master they can lose it.

> 
> Perhaps it is better to extend git-checkout to allow to do the
> correct thing when the user specifies a read-only branch from
> refs/remotes. E.g. with refs/remotes/origin/vmdvt,
> 
>  	git checkout origin/vmdvt
> 
> should create a new local branch refs/heads/vmdvt which forks
> from remotes/origin/vmdvt (and abort with
> error if refs/heads/vmdvt already exists without being the local
> development branch for remotes/origin/vmdvt), add to .git/config
> 
> [branch "vmdvt"]
> 	remote = origin
> 	merge = remotes/origin/vmdvt
> 
> and switch to this new created branch.
> 
> Given this addition to git-checkout, the implicit default
> action after cloning with --use-separate-remote should be
> 
> 	git checkout origin/master
> 
> where "master" can be changed on the git-clone command line
> to another branch, e.g. "--checkout vmdvt".
> 
> IMHO, this addition to git-checkout would make it a lot
> easier to work with --use-separate-remote, as there,
> every branch other the master is read-only.
> 
> And if you have two remote repositories with a master branch
> each, and you want to develop locally on both, this could
> be accomplished with
> 
> 	git checkout -b othermaster remotes/otherrepo/master

-apw

Re: git bug? + question

[Josef Weidendorfer]

On Monday 06 November 2006 10:53, Andy Whitcroft wrote:
> Josef Weidendorfer wrote:
> > On Saturday 04 November 2006 06:03, Shawn Pearce wrote:
> >> After reading your reply you are probably correct.  I can see there
> >> may be workflows that want every remote branch also created as a
> >> local branch.
> >>
> >> I could certainly live with a command line option to clone, e.g.:
> >>
> >> 	git clone --only vmdvt,vmtip user@host:/path...
> > 
> > Still missing here: What branch should be checked out after
> > cloning?
> 
> Does any need to be checked out?

We should not change existing behavior. IMHO, checking out a branch is
mostly the right thing to do. Of course, you often want to specify which one.
The current requirement for a master branch in the origin repository
is really bad, as it obviously requires ugly workarounds in some cases
(and totally confuse newbies in such use cases).

> Or perhap I should put it another way, 
> when we make a virgin repository we default to master checked out but
> its not joined to the DAG.

I do not understand this. By creating a local branch, the commit DAG
is never changed.

Re: git bug? + question

[Josef Weidendorfer]

On Saturday 04 November 2006 20:05, Shawn Pearce wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> >
> >  	git checkout origin/vmdvt
> > 
> > should create a new local branch refs/heads/vmdvt which forks
> > from remotes/origin/vmdvt (and abort with
> > error if refs/heads/vmdvt already exists without being the local
> > development branch for remotes/origin/vmdvt)
> 
> Yes, that would work for our workflow.  I won't try to speak about
> anyone else's.
> 
> I'd also say that if the local branch (refs/heads/vmdvt) exists and
> if `git pull . origin/vmdvt` is going to be a fast-forward that the
> fast-forward should happen during the checkout.  That way after the
> checkout is complete you really do have what is in origin/vmdvt,
> but are sitting on a local branch.

Hmmm... But you are changing the tip of a local development branch,
which is probably not always the thing we want.

Thinking about it, we should always error out if a proposed branch
name for a read-only branch already exists.

Josef

Re: git bug? + question

[Andy Whitcroft]

Josef Weidendorfer wrote:
> On Monday 06 November 2006 10:53, Andy Whitcroft wrote:
>> Josef Weidendorfer wrote:
>>> On Saturday 04 November 2006 06:03, Shawn Pearce wrote:
>>>> After reading your reply you are probably correct.  I can see there
>>>> may be workflows that want every remote branch also created as a
>>>> local branch.
>>>>
>>>> I could certainly live with a command line option to clone, e.g.:
>>>>
>>>> 	git clone --only vmdvt,vmtip user@host:/path...
>>> Still missing here: What branch should be checked out after
>>> cloning?
>> Does any need to be checked out?
> 
> We should not change existing behavior. IMHO, checking out a branch is
> mostly the right thing to do. Of course, you often want to specify which one.
> The current requirement for a master branch in the origin repository
> is really bad, as it obviously requires ugly workarounds in some cases
> (and totally confuse newbies in such use cases).

We are not changing existing behaviour, if we do not check anything out
only when specifying '--only'.
> 
>> Or perhap I should put it another way, 
>> when we make a virgin repository we default to master checked out but
>> its not joined to the DAG.
> 
> I do not understand this. By creating a local branch, the commit DAG
> is never changed.

In a virgin repository there is no DAG to speak of and master doesn't
really point anywhere until the first commit.  I was proposing that when
--only is specified, we just leave things as they are.  The master half
pointing into the zero element DAG we have in an entirely empty repo.
The new unconnected DAG or DAG's we have downloaded in the clone will be
attached to their respective branch names.