* Re: Unable to checkout a particular SVN revision
From: Daniele Segato @ 2009-11-29 16:50 UTC (permalink / raw)
To: Marc Liyanage; +Cc: git
In-Reply-To: <718EEBA2-FA4B-402D-B2FC-A8F14D79F6FF@entropy.ch>
Il giorno ven, 27/11/2009 alle 18.05 -0800, Marc Liyanage ha scritto:
> I'm trying to clone a specific SVN revision with git-svn:
>
> git svn clone -r 12345 https://host/svn/foo/branches/bar xyz
>
> but it doesn't check out any files, I see just this:
>
> Initialized empty Git repository in /Users/liyanage/Desktop/xyz/.git
>
> If I try the same thing with SVN like this:
>
> svn co -r 12345 https://host/svn/foo/branches/bar xyz
>
> then I get what I expect, it checks out all the files and "svn info" gives me this revision.
>
>
> I think it's because this particular revision wasn't committed on this branch, i.e. it doesn't show up in "svn log". If I try a revision that is listed in the log, it works as expected.
>
>
> Is there a way to make this work?
You had to understand the difference between a distributed version
control system (git) and a centralized version control system (svn).
On SVN there is a central repository and all user checkout a SINGLE
revision at a time, if they want to switch to another revision/branch
they had to update the local files communicating with the central
repository (can't work offline)
On Git you clone the ENTIRE history of a repository and you keep it
(all) locally. If you want to switch to another "revision" or branch you
can do it locally without interacting over network with a remote
repository, if you want to commit you can do it locally and the first
time you got connected to the network you can push your change to the
remote repository and pull others changes.
Git-SVN is a tool that allow you to interact with an SVN repository
using Git as client: the cool thing is that you get a lot of the
features of a distributed repository even if you are interacting with a
centralized one.
The bad news is that cloning the first time is really really slow: this
is because SVN has not been wrote to support distributed repository and
is not optimized to allow cloning of all the history.
to made thinks clearer:
SVN:
svn checkout -r <revision> <url> # this connect to <url> and download
that revision locally
GIT:
git svn clone <url> -T trunk -t tags -b branches # this connect to <url>
and start from revision 1 to the last cloning all the repository
(supposing you have a standard SVN structure with trunk/tags/branches)
this could keep a lot of time if it is a big repository (even days)
but when it is done you can checkout any revision:
git checkout <your-revision-commit>
git doesn't store the history as SVN do, revision numbers does NOT make
sense in a distributed environment... it just keep revision numbars
inside commits comments.. so you'll first had to search your revision
number into the git log history and then checkout the corresponding
commit.
Git is NOT another SVN client, is a completely different way of doing
versioning and you had to understand this and stop trying to use git as
you use svn until now
^ permalink raw reply
* Re: What is the best way to backport a feature?
From: Pascal Obry @ 2009-11-29 16:52 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Peter Weseloh, git
In-Reply-To: <20091129164748.GB7921@atjola.homenet>
Le 29/11/2009 17:47, Björn Steinbrink a écrit :
> What's unusual there is that you merged from Mainline to Feature_A.
> Usually, the history would look like this:
Right, I missed that! It is indeed very unusual at the point that I
missed to read it properly :) So my reply is wrong.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: What is the best way to backport a feature?
From: Michael J Gruber @ 2009-11-29 17:02 UTC (permalink / raw)
To: Peter Weseloh; +Cc: git
In-Reply-To: <loom.20091129T164518-669@post.gmane.org>
Peter Weseloh venit, vidit, dixit 29.11.2009 17:28:
> Hi,
>
> Suppose I have the following situation:
>
> o--o--o Release_1.0
> / \ \
> o-o-o--o--o-o-o-o-o-o---o--o Mainline
> \ \ \ /
> F1--F2--M1--F3--M2 Feature_A
>
> Now I want to backport "Feature_A" to the "Release_1.0" branch so that it gets
> included into the next minor release, i.e. I want to apply the commits F1, F2
> and F3 onto the "Release_1.0" branch.
> I cannot just merge "Feature_A" into "Release_1.0" because that would also bring
> in the merges M1 and M2 so a lot of other stuff from the Mainline.
>
> I played with cherry-pick but that means I have to manually find the commits F1,
> F2 and F3 (which in reality could be many more if Feature_A is big) which is not
> very nice.
>
> I also tried 'rebase -i' but that means I have to manually delete all the lines
> for changesets from the mainline. Also not very nice.
>
> Is there a better way? To me this scenario sounds not unusual but I could not
> find a solution.
The problem is that you've been a bad boy to begin with ;)
Seriously, I suggest reading up on "topic branches". Feature_A should
have been based off the common merge base of Mainline and Release_1.0,
and, even more importantly, there should not have been any merges from
Mainline into Feature_A. So, that branch is not at all what one would
call a feature branch/topic branch. Hopefully, this scenario is very
uncommon :)
I assume you have to deal with the given structure anyhow, and merge
will not help. The only solution is to try and replay your Feature_A
commits on top of the release branch. (Since you have merged Feature_A
into Mainline already, you probabably don't want to redo that branch and
merge.)
I you have many commits to deal with I suggest finding a good
semi-automated way to list the commits you are after, such as git
rev-list --no-merges sha1..Feature_A (with sha1 being the fork point). A
good way to find out could be git log --no-merges sha1..Feature_A.
Then, try and cherry-pick those onto the release branch. Alternatively,
you can use format-patch/am, or in fact try with rebase (I thought it
would ignore merges), which basically does what cherry-pick does.
Cheers,
Michael
^ permalink raw reply
* Fwd: What is the best way to backport a feature?
From: Peter Weseloh @ 2009-11-29 17:45 UTC (permalink / raw)
To: git
In-Reply-To: <4db3b0200911290941j42c5a0aaq2c6a9836b38066b2@mail.gmail.com>
Hi Björn,
First of all thank you very much for your quick reply (actually my
thanks go to all that have replied so far).
Note that at the moment it is just a brain exercise. We are currently
using CVS (yes, I know) and want to switch to something else and I'm
trying to push for git. During our discussions this scenario came up
and I could not give a simple answer. That's why I thought I'd better
ask the experts.
> What's unusual there is that you merged from Mainline to Feature_A.
> Usually, the history would look like this:
>
> o--o--o Release_1.0
> / \ \
> o-o-o--o--o-o-o-o-o-o---o--o Mainline
> \ /
> F1-----F2------F3 Feature_A
>
> And then you could easily use rebase to get the job done.
But on the other hand the intermediate merges from the Mainline make
for much simpler merges, right?.
If merging is done only when Feature_A is ready it might become a real
pain. It might take several month to complete it and the mainline
might have changed a lot.
>
> Had you known beforehand that Feature_A is a candidate for backporting,
> you would have even branch from an older commit like this:
>
> o--o--o Release_1.0
> / \ \
> o-o-o--o--o-o-o-o-o-o---o--o Mainline
> \ /
> F1--------F2-------F3 Feature_A
>
>
> Then you could easily merge Feature_A to Release_1.0 as well, without
> merging anything unrelated.
>
> But that's just for the future...
>
Yes, sure. If I would know the future already today I would not need
to do any coding anymore :-) But seriously our policy is clear:
Bugfixes (and small enhancements) go to the release branch to end up
in the next minor release. The release branch gets merged with the
mainline so that it is always a superset. Big new features are
developed in seperated branches and are finaly merged to the mainline
to end up in the next major release. But every now and then the
managment is so excited about such a new feature that they want it in
the next minor release. That's life.
>
> Given you current history, you could use format-patch + am like this:
>
> git format-patch --stdout --first-parent Mainline..Feature_A > fa.mbox
> git checkout Release_1.0
> git am -3 fa.mbox
>
> The --first-parent options make it follow the first parent of the merge
> commits only, so the whole stuff on the Mainline branch is ignored. And
> you just get F1, F2 and F3 in fa.mbox, which you then apply using am.
>
Ah, great! I played with format-patch + am but missed the
'--first-parent' option. I will give it a try. Thanks a lot!
>
> A long time ago, I hacked the --first-parent thing into rebase, but (of
> course) the first iteration of the patch wasn't quite perfect and as
> I've not been scratching my own itch there, I never got around to
> actually polish the patch so it could get into git.git. Maybe you want
> to pick it up?
>
> http://thread.gmane.org/gmane.comp.version-control.git/62782
In case we go for git this might very well be the case.
>
> Björn
Peter
^ permalink raw reply
* Re: What is the best way to backport a feature?
From: Björn Steinbrink @ 2009-11-29 18:17 UTC (permalink / raw)
To: Peter Weseloh; +Cc: Peter Weseloh, Junio C Hamano, git
In-Reply-To: <4db3b0200911290941j42c5a0aaq2c6a9836b38066b2@mail.gmail.com>
On 2009.11.29 18:41:35 +0100, Peter Weseloh wrote:
> > What's unusual there is that you merged from Mainline to Feature_A.
> > Usually, the history would look like this:
> >
> > o--o--o Release_1.0
> > / \ \
> > o-o-o--o--o-o-o-o-o-o---o--o Mainline
> > \ /
> > F1-----F2------F3 Feature_A
> >
> > And then you could easily use rebase to get the job done.
>
> But on the other hand the intermediate merges from the Mainline make for
> much simpler merges, right?.
> If merging is done only when Feature_A is ready it might become a real pain.
That's usually more often true with CVS or SVN than with git, but ...
> It might take several month to complete it and the mainline might have
> changed a lot.
... over such a long timeframe, yes, things might become ugly. OTOH such
a long timeframe might also mean that the topic branch actually does too
much. Splitting such a large thing into more manageable pieces would
help there, as you could merge completed topic branch to your mainline
branch earlier and more often.
> > Had you known beforehand that Feature_A is a candidate for backporting,
> > you would have even branch from an older commit like this:
> >
> > o--o--o Release_1.0
> > / \ \
> > o-o-o--o--o-o-o-o-o-o---o--o Mainline
> > \ /
> > F1--------F2-------F3 Feature_A
> >
> > Then you could easily merge Feature_A to Release_1.0 as well, without
> > merging anything unrelated.
> >
> > But that's just for the future...
> >
> Yes, sure. If I would know the future already today I would not need to do
> any coding anymore :-)
I meant something like "I just said that, so you can avoid problems in
the future" ;-) But yeah, knowing beforehand that things should go into
a maintenance branch isn't common, unless it's about a bugfix.
> > Given you current history, you could use format-patch + am like this:
> >
> > git format-patch --stdout --first-parent Mainline..Feature_A > fa.mbox
> > git checkout Release_1.0
> > git am -3 fa.mbox
> >
> > The --first-parent options make it follow the first parent of the merge
> > commits only, so the whole stuff on the Mainline branch is ignored. And
> > you just get F1, F2 and F3 in fa.mbox, which you then apply using am.
> >
> >
> Ah, great! I played with format-patch + am but missed the '--first-parent'
> option. I will give it a try. Thanks a lot!
Well, it's a rev-list option, which might work by accident. Junio
recently said that the fact that format-patch accepts path limiting is
by accident, might be true for --first-parent as well... No clue. Junio?
Björn
^ permalink raw reply
* dead links on gitwiki Tools list
From: Kissaki @ 2009-11-29 18:21 UTC (permalink / raw)
To: git
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#BzrToGit
The link is dead.
Is there any other source for that tool?
Maybe someone can add it there.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-29 18:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, James Pickens, git
In-Reply-To: <alpine.DEB.1.00.0911291118280.4985@pacific.mpi-cbg.de>
On Sun, Nov 29, 2009 at 11:21:06AM +0100, Johannes Schindelin wrote:
> You continue to ignore that inconsistency -- even if it is introduced with
> the best of all intentions -- is bad, bad, bad.
>
> But I guess that I continue to get ignored,
Speaking of ignoring, you have never once responded to my repeated point
that I agree that inconsistency is bad, but it is about weighing that
bad against other bad things.
-Peff
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-29 18:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: James Pickens, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0911291121300.4985@pacific.mpi-cbg.de>
On Sun, Nov 29, 2009 at 11:28:27AM +0100, Johannes Schindelin wrote:
> > > > Yes, as a matter of fact, I do work on 10 different computers. I'm sorry
> > > > that you find managing your configuration so challenging. But if you
> > > > don't use the configuration variable, then your own personal setup is
> > > > totally irrelevant.
> > >
> > > As I just demonstrated, this is a false statement.
> >
> > I must have missed where you demonstrated it.
>
> Usually, my mails are minimal, and I do not write as many mails as I
> used to anymore, so it is hard to miss what I am saying.
>
> For your benefit: both Junio and me talked about experts helping users.
> Even if I do not use the config options, I am affected. And it does hurt.
A point which I adressed in my numbered point (2) in the mail you are
quoting above. But you didn't bother to quote that part.
> > When the number of "git grep" crash fatalities rises above zero, maybe
> > this line of reasoning will be relevant.
>
> Sure. Let's wait for the first crash fatality, and only react then. No
> need to think ahead.
You missed my point. My point is that your analogy had many
characteristics that do not apply to this situation. You are comparing a
situation where somebody's preference (to drive on the left side or the
right side) is weighed against a system where everyone needs to follow
the same rule, or people will die in large numbers. The actual situation
at hand is a git grep configuration variable. I am weighing the
preference of people who use git every day and want it to work in a
certain way against the possibility that somebody helping them will be
slightly inconvenienced or surprised. Something that will happen much
less frequently than the person actually _using_ git, and something
which has much smaller negative consequences than people dying.
> That's it. I don't think that I want to participate in this kind of
> discussion anymore,
Fine. I have made my point over and over, and not once have you
responded to it directly, so I also feel this is going nowhere.
-Peff
^ permalink raw reply
* Re: Fwd: What is the best way to backport a feature?
From: Johannes Sixt @ 2009-11-29 18:33 UTC (permalink / raw)
To: Peter Weseloh; +Cc: git
In-Reply-To: <4db3b0200911290945r34a73346w148ee42e59868876@mail.gmail.com>
[please keep the Cc list]
On Sonntag, 29. November 2009, Peter Weseloh wrote:
> But on the other hand the intermediate merges from the Mainline make
> for much simpler merges, right?.
> If merging is done only when Feature_A is ready it might become a real
> pain. It might take several month to complete it and the mainline
> might have changed a lot.
Incidentally, Junio has blogged about this just the other day:
http://gitster.livejournal.com/42247.html
Basically, as soon as you merge Mainline into Feature_A, you change the topic
of Feature_A from "Feature for Release_1.0" to "Feature for this Mainline".
Clearly, this topic is not suitable for Release_1.0 anymore.
There is a way around this that doesn't sacrifice the topic-oriented nature of
the branch: You keep developing Feature_A as planned for Release_1.0 and when
you notice that merging this feature to Mainline will become increasingly
complex, you fork off a new branch Feature_A_for_Release_2.0 from Mainline
and merge Feature_A into this new branch:
o--o--o Release_1.0
/ \ \
o-o-o--o--o-o-o-o-X-o---o--o Mainline
\ \
F1 o--o Feature_A_for_Release_2.0
\ / /
F2--------F3-F4 Feature_A
The fork point X must be in Release_2.0.
-- Hannes
^ permalink raw reply
* Re: Fwd: What is the best way to backport a feature?
From: Peter Weseloh @ 2009-11-29 19:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200911291933.54301.j6t@kdbg.org>
2009/11/29 Johannes Sixt <j6t@kdbg.org>:
> [please keep the Cc list]
Sorry!
>
> http://gitster.livejournal.com/42247.html
>
> Basically, as soon as you merge Mainline into Feature_A, you change the topic
> of Feature_A from "Feature for Release_1.0" to "Feature for this Mainline".
> Clearly, this topic is not suitable for Release_1.0 anymore.
>
> There is a way around this that doesn't sacrifice the topic-oriented nature of
> the branch: You keep developing Feature_A as planned for Release_1.0 and when
> you notice that merging this feature to Mainline will become increasingly
> complex, you fork off a new branch Feature_A_for_Release_2.0 from Mainline
> and merge Feature_A into this new branch:
>
> o--o--o Release_1.0
> / \ \
> o-o-o--o--o-o-o-o-X-o---o--o Mainline
> \ \
> F1 o--o Feature_A_for_Release_2.0
> \ / /
> F2--------F3-F4 Feature_A
>
> The fork point X must be in Release_2.0.
That makes perfect sense. I will discuss your suggestion with my
colleagues and will send them the link you mentioned. It's just that
branching and especially merging with CVS is so painful that they
might get scared :-). With git that's completly different, of course.
Thanks a lot,
Peter
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Uri Okrent @ 2009-11-29 19:45 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jeff King, A Large Angry SCM, Junio C Hamano, git
In-Reply-To: <94a0d4530911290338h459dd5a2p4752f7d58c455964@mail.gmail.com>
Felipe Contreras wrote:
> On Thu, Nov 26, 2009 at 1:22 AM, Jeff King <peff@peff.net> wrote:
>> Probably we would want something flexible, but with sane defaults. Like
>> an environment variable to ignore all (or most) config options, but then
>> the ability to opt into specific ones. Something like:
>>
>> GIT_PLUMBING=1; export GIT_PLUMBING
>> git log ;# does not respect any non-plumbing config
>> git --respect='log.showroot' ;# respect just the one variable
>> git --respect='color.*' log ;# you get all color
>>
>> But there are two big obstacles (besides the obvious issue that
>> introducing this in itself needs a gentle transition plan):
>>
>> 1. We need to annotate every config option with whether it is
>> potentially problematic. For example, core.filemode should probably
>> be respected no matter what (but I'm not sure if it is simply true
>> for core.*).
>>
>> 2. Script writers need to actually use the system, which is somewhat
>> more verbose and annoying than what they have to do now. But at
>> least it defaults to safety when they are lazy, and then they can
>> re-add options. Of course, they are stuck on an upgrade treadmill
>> of analyzing and approving each new option that appears in git.
>
> +1 on this.
>
> This would make it easier to add options in the future that would be
> potentially dangerous to scripts otherwise. But more than
> "non-plumbing" I would rather define these variables as *preferences*;
> things that are not essential to the proper functioning of git
> commands, and would vary from user to user.
>
Sounds like a good idea to me, speaking as someone who has git support
scripts. Dealing with configuration soup in every script would be very
bad.
The same type of insulation though could probably be achieved by not
adding configuration options that alter the behavior of commands,
and instead have user's rely on aliases for that purpose. (The cat's
probably already out of the bag WRT to configuration though).
--
Uri
Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-29 19:49 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, James Pickens, git
In-Reply-To: <20091129183217.GB21520@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Nov 29, 2009 at 11:28:27AM +0100, Johannes Schindelin wrote:
> ...
>> > When the number of "git grep" crash fatalities rises above zero, maybe
>> > this line of reasoning will be relevant.
>>
>> Sure. Let's wait for the first crash fatality, and only react then. No
>> need to think ahead.
>
> ... The actual situation
> at hand is a git grep configuration variable. I am weighing the
> preference of people who use git every day and want it to work in a
> certain way against the possibility that somebody helping them will be
> slightly inconvenienced or surprised.
While my position is *not* "hurting people who help is too grave and we
shouldn't even weigh other upsides against it---bad is bad is bad, and it
is absolutely bad" (which is what I think Dscho is saying), I think
"slightly inconvenienced or surprised" is trying to make it sound a lot
lighter than it is.
Imagine you are helping somebody to track down a bug in a project whose
source happens to be under git. You two scratch your heads together, and
you try to find if the function you are fixing have other call sites, and
you run "git grep" to find them. You think you covered the whole tree,
identified all the callsites and made sure that the updated behaviour of
the function with your fix is consistent with all of them. But it turns
out that you didn't check the whole tree, due to user's configuration, and
you didn't notice.
You can easily waste 30 minutes of two people until you realize what
happened. Because the whole point of your grep.fulltree configuration is
that you can set it once and forget about it, even after you noticed that
your grep didn't look in the whole tree as you expected, the configuration
variable is not the first thing that will come to your mind. You will
waste more minutes wondering why grep is not working as you expect, until
you finally come up with a suggestion to set the configuration to make
grep look in the full tree by default in her repository.
Put it another way, your "I can set it and forget about it" may be a way
to solve "differentiating two things is a mental burden and I do not want
to think about it". But I do not think the "mental burden" problem is
necessarily what we want to solve. The "set and forget" will bring
confusion.
The best solution to the "mental burden" problem may not even be "I can
set it and forget about it". An obvious solution to that problem, that is
far easier to explain, is not to have two things to begin with, and that is
what we do: "If you want to grep in the whole tree, you go to the top and
run grep there." Of course, its downside is that it is often cumbersome
to "got to the top" when you are somewhere deep.
That is why I think it would be a lot better solution to spend our efforts
making sure that both semantics can be called for from the command line in
a concise and clear way. IOW, the problem I see worth solving first is
not the "mental burden" problem, but is "differentiating two things is
necessary, but it is cumbersome to say which one I want."
You probably can add both configuration and concise command line syntax,
but "solving" the "mental burden" problem will make you forget about the
need to use --full-tree option (or its quivalent that will happen in the
solution of the "cumbersome to say which one I want" problem). On the
other hand, not "solving" the "mental burden" problem will hopefully train
your brain and your fingers to always be aware of and to say which one you
want, to the point that you do not even have to think.
For that to happen, "cumbersome to say which" problem must be solved
nicely, of course.
> ... Something that will happen much
> less frequently than the person actually _using_ git, and something
> which has much smaller negative consequences than people dying.
It is of course not _fatal_, but there are not many things that are fatal.
Saying "that is not fatal so it is Ok" is not particularly a good way to
weigh downsides against upsides.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Uri Okrent @ 2009-11-29 19:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Schindelin, James Pickens, git
In-Reply-To: <20091127205305.GB26921@coredump.intra.peff.net>
Jeff King wrote:
> On Fri, Nov 27, 2009 at 10:47:45AM -0800, Uri Okrent wrote:
>> As a matter of
>> fact, my personal opinion (which I probably neglected to mention) is
>> that grep default behavior should stay the same since it is semantically
>> closer to unix (or gnu) grep.
>
> Keeping consistency with non-git grep has been mentioned a few times in
> this thread. I really don't understand how default file selection is
> supposed to maintain consistency with non-git grep. Regular grep
> defaults to stdin if no paths are given. That mode doesn't make any
> sense for git grep.
>
> So of the two options (grepping the list of files from the full tree, or
> the list of files rooted at the current directory), how is one closer to
> non-git grep than the other?
>
> -Peff
I guess you're right, in that neither is exactly the same as non-git,
and so it's impossible to objectively quantify how one is "closer". My
general feeling though is that grep rooted at the current directory is
more similar because grep -r does exist and is common enough that the
layman isn't too surprised at git's default behavior. Git grep with
--full-tree though, has no analogue in non-git grep.
--
Uri
Please consider the environment before printing this message.
http://www.panda.org/how_you_can_help/
^ permalink raw reply
* Re: [spf:guess] Re: git-svn: SVK merge commits can have >2 parents
From: Eric Wong @ 2009-11-29 20:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Vandiver, git, Sam Vilain
In-Reply-To: <1259493967.31767.4.camel@denix>
Sam Vilain <sam@vilain.net> wrote:
> On Sun, 2009-11-29 at 08:08 +0000, Eric Wong wrote:
> > Alex Vandiver <alex@chmrr.net> wrote:
> > > At Sun Nov 29 02:28:39 -0500 2009, Alex Vandiver wrote:
> > > > While converting a mildly complicated svn repository that was managed
> > > > with SVK, I ran across the following oddness. `svk smerge` can only
> > > > merge between _two_ branches at once -- however, the way that svk
> > > > merge detection works, you can end up with erroneous extra parents
> > > > from long-dead branches.
> > >
> > > Upon a little more inspection, I now understand that the rev-parse
> > > lines in find_extra_svk_parents are attempting to deal with this exact
> > > circumstance -- but they fail to properly sort the merge tickets
> > > first, which leads to this incorrect behavior. Armed with this
> > > understanding, I'm more confident in the attached updated patch. I
> >
> > Hi Alex, Sam,
> >
> > I'll defer to Sam for the Ack, my svk knowledge is limited. Thanks.
>
> Yes, the change does make sense to me - nicely done, Alex.
>
> Acked-By: Sam Vilain <sam@vilain.net>
Thanks Sam, acked and pushed to git://git.bogomips.org/git-svn
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 3/6] stg mail: make __send_message do more
From: Karl Wiberg @ 2009-11-29 21:23 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091128195026.949.1772.stgit@bob.kio>
On Sat, Nov 28, 2009 at 8:50 PM, Alex Chiang <achiang@hp.com> wrote:
> Factor out the common code required to send either a cover mail
> or patch, and implement it in __send_message.
Nice code size reduction.
> + msg_id = email.Utils.make_msgid('stgit')
> + build = { 1: __build_cover, 4: __build_message }
> + msg = build[len(args)](tmpl, msg_id, options, *args)
> +
> + from_addr, to_addrs = __parse_addresses(msg)
> + msg_str = msg.as_string(options.mbox)
> + if options.mbox:
> + out.stdout_raw(msg_str + '\n')
> + return msg_id
> +
> + outstr = { 1: 'the cover message', 4: 'patch "%s"' % args[0] }
> + out.start('Sending ' + outstr[len(args)])
You could consolidate the two dictionaries like this, to avoid making
the same choice twice and make the code more pleasant to read:
(build, outstr) = { 1: (__build_cover, 'the cover message'), 4:
(__build_message, 'patch "%s"' % args[0]) }
> + # give recipients a chance of receiving related patches in correct order
> + # patch_nr < total_nr
> + if len(args) == 1 or (len(args) == 4 and args[1] < args[2]):
> + sleep = options.sleep or config.getint('stgit.smtpdelay')
> + time.sleep(sleep)
Hmm. I must say I find all the args[x] a bit hard to read. I'd prefer
symbolic names.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 5/6] stg mail: add basic support for git send-email
From: Karl Wiberg @ 2009-11-29 21:54 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091128195037.949.63611.stgit@bob.kio>
On Sat, Nov 28, 2009 at 8:50 PM, Alex Chiang <achiang@hp.com> wrote:
> + # XXX: yuck, there's gotta be a more pythonic way. Ideally we'd like
> + # to use the git_opts dictionary as our mapping between stg mail and
> + # git send-email; extract k, v pairs from git_opts, and use those
> + # to iterate across options somehow.
> + git_opts = { 'to': '--to=', 'cc': '--cc=', 'bcc': '--bcc=' }
> + if options.to:
> + for a in options.to:
> + cmd.append("--to=%s" % a)
> + if options.cc:
> + for a in options.cc:
> + cmd.append("--cc=%s" % a)
> + if options.bcc:
> + for a in options.bcc:
> + cmd.append("--bcc=%s" % a)
> + if not options.auto:
> + cmd.append("--suppress-cc=body")
Like this?
for x in ['to', 'cc', 'bcc']:
if getattr(options, x):
cmd.extend('--%s=%s' % (x, a) for a in getattr(options, x))
> + (fd, path) = mkstemp()
> + os.write(fd, msg.as_string(options.mbox))
> + os.close(fd)
> +
> + try:
> + cmd.append(path)
> + call(cmd)
> + except Exception, err:
> + os.unlink(path)
> + raise CmdException, str(err)
> +
> + os.unlink(path)
To avoid having to remember to call unlink in all paths, you can write
try:
try:
cmd.append(path)
call(cmd)
except Exception, e:
raise CmdException(str(e))
finally:
os.unlink(path)
(The combined try...except...finally statement didn't appear until
python 2.5, but we'd like to stay compatible with 2.4.)
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit RFC PATCH 0/6] add support for git send-email
From: Karl Wiberg @ 2009-11-29 22:05 UTC (permalink / raw)
To: Alex Chiang; +Cc: catalin.marinas, git
In-Reply-To: <20091128194056.949.88791.stgit@bob.kio>
On Sat, Nov 28, 2009 at 8:50 PM, Alex Chiang <achiang@hp.com> wrote:
> stg mail still has some nice features over git send-email, such
> as the -v command line parameter and --prefix. Maybe at some point
> in the future, we can migrate those features into git send-email and
> continue thinning out stg mail.
Yes. But note that we tend to be conservative and not require a
too-new git, so a patch adding such a dependency would have to wait a
while. (I'm currently carrying two such patches in my experimental
branch.)
> But I wanted to get some feedback first to make sure I'm going in the
> right direction before going too much further.
I've read the patches, and it looks about right from where I stand.
Did you remember to run the regression tests? It's very helpful when
reviewing to know that the regression suite passes at every point in
the series.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* help reverting a merge
From: Justin Mattock @ 2009-11-29 23:24 UTC (permalink / raw)
To: git
(I'm not on the list, so hopefully this goes through).
I've done a bisect on a problem with the kernel,
and am a bit confused on what to do. i.g. the
results are showing this:
a03fdb7612874834d6847107198712d18b5242c7 is the first bad commit
when trying to revert this commit I get this:
git revert a03fdb7612874834d6847107198712d18b5242c7
fatal: Commit a03fdb7612874834d6847107198712d18b5242c7 is a merge but
no -m option was given.
then doing this I get this:
git revert -m 1 a03fdb7612874834d6847107198712d18b5242c7
Automatic revert failed. After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result.
how do I find out the commits in this merge to automatically
revert to find the problem that's causing this bug?
--
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH] reset: add --quiet option
From: Stephen Boyd @ 2009-11-30 1:18 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1259492290-21771-1-git-send-email-felipe.contreras@gmail.com>
On Sun, 2009-11-29 at 12:58 +0200, Felipe Contreras wrote:
> diff --git a/builtin-reset.c b/builtin-reset.c
> index 73e6022..c0127c4 100644
> --- a/builtin-reset.c
> +++ b/builtin-reset.c
> @@ -209,7 +209,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
> "reset HEAD, index and working tree", HARD),
> OPT_SET_INT(0, "merge", &reset_type,
> "reset HEAD, index and working tree", MERGE),
> - OPT_BOOLEAN('q', NULL, &quiet,
> + OPT_BOOLEAN('q', "quiet", &quiet,
> "disable showing new HEAD in hard reset and progress message"),
> OPT_BOOLEAN('p', "patch", &patch_mode, "select hunks interactively"),
> OPT_END()
Why not just OPT__QUIET? We lose the specific help string but it's
possible that what quiet is silencing will change in the future.
Maybe you could move the help string to the documentation if you want to
save it.
^ permalink raw reply
* Re: [RFC/PATCH] t7011: Mark fixed test as such
From: Nguyen Thai Ngoc Duy @ 2009-11-30 1:56 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <4B127DC0.4020108@drmicha.warpmail.net>
On Sun, Nov 29, 2009 at 8:57 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Nguyen Thai Ngoc Duy venit, vidit, dixit 29.11.2009 09:47:
>> On 11/29/09, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>>> Test 16/17 had been fixed since its introduction in b4d1690 (Teach Git
>>> to respect skip-worktree bit (reading part), 2009-08-20). So, mark it as
>>> expect_success rather than expect_failure.
>>>
>>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>>
>> No ACK. See below.
>>
>>> ---
>>> I'm actually wondering about 17/17 as well.
>>> If commit is called with a file name then shouldn't it simply commit the
>>> current state of the file in the worktree, no matter what the index or
>>> skip-worktree say? I therefore think 17/17 should be expect_success
>>> and have no test_must_fail.
>>
>> Both 16/17 and 17/17 ensure that Git won't look at files on worktree
>> if they are marked as skip-worktree (by definition of skip-worktree,
>> you can safely ignore worktree, otherwise you would not mark them as
>> such). 16/17 happens to pass, not because it does not touch worktree,
>> but because the base index does not have "1", which happens to is the
>> same situation in 16/17 (test commit when "1" is gone). The result is
>> OK but it is actually not (17/17 shows this clearer as it commits the
>> worktree version).
>
> On 16/17, I really cannot agree. You explain that you expect the test to
> succeed (we agree here), but that it succeeds for the wrong reasons. So
> it should be either "expect_success", or the test itself should be
> changed so that it really tests what it intends to, otherwise it raises
> a wrong "FIXED". I suggested and submitted the former.
That was my bad in setting up the environment for 16/17. I will fix
that in the next roll of nd/sparse.
> On 17/17, it's not clear what should happen. "skip-worktree" says ignore
> the worktree and look in the index instead of accessing worktree files.
> But "git commit file" says ignore the index and stage and commit the
> file from the worktree directly. And that is exactly what happens:
>
> You say "git commit file".
> That means "ignore the index".
> That also means that git ignores the skip-worktree bit which is set in
> the index.
> Therefore, file is committed with the content is has in the worktree.
To me, no command should break out skip-worktree mask. In reality I
would expect that case 17/17 only happens when a user accidentally
leaves a file that is marked skip-worktree and tries to commit it. An
error would be more appropriate to keep consistency with other
commands ("git diff HEAD -- 1" would show nothing before committing),
and to warn the user that he/she is stepping on the border. He/she can
then choose to extend worktree area if still wants to commit that
file. How does that sound?
> I'm going by the documentation for git-update-index and git-commit. It
> could be that they are wrong, too, but they agree with the code, so
> what's the reference for saying both code and documentation are wrong?
Both code and documentation are for Git without skip-worktree. If you
agree with my reasoning above, I will update documentation to reflect
this too.
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH 2/2] builtin-merge: show user-friendly error messages for fast-forward too.
From: Junio C Hamano @ 2009-11-30 2:23 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1259497113-1393-3-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> This is where I'm not 100% sure I'm not breaking some plumbing.
I think this change is safe for the current codebase, as the only caller
of checkout_fast_forward() is cmd_merge(), which is an implementation of
"git merge". Even if there were a plumbing implementation that internally
runs "git merge", either by calling cmd_merge() or via run_command()
interface (there isn't as far as I know), or if somebody adds such a thing
in the future, such a "plumbing" will get Porcelain messages from other
codepaths in cmd_merge() anyway. You are not introducing a new problem.
Or did you have something a lot more subtle in mind?
Side note. checkout_fast_forward() switches between two commits (the one
that matches HEAD) to another (given as remote), which is the same as what
"git checkout other-branch" and "git checkout -b new-branch" do. We might
want to replace it with the main part of merge_working_tree() from
builtin-checkout.c eventually, which would teach the "checkout -m" logic
that carries the local changes forward to fast-forward of "git merge".
> builtin-merge.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-merge.c b/builtin-merge.c
> index 57eedd4..0dd363f 100644
> --- a/builtin-merge.c
> +++ b/builtin-merge.c
> @@ -656,6 +656,7 @@ static int checkout_fast_forward(unsigned char *head, unsigned char *remote)
> opts.verbose_update = 1;
> opts.merge = 1;
> opts.fn = twoway_merge;
> + opts.msgs = get_porcelain_error_msgs();
>
> trees[nr_trees] = parse_tree_indirect(head);
> if (!trees[nr_trees++])
^ permalink raw reply
* [PATCH] Update $GIT_DIR/remotes to $GIT_DIR/refs/remotes in docs
From: ayiehere @ 2009-11-30 3:38 UTC (permalink / raw)
To: git
I think this patch is is order now that $GIT_DIR/remotes is no longer used.
^ permalink raw reply
* [PATCH] Update $GIT_DIR/remotes to $GIT_DIR/refs/remotes in docs
From: ayiehere @ 2009-11-30 3:38 UTC (permalink / raw)
To: git; +Cc: Nazri Ramliy
In-Reply-To: <1259552316-20088-1-git-send-email-ayiehere@gmail.com>
From: Nazri Ramliy <ayiehere@gmail.com>
---
Documentation/git-parse-remote.txt | 2 +-
Documentation/git-pull.txt | 6 +++---
Documentation/git-remote.txt | 14 +++++++-------
Documentation/git-show-branch.txt | 2 +-
Documentation/urls-remotes.txt | 8 ++++----
5 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-parse-remote.txt b/Documentation/git-parse-remote.txt
index 39d9daa..9d27489 100644
--- a/Documentation/git-parse-remote.txt
+++ b/Documentation/git-parse-remote.txt
@@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
This script is included in various scripts to supply
-routines to parse files under $GIT_DIR/remotes/ and
+routines to parse files under $GIT_DIR/refs/remotes/ and
$GIT_DIR/branches/ and configuration variables that are related
to fetching, pulling and pushing.
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index b932011..250d64c 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -74,13 +74,13 @@ present while on branch `<name>`, that value is used instead of
In order to determine what URL to use to fetch from, the value
of the configuration `remote.<origin>.url` is consulted
and if there is not any such variable, the value on `URL: ` line
-in `$GIT_DIR/remotes/<origin>` file is used.
+in `$GIT_DIR/refs/remotes/<origin>` file is used.
In order to determine what remote branches to fetch (and
optionally store in the tracking branches) when the command is
run without any refspec parameters on the command line, values
of the configuration variable `remote.<origin>.fetch` are
-consulted, and if there aren't any, `$GIT_DIR/remotes/<origin>`
+consulted, and if there aren't any, `$GIT_DIR/refs/remotes/<origin>`
file is consulted and its `Pull: ` lines are used.
In addition to the refspec formats described in the OPTIONS
section, you can have a globbing refspec that looks like this:
@@ -104,7 +104,7 @@ line of `git pull`, they are all merged.
When no refspec was given on the command line, then `git pull`
uses the refspec from the configuration or
-`$GIT_DIR/remotes/<origin>`. In such cases, the following
+`$GIT_DIR/refs/remotes/<origin>`. In such cases, the following
rules apply:
. If `branch.<name>.merge` configuration for the current
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index c272c92..9dbcb0b 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -50,11 +50,11 @@ the remote information is set up.
+
With `-t <branch>` option, instead of the default glob
refspec for the remote to track all branches under
-`$GIT_DIR/remotes/<name>/`, a refspec to track only `<branch>`
+`$GIT_DIR/refs/remotes/<name>/`, a refspec to track only `<branch>`
is created. You can give more than one `-t <branch>` to track
multiple branches without grabbing all branches.
+
-With `-m <master>` option, `$GIT_DIR/remotes/<name>/HEAD` is set
+With `-m <master>` option, `$GIT_DIR/refs/remotes/<name>/HEAD` is set
up to point at remote's `<master>` branch. See also the set-head command.
+
In mirror mode, enabled with `\--mirror`, the refs will not be stored
@@ -69,7 +69,7 @@ Rename the remote named <old> to <new>. All remote tracking branches and
configuration settings for the remote are updated.
+
In case <old> and <new> are the same, and <old> is a file under
-`$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to
+`$GIT_DIR/refs/remotes` or `$GIT_DIR/branches`, the remote is converted to
the configuration file format.
'rm'::
@@ -79,23 +79,23 @@ configuration settings for the remote are removed.
'set-head'::
-Sets or deletes the default branch (`$GIT_DIR/remotes/<name>/HEAD`) for
+Sets or deletes the default branch (`$GIT_DIR/refs/remotes/<name>/HEAD`) for
the named remote. Having a default branch for a remote is not required,
but allows the name of the remote to be specified in lieu of a specific
branch. For example, if the default branch for `origin` is set to
`master`, then `origin` may be specified wherever you would normally
specify `origin/master`.
+
-With `-d`, `$GIT_DIR/remotes/<name>/HEAD` is deleted.
+With `-d`, `$GIT_DIR/refs/remotes/<name>/HEAD` is deleted.
+
With `-a`, the remote is queried to determine its `HEAD`, then
-`$GIT_DIR/remotes/<name>/HEAD` is set to the same branch. e.g., if the remote
+`$GIT_DIR/refs/remotes/<name>/HEAD` is set to the same branch. e.g., if the remote
`HEAD` is pointed at `next`, "`git remote set-head origin -a`" will set
`$GIT_DIR/refs/remotes/origin/HEAD` to `refs/remotes/origin/next`. This will
only work if `refs/remotes/origin/next` already exists; if not it must be
fetched first.
+
-Use `<branch>` to set `$GIT_DIR/remotes/<name>/HEAD` explicitly. e.g., "git
+Use `<branch>` to set `$GIT_DIR/refs/remotes/<name>/HEAD` explicitly. e.g., "git
remote set-head origin master" will set `$GIT_DIR/refs/remotes/origin/HEAD` to
`refs/remotes/origin/master`. This will only work if
`refs/remotes/origin/master` already exists; if not it must be fetched first.
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index 7343361..3671c2e 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -161,7 +161,7 @@ $ git show-branch master fixes mhf
+ [mhf~5] Infamous 'octopus merge'
+ [mhf~6] Retire git-parse-remote.
+ [mhf~7] Multi-head fetch.
- + [mhf~8] Start adding the $GIT_DIR/remotes/ support.
+ + [mhf~8] Start adding the $GIT_DIR/refs/remotes/ support.
*++ [master] Add 'git show-branch'.
------------------------------------------------
diff --git a/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt
index 2a0e7b8..5c4deeb 100644
--- a/Documentation/urls-remotes.txt
+++ b/Documentation/urls-remotes.txt
@@ -7,7 +7,7 @@ The name of one of the following can be used instead
of a URL as `<repository>` argument:
* a remote in the git configuration file: `$GIT_DIR/config`,
-* a file in the `$GIT_DIR/remotes` directory, or
+* a file in the `$GIT_DIR/refs/remotes` directory, or
* a file in the `$GIT_DIR/branches` directory.
All of these also allow you to omit the refspec from the command line
@@ -35,11 +35,11 @@ config file would appear like this:
The `<pushurl>` is used for pushes only. It is optional and defaults
to `<url>`.
-Named file in `$GIT_DIR/remotes`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Named file in `$GIT_DIR/refs/remotes`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can choose to provide the name of a
-file in `$GIT_DIR/remotes`. The URL
+file in `$GIT_DIR/refs/remotes`. The URL
in this file will be used to access the repository. The refspec
in this file will be used as default when you do not
provide a refspec on the command line. This file should have the
--
1.6.6.rc0.63.g66abc
^ permalink raw reply related
* Re: [PATCH] Update $GIT_DIR/remotes to $GIT_DIR/refs/remotes in docs
From: Jeff King @ 2009-11-30 5:03 UTC (permalink / raw)
To: ayiehere; +Cc: git
In-Reply-To: <1259552316-20088-2-git-send-email-ayiehere@gmail.com>
On Mon, Nov 30, 2009 at 11:38:36AM +0800, ayiehere@gmail.com wrote:
> DESCRIPTION
> -----------
> This script is included in various scripts to supply
> -routines to parse files under $GIT_DIR/remotes/ and
> +routines to parse files under $GIT_DIR/refs/remotes/ and
> $GIT_DIR/branches/ and configuration variables that are related
> to fetching, pulling and pushing.
Er, what? $GIT_DIR/remotes/ and $GIT_DIR/refs/remotes/ are not even
remotely the same thing. The former holds information about how to
contact remotes (but that information is usually held in the config file
these days). The latter holds any tracking refs we have fetched from
the remotes.
-Peff
^ permalink raw reply
* [PATCH v2 1/6] t2300: use documented technique to invoke git-sh-setup
From: Matthew Ogilvie @ 2009-11-30 6:19 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259561971-25730-1-git-send-email-mmogilvi_git@miniinfo.net>
This is needed to allow the test suite to run against a standard
install bin directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
t/t2300-cd-to-toplevel.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
index 3b01ad2..9965bc5 100755
--- a/t/t2300-cd-to-toplevel.sh
+++ b/t/t2300-cd-to-toplevel.sh
@@ -8,7 +8,7 @@ test_cd_to_toplevel () {
test_expect_success $3 "$2" '
(
cd '"'$1'"' &&
- . git-sh-setup &&
+ . "$(git --exec-path)"/git-sh-setup &&
cd_to_toplevel &&
[ "$(pwd -P)" = "$TOPLEVEL" ]
)
--
1.6.4.GIT
^ permalink raw reply related
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