* stgit restrictions on patch names
From: Yann Dirson @ 2007-10-25 19:48 UTC (permalink / raw)
To: Catalin Marinas, Karl Hasselström; +Cc: GIT list
Looks like stgit is now more picky on patch names than in used to be:
$ stg branch --clone v2.0.6-debian
Checking for changes in the working directory ... done
Cloning current branch to "v2.0.6-debian" ...
No log for 01_springelectrical
stg branch: Invalid patch name: "10_g++4.0_build_failures"
$
=> the result of the cloning operation is a partial clone. Do we want to:
- implement a mechanism for checking beforehand that the operation
will not fail ? Seems awkward to duplicate checks already found
elsewhere.
- wait for proper transactions so we can rollback on error ?
- on clone error, delete the newly-created stack ? I'd vote for this
one, until the previous one gets done.
=> is there any particular reason why we would refuse "+" ?
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued
From: Andreas Ericsson @ 2007-10-25 20:08 UTC (permalink / raw)
To: Federico Mena Quintero; +Cc: Theodore Tso, git
In-Reply-To: <1193335339.4522.398.camel@cacharro.xalalinux.org>
Federico Mena Quintero wrote:
> On Thu, 2007-10-25 at 11:21 -0400, Theodore Tso wrote:
>
>> And of course it's inelegant. You just told us we were dealing with
>> CVS-brain-damaged corporate developers who can't be bothered to learn
>> about the fine points of using things the git way.
>
> Ignore the corporate developers who use SCMs only because their company
> requires them to. Git is not the right thing for them;
Quite contrary to what I think, and quite contrary to what Linus said in
his google speach. The problem with using a chainsaw instead of a tooth-
pick is that it's much easier to hurt yourself with a chainsaw. It's a
lot easier to get real work done though.
> some
> Eclipse-based monstrosity probably is. It's like the horrendous
> Oracle-based expense-reporting thing we have to use at Novell; I use it
> because they make me, not because I'm particularly excited about
> reporting expenses :)
>
Nobody's particularly excited about reporting expenses. That's why there
are so few OSS solutions for it, and the ones that exist suck horribly
because whoever got the job of making the system knew his users would
simply hate it, no matter how perfect it was. It's one of those things ;-)
> However, *do think* of the free software developers who have been using
> CVS forever. You won't make friends among them if you keep saying, "you
> use CVS? You are brain-damaged, then." CVS has been as good/bad to
> them as to anyone else, and they are probably delighted to get a better
> solution. That solution needs to take into account the concepts to
> which they have been exposed for the past N years. Just because your
> new concepts are better, doesn't mean that their old ones were wrong in
> their time.
>
Well, perhaps they were. CVS was a fairly important learning phase, much
like Thomas Edison who first discovered 2000 ways of not making a light-
bulb. It doesn't make them less valuable though, and the reason to keep
going until perfection is reached is that machines are made for work, and
humans are made for fun.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Fix generation of perl/perl.mak
From: Alex Riesen @ 2007-10-25 20:17 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The code generating perl/Makefile from Makefile.PL was causing trouble
because it didn't considered NO_PERL_MAKEMAKER and ran makemaker
unconditionally, rewriting perl.mak. Makemaker is FUBAR in ActiveState Perl,
and perl/Makefile has a replacement for it.
Besides, a changed Git.pm is *NOT* a reason to rebuild all the perl scripts,
so remove the dependency too.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Makefile | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index b728920..72f5ef4 100644
--- a/Makefile
+++ b/Makefile
@@ -812,7 +812,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
-perl/perl.mak: GIT-CFLAGS
+perl/perl.mak: GIT-CFLAGS perl/Makefile perl/Makefile.PL
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' $(@F)
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
@@ -931,10 +931,6 @@ $(XDIFF_LIB): $(XDIFF_OBJS)
$(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(XDIFF_OBJS)
-perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
- (cd perl && $(PERL_PATH) Makefile.PL \
- PREFIX='$(prefix_SQ)')
-
doc:
$(MAKE) -C Documentation all
--
1.5.3.4.403.g401f6
^ permalink raw reply related
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-25 20:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Johannes Schindelin, Steffen Prohaska,
Peter Baumann, J. Bruce Fields, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <7vejfj11tk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>> However, there's still this issue:
>> $ git checkout -b foo origin/pu
>> Branch foo set up to track remote branch refs/remotes/origin/pu.
>> Switched to a new branch "foo"
>>
>> git checkout will say that every time a branch is created from a
>> tracking branch, unless one tells it --no-track (which people don't
>> learn about unless they're really into git), so it's quite natural
>> that people think git will actually make sure, within reasonable
>> limits, that 'foo' is kept in sync with refs/remotes/origin/pu.
>> That's not the case, however.
>>
>> So we could either change the message to be:
>> "Branch foo set up to track remote branch refs/remotes/origin/pu,
>> provided you only ever issue git-pull while having branch foo
>> checked out."
>>
>> Or we could make 'git checkout -b' default to --no-track, perhaps
>> giving annoying messages everytime someone "git-checkout -b"'s a
>> remote tracking branch.
>> Or we could make git-pull keep git checkout's promises.
>
> The thing is, if you have 200 local branches (because you
> interact with 50 repositories with 4 primary branches each), you
> do not constantly check all of them out anyway. And the only
> place that staleness of the local tracking fork matters is when
> you check it out (that is, as long as you train your users that
> the way to check differences with the upstream 'pu' in your case
> is by doing operations with 'origin/pu' not with your local
> 'foo').
>
Probably, although I think the confusion of 'foo' being something
else than 'origin/pu' after it's been checked out would be hard
to explain. I'll see how the patch turns out. If it all goes tits
up, I'll see if a post-checkout hook can solve it.
> With that in mind, how about making "git checkout foo", after
> foo is set up thusly, to show:
>
> git log --pretty=oneline --left-right origin/pu...foo
>
> if (and only if) they have diverged? Then you can deal with the
> staleness of local tracking fork 'foo' in any way you want.
>
> You could even go one step further and make this "checkout foo",
> in addition to or instead of showing the above left-right log,
>
> - automatically run "git merge origin/pu" if it is a
> fast-forward, and say it did _not_ run that merge if it is
> not a fast-forward;
>
> - automatically run "git merge origin/pu" always, even if it is
> not a fast-forward;
>
> - automatically run "git rebase origin/pu" always;
>
> Would that make your life easier?
That it would, except the confusion would then be that it's automatically
rebased for the branches one currently hasn't got checked out while pulling,
and the branch that *is* checked out gets merged (crazy, yes), so those
who prefer the rebase would get what they want by doing something completely
bonkers, such as:
git checkout -b just-gonna-pull HEAD^
git pull
git checkout whatever-other-branch-they-were-on
(yes, "aggresively ignorant", I think Ted said in an earlier mail)
It'd probably be better to go with Dscho's suggestion, although I'm not quite
sure what that was any more. It involved automagical rebasing on fetch or pull
though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued
From: Andreas Ericsson @ 2007-10-25 20:19 UTC (permalink / raw)
To: Federico Mena Quintero; +Cc: J. Bruce Fields, git
In-Reply-To: <1193335562.4522.403.camel@cacharro.xalalinux.org>
Federico Mena Quintero wrote:
> On Thu, 2007-10-25 at 12:38 -0400, J. Bruce Fields wrote:
>
>> It's definitely not a simple cut-and-paste--even with permission from
>> the author of "Git for computer scientists", fitting this in would
>> require rethinking the ordering of topics in the manual.
>
> Oh, that can be done. It's easier to move text around than to
> rearchitect code :)
>
It misses the point though. Machines should work while humans are
lounging. If the humans have to read a lot to get the machines to
work, there's less time for lounging ;-)
>> Also, there's
>> the restriction that we'd like to keep it looking good in plain ascii,
>> so diagrams have to be done in ascii somehow.
>
> Hmm, what's the rationale for this? I'd assume that most people read
> the user's manual as a web page (or as bedside reading if they can print
> a PDF thereof), where diagrams can be pretty.
>
man pages.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 5/6] Do linear-time/space rename logic for exact renames
From: Daniel Barkalow @ 2007-10-25 20:23 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <20071025194859.GB27745@coredump.intra.peff.net>
On Thu, 25 Oct 2007, Jeff King wrote:
> On Thu, Oct 25, 2007 at 03:43:46PM -0400, Daniel Barkalow wrote:
>
> > Creating a list of the pointers doesn't work correctly with the grow
> > implementation, because growing the hash may turn a collision into a
> > non-collision, at which point items other than the first cannot be found
> > (since they're listed inside a bucket that's now wrong for them). AFAIK,
> > resizing a hash table requires being able to figure out what happened with
> > collisions.
>
> I thought this at first, too, but there are two types of collisions in
> this hash implementation: those that come from having the actual 32-bit
> hash collide, and those that come from not having enough buckets.
>
> The client code gets a pointer kicked back to it when there is a
> collision on the actual hash value (i.e., two things had the exact same
> hash value). The number of buckets grows when you simply have more
> buckets filled than you like. Two different hashes that would be in the
> same bucket don't actually occupy the same bucket -- the second one to
> arrive gets shoved into the next available bucket.
Ah, right, nevermind. The comment might be a bit misleading in that case,
if we both missed this at first.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Andreas Ericsson @ 2007-10-25 20:23 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Karl Hasselström, Randal L. Schwartz, git
In-Reply-To: <alpine.LFD.0.9999.0710251344220.22100@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 25 Oct 2007, Karl Hasselström wrote:
>
>> On 2007-10-25 07:32:36 -0700, Randal L. Schwartz wrote:
>>
>>> And when are we gonna get "fast forward only" for git-merge?
>> I'd like that too. For cases when I know I don't have to do a merge,
>> and want git to yell at me if I'm mistaken. For example, in a
>> repository that tracks an upstream so I can build the latest version,
>> but where I don't normally do any development.
>
> Isn't that called a remote branch that gets updated with "git fetch' ?
> You can even trick Git into not using the refs/remotes/ namespace for
> them if you wish.
>
You'd lose the ability to do "git diff origin/master" while disconnected
though. It's quite valuable.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 5/6] Do linear-time/space rename logic for exact renames
From: Linus Torvalds @ 2007-10-25 20:25 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710251522190.7345@iabervon.org>
On Thu, 25 Oct 2007, Daniel Barkalow wrote:
>
> Creating a list of the pointers doesn't work correctly with the grow
> implementation, because growing the hash may turn a collision into a
> non-collision, at which point items other than the first cannot be found
> (since they're listed inside a bucket that's now wrong for them). AFAIK,
> resizing a hash table requires being able to figure out what happened with
> collisions.
Nope.
The hash algorithm is much smarter than that.
I *always* uses a full 32-bit hash, and no amount of resizing is ever
going to change that. The index into the hash-table is in fact entirely
unused.
This has several good properties:
- it means that hash-table resizing is a non-event
- it means that you always have the full 32-bit hash, and a collision in
the hash size never causes unnecessary work apart from the fact that
the code walks the hash table a bit more.
- because the hash is embedded in the table itself, it has relatively
good cache behaviour when compared to something that needs to actually
follow the pointer to validate the full data. So assuming that the full
32-bit hash is good enough to effectively never have any collisions
(or, assuming you don't even *care* about the collisions, which is the
case when you're just generating content fingerprints for lines when
comparing the data in two files), you never end up with unnecessarily
following pointers to cachelines that you are not interested in.
The last point at least somewhat mitigates the (inevitably) bad cache
behaviour that hash tables tend to have. It's not like it's going to be
wonderful in the cache, but at least it's less horrid than the more common
implementation that needs to follow the pointer to validate each hash
entry that may or may not be a collision.
but the important part is #1, which is what allows the code to be a
generic hash algorithm that resizes the hash table without even
understanding or caring what is behind the pointer.
Linus
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinishedsummary continued
From: J. Bruce Fields @ 2007-10-25 20:27 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Federico Mena Quintero, git
In-Reply-To: <4720FA6E.9040805@op5.se>
On Thu, Oct 25, 2007 at 10:19:58PM +0200, Andreas Ericsson wrote:
> Federico Mena Quintero wrote:
>> On Thu, 2007-10-25 at 12:38 -0400, J. Bruce Fields wrote:
>>> Also, there's
>>> the restriction that we'd like to keep it looking good in plain ascii,
>>> so diagrams have to be done in ascii somehow.
>> Hmm, what's the rationale for this? I'd assume that most people read
>> the user's manual as a web page (or as bedside reading if they can print
>> a PDF thereof), where diagrams can be pretty.
>
> man pages.
I think he's talking about Documentation/user-manual.txt, which isn't
turned into man pages. (Might be nice if it could be though, I
suppose.)
--b.
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Nicolas Pitre @ 2007-10-25 20:38 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Karl Hasselström, Randal L. Schwartz, git
In-Reply-To: <4720FB4E.3030300@op5.se>
On Thu, 25 Oct 2007, Andreas Ericsson wrote:
> Nicolas Pitre wrote:
> > Isn't that called a remote branch that gets updated with "git fetch' ?
> > You can even trick Git into not using the refs/remotes/ namespace for them
> > if you wish.
> >
>
> You'd lose the ability to do "git diff origin/master" while disconnected
> though. It's quite valuable.
I don't see how you'd lose anything.
Nicolas
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Andreas Ericsson @ 2007-10-25 20:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Karl Hasselström, Randal L. Schwartz, git
In-Reply-To: <alpine.LFD.0.9999.0710251637240.22100@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 25 Oct 2007, Andreas Ericsson wrote:
>
>> Nicolas Pitre wrote:
>>> Isn't that called a remote branch that gets updated with "git fetch' ?
>>> You can even trick Git into not using the refs/remotes/ namespace for them
>>> if you wish.
>>>
>> You'd lose the ability to do "git diff origin/master" while disconnected
>> though. It's quite valuable.
>
> I don't see how you'd lose anything.
>
Sorry, I thought you were talking about a config along the lines of:
fetch = refs/heads/*:refs/heads/*
What other trick are you talking about?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Fix generation of perl/perl.mak
From: Johannes Schindelin @ 2007-10-25 20:42 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20071025201724.GA11308@steel.home>
Hi,
On Thu, 25 Oct 2007, Alex Riesen wrote:
> Besides, a changed Git.pm is *NOT* a reason to rebuild all the perl
> scripts, so remove the dependency too.
>
> [...]
>
> @@ -931,10 +931,6 @@ $(XDIFF_LIB): $(XDIFF_OBJS)
> $(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(XDIFF_OBJS)
>
>
> -perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
> - (cd perl && $(PERL_PATH) Makefile.PL \
> - PREFIX='$(prefix_SQ)')
> -
This is not really the dependency triggering a rebuild of all perl
scripts, right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix generation of perl/perl.mak
From: Alex Riesen @ 2007-10-25 21:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0710252140500.4362@racer.site>
Johannes Schindelin, Thu, Oct 25, 2007 22:42:07 +0200:
> On Thu, 25 Oct 2007, Alex Riesen wrote:
>
> > Besides, a changed Git.pm is *NOT* a reason to rebuild all the perl
> > scripts, so remove the dependency too.
> >
> > [...]
> >
> > -perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
> > - (cd perl && $(PERL_PATH) Makefile.PL \
> > - PREFIX='$(prefix_SQ)')
> > -
>
> This is not really the dependency triggering a rebuild of all perl
> scripts, right?
In a way. This rebuilds perl/perl.mak which, in turn, can cause the
rebuild of all perl scripts. The rule you replaced with "[...]" does
the same, but uses perl/Makefile, which generates the perl.mak
depending on the NO_PERL_MAKEMAKER setting.
^ permalink raw reply
* Re: git apply fails to apply a renamed file in a new directory
From: Alex Riesen @ 2007-10-25 21:30 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20071025180737.GA13829@uranus.ravnborg.org>
Sam Ravnborg, Thu, Oct 25, 2007 20:07:37 +0200:
> I just stumbled on what looks like a simple bug in git apply.
> I had following diff:
>
> diff --git a/arch/i386/defconfig b/arch/x86/configs/i386_defconfig
> similarity index 100%
> rename from arch/i386/defconfig
> rename to arch/x86/configs/i386_defconfig
> diff --git a/arch/x86_64/defconfig b/arch/x86/configs/x86_64_defconfig
> similarity index 100%
> rename from arch/x86_64/defconfig
> rename to arch/x86/configs/x86_64_defconfig
> --
> 1.5.3.4.1157.g0e74-dirty
>
> When trying to apply this diff using:
> git apply -p1 < .../patch
works here. Don't use -p1, it is assumed
^ permalink raw reply
* Re: git apply fails to apply a renamed file in a new directory
From: Alex Riesen @ 2007-10-25 21:35 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20071025213038.GC11308@steel.home>
Alex Riesen, Thu, Oct 25, 2007 23:30:38 +0200:
> Sam Ravnborg, Thu, Oct 25, 2007 20:07:37 +0200:
> > I just stumbled on what looks like a simple bug in git apply.
> > I had following diff:
> >
> > diff --git a/arch/i386/defconfig b/arch/x86/configs/i386_defconfig
> > similarity index 100%
> > rename from arch/i386/defconfig
> > rename to arch/x86/configs/i386_defconfig
> > diff --git a/arch/x86_64/defconfig b/arch/x86/configs/x86_64_defconfig
> > similarity index 100%
> > rename from arch/x86_64/defconfig
> > rename to arch/x86/configs/x86_64_defconfig
> > --
> > 1.5.3.4.1157.g0e74-dirty
.1157...-dirty. Your git looks heavily modified. Could you try with a
something like master of kernel.org?
Mine is based off d90a7fda355c251b8ffdd79617fb083c18245ec2
(builtin-fetch got merged).
> > When trying to apply this diff using:
> > git apply -p1 < .../patch
>
> works here. Don't use -p1, it is assumed
>
^ permalink raw reply
* Re: [PATCH 5/6] Do linear-time/space rename logic for exact renames
From: Daniel Barkalow @ 2007-10-25 21:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0710251317020.30120@woody.linux-foundation.org>
On Thu, 25 Oct 2007, Linus Torvalds wrote:
> On Thu, 25 Oct 2007, Daniel Barkalow wrote:
> >
> > Creating a list of the pointers doesn't work correctly with the grow
> > implementation, because growing the hash may turn a collision into a
> > non-collision, at which point items other than the first cannot be found
> > (since they're listed inside a bucket that's now wrong for them). AFAIK,
> > resizing a hash table requires being able to figure out what happened with
> > collisions.
>
> Nope.
>
> The hash algorithm is much smarter than that.
Ah, yes. I was just confused by the comment suggesting the possibility of
a collision when the only way to have two calls get the same bucket is
when the key that the library gets is actually identical.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git apply fails to apply a renamed file in a new directory
From: Sam Ravnborg @ 2007-10-25 21:41 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071025213523.GD11308@steel.home>
On Thu, Oct 25, 2007 at 11:35:23PM +0200, Alex Riesen wrote:
> Alex Riesen, Thu, Oct 25, 2007 23:30:38 +0200:
> > Sam Ravnborg, Thu, Oct 25, 2007 20:07:37 +0200:
> > > I just stumbled on what looks like a simple bug in git apply.
> > > I had following diff:
> > >
> > > diff --git a/arch/i386/defconfig b/arch/x86/configs/i386_defconfig
> > > similarity index 100%
> > > rename from arch/i386/defconfig
> > > rename to arch/x86/configs/i386_defconfig
> > > diff --git a/arch/x86_64/defconfig b/arch/x86/configs/x86_64_defconfig
> > > similarity index 100%
> > > rename from arch/x86_64/defconfig
> > > rename to arch/x86/configs/x86_64_defconfig
> > > --
> > > 1.5.3.4.1157.g0e74-dirty
>
> .1157...-dirty. Your git looks heavily modified. Could you try with a
> something like master of kernel.org?
I guess I still have Linus' rename stuff added - will update.
>
> Mine is based off d90a7fda355c251b8ffdd79617fb083c18245ec2
> (builtin-fetch got merged).
>
> > > When trying to apply this diff using:
> > > git apply -p1 < .../patch
> >
> > works here. Don't use -p1, it is assumed
> >
It seems to be a picnic[*] bug - at least I cannot reproduce it.
Sorry for the noise but thanks for testing.
[*] Problem In Chair Not In Computer
Sam
^ permalink raw reply
* Re: git-svnimport
From: Steven Walter @ 2007-10-25 22:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Felipe Balbi, git
In-Reply-To: <Pine.LNX.4.64.0710251403160.25221@racer.site>
On Thu, Oct 25, 2007 at 02:04:29PM +0100, Johannes Schindelin wrote:
> FYI you'll have to do something like this:
>
> git svn init svn://busybox.net/trunk/busybox
> git svn fetch
>
> to merge with current busybox (although I updated before I pushed).
More than that, you'll want to:
git svn init <foo>
cp .git/refs/remotes/origin/master .git/refs/remotes/git-svn
git svn fetch
If git-svn doesn't find a remote named "git-svn" it will assume that it
has no information about the repository and starting doing a full
checkout. By copying the ref, git-svn will see that there are already
commits with git-svn-id lines and rebuild its "rev-db". After that, it
will incrementally update for newer revisions.
That ought to save you a few precious minutes :)
--
-Steven Walter <stevenrwalter@gmail.com>
Freedom is the freedom to say that 2 + 2 = 4
B2F1 0ECC E605 7321 E818 7A65 FC81 9777 DC28 9E8F
^ permalink raw reply
* Re: git-svnimport
From: Johannes Schindelin @ 2007-10-25 22:22 UTC (permalink / raw)
To: Steven Walter; +Cc: Felipe Balbi, git
In-Reply-To: <20071025222029.GA11677@dervierte>
Hi,
On Thu, 25 Oct 2007, Steven Walter wrote:
> On Thu, Oct 25, 2007 at 02:04:29PM +0100, Johannes Schindelin wrote:
> > FYI you'll have to do something like this:
> >
> > git svn init svn://busybox.net/trunk/busybox
> > git svn fetch
> >
> > to merge with current busybox (although I updated before I pushed).
>
> More than that, you'll want to:
>
> git svn init <foo>
> cp .git/refs/remotes/origin/master .git/refs/remotes/git-svn
> git svn fetch
>
> If git-svn doesn't find a remote named "git-svn" it will assume that it
> has no information about the repository and starting doing a full
> checkout. By copying the ref, git-svn will see that there are already
> commits with git-svn-id lines and rebuild its "rev-db". After that, it
> will incrementally update for newer revisions.
>
> That ought to save you a few precious minutes :)
Good catch. Thanks.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Teach 'git pull' the '--rebase' option
From: Johannes Schindelin @ 2007-10-25 22:54 UTC (permalink / raw)
To: git, gitster
When calling 'git pull' with the '--rebase' option, it performs a
fetch + rebase instead of a fetch + pull.
This behavior is more desirable than fetch + pull when a topic branch
is ready to be submitted.
fetch + rebase might also be considered a better workflow with shared
repositories in any case, or for contributors to a centrally managed
project, such as Wine -- or Git.
For your convenience, you can set the default behavior for a branch by
defining the config variable branch.<name>.rebase, which is
interpreted as a bool. This setting can be overridden on the command
line by --rebase and --no-rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/git-pull.txt | 6 ++++++
git-pull.sh | 11 ++++++++++-
t/t5520-pull.sh | 22 ++++++++++++++++++++++
3 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index e1eb2c1..c3ce8ee 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -33,6 +33,12 @@ include::urls-remotes.txt[]
include::merge-strategies.txt[]
+\--rebase::
+ Instead of a merge, perform a rebase after fetching.
+
+\--no-rebase::
+ Override earlier \--rebase.
+
DEFAULT BEHAVIOUR
-----------------
diff --git a/git-pull.sh b/git-pull.sh
index 74bfc16..b5ecb80 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,6 +16,9 @@ test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
strategy_args= no_summary= no_commit= squash=
+curr_branch=$(git symbolic-ref -q HEAD)
+curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
+rebase=$(git config --bool branch.$curr_branch_short.rebase)
while :
do
case "$1" in
@@ -43,6 +46,12 @@ do
esac
strategy_args="${strategy_args}-s $strategy "
;;
+ -r|--r|--re|--reb|--reba|--rebas|--rebase)
+ rebase=true
+ ;;
+ --no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
+ rebase=false
+ ;;
-h|--h|--he|--hel|--help)
usage
;;
@@ -86,7 +95,6 @@ merge_head=$(sed -e '/ not-for-merge /d' \
case "$merge_head" in
'')
- curr_branch=$(git symbolic-ref -q HEAD)
case $? in
0) ;;
1) echo >&2 "You are not currently on a branch; you must explicitly"
@@ -133,5 +141,6 @@ then
fi
merge_name=$(git fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
+test true = "$rebase" && exec git-rebase $merge_head
exec git-merge $no_summary $no_commit $squash $strategy_args \
"$merge_name" HEAD $merge_head
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 93eaf2c..52b3a0c 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -53,4 +53,26 @@ test_expect_success 'the default remote . should not break explicit pull' '
test `cat file` = modified
'
+test_expect_success '--rebase' '
+ git branch to-rebase &&
+ echo modified again > file &&
+ git commit -m file file &&
+ git checkout to-rebase &&
+ echo new > file2 &&
+ git add file2 &&
+ git commit -m "new file" &&
+ git tag before-rebase &&
+ git pull --rebase . copy &&
+ test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
+ test new = $(git show HEAD:file2)
+'
+
+test_expect_success 'branch.to-rebase.rebase' '
+ git reset --hard before-rebase &&
+ git config branch.to-rebase.rebase 1 &&
+ git pull . copy &&
+ test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
+ test new = $(git show HEAD:file2)
+'
+
test_done
--
1.5.3.4.1351.gee906
^ permalink raw reply related
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Linus Torvalds @ 2007-10-25 23:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0710252351130.4362@racer.site>
On Thu, 25 Oct 2007, Johannes Schindelin wrote:
>
> This behavior is more desirable than fetch + pull when a topic branch
> is ready to be submitted.
I'd like there to be some *big*warning* about how this destroys history
and how you must not do this if you expose your history anywhere else.
I think it's a perfectly fine history, but if you have already pushed out
your history somewhere else, you're now really screwed. In ways that a
*real* merge will never screw you.
So the "--rebase" option really is only good for the lowest-level
developers. And that should be documented.
Linus
^ permalink raw reply
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Johannes Schindelin @ 2007-10-25 23:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, gitster
In-Reply-To: <alpine.LFD.0.999.0710251602160.30120@woody.linux-foundation.org>
Hi,
On Thu, 25 Oct 2007, Linus Torvalds wrote:
> On Thu, 25 Oct 2007, Johannes Schindelin wrote:
> >
> > This behavior is more desirable than fetch + pull when a topic branch
> > is ready to be submitted.
>
> I'd like there to be some *big*warning* about how this destroys history
> and how you must not do this if you expose your history anywhere else.
>
> I think it's a perfectly fine history, but if you have already pushed out
> your history somewhere else, you're now really screwed. In ways that a
> *real* merge will never screw you.
>
> So the "--rebase" option really is only good for the lowest-level
> developers. And that should be documented.
Fair enough.
How about this in the man page:
\--rebase::
Instead of a merge, perform a rebase after fetching.
*NOTE:* Never do this on branches you plan to publish! This
command will _destroy_ history, and is thus only suitable for
topic branches to be submitted to another committer.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Linus Torvalds @ 2007-10-25 23:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0710260007450.4362@racer.site>
On Fri, 26 Oct 2007, Johannes Schindelin wrote:
>
> \--rebase::
> Instead of a merge, perform a rebase after fetching.
> *NOTE:* Never do this on branches you plan to publish! This
> command will _destroy_ history, and is thus only suitable for
> topic branches to be submitted to another committer.
Well, it really needs explanation of what "destroy" means.
Also, it's not strictly even necessary to publish things for this to cause
problems. It's perfectly sufficient to just do development on two private
developer machines, and do things like keeping the two machines in sync by
pulling things between them manually...
So even "normal" developers who never publish a git tree to others may
actually hit this issue.
Linus
^ permalink raw reply
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Linus Torvalds @ 2007-10-25 23:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.LFD.0.999.0710251634200.30120@woody.linux-foundation.org>
On Thu, 25 Oct 2007, Linus Torvalds wrote:
> Also, it's not strictly even necessary to publish things for this to cause
> problems. It's perfectly sufficient to just do development on two private
> developer machines, and do things like keeping the two machines in sync by
> pulling things between them manually...
.. or any branch use, for that matter.
I do agree that "git merge --rebase" is potentially convenient, I'm just
not sure it's a great idea to document as such. People shouldn't do it
unless they really *really* understand the implications, and I think the
implications are much easier to understand if you instead teach them
"fetch+rebase", and perhaps even keep the "merge --rebase" option entirely
undocumented.
Linus
^ permalink raw reply
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Junio C Hamano @ 2007-10-25 23:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git, gitster
In-Reply-To: <Pine.LNX.4.64.0710260007450.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 25 Oct 2007, Linus Torvalds wrote:
>
>> On Thu, 25 Oct 2007, Johannes Schindelin wrote:
>> >
>> > This behavior is more desirable than fetch + pull when a topic branch
>> > is ready to be submitted.
>>
>> I'd like there to be some *big*warning* about how this destroys history
>> and how you must not do this if you expose your history anywhere else.
>>
>> I think it's a perfectly fine history, but if you have already pushed out
>> your history somewhere else, you're now really screwed. In ways that a
>> *real* merge will never screw you.
>>
>> So the "--rebase" option really is only good for the lowest-level
>> developers. And that should be documented.
>
> Fair enough.
>
> How about this in the man page:
>
> \--rebase::
> Instead of a merge, perform a rebase after fetching.
> *NOTE:* Never do this on branches you plan to publish! This
> command will _destroy_ history, and is thus only suitable for
> topic branches to be submitted to another committer.
Nits.
(1) This "operation" will "rewrite" history.
You are not describing a command, but just one mode of operation
of a command, whose other modes of operation do not share this
history altering behaviour.
The history is rewritten and made hard to work with for others
who have previous incarnation of that history. If it happens
that nobody shared that previously published history nobody
needs to suffer. In that sense, there is something _usable_
depending on who you are. Destroy feels a bit too strong a
word.
(2) This is not suitable for people who publish their trees and
let others fetch and work off of them.
Rebase is fine for e-mail submitting contributors as your
description above suggests, but as your proposed commit log
message said, it is also perfectly appropriate if your
interaction with the outside world is "fetch + rebase +
push". You are not limited to "submitted to another
committer".
^ 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