newby question about merge.

newby question about merge.

[picca]

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

Re: newby question about merge.

[Alex Riesen]

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...]"

Re: newby question about merge.

[Jakub Narebski]

[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:).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: newby question about merge.

[picca]

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

> [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

Re: newby question about merge.

[Junio C Hamano]

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.

Re: newby question about merge.

[picca]

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

> 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

Re: newby question about merge.

[Johannes Schindelin]

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

Re: newby question about merge.

[Christian MICHON]

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...
>
> 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

Re: newby question about merge.

[Johannes Schindelin]

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:

> 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

Re: newby question about merge.

[Christian MICHON]

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

Re: newby question about merge.

[Johannes Schindelin]

Hi,

On Wed, 16 May 2007, Christian MICHON wrote:

> 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.

> > > 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.

> > 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