* branch.pu.forcefetch @ 2006-12-27 20:31 Pavel Roskin 2006-12-27 21:14 ` branch.pu.forcefetch Jakub Narebski 2006-12-27 21:14 ` branch.pu.forcefetch Junio C Hamano 0 siblings, 2 replies; 14+ messages in thread From: Pavel Roskin @ 2006-12-27 20:31 UTC (permalink / raw) To: git Hello! I'm testing the current git from the master branch, and I like the idea of moving the remotes to the config file, but I think there is a significant omission in the new syntax. There is no way to specify that some branches are fast forward. For example, I clone the git repository anew, and I try to update it by git-fetch a few days later. I get an error: * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu' of git://www.kernel.org/pub/scm/git/git It would be great to have a "non-fastforward" option in the config file for every branch. I'm thinking about something like: [branch "pu"] forcefetch = 1 It would be even better to initialize such option while cloning. -- Regards, Pavel Roskin ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch.pu.forcefetch 2006-12-27 20:31 branch.pu.forcefetch Pavel Roskin @ 2006-12-27 21:14 ` Jakub Narebski 2006-12-27 21:14 ` branch.pu.forcefetch Junio C Hamano 1 sibling, 0 replies; 14+ messages in thread From: Jakub Narebski @ 2006-12-27 21:14 UTC (permalink / raw) To: git Pavel Roskin wrote: > I'm testing the current git from the master branch, and I like the idea > of moving the remotes to the config file, but I think there is a > significant omission in the new syntax. There is no way to specify that > some branches are fast forward. > > For example, I clone the git repository anew, and I try to update it by > git-fetch a few days later. I get an error: > > * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu' > of git://www.kernel.org/pub/scm/git/git > > It would be great to have a "non-fastforward" option in the config file > for every branch. I'm thinking about something like: > > [branch "pu"] > forcefetch = 1 Currently the old '+' before refspec still works. So you should have [remote "origin"] # ... fetch = +refs/heads/pu:refs/remotes/origin/pu > It would be even better to initialize such option while cloning. There was some talk about this, but I don't remember if there were any code. Actually the talk was about marking branch as non-fast-forwardable (which is meant to have rewritten history) on _server_ side, and allowing to fetch all/parts of config while cloning to get this info. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch.pu.forcefetch 2006-12-27 20:31 branch.pu.forcefetch Pavel Roskin 2006-12-27 21:14 ` branch.pu.forcefetch Jakub Narebski @ 2006-12-27 21:14 ` Junio C Hamano 2006-12-27 21:20 ` branch.pu.forcefetch Jakub Narebski 2006-12-28 21:29 ` branch.pu.forcefetch Pavel Roskin 1 sibling, 2 replies; 14+ messages in thread From: Junio C Hamano @ 2006-12-27 21:14 UTC (permalink / raw) To: Pavel Roskin; +Cc: git Pavel Roskin <proski@gnu.org> writes: > For example, I clone the git repository anew, and I try to update it by > git-fetch a few days later. I get an error: > > * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu' > of git://www.kernel.org/pub/scm/git/git Perhaps you would want something like this? if you are using separate remote layout: [remote "origin"] fetch = +refs/heads/pu:refs/remotes/origin/pu fetch = refs/heads/*:refs/remotes/origin/* Or traditional layout: [remote "origin"] fetch = refs/heads/master:refs/heads/origin fetch = refs/heads/next:refs/heads/next fetch = refs/heads/maint:refs/heads/maint fetch = +refs/heads/pu:refs/remotes/pu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch.pu.forcefetch 2006-12-27 21:14 ` branch.pu.forcefetch Junio C Hamano @ 2006-12-27 21:20 ` Jakub Narebski 2006-12-28 21:29 ` branch.pu.forcefetch Pavel Roskin 1 sibling, 0 replies; 14+ messages in thread From: Jakub Narebski @ 2006-12-27 21:20 UTC (permalink / raw) To: git Junio C Hamano wrote: > Pavel Roskin <proski@gnu.org> writes: > >> For example, I clone the git repository anew, and I try to update it by >> git-fetch a few days later. I get an error: >> >> * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu' >> of git://www.kernel.org/pub/scm/git/git > > Perhaps you would want something like this? > > if you are using separate remote layout: > > [remote "origin"] > fetch = +refs/heads/pu:refs/remotes/origin/pu > fetch = refs/heads/*:refs/remotes/origin/* By the way, does the ordering matter here, i.e. does it matter if 'pu' fetch line is before or after wildcards line? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch.pu.forcefetch 2006-12-27 21:14 ` branch.pu.forcefetch Junio C Hamano 2006-12-27 21:20 ` branch.pu.forcefetch Jakub Narebski @ 2006-12-28 21:29 ` Pavel Roskin 2006-12-28 22:44 ` branch.pu.forcefetch Junio C Hamano 1 sibling, 1 reply; 14+ messages in thread From: Pavel Roskin @ 2006-12-28 21:29 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hello! On Wed, 2006-12-27 at 13:14 -0800, Junio C Hamano wrote: > Pavel Roskin <proski@gnu.org> writes: > > > For example, I clone the git repository anew, and I try to update it by > > git-fetch a few days later. I get an error: > > > > * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu' > > of git://www.kernel.org/pub/scm/git/git > > Perhaps you would want something like this? > > if you are using separate remote layout: > > [remote "origin"] > fetch = +refs/heads/pu:refs/remotes/origin/pu > fetch = refs/heads/*:refs/remotes/origin/* That works. Actually, it's strange that I don't actually have refs/heads/pu under .git, and it doesn't get created even if I run "git-pull" or "git-pull origin pu". I realize that I'm far behind in my understanding of GIT, but it seems to me that something is wrong in the new layout. We have a line that says: "pull from pu branch of origin and merge it into local pu branch even if fast-forward is impossible". However, there it no local pu branch. Yet not having this line blocks updating of master branch. It's like saying: I won't update master branch because there is another branch that you are not tracking locally, but if you were, it would not fast forward. Seems quite perverse to me. My .git/config file is: [core] repositoryformatversion = 0 filemode = true logallrefupdates = true [remote "origin"] url = git://www.kernel.org/pub/scm/git/git.git fetch = refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master -- Regards, Pavel Roskin ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch.pu.forcefetch 2006-12-28 21:29 ` branch.pu.forcefetch Pavel Roskin @ 2006-12-28 22:44 ` Junio C Hamano 2006-12-29 0:32 ` [PATCH 1/2] core.logallrefupdates: log remotes/ tracking branches Junio C Hamano ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Junio C Hamano @ 2006-12-28 22:44 UTC (permalink / raw) To: Pavel Roskin; +Cc: git, Shawn Pearce, Johannes Schindelin, Lars Hjemli [jc: some people CC'ed because I'll talk about logallrefupdates at the end] Pavel Roskin <proski@gnu.org> writes: > Actually, it's strange that I don't actually have refs/heads/pu > under .git, and it doesn't get created even if I run "git-pull" or > "git-pull origin pu". "git-pull" without argument (and "git-pull origin") are affected by the config (and .git/remotes/origin), so we will look at your config later. With "git-pull origin pu", you are saying "use URL for origin but this time I am not interested in the set of branches to fetch by default specified in my config". And single token "pu" means you do not want to store the fetch result in any tracking branch (otherwise you would explicitly say "pu:refs/heads/pu" or "pu:/refs/remotes/origin/pu"). > We have a line that says: "pull from pu branch of origin and merge it > into local pu branch even if fast-forward is impossible". Are you talking about "remote.origin.fetch = +pu:refs/heads/pu"? If so, the line does _not_ say that. It does not talk about pulling nor merging. What it says is "My refs/heads/pu is used as a tracking branch for keeping track of the progress of his 'pu'; because I know he rewinds and rebases, please override the fast-forward check when you store the updated value of his 'pu' to my 'refs/heads/pu'". > However, > there it no local pu branch. Yet not having this line blocks updating > of master branch. Now that is worrisome. "git pull" and "git pull origin" (but not "git pull pu" for the reason I mentioned earlier) should create your "pu" branch if you have the configuration. Let me understand the situation. Your config file is: > My .git/config file is: > > [core] > repositoryformatversion = 0 > filemode = true > logallrefupdates = true > [remote "origin"] > url = git://www.kernel.org/pub/scm/git/git.git > fetch = refs/heads/*:refs/remotes/origin/* > [branch "master"] > remote = origin > merge = refs/heads/master So you may not have refs/heads/pu (iow, you do not build on top of my 'pu'), but the config says refs/remotes/origin/ is used to track all my branches. Do you have refs/remotes/origin/pu? If so, then "git fetch" would error out exactly because 'pu' would not fast forward and the config says it does not allow non-fast-forward fetch. It might make sense to make the default configuration git clone creates to say [remote "origin"] url = git://www.kernel.org/pub/scm/git/git.git fetch = +refs/heads/*:refs/remotes/origin/* instead. I think I suggested this once but vaguely recall some people objected, for the reason that an unusual situation such as non-fast-forward should always error out for safety and should require an explicit override by the user. But come to think of it, I think failing to update the remote tracking branch for non-fast-forward does not buy us very much. Letting the user to be aware of the situation has value, but at that point, I do not think there is much else the user can do. The purpose of the tracking branches is to track what happens on the remote side, and the user is in no position to override what has already happend on the remote side (otherwise it stops being "tracking branches"). If reflogs are enabled on remote tracking braches, you can always get back the older state if you wanted to. That makes me notice another thing. We do not seem to create reflog for remotes/ hierarchy even when logallrefupdates is set to true. Would people object if we did this? diff --git a/refs.c b/refs.c index 8b2a3c1..e88ed8b 100644 --- a/refs.c +++ b/refs.c @@ -925,7 +925,8 @@ static int log_ref_write(struct ref_lock *lock, const char *committer; if (log_all_ref_updates && - !strncmp(lock->ref_name, "refs/heads/", 11)) { + (!strncmp(lock->ref_name, "refs/heads/", 11) || + !strncmp(lock->ref_name, "refs/remotes/", 13))) { if (safe_create_leading_directories(lock->log_file) < 0) return error("unable to create directory for %s", lock->log_file); ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 1/2] core.logallrefupdates: log remotes/ tracking branches. 2006-12-28 22:44 ` branch.pu.forcefetch Junio C Hamano @ 2006-12-29 0:32 ` Junio C Hamano 2006-12-29 0:32 ` [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone Junio C Hamano 2006-12-29 1:22 ` branch.pu.forcefetch Pavel Roskin 2 siblings, 0 replies; 14+ messages in thread From: Junio C Hamano @ 2006-12-29 0:32 UTC (permalink / raw) To: git Not using reflog for tags/ was very sensible; not giving reflog for the remotes/ was not. Signed-off-by: Junio C Hamano <junkio@cox.net> --- refs.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/refs.c b/refs.c index 8b2a3c1..e88ed8b 100644 --- a/refs.c +++ b/refs.c @@ -925,7 +925,8 @@ static int log_ref_write(struct ref_lock *lock, const char *committer; if (log_all_ref_updates && - !strncmp(lock->ref_name, "refs/heads/", 11)) { + (!strncmp(lock->ref_name, "refs/heads/", 11) || + !strncmp(lock->ref_name, "refs/remotes/", 13))) { if (safe_create_leading_directories(lock->log_file) < 0) return error("unable to create directory for %s", lock->log_file); -- 1.5.0.rc0.gf5c587 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone 2006-12-28 22:44 ` branch.pu.forcefetch Junio C Hamano 2006-12-29 0:32 ` [PATCH 1/2] core.logallrefupdates: log remotes/ tracking branches Junio C Hamano @ 2006-12-29 0:32 ` Junio C Hamano 2006-12-29 4:35 ` Shawn Pearce 2006-12-29 16:39 ` Johannes Schindelin 2006-12-29 1:22 ` branch.pu.forcefetch Pavel Roskin 2 siblings, 2 replies; 14+ messages in thread From: Junio C Hamano @ 2006-12-29 0:32 UTC (permalink / raw) To: git This changes the default remote.origin.fetch configuration created by git-clone so that it allows non-fast-forward updates. When using the separate-remote layout with reflog enabled, it does not make much sense to refuse to update the remote tracking branch just because some of them do not fast-forward. git-fetch issues warnings on non-fast-forwardness, and the user can peek at what the previous state was using the reflog. Signed-off-by: Junio C Hamano <junkio@cox.net> --- git-clone.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/git-clone.sh b/git-clone.sh index f37eb9d..3d388de 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -388,7 +388,7 @@ then # Set up the mappings to track the remote branches. git-repo-config remote."$origin".fetch \ - "refs/heads/*:$remote_top/*" '^$' && + "+refs/heads/*:$remote_top/*" '^$' && rm -f "refs/remotes/$origin/HEAD" git-symbolic-ref "refs/remotes/$origin/HEAD" \ "refs/remotes/$origin/$head_points_at" && -- 1.5.0.rc0.gf5c587 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone 2006-12-29 0:32 ` [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone Junio C Hamano @ 2006-12-29 4:35 ` Shawn Pearce 2006-12-29 16:39 ` Johannes Schindelin 1 sibling, 0 replies; 14+ messages in thread From: Shawn Pearce @ 2006-12-29 4:35 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Junio C Hamano <junkio@cox.net> wrote: > This changes the default remote.origin.fetch configuration > created by git-clone so that it allows non-fast-forward updates. Ack'd, but only if '[PATCH 1/2] core.logallrefupdates: log remotes/ tracking branches.' is also applied. I think both are worth applying. -- Shawn. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone 2006-12-29 0:32 ` [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone Junio C Hamano 2006-12-29 4:35 ` Shawn Pearce @ 2006-12-29 16:39 ` Johannes Schindelin 1 sibling, 0 replies; 14+ messages in thread From: Johannes Schindelin @ 2006-12-29 16:39 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hi, On Thu, 28 Dec 2006, Junio C Hamano wrote: > git-repo-config remote."$origin".fetch \ > - "refs/heads/*:$remote_top/*" '^$' && > + "+refs/heads/*:$remote_top/*" '^$' && Minor nit: these days, it is cleaner (and clearer) to use "git-repo-config --add" instead of using the "^$" construct yourself. However, I don't think this patch has to be changed. Ciao, Dscho ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch.pu.forcefetch 2006-12-28 22:44 ` branch.pu.forcefetch Junio C Hamano 2006-12-29 0:32 ` [PATCH 1/2] core.logallrefupdates: log remotes/ tracking branches Junio C Hamano 2006-12-29 0:32 ` [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone Junio C Hamano @ 2006-12-29 1:22 ` Pavel Roskin 2006-12-29 2:30 ` branch.pu.forcefetch Junio C Hamano 2 siblings, 1 reply; 14+ messages in thread From: Pavel Roskin @ 2006-12-29 1:22 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, Shawn Pearce, Johannes Schindelin, Lars Hjemli On Thu, 2006-12-28 at 14:44 -0800, Junio C Hamano wrote: > [jc: some people CC'ed because I'll talk about logallrefupdates > at the end] OK. > Pavel Roskin <proski@gnu.org> writes: > > > Actually, it's strange that I don't actually have refs/heads/pu > > under .git, and it doesn't get created even if I run "git-pull" or > > "git-pull origin pu". > > "git-pull" without argument (and "git-pull origin") are affected > by the config (and .git/remotes/origin), so we will look at your > config later. > > With "git-pull origin pu", you are saying "use URL for origin > but this time I am not interested in the set of branches to > fetch by default specified in my config". And single token "pu" > means you do not want to store the fetch result in any tracking > branch (otherwise you would explicitly say "pu:refs/heads/pu" or > "pu:/refs/remotes/origin/pu"). OK, I'm going to take a "bird's view" of it. If you happen to think I'm saying stupid things, it's just because I'm playing an even less experienced user than I am. I don't think it's a good idea to expose the layout under .git to the end user. I do realize that git is just "plumbing", but things like "refs/heads/" should probably be hidden from the user in any case. Using path as an indicator that something should be saved looks like a kludge. Maybe we could have a notation for branches on remotes (e.g. pu@origin or origin#pu), tracking branches and non-tracking branches? I would be happy if the same name could be used for all of them. After all, that's the way CVS and Subversion do it, and it's fine for most users. As for the locations under refs, let's leave it to git. > > We have a line that says: "pull from pu branch of origin and merge it > > into local pu branch even if fast-forward is impossible". > > Are you talking about "remote.origin.fetch = +pu:refs/heads/pu"? Yes, I'm talking about that line. And I don't like that I have to use a magic token "refs/heads/pu" that doesn't correspond to a real file to make it possible to keep git up-to-date. [skip] > > However, > > there it no local pu branch. Yet not having this line blocks updating > > of master branch. > > Now that is worrisome. "git pull" and "git pull origin" (but > not "git pull pu" for the reason I mentioned earlier) should > create your "pu" branch if you have the configuration. > > Let me understand the situation. Your config file is: > > > My .git/config file is: > > > > [core] > > repositoryformatversion = 0 > > filemode = true > > logallrefupdates = true > > [remote "origin"] > > url = git://www.kernel.org/pub/scm/git/git.git > > fetch = refs/heads/*:refs/remotes/origin/* > > [branch "master"] > > remote = origin > > merge = refs/heads/master > > So you may not have refs/heads/pu (iow, you do not build on top > of my 'pu'), but the config says refs/remotes/origin/ is used to > track all my branches. Do you have refs/remotes/origin/pu? Yes. I'm doing a clean checkout now with the current git from the "master" branch: [proski@dv git]$ git-clone git://www.kernel.org/pub/scm/git/git.git Initialized empty Git repository in /home/proski/tmp/git/git/.git/ remote: Generating pack... remote: Done counting 35273 objects. remote: Deltifying 35273 objects. remote: 100% (35273/35273) done Indexing 35273 objects. remote: Total 35273, written 35273 (delta 24484), reused 35217 (delta 24444) 100% (35273/35273) done Resolving 24484 deltas. 100% (24484/24484) done Checking files out... 100% (761/761) done [proski@dv git]$ git --version git version 1.5.0.rc0.g4a4d [proski@dv git]$ ls git/.git/refs/remotes/origin/ HEAD html maint man master next pu todo [proski@dv git]$ ls git/.git/refs/heads/ master [proski@dv git]$ cd git/ [proski@dv git]$ git-pull Already up-to-date. [proski@dv git]$ ls .git/refs/heads/ master [proski@dv git]$ > If so, then "git fetch" would error out exactly because 'pu' > would not fast forward and the config says it does not allow > non-fast-forward fetch. > > It might make sense to make the default configuration git > clone creates to say > > [remote "origin"] > url = git://www.kernel.org/pub/scm/git/git.git > fetch = +refs/heads/*:refs/remotes/origin/* > > instead. > > I think I suggested this once but vaguely recall some people > objected, for the reason that an unusual situation such as > non-fast-forward should always error out for safety and should > require an explicit override by the user. In this particular case of the GIT project, it's very rare that I would be interested in the "pu" branch. I'm mostly interested in "master", and I can be occasionally interested in "next". The default for git-clone is to clone all branches. It's OK for me because I'm on a fast connection (I hear angry voices of modem users). Actually, I don't see an option to git-clone to clone HEAD or selected branches only. The "-o" option seems to be something different, even though the manual mention branches. Unfortunately, updating the current branch fails because pu is not fast-forwarding. Why fail if I'm not even on pu? In other words, the basic default functionality is hampered because of a branch the user is not even using in any way. And the fix involves editing the config file. > But come to think of it, I think failing to update the remote > tracking branch for non-fast-forward does not buy us very much. > Letting the user to be aware of the situation has value, but at > that point, I do not think there is much else the user can do. > The purpose of the tracking branches is to track what happens on > the remote side, and the user is in no position to override what > has already happend on the remote side (otherwise it stops being > "tracking branches"). If reflogs are enabled on remote tracking > braches, you can always get back the older state if you wanted > to. I tend to agree. Of course, if any porcelains require or prefer fast-forward, they should be able to prevent non-fast-forward updates. Perhaps they would be OK with non-fast-forward updates on branches other than those they are specifically managing? > That makes me notice another thing. We do not seem to create > reflog for remotes/ hierarchy even when logallrefupdates is set > to true. Would people object if we did this? No objection on my part. -- Regards, Pavel Roskin ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch.pu.forcefetch 2006-12-29 1:22 ` branch.pu.forcefetch Pavel Roskin @ 2006-12-29 2:30 ` Junio C Hamano 2006-12-29 3:34 ` branch.pu.forcefetch Pavel Roskin 0 siblings, 1 reply; 14+ messages in thread From: Junio C Hamano @ 2006-12-29 2:30 UTC (permalink / raw) To: Pavel Roskin; +Cc: git Pavel Roskin <proski@gnu.org> writes: >> Are you talking about "remote.origin.fetch = +pu:refs/heads/pu"? > > Yes, I'm talking about that line. And I don't like that I have to use a > magic token "refs/heads/pu" that doesn't correspond to a real file to > make it possible to keep git up-to-date. I think we misunderstood each other. That line is inconsistent with what your config has, which is the separate-remote layout, which I did not know you were using. In separate-remote layout, you don't have refs/heads/pu so if we do not do the patches you are agreeing to, you would want to have something like: [remote "origin"] fetch = +refs/heads/pu:refs/remotes/origin/pu fetch = refs/heads/*:refs/remotes/origin/* In other words, "path does not correspond to a real file" problem does not exist. If you tell git to track 'pu' at refs/remotes/origin/pu, it will use that path -- so that path has a corresponding real file. > Unfortunately, updating the current branch fails because pu is not > fast-forwarding. Why fail if I'm not even on pu? Your being not on 'pu' does not have anything to do with it. In fact, you do not even want to be _on_ any of your tracking branches. In the separate-remote layout, you cannot even be on remotes/origin/pu branch. What you are seeing is fetch's safety feature that stops and notifies you the situation when the remote rewinds/rebases the branch you are tracking with tracking branches. We have had it turned on by default for a long time, and you have it turned on in your config because that is the default. If you do not want to use that feature (and for git.git, you certainly don't), just turn it off. When you know you do not want to use a feature, you do not have to. Turning it off by default was not a wise thing to do in general for a long time, because rewound/rebased tip loses information, and we did not have reflog enabled by default. Your message raised this issue to attention of the list, and I suggested two patches out of it, both of which I think are sane things to do. If the list agrees, we can turn it off by default now. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch.pu.forcefetch 2006-12-29 2:30 ` branch.pu.forcefetch Junio C Hamano @ 2006-12-29 3:34 ` Pavel Roskin 2006-12-29 4:31 ` branch.pu.forcefetch Shawn Pearce 0 siblings, 1 reply; 14+ messages in thread From: Pavel Roskin @ 2006-12-29 3:34 UTC (permalink / raw) To: Junio C Hamano; +Cc: git On Thu, 2006-12-28 at 18:30 -0800, Junio C Hamano wrote: > Pavel Roskin <proski@gnu.org> writes: > > >> Are you talking about "remote.origin.fetch = +pu:refs/heads/pu"? > > > > Yes, I'm talking about that line. And I don't like that I have to use a > > magic token "refs/heads/pu" that doesn't correspond to a real file to > > make it possible to keep git up-to-date. > > I think we misunderstood each other. I just didn't notice that your question used a different line. I was talking about fetch = +refs/heads/pu:refs/remotes/origin/pu > That line is inconsistent > with what your config has, which is the separate-remote layout, > which I did not know you were using. In separate-remote layout, > you don't have refs/heads/pu so if we do not do the patches you > are agreeing to, you would want to have something like: > > [remote "origin"] > fetch = +refs/heads/pu:refs/remotes/origin/pu > fetch = refs/heads/*:refs/remotes/origin/* I get it now. "refs/heads/pu" must be the path on the remote side. The whole thing remains pretty hairy for my taste, but it looks like we are going to untangle it step-by-step. > Turning it off by default was not a wise thing to do in general > for a long time, because rewound/rebased tip loses information, > and we did not have reflog enabled by default. Your message > raised this issue to attention of the list, and I suggested two > patches out of it, both of which I think are sane things to do. > If the list agrees, we can turn it off by default now. Just a random idea - if fast-forward fails, save the original head somewhere under refs as a backup. It's like "patch" saving *.orig files if there is any doubt that the patch was applied cleanly. But I'm fine with reflog too. -- Regards, Pavel Roskin ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: branch.pu.forcefetch 2006-12-29 3:34 ` branch.pu.forcefetch Pavel Roskin @ 2006-12-29 4:31 ` Shawn Pearce 0 siblings, 0 replies; 14+ messages in thread From: Shawn Pearce @ 2006-12-29 4:31 UTC (permalink / raw) To: Pavel Roskin; +Cc: Junio C Hamano, git Pavel Roskin <proski@gnu.org> wrote: > Just a random idea - if fast-forward fails, save the original head > somewhere under refs as a backup. It's like "patch" saving *.orig files > if there is any doubt that the patch was applied cleanly. That's the entire point of the reflog. :-) -- Shawn. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2006-12-29 16:39 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-12-27 20:31 branch.pu.forcefetch Pavel Roskin 2006-12-27 21:14 ` branch.pu.forcefetch Jakub Narebski 2006-12-27 21:14 ` branch.pu.forcefetch Junio C Hamano 2006-12-27 21:20 ` branch.pu.forcefetch Jakub Narebski 2006-12-28 21:29 ` branch.pu.forcefetch Pavel Roskin 2006-12-28 22:44 ` branch.pu.forcefetch Junio C Hamano 2006-12-29 0:32 ` [PATCH 1/2] core.logallrefupdates: log remotes/ tracking branches Junio C Hamano 2006-12-29 0:32 ` [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone Junio C Hamano 2006-12-29 4:35 ` Shawn Pearce 2006-12-29 16:39 ` Johannes Schindelin 2006-12-29 1:22 ` branch.pu.forcefetch Pavel Roskin 2006-12-29 2:30 ` branch.pu.forcefetch Junio C Hamano 2006-12-29 3:34 ` branch.pu.forcefetch Pavel Roskin 2006-12-29 4:31 ` branch.pu.forcefetch Shawn Pearce
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.