threads / discuss / 8164

newby question about merge.

Subject: newby question about merge.

## tl;dr

11 messages between May 15, 2007 and May 16, 2007.

replies: 10people: 6as markdown or json

picca· May 15, 2007, 09:38 UTC · lore

Hello I am using git to deal with debian packages. So i have two Branches the "upstream" one with the different version of the programm I am packaging.

exemple with two tags

scigraphica/2.1.0 scigraphica/0.8.0

I have another branch the master one which is the upstream + the debian directory.

So I do a merge like this "git merge upstream ." when I am on the master branch to work on the new package.

Everything is fine until git merge the configure scripts. (autotools) there is conflict with the configure file of the 0.8.0 version during the last merge.

My question is how can I keep the upstream version of the configure file instread of the one in the working directory.

I read about the stage(1:2:3) but I do not know how if it is related to my problem.

Thanks in advance.

Frédéric

Alex Riesen· May 15, 2007, 10:25 UTC · re: picca · lore

Re: newby question about merge.

picca, Tue, May 15, 2007 11:38:20 +0200:

> So I do a merge like this
> "git merge upstream ." when I am on the master branch to work on the new
> package.

loose the dot. git-merge syntax is "git merge branch1 [branch2...]"

Jakub Narebski· May 15, 2007, 10:34 UTC · re: picca · lore

Re: newby question about merge.

[Cc: picca <picca@synchrotron-soleil.Fr>, git@vger.kernel.org]

picca wrote:

Show 5 quoted lines

> My question is how can I keep the upstream version of the configure
> file instread of the one in the working directory.
> 
> I read about the stage(1:2:3) but I do not know how if it is related to
> my problem.

You can just do "git cat-file -p :2:filename > filename", then "git add filename" (or "git update-index filename") to resolve conflict.

Check first if :2: is correct file (and not for example :3:).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

picca· May 15, 2007, 11:37 UTC · re: Jakub Narebski · lore

Re: newby question about merge.

On Tue, 15 May 2007 12:34:55 +0200 Jakub Narebski <jnareb@gmail.com> wrote:

Show 15 quoted lines

> [Cc: picca <picca@synchrotron-soleil.Fr>, git@vger.kernel.org]
> 
> picca wrote:
> 
> > My question is how can I keep the upstream version of the configure
> > file instread of the one in the working directory.
> > 
> > I read about the stage(1:2:3) but I do not know how if it is
> > related to my problem.
> 
> You can just do "git cat-file -p :2:filename > filename", then
> "git add filename" (or "git update-index filename") to resolve
> conflict.
> 
> Check first if :2: is correct file (and not for example :3:).

In fact the right file was the :3: one.

Thank you very much.

Is it possible to add this git cat-file -p :2:filename > filename in the man page of git-merge in the resolve conflict part ?

Or a link to the documentation speaking of this stage part.

Thanks

Frédéric

Junio C Hamano· May 15, 2007, 21:47 UTC · re: picca · lore

Re: newby question about merge.

picca <picca@synchrotron-soleil.Fr> writes:

> Is it possible to add this git cat-file -p :2:filename > filename in
> the man page of git-merge in the resolve conflict part ?
>
> Or a link to the documentation speaking of this stage part.

See:

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#conflict-resolution

As this walk through section from the user manual's already talks about it, I am not sure if we would want to duplicate its wording in git-merge manual page.

Regardlessly, I think it is a good idea to refer to it in SEE ALSO section, just in case the user hasn't read the user manual before reading the git-merge manpage.

picca· May 16, 2007, 06:33 UTC · re: Junio C Hamano · lore

Re: newby question about merge.

On Tue, 15 May 2007 14:47:51 -0700 Junio C Hamano <junkio@cox.net> wrote:

Show 14 quoted lines

> picca <picca@synchrotron-soleil.Fr> writes:
> 
> > Is it possible to add this git cat-file -p :2:filename > filename in
> > the man page of git-merge in the resolve conflict part ?
> >
> > Or a link to the documentation speaking of this stage part.
> 
> See:
> 
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#conflict-resolution
> 
> As this walk through section from the user manual's already
> talks about it, I am not sure if we would want to duplicate its
> wording in git-merge manual page.

I had already red this manual but did not catch up that the :2:configure was the git path of the files I want to retreive. In fact I was missing the git-cat-file part and the git path.

regards, frederic

Johannes Schindelin· May 16, 2007, 11:43 UTC · re: Jakub Narebski · lore

Re: newby question about merge.

Hi,

On Tue, 15 May 2007, Jakub Narebski wrote:

> You can just do "git cat-file -p :2:filename > filename", then "git add 
> filename" (or "git update-index filename") to resolve conflict.

Do we really want to advertise this obscure-looking plumbing? Wouldn't it be better to teach people to use "git show" instead?

I mean, people can get intimidated by that...

Ciao, Dscho

Christian MICHON· May 16, 2007, 14:21 UTC · re: Johannes Schindelin · lore

Re: newby question about merge.

On 5/16/07, Johannes Schindelin wrote:

Show 11 quoted lines

> > You can just do "git cat-file -p :2:filename > filename", then "git add
> > filename" (or "git update-index filename") to resolve conflict.
>
> Do we really want to advertise this obscure-looking plumbing? Wouldn't it
> be better to teach people to use "git show" instead?
>
> I mean, people can get intimidated by that...
>
> Ciao,
> Dscho
>

I could be wrong, but git-show works in this way only after version 1.5, right ?

As far as I can tell, using git-1.4.4.4 or ealier, you would still need git-cat-file -p... to fix this merge conflict.

-- 
Christian

Johannes Schindelin· May 16, 2007, 14:45 UTC · re: Christian MICHON · lore

Re: newby question about merge.

Hi,

[please, Christian, do not cut the Cc: list. In particular, do _not_ cut the person you are _responding_ to from the Cc: list]

On Wed, 16 May 2007, Christian MICHON wrote:

Show 11 quoted lines

> On 5/16/07, Johannes Schindelin wrote:
> > > You can just do "git cat-file -p :2:filename > filename", then "git 
> > > add filename" (or "git update-index filename") to resolve conflict.
> > 
> > Do we really want to advertise this obscure-looking plumbing? Wouldn't 
> > it be better to teach people to use "git show" instead?
> > 
> > I mean, people can get intimidated by that...
> 
> I could be wrong, but git-show works in this way only after version 1.5, 
> right ?

Yes. So what?

> As far as I can tell, using git-1.4.4.4 or ealier, you would still need 
> git-cat-file -p... to fix this merge conflict.

If you are using pre-1.5 Git, you should really, really upgrade.

If you do not want to do that, then _at least_ you should not confuse newbies, who _should_ use Git 1.5+.

And most importantly: if you suggest a change in the man pages, it should reflect the new Git versions, _not_ the old ones.

Okay?

Ciao, Dscho

Christian MICHON· May 16, 2007, 19:35 UTC · re: Johannes Schindelin · lore

Re: newby question about merge.

On 5/16/07, Johannes Schindelin wrote:

> [please, Christian, do not cut the Cc: list. In particular, do _not_ cut
> the person you are _responding_ to from the Cc: list]

[ oops. I thought some of us sometimes receive doublets of emails, being in reply_to and cc of git@vger.kernel.org. point *taken* ]

> > I could be wrong, but git-show works in this way only after version 1.5,
> > right ?
>
> Yes. So what?

I also sometimes use old git versions (I still consider 1.4.4.4 as a reference).

I know the API changes frequently. But engineers don't like too many changes usually, and like to carry a portable/stable way. "git cat-file" at least behaves as it was in 1.4.x :)

> > As far as I can tell, using git-1.4.4.4 or ealier, you would still need
> > git-cat-file -p... to fix this merge conflict.
>
> If you are using pre-1.5 Git, you should really, really upgrade.

While in principle I'd agree, in practice I do not. Git API changes increased learning curve for people who actually started with git a year ago.

Note this is a git user feedback, not a git developer feedback.

>
> If you do not want to do that, then _at least_ you should not confuse
> newbies, who _should_ use Git 1.5+.

hey, I'm not a newbie anymore! :)

it's just that today, on a machine I only had git-1.4.4.4 to play with, I had to do a merge of 2 private branches ( aufs and squashfs) on linux-2.6.21... I had 3 smalls conflicts to fix and I saw this thread... and decided to stick with git-cat-file on this fix.

> And most importantly: if you suggest a change in the man pages, it should
> reflect the new Git versions, _not_ the old ones.

nope, I would not dare to suggest. I'm not a git developer: just a git user :)

> Okay?

yep

-- 
Christian

Johannes Schindelin· May 16, 2007, 22:39 UTC · re: Christian MICHON · lore

Re: newby question about merge.

Hi,

On Wed, 16 May 2007, Christian MICHON wrote:

Show 6 quoted lines

> On 5/16/07, Johannes Schindelin wrote:
> > [please, Christian, do not cut the Cc: list. In particular, do _not_ 
> > cut the person you are _responding_ to from the Cc: list]
> 
> [ oops. I thought some of us sometimes receive doublets of emails,
> being in reply_to and cc of git@vger.kernel.org. point *taken* ]

Actually, I get doublets. Which is good, since I am more unlikely to just delete _two_ copies of the same mail.

> I know the API changes frequently. But engineers don't like too many 
> changes usually, and like to carry a portable/stable way. "git cat-file" 
> at least behaves as it was in 1.4.x :)

Those changes were good changes. "git-show" is here to stay. "git-cat-file" only appeals to Unix zealots who even sleep in their command line.

Show 8 quoted lines

> > > As far as I can tell, using git-1.4.4.4 or ealier, you would still 
> > > need git-cat-file -p... to fix this merge conflict.
> > 
> > If you are using pre-1.5 Git, you should really, really upgrade.
> 
> While in principle I'd agree, in practice I do not. Git API changes 
> increased learning curve for people who actually started with git a year 
> ago.

I think I can pretty much guarantee that git-cat-file will stay plumbing. As much as it will keep its not-exactly-user-friendly command line arguments.

And I can pretty much guarantee that git-show will always be the good thing for an end user to call.

Show 5 quoted lines

> > And most importantly: if you suggest a change in the man pages, it 
> > should reflect the new Git versions, _not_ the old ones.
> 
> nope, I would not dare to suggest. I'm not a git developer: just a git 
> user :)

You are right: for general help, this list is open for older versions of Git. What triggered my response, though, was the suggestion to put that particular command line, which indeed scares people away from Git (I tried it on somebody), into a man page.

	git-show <revision>:<path>

is so much nicer.

Ciao, Dscho