* 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
* Re: Question on empty commit
From: Luben Tuikov @ 2006-01-16 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060116215856.6618.qmail@web31805.mail.mud.yahoo.com>
--- Luben Tuikov <ltuikov@yahoo.com> wrote:
> --- Junio C Hamano <junkio@cox.net> wrote:
>
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> >
> > > Now the last merge introduced an empty commit, since
> > > tree A and tree B had been in sync (only local and
> > > remote trunk had been out of sync). While it was expected
> > > that no commit would be introduced since they were in sync.
> > >
> > > Was the empty commit correct behavior?
> >
> > 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.
>
> > What do you exactly mean? The tree object in the head
> > commits in treeA branch and treeB branch were identical?
>
> They cannot be, since Tree B contains Project B, which is not
> present in Tree A, but it depends on Project A in Tree A.
>
> > If that is the case, the commit being empty is the correct
> > behaviour, because there is no difference in the set of files
> > introduced by that commit. And the commit being made is also
> > the correct behaviour, because those two branches have different
> > development history, and the commit is what binds them together.
>
> So a new commit object, with 0 files changed was the correct behavior
> after all?
>
> I'd expect that there would be no commit object whatsoever since
> those trees had been synced before. I.e. the only thing which changed
> was the trunk and that trunk was synced to Tree A and Tree B separately.
>
> Thanks,
> Luben
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.
Thanks Junio,
Luben
^ permalink raw reply
* Re: [PATCH] stgit: make tutorial a valid asciidoc article
From: Pavel Roskin @ 2006-01-16 22:37 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0601160021t3b40ba3fp@mail.gmail.com>
On Mon, 2006-01-16 at 08:21 +0000, Catalin Marinas wrote:
> On 13/01/06, Pavel Roskin <proski@gnu.org> wrote:
> > There should be only one level 0 title in an article, so lower ranks of
> > all headers by one. Make capitalization uniform in the headers - level
> > 1 is capitalized, but level 2 is not. Create a new level 1 part
> > "Technical Information".
> >
> > Make ".git/ Directory Structure" a level 2 header and rephrase.
> > asciidoc doesn't like headers starting with a dot.
>
> I agree with most of this but what's the difference when adding "~~~~"
> instead of "----"?
An article can only have one level 0 title, which is underlined by
"====". There may be more than one level 0 title in a book, but we
probably shouldn't do it. Books have page breaks and table of contents
for every level 0 title.
This means that the existing hierarchy should be moved one step down.
Level 1 uses "----" and level 2 uses "~~~~". I guess your objection is
that the visual distinction between level 1 and level 2 is insignificant
in the original ASCII file. I agree.
It's possible to override the underline rules by placing asciidoc.conf
in the same directory as the document. I think "####" would be just
fine for the level 0. Then we can keep the rest.
Also, I've added a makefile. It's not used by default, but those who
want to read a tutorial, can generate it in html or pdf format.
Here's the new patch.
---
Make tutorial a valid asciidoc article.
From: Pavel Roskin <proski@gnu.org>
There should be only one level 0 title, so redefine underline rules in
asciidoc.conf to keep the existing underlines when possible. Form a new
level 1 part "Technical Information" from the text at the end. Make
introduction a preamble - it's too short to be a level 1 section.
Add doc/Makefile to process the tutorial automatically. make needs to
be run explicitly in the doc directory.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
doc/Makefile | 17 +++++++++++++++++
doc/asciidoc.conf | 3 +++
doc/tutorial.txt | 14 ++++++++------
3 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/doc/Makefile b/doc/Makefile
new file mode 100644
index 0000000..07704b8
--- /dev/null
+++ b/doc/Makefile
@@ -0,0 +1,17 @@
+DOCS = tutorial.txt
+DOCS_HTML = $(DOCS:.txt=.html)
+DOCS_PDF = $(DOCS:.txt=.pdf)
+
+all: $(DOCS_HTML) $(DOCS_PDF)
+
+%.html: %.txt
+ asciidoc $<
+
+%.xml: %.txt
+ asciidoc --backend=docbook $<
+
+%.pdf: %.xml
+ xmlto pdf $<
+
+clean:
+ rm -f *.xml *.html *.pdf
diff --git a/doc/asciidoc.conf b/doc/asciidoc.conf
new file mode 100644
index 0000000..5b8d95f
--- /dev/null
+++ b/doc/asciidoc.conf
@@ -0,0 +1,3 @@
+[titles]
+underlines="##","==","--","~~","^^"
+
diff --git a/doc/tutorial.txt b/doc/tutorial.txt
index 7183e41..5899c38 100644
--- a/doc/tutorial.txt
+++ b/doc/tutorial.txt
@@ -1,8 +1,6 @@
StGIT Tutorial
-==============
+##############
-Introduction
-------------
StGIT is a Python application that provides functionality similar to
quilt (i.e. pushing/popping patches to/from a stack) using GIT instead
@@ -334,8 +332,11 @@ result in an empty patch (StGIT notifyin
deleted.
-A Bit of StGIT Patch Theory
-===========================
+Technical Information
+=====================
+
+A bit of StGIT patch theory
+---------------------------
We assume that a patch is a diff between two nodes - bottom and top. A
node is a commit SHA1 id or tree SHA1 id in the GIT terminology:
@@ -374,8 +375,9 @@ The above operation allows easy patch re
Removing (popping) a patch from the stack is done by simply setting the
Nst to Nb.
-.git/ Directory Structure
+Layout of the .git directory
+----------------------------
HEAD -> refs/heads/<something>
objects/
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: RFC: Subprojects
From: A Large Angry SCM @ 2006-01-16 22:25 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Martin Langhoff, Junio C Hamano, git, Johannes Schindelin,
Simon Richter
In-Reply-To: <Pine.LNX.4.64.0601161414080.25300@iabervon.org>
Daniel Barkalow wrote:
> On Mon, 16 Jan 2006, A Large Angry SCM wrote:
>
>>Daniel Barkalow wrote:
>>[...]
>>>So the problem with handling subprojects with the build system is that it is
>>>too tempting to use the revision control system directly on the subproject,
>>>at which point the thing you're developing and testing isn't at all what
>>>other people will get if they check out your commit. You want "git status"
>>>to report it as an uncommitted change if you have a different revision of
>>>the subproject than your previous commit had, and it can't tell if this
>>>information is buried in the build system.
>>Using "git-status" is the wrong tool to use there. What you should be using is
>>"make project_status". Claiming "that it is too tempting to use the revision
>>control system on the subproject" is wrong; you should use the SCM (of the
>>subproject) to manage the subproject. You use the build system to manage the
>>_entire_ project.
>
> I'm talking about using "git status" on the main project, in case you're
> misunderstanding me. If you can manage the entire project with the build
> system, then you don't need git or any version control at all, aside from
> your build system. But you'd also lose the ability to use webgit, bisect,
> gitk, git log, and so forth on the project as a whole.
When you say "main project", do you mean the top level project and all
of its subprojects? Or just the top level project without any of its
subprojects?
A build system and a SCM working together can be a powerful very tool,
even if one or both of the components is not. Since managing a project
with a build system and no SCM means that you don't have any history and
since you seem to want access to the project's history, I'll ignore you
statement. (Backups and directory snapshots are primitive SCMs.)
Consider the following:
1) For a project to be a sub-project, it must also be a project.
2) So the standard SCM tools will work on the project.
3) The super-project is also a project and the standard SCM tools will
work on it.
4) Projects managed by an SCM are only considered consistent and usable
at specific points in that project's history; it may be every recorded
point in it's history or it may be just a few specific recorded points.
5) A super-project only cares about specific states of its sub-projects,
corresponding to points in the sub-project's history.
6) For each sub-project, the super-project needs to record the
sub-project's state identifier for each recorded point in the
super-project's history.
7) The super-project can record each sub-project's state identifier
somewhere in the build system.
8) If the super-project's SCM is Git then webgit, bisect, gitk, git log,
and so forth all work and will identify when and where the recorded
state identifier of each sub-project is changed.
9) The information is available to the build system to permit using
git-bisect in the super-project and notice that the breakage occurred
when the recorded state identifier of a sub-project changed. If the
sub-project used Git, the build system can automatically start
git-bisect'ing in the sub-project.
10) The information is available to the build system to permit doing
similar things for git-log and so forth.
11) Webgit and gitk are a little more work but by creating a git
repository that contains all of the history and refs of each project in
the entire project, you can navigate and view the history of any project
in the entire project.
12) If the SCM of some of the sub-projects is not Git, the build system
can still do git-bisect, git-log, etc. equivalents for the entire
project (subject to the limitations of the SCMs involved).
>>>The tricky question is whether we should permit the "subproject" objects to
>>>specify a revision that isn't a hash, for use in identifying revisions of
>>>subprojects in other systems.
>>Why would you want to limit how required versions of subprojects are
>>specified? Your project policies and procedures may require that subprojects
>>be specified by a subproject SCM specific immutable revision but the policies
>>and procedures of other projects may not be so restrictive and could accept a
>>tag identifying the latest "stable" (or something) revision.
>
> If you accept a tag identifying the latest stable revision, then you might
> as well not bother. The point of revision controlling a project is to be
> able to reconstruct previous states. If you allow any event, especially
> outside, unrelated, events to change the reconstructed state for a
> revision, then this is not the case. Your normal debugging situation will
> be "It's broken, and I didn't change anything." because someone somewhere
> else changed something, and you have no record of what last worked. And
> you can obviously forget any hope of "git bisect" working.
CVS does not have the concept of "hash" for use in identifying the state
of a particular set of files but it does have tags and CVS tags work
like Git tags. The form of identifier that is used to identify the
particular state of interest of a sub-project is dependent on the
policies and procedures of the super-project, and the SCM of the
sub-project.
The need to reproduce a particular state at sometime in the future is
well understood, even in organizations that use tools that only support
tags. Implying that it's not possible without using Git's immutable
hashes as the state identifier is just wrong.
--
^ 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