* 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: 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: [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: [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
* 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: 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
* 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: 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
* 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: 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:49 UTC (permalink / raw)
To: Peter Weseloh; +Cc: git
In-Reply-To: <loom.20091129T164518-669@post.gmane.org>
Le 29/11/2009 17:28, Peter Weseloh a écrit :
> 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.
In such a case I would use a rebase onto:
$ git co Feature_A
$ git rebase --onto Release_1.0 F1 F3
Then
$ git co Release_1.0
$ git merge Feature_A
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: Björn Steinbrink @ 2009-11-29 16:47 UTC (permalink / raw)
To: Peter Weseloh; +Cc: git
In-Reply-To: <loom.20091129T164518-669@post.gmane.org>
On 2009.11.29 16:28:17 +0000, Peter Weseloh wrote:
> 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.
> Is there a better way? To me this scenario sounds not unusual but I
> could not find a solution.
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.
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...
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.
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
Björn
^ permalink raw reply
* Re: does clone --depth work?
From: Björn Steinbrink @ 2009-11-29 16:32 UTC (permalink / raw)
To: Dan Carpenter; +Cc: git
In-Reply-To: <20091129160352.GO10640@bicker>
On 2009.11.29 18:03:52 +0200, Dan Carpenter wrote:
> I do: `git clone --depth 0 ./repo1/ repo2` I expected that
> "git log" in repo2 wouldn't show any revisions, but it does.
>
> I'm using 1.6.5.3.171.ge36e.dirty (small unrelated modification).
>
> Am I doing something incorrectly?
Two problems:
a) IIRC depth = 0 is like not specifying depth at all
b) When using plain paths, clone optimizes the process by just doing a
copy, that doesn't apply the depth setting at all
git clone --depth=1 file://$PWD/repo1 repo2
That should work. Of course you still got some commits, so "git log"
will show them. You just don't get all of them, but only to a certain
depth.
Björn
^ permalink raw reply
* What is the best way to backport a feature?
From: Peter Weseloh @ 2009-11-29 16:28 UTC (permalink / raw)
To: git
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.
Thanks,
Peter
^ permalink raw reply
* does clone --depth work?
From: Dan Carpenter @ 2009-11-29 16:03 UTC (permalink / raw)
To: git
I do: `git clone --depth 0 ./repo1/ repo2` I expected that
"git log" in repo2 wouldn't show any revisions, but it does.
I'm using 1.6.5.3.171.ge36e.dirty (small unrelated modification).
Am I doing something incorrectly?
regards,
dan carpenter
^ permalink raw reply
* Re: [RFC/PATCH] t7011: Mark fixed test as such
From: Michael J Gruber @ 2009-11-29 13:57 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <fcaeb9bf0911290047t43ea3040x730e04baa81d8a98@mail.gmail.com>
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.
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.
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?
Michael
^ permalink raw reply
* [PATCH 1/2] merge-recursive: make the error-message generation an extern function
From: Matthieu Moy @ 2009-11-29 12:18 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <1259497113-1393-1-git-send-email-Matthieu.Moy@imag.fr>
The construction of the struct unpack_trees_error_msgs was done within
git_merge_trees(), which prevented using the same messages easily from
another function.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
merge-recursive.c | 41 +++++++++++++++++++++++------------------
merge-recursive.h | 3 +++
2 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index a91208f..70cd6cc 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -172,23 +172,6 @@ static int git_merge_trees(int index_only,
int rc;
struct tree_desc t[3];
struct unpack_trees_options opts;
- struct unpack_trees_error_msgs msgs = {
- /* would_overwrite */
- "Your local changes to '%s' would be overwritten by merge. Aborting.",
- /* not_uptodate_file */
- "Your local changes to '%s' would be overwritten by merge. Aborting.",
- /* not_uptodate_dir */
- "Updating '%s' would lose untracked files in it. Aborting.",
- /* would_lose_untracked */
- "Untracked working tree file '%s' would be %s by merge. Aborting",
- /* bind_overlap -- will not happen here */
- NULL,
- };
- if (advice_commit_before_merge) {
- msgs.would_overwrite = msgs.not_uptodate_file =
- "Your local changes to '%s' would be overwritten by merge. Aborting.\n"
- "Please, commit your changes or stash them before you can merge.";
- }
memset(&opts, 0, sizeof(opts));
if (index_only)
@@ -200,7 +183,7 @@ static int git_merge_trees(int index_only,
opts.fn = threeway_merge;
opts.src_index = &the_index;
opts.dst_index = &the_index;
- opts.msgs = msgs;
+ opts.msgs = get_porcelain_error_msgs();
init_tree_desc_from_tree(t+0, common);
init_tree_desc_from_tree(t+1, head);
@@ -1188,6 +1171,28 @@ static int process_entry(struct merge_options *o,
return clean_merge;
}
+struct unpack_trees_error_msgs get_porcelain_error_msgs()
+{
+ struct unpack_trees_error_msgs msgs = {
+ /* would_overwrite */
+ "Your local changes to '%s' would be overwritten by merge. Aborting.",
+ /* not_uptodate_file */
+ "Your local changes to '%s' would be overwritten by merge. Aborting.",
+ /* not_uptodate_dir */
+ "Updating '%s' would lose untracked files in it. Aborting.",
+ /* would_lose_untracked */
+ "Untracked working tree file '%s' would be %s by merge. Aborting",
+ /* bind_overlap -- will not happen here */
+ NULL,
+ };
+ if (advice_commit_before_merge) {
+ msgs.would_overwrite = msgs.not_uptodate_file =
+ "Your local changes to '%s' would be overwritten by merge. Aborting.\n"
+ "Please, commit your changes or stash them before you can merge.";
+ }
+ return msgs;
+}
+
int merge_trees(struct merge_options *o,
struct tree *head,
struct tree *merge,
diff --git a/merge-recursive.h b/merge-recursive.h
index fd138ca..f4b7f57 100644
--- a/merge-recursive.h
+++ b/merge-recursive.h
@@ -17,6 +17,9 @@ struct merge_options {
struct string_list current_directory_set;
};
+/* Return a list of user-friendly error messages to be used by merge */
+struct unpack_trees_error_msgs get_porcelain_error_msgs();
+
/* merge_trees() but with recursive ancestor consolidation */
int merge_recursive(struct merge_options *o,
struct commit *h1,
--
1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply related
* [RFC/PATCH 2/2] builtin-merge: show user-friendly error messages for fast-forward too.
From: Matthieu Moy @ 2009-11-29 12:18 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <1259497113-1393-1-git-send-email-Matthieu.Moy@imag.fr>
fadd069d03 (merge-recursive: give less scary messages when merge did not
start, Sep 7 2009) introduced some friendlier error message for merge
failure, but the messages were shown only for non-fast forward merges.
This patch uses the same for fast-forward.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
This is where I'm not 100% sure I'm not breaking some plumbing.
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++])
--
1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply related
* [PATCH 0/2] User-friendly error messages for merge failure on fast-forward.
From: Matthieu Moy @ 2009-11-29 12:18 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
I noticed that failures of fast-forward merges were still using the
plumbing error message:
$ git merge master
Updating 1fdeef9..e248dad
error: Entry 'foo.txt' not uptodate. Cannot merge.
I'm not 100% sure that my patch doesn't trigger the porcelain behavior
for plumbing. Someone more familiar than me with the codebase should
confirm/infirm this.
Matthieu Moy (2):
merge-recursive: make the error-message generation an extern function
builtin-merge: show user-friendly error messages for fast-forward
too.
builtin-merge.c | 1 +
merge-recursive.c | 41 +++++++++++++++++++++++------------------
merge-recursive.h | 3 +++
3 files changed, 27 insertions(+), 18 deletions(-)
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Felipe Contreras @ 2009-11-29 12:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, James Pickens, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0911272102430.4521@intel-tinevez-2-302>
On Fri, Nov 27, 2009 at 10:07 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Fri, 27 Nov 2009, Jeff King 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.
Yes, defaults are important in UI.
>> If your argument is that this lack of consistency will irritate users,
>> you need to show that:
>>
>> 1. There are users who switch between a large number of setups, but
>> will not apply config consistently.
>
> This is a strawman, and you should be ashamed to put it here. Just
> because nobody does what you actively encourage does not mean that the
> encouraged procedure is good, or for that matter, helps anybody but you.
Not to mention that it's completely irrelevant. The fact that all
users apply their configurations consistently through their setups, or
not, doesn't make a default preference better or worst.
If the argument is that default preferences are not relevant enough,
then step aside and let the people that care about default preferences
to discuss.
>> And the GitTogether had a "users complain about git, and we try to
>> listen" session.
>
> Oh, that makes me so happy. <sarcasm>Soooo happy</sarcasm>. So it was an
> ivory tower meeting, once again?
This is very typical on many open source projects. I think the
benevolent dictator model works pretty good on low-level stuff, but on
UI I think a democratic model works better.
I've been thinking on setting up a pseudo-project on SourceForge and
setup an IdeaTorrent, that way users can generate and organize ideas
so that developers can have meaningful conversations with users:
http://brainstorm.ubuntu.com/
What do you think?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Felipe Contreras @ 2009-11-29 11:48 UTC (permalink / raw)
To: Junio C Hamano
Cc: Uri Okrent, Johannes Schindelin, Jeff King, James Pickens, git
In-Reply-To: <7vk4xbn7nl.fsf@alter.siamese.dyndns.org>
On Fri, Nov 27, 2009 at 8:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> That is exactly how we work and what people have been working hard for
> 1.7.0. Check the planned changes listed in the recent (and not so recent)
> "What's cooking" summary reports.
>
> Changing "grep" is too late for 1.7.0, but we are trying to find an easy
> migration path like you mentioned in your message and that is exactly what
> this thread is about.
How about this. For now, make --full-tree available, and that's it.
Then, on 1.8.0, add the configuration option, and if there's consensus
make it default (-1 from me).
However, in order to ease the transition I think Jeff's GIT_PLUMBING
(I would call it GIT_SCRIPTING) should be introduced on 1.7.0 so
people can start exporting it in their scripts. That way people don't
have to worry about adding --(no-)full-tree on their scripts (nor any
other argument that depends on configurations) and when 1.8.0 comes,
there's no script breakage.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Felipe Contreras @ 2009-11-29 11:38 UTC (permalink / raw)
To: Jeff King; +Cc: A Large Angry SCM, Junio C Hamano, git
In-Reply-To: <20091125232210.GA15538@coredump.intra.peff.net>
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.
--
Felipe Contreras
^ permalink raw reply
* Re: [spf:guess] Re: git-svn: SVK merge commits can have >2 parents
From: Sam Vilain @ 2009-11-29 11:26 UTC (permalink / raw)
To: Eric Wong; +Cc: Alex Vandiver, git
In-Reply-To: <20091129080815.GC24222@dcvr.yhbt.net>
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>
Sam
^ permalink raw reply
* [PATCH] reset: add --quiet option
From: Felipe Contreras @ 2009-11-29 10:58 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
There's already -q, but --quiet is missing.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/git-reset.txt | 1 +
builtin-reset.c | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 2d27e40..9df6de2 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -62,6 +62,7 @@ This means that `git reset -p` is the opposite of `git add -p` (see
linkgit:git-add[1]).
-q::
+--quiet::
Be quiet, only report errors.
<commit>::
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()
--
1.6.6.rc0.63.g0471c
^ permalink raw reply related
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-29 10:28 UTC (permalink / raw)
To: Jeff King; +Cc: James Pickens, Junio C Hamano, git
In-Reply-To: <20091127210530.GC26921@coredump.intra.peff.net>
Hi,
On Fri, 27 Nov 2009, Jeff King wrote:
> On Fri, Nov 27, 2009 at 09:07:51PM +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.
> > > If your argument is that this lack of consistency will irritate users,
> > > you need to show that:
> > >
> > > 1. There are users who switch between a large number of setups, but
> > > will not apply config consistently.
> >
> > This is a strawman, and you should be ashamed to put it here. Just
>
> How is this a strawman?
You are comparing config settings which must be different, because they
affect _what_ project you are working with, with config settings that
affect _how_ you can work with them.
> 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.
That's it. I don't think that I want to participate in this kind of
discussion anymore,
Dscho
^ 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