* Howto use StGit and git-svn at same time @ 2007-01-09 21:35 Guilhem Bonnefille 2007-01-09 21:41 ` Guilhem Bonnefille 0 siblings, 1 reply; 36+ messages in thread From: Guilhem Bonnefille @ 2007-01-09 21:35 UTC (permalink / raw) To: git Hi, I'm a newbie and I'm using: - git-svn to connect to a public SVN repo, - StGit to manage my patches for the project hosted by this repo. The current GIT repo was previously cloned from a GIT repo made with git-cvsimport. But the project moved to SVN, so I removed the GIT repo connected to the CVS. I succesfully fetch the SVN, create a "work" local branch (connected to remotes/trunk), and create some patches. As the SVN evolved, I wish to retrieve info and update my patches. So I tried a "stg pull" whihc failed because "origin" no more exists. So, I tried a "git-rebase remotes/trunk". Is it correct? I'm actually unable to conclude, as the maintainer apply my patches with some improves, so I have to solve lots of conflicts. But I would appreciate if you can confirm me that the git-rebase is the good way to update a "workspace" managed both by git-svn and StGit. -- Guilhem BONNEFILLE -=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com -=- mailto:guilhem.bonnefille@gmail.com -=- http://nathguil.free.fr/ ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Howto use StGit and git-svn at same time 2007-01-09 21:35 Howto use StGit and git-svn at same time Guilhem Bonnefille @ 2007-01-09 21:41 ` Guilhem Bonnefille 2007-01-09 22:41 ` Yann Dirson 0 siblings, 1 reply; 36+ messages in thread From: Guilhem Bonnefille @ 2007-01-09 21:41 UTC (permalink / raw) To: git Humh... I finished the conflicts solving game. I think the way I choosed is incorrect. Following gitk, it is now a big big bazaar in my commits history. Can you give me some tips about using both git-svn and stgit please? On 1/9/07, Guilhem Bonnefille <guilhem.bonnefille@gmail.com> wrote: > Hi, > > I'm a newbie and I'm using: > - git-svn to connect to a public SVN repo, > - StGit to manage my patches for the project hosted by this repo. > > The current GIT repo was previously cloned from a GIT repo made with > git-cvsimport. But the project moved to SVN, so I removed the GIT repo > connected to the CVS. > > I succesfully fetch the SVN, create a "work" local branch (connected > to remotes/trunk), and create some patches. > As the SVN evolved, I wish to retrieve info and update my patches. > > So I tried a "stg pull" whihc failed because "origin" no more exists. > So, I tried a "git-rebase remotes/trunk". > Is it correct? > > I'm actually unable to conclude, as the maintainer apply my patches > with some improves, so I have to solve lots of conflicts. But I would > appreciate if you can confirm me that the git-rebase is the good way > to update a "workspace" managed both by git-svn and StGit. > > -- > Guilhem BONNEFILLE > -=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com > -=- mailto:guilhem.bonnefille@gmail.com > -=- http://nathguil.free.fr/ > -- Guilhem BONNEFILLE -=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com -=- mailto:guilhem.bonnefille@gmail.com -=- http://nathguil.free.fr/ ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Howto use StGit and git-svn at same time 2007-01-09 21:41 ` Guilhem Bonnefille @ 2007-01-09 22:41 ` Yann Dirson 2007-01-15 13:26 ` Guilhem Bonnefille 0 siblings, 1 reply; 36+ messages in thread From: Yann Dirson @ 2007-01-09 22:41 UTC (permalink / raw) To: Guilhem Bonnefille; +Cc: git On Tue, Jan 09, 2007 at 10:41:20PM +0100, Guilhem Bonnefille wrote: > Humh... > I finished the conflicts solving game. I think the way I choosed is > incorrect. Following gitk, it is now a big big bazaar in my commits > history. Right, you should not use git-rebase on a StGIT branch :) What you should have done is moving your stack base from your old origin branch to remotes/trunk - something that StGIT does not support yet from command-line, but I've done this manually in the past (migrating an StGIT stack after re-running a full git-cvsimport after the original cvs branch got corrupted). Something along the line of (untested, off the top of my head): $ stg pop -a $ echo <TARGET-SHA1> > .git/refs/heads/<BRANCH> $ echo <TARGET-SHA1> > .git/refs/bases/<BRANCH> And then use "stg push" and "stg resolved -i" to resolve the conflicts. But always be sure of backing up your .git before doing such by-hand experiments. Best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Howto use StGit and git-svn at same time 2007-01-09 22:41 ` Yann Dirson @ 2007-01-15 13:26 ` Guilhem Bonnefille 2007-01-15 20:24 ` Rebasing stgit stacks Yann Dirson 0 siblings, 1 reply; 36+ messages in thread From: Guilhem Bonnefille @ 2007-01-15 13:26 UTC (permalink / raw) To: Yann Dirson; +Cc: git Ok, thanks for the reminder: I forgot "stg pop/push". I redo whole job as this: - git-svn -i trunk fetch - stg pop -a - git-rebase remotes/trunk # as recommended by git-svn manual - stg push -a - playing another merging game as my patches submissions were modified since archived Thanks. On 1/9/07, Yann Dirson <ydirson@altern.org> wrote: > On Tue, Jan 09, 2007 at 10:41:20PM +0100, Guilhem Bonnefille wrote: > > Humh... > > I finished the conflicts solving game. I think the way I choosed is > > incorrect. Following gitk, it is now a big big bazaar in my commits > > history. > > Right, you should not use git-rebase on a StGIT branch :) > > What you should have done is moving your stack base from your old > origin branch to remotes/trunk - something that StGIT does not support > yet from command-line, but I've done this manually in the past > (migrating an StGIT stack after re-running a full git-cvsimport after > the original cvs branch got corrupted). > > Something along the line of (untested, off the top of my head): > > $ stg pop -a > $ echo <TARGET-SHA1> > .git/refs/heads/<BRANCH> > $ echo <TARGET-SHA1> > .git/refs/bases/<BRANCH> > > And then use "stg push" and "stg resolved -i" to resolve the conflicts. > > But always be sure of backing up your .git before doing such by-hand > experiments. > > Best regards, > -- > Yann. > - > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Guilhem BONNEFILLE -=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com -=- mailto:guilhem.bonnefille@gmail.com -=- http://nathguil.free.fr/ ^ permalink raw reply [flat|nested] 36+ messages in thread
* Rebasing stgit stacks 2007-01-15 13:26 ` Guilhem Bonnefille @ 2007-01-15 20:24 ` Yann Dirson 2007-01-15 22:46 ` Catalin Marinas 0 siblings, 1 reply; 36+ messages in thread From: Yann Dirson @ 2007-01-15 20:24 UTC (permalink / raw) To: Catalin Marinas; +Cc: git, Guilhem Bonnefille On Mon, Jan 15, 2007 at 02:26:36PM +0100, Guilhem Bonnefille wrote: > >What you should have done is moving your stack base from your old > >origin branch to remotes/trunk - something that StGIT does not support > >yet from command-line, but I've done this manually in the past > >(migrating an StGIT stack after re-running a full git-cvsimport after > >the original cvs branch got corrupted). I have started work on implementing "stg pull --to <newbase>", but I'm facing some issues. "stg pull", after popping all patches, currently calls "git pull", which indeed has 2 roles: - running "git fetch" on the parent branch - updating the head of the stack (which matches the base since no patch is applied), by relying on git-pull to fast-forward the stack head The latter is, unless I miss something: - overkill when what we want is just to move the head to another place - problematic when the parent branch is one that would be tracker with "+" in the remote pull line (eg. "next", "pu", or an stgit stack). In that case, although "git fetch" refuses to update the parent head because it would not be a fast-forward, git-pull then attempt to do a merge, which completely breaks expectations. What my implementation of "pull --to" does is just moving the head with the following code added to git.py: def move_branch(tree_id): """Move HEAD to another commit """ __set_head(tree_id) switch(tree_id) if os.path.isfile(os.path.join(basedir.get(), 'MERGE_HEAD')): os.remove(os.path.join(basedir.get(), 'MERGE_HEAD')) That only partly works - that is, it works if I add the expected "+" in the remote refspec line (or if I add an explicit refspec on command-line). There is surely a way for "stg clone" to detect the parent is an stgit stack, and we can possibly have the clone operation setup things right from the start. I remember someone suggesting that such branches advertise their status so git-clone itself would add this - not sure this is planned for 1.5.0, though. Even when this fully works, I'm reluctant to leave things that way, because would be easy to forget the --to, and get a broken stack, with "stg diff" being confused enough to happily show this: |bar$ stg diff; echo $? |* Unmerged path file |0 I would be of the opinion to stop calling "git pull" entirely, and use "git fetch and the git.move_branch show above. Unless I hear about better ideas, my next patch set will be along those lines. Best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-15 20:24 ` Rebasing stgit stacks Yann Dirson @ 2007-01-15 22:46 ` Catalin Marinas 2007-01-15 23:39 ` Yann Dirson 0 siblings, 1 reply; 36+ messages in thread From: Catalin Marinas @ 2007-01-15 22:46 UTC (permalink / raw) To: Yann Dirson; +Cc: git, Guilhem Bonnefille On 15/01/07, Yann Dirson <ydirson@altern.org> wrote: > On Mon, Jan 15, 2007 at 02:26:36PM +0100, Guilhem Bonnefille wrote: > > >What you should have done is moving your stack base from your old > > >origin branch to remotes/trunk - something that StGIT does not support > > >yet from command-line, but I've done this manually in the past > > >(migrating an StGIT stack after re-running a full git-cvsimport after > > >the original cvs branch got corrupted). > > I have started work on implementing "stg pull --to <newbase>", but I'm > facing some issues. I think the combination of 'pull' and '--to' is confusing (at least to me) if you think of there English meaning. > "stg pull", after popping all patches, currently calls "git pull", > which indeed has 2 roles: > > - running "git fetch" on the parent branch > - updating the head of the stack (which matches the base since > no patch is applied), by relying on git-pull to fast-forward the > stack head As Petr suggested at the OLS last year, I added the possibility to configure the 'git pull' command so that people use whatever script they like. > The latter is, unless I miss something: > > - overkill when what we want is just to move the head to another place Doesn't git automatically detect that it can do a fast forward? A fetch is still necessary anyway. I'm not sure how people intend to use StGIT. Some might have their own changes to the base of the stack (maybe caused by 'stg commit') and would want 'git pull' to do a proper merge and not just fast-forward. I actually did the above when maintaining a public (well, ARM internal only currently) kernel branch for other people to pull from. Since StGIT is not public branch friendly, I was working on a set of patches (mainly picking from other branches and minor modifications) and just committing them when finishing. Further updates from kernel.org triggered full merges with the base. > - problematic when the parent branch is one that would be tracker with > "+" in the remote pull line (eg. "next", "pu", or an stgit stack). In > that case, although "git fetch" refuses to update the parent head > because it would not be a fast-forward, git-pull then attempt to do a > merge, which completely breaks expectations. Is there any way to configure git (via gitconfig) to behave differently? You can add some per-branch options with the parent to pull from but this would require separate .git/remotes/ files for each branch. > What my implementation of "pull --to" does is just moving the head > with the following code added to git.py: > > def move_branch(tree_id): > """Move HEAD to another commit > """ > __set_head(tree_id) > switch(tree_id) The switch() function already calls __set_head() > if os.path.isfile(os.path.join(basedir.get(), 'MERGE_HEAD')): > os.remove(os.path.join(basedir.get(), 'MERGE_HEAD')) When is the MERGE_HEAD file generated? Is there any harm in leaving this file? > I would be of the opinion to stop calling "git pull" entirely, and use > "git fetch and the git.move_branch show above. Unless I hear about > better ideas, my next patch set will be along those lines. Or replace the 'git pull' in the config file with 'git fetch && git reset --hard MERGE_HEAD'? I might be wrong though as I almost never use git directly :-). -- Catalin ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-15 22:46 ` Catalin Marinas @ 2007-01-15 23:39 ` Yann Dirson 2007-01-16 22:42 ` Catalin Marinas 2007-01-17 21:30 ` Yann Dirson 0 siblings, 2 replies; 36+ messages in thread From: Yann Dirson @ 2007-01-15 23:39 UTC (permalink / raw) To: Catalin Marinas; +Cc: git, Guilhem Bonnefille On Mon, Jan 15, 2007 at 10:46:37PM +0000, Catalin Marinas wrote: > >I have started work on implementing "stg pull --to <newbase>", but I'm > >facing some issues. > > I think the combination of 'pull' and '--to' is confusing (at least to > me) if you think of there English meaning. That's possible, I'm not a native english speater :) The idea is that we pull our stack from one place (current base) to another. Another possiblity would have been "stg rebase", but I'm not very keen on adding another command to do a very similar job. > > "stg pull", after popping all patches, currently calls "git pull", > > which indeed has 2 roles: > > > >- running "git fetch" on the parent branch > >- updating the head of the stack (which matches the base since > > no patch is applied), by relying on git-pull to fast-forward the > > stack head > > As Petr suggested at the OLS last year, I added the possibility to > configure the 'git pull' command so that people use whatever script > they like. Right. Maybe different workflows should have this option set to different values in different repos ? I'm merely trying to get the best default :) > >The latter is, unless I miss something: > > > >- overkill when what we want is just to move the head to another place > > Doesn't git automatically detect that it can do a fast forward? A > fetch is still necessary anyway. Yes, it detects it when it is one. The problem is merely that it can break things (for stgit's purpose) when it isn't. > I'm not sure how people intend to use StGIT. Some might have their own > changes to the base of the stack (maybe caused by 'stg commit') and > would want 'git pull' to do a proper merge and not just fast-forward. > > I actually did the above when maintaining a public (well, ARM internal > only currently) kernel branch for other people to pull from. Since > StGIT is not public branch friendly, Making StGIT public-branch friendly is indeed the primary goal for this set of patches - it is much less important to me to be able to base my stack on GIT's "pu" or "next". The idea is that, once we have are able to rebase a stack anyway, rebasing to the new tip of a branch that is an StGIT stack is in many aspects only a particular case (modulo any unapplied patches). > I was working on a set of patches (mainly picking from other > branches and minor modifications) and just committing them when > finishing. Further updates from kernel.org triggered full merges > with the base. But doing this means that you can end with a base that is not any more on the parent branch, but on a local merge, right ? I'm not sure it is an easy thing to work with. > >- problematic when the parent branch is one that would be tracker with > >"+" in the remote pull line (eg. "next", "pu", or an stgit stack). In > >that case, although "git fetch" refuses to update the parent head > >because it would not be a fast-forward, git-pull then attempt to do a > >merge, which completely breaks expectations. > > Is there any way to configure git (via gitconfig) to behave > differently? You can add some per-branch options with the parent to > pull from but this would require separate .git/remotes/ files for each > branch. I'm not sure there is anything currently. The solution which I remember was proposed was that such a branch "advertises" its status in some way, so that the creator of the remote.<name>.fetch config entry can indeed insert the "+" itself automatically. On the StGIT front, we could have "stg clone" look at patches/<branch>/current or so, and then modify the remote.<name>.fetch entry accordingly. Or do you think of any workflow that would break under this change ? > The switch() function already calls __set_head() Yup, noticed that when running the testsuite - I meant to run switch then reset instead. > > if os.path.isfile(os.path.join(basedir.get(), 'MERGE_HEAD')): > > os.remove(os.path.join(basedir.get(), 'MERGE_HEAD')) > > When is the MERGE_HEAD file generated? Is there any harm in leaving this > file? This is a leftover from sources of inspiration that create_branch and switch_branch were. I'm not 100% sure of why we want to get rid of it, but it looked like the situation was similar enough. It is apparently generated by git-merge (and git-resolve), and currently out of the scope of stgit anyway. If we're moving our stack, it is probable it will loose any sort of accurateness. Maybe instead we would want to block stgit operations if we see it, because there certainly have been (illegal ?) operations done outside of StGIT. > >I would be of the opinion to stop calling "git pull" entirely, and use > >"git fetch and the git.move_branch show above. Unless I hear about > >better ideas, my next patch set will be along those lines. > > Or replace the 'git pull' in the config file with 'git fetch && git > reset --hard MERGE_HEAD'? I might be wrong though as I almost never > use git directly :-). Hm. Probably rather FETCH_HEAD. Will have to look at that - but see above. FWIW, I now mostly have a patch to change from git-pull to git-fetch, which finally passes the current testsuite. Note that I did not think of using FETCH_HEAD, I was rather thinking of using information about the parent branch (which I had worked on recently), with the idea that this info probably belongs to branch.<name>.merge - which would complement Pavel's 87c69539 about branch.<name>.remote. Even if we would not need it here, it would be good to have those 2 parameters set when we can infer them. That reminds me that "stg clone" does not appear to allow selecting a specific branch in the parent repo (which explains why the .merge parameter is not so crucially needed yet: we always clone the main branch). Best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-15 23:39 ` Yann Dirson @ 2007-01-16 22:42 ` Catalin Marinas 2007-01-16 23:17 ` Yann Dirson 2007-01-17 21:30 ` Yann Dirson 1 sibling, 1 reply; 36+ messages in thread From: Catalin Marinas @ 2007-01-16 22:42 UTC (permalink / raw) To: Yann Dirson; +Cc: git, Guilhem Bonnefille On 15/01/07, Yann Dirson <ydirson@altern.org> wrote: > On Mon, Jan 15, 2007 at 10:46:37PM +0000, Catalin Marinas wrote: > > >I have started work on implementing "stg pull --to <newbase>", but I'm > > >facing some issues. > > > > I think the combination of 'pull' and '--to' is confusing (at least to > > me) if you think of there English meaning. > > That's possible, I'm not a native english speater :) I'm not either :-) > The idea is that we pull our stack from one place (current base) to > another. Another possiblity would have been "stg rebase", but I'm not > very keen on adding another command to do a very similar job. Can you give a typical example of what <newbase> argument for --to is and what you repository looks like? I just want make sure I correctly understand the problem. I see the 'pull' command as a way to fetch the latest remote changes and merge them into the current branch (which would usually be a fast-forward). This command was meant as a stgit-aware 'git pull'. > > As Petr suggested at the OLS last year, I added the possibility to > > configure the 'git pull' command so that people use whatever script > > they like. > > Right. Maybe different workflows should have this option set to > different values in different repos ? I'm merely trying to get the > best default :) But you want to replace the call to 'git pull' with 'git fetch'. I think this is fine with my workflow but some people might actually rely on calling 'git pull' (or cg-pull). > > I was working on a set of patches (mainly picking from other > > branches and minor modifications) and just committing them when > > finishing. Further updates from kernel.org triggered full merges > > with the base. > > But doing this means that you can end with a base that is not any more > on the parent branch, but on a local merge, right ? I'm not sure it > is an easy thing to work with. Yes, indeed, but this is probably the only way you can publish a branch and still partially manage it with StGIT. > On the StGIT front, we could have "stg clone" look at > patches/<branch>/current or so, and then modify the > remote.<name>.fetch entry accordingly. Or do you think of any > workflow that would break under this change ? Currently, 'stg clone' just calls 'git clone' and initializes the master branch. There is no patches/<branch>/current file as there is no current patch. > Even if we would not need it here, it would be good to have those 2 > parameters set when we can infer them. That reminds me that "stg > clone" does not appear to allow selecting a specific branch in the > parent repo (which explains why the .merge parameter is not so > crucially needed yet: we always clone the main branch). I haven't looked at 'git clone' recently, can you select a specific branch? -- Catalin ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-16 22:42 ` Catalin Marinas @ 2007-01-16 23:17 ` Yann Dirson 2007-01-16 23:30 ` Jakub Narebski 2007-01-18 9:05 ` Catalin Marinas 0 siblings, 2 replies; 36+ messages in thread From: Yann Dirson @ 2007-01-16 23:17 UTC (permalink / raw) To: Catalin Marinas; +Cc: git, Guilhem Bonnefille On Tue, Jan 16, 2007 at 10:42:17PM +0000, Catalin Marinas wrote: > >The idea is that we pull our stack from one place (current base) to > >another. Another possiblity would have been "stg rebase", but I'm not > >very keen on adding another command to do a very similar job. > > Can you give a typical example of what <newbase> argument for --to is > and what you repository looks like? I just want make sure I correctly > understand the problem. My example is quite similar to the one given by Guilhem: I had a git branch coming from git-cvsimport, and my stgit stack forked atop that branch. At some point git-cvsimport fucked something, and I regenerated a new mirror branch using it in a fresh repo. Then I wanted to rebase my stack on that new branch. > I see the 'pull' command as a way to fetch the latest remote changes > and merge them into the current branch (which would usually be a > fast-forward). This command was meant as a stgit-aware 'git pull'. Do you have an example of use where we would need a non-fast-forward pull (supposing we have the "pull --to" functionality already, since I shall find time to finish soon). > >> As Petr suggested at the OLS last year, I added the possibility to > >> configure the 'git pull' command so that people use whatever script > >> they like. > > > >Right. Maybe different workflows should have this option set to > >different values in different repos ? I'm merely trying to get the > >best default :) > > But you want to replace the call to 'git pull' with 'git fetch'. I > think this is fine with my workflow but some people might actually > rely on calling 'git pull' (or cg-pull). Right, it may be possible (and I'd be interested in seeing such a workflow). Maybe we could keep support for git-pull as an alternative. This could be done, eg. by letting the user use "pullcmd=git-pull" and introduce a new option like "fastforward=<bool>" triggering the fast-forward needed after git-fetch, with the default being "true", and the current behaviour being obtained by changing it to "false". That would not add too much complexity, while setting the default to what I believe to match the most common workflows, and allow anyone relying on the current behaviour to get it back. > >> I was working on a set of patches (mainly picking from other > >> branches and minor modifications) and just committing them when > >> finishing. Further updates from kernel.org triggered full merges > >> with the base. > > > >But doing this means that you can end with a base that is not any more > >on the parent branch, but on a local merge, right ? I'm not sure it > >is an easy thing to work with. > > Yes, indeed, but this is probably the only way you can publish a > branch and still partially manage it with StGIT. Well, I'd think that automatic rebasing would be a more elegant solution. > >On the StGIT front, we could have "stg clone" look at > >patches/<branch>/current or so, and then modify the > >remote.<name>.fetch entry accordingly. Or do you think of any > >workflow that would break under this change ? > > Currently, 'stg clone' just calls 'git clone' and initializes the > master branch. There is no patches/<branch>/current file as there is > no current patch. I meant, the patches/<branch>/current in the remote repo. If that one exist, then we should pull it with "+" as we should do for any rebasing remote branch. > >Even if we would not need it here, it would be good to have those 2 > >parameters set when we can infer them. That reminds me that "stg > >clone" does not appear to allow selecting a specific branch in the > >parent repo (which explains why the .merge parameter is not so > >crucially needed yet: we always clone the main branch). > > I haven't looked at 'git clone' recently, can you select a specific branch? I had assumed so without looking, but it looks like you cannot select much. When using separate remotes, the HEAD in the clone is taken from the HEAD in the remote, and bears the same name. It is the only ref created under heads/. Would there be some missing functionnality in git-clone, or am I just missing something obvious ? Best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-16 23:17 ` Yann Dirson @ 2007-01-16 23:30 ` Jakub Narebski 2007-01-17 9:03 ` Karl Hasselström 2007-01-17 20:53 ` Yann Dirson 2007-01-18 9:05 ` Catalin Marinas 1 sibling, 2 replies; 36+ messages in thread From: Jakub Narebski @ 2007-01-16 23:30 UTC (permalink / raw) To: git Yann Dirson wrote: > On Tue, Jan 16, 2007 at 10:42:17PM +0000, Catalin Marinas wrote: >>>The idea is that we pull our stack from one place (current base) to >>>another. Another possiblity would have been "stg rebase", but I'm not >>>very keen on adding another command to do a very similar job. >> >> Can you give a typical example of what <newbase> argument for --to is >> and what you repository looks like? I just want make sure I correctly >> understand the problem. > > My example is quite similar to the one given by Guilhem: I had a git > branch coming from git-cvsimport, and my stgit stack forked atop that > branch. At some point git-cvsimport fucked something, and I > regenerated a new mirror branch using it in a fresh repo. Then I > wanted to rebase my stack on that new branch. I'm all for calling this command "stg rebase". Currently you can do "stg push -a; stg commit -a; git rebase; stg uncommit -n <n>"... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-16 23:30 ` Jakub Narebski @ 2007-01-17 9:03 ` Karl Hasselström 2007-01-17 11:07 ` David Kågedal 2007-01-17 19:34 ` Yann Dirson 2007-01-17 20:53 ` Yann Dirson 1 sibling, 2 replies; 36+ messages in thread From: Karl Hasselström @ 2007-01-17 9:03 UTC (permalink / raw) To: Jakub Narebski; +Cc: git On 2007-01-17 00:30:18 +0100, Jakub Narebski wrote: > Yann Dirson wrote: > > > My example is quite similar to the one given by Guilhem: I had a > > git branch coming from git-cvsimport, and my stgit stack forked > > atop that branch. At some point git-cvsimport fucked something, > > and I regenerated a new mirror branch using it in a fresh repo. > > Then I wanted to rebase my stack on that new branch. > > I'm all for calling this command "stg rebase". Currently you can do > "stg push -a; stg commit -a; git rebase; stg uncommit -n <n>"... Or simpler, stg pop -a git reset --hard <new_base> stg push -n <n> This uses stgit for all operations that can conflict. (BTW, I've never seriously tried git rebase; does anyone have an opinion of how convenient its conflict handling is, compared to stgit's?) -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-17 9:03 ` Karl Hasselström @ 2007-01-17 11:07 ` David Kågedal 2007-01-17 19:34 ` Yann Dirson 1 sibling, 0 replies; 36+ messages in thread From: David Kågedal @ 2007-01-17 11:07 UTC (permalink / raw) To: git Karl Hasselström <kha@treskal.com> writes: > On 2007-01-17 00:30:18 +0100, Jakub Narebski wrote: > >> Yann Dirson wrote: >> >> > My example is quite similar to the one given by Guilhem: I had a >> > git branch coming from git-cvsimport, and my stgit stack forked >> > atop that branch. At some point git-cvsimport fucked something, >> > and I regenerated a new mirror branch using it in a fresh repo. >> > Then I wanted to rebase my stack on that new branch. >> >> I'm all for calling this command "stg rebase". Currently you can do >> "stg push -a; stg commit -a; git rebase; stg uncommit -n <n>"... > > Or simpler, > > stg pop -a > git reset --hard <new_base> > stg push -n <n> > > This uses stgit for all operations that can conflict. > > (BTW, I've never seriously tried git rebase; does anyone have an > opinion of how convenient its conflict handling is, compared to > stgit's?) I have used it a little (together with git-svn), and one thing that confused me was that when I got a conflict to resolve, it looked like this: ... <<<<<< base version ====== my version >>>>>> ... Where "my version" is the code in the branch I'm rebasing, and "base version" is the code in the branch I'm rebasing on. This is kind of opposite of how e.g. "git pull" works, where the first alternative is "my version". I guess it is an effect of the fact that you are actually merging your branch into another, instead of the other way around. -- David Kågedal ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-17 9:03 ` Karl Hasselström 2007-01-17 11:07 ` David Kågedal @ 2007-01-17 19:34 ` Yann Dirson 1 sibling, 0 replies; 36+ messages in thread From: Yann Dirson @ 2007-01-17 19:34 UTC (permalink / raw) To: Karl Hasselström; +Cc: Jakub Narebski, git On Wed, Jan 17, 2007 at 10:03:13AM +0100, Karl Hasselström wrote: > (BTW, I've never seriously tried git rebase; does anyone have an > opinion of how convenient its conflict handling is, compared to > stgit's?) When I was using it, it was much less convenient than stgit - required to forge a git-am command-line to continue after a conflict (--continue was added in April '06 - I had switched to StGIT before implementing it myself ;). My evaluation at that point was that it required too much understanding of the plumbing issues to be shown to a newbie - a problem which StGIT does not have. But I have not used it any more since then, and did not follow any improvements in this field. StGIT features like "push --undo" also make it much easier to delay merge of a given patch, and stack handling makes it easier to continue your work after a night-break. Not to mention all goodies like patch reordering. Best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-16 23:30 ` Jakub Narebski 2007-01-17 9:03 ` Karl Hasselström @ 2007-01-17 20:53 ` Yann Dirson 2007-01-18 12:06 ` Catalin Marinas 2007-01-19 9:40 ` Jakub Narebski 1 sibling, 2 replies; 36+ messages in thread From: Yann Dirson @ 2007-01-17 20:53 UTC (permalink / raw) To: Jakub Narebski; +Cc: git On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote: > I'm all for calling this command "stg rebase". After all, my current implementation as "pull --to" mostly bypasses the fetch, so it probably makes sense to use a new command. However, "stg rebase <target>" does not sound right. I'm not very happy with "stg rebaseto <target>" (or rebase-to) either. "stg rebase --to <target>" may feel strange too (command without non-option arg), but may finally a good choice after all ? What do others think ? Best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-17 20:53 ` Yann Dirson @ 2007-01-18 12:06 ` Catalin Marinas 2007-01-18 19:42 ` Yann Dirson 2007-01-19 9:40 ` Jakub Narebski 1 sibling, 1 reply; 36+ messages in thread From: Catalin Marinas @ 2007-01-18 12:06 UTC (permalink / raw) To: Yann Dirson; +Cc: Jakub Narebski, git Yann Dirson <ydirson@altern.org> wrote: > On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote: >> I'm all for calling this command "stg rebase". > > After all, my current implementation as "pull --to" mostly bypasses > the fetch, so it probably makes sense to use a new command. > > However, "stg rebase <target>" does not sound right. I'm not very > happy with "stg rebaseto <target>" (or rebase-to) either. I think something 'stg rebase <newbase>' sounds OK. -- Catalin ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-18 12:06 ` Catalin Marinas @ 2007-01-18 19:42 ` Yann Dirson 0 siblings, 0 replies; 36+ messages in thread From: Yann Dirson @ 2007-01-18 19:42 UTC (permalink / raw) To: Catalin Marinas; +Cc: Jakub Narebski, git On Thu, Jan 18, 2007 at 12:06:20PM +0000, Catalin Marinas wrote: > Yann Dirson <ydirson@altern.org> wrote: > > On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote: > >> I'm all for calling this command "stg rebase". > > > > After all, my current implementation as "pull --to" mostly bypasses > > the fetch, so it probably makes sense to use a new command. > > > > However, "stg rebase <target>" does not sound right. I'm not very > > happy with "stg rebaseto <target>" (or rebase-to) either. > > I think something 'stg rebase <newbase>' sounds OK. It's just that it sounds more natural to me to give as instruction "do rebase (current stack) to that point" than "do rebase that point", which "rebase <newbase>" would seem to imply. Best reagards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-17 20:53 ` Yann Dirson 2007-01-18 12:06 ` Catalin Marinas @ 2007-01-19 9:40 ` Jakub Narebski 2007-01-20 13:17 ` Yann Dirson 1 sibling, 1 reply; 36+ messages in thread From: Jakub Narebski @ 2007-01-19 9:40 UTC (permalink / raw) To: Yann Dirson; +Cc: git On Wed, Jan 17, 2007 Yann Dirson wrote: > On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote: >> I'm all for calling this command "stg rebase". > > After all, my current implementation as "pull --to" mostly bypasses > the fetch, so it probably makes sense to use a new command. > > However, "stg rebase <target>" does not sound right. I'm not very > happy with "stg rebaseto <target>" (or rebase-to) either. > "stg rebase --to <target>" may feel strange too (command without > non-option arg), but may finally a good choice after all ? What do > others think ? First, "stg rebase" when on some git branch might mean rebase StGIT stack to head of current branch (because there were some git commits on top of this branch). So it would be "stg rebase [--onto <target>]"; it would be command without non-option arg, but this arg would be optional. Second, if you were to implement separating commands into subcommands (perhaps just as alternative names) depending on what they act on: "stg stack <subcommand>", "stg patch <subcommand>" etc., this would I think belong to "stg base <subcommand>". -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-19 9:40 ` Jakub Narebski @ 2007-01-20 13:17 ` Yann Dirson 2007-01-20 19:16 ` Jakub Narebski 0 siblings, 1 reply; 36+ messages in thread From: Yann Dirson @ 2007-01-20 13:17 UTC (permalink / raw) To: Jakub Narebski; +Cc: git On Fri, Jan 19, 2007 at 10:40:16AM +0100, Jakub Narebski wrote: > First, "stg rebase" when on some git branch might mean rebase StGIT > stack to head of current branch (because there were some git commits > on top of this branch). So it would be "stg rebase [--onto <target>]"; > it would be command without non-option arg, but this arg would be > optional. I'm not sure I understand. Since the "current StGIT stack" is the one pointed to by HEAD, how do you specify, when HEAD points to the target branch, which stack to rebase ? > Second, if you were to implement separating commands into subcommands > (perhaps just as alternative names) depending on what they act on: > "stg stack <subcommand>", "stg patch <subcommand>" etc., this would > I think belong to "stg base <subcommand>". Hm, the operation is not just about moving the stack base, it also has to reapply patches, so, whereas the central concept is about moving the base, the whole operation is indeed about the rebaseing the whole stack. I'm not sure we need to expose the "stack base" to the user as an object she could manipulate all alone, I'd rather think it should only be kept a read-only attribute of the stack, which gets changed when the user rebases the stack. IOW, the conceptual base object is private to the stack object, (it is indeed just a simple text attribute) and only stack methods are allowed to call base.move(), when they have ensured it can be done safely (ie. popping all patches first). Best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-20 13:17 ` Yann Dirson @ 2007-01-20 19:16 ` Jakub Narebski 2007-01-20 20:07 ` Yann Dirson 2007-01-22 23:12 ` Catalin Marinas 0 siblings, 2 replies; 36+ messages in thread From: Jakub Narebski @ 2007-01-20 19:16 UTC (permalink / raw) To: Yann Dirson, Catalin Marinas; +Cc: git Yann Dirson wrote: > On Fri, Jan 19, 2007 at 10:40:16AM +0100, Jakub Narebski wrote: >> First, "stg rebase" when on some git branch might mean rebase StGIT >> stack to head of current branch (because there were some git commits >> on top of this branch). So it would be "stg rebase [--onto <target>]"; >> it would be command without non-option arg, but this arg would be >> optional. > > I'm not sure I understand. Since the "current StGIT stack" is the one > pointed to by HEAD, how do you specify, when HEAD points to the target > branch, which stack to rebase ? Well, I haven't thought this through. I was thinking about situation where there are no applied patches, and some commits were done without StGIT (pure git), i.e. we had ..1...2...3 <-- unapplied (deck) [ branch ] / a---b---c---d <-- HEAD [ branch ] There were some git commits (for example fetch, or cherry-pick, or ...) ..1...2...3 <-- unapplied (deck) [ branch ] / a---b---c---d---e---f <-- HEAD [ branch ] And after "stg rebase" I want to have: ..1...2...3 <-- unapplied (deck) [ branch ] / a---b---c---d---e---f <-- HEAD [ branch ] I'm not sure how should the above work with applied patches (non-empty stack), i.e. with the following: ..3...4...5 <-- unapplied (deck) [ branch ] / a---b---c---d-.-1-.-2 <-- HEAD [ branch ] \--v--/ (stack) Or for example git branch got rebased, and I want to move also deck (unapplied patches), because "git rebase" don't move them... unless this is not needed. Probably it is not needed. -- Jakub Narebski Poland ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-20 19:16 ` Jakub Narebski @ 2007-01-20 20:07 ` Yann Dirson 2007-01-22 23:12 ` Catalin Marinas 1 sibling, 0 replies; 36+ messages in thread From: Yann Dirson @ 2007-01-20 20:07 UTC (permalink / raw) To: Jakub Narebski; +Cc: Catalin Marinas, git On Sat, Jan 20, 2007 at 08:16:15PM +0100, Jakub Narebski wrote: > Yann Dirson wrote: > > On Fri, Jan 19, 2007 at 10:40:16AM +0100, Jakub Narebski wrote: > > >> First, "stg rebase" when on some git branch might mean rebase StGIT > >> stack to head of current branch (because there were some git commits > >> on top of this branch). So it would be "stg rebase [--onto <target>]"; > >> it would be command without non-option arg, but this arg would be > >> optional. > > > > I'm not sure I understand. Since the "current StGIT stack" is the one > > pointed to by HEAD, how do you specify, when HEAD points to the target > > branch, which stack to rebase ? > > Well, I haven't thought this through. I was thinking about situation > where there are no applied patches, and some commits were done without > StGIT (pure git), i.e. we had > > ..1...2...3 <-- unapplied (deck) [ branch ] > / > a---b---c---d <-- HEAD [ branch ] > > There were some git commits (for example fetch, or cherry-pick, or ...) > > > ..1...2...3 <-- unapplied (deck) [ branch ] > / > a---b---c---d---e---f <-- HEAD [ branch ] > > And after "stg rebase" I want to have: > > > ..1...2...3 <-- unapplied (deck) [ branch ] > / > a---b---c---d---e---f <-- HEAD [ branch ] So this what we typically currently get by using "stg pull . branchname", when HEAD is the stack branch. I can easily see that called as "stg rebase", with --to argument defaulting to parent branch (as given by branch.<name>.merge) when the HEAD is the stack branch. That would be a neat replacement for "stg pull . <name>". Calling 'stg rebase' from the branch to rebase onto, however, can't guess which stack to rebase - there are possibly many stacks forked off your branch. In that case, you will need to ask "stg rebase <mystack>". But this will mean that "stg rebase <mystack>" will have --to default to HEAD, whereas "stg rebase" will have --to default to the stack's parent branch. Not sure, but that looks a bit inconsistent, and may be confusing. But probably we can implement things this way, and wait for the user feedback to see if some restructuration is called, post-1.0, when we move to subcommands. > I'm not sure how should the above work with applied patches > (non-empty stack), i.e. with the following: > > ..3...4...5 <-- unapplied (deck) [ branch ] > / > a---b---c---d-.-1-.-2 <-- HEAD [ branch ] > \--v--/ > > (stack) As long as commits occured as children of 'd', 'rebase' will take care of applied patches (it pops all patches first). > Or for example git branch got rebased, and I want to move also deck > (unapplied patches), because "git rebase" don't move them... unless > this is not needed. Probably it is not needed. This is a typical ouse for "stg rebase", it should just work. Best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-20 19:16 ` Jakub Narebski 2007-01-20 20:07 ` Yann Dirson @ 2007-01-22 23:12 ` Catalin Marinas 1 sibling, 0 replies; 36+ messages in thread From: Catalin Marinas @ 2007-01-22 23:12 UTC (permalink / raw) To: Jakub Narebski; +Cc: Yann Dirson, git On 20/01/07, Jakub Narebski <jnareb@gmail.com> wrote: > Well, I haven't thought this through. I was thinking about situation > where there are no applied patches, and some commits were done without > StGIT (pure git), i.e. we had > > ..1...2...3 <-- unapplied (deck) [ branch ] > / > a---b---c---d <-- HEAD [ branch ] > > There were some git commits (for example fetch, or cherry-pick, or ...) > > > ..1...2...3 <-- unapplied (deck) [ branch ] > / > a---b---c---d---e---f <-- HEAD [ branch ] > > And after "stg rebase" I want to have: > > > ..1...2...3 <-- unapplied (deck) [ branch ] > / > a---b---c---d---e---f <-- HEAD [ branch ] StGIT currently doesn't care whether the base of an empty stack has changed. To get to the above graph, just use "stg push 1..3" and "stg pop 1..3". The unapplied patches may be disconnected from the current graph and StGIT doesn't care about them until pushed (applied) on top of the stack when they become part of the linear history graph. I'm not good at ASCII graphics to show an example but, for example, as long as they are unapplied, 1 above can have b as a parent and 2 can have e as a parent (it all depends on when they were last pushed). -- Catalin ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-16 23:17 ` Yann Dirson 2007-01-16 23:30 ` Jakub Narebski @ 2007-01-18 9:05 ` Catalin Marinas 2007-01-18 20:52 ` Yann Dirson 1 sibling, 1 reply; 36+ messages in thread From: Catalin Marinas @ 2007-01-18 9:05 UTC (permalink / raw) To: Yann Dirson; +Cc: git, Guilhem Bonnefille On 16/01/07, Yann Dirson <ydirson@altern.org> wrote: > My example is quite similar to the one given by Guilhem: I had a git > branch coming from git-cvsimport, and my stgit stack forked atop that > branch. At some point git-cvsimport fucked something, and I > regenerated a new mirror branch using it in a fresh repo. Then I > wanted to rebase my stack on that new branch. As Jakub said, I would also call this command 'rebase' instead of 'pull --to', even if we duplicate a bit of code. It would make the implementation even simpler as you won't break other people's workflows using git-pull or cg-pull. The main feature of the 'pull' command is to fetch the latest changes from a remote repository and merge (fast-forward) them into current base. > > But you want to replace the call to 'git pull' with 'git fetch'. I > > think this is fine with my workflow but some people might actually > > rely on calling 'git pull' (or cg-pull). > > Right, it may be possible (and I'd be interested in seeing such a > workflow). Maybe we could keep support for git-pull as an > alternative. As I said, I use this myself on an exported branch. > This could be done, eg. by letting the user use "pullcmd=git-pull" and > introduce a new option like "fastforward=<bool>" triggering the > fast-forward needed after git-fetch, with the default being "true", > and the current behaviour being obtained by changing it to "false". But isn't this too complicated when all you need is a 'rebase'-like command? > That would not add too much complexity, while setting the default to > what I believe to match the most common workflows, and allow anyone > relying on the current behaviour to get it back. The problem is that I may use different workflows in the same repository (but on different branches). Any new config options would have to be per branch. -- Catalin ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-18 9:05 ` Catalin Marinas @ 2007-01-18 20:52 ` Yann Dirson 2007-01-19 9:47 ` Jakub Narebski 0 siblings, 1 reply; 36+ messages in thread From: Yann Dirson @ 2007-01-18 20:52 UTC (permalink / raw) To: Catalin Marinas; +Cc: git, Guilhem Bonnefille On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote: > But isn't this too complicated when all you need is a 'rebase'-like command? Well, I realize that I was not very clear in all this stuff. There are indeed 3 things I'm working on, but which are closely related to each other. One is rebasing to an arbitrary point; the second is forking an stgit stack out of another (possibly remote) stgit stack; the third is that having "stg pull" use git-pull results for my workflow in a purely broken situation. Since the 2nd is merely "git-fetch then rebase to new head of remote", and the 3rd is 100% fixed for me by using git-fetch instead of git-pull, I tend to somewhat mix all those concepts and that surely shows in my mails. That said, let me try to detangle all this :) > On 16/01/07, Yann Dirson <ydirson@altern.org> wrote: > >My example is quite similar to the one given by Guilhem: I had a git > >branch coming from git-cvsimport, and my stgit stack forked atop that > >branch. At some point git-cvsimport fucked something, and I > >regenerated a new mirror branch using it in a fresh repo. Then I > >wanted to rebase my stack on that new branch. > > As Jakub said, I would also call this command 'rebase' instead of > 'pull --to', even if we duplicate a bit of code. > It would make the implementation even simpler A new command is fine with me, it's just that I feel "rebase <target>" may be confusing to beginners. I'd rather say "rebase [<stack>] --to <target>", but it's just that I don't see the case for specifying a different stack than the current one. > as you won't break other people's workflows using git-pull or > cg-pull. The main feature of the 'pull' command is to fetch the > latest changes from a remote repository and merge (fast-forward) > them into current base. However, this relates to the 2nd and 3rd items in my list, sorry to have brought confusion here. > >> But you want to replace the call to 'git pull' with 'git fetch'. I > >> think this is fine with my workflow but some people might actually > >> rely on calling 'git pull' (or cg-pull). > > > >Right, it may be possible (and I'd be interested in seeing such a > >workflow). Maybe we could keep support for git-pull as an > >alternative. > > As I said, I use this myself on an exported branch. I've heard that, but I had understood that you used this because there was nothing better available now, and that my second item (forking off a public stgit-managed branch) would address your needs. If not, I may have missed something. > >This could be done, eg. by letting the user use "pullcmd=git-pull" and > >introduce a new option like "fastforward=<bool>" triggering the > >fast-forward needed after git-fetch, with the default being "true", > >and the current behaviour being obtained by changing it to "false". > > >That would not add too much complexity, while setting the default to > >what I believe to match the most common workflows, and allow anyone > >relying on the current behaviour to get it back. > > The problem is that I may use different workflows in the same > repository (but on different branches). Any new config options would > have to be per branch. That can be a serious point. But I fear we would start to seriously over-enginneer things here - unless the workflows that really require the current behaviour are really widespread (again this assume I've correctly understood yours), wouldn't it be better to require the user to use one workflow per checkout, at least until such workflows are explicited so we can support them at best ? BTW, I have started a couple of weeks ago to write things about patch management and associated workflows in the GIT wiki [1]. This has a wider scope than just StGIT, and I have not finished to write down everything I wanted to, but that could be a place to start from. Especially, I only listed a couple of workflows without extended description, and it would be great to have a page for each, with several ways to put them in action, with different sets of tools. [1] http://git.or.cz/gitwiki/PatchManagement Best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-18 20:52 ` Yann Dirson @ 2007-01-19 9:47 ` Jakub Narebski 2007-01-22 17:54 ` Catalin Marinas 0 siblings, 1 reply; 36+ messages in thread From: Jakub Narebski @ 2007-01-19 9:47 UTC (permalink / raw) To: git Yann Dirson wrote: > On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote: >> As Jakub said, I would also call this command 'rebase' instead of >> 'pull --to', even if we duplicate a bit of code. >> It would make the implementation even simpler > > A new command is fine with me, it's just that I feel "rebase <target>" > may be confusing to beginners. I'd rather say "rebase [<stack>] --to > <target>", but it's just that I don't see the case for specifying a > different stack than the current one. If you want to move some stack from one branch to other, for example from 'next' or next-based branch to 'origin'/'master' or origin-based branch you could do either: $ git checkout <newbase> $ stg rebase <stack> or $ git checkout <oldbase> $ stg rebase --onto <newbase> (or even "stg rebase <stack> --onto <newbase>" or "stg rebase --onto <newbase> <stack>"). Although usually you have separate branch as StGIT stack "base", and you can simply rebase git branch, then do $ stg rebase -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-19 9:47 ` Jakub Narebski @ 2007-01-22 17:54 ` Catalin Marinas 2007-01-22 19:47 ` Yann Dirson 0 siblings, 1 reply; 36+ messages in thread From: Catalin Marinas @ 2007-01-22 17:54 UTC (permalink / raw) To: Jakub Narebski; +Cc: git Jakub Narebski <jnareb@gmail.com> wrote: > Yann Dirson wrote: >> On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote: > >>> As Jakub said, I would also call this command 'rebase' instead of >>> 'pull --to', even if we duplicate a bit of code. >>> It would make the implementation even simpler >> >> A new command is fine with me, it's just that I feel "rebase <target>" >> may be confusing to beginners. I'd rather say "rebase [<stack>] --to >> <target>", but it's just that I don't see the case for specifying a >> different stack than the current one. > > If you want to move some stack from one branch to other, for example > from 'next' or next-based branch to 'origin'/'master' or origin-based > branch you could do either: > > $ git checkout <newbase> > $ stg rebase <stack> Currently, in the StGIT terminology stack and branch are about the same. If you want to move to a different stack, just use the "stg branch" command. I think this should stay as it is since it gets confusing to have a name for a stack and a different name for a branch. A stack is just a branch with stgit-specific metadata. If <newbase> is a branch and 'git checkout' causing to switch branches, you end up on a different stack. What you'd probably want is a way to import patches from a different branch/stack onto the newly checked out branch. > Although usually you have separate branch as StGIT stack "base", and > you can simply rebase git branch, then do > > $ stg rebase I only see the 'rebase' command as a shortcut for: stg pop -a git reset --hard <newbase> stg push -a (or just push the previously popped patches) -- Catalin P.S. could you cc me to your replies as I only read the GIT mailing list via gmane and only when I'm at work (and usually work on StGIT at home) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-22 17:54 ` Catalin Marinas @ 2007-01-22 19:47 ` Yann Dirson 2007-01-22 22:58 ` Catalin Marinas 0 siblings, 1 reply; 36+ messages in thread From: Yann Dirson @ 2007-01-22 19:47 UTC (permalink / raw) To: Catalin Marinas; +Cc: Jakub Narebski, git On Mon, Jan 22, 2007 at 05:54:29PM +0000, Catalin Marinas wrote: > Jakub Narebski <jnareb@gmail.com> wrote: > > Yann Dirson wrote: > >> On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote: > > > >>> As Jakub said, I would also call this command 'rebase' instead of > >>> 'pull --to', even if we duplicate a bit of code. > >>> It would make the implementation even simpler > >> > >> A new command is fine with me, it's just that I feel "rebase <target>" > >> may be confusing to beginners. I'd rather say "rebase [<stack>] --to > >> <target>", but it's just that I don't see the case for specifying a > >> different stack than the current one. > > > > If you want to move some stack from one branch to other, for example > > from 'next' or next-based branch to 'origin'/'master' or origin-based > > branch you could do either: > > > > $ git checkout <newbase> > > $ stg rebase <stack> > > Currently, in the StGIT terminology stack and branch are about the > same. If you want to move to a different stack, just use the "stg > branch" command. I think you missed the point. StGIT stacks are usually forked off another branch. As I understand it, Jakub talks about standard rebasing, ie. moving the stack base from its current parent branch to a new one. > A stack is just a branch with stgit-specific metadata. I would rather say that an StGIT stacks uses a branch, but the stack is not the branch - eg, unapplied patches do not belong to the branch. Indeed I was thinking about that today, and thought that maybe it would make sense not to use a head ref (and thus not using a real branch), which would minimize the risk of someone committing by error (and thus minimize the need to use "assimilate"), since porcelainish commit tools would then refuse to commit there. > What you'd probably want is a way to import patches from a different > branch/stack onto the newly checked out branch. Sometimes you just want to throw out an obsolete branch and move your stack to a new baseline. That said, being able to duplicate a stack (and possibly rebasing it afterwards) would be useful as well. > > Although usually you have separate branch as StGIT stack "base", and > > you can simply rebase git branch, then do > > > > $ stg rebase Oh, I think I understand - he probably uses "base" to refer to what I call "parent branch", and not to the refs/bases/<branch> reference... Best regards, -- yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-22 19:47 ` Yann Dirson @ 2007-01-22 22:58 ` Catalin Marinas 2007-01-23 7:49 ` Yann Dirson 2007-01-28 4:33 ` Theodore Tso 0 siblings, 2 replies; 36+ messages in thread From: Catalin Marinas @ 2007-01-22 22:58 UTC (permalink / raw) To: Yann Dirson; +Cc: Jakub Narebski, git On 22/01/07, Yann Dirson <ydirson@altern.org> wrote: > On Mon, Jan 22, 2007 at 05:54:29PM +0000, Catalin Marinas wrote: > > Currently, in the StGIT terminology stack and branch are about the > > same. If you want to move to a different stack, just use the "stg > > branch" command. > > I think you missed the point. StGIT stacks are usually forked off > another branch. As I understand it, Jakub talks about standard > rebasing, ie. moving the stack base from its current parent branch to > a new one. StGIT stacks are a series of volatile commits (commits) at the top of a branch. The idea when I started writing this tool was that a series of applied patches would lead to the head of the current branch. The branch and stack are tightly coupled and you cannot simply change the parent branch the stack is based on (not from a technical point but rather from conception one). > > A stack is just a branch with stgit-specific metadata. > > I would rather say that an StGIT stacks uses a branch, but the stack > is not the branch - eg, unapplied patches do not belong to the branch. The unapplied patches can have any commit as a parent, either in the direct history of the current branch or in any other branch, there is no restriction here. They get in line with the current branch's head during the push operation. > Indeed I was thinking about that today, and thought that maybe it > would make sense not to use a head ref (and thus not using a real > branch), which would minimize the risk of someone committing by error > (and thus minimize the need to use "assimilate"), since porcelainish > commit tools would then refuse to commit there. But isn't this what Quilt already does (i.e. a different mechanism for patches, on top of any SCM)? One of the base ideas of StGIT is that the top patch represents the head of the current branch and that the patches applied on the stack always form the recent history of the current branch. I added the commit command to have a way to freeze this state into the current branch and no longer manage them with StGIT. > > What you'd probably want is a way to import patches from a different > > branch/stack onto the newly checked out branch. > > Sometimes you just want to throw out an obsolete branch and move your > stack to a new baseline. That said, being able to duplicate a stack > (and possibly rebasing it afterwards) would be useful as well. You have 'branch --clone' (or --rename if you just want a different name) and now 'rebase'. As I said, the idea of moving the stack (patches) on top of a different branch should be done as an import (or multiple cherry-pick or clone), otherwise we loose the coupling between branches and stacks. > > > Although usually you have separate branch as StGIT stack "base", and > > > you can simply rebase git branch, then do > > > > > > $ stg rebase > > Oh, I think I understand - he probably uses "base" to refer to what I > call "parent branch", and not to the refs/bases/<branch> reference... The ref/bases/<branch> is not used much in StGIT. I initially added it as a way to see the base of a stack in gitk but that's probably the only usecase. -- Catalin ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-22 22:58 ` Catalin Marinas @ 2007-01-23 7:49 ` Yann Dirson 2007-01-23 22:03 ` Catalin Marinas 2007-01-28 4:33 ` Theodore Tso 1 sibling, 1 reply; 36+ messages in thread From: Yann Dirson @ 2007-01-23 7:49 UTC (permalink / raw) To: Catalin Marinas; +Cc: Jakub Narebski, git On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote: > On 22/01/07, Yann Dirson <ydirson@altern.org> wrote: > >On Mon, Jan 22, 2007 at 05:54:29PM +0000, Catalin Marinas wrote: > >> Currently, in the StGIT terminology stack and branch are about the > >> same. If you want to move to a different stack, just use the "stg > >> branch" command. > > > >I think you missed the point. StGIT stacks are usually forked off > >another branch. As I understand it, Jakub talks about standard > >rebasing, ie. moving the stack base from its current parent branch to > >a new one. > > StGIT stacks are a series of volatile commits (commits) at the top of > a branch. The idea when I started writing this tool was that a series > of applied patches would lead to the head of the current branch. The > branch and stack are tightly coupled and you cannot simply change the > parent branch the stack is based on (not from a technical point but > rather from conception one). Well, that's now allowed by "rebase". > >> A stack is just a branch with stgit-specific metadata. > > > >I would rather say that an StGIT stacks uses a branch, but the stack > >is not the branch - eg, unapplied patches do not belong to the branch. > > The unapplied patches can have any commit as a parent, either in the > direct history of the current branch or in any other branch, there is > no restriction here. They get in line with the current branch's head > during the push operation. Right. I'm just emphasizing that, since they are (even temporarily) not part of the GIT branch from a GIT point of view, but part of the stack, the 2 concepts, while closely linked, are not strict subsets of each other. Rather, they share some common points, but neither would be parent of the other in a class hierarchy. > >Indeed I was thinking about that today, and thought that maybe it > >would make sense not to use a head ref (and thus not using a real > >branch), which would minimize the risk of someone committing by error > >(and thus minimize the need to use "assimilate"), since porcelainish > >commit tools would then refuse to commit there. > > But isn't this what Quilt already does (i.e. a different mechanism for > patches, on top of any SCM)? I'm not sure wat you mean here. I'm only talking of StGIT and the GIT world here. > One of the base ideas of StGIT is that the top patch represents the > head of the current branch and that the patches applied on the stack > always form the recent history of the current branch. I'm not willing to change the concept. I'm just wondering whether using a non-head reference (eg. stacks/<name> or stacks/<name>/top) would not be better. For this we may need to consider using detached HEAD support from 1.5.0, but I'm just thinking loudly, I have not looked at what that thing provides exactly yet. > I added the commit command to have a way to freeze this state into > the current branch and no longer manage them with StGIT. > >> What you'd probably want is a way to import patches from a different > >> branch/stack onto the newly checked out branch. > > > >Sometimes you just want to throw out an obsolete branch and move your > >stack to a new baseline. That said, being able to duplicate a stack > >(and possibly rebasing it afterwards) would be useful as well. > > You have 'branch --clone' (or --rename if you just want a different > name) and now 'rebase'. D'oh. I was probably expecting "stack --clone" or something :) > As I said, the idea of moving the stack (patches) on top of a > different branch should be done as an import (or multiple > cherry-pick or clone), otherwise we loose the coupling between > branches and stacks. I'll have to think more about that - I'm not sure I get you point. By moving/cloning we keep (or could keep) the patches' history. By importing we cannot do that. Best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-23 7:49 ` Yann Dirson @ 2007-01-23 22:03 ` Catalin Marinas 2007-01-24 0:05 ` Yann Dirson 0 siblings, 1 reply; 36+ messages in thread From: Catalin Marinas @ 2007-01-23 22:03 UTC (permalink / raw) To: Yann Dirson; +Cc: Jakub Narebski, git On 23/01/07, Yann Dirson <ydirson@altern.org> wrote: > On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote: > > On 22/01/07, Yann Dirson <ydirson@altern.org> wrote: > > The unapplied patches can have any commit as a parent, either in the > > direct history of the current branch or in any other branch, there is > > no restriction here. They get in line with the current branch's head > > during the push operation. > > Right. I'm just emphasizing that, since they are (even temporarily) > not part of the GIT branch from a GIT point of view, but part of the > stack, the 2 concepts, while closely linked, are not strict subsets of > each other. Rather, they share some common points, but neither would > be parent of the other in a class hierarchy. Indeed, but my point is that they are really tightly coupled and not easy to disconnect in the current design. Maybe we could loose the coupling post 1.0 but I'm not convinced it wouldn't create confusion among users. I also don't think there would be many users wanting to move a stack on top of a different branch when some import or multiple cherry-picking would be enough. > > >Indeed I was thinking about that today, and thought that maybe it > > >would make sense not to use a head ref (and thus not using a real > > >branch), which would minimize the risk of someone committing by error > > >(and thus minimize the need to use "assimilate"), since porcelainish > > >commit tools would then refuse to commit there. > > > > But isn't this what Quilt already does (i.e. a different mechanism for > > patches, on top of any SCM)? > > I'm not sure wat you mean here. I'm only talking of StGIT and the GIT > world here. I got the (wrong) impression that you'd like to disconnect StGIT patches from GIT commits which would mean re-writing Quilt or some other form of patch management. > > One of the base ideas of StGIT is that the top patch represents the > > head of the current branch and that the patches applied on the stack > > always form the recent history of the current branch. > > I'm not willing to change the concept. I'm just wondering whether > using a non-head reference (eg. stacks/<name> or stacks/<name>/top) > would not be better. For this we may need to consider using detached > HEAD support from 1.5.0, but I'm just thinking loudly, I have not > looked at what that thing provides exactly yet. It might be a good idea (probably post 1.0) since we have a 'commit' command to update the head of the branch already. I'll have to think a bit more to make sure it doesn't break existing use-cases. I also haven't followed the detached HEAD support. StGIT currently relies on the HEAD giving the information about the current branch. > > As I said, the idea of moving the stack (patches) on top of a > > different branch should be done as an import (or multiple > > cherry-pick or clone), otherwise we loose the coupling between > > branches and stacks. > > I'll have to think more about that - I'm not sure I get you point. By > moving/cloning we keep (or could keep) the patches' history. By > importing we cannot do that. The 'pick' command could be (easily) fixed to preserve the history of a patch (I'll add this to the todo list). The log commit would have the picked patch's log as a parent rather than none. StGIT grew up almost (or just 2 months behind) at the same time with GIT with a lot experimental/prototype features implemented. Now we probably have a lot more ideas (and users) about how we should use GIT and StGIT and can re-design parts of StGIT to accommodate the new use-cases. As I said, I'll first like to get a 1.0 out this spring. -- Catalin ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-23 22:03 ` Catalin Marinas @ 2007-01-24 0:05 ` Yann Dirson 2007-01-24 12:37 ` Catalin Marinas 0 siblings, 1 reply; 36+ messages in thread From: Yann Dirson @ 2007-01-24 0:05 UTC (permalink / raw) To: Catalin Marinas; +Cc: Jakub Narebski, git On Tue, Jan 23, 2007 at 10:03:26PM +0000, Catalin Marinas wrote: > >I'll have to think more about that - I'm not sure I get you point. By > >moving/cloning we keep (or could keep) the patches' history. By > >importing we cannot do that. > > The 'pick' command could be (easily) fixed to preserve the history of > a patch (I'll add this to the todo list). The log commit would have > the picked patch's log as a parent rather than none. Right - "branch --clone" could also use that (or maybe it does already by design). Together with this, "pick --fold" and possibly "sync" (although I never used the latter so I'm not 100% sure how it works) could register a merge, and sometime in the future we could use this information to be able to do some merging. I'm not going to look into this soon, but I have this popping out regularly in my head ;) > As I said, I'll first like to get a 1.0 out this spring. Yes. Maybe we should get 0.12 out of the door soon, with some more bugs fixed. I'm trying to finish putting out in a decent shape stuff about parent branches, git-fetch use and the other related issues mentionned those last days. Maybe that will be ready before enough bugs are squashed for 0.12, but maybe not :) Best regards, -- yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-24 0:05 ` Yann Dirson @ 2007-01-24 12:37 ` Catalin Marinas 2007-01-24 20:03 ` Yann Dirson 0 siblings, 1 reply; 36+ messages in thread From: Catalin Marinas @ 2007-01-24 12:37 UTC (permalink / raw) To: Yann Dirson; +Cc: Jakub Narebski, git On 24/01/07, Yann Dirson <ydirson@altern.org> wrote: > On Tue, Jan 23, 2007 at 10:03:26PM +0000, Catalin Marinas wrote: > > >I'll have to think more about that - I'm not sure I get you point. By > > >moving/cloning we keep (or could keep) the patches' history. By > > >importing we cannot do that. > > > > The 'pick' command could be (easily) fixed to preserve the history of > > a patch (I'll add this to the todo list). The log commit would have > > the picked patch's log as a parent rather than none. > > Right - "branch --clone" could also use that (or maybe it does already > by design). Together with this, "pick --fold" and possibly "sync" > (although I never used the latter so I'm not 100% sure how it works) > could register a merge, and sometime in the future we could use this > information to be able to do some merging. I'm not going to look > into this soon, but I have this popping out regularly in my head ;) 'sync' is still experimental. I usually have the same patches on different branches (i.e. a stable kernel branch for customers and a more up-to-date branch for pushing patches upstream). I wanted a way to automatically synchronise the changes made to some patches found in both branches. This command folds the remote patch onto the current one using a three-way merge. If they are identical, the current patch shouldn't change. If they are not identical, it leads to conflicts that have to be manually solved. > > As I said, I'll first like to get a 1.0 out this spring. > > Yes. Maybe we should get 0.12 out of the door soon, with some more > bugs fixed. I'm trying to finish putting out in a decent shape stuff > about parent branches, git-fetch use and the other related issues > mentionned those last days. Maybe that will be ready before enough > bugs are squashed for 0.12, but maybe not :) Maybe I'll manage to get a new release out in about a week or so. -- Catalin ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-24 12:37 ` Catalin Marinas @ 2007-01-24 20:03 ` Yann Dirson 0 siblings, 0 replies; 36+ messages in thread From: Yann Dirson @ 2007-01-24 20:03 UTC (permalink / raw) To: Catalin Marinas; +Cc: Jakub Narebski, git On Wed, Jan 24, 2007 at 12:37:15PM +0000, Catalin Marinas wrote: > >Right - "branch --clone" could also use that (or maybe it does already > >by design). Together with this, "pick --fold" and possibly "sync" > >(although I never used the latter so I'm not 100% sure how it works) > >could register a merge, and sometime in the future we could use this > >information to be able to do some merging. I'm not going to look > >into this soon, but I have this popping out regularly in my head ;) > > 'sync' is still experimental. I usually have the same patches on > different branches (i.e. a stable kernel branch for customers and a > more up-to-date branch for pushing patches upstream). That sounds like a typical usecase we should document :) > I wanted a way to automatically synchronise the changes made to some > patches found in both branches. This command folds the remote patch > onto the current one using a three-way merge. If they are identical, > the current patch shouldn't change. If they are not identical, it > leads to conflicts that have to be manually solved. So, indeed "sync" is a kind of merge tool already. It could be a good start to implement merging of forked patches. But going further would probably require to further develop the technics to work with patches of patches. best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-22 22:58 ` Catalin Marinas 2007-01-23 7:49 ` Yann Dirson @ 2007-01-28 4:33 ` Theodore Tso 2007-01-28 10:25 ` Yann Dirson 2007-01-28 23:21 ` Catalin Marinas 1 sibling, 2 replies; 36+ messages in thread From: Theodore Tso @ 2007-01-28 4:33 UTC (permalink / raw) To: Catalin Marinas; +Cc: Yann Dirson, Jakub Narebski, git On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote: > StGIT stacks are a series of volatile commits (commits) at the top of > a branch. The idea when I started writing this tool was that a series > of applied patches would lead to the head of the current branch. The > branch and stack are tightly coupled and you cannot simply change the > parent branch the stack is based on (not from a technical point but > rather from conception one). Well, a typical use case for me is: stg branch master git pull . stg branch 2.6.20-rc5 stg export -d /tmp/temp-stack stg branch master stg branch -C 2.6.20-rc6 stg import -s /tmp/temp-stack/series That's because I want to keep the original patch series for 2.6.20-rc5, but I also want rebase the patch set to 2.6.20-rc6. Is there a better way of doing this? - Ted ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-28 4:33 ` Theodore Tso @ 2007-01-28 10:25 ` Yann Dirson 2007-01-28 23:21 ` Catalin Marinas 1 sibling, 0 replies; 36+ messages in thread From: Yann Dirson @ 2007-01-28 10:25 UTC (permalink / raw) To: Theodore Tso; +Cc: Catalin Marinas, Jakub Narebski, git On Sat, Jan 27, 2007 at 11:33:12PM -0500, Theodore Tso wrote: > On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote: > > StGIT stacks are a series of volatile commits (commits) at the top of > > a branch. The idea when I started writing this tool was that a series > > of applied patches would lead to the head of the current branch. The > > branch and stack are tightly coupled and you cannot simply change the > > parent branch the stack is based on (not from a technical point but > > rather from conception one). > > Well, a typical use case for me is: > > stg branch master > git pull . > stg branch 2.6.20-rc5 > stg export -d /tmp/temp-stack > stg branch master > stg branch -C 2.6.20-rc6 You mean lowercase "-c", right ? > stg import -s /tmp/temp-stack/series > > That's because I want to keep the original patch series for > 2.6.20-rc5, but I also want rebase the patch set to 2.6.20-rc6. Is > there a better way of doing this? Yes. First, you can clone your stack: stgit$ stg branch --clone copy Cloning current branch to "copy"... done stgit$ stg branch -l Available branches: > s copy | clone of "master" s master | origin | And then you can rebase the clone, either with "stg rebase" (in stg HEAD only), or use the small tip described at http://git.or.cz/gitwiki/GitTips#head-8e71c3bdda0c372b79e33f5a3fedaf22c4c6f944 Best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-28 4:33 ` Theodore Tso 2007-01-28 10:25 ` Yann Dirson @ 2007-01-28 23:21 ` Catalin Marinas 1 sibling, 0 replies; 36+ messages in thread From: Catalin Marinas @ 2007-01-28 23:21 UTC (permalink / raw) To: Theodore Tso; +Cc: Yann Dirson, Jakub Narebski, git On 28/01/07, Theodore Tso <tytso@mit.edu> wrote: > Well, a typical use case for me is: > > stg branch master > git pull . > stg branch 2.6.20-rc5 > stg export -d /tmp/temp-stack > stg branch master > stg branch -C 2.6.20-rc6 > stg import -s /tmp/temp-stack/series > > That's because I want to keep the original patch series for > 2.6.20-rc5, but I also want rebase the patch set to 2.6.20-rc6. Is > there a better way of doing this? As Yann pointed out, you could just clone 2.6.20-rc5 into 2.6.20-rc6 and rebase the latter (currently with 'stg rebase v2.6.20-rc6'). If you have the branches already created, you can avoid the export/import with a cherry-pick (with better merging than just applying a patch). The 'pick' command only takes an argument (I'd like to extend it to accept multiple or patch ranges) but you can use it with 'series': stg branch 2.6.20-rc6 stg series -b 2.6.20-rc5 --noprefix --showbranch [patches...] \ | xargs -rn1 stg pick You could even use the --missing instead of -b for the series command. This option shows the patches on the remote branch which are missing in current. Pretty useful if you want to continue importing after fixing a conflict for example (that's a reason why I haven't extended 'pick' yet, 'series -m' seemed pretty powerful). Another trick if you modify some patches in one branch (i.e. 2.6.20-rc5) is to use 'stg sync -b 2.6.20-rc5 [patches]' in the other branch. It tries a three-way merge of each individual patch with the corresponding one in the other branch, showing you any possible conflicts (I usually have 'imerger' set to emacs... and 'autoimerge' to 'yes' in the config file so that emacs' ediff is automatically invoked for every conflict). -- Catalin ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Rebasing stgit stacks 2007-01-15 23:39 ` Yann Dirson 2007-01-16 22:42 ` Catalin Marinas @ 2007-01-17 21:30 ` Yann Dirson 1 sibling, 0 replies; 36+ messages in thread From: Yann Dirson @ 2007-01-17 21:30 UTC (permalink / raw) To: Catalin Marinas; +Cc: git, Guilhem Bonnefille On Tue, Jan 16, 2007 at 12:39:58AM +0100, Yann Dirson wrote: > > >I would be of the opinion to stop calling "git pull" entirely, and use > > >"git fetch and the git.move_branch show above. Unless I hear about > > >better ideas, my next patch set will be along those lines. > > > > Or replace the 'git pull' in the config file with 'git fetch && git > > reset --hard MERGE_HEAD'? I might be wrong though as I almost never > > use git directly :-). > > Hm. Probably rather FETCH_HEAD. Will have to look at that - but see > above. [...] > Note that I did not think of using FETCH_HEAD, I was rather thinking > of using information about the parent branch (which I had worked on > recently), with the idea that this info probably belongs to > branch.<name>.merge - which would complement Pavel's 87c69539 about > branch.<name>.remote. Unfortunately, using "reset('FETCH_HEAD')" or similar would not work. Eg, in the case we have cloned an stgit branch as "origin", and the revspec does not have a "+", git-fetch after a patch refresh in the remote repo still updates FETCH_HEAD even if it notices it cannot then fast-forward. With this we would end up with the "origin" branch not being changed, and our stack still being rebased as if we had a "+" refspec, which would be quite inconsistent. Best regards, -- Yann. ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2007-01-28 23:21 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-01-09 21:35 Howto use StGit and git-svn at same time Guilhem Bonnefille 2007-01-09 21:41 ` Guilhem Bonnefille 2007-01-09 22:41 ` Yann Dirson 2007-01-15 13:26 ` Guilhem Bonnefille 2007-01-15 20:24 ` Rebasing stgit stacks Yann Dirson 2007-01-15 22:46 ` Catalin Marinas 2007-01-15 23:39 ` Yann Dirson 2007-01-16 22:42 ` Catalin Marinas 2007-01-16 23:17 ` Yann Dirson 2007-01-16 23:30 ` Jakub Narebski 2007-01-17 9:03 ` Karl Hasselström 2007-01-17 11:07 ` David Kågedal 2007-01-17 19:34 ` Yann Dirson 2007-01-17 20:53 ` Yann Dirson 2007-01-18 12:06 ` Catalin Marinas 2007-01-18 19:42 ` Yann Dirson 2007-01-19 9:40 ` Jakub Narebski 2007-01-20 13:17 ` Yann Dirson 2007-01-20 19:16 ` Jakub Narebski 2007-01-20 20:07 ` Yann Dirson 2007-01-22 23:12 ` Catalin Marinas 2007-01-18 9:05 ` Catalin Marinas 2007-01-18 20:52 ` Yann Dirson 2007-01-19 9:47 ` Jakub Narebski 2007-01-22 17:54 ` Catalin Marinas 2007-01-22 19:47 ` Yann Dirson 2007-01-22 22:58 ` Catalin Marinas 2007-01-23 7:49 ` Yann Dirson 2007-01-23 22:03 ` Catalin Marinas 2007-01-24 0:05 ` Yann Dirson 2007-01-24 12:37 ` Catalin Marinas 2007-01-24 20:03 ` Yann Dirson 2007-01-28 4:33 ` Theodore Tso 2007-01-28 10:25 ` Yann Dirson 2007-01-28 23:21 ` Catalin Marinas 2007-01-17 21:30 ` 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.