From: Paolo Bonzini <hidden> Date: 2016-06-15 22:42:57
As can be seen from my other messages, I'm experimenting a little with
git and trying to understand how its workflow compares with arch. Right
now, my procedure for branching off a remote archive is:
git checkout -b branchname remote/upstreambranch
git config --add branch.branchname.remote remote
git config --add branch.branchname.merge refs/heads/upstreambranch
Is there a reason why "git branch" and "git checkout -b" should not
automatically do the two "git-config --add"s when the source branch is
remote?
In case the source branch is not remote, would "origin" be a good choice
for the "branch.branchname.remote" variable?
Paolo
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:57
Hi,
On Wed, 28 Feb 2007, Paolo Bonzini wrote:
As can be seen from my other messages, I'm experimenting a little with
git and trying to understand how its workflow compares with arch.
Right now, my procedure for branching off a remote archive is:
git checkout -b branchname remote/upstreambranch
git config --add branch.branchname.remote remote
git config --add branch.branchname.merge refs/heads/upstreambranch
Is there a reason why "git branch" and "git checkout -b" should not
automatically do the two "git-config --add"s when the source branch is
remote?
I like it.
In case the source branch is not remote, would "origin" be a good choice
for the "branch.branchname.remote" variable?
In case source branch is not a remote, I would not want that DWIMery.
Ciao,
Dscho
From: Andy Parkins <hidden> Date: 2016-06-15 22:42:57
On Wednesday 2007 February 28 14:53, Paolo Bonzini wrote:
As can be seen from my other messages, I'm experimenting a little with
git and trying to understand how its workflow compares with arch. Right
now, my procedure for branching off a remote archive is:
git checkout -b branchname remote/upstreambranch
git config --add branch.branchname.remote remote
git config --add branch.branchname.merge refs/heads/upstreambranch
Is there a reason why "git branch" and "git checkout -b" should not
automatically do the two "git-config --add"s when the source branch is
remote?
I can see why that would be handy, but I often make short lived branches off a
remote; and I wouldn't want my config cluttered up with branch defintions.
In case the source branch is not remote, would "origin" be a good choice
for the "branch.branchname.remote" variable?
No. That would still reference a remote. As in:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = refs/heads/master:refs/remotes/origin/master
[branch "master"]
remote = origin
merge = refs/heads/master
The remote = origin tells git to use the [remote "origin"] section.
I think what you want is something that I would like too. If you specify "."
to a git-pull it means to use the local repository not a remote. It would be
great if one could have:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = refs/heads/master:refs/remotes/origin/master
[branch "master"]
remote = .
merge = refs/remotes/origin/master
That way a "git pull" on master wouldn't need to make a remote connection in
order to do a merge (which is the way I like it). However, I remember there
was a reason this wouldn't work, but I don't remember what it was :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
From: Paolo Bonzini <hidden> Date: 2016-06-15 22:42:57
quoted
git checkout -b branchname remote/upstreambranch
git config --add branch.branchname.remote remote
git config --add branch.branchname.merge refs/heads/upstreambranch
Is there a reason why "git branch" and "git checkout -b" should not
automatically do the two "git-config --add"s when the source branch is
remote?
I can see why that would be handy, but I often make short lived branches off a
remote; and I wouldn't want my config cluttered up with branch defintions.
So, is there a reason why the config not could be cleared out by branch -d?
(The "is there a reason" has the same meaning: it seems obvious to me,
but I surely miss a lot of usecases because of inexperience).
Paolo
On Wednesday 2007 February 28 14:53, Paolo Bonzini wrote:
quoted
As can be seen from my other messages, I'm experimenting a little with
git and trying to understand how its workflow compares with arch. Right
now, my procedure for branching off a remote archive is:
git checkout -b branchname remote/upstreambranch
git config --add branch.branchname.remote remote
git config --add branch.branchname.merge refs/heads/upstreambranch
Is there a reason why "git branch" and "git checkout -b" should not
automatically do the two "git-config --add"s when the source branch is
remote?
I can see why that would be handy, but I often make short lived branches off a
remote; and I wouldn't want my config cluttered up with branch defintions.
How about adding an option to tell checkout/branch that a tracking branch
is wanted (-t perhaps) - or perhaps a way to say that you don't want to
track the remote (depending on which is more popular)?
Certainly would be a nice feature to have ...
--
Julian
---
Meg Griffin: Somebody's in the closet!
Jeff Foxworthy: You know you're a redneck when your gun rack has a gun rack on it.
Stewie Griffin: You suck!
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:57
Hi,
On Wed, 28 Feb 2007, Julian Phillips wrote:
On Wed, 28 Feb 2007, Andy Parkins wrote:
quoted
On Wednesday 2007 February 28 14:53, Paolo Bonzini wrote:
quoted
As can be seen from my other messages, I'm experimenting a little with
git and trying to understand how its workflow compares with arch. Right
now, my procedure for branching off a remote archive is:
git checkout -b branchname remote/upstreambranch
git config --add branch.branchname.remote remote
git config --add branch.branchname.merge refs/heads/upstreambranch
Is there a reason why "git branch" and "git checkout -b" should not
automatically do the two "git-config --add"s when the source branch is
remote?
I can see why that would be handy, but I often make short lived
branches off a remote; and I wouldn't want my config cluttered up with
branch defintions.
How about adding an option to tell checkout/branch that a tracking
branch is wanted (-t perhaps) - or perhaps a way to say that you don't
want to track the remote (depending on which is more popular)?
I don't think that you should be forced to do it explicitely. If you want
to merge in another branch, you can do that _explicitely_. So, defaulting
to what most people want anyway is A Good Thing.
Just my 2 cents,
Dscho
From: Paolo Bonzini <hidden> Date: 2016-06-15 22:42:57
I don't think that you should be forced to do it explicitely. If you want
to merge in another branch, you can do that _explicitely_. So, defaulting
to what most people want anyway is A Good Thing.
Here is a prototype patch to implement this functionality. One problem
is that config.c does not remove cleaned sections, so after "git-branch
-d mybranch" one is left with a useless "[branch "mybranch"]" section in
.git/config. Other than this, it seems to work well in my experiments.
Paolo
From: Peter Baumann <hidden> Date: 2016-06-15 22:42:57
Andy Parkins [off-list ref] schrieb:
On Wednesday 2007 February 28 14:53, Paolo Bonzini wrote:
quoted
As can be seen from my other messages, I'm experimenting a little with
git and trying to understand how its workflow compares with arch. Right
now, my procedure for branching off a remote archive is:
git checkout -b branchname remote/upstreambranch
git config --add branch.branchname.remote remote
git config --add branch.branchname.merge refs/heads/upstreambranch
Is there a reason why "git branch" and "git checkout -b" should not
automatically do the two "git-config --add"s when the source branch is
remote?
I can see why that would be handy, but I often make short lived branches off a
remote; and I wouldn't want my config cluttered up with branch defintions.
quoted
In case the source branch is not remote, would "origin" be a good choice
for the "branch.branchname.remote" variable?
No. That would still reference a remote. As in:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = refs/heads/master:refs/remotes/origin/master
[branch "master"]
remote = origin
merge = refs/heads/master
The remote = origin tells git to use the [remote "origin"] section.
I think what you want is something that I would like too. If you specify "."
to a git-pull it means to use the local repository not a remote. It would be
great if one could have:
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = refs/heads/master:refs/remotes/origin/master
[branch "master"]
remote = .
merge = refs/remotes/origin/master
That way a "git pull" on master wouldn't need to make a remote connection in
order to do a merge (which is the way I like it). However, I remember there
was a reason this wouldn't work, but I don't remember what it was :-)
Andy
This doesn't work (AIUI). In your example you need to have a remote named ".",
which you havened (and I don't think . is valid for a remote name ).
But this works for me:
[remote "origin"]
url = host:/path/to/your/repo
fetch = refs/heads/*:refs/remotes/origin/*
[remote "local"]
url = .
fetch = refs/remotes/*:refs/remotes/* # fetch into itself -> do nothing
# needed to get the LHS of the fetch
[branch "testbranch"]
remote = local
merge = refs/remotes/origin/master # specifying the LHS of the fetch
When on branch 'testbranch', a 'git pull local' merges
'refs/remotes/origin/master'.
Peter
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:57
Hi,
On Wed, 28 Feb 2007, Paolo Bonzini wrote:
quoted
I don't think that you should be forced to do it explicitely. If you
want to merge in another branch, you can do that _explicitely_. So,
defaulting to what most people want anyway is A Good Thing.
Here is a prototype patch to implement this functionality. One problem
is that config.c does not remove cleaned sections, so after "git-branch
-d mybranch" one is left with a useless "[branch "mybranch"]" section in
.git/config. Other than this, it seems to work well in my experiments.
I'd rather remove the complete section (However, that means that you have
to introduce a function to do that in config.c) instead of unsetting
several hardcoded values.
Also, the second part of your patch would be clearer (methinks) if you
replaced the call to get_sha1() with dwim_ref(). You'd get the real
refname for free...
Ciao,
Dscho
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:57
On 2/28/07, Johannes Schindelin [off-list ref] wrote:
quoted
How about adding an option to tell checkout/branch that a tracking
branch is wanted (-t perhaps) - or perhaps a way to say that you don't
want to track the remote (depending on which is more popular)?
I don't think that you should be forced to do it explicitely. If you want
to merge in another branch, you can do that _explicitely_. So, defaulting
to what most people want anyway is A Good Thing.
As is an option to disable the feature. I.e. for scripts, which create branches
blindly, without knowing they working on a remote branch.
So, please, provide an option to do what git-checkout/git-branch did before:
which is just create the branch, nothing more.
From: Paolo Bonzini <hidden> Date: 2016-06-15 22:42:57
As is an option to disable the feature. I.e. for scripts, which create
branches
blindly, without knowing they working on a remote branch.
So, please, provide an option to do what git-checkout/git-branch did
before:
which is just create the branch, nothing more.
This does create the branch and nothing more. It sets up "git pull" to
do the obvious thing, but does not do anything more. The branch is left
in the same state than without the patch. So the scripts will still
work unless they create branches blindly, and blindly do a "git pull"
expecting it to do the unobvious thing.
Paolo
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:57
On 2/28/07, Paolo Bonzini [off-list ref] wrote:
quoted
As is an option to disable the feature. I.e. for scripts, which create
branches
blindly, without knowing they working on a remote branch.
So, please, provide an option to do what git-checkout/git-branch did
before:
which is just create the branch, nothing more.
This does create the branch and nothing more.
... except ...
It sets up "git pull" to
do the obvious thing, but does not do anything more. The branch is left
in the same state than without the patch. So the scripts will still
work unless they create branches blindly, and blindly do a "git pull"
expecting it to do the unobvious thing.
Well, I find it unobvious for pull to magically starting merging.
Perhaps I'm using branch configuration in .git/config for too long,
and actually expect nothing to be merged if there is no appropriate
branch configuration.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:57
Hi,
On Thu, 1 Mar 2007, Alex Riesen wrote:
Well, I find it unobvious for pull to magically starting merging.
Pull is _all_ about merging.
Perhaps I'm using branch configuration in .git/config for too long, and
actually expect nothing to be merged if there is no appropriate branch
configuration.
It is not possible that you use that feature you described for too long,
since it was not there in 1.4.x. There, whenever you said "git pull", it
would try to blindly pull the default branch of the remote "origin", which
might have been correct for the default branch (i.e. the branch
automatically set up by git-clone), but not necessarily for the other
branches.
And I want to stress a very important point: this automatic setting of the
default remote and branch-to-merge should be _only_ triggered when
branching from refs in $GIT_DIR/refs/remotes. Even if you _do_ branch them
from scripts, I doubt that you'll break _anything_, except of course when
the scripts are buggy to begin with.
There is a good chance that some user wants to merge something
different, but in that case you have to specify what to merge _anyway_.
However, with the proposed behaviour, more new users would get less "Huh?"
experiences.
Ciao,
Dscho
From: Paolo Bonzini <hidden> Date: 2016-06-15 22:42:57
I'd rather remove the complete section (However, that means that you have
to introduce a function to do that in config.c)
No problem.
Also, the second part of your patch would be clearer (methinks) if you
replaced the call to get_sha1() with dwim_ref(). You'd get the real
refname for free...
Not only that, my previous version did not work if somebody specified
remotes/remote/upstreambranch instead of remote/upstreambranch.
Updated version attached.
Paolo
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:57
On 3/1/07, Johannes Schindelin [off-list ref] wrote:
quoted
Well, I find it unobvious for pull to magically starting merging.
Pull is _all_ about merging.
... from what the user _conciously_ meant it to.
quoted
Perhaps I'm using branch configuration in .git/config for too long, and
actually expect nothing to be merged if there is no appropriate branch
configuration.
It is not possible that you use that feature you described for too long,
since it was not there in 1.4.x. There, whenever you said "git pull", it
the syntax was introduced about half a year ago. Plenty of time
to get used to it
would try to blindly pull the default branch of the remote "origin", which
might have been correct for the default branch (i.e. the branch
automatically set up by git-clone), but not necessarily for the other
branches.
which everyone hated. With this change it will not that blindly,
but still unexpectedly jump to some remote branch.
However, with the proposed behaviour, more new users would get less "Huh?"
experiences.
yes, it will be the old users who'd get the experiences. What do they
do, edit out unwanted tracking from .git/config everytime a branch
from remote is created?
Besides, I'm was just asking about providing an option (command-line
parameter) to change the behavior to what it was before!
Just "--no-tracking"?
From: Paolo Bonzini <hidden> Date: 2016-06-15 22:42:57
> which everyone hated. With this change it will not that blindly,
> but still unexpectedly jump to some remote branch.
>
>> However, with the proposed behaviour, more new users would get less
>> "Huh?" experiences.
>
> yes, it will be the old users who'd get the experiences. What do they
> do, edit out unwanted tracking from .git/config everytime a branch
> from remote is created?
If everyone hated the old behavior, old users should already be careful
about not git-pull'ing (without options) from any branch but master. So
they won't see any difference.
Coming from arch, which is not really a masterpiece of intuitiveness,
this detail (as well as others for which I may try writing patches
later) struck me as *extremely* unintuitive...
Paolo
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:57
On 3/1/07, Paolo Bonzini [off-list ref] wrote:
> which everyone hated. With this change it will not that blindly,
> but still unexpectedly jump to some remote branch.
>
>> However, with the proposed behaviour, more new users would get less
>> "Huh?" experiences.
>
> yes, it will be the old users who'd get the experiences. What do they
> do, edit out unwanted tracking from .git/config everytime a branch
> from remote is created?
If everyone hated the old behavior, old users should already be careful
about not git-pull'ing (without options) from any branch but master. So
they won't see any difference.
From: Paolo Bonzini <hidden> Date: 2016-06-15 22:42:57
quoted
If everyone hated the old behavior, old users should already be careful
about not git-pull'ing (without options) from any branch but master. So
they won't see any difference.
except for .git/config growing uncontrollably
While I am probably going to modify the patch to satisfy Junio, have you
noticed that "git branch -d" will delete the section, hence .git/config
will not be growing uncontrollably?
Paolo
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:57
On 3/1/07, Paolo Bonzini [off-list ref] wrote:
quoted
quoted
If everyone hated the old behavior, old users should already be careful
about not git-pull'ing (without options) from any branch but master. So
they won't see any difference.
except for .git/config growing uncontrollably
While I am probably going to modify the patch to satisfy Junio, have you
noticed that "git branch -d" will delete the section, hence .git/config
will not be growing uncontrollably?
Maybe you also have noticed that it will remove also the reference?
How do I remove the garbage you added for TRACKING?!
From: Paolo Bonzini <hidden> Date: 2016-06-15 22:42:57
quoted
While I am probably going to modify the patch to satisfy Junio, have you
noticed that "git branch -d" will delete the section, hence .git/config
will not be growing uncontrollably?
Maybe you also have noticed that it will remove also the reference?
Sure I have.
How do I remove the garbage you added for TRACKING?!
I see two possibilities:
1) I can add a "git-config --remove-section" option. So you can do
"git-pull" to merge onto your branches, and then remove the tracking
section.
2) I can add a "git-branch --stop-tracking" option, which just removes
the section.
3) Same as 2), plus I add a "git-branch --no-track" option, which does
not add the section in the first place. But I do believe that there is
no reason why this cannot be the default.
Paolo
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:57
On 3/1/07, Paolo Bonzini [off-list ref] wrote:
quoted
How do I remove the garbage you added for TRACKING?!
I see two possibilities:
1) I can add a "git-config --remove-section" option. So you can do
"git-pull" to merge onto your branches, and then remove the tracking
section.
This is irrelevant in this particular context. It is just wrong here:
are you sure you _CAN_ know what it is you are removing?
Git config syntax is loosely defined, and branch or remote sections
can have important user information. Which he does not immediately
see typing git config --remove-section branch.abc _JUST_ to get
rid of the configuration he did not want in first place!
2) I can add a "git-branch --stop-tracking" option, which just removes
the section.
This is independent and _probably_ not really needed. It is also
probably more complex than you think. Consider:
[remote "abc"]
url = ...
fetch = refs/heads/*:refs/remotes/abc/*
fetch = refs/heads/test:refs/heads/abc-test
3) Same as 2), plus I add a "git-branch --no-track" option, which does
not add the section in the first place. But I do believe that there is
no reason why this cannot be the default.
This is just what I asked for except for the first part.
And I see no reason for it to _BE_ the default.
Actually, how about making the default configurable _AND_ have
the --no-track option (for scripting)?
From: Paolo Bonzini <hidden> Date: 2016-06-15 22:42:57
Actually, how about making the default configurable _AND_ have
the --no-track option (for scripting)?
Fine by me. And also --track in case you want to try it out. ;-)
I made it default true, environment.c can be changed by Junio if he
applies the patch.
Patch attached. --remove-section will go in a separate patch.
Paolo