* Re: RFC: Subprojects
From: Junio C Hamano @ 2006-01-15 0:49 UTC (permalink / raw)
To: Martin Langhoff; +Cc: gitzilla, git, Johannes Schindelin, Simon Richter
In-Reply-To: <46a038f90601141628n2ec32e8fy7fc23d8d7884c0f2@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> I am with gitzilla on this one. Let the projects have their own
> bootstraping mechanisms, using make, ant or whatever catches their
> fancy. One of the great things about git is that it doesn't assume
> that it's being used by all the projects in the world -- thanks to
> Linus' disregard for arbitrary metadata and to your git-cherry
> implementation, it's all about the content -- and so it interoperates
> great with Arch, SVN, CVS, etc.
I had the exactly the same reaction when I saw the project
bundling facility of Arch (tla 1.0 -- I do not know what the
newer versions use). It probably was a great way to tie two or
more Arch projects together, but it would quickly become less
useful once the component project is outside Arch space and the
toplevel project would end up with doing some Makefile targets
like ALASCM described.
I hope this settles this issue and nobody would bring up "Wee
want subprojects" ever again ;-).
^ permalink raw reply
* Re: RFC: Subprojects
From: Martin Langhoff @ 2006-01-15 0:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, git, Johannes Schindelin, Simon Richter
In-Reply-To: <7vk6d2fsu6.fsf@assigned-by-dhcp.cox.net>
On 1/15/06, Junio C Hamano <junkio@cox.net> wrote:
> > The "get" rule for each sub-project could be something like:
> >
> > git_sub-project:
> > mkdir sub-project
> > cd sub-project
> > git-init-db
> > git-fetch <fetch-options> <repository> <refspec>
> > git-checkout <branch>
> > $(MAKE) get_sub_components
>
> There lies a drake here --- <repository> is not the same for
> everybody. It is not a big showstopper dragon, though.
Well, that /little complication/ applies to doing it in git too ;-)
There's no way to tell how the dev doing the top level checkout has
access to the subproject repos.
I am with gitzilla on this one. Let the projects have their own
bootstraping mechanisms, using make, ant or whatever catches their
fancy. One of the great things about git is that it doesn't assume
that it's being used by all the projects in the world -- thanks to
Linus' disregard for arbitrary metadata and to your git-cherry
implementation, it's all about the content -- and so it interoperates
great with Arch, SVN, CVS, etc.
Having intra-git subproject support assumes that the subprojects are
all in git. Heh! That covers about 0.001% of reality out there.
Per-project bootstraping scripts will use whatever tools they need for
the checkout.
Automating the 'checkout' stage for git subprojects is trivial, and
I'd argue not interesting enough to try and solve within git,
specially when most subprojects are going to be using a different SCM
anyway. And all the *interesting* operations (branch, commit, tag) are
perhaps indeed interesting problems to solve, but definite misfeatures
in a tool that tries to be sane and minimalistic.
IOWs, adding some repo metadata describing subprojects is the wrong
thing to do, just like tracking patches via metadata would be the
wrong thing to do. It's all about files -- which git handles
masterfully.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] cg-seek should not complain if run twice
From: Petr Baudis @ 2006-01-14 23:30 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1135054536.3815.14.camel@dv>
Dear diary, on Tue, Dec 20, 2005 at 05:55:36AM CET, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> cg-seek complains if run without arguments in a non-seeked repository:
>
> rm: cannot remove `.git/refs/heads/cg-seek-point': No such file or directory
> rm: cannot remove `.git/head-name': No such file or directory
>
> In fact, it's OK for those files not to exist, so they should be removed
> silently.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
It seems cleaner to just make cg-seek fail with a sensible error message
if it's already unseeked.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: My first git success [not quite]
From: Linus Torvalds @ 2006-01-14 21:57 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dqbnl1$3si$1@sea.gmane.org>
On Sat, 14 Jan 2006, walt wrote:
>
> Linus Torvalds wrote:
> [...]
> > Now, what happens is that when you change branches with a dirty tree, the
> > "git checkout" will do one of two things:
> >
> > - if the dirty files are _identical_ in both branches...
>
> I'm sorry to be quibbling over semantics, truly I am! But here
> is my confusion: if modified-but-uncommitted (hence dirty) files
> are not associated with *any* branch, then how could 'dirty' files
> be 'in' both branches (or 'in' any branch at all)?
The file itself is associated with the branch. It's just that the _dirty_
part isn't.
Of course, you can also truly have files that aren't associated with
either branch at all: files that haven't gotten committed at all. They're
also "dirty state", and exactly like modifications to known files, they
are carried along with the switch, so they'll exist in the directory tree
after a "git checkout".
Anyway, in git, a "branch" is technically really nothing more than "top of
a commit chain". If you look into the files that describe a branch, you'll
literally just find the name of the top commit. Do a
cat .git/refs/heads/master
to see.
So anything that isn't described by that commit is by definition "dirty
state", whether it's because you've edited something (but not checked it
in) or because there's some random generated file in the working tree.
So when you switch branches, you really should think of it as "ok, the
committed state was switched around", and everything else was just "moved
along".
Linus
^ permalink raw reply
* Re: www.kernel.org/git is slow...
From: H. Peter Anvin @ 2006-01-14 21:47 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: ftpadmin, git
In-Reply-To: <20060114203654.GA10314@mars.ravnborg.org>
Sam Ravnborg wrote:
> During the last couple of days http://www.kernel.org/git has
> been very slow.
>
> The www.kernel.org frontpage is quick, so it looks like a gitweb
> problem, but ftpadmin put on cc: just in case.
>
Wonder if the caching is broken, or if it's gitweb itself...
-hpa
^ permalink raw reply
* Re: My first git success [not quite]
From: Junio C Hamano @ 2006-01-14 20:49 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dqbnl1$3si$1@sea.gmane.org>
walt <wa1ter@myrealbox.com> writes:
> Linus Torvalds wrote:
> [...]
>> Now, what happens is that when you change branches with a dirty tree, the
>> "git checkout" will do one of two things:
>>
>> - if the dirty files are _identical_ in both branches...
>
> I'm sorry to be quibbling over semantics, truly I am! But here
> is my confusion: if modified-but-uncommitted (hence dirty) files
> are not associated with *any* branch, then how could 'dirty' files
> be 'in' both branches (or 'in' any branch at all)?
"If the paths that you have dirty are the same in both
branches".
That is:
* "master" branch has Makefile file, as taken from git.git
* "my-work" branch was made out of "master" branch, but
has not modified Makefile file.
git-diff-tree master my-work Makefile
would yield nothing.
* You are on "master" branch. You have added a new target to
your Makefile in the working tree and the path is dirty.
Then:
git checkout my-work
would notice that the path "Makefile" are identical between two
branches "master" you are switching from and "my-work" you are
switching to. The "Makefile" in your working tree does not
match either tree, but that difference is carried over while
switching branches.
As Linus mentioned, with '-m' flag to "git checkout", it can
merge your local modifications even when "master" and "my-work"
disagrees on "Makefile" in this example.
^ permalink raw reply
* Re: My first git success [not quite]
From: walt @ 2006-01-14 20:41 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0601141117120.13339@g5.osdl.org>
Linus Torvalds wrote:
[...]
> Now, what happens is that when you change branches with a dirty tree, the
> "git checkout" will do one of two things:
>
> - if the dirty files are _identical_ in both branches...
I'm sorry to be quibbling over semantics, truly I am! But here
is my confusion: if modified-but-uncommitted (hence dirty) files
are not associated with *any* branch, then how could 'dirty' files
be 'in' both branches (or 'in' any branch at all)?
Thanks for your continued patience with me! I hate to distract you
from your real work -- I can only hope that others are learning as
much from your answers as I am.
^ permalink raw reply
* Re: RFC: Subprojects
From: Junio C Hamano @ 2006-01-14 20:38 UTC (permalink / raw)
To: gitzilla; +Cc: git, Junio C Hamano, Johannes Schindelin, Simon Richter
In-Reply-To: <43C95F69.7090200@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
>> If I could have just done a "git clone <top-level>" to get it all,
>> I'd have been a much more productive user.
>
> $ make get_sub_components
>
> This can work with most any SCM (depending on your environment), is
> amazingly flexible, and does not require special support in the SCM.
I am with you two on this one, in principle, as a developer.
> The "get" rule for each sub-project could be something like:
>
> git_sub-project:
> mkdir sub-project
> cd sub-project
> git-init-db
> git-fetch <fetch-options> <repository> <refspec>
> git-checkout <branch>
> $(MAKE) get_sub_components
There lies a drake here --- <repository> is not the same for
everybody. It is not a big showstopper dragon, though.
^ permalink raw reply
* www.kernel.org/git is slow...
From: Sam Ravnborg @ 2006-01-14 20:36 UTC (permalink / raw)
To: ftpadmin, git
During the last couple of days http://www.kernel.org/git has
been very slow.
The www.kernel.org frontpage is quick, so it looks like a gitweb
problem, but ftpadmin put on cc: just in case.
Sam
^ permalink raw reply
* Re: [PATCH] rpmbuild doesn't like '-' in version strings
From: Junio C Hamano @ 2006-01-14 20:35 UTC (permalink / raw)
To: John Ellson; +Cc: git, Linus Torvalds
In-Reply-To: <43C95E25.3070006@research.att.com>
John Ellson <ellson@research.att.com> writes:
> Anyway, this is above and beyond doing something with sed to
> fix the '-' issue.
What I am saying is that until that issue of ordering is
resolved (and I highly suspect it is unsolvable) I think it is
dangerous and more confusing to let binary packages be built,
and it is better to simply forbid it like in the current
scheme.
BTW, if we _were_ to do a sed, please do s/-/./g instead; the
underscore breaks Debian if I am not mistaken.
^ permalink raw reply
* Re: My first git success [not quite]
From: Junio C Hamano @ 2006-01-14 20:31 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git, walt
In-Reply-To: <86acdyu2dz.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Well, I'm a developer and *I* also had that problem while working
> on my "ajax" branch.
>
> Maybe git-checkout should by default *warn* when it is leaving
> things in the tree that are indexed but not updated in the index...
What Linus already said. But you may find this on top of the
current "master" branch useful.
Likes, dislikes?
-- >8 --
[PATCH] checkout: show dirty state upon switching branches.
This shows your working file state when you switch branches. As
a side effect, "git checkout" without any branch name (i.e. stay
on the current branch) becomes a more concise shorthand for the
"git status" command.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-checkout.sh b/git-checkout.sh
index bd7f007..d99688f 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -164,6 +164,9 @@ else
esac
exit 0
)
+ saved_err=$?
+ git diff-files --name-status
+ (exit $saved_err)
fi
#
^ permalink raw reply related
* Re: RFC: Subprojects
From: A Large Angry SCM @ 2006-01-14 20:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Junio C Hamano, Johannes Schindelin, Simon Richter
In-Reply-To: <Pine.LNX.4.64.0601141154590.13339@g5.osdl.org>
Linus Torvalds wrote:
>
> On Sat, 14 Jan 2006, A Large Angry SCM wrote:
>>So far I've not seen any convincing arguments why the sub-projects can not be
>>managed by the Makefile, or equivalent, of the super-project. Particularly
>>when the sub-projects have a life of their own.
>
> Now, from a developer standpoint I actually agree with you. I find
> sub-projects totally useless - I'm much happier just having separate
> trees.
>
> The advantage (as far as I can tell) of sub-projects is not that they are
> easier to develop in, but that it's a total nightmare for the technical
> _user_ to download ten different projects from ten different sites, and
> configure them properly and install them in the right order, and keep them
> up-to-date.
>
> There are projects that I simply gave up even trying to track: I wasn't
> interested in being a developer per se, but I _was_ interested in trying
> to test and give feedback to the current development tree - but it was
> just too damn confusing to get it working.
>
> If I could have just done a "git clone <top-level>" to get it all, I'd
> have been a much more productive user.
$ make get_sub_components
This can work with most any SCM (depending on your environment), is
amazingly flexible, and does not require special support in the SCM.
The "get" rule for each sub-project could be something like:
git_sub-project:
mkdir sub-project
cd sub-project
git-init-db
git-fetch <fetch-options> <repository> <refspec>
git-checkout <branch>
$(MAKE) get_sub_components
>
> This is why I think sub-projects are more about "git checkout" and an
> automated "git fetch" than anything else. Doing actual development etc you
> can easily do one project at a time. "git diff" and "git commit" wouldn't
> need any real ability to recurse into subprojects and try to make it
> seamless. And if you do a "git pull" that needs to do anything but
> fast-forward, you might as well resolve the sub-projects one by one.
And all of this can be done today, without changing git, with more
flexibility, with Make rules.
^ permalink raw reply
* Re: [PATCH] rpmbuild doesn't like '-' in version strings
From: John Ellson @ 2006-01-14 20:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7v1wzaliv0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> John Ellson <ellson@research.att.com> writes:
>
> I consider leaving the interim version unbuildable for binary packaging
> consider a feature.
>
Not a very helpful feature IMO. Who is protected by this?
> If you want to build your own version, I think you could locally
> tag that head and build, like:
>
> $ git tag -a "John's GIT 1.1.2+frotz patch" v1.1.2.John0114
> $ make rpmbuild
>
> Of course you can keep a patch with the sed -e 's/-/_/' in
> GIT-VERSION-GEN as Linus suggested in your development branch.
>
Thats basically all I'm looking for. I agree that is only necessary to
fix the "make rpm" target.
Further changes are not strictly necessary. I don't understand why it
would only be useful to me?
> I am not yet convinced being able to build a random
> unidentifiable binary package is a good thing, and "the number
> of minutes/seconds monotonicity" would not work in multiple
> branches case (i.e. still leaves the result unordered).
>
Since disparate branches are intrinsically unordered I was suggesting
that the
hash field would be used to ensure uniqueness only. The timestamp
field is only for ordering within a branch.
So if someone builds rpms from two different branches, they might still
have to force the particular
selection they want with "rpm -Uvh --oldpackage ...", but I think this
is the best that can be done
in the absence of any intrinsic ordering.
Anyway, this is above and beyond doing something with sed to fix the '-'
issue.
John
>
>
>
^ permalink raw reply
* Re: RFC: Subprojects
From: Junio C Hamano @ 2006-01-14 20:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0601141055210.13339@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 14 Jan 2006, Junio C Hamano wrote:
>
> The thing is, if you do the contained projects as "union projects" as you
> suggest, I will bet that it will really really suck, because it ends up
> losing the two positives above.
After a good night's sleep, I agree. I have not thought things
through and still have a feeling that (feasibilities aside) it
would be interesting if we can do a "union projects" a la "union
mounts" (or translucent filesystem). But that "interesting"
thing would probably not be very useful in practice.
> would actually act like they now act for directories that they don't
> recurse into, ie you'd see something like
>
> :160000 160000 5eb57670... 3f1a42aa... M sub-project
>
> and it would be up to higher-level porcelain to recurse.
This I agree with.
> The other reason? A lot of the git infrastructure really does only work on
> the "one project" level. The programs work with _one_ index, not two.
> Reading two trees is perfectly possible, but unless you keep them in
> separate stages, you can't separate them afterwards. IOW, trying to be
> recursive really does end up being a big change, for very little gain (and
> for a lot of potential bugs and instability).
Yup. BTW, I think with a couple of minor tweaking and giving it
the same restriction ("two pluses and one negative") as the
gitlink proposal, the "union" approach would work equally well,
perhaps with a simpler implementation. I'll think aloud about
this at the end.
>> Fetching/cloning at the core level is easy. "git-fetch-pack"
>> would just need to do one level, but Porcelains need to address
>> how to actually arrange the subprojects cloning to happen, which
>> is harder.
>...
> So only if you actually check it out (which is often in practice the
> second stage of the cloning, of course) do you want to fetch the
> subproject too.
We are in complete agreement here.
> I think this one has serious disadvantages:
>
> - it's much less obvious when there are common names and especially
> common subdirectories.
> - in _practice_, almost all sub-projects are kept in sub-directories. Are
> you doing to change the sub-project git tree? How are you going to
> merge back to the original sub-project?
> - iow, I think this only works for sub-projects that are totally
> controlled by the top-level project - in which case they might as well
> just be totally merged into the top level (the way we did with the
> "tools" project, and largely with "gitk").
Yes, I agree to the above 100%; the serious disadvantages come
from the fact that we do not have clear separation between
subprojects -- which new files belong to what subproject. I
think re-rooting read-tree and write-tree would help solving
that. After I wrote the message you are replying to, I came up
with a couple of tweaks.
- Do the octopus-like thing, but always give subprojects a
separate directories to work in.
- Extend "commit" objects for the toplevel project to record
what subprojects with what head commits are contained at
which subdirectory. I wrote in the previous message to make
subprojects heads parents of aggregate commits, but I think
that one without "where to" information has a serious
disadvantage when computing a merge.
In the "embedded linux" example that has "linux-2.6" and
"gcc-4.0" projects as an externally controlled subprojects, and
has all the rest (including the toplevel Makefile) in "master"
branch:
$ tar xf embed.tar embed && cd embed && git init-db
$ git add . ;# toplevel Makefile and stuff
$ git commit -a -m 'embedded repo - initial'
After doing "git-fetch-pack -k git://.../linux-2.6.git/ master"
and "echo $H >.git/refs/heads/kernel" (similar for gcc-4.0) to
set up the branch heads (but we do not have any working tree
files for these subprojects yet):
$ git bind -m 'Bind kernel and gcc into us' \
kernel=linux-2.6 gcc=gcc-4.0
would prepare the subprojects binding (I am just looking for a
better word --- I called it "setup-overlay" in the previous
message). This would:
- append the tree object in "kernel" commit object to the
current index, rerooted at linux-2.6/; similar for "gcc" at
gcc-4.0/. We may need a new mode and option for read-tree for
this, or we may not. Internally this step would be scripted
in "git bind" wrapper like this:
git read-tree --bind --prefix=linux-2.6 kernel
git read-tree --bind --prefix=gcc-4.0 gcc
and would result in an index file that has these trees
"mounted" at specified places. If you look at only the index
file, you cannot tell this is an overlay, unlike gitlink
scheme.
- make a commit that records the tree object (the whole thing
including the subproject trees), with the initial commit we
made earlier as the sole parent commit, and additionally
records the two subproject heads with bind points. This
happens in the same "git bind" wrapper, and produces
something like:
$ git cat-file commit HEAD
tree e9de76f2e141824439caa00a65e3b91d05d125c9
parent bfca932434cc65e7aa90794e7c4d66f75d00b16a
bind a8fe7257b8427d31cfcca0aa336335bb43689fc9 linux-2.6
bind b3b2df23226634f42c9646bd7961fbea8b00f914 gcc-4.0
author Junio C Hamano <junkio@cox.net> 1137205528 -0800
committer Junio C Hamano <junkio@cox.net> 1137205528 -0800
Bind kernel and gcc into us.
"bind" line needs to be taught to fsck-objects. The format
is the object name of the commit followed by (c-style quoted)
subdirectory name.
- record the branch name vs subproject directory binding in
$GIT_DIR/ somewhere, say $GIT_DIR/mtab ;-).
$ cat .git/mtab
kernel linux-2.6
gcc gcc-4.0
After this, "git checkout-index -f -q -u -a" would populate the
whole thing. Instead of linux-2.6/.git/HEAD as in gitlink
example, I am using .git/refs/heads/kernel; this would not make
a semantic difference. One big difference however is I have
only one index file that controls the whole tree, without using
a separate linux-2.6/.git/index.
After mucking with a file in linux-2.6/ subdirectory and nowhere
else, committing the result from the whole tree would work like
this:
- Look at the current commit and notice the bind for two
subdirectories; then look them up in $GIT_DIR/mtab to see
which branches keep track of them.
- Notice that there are modified paths in the index vs tree
from the last commit under linux-2.6/ directory.
- Write out only that part, re-rooted, into a tree.
git write-tree --prefix=linux-2.6
- Make a commit to record that tree, with a parent set to the
"kernel" branch head; update the "kernel" branch head at that
commit.
- Make another commit to record the tree made from the whole
index (obviously linux-2.6 subdirectory would result in the
same tree object we just committed in the subproject) with
parent set to .git/HEAD and bind adjusted accordingly; update
the "HEAD".
Now I have to think about clones and merges but this is getting
too long so I'll leave it to a separate message.
^ permalink raw reply
* Re: RFC: Subprojects
From: Linus Torvalds @ 2006-01-14 20:02 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git, Junio C Hamano, Johannes Schindelin, Simon Richter
In-Reply-To: <43C951B6.5030607@gmail.com>
On Sat, 14 Jan 2006, A Large Angry SCM wrote:
>
> So far I've not seen any convincing arguments why the sub-projects can not be
> managed by the Makefile, or equivalent, of the super-project. Particularly
> when the sub-projects have a life of their own.
Now, from a developer standpoint I actually agree with you. I find
sub-projects totally useless - I'm much happier just having separate
trees.
The advantage (as far as I can tell) of sub-projects is not that they are
easier to develop in, but that it's a total nightmare for the technical
_user_ to download ten different projects from ten different sites, and
configure them properly and install them in the right order, and keep them
up-to-date.
There are projects that I simply gave up even trying to track: I wasn't
interested in being a developer per se, but I _was_ interested in trying
to test and give feedback to the current development tree - but it was
just too damn confusing to get it working.
If I could have just done a "git clone <top-level>" to get it all, I'd
have been a much more productive user.
This is why I think sub-projects are more about "git checkout" and an
automated "git fetch" than anything else. Doing actual development etc you
can easily do one project at a time. "git diff" and "git commit" wouldn't
need any real ability to recurse into subprojects and try to make it
seamless. And if you do a "git pull" that needs to do anything but
fast-forward, you might as well resolve the sub-projects one by one.
Linus
^ permalink raw reply
* Re: RFC: Subprojects
From: A Large Angry SCM @ 2006-01-14 19:32 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Junio C Hamano, Johannes Schindelin,
Simon Richter
In-Reply-To: <Pine.LNX.4.64.0601141055210.13339@g5.osdl.org>
So far I've not seen any convincing arguments why the sub-projects can
not be managed by the Makefile, or equivalent, of the super-project.
Particularly when the sub-projects have a life of their own.
^ permalink raw reply
* Re: My first git success [not quite]
From: Linus Torvalds @ 2006-01-14 19:25 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dqb5vg$a09$1@sea.gmane.org>
On Sat, 14 Jan 2006, walt wrote:
>
> I see I still have a problem: my mental model of how git
> works is still wrong.
>
> I used 'git-checkout -b test' to create a disposable place
> to test the patch I was given.
>
> Okay, making sure I'm now sitting in 'test', I apply the
> patch to foo.c and do my testing.
>
> Now, intending to delete my 'test' branch, I do git-checkout
> master. My mental model predicts that 'master' should still
> be identical to 'origin' because I did the patching in 'test'.
> Am I right so far?
Yes.
> The problem I see is that, after switching back to 'master',
> foo.c is the patched version, not your original version.
Ahh. This is very much done on purpose.
Something that hasn't been committed (it is "dirty" in git terms) is
really not associated with any branch _at_all_. It's purely associated
with the checked-out directory.
Now, what happens is that when you change branches with a dirty tree, the
"git checkout" will do one of two things:
- if the dirty files are _identical_ in both branches, the dirty state
(remember: it's not associated with any particular branch) will follow
the branch switch.
This is very convenient. You've edited a file, but you realized that
you did this in the wrong branch. For example, you realize that you are
in the main development branch, but that your edit is pretty damn
experimental. So what you do is _not_ to undo your edit, but to create
a new branch and switch to it, and then commit it _there_.
git checkout -b experimental
git commit --all
(you might have an old experimental branch too, in which case you don't
need to create it, but then you can only switch to it if the file you
edited is the same as in your development branch)
- otherwise, the switch will fail, and you'll have to either commit the
changes in that branch, or you'll have to undo them.
Now, Junio has patches (maybe they even got merged in mainline) to relax
the "exactly the same" rule a bit, and instead try to merge any dirty
state into the branch you're switching to. Conceptually nothing changed:
dirty state is branchless, so when you switch to another branch, the dirty
state follows you.
> I figured that the git-checkout would overwrite any changes I
> made to foo.c, but that doesn't seem to be the case. To get
> your original version back I had to delete foo.c and do a
> git-checkout foo.c (or git-checkout -f master).
Yes. You can either undo the dirty state, or you can do a "forced
checkout" that will start from scratch. And the dirty state will be _gone_
in both cases. It won't be saved away in the "original branch". Again,
this is 100% consistent with the notion that dirty state is branchless.
Only _committed_ state is committed to a particular branch.
> So, I clearly don't understand what git-checkout does. It
> doesn't seem to touch the already-checked-out sources at
> all, which is what I would expect it to do.
No, you understand exactly what git-checkout does, you just didn't realize
that dirty state was different from committed state.
Linus
^ permalink raw reply
* Re: [PATCH] rpmbuild doesn't like '-' in version strings
From: Junio C Hamano @ 2006-01-14 19:17 UTC (permalink / raw)
To: John Ellson; +Cc: git, Linus Torvalds
In-Reply-To: <43C91B25.9030707@research.att.com>
John Ellson <ellson@research.att.com> writes:
>> ... In that
>> sense, maybe leaving the interim version unbuildable for binary
>> packaging might be considered a feature.
>
> What happened to this?
I consider leaving the interim version unbuildable for binary packaging
consider a feature.
If you want to build your own version, I think you could locally
tag that head and build, like:
$ git tag -a "John's GIT 1.1.2+frotz patch" v1.1.2.John0114
$ make rpmbuild
Of course you can keep a patch with the sed -e 's/-/_/' in
GIT-VERSION-GEN as Linus suggested in your development branch.
I am not yet convinced being able to build a random
unidentifiable binary package is a good thing, and "the number
of minutes/seconds monotonicity" would not work in multiple
branches case (i.e. still leaves the result unordered).
^ permalink raw reply
* Re: RFC: Subprojects
From: Linus Torvalds @ 2006-01-14 19:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Simon Richter
In-Reply-To: <7vacdzkww3.fsf@assigned-by-dhcp.cox.net>
On Sat, 14 Jan 2006, Junio C Hamano wrote:
> + The contained project is kept totally independent and does
> not have to know it is contained.
>
> + The tree for the contained project can be rooted anywhere in
> the containing project's tree.
Right.
> - The contained project cannot be rooted at the same level or
> higher than the containing project; the containing project
> can only delegate a whole subdirectory to the contained
> project.
Yes.
However, I think this is actually a _huge_ advantage.
The thing is, if you do the contained projects as "union projects" as you
suggest, I will bet that it will really really suck, because it ends up
losing the two positives above.
In particular, any real independent project will have it's own "Makefile"
or "configure-in", and often its own "src" subdirectory or other
pseudo-standard names.
And the "contained project as a link" approach has zero problems with that
at all, exactly because it keeps the projects clearly separate - just
linked (one way).
> What does "git-diff-index/git-diff-tree/git-diff-files" would do
> with them?
I would actually argue that git itself wouldn't do a whole lot with them.
There are real advantages to seeing only the diffs wrt _one_ of the
projects, and I'd argue that
git-diff-*
would actually act like they now act for directories that they don't
recurse into, ie you'd see something like
:160000 160000 5eb57670... 3f1a42aa... M sub-project
and it would be up to higher-level porcelain to recurse.
Why? Partly because that's actually likely enough for a lot of users: you
_can_ use just the raw git programs by just doing
cd sub-project
git diff
..
git commit
and so technically you aren't really missing a lot. The capabilities are
there, you just have to do some more by hand (but in many ways that is
_good_: it makes it obvious that you're really committing a _different_
subproject).
The other reason? A lot of the git infrastructure really does only work on
the "one project" level. The programs work with _one_ index, not two.
Reading two trees is perfectly possible, but unless you keep them in
separate stages, you can't separate them afterwards. IOW, trying to be
recursive really does end up being a big change, for very little gain (and
for a lot of potential bugs and instability).
In contrast, doing it at a higher level means that you have a simple and
reliable lower level that you can trust. Layering is good.
> Fetching/cloning at the core level is easy. "git-fetch-pack"
> would just need to do one level, but Porcelains need to address
> how to actually arrange the subprojects cloning to happen, which
> is harder.
>
> "git clone" would say: "Ah, now I see these gitlinks; we need to
> clone them.
Actually, I would say no - that's actually not a "clone" operation so much
as a "checkout" operation. There are strong arguments that you should
_not_ clone sub-projects when you clone the top-level project: there's no
reason to. Anybody else who clones it will have all the information you
have, so cloning th esub-project is just extra work.
So only if you actually check it out (which is often in practice the
second stage of the cloning, of course) do you want to fetch the
subproject too. But even then you might want to ask the user (he may have
a local repository for that sub-project somewhere else, so going to the
"canonical name" might be the wrong thing to do - and he might not even
care, because he might want to work _just_ on the top-level project).
> Now I'll think aloud about a completely different design.
>
> We could simply overlay the projects. I think this is what
> Johannes suggested earlier.
>
> You keep one branch for each "subproject", and make commits into
> each branch (i.e. if you modified files for the upstream kernel,
> the change is committed to the branch for linux-2.6 subproject),
> but when checking things out, you do an equivalent of octopus
> merge across subprojects.
I think this one has serious disadvantages:
- it's much less obvious when there are common names and especially
common subdirectories.
- in _practice_, almost all sub-projects are kept in sub-directories. Are
you doing to change the sub-project git tree? How are you going to
merge back to the original sub-project?
- iow, I think this only works for sub-projects that are totally
controlled by the top-level project - in which case they might as well
just be totally merged into the top level (the way we did with the
"tools" project, and largely with "gitk").
in the "gitk" case, we could actually continue to keep gitk a separate
project, but that was really fortunate: it's purely because gitk ends up
being a single file, with no Makefile at all to build it independently
etc. The moment we integrated the "tools" sub-project into git, we lost
the ability to do that, exactly because they now needed to share Makefiles
etc, making all further development very inter-twined.
Put another way: the moment you have linkages going both ways between the
subproject and the top-level project, it's no longer two separate
projects. At that point, it in practice becomes one, since the sub-project
can no longer do independent development without merging becoming a big
issue.
The advantage of having a "git link" is exactly the fact that the
dependency goes only one way. The subproject remains truly independent.
Linus
^ permalink raw reply
* Re: [PATCH] rpmbuild doesn't like '-' in version strings
From: Linus Torvalds @ 2006-01-14 17:53 UTC (permalink / raw)
To: John Ellson; +Cc: Junio C Hamano, git
In-Reply-To: <43C91B25.9030707@research.att.com>
On Sat, 14 Jan 2006, John Ellson wrote:
>
> What happened to this? I don't particularly like my fix either, but
> some kind of fix is needed for the "make rpm" target to work. Its still
> broken because of the '-' in the version string.
Do a "sed" for rpmbuild.
There's absolutely no point in trying to make git-describe use "_" instead
of "-", since having a "-" in a tag-name is very common ("my-version"),
and it would be a horrible mistake to munge the tag-names. So even if we
changed "-g" into "_g" it wouldn't help anything, and just make things
uglier.
This is an RPM versioning problem, and nothing more. So it should be
handled by rpmbuild.
Linus
^ permalink raw reply
* Re: My first git success [not quite]
From: Randal L. Schwartz @ 2006-01-14 17:48 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dqbbo9$s49$1@sea.gmane.org>
>>>>> "walt" == walt <wa1ter@myrealbox.com> writes:
walt> I suppose the underlying problem is that I don't think like
walt> a developer.
Well, I'm a developer and *I* also had that problem while working
on my "ajax" branch.
Maybe git-checkout should by default *warn* when it is leaving
things in the tree that are indexed but not updated in the index
(committed?). And you'd have to add a --no-warn thingy to turn
that off. Then beginners wouldn't be quite as confused. I'm not
talking about things that are .gitignore'd... just things like
walt's example.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: My first git success [not quite]
From: walt @ 2006-01-14 17:18 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP10B423DC1B2FC1F8C9992BAE190@CEZ.ICE>
sean wrote:
> > On Sat, 14 Jan 2006 07:39:28 -0800
> > walt <wa1ter@myrealbox.com> wrote:
[...]
>> >> So, I clearly don't understand what git-checkout does. It
>> >> doesn't seem to touch the already-checked-out sources at
>> >> all, which is what I would expect it to do.
> > Hi Walt,
> >
> > When you switch branches _uncommitted_ changes will stay in
> > your working directory. This lets you change to a different
> > branch before committing something you're working on for
> > instance.
Ah! The underlying reason is what I was missing.
> > So likely, even though you had switched to your
> > test branch to apply the patch, you didn't actually commit
> > it into that branch before switching back to master.
Right. And *my* reasoning (FWIW) is that I was intending
to throw the entire branch away so I didn't see any need to
commit. (But men always have that problem ;o)
I suppose the underlying problem is that I don't think like
a developer. My wish for a future improvement for git would
be a bonehead<-->expert switch that would turn on some basic
warning messages. In this particular example, I would have
welcomed a warning message that said: "You have uncommitted
changes! Hit 'D' to discard them or <Enter> to keep them without
committing". An experienced git user would want to turn that off,
most likely.
Thanks for the clue-stick, and I very much appreciate your
patience.
^ permalink raw reply
* Re: [wish] Auto-generate gitk's pretty pictures
From: Artem Khodush @ 2006-01-14 16:26 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <43C8FE6F.4050206@op5.se>
On 1/14/06, Andreas Ericsson <ae@op5.se> wrote:
> Artem Khodush wrote:
> But, the next feature I plan to add
> > is to show commits in the same window in a way like gitk does.
> >
>
> Why not just have a separate frame for the commits and load gitweb.cgi
> there?
Mainly because gitweb can't show the commit in most
convenient (IMHO) way, with everything on one screen.
I like the way gitk does it, when you can see all at once -
list of changed files in the lower right pane and commit message
with links to parent and child commits and diff in the left.
And with gitweb, those links to related commits must allow somehow
to highlight those commits on the diagram, wich means that gitweb
must be made aware of the frame that it's embedded in, and must
be able to call some javascript there. Eventually I will add interaction
with gitweb in some way or another, but for now, it's easier for me
to just show the commit.
^ permalink raw reply
* Re: My first git success [not quite]
From: sean @ 2006-01-14 15:55 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <dqb5vg$a09$1@sea.gmane.org>
On Sat, 14 Jan 2006 07:39:28 -0800
walt <wa1ter@myrealbox.com> wrote:
> Linus Torvalds wrote:
> >
> > On Fri, 13 Jan 2006, walt wrote:
> >> And it was all so easy I never broke a sweat. Amazing!
>
> > ...Most people don't bother to
> > explain their problems well...
>
> I see I still have a problem: my mental model of how git
> works is still wrong.
>
> I used 'git-checkout -b test' to create a disposable place
> to test the patch I was given.
>
> Okay, making sure I'm now sitting in 'test', I apply the
> patch to foo.c and do my testing.
>
> Now, intending to delete my 'test' branch, I do git-checkout
> master. My mental model predicts that 'master' should still
> be identical to 'origin' because I did the patching in 'test'.
> Am I right so far?
>
> The problem I see is that, after switching back to 'master',
> foo.c is the patched version, not your original version. I
> figured that the git-checkout would overwrite any changes I
> made to foo.c, but that doesn't seem to be the case. To get
> your original version back I had to delete foo.c and do a
> git-checkout foo.c (or git-checkout -f master).
>
> So, I clearly don't understand what git-checkout does. It
> doesn't seem to touch the already-checked-out sources at
> all, which is what I would expect it to do.
>
> Can someone hit me with the clue-stick here? Thanks!
>
Hi Walt,
When you switch branches _uncommitted_ changes will stay in
your working directory. This lets you change to a different
branch before committing something you're working on for
instance. So likely, even though you had switched to your
test branch to apply the patch, you didn't actually commit
it into that branch before switching back to master.
Here's a little example that should show the difference:
Create a test repo:
$ mkdir walt ; cd walt
$ git-init-db
defaulting to local storage area
Create a simple file and commit it on the master branch:
$ echo A > file
$ git add file
$ git commit -m "initial"
Committing initial tree a9e3325a07117aa5381e044a8d96c26eb30d729d
Create and checkout a new branch named "test":
$ git checkout -b test
$ git branch
master
* test
Modify (ie. patch) the file:
$ echo B > file
$ cat file
B
Now, if you switch back to the master branch, the file is still patched:
$ git checkout master
$ cat file
B
Switch back to the test branch and commit the change this time:
$ git checkout test
$ git commit -m "test branch" file
$ cat file
B
Now, this time when you switch back to master, you'll get what you expect:
$ git checkout master
$ cat file
A
HTH,
Sean
^ permalink raw reply
* Re: My first git success [not quite]
From: walt @ 2006-01-14 15:39 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0601130909290.3535@g5.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 13 Jan 2006, walt wrote:
>> And it was all so easy I never broke a sweat. Amazing!
> ...Most people don't bother to
> explain their problems well...
I see I still have a problem: my mental model of how git
works is still wrong.
I used 'git-checkout -b test' to create a disposable place
to test the patch I was given.
Okay, making sure I'm now sitting in 'test', I apply the
patch to foo.c and do my testing.
Now, intending to delete my 'test' branch, I do git-checkout
master. My mental model predicts that 'master' should still
be identical to 'origin' because I did the patching in 'test'.
Am I right so far?
The problem I see is that, after switching back to 'master',
foo.c is the patched version, not your original version. I
figured that the git-checkout would overwrite any changes I
made to foo.c, but that doesn't seem to be the case. To get
your original version back I had to delete foo.c and do a
git-checkout foo.c (or git-checkout -f master).
So, I clearly don't understand what git-checkout does. It
doesn't seem to touch the already-checked-out sources at
all, which is what I would expect it to do.
Can someone hit me with the clue-stick here? Thanks!
^ 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