* Re: RFH: refactor read-tree
From: Linus Torvalds @ 2006-07-09 15:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.63.0607091630110.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 9 Jul 2006, Johannes Schindelin wrote:
>
> On Sun, 9 Jul 2006, Alex Riesen wrote:
>
> > Linus Torvalds, Sun, Jul 09, 2006 05:15:41 +0200:
> > > The basic idea is that "branch1" should be your current branch, and it
> > > obviously is also expected to match (more or less) the current index. So
> > > you can do a merge by
> > >
> > > - reading in "branch1" into the index:
> > >
> > > GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1
> >
> > what is "-m" here for?
>
> It means that git-read-tree tries to merge the current index with branch1.
Well, the current index always "merges" by just taking the timestamps from
it. The actual _content_ doesn't matter for the single-tree case.
For the two- and three-tree case, "git-read-tree -m" will verify that the
parts that got changed still _match_ in the index, but for a single-tree
"git-read-tree", there's nothing to match against, just the target, so
the only thing it does is that for matching index/target-tree entries it
will re-use the index timestamps (and other stat info).
Linus
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Jan-Benedict Glaw @ 2006-07-09 16:24 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Michal Rokos, Junio C Hamano, Alex Riesen, git
In-Reply-To: <86ejwuuba2.fsf@blue.stonehenge.com>
[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]
On Sun, 2006-07-09 07:02:13 -0700, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>> "Michal" == Michal Rokos <michal.rokos@nextsoft.cz> writes:
>
> Michal> I have no problem with that. I can set $PATH.
> Michal> But then I'd suggest to change magic #!
> Michal> from #!/usr/bin/perl
> Michal> to #!/usr/bin/env perl
> Michal> for *.perl
>
> Michal> It that what you meant?
>
> No, don't do that. Use the path to Perl that they chose during
> configuration because
>
> (a) it might not be the first one in PATH
If you want to execute some binary that's not first in path, you'd
better *always* call that explicit.
> (b) even if it's the first one in *my* path, it might not be the
> first one in *everyone's* path
Communication problem. Machine's administrator should offer a working
git installation. If a user chooses to build his own git, he'd better
make sure that all the environment is properly set-up, too.
> (c) env requires an *extra* fork/exec
Only an extra exec.
> (d) some systems don't have env
Huh? Show me a system that has no /usr/bin/env, but a working POSIX
shell in /bin/sh .
> The env hack is a nice hack, but it's just a hack. Don't
> rely on it when the right thing is nearby.
What's the right thing? The right thing is to explicitely call the
interpreter, not using the shellbang at all.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 3] Copy description of build configuration variables to configure.ac
From: Jakub Narebski @ 2006-07-09 16:47 UTC (permalink / raw)
To: git
In-Reply-To: <7virm7nq7h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Copy description of build configuration variables from the commentary
>> in the top Makefile (from 'next' branch) to configure.ac, splitting
>> them into "autoconf" sections.
>
> I do not see much point in this -- they will become out of sync.
> [...] I think you are better off making a list of
> supported and yet to be supported ones in the comment in
> configure.ac, and when you want to see if the list got stale
> over time, grep for '^# Define' from the Makefile and match them
> up.
This is kind of such a list. Also let me point out that this was in _first_
patch of the series, as a kind of TODO list.
Perhaps those which are done, and those which are not implemented should be
marked differently...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Jakub Narebski @ 2006-07-09 17:04 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0607090011000.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Sat, 8 Jul 2006, Jakub Narebski wrote:
>
>> moreau francis wrote:
>>
>>> Would it be possible to let the user stick a short explanation
>>> on what a branch is supposed to implement during its creation.
>>
>> It would be possible when/if branch and remotes config would migrate
>> to .git/config. Currently too many I think relies on refs/heads being
>> simple sha1 of "top" commit.
>
> But it does not need a change of existing practice at all! Just add the
> information provided by --topic as branch."pathname".description to the
> config. And make format-patch aware of that.
And make tools remove stale descriptions. I sometimes rename branches "by
hand", as currently there is I think no tool for this...
By the way, did this series of patches (adding support for branch and
remotes configuretion to config file) made into 'next', 'master' or even
'pu', or after some discussion it stalled?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Johannes Schindelin @ 2006-07-09 19:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8rcu5$je5$2@sea.gmane.org>
Hi,
On Sun, 9 Jul 2006, Jakub Narebski wrote:
> By the way, did this series of patches (adding support for branch and
> remotes configuretion to config file) made into 'next', 'master' or even
> 'pu', or after some discussion it stalled?
The latter. Some parts are there (the remote configuration made it in
AFAIK) but things like the default remote(s) to fetch / push are not.
Ciao,
Dscho
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Junio C Hamano @ 2006-07-09 20:33 UTC (permalink / raw)
To: Michal Rokos; +Cc: git
In-Reply-To: <200607091441.16161.michal.rokos@nextsoft.cz>
Michal Rokos <michal.rokos@nextsoft.cz> writes:
> Hello,
>
> On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
>> Michal, is there a reason you do not want to have the version of
>> perl you teach git tools via #! lines with PERL_PATH on your $PATH?
>
> I have no problem with that. I can set $PATH.
> But then I'd suggest to change magic #!
> from #!/usr/bin/perl
> to #!/usr/bin/env perl
> for *.perl
>
> It that what you meant?
No, that is not what I meant.
Invocation of perl _in_ scripts can be controlled by user's
PATH, but #! cannot be. As Merlyn says 'env' is a nice hack,
but we configure the scripts we install to have #! pointing at
the right interpreter as a more cleaner (than using 'env', that
is) workaround anyway, so #! pointing at PERL_PATH and scripts
relying on user's $PATH would be the right thing to do.
^ permalink raw reply
* Re: [RFC/PATCH 3] Copy description of build configuration variables to configure.ac
From: Junio C Hamano @ 2006-07-09 20:43 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <e8rbuk$je5$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>> [...] I think you are better off making a list of
>> supported and yet to be supported ones in the comment in
>> configure.ac, and when you want to see if the list got stale
>> over time, grep for '^# Define' from the Makefile and match them
>> up.
>
> This is kind of such a list. Also let me point out that this was in _first_
> patch of the series, as a kind of TODO list.
Yes, you are right -- I spoke too early without realizing what
was going on. The others build on this TODO list to fill the
gap rather nicely.
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Jan-Benedict Glaw @ 2006-07-09 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michal Rokos, git
In-Reply-To: <7v4pxqfri7.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]
On Sun, 2006-07-09 13:33:04 -0700, Junio C Hamano <junkio@cox.net> wrote:
> Michal Rokos <michal.rokos@nextsoft.cz> writes:
> > On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
> >> Michal, is there a reason you do not want to have the version of
> >> perl you teach git tools via #! lines with PERL_PATH on your $PATH?
> >
> > I have no problem with that. I can set $PATH.
> > But then I'd suggest to change magic #!
> > from #!/usr/bin/perl
> > to #!/usr/bin/env perl
> > for *.perl
> >
> > It that what you meant?
>
> No, that is not what I meant.
Though I think you actually should :-)
> Invocation of perl _in_ scripts can be controlled by user's
> PATH, but #! cannot be. As Merlyn says 'env' is a nice hack,
> but we configure the scripts we install to have #! pointing at
> the right interpreter as a more cleaner (than using 'env', that
> is) workaround anyway, so #! pointing at PERL_PATH and scripts
> relying on user's $PATH would be the right thing to do.
It's just a question of the target system, so: What is our target? If
we target a fairly recent Unix box, we'd put whatever a user asked for
into the shellbang, and hope that he properly sets $PATH.
If we try to aim at POSIX systems, then first of all, `env' isn't a
hack. It's specified i the POSIX documents, even argument passing is
given. (So if `#!/usr/bin/env perl -w' doesn't work on a HP-UX system,
that's simply broken wrt. POSIX.)
At the maximum, we'd allow the user to supply the location of `env' if
it's not /usr/bin/env, but I guess you'll find a hard time finding a
system where there's no /usr/bin/env... The final killer would be to
explicitely mention the interpreter and install all scripts a-x to
force that :-)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What *have* I done?
From: Petr Baudis @ 2006-07-09 21:21 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <87u05ru30p.fsf@hades.wkstn.nix>
Hi,
Dear diary, on Sun, Jul 09, 2006 at 12:48:22AM CEST, I got a letter
where Nix <nix@esperi.org.uk> said that...
> loki 593 /usr/packages/linux/linux% cg-diff | diffstat
Note that cg-diff -s might be useful.
> loki 594 /usr/packages/linux/linux% cg-reset
> loki 595 /usr/packages/linux/linux% cg-diff
> loki 596 /usr/packages/linux/linux%
...but when you switch away and switch back, the uncommitted changes
appear again?
Just in case, don't the tree happen to simply stay the same as in the
branch you switched from? (Try cg-diff -r yourpreviousbranch.)
And most importantly, does this also happen with just stock 0.17.3
cg-switch? With stock master cg-switch? (If both is no, you probably
forgot to cherrypick some associated cg-switch bugfix or something.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Martin Langhoff @ 2006-07-09 21:26 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <11524258261798-git-send-email-ryan@michonline.com>
On 7/9/06, Ryan Anderson <ryan@michonline.com> wrote:
> This is the first in a series to categorize the source tree a little bit more
> than it is currently.
Given that you title it RFC, I guess it hasn't been discussed before.
I personally don't see much benefit from the move/rename. The tree is
not so large, the SCM import/export utilities are a single file each
and their names are quite clear. Having /contrib is more an issue of
marking utilities there as 'new, experimental, unsupported', and the
assumption is that when something matures it moves out of /contrib.
So I have to ask... what are the expected benefits of the move?
In any case, use /interop instead. /scm in the tree of an SCM could be
anything ;-)
martin
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Petr Baudis @ 2006-07-09 22:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marco Costalba, git
In-Reply-To: <Pine.LNX.4.63.0607091632070.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Sun, Jul 09, 2006 at 04:33:53PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Sun, 9 Jul 2006, Marco Costalba wrote:
>
> > It is possible to add a message (and more) to a tag creating a tag
> > object. FWIK this is not allowed for the other refs.
> >
> > Why there is this (artifical?) difference between tags and the other
> > kind of refs?
>
> The tag message is nothing else than a commit message.
huh?
The tag message is a message in the "freeform" part of the tag object,
but disregarding the format similiraties, it has really nothing to do
with a commit message. (Also, commit messages don't tend to be commonly
PGP signed. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Johannes Schindelin @ 2006-07-09 22:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Marco Costalba, git
In-Reply-To: <20060709220116.GT29115@pasky.or.cz>
Hi,
On Mon, 10 Jul 2006, Petr Baudis wrote:
> Hi,
>
> Dear diary, on Sun, Jul 09, 2006 at 04:33:53PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > On Sun, 9 Jul 2006, Marco Costalba wrote:
> >
> > > It is possible to add a message (and more) to a tag creating a tag
> > > object. FWIK this is not allowed for the other refs.
> > >
> > > Why there is this (artifical?) difference between tags and the other
> > > kind of refs?
> >
> > The tag message is nothing else than a commit message.
>
> huh?
>
> The tag message is a message in the "freeform" part of the tag object,
> but disregarding the format similiraties, it has really nothing to do
> with a commit message. (Also, commit messages don't tend to be commonly
> PGP signed. ;-)
Marco was talking about an "artificial difference", which means technical
issues. From a technical viewpoint, the tag message is _exactly_ the same
as a commit message.
Hth,
Dscho
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Petr Baudis @ 2006-07-09 22:13 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Ryan Anderson, git
In-Reply-To: <46a038f90607091426u5a6ea328h2090a876e51725ce@mail.gmail.com>
Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> So I have to ask... what are the expected benefits of the move?
I've been meaning to do something like this for some time already; my
itch have been the builtins. The tree size _is_ getting out of hand and
a little more categorization of the sources would certainly help.
Although I'd take a different approach:
libgit/
builtin/
standalone/
scripts/
> In any case, use /interop instead. /scm in the tree of an SCM could be
> anything ;-)
I agree on this point.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: RFH: refactor read-tree
From: Alex Riesen @ 2006-07-09 22:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0607090827430.5623@g5.osdl.org>
Linus Torvalds, Sun, Jul 09, 2006 17:30:26 +0200:
> > > > The basic idea is that "branch1" should be your current branch, and it
> > > > obviously is also expected to match (more or less) the current index. So
> > > > you can do a merge by
> > > >
> > > > - reading in "branch1" into the index:
> > > >
> > > > GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1
> > >
> > > what is "-m" here for?
> >
> > It means that git-read-tree tries to merge the current index with branch1.
>
> Well, the current index always "merges" by just taking the timestamps from
> it. The actual _content_ doesn't matter for the single-tree case.
But the name suggests it's a temporary index, which would not have
anything in it and even the .git/tmp-index is not supposed to exist.
So I'd actually understand this as creating an index from the tree-ish
branch1, without merging anything. And continue wondering what that -m
is for...
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Johannes Schindelin @ 2006-07-09 22:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff, Ryan Anderson, git
In-Reply-To: <20060709221326.GU29115@pasky.or.cz>
Hi,
On Mon, 10 Jul 2006, Petr Baudis wrote:
> Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter
> where Martin Langhoff <martin.langhoff@gmail.com> said that...
> > So I have to ask... what are the expected benefits of the move?
>
> I've been meaning to do something like this for some time already; my
> itch have been the builtins. The tree size _is_ getting out of hand and
> a little more categorization of the sources would certainly help.
Funny. I thought the builtin-* prefix, and the *.sh and *.perl extensions
were there for the sake of categorization.
And I disagree on the "out of hand" thing.
Ciao,
Dscho
^ permalink raw reply
* Re: git on HP-UX
From: Petr Baudis @ 2006-07-09 22:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vfyhe465i.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Jul 07, 2006 at 02:20:41AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> > I hope the Autoconf based configure is on its way to git, but I don't
> > see in in the "pu" branch yet. I'm not very keen about reinventing
> > Autoconf and hacking a hand-made configure script.
>
> OK, you half-convinced me. The other half came from a recent
> series of patches to try using 'which' to detect executables,
> which is another common mistake handcrafted configure script
> makes, which autoconf people have solved for us long time ago.
Good! In fact, I have been a moderate autoconf fan and originally I have
meant the hand-crafted ./configure script partially just as a tease and
a nominal competitor for the autoconf one, so that we would for sure got
_some_ autoconfiguration mechanism (which is what I care about).
I have to admit that I have grown somewhat attached to my script over
time and I like it a lot more than the autoconf thing personally, but
then again I had no idea that we actually want to support such systems
like those with broken which...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Ryan Anderson @ 2006-07-09 22:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff, Ryan Anderson, git
In-Reply-To: <20060709221326.GU29115@pasky.or.cz>
On Mon, Jul 10, 2006 at 12:13:26AM +0200, Petr Baudis wrote:
> Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter
> where Martin Langhoff <martin.langhoff@gmail.com> said that...
> > So I have to ask... what are the expected benefits of the move?
>
> I've been meaning to do something like this for some time already; my
> itch have been the builtins. The tree size _is_ getting out of hand and
> a little more categorization of the sources would certainly help.
That's what I was thinking, as well, basically. I started with the "scm
interop" tools because they should be the least controversial to move
around.
> Although I'd take a different approach:
>
> libgit/
> builtin/
> standalone/
> scripts/
>
> > In any case, use /interop instead. /scm in the tree of an SCM could be
> > anything ;-)
>
> I agree on this point.
Very good point.
So these seem obvious to me:
libgit/ (maybe just lib/?)
builtin/
interop/
I'm less sure of the rest, but I'll poke at doing the above for the
moment, and worry about the rest later.
Comments on a way to make the Makefile less repetitive would be
appreciated, though.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: What *have* I done?
From: Nix @ 2006-07-09 22:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060709212113.GS29115@pasky.or.cz>
On Sun, 9 Jul 2006, Petr Baudis yowled:
> Hi,
>
> Dear diary, on Sun, Jul 09, 2006 at 12:48:22AM CEST, I got a letter
> where Nix <nix@esperi.org.uk> said that...
>> loki 593 /usr/packages/linux/linux% cg-diff | diffstat
>
> Note that cg-diff -s might be useful.
Indeed :)
>> loki 594 /usr/packages/linux/linux% cg-reset
>> loki 595 /usr/packages/linux/linux% cg-diff
>> loki 596 /usr/packages/linux/linux%
>
> ...but when you switch away and switch back, the uncommitted changes
> appear again?
Yes.
> Just in case, don't the tree happen to simply stay the same as in the
> branch you switched from? (Try cg-diff -r yourpreviousbranch.)
Yes. Also, that branch (which was forked recently from the misbehaving
one) claims that all changes are merged from that branch, but this is
demonstrably untrue.
> And most importantly, does this also happen with just stock 0.17.3
> cg-switch? With stock master cg-switch? (If both is no, you probably
> forgot to cherrypick some associated cg-switch bugfix or something.)
This is 0.17.3 cg-switch plus the seek speedup 40f8a28806a1c5a7cb1f7d137f1bb271b71f890f.
(I doubt that's to blame, but I've been wrong before.)
I think the oddity is related to git-cherry-pick somehow, but I'm
not sure how: I took the original upstream pack again, rebuilt the
branches from scratch and now I can't make the problem happen anymore.
If it happens again I'll keep the tree around and collect more data.
(I'll have to dig some more disk space up...)
--
`She *is*, however, one of the few sf authors with a last name ending in O,
which adds some extra appeal to those of us who obsess about things like
having a book review of an author for each letter in the alphabet.' -- rra
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Timo Hirvonen @ 2006-07-09 22:34 UTC (permalink / raw)
To: pasky; +Cc: martin.langhoff, ryan, git
In-Reply-To: <20060709221326.GU29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> I've been meaning to do something like this for some time already; my
> itch have been the builtins. The tree size _is_ getting out of hand and
> a little more categorization of the sources would certainly help.
> Although I'd take a different approach:
>
> libgit/
> builtin/
> standalone/
> scripts/
Please don't. One directory is much easier to work with. At least
don't split the Makefile. Also moving files makes "git log <file>"
stop at the rename.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [BUGFIX][RESEND]git-cvsexportcommit can't handle merge commits correctly
From: Martin Langhoff (CatalystIT) @ 2006-07-09 23:12 UTC (permalink / raw)
To: Peter Baumann; +Cc: git, Junio C Hamano
In-Reply-To: <20060707105541.GA17004@xp.machine.xx>
Peter Baumann wrote:
> git-cvsexportcommit should check if the parent (supplied on the cmdline) to use
> for a merge commit is one of the real parents of the merge.
>
> But it errors out if the _first_ parent doesn't match and never checks
> the other parents.
>
Ack. Thanks for spotting this!
m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Ryan Anderson @ 2006-07-10 0:20 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: pasky, martin.langhoff, git
In-Reply-To: <20060710013405.54fbe6bb.tihirvon@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
Timo Hirvonen wrote:
> Petr Baudis <pasky@suse.cz> wrote:
>
>
>> I've been meaning to do something like this for some time already; my
>> itch have been the builtins. The tree size _is_ getting out of hand and
>> a little more categorization of the sources would certainly help.
>> Although I'd take a different approach:
>>
>> libgit/
>> builtin/
>> standalone/
>> scripts/
>>
>
> Please don't. One directory is much easier to work with. At least
> don't split the Makefile. Also moving files makes "git log <file>"
> stop at the rename.
>
By "don't split the Makefile", do mean, "Don't use recursive make"?
I'm fine with that (and if you look at my patch, I "include
scm/Makefile" to do just that), but if you mean "keep only a top-level
Makefile", well, I think that continues the problem of "there is too
much stuff going on here", but I can be persuaded otherwise.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix some doubled word typos
From: Alp Toker @ 2006-07-10 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <11524377844177-git-send-email-alp@atoker.com>
Alp Toker wrote:
> Signed-off-by: Alp Toker <alp@atoker.com>
> ---
> Documentation/git-svn.txt | 2 +-
> Documentation/urls.txt | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
My patch was made against the 'next' branch, where the file had recently
been moved to Documentation/git-svn.txt, but it was applied to the
'master' branch where the file still exists at
contrib/git-svn/git-svn.txt as it has not yet been moved.
As a result, it seems that only the modification to
Documentation/urls.txt in this patch made it into the repository, with
the fix to Documentation/git-svn.txt having been silently omitted.
By the time the commit was merged from 'master' to 'next', it had
permanently lost the modification to git-svn.txt, and even though the
commit message claims to "Fix some doubled word typos" it only fixes one.
Could this situation have been avoided if the patch had mentioned that
it was against the 'next' branch? Should/does git warn the user if a
patch modifies files that don't exist? Would rename tracking have helped
this patch to apply properly?
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Junio C Hamano @ 2006-07-10 0:39 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <20060709222308.GA4153@h4x0r5.com>
Ryan Anderson <ryan@michonline.com> writes:
> Comments on a way to make the Makefile less repetitive would be
> appreciated, though.
One obvious way would be not to have scm/Makefile but have the
dependencies in the main Makefile to say (the moral equivalent
of):
git-archimport.perl: scm/git-archimport.perl
^ permalink raw reply
* Re: [PATCH] Fix some doubled word typos
From: Junio C Hamano @ 2006-07-10 0:50 UTC (permalink / raw)
To: Alp Toker; +Cc: git
In-Reply-To: <44B1A01F.5090408@atoker.com>
Alp Toker <alp@atoker.com> writes:
> My patch was made against the 'next' branch, where the file had
> recently been moved to Documentation/git-svn.txt, but it was applied
> to the 'master' branch where the file still exists at
> contrib/git-svn/git-svn.txt as it has not yet been moved.
Actually, I am a bit more careful than that ;-).
I have split your patch into two, and applied the part that
applicable to "master" first. The tip of ew/svn topic branch (I
do not publish topic branch tips) have two patches that are
still not in even "pu", and one of these two patches is your
Documentation/git-svn.txt patch. These two will appear in
"next" hopefully soon -- I just haven't gotten around to them.
^ permalink raw reply
* Re: [PATCH] Fix some doubled word typos
From: Alp Toker @ 2006-07-10 1:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodvye10h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Actually, I am a bit more careful than that ;-).
>
> I have split your patch into two, and applied the part that
> applicable to "master" first. The tip of ew/svn topic branch (I
> do not publish topic branch tips) have two patches that are
> still not in even "pu", and one of these two patches is your
> Documentation/git-svn.txt patch. These two will appear in
> "next" hopefully soon -- I just haven't gotten around to them.
I hadn't realised that git-svn work was happening on a topic branch. In
light of that, it makes perfect sense to split out the commit as you
did. It's good to hear that git isn't just truncating patches.
Cheers.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox