* StGIT discards local commits on "stg pull" @ 2007-02-12 7:26 Pavel Roskin 2007-02-12 9:31 ` Catalin Marinas 0 siblings, 1 reply; 12+ messages in thread From: Pavel Roskin @ 2007-02-12 7:26 UTC (permalink / raw) To: git; +Cc: Yann Dirson, Catalin Marinas Hello! I have been bitten by a strange bug/feature of StGIT, and it looks like it's not only counterintuitive, but also inconsistent with git. I have a repository available over ssh and I push to it from several places. Sometimes I make a commit and forget to push it. Then I run "stg pull" to make sure my repository is up to date. The result is that the repository is rebased back to the last remote commit. It's very easy to miss. There is no warning. Everything looks just like an update from the remote. The example below shows that git-pull keeps my commit, but "stg pull" discards it by rebasing back to the remote ID. My .gitconfig doesn't override "stg pull" behavior; it merely sets my name and mail aliases. [proski@dl stgit-test]$ stg id ebc429e7b7e596a12e8255fadc397123893cec73 [proski@dl stgit-test]$ echo "test change" >README [proski@dl stgit-test]$ git-commit -m "test commit" README Created commit 468861a2a1530f3bf98108e69632b3059e4ca0ce 1 files changed, 1 insertions(+), 14 deletions(-) [proski@dl stgit-test]$ git-pull Fetching refs/heads/master from http://homepage.ntlworld.com/cmarinas/stgit.git using http Fetching refs/heads/stable from http://homepage.ntlworld.com/cmarinas/stgit.git using http Already up-to-date. [proski@dl stgit-test]$ stg id 468861a2a1530f3bf98108e69632b3059e4ca0ce [proski@dl stgit-test]$ stg pull Checking for changes in the working directory... done Pulling from "origin"... Fetching refs/heads/master from http://homepage.ntlworld.com/cmarinas/stgit.git using http Fetching refs/heads/stable from http://homepage.ntlworld.com/cmarinas/stgit.git using http rebasing to "ebc429e7b7e596a12e8255fadc397123893cec73"... done No patches applied [proski@dl stgit-test]$ stg id ebc429e7b7e596a12e8255fadc397123893cec73 [proski@dl stgit-test]$ -- Regards, Pavel Roskin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: StGIT discards local commits on "stg pull" 2007-02-12 7:26 StGIT discards local commits on "stg pull" Pavel Roskin @ 2007-02-12 9:31 ` Catalin Marinas 2007-02-12 20:26 ` Yann Dirson 2007-02-13 0:20 ` Pavel Roskin 0 siblings, 2 replies; 12+ messages in thread From: Catalin Marinas @ 2007-02-12 9:31 UTC (permalink / raw) To: Pavel Roskin; +Cc: git, Yann Dirson On 12/02/07, Pavel Roskin <proski@gnu.org> wrote: > I have been bitten by a strange bug/feature of StGIT, and it looks like > it's not only counterintuitive, but also inconsistent with git. > > I have a repository available over ssh and I push to it from several > places. Sometimes I make a commit and forget to push it. Then I run "stg > pull" to make sure my repository is up to date. > > The result is that the repository is rebased back to the last remote > commit. It's very easy to miss. There is no warning. Everything looks > just like an update from the remote. > > The example below shows that git-pull keeps my commit, but "stg pull" > discards it by rebasing back to the remote ID. I think this is a "feature" but we should've probably leave the original behaviour as the default. Maybe we should also have this per-branch rather than per-repository. In StGIT 0.12, git-fetch is used by default rather than git-pull and StGIT performs the rebasing. We had some discussions on whether this would break existing workflows and we thought it wouldn't (I don't usually mix git-commit with stg commands). The solution would be to define the following in your gitconfig file (either ~/.gitconfig or .git/config; a full example in StGIT's examples/gitconfig): [stgit] pullcmd = git-pull pull-does-rebase = no The last line would tell StGIT not to do the rebasing and let git-pull handle it. I agree that for the rebasing case, we should have some warning if fast-forwarding of the stack's base is not possible so that you could run 'stg uncommit'. -- Catalin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: StGIT discards local commits on "stg pull" 2007-02-12 9:31 ` Catalin Marinas @ 2007-02-12 20:26 ` Yann Dirson 2007-02-12 21:47 ` Yann Dirson 2007-02-13 0:20 ` Pavel Roskin 1 sibling, 1 reply; 12+ messages in thread From: Yann Dirson @ 2007-02-12 20:26 UTC (permalink / raw) To: Catalin Marinas; +Cc: Pavel Roskin, git On Mon, Feb 12, 2007 at 09:31:28AM +0000, Catalin Marinas wrote: > On 12/02/07, Pavel Roskin <proski@gnu.org> wrote: > >I have been bitten by a strange bug/feature of StGIT, and it looks like > >it's not only counterintuitive, but also inconsistent with git. > > > >I have a repository available over ssh and I push to it from several > >places. Sometimes I make a commit and forget to push it. Then I run "stg > >pull" to make sure my repository is up to date. > > > >The result is that the repository is rebased back to the last remote > >commit. It's very easy to miss. There is no warning. Everything looks > >just like an update from the remote. > > > >The example below shows that git-pull keeps my commit, but "stg pull" > >discards it by rebasing back to the remote ID. > > I think this is a "feature" No, I agree it's a bug. Rebasing after a fetch should allow this workflow to work as well. If the parent branch is not a rewinding one, we should ensure there is nothing lost. And even for rewinding branches, we should probably keep track of the existence of commits, so we can warn and nothing gets lost without knowing. That makes me think that in most cases, an "stg commit" is done to be pushed to a remote repo, as symetric operation to "stg pull". Probably we could add support for this sort of operation (similar to "stg-cvs commit" from my script). > but we should've probably leave the > original behaviour as the default. Maybe we should also have this > per-branch rather than per-repository. Right, having it per-branch would allow, eg. to declare something like git-svn as the way to pull from a given branch, while using different backends for other branches. > I agree that for the rebasing case, we should have some warning if > fast-forwarding of the stack's base is not possible so that you could > run 'stg uncommit'. Right. "rebase --undo" could help too. best regards, -- Yann. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: StGIT discards local commits on "stg pull" 2007-02-12 20:26 ` Yann Dirson @ 2007-02-12 21:47 ` Yann Dirson 2007-02-19 23:07 ` Catalin Marinas 0 siblings, 1 reply; 12+ messages in thread From: Yann Dirson @ 2007-02-12 21:47 UTC (permalink / raw) To: Pavel Roskin; +Cc: git, Catalin Marinas On Mon, Feb 12, 2007 at 09:26:34PM +0100, Yann Dirson wrote: > On Mon, Feb 12, 2007 at 09:31:28AM +0000, Catalin Marinas wrote: > > On 12/02/07, Pavel Roskin <proski@gnu.org> wrote: > > >I have been bitten by a strange bug/feature of StGIT, and it looks like > > >it's not only counterintuitive, but also inconsistent with git. > > > > > >I have a repository available over ssh and I push to it from several > > >places. Sometimes I make a commit and forget to push it. Then I run "stg > > >pull" to make sure my repository is up to date. > > > > > >The result is that the repository is rebased back to the last remote > > >commit. It's very easy to miss. There is no warning. Everything looks > > >just like an update from the remote. > > > > > >The example below shows that git-pull keeps my commit, but "stg pull" > > >discards it by rebasing back to the remote ID. > > > > I think this is a "feature" > > No, I agree it's a bug. Rebasing after a fetch should allow this > workflow to work as well. If the parent branch is not a rewinding > one, we should ensure there is nothing lost. And even for rewinding > branches, we should probably keep track of the existence of commits, > so we can warn and nothing gets lost without knowing. Thinking about it, detecting whether we're going to lose a commit is just checking *before pulling* whether the current base is reachable from the parent's current head. In git-fetch-based workflows, proceeding further should be simply refused. I'm not sure about the git-pull-based workflows; here is at least one problem with git-pull I can think of: AFAICT, someone using git-pull would in this case get a merge commit, so under 0.11 (or with the compat settings outlined by Catalin) you should now have your stack based on a merge commit, with as parents the new parent-branch head and the commits you did not push yet, right ? So how did you proceed from there using 0.11 ? I'd think you still want to push your patch into the parent repo, but the situtation is cumbersome: it would have been far easier IMHO to "stg pull" first, in which case the fetch-and-rebase model is what you wanted, and then do a "stg commit && git push". That makes me think that indeed we should have an stgit command doing precisely this "stg commit && git push" (suggested in previous mail) as an atomic operation, rolling back the commit if the push failed because you were out of date. Since that looks like a pathological case, I suppose this may not be what you were trying to do. Can you please give more information if that is the case ? Best regards, -- Yann. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: StGIT discards local commits on "stg pull" 2007-02-12 21:47 ` Yann Dirson @ 2007-02-19 23:07 ` Catalin Marinas 2007-02-19 23:28 ` Pavel Roskin 2007-02-19 23:44 ` Yann Dirson 0 siblings, 2 replies; 12+ messages in thread From: Catalin Marinas @ 2007-02-19 23:07 UTC (permalink / raw) To: Yann Dirson; +Cc: Pavel Roskin, git On 12/02/07, Yann Dirson <ydirson@altern.org> wrote: > On Mon, Feb 12, 2007 at 09:26:34PM +0100, Yann Dirson wrote: > > No, I agree it's a bug. Rebasing after a fetch should allow this > > workflow to work as well. If the parent branch is not a rewinding > > one, we should ensure there is nothing lost. And even for rewinding > > branches, we should probably keep track of the existence of commits, > > so we can warn and nothing gets lost without knowing. > > Thinking about it, detecting whether we're going to lose a commit is > just checking *before pulling* whether the current base is reachable > from the parent's current head. There is a potential problem with this approach - pulling/fetching from a tree which is always rebased (either managed with StGIT or simply running git-rebase before publishing it) would report an error since the old base is no longer reachable from the current head. In this case, the current fetch+rebase behaviour would be desirable. I think the fail-safe solution would be to leave the old behaviour (i.e. git-pull and pull-does-rebase=no) and people that need to pull from branches like that described above would use the fetch+rebase approach. Ideally, we'll have this configurable per-branch (and could leave the global one as well if the most specific is not available, but should default to git-pull). Let me know what you think so that I'll try to release a 0.12.1 update (I already have the simple patch for using git-pull by default if you are OK with this scenario). Thanks. -- Catalin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: StGIT discards local commits on "stg pull" 2007-02-19 23:07 ` Catalin Marinas @ 2007-02-19 23:28 ` Pavel Roskin 2007-02-20 0:00 ` Yann Dirson 2007-02-19 23:44 ` Yann Dirson 1 sibling, 1 reply; 12+ messages in thread From: Pavel Roskin @ 2007-02-19 23:28 UTC (permalink / raw) To: Catalin Marinas; +Cc: Yann Dirson, git On Mon, 2007-02-19 at 23:07 +0000, Catalin Marinas wrote: > On 12/02/07, Yann Dirson <ydirson@altern.org> wrote: > > On Mon, Feb 12, 2007 at 09:26:34PM +0100, Yann Dirson wrote: > > > No, I agree it's a bug. Rebasing after a fetch should allow this > > > workflow to work as well. If the parent branch is not a rewinding > > > one, we should ensure there is nothing lost. And even for rewinding > > > branches, we should probably keep track of the existence of commits, > > > so we can warn and nothing gets lost without knowing. > > > > Thinking about it, detecting whether we're going to lose a commit is > > just checking *before pulling* whether the current base is reachable > > from the parent's current head. > > There is a potential problem with this approach - pulling/fetching > from a tree which is always rebased (either managed with StGIT or > simply running git-rebase before publishing it) would report an error > since the old base is no longer reachable from the current head. In > this case, the current fetch+rebase behaviour would be desirable. One possible workaround would be to report an error and do nothing if the old head would become unreachable (it's possible that I'm missing something and that it was discussed to death already). > I think the fail-safe solution would be to leave the old behaviour > (i.e. git-pull and pull-does-rebase=no) and people that need to pull > from branches like that described above would use the fetch+rebase > approach. Ideally, we'll have this configurable per-branch (and could > leave the global one as well if the most specific is not available, > but should default to git-pull). By the way, it would be great to reduce all complexity to "one bit" per branch. If stgit.internal-pull (the name is subject to improvement) is on, "stgit pull" calls git-fetch and does rebase. Otherwise, it calls git-pull. No need to configure two variables per branch. > Let me know what you think so that I'll try to release a 0.12.1 update > (I already have the simple patch for using git-pull by default if you > are OK with this scenario). Any fix for the current behavior would be fine to me. Either restore the old default or don't rebase if the old head becomes unreachable. -- Regards, Pavel Roskin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: StGIT discards local commits on "stg pull" 2007-02-19 23:28 ` Pavel Roskin @ 2007-02-20 0:00 ` Yann Dirson 2007-02-20 18:55 ` Yann Dirson 0 siblings, 1 reply; 12+ messages in thread From: Yann Dirson @ 2007-02-20 0:00 UTC (permalink / raw) To: Pavel Roskin; +Cc: Catalin Marinas, git On Mon, Feb 19, 2007 at 06:28:40PM -0500, Pavel Roskin wrote: > > I think the fail-safe solution would be to leave the old behaviour > > (i.e. git-pull and pull-does-rebase=no) and people that need to pull > > from branches like that described above would use the fetch+rebase > > approach. Ideally, we'll have this configurable per-branch (and could > > leave the global one as well if the most specific is not available, > > but should default to git-pull). > > By the way, it would be great to reduce all complexity to "one bit" per > branch. If stgit.internal-pull (the name is subject to improvement) is > on, "stgit pull" calls git-fetch and does rebase. Otherwise, it calls > git-pull. No need to configure two variables per branch. Being able to specify the command to use makes it possible to hook to other SCM's (eg. using git-cvsimport, git-svn or similar). I'll try to adapt by stg-cvs script to fit into this model some day (indeed, "pullcmd = stg-cvs fetch" may indeed already work). Best regards, -- Yann. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: StGIT discards local commits on "stg pull" 2007-02-20 0:00 ` Yann Dirson @ 2007-02-20 18:55 ` Yann Dirson 0 siblings, 0 replies; 12+ messages in thread From: Yann Dirson @ 2007-02-20 18:55 UTC (permalink / raw) To: Pavel Roskin; +Cc: Catalin Marinas, git On Tue, Feb 20, 2007 at 01:00:59AM +0100, Yann Dirson wrote: > On Mon, Feb 19, 2007 at 06:28:40PM -0500, Pavel Roskin wrote: > > > I think the fail-safe solution would be to leave the old behaviour > > > (i.e. git-pull and pull-does-rebase=no) and people that need to pull > > > from branches like that described above would use the fetch+rebase > > > approach. Ideally, we'll have this configurable per-branch (and could > > > leave the global one as well if the most specific is not available, > > > but should default to git-pull). > > > > By the way, it would be great to reduce all complexity to "one bit" per > > branch. If stgit.internal-pull (the name is subject to improvement) is > > on, "stgit pull" calls git-fetch and does rebase. Otherwise, it calls > > git-pull. No need to configure two variables per branch. > > Being able to specify the command to use makes it possible to hook to > other SCM's (eg. using git-cvsimport, git-svn or similar). Thinking twice, we could make things even better :) Let's acknowledge that we have several ways of pulling, by getting rid of the awkward 'stgit.pull-does-rebase'. Instead we could use a new "pull-policy" setting, with possible values "pull" and "fetch-rebase" to match the 2 currently-available behaviours. Then according to the pull-policy, "stg pull" would use "pullcmd" or a new "fetchcmd" setting, thus removing the requirement to mess with pullcmd in the common case. All of "pull-policy", "pullcmd", and "fetchcmd" would have a per-branch and a global setting (stgit.<foo> and branch.*.stgit.<foo>). We could also introduce a 3rd "rebase" policy, to support local parent branches better. Best regards, -- Yann. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: StGIT discards local commits on "stg pull" 2007-02-19 23:07 ` Catalin Marinas 2007-02-19 23:28 ` Pavel Roskin @ 2007-02-19 23:44 ` Yann Dirson 1 sibling, 0 replies; 12+ messages in thread From: Yann Dirson @ 2007-02-19 23:44 UTC (permalink / raw) To: Catalin Marinas; +Cc: Pavel Roskin, git On Mon, Feb 19, 2007 at 11:07:09PM +0000, Catalin Marinas wrote: > >Thinking about it, detecting whether we're going to lose a commit is > >just checking *before pulling* whether the current base is reachable > >from the parent's current head. > > There is a potential problem with this approach - pulling/fetching > from a tree which is always rebased (either managed with StGIT or > simply running git-rebase before publishing it) would report an error > since the old base is no longer reachable from the current head. Right - a better solution is highlighted in today's proposal (which I have started to implement). > In this case, the current fetch+rebase behaviour would be desirable. > > I think the fail-safe solution would be to leave the old behaviour > (i.e. git-pull and pull-does-rebase=no) and people that need to pull > from branches like that described above would use the fetch+rebase > approach. We could do this, but I only see this as a temporary measure to avoid unleashing the new behaviour onto unsuspicious users before we've ironed out the final behaviour. I still think that the current behaviour belongs to a very specific workflow which is not that expected by most users. > Ideally, we'll have this configurable per-branch (and could > leave the global one as well if the most specific is not available, Right. > but should default to git-pull). > > Let me know what you think so that I'll try to release a 0.12.1 update > (I already have the simple patch for using git-pull by default if you > are OK with this scenario). Since it is important that users don't unknowingly loose commits, yes it is preferable to release 0.12.1 with the old behaviour. Let's take the time to shake things more for 0.13, and we can reconsider this choice by then. Best regards, -- Yann. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: StGIT discards local commits on "stg pull" 2007-02-12 9:31 ` Catalin Marinas 2007-02-12 20:26 ` Yann Dirson @ 2007-02-13 0:20 ` Pavel Roskin 2007-02-13 22:48 ` Catalin Marinas 1 sibling, 1 reply; 12+ messages in thread From: Pavel Roskin @ 2007-02-13 0:20 UTC (permalink / raw) To: Catalin Marinas; +Cc: git, Yann Dirson On Mon, 2007-02-12 at 09:31 +0000, Catalin Marinas wrote: > On 12/02/07, Pavel Roskin <proski@gnu.org> wrote: > > The example below shows that git-pull keeps my commit, but "stg pull" > > discards it by rebasing back to the remote ID. > > I think this is a "feature" but we should've probably leave the > original behaviour as the default. Maybe we should also have this > per-branch rather than per-repository. I don't know the original motivation behind effectively reimplementing "git pull" in StGIT, but it's clear that the StGIT's own implementation needs some polish. I think it's always wrong to lose local commits. I think StGIT should refuse to rebase if a merge would be needed or the rebase would go back in history (in other words, if git-pull would not go to the remote revision). > In StGIT 0.12, git-fetch is used by default rather than git-pull and > StGIT performs the rebasing. We had some discussions on whether this > would break existing workflows and we thought it wouldn't (I don't > usually mix git-commit with stg commands). Maybe such assumptions could be enforced? Perhaps we could consider branch specialization. As it stands now, we can have branches where fast-forward is OK and branches where it's not OK. If we look at it from the user standpoint, the branches could be distinguished by the use model: 1) Tracking branch: pull is OK, commit is not OK, push is not OK. All development is done in StGIT patches and sent to others. 2) Development branch: commit is OK, push is OK, pull is OK but no merges by default. 3) Merge branch: pull is OK, even with automatic merge, commit is OK, merge is OK. I'm not sure if this belongs to git or StGIT. > The solution would be to define the following in your gitconfig file > (either ~/.gitconfig or .git/config; a full example in StGIT's > examples/gitconfig): > > [stgit] > pullcmd = git-pull > pull-does-rebase = no > > The last line would tell StGIT not to do the rebasing and let git-pull > handle it. It's actually my deliberate choice to subject myself to the pains of the default configuration. I don't want to live in backwards compatible environment until it rots away. I'll rather eat the dogfood we are offering to others :) > I agree that for the rebasing case, we should have some warning if > fast-forwarding of the stack's base is not possible so that you could > run 'stg uncommit'. Sounds good to me. -- Regards, Pavel Roskin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: StGIT discards local commits on "stg pull" 2007-02-13 0:20 ` Pavel Roskin @ 2007-02-13 22:48 ` Catalin Marinas 2007-02-19 20:47 ` Yann Dirson 0 siblings, 1 reply; 12+ messages in thread From: Catalin Marinas @ 2007-02-13 22:48 UTC (permalink / raw) To: Pavel Roskin; +Cc: git, Yann Dirson On 13/02/07, Pavel Roskin <proski@gnu.org> wrote: > On Mon, 2007-02-12 at 09:31 +0000, Catalin Marinas wrote: > > On 12/02/07, Pavel Roskin <proski@gnu.org> wrote: > > > > The example below shows that git-pull keeps my commit, but "stg pull" > > > discards it by rebasing back to the remote ID. > > > > I think this is a "feature" but we should've probably leave the > > original behaviour as the default. Maybe we should also have this > > per-branch rather than per-repository. > > I don't know the original motivation behind effectively reimplementing > "git pull" in StGIT, but it's clear that the StGIT's own implementation > needs some polish. Yann can describe the motivation better as he was the one pushing for it. It was mainly to allow different local branches to be based on different remote branches. In the normal case, i.e. using only StGIT commands, there shouldn't be any difference. As I said, the old behaviour is still present and maybe we should do the new one per-branch. > I think it's always wrong to lose local commits. I think StGIT should > refuse to rebase if a merge would be needed or the rebase would go back > in history (in other words, if git-pull would not go to the remote > revision). Yes, indeed. > If we look at it from the user standpoint, the branches could be > distinguished by the use model: > > 1) Tracking branch: pull is OK, commit is not OK, push is not OK. All > development is done in StGIT patches and sent to others. > > 2) Development branch: commit is OK, push is OK, pull is OK but no > merges by default. > > 3) Merge branch: pull is OK, even with automatic merge, commit is OK, > merge is OK. I probably have another situation - a branch managed partially with StGIT but GIT commits (or 'stg commit') used and pulling would lead to a merge of the base, followed by patch pushing. This would work if we use git-pull rather than git-fetch. > > The solution would be to define the following in your gitconfig file > > (either ~/.gitconfig or .git/config; a full example in StGIT's > > examples/gitconfig): > > > > [stgit] > > pullcmd = git-pull > > pull-does-rebase = no > > > > The last line would tell StGIT not to do the rebasing and let git-pull > > handle it. > > It's actually my deliberate choice to subject myself to the pains of the > default configuration. I don't want to live in backwards compatible > environment until it rots away. I'll rather eat the dogfood we are > offering to others :) I don't consider this as a backward-compatibility feature. It simply targets a different workflow and it would be even better if we have it per-branch. The default should be the current fetch+rebase (as the most common case would be to use StGIT commands only) but with a warning if stack base fast-forwarding is not possible. -- Catalin ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: StGIT discards local commits on "stg pull" 2007-02-13 22:48 ` Catalin Marinas @ 2007-02-19 20:47 ` Yann Dirson 0 siblings, 0 replies; 12+ messages in thread From: Yann Dirson @ 2007-02-19 20:47 UTC (permalink / raw) To: Catalin Marinas; +Cc: Pavel Roskin, git On Tue, Feb 13, 2007 at 10:48:11PM +0000, Catalin Marinas wrote: > On 13/02/07, Pavel Roskin <proski@gnu.org> wrote: > >On Mon, 2007-02-12 at 09:31 +0000, Catalin Marinas wrote: > >> On 12/02/07, Pavel Roskin <proski@gnu.org> wrote: > > > >> > The example below shows that git-pull keeps my commit, but "stg pull" > >> > discards it by rebasing back to the remote ID. > >> > >> I think this is a "feature" but we should've probably leave the > >> original behaviour as the default. Maybe we should also have this > >> per-branch rather than per-repository. > > > >I don't know the original motivation behind effectively reimplementing > >"git pull" in StGIT, but it's clear that the StGIT's own implementation > >needs some polish. The primary motivation was to allow some sort of distributed handling of a stack. That is, I publish an stgit-managed branch, you "stg clone" it, you create your own patches on top of that, and when I refresh my stack, you can just "stg pull" it as you would do if my published work was a standard non-rewinding git branch. > >I think it's always wrong to lose local commits. I think StGIT should > >refuse to rebase if a merge would be needed Right, we should make it so losing local commits cannot be done by error. However, we cannot rely on the branch topology at the time we're rebasing. Consider those 2 use cases: - my stack forks off a non-rewinding branch, and I "stg commit" part of it, then "stg pull" - my stack forks off a rewinding branch, and I use "git fetch" to look at what's new upstream, then I decide it's a good time to rebase, and run "stg pull" (or preferably "stg rebase" to avoid fetching more recent commits by error) In the 2 cases "git pull" would do a merge. One crucial thing distinguishes the 2 cases, is that in the 1st case we have "manually" messed with the stack base. By "manually", I mean we changed the stack base by other means than pulling/rebasing, but this notion possibly needs some tuning. "stg commit" is an example, "stg uncommit" is another, and both would cause "git pull" to do a merge *because rebasing would not be what you want*, whereas in the rewinding-branch use-case *what you is precisely rebasing*. What we could do then, is having "rebase" and "pull" record an orig-base ref as a "backup copy" of the the new base, and first refuse to do the job (unless --force'd) if the base does not match its backup (that is, if the user used "commit" or "uncommit"). > >or the rebase would go back in history (in other words, if > >git-pull would not go to the remote revision). I'm less sure about the use-case you're trying to address here. Could you please give more details ? The only case I can think of would be that of a rewinding branch that would have been just that, rewinded, so it should be handled differently than when any new commit would exist on top of this ancestor commit. > >If we look at it from the user standpoint, the branches could be > >distinguished by the use model: > > > >1) Tracking branch: pull is OK, commit is not OK, push is not OK. All > >development is done in StGIT patches and sent to others. > > > >2) Development branch: commit is OK, push is OK, pull is OK but no > >merges by default. Right, those ones are probably the most used. > >3) Merge branch: pull is OK, even with automatic merge, commit is OK, > >merge is OK. This one I'm not sure to understand well. Could you please describe it in more details, perhaps in terms of the relation with other repos, and of the most distinctive local operations ? > I probably have another situation - a branch managed partially with > StGIT but GIT commits (or 'stg commit') used and pulling would lead to > a merge of the base, followed by patch pushing. This would work if we > use git-pull rather than git-fetch. You mean, a branch to which possibly several devs would commit (or to which you want to commit multiple topic branches yourself), and where you want to keep track of merges between these branches (as opposed to rebasing), while still using stgit locally ? > >> The solution would be to define the following in your gitconfig file > >> (either ~/.gitconfig or .git/config; a full example in StGIT's > >> examples/gitconfig): > >> > >> [stgit] > >> pullcmd = git-pull > >> pull-does-rebase = no > >> > >> The last line would tell StGIT not to do the rebasing and let git-pull > >> handle it. > > > >It's actually my deliberate choice to subject myself to the pains of the > >default configuration. I don't want to live in backwards compatible > >environment until it rots away. I'll rather eat the dogfood we are > >offering to others :) > > I don't consider this as a backward-compatibility feature. It simply > targets a different workflow and it would be even better if we have it > per-branch. The default should be the current fetch+rebase (as the > most common case would be to use StGIT commands only) but with a > warning if stack base fast-forwarding is not possible. One way to handle different workflows could be to define a particular workflow with a set of settings such as pullcmd and pull-does-rebase. That way, we could say eg. "stg branch --workflow=<id>" to set the vars in one run. Best regards, -- Yann. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2007-02-20 18:55 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-02-12 7:26 StGIT discards local commits on "stg pull" Pavel Roskin 2007-02-12 9:31 ` Catalin Marinas 2007-02-12 20:26 ` Yann Dirson 2007-02-12 21:47 ` Yann Dirson 2007-02-19 23:07 ` Catalin Marinas 2007-02-19 23:28 ` Pavel Roskin 2007-02-20 0:00 ` Yann Dirson 2007-02-20 18:55 ` Yann Dirson 2007-02-19 23:44 ` Yann Dirson 2007-02-13 0:20 ` Pavel Roskin 2007-02-13 22:48 ` Catalin Marinas 2007-02-19 20:47 ` Yann Dirson
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.