* Merging to and from non-current branches.
@ 2009-08-04 23:21 lists
2009-08-05 2:45 ` Daniel Barkalow
0 siblings, 1 reply; 11+ messages in thread
From: lists @ 2009-08-04 23:21 UTC (permalink / raw)
To: git
Hi All,
I've been reading up on some of the GIT commands and I'm not sure if
what I want/need exists. Basically I want to merge all changes from
one branch to another, regardless of whether I'm in either of those
branches. At the very least I would like to merge an existing
"development" branch with the "master" branch without needing to first
check out master. I've seen rebase, but I'm not absolutely sure what
that's doing. Thoughts?
Best,
Michael
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Merging to and from non-current branches.
2009-08-04 23:21 Merging to and from non-current branches lists
@ 2009-08-05 2:45 ` Daniel Barkalow
2009-08-05 2:48 ` lists
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Barkalow @ 2009-08-05 2:45 UTC (permalink / raw)
To: lists; +Cc: git
On Tue, 4 Aug 2009, lists@mgreg.com wrote:
> Hi All,
>
> I've been reading up on some of the GIT commands and I'm not sure if what I
> want/need exists. Basically I want to merge all changes from one branch to
> another, regardless of whether I'm in either of those branches. At the very
> least I would like to merge an existing "development" branch with the "master"
> branch without needing to first check out master. I've seen rebase, but I'm
> not absolutely sure what that's doing. Thoughts?
It can't work, because you need to be able to use the working tree to
resolve any conflicts that arise during the merge. Merging without
checking out a branch is a bit like building without checking out a
branch; it would be avoiding using the filesystem for what it's there for.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Merging to and from non-current branches.
2009-08-05 2:45 ` Daniel Barkalow
@ 2009-08-05 2:48 ` lists
2009-08-05 3:33 ` Adam Brewster
` (3 more replies)
0 siblings, 4 replies; 11+ messages in thread
From: lists @ 2009-08-05 2:48 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
On Aug 4, 2009, at 10:45 PM, Daniel Barkalow wrote:
> On Tue, 4 Aug 2009, lists@mgreg.com wrote:
>
>> Hi All,
>>
>> I've been reading up on some of the GIT commands and I'm not sure
>> if what I
>> want/need exists. Basically I want to merge all changes from one
>> branch to
>> another, regardless of whether I'm in either of those branches. At
>> the very
>> least I would like to merge an existing "development" branch with
>> the "master"
>> branch without needing to first check out master. I've seen
>> rebase, but I'm
>> not absolutely sure what that's doing. Thoughts?
>
> It can't work, because you need to be able to use the working tree to
> resolve any conflicts that arise during the merge. Merging without
> checking out a branch is a bit like building without checking out a
> branch; it would be avoiding using the filesystem for what it's
> there for.
>
> -Daniel
> *This .sig left intentionally blank*
>
Hi Daniel,
I appreciate your post. I understand what you're saying, and I'm not
so much concerned about the logistics of what need to occur so much as
a single command to intuitively handle it. I've been doing a great
deal of incremental development lately and it becomes rather tedious
to have to checkout master, merge dev, re-checkout dev and proceed.
I'm not sure why this isn't currently possible with a single command.
I suppose I could write a shell script to do so, but that's a little
less "native" than I'd like.
Best,
Michael
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Merging to and from non-current branches.
2009-08-05 2:48 ` lists
@ 2009-08-05 3:33 ` Adam Brewster
2009-08-05 3:46 ` Sverre Rabbelier
` (2 subsequent siblings)
3 siblings, 0 replies; 11+ messages in thread
From: Adam Brewster @ 2009-08-05 3:33 UTC (permalink / raw)
To: lists; +Cc: Daniel Barkalow, git
In case it helps, I think that if you're on branch dev, and you `merge
master`, you should get a commit that's substantially similar to that
that you'd get if you're on master and you `merge dev`.
The most noticeable difference should be that if you `checkout master
&& merge dev` the master is updated to point to the merged commit,
whereas if you `checkout dev && merge master` dev is updated to the
new commit.
(If there are conflicts, then the merge processes will differ more
significantly, but hopefully the human should be able to sort that
out.)
You should be able to use git-reset and git update-ref to clean up the
mess if that's not good enough.
Adam Brewster
On Tue, Aug 4, 2009 at 10:48 PM, lists@mgreg.com<lists@mgreg.com> wrote:
>
> On Aug 4, 2009, at 10:45 PM, Daniel Barkalow wrote:
>
>> On Tue, 4 Aug 2009, lists@mgreg.com wrote:
>>
>>> Hi All,
>>>
>>> I've been reading up on some of the GIT commands and I'm not sure if what
>>> I
>>> want/need exists. Basically I want to merge all changes from one branch
>>> to
>>> another, regardless of whether I'm in either of those branches. At the
>>> very
>>> least I would like to merge an existing "development" branch with the
>>> "master"
>>> branch without needing to first check out master. I've seen rebase, but
>>> I'm
>>> not absolutely sure what that's doing. Thoughts?
>>
>> It can't work, because you need to be able to use the working tree to
>> resolve any conflicts that arise during the merge. Merging without
>> checking out a branch is a bit like building without checking out a
>> branch; it would be avoiding using the filesystem for what it's there for.
>>
>> -Daniel
>> *This .sig left intentionally blank*
>>
>
>
> Hi Daniel,
>
> I appreciate your post. I understand what you're saying, and I'm not so
> much concerned about the logistics of what need to occur so much as a single
> command to intuitively handle it. I've been doing a great deal of
> incremental development lately and it becomes rather tedious to have to
> checkout master, merge dev, re-checkout dev and proceed. I'm not sure why
> this isn't currently possible with a single command. I suppose I could
> write a shell script to do so, but that's a little less "native" than I'd
> like.
>
> Best,
>
> Michael
> --
> 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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Merging to and from non-current branches.
2009-08-05 2:48 ` lists
2009-08-05 3:33 ` Adam Brewster
@ 2009-08-05 3:46 ` Sverre Rabbelier
2009-08-05 21:28 ` Alex Riesen
2009-08-06 11:54 ` Steffen Siebert
3 siblings, 0 replies; 11+ messages in thread
From: Sverre Rabbelier @ 2009-08-05 3:46 UTC (permalink / raw)
To: lists; +Cc: Daniel Barkalow, git
Heya,
On Tue, Aug 4, 2009 at 19:48, lists@mgreg.com<lists@mgreg.com> wrote:
> I appreciate your post. I understand what you're saying, and I'm not so
> much concerned about the logistics of what need to occur so much as a single
> command to intuitively handle it. I've been doing a great deal of
> incremental development lately and it becomes rather tedious to have to
> checkout master, merge dev, re-checkout dev and proceed. I'm not sure why
> this isn't currently possible with a single command. I suppose I could
> write a shell script to do so, but that's a little less "native" than I'd
> like.
You might want to try out an alias:
$ git config alias.update "!git checkout master && git merge dev &&
git checkout dev"
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Merging to and from non-current branches.
2009-08-05 2:48 ` lists
2009-08-05 3:33 ` Adam Brewster
2009-08-05 3:46 ` Sverre Rabbelier
@ 2009-08-05 21:28 ` Alex Riesen
2009-08-06 1:48 ` lists
2009-08-06 11:54 ` Steffen Siebert
3 siblings, 1 reply; 11+ messages in thread
From: Alex Riesen @ 2009-08-05 21:28 UTC (permalink / raw)
To: lists; +Cc: Daniel Barkalow, git
On Wed, Aug 5, 2009 at 04:48, lists@mgreg.com<lists@mgreg.com> wrote:
> I appreciate your post. I understand what you're saying, and I'm not so
> much concerned about the logistics of what need to occur so much as a single
> command to intuitively handle it. I've been doing a great deal of
> incremental development lately and it becomes rather tedious to have to
> checkout master, merge dev, re-checkout dev and proceed. I'm not sure why
> this isn't currently possible with a single command.
Because no one needed this sequence of commands for long enough.
> I suppose I could write a shell script to do so, but that's a little less "native"
> than I'd like.
But that's absolutely native to Git. Many Git commands are just shell scripts!
Many guarantee (the "plumbing") you stability and machine-readability of
their output precisely for this reason.
Write your script, propose it here, and there will be enough interest it'll land
in the official distribution (or, more likely, in the "contrib"
directory of it).
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Merging to and from non-current branches.
2009-08-05 21:28 ` Alex Riesen
@ 2009-08-06 1:48 ` lists
2009-08-06 2:15 ` Randal L. Schwartz
2009-08-06 17:41 ` Daniel Barkalow
0 siblings, 2 replies; 11+ messages in thread
From: lists @ 2009-08-06 1:48 UTC (permalink / raw)
To: Alex Riesen; +Cc: Daniel Barkalow, git
On Aug 5, 2009, at 5:28 PM, Alex Riesen wrote:
> On Wed, Aug 5, 2009 at 04:48, lists@mgreg.com<lists@mgreg.com> wrote:
>> I appreciate your post. I understand what you're saying, and I'm
>> not so
>> much concerned about the logistics of what need to occur so much as
>> a single
>> command to intuitively handle it. I've been doing a great deal of
>> incremental development lately and it becomes rather tedious to
>> have to
>> checkout master, merge dev, re-checkout dev and proceed. I'm not
>> sure why
>> this isn't currently possible with a single command.
>
> Because no one needed this sequence of commands for long enough.
As I said, I understand what is being said, but in IMHO it would seem
that a merge of that nature would be immediately desirable. Think of
it more as a local "push". I'm never a fan of "because it hasn't be
done means it shouldn't be". I realize that's not exactly what you're
saying though. Anyway, I absolutely appreciate the post, and may very
well post the script.
Best,
Michael
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Merging to and from non-current branches.
2009-08-06 1:48 ` lists
@ 2009-08-06 2:15 ` Randal L. Schwartz
2009-08-06 17:41 ` Daniel Barkalow
1 sibling, 0 replies; 11+ messages in thread
From: Randal L. Schwartz @ 2009-08-06 2:15 UTC (permalink / raw)
To: lists; +Cc: Alex Riesen, Daniel Barkalow, git
>>>>> "mgreg" == lists@mgreg com <lists@mgreg.com> writes:
mgreg> As I said, I understand what is being said, but in IMHO it would seem
mgreg> that a merge of that nature would be immediately desirable. Think of
mgreg> it more as a local "push". I'm never a fan of "because it hasn't be
mgreg> done means it shouldn't be". I realize that's not exactly what you're
mgreg> saying though. Anyway, I absolutely appreciate the post, and may very
mgreg> well post the script.
In other words, you'd be happy with it if it was just a fast-forward only?
Because the moment you might have conflicts, that *has* to be the workdir
so you can resolve those conflicts. Dunno why this is so hard to grok.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Merging to and from non-current branches.
2009-08-05 2:48 ` lists
` (2 preceding siblings ...)
2009-08-05 21:28 ` Alex Riesen
@ 2009-08-06 11:54 ` Steffen Siebert
3 siblings, 0 replies; 11+ messages in thread
From: Steffen Siebert @ 2009-08-06 11:54 UTC (permalink / raw)
To: git
lists <at> mgreg.com <lists <at> mgreg.com> writes:
> a single command to intuitively handle it. I've been doing a great
> deal of incremental development lately and it becomes rather tedious
> to have to checkout master, merge dev, re-checkout dev and proceed.
> I'm not sure why this isn't currently possible with a single command.
> I suppose I could write a shell script to do so, but that's a little
> less "native" than I'd like.
Hi Michael,
I had a similar problem (we are doing rebases instead of merges) and found a way
to rebase and push my changes onto the master without the need of a "checkout
master".
You can find my question and the approved (green) answer that works for me on
stackoverflow.com:
http://stackoverflow.com/questions/945372/how-to-efficiently-rebase-and-push-a-local-git-branch
Maybe this works for you, too.
Ciao,
Steffen
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Merging to and from non-current branches.
2009-08-06 1:48 ` lists
2009-08-06 2:15 ` Randal L. Schwartz
@ 2009-08-06 17:41 ` Daniel Barkalow
2009-08-06 18:43 ` Junio C Hamano
1 sibling, 1 reply; 11+ messages in thread
From: Daniel Barkalow @ 2009-08-06 17:41 UTC (permalink / raw)
To: lists; +Cc: Alex Riesen, git
On Wed, 5 Aug 2009, lists@mgreg.com wrote:
>
> On Aug 5, 2009, at 5:28 PM, Alex Riesen wrote:
>
> >On Wed, Aug 5, 2009 at 04:48, lists@mgreg.com<lists@mgreg.com> wrote:
> > >I appreciate your post. I understand what you're saying, and I'm not so
> > >much concerned about the logistics of what need to occur so much as a
> > >single
> > >command to intuitively handle it. I've been doing a great deal of
> > >incremental development lately and it becomes rather tedious to have to
> > >checkout master, merge dev, re-checkout dev and proceed. I'm not sure why
> > >this isn't currently possible with a single command.
> >
> >Because no one needed this sequence of commands for long enough.
>
> As I said, I understand what is being said, but in IMHO it would seem that a
> merge of that nature would be immediately desirable. Think of it more as a
> local "push".
You mean like "git push . dev:master"? That does work in the case where a
content merge is not required (although not otherwise).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Merging to and from non-current branches.
2009-08-06 17:41 ` Daniel Barkalow
@ 2009-08-06 18:43 ` Junio C Hamano
0 siblings, 0 replies; 11+ messages in thread
From: Junio C Hamano @ 2009-08-06 18:43 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: lists, Alex Riesen, git
Daniel Barkalow <barkalow@iabervon.org> writes:
>> As I said, I understand what is being said, but in IMHO it would seem that a
>> merge of that nature would be immediately desirable. Think of it more as a
>> local "push".
>
> You mean like "git push . dev:master"? That does work in the case where a
> content merge is not required (although not otherwise).
Just to clarify.
It works _only_ when the push is a fast forward, i.e. where a merge is not
required.
That is different from working in a case "where a content merge is not
required".
The word "content merge" is often used in contrast to "tree level merge",
meaning the latter can be finished by flipping stages inside the index by
the three-way read-tree (--aggressive) while the former needs to call out
to "merge-one-file".
But the push will be rejected if you need _any_ kind of merge.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-08-06 18:43 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-04 23:21 Merging to and from non-current branches lists
2009-08-05 2:45 ` Daniel Barkalow
2009-08-05 2:48 ` lists
2009-08-05 3:33 ` Adam Brewster
2009-08-05 3:46 ` Sverre Rabbelier
2009-08-05 21:28 ` Alex Riesen
2009-08-06 1:48 ` lists
2009-08-06 2:15 ` Randal L. Schwartz
2009-08-06 17:41 ` Daniel Barkalow
2009-08-06 18:43 ` Junio C Hamano
2009-08-06 11:54 ` Steffen Siebert
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.