* Re: git rebase behaviour changed?
From: Junio C Hamano @ 2006-01-17 8:43 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Mike McCormack, git
In-Reply-To: <46a038f90601170033y334d111fjed277fc787a2e523@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> GIT won't literally lose them, someone could run git-fsck and fish
> out the dangling heads from the repo, and after a bit of spelunking
> recover them, but it's suddenly a really tricky operation.
"git-lost-found".
You are right. We will lose #1 and #2, (although the "already
up to date" might catch some cases) and this _is_ dangerous. I
need to do something about this soon.
Thanks for the discussion.
[Footnote]
*1* ... or #1 and #3 --- sorry, my "one of them picked up by
upstream" scenario description was inconsistent in the previous
message.
^ permalink raw reply
* Re: git rebase behaviour changed?
From: Martin Langhoff @ 2006-01-17 8:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike McCormack, git
In-Reply-To: <7v8xtfclyx.fsf@assigned-by-dhcp.cox.net>
On 1/17/06, Junio C Hamano <junkio@cox.net> wrote:
> Sorry I am always slow but I am a bit slower than I usually am
> tonight, and do not understand this part without an
> illustration:
My fault. I did have a few bits of paper here on my lap, but gmail's
textbox sucks at ascii art...
>
> master 1---2---3---4---5---A
> / /
> origin 0---6---7---B
>
>
> A = master head
> B = origin head == merge base
>
> rev-list B..A = 1 2 3 4 5
> rev-list A..B = 6 7
Yep, exacly the example I was thinking about.
(...)
> Among the first list of commit, there is #4 which is a merge.
> So we reject. Is that what you meant?
Exactly. We refuse to reset the head and begin the rebase operation,
because it looks like operator error.
> By the way, the longer I think about this, the more I agree with
> the conclusion of the earlier thread: "if you rebase, do not
> merge; if you merge, do not rebase". It is really about picking
> the right workflow.
Definitely. But errors and misunderstandings are frequent, and people
who haven't thought the process through or aren't that familiar with
the internals are very likely to try it.
Refusing to rebase, with a good error msg gives the user a chance to
evaluate what to do with the commits. Right now, if I read the
situation right, there's a good chance commits 1,2 and 3 will be
"lost" once the rebase is complete.
GIT won't literally lose them, someone could run git-fsck and fish
out the dangling heads from the repo, and after a bit of spelunking
recover them, but it's suddenly a really tricky operation.
cheers,
martin
^ permalink raw reply
* Re: [kernel.org users] [RFC] "clone --naked"?
From: Junio C Hamano @ 2006-01-17 8:17 UTC (permalink / raw)
To: Ulrich Windl; +Cc: git
In-Reply-To: <43CCB1D3.10309.35645D@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
"Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
> ... My original intention was that I
> thought them to be little descriptive regarding their
> function. You seem to have "--bare" and "--naked". Hard to
> guess what they really do.
True. "A repository without an associated working tree". I do
not know a short and sweet phrase to describe that (well, except
"bare" and "naked", which I kind of already got used to).
Whatever word we choose to describe that, it should go to the
glossary document.
^ permalink raw reply
* Re: git rebase behaviour changed?
From: Junio C Hamano @ 2006-01-17 8:11 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Mike McCormack, git
In-Reply-To: <46a038f90601162252y7e2d9227p4eb4091b653d5c6d@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Now, I have realised that a simple mistake (merging from origin in you
> scenario) would lead git-rebase to discard earlier patches during the
> rebase. If you had a single commit *after* the merge, git-rebase would
> have rebased that single patch, and dropped earlier patches.
It may not necessarily be a mistake.
> git-rebase should refuse to run in the above scenario. Is there a
> straightforward way to ask if the merge base is "shared"?
>
> <thinking>
>...
> </thinking>
Sorry I am always slow but I am a bit slower than I usually am
tonight, and do not understand this part without an
illustration:
master 1---2---3---4---5---A
/ /
origin 0---6---7---B
A = master head
B = origin head == merge base
rev-list B..A = 1 2 3 4 5
rev-list A..B = 6 7
The first rev-list is "what we have but they do not". They are
the candidates to be fed upstream. The latter is "what they
have but we do not". Potentially some of them are commit that
represent patches we submitted earlier upstream.
Among the first list of commit, there is #4 which is a merge.
So we reject. Is that what you meant? Which makes sense in
this picture (but I am a bit tired and maybe this may not apply
in a different picture).
By the way, the longer I think about this, the more I agree with
the conclusion of the earlier thread: "if you rebase, do not
merge; if you merge, do not rebase". It is really about picking
the right workflow.
Let's say you submitted #1, #2, #3 earlier, and #3 was accepted
upstream and came back as #7, and let's further assume that we
are lucky enough that patch-id gives the same answer for
"diff-tree #2" and "diff-tree #7". So the set of commits left
are #1, #3, and #5 (#4 is just a merge so we will not re-apply).
Now, what is the shape of the final "rebased" ancestry graph we
would want?
master 1'--3'--5'--A'
/
origin 0---6---7---B
If this is what we want, why did we make #4 merge in the first
place, I wonder. If the workflow is based on rebase [*1*],
instead of making a merge at #4, the developer *should* have
done fetch and rebase, not merge:
master 1---2---3
/
origin 0---6---7---B
==>
master 1'--3'
/
origin 0---6---7---B
This would have been easier to manage at the point we discovered
#6, #7, and #B, than creating #4 merge only to discard it later.
And #5 and #A can be built on top of #3'.
master 1'--3'--5---A
/
origin 0---6---7---B
[Footnote]
*1* That is certainly easier to manage for an individual
developer than a merge based workflow. I know it because I
operated that way for a long time back when Linus was managing
git)
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.16.3
From: Gerrit Pape @ 2006-01-17 8:07 UTC (permalink / raw)
To: git
In-Reply-To: <20060116015141.GG28365@pasky.or.cz>
On Mon, Jan 16, 2006 at 02:51:41AM +0100, Petr Baudis wrote:
> Hello,
>
> this is Cogito version 0.16.3, the next stable release of the
> human-friendly version control UI for the Linus' GIT tool. Share
> and enjoy at:
>
> http://www.kernel.org/pub/software/scm/cogito/
Hi, the cg-clone program in the tarball has permissions 666, breaking
the selftest t9105, unless you have another cg-clone program in PATH;
and if so, the other cg-clone is tested instead of the new one.
$ wget -q -O- kernel.org/pub/software/scm/cogito/cogito-0.16.3.tar.gz |
tar tzvf - cogito-0.16.3/cg-clone
-rw-rw-rw- git/git 2483 2006-01-16 01:39:11 cogito-0.16.3/cg-clone
Regards, Gerrit.
^ permalink raw reply
* Re: [kernel.org users] [RFC] "clone --naked"?
From: Ulrich Windl @ 2006-01-17 7:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, users
In-Reply-To: <Pine.LNX.4.64.0601161114080.13339@g5.osdl.org>
Hi!
Maybe let me clarify: I don't have anything against any of those particular words.
My original intention was that I thought them to be little descriptive regarding
their function. You seem to have "--bare" and "--naked". Hard to guess what they
really do. The suggestion to select better words was not primarily because of
underaged using Linux or any SPAM issues. That part was just a joke. Sorry.
Regards,
Ulrich
On 16 Jan 2006 at 11:17, Linus Torvalds wrote:
>
>
> On Mon, 16 Jan 2006, Arjan van de Ven wrote:
> >
> > While I don't give a rats bottom about the "21"-ness of naked, "naked"
> > is more likely to trigger spam traps than "bare" though... just a side
> > consideration but unfortunately needed nowadays ;(
>
> Yeah. I've had spamassassin kill patches to the aic7xxx driver because the
> subject said "aic7xxx", and the "xxx" triggered as being a bad word.
>
> Now, "naked" doesn't seem to trigger anything for spamassassin, but I
> wouldn't be entirely surprised if some web-content blocker were to be
> over-eager at times. So "bare" might be safer.
>
> Linus
>
> _______________________________________________
> Users mailing list
> Users@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/users
^ permalink raw reply
* Re: git rebase behaviour changed?
From: Martin Langhoff @ 2006-01-17 6:52 UTC (permalink / raw)
To: Mike McCormack; +Cc: Junio C Hamano, git
In-Reply-To: <43CC89DC.5060201@codeweavers.com>
On 1/17/06, Mike McCormack <mike@codeweavers.com> wrote:
> > summary was: "if you do a merge, do not rebase; if you are going
> > to rebase, do not merge". The thread is this one:
>
> I want to do rebases. So is it that behaviour of "git pull" that has
> been changed to do merges, and I should be using "fetch" instead of
> "pull" or something similar?
Now, I have realised that a simple mistake (merging from origin in you
scenario) would lead git-rebase to discard earlier patches during the
rebase. If you had a single commit *after* the merge, git-rebase would
have rebased that single patch, and dropped earlier patches.
git-rebase should refuse to run in the above scenario. Is there a
straightforward way to ask if the merge base is "shared"?
<thinking>
If the commit following right after the merge base on "our" side is a
merge commit, there's a good chance we're about to fuck up. To make
double sure, we can walk up that commit to the other parent (the one
that is not the merge base for the current merge) and get what merge
base between that commit and the current merge base. If it returns
anything interesting, we bail out if we are conservative -- or walk up
the history again if we take a more adventurous approach.
If it returns empty, it's a splice merge and get outta here -- you are
not supposed to rebase a splice merge. And if the merge after our
original merge base was an octopus, die too. Those are not rebasable
either.
</thinking>
So, the conservative (and easy) approach would be to make rebase bail
out when it finds any merge commit.
cheers,
martin
^ permalink raw reply
* Re: git rebase behaviour changed?
From: Junio C Hamano @ 2006-01-17 6:29 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
In-Reply-To: <43CC89DC.5060201@codeweavers.com>
Mike McCormack <mike@codeweavers.com> writes:
> btw. I'm not the only person having this problem. Others using the
> same commands, and upgrading GIT have run into it too, so something
> has changed...
Sorry, I accidentally removed the part from my message where I
said "Yes it was changed on Nov 28 after discussion on the list
regarding rebase".
$ git whatchanged -S'is up to date' git-rebase.sh
would show that commit.
^ permalink raw reply
* Re: RFC: Subprojects
From: Junio C Hamano @ 2006-01-17 6:18 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Josef Weidendorfer, git
In-Reply-To: <Pine.LNX.4.64.0601170001130.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> So why not use the "bind" approach for the "index vs working tree" part,
> but write out "gitlink"-style tree objects?
I said "index vs working tree" as a mere example, and never said
"gitlink" is easier (or at least as easy as "bind") for "tree
object vs index" or "tree object vs working tree through index".
In fact I suspect those parts also need to be changed fairly
heavily, and to be honest, I am not very much looking forward to
investigating the details.
> In any case, I think it would be good to track where the subprojects are
> in some core state, and probably the right solution is to have special
> index entries for them, in addition to having their contents in the index.
Actually, the "special entry" was what I found out to be quite a
pain, if you mean to have "linux-2.6/" in the index and have it
used in some meaningful way. Further hacking and prototyping
_might_ convince me otherwise, but I am not so optimistic at
this moment.
> I'm not seeing a clear way to get from commit objects with "bind" lines to
> an index with the appropriate things read and back otherwise.
Here again I am thinking aloud, remembering the earlier example
of an embedded linux project that ships with linux-2.6 and
gcc-4.0, along with its own README and Makefile at the toplevel
and src/ for its own sources. The tools at the tip of "pu"
should be able to let you do the following:
$ git cat-file commit $such_toplevel_commit
tree $tree
parent $parent
bind $primarysub /
bind $linuxsub linux-2.6/
bind $gccsub gcc-4.0/
author A U Thor <author@example.com> 1137392543 -0800
commmitter A U Thor <author@example.com> 1137392543 -0800
An example.
where $tree is the object name of the whole tree (no "gitlink"
object), $primarysub and $linuxsub are the object names of
commit objects for the primary subproject (which sits at the
rootlevel) and another subproject (which sits at linux-2.6/
subdirectory).
To make sure there is no misunderstanding:
* "git-ls-tree $tree" would show the object name of
$linuxsub^{tree} at path "linux-2.6/" because
"tree" line of a commit describes the whole tree,
including subprojects.
* "git-ls-tree $primarysub" would show README,
Makefile and src/ directories but not linux-2.6/ nor
gcc-4.0/.
* "git-ls-tree $linuxsub" would show COPYING, Makefile
etc., not linux-2.6/COPYING.
Reading such a commit is easy:
$ git-read-tree $tree ;# ;-)
But that is cheating. Constructing such an index can be done by:
$ git-read-tree $primarysub
$ git-read-tree --prefix=linux-2.6/ $linuxsub
$ git-read-tree --prefix=gcc-4.0/ $gccsub
When you have such an index, writing out various trees are:
$ git-write-tree ;# $tree
$ git-write-tree --prefix=linux-2.6/ ;# $linuxsub^{tree}
$ git-write-tree --prefix=gcc-4.0/ ;# $gccsub^{tree}
$ git-write-tree \
--bound=linux-2.6/ --bound=gcc-4.0/ ;# $primarysub^{tree}
The decision to use what --prefix and --bound and what tree(s)
to write out must come from somewhere, and as you say it would
be nice if we _could_ stick them in the index as "special
entries", but for the purpose of prototyping I am assuming I
keep that somewhere in $GIT_DIR/ (the "mtab" in the previous
message. Maybe "$GIT_DIR/bind" is a good name?).
^ permalink raw reply
* Re: git rebase behaviour changed?
From: Mike McCormack @ 2006-01-17 6:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslrnh080.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Rebase changes the "master" branch when the development track
> between you (master) and upstream (origin) have forked:
>
> 1---2---3---4 master
> /
> origin' 0---5---6 origin
Well, I thought I was in the above situation, but it seems that "origin"
has been merged into "master" :/
The "pull, rebase, commit, commit, send patches, pull, ..." strategy
used to work for me, but now it doesn't.
> summary was: "if you do a merge, do not rebase; if you are going
> to rebase, do not merge". The thread is this one:
I want to do rebases. So is it that behaviour of "git pull" that has
been changed to do merges, and I should be using "fetch" instead of
"pull" or something similar?
Mike
btw. I'm not the only person having this problem. Others using the same
commands, and upgrading GIT have run into it too, so something has
changed...
^ permalink raw reply
* Re: git-diff-files and fakeroot
From: Ryan Anderson @ 2006-01-17 6:08 UTC (permalink / raw)
To: Kyle Moffett; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <95E085A7-B910-4C01-BA6E-43971A6F5F97@mac.com>
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]
Kyle Moffett wrote:
> On Jan 17, 2006, at 00:27, Ryan Anderson wrote:
>
>> On Mon, Jan 16, 2006 at 06:36:39PM -0800, Junio C Hamano wrote:
>>
>>> BTW, Ryan, I suspect this is where you try to append "-dirty" to
>>> the version number. But I wonder why you are doing the build under
>>> fakeroot to begin with? Wasn't the SOP "build as
>>> yourself, install as root"?
>>
>>
>> That's exactly what started this search, because I was running "make
>> deb-pkg". (Effectively.) dpkg-buildpackage wants to think it is
>> running as root, either via sudo or via fakeroot. I had my build
>> environment switched over entirely to fakeroot, as it just seems to
>> be a better practice, but I've temporarily switched back to sudo.
>>
>> However, your explanation has pointed out to me how I can solve this
>> - run "fakeroot -u" instead of "fakeroot", and I think it will be
>> fixed.
>
>
> You should run "make" first, then after that completes run "fakeroot
> make deb-pkg". I think this is similar to what the Debian package
> "kernel-package" does, except it substitutes an alternate "debian/"
> directory. IIRC, it just runs "make install" as a normal user to a
> staging directory, then runs "$(ROOTCMD) dpkg-deb -b [...]" to build
> the package. IMHO it's somewhat of a cleaner solution, and I've used
> it for several years now with no issues.
Right "make all && fakeroot make deb-pkg" was failing, because with
CONFIG_LOCALVERSION_AUTO set, I was both getting a "-dirty" string
appended to the version, as well as something awfully close to a full
rebuild due to the version number changing, and on top of all that, the
dpkg-buildpackage would fail, as "-dirty" doesn't have a number in it
(hence why you see dfsg1 or ubuntu0 in version strings.)
I think I might take your suggestion, and fix up the builddeb script to
do the "run as root" part itself, rather than needing to do it outside.
It would make it possible to just run "make oldconfig deb-pkg" which
would make things a little bit simpler.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: git-diff-files and fakeroot
From: Kyle Moffett @ 2006-01-17 5:59 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <20060117052758.GA22839@mythryan2.michonline.com>
On Jan 17, 2006, at 00:27, Ryan Anderson wrote:
> On Mon, Jan 16, 2006 at 06:36:39PM -0800, Junio C Hamano wrote:
>> BTW, Ryan, I suspect this is where you try to append "-dirty" to
>> the version number. But I wonder why you are doing the build
>> under fakeroot to begin with? Wasn't the SOP "build as
>> yourself, install as root"?
>
> That's exactly what started this search, because I was running
> "make deb-pkg". (Effectively.) dpkg-buildpackage wants to think it
> is running as root, either via sudo or via fakeroot. I had my
> build environment switched over entirely to fakeroot, as it just
> seems to be a better practice, but I've temporarily switched back
> to sudo.
>
> However, your explanation has pointed out to me how I can solve
> this - run "fakeroot -u" instead of "fakeroot", and I think it will
> be fixed.
You should run "make" first, then after that completes run "fakeroot
make deb-pkg". I think this is similar to what the Debian package
"kernel-package" does, except it substitutes an alternate "debian/"
directory. IIRC, it just runs "make install" as a normal user to a
staging directory, then runs "$(ROOTCMD) dpkg-deb -b [...]" to build
the package. IMHO it's somewhat of a cleaner solution, and I've used
it for several years now with no issues.
Cheers,
Kyle Moffett
--
I have yet to see any problem, however complicated, which, when you
looked at it in the right way, did not become still more complicated.
-- Poul Anderson
^ permalink raw reply
* Re: git rebase behaviour changed?
From: Junio C Hamano @ 2006-01-17 5:50 UTC (permalink / raw)
To: Mike McCormack; +Cc: git
In-Reply-To: <43CC695E.2020506@codeweavers.com>
Mike McCormack <mike@codeweavers.com> writes:
> git-rebase origin
> -> Current branch refs/heads/master is up to date.
>
> However, I can do the "rebase" manually with:
>
> git branch master-20060117
> git reset --hard origin
> git-format-patch -k --stdout --full-index origin master-20060117 | \
> git am --binary -3 -k
>
> Is this broken, or am I meant to be doing something different now?
What does "git-merge-base master-20060117 origin" give you? If
it is the same as "origin", then the master-20060117 has been
merged with origin, and rebase does not run in this case.
Here is the simplest example:
1---2---3---4 master
/
origin 0
Of course, you _could_ extract patches #1, #2, #3, and #4
between origin and master, and apply them on top of #0 to
reconstruct "master" as you found out, but there is not much
point doing so.
Rebase changes the "master" branch when the development track
between you (master) and upstream (origin) have forked:
1---2---3---4 master
/
origin' 0---5---6 origin
In this case, things are rearranged by rebase:
1'--2'--3'--4' master
/
origin' 0--5--6 origin
End of on-topic answers.
BTW, what this means is that it would not rearrange something
like this:
2---3
/ \
1---4---5---6 master
/
origin 0
But a structure like this could be rebased:
2---3
/ \
1---4---5---6 master
/
origin' 0---7---8 origin
to produce something like this:
1'--2'--3'--4'--6' master
/
origin' 0---7---8 origin
The ordering of patches may turn out to be wrong; #4 might
conflict with already applied #2 and #3. In general, rebasing
such a merged structure is highly discouraged. I think there
was a discussion on this topic on the list recently, and a short
summary was: "if you do a merge, do not rebase; if you are going
to rebase, do not merge". The thread is this one:
http://thread.gmane.org/gmane.comp.version-control.git/14308
Especially please look at a couple of message from Linus:
http://article.gmane.org/gmane.linux.kernel/365410
http://article.gmane.org/gmane.linux.kernel/365409
http://article.gmane.org/gmane.linux.kernel/365501
I guess we could decompose the commit ancestry chain in such a
case, and reproduce something like this:
2'--3'
/ \
1'--4'--5'--6' master
/
origin' 0---7---8 origin
Rebase has never done this, though. It is left as an exercise
for the reader ;-).
^ permalink raw reply
* Re: RFC: Subprojects
From: Daniel Barkalow @ 2006-01-17 5:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josef Weidendorfer, git
In-Reply-To: <7vek37rj83.fsf@assigned-by-dhcp.cox.net>
On Mon, 16 Jan 2006, Junio C Hamano wrote:
> We could introduce "bind the rest" to make write-tree write
> out a tree that contains only the containing project part and
> not any of the subproject part (e.g. Makefile, README and
> src/ but not linux-2.6/ nor gcc-4.0/ in the earlier example).
> Essentially the contents of such a tree object would be the
> same as what "gitlink" approach would have had for the
> containing project in the index file, minus "gitlink" entries
> themselves). This is not so surprising, because the missing
> information "gitlink" approach recorded in the tree object
> itself is expressed on "bind" lines in the commit object with
> this approach.
So why not use the "bind" approach for the "index vs working tree" part,
but write out "gitlink"-style tree objects? I think putting the info in
the tree objects in the location the subproject would appear is nicer than
having tree objects that tell only part of the story, and you don't have
to worry about commits that stick a subproject on top of something in the
tree.
In any case, I think it would be good to track where the subprojects are
in some core state, and probably the right solution is to have special
index entries for them, in addition to having their contents in the index.
I'm not seeing a clear way to get from commit objects with "bind" lines to
an index with the appropriate things read and back otherwise.
One idea I toyed with a while ago for the index/working tree
implementation is having an index file per bound project, such that each
project has a completely ordinary index file, and you just need to tell
checkout-index where to write. This is especially cute because the index
file for the superproject doesn't need to know about the subprojects at
all; they're not in that index, and the working tree is just directories
of untracked files. Not sure if this is a useful idea at this point or
not.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-diff-files and fakeroot
From: Ryan Anderson @ 2006-01-17 5:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vzmlvk2bs.fsf@assigned-by-dhcp.cox.net>
On Mon, Jan 16, 2006 at 06:36:39PM -0800, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > I've been trying to track down a strange issue with building kernels
> > (and scripts/setlocalversion) and finally realized the problem was the
> > when run under fakeroot, git-diff-files thinks everything is changed
> > (deleted, I believe)
>
> BTW, Ryan, I suspect this is where you try to append "-dirty" to
> the version number. But I wonder why you are doing the build
> under fakeroot to begin with? Wasn't the SOP "build as
> yourself, install as root"?
That's exactly what started this search, because I was running
"make deb-pkg". (Effectively.) dpkg-buildpackage wants to think it is
running as root, either via sudo or via fakeroot. I had my build
environment switched over entirely to fakeroot, as it just seems to be a
better practice, but I've temporarily switched back to sudo.
However, your explanation has pointed out to me how I can solve this -
run "fakeroot -u" instead of "fakeroot", and I think it will be fixed.
lkml cc:ed to hopefully stick this in an archive where someone else will
find it.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* git rebase behaviour changed?
From: Mike McCormack @ 2006-01-17 3:49 UTC (permalink / raw)
To: git
Hi,
git-rebase was a very useful tool for me to help organize my patches.
Recently, it seems the behaviour of git-rebase changed. It used to take
the commits I'd made to my "master" branch and reapply them to a new
"master" branch on top of "origin". Where rebase from git-0.99.x used
to work, git-1.1.3 now does nothing and gives me the following message:
git-rebase origin
-> Current branch refs/heads/master is up to date.
However, I can do the "rebase" manually with:
git branch master-20060117
git reset --hard origin
git-format-patch -k --stdout --full-index origin master-20060117 | \
git am --binary -3 -k
Is this broken, or am I meant to be doing something different now?
thanks,
Mike
^ permalink raw reply
* Cogito wishlist: ability to set merge strategy
From: H. Peter Anvin @ 2006-01-17 3:29 UTC (permalink / raw)
To: Petr Baudis, Git Mailing List
It would be nice if Cogito would let one override the default merge
strategy, i.e. to use the recursive merge strategy. I've had some
moderate luck with using recursive merge for the klibc trees recently.
-hpa
^ permalink raw reply
* Re: git-diff-files and fakeroot
From: Junio C Hamano @ 2006-01-17 2:36 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <43CC5231.3090005@michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> I've been trying to track down a strange issue with building kernels
> (and scripts/setlocalversion) and finally realized the problem was the
> when run under fakeroot, git-diff-files thinks everything is changed
> (deleted, I believe)
BTW, Ryan, I suspect this is where you try to append "-dirty" to
the version number. But I wonder why you are doing the build
under fakeroot to begin with? Wasn't the SOP "build as
yourself, install as root"?
^ permalink raw reply
* Re: git-diff-files and fakeroot
From: Junio C Hamano @ 2006-01-17 2:33 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <43CC5231.3090005@michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> Oddly, running "git status" seems to correct things.
>
> Running "fakeroot git-diff-files" gives me lines like this:
>
> :100644 100644 f866059f24bacd314fa4a979334a9893dbfc19ba 0000000000000000000000000000000000000000 M write-tree.c
>
> Looking at strace output, I can't see a difference that appears meaningful,
How does fakeroot keep track of fake ownerships?
That is, I suspect:
$ date >foo
$ ls -l foo
-rw-rw-r-- 1 junio junio 29 Jan 16 18:29 foo
$ fakeroot sh -i
# ls -l foo
-rw-rw-r-- 1 root root 29 Jan 16 18:29 foo
which means that under fakeroot, stat would give file ownerships
for *my* files as if they are owned by root.
And of course .git/index records the as me and fakeroot has no
way of knowing me maps to root in that fake environment.
"git status" includes "git update-index --refresh", which reads
from the stat bits and ownerships, notices that file contents have
not changed, and writes a new index file that records these stat
bits (so git thinks they are now owned by root).
If you come out of the fakeroot environment, I am reasonably
sure that you would find all the index entries are dirty again,
for exactly the same reason. index thinks things are owned by
root, the files are owned by you, so without looking at file
contents, it says "these things might have changed".
^ permalink raw reply
* git-diff-files and fakeroot
From: Ryan Anderson @ 2006-01-17 2:10 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 731 bytes --]
I've been trying to track down a strange issue with building kernels
(and scripts/setlocalversion) and finally realized the problem was the
when run under fakeroot, git-diff-files thinks everything is changed
(deleted, I believe)
Oddly, running "git status" seems to correct things.
Running "fakeroot git-diff-files" gives me lines like this:
:100644 100644 f866059f24bacd314fa4a979334a9893dbfc19ba 0000000000000000000000000000000000000000 M write-tree.c
Looking at strace output, I can't see a difference that appears meaningful,
I can probably work around this, some other way, but knowing if
this is something that is fixable in git itself or not would be nice.
Thanks!
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: git-mailinfo: cut lines at ^M
From: Linus Torvalds @ 2006-01-16 23:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v1wz7n3oz.fsf@assigned-by-dhcp.cox.net>
On Mon, 16 Jan 2006, Junio C Hamano wrote:
>
> I've briefly wondered if a better alternative is to split lines
> at "\r\n", "\n", or "\r", which would make the next line begin
> with ")" in your example.
In which case the patch does nothing good for me. I want to either drop
the bogus line, or have applymbox refuse to apply such an email..
Linus
^ permalink raw reply
* Re: Cancelling certain commits
From: Junio C Hamano @ 2006-01-16 23:43 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Bahadir Balban, git
In-Reply-To: <43CBAC0B.3020104@op5.se>
Andreas Ericsson <ae@op5.se> writes:
... (all the good stuff not repeated).
As a general rule, first of all, make sure that this kind of
"cleaning up the history" can be done only before you make your
history available to others, and not after.
> # make sure "git status" doesn't show any changes
>
> $ git branch anchor # to make a safe point to reset to if things go bad
> $ git reset --hard HEAD~7 # undo commits 3 - 10
> # replay commits 4, 5, 6, 8, 9
> $ for i in 6 5 4 2 1; do git cherry-pick -r anchor~$i || break; done
> # replay commit 10
> $ git cherry-pick -r anchor
I think "6 5 4 2 1 0" would be sweeter. rev~0 == rev
> ..., and never *ever*
> do
>
> $ git prune
>
> on a repo where you're juggling loose commits like this (although that
> should actually be safe when you create 'anchor' as a branch rather
> than as a tag, which Junio usually recommends).
Sorry, I do not understand this part. tags and branch heads are
used in the same way to determine what objects to protect from
"prune", so I thought there was no difference from the safety
point of view between the anchor being a branch or a tag.
^ permalink raw reply
* Re: git-mailinfo: cut lines at ^M
From: Junio C Hamano @ 2006-01-16 23:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601161104070.13339@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Junio, feel free to ignore this. It shouldn't hurt, but
> admittedly it's a stupid hack for a problem that has nothing
> to do with git...
This is doing "instead of removing trailing spaces, terminate a
line at the first CR or LF and discard the rest". So your "^M)"
at the end, especially the close paren, is dropped.
I've briefly wondered if a better alternative is to split lines
at "\r\n", "\n", or "\r", which would make the next line begin
with ")" in your example. Normally the first two would have
already been done by fgets(), so the alternative approach would
involve wrapping the use of fgets() with something of our own.
I do not think "keeping the rest of the line after '\r' in the
middle" is worth that trouble, so I am personally fine with your
patch.
^ permalink raw reply
* Re: Question on empty commit
From: Junio C Hamano @ 2006-01-16 23:32 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20060116225749.90052.qmail@web31812.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Ok, so what I'm seeing is that git history records what the _user did_
> as opposed to _what happened to the code_.
>
> Is it possible to have an env var to control this "feature". I.e. if
> the result is 0 lines 0 files changed, then do not update the index and/or
> the git database.
Good question. We could go stronger than that, and say it would
make more sense not to make that commit by default, except when
the merge was done with "ours" strategy (it explicitly asks for
an empty commit to make it stand out that trees were in sync at
that point), or the merge was manually resolved and the result
happens to match what treeB already had.
Why?
treeB ---------o--o--o--*--o--o---*--o..?
/ / .
/ / .
common upstream ---- / --o--o--o--o .
/ \ .
/ \ .
treeA ------o--o--o---------------*
^
|
No commit on this segment.
o are commits, * are merge commits.
At point '?' we can choose not to make a merge. You could,
after seeing such an empty merge, emulate this behaviour by
doing "git reset --hard HEAD^" yourself. Then some time later,
when treeA truly has something new to offer treeB, the next
merge attempt will create a true merge commit at '!':
treeB ---------o--o--o--*--o--o---*--o--?--o--o--!
/ / . /
/ / . /
common upstream ---- / --o--o--o--o . /
/ \ . /
/ \ . /
treeA ------o--o--o---------------*--o--o--o
When we have the last two 'o' commits on treeB development
track, creating '?' merge _might_ have some value, because we
can clearly see that those two new 'o' commits on treeB are
compatible with the '*' merge commit on treeA track. Without
the merge at '?' we would not be able to tell that, so in that
sense it is a small plus to have '?' merge commit, and it may
even help bisection bug hunting. But in practice it may not
matter and just clutter your history.
Especially if we did not have the last two 'o' commits on treeB
line, making an empty merge commit at '?' would mostly be
pointless.
treeB ---------o--o--o--*--o--o---*--o--?--------!
/ / . /
/ / . /
common upstream ---- / --o--o--o--o . /
/ \ . /
/ \ . /
treeA ------o--o--o---------------*--o--o--o
But unfortunately we cannot tell if we are going to build on top
of '?' before we merge with treeA again next time at '!', when
we are at point '?', so we could have an option or environment
variable to control this "feature", but unless you can predict
the future at point '?', deciding whether to use that option
would be rather difficult.
^ permalink raw reply
* Re: Question on empty commit
From: Junio C Hamano @ 2006-01-16 22:58 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20060116215856.6618.qmail@web31805.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
>> I do not quite follow you, but immediately before the "empty
>> commit" (I presume you mean the last "git merge" that merges
>> treeA head in treeB), you say "the treeA and treeB had been in
>> sync".
>
> Meaning that merging Tree A into Tree B would introduce 0 changes
> to Tree B.
You had two separate development tracks treeA and treeB, and the
entire merge result is taken from treeB because it had all the
changes from the common upstream already and there was no
development in treeA on its own:
treeB ---------o--o--o--*--o--o---*--o..?
/ / .
/ / .
common upstream ---- / --o--o--o--o .
/ \ .
/ \ .
treeA ------o--o--o---------------*
^
|
No commit on this segment.
o are commits, * are merge commits.
and we are trying to merge the last commit on treeA line into
the tip of treeB. The last merge commit on the treeB line of
development would introduce zero change from treeB's point of
view, because there is nothing new treeB would get by merging
with treeA.
Before the '?' mergepoint, what is known about treeA and treeB
was that treeB contained everything up to the third from the
left 'o' commit on treeA line. We now noticed that treeA has
some changes since then (i.e. all the good stuff from the common
upstream), and merge even has noticed that these changes happen
to be already what treeB already had and you did not have to
hand resolve (or you might have had to; I dunno). Making a
commit for '?' merge records the fact that these two tips are in
sync. IOW, earlier treeB did not know about the merge commit at
the tip of treeA; now it does.
After this sync, if you try to merge again with treeA, no merge
commit would be made, of course. Now you are truly up-to-date.
When git talks about a branch being up-to-date wrt another
branch, it is not about "all of the patches that the other line
has have been applied to our tree" (we are not a patchset based
system like darcs). It is about commit ancestry, IOW, "in the
past we have merged with them, and all the commits that line has
right now are what we have already examined when we made that
merge" is what we mean by us being up-to-date wrt them.
Fast-forward is the other way around but the principle is the
same. We are fast-forward to them not because we have applied
all the patches they have and we have more. We are fast-forward
because we have seen all of their commits in the past and
recorded in our commit ancestry chain that fact as a merge, and
in addition we have one or more commits on top of that merge
commit. That is when we are fast-forward wrt to them.
^ 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